Go with the Kotlin Flow 🌊 | Android Summit

Kotlin Flow is yet another implementation of Reactive Stream specification made on top of coroutines for Kotlin.

In this talk, we will look at Kotlin Flow, why it was introduced, some basics, show what makes it special, how can you migrate and most important testing

Agenda
- Why Flow and it's history
- Basics of Kotlin Flow
- How it compares with RxJava and LiveData
- Why and how to migrate from RxJava 1 or 2
- Working with RxJava ❤ Flow in single codebase
- Magic of multi-platform
- Tests
- Conclusion

You’ll walk away with a clear idea of what Kotlin Flow is and how it compares with other reactive implementation particularly RxJava and how to evaluate and how you can gradually migrate from Rx if you want to

Transcript

1. Akshay Chordiya Go with the Flow @Akshay_Chordiya Hey everyone, welcome and thank you for joining. It’s great to be here at Android Summit virtually! I’m Akshay Chordiya, I’m based in Berlin, Germany. I work as Android Developer at Clue which is a female health company. I’m also Google Developer Expert for Android.
2. Akshay Chordiya Go with the Flow @Akshay_Chordiya Today we are going to talk about something which many people are excited about i.e Kotlin Flow
3. Coroutines Let’s rewind ⏪ a little bit Let’s rewind a little bit and look at what Kotlin gave us - coroutines. They simplify asynchronous programming in general and especially on Android
4. Synchronous code fun showUser() { val user = db.loadUser() // Blocks the thread render(user) } Here is an example of synchronous function called `showUser` which internally loads the user from the database.
5. Synchronous code fun showUser() { val user = db.loadUser() // Blocks the thread render(user) } loadUser When this function calls `loadUser` it blocks the current thread and waits till user is loaded from the database, this blocking is bad because at this moment the whole UI is frozen -> making the user unhappy
6. Synchronous code fun showUser() { val user = db.loadUser() // Blocks the thread render(user) } loadUser render And then once the data is loaded from database the `render` function is called which renders the user data on the UI. There are multiple ways to tackle this. Let’s look at how we can convert this function to use coroutine
7. With Coroutines fun showUser() { val user = db.loadUser() render(user) } Let’s start by taking the original synchronous function
8. With Coroutines suspend fun showUser() { val user = db.loadUser() // Background thread render(user) } First we need to mark the `showUser` function with suspend keyword, of course we will need to mark the `loadUser` as suspend too since we also want want it to run on background thread. You can see that just by marking it as suspend the code will run in background thread
9. With Coroutines suspend fun showUser() { val user = db.loadUser() // Background thread render(user) } But there is a problem the `render` function needs to be called from UI thread since its touching the view hierarchy.
10. With Coroutines suspend fun showUser() { val user = db.loadUser() // Background thread withContext(Dispatchers.Main) { render(user) // UI thread } } We can use the `withContext` function which allows to switch the thread inside the suspending function and change the thread to main and call `render` function, and that’s it!
11. With Coroutines suspend fun showUser() { val user = db.loadUser() // Background thread withContext(Dispatchers.Main) { render(user) // UI thread } } showUser This is how it will work, we start by calling the `showUser` function, since it’s marked as suspend it will switch to a background thread or the thread specified while launching the coroutine
12. With Coroutines suspend fun showUser() { val user = db.loadUser() // Background thread withContext(Dispatchers.Main) { render(user) // UI thread } } showUser loadUser and then the user will be loaded from the database on a different thread while the main thread continues to go ahead without waiting for anything i.e not freezing or blocking the user experience
13. With Coroutines suspend fun showUser() { val user = db.loadUser() // Background thread withContext(Dispatchers.Main) { render(user) // UI thread } } showUser loadUser render And then it will switch back to main thread because of `withContext` and then call the `render` function on the Main / UI thread
14. A suspend function can only be called from another suspend function One key thing to remember is a suspend function can only be called from another suspend function
15. A suspend function can only be called from another suspend function or a coroutine scope Or from a coroutine scope,
16. Coroutine scope A coroutine scope represents the scope of the coroutines, each coroutine needs a scope to run in and when the scope is destroyed all the running jobs inside the scope are also stopped or cancelled
17. Coroutine scope ~ Lifecycle scope This scope is generally associated to the lifecycle scope for simplicity. For instance, on Android each activity has a lifecycle. Let’s look at example to help understand this better
18. fun main() { lifecycleScope.launch { showUser() } } * available in lifecycle-ktx Jetpack library For example, in order to call our `showUser` suspend function from a normal function we would need a coroutine scope. On Android these scopes are already implemented for us like `lifecycleScope` which is part of `lifecycle-ktx` library from Jetpack components. it is provided to use coroutine function in Activity or Fragment. It’s a coroutine scope which is tied to the lifecycle of activity or fragment
19. fun main() { lifecycleScope.launch { showUser() } } CREATED DESTROYED This provides the magic of automatically clearing or cancelling all the jobs running in the specified scope when the activity or fragment is destroyed
20. fun main() { lifecycleScope.launch { showUser() } } The launch function is used to start the coroutine, it will immediately start the coroutine That means coroutines are hot in nature, this also one of the reason why coroutines are not replacement for reactive streams
21. “A coroutine scope is kinda a subscription management system associated to lifecycle ♻”
22. Structured Concurrency This concept is called as Structured Concurrency and this is what makes Kotlin coroutines so powerful and also helps developers prevent leaking the job / subscription
23. Why Kotlin Flow? Let’s come to the important question, why Kotlin Flow?
24. Why Kotlin Flow? Kotlin Coroutine With growing usage of Kotlin and the love for Kotlin coroutines, people expressed a lot of interest in having a pure Kotlin implementation of RxJava to leverage all the amazing features which Kotlin provides
25. RxKotlin or from scratch? But the confusion was creating some sort of magic on top of RxJava to leverage Kotlin or to build a whole new library from scratch. In case if you don’t know RxKotlin does exist but it cannot really leverage all the Kotlin features.
26. Me “At the end it’s important that any new library raises the bar compared to existing ones and is not just a replica with slight improvements” To me it’s important that any new library raises the bar compared to any existing libraries out there and is not just a replica with slight improvements. And Kotlin Flow does raise the bar
27. So What’s special So let’s look at what’s special in Kotlin Flow to raise the bar
28. What’s special ✨ Null safety in streams ✨ Interoperability between other reactive streams and coroutines ✨ Supports Kotlin multiplatform ✨ No special handling for back pressure ✨ Fewer and simple operators ✨ Perks of structured concurrency • Flow provides null safety in the stream that means you cannot send null values in the stream, this is not something new; RxJava 2 has it too • This is the key thing, Flow provides easy APIs to convert Flow to any other reactive stream like RxJava Flowable and the reverse. Also you can combine Flow and coroutines, we will see this later • You can actually use Kotlin coroutines and Flow on any of the supported Kotlin platforms like JVM, JS and native + use it the common code or shared code for Kotlin multiplatform projects • There is no special handling for back pressure, there are literally no operators for handling back pressure cause this is magically handled by the suspending nature of coroutines • There are fewer operators which directly correlates to ease of understanding, this is because of 2 reasons • Kotlin’s extension function magic • Suspending nature of coroutines allow having same operator for synchronous / asynchronous code which cuts down the number of operators •
29. What is Flow?
30. What is Flow? Based upon reactive stream specification Similar to a list / collection It has operators like map, switchMap, etc Built on top of coroutines It’s ❄ in nature
31. Basics Let’s look at some of the basics of Flow
32. fun stream(): Flow<String> = flow { emit("") // Emits the value upstream ☝ emit("⚽") emit("") } Essentially there are 2 components i.e emitter and collector where emitter emits new values and collector receives the value. Here is an example of an emitter.
33. fun stream(): Flow<String> = flow { emit("") // Emits the value upstream ☝ emit("⚽") emit("") } Which returns Flow of string very similar to how you would return a list of string
34. fun stream(): Flow<String> = flow { emit("") // Emits the value upstream ☝ emit("⚽") emit("") } There are various ways of creating a flow using something called as flow builders (they are functions provided by Kotlin coroutines library). It internally creates the flow for us, we will come to it later.
35. fun stream(): Flow<String> = flow { emit("") // Emits the value upstream ☝ emit("⚽") emit("") } ❄ ❄ ❄ ❄ ❄ Since Flow is cold, nothing inside the flow builder block will be called until there is a subscriber or a collector observing the flow
36. fun stream(): Flow<String> = flow { emit("") // Emits the value upstream ☝ emit("⚽") emit("") } Emitter Collector fun main() = runBlocking { stream().collect { value -> println(value) } } Let’s look at the collector, here we have a main function which gets the flow inside the `runBlocking` function. For people who haven’t used coroutines; `runBlocking` function is a blocking coroutine scope i.e it blocks the current thread until everything is completed. We need the coroutine scope since the `collect` function is a suspend function, so is `emit`. We will see ahead why they are suspend functions
37. fun stream(): Flow<String> = flow { emit("") // Emits the value upstream ☝ emit("⚽") emit("") } Emitter Collector fun main() = runBlocking { stream().collect { value -> println(value) } } main() stream() Let’s understand how things work internally
38. fun stream(): Flow<String> = flow { emit("") // Emits the value upstream ☝ emit("⚽") emit("") } Emitter Collector fun main() = runBlocking { stream().collect { value -> println(value) } } main() stream() Initially the main function calls the stream function
39. fun stream(): Flow<String> = flow { emit("") // Emits the value upstream ☝ emit("⚽") emit("") } Emitter Collector fun main() = runBlocking { stream().collect { value -> println(value) } } main() stream() Which immediately returns the flow
40. fun stream(): Flow<String> = flow { emit("") // Emits the value upstream ☝ emit("⚽") emit("") } Emitter Collector fun main() = runBlocking { stream().collect { value -> println(value) } } main() stream() Which immediately returns the flow
41. fun stream(): Flow<String> = flow { emit("") // Emits the value upstream ☝ emit("⚽") emit("") } Emitter Collector fun main() = runBlocking { stream().collect { value -> println(value) } } main() stream() collect Then we call the collect function on the flow, which essentially means we are subscribed to the emitter
42. fun stream(): Flow<String> = flow { emit("") // Emits the value upstream ☝ emit("⚽") emit("") } Emitter Collector fun main() = runBlocking { stream().collect { value -> println(value) } } main() stream() collect emit That the emitter starts emitting the value sequentially
43. fun stream(): Flow<String> = flow { emit("") // Emits the value upstream ☝ emit("⚽") emit("") } Emitter Collector fun main() = runBlocking { stream().collect { value -> println(value) } } main() stream() collect emit And the collector receives them and prints in this case
44. fun stream(): Flow<String> = flow { emit("") // Emits the value upstream ☝ emit("⚽") emit("") } Emitter Collector fun main() = runBlocking { stream().collect { value -> println(value) } } main() stream() collect emit collect emit ⚽ And then the same loop happens emitting the next value
45. fun stream(): Flow<String> = flow { emit("") // Emits the value upstream ☝ emit("⚽") emit("") } Emitter Collector fun main() = runBlocking { stream().collect { value -> println(value) } } main() stream() collect emit collect emit ⚽ ⚽
46. fun stream(): Flow<String> = flow { emit("") // Emits the value upstream ☝ emit("⚽") emit("") } Emitter Collector fun main() = runBlocking { stream().collect { value -> println(value) } } main() stream() collect emit collect emit ⚽ ⚽ .. This goes on
47. fun stream(): Flow<String> = flow { emit("") // Emits the value upstream ☝ emit("⚽") emit("") } Emitter Collector fun main() = runBlocking { stream().collect { value -> println(value) } } main() stream() collect emit collect emit ⚽ ⚽ collect .. Till the emitter has no values that’s when the execution moves out of collect and is complete
48. Let’s dive deeper Let’s dive a little deeper and see how this is working internally
49. public interface Flow<out T> { public suspend fun collect(collector: FlowCollector<T>) } Collector As I mentioned before Flow is based upon 2 components a collector and emitter, essentially they are interfaces. The following represents the interface for collector which exposes the `collect` function
50. public interface Flow<out T> { public suspend fun collect(collector: FlowCollector<T>) } Collector public interface FlowCollector<in T> { public suspend fun emit(value: T) } Emitter And the emitter interface which allows emitting values
51. public interface Flow<out T> { public suspend fun collect(collector: FlowCollector<T>) } Collector public interface FlowCollector<in T> { public suspend fun emit(value: T) } Emitter The key thing to note over here is both the functions are suspend which allows the magic of interoperability with coroutines and also allows using the structured concurrency provided by coroutines. The funny thing is the whole internal mechanism of flow is essentially `emit` and `collect` function calling each other.
52. Flow ❤ Coroutines Flow loves coroutine also because it’s built on top of it
53. fun loadFromDatabase(): String { // Heavy operation of fetching from DB return "Very heavy " } Let’s say you have a function which loads some data from database, since this operation takes time to perform you’d ideally want to perform it in the background thread by marking it as suspend
54. suspend fun loadFromDatabase(): String { // Heavy operation of fetching from DB return "Very heavy " } And the funny thing is
55. suspend fun loadFromDatabase(): String { // Heavy operation of fetching from DB return "Very heavy " } fun stream() = flow { val value = loadFromDatabase() emit(value) } you can just directly call any coroutine function inside the `flow` block
56. suspend fun loadFromDatabase(): String { // Heavy operation of fetching from DB return "Very heavy " } fun stream() = flow { val value = loadFromDatabase() emit(value) } public fun <T> flow(@BuilderInference block: suspend FlowCollector<T>.() -> Unit): Flow<T> That’s because the `flow` block accepts a suspending lambda and also because the both the collector and emitter are suspend functions which is just great!
57. Principles of Flow Let’s take a look at core ideology of Flow and how they make our life easier
58. fun main() = runBlocking { flow { emit("Context") } .flowOn(Dispatchers.IO) } With Flow you can define or switch the thread by using the operator called as `flowOn` which takes in a dispatcher which in this case is IO.
59. fun main() = runBlocking { flow { emit("Context") // IO thread } .flowOn(Dispatchers.IO) } ‐ This operator sets the specified this thread only upstream i.e anything above the `flowOn` operator will run on IO thread.
60. fun main() = runBlocking { flow { emit("Context") // IO thread } .flowOn(Dispatchers.IO) .map { "$it Preservation" } } The map operator below the `flowOn` will run on some different thread and not IO thread
61. Context Preservation This concept of preventing context from leaking is called as “Context Preservation” where the context is encapsulated and it’s never allowed to go downstream ⬇ . There is only one way to change the context of a flow
62. Observable.just("") .map{ /* IO thread */ } .subscribeOn(Schedulers.io()) .map{ /* IO thread */ } .subscribeOn(Schedulers.computation()) .map{ /* IO thread */ } RxJava example If you compare this to RxJava where it’s super confusing especially for beginners to understand which thread their code is going to run on. In the example above you can see that only the first `subscribeOn` is applied and other one is ignored
63. Observable.just("") .map{ /* IO thread */ } .subscribeOn(Schedulers.io()) .map{ /* IO thread */ } .subscribeOn(Schedulers.computation()) .map{ /* IO thread */ } .observeOn(Schedulers.computation()) .map { /* */ } RxJava example Combined with another operator to change thread i.e `observeOn` with different behaviour, it’s a facepalm moment
64. Exception Transparency ☢ This is the 2nd principle or ideology of Flow. Flow implementations never catch or handle exceptions that occur in downstream ⬇ flows, they catch only for upstream ⬆ ; this is again due to context preservation. There is only 1 operator to catch error which is the `catch` operators. Let’s look at an example
65. flow { val value = loadFromDatabase() emit(value) } Let’s take the previous example of a flow which tries to get the value from the database and emit. As you can imagine anything can happen while loading from database which might throw some sort of exception
66. flow { val value = loadFromDatabase() emit(value) } .catch { emit("Fallback value") } Very similar to try/catch block, flow has a `catch` operator which will catch the any exceptions thrown above
67. flow { try { val value = loadFromDatabase() emit(value) } catch (e: Exception) { emit("Fallback value") } } You can even use the classic try/catch block, it will behave exactly similar to the catch operator
68. flow { try { val value = loadFromDatabase() emit(value) } catch (e: Exception) { when (e) { is CancellationException -> throw e else -> emit("Fallback value") } } } I’d recommend to use the catch operator but there are can be use-cases. During those time just make sure to ignore the `CancellationException` because you don’t want to emit an error when your flow or coroutine was cancelled when the activity was closed or something. This is pretty how the catch operator works internally
69. flow { try { val value = loadFromDatabase() emit(value) } catch (e: IOException) { emit("Fallback value") } } Or you can specifically handle the exception you expect to see. For example, in case of database operation you’d specifically want to exception related to IO operation.
70. flow { val value = loadFromDatabase() emit(value) } .catch { emit("Fallback value") } .collect { } The value emitted from the catch is received in the collect, that means there is only a single place to handle all types of cases either success or failure which makes it super transparent to handle all the cases
71. sealed class State { object Success: State() object Failure: State() } fun main() = runBlocking { flow<State> { emit(State.Success) } .catch { emit(State.Failure) } .collect { state -> when (state) { State.Success -> println("Success") State.Failure -> println("Failure") } } } Ex Example I’d recommend to toss in sealed classes so you always cover all your cases
72. “- Use suspend for one-shot operations like insert operation or a network operation - Use Flow<T> to get stream of data like getting updates on data changes in the database.” It might be confusing to understand when to use suspend and when to use `Flow`.
73. “- Use suspend for one-shot operations like insert operation or a network operation - Use Flow<T> to get stream of data like getting updates on data changes in the database.” The general rule of thumb is use `suspend` for one-shot operations like insert into database operation or a network operation.
74. “- Use suspend for one-shot operations like insert operation or a network operation - Use Flow<T> to get stream of data like getting updates on data changes in the database.” And use Flow when there is stream of data involved, for example get data from the database and continuously listening for updates.
75. Channels
76. Channels are communication primitives
77. Channels are communication primitives Source And they allow to send and receive data between different coroutines. The idea is to use communication for sharing information instead of shared mutable memory
78. Source Channels are communication primitives A coroutine that sends (produces) information is often called a producer, and a coroutine that receives (consumes) information is called a consumer.
79. Channels are hot in nature Channels are hot in nature hence they are not always the best candidate to use
80. Channels are low level primitives Channels are low level primitives and Kotlin Flow internally is built using coroutines and channels. Generally you should try using Flow for your use cases just because with channels you need to be a bit careful with it’s hot nature, cancellation, etc.
81. private val searchQueryChannel = ConflatedBroadcastChannel<String>() Let’s take an example of a search application, where the app needs to show some results after the user enters the search query; for which we will use the ConflatedBroadcastChannel
82. private val searchQueryChannel = ConflatedBroadcastChannel<String>() which is basically a broadcast channel or send channel i.e it allows to broadcast or send values
83. private val searchQueryChannel = ConflatedBroadcastChannel<String>() and Conflated means only recent values are emitted and every subscriber immediately receives the most recently sent element
84. // On text change searchQueryChannel.send("Bob the builder ") private val searchQueryChannel = ConflatedBroadcastChannel<String>() And somewhere from your activity or fragment when the search text changes, you’d call the send function on the channel which will emit a new value to it’s observers
85. // On text change searchQueryChannel.send("Bob the builder ") private val searchQueryChannel = ConflatedBroadcastChannel<String>() searchQueryChannel .asFlow() /* Get the results for the search query */ .distinctUntilChanged() .collect { // Render the result on UI } On the receiving end, you can convert the channel to Flow and do some map operation to get the result for the specified search query, take only unique results using distinctUntilChanged and finally render the result on the UI
86. StateFlow But like I said Channels are low level and you should try to use Flow and Kotlin team is working on this, one such class is available to us is StateFlow. StateFlow is a new primitive and it’s designed to emit updates to it’s collectors and it will eventually replace ConflatedBroadcastChannel we just saw
87. private val searchQueryFlow = MutableStateFlow<String>("") It’s pretty similar to the previous example, there is StateFlow and MutableStateFlow, the difference is Mutable one allows setting the value to the Flow. Make sure to always expose StateFlow outside to avoid side effects
88. private val searchQueryFlow = MutableStateFlow<String>("") // On text change searchQueryFlow.value = "Bob the builder " On text change, we will set the value to the flow and whenever this value is updated, the collectors will receive it
89. private val searchQueryFlow = MutableStateFlow<String>("") // On text change searchQueryFlow.value = "Bob the builder " searchQueryFlow /* Get the results for the search query */ .collect { // Render the result on UI } And then like every other flow, we can just directly collect it and listen to the updates.
90. private val searchQueryFlow = MutableStateFlow<String>("") // On text change searchQueryFlow.value = "Bob the builder " searchQueryFlow /* Get the results for the search query */ .distinctUntilChanged() .collect { // Render the result on UI } One key thing to remember is the operator distinctUntilChanged is automatically applied StateFlow. The IDE will warn you if you forget so that’s good
91. Legacy ➡ Flow A lot of the codebases are stuck with legacy code either callbacks, RxJava 1, loaders or other old asynchronous programming APIs and it’s totally fine! If it’s working it’s great but the problem lies with slower and hard code maintenance and refactoring when there is a (new) requirement. This slows the efficiency and the velocity ⏩ of developing the given requirement.
92. Setup migration process There are 2 major things to do for migration, first is setting up the process with the team is super important … (little pause) so the whole team works towards the single goal of migration There is no rule of thumb here, these are just my recommendations
93. Discuss with your team First order of business is to discuss within your team and trying to figure what alternative to pick, that works for your team and the use-case you are trying to solve. I’d recommend doing as followed to get started and decide what other tool suits the best for your codebase:
94. Discuss with your team Setup a meeting - Setup a meeting with the team and list out all the possible alternatives like RxJava 2, 3 or Flow. Discuss the pros — cons — advantages of all the options
95. Discuss with your team Setup a meeting Getting comfortable It’s best if the team gets to try out and get comfortable with the option you all like, this might include doing a small sample app, giving an internal presentation, articles, talks, etc.
96. Discuss with your team Setup a meeting Getting comfortable Evaluate It’s also important to evaluate how hard the migration of certain option looks like for your codebase, the learning curve for new joiners to the team. For instance, we at Clue migrated from RxJava 1 to Flow and we had evaluated RxJava 2 and 3 at that time and for our codebase it would have been super hard and we really liked Flow and everyone felt comfortable with it
97. Discuss with your team Setup a meeting Getting comfortable Evaluate Set the common goal At the end of this, you have a common goal in mind; for example migrate from RxJava 1 to Flow.
98. Setup foundation ⛩ Setting up the foundation is very key to the whole migration because it’s what will motivate the team to write the new code in Flow or whatever is decided. You don’t want any developer to start thinking to write the new feature in Flow and then realise there is no testing framework which will make the developer go back into comfort zone since all of us are humans.
99. Setup foundation ⛩ Setup guidelines Setup guidelines with standard practices of how team decided to use Flow throughout the codebase
100. Setup foundation ⛩ Setup guidelines Setup the necessary base classes Setup the necessary base classes for your codebase and to work with your architecture including the dependencies
101. Setup foundation ⛩ Setup guidelines Setup the necessary base classes Setup the testing framework Setup the testing framework / utilities so it’s easier to do get started and do testing like setting up the dispatchers
102. Setup foundation ⛩ Setup guidelines Setup the necessary base classes Setup the testing framework Expose common features as Flow Each codebase has some base APIs which are commonly used by features like getting the user details. It’s ideal if those base APIs are exposed as Flow equivalent functions
103. Expose common features as Flow interface UserRepository { // Legacy function fun observeUser(): Observable<User> } Let’s say you have this existing interface which exposes an Observable of user. One approach is to convert this function to return Flow or coroutine which is great if it’s possible, but it not be feasible always
104. Expose common features as Flow interface UserRepository { // Legacy function fun observeUser(): Observable<User> // Flow equivalent of [observeUser]. fun getUser(): Flow<User> } Another approach is to duplicate those base APIs and expose the duplicated API as Flow or coroutine
105. Expose common features as Flow interface UserRepository { // Legacy function @Deprecated( message = "Use the flow equivalent -> getUser()", replaceWith = ReplaceWith("getUser()", "<package>") ) fun observeUser(): Observable<User> // Flow equivalent of [observeUser]. fun getUser(): Flow<User> } ☠ Mark the legacy function as @Deprecated so everyone uses the new function and avoids the legacy one ☠ And eventually with time as everyone uses the new function, you can remove the legacy function Try to extract the business logic so the existing function and new Flow function shares the same logic preventing updating it twice when needed
106. Setup safeguards ☢ Now that we are super motivated to write Kotlin Coroutines, Safeguards will prevent kinda force the team to write more and more code in Kotlin Flow / Coroutines and also convert the legacy code.
107. Setup safeguards ☢ • Ensuring that the new code is written using Kotlin Coroutines while doing the PR reviews • Ensuring when the legacy code is touched, the developer has tried to convert it coroutines or flow • Monthly or quarterly checking of progress of the gradual migration • And other ideas which will pop in your brilliant minds Each codebase has some base APIs which are commonly used by features like getting the user details. It’s ideal if those base APIs are exposed as Flow equivalent functions
108. Interoperability The key to success of Java-Kotlin migration was interoperability and ease of using one from another which opened the doors for gradual migration. Similarly having this ability allows to quickly interop between the legacy code and Flow or Coroutines which can drastically change the landscape and Flow provides an amazing API to covert any legacy callback based API to Flow
109. fun updateOnDocumentChange(document: Document) { val listener = Document.ChangeListener { updateUI(it) } document.addChangeListener(listener) } Let’s say you have a function which has a listener which is triggered each time the document is updated.
110. fun updateOnDocumentChange(document: Document) { val listener = Document.ChangeListener { updateUI(it) } document.addChangeListener(listener) } removeChangeListener(listener) You need to make sure to remove this listener when the component is destroyed for example when activity is destroyed
111. fun Document.awaitChange(): Flow<Document> = callbackFlow { } Flow provides an API called as `callbackFlow`
112. fun Document.awaitChange(): Flow<Document> = callbackFlow { val listener = Document.ChangeListener { } addChangeListener(listener) } Where you can write the legacy listener aka callback
113. fun Document.awaitChange(): Flow<Document> = callbackFlow { val listener = Document.ChangeListener { offer(it) } addChangeListener(listener) } And offer which basically means emit this value each time the document is changed. But you also need to remove the listener at some point right?
114. fun Document.awaitChange(): Flow<Document> = callbackFlow { val listener = Document.ChangeListener { offer(it) } addChangeListener(listener) awaitClose { removeChangeListener(listener) } } You can use the function `awaitClose` which is called when the flow or coroutine is cancelled, where we can safely remove the listener
115. /** * Listen for changes in the [Document] and notify the * receivers about changes. */ fun Document.awaitChange(): Flow<Document> = callbackFlow { val listener = Document.ChangeListener { offer(it) } addChangeListener(listener) awaitClose { removeChangeListener(listener) } } Finally with code comments it looks something like this which a lot of people forget to write
116. Rx ➡ Flow Let’s look at how you can migrate from Rx to Flow, the goal here is to not tell you to go next moment and migrate your codebase to Flow [I mean that would be great for your own projects].
117. Reactive Stream Specification Flow Rx Flow and Rx follow the same reactive stream specification so in theory it’s very easy to convert data streams from Rx to Flow and the reverse
118. https://github.com/Kotlin/kotlinx.coroutines/tree/master/reactive/kotlinx-coroutines-rx2 fun flow(): Flow<String> { return Observable.just("a") .asFlow() } There are two ways to convert, 1st is like refactor your Rx implementation to use flow but that’s time confusing and sometimes you just want to switch types so you can gradually move to flow. In that cases you can use the `asFlow` extension function to quick switch the type from `Flowable` / `Observable` to `Flow`
119. fun observable(): Observable<String> { return flow { emit("a") }.asObservable() } https://github.com/Kotlin/kotlinx.coroutines/tree/master/reactive/kotlinx-coroutines-rx2 fun flow(): Flow<String> { return Observable.just("a") .asFlow() } Same can be done to convert flow to observable or flowable when you need it
120. Rx Coroutines Single / Completable / Maybe suspend function Observable Flow Subject Channel Schedulers Dispatchers Disposables Scopes subscribe collect Terminology between Rx and Coroutine world Here’s a quick comparison of terminology between Rx and coroutine which I stole from Clue’s documentation. In my defence I created this table at Clue Use this chart as a reference when you are new to coroutines world or working on migrating from Rx to coroutines or reverse. Now that see, we pretty much covered all the things mentioned.
121. Fun part Let’s look at something really fun
122. public fun <T: Any> ObservableSource<T>.asFlow(): Flow<T> = callbackFlow { val observer = object : Observer<T> { override fun onComplete() { close() } override fun onSubscribe(d: Disposable) { .. } override fun onNext(t: T) { sendBlocking(t) } override fun onError(e: Throwable) { close(e) } } subscribe(observer) awaitClose { /* Dispose */ } } The `asFlow` function actually uses `callbackFlow` to convert observable to flow which is soooo cool
123. Rx1 ➡ Flow https://github.com/AkshayChordiya/kotlinx.coroutines-rx1 If your codebase is stuck with RxJava 1 and you want to move away. I’d recommend to migrate to Kotlin Flow rather than RxJava 2 / 3. Since RxJava 1 bindings are not officially supported. I have created a library for those need it.
124. import rx.Observable fun observable(): Observable<String> { return flow { emit("a") }.asObservable() } import rx.Observable fun flow(): Flow<String> { return Observable.just("a") .asFlow() } https://github.com/AkshayChordiya/kotlinx.coroutines-rx1 It offers the API for RxJava 1 types to coroutines and also API for Flow and Observable almost similar to RxJava 2
125. Testing Now to everyone’s favourite topic - testing Testing flow or coroutine is pretty easy
126. @RunWith(JUnit4::class) class TestingWithFlow { fun getFlow() = flow { emit("Bob the builder ") } } Let’s take a simple flow of string
127. @RunWith(JUnit4::class) class TestingWithFlow { fun getFlow() = flow { emit("Bob the builder ") } @Test fun testFlow() = runBlocking { } } And write the test function and use the `runBlocking` coroutine scope because we want our test to wait till the coroutine is completed
128. @RunWith(JUnit4::class) class TestingWithFlow { fun getFlow() = flow { emit("Bob the builder ") } @Test fun testFlow() = runBlocking { val expected = listOf("Bob the builder ") val actualList = getFlow().take(1).toList() // Assert the list assertEquals(expected, actualList) } } Like I said Flow is similar to a list or a collection
129. @RunWith(JUnit4::class) class TestingWithFlow { fun getFlow() = flow { emit("Bob the builder ") } @Test fun testFlow() = runBlocking { val expected = listOf("Bob the builder ") val actualList = getFlow().take(1).toList() // Assert the list assertEquals(expected, actualList) } } So you can use `take(1)` operator to pick the 1st value from the stream
130. @RunWith(JUnit4::class) class TestingWithFlow { fun getFlow() = flow { emit("Bob the builder ") } @Test fun testFlow() = runBlocking { val expected = listOf("Bob the builder ") val actualList = getFlow().take(1).toList() // Assert the list assertEquals(expected, actualList) } } and then convert the flow to list so you can easily assert it
131. /** * Asserts only the [expected] items by just taking that many from the stream */ suspend fun <T> Flow<T>.assertItems(vararg expected: T) { assertEquals(expected.toList(), this.take(expected.size).toList()) } Or use this extension function which I again stole from our Clue code
132. @RunWith(JUnit4::class) class TestingWithFlow { fun getFlow() = flow { emit("Bob the builder ") } @Test fun testFlow() = runBlocking { val expected = "Bob the builder " // Assert the list getFlow().assertItems(expected) } } With the extension function it would be something like this, much more cleaner
133. Conclusion
134. Conclusion • Revisited coroutines • Why Flow? And what makes it special? • Basics of Flow • Principles of Flow • Legacy code -> Flow • Testing • Pro-tips along the way Here’s a quick summary what you learned today - We revisited coroutines - We saw why Kotlin Flow came into the picture and what makes it special - We saw basics of Flow i.e the emitter and collector and how they work internally - Principles of Flow i.e context preservation and exception transparency and how they make our lives easy - then how to convert Rx or Legacy code to Flow - How you can test flows - And some pro-tips along the way
135. Me “Kotlin Flow raises the bar and introduces easy reactive streaming, that said it’s work in progress and lots of exciting things are coming sooooooon ” Final thoughts To conclude Kotlin Flow raises the bar and makes reactive programming easy, gives us great Kotlin features. That said it’s still work in progress and lots of exciting things are coming soooon.
136. Further resources • News App https://github.com/AkshayChordiya/News • Go with the Kotlin Flow https://medium.com/google-developer-experts/go-with-the- kotlin-flow-7067564665a3 • Migrating from legacy code to Kotlin Flow https://medium.com/@aky/migrating-legacy-code-to-kotlin- flow-3f3e1854925
137. Also make sure to check out the Kotlin online event to hear new updates on Kotlin Flow and coroutines
138. Thank You https://bit.ly/2Favsdn Below the feedback link to my talk if you want to give one, the QR code does the same. And yeah thank you so much!