Abstract Communications Interface
- Didier Lessage (Deactivated)
Introduction
The Abstract Communications Interface will provide a set of interfaces that serve as a layer between communicating with a device and the protocol used by said device. Device, as well as the DeviceManager classes, will utilize this communications interface and implement the details of their specific communications protocol internally. This interface will be utilized in both Windows and Android implementations of the Communications library.
Requirements
Software Requirements | 2. Communications
Related Jira Issues
https://unity3d.atlassian.net/browse/FNSDKEXT-100
https://unity3d.atlassian.net/browse/FNSDKEXT-78
Constraints
Performance
Similar to other interfaces dealing with communications to the VictoR device, asynchronous calls to the device will be made available from the interface.
OS Requirements
Two version of this interface will be built: one to support communications on Windows platforms and one for Android platforms.
Standardization
This interface defines the contract that any communication device or device manager built within the Victor SDK will follow.
Ease of Use
The interface will assist in abstracting away the details of a specific communications protocol.
Detailed Design
The abstract communications interface involves both the device manager, as well as an interface for the device being interacted with. Both the Windows BLE Interface and the Android BLE Interface will inherit from this abstracted interface to allow for a general means to interface with devices divorced from the communications protocol used by the device. The important functionality to expose to the user simply involves connection to the device and reading/writing to the device. As many of these calls will require asynchronous callbacks from the device in many common communications protocols, the interface defines a majority of these methods with asynchronous calls to allow for the continued execution of code when performing actions on the physical device. It is up to interfaces that derive from this base interface to provide additional functionality specific to their protocol.
System Interaction
The sequence diagram below illustrates an abstracted workflow for connecting to a device. Users can expect any device manager that uses the Device Manager interface will provide a means to begin a scan for devices. This scan can either be provided a callback for any devices found during the scan, or simply wait for a list of found devices to be provided at the end of a scan (the below diagram illustrates the first case). On finding several devices, a connect for one of the found devices is called on the Device Manager. This triggers a creation of an object implementing the Device interface with definitions for any communications protocol specific functionality. Once a successful connection has been made to the physical device, a task result of a bool is returned by the Device, which propagates back to the end-user application. Important items to make note of are that any asynchronous calls made within this sequence are illustrated by open arrows with solid lines, whereas dotted lines with open arrows illustrate the results of asynchronous tasks.
