Android development: From Modular to component

In the Android SDK article, we talked about modularity and assembly, and now we're going to talk about what's behind component development. The first is to apply the component in the Ad SDK, but also for common application development

The following high-energy, please prepare mentally, do not understand please send a private letter to communicate. This article is not recommended for beginners to read, if you have just contacted Android development soon, please give up reading this article immediately.

Hundred Cattle Information Technology Bainiu.ltd organized and published in the blog Park

Modular and modular Assembly

The component is not a new concept, it has been paid much attention in all walks of life. As to when the component is in the field of software engineering has not been refined, but it can be confirmed that the first component of the application of server-side development, and then under the guidance of the idea, the front-end development and mobile development also produced their own development.

Review the modular definition before you understand the component

Modular programming is a software design technique this emphasizes separating the functionality of a program into Independ ENT, interchangeable modules, such, contains everything necessary to execute only one aspect of the desired funct Ionality.

In a nutshell, modularity is a process of splitting a program into its own function, dividing it into separate modules so that each module contains only the content relevant to its function. Modules we are relatively familiar with, such as the login function can be a module, the search function can be a module, the car's transmitter is also a module.

Component of

Now let's look at "component development," and here's the definition:

component-based Software Engineering (CBSE), also known as component-based Development (CBD), is a branch of software Engi Neering that emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a GIV En software system. It is a reuse-based approach to defining, implementing and composing loosely coupled independent components into systems. This practice aims to bring a equally wide-ranging degree of benefits in both, the short-term and the long-term for The software itself and for organizations that sponsor such software.

The popular point is: The component is based on reusable purposes, a large software system in the form of separation of concerns, split into multiple independent components, has less coupling.

How to see or very abstract, said so much seems to still do not understand. What is a component? A component can be a module, a Web resource, a package, such as a car's engine is a module, a component, or a calendar control in the front end is a module, but also a component.

Modular vs Component

When you see this, you must be mentally aversion: modular? What the hell is that?
This feeling is right, modularity and component of the essence of the idea is the same, are "Dahua small", both of the purpose is to reuse and decoupling, but the term is not the same. If you want to say the difference, you can consider the modularity granularity is smaller, more emphasis on reuse, and the component granularity is slightly larger than the module, more focused on business decoupling

Advantages and disadvantages of components

The benefits of component development are obvious: system-level control is refined to component-level control, and a complex system is built with the result of component integration. Each component has its own version, which can be compiled, tested, packaged, and deployed independently.

After the product is assembled, the product can be configured and sold in full sense, the user can choose to use those components, and the components can be built flexibly.

Configuration management, development, testing, packaging, release complete control to the build level, and bring many benefits. For example, if a component iteration is upgraded, the other components do not need to be tested at all if there is no change to the externally available interface.

But the implementation of the component puts a higher level of demands on the developer and the team manager. Compared with the traditional way, in the project management and organizational difficulty increased, require developers to have a deeper understanding of the business.

Why do I need to implement component development in Android for Android projects?

Why do you want to implement component development in Android, the root cause is that business growth increases the complexity of the project, in order to better adapt to team development, improve development efficiency, the implementation of components is the trend.

To help you understand the above sentence, I'll start with the earliest Android project development approach.

Simple development model

The so-called simple development model is the most basic development method, there is no so-called module in the project, there is no so-called planning, common in the beginner learning stage or the individual learning process written by the demo, its structure is probably as follows:

It is not difficult to find, often in an interface there is a large number of business logic, and business logic is flooded with various network requests, data manipulation and other behaviors, the whole project does not have the concept of the so-called module, the basic unit of the project is not a module, but a method-level.

There is nothing to be told about this development model, as we have experienced in the early days, and it is now rare to see a few very old projects and beginner practiced hand.

Single Engineering development model

This kind of development model already has the Clear module division, and through the logical stratification presents the good structure, this model is most familiar to us, usually uses in the early product rapid development, the team size is small case. The development model is structured as follows:

With the iteration of the product, the complexity of the business, and the consequent increase in the complexity of the project structure, we are faced with several problems:

1. The actual business change is very fast, but the business module coupling is too high and reaching before the project.
2. Any modifications made to the project must be compiled for the entire project.
3. Functional testing and system testing are performed every time.
4. There are a lot of conflicts in team development. Have to spend more time to communicate and coordinate, and in the development process, any one member can not focus on their own function point, affect the development efficiency.
5. The project can not be flexibly configured and assembled. For example, today the Product manager said add this function, tomorrow said to remove, the day after next added.

In the face of these problems, we rethink the component and see if it solves the challenges we face in the development of Android projects.

Multi-component Development model of main engineering

With the idea of component-based, we extract the business in the business layer on the basis of the "single project" model, package it into the corresponding business components, extract the parts from the base library, encapsulate it as the basic component, and the main project is a running app, as the entrance to each component (the main project is also called Shell program). These components are either presented as jars or in the form of an AAR. The main project uses the functionality provided by the component in a way that relies on it.

(It is important to note that this is the ideal state of the structure diagram, the actual project, the business components will generate communication between, will also produce dependencies, in this regard, we talk below)

Both the jar and the AAR are essentially libraries, and they cannot be run separately from the main project. When members of a team are involved in the development of a project, each member of the development equipment must have at least the main project and the respective components, it is not difficult to see by the implementation of the project component, Each member can focus on the business he or she is responsible for, does not affect other businesses, and with the help of stable base components, can greatly reduce code defects, so that the entire team can be developed in parallel in a way to advance the development process efficiently.

Not only that, the component can be flexible to let us do the product assembly, to do is to configure the corresponding components according to the requirements, and finally produce the products we want. It's kind of like playing with bricks, and we can get the shape we want by different places.

For the test students, can effectively reduce the test time: The original business does not need to perform functional testing again, can focus on the change of business testing, as well as the final integration test.

So far, we've solved some of the problems in the single-project development model, which is fine for most teams, but there are still some things that can be improved: every time you modify a dependent package, You will need to recompile the generated Lib or AAR. For example, Xiao classmate took over a project has more than 40 components, at the end of the integration of all components, small Yan classmate found that there is a problem, in order to locate and modify the components of the problem, the small Yan classmate constantly this debugging component. Because of this model, Components can not be separated from the main project, it means that every time after the change, the students will have to wait in the long process of compiling. What's worse, now it's only 5 hours away from the line, 10 minutes per compilation, to fix this bug, compiled 20 times, uh ... nothing to do, you can submit a resignation report

How do I solve the problem of compiling each component with the main project? Let's see how the main engineering multi-sub-engineering development model solves this problem.

Multi-sub-engineering development model of main engineering

This kind of development model is improved on the basis of "main engineering multi-component" development model, and its structure diagram is as follows:

It is not difficult to find that this kind of development model is structurally and "main engineering multi-component" is not different, the only difference is: All business components are no longer mouble but as a sub-project, the base component can be moudle, or sub-engineering, the sub-project and the main project is different: In debug mode as an app, Can be independently developed, run, debug; Release mode as the library, is dependent on the main project, to provide services to the main project.

In this model, when the small Yan classmate found a business component defects, how will do? For example, the basic component 2 problem, because in the debug mode, the basic component 2 as an app can be run independently, it can be easily modified to the module, Debug. After the last modification, you only need to recompile the entire project.

It is not difficult to find that this kind of development model effectively reduces the number of full compilations, reduces compilation time, and facilitates developers to debug.

For the test students, functional testing can be in advance, and be able to participate in the development process in a timely manner, minimizing risk.

By now, we have demonstrated at the theoretical level the convenience of using component development, and word ... is not convincing, and in the next section we will talk about how to implement the component in Android.

Component partitioning for problems encountered during assembly

Component is the first thing to do is to divide the components. How to divide and not have an exact standard, I recommend the early implementation of the component, can be a "coarse" granularity, so the advantage is that the late with the understanding of the business to subdivide again, without too much cost. Of course, I recommend dividing the component this work has to be customized by the team architect and the business person to negotiate.

Sub-project Work mode switching

In the "main engineering multi-sub-engineering model", we mentioned that the sub-project in the debug mode as a separate application run, in release mode as the library run, how to dynamically modify the sub-project operation mode? We all know that the construction of Gradle apply plugin: ‘com.android.application‘to identify the application, while the apply plugin: ‘com.android.library‘ flag is the library. Therefore, we can modify the working mode of the sub-project by judging the parameters in the build environment, and add the following script fragment to the Gradle script header of the subproject:

if (isDebug.toBoolean()) {    apply plugin: ‘com.android.application‘} else {    apply plugin: ‘com.android.library‘}

• 1
• 2
• 3
• 4
• 5
• 6

In addition, the sub-project in different modes of operation, its androidmainifest.xml is not the same, you need to provide their own androidmanifest.xml files: in the sub-project SRC directory (created elsewhere) to create two directories, Used to store different androidmanifest.xml, like here I created the Debug and release directories

The next step also needs to be built in the Gradle build script for this sub-project:

android {    sourceSets {        main {            if(isDebug.toBoolean()) {                manifest.srcFile ‘src/debug/AndroidManifest.xml‘            } else {                manifest.srcFile ‘src/release/AndroidManifest.xml‘ } } }}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12

Component Communication and component dependencies

In the ideal model of "main engineering multi-component", business components do not exist to communicate and depend on each other, but the reality is the opposite, such as:

Here, business component 1 and Business component 3 also provide services to business component 2, that is, business component 2 needs to rely on both business component 3 and business component 1.

Now let's look at a worse situation:

As a result, the interdependencies between components and components can lead to two problems in a complex business situation:

• Recurring dependencies: For example, there may be a business component 3 that relies on business component 1, and business component 2 relies on business component 3 and Business component 1, which results in business component 1 being repeatedly dependent.
• subsystem communication mode can not rely on the traditional display. In this model, the use of explicit will result in a high degree of coupling of components. For example, business component 2 relies on business component 1 and communicates in an explicit way, and once business component 1 is no longer used, there will be errors in the use of realistic intent in business component 2. This clearly runs counter to the purpose of our component.

Resolving component Communication

First, solve the business component communication problem. When we saw the above complex component communication diagram, it is not difficult to think of operating system introduced bus mechanism to solve the device mount problem, similarly, the concept of borrowing bus we add "component Bus" in the project for communication between different components, the structure is as follows:

All the business components that are mounted on the component bus can implement two-way communication. The communication protocol is similar to the HTTP communication protocol, which is based on the URL. As for the way of implementation, a method that can be based on the implicit intent provided by the system, The other is to implement the component bus entirely on its own. This article is not intended to be described in detail here.

Resolving recurring dependencies

For a library that uses AAR output, Gradle will keep the latest version of AAR for us when building the project, in other words, if an AAR is offered to the main project, there will be no recurring dependency on the dependency. And if you are directly providing dependencies in project form, Duplicate code will appear during the packaging process. Resolve Project recurring dependencies There are two ways to do this: 1. For a library or jar package that is purely code-based, only the compile is executed in the final project, and provider is used in other cases; 2. Detects dependent packages at compile time. have relied on no longer depend on

Resource ID Conflict

Resource reference conflicts can occur when merging multiple components into the main project.
The simplest way to avoid this is by implementing the contract resource prefix name (resourceprefix), which needs to be configured in the component's Gradle script:

andorid{    ...    buildTypes{        ...    }    resourcePrefix "moudle_prefix"}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11

Once the Resourceprefix is configured, all resources must begin with the prefix name. For example, the prefix named Moudle_prefix is configured above, then all resource names are prefixed with the prefix, such as: Mouble_prefix_btn_save.

Component Contexts (context)

Finally, be aware that in debug mode and release mode, the required context is what you want to avoid a strong turn exception.

Conclusion

The first contact component of this concept is in the work of advertising SDK, recently continued to do some summary, so there is this article on "Component development". In addition, component development is not a silver bullet, and can not completely solve the current business complex situation, before the implementation and improvement of the project must be considered.

Please look forward to the second article, where we will show you how to implement the components of the project in the second chapter.

Android development: From Modular to component