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.
Related
In my application, I have multiple dynamic lists in which the user can navigate between them.
For simplification, the app has a main screen which shows a list of items.
When the user clicks on any of the items, a new list should be shown, and again if he/she clicks on an item again, a new list should be shown.
Moreover, the user should have the ability to navigate back to the previous screen.
I considered two options for implementing this:
Using the same recyclerview and change the content when needed.
Using fragment with recyclerview and replace the fragment with a new fragment that shown a recyclerview with the new content.
My question is about the implications of each of these implementations, especially in term of efficiency and user experience, or if someone can suggest a better approach to this situation.
I know a little about fragments and recyclerview, and I think that using fragment might be preferable since it is suitable if I ever plan to make the application fit into tablets and devices with a bigger screen.
I planned to test both to understand them better. However, I still hoped to hear more opinions.
I would like to thanks in advance to anyone who will share his opinion with me.
I think Using fragment with recyclerview and replace the fragment with a new fragment that shown a recyclerview with the new content is pref rebel because if you need some ui changes also fragment will be good choice.
I will suggest you use fragments for this implementation. So that you don't write huge lines file in one class.
Also it will reduce future problems if app will upgrade and UI or functionality changes, then you will have separate code to change.
Keeping adapters and fragments separate will lead more efficient way to manage user interactions.
Also you don't need to maintain views stack, android will take care of backpress itself.
I want to create something like this:
That is, a menu which I can feed an arbitrarily nested tree of strings to which will then lead to an activity who has access to the selected item.
Should I create an activity class TreeSelectActivity then pass it a List<TreeNode> in a bundle and then recursively create a list of the next activities for each item? One activity per item doesn't seem like the correct way of doing this. Maybe it would be better if they were fragments?
What are the pros and cons of different approaches to do this, and which approach is easiest to implement?
Look into Wizard Pager to see if this does what you need.
Otherwise, you could implement it as an activity that takes a tree and has an adapter that shows its current level, and then passes subtrees to new activities via intent extras.
Or you could implement it as a Fragment that does approximately the same thing and stay in the same activity and just do FragmentTransactions.
I will try to describe my question as clearly as possible here. I am a novice developer and I am having trouble deciding how to correctly organize my app. Hopefully some of you guys can provide me with some insight on the best practices.
I have a FragmentActivity called Form.java. This activity is supported by tabbed navigation. One of these tabs displays a Fragment called SymptomBrowser. This fragment is basically a list view, with the option of the user adding his own items (there is a Add Symptom button).
The AddSymptom Button opens a List of all the available items that can be added to SymptomBrowser. When one of those items is selected, the user is brought to a form inquiring about that particular item.
In short: Form.java -> SymptomBrowser Fragment -> Fragment with the list of all symptoms -> Edit that particular symptom and store form data.
There are over 50 symptoms. Should I add 50 different fragments for each? Or should I have one fragment and many different layouts? Am I doing this correctly? How should I organize the app structure?
Thanks in advance!
You have one single fragment filled with TextViews and stuff. All the symptoms must share common data, e.g. name, description, etc.
When you "load" a symptom, you basically change the data inside the same fragment.
I have a hierarchical data structure. As an example, lets consider my data television shows. Each show has multiple seasons and each season has several episodes. I want to have a list that displays all shows. When a show is clicked the list will then display all seasons for that show and when a season is clicked the list will show all episodes for that season.
OK so with that out of the way, currently I have ONE Activity that implements a Loader through LoaderCallbacks. This loader returns a full hierarchy of data (AKA all shows with all seasons with all episodes). I then use a different ArrayAdapter depending on the level of data I'm on.
Is this the 'right' way to handle this kind of data? Should I instead have a loader and activity and adapter for each level of the data?
Sorry if this is confusing, thank you in advance for your insight.
There really is no right or wrong here. I would go for one activity and adapter per set of data. This will make your activities less complex and make them decoupled from each other. In your case I would have:
ShowActivity+ShowAdapter
SeasonActivity+SeasonAdapter
EpisodeActivity+EpisodeAdapter
Your data model (with Shows, Seasons and Episodes) should be made accessible to the activities and used to initialize each activity and adapter with the correct data.
Once a show has been selected I'd pass on the id of the show to the next activity through the intent bundle, pick up the show id in the SeasonActivity, fetch the relevant seasons from the data model and display them. The same goes for the transition from season to episode.
Using the approach of one activity per list you'll also get nice transitions between activities and don't have to worry about dealing with the back button to navigate up through your hierarchy.
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.