Preface
Everyone should know that project modularization is a big proposition, and I believe that each team has its own reasonable plans. This article does not cover all aspects, but only briefly describes a feasible solution from three aspects: project collaboration, development and debugging, business module service call and notification. I won’t say much below, let’s take a look at the detailed introduction together.
Project collaboration
Project collaboration, also known as multi-project collaboration, is a management model for multiple related and parallel projects. It is an effective theory and tool to help combine projects with corporate strategies [1]. The project collaboration in this article is the collaboration between the main Android APP and other business modules.
Suppose our APP directory is as follows, one main app, multiple modules. And assume that our main app and each module are multi-git repository. A large APP is reasonable to manage multiple git repository. This article uses git repo[2] to manage projects (there may be a team using git submodule[3], which is not recommended here, there will be many pitfalls).
MApp --independentgit rep app modules module1 --independentgit rep module2 --independentgit rep module3 --independentgit rep ...
Using git repo, the team can do not have to play a whole set of git repo+gerrit in the early stage. They can consider using repo to manage the project directory, and members submit code or continue to submit git.
Project development and debugging
The main purpose of Android modularization is to develop business in parallel, reduce compilation time, but also facilitate debugging of business modules and main apps. This article introduces the following scheme.
MApp
app --application
modules
module1
demo --application
lib --library
settings_debug.gradle
MApp files:
boolean moduleDebug() {
boolean ret = false
try {
Properties properties = new Properties()
File file = file('')
if (!()) {
return false
}
(())
String debugStr = ("debug")
if (debugStr != null && () > 0) {
ret = ()
}
} catch (Throwable throwable) {
()
ret = false
}
return ret
}
include ':app'
if (moduleDebug()) {
apply from: 'settings_debug.gradle'
}
settings_debug.gradle file:
//include 'module1'
//project(':module1').projectDir = new File('modules/module1/lib')
...Other business modules
When module1 is in the requirements development stage, you don’t need to consider the main APP at all, and can be opened in Android Studio as a project. When module1 needs to run the process with the main APP, we only need to change the debug property of MApp to true and open module1 in settings_debug.gradle.
Business module service calls and notifications
When the APP is modular,Intent(Context packageContext, Class<?> cls)It is not reasonable to start the activity of other modules. After modularization, the Activity or other components in the module are best transparent to other business modules. You can evoke Activity through App Links[4], which is what we often call the url router. App Links can also play deep link. The current open source projects on Github, such as ARouter[5], are App Link applications.
Of course, communication between modules is not limited to starting the four major components, but also service calls and notifications. This service is not an Android service. For example, in the e-commerce app, click the Favorite button on the store details page to notify other modules and change the UI or data. Examples of service calls, such as the module calls login registration, and after logging in or registering successfully, the corresponding business processing will be done.
Most teams may not be involved in service calls. Service calls can be registered with the service registration center using IOC, reflection, etc. This article chooses a trick. Using methods, let Application become a service registration center as ZoomKeep. As long as each Service inherits the same Interface, it will be easy to call service between the corresponding modules.
public class MApp extends Application {
@Override
public Object getSystemService(String name) {
return (name);
}
}
Service notification, slightly simpler, can be used in broadcast, EventBus[6] or other methods. This article recommends EventBus, but it has its disadvantages. For example, after more Events, it is difficult to find the relationship between the full observer and the notifier; some simple Event objects cannot be reused, so it is best to develop them again.
Summarize
The above is the entire content of this article. I hope that the content of this article has a certain reference value for everyone's study or work. If you have any questions, you can leave a message to communicate. Thank you for your support.
refer to
[1] Project Collaboration:/wiki/%E...
[2] git repo：/git-repo/
[3] git submodule: /book/zh/v1/Git...
[4] App Links:/training/app-links/
[5] ARouter:/alibaba/ARouter
[6] EventBus:/greenrobot/EventBus