What is Context Class
We find Context almost everywhere in Android Development and it is the most important thing in the Android Development, so we have to understand how to use it correctly. You can do almost nothing without context; without it your app is just plain Java code.  I come across a guy on the internet – Gaurav – who calls it “God Object”

Context class is an abstract class and it’s the current state of the app or an activity at a given time. Being an abstract class, Context class cannot be instantiated.

Context lets newly-created objects understand what has been going on and provides info about the Activity or Application to the newly created components.

Context provides the answer to the android components’ question of “where the hell am I?” and “how do I access, interact and communicate with the rest of the app?”.

When do we need Context
Let us break down things that involve context.

First it provides Activities, Fragments and Services access to classes and resources (e.g. images, themes, styles, external directory locations/ file paths, databases etc.).

Context gives access to the System Services enabling interaction with various managers e.g. AlarmManager, AudioManager, BatteryManager and LocationManager.

It also enables access to app-level operations such as finding content providers, launching activities, broadcasting and receiving intents. A few examples are provided below.

a) Loading resources – getResources(), getAssets()

b) Obtaining system services – Context.getSystemService()

c) Getting internal file paths

d) Launching an activity explicitly e.g.

e) Creating dynamic views.

f) Inflating an XML Layout file

g) Sending a local broadcast

Context Types
Generally, there are two types of Contexts:

Application Context – typically you call it to get information regarding another part of your program e.g. an activity or a package.

You can call getApplicationContext() to get the app’s context in the current process.

Application Context is tied to the lifecycle of the application. The application context will remain the same throughout the app’s lifecycle. You should only use it if you need a context whose lifecycle is separate from the current context or when you are passing a context beyond the scope of an activity.

Application context is not suited to handle UI tasks. You should only use this if you need a context whose lifecycle is separate from the current context.

Activity/Service context (BaseContext) – This context is available in an activity.

Activity Context is the only context equipped to handle all tasks associated with the UI.
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’s context.

In general, use the activity context unless you have a good reason not to.

Don’t Mess with the Context
Use the relevant context because using the wrong context can result in memory leaks and styling problems.

Styling Problems
Views access the resources available to them from the context supplied to their constructors. Different contexts supply different details about the app’s environment.
If we specify in the manifest that the app should use the AppTheme and the activity to use the ActivityTheme; views constructed using the Activity context will look different from views constructed by the application context. This is because the application context uses the AppTheme while the activity context uses the ActivityTheme, hence the difference.
Memory leaks
Android apps are usually limited to 16 MB of heap. An app should use little memory as possible to let other applications run without getting them killed. The more apps Android can keep in memory, the faster it will be for the user to switch between apps because of caching.

Activity context may cause memory leak e.g. if you use your activity as the context for something which is not tied to the life cycle of your activity, when the activity is destroyed, the garbage collector cannot discard the Activity’s object (from the Virtual Memory) because there is still a strong reference being held.

The Rule of Thumb
In most cases, use the Context directly available to you from the enclosing component you’re working within. You can safely hold a reference to it as long as that reference does not extend beyond the lifecycle of that component.

As soon as you need to save a reference to a context from an object that lives beyond your Activity or Service, even temporarily, switch that reference you save over to the application context.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.