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.
Related
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.
I have a requirement to display a list of items from a database query. Some of the items need to be displayed twice; once at the top of the list if a specific flag is set, which is the primary sort criteria, and again in their natural position in the list according to the secondary/default sort criteria.
I have my database query correctly returning multiple rows for the relevant items. The rows differ only by the special flag, and the result appears exactly as I expect.
My question: is it safe, from the point of view of the CursorAdapter or the ListView, to have multiple rows with the same _id? Or is there a requirement somewhere that the _id field be unique in a given result set?
It seems to be working just fine, but I don't know if I'm just lucky.
The short answer...sorta.
The slightly longer but still quick answer...so long as you aren't using a ListViews choice mode...you'll be fine.
CursorAdapters derive their id for a given item based on the "_id" column. AFAIK, this is pretty much only used when determining which item is checked or activated. The whole checked or activation state only become a relevant concern when you enable one of the choice modes. In fact, not having a unique id returned with getItemId() for any adapter will cause the following same problem.
Lets say you've set the choice mode to CHOICE_MODE_MULTIPLE_MODAL. If the user activates both of your dupe row id items; then rotates the device, they will find that only 1 item has been restored to an activated state instead of both.
Side note, this may or may not affect the selected state too. Quickly glossing over the source code looks like that even though it tracks both a selected item via id and position...it seems to only use the position number to determine which view to show selected. I could be wrong though.
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 ?
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.
I am building an Inventory application. The items are shown in a grid view and each cell of the grid view also has a TextView in the upper right corner that displays the available quantity of the item. The user can single click on the gridview cell to increase the quantity or long click to decrease it.
I am currently using a class derived from SimpleCursorAdapter to display the data, but I am not sure about how to update the quantity in the DB. I am afraid that if I write directly to the DB and then create a new cursor and change cursor that the application might become bogged down if the user clicks repeatedly (say to add 10 items)
I have considered copying the data from the query cursor to an array in the Activity and then using an ArrayAdapter but this seems kludgy.
I have also thought about creating an array in my SimpleCursorAdapter which would cache items that have been modified and then save those items when pausing...
Is there a better way? A more Android way?
I guess this comes down to: what is the best way to make rapid changes in the DB and UI?
I don't know much about Cursors in this regard, but I would create a custom ArrayAdapter based on a model object rather than a Cursor. That's just a personal preference, but by doing this I don't have to make any assumptions about the Cursor implementation or know it inside and out.
Let's say you're displaying a collection of type Item in your grid. I would create a class called ItemsList that derives from ArrayList<Item> and my adapter would derive from ArrayAdapter<Item>. The reason you create a wrapper around the ArrayList is that you can allow the user to interact with it freely and mark it as "dirty" and allow it to update the database asynchronously. This way, you just call notifyDataSetChanged() on your adapter and you don't have to think about the overhead of updating the db...you've separated interacting with the collection being displayed and the process of updating the persistent storage.
Btw...this video is a must when working with ListViews and Adapters if you haven't already seen it:
http://www.youtube.com/watch?v=wDBM6wVEO70
You could use a regular listView and a regular Adapter with a list (arraylist) of items in it. Every time user clicks or long clicks you can edit the list in your adapter and notifyDataChanged() which will reflect the list changes on your listView. If you want to keep your list after user quits your application you can use either database(for bigger amount of data) or preferences (for smaller data amount).