I was looking at the UI events documentation <here...

# compose

[Stylianos Gakis]

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.

[Stylianos Gakis]

I remembered that tivi has a convenience function here named rememberStateWithLifecycle which does exactly what I am looking for. But the sad part is that, I can almost see myself almost always preferring that one over the normal .collectAsState() extension on StateFlow. There’s very few cases where I’d purposefully allow the state to be collected in the background (they exist, but by default I want the rememberStateWithLifecycle approach).

[Stylianos Gakis]

Went ahead and posted this in nowinandroid too to potentially get some official examples inside a real app. I think there’s some room for improvement around the communication of how this very common issue should be solved.

[Colton Idle]

@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?

[Manuel Vivo]

Definitely! Thanks for raising this. We already started working on this :D

https://android-review.googlesource.com/c/platform/frameworks/support/+/2102573/

[Stylianos Gakis]

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!

[Manuel Vivo]

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

[Stylianos Gakis]

Nice, super happy to see it coming together!

[Colton Idle]

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

[Stylianos Gakis]

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.