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

> So, what I agreed with jonas about was a new event that only fired when there was a transition between near and far.  device proximity for something that was more advanced.  <insert this new event name here> for something really simple. 

> Thoughts?

What I am afraid of is that browsers going to interpret far versus near differently on the same device. I rather to give the control to the programmer to interpret base on value, min, max.

Thanks
Dzung Tran


-----Original Message-----
From: Doug Turner [mailto:dougt@mozilla.com] 
Sent: Wednesday, May 09, 2012 2:02 PM
To: Marcos Caceres
Cc: Anssi Kostiainen; public-device-apis@w3.org public-device-apis@w3.org
Subject: Re: [sensors] Device Proximity (was: Device light and proximity sensor)


On May 9, 2012, at 1:56 PM, Marcos Caceres wrote:

> 
> 
> 
> 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)  
> if(e.near){
>   //Woops! lets pause the game!  
>   game.pause();
>   return;
> }
> //otherwise, lets party on!  
> game.resume();


So, what I agreed with jonas about was a new event that only fired when there was a transition between near and far.  device proximity for something that was more advanced.  <insert this new event name here> for something really simple. 

Thoughts?

Received on Wednesday, 9 May 2012 21:14:10 UTC