In my years of Android development, I have been consciously thinking about the directory structure of an Android project. Here is my share.

For an Android project, I think there should be at least four modules. Tools, basics, business functions, App modules.

Tool module

Look at the image below: (one small suggestion: name all modules module_xxx)

Module_swutils in the module above is the most commonly used utility class for the entire project and should be relied upon by all projects. The content should be irrelevant to the project business, including utility classes, constants, and so on. For example, log module encapsulation, image loading module encapsulation. And use ContentProvider for automatic registration.

object SwUtils {
    lateinit var application: Application
    fun init(application: Application) {
        SwUtils.application = application
        varisDebug = (application.applicationInfo.flags and ApplicationInfo.FLAG_DEBUGGABLE) ! =0}}Copy the code

SwUtils, for example, saves the global Application for use by this module. It is also recommended that each module have a unique application context and not use the context of other modules. Or save the application of the tool module with a variable in each module for use as this module.

class UtilContentProvider : ContentProvider() {
    override fun query(
        uri: Uri,
        projection: Array<String>? , selection:String? , selectionArgs:Array<String>? , sortOrder:String?).: Cursor? {
        return null
    }

    override fun onCreate(a): Boolean {
        SwUtils.init(context as Application)
        return true
    }

    override fun update(uri: Uri, values: ContentValues? , selection:String? , selectionArgs:Array<String>?: Int {
        return 0
    }

    override fun delete(uri: Uri, selection: String? , selectionArgs:Array<String>?: Int {
        return 0
    }

    override fun getType(uri: Uri): String? {
        return null
    }

    override fun insert(uri: Uri, values: ContentValues?).: Uri? {
        return null}}Copy the code

The above uses provider for automatic registration of modules, which is a lot of usage, will not expand on.

This is the overall structure of the tools module: pure tools, irrelevant to the business

Basic module

Module_base module, which I understand as the base module. The content includes basic encapsulation of activities, fragments, views, BaseActivity and so on. There are also custom views that are used by specific businesses. This module does not recommend storing XML resources, such as String.xml (multilingual). These resources should be placed under the specific business module used.

api project(":module_swutils")
Copy the code

Using the tool module via the API, yes, it can be used in other modules.

Business module

Module_fun1, module_FUN2, and module_wechat are all service modules that implement the service functions of the project.

During implementation, parts that are common are dropped into the Base or utils module, depending on whether they are relevant to the business.

Service modules do not depend on each other, and Arouter can be used to jump between components.

The service module depends on the Base module.

The App features

As the Project of the Project, App should not contain any business logic implementation under ideal circumstances and only serve as the startup module of the Project.

In addition, in addition to these four modules, perhaps because the tool module or the base module is too large, we can divide the module_third module into a tripartite module, which is used to store some encapsulation of the open source module.

For companies with multiple projects:

Because utils is completely business independent, it is possible to maintain the module and upload Maven as an internal common module for use.

conclusion

The project is roughly divided into four modules:

Utils: Utility module, completely business neutral, pure function

Base: The base module that encapsulates the common UI, business-related functions and constants, and depends on the upper layer

Funx: specific service module, which depends on Base.

The App; Shell engineering, as far as possible not to achieve business, only responsible for the start of the project.

Have good ideas can be added, welcome to exchange.