Closed p-lr closed 3 years ago
Hi @peterLaurence,
Your change looks good. Could you please tell more about the use case where launchWhenStarted
mattered?
Please consider opening a pull request for your changes - both the naming of the functions and the launchWhenStarted
change. I'll be happy to review them and integrate.
Thanks!
Hi @psteiger,
When the flow collection is done inside a fragment, and when we want to trigger a view change based on a particular event, we can use collectWhileStarted
operator. The issue I had was due to the fact that I had to remove a child view and add it back to the view hierarchy, assigning the same id. If this is done when the state is STARTED
, the newly added view has its state automatically restored (using the state of the previous view). While if this is done when the state isn't yet STARTED
, the view state isn't automatically restored.
On the other hand, for other use cases, I don't think using launchWhenStarted
instead of launch
will make a difference. Anyway, I think that this is a good thing that the name of the operator explicitly tells when actions are triggered.
If that sounds ok to you, I can do a PR.
Ok @peterLaurence , I understand the failing use case and I don't think using a lifecycle-specific launch would break other use cases.
A PR would be welcome! Thanks.
Ok great, I'll do that.
Solved by PR #3
onStart()
on a lifecycle observer is indeed invoked right before an androidx.Fragment reaches theSTARTED
state
@peterLaurence Are you sure? I see that lifecycle.currentState
is indeed CREATED
during Activity/Fragment onStart()
(in accordance to the docs), but it is already STARTED
during LifecycleObserver.onStart()
, where flow collection is launched.
You can also check the code: mState
is currentState
, and sync()
is where observers are notified.
@gmk57 I'll double check. Anyway, there was a difference between using launchWhenStarted
and launch
. Even though, if you're right, there shouldn't have been a difference.
I recently came across an issue that was due to the fact that the flow collection started with
observe
operator is actually performed right before the lifecycle reaches theSTARTED
state.Checking the source code, we can indeed see that:
Well, I can at least tell that
onStart()
on a lifecycle observer is indeed invoked right before an androidx.Fragment reaches theSTARTED
state.It may all sound not really important, but it turned out to matter today for some particular case. I could easy fix that with using
launchWhenStarted
instead oflaunch
, inside the operator implementation.This what I'm using in my project (it also has different naming, which I find more explicit. It also has a collectWhileResumed variant):