Jetpack Compose

The “Empty Activity” template in current Android Studio is already a Compose project: it sets up the Compose compiler plugin, the Material 3 dependency, and a MainActivity whose onCreate calls setContent { } instead of setContentView(R.layout.…). There is no XML layout file — the UI is Kotlin. You don’t wire up a build by hand for this track; the template does it so you can focus on composables.

A @Composable function describes a piece of UI; it doesn’t return a View, it emits UI into the composition by calling other composables (Text, Column, Button). Composable functions are normal Kotlin — they take parameters and can call each other — but they may only be called from other composables. By convention a composable is named in PascalCase like a type (Greeting, not greeting) and returns Unit.

@Preview renders a composable directly inside Android Studio — no build-install-launch cycle, no emulator boot. The previewed function takes no parameters, so you write a tiny wrapper that supplies sample data and calls the real composable. You can declare several previews (light/dark, different font scales, different states) side by side. Previews are the fastest feedback loop in Compose; lean on them constantly.

Column stacks children vertically, Row horizontally, Box overlaps them. Almost every composable accepts a modifier: Modifier that decorates it — Modifier.padding(16.dp).fillMaxWidth() reads left-to-right and order matters: padding before a background paints the padding outside the background; after, inside it. Pass a modifier parameter through your own composables so callers can position them — that’s the idiomatic Compose API shape.

Compose redraws by recomposition: when a state value a composable reads changes, Compose re-invokes that composable (and only what depends on it). mutableStateOf creates an observable state holder; remember keeps it alive across recompositions so it isn’t reset every frame. Use by with the getValue/setValue delegates to read/write it like a normal variable. For state that must survive configuration changes (rotation), use rememberSaveable instead of remember.

State hoisting moves a composable’s state to its caller, making the composable stateless: it receives the current value and an onValueChange: (T) -> Unit callback. This is unidirectional data flow — state flows down, events flow up. Stateless composables are easier to preview, reuse, and test, and they keep a single source of truth for each piece of state. Hoist state to the lowest common ancestor that needs to read or change it.

A Column with verticalScroll composes every child up front — fine for a handful, ruinous for thousands. LazyColumn (and LazyRow) only composes and lays out the items currently visible, recycling as you scroll, the way RecyclerView did for the View system. Provide a stable key per item so Compose can track items across data changes and animate/reorder correctly. Use LazyColumn for any list whose length you don’t control.

Material 3 (androidx.compose.material3) supplies themed components — Button, Card, Scaffold, TopAppBar — that read their styling from a MaterialTheme you wrap around your app. Pull values from MaterialTheme.colorScheme and MaterialTheme.typography rather than hard-coding colors, so light/dark and (on Android 12+) Material You dynamic color from the user’s wallpaper work for free via dynamicLightColorScheme / dynamicDarkColorScheme. Scaffold gives you the standard app-bar / content / FAB slots. TopAppBar is still marked ExperimentalMaterial3Api, so a composable that uses it needs @OptIn(ExperimentalMaterial3Api::class) until the API stabilises.

Local remember is fine for a widget; screen-level state belongs in a ViewModel, which survives configuration changes and holds your business logic. Model the screen as an immutable UI-state data class, expose it as a StateFlow<UiState> (commonly a private MutableStateFlow behind a public read-only StateFlow), and collect it in the composable with collectAsStateWithLifecycle() from androidx.lifecycle:lifecycle-runtime-compose. That collector stops gathering when the UI isn’t started, avoiding wasted work and leaks — preferred over the lifecycle-agnostic collectAsState(). The composable stays a stateless render of the latest UiState; events call ViewModel methods.

navigation-compose models navigation as a NavHost containing composable("route") { } destinations, driven by a NavController (rememberNavController()). navController.navigate("detail/$id") pushes onto the back stack; the system back button pops it. Pass arguments by encoding them in the route ("detail/{id}") and reading them from backStackEntry.arguments. Keep each destination a stateless composable fed by its own ViewModel, so the navigation graph wires which screen shows, not how it works.

Compose skips recomposing a composable when its inputs are unchanged and “stable”. Unstable inputs (e.g. a plain List or a class with var fields) defeat skipping and cause needless recompositions. Prefer immutable data and read-only collections (or mark types with @Immutable/@Stable); use the Layout Inspector’s recomposition counts to find hotspots. Cache derived work with remember(key) { … } so it recomputes only when key changes, and derivedStateOf when a value is computed from other State objects that change more often than the result. Don’t perform expensive work directly in a composable body — it runs on every recomposition.