Passing Activity Context to constructors to use internally - is this bad

Question

Is it bad practice to pass the Context to a constructor and save it as a private variable for internal use? The other option is to pass the Context as a parameter to methods that need it.

Which is a better option? I have a feeling that passing to the constructor might result in memory leaks accidentally.

Solution 1

Often, all you need is the ApplicationContext, so what you can do is pass this.getApplicationContext() instead of just this. Your app context exists for the lifetime of the app anyway, so it's not a memory leak.

Solution 2

It depends on the lifetime of your object. If you're sure the Object will only ever be used internally by your Activity you'd be OK passing the Context to the constructor, otherwise don't pass the Context in.

If an Object has a reference to the Context this will stop the Activity being Garbage Collected, and since an Activity has references to all its views this means you can easily leak a lot of memory very quickly.

It's easy to catch yourself out here since things like device rotations cause Activities to be re-created and it's easy to hang on to an Object without realising.

So it's probably best to be on the safe side and pass in the Context as and when you need it.

Solution 3

In the main application (which launches), declare a variable appContext: "public static Context appContext;" Then, in the onCreate() method for this main application, assign: "appContext = this;" Because appContext is public, any other class in this package can then use appContext to track down the XML resources. Is this any better (from memory standpoint)?

Even better might be to declare the Resources object as public static in the main application and then use it elsewhere, since resources is all you need.

Comments

[jax]

Actually normally all I want to do is use getResources() so this will do the job in my case right?

[JRL]

Sure, if that's all you need.

[Romain Guy]

This is true only if the Object that references your Context is held statically or at least by another Object that outlives the Activity.

[hackbod]

Please don't use getApplicationContext() unless you really know that is what you want. The main situation you will use it is for global objects that are independent of a particular activity. For objects that are associated with a specific activity, it is usually best to use that activity's context. (And for those, holding on to the context in a private variable is fine, as long as you don't have other global objects holding a reference to it and thus causing a leak.)

[JRL]

@hackbod: so to access resources for example, would you consider that an acceptable situation?

[hackbod]

If you only need the Resources object, you can just use that... there is a single global Resources instance for each .apk.