Stylianos Gakis
05/20/2022, 7:03 AMviewModel.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..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).Colton Idle
05/25/2022, 1:54 PMManuel Vivo
05/30/2022, 8:49 AMStylianos Gakis
05/30/2022, 9:20 AMManuel Vivo
05/30/2022, 10:19 AMStylianos Gakis
05/30/2022, 10:24 AMColton Idle
06/02/2022, 9:13 AMStylianos Gakis
06/02/2022, 9:41 AMcollectAsState
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.