Oleg has over 5 years of experience developing Android apps and has worked with various architectures from Loaders/Services to MVI. He discusses how architectures have evolved from Service/Loader patterns to MVP and Clean Architecture. MVI is described as having advantages like reliable state management, testability, and forcing better app decomposition, but also potential disadvantages like complexity for new developers or with large states. Common MVI frameworks and concepts like states, flows, and handling side effects are also covered.
2. Mazhukin Oleg
Senior Android Developer
I Have over 5 years experience of developing Android apps
and came a long way through various architectures in
production. Have wide experience with different architecture
solutions from Loaders/Services to MVI.
49. Disadvantages in MVI
- Can be too complex for new developers
- Becomes very complex for big states
- Hard to test all state flows
- Side effects still use MVP approach
- Lots if analyzing possible states
- UI redraws every time state changes
- Some logic need to be implemented on every screen
50. Advantages in MVI
- Reliable state
- Single method that changes view state
- View interface reflects it’s functionality
- Testability
- Force to decompose app
- Force to think about states and state changes
Работаб с 2013, поскольку буду рассказывать про архитектуру давайте начнем с небольшого экскурса
Добро пожаловать в плохой код
Google IO 2010 показали пару подходов
Прежде чем погружаться в реализацию архитектуры давайте абстрагируемся и поговорим про то как пользователи работают с приложениями
Если абстрактно показать как пользователи работают с приложениями, то мы получил примерно такую схему.
Важно понимать что здесь можно увидеть что UI представляет собой цикл
UI это функция
UI асинхронен
Пользователи очень не любят ждать чего-то в приложении
С другой стороны сами пользователи тоже функция
Если рассмотреть их с друг другом, то можно увидеть симметрию
Итак какие выводы можно сделать
Так же если еще раз остановиться на том что пользователь эта функция, то можно выделать последовательность экранов и последовательность действий. При это они все просиходит по времени
Итак для того чтобы перенести эту абстракцию в архитектуру в ней нужно отразить следующие моменты
Давайте сразу смотреть на примере. Предположим что перед нами стоит задача сделать приложение поиск по github. Первое что можно увидеть что тут нужно знать rx.
Стейт отражает текущее состояние экрана.
Выглядит всё не очень – все происходит в одном месте. Давайте все разнесем
Выделяем View
Основную логику перенесем в презентер
Посмотрим что у нас получилось. Понятно что этот код пока далек от совершенства, давай попробуем добавить progress
Добавляем в разметку и вуаля все работает
Но давайте на минутку оснановимся и поговорим про модель.
Тогда давайте вернемся назад и кроме прогресса так же добавим ошибку в состояние
Теперь все работает как хочется. Модель полностью отображает текущее состояние экрана и все круто
Но на недел такой подход пока не гибкий и у него есть много недостатков. Основной то что нам каждый раз нужно констурировать модель. Это приводит к тому что при усложнении состояния нам придется полностью ее копировать
Если еще раз посмотреть на модель
Если еще раз посмотреть на модель
Но давайте добавим еще продакшена. Сейчас у нас нету кэширования данных и рефреша. Добавим их