ceedee10/18/2023, 7:36 AM
for Flow collection within
of Fragments. But there’s a catch to it: when I navigate to another Fragment, the previous Fragment goes to
but returns to
state when I navigate back to it. Since
will only fully terminate itself when the Fragment reached
state, the call to
will spawn a DUPLICATE Flow collection. When I repeat this navigation / back navigation, even more Flow collections will add up. The solutions I considered are: a) using
in the ViewModel b) moving
of the Fragment But I wonder why Google recommends using
. Can anyone shed some light on this?
zsmb10/18/2023, 7:47 AM
as described in the article, then the collection should be tied to the lifecycle of the Fragment's view, which means that it will be terminated when
Robert Williams10/18/2023, 8:42 AM
Albert Chang10/18/2023, 10:22 AM
ceedee10/19/2023, 1:20 PM
we can get back to
calls are issued which add up one after the other. @Robert Williams Even if the
from the ViewModel is a
, still multiple collections will be launched which lead to multiple UI updates which is a bad thing since my application will become slower and slower after each navigation back to that Fragment. I still think, that
is the wrong place to call
Robert Williams10/19/2023, 1:37 PM
* Runs the given [block] in a new coroutine when[Lifecycle] is at least at [state] and
* suspends the execution until[Lifecycle] is [Lifecycle.State.DESTROYED].
scope the old repeatOnLifecycle will just return and the coroutine will be cleaned up on destroy view and the newly started one will be the only collection
ceedee10/20/2023, 12:58 PM
. From there, it can re-enter
on back navigation. Thus, active
calls will add up. So still, I believe the documentation is wrong in this point.
Robert Williams10/20/2023, 1:00 PM
ceedee10/20/2023, 1:56 PM
part because I had
in front of my eyes… All explanations totally make sense, thank you!