Rx: What? Why? How?

With modern applications having a lot of moving parts, asynchrony is ubiquitous! Be it the IO, UI or the database accesses, it has to be fluid for a better user experience. Reactive extensions provides a way to build robust, resilient systems where failures are dealt with elegance rather than disaster.

We take a dive into demystifying Rx; taking a jump into reactive streams & their constructs, junking callbacks in favour of a fluent API, and finding solutions for common problems.

Transcript

2. F R P & Functional Reactive Programming
3. F R P & Functional Reactive Programming
4. F R P & Functional Reactive Programming
5. *stolen inspired from Ragunath’s talk
6. *stolen inspired from Ragunath’s talk
7. Callbacks?* *a completion handler?
8. Callbacks Alamofire.request(req).responseJSON { (response) in switch response.result { case .success: // Store in a database or file systems case .failure(let error): showError() } }
9. Callbacks Alamofire.request(req).responseJSON { (response) in switch response.result { case .success: // Store in a database or file systems case .failure(let error): showError() } }
10. Callbacks! also a “reactive” system
11. “Compositional Event” Systems
12. “Compositional Event” Systems - over discrete time.
13. “Compositional Event” Systems - over discrete time.
14. Rx(*) * Eggs/tomatoes are off limits Ashish Krishnan / @ashishkrishnan Android @ kite.work
15. RxSwift
16. RxJava
17. RxKotlin
18. RxJS
19. Rx.Net
20. Rx(*) * Eggs/tomatoes are off limits What, Why, How ?
21. functional reactive
22. reactive
23. reactive “composable” events
24. reactive “composable” events time
25. functional reactive styles
26. Observer Pattern (or any Publisher-Subscriber patterns)
27. Observer Pattern (or any Publisher-Subscriber patterns) Let’s google maybe?
30. Observer Pattern (or any Publisher-Subscriber like pattern)
34. *spy
35. Reactive Streams* *steroids.
36. Subjects & Observers + can signal “I am done”. Under the hood Reactive Streams!
37. Under the hood Reactive Streams! Subjects & Observers + can signal “I am done”. + can signal error.
38. Observable Observer
39. Observable data error done
40. Observable data error done
41. Observable data error done
42. Observable data error done
43. Observable data error done
44. Observer onNext( onError( onComplete(
45. The Rule onNext(“Hello”) onNext* (onCompleted | onError)?
46. The Rule onNext(“Hello”) onNext(“This is boring”) onNext* (onCompleted | onError)?
47. The Rule onNext(“Hello”) onNext(“This is boring”) onCompleted ( ) onNext* (onCompleted | onError)?
48. The Rule onNext(“Hello”) onNext(“This is boring”) onNext* (onCompleted | onError)?
49. The Rule onNext(“Hello”) onNext(“This is boring”) onNext* (onCompleted | onError)?
50. The Rule onNext(“Hello”) onNext(“This is boring”) onNext* (onCompleted | onError)?
51. The Rule onNext(“Hello”) onNext(“This is boring”) onError( ) onNext* (onCompleted | onError)?
52. A simple chain: Observable .from(1, 2, 2, 2, 5, 6) .map { } .skip(2) .distinct() .doOnEach { } .subscribe { }
53. Observable .from(1, 2, 2, 2, 5, 6) .map { } .skip(2) .distinct() .doOnEach { } .subscribe { } Source-like
54. Observable .from(1, 2, 2, 2, 5, 6) .map { } .skip(2) .distinct() .doOnEach { } .subscribe { } observer
55. Observable .from(1, 2, 2, 2, 5, 6) .map { } .skip(2) .distinct() .doOnEach { } .subscribe { onNext ( onError ( onComplete ( } Remember?
56. Observable .from(1, 2, 2, 2, 5, 6) .map { } .skip(2) .distinct() .doOnEach { } .subscribe { } subscription *upstream
57. Observable .from(1, 2, 2, 2, 5, 6) .map { } .skip(2) .distinct() .doOnEach { } .subscribeOn( /* thread pool */) .subscribe { } subscription utility for threading
58. Observable .from(1, 2, 2, 2, 5, 6) .map { /* multiply $0 by 100 */ } .skip(2) .distinct() .doOnEach { } .subscribe { } transforming data
59. Observable .from(1, 2, 2, 2, 5, 6) .map { } .skip(2) .distinct() .doOnEach { } .subscribe { } filtering
60. Observable .from(1, 2, 2, 2, 5, 6) .map { } .skip(2) .distinct() .doOnEach { } .subscribe { }
61. Observable .from(1, 2, 2, 2, 5, 6) .map { } .skip(2) .distinct() .doOnEach { /* print? */ } .subscribe { } Side-effects
62. Observable .from(1, 2, 2, 2, 5, 6) .map { } .skip(2) .distinct() .doOnEach { } .observeOn( /* main? */ ) .subscribe { } = disposable bag emissions Another utility for threading
63. Cool?
64. Okay!
65. Why?
67. ‘Asynchrony’ is ubiquitous * everywhere
68. ‘Asynchrony’ is I/O reads right to left
69. reads right to left ‘Asynchrony’ is UI
70. ‘Asynchrony’ is db
71. Callbacks Alamofire.request(req).responseJSON { (response) in switch response.result { case .success: // Store in a database or file systems store() { case .success: // do something case .failure: // show error } case .failure(let error): showError() } }
72. Callback Hell Alamofire.request(req).responseJSON { (response) in switch response.result { case .success: // Store in a database or file systems store() { case .success: // do something case .failure: // show error } case .failure(let error): showError() } }
73. www.reactivemanifesto.org
74. 1. Responsive 2. Resilient 3. Elastic 4. Message Driven
75. 1. Responsive 2. Resilient 3. Elastic 4. Message Driven
76. 1. Responsive 2. Resilient 3. Elastic 4. Message Driven
77. 1. Responsive 2. Resilient 3. Elastic 4. Message Driven
78. Failures/Errors are first class
79. Threading?
80. Threading! - abstracted
81. But?
82. How?
83. How? “Unless you can model entire system synchronously, a single async source breaks imperative programming” Jake Wharton
84. How? “Unless you can model entire system synchronously, a single async source breaks imperative programming” Jake Wharton
85. How? “Unless you can model entire system synchronously, a single async source breaks imperative programming” Jake Wharton
86. MV(*) Architecture?
87. MV(*) MVC MVP MVVM MVI ….. ….
88. MVC - 1979 MVP - 1996 MVVM - 2005
89. MVC - 1979 MVP - 1996 MVVM - 2005 ... Android & iPhone: 2007 - 2009
90. MVC - 1979 MVP - 1996 MVVM - 2005 ... Android & iPhone: 2007 - 2009 ... MVI - 2015
91. MVI Model - View - Intent(ion)
92. What now?
93. Look out for libraries?
94. Synchronous | | Asynchronous
95. Synchronous | | Asynchronous
96. Observable.deferred { // sync-work }
97. Observable.deferred { // sync-work } * trick!!!
98. Disposables?
99. Disposables! = dispose bags?
100. ViewController starts
101. ViewController terminates
102. A (has network, IO)
103. A (has network, IO) B (databases)
104. A (has network, IO) B (databases) C (has network, IO)
105. A (has network, IO) B (databases) C (has network, IO) Disposed off on lifecycle
106. More? reactivex.io/rxswift
107. More? reactivex.io/rxswift github.com/ReactiveX/RxSwift/
108. Stalk! David Karnok
109. Stalk! David Karnok Ben Christensen
110. Stalk! David Karnok Ben Christensen Erik Meijer
111. Stalk! David Karnok Ben Christensen Erik Meijer Krunoslav Zaher
112. Stalk! David Karnok Ben Christensen Erik Meijer Krunoslav Zaher Andre Staltz
113. Stalk! David Karnok Ben Christensen Erik Meijer Krunoslav Zaher Andre Staltz Ragunath Jawahar
114. That’s all folks
115. Questions?
116. Thank you @ashishkrishnan