Android Compose State Effects
When To Use
- Use this skill when the request is about: compose side effect problem, remember vs derivedstateof, collect flow in compose screen.
- Primary outcome: Manage Compose state, remember APIs, side effects, snapshots, and lifecycle-aware collection without leaks or loops.
- Reach for this skill when the problem lives inside a composable or Compose runtime primitive, not when redesigning app-wide state holders or reducers.
- This skill is about runtime primitives inside Compose. If the question is reducer design, screen contracts, or ViewModel ownership, hand off to
android-state-management. - Handoff skills when the scope expands:
android-state-managementandroid-compose-performance
Workflow
- Classify the issue first: local remembered state, saved state, derived state, lifecycle-aware collection, or one-off side effects.
- Pick the narrowest Compose primitive that matches that problem:
remember,rememberSaveable,derivedStateOf,produceState,collectAsStateWithLifecycle,LaunchedEffect,DisposableEffect,SideEffect, orsnapshotFlow. - Keep durable UI state separate from transient events such as snackbars, navigation, and analytics.
- Stabilize effect keys and callback references so recomposition does not relaunch work or capture stale lambdas.
- Hand off broader state-holder design to
android-state-managementonly after the Compose-runtime issue is isolated.
Guardrails
- Prefer lifecycle-aware collection such as
collectAsStateWithLifecyclefor UI-facing flows. - Use
rememberUpdatedStatewhen an effect should see the latest lambda or value without restarting. - Keep one-shot effects out of immutable screen state when they are really events.
- Do not launch coroutines or trigger navigation directly from the composable body outside the appropriate effect APIs.
Anti-Patterns
- Using
LaunchedEffect(Unit)or unstable keys when the effect should restart on real dependency changes. - Collecting flows in multiple places and wondering why events duplicate.
- Storing transient events as persistent booleans in screen state and then manually resetting them.
- Using
derivedStateOforsnapshotFlowwhen plain state reads would be simpler and cheaper.
Review Focus
- Which runtime primitive owns this behavior?
- Are recomposition and effect restarts intentional?
- Are state and event channels modeled separately?
- Is collection lifecycle-aware and cancellation-safe?
Examples
Happy path
- Scenario: Collect task state and snackbar events in Compose without duplicate launches.
- Command:
cd examples/orbittasks-compose &&./gradlew:app:testDebugUnitTest
Edge case
- Scenario: Handle recomposition when permission state and sync state change together.
- Command:
cd examples/orbittasks-compose &&./gradlew:app:assembleDebug
Failure recovery
- Scenario: Disambiguate state/effects work from generic Compose layout or state-management requests.
- Command:
python3 scripts/eval_triggers.py --skill android-compose-state-effects
Done Checklist
- The chosen Compose primitive matches the actual runtime problem.
- Effects have stable keys and do not duplicate on recomposition.
- State and events are separated clearly.
- Broader app-state architecture work is handed off instead of mixed into the composable fix.