so some debouncing is happening at a higher layer already

TextView#setText has some cost associated with it but not one you're likely to see a lot of in most cases.

Or to put it another way, have you measured a problem with this approach so far? 🙂

whole issue basically is if written to room it will emit later than suspend function which writes it, returns

tldr; writing to db is sideffect, and that messes up the whole flow

here updateCompleteLiveData will be true, but the itemLiveData will still contain item where item.activated == false for a brief moment

you might notice that in the logs of the original question

something like this, whereas Fragment reacts to activationLiveData by showing toasts for example, and to itemLiveData refeshing the recycler view or somethimg

issue is: there is point in time when itemLiveData contains item which item.activated == false, while activationLiveData already contains success

er, pretend I tacked a,

.asLiveData()

on the end of that 🙂

however imagine there will be Loading and error states to it as well viewModelScope.launch { activationLiveData.set = Loading activate() activationLiveData.set = Success }

I could model this as a column in the db as you said, but, then I have the burden of clearing the transient states on app start, as they are now persistent, and im not sure if this is so great for every such use case as it is very common,.. or is it?

using the db as the source of truth is one way, another would be to route other reads of db changes through some sort of repository object that muxes together your other in-memory signals

and then zip/combineLatest as appropriate, or what have you

if this idea of, "activated" isn't present in the db itself, then it doesn't much matter if other parts of the system see implementation detail db changes along the way as long as any decisions they might make at any snapshot are valid/consistent

and if those db changes are intended to be implementation details that don't get leaked, you need some sort of filter/serialization construct in front of other things that read it

is it a problem, or is it just a quirk of the data flow?

after the 1ms or whenever io scheduler desires it will emit new db item with activated=true reflected and then its all good

IO latency can go way up on some devices under load or on low-end devices with slow flash parts

since now it anonymous. If I knew that, then I could combineLatest safely

I could just pull the query not push but then whole modern approach is a bust

there have also been a number of other changes to android animation systems to better handle interruption/new targets of the animation

but how can I tell which is valid at the subscriber level? its not always clear, and also the debounce-and-pray can be broken based on business of io as you said

which means you can't permit anything but this code that does this consistency enforcement to hand out a

Flow

of your raw observed db changes

you might take a look at how things like https://github.com/dropbox/Store address cases like this

I remember, it was pagination in chat, were user could delete a message

so I couldnt just assume if next emit contains more messages = pagination happened

in this case is not invalid "as much" but there still exists a point in time, where old list is shown without a progressbar at the end (since paginationState==Finished, and db items are still old since io didnt emit yet), which doesnt make sense; and also its a pointless adapter notify call/list diffing just to be interuppted intederminate few ms later -- same issue as we were talking about with the activation thing. And here I cannot determine if pagination happened (at least easily naively, since user can send new messages during the chat history pagination is in flight), and can only debounce-and-pray, so is really "best effort" best reactive programming can do here? Since the pagination library of you guys, internally its basically imperative / blocking listeners if I remember correctly