Modern Android Development Using MVI Architecture

Over the past years, app architecture has evolved. From god activities to MVP to MVVM which became popular after Google announced Android architecture components to MVI. the latest in the MV* band.

Jetpack compose, the modern UI toolkit for Android introduces a new way of writing your App UI. It is declarative. Hence, compose works fluently with unidirectional data flow architectural patterns.

In this session, we’ll see how the common architectural patterns work with Jetpack compose paradigm. We’ll go through the Model as the single source of truth. We’ll also look at handling SingleLiveEvents and app navigation using MVI pattern, and the benefits of unidirectional data flow. In the end, we’ll have fewer UI - related bugs in our Android apps.

Transcript

1. Beatrice Kinya Android Engineer @ Kyosk Digital Android Author @ kodeco.com @B__Kinya | Beatrice Kinya
2. Modern Android development using MVI Architecture Android, Kotlin, Jetpack
3. How it Started.
4. God activities - Performance issues. - Lifecycle issues - Memory leaks - Out of Memory issues
5. MVP Model - View - Presenter
6. MVP Source: touchgfx.com
7. MVP - Model - View - Presenter - Model is just data. - Presenter fetches data from the model, and manages state of the view. - It takes action based on user input in the View. - It calls methods on the View to notify it of state changes. - View receives method calls from the Presenter to be notified of changes to update itself.
8. MVP CONT’ - Presenters have a reference to the view. The view ia usually an activity or fragment injected into the presenter as an interface. - The presenter call functions on the interface to update the UI. - Composable functions do not have a return value. Hence, no view references to pass to our presenter. - Making MVP less ideal for Jetpack compose projects.
9. MVVM Model - View - ViewModel
10. MVVM - Became popular when Google announced AAC: ViewModel, LiveData etc. - ViewModel is the link between the View and Model. - ViewModel stores and manages UI related data in a lifecycle conscious manner. - Model is data mapped into observable fields like LiveData, or StateFlow. - When there are changes in the model, the UI observes the changes and recomposes itself based on the new data.
11. MVVM - Instead of updating the view imperatively like in MVP, MVVM uses observable data types making it a unidirectional Data Flow architectural pattern. - Downside: multiple objects for different UI states.
13. MVI Model - View - Intent
14. MVI Image Source
15. Model - In MVVM, model is just data e.g. A list of movies - In MVI, model represents state. - It tells the view what to display E.g. Loading, Data, Error. - When the model changes, the view gets notified and recomposes itself using the new state.
17. Intent/UI Events - An action that changes state e.g. user fetching favourite movies from an Api - MVI pattern uses redux style to create new state. - There are three components: - State - state holder - Action - Command to change state - Reducer - a pure function that takes the previous state and action and creates a new state
18. Intents
19. Reducer - Reduce function directly in the ViewModel OR - Separate the reducer from ViewModel - Reducer will be responsible for holding and processing state - ViewModel will be responsible for presentation layer business-logic, and transforming events from the UI layer into Intentions passed to the Reducer.
20. Reduce Function
21. View - UI i.e. a composable function. - It listens and responds to state changes. - Publishes stream of events as they happen to the ViewModel.
23. Time Machine - Optional feature. - It saves all states during a session. - You can do with it as you want: log to crashlytics, display in a debug menu or a screen where you can check all the steps made previously. - Note: Consider not to implement this by default. You’ll have chatty logs. Just use it for debugging purposes
25. Handling Configuration changes - The UI will display the most recent state. - However, remember to save state object. - Use - ViewModel to handle configuration changes like screen rotation - ViewModel saved state module to handle process death - Any other state saving mechanism
26. Single Live Events - E.g. Showing a snackbar message. - During configuration changes, the app will use the latest state. - It’ll show the snackbar again, which is not so good. - There are several ways to handle single live events - Sending ViewModel events to the UI - Google recommendation - Using Kotlin Channel Sample project: https://github.com/BKinya/Calculator-App
27. Navigation Options: - Making navigation be part of our state - State should hold data the app should show on a screen - Handled as a side effect. - But side effects are related to API calls, database access, remote logging - Call navigation directly from the UI. My preference.
28. Wrapping Up - Improved state management. - The “planning” effect. - Unidirectional/Cyclic Data Flow. - Immutability, hence single source of truth. - Debuggability with time machine. - Testability.
29. Downside - Lot’s of boilerplate code. - Each view will at least have a model, intent and a reducer function. - For large projects, this is a non- trivial organisation problem. - Solutions: - Use Android studio template support - Implement base interfaces - Modularisation
30. Resources - Sample project: https://github.com/BKinya/Movies-App - Reactive Apps using MVI: http://hannesdorfmann.com/android/mosby3-mvi-1/ - MvI, a new member of MV band: https://proandroiddev.com/mvi-a-new-member-of-the-mv-band-6f7f0d23bc8a - MVI - the good, bad and ugly: https://adambennett.dev/2019/07/mvi-the-good-the-bad-and-the-ugly/ - State and Jetpack compose: https://developer.android.com/jetpack/compose/state - State holders and state production in the UI layer. https://www.youtube.com/watch?v=pCX9wvu-Bq0
31. END! 🤠
32. Questions? 😇