• View and Presenter (Mediator) can see each other
• Presenter can only see Model
• Unit Test Friendly
• Each Presenter is mapped to a View but it’s possible a complex View can be driven by multiple Presenters
• Presenter is really Mediator Pattern – Mediates between an arbitrary view and it’s model; Mediator formats data for view; Defines callbacks
• View will have a dependency on a Presenter for sourcing dynamic data and relaying interaction callbacks
• Model is the domain layer/business logic/data provider
• To increase decoupling, each Model, View, and Presenter can employ their own respective Interface classes. Implementations would then have a dependency on abstractions and not be directly coupled to concrete implementations. One such convention is to use the “-Ops” suffix. i.e. ModelOps, ViewOps, PresenterOps
• One way to counter artifact bloat is to have each of the M,V,P abstractions exist under an Umbrella Interface. Each of the Ops would exist as inner interfaces to a MainMVP umbrella interface.

Source:
http://www.tinmegali.com/en/model-view-presenter-android-part-1/
http://www.tinmegali.com/en/model-view-presenter-android-part-2/

Share

Google+ Comments