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

Re: [proximity] does it have a proximity sensor?

From: Doug Turner <dougt@mozilla.com>
Date: Sun, 20 May 2012 11:14:10 -0700 (PDT)
To: Marcos Caceres <w3c@marcosc.com>
Cc: public-device-apis@w3.org
Message-ID: <799156888.1329465.1337537650343.JavaMail.root@mozilla.com>
This also feels like a conversation we have already had.

There really is no way to really know if the proximity sensor is going to return a value.  The proximity sensor might be present on a device, but never fire due to some hw bug or something.  The only real way you'll know is if you get some change in the sensor.

Similar to device orientation, motion, I do not want to have any "is device present" predicate in the API.  If someone wants to build something through System API that allows you to query for device sensors - that's what I'd do.

Doug

----- Original Message -----
From: "Marcos Caceres" <w3c@marcosc.com>
To: public-device-apis@w3.org
Sent: Sunday, May 20, 2012 5:15:08 AM
Subject: [proximity] does it have a proximity sensor?

I'm still a bit concerned that the API lacks a way to check if a device 
has a proximity sensor. Current generation of tablets do not contain 
proximity sensors because there is no use case for putting a tablet next 
to your head, and because of the way they are held: a user's hands would 
constantly be activating the sensor when switching to landscape/portrait 
because of the form factor. This means that a developer could save 
themselves a bunch of trouble (and potentially some memory) but not 
setting up event listeners and other code for devices that don't contain 
a proximity sensor. I also don't know of any tablets that intend to put 
alternative proximity sensors on devices (e.g., behind the screen) or 
that those proximity sensors won't have a clear use case that would 
warrant their own API (e.g., a stylus API).

I see two potential ways of checking for this (assuming we go with my 
previously proposed API changes)...

PROPOSAL 1. Making near attribute "near" attribute nullable

Example:
//check if we have a proximity sensor
if(navigator.proximity.near !== null) {
     //we are good to go...
}

Pros:
  * Piggy-backs on already required attribute;

Cons:
  * Slightly changes the semantics "near" (gives it two data types, 
which can kinda suck sometimes)

PROPOSAL 2. add a new attribute

Example:
//check if we have a proximity sensor
if(navigator.proximity.<hasSensor>) {
     //we are good to go...
}

Pros:
   * leaves "near" attribute alone.
   * has its own clean semantics.

Cons:
   * adds another attribute

Kind regards,
Marcos

-- 
Marcos Caceres
http://datadriven.com.au
Received on Sunday, 20 May 2012 18:14:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 20 May 2012 18:14:39 GMT