How many Activities vs Fragments?

Question

Intro:

The basic \"Fragments Tutorial\" pattern goes something like this:

1. On a tablet, have a list on the left, details on the right.
2. Both

Answer 1

I think you're on the right track. (And yes, the tutorials are over-simplified).

In a tablet layout, you could use a single Activity and swap in and out Fragments (in multiple 'panes'). While in a phone layout you can use a new Activity for each Fragment.

Like so:

It may seem like a lot of extra work, but by using multiple activities for phones, you enable basic Activity life-cycle and Intent passing. This also allows the framework to handle all the animations and the back-stack.

To help reduce the code you can use a BaseActivity and extend from that.

So if the user has a tablet you would use MyMultiPaneFragActivity or something similar. This activity is responsible for managing callbacks from the fragments and routing intents to the correct fragment (such as a search intent)

If the user has a phone, you can use a regular Activity with very little code and have it extend MyBaseSingleFragActivity or something similar. These activities could be very simple, 5-10 lines of code (maybe even less).

The tricky part is routing intents and whatnot. *(Edit: see more below).

I think the reason this is the recommended way is to save memory and reduce complexity and coupling. If you are swapping out Fragments, the FragmentManager maintains a reference to that Fragment for the back-stack. It also simplifies what should be 'running' for the the user. This setup also decouples the views and layout and logic in the Fragment from the Activity life-cycle. This way a Fragment can exist in a single activity, alongside another fragment (two-pane), or in a three-pane Activity, etc.

*One of the benefits of having regular intent routing is that you can launch an Activity explicitly from anywhere in the back-stack. One example might be in the case of search results. (MySearchResults.class).

Have a read here for more:

http://android-developers.blogspot.com/2011/09/preparing-for-handsets.html

It might be a little more up-front work, because each fragment must work well across separate activities, but it usually pays off. It means that you can use alternative layout files that define different fragment combinations, keep fragment code modular, simplify action bar management, and let the system handle all the back stack work.