I'm new in android development, and i just got into fragments so im so confused about this.
i want to build and app that takes 2 listfragments, the first one is a categories list and i want that when i click on one of those categories the second listfragment show me the sub-categories of that one, i've used and example from here http://mobile.tutsplus.com/tutorials/android/android-sdk_fragments/ to try to understand how information flows but i really can't figure it out, and i really don't know how to do that, any hel would be very appreciated
That tutorial should be fine for what you want to do, with a few tweaks.
Essentially, the flow of information should be from your category fragment, up to the Activity which contains both fragments, which should then update the sub-category fragment as appropriate (i.e. depending on which category was selected). You could update the sub-category fragment from the category fragment but as far as I understand, that's bad practise.
So your Activity knows what is going on in the categories fragment, you'd define an interface of the Fragment (e.g. OnCategorySelectedListener), which the Activity would implement. The category fragment, when it's being attached to an Activity should check that that activity implements OnCategorySelectedListener. Then, when an item in your list of categories is selected, the fragment will call up to the activity and basically says "hey, look, a user wants to know more about category X". The activity will then deal with the logic of determining which category was clicked and so which sub-categories to show.
The Android developer document on fragments is pretty useful in this respect and explains everything thoroughly. Might be work having a look through the samples on that website too, in particular the News Reader sample.
Good luck!
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
I have a typical dual UI scenario - a list of categories, which when one is clicked, loads a category detail fragment containing a list of items in that category. On the phone, it's implemented as a stack-of-cards UI, opening up the details in a separate activity on top of the category list. On a tablet, it's the category list on the left, with the details on the right.
In the details pane, there's a button to add an item. The details fragment has an interface, required of Activities, with an onClickAddItem method, which should bring up a DialogFragment to ask you for the details of the item and add it when it returns.
The problem: both the tablet version's all-in-one Activity and the phone's standalone details Activity need the same onClickAddItem logic. There's a sinking feeling deep in my gut that the proper solution for this is to pull that logic out into yet another class, but the need to create several million files to do simple things in Android is slowly driving me insane, so I'm hoping there's another best practice I'm overlooking here. Thanks!
If your "add" button is in the detail fragment, there is no reason to handle the click event in the activity.
I think you should put the click event handling in your detail fragment.
Why do you want to keep all database access in the activity ? Make sure you're properly abstracting database access ( using a ContentProvider for example ) and don't be shy to use your abstraction wherever it makes sense. Adding an item using a ContentProvider should be as simple as:
getContentResolver().insert(myUri, myNewItemContentValues);
It you need to display a dialog, just get a reference to the current activity from the detail fragment, and use it to display your dialog.
If several fragments share the same functionality, you may need to write a simple helper class with some methods like:
public void showAddItemDialog(Activity activity)
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 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.