A composable's lifecycle is three events, and none of them is onDestroy
Composables have a lifecycle, but it is nothing like a View's. Three events — enter, recompose, leave — and the identity rules that decide which one you get.
All posts
Recomposition doesn't re-run your screen. It re-runs the scopes that read what changed.
Compose does not re-run your whole screen when state changes. It re-runs the smallest restartable scopes that read the changed value. Once you can see those scopes, recomposition stops being mysterious.
What @Composable actually does to your function
@Composable is a compiler plugin that adds hidden parameters to your function. Once you know what it adds, the rules about calling context, skipping and recomposition stop being arbitrary.
Thinking in Compose: you can't reach into the UI any more, and that's the point
In Views you fix UI by reaching in and mutating it. Compose removes that ability entirely. Understanding why the removal is the feature is what makes the rest of Compose make sense.
Compose has two version problems, and the BOM only solves one
The Compose BOM aligns runtime artifacts. The Kotlin/Compose compiler is a separate alignment problem, and mixing the two up produces errors that look like your code is wrong when it isn't.
Basics of Jetpack Compose
What a composable function actually is, the three layout blocks every screen is made of, and how to preview one without running the app.
What is Jetpack Compose?
XML made you invalidate the UI by hand. Compose recomposes only the nodes whose data changed — and that one difference reorders how you build a screen.
Analyse your Android knowledge before you learn anything new
Before learning a new toolkit, work out what you already know. Four questions that decide where to start, applied to Jetpack Compose.
Asking AI to check its own work does not work. Ask it to disprove it.
A verifier asked to confirm will confirm. Inverting the instruction to 'try to prove this wrong' found bugs that three rounds of review had passed, including one in the verifier itself.
The agent said 'fixed'. The list said otherwise
A delete returned deleted:true while the item was still there. Four failures in one day shared a shape: the action reported on itself, and nothing read the state back.
An agent that checks the page itself
Giving an agent a real browser removes the slowest loop in web debugging. The first thing that breaks is not your selectors — it is that a headless browser is refused at the edge.
A test that cannot fail is not a test. Mine passed twice.
A RED test fixture that passed because a comment explaining the omission contained the omitted string. The failure mode is generic: any test whose input mentions what it removes.