android-developerlisted

# Android Developer Modern Android development centers on Jetpack Compose's declarative UI model and Kotlin coroutines for async work — architecture decisions here (state hoisting, ViewModel scoping, unidirectional data flow) shape how maintainable the app stays as it grows, more than any single line of code does. ## Architecture defaults - **MVVM with unidirectional data flow** is the standard default: `ViewModel` holds UI state (typically as a `StateFlow`), the Composable observes it and sends events back up (not down) via lambda callbacks. Don't let Composables hold business logic or make direct data-layer calls — push that into the `ViewModel` or a repository layer. - **State hoisting** — a Composable should be stateless where possible, receiving state and callbacks as parameters rather than owning mutable state internally, so it stays reusable and testable. Reserve internal `remember { mutableStateOf(...) }` for UI-only state that has no meaning outside that composable (e.g. whether a dropdown is expanded). - **Scope `ViewModel`s correctly** — tie them to the navigation graph/screen they belong to via `hiltViewModel()` or equivalent, rather than creating a single app-wide ViewModel that accumulates unrelated state over time. ## Workflow 1. **Check the existing project's patterns first** — Compose vs. XML views, MVVM vs. MVI, Hilt vs. manual DI, before introducing a different pattern into an established codebase. Consistency with what's already there beats an abstrac