Best practices for implementing Android ViewModels using Kotlin 2.3+ Explicit Backing Fields, StateFlow for UI state, and SharedFlow for one-off events.
64
76%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Fix and improve this skill with Tessl
tessl review fix ./.github/skills/architecture/android-viewmodel/SKILL.mdUse 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/statebacking property pattern.
- Kotlin 2.3: Experimental (
-Xexplicit-backing-fields)- Kotlin 2.4+: Stable (recommended)
Avoid creating duplicate backing properties unless targeting older Kotlin versions.
Represents the persistent UI state.
Examples:
Use an explicit backing field.
val uiState: StateFlow<UiState>
field = MutableStateFlow(UiState.Loading)The backing field is mutable (MutableStateFlow) while consumers only see StateFlow.
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)Use for transient events that should not survive recomposition or configuration changes.
Examples:
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().
Suspend:
uiEvent.emit(UiEvent.NavigateBack)Non-suspending:
uiEvent.tryEmit(UiEvent.ShowSnackbar("Saved"))Always collect lifecycle-aware.
val state by viewModel.uiState.collectAsStateWithLifecycle()Collect inside a single LaunchedEffect.
LaunchedEffect(Unit) {
viewModel.uiEvent.collect { event ->
when (event) {
is UiEvent.NavigateBack -> { /* ... */ }
is UiEvent.ShowSnackbar -> { /* ... */ }
}
}
}Do not collect SharedFlow with collectAsState().
Use lifecycle-aware collection.
lifecycleScope.launch {
repeatOnLifecycle(Lifecycle.State.STARTED) {
viewModel.uiState.collect {
render(it)
}
}
}Likewise for events.
lifecycleScope.launch {
repeatOnLifecycle(Lifecycle.State.STARTED) {
viewModel.uiEvent.collect(::handleEvent)
}
}Launch all ViewModel work in viewModelScope.
viewModelScope.launch {
repository.refresh()
}Business logic should preferably be delegated to UseCases or Repositories.
Represent the entire screen with a single immutable state object.
data class UiState(
val isLoading: Boolean = false,
val items: List<Item> = emptyList(),
val error: String? = null
)Avoid exposing multiple unrelated StateFlows for one screen unless they truly have different lifecycles.
Expose immutable APIs (StateFlow, SharedFlow)
Prefer Explicit Backing Fields (Kotlin 2.4+)
Use immutable UI state
Use update {} when modifying state
Keep one-off events in SharedFlow
Keep business logic out of Composables
Use collectAsStateWithLifecycle()
Use repeatOnLifecycle() in Views
Launch work in viewModelScope
Do not expose MutableStateFlow
Do not use StateFlow for navigation events
Do not use SharedFlow for persistent screen state
Do not keep duplicate _state properties when Explicit Backing Fields are available
82900ea
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.