Stylianos Gakis05/20/2022, 7:03 AM
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
API to make this work correctly. Maybe this has to do something with the fact that we’re using a
object inside the VM in that sample instead of a
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
in the VM.
. 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
Colton Idle05/25/2022, 1:54 PM
Manuel Vivo05/30/2022, 8:49 AM
Stylianos Gakis05/30/2022, 9:20 AM
Manuel Vivo05/30/2022, 10:19 AM
Stylianos Gakis05/30/2022, 10:24 AM
Colton Idle06/02/2022, 9:13 AM
Stylianos Gakis06/02/2022, 9:41 AM
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
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.