У меня более низкоуровневый вопрос. Есть список с элементами, множественное выделение. Этот список лежит в адаптере во фрагменте, тк будет реиспользован. Количество элементов и сами элементы в списке константные.
Презентер фрагмента имеет метод init(List<ViewModel> elements), который просто заполняет список во фрагменте. Там фрагмент просто сам в себе отвечает за переключение элементов (пользователь кликает, сама вьюха меняет viewModel в которой есть boolean checked).

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

Вопрос: как бы вы организовали передачу списка?
mainView.onNextButtonClick() -> mainPresenter.onNextClick() -> mainView.getStates() -> innerView(fragment).getStates() -> (а ещё здесь можно через innerpresenter прогнать...) adapter.getStates()

В этом варианте смущает, что:
1) две вью общаются напрямую (внешняя с внутренней)
2) Получается, у адаптера есть метод getElements() и @xanderblinov, если я не ошибаюсь, выше писал, что они у себя так никогда не делают.

многобукф)

1) две вью общаются напрямую (внешняя с внутренней)
Кстати мне легче ассоцировать фрагмента и активти с контролером. Который делает минимальную работу. Получает данные из виюхи и передает сервису (презентеру)

Вот тогда можно принять то что фрагмент передает данные друг другу)

А когда две кнопки при клике на которые меняют состояние видимости - это не смущает? Я про то что чем отличается общение с адаптером от общения с другими вью? как бы вы организовали проверку состояния из одной кнопки - другой. Или при нажатии кнопки "Логин" где бы вы брали логин и пароль в обработчике кнопки или презентере?

ПО сути этого слоя можно юзать как контроллер. Чисто как клей

View в данном случае - компонент MVP. Соответственно, все 3 поля были бы в нужной мне вью.

чем адаптер отличается?

вот надо было бы переиспользовать кнопки.... что бы изменилось?

о, кстати, тоже бьюсь над этим вопросом, если я все правильно понял, мне кажется не очень стественным чтоли общение через View, примерно в таком кейсе что у вас

В моей реализации у кнопки бы не было своего презентера. Сейчас фрагмент притворяется "полноценным" компонентом - он вью и у него есть презентер.

Как вариант, сделать фрагмент имплементайей вью и выкинуть из него презентер...

@AntonAverin писал про ViewExtensions, очень круто у него все там, но до конца не изучил https://android.jlelse.eu/keep-your-droid-clean-activities-and-fragments-da1799fe1e7a#.aatu5ibbl

если адаптер содержит в себе презентер, то можно было бы его отдавать. Все зависит от того как написан адаптер. Я часто не отделяю внутри одаптера отдельные сущности. Телодвижений много, выхлопа не очень. Но если надо хранить состояние при повороте и восстанавливать его, то презентер всеравно внешний. И в нем должно храниться состояние чекбоксов

А как поступать с viewpagerом где одинаковые фрагменты но с разной информацией? Мне кажется можно сделать один презентер на них

фрагменты одного классы в мысле, но разные инстансы? ну да, тогда презентер тоже одного класса будет и разыне инстансы его

а такой вопрос, если у меня на аткивити единственный фрагмент  во весь экран, нужно 2 презентера, или только один, который для фрагмента?

Фрагменты одного класса, несколько инстансов. А презентер один инстанс. Так хотел. Хотя сейчас уже передумал

Ребят, у меня такой кейс. Есть данные которые нужны на нескольких экранах. Эти данные получаем из сети. Кэшировать вроде бы надобности нет, устраивает каждый раз получать новые. Казалось бы можно хранить эти данные в синглтоне. НО! Возникает проблема, что тогда мне нужно на каждом экране их с сервера получать? Иначе когда приложение вдруг будет свернуто и развернуто, то данные будут нулл если приложение будет убито, и надо их заново получать.  Так может случится на любом из экранов(активити) где нужны данные

так мне получается все же лучше хранить в бд данные?

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