Context in Android
Context in Android allows us to access application specific classes and resources. It’s an abstract class and its implementation provided by Android Framework’s itself. It’s actually a bridge between our app and the Android System.
Now, let’s discuss what is happening in this hubbub.
We already said that Context itself is an abstract class and as you can see it is on the top of the hierarchy. So, we can comprehend that there must be implementations of it which serves different purposes in the whole application.
Who implements it then ?
Behind the scenes,Context’s implementation (ContextImpl in the diagram) is being provided by AMS (Activity Manager Service) which is a system process to manage running status of Activity and other components. AMS considers app permissions and other different context that our app needs and finally gives us a context implementation. So, we can think that as a translation. Since it is given by Android System, plain Java/Kotlin classes don’t have access to Context.
Context Wrapper inherits from Contextbut does not implement it. Instead, it gets implementation from ContextImpland wraps all of its functions. ContextWrapper has an attach based context function and thanks to this, we make sure that the context attached only once to whole application.
At the third level of hierarchy we can see Application and Service which directly inherits from ContextWrapper this is because they don’t need a Theme and should not contain a theme since their purposes are not building a UI.
But Activity, as you can guess, really needs a theme because its an Android Fundamental Component whose purpose is building and managing UIs for our apps (at least at the early stages of Android). So it inherits from ContextThemeWrapper which contains information about theme files of our app that are declared in our AndroidManifest.xml file.
Note that, in theory, these contexts seperate from each other whether they are containing a theme or not but in practice there is one more and VERY IMPORTANT difference: their scopes. Some of them lives as long as our app lives and some of them does not.
With that in mind let’s see with which context what we are able to:
Application Context: It is our global context which means its instance is created only once and is used across whole application. In our code we can get application context with two ways and there is no difference between them:
context.getApplicationContext()
//or
activity.getApplication()With application context we are able to;
- Accessing application resources like strings, colors etc.
- Starting a service
- Binding to a service
- Sending a broadcast
- Registering a broadcast
Activity Context: This context declared seperately for each activity and has a theme since it inherits from ContextThemeWrapper as we mentioned earlier. Each activty context has its own lifecycle and because of that, it must stay in its borders. At this point, i want to share a specific example for this which is seen so much:
Get Sevban Bayır’s stories in your inbox
Join Medium for free to get updates from this writer.
Passing Activity Context to a Component that outlives the Activity
If you pass the activity context to a component that outlives the Activity (Viewmodel for instance) that directly causes memory leaks. Why ? In JVM the gadget responsible for freeing allocated memory of unused objects is Garbage Collector and when your activity whose context passed to viewmodel is died (fires off onDestroy callback) its allocated memory must be cleared by the Garbage Collector but since your viewmodel is still living, GC avoids to do that obviously because you may need that instance until your viewmodel dies as well.
We can get activity context in our activity by doing:
this
//or
getContext()With activity context, we are able to do everthing we can do with application context, plus:
- Layout Inflation
- Navigate to another Activity
- Start an Activity
- Show a Dialog
Service Context: It’s a context for Service class in Android and used for downloading operations or listening a music which sometimes has a very very long lifetime than our application. I mean it lives as long as our service lives.
Base Context: It exists for ContextWrapper actually. When AMS creates an implementation of the context abstract class, ContextWrapper gets that implementation with its getBaseContext() function, so there is no actual usecase of BaseContext in app development.
Resources
