Breaking up with RxJava (Kotlin Coroutines & Channels)

Held on 26th June 2018 Kotlin Zagreb Meetup:
https://www.meetup.com/Kotlin-Zagreb/events/251748671/

When RxJava came along, it made our lives so easy that most Android developers jumped ship.
Soon, it was everywhere and everything was a stream. But was that really a good idea?
Now that we have Kotlin, a lot of painpoints solved by (ab)using RxJava are solvable by using plain Kotlin (well, experimental) coroutines.
So should we be jumping ship again? What makes Kotlin a better solution for most of your problems?
In this talk we’ll take a dive into some of Kotlin’s coroutine features and find out how, when and why to say “No” to RxJava.

Transcript

4. Breaking up with Rx
5. Breaking up with Rx Ian Rumac Software Architect @ Undabot
6. The story so far
7. What RxJava gives us:
 The Good Parts
8. What RxJava gives us:
 The Good Parts • Easy stream manipulation • Simple concurrency • Chained operators • Observing state changes • Combining operators
9. What RxJava gives us:
 The Good Parts • Easy stream manipulation • Simple concurrency • Chained operators • Observing state changes • Combining operators
10. And we subscribed({});
11. And all was good.
19. What RxJava gives us:
 The Bad Parts
20. • One library that spans across all layers
 (remember migrating?) • One library which you shape your code around • One paradigm you force everything into • One naming style • One extra layer of complexity • Code • Mental What RxJava gives us:
 The Bad Parts
21. • One library that spans across all layers
 (remember migrating?) • One library which you shape your code around • One paradigm you force everything into • One naming style • One extra layer of complexity • Code • Mental What RxJava gives us:
 The Bad Parts
22. The core
23. • Is your business logic wrapped in Rx? • Is your business logic a stream? 
 (not a stream of one ) • Why do you represent the core logic of your app with a stream if it isn’t one? The core
24. So, what can we do about it?
25. Replacing the operator magic
26. Replacing the operator magic • Collection extensions already in stdlib
27. Replacing the operator magic • Collection extensions already in stdlib
28. Replacing the operator magic • Collection extensions already in stdlib
29. Replacing the operator magic • Collection extensions already in stdlib • Easy to write your own
30. Replacing the operator magic • Collection extensions already in stdlib • Easy to write your own
31. Replacing the operator magic • Collection extensions already in stdlib • Easy to write your own
32. Replacing the operator magic • Collection extensions already in stdlib • Easy to write your own • Receiver lambdas
33. Replacing the operator magic • Collection extensions already in stdlib • Easy to write your own • Receiver lambdas
34. Replacing the operator magic • Collection extensions already in stdlib • Easy to write your own • Receiver lambdas
35. Replacing the operator magic • Collection extensions already in stdlib • Easy to write your own • Receiver lambdas
36. Observing state changes
37. Observing state changes • Observable delegate
38. Observing state changes • Observable delegate
39. Observing state changes • Observable delegate • Vetoable delegate
40. Observing state changes • Observable delegate • Vetoable delegate
41. Observing state changes • Observable delegate • Vetoable delegate
42. Observing state changes • Observable delegate • Vetoable delegate
43. Observing state changes • Observable delegate • Vetoable delegate • Simple
44. Observing state changes • Observable delegate • Vetoable delegate • Simple • Cover a lot of usecases
45. Observing state changes • Observable delegate • Vetoable delegate • Simple • Cover a lot of usecases
46. Observing state changes • Observable delegate • Vetoable delegate • Simple • Cover a lot of usecases
47. Coroutines
48. Coroutines • Language feature • Lightweight • Context(s) • Easy thread switching
49. Coroutines
50. So just tldr light threads?
51. Coroutines
52. Coroutines • Easy concurrency • Yield! • Nesting and composing • cancelChildren()
53. Composing & Combining • Easy • Human readable • Wrap it any way you want
55. doOne doTwo
57. doOne doTwo
59. doOne doTwo
64. But wait, there’s more!
65. Channels 101
66. Channels 101 • A hot asynchronous stream of elements
67. Channels 101 • A hot asynchronous stream of elements • Rendezvous transfer
68. Channels 101 • A hot asynchronous stream of elements • Rendezvous transfer • Suspending
69. Channels 101 • A hot asynchronous stream of elements • Rendezvous transfer • Suspending • Once it’s consumed, it’s consumed
70. Channels 101 • A hot asynchronous stream of elements • Rendezvous transfer • Suspending • Once it’s consumed, it’s consumed • 1 item at a time
71. Channels 101
72. Channels 101
73. Channels 101
74. Channels 101
75. Channels 101
76. Channels 101
77. Channels of all shapes and sizes! • ArrayChannel - Buffered! • ConflatedChannel - Only the latest element • Ticker channel - Time based operations • BroadcastChannel & ArrayBroadcastChannel “Broadcast channel is a non-blocking primitive for communication between the sender and multiple receivers that subscribe for the elements using [open] function and unsubscribe using [SubscriptionReceiveChannel.close] function.” ReceiveChannel<T>
79. … well I still need my operators…
80. … well I still need my operators…
81. … well I still need my operators…
82. … well I still need my operators…
83. … well I still need my operators…
84. … well I still need my operators…
85. … well I still need my operators…
86. … well I still need my operators…
88. …that’s all nice, but how do I test it?
89. …that’s all nice, but how do I test it? Just like any other code. (Context = Unconfined)
90. Thinking about dumping your old library?
91. Thinking about dumping your old library? • KotlinX Coroutines Rx 1&2 • Kotlin Coroutine (Experimental) Retrofit Adapter • Still experimental! • Wrap the boilerplate
92. Conclusion
93. Conclusion Kotlin > RxJava
94. Conclusion
95. Conclusion Q & A?
97. Thank you for your time! Ian Rumac Software Architect @Undabot