I've been struggling with this for a while now, I want to start off with a diagram of my problem:
The three navigation drawer buttons are part of my Base Activity. Each purple block below the three buttons are fragments, and the descendants of each of those blocks are in turn fragments. I'll use the master and detail fragments as a demonstration of the issue I am having...The user clicks the nav drawer button, which opens the master fragment that hosts a list of articles. Once a user clicks one of those articles, I then open the detail fragment inside of the master fragment. So If I find myself at the detail, and I decide to open the nav drawer and click the third button for instance, then click the second button again, I want the detail to be open still, and if I hit the phone's back button I want it to move back to the master fragment, and end there. Any tips will be helpful, as I am probably going to use a similar pattern for the first button, it's main fragment and it's children fragments as well.
In my opinion, the cleanest way to handle what you are describing would be to have three separate FragmentActivity classes that implement the DrawerLayout instead of one monolithic BaseActivity.
Each button in the drawer should start it's respective FragmentActivity using launchMode singleTask. This ensures that you launch the same activity instance each time, instead of a new one, which will maintain your back stack for each activity as you switch between them using the drawer buttons. See Android Developer Guide Activity:launchMode for more details.
Each of the three FragmentActivity instances should be responsible for starting and managing it's fragments using listener interfaces. For example, where you have your Master fragment opening a Detail fragment directly, you should instead have your Master fragment tell it's FragmentActivity that it needs to open the Detail fragment. See Android Developer Guide: Communicating with Other Fragments for recommended practices in implementing this type of decoupled communication between FragmentActivity and Fragment. It will make your life much easier down the road when you want different layouts for tablets, etc.
Each of the three main drawer "tasks" seem to be unique enough that isolating each within it's own FragmentActivity seems the best way to implement what you are trying to do. You can apply this same approach for each of your main sections.
I had the same problem and didn't want to go to multiple activities since that would complicate the back navigation of my application. Your fragments won't save their state automatically unless the activity lifecycle events are being called.
In our case those don't happen since we're not leaving the activity. You can use FragmentManager's saveFragmentState on the fragment you are replacing to manually trigger the state saving and get a Fragment.SavedState object. You can keep a list of your SavedState objects and when pushing a fragment check if you have a saved state for it. If so you can call Fragment setInitialSavedState which will cause your fragment to load the previous state.
Now in my app as a user toggles between fragments with their own child fragments the state is retained when they come back.
Related
I set up my application in the following way and am curious if it's considered "best practice." I have two activities and two fragments. Activity 1 launches and immediately uses Fragment 1 to display a RecyclerView of items. An Item is clicked in the Fragment, it's communicated back to the Activity through an interface, some logic occurs and Activity 2 is launched, which immediately uses Fragment 2 to display the detail of the selected item.
I did this because A)I like the logical flow of Activities within an application and 2) I needed to create tablet layouts in which I could use both the Fragments to fill the screen.
The more I'm looking at this thing, I'm thinking why not simply have 1 Activity that manages both of these Fragments? Activity 1 launches Fragment 1, item is clicked, info goes back to Activity, FragmentManager replaces Fragment 1 with Fragment 2.
My question does one of these ways adhere more to "best practices" or are they both fine and it's a matter of choice?
You've not described your problem clear enough to use more than one Activity, other than unrelated data to the list and what happens when you click there.
What you described is a "master-detail" flow, and that is a good use case for one Activity and two (or more) Fragments - a list + some detail page. This especially makes sense on larger screens when you can show those Fragments side-by-side.
For example, you can have an Activity that holds a navigation screen (whether that be tabs, a drawer, or a bottom view), then everything you navigate to within there is a Fragment.
Otherwise, you redirect to some "settings" page, for example, that is a new Activity, which demonstrates the "Single responsibility principle" in your UI.
Well you can go with the single activity - multiple fragments. You can pass data between fragments using bundle as well. Matter of choice also depends on the use case. But fragments are made to use as light weight activity that requires less resources then activity. Most of the things are possible with fragments. So unless it is not required to use activity my choice goes with single activity - multiple fragments.
I want to implement a Navigation Drawer in my app but I am conflicted on whether I should use it with Fragments or with Activities (see image below for more details).
Is there any real advantages or disadvantages between the two or is it just a matter of preference?
Edit:
Just to clarify my question:
In the case of using Activities instead of Fragments;
When I select "Import" that will open an Activity and not a Fragment and if I select "Gallery" it will open an Activity with contents for gallery item etc. and so on for the other items in the Drawer window.
In the case of using Fragments instead of Activities;
If I choose from any of the Items in the Drawer window it will open their contents in Fragments for each Item selected instead of starting new Activities for each selction.
Remember Fragments need an Activity. You always have one minimum when using Fragments.
If you are talking about to use like main element in the most cases is best use fragments because you have more flexibility UI.
The performance would be better if you have 3 activities and 10 Fragments or have 13 Activities? Think about it, the navigation within the App would be the big challenge but it's just about using the right flow in your application.
Edit:
For instance:
Drawer With Activities instead of Fragments
If you were to use NavigationDrawer without Fragments then it would be best to keep the NavigationDrawer instance in a single Activity and when you navigate the app by choosing from the items in the NavigationDrawer then each of those Activities that are started should not implement the NavigationDrawer but instead should implement the back button to Navigate back to the "Main"/single Activity that the NavigationDrawer was implemented in.
Note: If you do want to implement the NavigationDrawer in multiple Activities you would have to recreate a new instance of the NavigationDrawer in every Activity that you desire to display it.
I suppose this would be a disadvantage vs using Fragments whereas if you used a fragment you wouldn't need many instances of the drawer you would only need one.
Drawer With Fragments instead of Activities
If you use the NavigationDrawer with Fragments then the drawer should be implemented in a single Activity and when each drawer item is selected, their contents are displayed in each of their very own Fragments(which is called inside of the central Activity which manages all the Fragment instances)
I need some best practices ideas for my app. I think there is too much boilerplate code right now and I don't know if I'm using activities and fragments the right way.
There are 3 activities (A,B,C). The app starts at A. I can navigate to B which is a simple list and each of the items are clickable to show the item more detailed in activity C. A should be the "root" activity, so I set the parent activities in the manifest file.
Now I want to have a DrawerLayout navigation on B and C, which actually represents A in a smaller way.
I created an abstract NavigationActivity class for taking the view of the activity and set is as the first child of the DrawerLayout and add the navigation as second child. This works very well, but since the navigation has a state I embed the navigation as fragment, because I thought that the state is shared then, but it isn't and I don't know why I should use fragments at all.
Should I use one activity and load different fragments as main content? Then my app consists of 2 activities and maybe 50 fragments, when I finished it. I think that the way I try to implement it is not correct.
As an example: When you enter the PlayStore, there is the navigation on the left. You can browse the app and so on. Do you thing/know that it's the same activity with different main content or are there more activities?
Can you help me? Thanks :)
Single Activity applications are possible, but are not necessarily a best practice. IMHO, fragments have a very complicated lifecycle, so use Activituies when you don't HAVE to use fragments.
If your problem is to share the state of your drawer fragment through activities, you could pass it as an extra to each activity, or keep it in a static class/variable to retrieve it at every start.
Don't forget to also save this state during the destruction of one of your activity.
In my application I am making use of navigation drawer which is in the MainActivity and this navigation drawer has say 5 fragments. I am not maintaining any backstack of these fragments.
Now, the first fragment has one button which when clicked pushes a fragment (which I call an inner fragment). Here, I am maintaining a backstack because I want to get back to the first fragment from the inner fragment.
Now, I have a requirement in which I want to navigate from an activityA to the inner fragment.
Is this possible?
One way that I have thought of is to have the push code inside the first fragments create method (and make this conditional).
But I don't think its an appropriate way. Any suggestions would be helpful.
first, I'd like to state that I'm new to android development and to gradle as well. not to java.
I had a project supporting 2.3.6 and I'm now in the process of migrating it to 4.4 using the support library.
I'm using Gradle as well, and so far, it's working great.
I'm now using the navigation drawer to navigate between the app's fragments, which used to be activities.
One of the fragments in the drawer holds a listview and a detail view for an item in the list.
The drawer fragment switches it's view when the user clicks an item in the list and shows it's details.
While it's pretty clear to me why it's not recommended for 2 fragments to communicate directly, I still need the list fragment to tell it's details fragment counterpart about the selected item.
The guides specifically say that the activity should implement the callbacks and on the callback methods it should communicate the data between the fragments.
However, in my case, the parent is also a fragment.
My question is should the parent fragment maintain the callbacks?
It seems like the proper solution, since my fragment is only implemented this way to use the navigation drawer swap, and logically, it behaves like an activity, but this would go against the guides saying fragments should not communicate directly.
The question is if implementing the callbacks in the containing fragment is a viable approach or i should change this part of the app to an activity?
Thanks, and sorry for the wall of text.
Your parent fragment should be swapped in via the NavigationDrawerFragment whose callbacks should be implemented in the Activity. The callbacks shouldn't have anything to do with the data passing if I'm understanding you correctly. If the detail is a child of the parent fragment I don't see any reason that the data can't be passed when the child is created.