Но запрос приняли)

У нас была одна оххенная история на эту тему)

Будет супер , если будет отрисовка каких то изменяющихся списков.

Самый частый кейс.

Еще бы я на ваш байндер посмотрел с удовольствием .) вы же вроде свой используете, а не бадушный.

ну это так , любопытство.

Кстати, на хабре статью писали про то, как пилили сложную фичу на части — там больше подробностей про доменный и presentation слои https://habr.com/ru/company/hh/blog/534692/

👍

Привет! Кто сталкивался, миграция на androidx обязательное условие выката обновлений в стор? Не могу найти в официальных источниках, только косвенные

не слышал раньше о таком требовании и думаю что его нет, но вам сюда @android_ru

Там никогда не отвечают.

а тут оффтоп)

А по мне так вполне к архитектуре относится.

никоим образом)

Вопрос наверное будет не совсем по теме многомодульности, а скорее по интеграции MVI-Core
Насколько я понимаю у вас в проекте используется традиционная xml верстка, не декларативный UI, и интересно как обрабатывается подобный кейс
Допустим форма логина по номеру телефона, есть editText с маской и кнопка получить смс, которая disabled пока номер не будет введен до конца.
Собственно вопрос, в таком кейсе номер телефона является частью MVI стейта и соответственно состояние enable кнопки тоже или же это разруливается на UI(во фрагменте)

С одной стороны мне кажется, что это все таки часть стейта, поэтому разумно хранить это в нем, с другой стороны, изменение текста отправляется Wish'ами из TextWatcher, и нужно либо убирать вотчер и добавлять его при перерисовке стейта, либо перед перерисовкой проверять а не равен ли текст в editText тому что уже был введен, иначе при setText из вотчера снова будет улетать Wish в Feature

Если у фичи есть логика, которая завязана на состояние вводимого текста или же от логики фичи зависит то, какой текст должен видеть пользователь в поле ввода, то да, держим как состояние внутри фичи. Кидаем Wish на вводе и сетим актуальный текст из стейта фичи в EditText. Блокировка действий на форме, пока пользователь не введет валидный текст, как раз один из таких примеров. Другой пример: сохранение черновика вводимого текста. В таком случае не только UI обновляет стейт фичи, а сама фича может обновить текст на UI (загрузив предыдущий черновик).

По поводу не очень приятных деталей реализации в контексте стандартных андроидовских EditText-ов, у нас для двустороннего байндинга текста такой экстеншен есть: https://pastebin.com/sAhCmnEQ
Идея была взята из RxPM: https://github.com/dmdevgo/RxPM/blob/9a79e0a4adf1ec682f36bf5e2313a10937385c4c/rxpm/src/main/kotlin/me/dmdev/rxpm/widget/InputControl.kt#L131

Спасибо за ответ, идея с экстеншном кстати классная, возьму на вооружение

есть какая-то дефолтная реализация CommandBuffer'а?

очередь чтоли?

там не совсем очередь. Это очередь, которая ждет события для выполнения этой очереди

что-то вроде этого, но только с очередью