Introduction

The Device Configuration Service provides a set of functionality to enable users to read and write to the various characteristics that make up the service. 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 Configuration 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 | 5. Device Configuration Service

Related Jira Issues

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

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

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

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

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

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

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

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

Constraints

Performance

As the device configuration 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 Configuration Service will utilize classes 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 DeviceConfigurationService will inherit from the BaseService class, exposing public functions to read from and write 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. Each of these read and write calls will make use of data classes and structs built to represent the various characteristics that make up the device configuration service on the VictoR device. These data classes and structs will provide two constructors for ease of use: one which can take a byte array and process the data to construct the desired characteristic and one default constructor. It will be especially important that the byte array characteristic is able to account for byte arrays that do not properly represent the desired characteristic. In these cases, some (or all) of the fields that make up the characteristic will be initialized to their default values or null where appropriate. 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. Using the default constructor 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 Configuration Service Class Diagram (Windows)

 

Open

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

 

System Interaction

The below sequence diagram illustrates the typical workflow when reading a characteristic from the VictoR device. The Device Configuration 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 system time on the device, the service’s “GetSystemTime” 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 Configuration service will then utilize the Read function. This in turn calls the DeviceManager’s Read function, using the device address passed by the end-user application’s request for the system time 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 and converted into the SystemTime class, to be passed back to the end-user application.

Glossary