Simple practices for Android design (Message flow)

Simple practices for Android design (Message flow)

The above two Articles respectively show that the design is simple and also a key practice point.

The first module is divided according to the business carried by each module. It is a static description of the application.

The second rational combination is a quasi-dynamic description of how each module is mobilized to jointly implement the business.

Today, we mainly describe that the messages and data in an application and how to cycle are completely dynamic. At the same time, various design frameworks are also briefly mentioned. Is the final part.

Let's start with downloading this service. The user clicks the Download button onClick on the page, and then onClicK calls the onStartDownLoadApp (Item) of the scheduling layer. The scheduling layer downloads the module of the instruction business unit module. Call the onStartDown (Item) of the download module ). It can be seen from this that the message is passed down layer by layer. The download module starts to download data and reports the download progress downLaodProgress (id, progress). This method passes the download item information (id) and progress information (progress ), the downLoadAppProgress (id, progress) method at the scheduling layer is called by onUpdateProgress. this allows you to transmit data from the download module to the page.

Note that the process from the download module to the report progress is asynchronous. Because the download is asynchronous, the report progress must go to the main thread, therefore, the message can be downloaded to the main thread asynchronously.

 

Visible from top,

1. messages are sent simultaneously step by step, and must pass through the scheduling layer.

2 Data reporting is also a layer-1 upload, and must pass through the scheduling layer.

 

You can also give other examples. In general, it is necessary to clearly understand how messages and data flow during the design so as to completely summarize the business model and adapt it to the design.

The design models include MVC, MVP, and MVVM. Among them, MVC has a feature that not only C can update V, but M can also update V (Circular message stream). In this way, during the design process, V should not only take care of C but also take care of M, M also needs to take care of C and V. This obviously reflects the complexity. However, it is often used in large web projects. However, MVVM and mvp mvvm only call each other with P (or VM) and are not called by M. M is only called with P (or VM), but has no direct relationship with V. Therefore, in the design, V and M do not have to take care of each other.

All the above mentioned are relatively mature design models, But no matter which design model is pursuing the goal of "low coupling, high cohesion", each module takes care of each other but has its own responsibilities. Good decoupling is required in the response.

The five-view method is often used in the design. This method is comprehensive, that is, considering the surrounding runtime environment and associated modules, the internal interface and linkage mode of the program are also described dynamically and statically. I used this method to design twice. Very good. The above four articles are a simple summary based on his theory and my practice.

I suddenly thought that there was another thing I did not talk about: business changes and constant considerations. This is also very important. In the design, we should fully consider the changes that will occur in the business and how to lock the changes within a controllable range. This requires an interface that standardizes variable business implementation and must comply with the contract of the interface regardless of business changes.

Finished.