DEV Community

Binding Android UI with Kotlin Flow

Yang on October 29, 2019

Modern Android codebases are becoming increasingly reactive. With concepts and patterns such as MVI, Redux, Unidirectional Data Flow, many componen...

Read full post

Ivet Jurčíková • Nov 5 '19

Thanks for your effort and for making the library!

I have one, a bit unrelated question: while introducing safeOffer, you wrote: "But the function might throw an exception if the channel is closed for send." - When can this happen? How is it possible that the channel may be closed for send if its superior flow is not?

Yang • Nov 5 '19

Great question! You're right that in this case isClosedForSend should never return true in the callback, but this is only because in the the awaitClose block we've unregistered / removed the callback from the widget. So this is somewhat a "defensive" approach to make sure we don't crash if we forgot to unregister the callback (which is arguably worse as we usually want to fail early but that's a different conversation).

SendChannel.offer also has other issues (note the 3rd point), so even when isClosedForSend is false a subsequent offer call might still throw and hence in the safeOffer function we still need to wrap a try / catch around offer.

Hope that answered your question 😀

Denys M. • Nov 5 '19

Don't want to upset you. But there is library which does the same: Corbind.

Are there some reasons why to create new one?

Yang • Nov 5 '19

Yes I'm aware of Corbind! A couple of months into developing FlowBinding I found out about Corbind which also provides Flow bindings along with actor and channel bindings which existed before coroutines introduced Flow. I thought about moving on to something else but decided continue developing FlowBinding for a couple of reasons:

I want something that only supports cold streams (Flow) which is safer API to expose to the consumer than channels.
Testing is really important to me both as a developer and a library consumer so I was hesitant to introduce a library with no tests at all into my codebase. For FlowBinding I invested in building a custom testing framework and CI pipeline to ensure all bindings are tested with instrumented tests on CI, and I really wanted to leverage these to continue developing these bindings which had become a fairly mechanical process.
It's also a great exercise for me to be able to explore and interact with most of the UI widgets on Android many of which I'd never needed to touch as an app developer.

That said, from a user's perspective if you’re already using Corbind and are happy with it there’s probably little reason to switch; but if you are looking to migrate from RxBinding to a Flow equivalent today, I think FlowBinding is a good option.

Hope that answered you question 😀

Denys M. • Nov 5 '19

Thanks for you detailed answer!

Have you thought about joining your efforts (e.g. tests) with author of Corbind? I guess, it's win-win situation for the community when instead of few same-functionality libraries we'll have one that offers strong and bug-less implementation.

There is good example in Kotlin-community: Arrow. Authors of two functional libraries joined their efforts to avoid ecosystem fragmentation.

Good luck!