Android-gradle (iii)

Relying on management is the most shining place in Gradle, the best scenario is that you simply add a line of code in your build file, Gradle automatically downloads the relevant jar packages for you from the remote repository and ensures that you can use them correctly. Gradle can even do more for you, including when you add multiple identical dependencies to your project, Gradle will exclude the same jar package for you. In this chapter we will learn the following:

• Warehouse

• Local dependency

• To rely on this concept in a detailed

Warehouse

When we talk about dependencies, we're usually talking about remote repositories, just like those dependent libraries that rely on libraries to be used exclusively for other developers. Managing dependencies manually can cause a lot of trouble for you. You must locate the dependent file location, then download the jar file, copy the file to your project, and then reference them. Usually these jar files do not have a specific version number, so you must also remember their version number, so that when the need to update, you will know the need to replace which version. You must also put the dependency package on SVN or git so that your other colleagues can not manually download these dependent jars.

Using remote repositories solves these problems, and a warehouse can be considered a collection of files. Gradle does not add any warehouses to your project by default. So you need to add them to the repositories method body. If you are using Android Studio, then the tool is ready for you:

repositories {    jcenter()}

Gradle supports three different warehouses: Maven and Ivy, and folders. Dependent packages are downloaded from these remote repositories when you perform build builds, of course gradle will keep the cache locally for you, so a specific version of the dependency package needs to be downloaded only once.

A dependency requires the definition of three elements: Group,name and version. Group means the organization name of the library is created, usually this is the package name, and name is the unique identifier of the library. Version is the edition number of the library, so let's look at how to declare dependencies:

dependencies {       compile ‘com.google.code.gson:gson:2.3‘       compile ‘com.squareup.retrofit:retrofit:1.9.0‘}

The code above is based on groovy syntax, so the complete statement should look like this:

dependencies {      compile group: ‘com.google.code.gson‘, name: ‘gson‘, version:‘2.3‘      compile group: ‘com.squareup.retrofit‘, name: ‘retrofit‘           version: ‘1.9.0‘     }     

Pre-defined for your warehouse

For convenience, Gradle will default to three Maven repositories: Jcenter and Mavencentral, and local maven repositories. You can declare them at the same time:

repositories {       mavenCentral()       jcenter()       mavenLocal()   }   

Maven and Jcenter warehouses are two of the most famous warehouses. We don't need to use them at the same time, here I suggest you use Jcenter,jcenter as a branch of the MAVEN central repository so you can switch between the two warehouses at will. Of course Jcenter also supports HTTPS, and the MAVEN repository does not.

The local MAVEN library is a collection of all the dependencies you've used, and of course you can add your own dependency packages. By default, you can find the. M2 folder under your home file. In addition to these warehouses, you can also use other public and even private warehouses.

Remote Warehouse

Some organizations have created interesting plugins or libraries, and they prefer to put them in their MAVEN library instead of the MAVEN Central Library or Jcenter. So when you need these warehouses, you just need to add the URL address to the Maven method:

repositories {       maven {           url "http://repo.acmecorp.com/maven2"       }}

Similarly, ivy warehouses can do the same. Apache Ivy is a well-known dependency management tool in the Ant world. If your company has its own warehouse and if they need permission to access it, you can write:

repositories {       maven {           url "http://repo.acmecorp.com/maven2"           credentials {               username ‘user‘               password ‘secretpassword‘           }        }   }   

Note: This is not a good idea, the best way is to put these validations in the Gradle properties file, which we have introduced in chapter two.

Local dependency

There may be situations where you need to manually download the jar package, or you want to create your own library so you can reuse it in different projects without having to publish the library to public or private libraries. In these cases, you might not need network resources, and then I'll show you how to use these jar dependencies and how to import so packages, and how to add dependent projects to your project.

File dependencies

If you want to add a jar file as a dependency for your project, you can do this:

dependencies {       compile files(‘libs/domoarigato.jar‘)}

If you do this, it would be stupid, because when you have a lot of these jar packages, you can rewrite them as:

dependencies {       compile fileTree(‘libs‘) } 

By default, the new Android project will have a Lib folder and will be defined in dependencies (that is, add all the jars in the Libs folder):

dependencies {       compile fileTree(dir: ‘libs‘, include: [‘*.jar‘])}

This also means that in any Android project, you can put a jar file in the Libs folder, which will automatically add it to the compilation path and the last apk file.

Native bag (so pack)

C or C + + written library will be called so package, Android plugin by default support native package, you need to put the. so file in the corresponding folder:

app   ├── AndroidManifest.xml   └── jniLibs       ├── armeabi       │   └── nativelib.so       ├── armeabi-v7a       │   └── nativelib.so       ├── mips       │   └── nativelib.so       └── x86           └── nativelib.so           

AAR file

If you want to share a library, the dependent package uses the Android API, or contains an Android resource file, then the AAR file is right for you. Depending on the library and application engineering is the same, you can use the same tasks to build and test your dependent projects, of course they can also have a different build version. The difference between application engineering and dependency engineering is that the output file, application engineering generates the APK file, and it can be installed on Android devices, and dependent projects generate. aar files. This file can be used by Android application Engineering as a dependency.

Create and use dependent engineering modules

The difference is that you need to add a different plugin:

plugin: ‘com.android.library‘ 

We have two ways to use a dependency project. One is in your project, directly as a module, the other is to create an AAR file, so that other applications can be reused.

If you use it as a module, you need to add it as a module in the Settings.gradle file:

include ‘:app‘, ‘:library‘   

Here, let's call it the library, if you want to use the module, you need to add it to your dependencies, like this:

dependencies {       compile project(‘:library‘)  }

Using AAR files

If you want to reuse your library, then you can create an AAR file and use it as your engineering dependency. When you build your library project, the AAR file will be generated under build/output/aar/. To use the file as your dependency package, you need to create a folder to place it, we call it Aars folder, then copy it into the folder, and then add the folder as a dependent library:

repositories {    flatDir {        dirs ‘aars‘     }}

This way you can take all the AAR files under that folder as dependencies, and you can do this:

dependencies {       compile(name:‘libraryname‘, ext:‘aar‘)}

This will tell Gradle, under the Aars folder, add a file called LibraryName, and the suffix is an AAR dependency.

Conceptual configuration of dependencies

Sometimes you may need to work with the SDK. In order to successfully compile your code, you need to add the SDK to your build environment. You do not need to include the SDK in your apk, as it already exists in the device, so the configuration comes, we will have 5 different configurations:

• Compile

• apk

• Provided

• Testcompile

• Androidtestcompile

Compile is the default, meaning that it contains all the dependencies, that is, in the APK, the compile dependency will exist.

APK is meant to be present in the APK, but will not be included in the compilation, this seems to use less.

Provided means to provide compilation support, but does not write to the APK.

Testcompile and Androidtestcompile will add additional library support for testing.

These configurations will be used in test-related tasks, which can be useful for adding test frameworks such as JUnit or espresso, because you just want these frameworks to appear in the test apk, not in the production apk.

In addition to these specific configurations, the Android plugin also provides configurations for each build variant, which makes configurations such as Debugcompile or releaseprovided possible. This is useful if you want to add a logging framework to your debug version. A detailed description of the content, which I'll cover in the next blog.

Dynamic version

In some cases, you might want to use the latest dependencies when building your app or library. The best way to implement him is to use a dynamic version. I now show you several different modes of dynamic versioning:

dependencies {       compile ‘com.android.support:support-v4:22.2.+‘       compile ‘com.android.support:appcompat-v7:22.2+‘       compile ‘com.android.support:recyclerview-v7:+‘}

In the first line, we told Gradle to get the latest production version. In the second line, we told Gradle that we wanted the latest minor version, and that the minimum version number was 2. In the third line, we told Gradle to get the latest library.

You should be careful to use the dynamic version, if you allow Gradle to pick the latest version, it may lead to the selection of dependent version is not stable version, this will create a lot of problems for the build, and worse, you may be on your server and private PC to get different dependent versions, which directly lead to your application out of sync.

If you use a dynamic version in your build.gradle, Android Studio will warn you about the potential problem with the dynamic version, as you can see below:

Android Studio UI Operations Dependent libraries

In Android studio, the simplest way to add a new dependency package is to use the project structure bullet box. Open the interface from the File button, navigate to the dependent package navigation bar, and you will be able to see your current dependency package:

When you want to add a new dependency package, you can click the Small green button, you can add other modules, files, or even Internet search.

Using the Android Studio interface allows you to easily navigate through all the dependencies in your project and add new dependency packages. You don't have to add code manually in Build.gradle, and you can search directly for dependent resources in the Jcenter library.

Summarize

In this chapter, we learned how to add dependencies in a variety of ways, we learned what warehouses are and how to use them, and learned how to use jar files without using warehouses.

You now know the dependency on the property configuration of the package, dynamic versioning, and so on.

We've also talked about building app variants in multiple environments, and in the next chapter we'll learn what build variants are and why they are important, and building variants will make it easier to develop tests and distribute apps. Understanding how a variant works can speed up your development and distribution efficiency.

Original: 1190000004237922

Follow the public number for more information:

Android-gradle (iii)