Why is it necessary to call `BroadcastChannel.send` in a suspended function? With e.g. RxJava pushin...

# coroutines

[iex]

Why is it necessary to call BroadcastChannel.send in a suspended function? With e.g. RxJava pushing events to a subject doesn't require anything special.

[louiscad]

@iex You are probably looking for offer.

[iex]

ah, makes sense, thanks!

[iex]

(just started using channels)

[iex]

there should be something like offer, but which throws an error if the channel is full (instead of returning false)?

[iex]

given the options I actually feel a bit safer using runBlocking { observable.send(x) }

[louiscad]

You can easily make your own if you want to throw if that's how you need to handle it.

If it should never happen, you can for example do check(myBroadcastChannel.offer(element))

[louiscad]

You can also do launch { myBroadcastChannel.offer(element) }

[louiscad]

Or use sendBlocking if you're sure you need to block the sending thread.

[iex]

what would be the purpose of the one with launch?

[louiscad]

To wait for the channel to no longer be full and send when possible

[iex]

ah, sendBlocking is perfect!

[iex]

that (the option with launch) would be identical to runBlocking { observable.send(x) } ?

[iex]

ah no

[iex]

it's async

[iex]

confused 🤔

[louiscad]

But with launch and send, you're not blocking that expensive thread (expensive in terms of memory and that it cannot be used for something else). Blocking a thread when you don't need to is like holding a car that you don't need

[louiscad]

It's like useless traffic lights… oh wait, I see a pattern here 😅

[iex]

yeah, definitely. This is just to call some (non long running) callbacks on the main thread

[iex]

so blocking is fine

[iex]

thanks for the help, everything is clearer now 🙂

[louiscad]

Well, depends on which platform… if you are in a UI environment (e.g. mobile/desktop app), it's absolutely not fine, at all. If it's on a server, it depends, but it might not be best to block thread

[iex]

as I said, it's not long running. It's just to channel the control flow in a specific way.

[iex]

in this specific case I've a component to start a permission flow, and when it finishes, it notifies other components

[louiscad]

in UI environment, long running can start before 1ms long. It all adds up

[louiscad]

It's in an Android app?

[iex]

yes

[louiscad]

I made this for Android permissions requests with coroutines which is very likely to be what you're looking for: https://github.com/LouisCAD/Splitties/tree/master/modules/permissions

[iex]

thanks! I've already an rx component which I'm happy with and just changing it to use channels instead of subjects

[iex]

but will give it a look if I need something new

[louiscad]

I personally found Channels to be better hidden in implementation details for this kind of use case, simply exposing suspending functions as a higher level API instead.

[louiscad]

But I'm glad I helped either way 🙂

[iex]

I find observables convenient, because I can have arbitrary components observing the result and don't have to care about timing etc.

[iex]

but I just like modeling everything with observables 🙂

[louiscad]

In coroutines world, the analogue is Flow and suspending functions. It's very easy to turn one or more suspending functions and some logic into a Flow BTW.

[iex]

It's still needed to use BroadcastChannel for where I was using PublishSubject apparently

[iex]

(or ConflatedBroadcastChannel for BehaviorSubject from what I just read)

[louiscad]

If you care only about the latest value, StateFlow might be a great solution.

[iex]

it's more that I need to push values to it arbitrarily

[louiscad]

But on the receiving end?

[louiscad]

You can just set a new value on a MutableStateFlow

[iex]

just sending... Ideally the interface to the observer would expose something different

[iex]

(previously I used Observable )

[iex]

but BroadcastChannel doesn't implement Flow, so I can't apply the same pattern

[louiscad]

(I'm not very familiar with Rx FYI)

[iex]

MutableStateFlow -> interesting, will give that a look 👍

[louiscad]

But you don't need a BroadcastChannel if you're using MutableStateFlow and expose StateFlow or a plain Flow.

[iex]

I just googled the equivalents for the rx stuff and that's what came up 😅

[louiscad]

It is, it's just going away soon, replaced by already avilable StateFlow, and upcoming SharedFlow.

[iex]

good to know, thanks!

[julian]

What's going away, BroadcastChannel? @louiscad

[andylamax]

Very interesting thread

[louiscad]

ConflatedBroadcastChannel in favor of StateFlow.
BroadcastChannel, I cannot tell. But they are still safe to use if StateFlow doesn't suit your use case.

[andylamax]

and what will be the purpose of shared flow?

[louiscad]

@andylamax https://github.com/Kotlin/kotlinx.coroutines/pull/2069

[andylamax]

Thank you

[andylamax]

While I totally understand what a StateFlow is, I still have partial knowledge on what a SharedFlow is (Ironic ey? provided that StateFlow implements SharedFlow)

[andylamax]

Thanks any way.

[louiscad]

There's two link to related issues in the PR I linked. Regardless, it'll be more clear when it'll be released with docs, and examples in the wild.

[Zach Klippenstein (he/him) [MOD]]

If StateFlow is like Rx's BehaviorSubject, then SharedFlow is basically like PublishSubject. However, SharedFlow actually supports propagating backpressure to the sender, like BroadcastChannel, so if one of your subscribers is slow, the send call will suspend. SharedFlow also supports custom replay behavior, so you can make it act like a StateFlow (but without access to the current value). Both flows are also unlike Subjects in that you can't close or fail them directly, although you can get similar behavior by applying operators to the flows before exposing them.

[andylamax]

Woooow... thank you so much