A Compose state of mind: Using Jetpack Compose's automatic state observation
Why Stack Overflow recommends it
Stack Overflow users link it when answering Compose questions about state not updating the UI, remembering objects across recompositions, and where to hold state.
Recommended by 3 people across 3 different months, 2022 to 2022.
What it is
A 21-minute Android Dev Summit 2021 session by Manuel Vicente Vivo of Google's Android team on how Jetpack Compose observes state automatically and recomposes the UI. It covers the Composition, when to hoist state, state holders versus ViewModels, and safely mutating state from outside the Composition.
What people said
Recommends Phil Dukhov · 2022-05 · Stack Overflow · on “Compose not refreshing view on change of mutableStateOf value”
state should be declared as `mutableStateOf(State())`, you can use it with delegation. Check out this video [this video] for details
Recommends z.g.y · 2022-06 · Stack Overflow · on “What is the best way to persist state in composable recreation in Jetpack Compose?”
It depends on the scope of how you want to recreate or restore a state, you can either hoist it in a viewmodel where a state is dependent on its lifecycle, or inside a rememberSaveable where you have to define a Saver for it to save and restore the state. So far, I only consider using rememberSaveable when I only want to survive and restore states during configuration changes ( i.e light to dark, screen rotate ), on the other hand, I hoist states via ViewModel when functionalities of a composable depends on much deeper functionalities ( i.e repository/network calls, heavy business use-cases ) Also Both of the implementation will trigger the entire re-composition of RootComposable as it obser
Recommends Ma3x · 2022-07 · Stack Overflow · on “Making network call to receive image and show it when location access has been granted”
This line val locationLiveData = LocationLiveData(context) creates a new LocationLiveData instance on every recomposition. You have to remember the same instance of LocationLiveData across recompositions, if you want it to hold any state or view state. Change it to // remember LocationLiveData across recompositions // this does not survive configuration changes, nor other short Activity restarts val locationLiveData = remember { LocationLiveData(context) } As also mentioned in the code comment above, now locationLiveData will survive re-compositions, but it will still get reset on: every configuration change (examples include but are not limited to: orientation change, light/dark mode change
Cites Ma3x · 2022-07 · Stack Overflow · on “When I change ViewModel var, Composable Doesn't Update in Kotlin + Compose”
Part 1: Obtaining a ViewModel correctly On the marked line below you are setting your view model to a new ProfileViewModel instance on every recomposition of your Menu composable, which means your view model (and any state tracked by it) will reset on every recomposition. That prevents your view model to act as a view state holder. @Composable fun Menu(user: FirebaseUser) { val context = LocalContext.current val ProfileVModel = ProfileViewModel() // <-- view model resets on every recomposition // ... } You can fix this by always obtaining your ViewModel s from the ViewModelStore . In that way the ViewModel will have the correct owner (correct lifecycle owner) and thus the correct lifecycle.
Cites Ma3x · 2022-07 · Stack Overflow · on “How to update my composable upon service property update?”
In your code snippet on this line var loggedInUser: User? by remember { mutableStateOf(auth.user) } you are creating an instance of MutableState<User?> with an initial value of the value that is at that time referenced by auth.user . Due to remember { } this initialization happens only when the composable ContentView enters composition and then the MutableState instance is remembered across recompositions and reused. If you later change the variable auth.user no recomposition will happen, because the value stored in loggedInUser (in the mutable state) has not changed. The documentation for mutableStateOf explains what this call actually does behind the scenes Return a new MutableState initia