Cleaner approach to distributing CMSensorRecorder data

I've taken another path for handling accelerometer data.  Recall:

• CMSensorRecorder does continuous sampling, but the data visibility is slightly delayed
• WCSession.sendMessage requires both watch and iPhone apps to be active and in focus
• A Watch application's threads pretty much will not be scheduled when the watch is quiescent or another application is running
• The goal is to have an application running on the Watch that does not require continuous access to the iPhone -- instead, enqueuing data for later delivery
• Don't forget NSDate still can't be sent through WCSession... (until beta5?)

All of the above make it difficult to have continuous distribution of accelerometer data off the Watch. There still may be some technique for having a system level background thread using complications, notifications, etc. I haven't found it yet. So, for now, I will simply distribute the data when the application is running on the Watch.

Let's try WCSession.transferUserInfo() as the transfer mechanism. The flow on the Watch is roughly:

• CMSensorRecorder starts recording as before
• An independent dequeue enable switch will start a timer loop on Watch
• When the timer fires it will look for and enqueue any new batches of sensor data from the recorder

This works pretty well. Sensor data is recorded, a polling loop is fetching data from the recorder and queueing the data for send to the iPhone. Then, when the iPhone is reachable, the data gets sent and handled by the phone app.

Code is here.  Some screen shot examples are here:

The astute reader will notice the difference between batchNum and lastBatch above (835 vs 836). batchNum is the next batch we are looking for and lastBatch is the last batch handled.  I think this is a problem in the api -- basically my code needs to know that batch numbers monotonically increase so it can inclusively search for the next batch after what has been handled.  This seems to be a bit too much knowledge to expose to the user.  I suggest that the call to CMSensorRecorder.accelerometerDataSince(batchNum) should be exclusive of the batch number provided.  Or, add an optional parameter (inclusive, exclusive) to keep the API more or less compatible.

Next up:

• Getting on beta5 s/w stack (Xcode, iOS9, WatchOS2)
• Going back to attempt native object transfer from Watch to iPhone
• Moving the iPhone data receiver to a first class background thread
• Adding the AWS Cognito and Kinesis support for receiving sensor data