Application context for SharedPreferences?

Question

Can I use ApplicationContext for working with SharedPreferences and starting, for example, RemoteService?

Logically, I think that I can. Are there any nuances in such an approach?

Answer 1

as Gunnar Karlsson mentioned ContextWrapper's getApplicationContext() usage its pretty clear that you should only use Activity or Service Context to register/unregister your receiver, bind/unbind your services (unless it is really required to register with static data, not a particular component) to avoid uncertain memory leaks and to be safe even if you forget sometimes to unregister, the system will clear it for you with warnings.

But, for getSharedPreferences(...) you can always use any ApplicationContext or Context without a hitch. The reason is, it has been clearly mentioned

For any particular set of preferences(here SharedPreferences), there is a single instance of this class that all clients share.

Getting only a reference via application context will not keep the reference forever. It's just a reference to the preferences via application context like any other. So it will be cleared as soon as the user is done with it.

Please note, registering a receiver via application context will be maintained as global state associated with your application. So it will never be cleared for you.

Please someone correct me if I'm wrong.

Hope this will help you.

Answer 2

You should use the Activity or Service Context, i.e. 'this', unless you have a clear and strong reason not to. Only use ApplicationContext if you clearly need a reference to the global state of your application.

From Android Developers API docs on ContextWrapper's getApplicationContext() method:

This generally should only be used if you need a Context whose lifecycle is separate from the current context, that is tied to the lifetime of the process rather than the current component.

and

using the ApplicationContext (...) [as opposed to e.g. an Activity or Service context] can easily lead to serious leaks if you forget to unregister, unbind, etc.

For example, to retrieve SharedPreferences in an Activity to e.g. change data displayed to the user, use this.getSharedPreferences(...) since there is no clear reason why you would need to tap into the application's lifecycle. Same, in a Service, use this.getSharedPreferences(...). (Note that Activity and Service are Contexts. They indirectly extend android.content.Context)

CommonsWare has written an in-depth answer: When to call activity context OR application context? where he makes the case that calling getApplicationContext() "is almost always wrong" and outlines the few exceptions when to use it:

• bind to a Service from an Activity.
• something needs to be tied to a Context with global scope.

CommonsWare also links to an answer by Android Framework Engineer Dianne Hackborn:

The first rule I would give you: if you don't know why you need [Application Context], you probably don't need it (...)The only time you want to use getApplicationContext() is when you need a Context that exists outside of the lifecycle of an Activity class (or other component).

More answers on the same subject with discussions on the issues relating to ApplicationContext:

• Android: ProgressDialog.show() crashes with getApplicationContext
• Difference between Activity Context and Application Context