Android上基于枚举的单例的生命周期

Question

A few days ago I've discovered that singleton can become anti-pattern in Android. My singleton (class with private constructor and instance stored in static field) was deleted (instance was deleted despite the fact other activities were still using this singleton (via getInstance() method) so another instance had to be created ) because Activity from which it was first invoked was deleted (after invoking finish for only this one activity).

I've read already how this problem can be resolved however I've also just read "Effective Java". There is said that "Single-element enum type is the bast way to implement a singleton".

So now I'm wondering what would be the lifecycle of singleton created this way in Android application? Would it be the same like in case of "standard singleton implementation" so after destroying activity from which it was invoked the first time it will be destroyed (even if it used also in other activities)?

I'm not asking about proper android singleton implemenation or the singleton pattern itself (is it pattern or anti-pattern etc) but I'd like to know what be the lifecycle of such enum singleton object and when it will be destroyed.

Answer 1

In all cases, the classes you use are tied to the ClassLoader that loaded them. This is true in Java in general, not just Android. Android will isolate activities by using new ClassLoader s each time -- at the least, it doesn't promise it won't, and it does as far as I can tell.

Any singleton, or other class-level state, is tied to the Class which is tied to the ClassLoader . This is why your state "disappears"; it's actually that your calling code is seeing a new Class in a new ClassLoader .

So, your enum-based trick, or anything else along these lines, would have exactly the same behavior. You just can't "persist" activity information this way. You can and should write to a SQLite DB. You could probably stash it in the SharedPreferences too.

Answer 2

The application object is a good location to store information which needs to be accessible to various activity or service instances. You can retrieve it like this (where this is an Activity or Service):

private MyApplication app;

in onCreate(...){ ... this.app = (MyApplication) this.getApplication(); ... }

Remember to set the name also in the manifest: Set the attribute "name" of the "application" tag: The value is the path to the class relative to the package of your app.

The application object is created when the app is started, you can initialize like in an activity or service in it's onCreate() method.

One thing to remember: The application object can survive closing your "last" activity. In this case you may get the same application object with the state from the previous interaction with your app. If this is a problem you must somehow detect the initial start of your app (eg using a special launcher activity without UI, which initializes the application object and then starts a new intent. BTW, the same may happen with singletons if they have not yet been lost to garbage collection.

Answer 3

My secure singleton implementation is like that:

I create a singleton class which has an attribute of boolean 'didReceiveMemoryWarning';

public class SingleTon(){
     public boolean didReceiveMemoryWarning = true;
     ...
     ...
}

In application first screen(It is exactly first launch screen)(I have a splash screen that is visible 3 sec)

SingleTon.getInstance().didReceiveMemoryWarning = false;

And in every Activity's onCreate() method, check this boolean data,

@Override
public void onCreate(Bundle savedInstanceState) {
     super.onCreate(savedInstanceState);

     if(SingleTon.getInstance().didReceiveMemoryWarning){
          { Load your data from local to your SingleTon class, 
             because your app was released by OS};
     }
}

it is my implementation.