Is it a bad practice to hold application Context instance?

Question

From my understanding, Application in Android is a singleton (correct me if I'm wrong) and we always have just one application Context instance.

So, from this perspective, is it a bad practice to save the application Context in my Application class? Can it lead to a massive memory leak?

Here is an example:

public class MyApp extends Application {
    private static Context appContext = null; // <-- here is the thing!

    @Override
    public void onCreate() {
        appContext = this;
    }

    public static Context getApplicationContextSingleton () {
        return MyApp.appContext;
    }
}

The reason to do this is globally accessed classes, like PreferencesManager, that mostly have static methods always need a context. So, instead of passing it everytime (or even storing it in an instance, which can be bad), I thought about storing the app context. What are the drawbacks I'm not seeing?

score 11 · Accepted Answer · answered Nov 30 '13 at 15:37

11

is it a bad practice to save the application Context in my Application class?

It is a code smell.

Can it lead to a massive memory leak?

Having the static data member will not lead to a massive memory leak. Whether your over-use of the Application object will lead to a massive memory leak depends upon where and how you use it.

What are the drawbacks I'm not seeing?

Not all Contexts are created equal. Generally speaking, only use Application when you know specifically why you need the Application context, not for everything.

Dave Smith of DoubleEncore has an awesome blog post covering the differences between types of Context and when to use one over another.

answered Nov 30 '13 at 15:37

CommonsWare

986,068
189
2,389
2,491

2

What do you mean by "Code Smell"? It's smells like bad practice? – Bolhoso Nov 30 '13 at 15:43
2

@Bolhoso: http://en.wikipedia.org/wiki/Code_smell "In computer programming, code smell is any symptom in the source code of a program that possibly indicates a deeper problem. Code smells are usually not bugs—they are not technically incorrect and don't currently prevent the program from functioning. Instead, they indicate weaknesses in design that may be slowing down development or increasing the risk of bugs or failures in the future." – CommonsWare Nov 30 '13 at 15:47
1

Always it's very bad and "pig" approach. Never do that. – Simon Dorociak Nov 30 '13 at 15:48
Awesome! @CommonsWare I liked the concept. Great article, I discovered that I know less than I thought about contexts. – Bolhoso Nov 30 '13 at 16:12
2

@Geralt I understand your point. Although the article states "Now it doesn’t matter where our Context came from, because the reference we are holding is safe. The application context is itself a singleton, so we aren’t leaking anything by creating another static reference to it.", in my case would be safer to create a Singleton PreferencesManager that I receive a context in the getInstance, there I could hold a refernce to the application context. Right? – Bolhoso Nov 30 '13 at 16:13
Suppose I need to pass Views as global static variables throughout my Activities and Fragments. Wouldn't using the Application Context for this be good? – IgorGanapolsky Apr 02 '14 at 20:07
2

@IgorGanapolsky: You absolutely do not have a "need to pass Views as global static variables". – CommonsWare Apr 03 '14 at 07:24
Just to be clear, because I am in the middle of a similar issue, even according to the article if u need to hold onto a context inside your class (singleton or otherwise), its "okay" if that context is an application context (because its a singleton context and u explicitly make sure it is one inside ur code), but a big no-no if u just blindly store the reference to the incoming context. – Kumar Rangarajan Jan 14 '18 at 11:12
1

@KumarRangarajan: Correct! – CommonsWare Jan 14 '18 at 12:02

Is it a bad practice to hold application Context instance?

1 Answers1

Linked