RE: Publishing System Information API FPWD

Taking all input in account it seems as:

- Only one use case has yet been identified, i.e. detecting whether the device is close to the user's face/ear or not in order to be able to disable touch screen and/or shut display light off.

- Some types of sensors might be able to report a distance and some are only able to state "close" or far".

- Suggested to support both "front" and "back" sensors".


Should we make it simple in the first version of SysInfo by just adding?

- A parameter to specify if the proximity sensor is front or back
- A max range attribute. For proximity sensors only supporting a binary "close" or "far" measurement the sensor should report its max range value in the "far" state and a value less than max range in the "near" state. This would be analogue to Android. 

This would cover the most basic use cases. 

Claes
 

> -----Original Message-----
> From: Max Froumentin [mailto:maxfro@opera.com]
> Sent: måndag den 1 februari 2010 11:51
> To: Thomas Roessler
> Cc: Tran, Dzung D; Nilsson, Claes1; 'Robin Berjon'; public-device-
> apis@w3.org
> Subject: Re: Publishing System Information API FPWD
> 
> On 29/01/2010 19:02, Thomas Roessler wrote:
> > On 29 Jan 2010, at 18:57, Tran, Dzung D wrote:
> >
> >> place away from where you would hold the device. On mobile phone
> >> the proximity sensor is usually in front, but that does not
> >> precluded a device from having one on the back. The one use case is
> >> that the proximity sensor is in the front screen and you hold it up
> >> to your face, the display goes dark to save power.
> >>
> >> I have suggested in my previous posting to add a parameter to
> >> specify if the sensor is front or back.
> >
> > Is "front" or "back" really the information we're looking for?
> >
> > Or is "display is obscured", "device is sitting on the table" and the
> > like the information we're after?
> >
> > It strikes me that for existing devices, we kind of know how to deal
> > with a proximity sensor that notices an obscured display.  Perhaps we
> > should leave it at that, and not introduce an API for an arbitrary
> > proximity sensor of which we don't actually know what it measures.
> >
> 
> Both iPhone and Android SDKs provide access to proximity sensor:
> - On the iPhone, the developer has access to a property called
> ProximityState, "a Boolean value indicating whether the proximity
> sensor
> is close to the user (YES) or not (NO)." Thus, the API hides how the
> proximity is measured (in particular the number of sensors) and what
> proximity they measure, letting the developer assume it's "front"
> proximity.
> 
> - On Android, the Sensor class provides the "Proximity sensor distance
> measured in centimeters (Note that some proximity sensors only support
> a
> binary "close" or "far" measurement). That is more information than the
> iphone (there can be more than one sensor) but again there is no
> information on what/where they measure. The device-agnostic programmer
> is left to their own devices (ha ha, I couldn't resist...) as to
> guessing what proximity is reported.
> 
> So neither patform solves our problem of how to know what proximity the
> sensor measures, but they provides values regardless although as a
> result the use cases become very limited.
> 
> Max.

Received on Monday, 1 February 2010 15:55:49 UTC