Android ViewModel & State Management

Instructions

Use ViewModel to own UI state and business logic. It should survive configuration changes and expose immutable APIs.

Kotlin 2.3+

Prefer Explicit Backing Fields instead of the traditional _state/state backing property pattern.

• Kotlin 2.3: Experimental (-Xexplicit-backing-fields)
• Kotlin 2.4+: Stable (recommended)

Avoid creating duplicate backing properties unless targeting older Kotlin versions.

---

1. UI State (StateFlow)

Purpose

Represents the persistent UI state.

Examples:

• Loading
• Success(data)
• Error(message)
• Empty

Declaration

Use an explicit backing field.

val uiState: StateFlow<UiState>
    field = MutableStateFlow(UiState.Loading)

The backing field is mutable (MutableStateFlow) while consumers only see StateFlow.

Updating State

Prefer update { } for atomic updates.

_uiState.update { old ->
    old.copy(isLoading = false)
}

With explicit backing fields:

uiState.update {
    it.copy(isLoading = false)
}

You may also assign directly when appropriate.

uiState.value = UiState.Success(data)

---

2. One-Off Events (SharedFlow)

Purpose

Use for transient events that should not survive recomposition or configuration changes.

Examples:

• Navigate
• Show Snackbar
• Show Toast
• Open Dialog
• Request Permissions

Declaration

val uiEvent: SharedFlow<UiEvent>
    field = MutableSharedFlow(
        replay = 0,
        extraBufferCapacity = 1
    )

replay = 0 ensures events are not replayed after recreation.

Using extraBufferCapacity = 1 is recommended for UI events sent with tryEmit().

Sending Events

Suspend:

uiEvent.emit(UiEvent.NavigateBack)

Non-suspending:

uiEvent.tryEmit(UiEvent.ShowSnackbar("Saved"))

---

3. Collecting in Compose

StateFlow

Always collect lifecycle-aware.