views:

497

answers:

2

Hi,

I frequently run into the problem that I have to preserve state between several invocations of an activity (i.e. going through several onCreate()/onDelete() cycles). Unfortunately, Android's support for doing that is really poor.

As an easy way to preserve state, I thought that since the class is only loaded once by the class loader, that it would be safe to store temporary data that's shared between several instances of an activity in a static Bundle field.

However, occasionally, when instance A creates the static bundle and stores data in it, then gets destroyed, and instance B tries to read from it, the static field is suddenly NULL.

Doesn't that mean that the class had been removed and reloaded by the classloader while the activity was going through a create/destroy cycle? How else could a static field suddenly become NULL when it was referencing an object before?

+4  A: 

You can use the Application object to store application persistent objects. This Android FAQ talks about this problem as well.

Something like this:

public class MyApplication extends Application{
    private String thing = null;

    public String getThing(){
        return thing;
    }

    public void setThing( String thing ){
        this.thing = thing;
    }
}

public class MyActivity extends Activity {
    private MyApplication app;

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

        app = ((MyApplication)getApplication());

        String thing = app.getThing();
    }
}
JohnnyLambada
that's a pretty good and simple idea actually... as long as it doesn't turn into the god object anti-pattern
Matthias
Hehe, I hadn't heard of the god object [1] pattern before. Pretty funny stuff. I probably should have said that this is just a simple example. For anything more than a trivial app, your Application class should simply have other objects that hold the real data, not be the repository of the data itself. It's a convenient place in Android to store other objects.[1] http://en.wikipedia.org/wiki/God_object
JohnnyLambada
A: 

The other, also evil, way to keep static data is to have you activity spin up a singleton class. This singleton would keep a static reference to itself.

class EvilSingleton{
    private static EvilSingleton instance;

    //put your data as non static variables here

    public static EvilSingleton getInstance()
    {
        if(instance == null)
            instance = new EvilSingleton();
        return instance;
    }
}

In the onCreate() method of your activity you can access/build the singleton and any data you might need. That way, your activity or application can get destroyed or recreated any number of times and as long as your process' memory space is preserved you should be ok.

This is an evil subversive hack, so no promises ;-)

haseman
thanks, but no thanks. I've had enough fun with singletons. It's the most abused design pattern of them all, and in most cases I've seen it being used, it was actually an anti-pattern.
Matthias
Fair enough. It's not much of a pattern, I've used them from time under heavy schedule pressure but I agree, in a large, well maintained project, they should be used sparingly at best.
haseman