Composable Functions & Previews — Android Course

What you'll learn

Composables become powerful when they take parameters — then one function can render any data you pass it, and you build a whole screen by composing small, reusable pieces. This module also introduces recomposition, the engine that keeps your UI in sync with your data.

By the end you'll be able to:

Pass parameters to composables to make them reusable
Compose screens from smaller composables
Explain what recomposition is
Configure previews for different scenarios

Parameters

A composable takes parameters exactly like any Kotlin function. Passing data in makes it reusable — instead of a composable hard-coded to one name, you get one that renders any name. Default values work too, so callers can omit optional parameters.

Reusing composables

This is how real UIs are built: define a small composable once, then call it repeatedly with different data. Here a ProfileCard is reused to build a team list — and notice a composable (Team) is made entirely of calls to other composables:

Team.kt

@Composable
fun ProfileCard(name: String, role: String) {
    Column {
        Text(text = name)
        Text(text = role)
    }
}

@Composable
fun Team() {
    Column {
        ProfileCard(name = "Ada", role = "Engineer")
        ProfileCard(name = "Linus", role = "Maintainer")
    }
}

9:41

Ada

Engineer

Linus

Maintainer

Team() — how this renders on a device

Key idea

Small, focused, reusable composables are the goal. A screen is a tree of composables — a Screen calls a Header and a List, the list calls many Rows, and so on. Compose it like Lego, from small blocks up.

Recomposition

Here's the magic. When the data a composable reads changes, Compose automatically re-runs that function to update the screen — this is called recomposition. You never manually update the UI; you change the data, and Compose redraws the parts that depend on it. Smartly, it only re-runs the composables whose inputs actually changed, skipping the rest for performance.

Note

Because a composable can re-run at any time (and often), it should be fast and free of side effects — don't start network calls or mutate global state directly inside one. Think of the composable body as simply describing the UI for the current data. You'll learn the correct place for side effects in Phase 5.

Configured previews

Previews take parameters to simulate real conditions. Stack several on one composable to check it in light and dark themes, at different font sizes, or on different screen widths — all without running the app:

ProfileCardPreview.kt

import android.content.res.Configuration

@Preview(name = "Light", showBackground = true)
@Preview(
    name = "Dark",
    showBackground = true,
    uiMode = Configuration.UI_MODE_NIGHT_YES,
)
@Composable
fun ProfileCardPreview() {
    ProfileCard(name = "Ada", role = "Engineer")
}

Recap & quick check

Key takeaways

Composables take parameters like any function, which makes them reusable with different data.
Build screens by composing small composables into a tree — call composables inside composables.
Recomposition: when the data a composable reads changes, Compose re-runs it to update the UI.
Compose skips composables whose inputs didn't change, so recomposition stays efficient.
Keep composable bodies fast and side-effect-free — they may re-run frequently.

Quick check

1. Why pass parameters to a composable?

2. What is recomposition?

3. How does Compose keep recomposition efficient?

4. Why should a composable body avoid side effects?

5. How do you preview a composable in both light and dark themes?

You can build reusable UI now. Next we style it — mastering Text and the Modifier system that shapes every composable.