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.
android
118 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.
The keyboard covered the field, and the fix was not imePadding
Insets, soft-input mode, scroll position and focus order are four systems, and three are configured outside Compose.
A route is a string until you make it a type
String routes fail at runtime on a typo or a missing argument. Serializable types move both into the compiler.
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.