Много уже сказано про MVI, о том как его правильно прожарить и настроить. Однако не так много времени уделяется тому, насколько этот метод упрощает жизнь в определенных ситуациях, в сравнении с остальными подходами.
Цель этой статьи
Я не буду углубляться в то как технически реализуется MVI (способов больше одного и у каждого есть свои плюсы и минусы). Моя главная цель в короткой статье заинтересовать тебя изучать эту тему в дальнейшем и возможно побудить внедрить данный паттерн на своих боевых проектах или хотя бы проверить на домашних заготовках.
С какой проблемой можно столкнуться
Мой дорогой друг, давай представим такую ситуацию, у нас имеется интерфейс вью, с которым
предстоит работать:
interface ComplexView
На первый взгляд кажется, что ничего сложного. Ты просто выделяешь для работы с этой вьюшкой отдельную сущность, называешь ее презентером (вуаля вот и MVP готов), а это большие проблемы небольшие сложности и сейчас я постараюсь объяснить почему.
А вот и сам презентер:
interface Presenter { fun onLoadData(dataKey: String) fun onLoadCredit()}
Все просто, вьюшка дергает методы презентера, когда надо загрузить данные, презентер в свою очередь имеет право дергать вьюшку, для того, чтобы отобразить загруженную информацию, а также отобразить прогресс. Но тут и появляется проблема сложность — это абсолютное отсутствие контроля консистентности твоего UI мой товарищ.
К примеру мы хотим вывести диалог предлагающий кредит выгодное предложение пользователю и делаем этот вызов из презентера, имея на руках ссылку на интерфейс вью:
view.hideTakeCreditDialog()
Но при этом тебе не следует забывать, что при отображении диалога, нужно скрывать лоадинг и не показывать его пока у тебя имеется диалог на экране. Плюс к этому есть метод, показывающий баннер, который мы не должны вызывать пока у нас отображается диалог (либо закрывать диалог и уже после этого отображать баннер, все зависит от требований). Картина у тебя складывается такая.
Тебе ни в коем случае нельзя вызывать:
view.showBanner()
view.showLoading()
Пока идет показ диалога. Иначе будут плакать котики тестировщики и пользователи, от боли в глазах от одного взгляда на баннер поверх важного диалога c кредитом выгодным предложением.
А сейчас давай еще подумаем с тобой и предположим, что все таки захотелось показать баннер (такое уж требование от бизнеса). О чем же надо помнить?
Дело в том, что при вызове сего метода:
view.showBanner()
Обязательно надо вызывать:
view.hideLoading()
view.hideTakeCreditDialog()
Опять же для того, чтобы у нас на экране ничего не скакало поверх остальных юайных элементов, пресловутая консистентность.
Вот и всплывает вопрос, кто ударит тебя по рукам, если сделаешь что-то не так? Ответ прост — НИКТО. В такой реализации у тебя нет абсолютно никакого контроля.
Возможно в будущем понадобится добавить еще какую-либо функциональность во вью, которая также будет связано с тем, что уже есть. Какие минусы мы из этого получаем?
- Лапша из зависимостей состояний юайных элементов
- Логика переходов из одного состояния отображения в другое будет размазана по
презентеру - Довольно тяжело добавлять новое состояние экрана, так как велик риск того, что
забудешь что-то скрыть перед тем как отобразить новый баннер или диалог
И это мы с тобой разбирали кейс когда во вью всего 7 методов. И даже тут получилось встрять на проблемы.
А ведь бывают вот такие вью:
interface ChatView : IView<ChatPresenter> { fun setMessage(message: String) fun showFullScreenProgressBar() fun updateExistingMessage(model: ChatMessageModel) fun hideFullScreenProgressBar() fun addNewMessage(localMessage: ChatMessageModel) fun showErrorFromLoading(message: String) fun moveChatToStart() fun containsMessage(message: ChatMessageModel): Boolean fun getChatMessagesSize(): Int fun getLastMessage(): ChatMessageModel? fun updateMessageStatus(messageId: String, status: ChatMessageStatus) fun setAutoLoading(autoLoadingEnabled: Boolean) fun initImageInChat(needImageInChat: Boolean) fun enableNavigationButton() fun hideKeyboard() fun scrollToFirstMessage() fun setTitle(@StringRes titleRes: Int) fun setVisibleSendingError(isVisible: Boolean) fun removeMessage(localId: String) fun setBottomPadding(hasPadding: Boolean) fun initMessagesList(pageSize: Int) fun showToast(@StringRes textRes: Int) fun openMessageDialog(message: String) fun showSuccessRating() fun setRatingAvailability(isEnabled: Boolean) fun showSuccessRatingWithResult(ratingValue: String)}
Добавлять сюда что-либо новое или править старое будет довольно тяжело, придется посмотреть, что и как связано между собой, а потом начать плакать работать и молиться, чтобы тестировщик ничего не пропустил. И в момент твоего отчаяния появляется он.
MVI
Вся суть
Суть в том, что мы имеем сущность, которая называется стейт. На основе этого стейта вьюшка будет рендерить свое отображение. Не буду углубляться, так моя задача пробудить в тебе интерес, так что сразу перейду к примерам. А в конце статьи будет список очень полезных источников, если тебя все же появится интерес.
Давай вспомним наше положение в начале статьи, у нас есть вью, на которой мы показываем диалоги, баннеры и волшебство. Опишем ка мы с тобой стейт вьюшки
data class UIState( val loading: Boolean = false, val names: List<String>? = null, val isBannerShowing: Boolean = false, val isCreditDialogShowing: Boolean = false)
Установим правило, мы с тобой можем менять вью только с помощью этого стейта, будет такой интерфейс:
interface ComplexView { fun renderState(state: UIState)}
А сейчас установим еще одно правило. Мы можем обращаться к владельцу стейта (в нашем случае это будет презентер) только через одну точку входа. Путем отправления ему событий. Хорошая идея назавать эти события экшенами.
sealed class UIAction { class LoadNamesAction(dataKey: String) : UIAction() object LoadBannerAction : UIAction() object LoadCreditDialogInfo : UIAction()}
Только не кидай в меня помидоры за силд классы, они упрощают жизнь в текущей ситуации, избавляя от дополнительных кастов при обрабокте экшенов в презентере, пример будет ниже. Интерфейс презентера будет выглядеть так:
interface Presenter { fun processAction(action: UIAction)}
А теперь давай подумаем как связать все это дело:
fun processAction(action: UiAction): UIState { return when (action) { is UiAction.LoadNamesAction -> state.copy( loading = true, isBannerShowing = false, isCreditDialogShowing = false ) is UiAction.LoadBannerAction -> state.copy( loading = false, isBannerShowing = true, isCreditDialogShowing = false ) is UiAction.LoadCreditDialogInfo -> state.copy( loading = false, isBannerShowing = false, isCreditDialogShowing = true ) }}
Если ты обратил внимание, то перетекание из одного состояния отображения в другое сейчас происходит в одном месте и уже проще сложить в голове картину как все работает.
Это не стало супер просто, однако твоя жизнь должна стать легче. Плюс в моем примере этого не видно, но мы можем решать как запроцесить наш новый стейт на основе предыдущего стейта (для реализации такого также есть несколько придумок). Я уж не говорю о безумной возможности пере использования, которой добились ребята из badoo, одним из их помощников в достижении этой цели был MVI.
Однако не стоит рано радоваться, у всего в этом мире есть как плюсы так и минусы, а вот и они
- Нас ломает об ногу обычный показ toast
- При обновлении одного флажка весь стейт будет скопирован заново и отправлен во
вью, то есть произойдет ненужная перерисовка, если ничего с этим не сделать
Предположим, что мы хотим вывести обычный андроидный toast, по текущей логике мы заведем в нашем стейте флаг для вывода нашего тостика.
data class UIState( val showToast: Boolean = false,)
Первое
Берем и меняем стейт в презентере, ставим showToast = true и самое простое, что может произойти это поворот экрана. Все уничтожается взрывы и разрушения активити пересоздается, но так как ты крутой разработчик твой стейт все это дело переживает. А в стейте у нас волшебство флаг, который говорит отобразить toast. Результат — toast показывается дважды. Для решения данной проблемы есть несколько способов и все выглядят как костыли. Опять же об этом будет написано в источниках, приложенных к этой статье.
Ну, а второе
Это уже проблема ненужных отрисовок во вью, которые будут происходить каждый раз даже когда в стейте меняется всего одно из полей. И эта проблема решается несколькими иногда не самыми красивыми способами (порой тупой проверкой перед тем как сетать во вью новое значение, на то, что оно отличается от предыдущего). Но с выходом compose в stable версию эта проблема будет решена, вот тогда мой друг заживем с тобой в преображенном и счастливом мире!
Время для плюсов:
- Одна точка входа во вью
- Мы всегда под рукой имеем текущее состояние экрана
- Еще на стадии реализации приходится продумывать как один стейт будет перетекать
в другой и какая между ними связь - Unidirectional Data Flow
Любите андроид и никогда не теряйте свою мотивацию!
Список моих вдохновителей
