Generic Sensor API: https://w3c.github.io/sensors/
Ambient Light Sensor API: https://w3c.github.io/ambient-light/
Generic Sensor API: https://github.com/w3ctag/spec-reviews/issues/110
Ambient Light Sensor API: https://github.com/w3ctag/spec-reviews/issues/115
The Generic Sensor API defines a framework for exposing MEMS sensors to the Open Web Platform in a consistent way. It does so by defining a blueprint for writing specifications of concrete sensors along with an abstract Sensor interface that can be extended to accommodate different sensor types (such as a gyroscope, magnetometer, or an altimeter). The AmbientLightSensor is the first concrete implementation of a sensor in terms of the Generic Sensor API. More will follow.
Currently, not all MEMS sensors available on a device are exposed to web applications while those are readily available to native apps. This incentivizes developers to pick native solutions where web applications would have been a better choice.
In the cases where such sensors are exposed to the web (for example through the DeviceOrientation or DeviceLightEvent APIs), the APIs are inconsistent, don’t meet key use-cases, and are generally too high-level (and thus in opposition to the spirit of the Extensible Web Manifesto).
This new API addresses these concerns, those brought up by W3C TAG in the Sensor section of the Extensible Web Report Card and issues specific to the DeviceLightEvent such as not providing a value until a change causes the devicelight event to fire.
Overall, this API lowers developers’ cognitive load by offering a consistent API across sensors, makes it simpler and faster to specify and implement new sensors (such as barometers/altimeters which are now appearing on high-end devices) and opens up a number of uses cases by providing lower-level access to the sensors.
Interoperability and Compatibility Risk
Firefox: shipped DeviceLightEvent. Positive public signals for moving to Ambient Light Sensor.
Edge: has implemented DeviceLightEvent. Positive public signals for moving to Ambient Light Sensor.
Safari: No negative signals.
Ongoing technical constraints
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
OWP launch tracking bug
Link to entry on the feature dashboard
Requesting approval to ship?
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Based on feedback we’ve received from initial review for the patches that Riju sent and constraints that were identified by Alex Russel and Tim Volodine (e.g., subclassing, addition of new sensor types, managing different sensor configurations, etc), we’ve created design for Generic Sensor API and implemented prototype that is based on it.
The proposed design provides:
Sharing code between the concrete sensor implementations (for example: adding a new sensor on Android requires ~30 loc on platform side and ~150 loc on blink side). This reduces the code duplication and also simplifies maintenance of the newly added code.
Support for multiple JS Sensor instances that can have different configurations and life-time.
Support for both “slow” sensors that provide periodic updates (e.g. AmbientLight, Proximity), and “fast” streaming sensors that have low-latency requirements for sensor reading updates (Gyroscope, LinearAcceleration).
Please find class and sequence diagrams for the intended design in the attachment.
Comments and questions are welcome.
Best regards,Alexander Shalamov