Android skin replacement function design and implementation (4) -- Control Layer Design and Implementation

According to the features of Android, we can say that the standard control layer of the Android system is activity. Why do we say this? Let's start with the lifecycle of activtiy: what is the control layer? We know that the control layer is connected to the view presentation layer, and the part of the model layer mainly implements various interactions. The interaction here is a generalized interaction, an app consists of two parts: interaction with people and interaction with the system environment. For activity, we also need to explain from these two perspectives.

 

Interaction with people mainly refers to the application receiving users' click operations, changing the relevant interface display, and prompting the user's current app status through different interface changes, and step by step to achieve interaction with users. In fact, through the simple definition of APP-to-person interaction, we can know that the subject of interaction with people is actually the interface, that is, view. This is why various interactions are centered on views. This is the widely used SDK design method. Bind all interactions with users to the view. We can describe this design idea through the interface implemented by view. View implements all interfaces for interaction with users, such as click, drag and drop, and gesture. This design idea is well understood from the object-oriented perspective. After all, the smallest individual interacting with users is one view on the app interface. Of course, the SDK abstracts various controls, such as button, switch, and listview, to facilitate and quickly develop applications ...... wait. viewgroup is formed through integration of views, and various layout types such as linearlayout, relativelayout, and framelayout are abstracted. (Here we only discuss this problem from the perspective of interaction, in the following description, we will explain it from the rendering perspective .) From the perspective of interaction, we can understand that the main function of various controls is to provide an abstraction of standard interface changes during interaction, such as buttons, switches, and so on, for these controls, the main purpose is to achieve a standard interactive appearance and a standard interactive response. For example, the button is normal, pressed, and selected, and the switch is displayed in different States. The control conforms to the standard interface response for user interaction. Viewgroup focuses more on the overall layout of the interface. viewgroup provides a parent-child relationship tree for interaction, and a notification tree for interactive events such as touch events, manage the response to interactive events through the hierarchical relationship of views. In the final sense, both the control and viewgroup are an extension of the view, whether it is the interface changes emphasized by the control, or the competitor of the interactive events highlighted by the viewgroup, both emphasize the interaction with people.

The above briefly introduces the interaction with people. Next, let's talk about the interaction with the system. The interaction with the system mainly refers to the scheduling of apps by the system, that is, the processing of various system events. For Android, the most important thing is its activity class. The system calls different methods of activity for different statuses of the current app at different stages of its lifecycle. In addition to the interaction in the life cycle, the interaction with the system also includes the response of various system buttons, such as menu, back, home. The interface for system buttons and app response is also mainly in activity. The introduction of actionbar in android4.0 can also be seen as interaction with the system. This is why the activity class is often one of the most complex classes with the largest number of lines of code in Android applications, because the activity carries all the entries at the control layer, including introducing the view layout in its oncreate method, and completing various interactions with the system through its different lifecycle interfaces, this greatly enables the activity class to carry a large number of functions, and eventually changes to a large number of complex code. To share this part of work and simplify the design and implementation logic of the activity, the fragment concept introduced after Android 3.0, as the name suggests, fragment is also part of the interface, in Android, fragment is used as the control layer of some interfaces. From the fragment lifecycle, it can be seen that fragment carries methods similar to activity, in fragment, the lifecycle of an activity has a relative reaction. From this perspective, we can see that android has made great efforts to adapt to the large screen and simplify the complexity of the activity logic, for apps after android3.0, you can consider using fragment to build your own apps, divide apps into different functional blocks based on different interfaces, and implement different fragment blocks, the fragment interaction and switching are implemented in different interface switching processes.

 

During the development of the android skin replacement function, the design of the control logic is based on fragment through the above ideas to divide the entire functional interface, the control logic of different interfaces is designed separately. This effectively avoids excessive dependence on the activity and oversize the activity logic. fragment is a sub-control layer designed by Android for large-scale application development. The main work of the control layer is implemented through fragment to achieve interaction with users and systems based on small interfaces.

 

In the process of designing the control layer, in addition to the fragment designed and implemented based on each sub-interface, when designing the control layer logic, consider how to separate modules with complicated logic as much as possible. Based on the characteristics of specific applications, the menu and actionbar parts are independent of each other, specifically responsible for interaction and interface changes of actionbar and menu. In the control layer design, we also need to consider the interaction with other modules of the system. We should try to concentrate this part together, access system resources through interface mode, and receive system broadcasts. At last, it is implemented as two classes. systemfacade is responsible for accessing the system Download Manager and interacting with the Download Manager. themereceiver is responsible for broadcasting and receiving and responding from the system.

The above is basically the design concept of the control layer design process, and how to use new features in the new version of the Android system, new features as much as possible to design a simple and stable control layer logic. If the corresponding control layer is designed for the Android system application of the old version, you can create a class of new features and manage them separately. Here, we mainly use the fragment design idea, the control logic is implemented one by one based on different interfaces as the main interaction objects and independent control modules. All modules are managed comprehensively in the activity. The main purpose of designing and implementing the control layer is to make the logic simple, the structure fresh, and the coupling degree as low as possible (the coupling part can be concentrated in a class, for example, activity is a very good coupling class, concentrate the main access interfaces of the presentation layer and Module layer in the activity ).

-- Reprint is welcome. Please indicate the source
Http://blog.csdn.net/zyplus --