Introduction
If you have spent any meaningful time building screens in Jetpack Compose, you have probably hit the same wall. Your composable starts small, but features pile up. A search bar here, a loading spinner there, a toggle between modes, a progress tracker. Before you know it, state variables are scattered across half a dozen remember calls, recompositions fire when they shouldn't, and debugging feels like untangling holiday lights. The pain gets worse the moment your UI needs to survive a configuration change like a screen rotation.
The solution is a pattern the Android community calls Unidirectional Data Flow (UDF). Instead of sprinkling state throughout your composables, you consolidate everything into a single, immutable data class, expose it through a StateFlow inside a ViewModel, and let your composable observe it. State flows down to the UI. Events flow up to the ViewModel. The result is a screen that is predictable, testable, and resistant to unnecessary recompositions.
In this article, you will walk through a production Android screen: a map-based routing interface. You will dissect exactly how its state is modeled, updated, and consumed. You will see actual Kotlin code, not contrived counter examples, and learn why each architectural choice prevents bugs that surface in real apps.
