I was looking at the UI events documentation here and I have once thing I am confused about which I’d love to discuss here. In the last code snippet of the linked section, right under “causing another UI state update:“, in the compose version, we’re looking at

viewModel.uiState.userMessages

inside the LaunchedEffect, but with no mechanism to ensure that this only happens when the app is in the foreground. Wouldn’t this mean that if I were to press home on my device, and right as I do that a message appears, this would trigger normally, and I would miss that message. On the contrary, in the View version, we’re using the

repeatOnLifecycle

API to make this work correctly. Maybe this has to do something with the fact that we’re using a

State<T>

object inside the VM in that sample instead of a

[State]Flow

and there’s some interaction I don’t understand, but I still think this would happen in the background even with that approach. p.s. I really wish the docs followed the more “common” pattern of having a StateFlow inside the VM instead. Or at least show how you’d have to approach this problem with both

State

and

StateFlow

in the VM.

@Manuel Vivo What do you think about "but with no mechanism to ensure that this only happens when the app is in the foreground. Wouldn’t this mean that if I were to press home on my device, and right as I do that a message appears, this would trigger normally, and I would miss that message." I think @Stylianos Gakis brings up a good point that I didn't think about?

Definitely! Thanks for raising this. We already started working on this :D https://android-review.googlesource.com/c/platform/frameworks/support/+/2102573/

Wow thank you SO much Manuel, yes this is exactly what I had in mind! Is this something that you’ve had on your todo list after making the initial UI event docs or was it a result of community feedback? I am just curious 🤔 It would be an amazing combo if once this is merged, you managed to get an example of using this in now-in-android repo too!

We’ve been having these conversations for a long time already. But the work is materializing now 🙂

Nice, super happy to see it coming together!

Manuel published this yesterday. I haven't read it... but maybe related @Stylianos Gakis? https://medium.com/androiddevelopers/viewmodel-one-off-event-antipatterns-16a1da869b95

No, not quite touching on the

collectAsState

vs

collectAsStateWithLifecycle

problem, since that one is not out yet I guess they are not going to be talking about it yet. In fact, in the last snippet, the compose and View alternatives are not functionally equivalent since one reads the state in the background as well while the View alternative uses repeatOnLifecycle as one should. I hope that once the

collectAsStateWithLifecycle

hits alpha/beta this article will be updated and all future ones will take it into consideration. A good article nonetheless, I read it before and it was a nice read.