3 технологии Android-разработки, от которых начнут отказываться в 2022 году

Разработка приложений под 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.

1. С введением Android Architecture Component в 2017 году Google представил ViewModel, которая сохраняется при изменении onConfiguraiton. Следовательно, это помогает уменьшить вызов onSavedStateInstance (хотя и не полностью).
2. С введением LiveData цель состоит в том, чтобы можно было уменьшить код в Activity и отписаться от наблюдателя. LiveData больше не будет отправлять данные наблюдателю в Activity, когда оно больше не активно, поэтому для этой цели нам больше не нужен API жизненного цикла.
3. Google также представил класс Lifecycle, с помощью которого можно перехватывать события жизненного цикла по мере необходимости любым классом, который должен знать об этом. Это устраняет явную необходимость наличия кода в Activity Lifecycle API.
4. В 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, хорошо знать, что это такое, и иметь возможность использовать их по мере необходимости, но в будущем основное внимание должно быть уделено более новым способам разработки.

Источник