Fragment design: Adapting to multiple screen layouts by showing/hiding fragments within a single Activity?

Question

I am trying to understand how to use Fragments to create apps that adapt well to multiple screens and layouts. I have studied a few examples:

1. The Fragments doc

Answer 1

In this article http://developer.android.com/guide/practices/tablets-and-handsets.html#Fragments Google says:

"The approach you choose depends on your design and personal preferences."

and

"Other times, however, dynamically swapping fragments for your handset design can make your code more complicated, because you must manage all the fragment combinations in the activity's code (rather than use alternative layout resources to define fragment combinations) and manage the back stack of fragments yourself (rather than allow the normal activity stack to handle back-navigation)."

Answer 2

This answer by @Taylor Clark was pretty informative. However, it wasn't an actual sharing of experience with using the single-activity approach as I asked in my original question. I set out to modify the News Reader example from the Android developer guide to use the single-activity approach and came up with a workable solution.

What remains to be seen is what are the use cases where this approach is preferable over the multiple-activity method (or whether there are any such cases at all). Also, I haven't looked in detail about the 3-pane scenario described in Edit 1 of my question.

I hope to post my entire project shortly, but here is a quick overview of how I went about it:

• Single Activity: NewsActivity
• Two Fragments: TitlesListFragment and DetailsFragment
• Both fragments are always present in NewsActivity. Depending on the current dual-pane-ness, I show/hide the appropriate fragment.

Some problems I came across:

Designating a Layout as Dual-pane or not:

In the original News Reader example, dual-pane layouts have a FrameLayout for holding the news Details. We figure out whether we are currently in a dual-pane layout by testing for the existence of this Frame Layout.

However, in my solution, both fragments are always present in all layouts. I hacked this by including a View with id dualPane and android:visibility="gone" in those layouts that I want to be dual-pane and omitting this view in the single-pane layout. Then, it was a matter of

mDualPane = findViewById(R.id.dualPane)!=null;

EDIT:

There are better ways to designate dual pane-ness than having a dummy view. The one I prefer is to create a boolean resource. For example, I have a config.xml as follows:

<resources>
    <bool name="dual_pane">false</bool>
</resources>

I can then place additional config.xml files in folders like values-xlarge-land, values-port or values-sw600dp etc and adjust the boolean value to true or false as I desire.

Then, in the code it is a matter of getResources().getBoolean(R.bool.dual_pane);

Closing the Details Fragment

This was a problem of differentiating between the Activity close and the Fragment close. In the end, I had to override onBackPressed() as follows:

• In dual-pane mode, just call super.onBackPressed();
• In single-pane mode, if we are in TitlesListFragment, call super.onBackPressed();
• In single-pane mode, if we are in DetailsFragment, then treat it as closing the fragment. This means hiding it and showing the TitlesListFragment.

This is not ideal, but it is the best I could come up with.

EDIT:

Based on the suggestion by @SherifelKhatib in the comments, there is a much cleaner way to handle back-button presses: Simply add to the Fragment backstack, the transaction of showing/hiding the details fragment. That way, when you press the back button, the fragment transaction is reversed. You can also pop the backstack manually if you wish to do so on other button clicks.

Answer 3

Generally applications are split into Activities because each represents a specific "thing" that a user can do. For example, in an email application a defined set of actions could be:

1. Viewing a list of messages
2. Viewing a message's detail
3. Composing a reply to an email.

Each action could be its own Activity that shows a single (or set) of Fragments. However, if you had the screen real-estate it would make sense to combine the viewing of a message list AND the message detail into a single Activity that can show/hide the "detail view" Fragment. Essentially, Fragments allow you to show the user multiple 'activities' at one time.

Things to consider when making your decision:

1. Fragments specified in xml cannot be supplied arguments
2. If your decision is based on screen orientation you can always use resource qualifiers to point to another layout with more/less Fragments (ex. layout-land-large)
3. Fragments cannot be maintained Activities
4. Are the Fragments working together to provide the user a streamlined experience?
5. Is there a time where one of your Fragments will be gone for good? If so, maybe it's time for a new Activity
6. Go with your gut. If its "natural" for you application to swap-out fragments, go for it. Just remember that if you find yourself doing it a lot, maybe a separate Activity is a more appropriate solution

I've usually employed the "multiple Fragment approach" for tablet versions of applications and a "one Fragment per Activity" for phones, which sounds in-line with your first approach listed. Not that the second doesn't have a time and place, but I could see the implementation getting messy quick!

Sorry for the wordy reply! Perhaps you could tell more about your specific use case? Hope this helps!

Response to Question Edit One

---

Here's how I imagine your application project could be setup:

Source files:

yourapp.package.phone: NewsActivity1, NewsActivity2, NewsActivity3

yourapp.package.tablet: NewsMultipaneActivity

Resources

layout/

activity_news.xml- phone version, only includes Fragment1
activity_news_detail.xml- phone version, only includes Fragment2
activity_news_<something>.xml- phone version, only includes Fragment3

layout-large/

activity_news.xml- 7" tablet version, includes Fragment2 and an empty fragment container. Split vertically

layout-large-land/

activity_news.xml- same as layout-large, but with the split being horizontally

layout-xlarge-land/

activity_news.xml- 10"+ tablet version, contains all three fragments split horizontally

So what happens here?

• If your app is running on a phone, start NewsActivity1
• If you app is runnin on a tablet, start NewsMultipaneActivity

Android will swap layouts for you, based on screen size and orientation as long as the file names are the same. Because Fragment2 will always be displayed, you can 'hard code' it into your tablet layouts. Then you can use FragmentTransactions to switch between Fragment1 and Fragment3 in the container as necessary

Be sure to check out http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources to see how you can take advantage of resource qualifiers to mitigate some of the headaches of different screens and orientations

Answer 4

Thank you for this question and your insights. I used multiple-activity approach until I stepped into a problem. My app is like the doc-example news reader. Consider this scenario:

1. (initial state) I'm using a tablet in landscape mode (two-pane), activity A is displaying article list on the left and some article on the right.
2. I rotate the device, now activity A is in single-pane mode and displays a list of articles.
3. I click on a list item, activity B starts with aritcle opened.
4. Now I rotate the device back to landscape mode.

What's happening? Activity B is displaying an article full-sized, while of course I want to go back to two panes. I'm not sure how to solve this nicely. Of course activity B may check for multi-pane mode and finish itself, and activity A may check what was the last article displayed... That looks ugly. Thoughts?

PS I have a suspicion that GMail app uses single-activity approach. I don't see any activity transition when I select an e-mail from the list. It also behaves properly in the scenario I described.