The Android official documentation (in the FAQ) provides a lot of info about how to pass complex data structures.
How do I pass data between Activities/Services within a single application?
http://developer.android.com/guide/faq/framework.html#3
Primitive Data Types
To share primitive data between Activities/Services in an application,
use Intent.putExtras(). For passing primitive data that needs to
persist use the Preferences storage mechanism. Non-Persistent Objects
For sharing complex non-persistent user-defined objects for short
duration, the following approaches are recommended:
Singleton class
You can take advantage of the fact that your application components
run in the same process through the use of a singleton. This is a
class that is designed to have only one instance. It has a static
method with a name such as getInstance() that returns the instance;
the first time this method is called, it creates the global instance.
Because all callers get the same instance, they can use this as a
point of interaction. For example activity A may retrieve the instance
and call setValue(3); later activity B may retrieve the instance and
call getValue() to retrieve the last set value.
A public static field/method
An alternate way to make data accessible across Activities/Services is
to use public static fields and/or methods. You can access these
static fields from any other class in your application. To share an
object, the activity which creates your object sets a static field to
point to this object and any other activity that wants to use this
object just accesses this static field.
A HashMap of WeakReferences to Objects
You can also use a HashMap of WeakReferences to Objects with Long
keys. When an activity wants to pass an object to another activity, it
simply puts the object in the map and sends the key (which is a unique
Long based on a counter or time stamp) to the recipient activity via
intent extras. The recipient activity retrieves the object using this
key.
Persistent Objects
Even while an application appears to continue running, the system may
choose to kill its process and restart it later. If you have data that
you need to persist from one activity invocation to the next, you need
to represent that data as state that gets saved by an activity when it
is informed that it might go away.
For sharing complex persistent user-defined objects, the following
approaches are recommended:
- Application Preferences
- Files
- contentProviders
- SQLite DB
If the shared data needs to be retained across points where the
application process can be killed, then place that data in persistent
storage like Application Preferences, SQLite DB, Files or
ContentProviders. Please refer to the Data Storage for further details
on how to use these components.
Why this is necessary:
Because of Android's unique ability to multitask and the idea of component life-cycles. In order to allow a user to leave an app (say with Activities A, B, and C, and intents i1, i2, i3) The system separates the application into components.
That way, if the user launches Activity B using intent i2, but gets a phone call or checks their email, they can go back to Activity B and the Android system can redeliver intent i2. And the user can easily and seamlessly pick up where they left off in your app.
With component life-cycles you make entry and exit to each individual component much easier. It also allows for asynchronous communication between different types of components such as BroadcastReceivers
, Services
and Activities
.
To do this, the OS does what's called "marshaling". It flattens data to primitive data types (such as int
and char
) so that it can easily be held in memory or written to temporary storage for later retrieval.
Additionally this is required for any type of IPC (inter-process communication).
Using an Intent
allows a developer to let the Android OS perform the marshaling -- which normally would be tedious (and possibly difficult or buggy).