[Cesar Valiente] Unidirectional data-flow on Android using Kotlin

Presentation from GDG DevFest Ukraine 2017 - the biggest community-driven Google tech conference in the CEE.

Learn more at: https://devfest.gdg.org.ua

Transcript

1. Unidirectional data flow on Android … using Kotlin @CesarValiente @CesarValiente
2. Unidirectional? A B C D
3. Unidirectional? A B C D
4. Unidirectional? A B C D
5. Unidirectional? A B C D
6. Unidirectional? A B C D
7. History Flux Redux
8. Flux and Redux
9. Flux and Redux Architectures based in unidirectional data flows.
10. Flux and Redux Architectures based in unidirectional data flows. We start in A and we finish in A.
11. Flux and Redux Architectures based in unidirectional data flows. We start in A and we finish in A. Global app state. State has everything the App needs.
12. Flux DISPATCHER STORE VIEW ACTION
13. Flux DISPATCHER STORE VIEW ACTION
14. Flux DISPATCHER STORE VIEW ACTION
15. Flux DISPATCHER STORE VIEW ACTION
16. Flux DISPATCHER STORE VIEW ACTION
17. Flux ACTION DISPATCHER STORE VIEW ACTION
18. Flux ACTION DISPATCHER STORE VIEW ACTION
19. Redux REDUCER VIEW ACTION STORE
20. Redux REDUCER VIEW ACTION STORE
21. Redux REDUCER VIEW ACTION STORE
22. Redux REDUCER VIEW ACTION STORE
23. Redux ACTION REDUCER VIEW ACTION STORE
24. Redux ACTION REDUCER VIEW ACTION STORE
25. Why (are we following this approach) ?
26. ACTION REDUCER VIEW CONTROLLER-VIEW SIDE EFFECT 1 STORE Action State User interaction UI Data Optional Action SIDE EFFECT N
27. ACTION REDUCER VIEW CONTROLLER-VIEW SIDE EFFECT 1 STORE Action State User interaction UI Data Optional Action SIDE EFFECT N
28. ACTION REDUCER VIEW CONTROLLER-VIEW SIDE EFFECT 1 STORE Action State User interaction UI Data Optional Action SIDE EFFECT N
29. ACTION REDUCER VIEW CONTROLLER-VIEW SIDE EFFECT 1 STORE Action State User interaction UI Data Optional Action SIDE EFFECT N
30. ACTION REDUCER VIEW CONTROLLER-VIEW SIDE EFFECT 1 STORE Action State User interaction UI Data Optional Action SIDE EFFECT N
31. ACTION REDUCER VIEW CONTROLLER-VIEW SIDE EFFECT 1 STORE Action State User interaction UI Data Optional Action SIDE EFFECT N
32. ACTION REDUCER VIEW CONTROLLER-VIEW SIDE EFFECT 1 STORE Action State User interaction UI Data Optional Action SIDE EFFECT N
33. ACTION REDUCER VIEW CONTROLLER-VIEW SIDE EFFECT 1 STORE Action State User interaction UI Data Optional Action SIDE EFFECT N
34. NO FRAMEWORK DEPENDENCIES Dependencies ACTION REDUCER VIEW CONTROLLER-VIEW NO FRAMEWORK DEPENDENCIES SIDE EFFECT 1 ANDROID DEPENDENCIES SIDE EFFECT N STORE ANDROID DEPENDENCIES
35. KUnidirectional
36. KUnidirectional OSS sample app which shows this architecture.
37. KUnidirectional OSS sample app which shows this architecture. A simple item list app.
38. KUnidirectional OSS sample app which shows this architecture. A simple item list app. Everything is unidirectional.
39. KUnidirectional OSS sample app which shows this architecture. A simple item list app. Everything is unidirectional. Without external libraries, just Kotlin + Android.
40. View
41. View Are Activities and Fragments.
42. View Are Activities and Fragments. It uses its ControllerView to start the process of what the user wants.
43. View Are Activities and Fragments. It uses its ControllerView to start the process of what the user wants. It will render the data that comes from its ControllerView.
44. ControllerView
45. ControllerView “Man in the middle” between UI and everything else.
46. ControllerView “Man in the middle” between UI and everything else. 1 Activity/1Fragment -> 1 Controller-View.
47. ControllerView “Man in the middle” between UI and everything else. 1 Activity/1Fragment -> 1 Controller-View. Creates and dispatches actions.
48. ControllerView “Man in the middle” between UI and everything else. 1 Activity/1Fragment -> 1 Controller-View. Creates and dispatches actions. Handles a new State.
49. protected fun <T : Action> dispatch(action: T) {
 store.dispatch(action)
 }
 
 abstract fun handleState(state: State)
 } abstract class ControllerView(
 val store: Store,
 mainThread: ThreadExecutor? = null): LifecycleCallbacks, StateHandler(mainThread) {
50. Action
51. Action Are the intentions, what we want to do.
52. Action Are the intentions, what we want to do. They have metadata.
53. Action Are the intentions, what we want to do. They have metadata. They will be reduced or handled.
54. sealed class Action
 sealed class UpdateAction : Action() {
 data class ReorderItemsAction(val items: List<Item>) : UpdateAction()
 
 data class UpdateItemAction(val localId: String,
 val text: String?,
 val color: Color) : UpdateAction()
 
 data class UpdateFavoriteAction( val localId: String, val favorite: Boolean) : UpdateAction()
 
 data class UpdateColorAction( val localId: String, val color: Color) : UpdateAction()
 } sealed class ReadAction : Action() {
 class FetchItemsAction : ReadAction()
 data class ItemsLoadedAction(val items: List<Item>) : ReadAction()
 }
55. Store
56. Store It has the State of the app. State is immutable.
57. Store It will handle Actions. It has the State of the app. State is immutable.
58. Store It will handle Actions. It will reduce an Action and dispatch a new State. It has the State of the app. State is immutable.
59. Store It will handle Actions. It will reduce an Action and dispatch a new State. It has the State of the app. State is immutable. Dispatches an Action to its Side Effects after being reduced.
60. State enum class Navigation {
 ITEMS_LIST,
 EDIT_ITEM
 }
 data class ItemsListScreen(
 val items: List<Item> = emptyList())
 
 data class EditItemScreen(val currentItem: Item = Item())
 
 data class State(
 val itemsListScreen: ItemsListScreen = ItemsListScreen(),
 val editItemScreen: EditItemScreen = EditItemScreen(),
 val navigation: Navigation = Navigation.ITEMS_LIST) Remember, State is immutable.
61. Store abstract class Store( val sideEffects: CopyOnWriteArrayList<SideEffect> = CopyOnWriteArrayList(),
 val stateHandlers: CopyOnWriteArrayList<StateHandler> = CopyOnWriteArrayList(),
 val storeThread: ThreadExecutor? = null) : Subscribers { private fun handle(action: Action) {
 val newState = reduce(action, state)
 dispatch(newState)
 sideEffects.dispatch(action)
 } fun dispatch(newState: State) {
 state = newState
 stateHandlers.dispatch(state)
 } 
 . . .
62. Store . . . private fun reduce(action: Action, currentState: State): State =
 when (action) {
 is CreationAction -> CreationReducer.reduce(action, currentState)
 is UpdateAction -> UpdateReducer.reduce(action, currentState)
 is ReadAction -> ReadReducer.reduce(action, currentState)
 is DeleteAction -> DeleteReducer.reduce(action, currentState)
 is NavigationAction -> NavigationReducer.reduce(action, currentState)
 } }
63. Reducer
64. Reducer Reduces an action to create a new state.
65. Reducer Reduces an action to create a new state. Reduces every part of the state independently.
66. Reducer Reduces an action to create a new state. Reduces every part of the state independently. The resulted new state will be dispatched.
67. abstract class Reducer<in T : Action> {
 
 open fun reduce(action: T, currentState: State) : State =
 with(currentState) {
 currentState.copy(
 itemsListScreen = reduceItemsListScreen(action, itemsListScreen),
 editItemScreen = reduceEditItemScreen(action, editItemScreen),
 navigation = reduceNavigation(action, navigation)
 )
 } . . . }
68. Models
69. STORE STORE MODELS Models
70. STORE STORE MODELS PRESENTATION STORE MODELS + EXTENSIONS Models
71. STORE STORE MODELS PRESENTATION STORE MODELS + EXTENSIONS Models PERSISTENCE PERSISTENCE MODELS MAPPER
72. enum class Color {
 RED, YELLOW, GREEN, BLUE, WHITE
 }
 
 data class Item(
 val localId: String = generateLocalId(),
 val text: String? = null,
 val favorite: Boolean = false,
 val color: Color = Color.WHITE,
 val position: Long = object : PositionsFactory {}.newPosition()) Store Models
73. import com.cesarvaliente.kunidirectional.persistence.Color as PersistenceColor
 import com.cesarvaliente.kunidirectional.persistence.Item as PersistenceItem
 import com.cesarvaliente.kunidirectional.store.Color as StoreColor
 import com.cesarvaliente.kunidirectional.store.Item as StoreItem Mapper fun StoreItem.toPersistenceItem(): PersistenceItem =
 with(this) {
 PersistenceItem(localId, text, favorite, color.toPersistenceColor(), position)
 }
 
 fun StoreColor.toPersistenceColor(): PersistenceColor =
 when (this) {
 StoreColor.BLUE -> PersistenceColor.BLUE
 StoreColor.GREEN -> PersistenceColor.GREEN
 StoreColor.RED -> PersistenceColor.RED
 StoreColor.WHITE -> PersistenceColor.WHITE
 StoreColor.YELLOW -> PersistenceColor.YELLOW
 }
74. Presentation models? fun Color.toColorResource(): Int =
 when (this) {
 RED -> R.color.red
 YELLOW -> R.color.yellow
 GREEN -> R.color.green
 BLUE -> R.color.blue
 WHITE -> R.color.white
 }
 
 fun Item.getStableId(): Long = this.localId.hashCode().toLong()
75. Side Effect
76. Side Effect Extends the functionality of your core logic.
77. Side Effect We can have 0 or as many side effects as we want. Extends the functionality of your core logic.
78. Side Effect We can have 0 or as many side effects as we want. It handles an Action right after the Store has reduced it. Extends the functionality of your core logic.
79. Side Effect We can have 0 or as many side effects as we want. It handles an Action right after the Store has reduced it. It can return a new Action. Extends the functionality of your core logic.
80. REDUCER
81. SIDE EFFECT 1 REDUCER
82. SIDE EFFECT 1 SIDE EFFECT 2 REDUCER
83. SIDE EFFECT N SIDE EFFECT 1 SIDE EFFECT 2 REDUCER . . .
84. SIDE EFFECT N SIDE EFFECT 1 SIDE EFFECT 2 REDUCER . . .
85. SIDE EFFECT N SIDE EFFECT 1 SIDE EFFECT 2 REDUCER . . .
86. Threading? VIEW STORE PERSISTENCE SIDE EFFECT
87. Threading? VIEW STORE PERSISTENCE SIDE EFFECT UI Thread
88. Threading? VIEW STORE PERSISTENCE SIDE EFFECT UI Thread Store Thread
89. Threading? VIEW STORE PERSISTENCE SIDE EFFECT UI Thread Store Thread Persistence Thread (Side Effect N Thread)
90. Testing?
91. Testing? UI tests on Presentation layer (View).
92. Testing? UI tests on Presentation layer (View). Unit + Integration tests on our ControllerViews.
93. Testing? UI tests on Presentation layer (View). Unit + Integration tests on our ControllerViews. Unit + instrumentation tests in our Persistence layer (side effect).
94. Testing? UI tests on Presentation layer (View). Unit + Integration tests on our ControllerViews. Unit + instrumentation tests in our Persistence layer (side effect). Unit tests in our Store layer.
95. Demo 1!
96. Demo 1!
97. Demo 1! FETCH LIST ITEMS LIST ITEMS Action State
98. Demo 1! OPEN EDIT ITEM NAVIGATION UPDATED FETCH LIST ITEMS LIST ITEMS Action State
99. Demo 1! OPEN EDIT ITEM NAVIGATION UPDATED SAVE ITEM NEW ITEM FETCH LIST ITEMS LIST ITEMS Action State
100. Demo 1! OPEN EDIT ITEM NAVIGATION UPDATED SAVE ITEM NEW ITEM TO NOTE LIST NAVIGATION UPDATED FETCH LIST ITEMS LIST ITEMS Action State
101. Demo 1! OPEN EDIT ITEM NAVIGATION UPDATED SAVE ITEM NEW ITEM TO NOTE LIST NAVIGATION UPDATED FETCH LIST ITEMS LIST ITEMS FETCH LIST ITEMS LIST ITEMS Action State
102. Demo 2! The cool thing of side effects in this architecture with decoupled elements.
103. Demo 2! The cool thing of side effects in this architecture with decoupled elements.
104. Final thoughts
105. Final thoughts This is not the Philosopher Stone of the architectures.
106. Final thoughts Unidirectional makes your code easy to follow. This is not the Philosopher Stone of the architectures.
107. Final thoughts Decoupling elements in your app makes maintainability and testing easier. Unidirectional makes your code easy to follow. This is not the Philosopher Stone of the architectures.
108. Final thoughts Decoupling elements in your app makes maintainability and testing easier. Unidirectional makes your code easy to follow. This is not the Philosopher Stone of the architectures. Immutability makes your code safer.
109. Final thoughts Decoupling elements in your app makes maintainability and testing easier. Take advantage of the tools you have. Unidirectional makes your code easy to follow. This is not the Philosopher Stone of the architectures. Immutability makes your code safer.
110. Final thoughts Decoupling elements in your app makes maintainability and testing easier. Take advantage of the tools you have. What is good for our problem maybe is not good for yours. Unidirectional makes your code easy to follow. This is not the Philosopher Stone of the architectures. Immutability makes your code safer.
111. ? @CesarValiente @CesarValiente
112. Thanks! @CesarValiente @CesarValiente
113. Useful Links KUnidirectional app KUnidirectional demo videos Flux Redux Luis G. Valle: Flux on Android André Staltz: Unidirectional data flow architectures Austin Mueller: Flux and Android Brian Egan and Guillaume Lung: Exploring the possibilities of Unidirectional Data Flow Architectures on Android
114. License (cc) 2017 César Valiente. Some rights reserved. This document is distributed under the Creative Commons Attribution-ShareAlike 3.0 license, available in http://creativecommons.org/licenses/by-sa/3.0/
115. Image licenses Flux and Redux images are property of Facebook. Emojis by Emoji One (CC-BY): http://emojione.com/