preface

Hi, I’m KunMinX, the author of “Jetpack MVVM Insights” on GitHub Star 8.7K, dedicated to deep thinking and sharing Jetpack MVVM.

I didn’t want to write an article about the essence and difference between MVP and MVVM, because after a year of immersion and methodological test, I believe that if anyone has read the systematic article “Relearning Android”, they have practiced the scarce ability to grasp the essence quickly through the appearance.

New readers join the column every day, and surprisingly, a year later, I still occasionally get consulted or see people in various communities talking about who is “good” or “bad” in MVP or MVVM.

Not every question deserves an answer

Einstein said, “Ask the right questions and the problem is half solved.”

In other words, not every question is worth answering. A question contains much more information than the content itself.

Through the questioner’s questions, you can almost instantly sense how much the questioner knows about the situation, and thus determine whether it is worth continuing the conversation.

The feeling of “high” quality question-and-answer communication — the ability to clarify context in a few sentences and then ask questions about a particular detail — made me want to talk more and share what I knew without holding back.

On the other hand, “low” quality questions feel uncomfortable, even wrong — the effort to highlight multiple points, the clarity in black and white, even paragraphs and links pointed out to him, as if they never happened.

Note: I never use subjective descriptions such as “high”, “low”, “good”, “bad”, “light” and “heavy” in technical communication, but only in a way that most people can easily understand. All subjective descriptions used in this article shall be in double quotation marks.

What’s more, they waste each other’s time in order to satisfy the pleasure of barging…

Essence and difference. I’m only gonna say it once

In fact, I don’t get to judge whether newcomers to bicker, not only through the other words, you can instantly judge each other said is a fact, or simply bullshit – you can’t and a bullshit people exchanges, you will find this conversation often there is a huge gap, and to have no intention of seeking and stitching the understanding of facts, He had come for the “come quick” moral victory.

Different from subjective preferences, facts are bound by specific background and purpose. All opinions and opinions that deviate from the characteristics of facts are nonsense, without the premise of discussion, and unworthy of participation. ©KunMinX

Therefore, this article is only for those who really want to find out the truth, only for the fate of the people.

And THAT’s all I’m going to say about the nature and difference between MVP and MVVM, so read on.

List of articles

  • preface
  • Not every question deserves an answer
  • Essence and difference. I’m only gonna say it once
  • Say first conclusion
  • So what’s the difference?
  • Relationship between Jetpack MVVM and MVVM patterns
  • Why can I instantly perceive the “good” and “bad” quality of communication?
  • To sum up

Say first conclusion

MVP essence: It is a broad architectural pattern applicable to the development of physical or virtual user interfaces.

It is mainly in the background of MVC, through dependency inversion, to solve the problem of logic reuse difficult, difficult to implement replacement.

MVVM essence: It is a narrowly defined architectural pattern dedicated to page development.

It is mainly in the context of multi-person collaborative software engineering, by only manipulating the view data mapped in the ViewModel to refresh the view state, so as to solve the consistency problem of view calls and avoid unexpected errors.

So what’s the difference?

The difference is:

One is architecture in a broad sense:

You can use the same set of logic to drive physical user interfaces (for example, different brands of headphone controllers) or virtual user interfaces (for example, Android View, which is not recommended because of consistency issues) for different brands of devices.

One is architecture in a narrow sense:

Dedicated to visual page development, avoiding unexpected errors by solving consistency problems.

So you can easily see that the two are suitable for solving different problems in their own special field. There is no comparison, let alone the so-called “good” and “bad” ones.

And there’s really no relationship between the two, except that they’re not comparable. MVP is dependent inversion and MVVM is data-driven. There’s no relationship between who evolved from who. Going back to what I said earlier: “Fundamentally two very different architectural patterns for solving specific problems in specific scenarios.”

There is no such thing as MVVM == MVP + DataBinding, just as there is no such thing as Leifeng Pagoda == Leifeng pagoda + tower.

Relationship between Jetpack MVVM and MVVM patterns

Jetpack MVVM is an implementation of the MVVM pattern in Android development, which not only incorporates the nature of the MVVM pattern to solve the “consistency problem of view calls,” but also addresses other unexpected errors in Android page development.

As I explained in Jetpack MVVM Essentials:

Lifecycle exists primarily to solve the problem of consistency in Lifecycle management.

LiveData is designed to help novice and experienced developers follow the standardized development philosophy of distributing state through a unique trusted source without thinking, thus avoiding a series of difficult to trace, difficult to troubleshoot, and unexpected problems during rapid development.

Viewmodels exist primarily to solve the problem of state management and page communication.

DataBinding exists primarily to solve the problem of consistency in view calls.

Most of them exist to solve the problem of consistency under the background of software engineering, and encapsulate error-prone operations in the background, so that users can quickly, stably, and do not produce unexpected error coding.

Therefore, Jetpack MVVM’s high-frequency core architecture components must be different from the implementation of iOS and WPF, but by grasping the essence, we can make the same changes.

The only challenger to DataBinding, based on automated generation of intermediate code for DataBinding, is a data-driven UI framework based on functional programming ideas. React, Flutter, Jetpack Compose and SwiftUI originate from the front-end Elm framework.

So does a Flutter, for example, count as an MVVM? No, but both are essentially addressing the problem of consistency in view calls.

So…

Why can I instantly perceive the “good” and “bad” quality of communication?

In fact, After the essence is introduced in the conclusion section, it is customary for me to begin with “Before” and “After” by saying “if this is not understood,”

Because new readers join the column every day, almost every article is released in the integrity of an independent album so that they can read it randomly based on their own interests.

That’s why I treat every article as if it’s the first time I’m meeting readers, and I spare no effort to implement the unique deep thinking writing style of the whole web, so that every new reader has a chance to communicate with the spirit that I inject into the article.

This time, however, I had to be a little capricious, for if I had not understood what I had said above, the answer would have been written in the following passages:

“Dessert should not be eaten as a staple food” section;

The “So How to Think Right” section of “Fundamentals: Principles of Deep Thinking that Can be Applied anytime, Anywhere”;

The “Cognitive Map” section of “This is a Concise and Powerful Cognitive Map”;

Each of these places provides methodological evidence and hand – by – hand demonstrations of the right way of thinking.

Once you’re familiar with the methodology, will you participate in the endless debates? I think most likely not, because you can tell at a glance that there is no fact-based thinking involved in these statements, but that they are self-reported, based on subjective feelings and personal preferences.

It’s disrespectful to yourself to participate in this bullshit, so you won’t.

To sum up

The essence of MVP is the inversion of MVC dependency to solve the problem of logic reuse and implementation replacement.

Because under MVP, UI logic and business logic are all written in Presenter, and UI and Model implementations are interchangeable,

In other words, the same set of Presenter logic can drive the line-control of different brands and models of earphones. (Note that the full name of UI is “user interface.” The Taiwanese term is more accurate: “User interface.” UI is not a page in the narrow sense, UI is UI.)

The essence of MVVM is the mapping of View data to solve the consistency problem of View calls in the soft work background.

The difference between MVP and MVVM is that the former is a broad architectural pattern that is universally applicable; The latter is a narrowly defined architectural pattern, dedicated to page development, that addresses issues such as consistency in view calls to avoid unexpected errors.

MVP and MVVM have nothing to do with each other.

Jetpack MVVM is an implementation of the MVVM pattern on Android, which addresses other consistency issues in addition to view calls, avoiding unexpected errors and allowing software development to get done faster and better.

The full text after

Copyright statement

This article is issued under the CC signature – Non-commercial Use – No Deduction 4.0 International Agreement.

Copyright © 2019 – present KunMinX

Detailed description of “The Essence and difference between MVP and MVVV”, examples of “User Interface and Headphone Control”, architectural design illustrations, detailed description of “Relationship between DataBinding and Functional Programming Data-driven Framework”, “Relationship between Jetpack MVVM and MVVM” “Lifecycle, LiveData, ViewModel, DataBinding and other architectural components of the meaning of existence”, “by solving consistency problems to avoid unexpected errors” and many other generalizations about specific phenomena and their nature are the work of my own original work. I have the right of ownership and final interpretation.

When you refer to or quote the introduction, ideas and conclusions of this article for second creation, or reprint the full text, you must indicate the link source, otherwise we reserve the right to pursue responsibility.