It s interesting that there seem to be a lot of ways to mana kotlinlang #compose

annotation) don't resonate that much with me. I like the unidirectional flow with MVVM and live data. I'm considering implementing MVI like described here https://medium.com/swlh/android-mvi-with-jetpack-compose-b0890f5156ac but without the "innovation" of letting the state to directly create the Compose views. I'd let the fragment create those in response to the state. Are there any problems with this approach?

Specifically I wonder whether not using

MutableState

@Model

but instead pushing down immutable objects with all the state will turn off optimizations or something?

Adam Powell

07/11/2020, 7:19 PM

If the objects are marked

@Immutable

then they will be compared to previous parameter values and a composable function call will be skipped if the parameters are stable and equal

(immutable being a stronger form of stable here)

iex

07/11/2020, 8:48 PM

good to know! The article doesn't mention this

thanks

Leland Richardson [G]

07/11/2020, 9:55 PM

we are still playing around with some ways to infer immutability via whole program analysis potentially (or other means) and so haven’t spoken loudly about the @Immutable annotation so far as it may become unnecessary at some point

but as adam mentions, the compiler will use the @Immutable contract to make optimizations. Compose very much likes immutable objects wherever possible. The MutableState object just creates a single point of mutation that compose can deal with properly (with some useful guarantees that MutableState provides you) since most applications will need to have a point of mutation somewhere as state changes over time

iex

07/12/2020, 4:22 PM

thanks again for all the infos!

3 Views