Pattern "One activity, multiple views": Advantages and disadvantages

This pattern is similar to the pattern Main Servlet (the Front Controller) that is used for developing web applications.

The main idea of this pattern: we have one Activity that manages multiple views and this activity is responsible for representing current content. Not all views need functional of activity (e.g. life-cycle methods) so the main question is: if I can go without activity why do I have to use it?

I have found the following disadvantages of using this pattern:

1. Official source doesn't recommend to Overload a Single Activity Screen but they don't explain why.

2. We cannot use TabActivity, ListActivity, MapActivity. But there are some tricks to go without them.

3. If different screens have different menu it's a problem to make that without activities.
4. It is necessary to keep history by ourselves. But it's not so difficult to develop.

I have found the following advantages of using this pattern:

1. It's faster to change the content of current activity than to start another activity
2. We are free to manage history as we want
3. If we have only one activity-context it's simpler to find and solve problems with memory leaks

What do you think about this pattern ? Could you provide any other advantages/disadvantages ?

Solution 1:

We cannot use TabActivity, ListAcivity, MapActivity. But there are some tricks to go without them.

You have to use MapActivity if you want to use MapView. You have to use PreferenceActivity if you want to use preference XML.

It is necessary to keep history by ourselves. But it's not so difficult to develop.

The difficulty in managing your own history will depend greatly on what the history needs to be. Implementing history for a simple wizard will be fairly easy. However, that is a particularly simple scenario. There is a fair amount of history management code in Android that you would have to rewrite for arbitrary other cases.

You also forgot:

#5. You will be prone to leak memory, because you will forget to clean up stuff, and Android will not clean up stuff (since it assumes that you will be using many small activities, the way they recommend).

#6. Your state management for configuration changes (rotation, dock, SIM change, locale change, multiple displays, font scale) will be more complicated because now you also have to figure out what extra stuff (e.g., history) need to be part of the state, and you have deal with all of them at once rather than activity-at-a-time.

#7. Having multiple entry points for your application becomes more challenging (e.g., multiple icons in launcher, app widget linking to some activity other than the main one, responding to etc.).

It's faster to change the content of current activity than to start another activity

For most modern Android devices, the speed difference will not be significant to most users, IMHO.

If we have only one activity-context it's simpler to find and solve problems with memory leaks

Except that you still have more than "one activity-context". Remember: your activity, large or small, is still destroyed and recreated on configuration changes.

What do you think about this pattern ?

Coase's "nature of the firm" theory says that businesses expand until the transaction costs for doing things internally become higher than the transaction costs for having other firms do the same things.

Murphy's "nature of the activity" theory says that the activity expands until the transaction costs of doing things internally become higher than the transaction costs for having other activities do the same things. Android developers will tend towards a "user transaction" model for activities -- things that are tightly coupled (e.g., steps in a wizard) will tend to be handled in single activity, and things that have little relationship (e.g., browse vs. search vs. settings vs. help vs. about) will tend to be handled in distinct activities.

Solution 2:

This will be horrible to maintain if new functionality is added later on. I'm also not convinced it will be so much faster that the user could notice. Having components as smaller pieces that are easier to change or swap out is definitely the way to go.