Опыт перехода на MVI в Android на базе собственного решения01.09.2022 16:31

Мы активно применяем MVI для проектирования взаимодействия состояния экрана и бизнес-логики. Сегодня хотим рассказать, почему у нас появилась  собственная MVI-библиотека — Reduktor.

Предисловие

На сегодняшний день архитектурный подход MVI пользуется большой популярностью, его выбирают разработчики приложений по многим причинам. О том, что такое MVI и почему его следует использовать, написано много, например, статьи Ханнеса Дорфмана в восьми частях. Также можно посмотреть доклад Сергея Рябова «Как приготовить хорошо прожаренный MVI под Android«и прочитать о реализации MVI-библиотеки в Badoo.

Что такое MVI

Как это было в Юле

Рассмотрим на примере с кнопкой «Откликнуться на заявку», как это было реализовано у нас до появления Reduktor. Заранее уточню, что мы в проекте используем RxJava.

Определяем интерфейс-маркер UIEvent, который отвечает за какое-либо событие на экране, и описываем классы (объекты) событий, которые наследуются от UIEvent. Слой Model описывается внутри стандартной Android ViewModel, которая может принимать извне события UIEvent. Внутри ViewModel есть viewStates: Flowable — состояние экрана. На изменения состояния подписывается слой View.

Intent

interface UIEvent

object RespondClick : UIEvent()

State

data class ServiceDetailViewState(
   val isLoading: Boolean,
   val isRespondAvailable: Boolean
)

Model

class ServiceDetailViewModel : ViewModel(), Consumer {

   private val viewStateProcessor: BehaviorProcessor = BehaviorProcessor.create()

   // Текущее состояние экрана на момент вызова
   private val currentViewState: ServiceDetailViewState
       get() = viewStateProcessor.value ?: ServiceDetailViewState(false, true)

   private fun postViewState(vs: ServiceDetailViewState): Unit = viewStateProcessor.onNext(vs)

   // Поток состояний экрана
   val viewStates: Flowable = viewStateProcessor.toSerialized()

   // Обработка событий извне
   override fun accept(event: UIEvent) {
       when (event) {
           is RespondClick -> handleRespondClick()
       }
   }

   // Обработка клика и изменение состояние экрана
   private fun handleRespondClick() {
       someNetworkCall()
           .subscribeOn(Schedulers.io())
           .observeOn(AndroidSchedulers.mainThread())
           .doOnSubscribe { postViewState(currentViewState.copy(isLoading = true)) }
           .subscribeBy(
               onSuccess = { postViewState(ServiceDetailViewState(isRespondAvailable = false)) },
               onError = { postViewState(currentViewState.copy(isLoading = false, isRespondAvailable = true)) }
           )
   }
}

View

class ServiceDetailView {

   // ..
   // Подписка на изменения состояния
   viewModel.viewStates.subscribe { state ->
       showLoading(state.isLoading)
       showRespondButton(state.isRespondAvailable)
   }

   // Отправка события RespondClick по клику на кнопку
   respondButton.setOnClickListener { viewModel.accept(RespondClick) }
}

Выше описана упрощённая структура, на основе которой было реализовано множество экранов Юлы.

Подробнее о том, как появился MVI в Юле

Время шло, фичи усложнялись, и мы обратили внимание на чистую архитектуру. Стало понятно, что ViewModel более не может сочетать столько ответственности, и переместили бизнес-логику в интеракторы. При этом, некоторые интеракторы были довольно сложными — см. доклад А. Червякова о state-машинах на слое domain. Кроме того, следует понять, что появилось 2 состояния: доменное состояние фичи и ViewState для отображения, который получается в результате маппинга доменного состояния. При этом, у разработчика сохраняется свобода в организации связей интеракторов внутри ViewModel.

Фредерик Брукс считал, что:»…получение архитектуры извне усиливает, а не подавляет творческую активность группы исполнителей». Давайте добавим в нашу схему недостающий кусочек:, а именно, сделаем общий шаблон организации любого количества (use-case«ов / interactor«ов), ViewModel с ViewState, и наших подписок с RouteEvent/ServiceEvent. Этот общий кусочек мы хотели получить в виде фреймворка/библиотеки.

Поиск готового MVI-решения

Конец 2020 / начало 2021-го года. Команда Android-разработки выросла по количеству. Появился запрос на гибкий, простой, небольшой по коду MVI-фреймворк для команды, в котором можно было бы поддержать нужные нам кейсы, внедрить в краткие сроки; который бы не имел ощутимый порог входа.

Мы начали искать готовые open source решения, чтобы встроить их в наш проект. Руководствовались следующими требованиями к коду, написанному на основе готового MVI-решения:

1. Масштабируемость и независимость от платформы и внешних библиотек. Архитектура должна быть крайне гибкой и расширяемой. Как сказано выше, сейчас у нас в проекте используется RxJava, при этом мы планируем перейти на compose и использовать coroutines в недалеком будущем. Отсюда требование: решение не должно зависеть от сторонних библиотек;

2. Сопровождаемость. Чем проще исправлять ошибки и управлять проектом после передачи в эксплуатацию, тем легче новым разработчикам поддерживать проект;

3. Надежность. Внутри реализации системы исключены проблемы многопоточной среды. Единый контракт должен обеспечивать безопасность интерфейсов;

4. Тестируемость;

5. Возможность переиспользования;

6. Легкая встраиваемость в проект;

7. Детальные и хорошо читаемые логи.

Дополнительные критерий — активное сообщество, поскольку библиотека должна сохранять актуальность, её должны обновлять, проверять и поддерживать в порядке.

Если вы ищете такое решение, то посмотрите статью «Сравниваем готовые решения для реализации MVI-архитектуры на Android», актуальную на 2022 год. В начале 2021 года, мы отмели MVICore от Badoo, как слишком сложный. MVIKotlin не имел такой популярности, как сейчас. Итого, мы завели демо-проект на github, в котором сравнивали RxRedux и первую версию Reduktor, которую нам принёс на рассмотрение наш коллега. Поскольку Reduktor покрывал все наши нужды, в отличие от RxRedux, фреймворк был значительно доработан и состоялось внедрение в проект. В продакшн версия на RxJava существует более года, полёт нормальный.

Про Reduktor

В Reduktor всё взаимодействие происходит через объект Store. Класс Store параметризован двумя типами: ACTION — базовым классом событий, и STATE — состоянием системы.

Какие параметры есть у Store:

class Store(
   initialState: STATE,
   private val reducer: Reducer,
   initializers: Iterable> = emptyList(),
   sideEffects: Iterable> = emptyList(),
   private val logger: Logger = Logger {},
   private val newStatesCallback: (state: STATE) -> Unit
)

• initialState — начальное состояние экрана;

• reducer — сущность, которая в зависимости от нового действия преобразовывает текущее состояние в новое;

• initializers — сущности, которые могут передавать действия из внешних источников. Их может быть любое количество (в том числе 0). У класса Initializer есть стандартная реализация ActionsInitializer с публичным полем actions, через которое необходимо отправлять события методом post;

• sideEffects — сущности, которые преобразовывают новое действие и текущее состояние в поток новых действий. Их может быть любое количество (в том числе 0). Могут не возвращать новое действие, если оно не требуется. Именно в них необходимо описывать бизнес-логику, например, отправлять запросы в сеть;

• logger — сущность для логирования всего, что происходит в системе: какое действие пришло, какое сейчас состояние и какое получилось новое состояние (или что не изменилось). По умолчанию null;

• newStatesCallback — коллбэк, в который приходит новое состояние. Внутри системы есть проверка состояний на эквивалентность. Когда создан объект Store, в newStatesCallback сразу придёт актуальное состояние в текущем потоке. Однако дальнейшие обновления могут приходить в других потоках.

Для удобства, у класса Store есть несколько базовых реализаций для поддержки потока состояний через сущности StateFlow (Coroutines) и Flowable (RxJava2, RxJava3).

Принцип работы:

• Действие может попасть в систему через Initializer. Это может быть событие от взаимодействия с пользователем или любое другое внешнее событие (например, новое сообщение из сокета).

• Далее действие проходит через Reducer. Тут оно может повлиять на изменение состояния. Если состояние изменилось, то информация об этом будет отправлена тем, кто на него подписался.

• После этого действие и новое (либо не изменившееся) состояние попадают в SideEffect. Оттуда могут возвращаться новые цепочки с действиями. Подписываемся на них и ожидаем новые действия, которые будут снова отправлены в Reducer. В SideEffect можно создавать и выполнять фоновые задачи, результатом работы которых становится новое действие.

Reduktor на примере

В этом разделе разберем принцип работы Reduktor на примере экрана со списком пользователей. Он может иметь три состояния: загрузка, ошибка загрузки и успешно полученный из сети список пользователей. По клику на элемент в списке будет открываться webview. Для распараллеливания будем использовать RxJava. Состояние такого экрана:

data class FeatureViewState(
   val isLoading: Boolean = false,
   val error: Throwable? = null,
   val data: List = listOf()
)

Теперь определим действия, в нашей системе они могут быть двух типов:

• внешние, исходящие от пользователя — FeatureViewAction;

• внутренние, исходящие внутри системы, например, результат загрузки данных — FeatureSideAction.

Все действия наследуем от интерфейса FeatureAction, чтобы потом им параметризовать другие сущности Reduktor:

interface FeatureAction

sealed class FeatureViewAction : FeatureAction {
   object Init : FeatureViewAction()
   object Retry : FeatureViewAction()
   class Click(val user: User) : FeatureViewAction()
}

sealed class FeatureSideAction : FeatureAction {
   class Data(val data: List) : FeatureSideAction()
   class Error(val error: Throwable) : FeatureSideAction()
}

В ответ на действия FeatureViewAction.Init и FeatureViewAction.Retry должна начаться загрузка пользователей, в ответ на FeatureViewAction.Click должна открываться webview. Всё это будет происходить в одном side-эффекте. Для этого необходимо наследоваться от функционального интерфейса SideEffect и переопределить метод invoke:

class FeatureLogicSideEffect : SideEffect {

   override fun Environment.invoke(action: FeatureAction, state: FeatureViewState) {
       // ..
   }
}

Метод invoke принимает текущее действие (action) и актуальное состояние (state).

Сущность Environment предоставляет доступ к задачам (tasks) и действиям (actions). Чтобы в Reduktor создать фоновую задачу, необходимо наследоваться от класса Task и поместить в массив tasks. Завершить выполнение работы и отменить все задачи можно через метод release().

Для того, чтобы начать загрузку экрана, определим задачу tasks[”load_data”]:

private fun Environment.loadData() {
   tasks["load_data"] = repository.loadData()
       .subscribeOn(Schedulers.io())
       .toTask(
           onSuccess = { actions.post(FeatureSideAction.Data(it)) },
           onError = { actions.post(FeatureSideAction.Error(it)) }
       )
}

Ключ задачи задаётся для её отмены с таким же ключом. Метод toTask преобразует тип Single (RxJava) в тип Task (сущность задачи в Reduktor). В обратных вызовах onSuccess и onError отправляем действия результатов загрузки в систему с помощью actions.post.

Финальный FeatureLogicSideEffect будет выглядеть так:

class FeatureLogicSideEffect(
   private val repository: FeatureRepository,
   private val router: FeatureRouter
) : SideEffect {

   override fun Environment.invoke(action: FeatureAction, state: FeatureViewState) {
       when (action) {
           is FeatureViewAction.Init,
           is FeatureViewAction.Retry -> loadData()
           is FeatureViewAction.Click -> router.openBrowser(action.user.url)
       }
   }

   private fun Environment.loadData() {
       tasks["load_data"] = repository.loadData()
           .subscribeOn(Schedulers.io())
           .toTask(
               onSuccess = { actions.post(FeatureSideAction.Data(it)) },
               onError = { actions.post(FeatureSideAction.Error(it)) }
           )
   }
}

В этом side-эффекте мы также определили, что будет происходить с системой по клику на элемент в списке (см. FeatureViewAction.Click).

Нюансики

Ранее мы описали состояние экрана, действия и их обработку в SideEffect. В side-эффекте в свою очередь тоже отправляются новые события.

Для изменения состояния в зависимости от действий в Reduktor есть сущность Reducer. Реализуем Reducer для нашего экрана. В зависимости от действия создаём новый  state на основе предыдущего:

class FeatureReducer : Reducer {

   override fun FeatureViewState.invoke(action: FeatureAction): FeatureViewState {
       val state = this
       return when (action) {
           is FeatureViewAction.Init,
           is FeatureViewAction.Retry -> state.copy(isLoading = true, error = null)
           is FeatureSideAction.Data -> state.copy(isLoading = false, error = null, data = action.data)
           is FeatureSideAction.Error -> state.copy(isLoading = false, error = action.error)
           else -> state
       }
   }
}

Все необходимые составляющие мы описали, теперь свяжем их в объекте Store:

private val logicSideEffects = FeatureLogicSideEffect(repository, router)
private val featureReducer = FeatureReducer()
private val actionsInitializer = ActionsInitializer()

val store: Store = Store(
   initialState = FeatureViewState(),
   reducer = featureReducer,
   initializers = listOf(actionsInitializer),
   sideEffects = listOf(logicSideEffects),
   logger = { Timber.d("FEATURE_TAG | $it") }
)

fun accept(action: FeatureViewAction) {
   actionsInitializer.actions.post(action)
}

Чтобы состояние экрана сохранялось при смене конфигурации, положим объект Store в Android ViewModel. И, наконец, подпишемся и обработаем изменения состояния экрана и опишем отправку действий в необходимые моменты:

disposable = viewModel.store.states
   .observeOn(AndroidSchedulers.mainThread())
   .subscribe { state ->
   // обновляем UI
}
....
// инициализация
viewModel.accept(FeatureViewAction.Init)
....
// клик по элементу списка
val action = FeatureViewAction.Click(user)
viewModel.accept(action)
....
// клик по кнопке повтора загрузки
viewModel.accept(FeatureViewAction.Retry)
....

Запускаем экран и изучаем лог

В независимости от сложности задачи можно проявить фантазию и встроить Reduktor в любое место приложения. Это может быть состояние экрана, состояние загрузки медиафайлов, состояние фичи, состоящей из нескольких экранов, и т.д. Одновременно можно подключать к системе side-эффекты, задачи которых запускаются с помощью coroutines и RxJava, что особенно полезно для плавного перехода одного к другому.

Наш опыт

Нашей команде было несложно разобраться в принципах работы библиотеки. Мы не стали ставить жёсткое условие писать все экраны на Reduktor, поскольку в совсем простых случаях код, скорее всего, будет излишне нагружен сущностями. Как правило, мы используем Reduktor, если необходимо отделить состояние фичи от состояния экрана.

Возьмём для примера экран карточки продукта: он состоит из одного RecyclerView и ViewPager для фотографии товара в шапке. Каждый блок в списке экрана описывается отдельной доменной сущностью. Все сущности необходимо хранить в течение всего жизненного цикла фичи и использовать их в зависимости от действий пользователя. Поэтому получаем два состояния: одно для экрана со списком элементов, подготовленных для отрисовки, другое — доменное с дополнительными параметрами экрана, ненужными для отрисовки. Каждый раз, когда меняется доменное состояние, модель преобразуется в состояние экрана, а оно, в свою очередь, отправляется на отрисовку. С переходом на Reduktor бизнес-логика этого экрана была декомпозирована на множество side-эффектов, отчего код стал гораздо чище и проще в поддержке и расширении. Есть отдельные side-эффекты, которые используются и в других экранах.

Отладка подобных экранов стала занимать гораздо меньше времени, так как любое происходящее изменение внутри Reduktor логируется в удобочитаемом виде (см. пример выше).

В недалеком будущем плавный переход на compose и coroutines не должен быть проблематичным с MVI-структурой, которую мы получили в результате. Чтобы поменять поток состояний типа Flowable (RxJava) на StateFlow (coroutines), необходимо будет поменять импорт класса Store на тот, что находится в пакете reduktor.coroutines. На поток состояний StateFlow будет подписка в composable view. В SideEffect необходимо будет переписать асинхронные задачи c RxJava на coroutines. Чтобы поддержать тип Reduktor Task можно будет воспользоваться extention-методом к CoroutineScope: CoroutineScope.newTask.

* * *

Исходный код библиотеки Reduktor, а также подробную инструкцию по подключению и примеры использования можно найти на GitHub.

© Habrahabr.ru