is there any similar source or tutorial that you recommend that is similar to this function of the widget?
The function is when we press the + button it will show the Category box again.
It's actually much easier than you think.
First, I'd suggest you to take a look at Flutter widget called ListViews (Flutter ListView, official documentation). They're amazing since, simply said, you can basically create a loop of widgets that show different data (and most of the time you'll show data from some kind of array that you'll access through the index of the current rendered item in the ListView).
How will you work with them? Basically, you're having a list of categories. Each category is having some data (for example, two texts and one boolean - availability toggle).
You can give an instruction to the ListView widget to render category widgets based on the list you'll maintain in your application flow. That list would contain list of categories that should be shown (so let's say, on the image you provided, we have only one category added).
When someone clicks on the "+", a new category item will be added to the list (most likely using the setState or other kind of logic that'll lead up to re-rendering) and after that, the ListView will detect a new item and show up a new widget that will be filled with the content from the newly inserted item at its index.
Related
Hello there guys and ladies,
Right now I'm developing a content-providing application, which should be able to get live-ticking content.
So if content is uploaded to a server, the user should get the recent news. It don't have to be imediatly. I'm more thinking of an API-Calling method, which is doing an API-Call every now and then.
But what's more important right now: The content is provided in a List. So after fetching the content i've an arraylist, which is filled with content-objects.
Those content-objects will have a timestamp.
I wanna create a timeline. The thing is, if there is new content coming in, it should be marked. for example in a different color.
So imagine a timeline, when ur looking at the content. Then you put your phone away. and after you looked at the app again, there are e.g. 4 new content-objects available. These 4 content-objects should be marked in the timeline.
Can I dynamically color a listview? or would you rather recommmend another layout-element to reach my goal?
I've never done any design aspect in Android before, so I'm quite lost in this field. Do you guys know any good tutorials or books for designing android applications.
you should use a listview, and then in your list which contains your list view object, you should just add the new elements to it, and call adapter.notifiyDatasetChanged(). this will update your list with the new items. As for the color you could add an object field called color where you could store the hex value for your row, and each time you add new items set thier color to what ever color you want, and unset the other items in the array. then in the adapter change their background color accordingly
The title doesn't really cover it all. It's basically the following use case:
Select a bunch of items in a listview
Move to the next activity
Show the selected items in this new activity in a listview
If the user decides to move to the previous section the same items should still be checked
If I were using POJOs I could simply add an OnItemClickListener to the ListView and add the items to an array each time user clicks an item and ship this array to the new Activity. However the ListView is populated using a Loader which gets the data from a ContentProvider and puts it in a SimpleCursorAdapter.
In the current state I can think of a few possible solutions:
1) Add an extra column to the relevant table of the objects in the ListView. Each time the user selects an item this column is updated to indicate it is selected.
This has a few advantages:
Once I have moved to the next Activity I can simply query for all selected items.
When moving to the previous activity I can use this column to show a selected view.
But also a few disadvantages:
Requires an update each time an item is clicked, triggering the loader.
Requires a custom adapter which uses the state of the new column to decide whether it should or should not be shown as checked. Possibly creating a delay between clicking an item and actually showing it as checked.
The default check options in the ListView will be unusable
2) Track the IDs of checked items (using OnItemClickedListener or getCheckedItemIds) and pass them to the next Activity. In the new activity I then create a selection argument of "ID = ? OR " repeating N times (and excluding the last OR) and use the given array as the selection arguments.
Advantages:
No need to keep updating the database.
No extra columns in the database.
Item checking has no extra delay.
Default check options from the listview still usable
Disadvantages:
Moving to the previous activity is now harder. I could return the list of selected item IDs, but the listview only has the option setItemChecked which takes a position. So I'd have to iterate over the entire adapter to find the positions of the items and set them as checked.
I'm probably capable of implementing them without any hassle. At the moment I'm gravitating towards the second option.
So ultimately I have the following questions:
Is there an easier way to do this in Android.
What would be a good way to recheck the items (see the disadvantage in the second suggestion and if there's no better way to do it).
This ListView will also get a search function which will probably again make it a bit harder because if I'm not mistaken filtering resets it every time. So I'd also have to recheck items every time (ideally during filtering).
Your disadvantage "Requires an update each time an item is clicked, triggering the loader." is not quite true it will trigger only if your ContentProvider calls notifyChange you could have it not to call notifyChange in some specific cases
and pressing back by going to the previous activity shouldn't be that hard only if you explicitly call finish() on your activity, otherwise it should be able to save its state onSaveInstanceState
Either way i would use a third approach and simply wouldn't use a second activity but would keep everything inside a single activity use pearhaps two Fragments one for the initial check list and the second one for your second preselected list and would use callbacks and let the activity manage all,is that possible for your use case ?
first of all please forgive me for asking very broad question, I am designing an android app which requires atleast 600 rows and about 50 columns in a single table, i have created code for it and initialized my db with data required.
Now i am faced with a simple problem and no where to go or look for basically i
i have situation matches to attached table, wherein separate list activities are called for each column, for example first list activity should have product name only while clicking in first activity user shifts to new list activity having year after clicking year user goes to version and so on. it is to be noted that filtering is required at each stage to remove unrelated entry.
can any one guide me how to achieve this goal.
thanks and regards
This is quite a exquisite behaviour to implement... But hey, if you do wanna do this, here is a possible approach:
Your ListView will need a custom adapter implemented using BaseAdapter. This CustomBaseAdapter will be backed up by a list of lists of objects, a "stack of selections" and a integer state holder.
The list of lists of objects will form a matrix just like your image containing "SN, product, year, version, color, custom text" respective lists, that will be used together with the state holder that allows you to know in what of those lists the mode is currently in and what mode next to go.
Your "stack of selections" will help you do the filtering needed by the user, based on what stack level you are currently in, that will also be controlled by the state holder.
Everytime the user clicks one row, your ListView will fire the onItemClick that calls your adapter to add the user selection to the "stack of selections", and change its state to update the data based on the state holder next possibility. Remember your state holder cannot be bigger then your matrices number of columns, since it holds the column currently being showed.
The "change its state" part of the above is simply changing the currently state holder and calling notifyDataSetChanged, assuming you will implement a getView method on your adapter that takes note of the currently state of the state holder and the current selections of the "stack of selections" to filter the content of the list it will show accordingly.
The ListView will refresh itself and your getView method from your adapter will get the views based on your current state.
Sorry for the big response, i can try to explain better if needed.
Try to focus on general "dos and donts" regarding lists, e.g. is
adding and removing 30 items of a 200 item list better then clearing
and repopulating? Or any other tips in this area - I cant really try
on my phone, to fast for that :-)
Is there any way to calculate the memory overhead / calculation power of list operations. The background is as following:
I have a list view on a page, the page has e.g. 3 Tabs at the bottom (All, Search, Recent). Now if you click on a tab, the listview should show you the approriate items.
There are two different approaches now, one is:
Use a single ListAdapter, filter the items accordingly
- If you click All, just put all items from the DB into it
- If you click Recent, just put the items which meet the requirements
Use two (three..) ListAdapters, one for each category
- If you click All, setAdapter() of list to the approriate one
- If you click Recent, setAdapter() to appropriate one
We are talking about a list of 200 items, which are complex objects created out of a database. When e.g. searching for an item, you enter part of the title, and the list should only show the appropriate items. The items will not be recreated, I would query for the IDs only, and use the buffered items (see later on datastructure).
What I am also not sure about is "where to filter", I could do it in the database (select from where title LIKE abc) and then EITHER:
remove not matching items from the list and add all matching (but not included) items
clear the whole list, add all matching items
Again, to clarify the structure of the App data:
Database with raw simple entries (with IDs + title + ...)
HashSet with complex entries, created once from DB, readonly + always all entries
ArrayList of current entries shown in a listView
I hope you get my drift, I am trying to get a feel for "expensive" operations. Perhaps, as a last motivation to answer, I will write some cases down, and you can give an opinion about how costly they are:
Selecting N items (ID only) from DB with "title LIKE"
Iterating a list of 200 items with a "title.contains()" and using only matches
Removing 100 items from an arraylist SHOWN by an list view
Removing 100 items from an arraylist not shown, then connect and show
Thanks for any feedback, or any tips for bad practices. Especially possible event trigger problems by working on visible list elements, instead of doing it first "in the background" and then setting a new ListAdapter
I see you have accepted an answer already, but I think I don't agree, because ArrayList has to copy all elements, if in the middle is an element added or removed.
I understand you already have a HashSet with all entries.
In that case, I believe the most efficient adapter is a custom ListAdapter inspired from ArrayAdapter
your adapter stores an ArrayList mAllObjects of all entries (for the "all" tab).
your adapter stores an ArrayList mRecentObject of recent entries (for the "recent" tab)
your adapter stores an ArrayList mMatchObject of matching entries (for the "search" tab)
your adapter has two filters
the recent filter returns the mRecentObject list (and creates it if it does not exist already)
the match filter creates a new mMatchObject list and adds matching elements. There is no optimization to be done here. the delete()method on an ArrayList is O(n).
I'm not sure I understand what you're trying to do with the whole list thing, but regarding filtering, you should do it on the database side (in the select statement you mentioned)... especially since this application is for mobile (given the comment at the top) and you would want to offload intensive operations to server side rather than leave them on mobile.
Slight stab in the dark. From the (fairly cursory) "Designing for Performance" document, it would seem that object creation, especially short-lived ones, have very high cost. I would interpret this as coming from two places: 1) object creation overhead (especially for complex objects), and 2) invoking the GC when these go out of scope or are explicitly destroyed.
Thus, as a starting point, I'd argue that you would want to do the work in the DB, and push the deltas to the view. So, per your original question, do:
remove not matching items from the list and add all matching (but not included) items
I suppose you could write a synthetic benchmark for this to get a feel for the differences in speed. However, in my own code, I try and avoid short-lived objects as much as possible as suggested by the performance document. The impact of the GC is heavyweight, as it often will disturb the UI thread and make it hiccup as it goes about its work.
I'm writing my first Android app and want to pick up good coding practices. I have an Activity which contains a 2-column grid of all the data items available in the app (listActivity). There's an Activity to create a new data item (createActivity), which is triggered from the listActivity. Now, when the createActivity finishes, what is the best way to handle this situation with respect to the following:
Should the createActivity store the new data item in the permanent storage and return only the ID of the newly created item to the listActivity OR should it return all the data fields of the item as putExtras() of the returnIntent?
Should the listActivity 'repaint' the entire data view or should it simply append the newly created data item dynamically? Will the answer to this question change if the listActivity also has to handle delete & edit events? What if the list view is NOT a 2-column grid but a single column list?
Should the createActivity store the new data item in the permanent storage and return only the ID of the newly created item to the listActivity OR should it return all the data fields of the item as putExtras() of the returnIntent?
That depends on what your listActivity needs to know about the new item. Generally saving the data in storage and only sending back the ID should be enough - based on my answer to some of your following questions. You might also need some indicator of the action that has been performed (Create, edit or delete).
Should the listActivity 'repaint' the entire data view or should it simply append the newly created data item dynamically?
Yes, if something in the underlying Adapters data set has changed a repaint is most probably needed (or at least calling notifyDataSetChanged() on the Adapter). If the order of the items in the list does not matter, you could just append the item to the list - but I still recommend that you save it in storage and then retrieve it when you want to add it to the Adapter. This is also why you would only need to pass the ID around. Also in order to append you would need some way of knowing if the last listitem has one or two columns filled.
Will the answer to this question change if the listActivity also has to handle delete & edit events?
The edit functionality is basicly the same as created (except the fields have values when you open the edit view). If you delete an item from the list a full repaint of the list is probably the best thing to do, as to not confuse the order of the items.
What if the list view is NOT a 2-column grid but a single column list?
Appending would be easier - but there is not much difference. In a single column list you might be able to avoid some full repaints that would be needed in a 2-column list - though I don't think it will make much difference.