When using MVP, should Presenters communicate with each other?

If you are a MVP purist, surely you will scoff from such a question. Views should only communicate to their respective presenters! If you’re thinking this acronym has something to do with a product (It gets used heavily surprisingly), I’d recommend moving on to this great article on Minimum Viable Product. If this sounds vaguely familiar but need a refresher, check out Wikipedia’s quick explanation of Model-View-Presenter design pattern before reading ahead.


Alright, now that we’re all on the same page, above is the typical diagram you see when explaining the responsibilities of each component of MVP. At first implementation, it really does solve a lot of headaches on Android. But as projects get bigger and more complex, you start to feel like the strict rules of MVP require lots of boilerplate.

In what situation should a presenter ever communicate with another presenter?

Take for example an Activity that is used in every aspect of your app. There’s multiple ways to reach it and it can also open other Activities that must return information back to itself. Those two requirements alone can cause a lot of interaction with a View and a Presenter.

To make it more fun, this Activity houses a horizontal ViewPager which incorporates a vertical RecyclerView. The views within that RecyclerView is has its own set of interactions and also needs to open other Activities and return back its updated information.

A strict view-to-view interaction

That’s a lot of hoops to get through in order to pass along information.

While it would be easy to use Otto to send data back and forth through layers of views (please don’t), there is an easier and more manageable way. If you’ve incorporated presenters with your views, that means you are probably already passing along a reference or creating a presenter in every view. What’s stopping you from having a parent-child relationship?

Utilizing a parent/child presenter relationship

Having child presenters require a parent presenter in its construction would provide a direct line of communication for the business logic and eliminate all the method calls needed when navigating through views. It would also improve reusability and reduce coupling since you won’t be adding methods for views in between which couples everything together. Pretty sweet huh?

When I first saw this implementation, I thought it was an odd decision until I understood how complex each view was. Realizing how much information was being sent back and forth, it makes more sense to use this technique than following the traditional methods.

What do you think about this solution? Have you implemented or used something better? I’m all 👂s!

If you found this post useful, please give it a 👏 so others like you can find it also! Off-topic questions? Remarks? Reach me at @jasenmoloy!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.