Re: Publishing System Information API FPWD

But the use case argues only for a front sensor (i.e. facing the user). 
I'm not even sure we need a back sensor.


On 01/02/2010 16:55, Nilsson, Claes1 wrote:
> 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
>> [] Sent: måndag den 1 februari 2010 11:51
>> To: Thomas Roessler Cc: Tran, Dzung D; Nilsson, Claes1; 'Robin
>> Berjon'; public-device- 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 Tuesday, 2 February 2010 12:30:23 UTC