Why some people still use viewmodel in jetpack compose?

Question

I watch some tutorial projects on YouTube and some of them make viewmodel file and write some bunch of code, just to use viewmodel!

We have remember and rememberSavable and state and recomposition and ... in jetpack compose. so why still some people use viewmodel?! it's some more code and makes the project more difficult to understand for we beginners.

I guess they learned viewmodel for XML hardly and they can't just forget about it!

isn't it possible in jetpack compose to write the code in a way that we don't need to use viewmodel anyway?

Claus

Answer 1

ViewModels are still useful for passing data between screens or changing a Composable from another like in xml.

Let's say you have a Cart composable you wish to change TopAppBar from or other Composables that are not related to each other but changes TopAppbar color or text. You can use a shared ViewModel to set from various places and listen for mutableState inside TopAppBar composable.

Also, remember is for storing Data through recomposition, rememberSaveable adds configuration changes on top of remember. When you move to next screen and come back if your Composable is not in composition these will be reinstantiated but you can keep data in ViewModel as long as your apps alive. You can use ViewModel in various ways.

Last but not least, remember makes your Composables stateful, instead of this using state-hositing makes your Composable easier to maintain.

If you build layers top of stateful Composables you increase permutation of states your Composable go into when any MutableState in child or parent changes.

It might be difficult to track state changes from parent to child. I sometimes have this issue when i have Modifier.pointerInput(keys) with state not changing as expected.

In my opinion state management is one of the most difficult aspects of Compose. Because of this the less stateful Composables you have easier it's to manage your Composable's internal changes

Chaparro

Answer 2

The recommendation to use ViewModel is still there, because we should have calculations in ViewModel as much as possible, except for those that require calculations in pixel space.

On the other hand, we have to use ViewModel to call Domain layer specefic interfaces method.

It is recommended that our presentation layer logic and code not depend on Compose or XML.

It is also logical to use ViewModel for testing purpose

Oppose

Answer 3

It's very important to keep separation of concerns in mind when developing all but the most trivial of apps.

We've always had the ability to put all of our code in one place - early Android development was often just chucking all our code in one monolithic activity. This created nightmares for code complexity, maintenance/support and enhancements.

Putting everything into compose would basically be regressing to those early dark days. ViewModels (and Presenters/Controllers/Coordinators/etc) force you to architect your app in such a way that the principle of SoC is adhered to. Your VMs contain the data that your screen cares about, your controller classes contain non-view-related screen logics, etc.

SoC is extremely important - I think the most thorough way to learn how important it is is to ignore it and then have to suffer through your decision as you have to deal with your code in the future! But if you're happy to side-step that painful part of your career then learn from those who came before you.

Vulcanize

Where should we use rememberSaveable then if every state could be stored in ViewModels? What about 2+ ViewModels in 1 Composable? – Metaphrast

SoC doesn't mean all state has to live in one specific place - any concern can keep its own state. It's expected in Android apps that View concerns will have their own internal states. Consider TextView (or TextField in compose), they need to track things like cursor location, selection, whether the editing handle is shown, the editing menu itself, how to update its own internal text when pasting cutting etc. If the developer had to handle all of this for every TextField that'd be a huge overhead, or had to track whether a button is "pressed in" on the down click, etc. – Vulcanize

Likewise for the model layer classes. A data store could have its own internal state tracking whether there is cached information, you wouldn't expect any other class to know this info. Holding state is not unique to the VM layer. So feel free to save UI-specific state in your View. Knowing when to defer to VM/presenters/etc is somewhat an art and you'll get a good idea of what you can and cannot leave in View land as you gain XP – Vulcanize