А Вы это делаете не в интеракторах, используя репозитории? В таком случае можно и до домен слоя тянуть (то есть до слоя, где интерактор)

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

Ещё до меня не доходит до конца зона ответственности presenter'а.
Предположим, у меня есть кастомный экран с настройками. В нем есть switch. Я хочу его отображать в том положении, какое у него сохранено.
Если switch == true он отобразит анимацию включения, я его выключаю, поворот - анимации отключения нет (потому что при создании он инфлейтится как false).
А я хочу, чтобы отобразилось последнее действие пользователя.
Вопрос в том, как инициализировать изначальное состояние без анимации? Неужели через отдельные методы view со своими StateStrategy(moxy)?

Вопрос чисто концептуальный

любое состояние вашего ui должна контролироваться презентационным слоем(презентор или вью модель или контроллер или как называете). как вариант, при инициализации презентора можно запостить дефолтное состояние для юай. сам презентейшен слой не хранит никакого состояние конечно же (оно должно прийти из data слоя). если я верно понял вопрос.

хм, а если это true/false для какой-то временной настройки - тоже в data тащить?

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

По сути Вы ответили на основной вопрос про дефолтную инициализацию. Но почему пресентер не хранит состояния? Как же он его восстановит после поворота?

Но более глобальный вопрос это - "за какой стек задач отвечает пресентер?"

презентор - это просто прослойка, для того чтобы сообщать юай, что ему нужно сделать, т.е. установить ui state. он не содержит ни логики, ни понимание откуда приходят данные и т.д. он от слова презентационный слой просто мапит результаты выполнения каких-то бзинес кейсов на ui. т.е. нажали на баттон, надо выоплнить какое-то правило. он вызывает это правило, поулчает ответ и знает как показать этот рузельтат на ui. надеюсь, что смог как-то пояснить

В общих чертах это понятно. У меня получается что это слой взаимодействия пользователя с доменом

Аккуратно надо воспринимать слова "не содержит логики". Логика бывает разная, связанная с работой предметной области, приложения ли UI конкретного экрана. Последняя как раз в презентере и должна быть. Если пошла загрузка данных, показать прогресс - тоже ведь логика.

Но например входит ли всего задача навигации в приложении?
Presenter, как я понял из концепции mvp - платформонезависимый слой (т.е. технически можно его прям в fx перенести без изменений)

Согласен

Обращения к навигатору - да, реализация платформенной навигации - нет

Я знаю человека который сделал мультиплатформенные презентеры, но это по мне несколько перебор) если нет большой необходимости

Имел ввиду не реализацию навигации, а управление ею

Ещё в заблуждение вводят названия. В схеме clean в книге между domain и view лежит 2 слоя (controller и presenter. Controller отвечает за обработку пользовательских действий; Presenter за форматирование и вывод данных пользователю). Получается что в Android+moxy - Activity.fragment = presenter; А Moxy.Presenter = controller.

А view-слой это layout

в рамках одного экрана, которая живет только пока жива вьюха (фильтр списка контактов, например 🤷)