Introduction

The Windows Mock Communications Interface will provide a set of interfaces and abstract classes that enable developers to mock communications with a mock VictoR device, facilitating communications with the VictoR Core library to support automated testing of SDK development. An abstract device class will be created to provide a means to read, write, connect, and disconnect from the mock devices, while refraining from direct references to core VictoR concepts.

Requirements

Software Requirements | 2. Communications

Related Jira Issues

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

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

Constraints

Performance

Calls to a mock VictoR device are time-sensitive I/O operations; the Windows Mock Communications Interface should not block and force the end-user to wait for these operations to complete. Instead it should return results asynchronously through callbacks.

OS Requirements

The interface will target Windows 10 platforms.

Ease of Use

The process of connecting, disconnecting, reading, and writing to a mock device should be relatively simple given that there is no real hardware or hardware interaction underlying any of the commands or performance, other than the actual system that is running the interface implementation; this helps soften the workflow when dealing with this process. Each of the abstract classes wraps behaviors in single call functions.

Detailed Design

The Mock Communications API will be comprised primarily of two classes: VictorMockDevice and VictorMockDeviceManager. These classes are implementations of the abstract VictorDevice and VictorDeviceManager interfaces provided by the VictoR Core library.

The VictorMockDevice class represents the connection interface to an individual mock VictoR device that is created and stored in system memory. This class handles all interactions with that mock device, including connecting/disconnecting, reading/writing data, and subscribing/unsubscribing from events for that mock device, such as attribute (characteristic) changes and connection state changes. These interactions are implemented as part of this API.

The VictorMockDeviceManager manages all mock VictoR device connection interfaces through VictorMockDevice objects that it creates, maintains, and destroys as needed. This class acts as the primary interface for end-users to “discover” (create) mock devices and manage connections to them. In addition, the VictorMockDeviceManager provides a wrapper around the functions that the VictorMockDevice class offers, requiring only that the end-user provide the ID for the specific mock device that they are interested in interacting with, so that they don’t need to have any knowledge of the underlying organization of the devices within the manager. The class diagram in Figure 1 illustrates the architecture of the Mock Communications API.

Figure 1

VictorMockDevice

VictorMockDevice represents an “internal” device, i.e. it is simply a data structure containing data fields (“attributes”, “characteristics”) that can be read from/written to, held in system memory.

Additionally, VictorMockDevice maintains a dictionary that maps attributes to callbacks. The callbacks should be triggered with the associated attribute whenever the attribute is written to, or on state changes.

GetDevice

Returns the device information as a VictorDeviceInfo structure

Connect

Flags device as “connected”
Retrieves a list of services, building the list if it does not exist
- The list may contain mock services
For each service, retrieve a list of offered characteristics, building the list if it does not exist
- The list may contain mock characteristics

Disconnect

Un-flags device as “connected”

IsConnected

Reports the state of the “connected” flag

Read

Reads the specified attribute and returns data via the given callback
- Attribute and data is stored as a dictionary of UUID to byte arrays
  - Where possible, byte array size will adhere to the specifications stated in the ICD

Write

Writes the given data to the specified attribute
- Attribute and data is stored as a dictionary of UUID to byte arrays
  - Where possible, byte array size will adhere to the specifications stated in the ICD
Triggers all callbacks associated with the specified attribute

SubscribeAttributeChange

Creates the specified attribute if such attribute does not already exist in the mock device
Register the given callback by adding it to the association table

UnsubscribeAttributeChange

Deregister the given callback by removing it from the association table

SubscribeConnectionStateChange

Register the given callback by adding it to the association table
Associated callbacks are triggered when connection state changes

UnsubscribeConnectionStateChange

Deregister the given callback by removing it from the association table

VictorMockDeviceManager