for event dispatching and handling, x/mobile/exp/sensor package may
benefit from similar APIs.
Having multiple instances of sensor.Manager has a performance cost
both on Android and iOS. Rather than allowing users to create multiple
sensor data resources (managers), we can switch to a global single
manager whose events will be consumed by the main package.
Given the constraints above, the changes I am planning to make are below.
- Manager type should not be exported, a Manager instance should be
initiated at package init.
- sensor package should keep providing Enable/Disable functions to
turn on/off which sensor data must be provided from the channel.
- We don't need to deallocate the global Manager instance.
(*Manager).Close is not required anymore.
- sensor events should have their own event types under the
- Events could be sent to the app events channel via app.Send. Due to
the high frequency nature of the sensor data, using the main app event
channel might be a bottleneck. Alternatively, the sensor package can
export its own channel but we must figure out how to disable the cases
where there are multiple consumers.
The current implementation constraints and how it influenced the
current APIs is explained more in detail at my previous design doc,
With the removal of the Reader-like interfaces, we are taking the
oppurtunity to optimize the read rate against the cgo overhead. We
won't be able optimize the number of values we must return each time
we go from Go to C.
Unlike Android NDK, iOS SDK doesn't provide queue based event
buffering. CMMotionManager provides two APIs to read accelerometer
data: `startAccelerometerUpdatesToQueue:withHandler:` and
`accelerometerData`. We either can buffer the event data to an
intermediate buffer as startAccelerometerUpdatesToQueue is invoking
the handler and consume the buffer to send events to the event channel
or periodically poll accelerometerData to see if there is new data.
The initial suggestion may lead to an ever growing buffer if the
consumers stop or work at a low rate. The latter solution might be CPU
intensive and battery draining if we can't optimize how often we
should do the check. Enabling sensors (see the current
(*Manager).Enable) requires users to set a target frequency. As a
primitive solution, we can use this value to sleep between reads.
I am also not sure what should happen if the user is not consuming the
events channel. Should it be ever growing?
I am looking forward to see your input and will be working on a
working prototype to gather benchmarks.
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.