Is a "Globals" class holding static variables in Android safe?

Question

Can anyone enlighten me about the safety of a class holding global values in Android?

Here's a short example of what I mean:

public class Globals {
    public static int someVariable = 0;
    public static User currentUser = null;
    public static Handler onLogin = null;
}

Then somewhere in an Activity I do the following:

Globals.someVariable = 42;
Globals.currentUser = new User("John", "Doe");

I have to rely on Globals.currentUser at multiple places in my app as soon as the user is logged in, but I'm unsure if I should do it, and also if I could use a Handler like this.

I read everywhere that an Android app could be killed anytime, does this mean it is killed completely or maybe just a part of it, thus killing my Globals class only?

Or is there any other way to store globally available data in a safe way, without writing every member change to the database (in fact, my User class is a little more complex than in this example. ;-)

Thanks for your effort!

---

Edit: Ok, here's what I finally did:

public class MyApp extends Application {

    private static MyApp _instance;

    public MyApp() {
        super();
        _instance = this;
    }

    public static MyApp getContext() {
        return _instance;
    }
    ....
    private User _user = null;
    public User getUser() {
        if (_user == null) _user = new User();
        return _user;
    }
}

Then modify the AndroidManifest.xml and add android:name=".MyApp" to your application node to tell the app to use your subclass.

So far everything works fine and I can easily access the current Context (f.ex. in SQLiteOpenHelper) by calling MyApp.getContext().

Answer 1

It would be better to use the Android Application class. It's meant to store global application state

http://developer.android.com/reference/android/app/Application.html

Just create a subclass and make sure to update your manifest file to use your version. Then you can store whatever you need to in it. Activities have a method getApplication() which you can cast to your class to access your implementation

Answer 2

The pattern is discouraged--you will run into problems when unit testing.

Can you explain how you unit-test a class that must supply different custom "Users" here? You are either forcing a mock/fake class into "User" which will probably have a cross-effect on other tests or you are putting an if(test) into your code which gets ugly quick.

Over time populating this class artificially for testing gets more complex and starts to have relationships and dependencies.

More simply it makes it difficult to unit test a class in isolation.

It's one of those patterns that a given programmer either doesn't see a problem with or never uses because he's been burnt--you'll see little middle ground.