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
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
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
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
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
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
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
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
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
StateUpdateEvent) -> StateAndSideEffects, private val sideEffectProcessor: (SideEffect) -> Unit, ) data class StateAndSideEffects( val state: State, val sideEffects: List<SideEffect>, ) @AdamMc331 ttv/adammc #DCSF24 80
for quick prototyping • Can handle config changes easily if we use Android's architecture components • State management is unpredictable @AdamMc331 ttv/adammc #DCSF24 91
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
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
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