ViewModel and MVVM

Why a ViewModel?

If a screen's data and logic live in composables or the activity, two problems appear. First, rotation recreates the activity and the data is lost or reloaded. Second, logic mixed with UI code is hard to test. A ViewModel is a class that holds the state and logic for a screen and survives configuration changes. It is cleared only when the screen is gone for good (for example, the user navigates away and it is popped from the back stack).

MVVM in plain words

A ViewModel with UiState

data class CartUiState(
    val items: List<String> = emptyList(),
    val isCheckingOut: Boolean = false,
    val message: String? = null,
) {
    val count: Int get() = items.size
}

class CartViewModel : ViewModel() {
    private val _uiState = MutableStateFlow(CartUiState())
    val uiState: StateFlow<CartUiState> = _uiState.asStateFlow()

    fun onAdd(item: String) {
        _uiState.update { it.copy(items = it.items + item) }
    }

    fun onCheckout() {
        viewModelScope.launch {
            _uiState.update { it.copy(isCheckingOut = true) }
            delay(1000)                       // pretend payment call
            _uiState.update { CartUiState(message = "Order placed!") }
        }
    }
}

A UiState data class collects everything the screen needs to draw. Because it is immutable, every change creates a new object with copy, and StateFlow tells the UI. update { } is a thread-safe way to change a MutableStateFlow's value based on the old one.

Using it from Compose

@Composable
fun CartScreen(viewModel: CartViewModel = viewModel()) {
    val state by viewModel.uiState.collectAsStateWithLifecycle()
    CartContent(state = state, onAdd = viewModel::onAdd, onCheckout = viewModel::onCheckout)
}

@Composable
fun CartContent(state: CartUiState, onAdd: (String) -> Unit, onCheckout: () -> Unit) {
    Column(Modifier.padding(16.dp)) {
        Text("${state.count} items")
        Button(onClick = { onAdd("Mango pickle") }) { Text("Add pickle") }
        Button(onClick = onCheckout, enabled = state.count > 0 && !state.isCheckingOut) { Text("Checkout") }
        state.message?.let { Text(it) }
    }
}

collectAsStateWithLifecycle() (from the lifecycle-runtime-compose library) collects the flow only while the screen is at least STARTED, so nothing runs in the background when the app is hidden.

Splitting CartScreen (which talks to the ViewModel) from CartContent (which only takes state and lambdas) is a common pattern. Previews and UI tests use CartContent with sample state, with no ViewModel needed.

Events in, state out

The UI never changes the state directly. It calls functions on the ViewModel (events such as onAdd, onCheckout), and the ViewModel updates the state. The UI just draws whatever state it receives. This one-way loop makes bugs easy to trace: every change happens in one place.

Common mistakes

• Holding a reference to an Activity, Context or composable inside the ViewModel: memory leaks. A ViewModel outlives the activity.
• Exposing MutableStateFlow publicly: any screen can change state anywhere.
• Several separate flows for one screen that can disagree. Prefer one UiState.
• Doing network calls in composables instead of the ViewModel.