:wave: was taking a look into molecule and the whole concept it brings. Its quite interesting altho...

# squarelibraries

[Marco Pierucci]

👋 was taking a look into molecule and the whole concept it brings. Its quite interesting altho Im wodnering now that you dont have AAC viewmodels how are poeple dealign with config changes? scoping and caching on the data layer?
Would be great to hear some alternatives ppl have come up with

[Benoit Quenaudon]

What's the relationship with molecule ?

[kevin.cianfarini]

Currently we’re working around this by dangling our molcule composition off of a single AAC viewmodel. I don’t like this solution but it does have the added benefit of surviving config changes for us.

Completely removing AAC viewmodel, which would be nice, requires some more custom code.

[kevin.cianfarini]

You could likely do some sort of mpp implementation of rememberSaveable for molecule but I don’t know if that’s a great idea. Just a thought.

[Marco Pierucci]

Ah interesting. I was considering hosting it a AAC and take the hit. I guess is not a terrible idea

[kevin.cianfarini]

If you can avoid using AAC it might be worth it. The only reason we do it currently is because of our investment in jetpack compose navigation which has a hard dependency on AAC VM

[saket]

I've used this in the past: https://github.com/marcellogalhardo/retained

[Daniel Perez]

I guess it's not a big issue if we're just trying to stop inheriting from ViewModel to survive configuration changes, but it looks like that's still using an AAC ViewModel under the hood, just in a clever way that retains your object using composition instead of inheritance.

[saket]

yea I'd say that's the most straightforward solution if you don't want to maintain any code yourself. some of my colleagues were exploring using dagger scopes.

[KamilH]

In the full compose app, wouldn’t it be enough to disable any configuration changes as they are handled by Compose framework?

[saket]

yep yep!

[Stylianos Gakis]

With the caveat that you can’t disable all config changes. Particularly the wallpaper change config change is the only one atm which you can not disable. And who knows if we’ll get more of those in the future 🤷

[Marco Pierucci]

Interesting, where did you find about that config change and its restriction?

[Marco Pierucci]

( FWIW we might go for disabling all config chances that we can)

[Stylianos Gakis]

I think it was this section https://developer.android.com/guide/topics/resources/runtime-changes#restrict-activity where they state that on API 32 and above there’s no way to disable “dynamic colors change”.
So your best bet is going in android:configChanges= and autocompleting all the options, but even then, you got this one exception and potentially more in the future.

[Marco Pierucci]

Yeah had a look at that yesterday, seems there are a few edge cases to consider. Thanks!