Introduction to android Architecture Design and android Architecture Design
So far, android development has no accepted or unified development framework on the network or in the community. Many frameworks are based on method encapsulation. Today, I am talking about my understanding of android development over the past two years. I hope it will be helpful to you.
I think android development can summarize the architecture design in two aspects. Here, we only make a statement on implementation:
One is the design philosophy of most people and the encapsulation of methods.
Here I design the project package based on the Development habits:
1. http: Network Request Method encapsulation. We recommend that you use the thread + Handler mode to separate the get method and post method in Http. The normal operation logic adopts the post method to facilitate data encapsulation, encryption and security. For image retrieval, the video can be obtained through a URL directly using the get method, which is fast and not complex.
2. thread: Since http adopts the thread method, the natural thread management is a key point. It is recommended that the whole App manage the threads in a unified manner and encapsulate multithreading and single threads according to the characteristics of the thread pool, every time a thread is enabled, it is retrieved from the thread pool. In this way, the size of memory occupied by the threads of the entire App is basically under control.
3. download: download an apk or manage images and videos. During the multi-thread, soft reference, local storage, and memory storage, images can be stored in multiple threads. Two methods are available for downloading image processing results: one is to directly pass the display Imageview display, but this method is not very convenient to process the returned image. Therefore, we recommend that you add a method for returning the image, if an object is passed back, an event is added after it falls back to the page.
4. upload: upload files, images, videos, etc. It is better to compress the files and then upload them.
5. dao: database operations, table creation, version control, data addition, data addition, deletion, modification, and query.
6. file: file operations.
7. utils: tool class.
8. exception: exception class. The exception class is mainly parsed based on the error code returned by the http request, and some details are captured during project running.
9. log: three types of log encapsulation are required: a: Development and debugging; B: Saving the error log locally during release; c: sending the error log to the server as necessary.
10. bean: Data encapsulation bean. We recommend that you use Json and Gson to convert data through bean.
2. It can be designed based on business logic processing of data and data.
The above is the encapsulation idea of most people, mainly for method encapsulation. The following is to talk about how to integrate the above encapsulation into the actual project business, mainly for business encapsulation, here, we have mainly applied two design modes: intermediary mode and MVP mode. In the meantime, the factory mode, single-profit mode, template mode, and observer mode are widely used.
The overall idea is:
11. daorest, httprest, and filerest: these packages mainly encapsulate interfaces between apps and various channels. They can be added based on actual project requirements. There is no implementation method in them, all classes are interfaces.
12. mediator: an intermediary. If we use A common method for interaction, we use A, B, and C to replace three interfaces with different sources. If there is A page V, we need to use these three sources, then there will be interaction between V and A, and between V and B, V and C. If there is A complicated relationship, there may be interaction between V and AB, etc, in this way, the interaction is like a network without rules, which is difficult to understand. At this time, if we use an intermediary, the problem will be greatly improved. When we introduce an intermediary M, ABC will be integrated into M. No matter how complicated the relationship between ABC and V is, internal integration will be involved, at last, M unified the interaction with V. At this time, the relationship is very clear. V and ABC will not affect the other party no matter who needs to change. M acts as a mediation relationship, so the mediation mode is also called the mediation mode.
13. presenter: This is P in MVP mode. Many people say that android cannot distinguish between the MVC mode, because Activity contains both V and C. In fact, the real V layer of android should be the XML layer, however, the XML layer cannot dynamically change data. So simply let us take a step back and let activity be our only V layer. At this time, MVP was born. Among them, the MV is the same as the MV in MVC. P is the layer we added to process the business in the Activity. we name it Presenter. The main role of P is to move all data service processing in the original Activity to the P layer, making the Activity a pure V. The specific implementation method can be referred to: http://blog.csdn.net/zhouyinhui/article/details/4614474
14. view: Activity implementation layer.
Finally, the project directory is summarized. Here we mainly introduce the framework structure and general implementation ideas of the Mediator + MVP model. There are many details in it, for example, each business interface in each layer of the business needs the constraint acts, management requires the factory mode, code implementation requires the template, and View layer status changes require the observer mode. Writing a framework requires a lot of effort and constant accumulation of reconstruction. Ah, by the way, a few directories are added together.
15. service: the android service will not be disabled with the application being disabled. It is often turned off by third-party software.
16. broadcase: It is useful when broadcasting and notifying the status between activities, similar to the observer mode.
Hope to help everyone and learn from each other!
Zookeeper