чтобы каждый фрагмент отвечал только за свой тулбар, и не было shared state в приложении для toolbar.

поищите объснение в архитектурном чате

Ойей

Евгений правильно направил, спросите в архитектурном

В архитектурном это где?

Благодарю

Кажется больная тема=)

Ну как бы вот оно и глобальный тулбар это как раз вариант 1

#кейсы
Вопрос:
Есть активити с тулбаром, внутри которой переключаются фрагменты. Как из вьюшки (фрагмента) взаимодействовать с тулбаром (например поменять тайтл)?
Что предлагаем:

Вариант 1:
Тулбар в данном случае будет независимой вьюшкой, со своим собственным презентером. Презентер тулбара подписывается на модель (репозиторий), которая хранит состояние тулбара. Эта модель является глобальной для всех презентеров внутри этой активити. Остальные презентеры при надобности имеют право писать в модель, а презентер тулбара должен соответственно реагировать на ее изменения.

Вариант 2:
Зачастую надобности в глобальном тулбаре нету. Тогда у каждого фрагмента можно сделать собственный тулбар. Поскольку в данном случае он будет являться частью текущей вьюшки, то презентер сможет обращаться к нему напрямую (например через метод во вью setTitle)

А тут, не поверите, вариант 2 :)

А вообще, вбейте в поиск по той группе фразу «Общий туллбар - это сплошной геморрой» - там будет обсуждение)

Ну если он действительно сильно должен изменяться от фрагмента к фрагменту то да

Оффтоп: делал приложение с общим тулбаром на весь главный экран. Огрёб очень сильно по следующим причинам:
1) Дизайн был очень занимательный, на разных экранах в тулбаре были спиннеры, сабтайтлы, аватарки и т.д.
2) Взаимодействие с активити: стали появляться "полноэкранные" фрагменты, с другим фоном и всё подобное. На всё это приходилось добавлять соответствующие методы..
3) Потребовалось реализовать скрытие тулбара при скроле. При этом в одном из фрагментов был ViewPager с табами, а на тот момент support имел много косяков, связанных с CoordinatorLayout. В итоге все костыли в виде кастомных поведений стали глобальными, и понеслось...

Сделал для себя вывод: даже если в приложении будет всего несколько экранов, то всё равно буду использовать toolbar внутри фрагмента.

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

убедили =)

ребят,повторю вопрос,так как вы presenter методы будете тестировать если у вас некоторые методы  вынесен в абстарктынй класс  (я про CompositeDisposable)?

на текущий момент тестов для Presenter вообще нет.
А что именно нам не позволит оттестировать данная реализация?

вам же надо будет дял тестов ваш базовый презентер

это не аргумент