Can we summarize which are the main advantages of ...

# compose

[Daniele B]

Can we summarize which are the main advantages of using an AAC ViewModel in a Compose app?
This is an Android Compose app, which doesn’t use the AAC ViewModel and stores its custom model (with data tree and event functions) in the Application. It seems to work with no issues.

class MyApp : Application() {

    lateinit var model: MyCustomModel

    override fun onCreate() {
        super.onCreate()
        model = MyCustomModel.Factory.get(this)
    }
}


class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val model = (application as MyApp).model
        setContent {
            MyMaterialTheme {
                MainComposable(model)
            }
        }
    }
}

[CLOVIS]

No: https://twitter.com/JimSproch/status/1454620401934364679?s=20

[CLOVIS]

(Jim Sproch is the creator of Compose)

[Daniele B]

@CLOVIS I am fully aware of Jim’s approach, and indeed I support it. But Android still officially promotes the AAC ViewModel for Compose, so I wanted to hear the thoughts of some of the people who think differently.

[Albert Chang]

If your view model lives throughout application lifecycle, surely you can do that, otherwise AAC view model allows you to tie it to the lifecycle of a part of UI.
(As Jim said you don't necessarily need AAC view model to achieve that though.)

[Daniele B]

I posted a simplified version.
In the complete version, the Application actually observes the lifecycle, triggering some funtions on Lifecycle change events:
https://github.com/dbaroncelli/D-KMP-sample/blob/main/androidApp/src/main/java/eu/baroncelli/dkmpsample/android/App.kt

[Albert Chang]

I'm not talking about on start or on stop. I mean all your view models will be in memory throughout the application life, which is a huge waste of memory in a complicated app.

[Daniele B]

the model actually decides to keep in memory only the states of the screen which are in the backstack: it discards all others

[Daniele B]

I guess the need for a multiplatform model will become even more evident with Kotlin/Wasm, as you could reuse for the Web all composables already defined for Android (and/or Desktop)

[Albert Chang]

So basically you are building the infrastructure (navigation / view model) yourself. To make a real world usable framework there are still some missing bits, such as state saving/restoration for process death and deep link handling. So what I recommend and what most people will do, is to just use a popular framework, and AAC ViewModel is one of the choices. There are also some multiplatform frameworks.

[Daniele B]

Yes, I am experimenting a multiplatform framework, that’s why I am interested in fully understanding the reasons of those who cannot imagine Compose without the AAC ViewModel.
Process death is probably one of the things that AAC ViewModel can handle out of the box, but I guess this could be solved by wrapping the multiplatform viewmodel inside one AAC ViewModel just for Android, or other possible approaches that would be interesting to discuss with other Compose MPP devs.

[Colton Idle]

main advantage? in my opinion, the main advantage is that its a popular and supported thing and so doing things like hilt + compose + navigation all work pretty damn well together. plus you can now pretty easily have different scopes that make sense. like a scope for a compose "destination"/screen and you can also have a few screens using a single VM for a nice shared scope.

Long term, just like live data, i think we'll see VMs not used more and more in pure compose apps and eventually google will probably stop promoting them. i think that is like 5 years out though. lol /remindme 5 years

[Colton Idle]

of course i think if you use some other stuff like square/cashapp molecule lib or slacks circuit library, you can probably not use VMs even sooner.

[Colton Idle]

also. compose can inherently work without an AAC VM... just see #compose-desktop 😅

[Daniele B]

I am researching on architectures that allow apps to be easily ported to different platforms: for this reason I am also avoiding Hilt and Jetpack Navigation. I expect Compose Multiplatform to be big already in 2 years time, thanks mainly to Kotlin/Wasm.

[Ash]

The DI (Hilt) helps with testing with fakes ... right? That is how we use it ...

[enighma]

The main reason to use an AVM is to keep state alive between configuration changes. A good example: Your VM is fetching data from your backend and your device orientation changes. Without a AVM you will drop your network call and have to do it again.

There's not way to keep that network call alive without something like an AVM.

If you want to solve it for a MPP scenario then I would make the VM an AVM on Android and just a regular class on other platforms. I've shared an example of how that could look before. Let me know if you want to see it.