MVP в Android'е со сложным интерфейсом из нескольких фрагментов. Как лучше скоординировать?

Question

[CheY]

Всем привет.

Пытаюсь освоить разработку под Андроид и после пары заходов всегда увязал в спагетти-коде раздутых активити и фрагментов. Поэтому решил применять best practices в плане архитектуры, а конкретнее MVP. В принципе идея красивая и реализуется все довольно просто, но возник принципиальный вопрос.

Предположим, что у нас есть two-pane приложение - для конкретности возьмем карту с маркерами и список этих маркеров. Соответственно имеются два фрагмента: MyMapFragment и MyListFragment. В общем случае события выделения, добавления, удаления, нажатия и прочие могут отлавливаться любым из них. Задача в том, что требуется координировать состояния обоих отображений: если мы выделили маркер на карте, то нужно выделить его и в списке, или если изменили название маркера в списке, то нужно тут же обновить его на карте.
Вопрос: какой способ наиболее корректен?

Я вижу три варианта:
1) Все вопросы координации вьюшек лежит на Presenter'е.

Соответственно сразу после инстанцирования Presenter'а, мы регистрируем каждый фрагмент в нем как реализацию интерфейсов для колбэков MarkersView. При этом важный момент: Presenter явно знает какая реализация к чему относится и какая именно реализация к нему обращается. Иными словами, помимо функции маршрутизации данных от View к Model и обратно, наш Presenter теперь так же занимается маршрутизацией нотификаций о событиях между известными ему View.
Но как я понимаю, это нарушает идеологию MVP в том плане, что Presenter теперь слишком многое знает о представлениях.

2) Presenter занимается только маршрутизацией данных, а согласованиями вьюшек - отдельный класс-посредник MarkersViewsMediator.

В этом случае Presenter слеп и принимает события от любого из фрагментов и вызывает колбэки того фрагмента, который к нему обратился. Для согласования своих состояний фрагменты используют MarkersViewMediator в качестве общей шины для передачи обновлений своих состояний.
Но тут можно заметить потенциальную проблему - Presenter ничего не знает о зарегистрированных в нем фрагментах (это хорошо), поэтому может либо дёрнуть коллбэк одного обратившегося к нему фрагмента (похоже на вариант, когда у каждого фрагмента своя копия presenter'а), либо всех сразу (и тут уже могут всплыть проблемы и нехороший код).

3) Как п.2, но Fragment'ы общаются с Presenter'ом только через посредника.

Иными словами, наш посредник становится мастер-представлением, координирующим работу фрагментов, отсылающим события Presenter'у и предоставляющим реализацию колбэков.
Но размеры такого класса могут быть внушительны и в целом он должен полностью знать подключенные к нему фрагменты.
Можно заметить, что на роль такого посредника может подойти активити, содержащая эти самые фрагменты. Правда придётся тесно завязываться на события её жизненного цикла. Другой вариант - отдельный синглтон.

Или может есть другой более правильный способ?

Comments

[Ernesto Guevara]

А почему для разных View один Presenter? Я всегда думал, что Presenter содержит логику, специфичную для конкретного View. Может, сделать разные Presenter'ы, а модель Observable ( https://en.wikipedia.org/wiki/Observer_pattern )?

[CheY]

В решении с несколькими Presenter'ами меня смущает то, что оба фрагмента (т.е. View) реализуют почти полностью идентичный набор действий (CRUD с маркерами + выделение маркера). Тогда оба presenter-а будут почти (если не абсолютно) идентичны, и мы сильно нарушим принцип DRY.
Да и главный вопрос - как согласовывать состояния View-шек остаётся открытым. Если вы предлагали сделать Model как Observable именно для того, чтобы распространять информацию об изменениях View, то это, на мой взгляд, еще более жёсткое нарушение MVP. Состоянию View (грубо говоря, их внешний вид + поведение) делать на уровне модели нечего.

[Ernesto Guevara]

CheY: меняется не View, а Model. Один View меняет модель, а она оповещает всех остальных, что изменилась. Если надо оповещать об изменениях текущего курсора и подобных состояний, то можно ввести между моделью и Presenter некий промежуточный слой, который будет Observable и хранить текущее состояние. Тогда подключение к модели будет осуществляться через этот промежуточный объект.

Нечто подобное сделано в .NET WinForms. Там через BindingSource "View" может подключиться к данным. BindingSource же хранит ссылку на модель и текущий курсор.

А еще я бы подумал о целесообразности вообще разделять View и Presenter. Много ли полезного будет делать View? Думаю, тут многое зависит от конкретного случая. Есть же еще принцип KISS :)

[CheY]

Вот не могу согласиться с тем, что модель должна как-то участвовать в согласовании внешнего вида вьюшек. То, что у нас выделен элемент списка, никак не должно отмечаться в ней. Это не та информация, для которой придуман этот слой абстракции. Сегодня у нас есть возможность выделять элементы, а завтра нет, и что - переписывать слой модели?

Про дополнительный слой - да, я склоняюсь к его необходимости. Только в моей картине мира он расположен не между презентером и моделью, а между вьюхами и презентером, так как хочется, чтобы презентер работал только с потоками данных к/от модели.

Не разделять View и Presenter в андроиде означает неимоверно раздувать активити/фрагменты жутким кодом, который одновременно реализует и поведение вьюхи, и работу с моделью. То есть все то, от чего хочется уйти при помощи MVP.

[Copperfield]

CheY: какой вариант в итоге применили?

[CheY]

Начал реализовывать 2-й, но смутило возросшее число зависимостей в коде. Поэтому плюнул и сделал наиболее простой и прямолинейный 1-ый. Фрагменты дёргают presenter'а за интерфейсы, presenter работает с данными и вручную дёргает notify-методы для каждого зарегистрированного в нём фрагмента (кроме вызвавшего). Для случая, когда работа с моделью не уходит дальше простых действий, выглядит весьма удобоваримо. Да, есть пустые методы, кода стало побольше, но он шаблонный и прост для понимания.

Теперь планирую упростить код, избавившись от велосипедов с нотификациями и добавив какой-нибудь event bus (Otto?). Думаю тогда все минусы 1-го варианта сойдут на нет. Тем более, что сетевое взаимодействие тоже планирую делать на связке retrofit+otto.

[CheY]

Что до варианта Константин Кирюшин , то он имеет право на жизнь, и в общем-то похож на описанный выше 2-ой вариант. Но только меня сильно смущает вынесение чего бы то ни было в активити. Всегда придётся держать в голове вопросы про отработку жизненного цикла активити. А этой сложности не хотелось бы.

В своём проекте я максимально разгрузил все активити и они выполняют у меня ровно две функции:
1) Инстанцируют фрагменты с передачей полученный в интенте данных
2) Управляют отображением фрагментов согласно текущей конфигурации (в том числе специфичными моментами UI, типа кнопки переключения между map/list фрагментами на маленьких экранах)
Хотелось бы сохранить такой минималистичный подход.

[Rustem Saitkulov]

CheY: Otto для данного кейса не стоит, используй greenrobot:eventbus

[CheY]

Рустем Саиткулов: почему? собственно уже сделал вариант с otto и никаких минусов не обнаружил

[Rustem Saitkulov]

CheY: вроде бы EventBus работает при наследовании (например от своих базовых классов), Otto - нет.

[CheY]

Ну в моем кейсе это не проблема. Более того, из-за наличия гуглокарт точка регистрации фрагмента в otto варьируется между onCreated (если нет карт, или они в light mode) и onMapReady (если есть карты). Поэтому вынести в какой-то базовый класс регистрацию в шине не удастся (простым способом).

Answer 1

[Константин Кирюшин]

По best practices взаимодействие двух фрагментов организовывается через Activity, которое их хостит.
Среди предложенных вариантов мне больше всего мне нравится вариант 3.
В рамках задачи я бы сделал Activity = MasterView, и общался бы Presenter'ом c Activity. Далее Activity служило бы Mediator'om и неким координатором для фрагментов.

НО.

Предлагаю рассмотреть схему с двумя Presenter'ами. Первый отвечает за загрузку списка маркером и работает с MyListFragment, второй за работу с картой и привязан к MyMapFragment.
А медиатором все так же является Activity с интерфейсами.



Как это будет работать? (внешний код опущен)

MyListFragment:

//MapInterface реализует Activity для взаимодействия между фрагментами.
mMapInterface.onMarkerSelected(marker);

Activity:

public void onMarkerSelected(Marker marker) {
      mMapFragment.selectMarker(marker);
}

MapFragment:

public void selectMarker(Marker marker) {
       //например грузим информацию по маркеру
      mMapPresenter.loadMarkerInfo(marker, someCallback).
      //или просто производим манипуляции со View.
}

Также:
Если же операции, выполняемые с Моделью одинаковые, то можно обойтись один презентером, но все равно он будет дергаться из Фрагментов. Потому что, раз мы говорим о хорошем дизайне, в случае дальнейшего усложенения логики Фрагментов, лучше чтоб каждый хостил свой Презентер.

С удовольствием подискутирую на тему.
Спасибо!