Implementation principle of hook mechanism in interface combination SDK

In the previous article, I briefly introduced the Flex-based interface combination SDK, in which the hook mechanism is used to implement UI part lifecycle management, master-Details link construction, and UI part injection. Hook is a hook. Its function can be understood as attaching additional functions to an object in a transparent way to achieve transparent extension. The hook mechanism can be applied to a variety of platforms without any restrictions on languages. It conveys an idea. The biggest advantage of using the hook mechanism to implement these features is that it is fully compatible with the design based on flex components while providing these features without increasing user complexity, it makes the user feel that we are using the SDK. That is to say, the introduction of this hook mechanism makes the functions provided by this SDK completely transparent to developers. This idea is cool. However, there is no perfect solution. This hook mechanism requires a certain order for resource release and event capture. The control sequence requires a high requirement on SDK maintenance personnel, an inexplicable error occurs. In addition, it is a little difficult to implement the hook mechanism.

Is the hook mechanism implementation class diagram.

The idisposable interface draws on the Microsoft Memory Management model. Adobe Flex is very rough in terms of memory management and GC, and has many SDK memory leaks. In modular applications, memory leaks are particularly serious. Therefore, I introduced some memory management ideas of Microsoft when designing This SDK. However, I made some changes as needed. The SDK memory is released in two stages. The first stage is implemented by the predispose function, which is used to release dependencies between class instances. The second stage is the postdispose function implementation, which is used to release instance reference. All hooks implement the idisposable interface to release the memory.

Icomponenthook inherits from the idisposable interface and defines a basic hook interface, which consists of compositionmanager, component, ishooked attributes, and hook and unhook methods, it is used to indicate the components mounted by the combined manager and hook, whether to attach and execute the mount and detach respectively.

Componenthook is the basis class of all hooks. It directly defines the attributes of compositionmanager, component, and ishooked, and sets the mounted components and ishooked attributes in the Hook method and unhook method.

The lifecycle management function consists of the icomponentlifecyclehook, icontainerlifecyclehook interface, componentlifecyclehook, containerlifecyclehook, and viewstacklifecyclehook implementation classes. Componentlifecyclehook is used to save the lifecycle status of a leaf control. the lifecycle of a leaf control is determined by its container. containerlifecyclehook is used to save the lifecycle status of the container and manage the Status of the Child control, by default, all sub-controls are consistent with the container status. viewstack is a special container that only displays one sub-control at any time, viewstacklifecyclehook is used to save the status of the viewstack container and manage the status of the currently displayed control. When the viewstack status changes, only the currently selected child control is changed, other sub-controls are not activated.

Smartpartplaceholderhook and smartpartcontainerhook implement dynamic UI part injection (in the SDK, each UI part is named as smartpart and the naming method is from Microsoft cab ). The two hooks read the location attribute from the containers that implement the ismartpartplaceholder and ismartpartcontainer interfaces, then obtain the corresponding smartpart from smartpartmanager Based on the location attribute, and inject it into these containers. The difference between smartpartplaceholder and smartpartcontainer is that the former can only inject one smartpart, while the latter can inject multiple smartparts.

Detailssmartparthook is used to build the master-Details relationship. The mastersmartpart corresponding to mastersmartpartlocations is added to a component that implements the idetailssmartpart interface to establish the relationship between the two. The relationship is transparent to users.

componenttreehook is the core class of the hook mechanism. It is mounted to the root node of the Control tree and dynamically monitors the onchildadded/removed event of the entire control tree to create and destroy all the hooks in the control tree; debugcomponenttreehook inherits from componenttreehook. The difference is that it is used to collect debugging information of the entire control tree. The debugging information collected by debugcomponenttreehook can be automatically displayed as follows.