I am seeing some problems if a LiveData is updated in quick succession from a coroutine with postVal...

# compose

[Andy Himberger]

I am seeing some problems if a LiveData is updated in quick succession from a coroutine with postValue, that the compose observers are not always updated with the final value.
If I insert a delay everything does work, its also odd because I am using the same Composable twice in my tree and one of them updates and the other doesn't, all of this seems more likely to happen (keeping old state) when the children are more expensive to update. It feels like if you have 2 updates, and the 2nd update comes in before the first one has completed recomposition, that first one when it ends is saving its state as if it did consume the update. (More in reply)

[Andy Himberger]

For a full story of what I'm doing:
• I have a ViewModel with LiveData that holds the state of the last time the androidx.window library has told us of an update to window properties (to get foldable state information). We're using LiveData as this viewmodel is consumed by some legacy code not in compose
• On the compose side we observeAsState this window information, and do have some visual differences based on this object which has some additional properties we could compute separately but its convenient to have them together (like window orientation)
• The androidx.window library sends multiple updates in quick succession when you change orientation of the device on devices like the Samsung Fold, it tells you once some generic information, then quickly in a second update it gives you correct information about the foldable display properties. Its not easy to just discard the first update since you don't know if another is going to come.
in end it seems like there is a recompose timing / versioning flaw here, any suggestions or known issue which such a pattern? I still haven't seen any of the samples use the androidx.window windowLayoutInfo async APIs (well they briefly did and they were quickly removed to use synchronous alternatives, not sure if they hit bugs like this or just didn't like the flicker that this library kind of pushes on you)

I tried using StateFlow instead of LiveData, same issue occurs (actually seems like it happens a bit more often with StateFlow)

[Colton Idle]

I don't know the answer to your question, but I think i remember reading that LiveData doesn't have true backpressure support and so maybe that's the cause of this? You could go for an observable that does support it... like Flow? i dont want to mislead you (as im no expert in livedata, rx, flow, snapshot state) but I do feel like i remember seeing a conference talk about this sorta thing.

[Andy Himberger]

I did try converting it over to StateFlow, which didn't help.

[Abhishek Dewan]

with state flow atleast if the value being updated is the same as the value inside of the state flow then it won’t push an update to the observer

[Andy Himberger]

Yeah I suppose thats a thing though we always use a helper that looks for differences before updating livedata.

Back on the original issue, I also tried removing the LiveData and just using mutableState, that didn't help either

[Colton Idle]

If you post the question here using mutableState you might be able to get help from some of the googlers as im sure theyre interested in knowing why mutableState cant keep up with your changes and they might give you a good alt solution

[Andy Himberger]

You're saying repost so its 'new' with mutableState in the first message, I can do that in a bit, I was thinking about making a standalone project showing it

[Colton Idle]

I think someone should be able to figure it out here without an entire project if you post a new question but show an example using mutableState*, yes.