Разработка приложений под Android непрерывно развивается. По мере того, как сообщество продолжает изучать новые способы разработки, Google продолжает предоставлять новые технологии, чтобы мы могли двигаться вперед.
В этой статье 3 технологии, от которых, как я думаю, начнут отказываться в этом году. Как минимум — использовать меньше.
1. Android View
С самого первого дня разработки Android мы определяли представление в основном с помощью XML. Это прокси с кодом Android View (на Java) за кулисами.
Это позволяет Activity и Fragment не взаимодействовать напрямую с кодом представления.
К сожалению, есть несколько ограничений, например.
- Когда мы хотим взаимодействовать между представлениями (например, анимацией), нам понадобится код в Activity для управления всем.
- Привязать данные к представлению всегда сложно. Не существует идеального способа сделать это, за исключением ручной передачи данных.
- Цель Activity не всем ясна. Для одних это контроллер, для других — представление. Иногда у нас слишком много кода внутри.
Jetpack Compose — это будущее
В связи с этим был представлен Jetpack Compose. Совершенно другая парадигма дизайна пользовательского интерфейса, чем Android View. Он носит декларативный характер, что гораздо больше соответствует предпочтительной сегодня парадигме программирования.
В нем были преодолены проблемы Android View, упомянутые выше, например:
- View могут перекрестно взаимодействовать друг с другом в Jetpack Compose, благодаря чему управление анимацией может находиться в Composable функциях.
- Данные Mutable State автоматически привязываются к функции компонента представления. Изменения в них перекомпонуют представление. Следовательно, больше нет необходимости для явной ручной обработки данных.
- Роль Activity/Fragment продолжает уменьшаться. ViewModel можно подключить к соответствующей Composable функции.
Впервые о Jetpack Compose было объявлено в 2019 году на Google I/O, а первая стабильная версия была выпущена в сентябре 2021 года. Сейчас многие приложения начали использовать Jetpack Compose.
2. LiveData
Во время Google I/O 2017 впервые был анонсирован Architecture Component, в котором у Google теперь есть рекомендуемый шаблон архитектуры для разработчиков Android, то есть MVVM с использованием ViewModel и LiveData.
В какой-то момент ViewModel все еще была полусырым решением, поскольку она выживала только при изменении конфигурации, но не после смерти процесса. Однако в 2019 году был представлен SavedStateHandler в ViewModel, что дало возможность использовать эту технологию в каждом экране приложения.
Поэтому уже в 2020 году многие приложения начали использовать Architecture Component, используя LiveData в качестве средства связи между уровнями.
Однако он имеет много ограничений и никогда не предназначался для широкого использования. Как сказал Йигит Бояр:
LiveData никогда не был заменой RX, мы очень четко об этом говорили с первого дня, но иногда трудно контролировать повестку. На самом деле, в то время (более 5 лет назад) мы думали о том, чтобы сделать RX базовой технологией, но, увидев, как сильно люди страдают от этого, решили предоставить легкое решение, которое может справиться с обычными простыми случаями, а также послужит стартовым лекарством от реактивного программирования. По этой же причине мы никогда не добавляли многопоточность или множество трансформаций. На самом деле в первоначальном дизайне трансформаций даже не было, но мы заметили, что LiveData была слишком ограничена и бесполезна без них (без switchMap, если быть откровенным).
StateFlow — это будущее
В наши дни корутины Kotlin набирают обороты в Android-разработке, Kotlin Flow в качестве альтернативы RxJava и Kotlin StateFlow как средство связи, соединяющее разные уровни архитектуры Android.
У StateFlow много преимуществ:
- Kotlin StateFlow является частью Flow, в котором доступно множество операций для преобразования данных и т.д.
- Это может обеспечить беспрепятственную работу между различными потоками, точно так же, как мы использовали RxJava в прошлом.
- Это технический стек, не зависящий от платформы, и его можно использовать в общем коде, например, в KMM.
Что еще более важно, команда разработчиков Google теперь поддерживает StateFlow, вводя функции расширения Kotlin, чтобы сделать его работу более плавной в Android.
Хотя StateFlow еще не совершенен, я думаю, что команда Google продолжит улучшать его для использования в Android-разработке. Кроме того, уже сегодня существует множество обходных путей для его ограничений.
Так что я предвижу, что в ближайшие месяцы мы увидим больше использования StateFlow, хотя LiveData все еще может использоваться для некоторых работ, специфичных для жизненного цикла, в будущем она будет использоваться гораздо меньше.
3. Activity Lifecycle API
Это немного спорный пункт. Может быть, не все со мной согласятся, но я все больше и больше вижу эту тенденцию.
С первого дня Android-разработки, Activity доминировали в жизненном цикле экрана приложения. Они имеют множество API-интерфейсов жизненного цикла, таких как onCreate, onStart, onResume, onPause, onStop, onSavedInstanceState, onDestroy…
Их использование вызывает чувство любви и ненависти одновременно, поскольку, хотя они позволяют нам обрабатывать ответы в определенных жизненных циклах Activity, кажется, что нам нужно использовать много докучливого кода в Activity, чтобы реагировать на эти события.
Это также делает Activity/Fragment центральной точкой управления для конкретного экрана/представления. Из-за этого возникает множество технических препятствий в разработке. Например, тестирование становится сложнее.
Google начинает выступать за отказ от Activity Lifecycle API
Если мы внимательно посмотрим, подход Google к разработке для Android заключался в том, чтобы максимально отойти от Activity.
- С введением Android Architecture Component в 2017 году Google представил ViewModel, которая сохраняется при изменении onConfiguraiton. Следовательно, это помогает уменьшить вызов onSavedStateInstance (хотя и не полностью).
- С введением LiveData цель состоит в том, чтобы можно было уменьшить код в Activity и отписаться от наблюдателя. LiveData больше не будет отправлять данные наблюдателю в Activity, когда оно больше не активно, поэтому для этой цели нам больше не нужен API жизненного цикла.
- Google также представил класс Lifecycle, с помощью которого можно перехватывать события жизненного цикла по мере необходимости любым классом, который должен знать об этом. Это устраняет явную необходимость наличия кода в Activity Lifecycle API.
- В 2019 году для ViewModel был представлен SavedStateHandler, что еще больше уменьшило необходимость использования onSavedStateInstance в Activity.
Корутины с учетом жизненного цикла
В последнее время, с появлением корутин, вместо того, чтобы просто использовать Global Scope для MainScope() или даже создавать произвольные CoroutineScope, теперь у нас есть Lifecycle Aware Coroutine.
Эти корутины будут иметь возможность либо завершить, либо приостановить свое действие, когда Activity переходит в фоновый режим. Они также могут возобновиться, когда экран выходит на передний план.
Вот как выглядит их поведение:
Используя их, не нужно вручную работать с Lifecycle API, что еще больше снижает потребность в вызовах Activity Lifecycle API.
Все еще тут, просто меньше
Сегодня все еще есть приложения, которые написаны с использованием Java, может быть, не полностью, а частично. Точно так же Android View (XML), LifeData и Activity Lifecycle API будут существовать еще какое-то время. Но я думаю, что в этом году их использование начнет сокращаться.
Если вы новичок в Android, хорошо знать, что это такое, и иметь возможность использовать их по мере необходимости, но в будущем основное внимание должно быть уделено более новым способам разработки.