WLT+ASA: Overview of supporting software
IBinder - binding SpacePins to Azure Spatial Anchors
The IBinder interface is at the center, implemented here by the SpacePinBinder class. The SpacePinBinder is a Unity Monobehaviour, and may be configured either from Unity's Inspector or from script.
Each IBinder is named, so a single IBindingOracle can manage bindings for multiple IBinders.
IPublisher - reading and writing spatial anchors to the cloud
The IPublisher interface handles publishing spatial anchors to the cloud, and then retrieving them in later sessions or on other devices. IPublisher is implemented here with the PublisherASA class. Pose data in the current physical space is captured and retrieved using Azure Spatial Anchors.
When a spatial anchor is published, a cloud anchor ID is obtained. This ID may be used in later sessions or on other devices to retrieve the cloud anchor's pose in the current coordinate system, along with any properties stored with it. The system always adds a property identifying the cloud anchor's associated SpacePin.
It should be noted that the IPublisher, and the PublisherASA, don't know anything about SpacePins. IPublisher doesn't know or care what will be done with the cloud anchor data. It provides a simplified awaitable interface for publishing and retrieving cloud anchors.
Read versus Find
If a cloud anchor's ID is known, the cloud anchor may be retrieved by its ID. This method is the most robust way to retrieve a cloud anchor. The method is Read.
However, there are interesting scenarios in which the IDs for the cloud anchors within an area aren't known by a device, but if they cloud anchors could be retrieved, their spatial data and properties would combine to provide enough information to make them useful.
Find searches the area around a device for cloud anchors, and returns any that it was able to identify. This process is known as coarse relocation.
IBindingOracle - sharing cloud anchor IDs
The IBindingOracle interface provides a means of persisting and sharing bindings between SpacePins and specific cloud anchors. Specifically, it persists space-pin-ID/cloud-anchor-ID pairs, along with the name of the IBinder.
The oracle's interface is extremely simple. Given an IBinder, it can either Put the IBinder's bindings, or it can Get them. Put stores them, and Get retrieves them. The mechanism of storage and retrieval is left to the implementation of the concrete class implementing the IBindingOracle interface.
This sample implements possibly the simplest possible IBindingOracle, in the form of the SpacePinBinderFile class. On Put, it writes the IBinder's bindings to a text file. On Get, it reads them from the text file (if available) and feeds them into the IBinder.
ILocalPeg - blob marking a position in physical space
The ILocalPeg interface is an abstraction of a device local anchor. In a more perfect world, the required ILocalPegs would be internally managed by the IPublisher. However, device local anchors work much better when created while the device is in the vicinity of the anchor's pose. The IPublisher only knows where the device local anchors should be placed when they are needed, not at the optimal time of creating them.
The SpacePinASA does know when the best time to create its local anchor is. When the manipulation of the SpacePin ends and its pose set, the SpacePinASA requests the IPublisher to create an opaque local peg at the desired pose. The SpacePinBinder then pulls the ILocalPeg off the SpacePinASA, and passes it to the IPublisher to be used in creating a cloud spatial anchor.