Hello, I have a very crude viewModel implementatio...
# multiplatformv
Vishnu Shrikar
10/13/2023, 11:14 PMHello, I have a very crude viewModel implementation that I use now for KMP/CMP, I cannot continue like this and need a framework, I would like one that is easy to use but still featured enough to use for most situations.
m
Matt Nelson
10/14/2023, 6:00 AM#decompose
v
Vishnu Shrikar
10/14/2023, 6:38 AMThis library seems to change the CMP function style to OOP... idk if that is desirable
m
Matt Nelson
10/14/2023, 7:51 AMCMP? Compose Multi Platform?
Matt Nelson
10/14/2023, 7:52 AMNever the less, to each their own. A lot of wonderful things happen when you rid yourself of ViewModel, and elevate state and business logic out of composables and into components.
decompose 1
a
Arkadii Ivanov
10/14/2023, 9:48 AMIf you only need Compose Multiplatform, then you can also check Decompose-Router library.
v
Vishnu Shrikar
10/14/2023, 10:08 PMYes CMP is compose multiplatform, I dont think Decompose Router adds viewmodels?
a
Arkadii Ivanov
10/14/2023, 10:47 PMDecompose-Router has
rememberOnRoutev
Vishnu Shrikar
10/14/2023, 10:48 PMwhat is AAC ?
Vishnu Shrikar
10/14/2023, 10:49 PMMy primary concern is not the backstack or memory but rather seperation of concerns where I want to seperate my database calls from the view itself
a
Arkadii Ivanov
10/14/2023, 11:18 PMSo both libraries, Decompose and Decompose-Router, allow separation of concerns. The former takes everything (business logic, data layer, navigation logic) out of Compose (UI). The latter manages navigation inside Compose (similar to the official navigation-compose but type-safe).
AAC ViewModel states for https://developer.android.com/topic/libraries/architecture/viewmodel
v
Vishnu Shrikar
10/14/2023, 11:52 PMSo from this, it seems that if i dont care about lifecycle awareness I dont need viewmodel?
a
Arkadii Ivanov
10/15/2023, 8:26 AMIn the classic Compose navigation, ViewModels have two purposes: to survive configuration changes on Android, and to stay alive while the corresponding screen is in the stack.
When a screen goes into the back stack, the screen's Composable function destroys, but the VM stays.
Decompose-Router brings this behaviour via rememberOnRoute. Decompose has a bit different story.
v
Vishnu Shrikar
10/16/2023, 2:42 PMI see, so the decompose router can manage the back stack. My application does not yet support the backstack as it will have alternative navigation because its multiplatform. When the backstack support is added it is good to see the decompose router will help there. This is probably a horrible way of doing so but I use databases for persistence. I do not have settings support yet but due to the amount of DB work in the app, it may be more straightforward to store them in a db... old school. Because of this DB behaviour, any "remembered" state can be reconstructed. Hopefully screen resize on android is similar to desktop where my recomposition works.
Vishnu Shrikar
10/16/2023, 2:43 PMBecause of how useless viewmodels are, is there an alternative to MVVM that is recommended for architecture?
a
Arkadii Ivanov
10/16/2023, 5:43 PMI think if you don't need the back stack yet, then you can just create a simple expect/actual ViewModel class and on Android typealias it to AndroidX ViewModel for surviving configuration changes.
If later you create your own stack library, then you will have to handle ViewModel scoping on your own. As well as saving and restoring the UI state. E.g. when you scroll a list, then open a clicked item details screen, then go back to the list screen, the scroll position should stay the same. By default it will reset, navigation libraries have special code for UI state preservation.
Arkadii Ivanov
10/16/2023, 5:44 PMIf for some reason you don't care about configuration changes, then a simple ViewModel class would work. But keep in mind that the Android can kill your app pretty quickly while in background or perhaps while taking a photo. So most likely you will have to preserve the navigation state.
v
Vishnu Shrikar
10/16/2023, 9:05 PMThat makes sense thanks, I have forground services for anything that is long running and consistent. I could see if I can write to settings to get rid of battery restrictions but every device does it different so probably more work than its worth. My configuration is stored to a database so all changes are persisted.
The navigation part interests me though, I will have to look into that as the app becomes more polished.
Of course it is mobile phones that cause all the problems. For a so called "simplified" system, I find the phones to cause more problems than the desktop
👍 1
5 Views