Flow vs StateFlow vs SharedFlow

Two collectors of the same Flow trigger two network requests. A snackbar event fires while the screen is rotating and disappears. A StateFlow doesn't emit after you "update" a list. Each of these comes from choosing the wrong kind of flow, or misunderstanding how it behaves.

The one-table summary

Flow: the cold default for data sources

class NotesRepository(private val dao: NoteDao) {
    fun observeNotes(): Flow<List<Note>> = dao.observeAll().map { rows -> rows.map { it.toDomain() } }
}

A cold flow does nothing until collected, and each collector gets its own run. That's ideal for repositories: the caller decides when and how long to observe.

StateFlow: state holders for the UI

class NotesViewModel(repo: NotesRepository) : ViewModel() {

    // 1. Derive state from a cold Flow with stateIn: shared, cached, lifecycle-friendly
    val notes: StateFlow<List<Note>> = repo.observeNotes()
        .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5_000), initialValue = emptyList())

    // 2. Hold mutable state directly with MutableStateFlow
    private val _query = MutableStateFlow("")
    val query: StateFlow<String> = _query.asStateFlow()
    fun onQueryChange(q: String) { _query.value = q }
}

SharingStarted.WhileSubscribed(5_000) stops the upstream five seconds after the last collector leaves. That survives rotation without restarting, but stops work when the user truly leaves the screen.

SharedFlow: broadcasts

class SessionEvents {
    private val _signedOut = MutableSharedFlow<Unit>(extraBufferCapacity = 1)
    val signedOut: SharedFlow<Unit> = _signedOut.asSharedFlow()

    fun notifySignedOut() { _signedOut.tryEmit(Unit) }
}

Key configuration: replay (how many past values new collectors receive), extraBufferCapacity and onBufferOverflow. With the default replay = 0, events emitted while nobody is collecting are lost. That's correct for some broadcasts, and wrong for one-off UI events.

One-off UI events: which tool?

Navigation and snackbars are where these choices bite. The options:

• Model the event as state (recommended by Android's architecture guidance): store userMessage: String? in UI state and clear it after showing. Nothing can be lost.
• Channel + receiveAsFlow(): buffers events until a single collector receives them. Each event is delivered to one collector.
• SharedFlow with replay 0: events emitted during rotation, when nobody is collecting, are dropped. Generally avoid it for UI events.

data class EditorUiState(val text: String = "", val userMessage: String? = null)

fun save() = viewModelScope.launch {
    repo.save(_state.value.text)
    _state.update { it.copy(userMessage = "Saved") }
}
fun messageShown() = _state.update { it.copy(userMessage = null) }

// In Compose:
// state.userMessage?.let { msg ->
//     LaunchedEffect(msg) { snackbarHostState.showSnackbar(msg); onMessageShown() }
// }

Decision rule

1. Exposing data from a repository or data source? Return a cold Flow.
2. Exposing state to the UI? Use a StateFlow (via stateIn or MutableStateFlow).
3. Broadcasting to several independent listeners, where missed values are acceptable or handled by replay? Use a SharedFlow.
4. One-off UI event? Prefer state. Otherwise use a buffered Channel collected with repeatOnLifecycle.

Common mistakes

• Exposing a cold flow from a ViewModel and collecting it from several composables, which restarts work on each collection and on every rotation.
• Using stateIn(..., SharingStarted.Eagerly, ...) everywhere, which keeps upstreams running even when no UI is visible.
• Calling stateIn inside a function that's called repeatedly, creating a new StateFlow each time. Create it once, as a property.
• Using SharedFlow with no replay for navigation events.

Frequently asked questions

Conclusion

Flow is a cold recipe for data. StateFlow is hot, always holds the latest value, and is the right tool for UI state. SharedFlow is a configurable broadcast. Expose cold flows from repositories, convert them to StateFlow in ViewModels with stateIn, and model one-off UI events as state whenever you can.

Next step: master the building block underneath all of these in Suspend Functions Explained.