Question about `callbackFlow` . Is it ok to use `t...

# getting-started

[Peter]

Question about callbackFlow . Is it ok to use trySendBlocking() , or should I prefer smth like launch { send() } ?

fun Something.observer(): Flow<String> = callbackFlow { 
    val callback = object : Callback() {
        override fun onSuccess() {
            trySendBlocking("done")
            // or
            launch { send("done") }
        }
    }
    addCallback(callback)
}

[Sam]

The difference is less than you might think. If you launch a bunch of coroutines to do your sending, you're effectively buffering the values at the dispatcher. I don't think they're guaranteed to send in the order you scheduled them, though. If you want the values buffered, better to add an explicit buffer() to the flow.

[Sam]

In the absence of either type of buffering, the choice of whether your callback is allowed to block its thread is really up to you, and depends on what code/framework will be executing the callback

[Sam]

Callback flows come with a buffer by default (per the docs), but you might want to change the size of the buffer if you are concerned about blocking

[Peter]

hm, yeah makes sense. I guess it only depends on if you want to block callback executor 🙈

[Peter]

since callback is buffered, I guess trySend should be good in most cases

[Sam]

Until the buffer gets full 😄 😭

[Sam]

There’s no real good answer unfortunately

[Sam]

trySendBlocking will only block if the buffer is full, so I think it’s generally a decent compromise

[Peter]

Thanks for info 🍺