I’ve seen a lot of articles about Android MVI mode recently.
MVVM is not hot, when is the next MVI? Do we develop such volume on Android? Who the hell is doing it?
What problem was the MVI model built to solve? Should we learn MVI mode and use it in the project?
Does Android really recommend MVI mode? What is the difference between MVI and MVVM?
How should we learn the MVI architecture pattern? MVI learning route suggestions.
With these questions, the uncle found the answers one by one.
Therefore, I continued to “vomit blood and tidy up” for many days, hoping to be helpful to my friends learning MVI
Hey hey ~ for uncle’s hard finishing, after reading a point of praise, this request is not excessive ~ hey hey ~
0, the full name
MVC: Model – View – Controller
MVP: Model – View – the Presenter
MVVM: Model – View – the ViewModel
MVI: Model – View – Intent
First, who is “Curly King”?
Is Android building its own MVI architecture?
Was the MVI architecture developed by Domestic Android developers in the last year or two?
Of course not. The real Curly king is the front end.
That’s right, the front-end, the web front-end that wants to rule the world, not Android.
Read a lot of MVI data, uncle found that all mentioned cycle.js framework. Android’s MVI architecture is inspired by the Cycle.js framework.
Take this article for example: MVI Architecture for Android Tutorial: Getting Started
MVI(Model-view-intent) Pattern in Android
Let’s take a look at when the Cycle.js framework started and when the MVI pattern started.
Cycle. Js frameworkFirst pre-release version:
It was released in 2014.
Combined with the official documentation, the Cycle.js framework was created for the MVI schema.
It is not known if the Cycle.js framework is the first MVI schema framework.
However, it can be inferred from many sources that the MVI architecture pattern is popularized by the Cycle.js framework.
It has been in front end development since 2014.
Think about 2014. What are we doing? What architectural patterns are android using?
At that time everybody was using MVC. Some of the best teams are just starting to try MVP.
Many domestic projects do not even use MVC, basically a bunch of code to put Activity. The Model and View are basically unisolated and unlayered.
Just as the saying goes, shaolin is the world’s martial arts.
Many of our Android technologies are already “broken” on the front end.
Recall that the official Flutter was born out of an internal experiment by the Chrome team. Is the Development of the Flutter project much like Web development?
Facebook React came first with Reactjs and then React Native.
Although, the world martial arts out of Shaolin, but, there is a sentence, the world martial arts only fast not broken, ha ha ha ~~~
Perhaps with the development of Moore’s Law, one day in the future, front-end, will finally realize the dream, the world.
Why did you create MVI? — What problem does MVI mode solve?
Conclusion: In order to implement the responsive programming paradigm on the idea of the MVC architectural pattern.
The main purpose of MVC is to separate the View from the Model.
MVI implements reactive programming (reactive programming) on the basis of separating View and Model.
MVC is also the father of MVI
We know that MVVM and MVVM both have MVC fathers. MVI’s father is MVC.
Model-View-Intent (MVI) is reactive, functional, and follows the core idea in MVC.
Excerpt from cycle.js official document
2. MVI implements Reactive programming paradigm on the basis of MVC idea
The Controller of MVC is a command and a programming component, which cannot directly realize the idea of responsive programming.
Model-View-Intent (MVI) is reactive, functional, and follows the core idea in MVC.
The Controller in MVC is incompatible with our reactive ideals, because it is a proactive component.
We can keep the MVC idea while avoiding a proactive Controller.
Excerpt from cycle.js official document
3. What is responsive programming?
Reactive Programming Paradigm:
Don’t understand the word paradigm? We’re all familiar with programming to objects, and object orientation is a programming paradigm.
Responsive programming paradigm: An declarative programming paradigm for data flow and change.
Android’s official compose framework, wechat mini app, Flutter, React and Hongmeng UI development frameworks all use responsive development frameworks.
Without further elaboration, you need a basic understanding of any of the frameworks mentioned above to understand the responsive programming paradigm.
It doesn’t matter if you don’t know any of them, it doesn’t matter if you don’t understand reactive programming now, until you learn MVI, which is something that you can’t really understand until you’ve actually used it.
Three, we should learn, learn not how to do?
1. Should we learn?
Learn, of course learn.
Learning these programming and architectural ideas is far more important than learning a dynamic implementation or an open source library to use.
2, learn how to do?
It doesn’t matter if you can’t learn, don’t worry (especially those who have not been working for a long time, learning is not a normal phenomenon ~)
It’s like Object-oriented Design Patterns, which we could never learn in college.
But after a few years of work, go back to learn, suddenly open, under the keyboard such as god ~
It’s like getting through two channels
MVI, I can’t learn it the first time, just wait 2 years and learn it again
If you don’t learn after 2 years, you have to wait another 2 years
If you still can’t learn it, it doesn’t matter, because MVI will become obsolete sooner or later
Ha ha ha ~ hold a smile, uncle does not joke.
Just like RXJava, how many people can’t learn rxJava, android development now who can learn RxJava? Ha ha ha ~
Does Android officially recommend MVI mode? What exactly has the Application Architecture Guide changed?
The latest official architecture guide does not explicitly state that the recommended architecture pattern is MVI, but it does resemble MVI in thought
However, this android Architecture Guide update is what I prefer to call an UPDATE to MVVM
This update to the architecture guide is not a complete refactoring, but rather an improvement over the previous MVVM.
The updated MVVM implements the responsive programming paradigm, where we can program for data flow and change.
Uncle summed up the core idea of the upgrade with a picture:
Old Architecture Guide – MVVM
At its core, MVVM implements a data-driven UI in the MVC mindset.
Isolate data (Model) and UI (View) through ViewModel, and bind data and UI through LiveData to achieve data-driven UI, as long as the LiveData data modification UI can automatically respond to updates.
Updated architecture Guide
Based on the previous edition, the new architecture Guide makes the following adjustments and suggestions:
1. Change LiveData component to StateFlow
More friendly use of coroutines. And it can better reflect the idea of development oriented to data flow.
In fact, there’s nothing wrong with still using LiveData.
2. The data that the ViewModel passes to the View is limited to the UIState of the View
The ViewModel gets the data from the Model layer, converts it into UIState data, and flows it through StateFlow to the View layer.
UIState’s data-oriented interface component 2 defines data that directly controls how the View component displays.
So we can also call UIState the interface state or the View state.
As follows:
data class NewsUiState( val isSignedIn: Boolean = false.val isPremium: Boolean = false.val newsItems: List<NewsItemUiState> = listOf() ) Copy the code3. Choice of single data stream or multiple data stream
The official guidelines do not force us to use a single stream.
It is up to us to decide whether we should use a single StateFlow or multiple Stateflows for the same interface.
We should decide whether to multi-stream or single-stream based on the degree of correlation between UIStates data.
Advantages and disadvantages of single flow are obvious:
Advantages: Centralized data control, improve code readability and ease of modification.
Disadvantages: When the data is very large and complex, it will affect efficiency. Because we don’t have diff, the View layer can’t just update the changed data, it just refreshes the current interface based on UIState.
Developer.android.com/jetpack/gui…
Let’s take a look at the official new architecture diagram:
Of course, it’s not just MVVM that can be transformed into a responsive development paradigm, but MVP as well.
Do not believe you see this article blog:www.raywenderlich.com/817602-mvi-…
Five, Android application architecture, learning route suggestions
There are some excellent learning materials at each step of the route.
You’re free in the back. Bring it up.
Need a small partner, collection or attention not lost ~
- MVC is the father of other architectural patterns. Its ideas are the basis of MVP, MVVM, and MVI. Learning it is a key step.
- Understand the difference between declarative, reactive, and imperative programming
- Learn kotlin’s StateFlow component, using Sequence->Flow->StateFlow
Kotlin: Sequences vs Sets
- Learn the use of ViewModel components (although it is possible to implement the MVI architecture without a ViewModel, the ViewModel is still worth learning)
- Understand the DRY (Don’t Repeat Yourself) principle
- Understand MVVM (because the official MVI mode is based on MVVM)
- Learn the official architecture guide
- In actual combat
Finally, a beautiful view of my home. It will be New Year’s Eve tomorrow. Happy New Year to you all
Uncle selected articles:
- Componentized blossom, ask you sweet not sweet
- How Kotlin can Make Java Development Happier
- Why did Google choose Kotlin? How kotlin solves Java Development Pain points [continued]?
- The Architect’s Path: Rereading Design Patterns Head First design Patterns
- How to optimize the android process name function?
- Breaking your mind, does Java divide by zero necessarily crash?