I am thinking about turning `View` clicks into `Fl...

# android

[dewildte]

I am thinking about turning View clicks into Flow<T>, has anyone done this? What approach did you take? If you think it's a bad idea, why?

[louiscad]

I made an awaitOneClick(…) suspending function and I prefer it that way, looping on it if needed. I actually put that into a library: https://github.com/LouisCAD/Splitties/tree/master/modules/views-coroutines

[dewildte]

@louiscad Thanks for the reply, I was looking at your code and I am not sure how you react to the click.

[dewildte]

I think your have a way better understanding of the continuation mechanism then I do.

[louiscad]

I resume the continuation, which is essentially making the function return

[louiscad]

So I handle the click on the line after the line where I call awaitOneClick(), simply.

[dewildte]

Ok, That's what I thought. but was not sure.

[dewildte]

That's very clever

[dewildte]

And you said you loop inside the wrapping suspend function?

[louiscad]

It's like waiting for network I/O, but here, it is UI I/O, where the output is enabling the view, and the input is the click.

[dewildte]

Could you give me a small example of the implementation side?

[louiscad]

Yes, I use a simple while loop where I wait for the click, then react to that, and once that's done, I let the loop interate again if I'm ready to accept further interactions.

All the examples I have are closed source for the company I work for unfortunately, but I plan to use that in future sample code in open source projects. Let me write a dummy example…

[dewildte]

Thank you so much!

[dewildte]

My use case is going to be turning the clicks into a Flow<T> and then passing the flow to an EventBus for collection and redistribution.

[louiscad]

Here's the simplest example I found on the top of my head:

while (true) {
    ui.launchDemoBtn.awaitOneClick()
    speakHello() // Suspends until done
}

[dewildte]

Awesome!

[dewildte]

you wrap the while loop into a launch {...} ?

[louiscad]

Note that I tend to hide this behind an interface for the user interface where I expose suspending functions and regular functions, with no dependencies on the platform though. You can call it coroutines enabled MV*

[louiscad]

I have one launch per independent UI process. That makes it clear what can run concurrently and what runs sequentially.

[dewildte]

Ok this is helpful, thanks!

[louiscad]

When you use coroutines and UI together, it becomes increasingly important to have the root CoroutineScope cancelled when the view hierarchy is destroyed, that's why I made this to not write the boilerplate each time: https://github.com/LouisCAD/Splitties/tree/master/modules/lifecycle-coroutines

If you're in a Fragment, be sure to use viewLifecycleOwner.

[Paul Woitaschek]

Can't this be done through a channel?

fun View.clicks(): Flow<Unit> {
  return flowViaChannel { channel ->
    setOnClickListener {
      channel.offer(Unit)
    }
    channel.invokeOnClose {
      setOnClickListener(null)
    }
  }
}

[Dominaezzz]

When do you close the channel?

[Paul Woitaschek]

Shouldn't it be automatically get cancelled through the coroutine scope?

[Dominaezzz]

What cancels the coroutine scope?

[Dominaezzz]

Nvm, I should just do some more reading on how Flow works. I'm not sure how it handles cancellation.

[Paul Woitaschek]

Well I'm not sure either, would love to have some light here 🙂

[Paul Woitaschek]

@FlowPreview
fun main() {
  val flow = flowViaChannel<Unit> { channel ->
    coroutineScope {
      launch {
        repeat(10) {
          channel.offer(Unit)
        }
      }
      channel.invokeOnClose { println("closed") }
    }
  }.take(3)
  val result = runBlocking {
    flow.toList()
  }
  println("flow emitted $result")
}

[Paul Woitaschek]

This prints:
closed
flow emitted [kotlin.Unit, kotlin.Unit, kotlin.Unit]

[Dominaezzz]

And without the take(3)?

[Paul Woitaschek]

Without it doesn't close - why would it?

[Dominaezzz]

That was the point I was initially trying to make.

[Paul Woitaschek]

I don't get the point

[Dominaezzz]

Same

[dewildte]

IT is safe to use though

[dewildte]

And a nice implementation.

[dewildte]

So I expanded on this idea and made

@FlowPreview
interface ChannelFlow<T> : SendChannel<T>, Flow<T>

@UseExperimental(FlowPreview::class)
fun <A> channelFlow(
    bufferSize: Int = 16
): ChannelFlow<A> {
    lateinit var c: SendChannel<A>

    val f = flowViaChannel<A>(bufferSize = bufferSize) {
        c = it
    }
    return object : ChannelFlow<A>, SendChannel<A> by c, Flow<A> by f {}
}

[dewildte]

Implementation looks something like

@FlowPreview
class ViewFacadeImpl : ViewFacade {

    private val channelFlow = channelFlow<ViewEvent>()

    override val events: Flow<ViewEvent> = channelFlow

    override suspend fun render(viewState: ViewState) {
        channelFlow.send(object : ViewEvent {})
    }
}

[dewildte]

hmm this seems to crash

[dewildte]

The instantiation order is not as expected.

[dewildte]

I had to rewrite to:

@UseExperimental(FlowPreview::class)
fun <A> channelFlow(
    bufferSize: Int = 16
): ChannelFlow<A> {

    val eventChannel: Channel<A> = Channel(bufferSize)

    val eventFlow: Flow<A> = flow {
        for (event in eventChannel) {
            emit(event)
        }
    }
    return object : ChannelFlow<A>,
        SendChannel<A> by eventChannel,
        Flow<A> by eventFlow {}
}