Здравствуйте! Тесты у нас в планах, проект ещё молодой. До релиза обязательно напишем. Пример для большой Java (на Kotlin, разумеется) добавим, спасибо за идею! Пока можно посмотреть пример Android приложения, там тоже JVM.
Здравствуйте! Flows основаны на корутинах, и пока не очень понятно, как это всё можно использовать в проде — реальный опыт мало у кого есть, насколько мне известно. Если кто-то знает успешные примеры — поделитесь, пожалуйста. У нас же давно возникла потребность делать Reaktive, еще до того, как появились какие-то слухи о Flows. Мы не стали менять традиции, в Reaktive есть стандартные наборы источников и планировщиков. Планировщики кстати тоже можно заменять на моки в тестах.
Как разработчик чата в Badoo и первопроходец MVICore могу добавить:
1. Есть возможность сохранять/восстанавливать стейты. Как отметили выше, на данный момент мы используем TimeCapsule и её Андроид реализацию AndroidTimeCapsule. Нужно ей передать в фичу и тогда фича регистрирует себя в капсуле как поставщик стейта, передавая туда Supplier текущего стейта. Далее из onSaveInstanceState надо сказать капсуле сохранить состояние и она опросит все зарегистрированные фичи, соберёт с них состояния и положит в Bundle. А позже фича сможет взять сохранённое состояние из капсулы. При этом перед выдачей стейта на сохранение, его можно изменить (во всё том же Supplier'е), например можно сбросить флаг загрузки, чтобы после пересоздания фича не оказалась в этом состоянии.
2. Списки храняться в тех же стейтах и они иммутабельные (хотя никто не мешает делать мутабельные списки для каких-либо хитрых случаев). Далее при маппинге стейтов во view-модели, можно постараться использовать исходные объекты: например просто перенести List как он есть из стейта во view-модель. Однако это не всегда возможно. В этом случае можно прибегнуть к хитростям. Например можно сделать LruCache из ChatMessage->ViewChatMessage и пробовать брать сначала оттуда, а если там нет, тогда мапить. Это позволит избежать лишних аллокаций.
3. В MVICore ничего особо строго не регламентировано, у разработчика довольно большая свобода. Лично я страюсь всю бизнес-логику складывать в фичи и писать на них хорошие и очень подробные юнит-тесты. А например источники данных (data source) и view делать совершенно без логики (например источники данных — это совершенно пассивные компоненты, выполняющие только дай-положи) и обязательно stateless.
Спасибо, с момента написания статьи библиотека MVIDroid сильно изменились, добавилось много нового! Также обновлены документация и демо проект.
1. Есть возможность сохранять/восстанавливать стейты. Как отметили выше, на данный момент мы используем TimeCapsule и её Андроид реализацию AndroidTimeCapsule. Нужно ей передать в фичу и тогда фича регистрирует себя в капсуле как поставщик стейта, передавая туда Supplier текущего стейта. Далее из onSaveInstanceState надо сказать капсуле сохранить состояние и она опросит все зарегистрированные фичи, соберёт с них состояния и положит в Bundle. А позже фича сможет взять сохранённое состояние из капсулы. При этом перед выдачей стейта на сохранение, его можно изменить (во всё том же Supplier'е), например можно сбросить флаг загрузки, чтобы после пересоздания фича не оказалась в этом состоянии.
2. Списки храняться в тех же стейтах и они иммутабельные (хотя никто не мешает делать мутабельные списки для каких-либо хитрых случаев). Далее при маппинге стейтов во view-модели, можно постараться использовать исходные объекты: например просто перенести List как он есть из стейта во view-модель. Однако это не всегда возможно. В этом случае можно прибегнуть к хитростям. Например можно сделать LruCache из ChatMessage->ViewChatMessage и пробовать брать сначала оттуда, а если там нет, тогда мапить. Это позволит избежать лишних аллокаций.
3. В MVICore ничего особо строго не регламентировано, у разработчика довольно большая свобода. Лично я страюсь всю бизнес-логику складывать в фичи и писать на них хорошие и очень подробные юнит-тесты. А например источники данных (data source) и view делать совершенно без логики (например источники данных — это совершенно пассивные компоненты, выполняющие только дай-положи) и обязательно stateless.