Изучение разработки под Android
Jetpack Compose: будущее пользовательского интерфейса Android
Android прошел долгий путь, и Jetpack Compose продолжает расти
Недавно я изучил, как Android прогрессировал в том, как код взаимодействует с пользовательским интерфейсом (View) на протяжении многих лет. Многое произошло за последние несколько лет ... и, наконец, это приземляется с Jetpack Composes.
Конечно, возникает вопрос - это просто шумиха или надолго? Стоит ли начинать изучать это или просто ждать следующего настоящего мессии?
Я считаю, что даже если Jetpack Compose не будет окончательным способом взаимодействия Android с пользовательским интерфейсом, это определенно будет путь вперед.
Вот почему ...
Заставить XML работать с кодом никогда не было идеально.
С первого дня XML - это способ определения пользовательского интерфейса приложения.
Маленький печально известный findViewById, где каждая итерация пытается избавиться от его использования, начиная с ButterKnife, затем Kotlin Synthetics и DataBinding, а в последнее время - ViewBinding.
С годами ситуация улучшилась, но подход XML все еще несовершенен. Логика пользовательского интерфейса лучше всего работает с использованием Kotlin, чем XML, поэтому создается два отдельных элемента пользовательского интерфейса, которые Google все еще пытается согласовать.
Есть даже попытка переместить модальное окно из кода в XML в функции DataBinding.
Тем не менее, слишком много шаблонного кода для поддержки. Переносить больше вещей в XML нежелательно.
Код XML + никогда не будет идеальным.
Jetpack Compose, с другой стороны, устраняет необходимость в XML и заменяет его полным кодом Kotlin для пользовательского интерфейса.
Теперь с Jetpack Compose код пользовательского интерфейса и логика могут оставаться внутри себя, полностью отделенными от других частей логики.
А недавно Крис Бэйнс исследовал преобразование приложения из XML в полностью Jetpack Compose, он показал улучшение как размера файла APK, так и времени сборки! 🤩
Архитектурная дилемма: деятельность - это представление или нет?
Когда Android был впервые представлен, не было архитектуры, рекомендованной Google. Некоторые люди кодировали все в Activity. Это плохо, так как делает код спагетти.
Само сообщество развивается, и наиболее распространенным подходом становится MVP (Model View Presenter).
Тем не менее, это очень сбивает с толку, что такое Activity.
- Действие рассматривается как представление, поскольку оно напрямую связано с представлением (XML) и иногда содержит логику пользовательского интерфейса).
- Деятельность осознает жизненный цикл, кажется центром контроля всего. (хотя в идеале ведущий должен иметь больше контроля)
Чтобы решить эту проблему, в 2017 году Google разработал компонент архитектуры. Это замечательно, поскольку теперь Google предоставляет структуру, которую он полностью поддерживает, - структуру MVVM (Model-View-ViewModel).
В нем одним из наиболее важных элементов (кроме ViewModel) является компонент LiveData и Live-Cycle Aware. Это начало смещать часть понимания жизненного цикла с Activity на ViewModel.
Тем не менее, он все еще несовершенен, поскольку Activity по-прежнему является ключом для восстановления состояния и внедрения зависимостей.
Начиная с 2020 года, упомянутая выше проблема восстановления состояния и внедрения зависимостей решается с помощью SaveStateHandle и Dagger Hilt.
Понятно, что Google пытается перенести ядро разработки с Activity на ViewModel.
Тем не менее, Activity по-прежнему связана с пользовательским интерфейсом XML. Некоторая часть логики пользовательского интерфейса все еще находится в Activity.
Чтобы полностью исключить необходимость в Activity для управления каким-либо кодом пользовательского интерфейса и просто быть проводником, представлен Jetpack Compose.
Весь код пользовательского интерфейса теперь находится в составных функциях. ViewModel и Activity больше не нуждаются в доступе к отдельному элементу пользовательского интерфейса для обновления.
Ему просто нужно обновить переменную состояния, и пользовательский интерфейс будет автоматически перекомпонован. Чтобы понять, как работает перекомпоновка, ознакомьтесь с приведенным ниже.
Activity теперь свободна от всей логики пользовательского интерфейса, а также от необходимости доступа к конкретному элементу пользовательского интерфейса для обновления. Он просто должен быть связующим звеном между ViewModel и компонуемыми функциями.
Декларативный пользовательский интерфейс: промышленная тенденция в Интернете и приложениях
Декларативный пользовательский интерфейс - это не новая вещь, которую только что представил Android Jetpack Compose. На самом деле, нативные версии Android появляются относительно поздно.
В веб-мире программирование на React существует давно, и оно относительно приветствуется и популярно. Мир приложений пытается имитировать успех: у нас есть React Native, представленный Facebook, и недавно Flutter от Google.
Они достигли определенного уровня успеха, иногда из-за того, что они пытаются поддерживать как мир iOS, так и Android с одной целью. Тем не менее, он по-прежнему относительно популярен, и попытки заставить их работать в приложении все еще продолжаются.
На рынке есть много веб-разработчиков, которые уже знакомы с фреймворком. Это позволит легко расширить такую структуру разработки для более широкого сообщества.
В мире приложений для сообщества iOS всегда обсуждаются подходы к программированию пользовательского интерфейса на основе Storyboard и InterfaceBuilder. Сгенерированный код нечитаем и трудно рецензировать. Также существует библиотека под названием SnapKit, которая делает программирование кода пользовательского интерфейса более доступным непосредственно в Swift.
Без колебаний Apple впервые представила своему сообществу декларативный пользовательский интерфейс, то есть SwiftUI, начиная с iOS 13.0. Теперь они стали достойными производства, и мы действительно видим, что эта тенденция растет, что вызывает большой интерес в сообществе.
Google также быстро отреагировал, объявив о том, что Jetpack Compose опередил свою готовность во время Google IO 2019. Альфа-версия была выпущена, а теперь выпущена бета-версия. Похоже, что в 2021 году он выйдет на достойное производство.
Что мне нравится в Jetpack Compose по сравнению со SwiftUI, так это то, что он снизился до степени базового управления API рисования из него. Используя Jetpack Compose, я могу программировать пользовательские представления, такие как Приложение для рисования, Простая анимация часов и даже Игра Flappy Bird.
Это выглядит действительно многообещающе. Это проверенная рабочая среда пользовательского интерфейса, которую индустрия приняла в веб-мире, и мир приложений (как для iOS, так и для Android) движется к ней. Он должен остаться.
Jetpack Compose… должен оставаться и расти
Мне ясно, что с рождением Jetpack Compose
- Google удалось устранить проприетарный подход к разработке XML, который имеет так много ограничений, которые Google пытался решить в прошлом.
- Представлена гораздо более четкая архитектура UI vs Logic в соответствии с архитектурным компонентом, который разработал Google, и освобождает Activity от всей нагрузки на пользовательский интерфейс.
- Сейчас он принимает промышленный стандарт парадигмы разработки пользовательского интерфейса. Теперь у него может появиться больше сообществ разработчиков, то есть Сообщество веб-интерфейса, чтобы присоединиться к удовольствию разработки под Android.
Пока Google сможет предоставить стабильную версию Jetpack Compose для производства, нет никаких сомнений в том, что это будет будущее Android-разработки.
Бонусный балл, вам не нужно будет беспокоиться о том, следует ли мне больше использовать Fragment или Activity. Фрагмент тоже может исчезнуть 😜
