Как обмениваться данными между двумя ведущими в архитектуре MVP в Android?

Вот пример сценария:

У меня есть активность (представление) и презентатор для этой точки зрения. Ведущий выбирает список пользователей из сетевого API и удерживает его в памяти с помощью объекта «Список». Активность содержит различные типы фрагментов для отображения содержимого о пользователях на основе User.type. Эти два фрагмента (UserType1Fragment и UserType2Fragment) также имеют свои собственные ведущие.

Ведущий мероприятия решает, какой тип (I или II) фрагмента показан ниже. Ведущие фрагментов решают, как отображается объект пользователя, и обрабатывать событие нажатия кнопки с именем killUser (). Это должно обновить объект List в презентаторе активности.

Вот в чем проблема:

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

Поэтому я закончил реализацию чего-то вроде того, что рекомендовал @Jahnold. (Я опубликую диаграмму в ссылке, предоставленной для идеи stackoverflow.com/a/41966497/568898 )

Ханнес Дорфманн (парень, который создал / управляет знаменитой библиотекой MVB Mosby: ссылка Github ) также указал мне в этом направлении.

Введите описание изображения здесь

Реализация

У меня есть ведущий для основной деятельности и нескольких фрагментов, которые можно использовать в этой деятельности. У каждого фрагмента есть свой ведущий. Затем я использую репозиторий (поиск шаблона репозитория), который в основном хранит модели и бизнес-логику. Для моего варианта использования я сохраняю этот репозиторий как одноэлементный. Репозиторий предоставляет данные в трех формах, из онлайн-api, sqlite-базы данных или кеша, хранящегося в памяти (в основном, арраиста элементов). У меня также есть некоторые currentitem int indexes и прочее в этом репозитории, которые обновляются в зависимости от текущего состояния.

Следовательно, данные, состояние и бизнес-логика хранятся в этом общем хранилище. Ведущие и взгляды довольно тупые. У меня не так много бизнес-логики (специфическая для приложения логика) у ведущих. У них просто есть логика, связанная с тем, как данные должны отображаться (просмотреть конкретную логику) и препроцессировать в логике их.

пример

Всякий раз, когда фрагмент и активность должны разговаривать друг с другом (через докладчиков), когда пользователь нажимает кнопку в дочернем фрагменте, фрагмент запрашивает у своего ведущего handleClick, ведущие обновляют текущие данные хранилища репозитория (или что-то еще) и запрашивают фрагмент Для запуска события (например, onbuttonclick) для прослушивателя интерфейса, который реализует эта активность. Когда действие получает событие, оно просит его собственного ведущего обрабатывать его, и в свою очередь ведущий активности ищет обновление в репозитории для получения нового currentItemSelected.

Дополнительная информация (расширенная версия) :

Вы также можете следить за чистой архитектурой, которая является своего рода более продвинутой версией архитектуры MVP. MVP просто имеет дело с архитектурой представлений, где, поскольку чистая архитектура также имеет дело с бизнес-логикой и архитектурой данных, MVP – это лишь небольшая часть чистой арки, которая используется для обработки представлений. Используя это, вы можете разбить мега-репо в моем случае на еще более используемые случаи использования (или взаимодействия), которые обрабатывают конкретный случай использования бизнес-логики, а репозиторий просто предоставляет данные. Таким образом, логический поток теперь представляет собой просмотр -> презентатор -> интерактор -> репо и обратно.

Вы можете передать ссылку на фрагмент с помощью newInstance () фрагмента. Я думаю, что ведущие не должны напрямую общаться друг с другом.