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

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

From: Robin Berjon <robin@berjon.com>
Date: Wed, 9 May 2012 18:04:32 -0700
Cc: Marcos Caceres <w3c@marcosc.com>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Message-Id: <33799BBF-7033-46F6-94FA-53B36185E164@berjon.com>
To: Doug Turner <dougt@mozilla.com>
On May 9, 2012, at 15:33 , Doug Turner wrote:
>>> So lets just create a new dom event as I suggested. Near and far are defined by the UA. Thoughts?  
>> 
>> I would be in support of that.  
> 
> Great.  Pick a name!  That is the hardest part.

How about just calling it "proximity" and see how the paint sticks to the shed?

>> I just thought that you might also need a way of checking if the phone is not already "in proximity" to something (e.g., through an attribute on the navigator object or something).  
>> 
>> if(!navigator.<name for in proximity>){
>>   //set the event listeners
>> }
>> userIsNear();  
> 
> I don't like attributes - some people do.  Attributes like this can be defined in the application logic.  Lets defer?

I agree with Marcos that there needs to be a way for the application to know if something's already close when it's launched. Here's a simple use case: I click a tel: link, and immediately press the device to my face. It's likely that I'll get it close to my ear before the dialer has done launching, so there will be no far-near transition to hang an event off of. It needs to know that when it starts. We could specify that the event triggers right after load, but that gets messy fast (especially if you have potentially slow, async initialisation code). Having an attribute solves that.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Thursday, 10 May 2012 01:04:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 10 May 2012 01:05:00 GMT