7

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?

Programmer Bruce
  • 64,977
  • 7
  • 99
  • 97
mgv
  • 8,384
  • 3
  • 43
  • 47

1 Answers1

6

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.

Nick Campion
  • 10,479
  • 3
  • 44
  • 58