How to understand complicated sharedflow expression?-CodePudding

I would like to fully understand what happens here.

sharedFlow.debounce(250)
            .onEach(::updateGroupingStrategy)
            .shareIn(viewModelScope, SharingStarted.WhileSubscribed(5000L), replay = 1)

debounce

Returns a flow that mirrors the original flow, but filters out values that are followed by the newer values within the given timeout. The latest value is always emitted.
 
debounce helps to detect the state when no new data is submitted for some time, effectively allowing you to process a data when the input is completed.

From my perspective, I delay subscribing sharedflow for 250L ms or I only subscribe values every and after 250L?

onEach

* Returns a flow that invokes the given [action] **before** each value of the upstream flow is emitted downstream.

From my perspective, quite don't understand it. First return flow then start subscribing, assign value for it?

.shareIn

Sharing is started when the first subscriber appears, immediately stops when the last subscriber disappears (by default), keeping the replay cache forever (by default).
It has the following optional parameters:
stopTimeoutMillis — configures a delay (in milliseconds) between the disappearance of the last subscriber and the stopping of the sharing coroutine. It defaults to zero (stop immediately).

replay - the number of values replayed to new subscribers (cannot be negative, defaults to zero).

From my perspective, after there is not more subscriber I wait 5000L miliseconds then I make action? Replay I do not understand.

CodePudding user response：

Each Flow operator (besides stateIn and shareIn) creates a new cold flow that wraps the one it's called on. When the downstream flow is collected, it runs through the actions of its upstream operators.

debounce immediately collects from upstream when it is collected, but delays re-emitting the values downstream by the amount of time you specify. It drops the pending value if a new one arrives during the delay. Its purpose is to filter out rapid changes to simplify what the downstream collectors have to deal with. Your upstream shared flow will immediately see a subscriber at the moment the downstream flow is collected.

onEach adds a side-effect that occurs each time the upstream flow emits.

shareIn makes the Flow hot, but WhileSubscribed limits when the flow is hot to only while there is at least one subscriber. This is so we don't waste resources fetching or monitoring data when there is nothing using it. The 5000L means it waits 5000ms before turning off after it loses its last subscriber. This avoids needlessly turning off the flow when we lose a last subscriber but get a new subscriber quickly. On Android, this is a frequent occurrence when the screen rotates, because the subscribers will be destroyed, but new subscribers to the same things will be created once the Activity is recreated in the new orientation. We want to avoid having to restart the flow from scratch so it can display the latest data quickly.