Jetpack Compose Advanced

Android Development — Production & Publishing

Course 3 · Chapter 1 · Jetpack Compose Advanced

🎬 Jetpack Compose Advanced

Course 2 built working screens with Compose; this chapter covers what turns a working screen into a polished, production-quality one — custom layout logic, real animations, app-wide theming beyond the defaults, and the recomposition pitfalls that quietly cause janky performance in larger apps.

📐 Custom Layouts

Column and Row (Course 2, Chapter 1) cover most needs, but the Layout composable gives full manual control over measuring and placing children — useful when no built-in layout produces the arrangement needed:

@Composable
fun StaggeredRow(modifier: Modifier = Modifier, content: @Composable () -> Unit) {
    Layout(content = content, modifier = modifier) { measurables, constraints ->
        val placeables = measurables.map { it.measure(constraints) }
        var yOffset = 0

        layout(constraints.maxWidth, placeables.sumOf { it.height }) {
            placeables.forEach { placeable ->
                placeable.placeRelative(x = 0, y = yOffset)
                yOffset += placeable.height
            }
        }
    }
}
        

Every child is measured first (asked how big it wants to be, given the available constraints), then placed at specific coordinates — this two-phase measure/place cycle is exactly what Column and Row do internally, just with their own arrangement logic instead of this example's simple vertical stacking. Reaching for a custom Layout is genuinely rare in practice — most real UI is built entirely from existing layout composables, so recognizing when it's actually necessary (rather than reaching for it prematurely) matters more than mastering every detail of the API.

🎞️ Animations

The simplest Compose animations are animate*AsState functions — they take a target value and automatically animate toward it whenever that target changes:

@Composable
fun ExpandableCard(expanded: Boolean) {
    val height by animateDpAsState(
        targetValue = if (expanded) 200.dp else 80.dp,
        label = "cardHeight"
    )
    Box(modifier = Modifier.height(height).fillMaxWidth())
}
        

animateDpAsState reuses the exact same by property delegation as remember { mutableStateOf(...) } (Course 2, Chapter 1) — height reads like a plain value, but every recomposition where expanded changes triggers a smooth transition rather than an instant jump.

@Composable
fun Notification(visible: Boolean) {
    AnimatedVisibility(visible = visible) {
        Text("You have a new message")
    }
}
        

AnimatedVisibility animates a composable's appearance/disappearance entirely (fade, slide, or a custom combination) rather than animating one property at a time — the right tool when something is conceptually "there or not there," not just changing size or color.

Compose Animation vs CSS

CSS	Compose
transition: height 0.3s ease;	animateDpAsState(targetValue = ...)
@keyframes / a mount-transition library	AnimatedVisibility
Coordinated multi-property transition	updateTransition (multiple synchronized animate*AsState-style values)

🎨 Theming Beyond the Defaults

Course 1 Chapter 8 covered XML themes (themes.xml, colorPrimary). Compose has its own, parallel theming system — MaterialTheme, typically wrapping the whole app:

private val AppColorScheme = lightColorScheme(
    primary = Color(0xFF3DDC84),
    onPrimary = Color(0xFF0F1117)
)

@Composable
fun MyAppTheme(content: @Composable () -> Unit) {
    MaterialTheme(
        colorScheme = AppColorScheme,
        typography = Typography(),
        content = content
    )
}
        

Any composable inside MyAppTheme { } can read MaterialTheme.colorScheme.primary instead of hardcoding a color — the exact same "define once, reference everywhere" idea as Course 1's XML theme attributes, just expressed as Kotlin objects instead of an XML resource. Dark mode support follows the same pattern too — a separate darkColorScheme(...), chosen based on isSystemInDarkTheme(), replaces Course 1's values-night resource-qualifier folder mechanism with an explicit runtime check.

⚡ Performance — Avoiding Unnecessary Recomposition

Course 2 established that Compose recomposes only what reads changed state — but that guarantee depends on Compose being able to tell whether a composable's inputs actually changed, which isn't automatic for every type:

Stable Types Recompose Efficiently

A data class built entirely from vals (Kotlin Fundamentals Chapter 4) is considered stable — Compose can compare old vs new by value and skip recomposition if nothing changed. A regular class with vars, or a plain interface, may not offer this guarantee.

remember for Expensive Calculations

A costly computation inside a composable body re-runs on every recomposition unless wrapped in remember(key) { ... } — the same remember from Course 2, used here purely for caching a derived value, not holding mutable state.

@Composable
fun ExpensiveList(items: List<Item>) {
    val sortedItems = remember(items) { items.sortedBy { it.priority } }   // only re-sorts when "items" actually changes

    LazyColumn {
        items(sortedItems, key = { it.id }) { item ->   // key() helps Compose track identity across list changes
            Text(text = item.name)
        }
    }
}
        

remember(items) { ... } takes items as a key — the sort only re-runs when items itself changes, not on every unrelated recomposition. key = { it.id } inside LazyColumn's items(...) gives each row a stable identity across reorders/insertions/deletions — directly the same role React's key prop plays in a list, and DiffUtil's areItemsTheSame played back in Course 1's RecyclerView chapter.

⚠ derivedStateOf — For State Computed From Other State

remember { derivedStateOf { someState > threshold } } is a more specialized tool: it recomputes only when its own inputs genuinely change, and — critically — only triggers recomposition of composables reading its result when that result actually differs, not every time the underlying state updates. Useful for something like "is the list scrolled past item 5?" derived continuously from a fast-changing scroll position, where recomposing on every pixel of scroll would be wasteful.

💻 Coding Challenges

Challenge 1: An Animated Toggle

Write a composable ToggleCard(isActive: Boolean) that animates both its background color (animateColorAsState, between two colors) and its elevation/size (animateDpAsState) based on isActive, plus a Button that flips a remembered Boolean state to trigger it.

Goal: Practice combining two animate*AsState calls driven by the same state.

→ Solution

Challenge 2: A Custom MaterialTheme

Define a custom color scheme (at least primary and onPrimary) and wrap a small screen (a Text and a Button) in a MyAppTheme composable using it. Confirm the Button picks up the custom primary color automatically, the same way an unstyled Course 1 Button picked up colorPrimary from an XML theme.

Goal: Practice defining and applying a Compose-native theme.

→ Solution

Challenge 3: remember and key() in a List

Write a composable rendering a LazyColumn of a List<Product>, sorted by price using remember(products) { }, with a stable key = { it.id } on each item. Add a comment explaining what could go wrong (in terms of wasted work or incorrect item state) if either the remember or the key were removed.

Goal: Practice both performance techniques together and reason about why each matters.

→ Solution

💡 Profiling Beats Guessing

Performance techniques like remember and stable types are easy to over-apply "just in case." Android Studio's Layout Inspector and Compose-specific recomposition counts (enabled via a debug flag) show exactly which composables are recomposing and how often — worth reaching for before assuming where a real performance problem actually is, rather than optimizing blind.

🎯 What's Next

Next chapter: Testing — unit tests, instrumented tests, Espresso, and Compose UI testing.