Design of Windows Mobile sensors api library

Background

We warmly welcome simon_new88 to join the Mobile sensors API-native unified APIs for Windows Mobile sensors project. To help him get familiar with it faster, I recorded the design of gsensor. For more information about this project, see gravitational sensor development in Windows Mobile and cppunitlite output test results in Windows Mobile.

Introduction

This article describes the design of the gsensor in the Windows Mobile sensors api library. Describes the design method of a uniform access interface sensor Library and the application of some design patterns.

Requirement

Requirements for the native unified APIs for Windows Mobile sensors:

1. Unified API access interfaces. Because HTC and Samsung mobile devices provide their own DLL to encapsulate sensor, they provide different access interfaces. Using the Windows Mobile sensors api library, application developers can)CodeYou do not need to know the API of a specific device. You only need to call the unified API of the Windows Mobile sensors api library to obtain the corresponding gsensor running information.

2. Unified output unit of gvector. Since the gvector units output by the gsensor library of HTC and Samsung mobile devices are different, the HTC output value is-100 to 100, while Samsung does not. Therefore, the Windows Mobile sensors api library must unify the units of output values. When developing client code, application developers can develop a set of code that supports both HTC and Samsung mobile devices.

 

Overall Design

The overall class graph design of the gsensor section is as follows:

BelowArticleIt is described in parts.

Gsensor Design

Gsensor is an abstract class that defines a unified access interface. It mainly provides three main interfaces:

1. gvector information interface. The client can call the getgvector () function to obtain real-time gvector information.

2. Event subscription interface. When the client calls register () to subscribe to a gvector event, it unsubscribes to the event through the unregister () function. Event sending is implemented in the Observer mode.

3. Organization adjustment interface. The client can call Scale () to adjust the desired unit.

Getgvector (), register (), and unregister () are pure virtual functions. Indicates the contract specified by gsensor. It inherits the sub-classes samsunggsensor and htcgsensor which must implement these interfaces to enforce the contract. These two subclasses call the DLL related to their respective platforms to implement these interfaces respectively.

Because HTC's dllhtcsensorsdk. dll does not implement a scheduled callback function, a threadtask class is implemented in the Windows Mobile sensors api library to regularly query gvector information. The threadtask class encapsulates the START (), stop () and processtask () functions. Start () generates a thread, and stop () is used to end the thread generated by START, processtask () is responsible for regular task execution. The specific content of the task to be executed is defined in process (). Process () is also a pure virtual function, that is, contract. The specific task to be executed is implemented by sub-classes, this can be considered as the implementation of the method template mode. Htcgsensor inherits the threadtask class, reloads process () to regularly query gvector information, and notifies the client by calling the gvectorchanged () function of gsensor. The following describes how to notify the client about the observer mode and gsensor.

Design of gsensorfactory

The simple factory mode is used here. The client only needs to call gsensorfactory to retrieve the pointer of gsensor. gsensorfactory can judge the instance of samsunggsensor or htcgsensor of the device type. For more information about simple factory, see simple factory, factory method, and abstract factory in my practical design patterns.

Observer Design

From the perspective of requirements, the Windows Mobile sensors api library must implement the event subscription interface. When the client subscribes to a message, the client automatically receives the gvector information. This function is implemented in observer mode. For more information about the observer mode, see my practical design mode-The Observer mode.

I used an open-source observer implementation mode, which is somewhat different from the implementation of the classic observer. However, the goal is to achieve the decoupling between the message provider and the message receiver. For the implementation, see experiences of implementing the observer design pattern (part 3 ).

Notifier is the abstract subject of the classic observer model. Gsensor is a concrete subject that inherits notifier and notifies observers by calling the notify () function. Listener is the abstract observer in the classic observer mode. It is a little different from the classic observer mode. Notifier notifies listener through the event class. The listener adds a layer inherited from gsensorlistener. Gsensorlistener is defined based on the specific notification content. This is implemented through the C ++ template class. For more information, see template metaprogramming.

 
Template<ClassInterface_type>
ClassListener:PublicInterface_type
 

Sensortesterview is a concrete observer. You need to implement gsensor_gvectorchanged () to process notification messages.

 

Singleton Design

Samsunggsensor and htcgsensor are designed as Singleton, because no matter how many message subscribers (listener) There is only one message sender. That is, an instance with only one samsunggsensor or htcgsensor in the system.

 

Mobile sensors API Project

This project is still in its infancy. Currently, Samsung's gravity sensor is implemented. I host the project to Mobile sensors API-native uniied APIs for Windows Mobile sensors, and I will continue to improve it, implement various sensors in this project.

Since I don't have an HTC machine on hand, if anyone is interested, I can join the project to help me test the HTC device. Because I have joined the unit test, the test is very simple and only needs to be executed.ProgramYou can refer to the test output file without debugging. Of course, this test process is a continuous iteration process, but unit test simplifies the sub-process.

Source code: Http://mobilesensor.codeplex.com/SourceControl/ListDownloadableCommits.aspx

Environment: vs2008 + WM 6 Professional SDK + Samsung Windows Mobile SDK