Can Application Context be changed during application lifecycle?

Question

Can I rely on statement the Application's Context is not changing during application's lifecycle? What if I store a context somewhere using singleton pattern and then use wherever I need?

Answer 1

To answer your second question first: If you need to store some state in a singleton, then you can use the Android Application class and your Application becomes your singleton (it is also a Context). There would be no need to store it.

To the first question, as to whether the Context can be changed at runtime: sort of related to your other question, I think we can figure that out by looking at ContextWrapper.attachBaseContext:

 protected void attachBaseContext(Context base) {
     if (mBase != null) {
         throw new IllegalStateException("Base context already set");
     }
     mBase = base;
 }

So, yes, you can rely on it; it can't be changed, and if you try, it will throw an IllegalStateException.

Answer 2

Android Application class IS your singleton for storing information that should be tracked through applications lifecycle phases. You can checkout this class' description in the manual - http://developer.android.com/reference/android/app/Application.html

Answer 3

Yes you can rely on that the context is not changed during application life cycle!

Google say so in the Application class overview.

I think it will be perfect for your case.

Answer 4

Application is a singleton and I don't know of a way to bypass that without changing core.

However there is a possibility to encounter 2 instances of an Application object if your code starts another process. One example would be starting a remote service; this will create another process which will create it's own instance of the application object.

http://developer.android.com/reference/android/app/Service.html#RemoteMessengerServiceSample

To avoid confusion you must communicate between the remote service and the rest of the app using one of the Parcelable or Serializable android options:

Message - Handler Intent Bundle Intent putExtra

or create one of your own

Answer 5

There's some controversy around this topic. Even some among people from Google. I keep which I believe is the right approach which basically tries to get the activity context as many times as possible. Reason being, the point of the context is providing some resources / parts of your app the environment from which is working. The more accurate is the information you give to the system, the less unexpected behavior would occur (ie.: You just have access to some resources within the Activity context scope and the way round from the app context.

Remember that the activity is a Context, so that passing "this" will make the job if you are inside of an activity, or "getActivity()" if your code works from within a fragment.

Moreover, I have to agree with devmiles.com. It's pretty useful to use your own Application class as a Singleton, since you can easily manage the lifecycle of the app and use it as a proper middle point. Once again, to get the appContext it is enough to call getApplicationContext or even the instance of your Application singleton class.

Answer 6

In application class is a singletion application level class for android application. My answer is no you can not change application context object.

Answer 7

While the top answer here is technically correct, it goes against google's current recommendations, quoted below from the page:

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

"Note: There is normally no need to subclass Application. In most situations, 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), include Context.getApplicationContext() as a Context argument when invoking your singleton's getInstance() method."

In a nutshell, it is dangerous to store contexts whose lifetime does not match that of the class that you store it in. The application context should match that of your singleton since they share the same process lifetime.