Как стать модным Android-разработчиком в 2022 году

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

С другой — перечисленные технологии становятся новой реальностью. И теперь просто знать о мультипоточности, 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