​​MVI — архитектура за 100 слов

Этот подход набирает все большую популярность, вытесняя MVVM

Яркий признак MVI — наличие State
State — неизменяемое состояние (объект, который называет состояние и передает все связанные с ним данные)

Например, ErrorState(val errorMessage: String)

Слои:

• Model — источник State для View
• View — принимает State и отображает
• Intent — события

Не буду вдаваться в философию, приведу пример:

когда пользователь открывает экран, Model создает State.Defult
загружает в этот State всю информацию, которую нужно отобразить, и отдает View

через некоторые время пользователь нажимает кнопку
View сообщает об новом Intent в Model
Model формирует новый State и отдает View

В целом — это все. Но мир не идеален, поэтому:

Intent можно разделить на 2 группы:

• Действия юзера
• События от бекенда (например, пришло новое сообщение)

State можно поделить на 2 группы:

• Стабильные — должны отображаться даже после переворота экрана
• Эффекты — должны отобразиться один раз (например, Toast\Snackbar)

Плюсы MVI:
• наглядность — прямой "поток" данных и событий, без макарон
• модульность — тестируемость
• заранее прописываешь стейты, так что не забываешь учесть разные состояния (обычно State.Default, State.Failed, State.Loading, State.Success)

Минусы MVI:
• часто приходится делать тяжелый моральный выбор - если на экране появляются новые вьюшка, то нужно создавать новый State или модифицировать старый?