问题
Take for example the app I'm currently working on: - it has an navigationDrawer with multiple items; there are two items which interest me for now, i'll call them X and Y.
both X and Y, when clicked on, display a fragment containing a list of x-elements or y-elements
selecting and x or y list element displays a new fragment in which I display info about the select item; the view fragments are different for x and y elements
in the view fragment I can choose to edit the specific element which brings up an edit fragment
The fragment approach is working, but it took me a while to manage the navigation between the fragments. Also, I will probably have to add some new items in the drawer similar with X and Y. My main activity, in which I have the drawer and I do the fragment switching, is quite dense already, which brings me to my question: should I switch from fragments to activities? I was thinking about starting a new activity when a drawer item is selected and handle the list/view/edit fragments related to the selected item in that activity, rather than handling all fragments for all items in a single activity.
Is it a good idea? Is it bad design?
回答1:
I was in similar boat and I used Activities method, that way I have each Activity with group of fragments for a particular nav click on the NavigationView. Obviously I use NavigationView, but managing all those fragments with just one MainActivity is really a painful task.
I rather prefer EachActivity managing their own fragments when we click a nav item. This gives me a better performance, since I do not need to worry about lifecycle of soo many fragments and it's backStack and add/remove/show/hide hell.
I used the following SO Question to cleverly use a BaseActivity implementing NavigationDrawer, and sharing it with all the other Activities. The real magic is it does not duplicate code, or it's not just plain old Inheritance technique.
Here's the link, do check it out
I used this method in two of my project's and it's running very well plus I do not have to deal with fragment management right from the very start.
回答2:
I have the following points to submit:
The fragment approach is much better. You should use fragments for better UI experience for the user.
Think like this, imagine your screen as a basket of information and if you have another basket(i,e another screen) with which a lot of data will have to be transferred to and fro, then, according to me, it is much better to use fragments for the two baskets along with a container activity. And of course there can be more than two baskets/screens.
There is no hard and fast rule that you should use only use fragments or activities, but google says that it is much better to use fragments where ever it is possible.
Generally, developers use fragments to group associated logic together and it is much better to do it this way as it will provide a logical grouping of whatever you are trying to do.
It is also easy to pass java data objects among fragments via the container activity and with the help of Interfaces. This is also considered a very modular approach.
Rest depends on how you would like to define the flow of your application. I think using fragments is a much better approach in your scenario. Use container activities wherever you think that the associated logic has changed drastically.
回答3:
First off, managing navigation between fragments is not difficult. You can check google's tutorial. I can suggest you some edits if you post your code
I think it is bad design for two reasons
- Lot of code rework
- If you want to change your navigation pattern to say tabs, it can't be done easily.
来源：https://stackoverflow.com/questions/32435389/navigationdrawer-with-activities-vs-navigationdrawer-with-fragments