DEV Community: Ben

Three bugs I found in my own BaseViewModel

Ben — Mon, 12 Oct 2026 18:16:53 +0000

A small UDF base class for Compose Multiplatform: one state, one-time events and central error handling

Every Compose Multiplatform project I've seen ends up with some kind of BaseViewModel. Mine holds a single immutable UI state, sends one-time events like snackbars and navigation, and routes unexpected errors to one place. It's about 100 lines, and a review pass found three problems in my first version.

This post shows the class, the three bugs and why they matter, and how it's used. It also shows a few tests, because this class sits under every screen.

What you'll get

A base ViewModel with one state, one event stream and one error path
A collectToState helper that removes the usual init { flow.onEach { ... } } boilerplate
A launch helper that handles errors without breaking coroutine cancellation
An exception handler you can swap out, with a hook for analytics
Tests for the parts most likely to break

Full source: GitHub. This is the BaseViewModel that the dark mode post mentions but doesn't explain.

1. The design

Three ideas, all from unidirectional data flow:

State is one immutable object per screen, exposed as a StateFlow. The UI renders it and never changes it.
Events are things that should happen once: show a snackbar, navigate, open a dialog. They don't belong in state, because state is replayed to every new collector. A snackbar that reappears after rotation is a bug.
Errors from background work go through one handler that decides what the user sees.

The dependencies are kotlinx-coroutines and androidx.lifecycle (ViewModel), both of which support multiplatform.

2. The events and the handler

The event type is a marker interface, so each feature defines its own events:

// ui/model
interface OneTimeEvent

The exception handler uses the template method pattern. The base class always tracks the exception, and subclasses decide what, if anything, the user sees:

// ui/error
abstract class BaseUiExceptionHandler {

    fun handleException(e: Throwable): OneTimeEvent? {
        trackException(e)
        return evaluateException(e)
    }

    protected abstract fun evaluateException(e: Throwable): OneTimeEvent?

    protected fun trackException(e: Throwable) {
        // TODO: send to analytics / crash reporting
    }
}

Returning null means "log it, but show nothing". That's useful for errors the user can't act on.

A concrete handler (the exception types here are examples, so use your own):

enum class ErrorKind { Network, Unknown }

data class ShowError(val kind: ErrorKind) : OneTimeEvent

class AppUiExceptionHandler : BaseUiExceptionHandler() {
    override fun evaluateException(e: Throwable): OneTimeEvent? = when (e) {
        is NoConnectionException -> ShowError(ErrorKind.Network)
        else -> ShowError(ErrorKind.Unknown)
    }
}

The event carries an enum, not a message string. Turning it into localized text is a UI job, the same reasoning as the ThemeMode.label() extension in the previous post.

3. The class

abstract class BaseViewModel<VS>(
    initialUiState: VS,
    private val exceptionHandler: BaseUiExceptionHandler? = null,
) : ViewModel() {

    private val _state = MutableStateFlow(initialUiState)

    /** The UI state. Composables collect this. */
    val stateFlow: StateFlow<VS> = _state.asStateFlow()

    /** The current state, for reading inside the ViewModel. */
    val state: VS get() = _state.value

    protected fun setState(update: (VS) -> VS) {
        _state.update(update)
    }

    private val eventChannel = Channel<OneTimeEvent>(Channel.BUFFERED)

    /** One-time events. Should have a single collector. */
    val eventsFlow: Flow<OneTimeEvent> = eventChannel.receiveAsFlow()

    protected fun sendEvent(event: OneTimeEvent) {
        viewModelScope.launch { eventChannel.send(event) }
    }

    /** Collects this flow and folds each value into the UI state. */
    protected fun <T> Flow<T>.collectToState(reduce: VS.(T) -> VS): Job =
        onEach { value -> setState { it.reduce(value) } }
            .launchIn(viewModelScope)

    /** Launches in viewModelScope. Failures go to [onError], cancellation does not. */
    protected fun launch(
        onError: (Throwable) -> Unit = ::onUnhandledError,
        block: suspend CoroutineScope.() -> Unit,
    ): Job = viewModelScope.launch {
        try {
            block()
        } catch (e: CancellationException) {
            throw e
        } catch (t: Throwable) {
            onError(t)
        }
    }

    protected open fun onUnhandledError(t: Throwable) {
        val handler = exceptionHandler ?: return
        handler.handleException(t)?.let(::sendEvent)
    }
}

4. The three bugs

Bug 1: `launch` swallowed cancellation

The first version caught Throwable:

} catch (t: Throwable) {
    onError(t)
}

CancellationException is a Throwable. When the user leaves a screen, viewModelScope is cancelled and that exception is how the coroutine finds out. Catching it means the cancellation is reported as an error, and the coroutine doesn't end the way coroutines are supposed to. The fix is to rethrow it before the general catch:

} catch (e: CancellationException) {
    throw e
} catch (t: Throwable) {
    onError(t)
}

This is the most common coroutine mistake in try/catch code, and it's easy to miss because it rarely crashes. It just causes odd behavior.

Do I need to catch `CancellationException` in every ViewModel?

No. The try/catch lives once, inside launch, so call sites stay clean:

fun onChangeTheme(mode: ThemeMode) = launch {
    settingsRepository.update { it.copy(themeMode = mode) }   // no try/catch here
}

Rethrowing doesn't crash the app either. CancellationException is how coroutines signal a normal cancellation, so when it propagates out of a launch, the coroutine ends quietly. Here's what happens in each case:

What happens inside the block	Result
Normal completion	Nothing
The user leaves the screen	Rethrown, the coroutine ends silently
A real exception	Caught and sent to `onUnhandledError`, which can turn it into an event

Without the helper, a real exception in a plain viewModelScope.launch would crash the app. The helper prevents that, and the rethrow just keeps a normal screen exit from being treated as a failure.

Where you do need to care is when you write your own try/catch or runCatching around suspend calls:

// Swallows cancellation too
try { repo.refresh() } catch (e: Exception) { showError() }
runCatching { repo.refresh() }

// Rethrow cancellation first
try { repo.refresh() }
catch (e: CancellationException) { throw e }
catch (e: Exception) { showError() }

Timeouts are cancellations too. withTimeout throws a TimeoutCancellationException, which is a CancellationException, so inside launch a timeout ends the coroutine silently and shows no error. If you want to react to a timeout, use withTimeoutOrNull and handle the null.

Bug 2: `setState` launched a coroutine for no reason

// before
protected fun setState(update: (VS) -> VS) {
    viewModelScope.launch {
        _state.emit(update(state))
    }
}

This worked, but only by accident. viewModelScope runs on Dispatchers.Main.immediate, and emit on a MutableStateFlow never suspends, so the update ran immediately when called from the main thread. Called from a background dispatcher, it was deferred to Main instead. So this:

setState { it.copy(loading = true) }
if (state.loading) { ... }   // true or false, depending on where you called from

behaved differently depending on the caller's thread. MutableStateFlow.update is synchronous, thread-safe, and needs no coroutine:

// after
protected fun setState(update: (VS) -> VS) {
    _state.update(update)
}

Bug 3: `collectToState` ignored the lambda's parameter

// before
onEach { value -> setState { state.reduce(value) } }

Inside the lambda, state is the ViewModel's property, not the state the lambda receives. With the old setState the two were always the same, so it was harmless. With update it isn't, because MutableStateFlow.update retries the lambda if another thread changes the state in between, and reading the property inside it bypasses that. Use the parameter:

// after
onEach { value -> setState { it.reduce(value) } }

The reduce lambda has the state as its receiver (VS.(T) -> VS), so call sites can write copy(...) directly.

The small ones

Two properties used getters (get() = _state.asStateFlow()), which create a new wrapper on every access. That's wasteful, and it matters for events: a composable that uses LaunchedEffect(viewModel.eventsFlow) would see a different flow on every recomposition and restart the effect. Plain property initializers fix both.

5. Using it

An exception handler

class SettingsUiExceptionHandler : BaseUiExceptionHandler() {
    override fun evaluateException(e: Throwable): OneTimeEvent? {
        return null // TODO: Handle specific exceptions here
    }
}

A ViewModel

class SettingsViewModel(
    private val settingsRepository: SettingsRepository,
    settingsUiExceptionHandler: SettingsUiExceptionHandler
) : BaseViewModel<SettingsUiState>(
    SettingsUiState(settingsRepository.settings.value.themeMode),
    settingsUiExceptionHandler
) {

    init {
        settingsRepository.settings.collectToState { settingsItem ->
            copy(themeMode = settingsItem.themeMode)
        }
    }

    fun onChangeTheme(mode: ThemeMode) = launch {
        settingsRepository.update { state -> state.copy(themeMode = mode) }
    }
}

If the update throws, onUnhandledError runs and the handler gets a chance to react. This one returns null for now, so the error is tracked but nothing is shown. Returning an event (like the ShowError example in section 2) is what surfaces it in the UI. The ViewModel itself contains no error-handling code either way.

Wiring it up with Koin

singleOf(::SettingsUiExceptionHandler)
viewModelOf(::SettingsViewModel)

Collecting events in the UI

@Composable
fun <E> ObserveEvents(events: Flow<E>, onEvent: (E) -> Unit) {
    val lifecycleOwner = LocalLifecycleOwner.current
    LaunchedEffect(events, lifecycleOwner) {
        lifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
            events.collect(onEvent)
        }
    }
}

ObserveEvents(viewModel.eventsFlow) { event ->
    when (event) {
        is ShowError -> scope.launch { snackbarHostState.showSnackbar(event.kind.label()) }
    }
}

The channel buffers events while nobody collects, and repeatOnLifecycle only collects while the screen is started. An error that happens while the app is in the background therefore waits until the user returns. (label() is the same UI-layer extension pattern as the theme labels.)

6. Test the part that breaks

This class sits under every screen, so a few tests are cheap insurance. viewModelScope needs a Main dispatcher in tests:

@OptIn(ExperimentalCoroutinesApi::class)
class BaseViewModelTest {

    private class CounterViewModel(
        handler: BaseUiExceptionHandler? = null,
    ) : BaseViewModel<Int>(0, handler) {
        val reported = mutableListOf<Throwable>()

        fun increment() = setState { it + 1 }
        fun failWith(t: Throwable) = launch { throw t }

        override fun onUnhandledError(t: Throwable) {
            reported += t
            super.onUnhandledError(t)
        }
    }

    private object TestEvent : OneTimeEvent

    @BeforeTest fun setUp() = Dispatchers.setMain(UnconfinedTestDispatcher())
    @AfterTest fun tearDown() = Dispatchers.resetMain()

    @Test
    fun `concurrent setState calls do not lose updates`() = runTest {
        val vm = CounterViewModel()
        withContext(Dispatchers.Default) {
            (1..1000).map { async { vm.increment() } }.awaitAll()
        }
        assertEquals(1000, vm.stateFlow.value)
    }

    @Test
    fun `cancellation is not reported as an error`() = runTest {
        val vm = CounterViewModel()
        vm.failWith(CancellationException("screen closed"))
        assertTrue(vm.reported.isEmpty())
    }

    @Test
    fun `unhandled error becomes a one-time event`() = runTest {
        val handler = object : BaseUiExceptionHandler() {
            override fun evaluateException(e: Throwable) = TestEvent
        }
        val vm = CounterViewModel(handler)
        vm.failWith(IllegalStateException("boom"))
        assertEquals(TestEvent, vm.eventsFlow.first())
    }
}

7. Trade-offs

Channel for events, not SharedFlow or a field in the state. A channel delivers each event once and buffers while nobody listens. The cost is that it expects a single collector. State fields are replayed, so they suit "what to show" and not "what just happened".
A base class, not delegation. Inheritance keeps ViewModels short, but it's a coupling you'll feel if you ever need a different state model. For a project this size I think the trade is right, and I'd revisit it if the hierarchy grew.
Not a full MVI framework. There's no reducer, intent type or middleware. Public functions on the ViewModel are the "intents", and that's enough until a screen proves otherwise.
launch shadows the name on purpose. Inside a ViewModel, launch { } always means "with error handling". The cost is that the name hides CoroutineScope.launch in some scopes, so use viewModelScope.launch explicitly if you need the raw one.

Wrapping up

The class itself is small, but it has real traps: cancellation handling, thread-dependent state updates, and a lambda parameter that's easy to ignore. If you copy one thing from this post, make it the catch (e: CancellationException) { throw e } line, and remember that it applies to your own try/catch and runCatching around suspend calls too.

My dark mode toggle was lying to users

Ben — Fri, 09 Oct 2026 08:46:10 +0000

Persisting a light, dark or system theme in Compose Multiplatform with multiplatform-settings, Koin and StateFlow

Most dark mode tutorials store one Boolean. That works until you ask what "false" means. Is it "the user chose light" or "the user never chose anything"? With a plain boolean, a user on a dark system who never touched the setting sees a dark app and a toggle that says "off".

This post builds a small, testable settings foundation that fixes that with three states (System, Light, Dark). It's also a starting point for any other setting you add later.

What you'll get

A persisted ThemeMode that survives restarts, on Android and iOS
One source of truth exposed as a StateFlow
Safe handling of corrupted or outdated stored data
Localizable labels that don't depend on enum names
A test for the part most likely to break

Full source: Github. Note: I use a BaseViewModel with setState and a collectToState helper, which are not covered here.

1. Dependencies

We use multiplatform-settings for key-value storage and kotlinx.serialization to store the settings as one JSON blob.

# libs.versions.toml
[versions]
multiplatform-settings = "1.3.0"
kotlinx-serialization = "1.11.0"

[libraries]
multiplatform-settings = { module = "com.russhwolf:multiplatform-settings-no-arg", version.ref = "multiplatform-settings" }
multiplatform-settings-test = { module = "com.russhwolf:multiplatform-settings-test", version.ref = "multiplatform-settings" }
kotlinx-serialization-json = { module = "org.jetbrains.kotlinx:kotlinx-serialization-json", version.ref = "kotlinx-serialization" }

[plugins]
kotlin-serialization = { id = "org.jetbrains.kotlin.plugin.serialization", version.ref = "kotlin" }

// build.gradle.kts
plugins {
    alias(libs.plugins.kotlin.serialization)   // easy to forget, and the build fails without it
}

kotlin {
    sourceSets {
        commonMain.dependencies {
            implementation(libs.multiplatform.settings)
            implementation(libs.kotlinx.serialization.json)
        }
        commonTest.dependencies {
            implementation(kotlin("test"))
            implementation(libs.multiplatform.settings.test)
        }
    }
}

2. Models

The domain model is what the app uses. The local model is what we write to disk. Keeping them separate means you can change storage without touching the UI, and vice versa.

// domain/model
enum class ThemeMode { System, Light, Dark }

data class SettingsItem(
    val themeMode: ThemeMode = ThemeMode.System,
)

The local model stores the enum as a String on purpose. If you rename or remove an enum value in a later release, an old stored value won't crash decoding. It falls back to a default in the mapper:

// data/local/model
@Serializable
data class SettingsLocalItem(
    val themeMode: String = ThemeMode.System.name,
)

Because the enum's name is now a storage format, renaming a constant is a data migration. That's one more reason to keep user-facing text out of the enum (see section 6).

3. The data source: one source of truth

// data/local/source
interface SettingsLocalDataSource {
    val settingsItem: StateFlow<SettingsItem>
    suspend fun update(transform: (SettingsItem) -> SettingsItem)
}

class SettingsLocalDataSourceImpl(
    private val settings: Settings,
    private val json: Json = Json { ignoreUnknownKeys = true },
) : SettingsLocalDataSource {

    private val mutex = Mutex()
    private val _settingsItem = MutableStateFlow(read())

    override val settingsItem: StateFlow<SettingsItem> = _settingsItem.asStateFlow()

    private fun read(): SettingsItem {
        val raw = settings.getStringOrNull(KEY_SETTINGS) ?: return SettingsItem()
        return runCatching { json.decodeFromString<SettingsLocalItem>(raw) }
            .map { it.asDomainModel() }
            .getOrElse { error ->
                // Corrupt data must never crash startup, but it should leave a trace.
                // Replace println with your logger.
                println("Settings: failed to decode stored settings, using defaults: $error")
                SettingsItem()
            }
    }

    override suspend fun update(transform: (SettingsItem) -> SettingsItem) = mutex.withLock {
        val updated = transform(_settingsItem.value)
        settings.putString(KEY_SETTINGS, json.encodeToString(updated.asLocalModel()))
        _settingsItem.value = updated
    }

    private companion object {
        const val KEY_SETTINGS = "settings"
    }
}

A few decisions worth explaining:

Synchronous initial read. The state is populated when the object is created, so the first frame already has the right theme. No loading state is needed.
A mutex around read-modify-write. Two quick updates can't overwrite each other, and the stored JSON always matches the in-memory value.
transform instead of setX() methods. Adding a new setting later needs no interface change.
One JSON blob instead of one key per setting. It's simpler to evolve and migrate. The trade-off is that every update rewrites the whole blob, which is fine for a handful of small settings and wrong for large data. For that, use a database.
Settings is injected, not defaulted. That's what makes the test in section 7 possible.

4. Repository

// domain
interface SettingsRepository {
    val settings: StateFlow<SettingsItem>
    suspend fun update(transform: (SettingsItem) -> SettingsItem)
}

// data/source
class SettingsRepositoryImpl(
    private val localDataSource: SettingsLocalDataSource,
) : SettingsRepository {
    override val settings = localDataSource.settingsItem
    override suspend fun update(transform: (SettingsItem) -> SettingsItem) =
        localDataSource.update(transform)
}

No use case here, deliberately. A use case that only reads one field adds a file and a layer without adding any logic. I add use cases when there's real logic to hold, like combining sources or validating input. For simple reads, ViewModels talk to the repository directly.

6. UI

Applying the theme (app root)

class AppViewModel(
    settingsRepository: SettingsRepository,
) : BaseViewModel<AppUiState>(
    // Seeding from the current value means the first frame is already correct.
    AppUiState(themeMode = settingsRepository.settings.value.themeMode)
) {
    init {
        settingsRepository.settings
            .map { it.themeMode }
            .distinctUntilChanged()
            .collectToState { mode -> copy(themeMode = mode) }
    }
}

@Composable
private fun AppContent() {
    val viewModel: AppViewModel = koinViewModel()
    val state by viewModel.stateFlow.collectAsStateWithLifecycle()

    val darkTheme = when (state.themeMode) {
        ThemeMode.System -> isSystemInDarkTheme()
        ThemeMode.Light -> false
        ThemeMode.Dark -> true
    }

    AppTheme(darkTheme = darkTheme) {
        NavigationComponent(rememberNavController())
    }
}

collectAsStateWithLifecycle() stops collecting while the app is in the background, which collectAsState() doesn't.

Changing the theme (settings screen)

class SettingsViewModel(
    private val settingsRepository: SettingsRepository,
) : BaseViewModel<SettingsUiState>(
    SettingsUiState(themeMode = settingsRepository.settings.value.themeMode)
) {
    init {
        settingsRepository.settings.collectToState { copy(themeMode = it.themeMode) }
    }

    fun onChangeTheme(mode: ThemeMode) {
        viewModelScope.launch {
            settingsRepository.update { it.copy(themeMode = mode) }
        }
    }
}

Labels live in the UI layer

The enum's name is a code identifier, and we just made it a storage format too. Showing it to users (Text(mode.name)) can't be localized, and renaming a constant would silently change what users see. So the label lives in a UI-layer extension, with the strings in Compose Multiplatform resources:

<!-- composeResources/values/strings.xml -->
<resources>
    <string name="theme_system">System</string>
    <string name="theme_light">Light</string>
    <string name="theme_dark">Dark</string>
</resources>

// ui/settings/ThemeModeLabel.kt  (UI layer only)
@Composable
fun ThemeMode.label(): String = when (this) {
    ThemeMode.System -> stringResource(Res.string.theme_system)
    ThemeMode.Light -> stringResource(Res.string.theme_light)
    ThemeMode.Dark -> stringResource(Res.string.theme_dark)
}

SingleChoiceSegmentedButtonRow {
    ThemeMode.entries.forEachIndexed { index, mode ->
        SegmentedButton(
            selected = state.themeMode == mode,
            onClick = { onChangeTheme(mode) },
            shape = SegmentedButtonDefaults.itemShape(index, ThemeMode.entries.size),
        ) { Text(mode.label()) }
    }
}

The when is exhaustive, so adding a new mode to the domain breaks the build until the UI handles it. The selected segment always matches what the app is actually showing, because "System" is a real, visible choice.

Why there's no ThemeModeUi

The UI uses the domain enum directly. The dependency direction is correct (UI depends on domain, never the reverse), and a mirror enum would add two mapping functions without adding any information. Presentation details such as labels live in a UI-layer extension, so the domain stays free of strings and resources. A separate UI model starts to pay off when the screen needs data the domain doesn't have, like icons, formatted text or selection state. I'd use one for a list of devices, but not for a three-value enum.

7. Test the part that breaks

Storage code fails quietly, so test the failure paths. MapSettings is an in-memory Settings, so the tests run on every platform with no device.

class SettingsLocalDataSourceTest {

    @Test
    fun `defaults to System when nothing is stored`() {
        val source = SettingsLocalDataSourceImpl(MapSettings())
        assertEquals(ThemeMode.System, source.settingsItem.value.themeMode)
    }

    @Test
    fun `update persists and is read back by a new instance`() = runTest {
        val storage = MapSettings()
        SettingsLocalDataSourceImpl(storage).update { it.copy(themeMode = ThemeMode.Dark) }

        val restored = SettingsLocalDataSourceImpl(storage)
        assertEquals(ThemeMode.Dark, restored.settingsItem.value.themeMode)
    }

    @Test
    fun `corrupt JSON falls back to defaults`() {
        val storage = MapSettings().apply { putString("settings", "{not valid json") }
        val source = SettingsLocalDataSourceImpl(storage)
        assertEquals(ThemeMode.System, source.settingsItem.value.themeMode)
    }

    @Test
    fun `unknown stored theme value falls back to System`() {
        val storage = MapSettings().apply { putString("settings", """{"themeMode":"Sepia"}""") }
        val source = SettingsLocalDataSourceImpl(storage)
        assertEquals(ThemeMode.System, source.settingsItem.value.themeMode)
    }
}

Wrapping up

The result is small but solid: one source of truth, a state that can't be misrepresented, localizable labels, safe handling of bad data, and tests for the failure paths. Adding a new setting (language, units, onboarding completed) means adding a field to two models and a mapper line, with no changes to the plumbing.

DEV Community: Ben

Three bugs I found in my own BaseViewModel

1. The design

2. The events and the handler

3. The class

4. The three bugs

Bug 1: launch swallowed cancellation

Do I need to catch CancellationException in every ViewModel?

Bug 2: setState launched a coroutine for no reason

Bug 3: collectToState ignored the lambda's parameter

The small ones

5. Using it

6. Test the part that breaks

7. Trade-offs

Wrapping up

My dark mode toggle was lying to users

1. Dependencies

2. Models

3. The data source: one source of truth

4. Repository

6. UI

7. Test the part that breaks

Wrapping up

Bug 1: `launch` swallowed cancellation

Do I need to catch `CancellationException` in every ViewModel?

Bug 2: `setState` launched a coroutine for no reason

Bug 3: `collectToState` ignored the lambda's parameter