hi all, any reason on why common ViewModel put as ...
# multiplatform
m
hi all, any reason on why common ViewModel put as part of Compose Multiplatform on docs (and the artifact)? Is it expected to use common ViewModel only on Compose multiplatform app or is just documentation thingy? About to try to migrate our multiplatform (not compose multiplatform) app to use common ViewModel but have a stepback since I don't want to waste efforts to migrate when turns out its only works for Compose multiplatform app
m
yes it not stable and many problem it. work only android side and not proper work ios and desktop . i try it i have two screen. one screen move to second screen after i back to main screen it refresh i mean viewmodel recreate so do not migrate common viewmodel
i
You can use ViewModel without Compose, but in this case you need to take care of Lifecycle of it yourself by defining ViewModelOwner. @Meet this case works just fine. Currently we have 0 issues regarding ViewModel in our issue tracker, so statement like "many problems" is at least questionable. Regarding behavior itself - lifetime of VM is defined by its owner. It's provided for each back stack entry in adopted multiplatform androidx navigation. On Android it's implemented by "support" library wrappers. If your case is different and your app manages pages differently (without talking care of it) it kinda expected and not an issue in VM itself
👍 1
m
sorry for that. @Ivan Matkov can you share me some code with navigation and viewmodel
i
any reason on why common ViewModel put as part of Compose Multiplatform on docs (and the artifact)?
Artifact has the same name as Android one. Documentation is about Compose binding because androidx.* packages were adopted by Compose Multiplatform team and Compose is considered as a main use case. However, there are non compose modules, so the VM itself (not that compose package) can be used without Compose
m
Artifact has the same name as Android one. Documentation is about Compose binding because androidx.* ...
aha, that explain everything. so basically this just artifact naming thingy and doesn't mean it only usable on Android/Compose app only right?
i
Ah and one more note. If you do not need to Compose or Web - you can just use Google's artifact without JB wrapper. It's published for desktop and iOS, PS JB wrapper will redirect on Google's one on all platforms where it's possible to avoid any conflicts, so you will use the same binary anyway
androidx.* is a base package for Google Jetpack components (VM is one if it). Some of this libraries were adopted to multiplatform, with the same API/packages
doesn't mean it only usable on Android/Compose app only right?
You need a package without "-compose" for this case
m
gotcha, thanks for the explanation!
👍 1