Abstract Device Management Framework

Recently, in a company's device management framework, it has been discovered that the device can be abstracted out and may be used for other possible devices. For the purposes of confidentiality, the company's business-related information is removed and listed below.

Devtool Module

1 Program Description devmanager abbreviation Dm,viewmanager VM. After the program starts, the Devmanager registers the event handling callback EVENTCALLBACKFORDM for the controller so that the Dev event arrives at the callback The event handling callback EVENTCALLBACKFORVM for the controller is registered within Viewmanager so that the callback occurs when the UI event arrives.
EVENTCALLBACKFORDM Call Dispatchrequestfromcfg To resolve whether there are matching events corresponding to the requirements need to be handled, if there is an interface, Call Getdatafromdmtovmforview to get the corresponding data from the Devmanager, and call Viewmanager's callback requestcallback to process the corresponding UI request and eventually pop up the UI. After the UI is processed, call EVENTCALLBACKFORVM, notify the controller of the completion event for the UI, and save the return data for the UI in the controller. The controller then calls the GETDATAFROMVMTODMFORDEV organization data, invokes Devmanager's requestcallback request, and finally calls Devapi to update the data in the dev. If you need to prompt for action results, you also need to go through a dm-controller->vm->controller operation.
The above description is for the Dev event processing, and also from user action. If the operation is similar to modifying the name, the processing order is vm->controller->dm->controller->vm-> Controller.
1) The VM first starts the main page, responds to the user button request, modifies the name to be inside the VM frame;
2) After completing the dev name, the controller obtains the data to form Dev's request after the legal verification is passed;
3) DM within the call encapsulated DEVAPI implementation of the modified name, after success, return to the controller;
4) The controller sends a request to the UI stating that the modification name succeeds;
5) VM Popup Modification Success prompt, the user click Success;
6) The VM notifies the controller to confirm success.
in 5) before the user clicks on the success, if the user disconnects dev at this time and the user needs to disconnect dev after closing the relevant dialog box, the action of closing the prompt will be completed from DM->CONTROLLER->VM.
The benefit of adding a layer of controller between the DM and the VM is that all the parts that need to be configured for customization are all done in this section, and other implementations can be provided in the form of libraries.
An abstraction of a controller is also a benefit of not having to cache any data within the VM. For example, to implement a dropdown box to select Dev, it is not enough to pass the dev pointer to the VM only when connecting/disconnecting events, and the VM needs to maintain the existing dev list itself.
The UML static diagram is as follows:

2 The function Devmanager, Viewmanager respectively realizes the device management, the view management. The main program realizes the function of the controller, connects each module, realizes the message transmission, the customer custom request processing.
2.1 Device Management Connection dev The new Dev object is stored in Devmap, and all data operations for Dev are performed by Devmanager. In addition to communicating with Dev, it is also responsible for replying to the Controller's request data, invoking the controller's callback, and notifying the controller event.
2.2 The view management responds to the Conroller request pop-up UI, and when the UI action is finished, call the controller's callback to return the result of the UI operation.
2.3 The controller Conroller provides a callback function to Devmanager, Viewmanager, in response to the event, and implements the parsing of the configuration, generating corresponding requests for the events at that time, and submitting them to Devmanager and Viewmanager.
2.4 Performance

2.5 Input items

2.6 Output Item None.
2.7 Algorithm None.
2.8 The process logic is not.
2.9 Interface data transmission is uniformly in XML format, and if some elements are binary stream data and are not unsigned integers, they are first converted to a hexadecimal string before being transmitted.
2.9.1 ViewType defines the types of views supported by the format: view, ListView, Tabview, ImageView, Button, ComboBox, TextView, TableView, Trayview, Bubbleview, Animateview.
Supported view content layout type: Contentlayout (left/right/center/top/down) marginwidth/marginheight
Supported Layout types: LinearLayout (vertical/horizontal)
Supported wide-Height types: height/width (30%/30)% defines the relative position of the parent window, and the pure number definition is the same as the unit defined in the MFC RC file


For example, define a vertical type of management tool Mainview

<?xml version= "1.0" encoding= "Utf-8"?><view><viewtype>mainview</viewtype><width> 500</width>



2.9.2 Dm->controller Interactive Event data format
<?xml version= ' 1.0 ' encoding= ' utf-8 '? ><event><eventtype>connect</eventtype><devindex >3</devIndex></event>




EventType selectable Connect/disconnect/format/datachange
Called in the controller's EVENTCALLBACKFORDM.


The controller then calls Getdatatfromdmtovmforview and organizes the CONTROLLER-&GT;VM interaction request data described in the next section.


The MAPTOUIID tag implements the mapping from data to UI fills.
2.9.3 CONTROLLER-&GT;VM Interactive Request data format
<?xml version= ' 1.0 ' encoding= ' utf-8 '?><request><requesttype>createui</requesttype>< View><viewtype>mainview</viewtype><viewid>view_1</viewid><viewparentid> Desktop</viewparentid><devlist> <!-The ID in this case is the same as the ID of the control in the ViewType definition, indicating that the fill is in the corresponding ID--><id> Devlist</id><maptouiid>listview_mainview</maptouiid><selectedid>dev_1</selectedid ><dev><id>dev_1</id><name>DevStd</name><sn>DS20150415</sn><  imageurl>$ (res)/dev.png</imageurl><otherparamlist><param1> <id>param_1</id>  <imageurl>$ (res)/param1.png</imageurl> </param1><param2> <id>param_2</id> <imageurl>$ (res)/param2.png</imageurl> </param2></otherparamlist ></dev></ Devlist><button><id>btn_change_name</id><isenable>true</isenable></button ><button><id&Gt;btn_view_devinfo</id><isenable>true</isenable></button><button><id>btn_ Init</id><isenable>true</isenable></button></view></request>




RequestType can be some of the needs that have been summed up in the outline design, such as Createui, Closeui, ShowUI, HideUI, and UpdateUI. The updateui corresponds to the viewid. When and only if it is createui need ViewType, Viewparent, DevId. One of the return parameters of Createui is Viewid.
The data format is called in the requestcallback of the VM.


2.9.4 Vm->controller Interactive Event data format
<?xml version= ' 1.0 ' encoding= ' utf-8 '?><request><requesttype>updateui</requesttype>< View><viewtype>mainview</viewtype><viewindex>view_1</viewindex ><event>click </event ><listview><id>listview_mainview</id><selectedid>param_2</selectedid ></listView></view></request>






The user clicked the ListView certificate node.
The data format is called in the DM eventcallbackforvm.


When the user selects the certificate, the submit request enables the certificate to operate related buttons. The CONTROLLER-&GT;VM request is called in the VM's Requestcallback, in the following format:

<?xml version= ' 1.0 ' encoding= ' utf-8 '?><request><requesttype>updateui</requesttype>< View><viewid>1</viewid><viewtype>mainview</viewtype><button><id>btn_ View_param2</id><isenable>true</isenable></button></view></request>






The user clicked the Modify Name button. The Vm->controller interactive event is invoked once, the button action is declared, and the Controller submits an interactive request to the VM again:


<?xml version= ' 1.0 ' encoding= ' utf-8 '?><request><requesttype>createui</requesttype>< view><viewtype>changelabelview</viewtype><viewid>view_2</viewid><devlist>< dev><name>dev1</name><id>dev1_devstd</id><value>devstd</value>< Maptouiid>oldname</maptouiid></label><sn><id>ds20150415<id><maptouiid> Sn</maptouiid></sn></dev></devlist></view></request>




After the user clicks on the Changenameview OK, invokes the Vm->controller interactive event and formally invokes the Modify name operation.


2.9.5 CONTROLLER-&GT;DM Interactive Request data format
<?xml version= ' 1.0 ' encoding= ' utf-8 '?><request><requesttype>updatedev</requesttype>< Dev><id>dev1_devstd</id></dev><action>changename</action><paramlist> <oldname>devstd</oldname><newname>devstdnew</newname></paramlist></request >


The message is called in the requestcallback of the DM.
Requestcallback after processing, if the execution succeeds, the controller sends the update message again to the VM, changes the UI display name, and creates a prompt box to prompt for success.




3 Additional notes:1. The implementation difference of synchronous asynchronous invocation:
Synchronization: The caller waits for the callback to finish after the next action.
Async: Returns immediately after the caller requests it. If there is an updated result, the controller is notified by event mode. There is absolutely no need to create a new thread detection in the caller and callee. The requirement to do this is to be in the same process.
If you have to have a different process, consider implementing an RPC remote procedure callback. But for now, judging from the security issues discussed earlier, you should try to do the same process, and then the UI is called in library form.


2. How to handle the button response function defined in the UI:
All the button functions are defined in the controller, such as modifying the name, finding the corresponding function pointer according to the string match, and populating the corresponding parameter list. All parameters can be unified as strings.


3, the hidden in the UI: with width or height update to 0%.


At this point, you can unify all of the UI requests, whether they are issued by a management tool, or even the UI of the installation package, and can be completely decoupled from this set. All are defined in XML.


Abstract Device Management Framework