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

https://unity3d.atlassian.net/wiki/spaces/FNUPEXT/pages/1584529409/Software+Requirements#2.-Communications

Related Jira Issues

FNSDKEXT-138 - Getting issue details... STATUS

FNSDKEXT-139 - Getting issue details... STATUS

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.

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

Subscribe

• 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

Unsubscribe

• 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

Connect

• Adds device to dictionary with device address as key

Disconnect

• Removes device from dictionary

GetConnectedDeviceIDs

• Returns a list of IDs from connected device dictionary

ScanForDevices

• Creates a number of mock devices that have been scanned

Read

• Reads data from a mock device

Write

• Writes data to a mock device

• Trigger all callbacks associated with the attribute

SubscribeAttributeChange

• Retrieves specified mock device from dictionary of connected devices

• Invokes the mock device’s Subscribe function with the given callback

UnsubscribeAttributeChange

• Retrieves the specified mock device from dictionary of connected devices

• Invokes the mock device’s Unsubscribe function with the given callback

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

Glossary