Android Context 101 with Class Diagram

Beginner's Guide to understand the fundamental of Context with class diagram in Android app development

You may find Context in Android app development is confusing. For example, which one you should use?

Before answering that, let's look at the Context class diagram below to understand its relationship with other classes/components.

Context Class Diagram

From the class diagram above, you can tell Activity, Service and Application inherits/extends Context indirectly.

As you can see, there are ContextThemeWrapper that extends ContextWrapper that extends Context. Here are the brief descriptions of all 3 classes.

• Context is an abstract class that allows an Android application to access system resources and interact with the operating system

• ContextWrapper is a convenient way to modify the behavior of a Context object, such as adding additional functionality or overriding existing behavior, without changing the original Context itself.

• ContextThemeWrapper allows you to change the visual appearance of an activity or view by applying a different theme to it

The most important thing to understand here is ContextWrapper has a mBase member variable which holds the Context reference (called Base Context) from the Android system which creates it.

For example, when an Activity is created by an Android system, a newly created Context (from the Android system) is passed into the ContextWrapper (held by the mBase member variable).

So after an Activity is created, it consists of 3 context objects now:

• Application Context - Can be retrieved by calling GetApplicationContext(). This is the same object instance throughout the whole application.

• Base Context - Can be retrieved by calling GetBaseContext(). This is a newly created Context every time an activity is created.

• Activity Context - The activity itself is a context, that can be retrieved by this within the Activity. This is a newly created context too, and it is different from the Base Context.

Similar to Service creation, which also consists of 3 context objects, except the Activity context is replaced by Service Context. There are also View Context and Fragment Context, but those do not apply to Jetpack Compose.

Which Context to Use?

Now you know there are 3 types of Context, Application Context, Activity Context and Service Context. The important concept of which context to use is to understand its lifecycle.

Application Context

Application lives for the entire duration of the application's lifecycle. So, if you have a singleton object that needs context, you want to pass in the Application Context.

A good example is the Room database creation that you usually want to pass in the Application Context into Room.databaseBuilder().

/.../

instance = Room.databaseBuilder(

    context.applicationContext,

    ArticlesDatabase::class.java,

    "articles.db")

    .fallbackToDestructiveMigration()

    .build()

/.../

Activity Context

An activity is created when the activity is launched and lives for the duration of the activity's lifecycle. The activity context is used for tasks that require interaction with the UI (e.g. displaying a toast message or starting a new activity).

For example, this starts an NewActivity with an Activity Context:

/.../

val context = LocalContext.current

context.startActivity(

    Intent(context, NewActivity::class.java)

)

/.../

Service Context

The Service Context is used for tasks that require background processing, such as downloading data or playing music.

For example, Service Context is passed into the MediaPlayer.create(). When the service is destroyed, the MediaPlayer is destroyed too, so passing in the Service Context here makes a lot of sense.

class PlayAudioService : Service() {

    private val mediaPlayer: MediaPlayer by lazy {

        MediaPlayer.create(this, R.raw.daybreak)

    }

}

Base Context

Oops, there is one more, which is called Base Context. This Context is from the Android System. I honestly do NOT know any usage of it. I think it is useless. Why do we want to access this Context from the Android system?

Conclusion

The application context is similar to a singleton object, where the object lives throughout the application.

Passing Activity/Service Context to a singleton object leads to memory leaks because the singleton will outlive the activity/service.

On the other hand, passing the Application context instead of the Activity context into the UI object may cause some display issues due to the activity-specific resources are not available.

Same as Service Context, if a wrong Context is being used the service will be not bound correctly.

Last but not least, Base Context is useless. My guess is its lifecycle is very similar to the Activity/Service lifecycle, but I do not know why we need it. If you find any proper usage of it, let me know. :)

---

Originally published at https://vtsen.hashnode.dev.