Question

I have been working with android for a little while now and feel pretty comfortable with the platform, but I have gotten a little confused with the Lifecycle of Context Objects. Looking at the hierarchy it is easy to see that Activity and Service both extend Context, and while this is convenient, it is concerning. I have avoided making helper classes that need a shared resource have a static field holding a context (since just about all resources come through some interaction with a Context object) so that way when an activity is destroyed, the GC is free to free it at any time, but I am wondering about resources fetched from a Context.

For example, if I have a static field that holds a File inside of a class. Then make this class’s constructor take the current context and assign the File a File resource fetched through the Context passed in, the do nothing else with the Context in my 2ndary class, am I still holding on in some way to the Context?

class testClass{
    private static File someFile;
    public testClass(Context context){
        synchronized(testClass.class){
            if(someFile!=null){
                //even though I am holding a File, or a SharedPreference Object generated from this context, am I correctly preventing this utility class from holding the Activity object in memory for no reason?
                someFile = context.openFileOutput("Some_File.txt", Context.MODE_PRIVATE);
            }
        }
    }
}

I did just read about Context.getApplicationContext() (Sadly not static). It says it returns a context relative to the process and not the activity so if I need to keep a context around, use that one. But the question above still remains.

Answer 1

I remembered I asked this question and thought I would answer it.

Though there may be more kinds of contexts, the primary ones developers use are the Activity Context, and the Application Context (and other things like Service Context). The Activity context is created and destroyed with the activity, so it is not a good idea to use as a constant reference stored between activity creation and destruction. The Application Context doesn’t have some of the things an Activity Context has, but everything you would want a static context reference for is there (file IO, preferences…). The application context is also created and destroyed with the application, so you can guarantee that as long as your application code is running, the context is valid.

Because of this, the Application context should be used for things like worker threads that may need a constant access point to a context but not need access to an activity. The best way I have learned to do this is to extend the android Application class. This class is created when the application is created in memory, and as soon as the Application onCreate method is called, the Application Context is valid. This means you can create a static function in your custom application class that gives access to the context.

public class CustomApplication extends Application {
private static Context context;

public void onCreate() {
    super.onCreate();
    context = getApplicationContext();
}

public Context getAppContext() {
    return context;
};
}

The only other thing you need to make this work is a modification to your manifest file so android knows to use your application class instead of the default.

<application
    android:icon="@drawable/icon"
    android:label="@string/app_name"
    android:name=".CustomApplication" >