status-im/mobile
2
0
Fork 0
mirror of synced 2025-02-23 23:08:14 +00:00
Code Issues Packages Projects Releases Wiki Activity
mobile/exp/sensor/notmobile.go

25 lines
482 B
Go
Raw Normal View History

mobile/sensor: initialize the sensor package Sensors package will contain APIs to read data from a wide variety of movement, position and other physical signals. This CL contains the initial APIs that are targeting event-based sensors. Some of the concerns that influenced the APIs are: - Target game developers. Latency is critical, allow output rates up to ~10 samples per second. - It’s rarely possible to predetermine the minimally viable sample rate requirement of the app. - Allow users to set an upper bound rate to avoid garbage and preserve battery life. - Allow multiple instances of accelerometer, gyroscope, magnetometer and altimeter sensors to be started. Optimize the share of the underlying resources as long as it is not a bottleneck for the sample rate. - Prefer blocking APIs. An automatic poll-timeout could be useful if we’re far behind the sample rate. But, sensor initialization and waking-up significantly take longer and there is no easy way to determine a sensor is in either one of these states. - Provide timestamps for each event to determine the actual rate of the sensor data. - Allow user to return multiple events from each call. Buffering the events at the cost of additional latency is sometimes more neglectable than the overhead of a function call that polls the events one by one. Allow user to determine how many items they want to buffer. The typical latency of a read a single event is 56 usec. Reading 8-16 events at once has a relatively lower bound per event. For high precision throughput, the opportunity to minimize a function call overhead could be useful. - Allow users to check the sensor availability on the device. Change-Id: I9582c8f025d9f922d9635e247d60817f95bdacb9 Reviewed-on: https://go-review.googlesource.com/8174 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-27 14:53:09 -07:00
// Copyright 2015 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
exp/sensor: provide sensor events from the app event channel We are also limiting the number of sensor managers to one. The application provide sensor events to third-party packages by consuming them in the main. An application will be able to consume the sensor events similar to the other events. package main func main() { app.Main(func(a app.App) { // enables the accelerometer sensor.Enable(a, sensor.Accelerometer, 100*time.Millisecond) var sz size.Event for e := range a.Events() { switch e := app.Filter(e).(type) { case sensor.Event: log.Println(e) } } }) } Change-Id: Iaad1c59f8d2322c7620df62ed9b9283c91746fa8 Reviewed-on: https://go-review.googlesource.com/13983 Reviewed-by: Nigel Tao <nigeltao@golang.org>
2015-08-27 19:55:09 -07:00
// +build linux,!android darwin,!arm,!arm64 windows
mobile/sensor: initialize the sensor package Sensors package will contain APIs to read data from a wide variety of movement, position and other physical signals. This CL contains the initial APIs that are targeting event-based sensors. Some of the concerns that influenced the APIs are: - Target game developers. Latency is critical, allow output rates up to ~10 samples per second. - It’s rarely possible to predetermine the minimally viable sample rate requirement of the app. - Allow users to set an upper bound rate to avoid garbage and preserve battery life. - Allow multiple instances of accelerometer, gyroscope, magnetometer and altimeter sensors to be started. Optimize the share of the underlying resources as long as it is not a bottleneck for the sample rate. - Prefer blocking APIs. An automatic poll-timeout could be useful if we’re far behind the sample rate. But, sensor initialization and waking-up significantly take longer and there is no easy way to determine a sensor is in either one of these states. - Provide timestamps for each event to determine the actual rate of the sensor data. - Allow user to return multiple events from each call. Buffering the events at the cost of additional latency is sometimes more neglectable than the overhead of a function call that polls the events one by one. Allow user to determine how many items they want to buffer. The typical latency of a read a single event is 56 usec. Reading 8-16 events at once has a relatively lower bound per event. For high precision throughput, the opportunity to minimize a function call overhead could be useful. - Allow users to check the sensor availability on the device. Change-Id: I9582c8f025d9f922d9635e247d60817f95bdacb9 Reviewed-on: https://go-review.googlesource.com/8174 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-27 14:53:09 -07:00
package sensor
mobile/sensor: don't panic, return an availability error on non-android Change-Id: I42152d6fd5af220a780a6e3a288a97551ee53f39 Reviewed-on: https://go-review.googlesource.com/8413 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-04-02 15:42:08 -07:00
import (
"errors"
"time"
)
mobile/sensor: initialize the sensor package Sensors package will contain APIs to read data from a wide variety of movement, position and other physical signals. This CL contains the initial APIs that are targeting event-based sensors. Some of the concerns that influenced the APIs are: - Target game developers. Latency is critical, allow output rates up to ~10 samples per second. - It’s rarely possible to predetermine the minimally viable sample rate requirement of the app. - Allow users to set an upper bound rate to avoid garbage and preserve battery life. - Allow multiple instances of accelerometer, gyroscope, magnetometer and altimeter sensors to be started. Optimize the share of the underlying resources as long as it is not a bottleneck for the sample rate. - Prefer blocking APIs. An automatic poll-timeout could be useful if we’re far behind the sample rate. But, sensor initialization and waking-up significantly take longer and there is no easy way to determine a sensor is in either one of these states. - Provide timestamps for each event to determine the actual rate of the sensor data. - Allow user to return multiple events from each call. Buffering the events at the cost of additional latency is sometimes more neglectable than the overhead of a function call that polls the events one by one. Allow user to determine how many items they want to buffer. The typical latency of a read a single event is 56 usec. Reading 8-16 events at once has a relatively lower bound per event. For high precision throughput, the opportunity to minimize a function call overhead could be useful. - Allow users to check the sensor availability on the device. Change-Id: I9582c8f025d9f922d9635e247d60817f95bdacb9 Reviewed-on: https://go-review.googlesource.com/8174 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-27 14:53:09 -07:00
exp/sensor: don't enable a sensor on a sender The underlying implementation was not enabling the sensors on a particular sender even though the Enable signature accepts different instances of Sender to enable. Consider the following program: type A struct{} func (a A) Send(ev interface{}) {} type B struct{} func (b B) Send(ev interface{}) {} sensor.Enable(A{}, sensor.Gyroscope, time.Millisecond) sensor.Enable(B{}, sensor.Accelerometer, time.Millisecond) is going to compile but only A will be notified when there are new gyroscope and accelerometer events. In order to improve the misleading APIs, this CL introduces a Notify function that users can register a Sender implementation to listen the changes. If set nil, the sensor package will keep reading the events but will won't notify. sensor.Notify(A{}) sensor.Enable(sensor.Gyroscope, time.Millisecond) sensor.Enable(sensor.Accelerometer, time.Millisecond) Change-Id: I25e43349e4ae682930baa2d32430f46f24b588b7 Reviewed-on: https://go-review.googlesource.com/15650 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-10-09 11:30:18 -07:00
func enable(t Type, delay time.Duration) error {
mobile/sensor: don't panic, return an availability error on non-android Change-Id: I42152d6fd5af220a780a6e3a288a97551ee53f39 Reviewed-on: https://go-review.googlesource.com/8413 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-04-02 15:42:08 -07:00
return errors.New("sensor: no sensors available")
mobile/sensor: initialize the sensor package Sensors package will contain APIs to read data from a wide variety of movement, position and other physical signals. This CL contains the initial APIs that are targeting event-based sensors. Some of the concerns that influenced the APIs are: - Target game developers. Latency is critical, allow output rates up to ~10 samples per second. - It’s rarely possible to predetermine the minimally viable sample rate requirement of the app. - Allow users to set an upper bound rate to avoid garbage and preserve battery life. - Allow multiple instances of accelerometer, gyroscope, magnetometer and altimeter sensors to be started. Optimize the share of the underlying resources as long as it is not a bottleneck for the sample rate. - Prefer blocking APIs. An automatic poll-timeout could be useful if we’re far behind the sample rate. But, sensor initialization and waking-up significantly take longer and there is no easy way to determine a sensor is in either one of these states. - Provide timestamps for each event to determine the actual rate of the sensor data. - Allow user to return multiple events from each call. Buffering the events at the cost of additional latency is sometimes more neglectable than the overhead of a function call that polls the events one by one. Allow user to determine how many items they want to buffer. The typical latency of a read a single event is 56 usec. Reading 8-16 events at once has a relatively lower bound per event. For high precision throughput, the opportunity to minimize a function call overhead could be useful. - Allow users to check the sensor availability on the device. Change-Id: I9582c8f025d9f922d9635e247d60817f95bdacb9 Reviewed-on: https://go-review.googlesource.com/8174 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-27 14:53:09 -07:00
}
exp/sensor: remove the manager type The manager type is not required, because the APIs don't allow more than one event sources as they used to. In this CL, I am flattening out the underlying implementations by removing the manager type. Change-Id: I3b606ac160b9cecd85cb657e3df1d7d789604764 Reviewed-on: https://go-review.googlesource.com/14293 Reviewed-by: Nigel Tao <nigeltao@golang.org>
2015-09-04 00:17:01 -07:00
func disable(t Type) error {
mobile/sensor: don't panic, return an availability error on non-android Change-Id: I42152d6fd5af220a780a6e3a288a97551ee53f39 Reviewed-on: https://go-review.googlesource.com/8413 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-04-02 15:42:08 -07:00
return errors.New("sensor: no sensors available")
mobile/sensor: initialize the sensor package Sensors package will contain APIs to read data from a wide variety of movement, position and other physical signals. This CL contains the initial APIs that are targeting event-based sensors. Some of the concerns that influenced the APIs are: - Target game developers. Latency is critical, allow output rates up to ~10 samples per second. - It’s rarely possible to predetermine the minimally viable sample rate requirement of the app. - Allow users to set an upper bound rate to avoid garbage and preserve battery life. - Allow multiple instances of accelerometer, gyroscope, magnetometer and altimeter sensors to be started. Optimize the share of the underlying resources as long as it is not a bottleneck for the sample rate. - Prefer blocking APIs. An automatic poll-timeout could be useful if we’re far behind the sample rate. But, sensor initialization and waking-up significantly take longer and there is no easy way to determine a sensor is in either one of these states. - Provide timestamps for each event to determine the actual rate of the sensor data. - Allow user to return multiple events from each call. Buffering the events at the cost of additional latency is sometimes more neglectable than the overhead of a function call that polls the events one by one. Allow user to determine how many items they want to buffer. The typical latency of a read a single event is 56 usec. Reading 8-16 events at once has a relatively lower bound per event. For high precision throughput, the opportunity to minimize a function call overhead could be useful. - Allow users to check the sensor availability on the device. Change-Id: I9582c8f025d9f922d9635e247d60817f95bdacb9 Reviewed-on: https://go-review.googlesource.com/8174 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-27 14:53:09 -07:00
}
exp/sensor: remove the manager type The manager type is not required, because the APIs don't allow more than one event sources as they used to. In this CL, I am flattening out the underlying implementations by removing the manager type. Change-Id: I3b606ac160b9cecd85cb657e3df1d7d789604764 Reviewed-on: https://go-review.googlesource.com/14293 Reviewed-by: Nigel Tao <nigeltao@golang.org>
2015-09-04 00:17:01 -07:00
func destroy() error {
mobile/sensor: don't panic, return an availability error on non-android Change-Id: I42152d6fd5af220a780a6e3a288a97551ee53f39 Reviewed-on: https://go-review.googlesource.com/8413 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-04-02 15:42:08 -07:00
return nil
mobile/sensor: initialize the sensor package Sensors package will contain APIs to read data from a wide variety of movement, position and other physical signals. This CL contains the initial APIs that are targeting event-based sensors. Some of the concerns that influenced the APIs are: - Target game developers. Latency is critical, allow output rates up to ~10 samples per second. - It’s rarely possible to predetermine the minimally viable sample rate requirement of the app. - Allow users to set an upper bound rate to avoid garbage and preserve battery life. - Allow multiple instances of accelerometer, gyroscope, magnetometer and altimeter sensors to be started. Optimize the share of the underlying resources as long as it is not a bottleneck for the sample rate. - Prefer blocking APIs. An automatic poll-timeout could be useful if we’re far behind the sample rate. But, sensor initialization and waking-up significantly take longer and there is no easy way to determine a sensor is in either one of these states. - Provide timestamps for each event to determine the actual rate of the sensor data. - Allow user to return multiple events from each call. Buffering the events at the cost of additional latency is sometimes more neglectable than the overhead of a function call that polls the events one by one. Allow user to determine how many items they want to buffer. The typical latency of a read a single event is 56 usec. Reading 8-16 events at once has a relatively lower bound per event. For high precision throughput, the opportunity to minimize a function call overhead could be useful. - Allow users to check the sensor availability on the device. Change-Id: I9582c8f025d9f922d9635e247d60817f95bdacb9 Reviewed-on: https://go-review.googlesource.com/8174 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2015-03-27 14:53:09 -07:00
}
Reference in New Issue Copy Permalink