This is the sixth day of my participation in the August More text Challenge. For details, see:August is more challenging

Unified Management of AArs

This is not something that every project will use, but I strongly recommend it. In actual projects, some basic controls and functions will be pulled out and managed as a separate project base library by a separate SVN branch. In a development project, a script will be written and packaged into an AAR file to be used locally, which can not only be reused to different projects but also shorten the compilation time. For example, the basic library generates three AAR based on UI, common logic, and business common module:

Used in projects:

repositories{
    flatDir{
        dirs '.. /libs'
    }
}

dependencies {
    ...
    compile(name: 'base_1. 2.0'.ext: 'aar')
    compile(name: 'commombase_1. 0.0'.ext: 'aar')
    compile(name: 'uibase_1. 2.0'.ext: 'aar')}Copy the code

If new modules are added to the base library, a new AAR will be generated, or if the product iterates over these AAR version numbers, is it possible to manually change them in build.gradle each time? This process can be fully automated.

Method: You can see that I put these aar into the root directory of the libs folder (folder optional), then get all the file names in this folder, dynamic reference.

def path = rootProject.getRootDir().getAbsolutePath() + "/libs"
    def configFile = new File(path)
// Get all files in the folder
    def files = configFile.listFiles(new FilenameFilter() {
        @Override
        boolean accept(File dir, String name) {
// Filenames filter to prevent errors
            if (name.contains("base")) {
                return true;
            } else {
                return false}}})def aar1 = files[0].getName()
    def aar2 = files[1].getName()
    def aar3 = files[2].getName()
// Reference these Aars dynamically
    compile(name: '$aar1'.ext: 'aar')
    compile(name: '$aar2'.ext: 'aar')
    compile(name: '$aar3'.ext: 'aar')
Copy the code

Is that good enough? This is all in the “build.gradle dependencies” file. If you want to wrap the AAR in the utility class, you need to add it to your dependencies. OK, gradle fully supports this. Create a utils. Gradle in the root directory

utils.gradle:

/ / gradle tools
// Get the base library version number
def getAARNames() {
    ...
// Return an array of strings
    return ["$lbName"."$aar1"."$aar2"."$aar3"]
}
ext {
// Note that this line cannot be less
    getAARNames = this.&getAARNames
}
Copy the code

In build.gradle use:

dependencies {
   ...
    // Get the aar filename, which is an array
    def aarList = getAARNames()
    compile(name: aarList[0].ext: 'aar')
    compile(name: aarList[1].ext: 'aar')
    compile(name: aarList[1].ext: 'aar')}Copy the code

And we’re done! The code is much cleaner.

Streamline the open source project directory structure

In practice, we will definitely use many open source libraries in the form of source code, especially the uI-related code, which can only be in the form of source code, so some of them are put together as Moduler and our app in a directory. When the number of open source libraries is more than a dozen, the project structure seems to be divided into priority and priority, so it is necessary to simplify. Method: Create a folder in the root directory, such as thirdPart, and put all the open source libraries in it. Then configure the project structure in Settings. gradle:

include ':bvcommon'.':app'.// This is the main project, the following are open source libraries
        ':thirdpart:PullToRefreshLibrary'.':thirdpart:datetimepicker-library'.':thirdpart:MultilevelTreeLibrary'.':thirdpart:FFmpegAndroid'.':thirdpart:autolinklibrary'.Copy the code