Passing data back and forth between activities on the Android platform is one of the more challenging aspects of understanding Android. Understanding how this data is managed by the OS is the difference between getting flooded with Error Reports and bad reviews and getting glowing praise and eternal gratitude. Well maybe not to that extent, but having a good background in passing data can make your code much easier to manage and cleaner to read (and for that you have my gratitude) So in passing the data there are essentially two types Persistent and strangely enough, Non-Persistent data types. The Persistent types are best handled by preferences, files, databases or content providers and they are pretty detailed in their operation. If you need to keep data over the length of more that one session consider using Persistent data stores. On the other hand, there are often times where transient data needs to be stored for one session and passed between activities. To handle that there are a couple of ways to handle it. This page details some of the methods, and it is repeated here for convenience;
How do I pass data between Activities/Services within a single application?
It depends on the type of data that you want to share:
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:
The android.app.Application class
The android.app.Application is a base class for those who need to maintain global application state. It can be accessed via getApplication() from any Activity or Service. It has a couple of life-cycle methods and will be instantiated by Android automatically if your register it in AndroidManifest.xml.
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.
A Singleton class
There are advantages to using a static Singleton, such as you can refer to them without casting getApplication() to an application-specific class, or going to the trouble of hanging an interface on all your Application subclasses so that your various modules can refer to that interface instead. But, the life cycle of a static is not well under your control; so to abide by the life-cycle model, the application class should initiate and tear down these static objects in the onCreate() and onTerminate() methods of the Application Class [my emphasis]
Being as I come from a java EE background the first decision was to use the singleton class and allow the instance to be available across the VM. The singleton design pattern is fairly well-known and is a good easy way to manage control across many activities. In some previous projects I have used them to manage HTTP connections, image caching and global application configuration to much success. However, this is the important part to consider when using singletons which is very important; Android OS can and will terminate your singleton and not even tell you about it. I highlighted that in bold because if your design depends on singleton patterns you naturally assume they are going to stay persistent through the VM. These are frustrating errors and difficult to track down and even more frustrating for your users. For instance consider this piece of code: In your main activity;
@Overridepublic void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);SuperSingletonManager.create(this);}
And your singleton;
private static SuperSingletonManager instance;private SuperSingletonManager(Context context){// do stuff once}protected static SuperSingletonManager create(Context context) {instance = new SuperSingletonManager(context);}protected static SuperSingletonManager getInstance() {if (instance == null)throw new NastyException(“Oh God Why?”);return instance;}
Seemingly you should be able to call SuperSingletonManager.getInstance() at any time and get access to the static instance. However, this isn’t the case. If the launching activity is removed by the OS (it happens, a lot) while you are on another activity, that static instance will be gone. So when you make that SuperSingletonManager getInstance() call you are only going to get a nasty exception. This also means that if any of your functions in SuperSingletonManager make use of the Context those will throw errors. Ack. But I really, really like singletons. So do I. And far be it from me to tell you how to architect your code. The only stipulation is that the singleton should abide by the lifecycle model. We can do this by launching the singletons from a service and binding that service to the launching activity. To the Android purists, and common-sensists out there you might just say “Why not just use a service instead of a singleton?”. Sure, makes sense but this post is about singletons and how to get them working and not common-sense. So here is the class that will do all that;
public class SingletonService extends Service {
private final ISingletonService.Stub mBinder = new ISingletonService.Stub() {
public void startSingletons() throws RemoteException {
initializeSingletons();
}
public void stopSingletons() throws RemoteException {
shutdownSingletons();
}
};
public IBinder onBind(Intent intent) {
return mBinder;
}
protected void initializeSingletons() {
SuperSingletonManager.initialize(getApplicationContext());
}
private void shutdownSingletons() {
SuperSingletonManager.shutdown();
}
}
When you start your main activity bind the service using bindService() , and make a call to the startSingletons() method. This will launch your singletons under the lifecycle of the service. This will ensure they are active for the life of your application session. Also, make sure to unbindService when you are finished. Nobody likes developers that don’t clean up after themselves. Good luck and if you actually use this method let me know! John
Posted via email from John Carpenter
http://www.2linessoftware.com/2010/08/03/singletons-and-services-and-shutdowns-oh-my/