- listener
- A Android.Hardware.ISensorEventListener object that will receive the sensor events. If the application is interested in receiving flush complete notifications, it should register with Android.Hardware.ISensorEventListener instead.
- sensor
- The Android.Hardware.Sensor to register to.
- rateUs
- The desired delay between two consecutive events in microseconds. This is only a hint to the system. Events may be received faster or slower than the specified rate. Usually events are received faster. Can be one of SensorManager.SENSOR_DELAY_NORMAL, SensorManager.SENSOR_DELAY_UI, SensorManager.SENSOR_DELAY_GAME, SensorManager.SENSOR_DELAY_FASTEST or the delay in microseconds.
- maxBatchReportLatencyUs
- An event in the batch can be delayed by at most maxBatchReportLatency microseconds. More events can be batched if this value is large. If this is set to zero, batch mode is disabled and events are delivered in continuous mode as soon as they are available which is equivalent to calling SensorManager.RegisterListener(ISensorEventListener, Android.Hardware.Sensor, Android.Hardware.Sensor).
Documentation for this section has not yet been entered.
Enables batch mode for a sensor with the given rate and maxBatchReportLatency. If the underlying hardware does not support batch mode, this defaults to SensorManager.RegisterListener(ISensorEventListener, Android.Hardware.Sensor, Android.Hardware.Sensor) and other parameters are ignored. In non-batch mode, all sensor events must be reported as soon as they are detected. While in batch mode, sensor events do not need to be reported as soon as they are detected. They can be temporarily stored in batches and reported in batches, as long as no event is delayed by more than "maxBatchReportLatency" microseconds. That is, all events since the previous batch are recorded and returned all at once. This allows to reduce the amount of interrupts sent to the SoC, and allows the SoC to switch to a lower power state (Idle) while the sensor is capturing and batching data. Note: Don't use this method with a one shot trigger sensor such as Sensor.TYPE_SIGNIFICANT_MOTION. Use SensorManager.RequestTriggerSensor(TriggerEventListener, Android.Hardware.Sensor) instead.
Registering to a sensor in batch mode will not prevent the SoC from going to suspend mode. In this case, the sensor will continue to gather events and store it in a hardware FIFO. If the FIFO gets full before the AP wakes up again, some events will be lost, as the older events get overwritten by new events in the hardware FIFO. This can be avoided by holding a wake lock. If the application holds a wake lock, the SoC will not go to suspend mode, so no events will be lost, as the events will be reported before the FIFO gets full.
Batching is always best effort. If a different application requests updates in continuous mode, this application will also get events in continuous mode. Batch mode updates can be unregistered by calling SensorManager.UnregisterListener(ISensorEventListener).