- From: Marcos Caceres <w3c@marcosc.com>
- Date: Sun, 20 May 2012 13:15:08 +0100
- To: "public-device-apis@w3.org" <public-device-apis@w3.org>
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 12:15:40 UTC