Shulou(Shulou.com)06/01 Report--

This article will explain in detail what are the three ways of unified dependency management of Android. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Brief introduction

Each project starts from the new we will import a variety of dependent libraries more or less, if there is only one module in the project, it is easy to manage the dependent library version, but if you do not pay attention to multiple module, it is easy to import multiple versions of the library or even cause version conflicts, updating and modifying the dependent library also requires multiple operations, so we need to manage the dependent library version in a unified way.

Traditional apply from approach (also used in my previous projects)

In order to uniformly manage the module, create a new config.gradle file in the root directory or define some variables in the build.gradle of the root directory

Ext {android = [compileSdkVersion: 29, buildToolsVersion: "30.0.2", applicationId: "com.xionggouba.bearseller", minSdkVersion: 19, targetSdkVersion: 30, versionCode: 27, versionName: "3.9.1", defaultPublishConfig: 'release' PublishNonDefault: true, multiDexEnabled: true, mapKey: 'c7e1ee468aaa1bf8a6739signals, pushKey:' 65aae199a0059eb1dbe7legs, pushChannel: 'developer-default',] appid = [app: "com.xionggouba.bearseller", login: "com.huitao.login" Home: "com.huitao.home", webview: "com.huitao.webview", main: "com.huitao.main", productManager: "com.huitao.productmanager", personal: "com.huitao.personalcenter", map: "com.huitao.map" Bluetooth: "com.huitao.bluetooth", push: "com.huitao.push", markketing: "con.huitao.marketing", printer: "com.huitao.printer"] versions = ["lifecycle_version": "2.2.0", "arch_version": "2.1.0" "retrofit_version": "2.6.2", "dialog_version": "3.3.0", "glide_version": "4.9.0", "hilt": "2.28-alpha", "kotlin_version": "1.4.10" "fragment_version": "1.2.5", "room_version": "2.2.6"] architecture = ["viewmodel": "androidx.lifecycle:lifecycle-viewmodel-ktx:$ {versions ['lifecycle_version']}" "livedata": "androidx.lifecycle:lifecycle-livedata-ktx:$ {versions ['lifecycle_version']}", "lifecycleruntime": "androidx.lifecycle:lifecycle-runtime-ktx:$ {versions [' lifecycle_version']}", "savedstate": "androidx.lifecycle:lifecycle-viewmodel-savedstate:$ {versions ['lifecycle_version']}", / / alternately-if using Java8 Use the following instead of lifecycle-compiler "lifecyclecommon": "androidx.lifecycle:lifecycle-common-java8:$ {versions ['lifecycle_version']}", / / Saved state module for ViewModel "viewmodelsavedstate": "androidx.lifecycle:lifecycle-viewmodel-savedstate:$ {versions [' lifecycle_version']}", "lifecycleextentions": "androidx.lifecycle:lifecycle-extensions:$ {versions ['lifecycle_version']}" "retrofit2": "com.squareup.retrofit2:retrofit:$ {versions ['retrofit_version']}", "gson": "com.squareup.retrofit2:converter-gson:$ {versions [' retrofit_version']}", "persistentcookiejar": "com.github.franmontiel:PersistentCookieJar:v1.0.1" "glide": "com.github.bumptech.glide:glide:$ {versions ['glide_version']}", "glidecompiler": "com.github.bumptech.glide:compiler:$ {versions [' glide_version']}", "oss": "com.aliyun.dpa:oss-android-sdk:2.9.1" "luban": "top.zibin:Luban:1.1.8"]]

Add to build.gradle in the root directory of the project

Apply from "config.gradle"

To find something, you have to search for it one by one.

BuildSrc mode what is buildSrc

When you run Gradle, it checks to see if there is a directory called buildSrc in the project. Then Gradle automatically compiles and tests this code and places it in the classpath of the build script. For multi-project builds, there can be only one buildSrc directory, which must be located in the root project directory. BuildSrc is a directory under the root directory of the Gradle project. It can contain our build logic. BuildSrc should be preferred compared to script plug-ins because it is easier to maintain, ReFactor, and test code.

Summary

BuildSrc is very popular in recent years because it shares references to buildSrc library artifacts, and there is only one place where it can be modified globally to support automatic completion (which is cool) and jump support. But he also has a drawback, relying on updates will rebuild the entire project, which is not very good.

Composing builds, what is Composing builds?

A composite build is just a build that contains other builds. In many ways, a composite build is similar to a Gradle multi-project build, except that it includes a complete builds rather than a single projects

Combine builds that are usually developed independently, for example, when error fixes are attempted in libraries used by the application

Break down large multi-project builds into smaller, more isolated blocks that can work independently or together as needed

Summary

This approach has the advantages of buildSrc while relying on updates without rebuilding the entire project.

Composing builds Project practice create a new model in the project to manage configuration information

Create a new class for ConfigPlugin without implementing class ConfigPlugin: Plugin {override fun apply (p0: Project) {} companion object {} edit the build.gradle file in configPluginmodel

My document is roughly as follows

Buildscript {repositories {jcenter ()} dependencies {/ / because you need to add the Kotlin plug-in classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.6.10"} apply plugin: 'kotlin'apply plugin:' java-gradle-plugin'repositories {/ / you need to add jcenter, otherwise you will be prompted that gradlePlugin jcenter () google ()} dependencies cannot be found {implementation gradleApi () implementation "org.jetbrains.kotlin:kotlin-gradle-plugin:1.6.10"} compileKotlin {kotlinOptions {jvmTarget = "1.8"}} compileTestKotlin {kotlinOptions {jvmTarget = "1.8"}} gradlePlugin {plugins {version {/ / this plugin id = 'com.umeshop needs to be referenced through id in the app module .configplugin'/ / the path of the class that implements this plug-in implementationClass = 'com.umeshop.configplugin.ConfigPlugin'} modify the settings.gradle file of the root directory

Introduce plug-ins into the project directory

Define a DependencyManager file in configPluginmodel to manage some third-party dependencies

When using catalog import

The general process introduction has been completed.

What you need to pay attention to.

Configuration of settings.gradle in the root directory

DependencyResolutionManagement {repositoriesMode.set (RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories {google () mavenCentral () jcenter () / Warning: this repository is going to shut down soon}} rootProject.name = "jetpackDemo" include': app'

Some versions are like this. It is recommended to delete the configuration of dependencyResolutionManagement and configure it in build.gradle. It goes something like this.

Allprojects {repositories {google () mavenCentral () jcenter () / Warning: this repository is going to shut down soon}}

Another is the dependent modification.

IncludeBuild ("configPlugin")

It's an includeBuild tag, not include.

What is Android? Android is a free and open source operating system based on the Linux kernel, mainly used in mobile devices, such as smartphones and tablets, led and developed by Google and the Open Mobile Alliance.

On the three ways of Android unified dependence management are shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.