MVWTF 2024: Demystifying Architecture Patterns

Presentation from Droidcon San Francisco 2024.

Transcript

1. MVWTF: Demystifying Architecture Patterns Adam McNeilly - @AdamMc331 @AdamMc331 ttv/adammc #DCSF24 1
2. You May Have Heard These Buzzwords: • MVC • MVP • MVVM • MVI @AdamMc331 ttv/adammc #DCSF24 2
3. Why Are There So Many? @AdamMc331 ttv/adammc #DCSF24 3
4. What's The Difference? @AdamMc331 ttv/adammc #DCSF24 4
5. Which One Should I Use? @AdamMc331 ttv/adammc #DCSF24 5
6. Which One Should I Use? @AdamMc331 ttv/adammc #DCSF24 6
7. Why Do We Need Architecture Patterns? @AdamMc331 ttv/adammc #DCSF24 7
8. More Buzzwords! @AdamMc331 ttv/adammc #DCSF24 8
9. More Buzzwords! • Maintainability @AdamMc331 ttv/adammc #DCSF24 8
10. More Buzzwords! • Maintainability • Extensibility @AdamMc331 ttv/adammc #DCSF24 8
11. More Buzzwords! • Maintainability • Extensibility • Robust @AdamMc331 ttv/adammc #DCSF24 8
12. More Buzzwords! • Maintainability • Extensibility • Robust • Testable @AdamMc331 ttv/adammc #DCSF24 8
13. Let's Start With One Simple Truth @AdamMc331 ttv/adammc #DCSF24 9
14. You Can't Put Everything In The Activity @AdamMc331 ttv/adammc #DCSF24 10
15. Or Your Fragment1 1 Thanks Mauricio for proofreading @AdamMc331 ttv/adammc #DCSF24 11
16. Why Not? @AdamMc331 ttv/adammc #DCSF24 12
17. Why Not? • Not readable @AdamMc331 ttv/adammc #DCSF24 12
18. Why Not? • Not readable • Difficult to add new code @AdamMc331 ttv/adammc #DCSF24 12
19. Why Not? • Not readable • Difficult to add new code • Difficult to change existing code @AdamMc331 ttv/adammc #DCSF24 12
20. Why Not? • Not readable • Difficult to add new code • Difficult to change existing code • Can't write Junit tests for this @AdamMc331 ttv/adammc #DCSF24 12
21. We Need To Break Up Our Code @AdamMc331 ttv/adammc #DCSF24 13
22. Let's Explore Some Options @AdamMc331 ttv/adammc #DCSF24 14
23. Model-View-Controller @AdamMc331 ttv/adammc #DCSF24 15
24. Model-View-Controller • One of the earliest architecture patterns @AdamMc331 ttv/adammc #DCSF24 15
25. Model-View-Controller • One of the earliest architecture patterns • Introduced in the 1970s as a way to organize code @AdamMc331 ttv/adammc #DCSF24 15
26. Model-View-Controller • One of the earliest architecture patterns • Introduced in the 1970s as a way to organize code • Divides application to three parts @AdamMc331 ttv/adammc #DCSF24 15
27. Model @AdamMc331 ttv/adammc #DCSF24 16
28. Model • This is your data source @AdamMc331 ttv/adammc #DCSF24 16
29. Model • This is your data source • Database, remote server, etc @AdamMc331 ttv/adammc #DCSF24 16
30. Model • This is your data source • Database, remote server, etc • It does not care about the view @AdamMc331 ttv/adammc #DCSF24 16
31. View @AdamMc331 ttv/adammc #DCSF24 17
32. View • This is the visual representation of information @AdamMc331 ttv/adammc #DCSF24 17
33. View • This is the visual representation of information • Does not care where this data came from @AdamMc331 ttv/adammc #DCSF24 17
34. View • This is the visual representation of information • Does not care where this data came from • Only responsible for displaying data @AdamMc331 ttv/adammc #DCSF24 17
35. View • This is the visual representation of information • Does not care where this data came from • Only responsible for displaying data • If your view has a conditional, consider refactoring @AdamMc331 ttv/adammc #DCSF24 17
36. Controller @AdamMc331 ttv/adammc #DCSF24 18
37. Controller • Handles user inputs @AdamMc331 ttv/adammc #DCSF24 18
38. Controller • Handles user inputs • Validates if necessary @AdamMc331 ttv/adammc #DCSF24 18
39. Controller • Handles user inputs • Validates if necessary • Passes input to model @AdamMc331 ttv/adammc #DCSF24 18
40. Controller • Handles user inputs • Validates if necessary • Passes input to model • Passes model response to view @AdamMc331 ttv/adammc #DCSF24 18
41. The Model & View Components Are The Same For All Patterns @AdamMc331 ttv/adammc #DCSF24 19
42. @AdamMc331 ttv/adammc #DCSF24 20
43. Model-View-WhateverTheFYouWant @AdamMc331 ttv/adammc #DCSF24 21
44. Why Do We Have So Many Options For This Third Component? @AdamMc331 ttv/adammc #DCSF24 22
45. Short Answer: State Management @AdamMc331 ttv/adammc #DCSF24 23
46. Long Answer: Let's Break Them Down @AdamMc331 ttv/adammc #DCSF24 24
47. Model-View-Controller @AdamMc331 ttv/adammc #DCSF24 25
48. Why Don't We Use This For Android? @AdamMc331 ttv/adammc #DCSF24 26
49. Why Don't We Use This For Android? @AdamMc331 ttv/adammc #DCSF24 27
50. Why Don't We Use This For Android? @AdamMc331 ttv/adammc #DCSF24 28
51. Why Don't We Use This For Android? • We can't write Junit tests for an Activity @AdamMc331 ttv/adammc #DCSF24 28
52. Why Don't We Use This For Android? • We can't write Junit tests for an Activity • We can't unit test our UI logic @AdamMc331 ttv/adammc #DCSF24 28
53. Why Don't We Use This For Android? • We can't write Junit tests for an Activity • We can't unit test our UI logic • We don't really have a separation of concerns here @AdamMc331 ttv/adammc #DCSF24 28
54. Model-View-Presenter @AdamMc331 ttv/adammc #DCSF24 29
55. Model-View-Presenter @AdamMc331 ttv/adammc #DCSF24 30
56. Model-View-Presenter • Similar to the last pattern @AdamMc331 ttv/adammc #DCSF24 30
57. Model-View-Presenter • Similar to the last pattern • Moves our presentation logic out of the Activity class @AdamMc331 ttv/adammc #DCSF24 30
58. Model-View-Presenter @AdamMc331 ttv/adammc #DCSF24 31
59. Why Is This Better? @AdamMc331 ttv/adammc #DCSF24 32
60. Why Is This Better? • UI logic is outside of the Activity, and now supports Junit tests @AdamMc331 ttv/adammc #DCSF24 32
61. Why Is This Better? • UI logic is outside of the Activity, and now supports Junit tests • Our concerns are separated again @AdamMc331 ttv/adammc #DCSF24 32
62. MVP Implementation @AdamMc331 ttv/adammc #DCSF24 33
63. Contract Class object TaskListContract { interface Model { // ... } interface View { // ... } interface Presenter { // ... } } @AdamMc331 ttv/adammc #DCSF24 34
64. Contract Class object TaskListContract { interface Model { suspend fun getTasks(): List<Task> } // ... } @AdamMc331 ttv/adammc #DCSF24 35
65. Contract Class object TaskListContract { interface View { fun render(tasks: List<Task>) } // ... } @AdamMc331 ttv/adammc #DCSF24 36
66. Contract Class object TaskListContract { interface Presenter { fun viewCreated() fun viewDestroyed() } // ... } @AdamMc331 ttv/adammc #DCSF24 37
67. Model class InMemoryTaskRepository : TaskListContract.Model { override suspend fun getTasks(): List<Task> { return listOf( Task("Test Task 1"), Task("Test Task 2"), Task("Test Task 3"), ) } } @AdamMc331 ttv/adammc #DCSF24 38
68. View class MainActivity : TaskListContract.View { private val presenter = TaskListPresenter( view = this, model = InMemoryTaskRepository(), ) // ... } @AdamMc331 ttv/adammc #DCSF24 39
69. View class MainActivity { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) presenter.viewCreated() } // ... } @AdamMc331 ttv/adammc #DCSF24 40
70. View class MainActivity { override fun render(tasks: List<Task>) { setContent { TaskList(tasks) } } // ... } @AdamMc331 ttv/adammc #DCSF24 41
71. Presenter class TaskListPresenter( private var view: TaskListContract.View?, private val model: TaskListContract.Model, ) : TaskListContract.Presenter { // ... } @AdamMc331 ttv/adammc #DCSF24 42
72. Presenter class TaskListPresenter { private var tasks: List<Task> = emptyList() set(value) { field = value view?.render(value) } // ... } @AdamMc331 ttv/adammc #DCSF24 43
73. Presenter class TaskListPresenter { override fun viewCreated() { presenterScope.launch { tasks = model.getTasks() } } // ... } @AdamMc331 ttv/adammc #DCSF24 44
74. Presenter class TaskListPresenter { override fun viewDestroyed() { view = null } // ... } @AdamMc331 ttv/adammc #DCSF24 45
75. State Restoration @AdamMc331 ttv/adammc #DCSF24 46
76. State Restoration object TaskListContract { interface Presenter { // New: fun getTasks(): List<Task> fun restoreTasks(tasks: List<Task>) } } @AdamMc331 ttv/adammc #DCSF24 47
77. Persist State class MainActivity { override fun onSaveInstanceState(outState: Bundle) { outState.putParcelableArrayList("tasks", presenter.getTasks()) super.onSaveInstanceState(outState) } // ... } @AdamMc331 ttv/adammc #DCSF24 48
78. Restore State class MainActivity { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) val tasks = savedInstanceState?.getParcelableArrayList("tasks") if (tasks != null) { presenter.restoreTasks(tasks) } } // ... } @AdamMc331 ttv/adammc #DCSF24 49
79. MVP Recap @AdamMc331 ttv/adammc #DCSF24 50
80. MVP Recap • View does nothing but display data @AdamMc331 ttv/adammc #DCSF24 50
81. MVP Recap • View does nothing but display data • Data fetching is all handled by model @AdamMc331 ttv/adammc #DCSF24 50
82. MVP Recap • View does nothing but display data • Data fetching is all handled by model • Presentation of data is handled by presenter @AdamMc331 ttv/adammc #DCSF24 50
83. MVP Recap • View does nothing but display data • Data fetching is all handled by model • Presentation of data is handled by presenter • Everything is separated, everything is testable @AdamMc331 ttv/adammc #DCSF24 50
84. MVP Recap • View does nothing but display data • Data fetching is all handled by model • Presentation of data is handled by presenter • Everything is separated, everything is testable • State can be fetched/restored as necessary @AdamMc331 ttv/adammc #DCSF24 50
85. What's Different About MVVM? @AdamMc331 ttv/adammc #DCSF24 51
86. The Presenter Doesn't Need To Care About The View @AdamMc331 ttv/adammc #DCSF24 52
87. Model-View-ViewModel @AdamMc331 ttv/adammc #DCSF24 53
88. MVVM Implementation @AdamMc331 ttv/adammc #DCSF24 54
89. Model Doesn't Change (much) interface TaskRepository { fun getTasks(): List<Task> } class InMemoryTaskService : TaskRepository { override fun getTasks(): List<Task> { return listOf(...) } } @AdamMc331 ttv/adammc #DCSF24 55
90. ViewModel class TaskListViewModel( taskRepository: TaskRepository, ) { private val mutableTasks = MutableStateFlow(emptyList<Task>()) val tasks = mutableTasks.asStateFlow() // ... } @AdamMc331 ttv/adammc #DCSF24 56
91. ViewModel class TaskListViewModel { init { viewModelScope.launch { tasks.value = taskRepository.getTasks() } } // ... } @AdamMc331 ttv/adammc #DCSF24 57
92. View class MainActivity { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContent { val tasks by viewModel.tasks.collectAsState() TaskList(tasks) } } // ... } @AdamMc331 ttv/adammc #DCSF24 58
93. This Is Pretty Close To MVP, With One New Benefit @AdamMc331 ttv/adammc #DCSF24 59
94. Since ViewModel Doesn't Reference View, We Can Leverage Android Architecture Component ViewModel To Outlast Config Changes @AdamMc331 ttv/adammc #DCSF24 60
95. State Restoration In MVVM @AdamMc331 ttv/adammc #DCSF24 61
96. State Restoration In MVVM 1. Have ViewModel class extend the AndroidX ViewModel class @AdamMc331 ttv/adammc #DCSF24 61
97. State Restoration In MVVM 1. Have ViewModel class extend the AndroidX ViewModel class 2. Update Activity to use ViewModelProviders @AdamMc331 ttv/adammc #DCSF24 61
98. State Restoration In MVVM 1. Have ViewModel class extend the AndroidX ViewModel class 2. Update Activity to use ViewModelProviders 3. Since Android's ViewModel outlasts config changes, no need to save/restore state, just re-subscribe @AdamMc331 ttv/adammc #DCSF24 61
99. State Restoration In MVVM class TaskListViewModel( private val repository: TaskRepository ) : ViewModel() { // ... } @AdamMc331 ttv/adammc #DCSF24 62
100. State Restoration In MVVM class MainActivity { private val viewModel: TaskListViewModel by viewModels { // ... } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContent { val tasks by viewModel.tasks.collectAsState() TaskList(tasks) } } } @AdamMc331 ttv/adammc #DCSF24 63
101. MVVM Recap @AdamMc331 ttv/adammc #DCSF24 64
102. MVVM Recap • All the benefits of MVP @AdamMc331 ttv/adammc #DCSF24 64
103. MVVM Recap • All the benefits of MVP • Decoupled view and presentation layer @AdamMc331 ttv/adammc #DCSF24 64
104. MVVM Recap • All the benefits of MVP • Decoupled view and presentation layer • Easier support for configuration changes @AdamMc331 ttv/adammc #DCSF24 64
105. Where Does MVVM Fall Short? @AdamMc331 ttv/adammc #DCSF24 65
106. Let's Consider A More Complicated State @AdamMc331 ttv/adammc #DCSF24 66
107. Let's Consider A More Complicated State sealed interface TaskListState { object Loading : TaskListState data class Loaded(val tasks: List<Task>) : TaskListState data class Error(val message: String) : TaskListState } @AdamMc331 ttv/adammc #DCSF24 67
108. Let's Consider A More Complicated State class TaskListViewModel(private val repository: TaskRepository) : ViewModel() { // ... private fun showLoading() { state.value = TaskListState.Loading } private fun fetchTasks() { val tasks = repository.getItems() state.value = TaskListState.Loaded(tasks) } private fun showError() { state.value = TaskListState.Error("Unable to fetch tasks.") } } @AdamMc331 ttv/adammc #DCSF24 68
109. What Are The Risks Of These Methods? private fun showLoading() { state.value = TaskListState.Loading } private fun fetchTasks() { val tasks = repository.getItems() state.value = TaskListState.Loaded(tasks) } private fun showError() { state.value = TaskListState.Error("Unable to fetch tasks.") } @AdamMc331 ttv/adammc #DCSF24 69
110. What Are The Risks Of These Methods? @AdamMc331 ttv/adammc #DCSF24 70
111. What Are The Risks Of These Methods? • Any methods in the class can call them @AdamMc331 ttv/adammc #DCSF24 70
112. What Are The Risks Of These Methods? • Any methods in the class can call them • We can't guarantee they're associated with a specific action or intent @AdamMc331 ttv/adammc #DCSF24 70
113. What Are The Risks Of These Methods? • Any methods in the class can call them • We can't guarantee they're associated with a specific action or intent • We have multiple methods manipulating our state that we have to ensure don't conflict with each other @AdamMc331 ttv/adammc #DCSF24 70
114. How Can We Mitigate This Risk? @AdamMc331 ttv/adammc #DCSF24 71
115. How Can We Mitigate This Risk? • Have one single source of truth for our state @AdamMc331 ttv/adammc #DCSF24 71
116. How Can We Mitigate This Risk? • Have one single source of truth for our state • Do this through a single pipeline where every action causes a specific change in the state @AdamMc331 ttv/adammc #DCSF24 71
117. How Can We Mitigate This Risk? • Have one single source of truth for our state • Do this through a single pipeline where every action causes a specific change in the state • This makes state changes predictable, and therefore highly testable as well @AdamMc331 ttv/adammc #DCSF24 71
118. Model-View-Intent @AdamMc331 ttv/adammc #DCSF24 72
119. Model-View-Intent @AdamMc331 ttv/adammc #DCSF24 73
120. Model-View-Intent • Unlike the previous patterns, "Intent" isn't used to reference a specific kind of component, but rather the intention of doing something that we want to capture in our state. @AdamMc331 ttv/adammc #DCSF24 73
121. The First Goal Is To Make Our State Changes Predictable @AdamMc331 ttv/adammc #DCSF24 74
122. We Can Achieve This With A State Machine class StateMachine( initialState: State, private val eventProcessor: (State, StateUpdateEvent) -> State, ) { private val mutableState = MutableStateFlow(initialState) val state = mutableState.asStateFlow() fun processEvent(event: StateUpdateEvent) { mutableState.update { currentState -> val newState = eventProcessor(currentState, event) newState } } } @AdamMc331 ttv/adammc #DCSF24 75
123. We Can Achieve This With A State Machine class StateMachine( initialState: State, private val eventProcessor: (State, StateUpdateEvent) -> State, ) { private val mutableState = MutableStateFlow(initialState) val state = mutableState.asStateFlow() fun processEvent(event: StateUpdateEvent) { mutableState.update { currentState -> val newState = eventProcessor(currentState, event) newState } } } @AdamMc331 ttv/adammc #DCSF24 75
124. We Can Achieve This With A State Machine class StateMachine( initialState: State, private val eventProcessor: (State, StateUpdateEvent) -> State, ) { private val mutableState = MutableStateFlow(initialState) val state = mutableState.asStateFlow() fun processEvent(event: StateUpdateEvent) { mutableState.update { currentState -> val newState = eventProcessor(currentState, event) newState } } } @AdamMc331 ttv/adammc #DCSF24 75
125. Clearly Defined Inputs sealed class TaskListStateUpdateEvent : StateUpdateEvent { data object SetLoading : TaskListStateUpdateEvent() data class SetTasks(val tasks: List<Task>) : TaskListStateUpdateEvent() data class SetError(val error: String) : TaskListStateUpdateEvent() } @AdamMc331 ttv/adammc #DCSF24 76
126. Clearly Defined Outputs private val stateMachine = StateMachine<TaskListViewState, TaskListStateUpdateEvent>( initialState = TaskListViewState.Loading, eventProcessor = { currentState, event -> when (event) { is TaskListStateUpdateEvent.SetError -> { TaskListViewState.Error(event.error) } TaskListStateUpdateEvent.SetLoading -> { TaskListViewState.Loading } is TaskListStateUpdateEvent.SetTasks -> { TaskListViewState.Loaded(event.tasks) } } }, ) @AdamMc331 ttv/adammc #DCSF24 77
127. Clearly Defined Outputs private val stateMachine = StateMachine<TaskListViewState, TaskListStateUpdateEvent>( initialState = TaskListViewState.Loading, eventProcessor = { currentState, event -> when (event) { is TaskListStateUpdateEvent.SetError -> { TaskListViewState.Error(event.error) } TaskListStateUpdateEvent.SetLoading -> { TaskListViewState.Loading } is TaskListStateUpdateEvent.SetTasks -> { TaskListViewState.Loaded(event.tasks) } } }, ) @AdamMc331 ttv/adammc #DCSF24 77
128. This State Machine Is Our Source Of Truth class TaskListViewModel { private val stateMachine = // ... val state = stateMachine.state } @AdamMc331 ttv/adammc #DCSF24 78
129. Side Effects @AdamMc331 ttv/adammc #DCSF24 79
130. Side Effects class StateMachine( // ... private val eventProcessor: (State, StateUpdateEvent) -> StateAndSideEffects, private val sideEffectProcessor: (SideEffect) -> Unit, ) data class StateAndSideEffects( val state: State, val sideEffects: List<SideEffect>, ) @AdamMc331 ttv/adammc #DCSF24 80
131. Task List Flow In MVI @AdamMc331 ttv/adammc #DCSF24 81
132. ViewModel Initialization class TaskListViewModel { init { stateMachine.processEvent(TaskListStateUpdateEvent.SetLoading) } } @AdamMc331 ttv/adammc #DCSF24 82
133. Process Loading Event private val stateMachine = StateMachine( eventProcessor = { currentState, event -> when (event) { TaskListStateUpdateEvent.SetLoading -> { TaskListViewState.Loading + TaskListSideEffect.FetchTasks } // ... } }, ) @AdamMc331 ttv/adammc #DCSF24 83
134. Process Side Effect private val stateMachine = StateMachine( // ... sideEffectProcessor = { sideEffect -> when (sideEffect) { TaskListSideEffect.FetchTasks -> { fetchTasks() } } }, ) @AdamMc331 ttv/adammc #DCSF24 84
135. Process Side Effect private fun fetchTasks() { viewModelScope.launch { val event = try { val tasks = taskRepository.getTasks() TaskListStateUpdateEvent.SetTasks(tasks) } catch (e: Exception) { TaskListStateUpdateEvent.SetError(e.message) } stateMachine.processEvent(event) } } @AdamMc331 ttv/adammc #DCSF24 85
136. Process Resulting Events private val stateMachine = StateMachine( eventProcessor = { currentState, event -> when (event) { is TaskListStateUpdateEvent.SetError -> { TaskListViewState.Error(event.error).noSideEffects() } is TaskListStateUpdateEvent.SetTasks -> { TaskListViewState.Loaded(event.tasks).noSideEffects() } // ... } } ) @AdamMc331 ttv/adammc #DCSF24 86
137. MVI Recap @AdamMc331 ttv/adammc #DCSF24 87
138. MVI Recap • All benefits of previous patterns @AdamMc331 ttv/adammc #DCSF24 87
139. MVI Recap • All benefits of previous patterns • State management is clear and predictable @AdamMc331 ttv/adammc #DCSF24 87
140. Is MVI The Best We Can Do? @AdamMc331 ttv/adammc #DCSF24 88
141. Is MVI The Best We Can Do? • State management is pretty solid @AdamMc331 ttv/adammc #DCSF24 88
142. Is MVI The Best We Can Do? • State management is pretty solid • But, we have 22 letters that weren't covered yet @AdamMc331 ttv/adammc #DCSF24 88
143. What Should I Take Away From This? @AdamMc331 ttv/adammc #DCSF24 89
144. Model-View-Presenter @AdamMc331 ttv/adammc #DCSF24 90
145. Model-View-Presenter • Seperated concerns and testing support @AdamMc331 ttv/adammc #DCSF24 90
146. Model-View-Presenter • Seperated concerns and testing support • Okay for quick prototyping @AdamMc331 ttv/adammc #DCSF24 90
147. Model-View-Presenter • Seperated concerns and testing support • Okay for quick prototyping • Managing state across config changes requires work @AdamMc331 ttv/adammc #DCSF24 90
148. Model-View-Presenter • Seperated concerns and testing support • Okay for quick prototyping • Managing state across config changes requires work • State management is unpredictable @AdamMc331 ttv/adammc #DCSF24 90
149. Model-View-ViewModel @AdamMc331 ttv/adammc #DCSF24 91
150. Model-View-ViewModel • Seperated concerns and testing support @AdamMc331 ttv/adammc #DCSF24 91
151. Model-View-ViewModel • Seperated concerns and testing support • Even better for quick prototyping @AdamMc331 ttv/adammc #DCSF24 91
152. Model-View-ViewModel • Seperated concerns and testing support • Even better for quick prototyping • Can handle config changes easily if we use Android's architecture components @AdamMc331 ttv/adammc #DCSF24 91
153. Model-View-ViewModel • Seperated concerns and testing support • Even better for quick prototyping • Can handle config changes easily if we use Android's architecture components • State management is unpredictable @AdamMc331 ttv/adammc #DCSF24 91
154. Model-View-Intent @AdamMc331 ttv/adammc #DCSF24 92
155. Model-View-Intent • Seperated concerns and testing support @AdamMc331 ttv/adammc #DCSF24 92
156. Model-View-Intent • Seperated concerns and testing support • Works with both a Presenter and a ViewModel @AdamMc331 ttv/adammc #DCSF24 92
157. Model-View-Intent • Seperated concerns and testing support • Works with both a Presenter and a ViewModel • Not good for quick prototyping @AdamMc331 ttv/adammc #DCSF24 92
158. Model-View-Intent • Seperated concerns and testing support • Works with both a Presenter and a ViewModel • Not good for quick prototyping • State management is clear and predictable @AdamMc331 ttv/adammc #DCSF24 92
159. Model-View-Intent • Seperated concerns and testing support • Works with both a Presenter and a ViewModel • Not good for quick prototyping • State management is clear and predictable • Has a steeper learning curve due to state machine logic @AdamMc331 ttv/adammc #DCSF24 92
160. General Suggestions @AdamMc331 ttv/adammc #DCSF24 93
161. General Suggestions • MVP can get you up and running quickly, but due to the boilerplate and config changes work I wouldn't recommend it @AdamMc331 ttv/adammc #DCSF24 93
162. General Suggestions • MVP can get you up and running quickly, but due to the boilerplate and config changes work I wouldn't recommend it • MVVM is what I'd recommend the most. It allows for separation of concerns and unit test support without a major learning curve @AdamMc331 ttv/adammc #DCSF24 93
163. General Suggestions • MVP can get you up and running quickly, but due to the boilerplate and config changes work I wouldn't recommend it • MVVM is what I'd recommend the most. It allows for separation of concerns and unit test support without a major learning curve • If your app handles complex user flows or states, MVI can give you more support for state management @AdamMc331 ttv/adammc #DCSF24 93
164. What's Most Important @AdamMc331 ttv/adammc #DCSF24 94
165. What's Most Important • Be consistent @AdamMc331 ttv/adammc #DCSF24 94
166. What's Most Important • Be consistent • Be comfortable @AdamMc331 ttv/adammc #DCSF24 94
167. Thank you! https://github.com/adammc331/mvwtf2024 @AdamMc331 ttv/adammc #DCSF24 95