On 13/05/2012 21:46, Doug Turner wrote:
> I requested that we have this be optional since Firefox has already shipped without this attribute.
In WebIDL, you can't have an optional attribute… it's either defined in
the interface or it is not (though the attribute could always return null).
> I am pretty sure that this attribute is going to be troublesome and it is one of those things we can bike shed all day on. Hence, i think we should just punt and look at this issue after we have something wildly deployed and have reported problems with the API.
I would agree we were bike-shedding if we were talking about names or
similar; but here we are trying to figure out the fundamental design of
the API and what the use cases are. At the moment, the arguments that
being presented seems to be:
1. it's already implemented and shipping (as an experimental thing).
2. because we have that data (i.e., in Android), we can return it and
let devs figure it out.
3. talking about use cases/requirement wastes time (and doesn't help
the Web)... 0_o.
I'll note that we risk making the same mistakes that were made with the
Orientation API where it's extremely confusing to work with (alpha,
beta, gamma is are extremely confusing to developers - and just outright
bad design on the part of the Geolocation WG). See the following for
instance (fast forward to 25:00):
http://www.infoq.com/presentations/Hybrid-Mobile-Applications-using-PhoneGap
We've also experience problems in the W3C Tech course on Advanced Mobile
Development getting developers to grok alpha, beta, gamma. I worry that
we are repeating those mistakes again by dumping complexity on
developers unnecessarily.
And as has also been pointed out, on iOS, this proximity is just either
close or near… for example:
http://mobiledevelopertips.com/device/using-the-proximity-sensor.html
It's for this reason that I would encourage you to consider the more
limited approach of far and near. If people come back and say "look, we
really need to know the min, max, value for this really important use
case: …. ." Then we are cooking. I'm really worried that everyone will
just get confused and we will just end up with code like this:
if(e.value > e.min && e.value < e.max){
//value was random fluctuation :/
}
Or:
//Max sometimes happens to be +Infinity, as allowed by the spec
var percent = e.value / e.max;
if(percent < .8){
//oh, they must be pretty close
}
> However, if we do want to continue with this attribute, I think that we need to have normalized language around this def. or interopt is not going to happen.
Proposal:
Near: "Sensing the presence of a physical object with a
UA/OS/sensor-specific degree of confidence."
Far: "Not sensing the presence of a physical object with
UA/OS/sensor-specific degree of
confidence."
Another approach would be to scope this further to the use case and just
say its a: "UserProximityEvent".
So, the my personal ideal API would work like this:
if(navigator.userProximity){
//enables proximity sensing
navigator.userProximity.addEventLister("proximity", proximityCheck);
//event is "UserProximityEvent"
function ProxityCheck(event){
if(e.near === true){
doNearStuff();
return;
}
//otherwise, user is far…
doFarStuff();
}
//later... stop sensing:
navigator.userProximity.removeEventLister("proximity", proximityCheck)
}
And I still have a nagging feeling that one would will need:
navigator.userProximity.near;
--
Marcos Caceres
http://datadriven.com.au