Hey, people. My team and I are working on a greenfield project, built from the ground up using compose and MVVM. It was fine and dandy until the VMs started to grow for more complex screens. We got around it by extracting logic away from the VMs, which helped us to keep the classes in check, however, they still need to take a large number of dependencies (use cases, etc.). We would like to improve this part as well as it still feels like the VMs are trying to do too many things. I wonder if anyone has experimented with screens with multiple VMs (e.g. some larger comosables, which are not ‘screens’, having dedicated VMs)? Do you have any experiences to share with this kind of approach or can see why this might not work? How do you deal with the problem of growing VMs in your projects, especially when working with compose?

I do have some "screens" which have multiple VMs. For example we're using a non-standard bottom navigation where the bottom nav is not present in all screens. So on the screens where it is present, I have

@Composable fun FooScreen(fooViewModel: FooViewModel, bottomNavViewModel: BottomNavViewModel)

.

Thanks for sharing, good to know we are not the only ones facing those obstacles and toying with those ideas 😄 Reusability of the VMs, for components that are shared between the screens, like the bottom sheet in your example, is something we are after as well. We plan to experiment with creating smaller VMs for some of our composables which we think fit the criteria of being fairly independent and reusable, but complex enough to justify having dedicated VMs. Let’s hope for the best 😄

Its possible to create independent controller class or whatever name is more suitable for you, they are jus plain kotlin classes that exposes estate as flow and update these states.

//Instead of
viewmodel.state.collectAsState
viewmodel.doSomething
// would be somethinslg like this
viemodel.myIndependentController.state.collectaAsState
viewmodel.myIndependentController.doSomethins

This is a suggestion of use though if you prefer to hide that from the ui you could delegate the calls to the controllers or maybe have some sorte of sealed classes for representing distinct actions that are handled by especific controllers.

Thanks for this interesting discussion. Maybe it is my naiv way of thinking, I only pass state and call back to the screen, rather not view model, to avoid recomposition. I also keep the view model as small as possible, and let the activity class or an additional activity state class implementing controller logic to transfer flow state rather than put the controller to the vm.

@Yingding Wang do you have one activity per screen? Then your solution might make sense (although I don't see how making your activity a source of truth might scale well). I'm following a single activity, no fragment approach. The activity hardly has any code at all beyond

setContent {MyTopLevelComposable()}

@curioustechizen I divided my mobile application to feature groups per activity. And each activity has multiple screens. I either use NavHost or PagerScreen, sometimes also my own controller logic to set the overlay screens on different activities. I use deepLink to move back and forth. I think i put some effort into design the feature groups and also navi structure to have fine control. I moved away from single activity, it also allows me to offload the workload of UI into second process if necessary, sometimes also background/forground process, or coroutine work into second process. I think in most case you don’t need a second process, but sometimes I need some more to compute real time IoT data sequence.

Please forgive the own-horn-tooting, but you might find this talk helpful: https://www.droidcon.com/2022/09/29/navigation-and-dependency-injection-in-compose/