8 мая гугл запустил превью новых Android extension libraries (AndroidX), которые представляют новую эру Support Library. Поскольку это предварительный просмотр, не рекомендуется использовать их для каких-либо производственных проектов, так как есть некоторые известные проблемы.

История Support Library началась более 7 лет назад, чтобы обеспечить обратную совместимость с API-интерфейсами. На протяжении многих лет библиотека расширилась за счет использования UX, отладки, тестирования и других утилит, специфичных для устройства. Принятие Библиотеки поддержки было феноменальным; сегодня большинство приложений для Android используют библиотеку поддержки. Мы хотим увеличить наши инвестиции в этой области, и очень важно, чтобы мы заложили прочную основу.

В этом ключе мы сделали шаг назад и побеседовали со многими из вас. Обратная связь была последовательной и единодушной; органический рост библиотеки стал запутанным. Есть компоненты и пакеты с именем «v7», когда минимальный уровень SDK, который мы поддерживаем, составляет 14! Мы хотим дать вам понять, как вы понимаете разделение между API-интерфейсами, которые связаны с платформой, и которые являются статическими библиотеками для разработчиков приложений, которые работают в разных версиях Android.

Имея это в виду, скажите «Hello World» на «AndroidX». Как уже отмечалось в объявлении Android KTX, мы добавляем новые функции в этот пакет и обновляем некоторые из существующих.

 

android.* vs androidx.* namespaces

Написание приложений для Android означает в зависимости от двух видов классов:

  • Классы, такие как PackageManager, которые поставляются вместе с операционной системой и могут иметь разные API и поведение для разных версий Android
  • Такие классы, как AppCompatActivity или ViewModel, которые отделяются от операционной системы и отправляются в ваш apk. Эти библиотеки написаны, чтобы обеспечить единую поверхность API с максимально возможной последовательностью по сравнению с версиями Android.

Во многих случаях, разрозненные библиотеки могут быть лучшим выбором, поскольку они обеспечивают единую поверхность API в разных версиях Android. Этот рефакторинг перемещает разрозненные библиотеки, включая всю Support Library и Architecture Components, в пакет AndroidX, чтобы было понятно, какие зависимости включать.

 

Читать ещё :   Android Storage : Internal, External, Removable. Часть 1

Пересмотр названий для пакетов и артефактов Maven

Мы переработали структуру пакета, чтобы поощрять меньшие, более сфокусированные библиотеки, которые уменьшают давление на приложения и тесты, которые не используют Proguard или Multidex. Maven groupIds и artifactIds были обновлены, чтобы лучше отражать содержимое библиотеки, и мы перешли к префиксным библиотечным пакетам с их groupId, чтобы создать очевидную связь между классом, который вы используете, и артефактом Maven, из которого он появился.

Как правило, вы можете ожидать следующее сопоставление от старых к новым пакетам:

Старое Новое
android.support.** [email protected]
android.databinding.** [email protected]
android.design.** [email protected]
android.support.test.** (in a future release) [email protected]

 

Библиотеки Architecture Components также были перемещены в androidx, а их имена пакетов упрощены, чтобы отразить их интеграцию с основными библиотеками. Образец изменений в этих библиотеках:

Старое Новое
android.arch.** [email protected]
android.arch.persistence.room.** [email protected]
android.arch.persistence.** [email protected]

Кроме того, после введения в 28.0.0-alpha1 Material Components для Android в качестве замены для библиотеки Design Library, мы обновили design package, чтобы отразить его новое направление.

Полный список сопоставлений от 28.0.0-alpha1 (android.support) до 1.0.0-alpha1 (androidx) см.  AndroidX refactoring map. Обратите внимание, что во время альфа-фазы могут быть незначительные изменения на этой карте.

Версионирование

Начиная с рефакторинга AndroidX, версии библиотек были сброшены с 28.0.0 до 1.0.0. Будущие обновления будут версионироваться на основе каждой библиотеки, следуя строгим правилам семантического управления версиями, где основная версия указывает бинарную совместимость. Это означает, например, что функция может быть добавлена ​​в RecyclerView и использована в вашем приложении, не требуя обновления для каждой другой библиотеки, используемой вашим приложением. Это также означает, что библиотеки, зависящие от androidx, могут предоставить разумные гарантии совместимости двоичных файлов с будущими версиями AndroidX — что зависимость от версии 1.5.0 будет по-прежнему работать при запуске с 1.7.0, но, скорее всего, не будет работать против 2.0.0.

Миграция из 28.0.0-alpha1

Перемещение вашего приложения из android.support к androidx-пакетам зависит от двух основных частей: рефакторинг исходного кода и перевод зависимостей.

Refactor_to_Androidx_menu_only

 

Читать ещё :   Android Dev : Removable Storage

Рефакторинг исходного кода обновляет ваш Java-код, XML-ресурсы и конфигурацию Gradle для ссылки на рефакторированные классы и артефакты Maven. Эта функция доступна в Android Studio Canary 14 для приложений, ориентированных на Android P.

Если вы зависите от библиотеки, которая ссылается на более раннюю библиотеку поддержки, Android Studio обновит эту библиотеку, чтобы ссылаться на androidx. Перевод зависимостей автоматически применяется в Android Gradle Plugin 3.2.0-alpha14, который перезаписывает байт-код и ресурсы зависимостей JAR и AAR (и транзитивных зависимостей) для ссылки на новые классы и артефакты, упакованные в androidx. Мы также предоставим автономный инструмент перевода в качестве JAR.

 

Что дальше?

 

Мы понимаем, что это большие изменения для существующих проектов и кодовых баз. Наше намерение состоит в том, чтобы обеспечить прочную основу для разработки проектов библиотеки Android для более устойчивого роста, улучшения модульности и меньшего размера кода.

 

Мы надеемся, что эти изменения также облегчат разработчикам изучать функции и внедрять высококачественные приложения за меньшее время; однако мы понимаем, что миграция требует времени и не вписывается в производственный график каждого человека. По этой причине мы продолжим предоставлять параллельно и обновления для android.support, на время предварительного SDK таймфрейма Андроид P. Эти обновления будут продолжать реализацию версии 28.0.0, начатой ​​с 28.0.0-alpha1 в марте 2018 года, и они будут по-прежнему совместимы с исходными кодами с существующими проектами, которые зависят от пакета android.support.

 

Стабильным выпуском 28.0.0 станет окончательный выпуск функций, упакованный как android.support. Все последующие выпуски функций будут доступны только в виде androidx пакетов.

 

Пожалуйста, пишите про любые ошибки, с которыми вы столкнулись в AOSP.