Using getApplicationContext() vs. referencing to custom Application class in Android

Question

I've been researching ways to store global settings for my Android application and so far the best way seems to extend the Application class and store the shared data inside it, as described here. I've discovered that instead of using (CustomApplicationClass)getApplicationContext().getSomething() i can do the same thing by referencing directly to the static method inside the class like this: CustomApplicationClass.getSomething() and both ways work just fine.

Here's a piece from CustomApplicationClass:

public class CustomApplicationClass extends Application {

  private static boolean something;

  @Override
  public void onCreate() {
    [...]
  }

  public static boolean isSomething() {
    return something;
  }

  public static void setSomething(boolean something) {
    this.something = something;
  }

}

Now, if i want to retrieve value of "something" variable somewhere in my code, say, from my application Activity, is there a difference between:

boolean var1 = ((CustomApplicationClass)getApplicationContext()).isSomething();

and

boolean var1 = CustomApplicationClass.isSomething();

? When running the application, both work fine. Is the second way safe to use, or is it inadvisable?

score 1 · Accepted Answer · answered Feb 11 '12 at 22:42

I've been researching ways to store global settings for my Android application and so far the best way seems to extend the Application class and store the shared data inside it, as described here.

Except that you're not doing that.

I've discovered that instead of using (CustomApplicationClass)getApplicationContext().getSomething() i can do the same thing by referencing directly to the static method inside the class like this: CustomApplicationClass.getSomething() and both ways work just fine.

Of course. You could just as easily had CustomApplicationClass extend Object, then executed CustomApplicationClass.getSomething(). You are gaining nothing by your current approach versus just using an ordinary singleton pattern in Java, and you are losing flexibility, as an application can only have one custom subclass of Application.

Is the second way safe to use, or is it inadvisable?

The first way is pointless, since your data member and methods are static.

Either:

Make your stuff in CustomApplicationClass not be static, and then use getApplicationContext().
Refactor CustomApplicationClass to not extend Application, and then use the static data member and/or accessor methods, or switch more formally to the Java singleton pattern.

Personally, I would go with option #2.

score 0 · Answer 2 · answered Nov 14 '12 at 09:38

If you check the api of android.app.Application (http://developer.android.com/reference/android/app/Application.html) then you will find on Class Overview as following:

Base class for those who need to maintain global application state. You can provide your own implementation by specifying its name in your AndroidManifest.xml's tag, which will cause that class to be instantiated for you when the process for your application/package is created.

There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can be given a Context which internally uses Context.getApplicationContext() when first constructing the singleton.

Using getApplicationContext() vs. referencing to custom Application class in Android

2 Answers2