How to reset view models?

[ivnsch]

Hi,

I added functionality to restore local database backups (sqldelight).

When restoring, I close the old db driver, re-create it.. but the viewmodels are likely keeping a reference to the old db alive, via observers, e.g:

  init {
        viewModelScope.launch {
            milestonesDao.milestone(milestoneId)
                .mapLeft { it.toUiError() }
                .collectHandling(_error) {
                    _milestone.value = toUiMilestone(it)
                }
        }
}

with dao:

private val milestoneQueries get() = database.milestoneQueries
override fun milestone(id: MilestoneId): Flow<Either<FetchMilestoneDaoError, Milestone>> = ...

java.lang.IllegalStateException: attempt to re-open an already-closed object: SQLiteDatabase: /data/user/0/foo/databases/db.db), msg: UiErrorMsg(msg=Unknown error, debugInfos=java.lang.IllegalStateException: attempt to re-open an already-closed object: SQLiteDatabase: /data/user/0/foo/databases/db.db)

So I figured, I'd like to tear down and recreate all the view models? but not succeeding so far.

I defined a scope

scope(named("viewmodels")) { .. }

and then

koin.getScopeOrNull("viewmodels")?.close()

but e.g. this on viewmodels is never called

override fun onCleared() {
    super.onCleared()
    log.w { "viewmodel cleared: ${this.hashCode()}" }
}

and error persists.

there's also e.g.

(koin.get<Activity>() as? MainActivity)?.viewModelStore?.clear()

but not sure this is what I should use and how to combine with the view models management by koin?

Maybe I'm entirely off track and I need a different approach to solve this, any advice appreciated!

[samyak2403]

To "reset" ViewModels in Koin after a major data event like a database restoration, I'd suggest these two approaches:

Approach A: Reactive UI (Preferred)

If your Repository exposes data as a Flow or LiveData directly from Room, you typically don't need to reset the ViewModel. Room's invalidation tracker will automatically emit the new data to the Flow as soon as the database is updated, and your ViewModel will reflect the change instantly.

Approach B: Custom Koin Scopes

If you need to force-recreate the ViewModel instances, you can define them within a custom Koin Scope. This allows you to close and re-open the scope, which wipes the cached instances.

Approach 1: Define the Scope

val myModule = module {
    scope<MySessionScope> {
        viewModel { MyViewModel(get()) }
    }
}

Approach 2: Reset Logic
When the restore is complete, close the existing scope. The next time you call getScope(), a fresh ViewModel will be injected.

getKoin().getScopeOrNull("session_id")?.close()
val newScope = getKoin().createScope("session_id", named<MySessionScope>())

[Alox1d]

There are two different lifetimes involved here: the Koin scope that resolves dependencies, and the AndroidX ViewModelStore that retains the ViewModel.

Closing a Koin scope does not, by itself, clear the owner's ViewModelStore or call ViewModel.onCleared(). In Koin's ViewModel resolution code, the model comes from ViewModelProvider.create(viewModelStore, factory, extras). The store can therefore return the existing model even after you change its Koin dependencies. Scope.close() closes Koin's scope, not that AndroidX store.

Also, scope(named("viewmodels")) { ... } declares a scope qualifier. getScopeOrNull("viewmodels") looks up a runtime scope ID. Those strings only identify the same scope if you explicitly created it with that ID.

For this database-replacement case, I would make restoration an explicit application transition:

1. Stop and await database work/collectors that use the old driver.
2. Leave the UI owners that hold those ViewModels, so their stores can be cleared. For navigation-scoped models, remove the relevant back-stack entries; clearing only the Activity's store does not clear every Fragment or navigation-entry store.
3. Close the old driver, restore the database, and build a new driver and the repository/DAO objects that capture it.
4. Re-enter the screens with fresh owners and resolve their models against the new dependencies.

Calling the correct owner's viewModelStore.clear() does invoke the clearing lifecycle (AndroidX documentation). However, it does not replace references already held in a screen, a by viewModel() lazy delegate, or another object. Use it as part of a controlled teardown/recreation, rather than clearing the store underneath an actively running screen. An ordinary configuration recreation also retains ViewModels, so Activity.recreate() alone is not a reliable reset.

The Room invalidation suggestion above doesn't apply to replacing your SQLDelight driver: an existing query flow is still associated with its old query/driver objects. A getter such as database.milestoneQueries won't make an already-created flow switch to a newly constructed database.

I checked the Koin implementation linked above; I haven't run your app's restore sequence. The key thing to inspect is the actual ViewModelStoreOwner used by each affected model, plus whether the injected DAO/repository still captures the old database.