android-viewmodellisted

# Android ViewModel and UI State Sources of truth: [UI layer](https://developer.android.com/topic/architecture/ui-layer), [State production](https://developer.android.com/topic/architecture/ui-layer/state-production), [UI events](https://developer.android.com/topic/architecture/ui-layer/events), [State holders](https://developer.android.com/topic/architecture/ui-layer/stateholders). The core idea: **state is; events happen.** The ViewModel turns inputs (repository data, user actions) into one observable UI state. Everything the UI needs to render, including messages and navigation triggers, is part of that state. ## 1. Role and boundaries - A ViewModel is the **business logic state holder for one screen** (a navigation destination). Use it only in screen-level composables. - Reusable components use plain state holder classes (`compose-ui`), never a ViewModel. - ViewModels hold **no** `Context`, `Activity`, `Resources`, `View`, or lifecycle types. Extend `ViewModel`, never `AndroidViewModel`. - Business logic is delegated to repositories, or to use cases when reused or complex. - The screen composable reads state and passes plain values and lambdas down. **Never pass the ViewModel to child composables.** ## 2. UI state - Name it `<Functionality>UiState`. - Make it immutable: a `data class` with `val`s, or a `sealed interface` for mutually exclusive states. A read-only `List` can still have a mutable alias: publish owned snapshots or persistent immutable collections, and