Ну в моем кейсе это не проблема. Более того, из-за наличия гуглокарт точка регистрации фрагмента в otto варьируется между onCreated (если нет карт, или они в light mode) и onMapReady (если есть карты). Поэтому вынести в какой-то базовый класс регистрацию в шине не удастся (простым способом).
Что до варианта Константин Кирюшин , то он имеет право на жизнь, и в общем-то похож на описанный выше 2-ой вариант. Но только меня сильно смущает вынесение чего бы то ни было в активити. Всегда придётся держать в голове вопросы про отработку жизненного цикла активити. А этой сложности не хотелось бы.
В своём проекте я максимально разгрузил все активити и они выполняют у меня ровно две функции:
1) Инстанцируют фрагменты с передачей полученный в интенте данных
2) Управляют отображением фрагментов согласно текущей конфигурации (в том числе специфичными моментами UI, типа кнопки переключения между map/list фрагментами на маленьких экранах)
Хотелось бы сохранить такой минималистичный подход.
Начал реализовывать 2-й, но смутило возросшее число зависимостей в коде. Поэтому плюнул и сделал наиболее простой и прямолинейный 1-ый. Фрагменты дёргают presenter'а за интерфейсы, presenter работает с данными и вручную дёргает notify-методы для каждого зарегистрированного в нём фрагмента (кроме вызвавшего). Для случая, когда работа с моделью не уходит дальше простых действий, выглядит весьма удобоваримо. Да, есть пустые методы, кода стало побольше, но он шаблонный и прост для понимания.
Теперь планирую упростить код, избавившись от велосипедов с нотификациями и добавив какой-нибудь event bus (Otto?). Думаю тогда все минусы 1-го варианта сойдут на нет. Тем более, что сетевое взаимодействие тоже планирую делать на связке retrofit+otto.
Вот не могу согласиться с тем, что модель должна как-то участвовать в согласовании внешнего вида вьюшек. То, что у нас выделен элемент списка, никак не должно отмечаться в ней. Это не та информация, для которой придуман этот слой абстракции. Сегодня у нас есть возможность выделять элементы, а завтра нет, и что - переписывать слой модели?
Про дополнительный слой - да, я склоняюсь к его необходимости. Только в моей картине мира он расположен не между презентером и моделью, а между вьюхами и презентером, так как хочется, чтобы презентер работал только с потоками данных к/от модели.
Не разделять View и Presenter в андроиде означает неимоверно раздувать активити/фрагменты жутким кодом, который одновременно реализует и поведение вьюхи, и работу с моделью. То есть все то, от чего хочется уйти при помощи MVP.
В решении с несколькими Presenter'ами меня смущает то, что оба фрагмента (т.е. View) реализуют почти полностью идентичный набор действий (CRUD с маркерами + выделение маркера). Тогда оба presenter-а будут почти (если не абсолютно) идентичны, и мы сильно нарушим принцип DRY.
Да и главный вопрос - как согласовывать состояния View-шек остаётся открытым. Если вы предлагали сделать Model как Observable именно для того, чтобы распространять информацию об изменениях View, то это, на мой взгляд, еще более жёсткое нарушение MVP. Состоянию View (грубо говоря, их внешний вид + поведение) делать на уровне модели нечего.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.