Custom view and MVP So, I have a slightly complex ...

# android-architecture

[Rok Koncina]

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)?

[Cody Engel]

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.

[Rok Koncina]

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

[Rok Koncina]

Thanks for the answer but I'm looking for some details, like - do presenters talk to eachother? Or do views and presenters just trigger the communication? From what you wrote it looks like the presenters should have some direct (more or less) connection, without involving the views? But in that case the presenters are quite interconnected, should you really expose the "custom view's presenter" outside of the custom view?

[Cody Engel]

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.

[Rok Koncina]

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

[Cody Engel]

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.