How to Get Context in Jetpack Compose for Toast Messages in Kotlin

By the end of this page, you will understand how Context works in Jetpack Compose, why this@MainActivity is usually not the right approach inside a composable, and how to use LocalContext.current to show a Toast safely and cleanly.

In Android, many APIs need a Context. A Toast is one of them. In the traditional View system, you often had direct access to an Activity, Fragment, or View, so getting a Context felt straightforward.

In Jetpack Compose, UI is written as composable functions. These functions are not class instances like Activity, so this usually does not refer to what you expect. That is why code such as this@MainActivity is often not available or not appropriate inside a composable.

Compose provides access to Android framework objects through Composition Locals. For Context, the standard way is:

val context = LocalContext.current

This gives you the current Android Context for the composable tree. You can then use it with APIs like:

• Toast.makeText(...)
• reading resources
• accessing system services
• starting activities in some cases

Why this matters:

• It keeps composables decoupled from a specific

Think of Context as your app's environment pass.

In the old View system, you were often standing inside a room that already had a label like MainActivity, so grabbing the environment was easy.

In Compose, a composable is more like a recipe for UI, not a room itself. Since the recipe is not the activity, it does not automatically have direct access to MainActivity.

LocalContext.current is like asking the Compose system:

“What Android environment am I currently running in?”

Compose then hands you the right Context for that part of the UI tree.

The basic Compose syntax is:

val context = LocalContext.current

Then use it in your click handler:

Toast.makeText(context, "Hello", Toast.LENGTH_SHORT).show()

Example

@Composable
fun CreateListItem(itemIndex: Int) {
    val context = LocalContext.current

    Row(modifier = Modifier.padding(8.dp)) {
        Text(
            text = "Item $itemIndex",
            modifier = Modifier.weight(1f)
        )

        Button(
            onClick = {
                Toast.makeText(
                    context,
                    "Item name $itemIndex",
                    Toast.LENGTH_SHORT
                ).show()
            }
        ) {
            Text("Button $itemIndex")
        }
    }
}

Why this works

• LocalContext.current gives the current Android Context
• The context value can be used inside the button's onClick

Consider this composable:

@Composable
fun ToastButton(itemIndex: Int) {
    val context = LocalContext.current

    Button(onClick = {
        Toast.makeText(context, "Clicked item $itemIndex", Toast.LENGTH_SHORT).show()
    }) {
        Text("Show Toast")
    }
}

Here is what happens step by step:

1. Compose starts building the UI for ToastButton.
2. val context = LocalContext.current asks Compose for the current Android Context.
3. Compose stores that context value for this composition.
4. The Button is displayed on screen.
5. The user taps the button.
6. The onClick lambda runs.
7. Toast.makeText(context, "Clicked item $itemIndex", Toast.LENGTH_SHORT) creates a toast.
8. .show() displays the toast on screen.

Trace example

If itemIndex is 3, then:

Getting Context in Compose is useful in many real apps, not just for Toast.

Common use cases

• Showing toast messages

  • Example: "Profile saved"
  • Example: "Failed to load data"

• Accessing resources

  • Reading strings, dimensions, or other Android resources

• Using Android services

  • Clipboard
  • Connectivity manager
  • Notification manager

• Starting Android components

  • Launching another activity with an Intent

• Working with files or preferences

  • Accessing app storage helpers that need a Context

Example scenario

In a shopping app:

• User taps Add to cart
• A toast says Item added to cart
• The composable uses LocalContext.current to create that toast

In a form screen:

• User presses Submit
• Validation fails

In real projects, developers often use Context in Compose with a few common patterns.

1. Direct UI feedback

For quick feedback such as a toast:

val context = LocalContext.current

Button(onClick = {
    Toast.makeText(context, "Saved", Toast.LENGTH_SHORT).show()
}) {
    Text("Save")
}

2. Keep business logic out of composables

A composable should usually handle UI actions, while business logic stays in a ViewModel or use-case layer.

Good pattern:

• ViewModel decides what happened
• Composable decides how to display it

For example, a ViewModel emits a success event, and the composable shows a toast using context.

3. Guard clauses before using Context-based APIs

Example:

if (itemIndex < 0) return

This prevents invalid actions before trying to show a toast or start another Android action.

4. Event handling pattern

A common real-world pattern is:

• user clicks button
• UI sends event
• state updates
• composable reacts
• composable uses LocalContext.current for Android-only UI work

1. Using this@MainActivity inside a composable

Broken example:

@Composable
fun MyItem() {
    Button(onClick = {
        Toast.makeText(this@MainActivity, "Hello", Toast.LENGTH_SHORT).show()
    }) {
        Text("Click")
    }
}

Why it is a problem:

• A composable is not the activity
• this may not refer to what you think
• It tightly couples the composable to one activity

Use this instead:

@Composable
fun MyItem() {
    val context = LocalContext.current

    Button(onClick = {
        Toast.makeText(context, "Hello", Toast.LENGTH_SHORT).show()
    }) {
        Text("Click")
    }
}

2. Forgetting @Composable

Broken example:

fun MyItem() {
     context = LocalContext.current
}

LocalContext.current vs passing

val context = LocalContext.current

Toast.makeText(context, "Hello", Toast.LENGTH_SHORT).show()

Rules

• Use LocalContext.current inside composables
• Add @Composable to the function reading LocalContext.current
• Prefer Context over directly referencing an Activity
• Use Context only for Android-specific work

Common import

import androidx.compose.ui.platform.LocalContext

Basic pattern

@Composable
fun MyButton() {
    val context = LocalContext.current

    Button(onClick = {
        Toast.makeText(context, "Clicked", Toast.LENGTH_SHORT).show()
    }) {
        Text("Click")
    }
}

Edge cases

How do I get Context in Jetpack Compose?

Use LocalContext.current inside a composable.

Can I use this@MainActivity inside a composable?

Usually you should not. Composables are not activity instances, and this creates tight coupling.

Why does Toast.makeText() need a context?

Toast is an Android framework API and needs the current app or UI environment to display itself.

Does LocalContext.current return an Activity?

Not necessarily. It returns a Context. Sometimes that context is backed by an activity, but you should not assume that unless required.

Can I call LocalContext.current outside a composable?

No. It must be used from a composable function.

Is it okay to show a toast directly in a composable click handler?

Yes, for simple UI feedback this is normal. For larger app logic, keep business decisions outside the composable.

What is the modern Compose way to replace old layout code like FlexRow?

Modern Compose usually uses Row, , and APIs instead of older layout syntax.

• Composable functions — LocalContext.current can only be used inside composable functions.
• CompositionLocal — LocalContext is one example of how Compose provides shared values down the UI tree.
• State in Jetpack Compose — UI actions often use state together with events like button clicks.
• Button click handling in Compose — showing a toast usually happens inside an onClick lambda.
• Android Context — understanding what Context is helps explain why framework APIs need it.
• Activity vs Context — useful for knowing when a general context is enough and when activity-specific access is needed.
• Jetpack Compose modifiers — modern Compose layout and styling often use Modifier.padding, weight, and similar APIs.
• ViewModel with Compose — real apps often keep logic in a ViewModel and leave context-based UI work to the composable.