Does anyone know how exactly `koin-androidx-compos...
# koin
v
Does anyone know how exactly
koin-androidx-compose
hooks compose UI with the ViewModelStore to notify it that the composable is disposed so viewModel should be removed from the store? I am having the weird situation, when I just remove from the composition a screen, I can see that the
DisposableEffect
triggers its onDispose, but the view model is not cleared. And when the screen returns into the composition - the same instance of the view model is provided. Although I don't scope it to activity or anything. Just using bare
org.koin.androidx.compose.getViewModel()
. So in practice we have a composable screen with its viewmodel. It triggers API and gets 401. The not authenticated state delivered and this screen just goes out of the composition via if(logged) and Login screen is the only screen in the composition. And then we close the login, and re-create the initial screen - it gets old view model instance. And the more weird part is that if I just close the screen via back button (having Voyager for navigation), the view model does get cleared. Any hints?
As I investigated I see that by default koin's
koinViewModel()
gets Activity's ViewModelStore, so basically scoped to activity. And since the activity never changes - the view models don't die if their screens out of the composition. So I need somehow my composable functions, which I treat as "Screen" to have their own ViewModelStore?!
s
You should probably use some compose navigation library (the one from google, or Voyager, or Decompose, or any of the others) which give you something to scope your viewModels+UI to.
a
Seems that ViewModel is scope is perhaps larger than you are looking in terms of scope
koinViewModel
is based on Android API and then, all the lifecycle plumbing. Did you try to inject just a
factory
instance?
v
No, do you have an example to check?
a
just change your instance to a "normal" compoennt and declare it as
factory
. use
koinInject
instead of
koinViewModel
v
Oh you mean to not count the ViewModel as androidx.ViewModel and to not instantiate it through the androdx factories?
But in that case, without having a store, it will be reset on config changes
a
yes, but it drop with composable drop
else it follow current activity lifecycle
v
But the only(main) point of the androidx VM to persist config change 🙂
a
if you need to persist changes, you have other solutions
=> remembersaveable
v
rememberSaveble some dataLoad()?
a
🤷 check the android doc