Simple practices for Android design (rational combination)

Simple practices for Android design (rational combination)

In the previous article (simple practice of Android design (module division), we demonstrated the application store design to illustrate how to divide modules. The module division mainly depends on the business requirements, specifically what business is. The app store includes two services: displaying the applist and downloading the app. The second is the runtime environment. On the Android platform, androidsdk provides socket and other API support. Therefore, the module is roughly replaced with five modules. (Of course, image loading can be proposed separately by using open-source components, but I will not mention it here to illustrate how to design it. You can also use the open-source components for download as follows:

Module 1 UI ModuleRecommendActivity is responsible for displaying information and user operations. RecommendActivity is responsible for displaying data and accepting user operations. RecommendInterface, responsible for underlying data callback. (Here is just an example. The download is not mentioned)

 

The call relationships between these three classes are as follows: (My viso seems to have not activated some features and cannot be dictated only)

1. initialize the RecommendInterface instance RecommendBase instance in onCreate of RecommendActivity. And inject the RecommendInterface into RecommendBase.

2. RecommendActivity then sends a command to RecommendBase to call methods such as getPageViewData to request data.

3. Click Download. When the gotoDownLoadApp is running, RecommendBase starts to call startDownloadApp.

The calling process of the UI module is generally here.

Module 2: scheduling module. Responsible for overall business scheduling. The main classes include:

 

Huge complexity. However, let's continue to look at the relationships between class calls.

1. initialize this module to initialize the Controller. Controller initializes ControllerDownLoadAppInfosInterface and ControllerBase. Controller injects ControlelrDownLoadAppInfosInterface into ControllerBase. ControllerBase initializes ControllerDownLoadAppInterface during initialization.

2. The key point is how the UI module interacts with the scheduling module.

2.1 initialize Controller and ControllerUIInterface in RecommendBase. And inject RecommendInterface into ControlelrUiInterface.

2.2 When the RecommendActivity receives user commands, the RecommendBase receives the commands and calls the Controller. When the asynchronous results come out, the ControllerUIInterface callsRecommendInterface. AndRecommendInterface updates the UI to the user.(It can be seen that the message is cyclically circled from RecommendBase .)

3. Load page data. After receiving the commands from RecommendBase, the Controller calls ControllerBase to start loading templates and getViewDataByTempID. When the underlying layer obtains Temp and Data, the ControlelrDownLoadAppInfosInterface is notified. This interface is called back to the Controller. The Controller calls CreateViewData. Then, ControllerUIInterface is called to send data to the UI.

There is also the download process. We will not deduct it here. But it mainly depends on how modules are called, that is, how to reasonably combine them.

You will find that upper-layer businesses and their dependent interfaces are a comprehensive set of complete businesses. The scheduling layer completes a complete set of services.

The third module is the data parsing module, which parses and combines applist data and templates of the network.

Key points: how to interact with the scheduling module

Initialize the DataWorkManager class in the ControllerBase of the scheduling layer. When the scheduling layer has template and app data, call setData and call getViewDataBytempId to obtain template data.

That is to say, in the dependency class of the scheduling layer, initialize your own interface and implement the business according to the method of the dependency class.

However, this is a business unit and cannot implement the overall business.

The fourth module is the network request module.

Key point: how to interact with the scheduling layer.

First, initialize NetTaskManager and NetTaskResultListener in ControllerBase. ControllerDownLoadAppinfosInterface is injected into NetTaskResultListener.

Call downLoadTemplateById (). Asynchronous. The result is fed back to ControllerDownLoadAppinfosInterface by NetTaskResultListener. ControllerDownLoadAppinfosInterface is used to process the message.

Module 5: Download the module. Do you still need to talk about it? I don't want.

In fact, a reasonable combination depends on how you schedule between modules. The module provides interfaces because, first, its modules do not need to be concerned by other modules. You only need to call its interface. Second, if there is a problem with his implementation, the problem must be solved in this module. It does not need to be modified elsewhere. Therefore, in principle, no matter how the module changes, but the interface changes are not allowed.

Each module has its own dependent class. However, if other modules have similar implementations, the provided interface must adapt to the dependency of the former module to achieve seamless connection. The above examples are very simple. Basically, there are not many dependencies that need to be adapted to interfaces, but the actual work is much more involved.

Finally, I am sorry to say that there are many leaks in the above examples. Many of them are just simple, rough, redundant, and even wrong. Only hope to benefit.