Custom view and MVP So, I have a slightly complex custom view for adding and removing items: + and - buttons and "add" button when you have 0 items selected. There are disabled states if you can't get over or below some value. The view is heavily reused, mostly (but not exclusively) inside recycler views, on different elements, multiple screens. So now the question - how to structure the code in the MVP pattern? Does this custom view get it's own presenter? If yes, how does it connect to the main presenter (and how to handle recycling in this case)? Else, do I have to repeat the logic in each presenter for each screen or inject some kind of controller and pass it through the adapter to items (in which case, what's the difference with individual presenters)?

In the ideal world the view should have it’s own presenter although I’m not sure how feasible that is with some of the Android Frameworks out there. To connect it to the main presenter I’d just make sure there is some way to output the relevant information to the controller which can feed into the presenter which sounds like it’d just be the value of the view. I think a decent fallback if it won’t work is to use class delegation so you write the logic that would go into the smaller presenter in one spot which implements an interface. From there you can add it to each presenter with the

by

keyword.

Hey, sorry for late reply, I was off and way more disconnected than expected 🙂

I’d force shared communication further down the chain. The presenters for example could have access to the same repository where they can share data back and forth. In terms of the View/Presenter the output of the View could be custom objects similar to how an

EditText

exposes

Editable

.

This kinda creates a cycle of connections which I'm trying to avoid, but I guess it's not always possible...

V1 --- V2
|       |
P1     P2
  \   /
    R

If you want to avoid the cycles then you’d just avoid having the two views talking to one another, the previous message was around some options you have but not recommendations for what you should necessary do for everything. 1. Small View (such as a text field within a larger view) -> presenter could handle your general logic but it would start and stop within the view itself. The output of this would come from the view in a similar fashion to

EditText

providing

text

. 2. Larger Views (such as an entire screen) -> presenter could speak with a common repository which other presenters could observe on if they care about that data. For avoiding cycles in data, if you’re using RxJava you can attach

distinctUntilChanged()

, in a non-rx workflow it’s likely going to be a little trickier but still do-able.