We discussed the various low-level interfaces for sensor drivers in a previous blog entry. Application level access to sensors occurs through an API normally provided by the operating system such as Android, iOS, or Windows 8. However, there is another alternative for developers interested in developing cross-platform apps: HTML5. Since web browsers are available in all mobile platforms, HTML5 provides a write-once deploy-many option for developers with a consistent user experience. Furthermore, alternative operating systems such as Tizen and Firefox OS are planning to leverage this language as well.
HTML5 is more than a web-only language. It also allows the browser to have access to local device resources, such as high performance audio and video, the ability to locally store assets offline, and sensors which is the focus here.
The sensor API as currently defined by the W3C supports DOM (document object model) events for device orientation, device motion, and whether the compass needs calibration:
- deviceorientation: provides events as Euler angles without the ability to access the underlying quaternion. Events are only provided when a “sufficient” change has occurred or the browser has determined that the last value used by the application is “stale”. The definition of “sufficient” and “stale” is browser-implementation-specific. (The W3C recommendation for sufficient change is one degree.) There is no way to access orientation confidence level or modify/query the change sensitivity threshold. Furthermore, when setting the “absolute” attribute to false the orientation is defined with respect to an arbitrary reference frame. The use case for this option seems limited, more likely leading to confusion for the developer.
- devicemotion: provides events for acceleration, accelerationIncludingGravity, rotationRate, and interval. The HTML5 spec is cloudy with regard to inclusion of effects of gravity and acceleration, leaving ways for cross-platform variations which would only hurt developers. If the effects of gravity cannot be removed, the browser is free to populate the acceleration attribute with an acceleration value that includes gravity (rather than null). This could lead to false assumptions by developers and code that may work on some browsers and platforms but not others. The interval is a constant containing the report sampling interval in milliseconds. There is no access to magnetometer or more useful virtual sensors such as altitude.
Although browsers claim HTML5 compatibility, our experience with sensor support is varied. Opera and the default Android browser support all the sensor aspects above, whereas Google Chrome on Android did not support rotationRate, and compatibility on Internet Explorer 10 required installation of experimental ActiveX components which lead to browser hang-ups. Given time, browser support for HTML5 should only improve. One way to accelerate adoption is developer interest in using sensors within browser apps to enable interesting consumer use-cases. Sample use-cases could be using device orientation to navigate e-commerce merchandise and context awareness virtual sensors such as Carry and Posture.