Hello, I have a very crude viewModel implementation that I use now for KMP/CMP, I cannot continue li...

# multiplatform

[Vishnu Shrikar]

Hello, 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.

[Matt Nelson]

#decompose

[Vishnu Shrikar]

This library seems to change the CMP function style to OOP... idk if that is desirable

[Matt Nelson]

CMP? Compose Multi Platform?

[Matt Nelson]

Never 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.

[Arkadii Ivanov]

If you only need Compose Multiplatform, then you can also check Decompose-Router library.

[Vishnu Shrikar]

Yes CMP is compose multiplatform, I dont think Decompose Router adds viewmodels?

[Arkadii Ivanov]

Decompose-Router has rememberOnRoute, which is equivalent to AAC ViewModels.

[Vishnu Shrikar]

what is AAC ?

[Vishnu Shrikar]

My 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

[Arkadii Ivanov]

So 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

[Vishnu Shrikar]

So from this, it seems that if i dont care about lifecycle awareness I dont need viewmodel?

[Arkadii Ivanov]

In 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.

[Vishnu Shrikar]

I 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]

Because of how useless viewmodels are, is there an alternative to MVVM that is recommended for architecture?

[Arkadii Ivanov]

I 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]

If 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.

[Vishnu Shrikar]

That 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