MVP pattern - what is its essence?

Question

Android

What is the essence of the MVP pattern in Android development?
Layer View - Activity with widgets (EditText, Button, ListView, etc), in which the code is just super.onCreate() with setting the layout and defining widgets, yes event listeners, but the methods themselves in the Presenter layer ?
Is the Presenter layer a "worker class" reacting to every event from the View and Model? We filled in the login and password, clicked LogIn - we called the button click processing method in the Presenter. The latter receives data. Then sends the data to the server ( Model layer ), processes the data according to the server's response, and renders the interface through the View methods (similar to the controller in MVC PHP)?
Notes-Questions.
1. How is it "more correct" to pass the login and password - through the method parameters, or ..?
2. Drawing data in the View - through the static methods of the View or creating an instance of the View and calling the instance methods (why such a garden?)?
3. In onResume, restoring the state (from a Bundle instance or something else) - through a Presenter call with the transfer of a Bundle instance?
4. Saving data on onPause (pausing or shutting down the application) - pass changed data to Presenter through method parameters?
4.1. Or is it "more correct" to subscribe the Presenter to each data change in the View, and only pass, say, the Activity context through the parameters?
5. Opening-closing the side menu by pressing the "hamburger" or the hardware button Menu - also through the Presenter? Those. in View - only data filling, no queries, no data processing, the only reaction to events is calling methods from the Presenter?
6. Is the use of interfaces mandatory? Those. a list of data filling methods was written in the interface, the Activity class is inherited from this interface, and in this Activity the methods are already implemented.

Answer 1

The bottom line is that the code in the activity is difficult to test. In addition, the problem of activity growth, the inclusion in it of various kinds of code that works with views, logic, database, services, and so on and so forth.
Therefore, programmers looked for ways out and found them. )
MVP was invented long before android. Its essence (as well as other similar templates) is the separation of the model and ui. The peculiarity is that we make a completely passive view, we transfer the logic of the view to the presenter.
schematically it is like this: there is an interface view. Activity implements this interface. the presenter knows about this interface.
It turns out that the presenter does not depend directly on the activity, only on some interface. Therefore, it is relatively easy to test it (substituting your view stub)
This solves two main problems:
- the code has become more testable
- the code is divided into a passive activity and its logic in the presenter.
For questions:
1. The activity reads the password and logs and passes them to the presenter (by calling the appropriate methods of the presenter). and he further processes from.
2. Drawing data is done by an activity with an interface (named for example ActivityView). the presenter has a link to this interface (the activity passes its link to it), and then calls for example activityView.setText(text)
3. there are two approaches
a) the lifetime of the presenter is equal to (no more than) the lifetime of the activity
b) the lifetime of the presenter is greater than the lifetime activity
respectively a) data is stored in budle and passed to presenter
b) data is stored in presenter
4 - above
5. activation - passive object. control via presenter. any even slightly complex logic in the presenter.
Interfaces are required. otherwise, we will lose testability and not get rid of the hard dependency of the presenter-activity.
it's all described very inaccurately. for example, instead of "activities" you can substitute "fragment". but I hope you get the gist.

Answer 2

6. Interface is optional, but desirable.
The trick is this: if you do not have an interface, then you can write any methods in your Activity as you like, and if you first describe the interface and then make its implementation, then you have to comply with the requirements of the interface. And when one interface has several implementations, their methods will be the same, and not just any, which greatly facilitates the further development and development of the project.
I don't know much about android.

Answer 3

On mvp for android, read the authors of moxy, there are several articles on habré, there are several examples in turnips on github