We use Google Analytics to see which pages help people. No ads, no profiles. Privacy Policy
118 posts
Compose renders in three phases. Where you read state decides which phase invalidates, and moving a read from composition into layout or draw is the single highest-leverage performance change available.
A network call written directly in a composable fires an unpredictable number of times. LaunchedEffect, DisposableEffect and SideEffect each define a different notion of when work should happen.
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.
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.
@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.
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.
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.
What a composable function actually is, the three layout blocks every screen is made of, and how to preview one without running the app.
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.
Before learning a new toolkit, work out what you already know. Four questions that decide where to start, applied to Jetpack Compose.
