Learn Jetpack Compose - Core Concepts & Compose Architecture

#Introduction

Episode 1 explained why Compose was born. Now you need to understand how it works: what a composable function is, how recomposition runs, how the composition tree is structured, and how the final pixels appear on screen.

The concepts in this episode are the shared language used throughout the entire series. If this episode feels heavy, that's normal — but hang in there, because the coming material will keep referring to terms like composition, state, and slots.

Episode 2 lays the foundation: composable functions, recomposition, the composition tree and slots, the rendering pipeline, and Compose's position within the Android framework.

#Composable Functions: UI as Functions

#The Basic Rules

The foundation of Compose is the composable function — a Kotlin function annotated with @Composable. This function produces UI based on its parameters and can only be called within a composition context. Compose assembles these functions into a UI tree that describes the screen.

Composable function

@Composable
fun KartuPengguna(nama: String, aktif: Boolean) {
    Card {
        Row {
            Text(nama)
            if (aktif) {
                Text("online")
            }
        }
    }
}

if (aktif) inside a composable is valid control flow — Compose processes the branch only when needed. Because the UI is simply a function of its inputs, the result is always predictable. To make sure your project compiles correctly after writing a composable, run ./gradlew :app:compileDebugKotlin in the terminal.

#Positional Memoization

Compose remembers the result of each composable based on its parameters and its position in the tree. This mechanism is called positional memoization: as long as the inputs don't change, Compose skips that function during recomposition. This is why the call order of composables must not change between invocations.

#Recomposition: How Compose Updates the UI

#State-driven Updates

Compose works on a state-driven model. When state changes, Compose re-runs the composables that read that state. This process is called recomposition, and Compose uses smart skipping — only the functions that actually read the changed state are recomputed.

State and recomposition

@Composable
fun Penghitung() {
    var jumlah by remember { mutableStateOf(0) }
 
    Button(onClick = { jumlah++ }) {
        Text("Ditekan $jumlah kali")
    }
}

remember { mutableStateOf(0) } stores a value that survives across recompositions. onClick = { jumlah++ } changes the state, and Compose automatically updates the text. The details of the state mechanism are dissected thoroughly in episode 5.

#The Composition Tree and Slots

#Tree Structure

Every composable call produces an entry in the composition tree. This structure is what Compose uses to compare old and new UI during recomposition. As long as the order and types of composables are the same, unnecessary work is skipped.

#The Slot API

The slots concept allows a composable to accept a region of UI as a parameter, not just data. This is the pattern Material Components use to inject free-form content:

Slot API

@Composable
fun HalamanDasar(content: @Composable () -> Unit) {
    Scaffold(topBar = { TopAppBar(title = { Text("Beranda") }) }) {
        content()
    }
}

content: @Composable () -> Unit is a slot: the caller is free to fill in the page content. This slot pattern is what keeps components like Scaffold, ModalBottomSheet, and SnackbarHost flexible.

#The Rendering Pipeline and Integration with Android Views

#The Three Phases of Rendering

After composition, Compose runs three sequential phases:

• Composition: builds the UI tree from composable functions.
• Layout: measures and places elements on screen.
• Drawing: draws the result to the canvas.

Modifiers that affect position work in the layout phase, while effects like background and shadow work in the drawing phase. These phases become relevant again when we discuss custom layouts in episode 18.

#Living on Top of the Android Framework

Compose doesn't replace Android; it runs on the same framework. Integration with legacy views is therefore always possible: AndroidView embeds a traditional view into a composable, and ComposeView embeds Compose into an XML layout. These interop mechanisms are covered in episode 16.

#Closing

Episode 2 built the conceptual foundation of Compose: composable functions as the representation of UI, state-driven recomposition, the composition tree with positional memoization, the slot API for flexible composition, the three-phase pipeline, and Compose's position of sitting on top of the Android framework.

Key takeaways:

• UI in Compose is composable functions annotated with @Composable.
• Recomposition only re-runs composables that read changed state.
• Positional memoization means the position of composables must stay consistent.
• The slot API accepts a region of UI as a parameter, not just data.
• The rendering pipeline: composition, then layout, then drawing.
• Compose runs on top of the Android framework, so interop is always possible.

In episode 3 we will discuss project setup and your first composable — creating a new Compose project in Android Studio, understanding the structure of build.gradle.kts, writing your first composable complete with a preview, and running it on the emulator. You'll put the episode 2 concepts into practice right here.