Welcome to a slippery slope. You've by this point realized that there is an endless variation of all the model-view interactions. MVC, MVP(Taligent, Dolphin, Passive View), MVVM just to name a few.
The Model View Presenter pattern, like most architectural patterns is open to a lot of variety and experimentation. The one thing all the variations have in common is the role of the presenter as a "middleman" between the view and the model. The two most common are the Passive View and the Supervising Presenter/Controller - [Fowler]. Passive View treats the UI as a very shallow interface between the user and the presenter. It contains very little if any logic, delegating as much responsibility to a presenter. Supervising Presenter/Controller tries to take advantage of the data binding built into many UI frameworks. The UI handles data synchronization but presenter/controller steps in for more complex logic. In either case the model, view and presenter form a triad
There are many ways to do this. Its very common to see this handled by treating each dialog/form as a different view. Many times there's a 1:1 relationship between views and presenters. This isn't a hard, fast rule. Its quite common to have one presenter handle multiple related views or vice versa. It all depends on the complexity of the view and the complexity of the business logic.
As for how views and presenters obtain a reference to each other, this is sometimes called wiring. You have three choices:
View holds a reference to presenter
A form or dialog implements a view. The form has event handlers that delgate to a presenter using direct function calls:
MyForm.SomeEvent(Sender)
{
Presenter.DoSomething(Sender.Data);
}
Since the presenter doesn't have a reference to the view, the view has to send it data as arguments. The presenter can communicate back to the view by using events/callback functions which the view must listen for.
Presenter holds a reference to view
In the scenario the view exposes properties for the data it displays to the user. The presenter listens for events and manipulates the properties on the view:
Presenter.SomeEvent(Sender)
{
DomainObject.DoSomething(View.SomeProperty);
View.SomeOtherProperty = DomainObject.SomeData;
}
Both hold a reference to each other forming a circular dependency
This scenario is actually easier to work with than the others. The view responds to events by calling methods in the presenter. The presenter read/modifies data from the view through exposed properties.
View.SomeEvent(Sender)
{
Presenter.DoSomething();
}
Presenter.DoSomething()
{
View.SomeProperty = DomainObject.Calc(View.SomeProperty);
}
There are other issues to be considered with the MVP patterns. Creation order, object lifetime, where the wiring takes place, communication among MVP triads but this answer has grown long enough already.
Android applications are fundamentally built around Model-View-Controller (MVC) - MVP sounds like the same thing, although I've not heard the term before. Activities fill the role of Controller, XML Views are just that (although you can build them programmatically in the Activity - it's just easier and simpler to do it in XML), and the Model you write yourself. So yes, that model is quite practical.
A possible reason you may not have heard much about this design model is that the Android framework forces you to separate the view out. Because the application on mobile devices tend to be small, people don't tend to use full-on MVC; they tend toward view and action layers where the action layer does much of the model's (small) job.
If you are writing a cross platform app, you may want to look at a four-layer approach: View, Action, Business Logic, and Model. The View and Action layers would be platform specific, while the Business Logic and Model would not change. Basically, you split out the presenter and user interaction out to the Action layer, which calls the Business Logic layer to perform the action the user wants.
Best Answer
In the MVP pattern is the View is "dumb". It doesn't really do anything. The presenter acts as the controlling object in the heirarchy, while the Model stores the data and has business logic methods on it.
That doesn't preclude the View from firing events, which are hooked by the Presenter to methods or properties on the model, or to other testable logic on the Presenter itself.
Your presenter has access to both the model and the view. On your presenter you can therefore hook up events fired on the View to methods or properties on the Model. The view and the model never know anything about each other.