Compose Architecture Review

When to Use This Skill:
- Reviewing EXISTING Compose screens/ViewModels
- Code review for architectural violations
- Refactoring guidance for specific files
- Validating state management patterns

When to Use project-architecture-analyst-android Agent Instead:
- Planning NEW features (uncertain file placement)
- Understanding project-wide architecture
- Major changes affecting multiple modules
- Need to discover existing patterns before implementing

Review Checklist

Separation of Concerns

• Composables: presentation only (no business logic, network, DB)
• ViewModels: state + business logic (StateFlow, events)
• Repository/UseCase: data access separated from UI

State Management

• remember - composable-local state only
• rememberSaveable - survive config changes
• ViewModel with StateFlow/MutableStateFlow - screen state
• collectAsStateWithLifecycle() - lifecycle-aware collection
• derivedStateOf - computed state from other state
• CompositionLocal - shared read-only state
• Use unidirectional data flow: state flows down, events flow up
• Prefer stateless composables (receive value + onChange callbacks)
• Use plain state-holder classes for complex state not tied to lifecycle
• Prefer side effects via LaunchedEffect (async work), DisposableEffect (cleanup), SideEffect (framework integration), produceState, rememberCoroutineScope, or snapshotFlow rather than arbitrary side effects in composable bodies
• Use SavedStateHandle for persistent state across process death

State Lifecycle Issues

• No leaked ViewModels (use viewModel() or hiltViewModel())
• Proper cleanup in ViewModel.onCleared()
• StateFlow collected with lifecycle awareness
• No unnecessary state hoisting

Dependency Injection

• Dependencies injected (check project: Koin, Hilt, Dagger, or manual)
• No hardcoded singletons in composables
• ViewModels receive dependencies via constructor

Composable Design

• Composables are small (single responsibility)
• Complex screens broken into components
• Reusable components extracted
• Stateless composables preferred (state hoisting)

Common Issues

State Hoisting Pattern

Composable receives: value: T, onValueChange: (T) -> Unit ViewModel holds: MutableStateFlow<T>

Severity

• 🔴 Critical: Architecture violation
• 🟡 Improvement: Better pattern available
• 🟢 Enhancement: Optional optimization