Upgrade to Pro — share decks privately, control downloads, hide ads and more …

MVWTF 2024: Demystifying Architecture Patterns

Adam McNeilly
June 07, 2024
240

MVWTF 2024: Demystifying Architecture Patterns

Presentation from Droidcon San Francisco 2024.

Adam McNeilly

June 07, 2024
Tweet

Transcript

  1. You May Have Heard These Buzzwords: • MVC • MVP

    • MVVM • MVI @AdamMc331 ttv/adammc #DCSF24 2
  2. Why Not? • Not readable • Difficult to add new

    code @AdamMc331 ttv/adammc #DCSF24 12
  3. Why Not? • Not readable • Difficult to add new

    code • Difficult to change existing code @AdamMc331 ttv/adammc #DCSF24 12
  4. 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
  5. Model-View-Controller • One of the earliest architecture patterns • Introduced

    in the 1970s as a way to organize code @AdamMc331 ttv/adammc #DCSF24 15
  6. 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
  7. Model • This is your data source • Database, remote

    server, etc @AdamMc331 ttv/adammc #DCSF24 16
  8. Model • This is your data source • Database, remote

    server, etc • It does not care about the view @AdamMc331 ttv/adammc #DCSF24 16
  9. View • This is the visual representation of information •

    Does not care where this data came from @AdamMc331 ttv/adammc #DCSF24 17
  10. 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
  11. 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
  12. Controller • Handles user inputs • Validates if necessary •

    Passes input to model @AdamMc331 ttv/adammc #DCSF24 18
  13. Controller • Handles user inputs • Validates if necessary •

    Passes input to model • Passes model response to view @AdamMc331 ttv/adammc #DCSF24 18
  14. The Model & View Components Are The Same For All

    Patterns @AdamMc331 ttv/adammc #DCSF24 19
  15. Why Do We Have So Many Options For This Third

    Component? @AdamMc331 ttv/adammc #DCSF24 22
  16. Why Don't We Use This For Android? • We can't

    write Junit tests for an Activity @AdamMc331 ttv/adammc #DCSF24 28
  17. 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
  18. 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
  19. Model-View-Presenter • Similar to the last pattern • Moves our

    presentation logic out of the Activity class @AdamMc331 ttv/adammc #DCSF24 30
  20. Why Is This Better? • UI logic is outside of

    the Activity, and now supports Junit tests @AdamMc331 ttv/adammc #DCSF24 32
  21. 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
  22. Contract Class object TaskListContract { interface Model { // ...

    } interface View { // ... } interface Presenter { // ... } } @AdamMc331 ttv/adammc #DCSF24 34
  23. Contract Class object TaskListContract { interface Model { suspend fun

    getTasks(): List<Task> } // ... } @AdamMc331 ttv/adammc #DCSF24 35
  24. Contract Class object TaskListContract { interface View { fun render(tasks:

    List<Task>) } // ... } @AdamMc331 ttv/adammc #DCSF24 36
  25. Contract Class object TaskListContract { interface Presenter { fun viewCreated()

    fun viewDestroyed() } // ... } @AdamMc331 ttv/adammc #DCSF24 37
  26. 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
  27. View class MainActivity : TaskListContract.View { private val presenter =

    TaskListPresenter( view = this, model = InMemoryTaskRepository(), ) // ... } @AdamMc331 ttv/adammc #DCSF24 39
  28. View class MainActivity { override fun render(tasks: List<Task>) { setContent

    { TaskList(tasks) } } // ... } @AdamMc331 ttv/adammc #DCSF24 41
  29. Presenter class TaskListPresenter( private var view: TaskListContract.View?, private val model:

    TaskListContract.Model, ) : TaskListContract.Presenter { // ... } @AdamMc331 ttv/adammc #DCSF24 42
  30. Presenter class TaskListPresenter { private var tasks: List<Task> = emptyList()

    set(value) { field = value view?.render(value) } // ... } @AdamMc331 ttv/adammc #DCSF24 43
  31. Presenter class TaskListPresenter { override fun viewCreated() { presenterScope.launch {

    tasks = model.getTasks() } } // ... } @AdamMc331 ttv/adammc #DCSF24 44
  32. Presenter class TaskListPresenter { override fun viewDestroyed() { view =

    null } // ... } @AdamMc331 ttv/adammc #DCSF24 45
  33. State Restoration object TaskListContract { interface Presenter { // New:

    fun getTasks(): List<Task> fun restoreTasks(tasks: List<Task>) } } @AdamMc331 ttv/adammc #DCSF24 47
  34. Persist State class MainActivity { override fun onSaveInstanceState(outState: Bundle) {

    outState.putParcelableArrayList("tasks", presenter.getTasks()) super.onSaveInstanceState(outState) } // ... } @AdamMc331 ttv/adammc #DCSF24 48
  35. 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
  36. MVP Recap • View does nothing but display data •

    Data fetching is all handled by model @AdamMc331 ttv/adammc #DCSF24 50
  37. 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
  38. 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
  39. 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
  40. 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
  41. ViewModel class TaskListViewModel( taskRepository: TaskRepository, ) { private val mutableTasks

    = MutableStateFlow(emptyList<Task>()) val tasks = mutableTasks.asStateFlow() // ... } @AdamMc331 ttv/adammc #DCSF24 56
  42. ViewModel class TaskListViewModel { init { viewModelScope.launch { tasks.value =

    taskRepository.getTasks() } } // ... } @AdamMc331 ttv/adammc #DCSF24 57
  43. 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
  44. This Is Pretty Close To MVP, With One New Benefit

    @AdamMc331 ttv/adammc #DCSF24 59
  45. Since ViewModel Doesn't Reference View, We Can Leverage Android Architecture

    Component ViewModel To Outlast Config Changes @AdamMc331 ttv/adammc #DCSF24 60
  46. State Restoration In MVVM 1. Have ViewModel class extend the

    AndroidX ViewModel class @AdamMc331 ttv/adammc #DCSF24 61
  47. State Restoration In MVVM 1. Have ViewModel class extend the

    AndroidX ViewModel class 2. Update Activity to use ViewModelProviders @AdamMc331 ttv/adammc #DCSF24 61
  48. 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
  49. State Restoration In MVVM class TaskListViewModel( private val repository: TaskRepository

    ) : ViewModel() { // ... } @AdamMc331 ttv/adammc #DCSF24 62
  50. 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
  51. MVVM Recap • All the benefits of MVP • Decoupled

    view and presentation layer @AdamMc331 ttv/adammc #DCSF24 64
  52. MVVM Recap • All the benefits of MVP • Decoupled

    view and presentation layer • Easier support for configuration changes @AdamMc331 ttv/adammc #DCSF24 64
  53. 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
  54. 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
  55. 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
  56. What Are The Risks Of These Methods? • Any methods

    in the class can call them @AdamMc331 ttv/adammc #DCSF24 70
  57. 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
  58. 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
  59. How Can We Mitigate This Risk? • Have one single

    source of truth for our state @AdamMc331 ttv/adammc #DCSF24 71
  60. 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
  61. 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
  62. 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
  63. 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
  64. 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
  65. 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
  66. 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
  67. 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
  68. 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
  69. This State Machine Is Our Source Of Truth class TaskListViewModel

    { private val stateMachine = // ... val state = stateMachine.state } @AdamMc331 ttv/adammc #DCSF24 78
  70. 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
  71. Process Loading Event private val stateMachine = StateMachine( eventProcessor =

    { currentState, event -> when (event) { TaskListStateUpdateEvent.SetLoading -> { TaskListViewState.Loading + TaskListSideEffect.FetchTasks } // ... } }, ) @AdamMc331 ttv/adammc #DCSF24 83
  72. Process Side Effect private val stateMachine = StateMachine( // ...

    sideEffectProcessor = { sideEffect -> when (sideEffect) { TaskListSideEffect.FetchTasks -> { fetchTasks() } } }, ) @AdamMc331 ttv/adammc #DCSF24 84
  73. 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
  74. 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
  75. MVI Recap • All benefits of previous patterns • State

    management is clear and predictable @AdamMc331 ttv/adammc #DCSF24 87
  76. Is MVI The Best We Can Do? • State management

    is pretty solid @AdamMc331 ttv/adammc #DCSF24 88
  77. 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
  78. Model-View-Presenter • Seperated concerns and testing support • Okay for

    quick prototyping @AdamMc331 ttv/adammc #DCSF24 90
  79. Model-View-Presenter • Seperated concerns and testing support • Okay for

    quick prototyping • Managing state across config changes requires work @AdamMc331 ttv/adammc #DCSF24 90
  80. 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
  81. Model-View-ViewModel • Seperated concerns and testing support • Even better

    for quick prototyping @AdamMc331 ttv/adammc #DCSF24 91
  82. 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
  83. 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
  84. Model-View-Intent • Seperated concerns and testing support • Works with

    both a Presenter and a ViewModel @AdamMc331 ttv/adammc #DCSF24 92
  85. 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
  86. 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
  87. 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
  88. 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
  89. 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
  90. 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