I have a page that list a current list. The user then clicks the floating + to add an item to this list and go through a wizard and then when they are complete, it redirects them back to the current list. I noticed that if I hit the back button, I go straight through the wizard again and back to an outdated list(instead of a current list).
I am wondering how people deal with user experience. If they land on the main page, I would simply (I think) like to just wipe the history as it is not useful at that point and more confusing than anything.
I am curious on
How to wipe the entire history
Is there other UX options that make sense to users
Check out this question and answer. Android: Clear the back stack. It will help you with your "history" (referred to as the back stack).
It should also fix your issue if the outdated list, however, I'm also questioning your method of adding an element to a list that results in an outdated list being shown when going back in the stack. If your data is properly managed, that shouldn't happen ever. To me it sounds like you are passing a list as an extra to an activity and setting a member variable in the activity class with that list. Or you have a static list somewhere and you only loop over it to create elements to display in the onCreate of the activity. Either way, it is a bad practice. The view should be notified of updates to the model. Look into the MVVM (model–view–viewmodel) design pattern or the MVP (model-view-presenter) design pattern for ideas of what this means. Ideally if you are displaying dynamic data in a list, you should be using either a list view or a recycler view both of which need to be notified of changes to update.
Related
This question is more my way of gauging a better understanding of the "Proper" way to handle this content flow instead of just "whatever works" or the "quickest" solution to code. Im looking for the best on performance and user experience.
The situation:
So my main activity handles my NavigationDrawer and is the basis of the app. The initial view that is loaded (navitem 0) is a Fragment which contains a RecyclerView(custom adapter, list item model, view holder). This list displays data pulled from an XML file and is returned as an Arraylist of Topic objects (each containing 3 strings and an array of Issue objects).
The array of Topic objects are used to populate the listitem w/ a title, desecription and image_name strings. (Not using the Issue array yet).
Here is where you come in ...
I know need to handle the click event on the Topic and display a new list (w/ different adapter) of the specific Issue object array for that Topic.
I'd like to know if its better to replace the current fragment w/ a new fragment for handling the Issue data. Or would it be better to launch a new activity to display the Issue list data.
Keep in mind, i want to ensure that navigation up will return the user to the previous view. ie. when clicking a Topic you should get the Issues for that topic. When going back, the TopicFragment should be displayed w/ its initial list.
If this is confusing you?
The core part of this question is needing to know the proper navigational way of displaying a List that when clicked needs to display another List specific to the parent object. Is fragment to fragment handled by callbacks in the MainActivity the best way, or is Intent'ing to another activity to handle the 2nd list better?
Whether you use a Fragment or an Activity to display the second list, it doesn't matter from a performance standpoint. If I were you, I'd use an Activity: it is always better to use a Fragment only in situations that require the explicit use of Fragments (such as a FragmentTabHost or a ViewPager).
But I do have another suggestion for you. Instead of going to another list, why not display your Issue objects as the child items of an ExpandableListView, and the Topic objects as the parent items ? Then when the user clicks on an Issue child item, go to the detail page containing details of that Issue object. To me, the List->Detail pattern is a far more familiar idiom than a List->List->Detail flow. Its what ExpandableListView was made for.
Imagine we want to design G+ application. It has a list activity/fragment and by click on an item then detail activity/fragment will be displayed.
My problem is, I don't understand if user hits plus button in detail activity and click on back button then how its counterpart item in list knows that user has clicked it in detail screen (since it shows number of plus oned as same as detail activity)?
Though it's bit late, thought of sharing my answer as it might help others who are coming across similar situation. Basically, you need to create an interface in the detail fragment class and implement it in the parent activity and use it to update the master list through notifyDataSetChanged().
You might want to refer to following SOF thread as an implmentation reference - Update ListView in Master/Detail after a form is saved
Okay, I know there is a lot of discussion according to this topic, but I couldn't find any answer.
My problem is the following:
I have an Activity with NavigationDrawer, so the Fragments are added from code. The first fragment is a ListFragment, witch reads data from an SQLite DB stored in the SD card. The data loading is kind of slow, because I load the nearest n place based on location. So I don't want to load the list every time.
Now, if the user clicks an item, a second Activity shows the details. The first strange stuff is the first activity is destroyed almost every time a leave it, witch is awful, but still I could save the state.
The discussions that I rad so far indicated that the Activity should retain the last displayed Activity, and it kind of does, because if I change the content of the first activity from the Drawer before navigation the correct Fragment is created.
The problem is that even if the ListFragment is being re-used its contents will be missing (since I create a new View in the onCreateView() because of custom layout). I guess I should use the Bundle provided as a parameter in onCreateView(), but I just couldn't figure it out.
So summed up: what is the proper way of saving the items of a ListFragment, even if its parent activity is destroyed?
It turned out that I had a developer option turned on that killed all Activities that I navigate from. I didn't know that because I use my phone in Hungarian (guess it'll change from now), and for some reason they felt like they had to translate the word "Activity", making the whole option description not understandable. Sorry about that, now my first Activity is kept in the memory, so the whole issue is not present...
There are two things which I like on the Instagram for Android app and I'd like to implement them in my app.
1. Infinite go back in history of fragments
If you tap on a user, you can see his details, taping on followers will return a list of followers, pressing on another user will show his details... and so on. Basically you can do this thing for many times BUT when you go back everything is instant without loading. How can this be implemented? My initial thought was to have only one activity with a top actionbar and for the rest use fragments (one fragment for user details, one fragment for users list) and so on. The problem is I can't think of a good way to allow going back in history. The only way I can see is by caching all the data (user data / list adapters) is an ArrayList so when the user presses back, take the last item from the list and instantiate the fragment. Is there a better way of doing it ? I'm thinking I could start a new activity for each user interaction and them when the user presses back, simply finish the current one. My only worry in this case would be running out of memory. Is there a way to cache fragments with their state ?
2.GridView inside ScrollView
On user details there are two main layouts: a layout with user details and a gridview of images. When the user scrolls, at the scroll's end, the gridview gets new set of items (load as you scroll). While I know how to implement load as I scroll for the gridview, I don't know how to add the gridview inside a scrollview and keep listening for scroll events
Haven't got a quick answer for number 2 but for the first question why not just add the fragments to the backstack with FragmentTransaction.addToBackStack ?
That way you get the natural back-action with fragments without having to start new activities for every action.
I am going to develop an app with the following structure:
Search: Lets user search for articles and displays search results in a list
Article: Displays an article
UserList: Displays a list of articles the user has chosen to add to the list
UserListItem: An item that represents an article in the list mentioned above, and lets the user add custom information via some EditText-fields.
The Search, Article and UserList seem like they could be implemented as fragments. But what about the UserListItem? There will of course be multiple UserListItems on the screen at the same time, could it still be implemented as a fragment? If not, how should it be implemented?
I'm having some trouble grasping the whole fragment concept. It seems obvious how to use it in the standard scenario, i.e. Search-pane and Article-pane. But it's a bit unclear to me if it should/could be used in a scenario where you will have multiple instances of the same fragment displaying at the same time.
I haven't yet written any code, because I want to have the overall structure clear before I start, so I don't have to go back and change everything.
This might be a bit much if you are a beginner, but if you want to add searching capabilities in your application, consider creating a search interface.
From the documentation on Fragments:
You can think of a fragment as a modular section of an activity, which
has its own lifecycle, receives its own input events, and which you
can add or remove while the activity is running (sort of like a "sub
activity" that you can reuse in different activities).
That being said, there is a huge difference between incorporating a behavior in your screen's layout and wrapping that behavior in a Fragment. In your case, it really wouldn't make sense to wrap each list item in a Fragment as it would be ridiculously inefficient to instantiate a new Fragment for each item in your ListView. Representing each list item as a Fragment would give each row its own lifecycle, which is obviously not what you want. What you probably want to do instead is represent each list item in XML, and have the Fragment (or Activity) that holds your ListView manage these list items as necessary.