The Nature of the Activity

Every now and then, the sort of question posed here comes up. In short, why do we bother with multiple activities? Why not just pour all our UI into one super-activity? That saves us from all this nonsense of passing data between activities and such.

In my answer to that question, I raised an analogy that could probably use a bit more explaining, particularly for those of you who are not familiar with the work of Ronald Coase.

One of Coase’s contributions to the world of economics is “the nature of the firm”. In this theory, the size of the firm will expand until such time as the incremental cost of doing things internally meets or exceeds the incremental cost of hiring others to do those same things. “The nature of firm” helps explain why conglomerates like ITT and sprawling firms like General Motors arose in the 1950’s and 1960’s. It also helps illustrate why the Internet and other aspects of the communications revolution have allowed smaller and more nimble businesses to achieve results that massive vertical and horizontal integration can no longer achieve.

I believe there is a similar theory surrounding where to break things into activities. I tend to think of it as the “user transaction”.

In databases, you have a database transaction when you have a series of changes that need to succeed or fail as a whole — having the changes partially succeed may cause problems. A “user transaction”, from a UI/UX perspective, is a series of operations that a user would think of as being part of some larger whole.

For example, a wizard represents a user transaction. The user is trying to provide a set of information to you, and you chose to collect it piecemeal instead of on one large form.

In my “nature of the activity” theory, user transactions are where you divide your activities. Or, more accurately for our new honey-flavored world, each user transaction represents a fragment, which are probably in separate activities on small-screen devices (e.g., phones) but might be consolidated onto fewer activities on large-screen devices (e.g., tablets).

So, for example:

• A wizard should be a single fragment, not a series of linked fragments, so you can more readily maintain context as the user moves back and forth through the different bits of information you are trying to collect.

• A list-of-things is a separate fragment from the-presently-selected-thing. On small-screen devices, these are represented in separate activities; on large-screen devices, these might be combined into one (e.g., list of messages on the left, message details on the right).

• Ancillary things that applications need, like “help” and “settings” and “about”, are separate fragments and, typically, separate activities.

Occasionally, technical requirements may force your hand. Maps, for example, might need to be separated from other aspects of your application due to the peculiar requirements of the Google Maps add-on (e.g., must inherit from MapActivity).

So, while this isn’t a universal solution, and while there is nothing in Android that forces this model, I find it useful when designing UIs to think of the user transactions and use those to help determine the boundaries between activities (and, now, fragments).