- 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
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 UTC