But, and I hate to say this, but I suspect the majority of "real projects" written in Go will use their

chan

primative, which is semantically identical (if not quite syntactically identical) to

kotlinx.coroutines.channel.Channel

. As for public source code of "real projects" in kotlin using channels, you're best bet is probably IDEA's own source code, or perhaps another Jetbrains product which has its source published.

So what does a

suspend

fun declaration looks like for Java?

I have a visibility issue with coroutines. I want to expose my

ConflatedBroadcastChannel

from my ViewModel to my view. However I don't want to expose all it's functionallity. The client should not be able to call offer itself. It should only be able to view the consuming part. Is that something that can be achieved? (without creating an extra wrapper class)

Ah is it like this?

-.kt

Yes, you got it right in your snippet

so ConflatedChannel functions like a

BehaviorSubject

. What functions similar to a

PublishSubject

?

@louiscad?

@Paul Woitaschek I never used

PublishSubject

, but from the name, it sounds very similar. I use

ConflatedBroadcastChannel

in several projects though

It just works as kind of an event bus

If you are subscribed while someone is onNexting it, you receive an event, otherwise not

+1 to @louiscad We use ConflatedBroadcastChannel exactly like that.

@Paul Woitaschek Yes ConflatedBroadcastChannel is close to BehaviorSubject BroadcastChannel works as PublishSubject

I use extensions to tie these subscriptions / channels to the livetime of my consumer.

Is it somhow possible to bind these channels to the parent coroutine livetime?

-.kt

All this cancellation is a bit error prone

No need to call

cancelOnDestroyView()

on your channel. When

launch

will be cancelled channel also will be cancelled.

First I thought so too but testing showed other wise:

-.kt

Are you sure that your snippet is correct? Because

consumeEach

do not return until channel is cancelled, so your password event will subscribe only when mail event channel will be closed

But cancel is not instant

use

cancelAndJoin()

to wait when job is cancelled Just replace

cancel()

to

cancelAndJoin()

@Paul Woitaschek Here's a

job

extension property on

Lifecycle

, plus a

createJob

function if needed, that you can use as a

parent

for a coroutine (including an

actor

)

But when cancel needs to be awaited first, that's buggy so you receive events after cancellation?

Not after cancellation, cancellation is not occured, there is a lot of async machinery under the hood

there is just not enough time to propagate the event before your second offer executed

But then it's a race condition isn't it?

No, I don’t see why it should be race condition there