Adoption of design patterns in ANDROID-behavior patterns

Adoption of design patterns in ANDROID-behavior patterns
 1 responsibility chain model

The purpose of the responsibility chain mode is to allow multiple objects to process requests, so as to avoid coupling between request senders and receivers. Connect these objects into a chain and pass the request along the chain until an object processes it. So that multiple objects have the opportunity to process the request, so as to avoid coupling between the request sender and the receiver. Connect these objects into a chain and pass the request along the chain until an object processes it. The structure of the responsibility chain mode is as follows:

The responsibility chain mode is used when an input event is submitted to the view in the ANDROID input management system. Its Class diagram is shown below:

The internal class EarlyPostImeInputStage, NativePostImeInputStage, ViewPostImeInputStage, and SyntheticInputStage in the ViewRootImpl class in the class diagram form an input event responsibility processing chain, which is used to process input events in stages, it is passed to the next object for processing until the event is processed.

2. Command mode

The purpose of the command mode is to encapsulate a request as an object so that you can parameterize the customer with different requests, queue requests or record request logs, and supports undo operations. The command mode structure is as follows:

In the ANDROID system, the command mode is also used. For example, in the event Input System, the command mode is used when the InputDispatcher object forwards events: encapsulate each input event as an object of the NotifyArgs type. Different events correspond to different subclasses of the NotifyArgs class. For example, the key event corresponds to the NotifyKeyArgs class, And the touch event corresponds to the notiftionargs class, the receiving object of the policyargs command is InputDispatcher. Therefore, the event itself is forwarded to the InputDispatcher object through the execution of the event command to implement event submission. The related pattern class diagram is as follows:

3 interpreter Mode

The interpreter mode is intended to define a syntax expression for a given language and an interpreter that uses this representation to explain sentences in a language. The structure of the interpreter mode is as follows:

In the android system, the package Management Service uses the interpreter mode to parse application packages.

The PackageParser class is used to parse application packages. The PackageParser class uses the interpreter mode to explain an application package, for each syntax structure in the application package, a corresponding class is created to collect the corresponding information in the application package. The class structure is as follows:

In the figure, all classes except Resources and XmlPullParser are internal classes of the PackageParser class. The classes corresponding to each syntax structure in the application package are derived from the componet class and belong to the internal members of the componet class, A Package class (a Package and a Package object) is an aggregation class used to aggregate the componet information in the parsed application Package into the Package class for unified management, the PackageParser class adds each parsed componet information to the Package.

4. iterator Mode

The intent of the iterator mode is to provide a method to access each element of an aggregate object sequentially without exposing the internal representation of the object. The structure of the iterator mode is as follows:

The iterator mode is a common mode. JAVA's collection class libraries (list, set, ing, Dictionary, ordered set, String, etc.) provide iterators in different forms, used to traverse the elements in the Collection class.

5. intermediary Mode

The intention of the intermediary mode is to use an intermediary object to encapsulate a series of object interactions. The intermediary makes the objects do not need to be explicitly referenced to each other, so that the coupling is loose and the interaction between them can be changed independently. The structure of the intermediary mode is as follows:

In the ANDROID system, keyguard uses the intermediary mode to mediate keyguard-related requests, including querying the keyguard status and power management events that affect keyguard display and reset, when keyguard is displayed, the notification events for window management and events about keyguard unlocked from the keyguard view itself are displayed. The related UML class diagram is as follows:

KeyguardViewMediator acts as an intermediary, interacts with services or objects such as power management, user management, alarm management, sound management, Status Bar management, KeyguardViewManager, KeyguardDisplayManager, KeyguardUpdateMonitor, and reads related statuses, the KeyguardViewManager, KeyguardHostView, and KeyguardUpdateMonitor send events related to the KeyguardViewMediator view and keyguard status update to the KeyguardViewMediator through related callbacks, in addition, the KeyguardService also queries the keyguard status through KeyguardViewMediator and provides the keyguard status information through the IKeyguardService interface.

6. Memorandum Mode

The purpose of the memorandum mode is to capture the internal state of an object without damaging encapsulation, and save the state outside the object. In this way, the object can be restored to the previously saved state. The structure of the memorandum mode is as follows:

There are many examples of using the memo mode in the ANDROID system. For example, saving and restoring the ACTIVITY status is an example of using the memo mode.

When an ACTIVITY is paused or stopped, the onSaveInstanceState (Bundle outState) function of the ACTIVITY is called to save the current state of the ACTIVITY to the Bundle object, when the activity is resumed or restarted, The onRestoreInstanceState (Bundle savedInstanceState) function of the activity is called to restore to the original state.

7. Observer Mode

The intent of the observer mode is to define a one-to-many dependency between objects. When the State of an object changes, all objects dependent on it are notified and automatically updated. The structure of the observer mode is as follows:

The observer mode, also known as the publish-subscriber mode, is one of the most common design modes. It can achieve loose coupling between the target and multiple observers and support broadcast communication.

The observer mode is also widely used in ANDROID systems. The observer mode provides the basis for ANDROD architecture connection, it is widely used in broadcast components, content provider components, Notification Services, View Controls, underlying event listening, and UI event input provided by the system.

The observer mode is also the basis for implementing the MVC mode. The M o d e l class in m vc serves as the target role, while Vi e w serves as the observer.

8. Status Mode

The intention of the state mode is to allow an object to change its behavior when its internal state changes. The object seems to have modified its class. The structure of the Status mode is as follows:

The status mode is also widely used in ANDROID systems, especially in data connection, Wi-Fi, Bluetooth, and other network connections and status management.

For example, in terms of WIFI management, the following state machines are provided: WifiStateMachine, P2pStateMachine, WifiController, WifiApConfigStore, and WifiWatchdogStateMachine. Each state machine object plays a Context Role in the state mode, which is used to aggregate the relevant State and start state execution.

In the ANDROID system, the State of each State machine is derived from the State class, and the State class is the implementation of the IState interface.

The following figure shows the status of WifiApConfigStore management:

9. Policy Mode

The policy pattern aims to define a series of algorithms, encapsulate them one by one, and make them replaceable. This mode allows algorithms to change independently of customers who use it. The structure of the Policy mode is as follows:

The policy mode is also frequently used. Almost every subsystem of the ANDROID system has the shadow of the Policy mode, such as the WindowManagerPolicy interface object that provides window management related policies in the window management service; the InputReaderPolicyInterface and PointerControllerPolicyInterface interface objects of the input event reading and submission policies are provided in the input management system, as well as the input event ing algorithm; audio-related services provide audio input and output configuration and activation policy AudioPolicyInterface interface objects; Network Management Services provide network statistics matching policy NetworkPolicy objects.

10. template method mode

The intent of the template method mode is to define the skeleton of an algorithm in an operation and delay some steps to the subclass. Te m p l a t e M et h o d allows sub-classes to redefine certain steps of the Algorithm without changing the structure of an algorithm. The structure of the template method mode is as follows:

The template method mode is also one of the most common design modes like the observer mode. The template method is very basic and can be found in almost any abstract class. The factory method is also a special case of using the template mode to create objects.

In the ANDROID system, the template method mode is the basis and core of the entire system framework. It provides a large runtime skeleton for running application components (including ACTIVITY, SERVICE, and Broadcastreceiver, the application only needs to re-implement the hook function (template method) in the derived class of the application component, that is, it can implement the customized function of the application, which can achieve a variety of applications, it also enables application development to follow the same framework API.

11. Visitor Mode

The visitor pattern is intended to indicate an operation that acts on each element in an object structure. It allows you to define new operations that act on these elements without changing the classes of each element. The structure of the visitor mode is as follows:

Visitor mode is also used in ANDROID systems. For example, when the input management service calls the getKeyboardLayout (String keyboardLayoutDescriptor) function to obtain the keyboard layout, the visitor mode is used. The getKeyboardLayout function calls the visitKeyboardLayout (StringkeyboardLayoutDescriptor, KeyboardLayoutVisitor visitor) function to query each package through the package management service. When the keyboard-layout element is found in the application package, call the visitor's visitKeyboardLayout function to create a KeyboardLayout keyboard layout object based on the detected keyboard-layout element.

All rights reserved. Please clearly indicate the link and source when reprinting. Thank you!

When there are too many threads, there are too many threads.