A modern programming language that makes developers happier.

kotlinlang

Anyone having any sample or any knowledge about how to architect multi screen app (say 30-35) in pure jetpack Compose with MVVM?

Do you guys use single activity and single viewmodel and handle it there only? Or you prefer creating multiple activities or fragments?.

The question is related to how to properly architect the MVVM based Compose app.

You could have a single activity and multiple viewmodels. The guidelines currently suggest <https://developer.android.com/jetpack/compose/navigation>
Also take a look on this:
<https://developer.android.com/jetpack/compose/libraries#hilt-navigation>
ViewModels can be scoped to the navigation graph

So all these viewmodels will be retained in the memory as long the activity is not destroyed? Even though lets say I popped up to from screen 32 to screen 1?

no, if you choose `hiltViewModel()`  the ViewModel is retained only inside your current screen.

Take a look on this example (from <https://developer.android.com/jetpack/compose/libraries#hilt-navigation|doc>):
```// import androidx.hilt.navigation.compose.hiltViewModel

@Composable
fun MyApp() {
    NavHost(navController, startDestination = startRoute) {
        composable("example") { backStackEntry -&gt;
            // Creates a ViewModel from the current BackStackEntry
            // Available in the androidx.hilt:hilt-navigation-compose artifact
            val exampleViewModel = hiltViewModel&lt;ExampleViewModel&gt;()
            ExampleScreen(exampleViewModel)
        }
        /* ... */
    }
}```

Ohh, so hilt is the defacto for compose?
But then, what if I don’t want DI or I want to use another DI tool ?

<https://kotlinlang.slack.com/archives/CJLTWPH7S/p1621438922239900?thread_ts=1621436989.236100&amp;cid=CJLTWPH7S>

We have a single VM with deeply immutable state (for deep "mutation" convenience we use arrow-kt optics). It solves problem of sharing data between VMs quite nicely :slightly_smiling_face:, immutable state means you can use `@Immutable` for your state data classes.

<@U3JKPCBLM>  Isn't it making your Single ViewModel bloat? Would love to see your code if it's public!

Not really. Can't really share anything big, but I can share something small, but done the same way.

state.kt

Untitled.kt

this is state modification (no side effects here). We have a state object which is 'modified' only by the reducer. What type of modification is performed is based on an Action which also carries required arguments.

since you can have sealed classes within sealed classes, you can clearly split the reducer to multiple functions, so no bloat here

Thanks so much Jan. Will definitely go through your code and try a small demo.

Untitled.cpp

now for anything you just do `vm.dispatch(Action.SomeAction(someArgument))`

no problem. enjoy :slightly_smiling_face:

I'm basically building my apps to be single activity and multiple composables as "pages". I will have a single VM for my activity and a VM for each composable "page".

My VMs will not be android archictecture component VMs though because in a fully compose app AAC VMs are not needed.

Do let us know how the experience turns out to be. I am thinking of the same approach. <@UN85K2RQR>