[proximity] extensions to navigator object

Hi,
I think the following extension to the Navigator interface might not be 
ideal:

partial interface Navigator {
readonly attribute DOMString proximitystate;
[TreatNonCallableAsNull]
attribute Function? onproximitystatechange;
};

1. Firstly, it does not follow the convention already established by 
Geolocation (and Battery API!): which uses an attribute that namespaces 
the API properly through an object.

2. Secondly, the interface above pollutes the Navigator object and sets 
a bad precedence for future sensors that might have multiple attributes 
(and would cause people to ask why the convention used with Battery and 
Geolocation were not followed). Other sensor might introduce even more 
attributes and handler types, which would make Navigator a real mess to 
look at. With correct namespacing, we cut down on the clutter by at 
least 50%.

3. Thirdly, it makes the interface slightly more annoying to use, 
because you need to log around "window.navigator.<sensornameProperty>" 
everywhere in your code.

4. Fourthly, "onproximitystatechange" is just way too long IMO.

I propose the following instead:

partial interface Navigator {
readonly attribute DeviceProximity proximity;
};

interface DeviceProximity : EventTarget {
readonly attribute Boolean near;
[TreatNonCallableAsNull]
attribute ProximityChange? onchange;
};
calllback ProximityChange = void(DeviceProximityEvent e)

And the event we listen for is just "change" instead of the really long 
"proximitystatechange".

Then, JS code looks like this:

if(navigator.deviceProximity){
var sensor = navigator.deviceProximity;
if(sensor.near){
//do awesome stuff….
}
sensor.onchange = function(e){
//oh yeah, I can handle that!
}
sensor.addEventListerner("change", function(e){ … } )
}

So, the above issues are addressed as follows:

1. We follow Geolocation's and Battery's lead by having a real object 
for proximity.
2. We reduce polluting Navigator with more stuff than we need to.
3. We make the interface easier to alias (and keep all its bits together).
4. We reduce "proximitystatechange" to just "change" (which follows 
conventions already used in HTML, like 'load', 'click', etc.).
5. We get an overall simpler, hopefully more friendly, API.

Kind regards,
Marcos

-- 
Marcos Caceres
http://datadriven.com.au

Received on Sunday, 20 May 2012 11:14:52 UTC