The original address: https://juejin.cn/post/6844903465060139016

Foreword (with welfare at the end)

Since Google released the official MVP Sample last year, more and more people have joined the RANKS of MVPS, and the MVP has flourished in 2016, and I have taken advantage of this opportunity to launch my MVP framework and create a wave of presence

The problem

However, I also found many disadvantages in the application, which led to many beginners never using MVP in their own projects after writing the Sample

MVP requires creating too many classes and interfaces, and passing information through interfaces is tedious for every communication

This is most of the friends who have used MVP, can feel the most. Recently, when helping the company’s technical side, I often ask candidates, can you try to solve these problems?

The solution

In fact, I have a set of solutions before, in fact, can not be called a solution, can only be said to alleviate 😅

Hard to solve

The hard solution is to use the more violent method 😂, using Template to automatically generate the required classes and interfaces, so as to reduce the frequent copy-and-paste

Soft solve

The so-called soft solution, that is about to move the brain, a little elegant solution 😀

  1. For simple pages, you can skip Presenter and process logic in an Activity or Fragment. If you don’t need to process data in a Presenter, you can skip Model

  2. Presenter and Model can be reused without limit, so the classification of MVP does not need to be too fine-grained. A coarser granularity is needed, that is, it does not need to have a set of MVP for each Activity or Fragment An Activity or Fragment can hold multiple types of Presenter objects according to different needs. The Model layer is the same. This flexible use can alleviate the MVP class and interface more to a certain extent disadvantages

It doesn’t quite solve the problem

The above solutions can alleviate some of the shortcomings of MVP, but cannot completely solve the above shortcomings

For example, if you want to reuse presenters, they must contain only the common logic, and the actual project does not have that much common logic, so the reduction of classes and interfaces is limited. If you force the logic of different pages into the same Prsenter to achieve reuse, then each Activity will Forced to implement many unnecessary methods, the loss is outweighed by the gain

Seek a solution

So I looked at most MVP frameworks to see how to radically improve this problem, like the T-MVP framework used by the Alipay team, by having an Activity or Fragment as a Presenter and pumping UI actions into a Delegate as a View layer

TheMVP advantages

The advantage is that not only are there fewer classes to write, but Presenter can be directly tied to the Activity or Fragment lifecycle (but use Lifecycles in Google’s newly released Android architecture component) You can easily bind any class to the Activity or Fragment lifecycle, including Presenter, and the Support Library V26.1.0 has this component built in. You can reuse views as you like (but most scenarios reuse presenters because the View layer changes more often than the other layers).

TheMVP shortcomings

The disadvantages are that Presenter cannot be reused, and the implementation of Presenter is limited to an Activity or Fragment. If Presenter is to be implemented elsewhere, such as Adapter,Dialog must rewrite the corresponding Presenter base class according to its characteristics

Because the Presenter base class inherits activities or fragments, if we want to use other activities or fragments through inheritance, we need to modify the Presenter base class again. If an Activity inherits from a different Activity, we need to modify the Presenter base class again Create a Presenter base class based on this Activity, resulting in multiple Presenter base classes for an Activity or Fragment

Analyze and solve problems

Summarize the shortcomings of the MVP

If you want to reuse presenter, you may implement too many unnecessary interfaces. 3. Communication between presenter and View through interfaces is too cumbersomeCopy the code

In order to fundamentally solve these problems, I think we have to think differently. Can we solve these problems by changing the traditional MVP structure?

There are two ways to achieve MVP at this stage, each with advantages and disadvantages:

One is to use an Activity or Fragment as a Presenter, abstracting it from a View layer

One is to abstract an Activity or Fragment as a View from the Presenter layer

I wanted to reuse presenters, so I naturally chose the latter

One day I came up with the idea of Handler, a method that uses a single handleMessage method to handle different operations according to the What field of Message, providing a unified entry point to the upper layer, and allowing multiple operations to be performed as well, regardless of how the lower layer changes

With this in mind, I reworked the MVP architecture to let Presenters communicate with the View layer through Message

How to implement

On the first picture

The VIEW layer holds Presenter objects. When a user requests an event, it calls a method in Presenter and passes a Message holding a VIEW reference to the method. After processing the request logic, the method encapsulates the data in Message and passes the VIEW reference held by Message Call back to the View’s handleMessage method, let the View do different things, and finally release all references to Message into the Message pool

The View is not owned directly by the Presenter, and the View is removed when the method is executed

It’s a lot like Handler, where you put a message into a MessageQueue,Looper to go round and process the message, and in this case you put a message into a Presenter method and process the message immediately

conclusion

In this way, the disadvantages mentioned above can be solved:

  1. A lot less classes and interfaces

  2. The Presenter only needs to communicate with the View through the handleMessage method, so there is no need to add interface methods all the time. The Presenter only needs a Message parameter to encapsulate data. If the View needs to change the data type, there is no need to change any method Affecting upper-level calls

  3. Reuse presenters. Even if you reuse 10 different presenters in one Activity, you only need to implement one handleMessage method. You don’t need to implement any other method in the View Resenter. Most presenters have only one or two methods, resulting in a large number of presenters with very little code. Have you ever wondered how cool it would be to write similar logic into a Presenter and reuse it all the time 😁)

  4. When a method in a Presenter needs the Activity to pass some data, it can also wrap the data in a Message and pass it to the Presenter. This way, if the data type is changed, the method does not need to be changed, so it does not affect the upper-level invocation

MVP can only be powerful if it can be reused flexibly

Of course, a lot of different logic is written in a Presenter, although it can write a lot of classes, but the later scalability is not good, so this granularity needs to be controlled by oneself, but it is a good news for outsourcing projects

Having said that, I still want to see the Demo, how to do it?

Go! Feel good must top right Star oh!

The public,

Scan the code to follow my official account JessYan to learn and make progress together. If there is any update to the framework, I will inform you immediately on my official account

Hello, my name is JessYan. If you like my articles, you can follow me on the following platforms

  • Personal homepage: Jessyan.me
  • Making: github.com/JessYanCodi…
  • The Denver nuggets: juejin. Cn/user / 976022…
  • Jane: www.jianshu.com/u/1d0c0bc63…
  • Weibo: weibo.com/u/178626251…

— The end