Every now and then, somebody asks on StackOverflow or somewhere else about how to parcelize some nasty data structure, because they want to pass it from one activity to another.
Generally, this is a really bad idea. What confuses me is that it should be fairly obviously a bad idea, since the design principles have been pounded into developers’ heads for the past decade or so.
“Wait!”, you say. “Android hasn’t been around for ‘the past decade or so’!”. ‘Tis true. However, the design principles behind activity coupling are damn near identical to the design principles for coupling between Web pages of a Web app.
When you get right down to it, activities and Web pages are, architecturally, rather similar:
They appear on a stack, with one visible at a time, and use a BACK button for reverse navigation through the stack.
A page/activity can transfer control to another page/activity via a “link” (<a> element in HTML,
Intentin Android) that is passed to the hosting environment (browser, Android) that arranges to display the new page/activity.
No page/activity can directly interact with the other, assuming you’re playing by the rules.
When writing a Web app, each Web page has some amount of model data, perhaps a table of items, or perhaps a detail form for modifying an item. However, the Web page itself is not the model — the model is held and managed by a Web server. The table-of-items Web page does not persist the entire MySQL database into the URL used to link to the next Web page. Rather, the table-of-items Web page provides just enough identifying information to tell the next Web page what to do, such as the primary key of whatever item it should display in a detail form.
Activities should be designed the same way. Use
extras to pass the same sorts of things you would pass in
HTTP GET parameters, such as keys. However, the model data
should be in a centralized store:
- Database fronted by a
Serviceproviding an API for accessing a set of model objects persisted by one means or another
Applicationobject providing an API for accessing a set of model objects persisted by one means or another
- Static singleton object providing an API for accessing a set of model objects persisted by one means or another
Think of your activities as Web pages and think of your centralized store as being your Web server.
If you have two activities that are tightly coupled working
with in-flight data not ready to go into the model, perhaps
they should not be separate activities. For example, I would
not recommend implementing an editing wizard as a set of
activities — rather, use a
ViewFlipper to implement
a wizard GUI within a single activity, so your editing operation
is in that one activity.
There will always be exceptions to every rule — that’s
half the reason the rules exist in the first place. But seriously
reconsider passing around your data model via
extras — that’s not how you would do it on the Web, and it’s
probably not how you should do it in Android.