The road to App componentization/modularization - building a development architecture idea

App componentization/modular development architecture ideas

As the business develops, App development technology becomes more and more mature, and the amount of App code for developers also grows rapidly to an order of magnitude. How to structure the App has become a practical problem faced by every developer. A good structure can improve the efficiency of developers and reduce maintenance costs.

Due to the surge in code volume in the project caused by business growth, as well as historical problems and chaotic structures, as a programmer with code cleanliness, I started thinking about how to organize the App architecture very early. The main problems I encountered are as follows:

1. The surge in code volume causes structural chaos
2. Each module references each other and has a high degree of coupling
3. Unable to independently develop or debug component code
4. Unable to cope with the need to plug and unplug components (for example: the product manager adds this feature today, removes it the next day, and adds it back on the third day T_T)

App Architecture Diagram

After reading a lot of documents, I summarized the following architecture based on the problems encountered in actual project development. Due to my limited level, please feel free to criticize if there is any unreasonable

From the bottom up, apps are divided into:

• Kernel layer
• Business Layer
• Application Layer

Kernel layer

The kernel layer includes some libraries that provide public services for the App. For example: public resources, network libraries, logging tools, databases, image loading and other core libraries. These are the basic libraries of the entire App.

Business Layer

I think this layer is the key to the entire App architecture. Because according to actual business needs, this layer will separate many independent components (actually corresponding to the Module in Android Studio), but these components can run independently, which is equivalent to a small application (how components run independently will be analyzed in detail in the application layer). And these components no longer reference each other in the traditional way, but use component routing for communication between components.

For example, if component A needs to jump to an Activity page in component B, the traditional approach is to do this in ModuleAActivity

Intent intent = new Intent(this,ModuleBActivity.class);
intent.putExtra("data", data);
startActivity(intent);

In this way, the coupling between Module A and Module B is very strong.

A better approach would be

Intent intent = Router.route(context,"BPackageName.ModuleBActivity",data);
startActivity(intent);

Of course, there are many ways to implement the above routing principle, for example, you can use the implicit call of the Android system to achieve jump communication.

In the manifest file

<activity android:name=".ModuleBActivity">
<intent-filter>
<data
android:host="moduleb"
android:path="/entry"
android:scheme="router"/>
<action android:name="android.intent.action.VIEW"/>
<category android:name="android.intent.category.DEFAULT"/>
<category android:name="android.intent.category.BROWSABLE"/>
</intent-filter>
</activity>

Actual call

String url = "router://moduleb/entry";
Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse(url));
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
PackageManager packageManager = getPackageManager();
List<ResolveInfo> activities = packageManager.queryIntentActivities(intent, 0);
if (!activities.isEmpty()) {
startActivity(intent);
}

The router layer currently has a relatively good open source framework for reference, from Alibaba's open source project: ARouter

SDK Coding Thinking

The business layer needs to achieve better component separation, and programmers need to change their current coding mindset and switch to SDK thinking.

So what is SDK thinking?

Think about how to use the interface of the library written by others in the project, and it is not difficult to understand. That is, think from the user's perspective: how to use the interface most conveniently? For example, the company currently has several App products, and each App needs to use the same authorization login. Then this authorization login module can be independent as a component.

Assume that the authorization login component is named auth. Then other components may be similar to the following code snippet when used.

AuthApi.authorize(context,userId,password).onAuthorizeFinished(
authInfo->doAuthorizeWorks(authInfo) //Process the logic after login and save the authorization code for requesting other business interfaces, such as requesting user information, etc.);

Therefore, the author believes that interface design or provision should be altruistic. Of course, this is purely the author's personal opinion, and you are welcome to continue to criticize.

Application Layer

As the name implies, this layer is the integration of the entire App and is also the entrance to the App. There are Main and Dev. Main is the integration of various business components and is the upper-layer application of the final packaged product. The component entrance is the sub-application that runs and debugs each component independently.

Dev corresponds to an Application in Android Studio. It is configured in gradle as

apply plugin: 'com.android.application'

It is a sub-project that can run independently. To debug Module A, reference this component in Dev

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

This is a general idea. It can be seen that the key part of this framework is the separation of the business layer. The basic modules in the original project need to be extracted and placed in the kernel layer. Then the next step is to build our kernel layer components.