Why MVP is outdated in Android

Time flies, especially in software development. MVP was one of the famous architecture in Android development few years ago, but more and more people start switching to MVVM pattern now. In this article, I’ll describe why I’m moving from MVP to MVVM after 2 years experience in MVP and provide my point of views.

If you have no idea about MVP you can read my 2 years ago article first — https://medium.com/@jintin/mvp-architecture-in-android-1f98a74e7e1b

All the problems I found in MVP are all relate to the Big Interface and Circular Dependency, let’s walk through one by one.

Big Interface

Too much responsibility in the contract interface, and the interface will keep change according to the view change. It break several SOLID principle like Single responsibility, Open/closed Principle and Interface Segregation Principle.

Meaningless

The function we added into the contract interface is mostly meaningless, whenever you want to extract some logic from View into Presenter, you’ll need to add more functions into the contract. Same as when you want to call something from Presenter to View. As a result, the contract will bigger and bigger from time to time and just looks like a public methods table of your Presenter and View. It’s not an object-oriented programming language, it more like a header file in C.

Reuse

Since the contract is not designed by the object-oriented thinking, it’s hard to reuse. If you want to create a new View to use the same interface, you probably will find you can’t or you have to mess up the contract interface. For example you want to A/B test on some existing View base on the MVP pattern, and the different View have different public method need Presenter to call. How can we deal with that gracefully?

Granularity

It’s always a good practice to extract business logic from View, but sometimes you’ll ask yourself how detail would you need/like to do. And there’s no standard for it. If you are in a large team with many developer with different opinion, it will become a problem in code review.

Circular Dependency

Another big problem is the circular dependency. Maybe it’s not a suitable name to describe as you might want to tell me Presenter and View only depend on the contract interface not the real implementation. Yes, but the truth is the contract interface is just a bundle of method we need from each side. No one is smart enough to design the interface first and implement the detail later without having problem. The interface layer is good to help us make test possible and easily, but I still treat them as tightly coupled with each other.

And although it’s not an egg and chicken problem since the dependency we need is not necessary to set at constructor level but the Presenter and View still rely on each other all the time. For example when you want trace code with MVP structure, you’ll find yourself keeping back and forth in Presenter and View classes.

Modularization

Modularization is not a necessary to every app, but you’ll find some bad smell of your app when you trying split modules and you found you couldn’t. Speaking of a good modularization, it’s usually better to let module depend on less dependency and the relation between each module is matter as well. My dream architecture is what Uncle Bob describe in The Clean Architecture where each layer only can depend on one inner layer, but it’s hard for MVP to follow the rule since Presenter need to know View, at least the View‘s interface, and it also wired to put contract interface into a inner module as well.

https://blog.cleancoder.com/uncle-bob/images/2012-08-13-the-clean-architecture/CleanArchitecture.jpg

Conclusion

Software is really a fast phase industry, who can ever imagine the MVC pattern will some day become outdated back to twenty years ago? I think MVP still a good architecture in the history, and some day there definitely will have a new pattern which is better than MVVM as well. If you want to ask me what is it, let see you again maybe two years later. ^^