Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
С одной стороны, статья для тех, кто уже прошел все основы, может собрать полноценное нативное приложение под андроид любой сложности и не знает, чем занять себя в свободное время.
С другой - перечисленные технологии становятся новой реальностью. И теперь просто знать о мультипоточности, ViewModels и LiveData становится недостаточно.
Цель статьи
Собираем список технологий\библиотек\фреймворков, которые нужно понять за этот год, если собираетесь проходить собеседования в компании, следящими за модой.
все нижеописанные технологии — лишь надстройки над базовыми компонентами
не обязательно знать их, чтобы написать отличное приложение
но если хотите придерживаться современных течений - айда читать документацию
Список
Далее будет идти список и краткое описание, объясняющее концепцию технологии и боль, которую она решает. Максимально коротко.
Compose
Compose — новый метод верстки.
Решает проблемы:
пропадает разделение кодовой базы — отпадает нужда в xml-файлах, оставляем только Kotlin
не нужно больше искать вьюшки по id и следить, чтобы значения обновлялись - грубо говоря, поля вьюшки подписываются на значения из viewModel и сами обновляются
не нужно больше следить за жизненным циклом (при правильной архитектуре библиотеки сами учитывают состояние lifecycler)
избавляет от наследования во вьюшках - переходим к композиции простых элементов
Flow
Flow (StateFlow, SharedFlow...) — асинхронных способ передачи данных по подписочной модели. По принципу Flow — это LiveData с кучей настроек, с завязкой на корутины и без завязки на lifecycler-компонент.
Решает проблемы:
передача данных от Database (Source) к View теперь может выглядеть как тунель без ответвлений - Database испускает данные в flow, их забирает ViewModel и пересылает во View
Да, та самая "чистая архитектура", которой сто лет, но теперь есть средство нагляднее показать идеальный "поток" данных
можно гибко настроить буффер - указать количество хранимых элементов, выбрать сценарий переполнения и определить, что делать, если пришли новые данные, а старые еще не обработаны подписчиком
Kotlin sealed class/interface
Это не целая технология, но эта фишка языка часто используется вместе с Flow и Compose, потому что идеально подходит для описания состояний.
Решает проблемы:
можно описывать состояния (States)
например, описать все состояния экрана - DataLoadedState, DataLoadingState, EmptyResultState....
результаты выполнения функции - Success<T>, Error(e: Throwable), Loading...
Подробнее о возможностях, отличиях от Enum и способах применения писал пост в tg-канале об android-разработке: https://t.me/dolgo_polo_dev/52
Kotlin delegation
Еще один сахар из котлина — синтаксическое средство, позволяющее делегировать методы getValue() и setValue() какому-то классу.
Например, оператор by lazy() делегирует метод getValue(), что позволяет инициализировать значение переменной только при первом обращении (а не в момент объявления.
Решает проблемы:
есть готовые делегаты - by lazy(), by viewModels()...
можно написать свои делегаты, избавившись от шаблонного кода
можно хранить свойства в ассоциативном списке
Hilt
Hilt — фреймворк для внедрения зависимостей, замена Dagger 2
Решает проблемы:
как и все dependency injection библиотеки - прям код создания объектов, управляет жизненный циклом и количеством создаваемых объектов
преимущество перед Dagger 2 - предоставляет собственные скопы (Scope) для всех стандартных элементов - Activity, Fragment, ViewModel, Service... - не нужно писать свои
преимущество перед Dagger 2 - не нужно писать ViewModelFactory для инъектирования во ViewModel
преимущество перед Dagger 2 - достаточно написать Module-классы, в которых объявлены Provide и Bind-функции, и ставить аннотацию @Inject
Coroutine
Корутины — пишем асинхронный код без явных коллбеков и явной работы с потоками
Решают проблемы:
код становится пошаговым, не нужно отслеживать макароны из коллбеков
если использовать правильно, приложение работает без тормозов, так как главный поток занят только отрисовкой UI
с помощью CoroutineScope и родительских отношений между корутинами можно легко прерывать выполнения функции в любом момент, если в ней больше нет нужды (например, viewModelScope автоматически остановится, когда ViewModel будет уничтожена из-за того, что пользователь ушел с экрана)
MVI
MVI — архитектура. Про ее минусы и плюсы можно бесконечно, но суть одна - многие вышеописанные технологии заточены под ее философию:
заранее описываем все возможные состояния и эффекты, и от класса к классу передаем не информацию, а информацию, обернутую в состояние
Navigation Components
NavComponents — способ описания взаимодействия экранов или же способ создания наглядной карты приложения
Решает проблемы:
не надо держать в голове или в макете, с какого экрана на какой можно перейти - в Android Studio строится визуальный граф
можно описать заранее, какие данные должны передавать экраны друг другу
нельзя случайно увести пользователя по пути, не описанному в графе
WorkManager
WorkManager — упрощает работу с запуском и контролем жизненного цикла сервисов (Service)
Решает проблемы:
очевидно - легче отслеживать, какие службы запущены, и задавать условия их смерти
становится удобнее создавать отложенные службы (в том числе те, что должны отработать после перезагрузки устройства)
в Android Studio добавили отладочное средство, которое позволяет отслеживать состояние сервисов, управляемых WorkManager
Где еще получать обзорную информацию
Если вам, как и мне, нравится подобный формат — краткий обзор концепции технологий с минимальным погружением в код, то предлагаю:
поддержать статью
оценить tg-канал об Android-разработке — с картинками и короткими постами для новичков и бывалых — Dolgo.Polo Dev Android @dolgo_polo_dev
