Flow and StateFlow

One value versus many

Some data arrives once: your account balance right now. Other data keeps changing: a cricket score, a delivery rider's location, the list of rows in a database table that the user keeps editing. A Flow is a stream of values delivered one after another over time, built on coroutines.

import kotlinx.coroutines.*
import kotlinx.coroutines.flow.*

fun countdown(from: Int): Flow<Int> = flow {
    for (i in from downTo 1) {
        emit(i)            // send a value to the collector
        delay(1000)
    }
}

fun main() = runBlocking {
    countdown(3).collect { println("OTP expires in $it s") }
    println("OTP expired")
}

Cold flows

A flow built with flow { } is cold: its code does nothing until someone calls collect, and it runs again from the start for each collector, like a recorded video that starts playing when you press play. Room can return Flow<List<T>> from a query, which emits a new list every time the table changes.

Operators

countdown(5)
    .filter { it % 2 == 1 }        // 5, 3, 1
    .map { "Tick $it" }
    .collect { println(it) }

StateFlow: the current state

A screen needs to know what to show right now, and to update when that changes. StateFlow is a hot flow that always holds exactly one current value. New collectors get the latest value immediately. MutableStateFlow lets the owner change the value; the owner exposes a read-only StateFlow to everyone else, the same private-mutable, public-read-only pattern you saw with lists.

import kotlinx.coroutines.flow.*

class CartState {
    private val _count = MutableStateFlow(0)
    val count: StateFlow<Int> = _count.asStateFlow()

    fun add() { _count.value += 1 }
}

// In Compose (module 6/7): val count by viewModel.count.collectAsStateWithLifecycle()

Hot means it exists and holds or emits values whether or not anyone is collecting. A ViewModel can also turn a cold Flow into a StateFlow with stateIn(viewModelScope, SharingStarted.WhileSubscribed(5000), initialValue), which keeps one shared upstream while the screen is visible.

Collecting safely on Android

Collecting a flow when the screen is not visible wastes work and can crash when the UI is gone. In Compose, use collectAsStateWithLifecycle(), which collects only while the screen is at least started. You will use it in module 7.

Common mistakes

• Expecting a flow { } block to run without collect. Cold flows are lazy.
• Exposing MutableStateFlow publicly. Expose StateFlow and change state only inside the owner.
• Using StateFlow for one-time events like "show a toast": a new collector would see it again after rotation. Model it as state that is cleared, or use a SharedFlow/Channel carefully.
• Collecting flows in Compose with collectAsState without lifecycle awareness for long-lived screens. Prefer collectAsStateWithLifecycle().