Droidcon Italy 2018 Slides - Dispatching Reactive State

1. UI Navigation
Mike Nakhimovich

2. Dispatching State
Mike Nakhimovich

3. Apps have a UI

4. Apps have a UI
Search View

5. Apps have a UI
Search View
ResultsView

6. Apps have a UI
Search View
ResultsView
ErrorView

7. Apps have a UI
Search View
ResultsView
ErrorView
LoadingView

8. Users interact with the UI
Pizza

9. Interactions lead to State change
Pizza

10. Pizza
Interactions lead to State change

11. PizzaPizza
State change need to be rendered

12. What is state?

13. A representation of UI
at a certain point in time
What is state?

14. State determines how the
UI renders & behaves

15. Android lacks patterns for
working with state & views

16. How to create state

17. How to pass state

18. How to hold state

19. How do we think about state?

20. data class ScreenState(
val searchResults:List<Results>,
val searchTerm:String,
val isLoading:Boolean)
Example: state modeled as a single data class

21. data class ScreenState(
val searchResults:List<Results>,
val searchTerm:String,
val isLoading:Boolean,
val CartItems:List<Items>,
val userId:Long
Example: state modeled as a single growing data class

22. data class ScreenState(
val searchResults:List<Results>,
val searchTerm:String,
val isLoading:Boolean,
val CartItems:List<Items>,
val userId:Long
State modeled as a God class

23. Android devs love being reactive,
why not represent state as a stream?

24. Lately, I’ve been using a
centralized dispatcher to model
state as a reactive stream

25. What’s a dispatcher?

26. A dispatcher is an object that receives
and sends messages about state

27. that the UI reacts to
A dispatcher is an object that receives
and sends messages about state

28. Why a state dispatcher?

29. Decouple producers of state
change from its consumers
Why a state dispatcher?

30. Journey to dispatcher

31. User types a search term
Pizza

32. User clicks search
Pizza

33. Loading should become visible
Pizza

34. Followed by results
Pizza

35. Pizza
Proposal 1: Encapsulate Screen
in a ScreenPresenter
How do we tell views what to display?

36. PizzaScreen Presenter
SearchView ResultsView
Pizza
Proposal 1: Encapsulate Screen
in a ScreenPresenter
How do we tell ResultsViews what to display?

37. Pizza
But then… Product adds another view
PizzaScreen Presenter
SearchView ResultsViewLoadingView

38. And then… Product adds 3 more views
Pizza
PizzaScreen Presenter
SearchView ResultsViewLoading
ProfileTab DrawerViewCartView

39. Proposal 1: Create a ScreenPresenter
which contains both Presenters
How do we tell ResultsView what to display?
Pizza
Not very scalable

40. How do we tell ResultsView what to display?
Pizza
Proposal 2: Create a Listener

41. Proposal 2: Create a Listener
Pizza
SearchViewResultsView
Listens To

42. Proposal 2: Create a Listener
SearchViewResultsView
Listens To
LoadingView
ListensTo
Listens
To

43. Proposal 2: Create a Listener
Listeners lead to circular dependencies

44. Last Proposal
Use a centralized dispatcher
for ALL state change

45. A Dispatcher is responsible for receiving
state changes and emitting them
Use a centralized dispatcher
for ALL state change

46. Why a state dispatcher?

47. Views become coupled to the dispatcher not each other
SearchViewResultsView LoadingView
Dispatcher

48. Reactive state
UI creates new state

49. Reactive state
UI reacts to new state

50. Reactive state
With no hard references between UI
elements

51. Reactive state
Push rather than pull

52. Implementing reactive state

53. Reactive state
Sealed class State{
data class ShowingLoading():State
data class ShowingResults(val results:List<String>):State
data class ShowingError(val error:Error):State
}
Represent your state as immutable value objects

54. Reactive state
Push new state through a reactive stream
Interface Dispatcher
fun dispatch(state: State)
}
interface RxState {
fun <T> ofType(clazz: Class<T>): Observable<T>
}
Sealed class State{
data class ShowingLoading():State
data class ShowingResults(val results:List<String>):State
data class ShowingError(val error:Error):State
}

55. Reactive state
Anytime UI needs to change, dispatch a new state
dispatcher.dispatch(State.ShowingResults(resultData)
dispatcher.dispatch(State.ShowingLoading()
dispatcher.dispatch(State.ShowingError(errors)

56. Reactive state
Anytime state changes, react to new state
rxState.ofType(State.Results)
.map{it.data}
.subscribe{ mvpView.updateUI(data) }

57. Rather than tightly coupling Search & Results
we decouple them with a dispatcher

58. Reactive state visualized
Dispatcher

59. Reactive state
ResultsPresenter Subscribes to ShowResults states change
Dispatcher
ResultsPresenter

60. Reactive state
LoadingPresenter Subscribes to ShowLoading states change
Dispatcher
ResultsPresenter
LoadingPresenter

61. Reactive state
Dispatcher
SearchPresenterSearchView
SearchTerm

62. Reactive state
Dispatcher
SearchPresenterSearchView
SearchTerm
ShowingLoading

63. Reactive state
Dispatcher
SearchPresenterSearchView
SearchTerm
ShowingLoading

64. Reactive state
Dispatcher
SearchPresenterSearchView
SearchTerm
ShowingLoading

65. Reactive state
Dispatcher
SearchPresenterSearchView
SearchTerm
ShowingLoading
LoadingPresenter

66. Reactive state
Dispatcher
SearchPresenterSearchView
SearchTerm
ShowingLoading
LoadingPresenter

67. Reactive state
Dispatcher
SearchPresenterSearchView
SearchTerm

68. Reactive state
Search Presenter calls dispatcher.dispatch(State.ShowingResults(resultData)
Dispatcher
SearchPresenterSearchView
SearchTerm
ShowingResults

69. Reactive state
Dispatcher needs to emit a new State to subscribers
Dispatcher
SearchPresenter
ResultsPresenter
SearchView
SearchTerm
ShowingResults

70. Reactive state
Dispatcher Emits new ShowingResults State to ResultsPresenter
Dispatcher
SearchPresenter
ResultsPresenter
SearchView
SearchTerm
ShowingResults

71. Reactive state
Dispatcher Emits new ShowingResults State to subscribers
Dispatcher
SearchPresenterSearchView
SearchTerm
ShowingResults
ResultsPresenter

72. Reactive state
Dispatcher Emits new ShowingResults State to subscribers
Dispatcher
SearchPresenter
ResultsPresenter
SearchView
SearchTerm
ResultsView
ShowingResults

73. Reactive state
Multiple Views can listen to same state change Dispatcher
SearchPresenterSearchView
SearchTerm
ResultsPresenterResultsView
LoadingPresenterLoadingView

74. Reactive state
Dispatcher
SearchPresenterSearchView
ShowingResults
LoadingPresenterLoadingView
ResultsPresenterResultsView

75. Reactive state
Dispatcher
SearchPresenterSearchView
ShowingResultsShowingResults
LoadingPresenterLoadingView
ResultsPresenterResultsView

76. Reactive state
Dispatcher
SearchPresenterSearchView
ShowingResults
ShowingResults
LoadingPresenterLoadingView
ResultsPresenterResultsView

77. Reactive state
Dispatcher
SearchPresenterSearchView
ShowingResults
ShowingResults
LoadingPresenterLoadingView
ResultsPresenterResultsView

78. Reactive state
Dispatcher
SearchPresenterSearchView
ShowResults
Hide View
LoadingPresenterLoadingView
ResultsPresenterResultsView

79. Interacting with a dispatcher

80. Pizza
override fun attachView(view: NearYouMVPView) {
rxState.ofType(State.Results)
.map{it.data}
.subscribe{ mvpView.updateUI(data) }
}
Presenter subscribes on attach

81. Another presenter dispatches state change
Pizza
fun searchFor(searchTerm:String){
store.getResults(searchTerm)
.subscribe{dispatcher.dispatch(State.Results(data=it.results)}

82. Dispatcher emits state change
Pizza
fun searchFor(searchTerm:String){
store.getResults(searchTerm)
.subscribe{dispatcher.dispatch(State.Results(data=it.results)}
override fun attachView(view: NearYouMVPView) {
rxState.ofType(State.Results)
.map{it.data}
.subscribe{ mvpView.updateUI(data) }
}

83. Consumers & Producers of state stay decoupled
Pizza
fun searchFor(searchTerm:String){
store.getResults(searchTerm)
.subscribe{dispatcher.dispatch(State.Results(data=it.results)}
override fun attachView(view: NearYouMVPView) {
rxState.ofType(State.Results)
.map{it.data}
.subscribe{ mvpView.updateUI(data) }
}

84. How does data flow?

85. Reactive state
Dispatcher
SearchPresenterSearchView
ResultsPresenterResultsView

86. Reactive state
Dispatcher
SearchPresenterSearchView
ResultsPresenterResultsView
ShowingResults1

87. Reactive state
Dispatcher
SearchPresenterSearchView
ResultsPresenterResultsView
ShowingResults1

88. Reactive state
Dispatcher
SearchPresenterSearchView
ResultsPresenterResultsView
ShowingResults1

89. Reactive state
Dispatcher
SearchPresenterSearchView
ResultsPresenterResultsView ShowingResults1

90. Reactive state
Dispatcher
SearchPresenterSearchView
ResultsPresenterResultsView
ShowingResults2

91. Reactive state
Dispatcher
SearchPresenterSearchView
ResultsPresenterResultsView
ShowingResults2

92. Reactive state
Dispatcher
SearchPresenterSearchView
ResultsPresenterResultsView
ShowingResults2

93. Reactive state
Dispatcher
SearchPresenterSearchView
ResultsPresenterResultsView ShowingResults2

94. Reactive state
Dispatcher
SearchPresenterSearchView
ResultsPresenterResultsView
CartPresenter

95. More state
Dispatcher
SearchPresenterSearchView
ResultsPresenterResultsView
CartPresenter
Add To Cart

96. Dispatcher
SearchPresenterSearchView
ResultsPresenterResultsView
CartPresenter
Add To Cart
More state

97. Dispatcher
SearchPresenterSearchView
ResultsPresenterResultsView
CartPresenter
Add To Cart
More state

98. Dispatcher
SearchPresenterSearchView
ResultsPresenterResultsView
CartPresenter
Add To Cart
More state

99. Dispatcher
SearchPresenterSearchView
ResultsPresenterResultsView
CartPresenterCartView
Add To Cart
More state

100. Dispatcher
SearchPresenterSearchView
ResultsPresenterResultsView
CartPresenterCartView
Add To Cart
More state

101. Emitting data is nice…
How about showing/hiding views?

102. When user clicks on cart, we
should show the cart view
HomeScreen
SearchView ResultsViewCartView

103. How?

104. We can combine state changes
through composition

105. Showing states
sealed class State {
object Cart : State()
data class Showing(val state: State) : State()
}

106. Showing states
dispatcher.dispatch(State.Showing(Cart))
sealed class State {
object Cart : State()
data class Showing(val state: State) : State()
}

107. Showing states
rxState.showing(Cart::class.java))
.subscribe({
mvpView.showCart()
}))
interface RxState {
fun showingNot(clazz: Class<out Screen>): Observable<Showing>
fun showing(clazz: Class<out Screen>): Observable<Showing>
}

108. We can show/hide views based on showing states
rxState.showingNot(Cart::class.java))
.subscribe({
mvpView.hide()
}))
rxState.showing(Cart::class.java))
.subscribe({
mvpView.showCart()
}))

109. Dispatching showing cart
rxState.showingNot(Cart::class.java))
.subscribe({
mvpView.hide()
}))
dispatcher.dispatch(State.Showing(Cart)) rxState.showing(Cart::class.java))
.subscribe({
mvpView.showCart()
}))

110. Dispatching Showing Checkout
Checkout
rxState.showingNot(Cart::class.java))
.subscribe({
mvpView.hide()
}))
dispatcher.dispatch(State.Showing(Checkout)) rxState.showing(Cart::class.java))
.subscribe({
mvpView.showCart()
}))

111. Showing/hiding works well
when all views attached

112. Not very scalable in real apps
Showing/hiding works well
when all views attached

113. How do we deal with deep flows?

114. How do we deal with deep flows?
Treat screen creation/routing as a state change

115. Dispatching screens workflow

116. Checkout
CartPresenterCartView

117. Checkout
CartPresenterCartView
Go To Checkout

118. Checkout
Screen.Checkout
CartPresenterCartView

119. Checkout
Screen.Checkout
CartPresenterCartView

120. Checkout
ScreenCreator
CartPresenterCartView
Creating(Screen.Checkout)

121. Checkout
ScreenCreator
CartPresenterCartView
Creating(Screen.Checkout)

122. Hidden CheckoutVIew
CartPresenterCartView
Screen.Checkout
ScreenCreator
CheckoutPresenter
CheckoutView

123. Hidden CheckoutVIew
CartPresenterCartView
Showing(Screen.Checkout)
ScreenCreator
CheckoutPresenter
CheckoutView

124. Hidden CheckoutVIew
CartPresenterCartView
Showing(Screen.Checkout)
ScreenCreator
CheckoutPresenter
CheckoutView

125. Hidden CheckoutVIew
CartPresenterCartView
Showing(Screen.Checkout)
ScreenCreator
CheckoutPresenter
CheckoutView

126. CheckoutView
With Data
CartPresenterCartView
Showing(Screen.Checkout)
ScreenCreator
CheckoutPresenter
CheckoutView

127. View tells presenter to go to new screen
presenter.openCart()

128. Presenter dispatches new screen state
sealed class Screen : State() {
data class Checkout(val payload:String) : Screen()
}
dispatcher.dispatch(Screen.Checkout)

129. Dispatcher encapsulates in a creating state
dispatcher.dispatch(Creating(Screen.Checkout))

130. Screen creator creates view/presenter
rxState.creating()
.subscribe({
createScreen(it)
})

131. Dispatches a showing state
rxState.creating()
.subscribe({
createScreen(it)
dispatcher.dispatch(Showing(it.screen))
})

132. Dispatcher adds each showing event to a back stack
override fun dispatch(state: State) {
when (state) {
is Showing->{
backstack.push(state)
rxState.push(state)
}
else -> rxState.push(state)
}
}

133. Dispatcher adds each showing event to a back stack
override fun dispatch(state: State) {
when (state) {
is Showing->{
backstack.push(state)
rxState.push(state)
}
else -> rxState.push(state)
}
}
val backstack: Stack<Showing> = Stack()

134. Dispatcher pushes new state to subscribers
override fun dispatch(state: State) {
when (state) {
is Showing->{
backstack.push(state)
rxState.push(state)
}
else -> rxState.push(state)
}
}

135. Presenter reacts to the showing state
override fun attachView(mvpView: CheckoutMVPView) {
rxState.showing(Screen.Checkout::class.java)
.observeOn(AndroidSchedulers.mainThread())
.subscribe { mvpView.show() }

136. Screens = States
sealed class Screen : State() {
object Search : Screen()
object Cart:Screen()
Data class Checkout(val items:List<Item>) : Screen()
data class Payment(val items:List<Item>) : Screen()
}

137. Routing becomes a state change
sealed class Screen : State() {
object Search : Screen()
object Cart:Screen()
Data class Checkout(val items:List<Item>) : Screen()
data class Payment(val items:List<Item>) : Screen()
}
fun goToSearch() {dispatcher.dispatch(Screen.Search)}
fun openCart() { dispatcher.dispatch(Screen.Cart) }
fun submitNames(firstName: String, lastName: String) {
userRepository.update(firstName, lastName)
.subscribe { dispatcher.dispatch(Screen.CheckoutPayment(cartItems)) }
}

138. Need to go back?

139. Dispatcher.goBack()
override fun onBackPressed() {
dispatcher.goBack()
}
interface Dispatcher {
fun dispatch(state: State)
fun goBack()
}

140. Dispatcher.goBack()
Dispatcher will pop current showing state and
dispatch previous one again
interface Dispatcher {
fun dispatch(state: State)
fun goBack()
}
override fun onBackPressed() {
dispatcher.goBack()
}

141. State Stack = Back Stack
override fun onBackPressed() {
dispatcher.goBack()
}
interface Dispatcher {
fun dispatch(state: State)
fun goBack()
}

142. Back Stack = State Stack
interface Dispatcher {
fun dispatch(state: State)
fun goBack()
}
override fun onBackPressed() {
dispatcher.goBack()
}

143. Routing becomes a state change

144. Every view interaction becomes a state change

145. Your UI becomes a representation
of dispatched state

146. Which is dispatched by your UI

147. TLDR: Your app becomes a cycle

148. TLDR: Your app becomes a cycle
User interacts with view

149. TLDR: Your app becomes a cycle
User interacts with view
View dispatches state change

150. TLDR: Your app becomes a cycle
User interacts with view
View dispatches state change
View reacts to state change

151. TLDR: Your app becomes a cycle
User interacts with view
View dispatches state change
View reacts to state change
User interacts with view

152. github.com/
digitalbuddha/Dispatcher
Big thank you to Efeturi
Money for the UI