ViewModel & StateFlow

When state outgrows the composable

The Walkers screen shows a list fetched from the backend. That involves real logic: start a request, handle success, handle failure. Stuffing all of that into a @Composable function gets ugly fast — and recomposition can re-run that function far more often than you'd want a network call to fire.

The Android pattern is a ViewModel: a class that owns a screen's data and the logic around it, and — unlike a composable — survives configuration changes (like a screen rotation) on its own. The composable's only job is to display whatever the ViewModel says.

Inside the ViewModel, PawWalk uses a pair of Flows: a private MutableStateFlow that only the ViewModel can change, and a public StateFlow — the read-only view of the same stream — that the screen observes. That split is exactly private(set) var from the iOS course, just spelled with two properties instead of one keyword.