@ikakus screenModel сама по себе и есть состояние view. У screenmodel есть наследник, который еше использует LoadState для управления состояниями загрузки/пустой экран/ошибка.

@egoriku синхронизация состояний у виджетов вещь скорее опциональная, зависит от кейсов экрана.

@O_Z_H А как у вас решаются моменты отображения снеков, тостов?

через messageController

Можно линк сразу)

@amihusb в шапке ссылка в репозиторий, а в репозитории есть поиск по репозиторию ;)

А что, если это не сообщение? А просто похожая механика?

Дайте конкретный кейс

Например, механизм отображения ошибок через messageController доступен у StandartErrorHandler. К примеру, выполняя запрос, можно осуществить подписку через метод subscribeIoHandleError, который по умолчанию  обработает ваш throwable и в зависимости от кода покажет стандартый мессадж, либо в тосте ,либо в снеке в зависимсотси от версии - и это очень удобно
Это поведение в любом презентере или вью можно переопределить

Допустим у меня есть точно такой же кастомный снекбар(просто view), который показывается и исчезает через некоторое время.
У меня такой вопрос, вы пробовали как нибудь решить отображение снеков через ScreenModel?

@amihusb для касторной вью с ошибкой можно свой errorHandler написать.

Screenmodel не связана с показами снеков.

Почему вы так решили, что отображение снеков это не про состояние экрана?

Снек/тост это для показа сообщения, что произошло. ScreenModel не хранит исключения. Состояние экрана хранит screenmodel + loadState

Я понимаю, но почему вы так решили сделать? Ведь если бы не было снекбаров/тостов в андроид фремворке, скорее всего был бы что то вроде такого:

sealed class Message
data class Visible(val title: String) : Message()
object Invisible: Message()

somewhere in presenter/viewmodel/etc
fun showMessage() {
    render(state.copy(message = Message.Visible("Message"))
    handler.postDelayed(1000) {
        render(state.copy(message = Message.Invisible))
    }
}

in fragment/activity/etc
fun render(state: ScreenModel) {
    when(state.message) {
        is Visible -> messageView.show(state.message.title)
        is Invisible -> messageView.hide()
    }
}

Это же тоже состояние экрана

Мне просто интересно, есть ли весомый аргумент почему это так, а не иначе? Имхо это тоже состояние экрана в определенный момент времени. Это было сделано потому что так проще, раз фреймворк позвляет? Или есть какие-то аргументы против?

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

Если в кратце: презентер грузит данные. Если произошла ошибка то errorHandler обработает ее и покажет, если надо, ошибку. ScreenModel получит соответствующий loadState
View отрендерит  ScreenModel относительно тех данных что пришли/ не пришли во время загрузки.
Нужна кастомная обработка/отображение ошибки - пишется кастомный ErrorHandler или переопределяется метод handleError в презентере или на худой конец из onError в методе загрузки вызываем нужный метод из View.
Последнее не рекомендуется делать, т.к сложно потом ловить где все ошибки обрабатываются.
Состояние экрана - это то, что будет и после поворота экрана. А снек показался и ушёл. Какие-то узкие кейсы я не рассматриваю со снеком

Мы разделяем 2 способа взаимодействия презентера с вью: передача состояния и передача разовых команд. Первое осуществляется с посмощью  screenModel. Примеры второго типа взаимодействий: тосты, скрол до нужной позиции, скрытие клавиатуры. Это такие действия, которые однажды кидаются на вью. Часть этих команд может быть представлена и через screenModel, например позиция скрола, но согласитесь что для обычного списка это не очень естественно делать. То же и для разовых сообщений.

Добрый день. Читаю ваши стандарты разработки. В обших требованиях к коду. Есть такое предложение " В таком случае стоит их выделить более высокий уровень абстракции, который выполняет вполне определенную задачу с объектом". Тут наверное "... выделить в более высокий уровень ..". И что должен в таком примере представлять из себя более высокий уровень абстракции ? Отдельный класс ? Дополнительный интерфейс ? Мне кажется было бы здорово тут дополнить пример, написав пример этого более высокого уровня абстракции.