Introduction

The Device Information Service class provides a set of functionality to enable users to read and write to the various characteristics that make up the service, as well as subscribe to changes to characteristics that allow for notifications. These functions will provide a layer of abstraction from the byte arrays that are passed back and forth between applications using the SDK and the physical device. The Device Information Service will derive from the Base Service class to provide a set of lower level functionality to read and write byte arrays that will be leveraged when calls to read and write to specific characteristics are made.

Requirements

Software Requirements | 4. Device Information Service

Related Jira Issues

https://unity3d.atlassian.net/browse/FNSDKEXT-72

https://unity3d.atlassian.net/browse/FNSDKEXT-178

https://unity3d.atlassian.net/browse/FNSDKEXT-110

https://unity3d.atlassian.net/browse/FNSDKEXT-177

https://unity3d.atlassian.net/browse/FNSDKEXT-198

Constraints

Performance

As the device information service deals with interacting with the physical device, asynchronous Read/Write calls will be made available to provide non-blocking calls to the device.

Ease of Use

Rather than require byte arrays to read/write to/from the device, the Device Information Service will utilize classes and primitives to represent the various characteristics.

Supported Characteristics

Certain characteristics, and elements of characteristics, are currently not supported through read/writes to the characteristic. If a particular characteristic is not listed in the Detailed Design section, it can be assumed that the characteristic will not be supported. Similarly, if a characteristic value is marked in red, this signifies that the latest ICD shows a lack of support for that particular value. While the characteristic data struct may contain a correlating field relating to the item, it is not expected to cause any changes to the device itself.

Detailed Design

The Device Information Service will inherit from the Base Service class, exposing public functions to read from, write to, and subscribe to specific characteristics in the service without the need to deal with the byte arrays passed between the device and the lower level function calls. It is important to note that the expected use case will be to first pull data from the device, modify the data where needed, and send back the modified object to the device. Assigning values without also verifying the current values on the VictoR device will cause any values currently set on the device to be overwritten.

Open

Figure 1A: Device Information Service Class Diagram (Windows)

 

Open

Figure 1B: Device Information Service Class Diagram (Android)

 

System Interaction

The below sequence diagram illustrates the typical workflow when reading a characteristic from the VictoR device. The Device Information Service provides public functions for getting and setting specific characteristics, with each characteristic having a corresponding class that represents the characteristic within the SDK. When requesting the current cpu load the device, the service’s “GetCPULoad” function is called asynchronously, with the expectation of providing a Task result containing the appropriate characteristic class, returning a null object if the read is not successful. The Device Information service will then utilize the Read function, paired with the appropriate Guid for the CPU Load characteristic. This in turn calls the DeviceManager’s Read function, using the device address passed by the end-user application’s request for the cpu load to get the data from the appropriate device. Should the device interface successfully get the data from the physical device, the byte array representing the data will be passed back through the device interface, to the device manager, and finally to the device configuration service. It is here that the byte array will be deserialized, to be passed back to the end-user application.

Glossary