Android context icon
The Context class gives you access to the global information about an application’s environment. It lets you:
The context also gives you access to the System Services. This enables you to interact with the various managers, some examples being the:
You’re probably familiar with two of the Context class’s subclasses:
Both the Activity and Service classes are subclasses of the Context class. So you can use instances of them wherever you need a context.
The Context class also gives you access to a number of useful methods. Here are some of the more popular ones:
A good example showing the role of a context can be seen when we use the View class.
The View class relies on the context to get information about the app’s environment which is necessary to be able to construct the View object. Consequently all of its constructors accept a context parameter.
The View needs to know which theme, strings, dimensions, etc. to use. It’s the context that enables it to access this information.
Passing the context to the view when it is being constructed, gives you the flexibility to use a different context to construct the view, as the one used by the activity, for example. This gives the view access to resources other than those used by the activity. We’ll show you an example later.
If you need to know which context the view is running in, call getContext(), from the view.
This means that they have access to different information about the application environment.
So which context should you use?
You can call getApplicationContext() to get the application’s context in the current process.
You can also use getApplication() which will return the application that owns the activity. Since the Application class extends the Context class, it can be used as the application context.
The application context will remain the same throughout the app’s life cycle.
You could for example use the application context:
Note that some "experts" warn against using it unless you know why you should use it and then only to use it when you absolutely have to.
Others maintain that you should use it as the default context for everything, except for the odd occasion, like when displaying a progress dialog.
Unfortunately the documentation can be confusing in this regard so in the end you’ll have to decide for yourself.
The activity context is attached to the Activity’s life cycle and is destroyed along with the activity.
Since the Activity class extends the Context class, an activity is a Context. You can therefore use the activity’s class name or this for an activity context.
You can also use getBaseContext() to return an activity context.
Note that some "experts" warn against using getBaseContext() and suggest that you rather use the context that you have.
You can use the getActivity() method to get the activity associated with the fragment. As the Activity class is a subclass of the Context class, the returned activity is therefore a context.
Check out our tutorial on fragments, Dynamic layouts using fragments if you’re interested in learning about fragments
Consider the following when making your choice as to which context to use:
A word of caution: Don’t pass an object around that is tied to an activity. It will leak the views and resources associated with the activity. (The activity maintains a hold on them so they can’t be garbage collected which means that valuable memory is wasted).
Memory leaks happen when you keep a reference to a context which prevents the Garbage Collector from collecting it (and releasing valuable memory).
Most memory leaks are caused by keeping a long-lived reference to a context.
The context is mainly used to load and access the app’s resources. This is why all views require a context as a parameter in their constructors.
Usually it’s the activity context that is used to construct the views. The result is that the views have a reference to the entire activity, including its View hierarchy and all its resources. So if you leak the context, you leak a lot of memory.
Read more in the original blog post covering memory leaks.
Here’s a summary of the suggested methods to avoid context related memory leaks:
Use TheActivityClassName.this in the inner class to access the outer TheActivityClassName class’s context.
Here’s an example:
Android context inner class onclick
The above code is used within the AppMenuActivity activity’s onCreate() method so we use the activity as the context in the onClick() method
A quick explanation
Calling new View.OnClickListener() creates an anonymous inner class. We need to pass the outer class’s context to the intent that we’re creating in the inner class. As Activities are a subclass of the Context class, they are therefore a Context. We can then use the activity as the context within the onClick() method.
Android context activity application theme
We have two themes. One is used for the application and the other for the activity
Android context activity application view
A quick explanation
We create two TextView objects in an activity’s onCreate() method:
We then add the views to our layout. Here’s a screenshot of what it looks like when the app runs:
Android context activity application view screenshot
The red text is displayed because the text view is constructed using the activity’s context. The grey text is displayed in the TextView that was constructed using the application’s context
A quick explanation
Each of the text views accesses the resources available to them from the context supplied to their constructors. These different contexts supply different information about the application’s environment.
We specify in the manifest that the app should use the AppTheme while the activity should use the ActivityTheme.
The two text views are constructed using different contexts so they use different themes:
I hope that you have found this tutorial helpful.