Мой рецепт MVI в Android

Как известно, MVI строится на основе трех компонентов — модели, намерения (действия) и состояния экрана. Логика приложения диктуется пользователем, например, он хочет загрузить картинку в высоком разрешении, и различными внешними эффектами (далее — side-effects), например, внезапной потерей соединения.

Мне хотелось создать механизм, который будет способен обрабатывать намерения пользователя и их следствия (что-то внешнее, например ответ от api). Для этого я решил создать три интерфейса-маркера, которые будут отвечать за какое-либо событие, состояние экрана и не влияющие на состояние экрана уведомления.

interface Action interface State interface News

Подготовка

Как я уже сказал, у экрана приложения имеется свой State, способный меняться из-за действий пользователя и внешних воздействий. Было решено создать некую сущность, способную содержать пути наружу (в DI модуле конфигурируем как хотим) и обработчик side-effects, чтобы иметь инструмент для обработки нашей бизнес логики в ViewModel.

open class Store<S: State, A: Action, N: News> @Inject constructor(     val apiRepository: ApiRepository,     val preferencesRepository: PreferencesRepository,     val logger: JuleLogger,     val resources: Resources ) {     var middlewares: List<Middleware<A>> by notNull()     var reducer: Reducer<S, A, N> by notNull() }

Тут нужно остановиться — я упоминал обработчик внешних эффектов. Где он тут находится?

Обработка событий

Как мы видим, в Store находится какое-то количество Middleware и Reducer. Мы уже знаем, что side-effects должны нести в себе какие-то данные, чтобы изменить UI, почему бы тогда каждую бизнес задачу не вынести в отдельный Middleware и держать в Store их коллекцию и обрабатывать каждый из них, принимая результат и возвращая State нашего экрана? Этим и будет заниматься Reducer.

abstract class Middleware<A: Action>(store: Store<*, *, *>) {     protected val apiRepository: ApiRepository = store.apiRepository     protected val preferencesRepository: PreferencesRepository = store.preferencesRepository     protected val logger: JuleLogger = store.logger.apply { connect(javaClass) }     protected val resources: Resources = store.resources      abstract suspend fun effect(action: A): A?     suspend operator fun invoke(action: A) = effect(action) }  interface Reducer<S: State, A: Action, N: News> {     fun reduce(state: S, action: A): Pair<S?, N?>     operator fun invoke(state: S, action: A) = reduce(state, action) }

Middleware содержит доступ к «ручкам», чтобы иметь возможность порождать новые Action и абстрактный метод effect(), чтобы выполнить его там.

Внимательный читатель заметил, что Middleware не просто порождает какой-то Action, но и принимает его в качестве параметра. Как я уже говорил, внешние эффекты могут быть вызваны пользователем напрямую, например явным запросом в сеть. Но ведь одни side-effects способны вызывать другие и наоборот. Мы хотим, чтобы каждый результат бизнес-задачи был «услышан» всеми остальными и, если необходимо, последовал новый side-effect. (Это вовсе не обязательно, для этого возвращаемый тип nullable)

C доменным слоем нашего приложения разобрались, теперь нужно обеспечить преобразование пришедшей извне информации на UI. Как я уже упоминал, этим будет заниматься Reducer. Что для этого нужно, помимо текущего State экрана? Очевидно, виновник торжества — Action, именно то, что будут возвращать нам Middleware’ы. Таким образом, Reducer принимает side-effect и исходя от него, меняет текущий State и вдобавок может выкинуть какое-то уведомление — News.

А что в ViewModel?

Давайте взглянем на базовую ViewModel, из важного тут — метод bind() — он будет отвечать за обработку нашего UI. В параметре приходит интерфейс MviView, на который подписан холдер данной ViewModel, в котором просто реализована отрисовка приходящих State и News.

abstract class BaseViewModel<S: State, A: Action, N: News>: ViewModel() {      private val backgroundScope = CoroutineScope(IO + SupervisorJob())      @Inject     lateinit var logger: JuleLogger      abstract val stateFlow: MutableStateFlow<S>     abstract val newsFlow: MutableSharedFlow<N>     abstract val actionFlow: MutableSharedFlow<A?>     abstract val store: Store<S, A, N>      override fun onCleared() {         super.onCleared()         backgroundScope.coroutineContext.cancelChildren()     }      fun obtainAction(action: A) {         backgroundScope.launch {             actionFlow.emit(action)         }     }      fun obtainState(state: S) {         stateFlow.value = state     }      fun bind(foregroundScope: LifecycleCoroutineScope, mviView: MviView<S, N>) {         logger.connect(javaClass)          with(foregroundScope) {             launch {                 stateFlow                     .onEach(mviView::renderState)                     .catch { logger.logException(it) }                     .collect()             }             launch {                 newsFlow                     .onEach(mviView::renderNews)                     .catch { logger.logException(it) }                     .collect()             }         }     } }

У читателя возникает логичный вопрос — раз у нас есть механизм, который все обрабатывает, и ViewModel, посылающая эти обработанные данные на UI, то как нам обеспечить, чтобы эти данные таки доходили наших state и news flow? Все это происходит в конструкторе.

init {         backgroundScope.launch {             actionFlow                 .filterNotNull()                 .transform {                     store.middlewares.forEach { middleware ->                         val effect = middleware.effect(it)                         effect?.let {                             logger.log("${middleware.javaClass.simpleName} effects $it")                             emit(it)                         }                     }                 }.flowOn(Default).combine(stateFlow) { a, s ->                     val (reducedState, reducedNews) = store.reducer.reduce(s, a)                     // Пришедший State                     reducedState?.let {                         stateFlow.value = it                     }                     // Пришедший News                     reducedNews?.let {                         newsFlow.emit(it)                     }                 }.catch {                     logger.logException(it)                 }.collect()         }     }

В этом фрагменте, пожалуй, находится ядро нашего «механизма». Каждый Action в блоке transform() уведомляет все Middleware о себе, а затем, комбинируясь с нашим state flow, проходит Reducer’а и как результат stateFlow и newsFlow потенциально получают какое-то значение и отправляются на отрисовку в UI. А что самое важное, другие Middleware обрабатывают этот Action и потенциально порождают новые изменения в UI в дальнейшем.

Каково это на практике?

Для примера возьмем типичный экран «Профиль». Для простоты позволим пользователю совершать logout и загрузку содержимого профиля. Так будут выглядеть State, Action и News:

sealed class ProfileState: State {   // Состояние экрана декларируется через ProfileModel,   // по сути отражающую наличие контента и navDirections,    // если мы хотим куда-то двигаться по приложению     data class Default(         val profile: ProfileModel? = null,         val navDirections: NavDirections? = null,     ): ProfileState() }  sealed class ProfileNews: News {   // Простое уведомление     data class Message(val duration: Int, val content: String): ProfileNews() }  sealed class ProfileAction: Action {   // Намерения пользователя     object FetchProfile: ProfileAction()     object Logout: ProfileAction()      // То, что приходит как результат работы middleware     data class FetchProfileDone(         val profile: ProfileResponse? = null,         val interpretedError: InterpretedError? = null     ): ProfileAction()          object LogoutDone: ProfileAction() }

Теперь взглянем на то, как будут «общаться» Reducer и Middleware

// Logout class LogoutMiddleware(store: Store<*, *, *>): Middleware<ProfileAction>(store) {     override suspend fun effect(action: ProfileAction): ProfileAction? {         var effect: ProfileAction? = null         with(action) {             // Реагируем только на этот Action             if (this is ProfileAction.Logout) {                 CoroutineScope(Dispatchers.IO).launch {                     preferencesRepository.clearAccessToken()                     preferencesRepository.clearRefreshToken()                 }                 effect = ProfileAction.LogoutDone             }         }         // Возвращаем side-effect         return effect     } }  // Загрузка профиля  class GetProfileMiddleware(store: Store<*, *, *>): Middleware<ProfileAction>(store) {     override suspend fun effect(action: ProfileAction): ProfileAction? {         var effect: ProfileAction? = null         with(action) {             // Реагируем только на этот Action             if (this is ProfileAction.FetchProfile) {                 // Выполняем какой-то запрос в сеть                 doRequest(                     responseAsync = {                         apiRepository.getProfile()                     },                     onOk = {                         effect = ProfileAction.FetchProfileDone(profile = this)                     },                     onApiErrorStatus = {                         effect = ProfileAction.FetchProfileDone(interpretedError = this)                     },                     onException = {                         effect = ProfileAction.FetchProfileDone(interpretedError = this)                     },                 )             }         }         // Возвращаем side-effect         return effect     } }  // Обработка приходящих Action'ов class ProfileReducer: Reducer<ProfileState, ProfileAction, ProfileNews> {     override fun reduce(state: ProfileState, action: ProfileAction): Pair<ProfileState?, ProfileNews?> {         var reducedState: ProfileState? = null         var reducedNews: ProfileNews? = null        // Меняем State в зависимости от Action         when (action) {             is ProfileAction.LogoutDone -> {               // Перемещаемся в фрагмент авторизации                 reducedState = ProfileState.Default(                     navDirections = ContainerFragmentDirections.containerAuth()                 )             }             is ProfileAction.FetchProfileDone -> {               // Вставляем модель в State и никуда не перемещаемся                 reducedState = ProfileState.Default(                     profile = action.profile?.profile?.let { ProfileModel(it) },                     navDirections = null                 )             }         }         // Возвращаем потенциальные State и News         return reducedState to reducedNews     } }  

И для полноты картины взглянем на части кода фрагмента

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {     super.onViewCreated(view, savedInstanceState)          logger.connect(javaClass)          with(profileViewModel) {         bind(viewLifecycleOwner.lifecycleScope, this@ProfileFragment)         // Сразу выполняем загрузку профиля         lifecycleScope.launch {             obtainAction(ProfileAction.FetchProfile)         }     }          // По клику на кнопку выхода осуществляем выход     btnLogout.click {         viewLifecycleOwner.lifecycleScope.launch {             profileViewModel.obtainAction(ProfileAction.Logout)         }     } }  override fun renderState(state: ProfileState) {     when (state) {         is ProfileState.Default -> {             state.navDirections?.let {                 navigate(it)                 profileViewModel.obtainState(state.copy(null))             }             state.profile?.let {                 tvFriendsCount.text = it.friends.size.toString()                 tvLogin.text = it.login                 tvName.text = it.name                }     }     } }