W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2012

Re: [sensors] Device Proximity (was: Device light and proximity sensor)

From: Marcos Caceres <w3c@marcosc.com>
Date: Wed, 9 May 2012 21:56:34 +0100
To: Doug Turner <dougt@mozilla.com>
Cc: Anssi Kostiainen <anssi.kostiainen@nokia.com>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <3E54ABE0E229461F92CEBB543A90AFC6@marcosc.com>

On Wednesday, May 9, 2012 at 9:41 PM, Doug Turner wrote:

> Hi Marcos,
> > readonly attribute boolean near;  
> >  
> > or  
> >  
> > enum Proximity { "far", "near" };
> > readonly attribute Proximity proximity;  
> Jonas asked me about this too. With high resolution proximity sensors defining what far and near mean is going to be difficult. I argued that if you have the min, max, value, and resolution you wouldn't need this.
I'm worried that this is deferring the problem to developers to work out what the threshold is (and this is going to be unnecessarily confusing and could lead to unnecessary events being fired). Also, high resolution sensors have a limited distance/range, which means they are either triggered or not (i.e., far/near still applies). Do we have any examples of high-res sensors in devices to which this API is targeting? And what is the use case for high-resolution proximity sensor data if their range is only limited? I'm not saying there is no use case, just wondering what it is and if that we don't return some data just because we can - without fully addressing the primary use case of "is the phone really close to the user's face" as best we can.  

Having said that, even if we keep min, max, value, then a proximity attribute is still really handy because you don't need to do too much thinking:

function proximityChecker(e)  
   //Woops! lets pause the game!  
//otherwise, lets party on!  


> > Lastly, there does not currently appear to be any normative text saying that the UA must only turn on the proximity sensor upon event registration (would suck if the sensor came on every time I open the browser, as it would just eat battery).
> implementation detail. it doesn't need to be spec'ed out.
Ok, I can live with that :)   
> > Also, it might be good to have a bit of text describing what happens when you switch tabs in a browser (i.e., stop the sensor)… common sense stuff, I know… :)  
> UA policy. Happy with it as non-normative text, but lets not dictate this in the spec.  

Can live with that too:)   

Marcos Caceres
Received on Wednesday, 9 May 2012 20:57:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:53 UTC