Hi all, I'm currently trying to replace usages of ...

# coroutines

[svenjacobs]

Hi all, I'm currently trying to replace usages of Channel with Flow in my Android application. But now I'm stuck in a conceptual thinking problem: Right now I use Channel to handle UI events on Android views, for instance clicks inside a RecyclerView.Adapter. I create an instance of Channel in the view (or presenter, it doesn't matter) and pass it to the RecyclerView.Adapter. Then inside the adapter I could just pass click events to the channel. But with Flow, the flow needs to be created at the place where the data is emitted. However I don't want to have x flows in my Adapter for every view the adapter manages. Is Flow even suited for UI events or are UI events classically hot streams? Am I just trying to apply Flow where Channel is the right choice after all?

[bdawg.io]

Yeah, those UI events are hot since you want the click event itself and the handler to be fully decoupled but listening.

[svenjacobs]

Thanks Bradyn, that's what I tought

[darkmoon_uk]

Flow isn't necessarily a replacement for Channel - Channel is appropriate for 'hot' events like live interactions with your UI.

[darkmoon_uk]

If you've come from experience with RxJava, then you might be used to working with the hybrid behaviour of a BehaviourSubject - subscription to which offers an immediate 'last known' value (cold), followed by subsequent updates (hot).

[darkmoon_uk]

There is a coroutines equivalent to this model - the ConflatedBroadcastChannel

[darkmoon_uk]

See: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.channels/-conflated-broadcast-channel/

[darkmoon_uk]

...pretty handy for UI work.

[svenjacobs]

Thanks Chris, I'm already using ConflatedBroadcastChannel 🙂 So basically channels are the right choice for hot UI events

[darkmoon_uk]

Yep

[svenjacobs]

But I might replace Channel with Flow for my API requests

[darkmoon_uk]

Yep, or note you can use asFlow to gain the Flow-API benefits for any BroadcastChannel.

[darkmoon_uk]

https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/as-flow.html

[yshrsmz]

https://github.com/Kotlin/kotlinx.coroutines/pull/1354

[yshrsmz]

I'm waiting for this 🙂

[elizarov]

Let’s bikeshed a name: https://github.com/Kotlin/kotlinx.coroutines/issues/1082#issuecomment-525650399

[darkmoon_uk]

@elizarov StateFlow is most incisive, because:
- Data Flow implies data in an untyped, raw form, which this is (usually) not.
- Value Flow somewhat clashes by name with Kotlins val, implying unchanging, or constant, which this is not.
- State Flow - as you said yourself, succinctly point to the fact there is an ever-present state of this thing, which can be accessed... but which flows, changes.

[Dominaezzz]

Use callbackFlow.

[Dominaezzz]

And do something similar to https://kotlinlang.slack.com/archives/C0B8M7BUY/p1566839392302900