Github github.com/beyondxia/m…

In the last article, we discussed current traditional decoupling schemes and communication mechanisms. Actually decoupling is just the first step to implement componentization, we want to do real componentization, is still need to do for business module code of points, lib (aar), the module can be integrated in the form of aar library to the main APP, further to provide the independence of the module, can even and convenient to install and uninstall the component.

  1. How do you ensure absolute decoupling between modules
  2. How to carry out the sub-warehouse code, what problems may be involved in the middle
  3. How to achieve the simple module access and offline requirements.

Let’s start with the second question, that is [how to carry out the code warehousing, which problems may be involved in the middle].

In the several large-scale projects I have developed, the componentization requirement is involved, and the componentization planning of the project starts only when the project develops from small to large to a certain extent, with more and more business modules and a certain number of developers. This meant that, at the beginning of the project, all of our modules were developed in a codeband, with developers working together, the module boundaries were not well defined. In this case, what problems will be involved in the componentized separation of modules:

  1. For example, module A wants to obtain model data, custom view, fragment, etc., of module B, but the definitions of these structures are defined in B and cannot be found in A.
  2. For example, several modules need to share some resource files (such as pictures, layout, value, etc.). It is impossible to keep one copy of the same resource in each module.

As we know, module functions are exposed in the form of interfaces, which need to be placed in the intermediate service layer, as shown in the following figure:

For the above problems, we can also put the corresponding shared data in the service layer, just like the service interface. For shared resource files, we suggest an independent module library in the service layer. Each business module can choose whether to rely on the Module library according to its needs.

Next, let’s talk about the first question [how to ensure absolute decoupling between modules]. There are two cases:

  1. How to ensure that there are no dependencies between submodules
  2. How to ensure that the main app is not dependent on submodules.

For the first problem, you can be absolutely sure that this module is decoupled from other modules as long as there are no dependencies on other modules in the sub-module’s gradle-dependencies list.

Second question, how do you make sure that the main APP doesn’t have absolute dependency on submodules? We know that if the main APP wants to integrate submodules, it has to rely on submodules. We can use a new gradle plugin dependency option, runtimeOnly, which is only available at runtime and will report errors at compile time.

In this way, absolute decoupling between each module and the main App can be guaranteed.

Now let’s move on to the third question [how to achieve module access and offline requirements with minimal effort] :

For a new business module, it is very important for us to be able to access our main APP in a minimalist way, which determines the access cost and willingness of the business side. This requires our framework (especially decoupling framework) to be able to quickly connect to the main APP with minimal code changes, which we will elaborate on in a subsequent article: the problem of a less invasive componentization scheme versus a traditional componentization scheme

So what if we want to take certain business modules offline in certain scenarios or versions? Here we need to consider two questions:

  1. In code packaging, you can optionally package certain business modules
  2. After offline, the stability of app should be guaranteed for normal inter-module calls, and app compilation should not fail or application crash due to invoking a non-existent module. For problem 1, it is easy to solve by selectively relying on some modules in the main APP. On us to the second question, has the certain requirement, the framework of our decoupling, bus, routing framework to be able to have the exception handling mechanism, such as: for some modules may have to logoff, other modules after the call, framework can throw a module that there is no exception, the caller must catch the exception.

Services provided:

public abstract class LoginService extends PAService implements ILogin {
	public static ILogin get() throws NoServiceException {
		returngetService(SERVICE_NAME); }}Copy the code

Caller:

String username = null;
try {
    username = LoginService.get().getUserName();
} catch (NoServiceException e) {
    e.printStackTrace();
}
Copy the code

Introduction to APP componentization for a low – invasive componentization solution

Next: Problems with traditional componentization schemes for a less intrusive componentization scheme