Обучение мобильной разработке

Объединение зависимостей Android в пакеты с помощью каталогов версий Gradle

Новая функция Gradle 7.0, которая упрощает группировку зависимостей

Когда вы создаете приложение Jetpack Compose по умолчанию с помощью Android Studio, у вас, вероятно, будет приведенный ниже список зависимостей.

implementation 'androidx.appcompat:appcompat:1.3.1'
implementation 'com.google.android.material:material:1.4.0'
implementation "androidx.compose.ui:ui:$compose_version"
implementation "androidx.compose.material:material:$compose_version"
implementation "androidx.compose.ui:ui-tooling-preview:$compose_version"
implementation 'androidx.lifecycle:lifecycle-runtime-ktx:2.3.1'
implementation 'androidx.activity:activity-compose:1.3.1'
testImplementation 'junit:junit:4.+'
androidTestImplementation 'androidx.test.ext:junit:1.1.3'
androidTestImplementation 'androidx.test.espresso:espresso-core:3.4.0'
androidTestImplementation "androidx.compose.ui:ui-test-junit4:$compose_version"
debugImplementation "androidx.compose.ui:ui-tooling:$compose_version"

Как хорошо, если все это собрано вместе, и мы можем просто сделать это

implementation (baseLibs.bundles.suite)
testImplementation (baseLibs.junit)
androidTestImplementation (baseLibs.bundles.android.test)
debugImplementation (baseLibs.compose.ui.tooling)

Хорошая новость в том, что да, в Gradle 7.0 мы можем легко связывать зависимости вместе с помощью функции VersionCatalogs, и вы можете делиться ею между проектами (как в одном репозитории, так и в отдельных репозиториях)



Совместное использование версий зависимостей между проектами
Сопоставление псевдонимов с типобезопасными средствами доступа Псевдонимы должны состоять из серии идентификаторов, разделенных тире (… docs.gradle. org



Чтобы оценить преимущества versionCatalogs, я создал дизайн в



GitHub - elye / demo_android_gradle_catalog_usage: Demo Gradle [Каталог 7.0…
Demo Gradle [функция каталога 7.0] (https://docs.gradle.org/current/userguide/platforms .html), в settings.gradle, локально… github.com



Все приведенные ниже объяснения основаны на приведенном выше дизайне.

Использование VersionCatalog Basic (преимущества объединения)

Хорошо, давайте начнем с основ. Чтобы использовать VersionCatalog, нужно сначала определить enableFeaturePreview в settings.gradle, поскольку эта функция все еще находится в предварительном просмотре.

enableFeaturePreview('VERSION_CATALOGS')

Затем в разделе dependencyResolutionManagement файла settings.gradle создайте versionCatalogs, как показано ниже.

versionCatalogs {
  version('compose_version', '1.0.0')
  alias('compose-ui-core').to('androidx.compose.ui',
       'ui').versionRef('compose_version')
  // ... more alias
  bundle('suite', ['compose-ui-core', .... ]
}

Из bundle мы можем сгруппировать все зависимости вместе, поэтому в dependencies из build.gradle нам просто нужно следующее

implementation (baseLibs.bundles.suite)

Мы можем связать разные зависимости вместе, например для тестирования, для отладки, для testAndroid и т. д.

Благодаря этому теперь у нас может быть связка зависимостей в нашем build.gradle, например

implementation (baseLibs.bundles.suite)
testImplementation (baseLibs.junit)
androidTestImplementation (baseLibs.bundles.android.test)
debugImplementation (baseLibs.compose.ui.tooling)

Наличие каталогов версий в файле

Иногда нам не нравится определять все наши зависимости в settings.gradle. Лучше иметь это в файле.

Мы можем сделать это, определив все зависимости в libs.versions.toml файле и поместив их в корневую папку gradle. Он будет загружен автоматически.

При желании мы можем назвать его другим именем или поместить в другое место, тогда мы можем легко использовать from(files(....)) в settings.gradle.

versionCatalogs {
    baseLibs {
        // From Local Toml File
        from(files('gradle/baseLibs.versions.toml'))
    }
}

Формат записи зависимостей в файл TOML отличается от формата записи в settings.gradle файл. Например.

[versions]
compose_version = '1.0.0' 
[libraries]
compose-ui-core = { group = 'androidx.compose.ui', name = 'ui', version.ref = 'compose_version' }
# ... more libraries
[bundles]
suite = ['compose-ui-core',.... ...]

Чтобы увидеть полный файл здесь.

Наличие VersionCatalogs в другом репозитории

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

Это действительно здорово, как и любой проект, и теперь он легко доступен для библиотеки каталога зависимостей, без необходимости переписывать их в собственном репозитории проекта.

Создание библиотеки каталога зависимостей

Для этого мы можем создать отдельную библиотеку. В проекте библиотеки достаточно иметь указанный ниже плагин в build.gradle

plugins {
    id 'version-catalog'
}

Примечание: не используйте plugin { id 'java-library' } в библиотеке, так как это вызовет ошибку, когда другой проект попытается использовать библиотеку, с ошибкой в ​​соответствии с этим stackOverflow.

В библиотеке все, что нам нужно, это build.gradle. Мы определим в нем versionCatalogs. Для этой цели у нас может быть доступ к catalog.

plugins {
    id 'version-catalog'
}

catalog {
    // declare the aliases, bundles and versions in this block
    versionCatalog {
        alias('androidx-core').to('androidx.core:core-ktx:1.6.0')
        // More aliases
        bundle('androidx', ['androidx-core', ...])
    }
}

Вы можете просмотреть полный пример здесь.

После этого вам просто нужно выполнить обычный шаг публикации библиотеки. Вы можете сослаться на этот блог. Небольшое изменение заключается в том, что при публикации вам нужно будет опубликовать файл TOML вместо исходного кода и компонентов Java.

Следовательно, вместо публикации java или release компонентов

if (project.plugins.findPlugin("com.android.library")) {
    from components.release
} else {
    from components.java
}

artifact androidSourcesJar

нам просто нужно что-то простое, как показано ниже

from components.versionCatalog

Вы можете просмотреть сценарий публикации здесь.

Использование библиотеки каталога зависимостей

После публикации библиотеки каталога зависимостей, чтобы использовать ее, нам просто нужно получить к ней доступ из settings.gradle, как показано ниже.

versionCatalogs {
    baseLibs {
        from("io.github.elye:dependencies-lib:1.0.0")
    }
}

Вот и все. Теперь любой проект может получить доступ к общим каталогам версий.

Дополнительные мысли… использование versionCatalogs для библиотеки

Очень приятно, что все приложения теперь могут обращаться к versionCatalogs в settings.gradle для общих зависимостей.

Один вопрос: если мы создаем библиотеку (а не приложение), может ли библиотека зависеть от versionCatalogs в ее settings.gradle файле?

Это может вызвать вопрос, потому что settings.gradle корневого файла является внешним файлом (на корневом уровне) для экспорта первой библиотеки (зеленый цвет ниже).

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

Это было экспериментировано с использованием этой библиотеки.

Последние мысли

versionCatalogs выглядит удобно. Но есть несколько соображений, прежде чем его использовать.

  1. это все еще функция предварительного просмотра, ничто не может гарантировать, что она не изменится.
  2. в Android Studio, похоже, не появляется новое обновление зависимостей, когда оно есть (в отличие от случая, когда зависимость напрямую реализуется в build.gradle, когда доступна более новая версия, Android Studio может отметить необходимость обновления)

Помимо двух вышеперечисленных пунктов, в целом у меня довольно удобная функция для объединения общих зависимостей для использования в нескольких проектах.

Спасибо Наньчен Янг за то, что поделился со мной информацией о доступности этой функции и поигрался с ней.