ComposeView is easy; deciding where to put it is the migration
Adding Compose to a View-based app is one class. The interesting decisions are which seam to cut at, and the ViewCompositionStrategy that governs when the composition is disposed.
kotlin
101 posts
What a Compose test suite should actually contain
A useful Compose suite is mostly unit tests, a layer of state-driven component tests, screenshot tests for visual regressions, and a handful of journeys. The shape matters more than the count.
A flaky test is a timing assumption you didn't know you made
Compose's test framework auto-syncs with the composition, so most tests need no waiting at all. The failures come from things that never go idle, and from work the framework cannot see.
Find, act, assert — and the rule that decides which test to write at all
Compose testing is finders, actions and assertions over the semantics tree. The API is small; the judgment is choosing between a unit test, a Compose test with a fake, and a full instrumented test.
Your UI tests query the accessibility tree, which is why testTag is a last resort
Compose UI tests match against the semantics tree, not the layout. Selecting by text and content description tests what users perceive; selecting by testTag tests an implementation detail you invented for the test.
Four tools, four questions, and none of them answers another's
Layout Inspector, the compiler reports, Macrobenchmark and the system trace each answer a different question. Using the wrong one produces confident, wrong conclusions, and knowing the split is most of performance work.
Nine pillars have quietly been teaching you one optimisation
Reading a state value later — in a lambda rather than as a parameter — moves the invalidation from composition to layout or draw. It is the single highest-leverage Compose optimisation, and it has one shape.
Baseline Profiles fix a problem recomposition counts can't see
Baseline Profiles ship a list of hot methods so ART compiles them at install time instead of interpreting them on first run. They typically cut startup and first-scroll jank by 20-30% and are unrelated to Compose recomposition.
Strong skipping made most of yesterday's advice unnecessary
Strong skipping lets composables skip even with unstable parameters, using instance comparison, and memoises lambdas automatically. It removes most of the need for @Immutable annotations and changes what the compiler report means.
The compiler decides your types are unstable, and it writes down why
Compose infers stability per class and per parameter, and can emit a report saying what it concluded. Understanding the inference rules — and why List is unstable — explains most unnecessary recomposition.
Compose performance is one question asked in four places
Compose performance work reduces to knowing which of composition, layout and draw is being invalidated, and why. The diagnostic order matters more than any individual optimisation.
Drag-and-drop crosses app boundaries, which is why it isn't just a drag gesture
Compose's drag-and-drop moves ClipData between sources and targets, including across apps. Reordering a list is a different problem with a different solution, and conflating them is why reorder implementations get complicated.