Anyone having any sample or any knowledge about how to architect multi screen app (say 30-35) in pur...

# compose

[Rooparsh]

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.

[Omar Miatello]

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

[Rooparsh]

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?

[Omar Miatello]

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

Take a look on this example (from doc):

// import androidx.hilt.navigation.compose.hiltViewModel

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

[Rooparsh]

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 ?

[Albert Chang]

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

[than_]

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 🙂, immutable state means you can use @Immutable for your state data classes.

[Rooparsh]

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

[than_]

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

[than_]

state.kt

[than_]

Untitled.kt

[than_]

Untitled.kt

[than_]

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.

[than_]

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

[Rooparsh]

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

[than_]

Untitled.cpp

[than_]

here is the actual VM implementation

[than_]

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

[than_]

no problem. enjoy 🙂

[Colton Idle]

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.

[Rooparsh]

Do let us know how the experience turns out to be. I am thinking of the same approach. @Colton Idle