I am starting a Honeycomb application that will have a basic two panel layout, one panel on the left for the menu and one on the right for the main functionality of each section.
Contrary to the available samples of the Fragments API the content displayed on the right panel consists of a completely different UI for each of the menu options.
It is tempting to just replace the right fragment according to the selected section, but this would mean using just one activity in the entire app, and this does not sound good. Moreover, the fragment's lifecycle is tied to the activity, so no fragments will be killed until the activity gets killed, resulting in a lot of fragments "alive".
However, having a different activity with two panels for every menu option means that the fragment used for the menu will have to be added in EVERY activity and will be subject to inconsistent layouts across all the sections that should have a menu.
What are the best practices here?
This blog post summarizes the reasons for choosing fragments over activities:
Embedded Activities via ActivityGroup
were a nice idea, but have always been
difficult to deal with since Activity
is designed to be an independent
self-contained component instead of
closely interacting with other
activities. The Fragment API is a much
better solution for this, and should
be considered as a replacement for
embedded activities.
Retaining data across Activity
instances could be accomplished
through
Activity.onRetainNonConfigurationInstance(),
but this is fairly klunky and
non-obvious. Fragment replaces that
mechanism by allowing you to retain an
entire Fragment instance just by
setting a flag.
A specialization of Fragment called
DialogFragment makes it easy to show a
Dialog that is managed as part of the
Activity lifecycle. This replaces
Activity’s “managed dialog” APIs.
Another specialization of Fragment
called ListFragment makes it easy to
show a list of data. This is similar
to the existing ListActivity (with a
few more features), but should reduce
the common question about how to show
a> list with some other data.
The information about all fragments
currently attached to an activity is
saved for you by the framework in the
activity’s saved instance state and
restored for you when it restarts.
This can greatly reduce the amount of
state save and restore code you need
to write yourself.
The framework has built-in support for
managing a back-stack of Fragment
objects, making it easy to provide
intra-activity Back button behavior
that integrates the existing activity
back stack. This state is also saved
and restored for you automatically.
Fragments are fairly new, so beyond that article, I'm not sure your going to find much for best practices. I think the decision you need to make is are my interactions tightly coupled and meant to share data or are they stand alone components which don't have much interaction.
edit, clarification: I think that using a single activity for an app isn't necessarily a bad decision. It's really a decision you should make based on the functionality of your app. Based on the article, an Activity is stand alone while a fragment is, typically, only relevant when combined with other fragments in the scope of an Activity. The situation you describe, with combinations of different activities is one of the pain points they designed Fragments to solve.
