mcpiroman
11/29/2021, 5:59 PMval focusRequests = MutableSharedFlow<Unit>(onBufferOverflow = BufferOverflow.DROP_LATEST, extraBufferCapacity = 1)
focusRequests.tryEmit(Unit) // on frontend
focusRequests.collect { ... } // on backend
but I feel like this is an abuse of the SharedFlow. Is there more specific construct I should use in such cases?Dominaezzz
11/29/2021, 6:03 PMmcpiroman
11/29/2021, 6:16 PMDominaezzz
11/29/2021, 6:19 PMmcpiroman
11/29/2021, 6:26 PMDominaezzz
11/29/2021, 7:23 PMmcpiroman
11/29/2021, 7:27 PMDominaezzz
11/29/2021, 7:27 PMChannel
?Joakim Forslund
11/29/2021, 7:44 PMmcpiroman
11/29/2021, 7:49 PMJoffrey
11/30/2021, 11:02 AMpasses around unnecessary instance of UnitThere is only one instance of the
Unit
object, so don't worry about this.
on callside usesThat sounds OK to me. The client doesn't know the backpressure strategy of that flow, so it makes sense IMO that the client expresses whether it is able to handle backpressure via suspension or whether it wants to just keep going (you could use emit if you're already in a suspending context, it won't suspend anyway). On the other side, the construction of the flow decides what to do for backpressure on its own.even though it is bound to successtryEmit
it uses a unnecessary buffer of 1Why do you consider it unnecessary? It allows slow subscribers to run multiple times in a row if one or more new notifications arrived while they were processing the previous one, it makes sense to have this buffer. You need somehow to store the "boolean state" you're referring to ("was there a notification since I last run?").
has quite complicated configuration in the constructor for such a simple and common usage.It's true it could maybe be included in the coroutines library, but you could also define a simple wrapper around this yourself.