The document provides an introduction to reactive programming concepts using the ReactiveX API. It discusses key reactive programming concepts like observables, observers, and streams that emit values. It shows how to define observables from variables and events, subscribe observers to observables to receive emitted values, and handle asynchronous and threaded behavior. The document also demonstrates how to solve a loading spinner coordination problem between multiple asynchronous requests using reactive programming patterns like combining observables rather than directly manipulating state. It discusses advantages like explicit states, reduced complexity, and error handling but also drawbacks like dependency issues.

1. Reactive programming
Introduction to ReactiveX API
Jianbin LIN
jianbin.lin@live.com

2. ReactiveX
• An API for asynchronous programming with
observable streams

4. Ready ?
Start with some quizzes !

5. Usage of constant
Let result be 3 times of a
let a = 36
result = ?

6. result = 3 * a
108

7. var a = 36
Let result be 3 times of a
Usage of variable
result = ?

8. 108
Usage of variable
result = 3 * a

9. Why ?

10. The value of a variable varies
over time.

11. The value of a variable varies
over time.

12. Variable is NOT one
value, but a stream of
values
36
94
8
19
a
t
Initial value
Current value
result <- a * 3
result is 108
or 57 ?

13. 108
282
24
57
result
t
Initial value
Current value
36
94
8
19
a
t
Initial value
Current value

14. Better ways to use variable
- ask repeatedly
- consume too much system resources
- Annoying !
- call me when there is update
- 1 to many, easy to scale
Poll
Push

15. Observer pattern

16. Observer pattern
Reactive

17. What is an Observable ?
- A stream that emits values
- Observer can subscribe to it
& react to the value it emits

18. The reactive way of using a
variable
onNext: { (newValue)
result = newValue * 3
})
Reactive
variable type
Create the subject
Let observer subscribe
on it
Callback when a is
updated
let a = Variable(36)
a.subscribe(

19. What can be emitted from a
Observable stream ?

20. Any value
Integer
Double
Network request response
Other custom object

21. User event
click
Swipe
Keyboard input
Voice input

22. System event
Low memory notification
function call
remote push notification

23. Questions ?

24. Observable also emits 2 special events
Error
Completion

25. Register call back on error & completion
observableClick.subscribe(onNext: {
(newClick)
// handle the click
},
onError: {
(error)
// handle the error
},
onCompletion: {
// do something when observable is completed
})

26. Timing & Threading
call-backs happens when & where ?

27. By default, synchronous
- callbacks run immediately (blocking)
- on whichever thread elements are
generated

28. By default, synchronous
a.subscribe(onNext: {
(newValue) in
result = newValue * 3
})
a.value = 97
Thread A
Thread B

29. Asynchronous: by scheduler
- callbacks run asynchronously
- on the thread chosen on subscription

30. Asynchronous: by scheduler
anObservable
.observeOn(UIScheduler.instance)
.subscribe(onNext: {
result = newValue * 3
})
a.value = 97
Thread A
Thread B

31. Schedulers
• Serial Dispatch Queue Scheduler
• Concurrent Dispatch Queue Scheduler
• MainScheduler (Serial scheduler)

32. OR
Implement your own
synchronous/asynchronous
scheduler

33. Combine observable

34. Why this is great ?
- Save us from the control flow hell
- Reveal the clear dependency

35. Sum = ?
<- input x
<- input y
<- input z

36. func updateResult() {
run_on_ui_thread{
sum <- x + y + z
display(sum)
}
}
var x = 1
var y = 2
var z = 3
Imperative way

37. func setX(value){
x = value
updateResult()
}
func setY(value){
y = value
updateResult()
}
func setZ(value){
z = value
updateResult()
}
Imperative way

38. combineLatest(x, y, z)
.observeOn(UIScheduler.instance)
.subscribe({
sum = xValue + yValue + zValue
display(sum)
}
Reactive wayx = Variable(1)
y = Variable(2)
z = Variable(3)
One clear dependency
No complex control flow

39. Not bad !
But just toy problem
Questions ?

40. More practical problem

41. Loading….

42. Better to have only one

43. class Spinner{
public var enabled: Bool
}
let spinner = Spinner()
spinner.enabled = true
spinner.enabled = false

44. class Request {
fun makeRequest(callback: Closure)
}

45. Request A
Page loaded
spinner.enabled = true spinner.enabled = false
t

46. Request A
Page loaded
spinner.enabled = true spinner.enabled = false
Request B
spinner.enabled = true spinner.enabled = false
t
t

47. Request A
Page loaded
Request B
t
Request C

48. What are the causes of the
problem ?

49. No explicit states
Requests cannot know the states of
each other.
class Request {
fun makeRequest(callback: Closure)
}

50. Encapsulation is violated
Request A
spinner.enabled = true spinner.enabled = false
t

51. Encapsulation
- Encapsulation is the important

52. Encapsulation is violated
Request A
spinner.enabled = true spinner.enabled = false
t
- All requests are trying to control the spinner
- Spinner is not autonomic

53. Solution
Define explicit states for requests
class Request {
let isLoading: Variable(Bool) = false
fun makeRequest(completion: CallBack)
}

54. Request A
Page loaded
self.isLoading = true self.isLoading = false
Request B
self.isLoading = true self.isLoading = false
t
t
Don’t modify spinner state directly

55. Solution
let spinner itself decide what to do
class Spinner{
private var enabled: Bool
func setUp(){
combineLatest(requestA.isLoading,
requestB.isLoading,
requestC.isLoading)
.observeOn(UIScheduler.instance)
.subscribe({
self.enabled =
requestA.isLoading || requestB.isLoading ||
requestC.isLoading
})
}

56. Pretty good, what else ?
Observable = stream = sequence of values
Does it remind you something ?

57. Functional programming

58. Filter

59. anObservable
.filter{$0 > 10}
.subscribe(onNext: {
// handle filtered value
})

60. Debounce

61. textObservable
.debounce(0.2)
.subscribe(onNext: {
// handle value
})

63. Map

64. anObservable
.map{return $0 * 10}
.subscribe(onNext: {
// handle filtered value
})

65. Why Rx ?
• Encourage to code with explicit states
• Code: less, easier to reason about
• Free error handling infrastructure
• Less complex threading
• Make object more autonomic

66. Drawbacks of Rx
• Hard to trace the source of change
• Dependency cycle
• Deadlock/memory leak

67. My suggestions
• Using Rx wisely can simplify your life
• Use Rx with good architecture in mind
• The goal is to improve code readability NOT to crash it
• Don’t try to do everything in one function

68. Questions ?
What would happen if we put stream into stream ?