Due UI pannello con Fragments vs attività separate

Question

Sto iniziando un'applicazione a nido d'ape che avrà un layout a due pannelli di base, un pannello sul per il menu a sinistra e uno a destra per la funzionalità principale di ogni sezione.

Contrariamente ai campioni disponibili delle API Frammenti il ??contenuto visualizzato sul pannello di destra è costituito da un'interfaccia utente completamente diverso per ciascuna delle opzioni del menu.

Si è tentati di sostituire solo il frammento di destra secondo la sezione selezionata, ma questo vorrebbe dire utilizzando un solo attività l'intera applicazione, e questo non fa un buon suono. Inoltre, ciclo di vita del frammento è legata all'attività, in modo che nessun frammenti saranno uccisi fino a quando l'attività viene ucciso, risulta in un sacco di frammenti "vivo".

Tuttavia, con un'attività differente con due pannelli per ogni mezzo opzione di menu che il frammento utilizzata per il menu dovrà essere aggiunto nell'attività OGNI e sarà soggetta ai layout incoerenti attraverso tutte le sezioni che dovrebbe avere un menu.

Quali sono le migliori pratiche qui?

Answer 1

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.