English | 中文 | Русский | Français

2,856 Posts served

8,606 Conversations started

Sensor Access in Your Web App

By Clayne Robison (Intel) (9 posts) on October 29, 2009 at 3:36 pm

You are a JavaScript programmer. You want to write an application that can access some really cool sensors on the client platform: accelerometer, gps, thermometer, compass, ambient light sensor, etc. There are different ways that such an API might show up. For example, to access temperature on the client, you might do this:

var t = device.thermometer.temperature;

or, it might look like this:

var t = device.get('thermometer', temperature);

If the accelerometer event and error handlers looked like this:

function handleMovement( accleration ) {
//do stuff
}

function handleError( accleration ) {
//do stuff
}

subscribing to events could either be

var watchId = device.movement.watchMovement( handleMovement, handleError, options);

or

var watchId = device.watch( 'movement', handleMovement, handleError, options );

In other words, You can either have a concrete API that has specific JavaScript syntax for each sensor's properties and events, or you can have a generic, dispatch-like API that is tied to a very specific ontology, vocabulary or list of acceptable values that can be used as parameters. Considering the vast range of sensors that might be included in the foreseeable future, the size of the API could be quite large and complex; alternatively, the API could be simple and the ontology could be complex.

The W3C Geolocation API uses the former; the W3C DCCI API and BONDI use the latter (here are the links to the DCCI and BONDI vocabularies).

All other advantages and disadvantages aside, which API style do you prefer?

Categories: Mobility, Uncategorized

Comments (3)

November 1, 2009 5:14 AM PST antiquus Total Points: 10 Registered User

This problem is similar to writing BSPs for embedded platforms. The critical notion is to not assume a system peripheral organization or composition. In other words, a pseudo-structure like device.thermometer.temperature implies that there is only one thermometer in the system. Therefore I think the second form is preferred, especially if the API returned a list instead of a single instance. The device.watch() function should be single-valued, though, and take a single-valued argument. In other words, device.watch() should be a property of the device itself (poor choice of identifier here). var t = device.accelerometer[0].acceleration; // assuming the first is the correct choice var watchId = t.watchMovement( etc. );

November 1, 2009 5:18 AM PST antiquus Total Points: 10 Registered User

I don't believe I just did that... :D The example should be... var t = device.get('thermometer',temperature); var watchId = t[0].watchMovement( etc. );

November 2, 2009 12:27 PM PST Clayne Robison (Intel) Total Points: 820 Status Points: 320 Brown Belt

I agree that flexibility is major benefit the dispatch-like API, as would be the simplicity of learning (and remembering) it. I also agree that attaching watch to the property to be watched is more logical and object oriented than passing in the name of the property being watched. Making watch() a single arg function could be challenging unless you want to make that argument an object/array. The main arg is the function to call when something's happened; the second arg would be the function to call when something wen't wrong, and the third arg could be a way to filter events by sample interval or value. But frankly, the filtering could take place inside the receiving function.

Trackbacks (0)

Leave a comment