Никаких :)
Вопрос в выборе библиотеки. Все хвалят MVIcore от badoo, например. Но она на Rx. Я ищу coroutine-based.

Выше хороший совет дали - не использовать библиотек
Они ничего не дают, кроме опининейтед абстракций

Ну и от меня совет - юзать jetpack compose) (ну или inkremental/litho)
По тому что весь MVI(U) упирается в отсутствие в android оптимизаций на ре-рендеринг

А почему не взять и не сделать свой MVI. Всё ядро по сути в отправке и получении стейта и событий. Сделать MviFragment, MviViewModel задача получаса, зачем какие то библиотеки?

А зачем корутины или Rx, если можно писать асинктаски? :))

Не хочется велосипиздить. Если есть готовые решения, которые нормально обрабатывают lifecycle, предоставляют удобный интерфейс, то зачем писать свой велосипед?

К тому же в моём проекте был негативный опыт использования самописного MVP. В итоге получилась хрень. С get'ами в презентерах и вюхах. Использовали бы moxy  и таких косяков бы не могло произойти - библиотека делает не логичным использование get в презентерах и view.
Не хочется чтобы с MVI случилось так же. Если библиотека не даёт косячить с архитектурой - то это было бы здорово.

асинктаски - деприкейтед

😝

форкаем аосп, убираем метку диприкейтед и вставляем форк в проект

Ориджинал метод блин

Мокси сомнительное удовольствие, помню в каком то проекте фрагменты убивались секунд по 10 из за него

Правда это было 2 года назад, может уже стало лучше

Ну я привел пример мокси как библиотеки с хорошим интерфейсом для MVP, которая не даёт косячить с архитектурой

Ты можешь стать первым с хорошей реализацией. Засветиться на гитхабе и ловить ништяки. Ну и плюс своё надёжнее) а самое крутое, что все грабли по ходу собираешь и тебе это даёт бесценный опыт

Я пробовал MVI, писал свою реализацию
Там ничего сложного, но мне не понравилось как это ложится на Android

в том, чтобы положить это на android и сложность основная (имхо)

А зачем это класть на Android?
Все эти проблемы, которые решает MVI надуманы
Это скорее не проблемы, а задачи из разряда «неплохо было бы»
А сам MVI используют только из-за того что он новомодный, а сами потом страдают и задаются вопросом как решить +100500 проблем, которые возникают при наложении MVI на Android

Мне кажется лучше подождать пару лет, дождавшись стабильного Compose и там уже можно попробовать MVI

Или встраивать RecyclerView-based архитектуру, писать ещё миниум 10 000 строк кода для обхода всех косяков MVI и жить спокойно с MVI
С другой стороны: к чему это все?

Именно из-за него? Или всё-таки наделали хуйни + в проекте был мокси?

И если именно из-за него, то в чём конкретно он так всё портил?

здесь не могу не согласиться)