Android modular Design

1. Model diagram of Android modular design scheme

2. Interface APi-ization of Android modular design scheme

3, Android modular design using proxy mode decoupling

4. SourceSets configuration of Android modular design scheme

In this article, we use Gradle script to generate an API module, and solve the problem of dependency between modules by referring to API modules. Of course, Gradle scripts have many flexible uses. In this article, we will introduce the use of sourceSets in Gradle.

Let’s say we have two environments, dev for development and Pro for production. Dev for dev, we want to make the code output as many logs as possible for debugging, or add some class files with debugging logic, but pro for avoiding invalid logs. And it’s best not to package debugging classes in dev into APK. It is not a good idea to use normal logical judgment to perform different operations in different environments. Can you use Gradle scripts to control your environment?

Sure, that’s sourceSets. Let me start with a brief introduction to the use of sourceSets:

android{
  sourceSets{
    main{
      java{ }// Specify the code directory
      manifest{ }// Specify the manifest file path
      res{ }// Specify the resource file directory
      jniLibs{ }// Specify the jni file directory.// If you are interested, check out the articles on sourceSets}}}Copy the code

Specific files and directories can be explicitly specified in sourceSets, which we use for flexible configuration of code and resources. Now that you know the basics, let’s practice them in a project.

First, we define the variables in the project root build.gradle:

ext {
  // Development mode
  modelDev = 1
  // Production mode
  modePro = 2
  // Current development mode
  currentModel = modelDev
}
Copy the code

We then create a few more folders at the same level as the Java folder of the project:

The dev folder corresponds to the debug classes to be added to the dev environment.

The Pro folder corresponds to the empty implementation of the debug class added to the DEV environment.

For example, we added an ActivityUtil method under dev as follows:

object ActivityUtil{
    fun install(application: Application){
        application.registerActivityLifecycleCallbacks(object : Application.ActivityLifecycleCallbacks{
            //TODO implements and debugs}}})Copy the code

This method is initialized in the Application using the Install method.

If the environment is switched to Pro and pro does not have the class, the compilation will fail unless we remove the Application initializing ActivityUtil method, which is obviously not friendly.

If we created an identical ActivityUtil class in Pro with an install method, but with an empty implementation inside, wouldn’t we be able to switch environments without changing the code, and the tested code wouldn’t be packaged into APK?

Now that we have created the folders and debug classes for our different environments, there is only one final step left:

android{
	sourceSets {
        if (currentModel == modelDev) {
            main.java.srcDirs += 'src/main/dev' The dev directory is specified in //dev mode
            main.res.srcDirs += 'src/main/res-dev' In //dev mode, an additional dev resource directory is specified
        } else {
            main.java.srcDirs += 'src/main/pro' // The pro directory is specified in pro mode
            main.res.srcDirs += 'src/main/res-pro' // In pro mode, an additional pro resource directory is specified}}}Copy the code

In the future, we can switch environments by simply changing currentModel in Build. gradle and not having to worry about packaging debugging logic and unnecessary classes into production.

Isn’t it easy? Give it a try

Project address: gitee.com/StudyNotes/…

If this article can help you, please like, comment and follow us