Одному фрагменту один презентер?

#android #mvp

Есть активити у которого 3-4 фрагмента .Для каждого из низ надо создать View и Presenter?или
Несколько View можно привязать к одному презентеру?
    

Ответы

Ответ 1

Ответ может быть дан только тогда, когда вы сами архитектурно примите решение, я
постараюсь помочь: 

Согласно MVP по структуре у вас у каждой view должен быть свой pesenter, логично.
В нашем случае нужно просто решить что такое View, если к примеру у вас activity, то
фрагменты в таком случае часто называют subView, и они будут являться дополнением основной
View кое у вас Activity, тогда у них будет общий presenter. На самом деле в небольших
проектах я бы делал именно так, будет меньше зависимостей, генерируемого кода, интерфейсов,
и легче будет построить логику между фрагментами, хотя такую зависимость лучше избегать,
но...
Presenter этой view (activity) разрастеться, и потом будет тяжело расщеплять эти
куски, также такая паутина будет тяжелее тестироваться, ну опять же если проект большой.
Чтоб убедить, что такой подход довольно частый, гугл его предлагает во время аттестации
и описывает в stable blue prints MVP. 

Другой очевидный вариант, что activity выступает в роли View, а каждый фрагмент это
тоже View, что тоже вполне логично, тогда нужно будет делать для них отдельные presenter.
Те будет View(Activity) -> Presenter, View(Fragment) -> Presenter. Плюсы будут в том
что такие фрагменты будут полностью независимы, и у нас не будет такого God object
в роли жирного Presenter с логикой всех фрагментов внутри. Такой код легче будет поддерживать
и тестировать, фрагменты можно использовать правильно по их назначению в других местах
приложениях, как угодно при этом придется поправить только поведение, те в Java эту
роль берет интерфейс. Проблема есть только в начальной структуре, например в Dagger2
чтоб выстроить такой граф нужно время и умение. Те по сути вы жертвуете начальным временем,
чтоб решить какое будет поведение и всё. Такой подход я считаю более правильным, но
его почему-то реже видно в исходниках или примерах в сети.


Ответ 2

в MVP устанавливается связь 1 презентер на 1 вью.

Если ваши фрагменты, являются отдельными вьюхами по логике (разными экранами к примеру)
то да, один фрагмент - один презентер.

Если у вас есть фрагмент, в котором есть дочерний фрагмент, который неразрывно связан
с основным фрагментом, то тогда вы делаете один презентер, который связан контрактом
с внешним фрагментом. Внутренний фрагмент, если ему нужны вызовы презентера, кидает
коллбеки во внешний фрагмент и уже внешний фрагмент общается с презентером.

В итоге презентер общается с одним интерфейсом вьюхи и ничего не знает о её внутренней
реализации.

Надеюсь понятно объяснил. В кратце -  у вас должен быть один класс, который реализует
интерфейс вьюхи, а как он устроен внутри - решать вам.