Expose interface callbacks as C# events in idiomatic wrappers (Managed-OSVR)

[JeroMiya]

Moved from here:
OSVR/OSVR-Unity#17

This issue is specifically for Managed-OSVR interface wrappers:

Events in .net are the idiomatic way to implement the pattern we are using over the raw registerSubscriber* functions from the native code. The editor (at least in visual studio) has explicit support for creating callbacks of the right type for an event. For example, if you typed interface.PoseReported += then visual studio's intellisense would have an auto-complete option to create a callback that has the correct arguments for the type of event delegate that PoseReported is using. Very easy and convenient. It's also easy to unsubscribe - you just call interface.PoseReported -= game.PoseReportHandler.

We could go two ways in terms of defining the events. One way, we use custom event add/remove accessors, and call into the native callback registration code the first time someone subscribes to the event, i.e. on demand. Also, clean up any subscriptions when the last subscriber is removed. This requires a lot of bookkeeping and boilerplate code.

The second way is to use plain events (compiler generates accessors), and then have functions that 'activate' the callbacks. For example, you could subscribe to the PoseReported event, but the event wouldn't be fired until you called Start(), or maybe StartPoseReports(), along with a Stop()/StopPoseReports() method. The Start and Stop methods would handle calling into the native api to register a callback, or clean up the callback when Stop is called. Only one callback would be needed for each event (the event has its own invocation list, which also handles unsubscribe).

Custom event add/remove function reference:
https://msdn.microsoft.com/en-us/library/bb882534.aspx

[JeroMiya]

This is in progress. I will be implementing this issue at the same time, as they are related:
#1

[JeroMiya]

Status update - I have an implementation for this here (work in progress - feedback welcome):
JeroMiya@934d583

I need to add samples for the state APIs and the interface adapter.

Question/Discussion:
Do we still need an Interface class that has all the register_Callback functions, or do we just need the separate classes? I didn't add the full set of state API methods to Interface - instead they are exposed in the wrappers (e.g. PositionInterface.GetState). However, if they are still needed (for example, as they are used in the Tracker sample with one Interface object and multiple calls to register_Callback for different report tyeps), then I should probably add a corresponding list of Get*State methods in Interface, not just the wrapper classes.

However, I got the impression from the C++ state API wrapper issue that separate classes per report/state type was more desirable. If going in that direction, I would have removed the methods from Interface and made it the base class for the other interface types instead of a new InterfaceBase class (an earlier version of my code above went in this direction, until I noticed the TrackerCallback sample).

[JeroMiya]

This issue has been implemented. Closing.