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 ClassLoaders 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.