- State management is simpler. Since with MVVM your View is bound to (and automatically reflects) your ViewModel state, the job of the ViewModel is simply to react to events and maintain its own state. With MVP the Presenter not only needs to maintain its own state, but it also is responsible for pushing state changes to its View. As such, it is very easy for the 2 to become out of sync.
- Less code. Using MVVM I have been able to successfully reduce my Views to being nothing more than layout XML files (with supporting custom view bindings). This can’t be done with MVP as you need an Activity, Fragment, or custom View Java class to implement methods expected by the Presenter. What’s more, if you want to maintain a layer of abstraction between the View and Presenter (as the pattern defines that you should), then you also need a View Interface defined through which the Presenter drives the View.
- Scales better. In addition to the many built-in bindings that you get out-of-the-box with the DataBinding library, additional custom bindings can be defined as needed in a generic, non-use-case-specific way. Then they can be used repeatedly. Over time your custom-bindings collection will grow and support a large number of Views, use-cases, and can even be shared across projects/applications. With MVP every View is like starting from scratch, with any number of
setText(...)calls and the like. Of course you can build a collection of custom views for reuse, but I find those to often be much more use-case specific to allow a significant amount of reuse.