W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2013

Re: Device API organization - request for use cases/rationale

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Thu, 17 Jan 2013 16:24:12 +0200
Cc: "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com>, ext Tobie Langel <tobie@fb.com>, "public-device-apis public-device-apis@w3.org" <public-device-apis@w3.org>
Message-Id: <94A28D00-2A86-44DE-92FC-7489B0888E02@nokia.com>
To: ext Rick Waldron <waldron.rick@gmail.com>
[+cc Tobie]

Hi Rick,

On 16.1.2013, at 0.57, ext Rick Waldron wrote:

[...]

> The use cases are the same use cases that any form of DeviceFoo event would have—the ability to write browser based programs that interact with device (mobile and desktop) sensors.

The new design does not enable any new use cases? If so, it may be difficult to motivate implementors to change their implementations.

I can think of one use case that your proposal would address better than the current one: how to get the current proximity if the device is completely stationary. In your proposal the state could be explicitly set when the sensor object is instantiated. In the current design this is an implementation detail ("The definition of granularity i.e. how often the event is fired is left to the implementation.").

> The rationale for shifting away from a single event interface attached to the Window to a constructed Sensor.Foo instance, that inherits from EventTarget and provides get-accessor properties for reading values, is that the latter isn't future hostile towards devices that might be built with more then one of any type of sensor.

API ergonomics aside, the current API could be extended to support multiple sensors too e.g. by adding an identifier attribute (the type and name to be defined) to the DeviceProximityEvent interface. We discussed this a while back but decided not to include it in v1 given devices supporting multiple proximity sensors were not shipping in volumes at that time, see:

  http://www.w3.org/2009/dap/wiki/FutureWork

Would adding such an attribute address your use cases?

> The iPhone 4s and 5 added an always-on infrared LED to the proximity sensor, that is used for "Raise to speak" detection, in addition to detecting your face during a call. This is only one example, but devices continue to evolve and become more sophisticated in their capabilities.

Is this exposed to 3rd party developers? I only see a "proximityState" boolean at [3]. Any other platforms supporting multiple proximity sensors?

[...]

Thanks for your feedback!

-Anssi

> [1] http://dev.w3.org/2011/webrtc/editor/getusermedia.html#handling-devices
> [2] http://developer.android.com/reference/android/hardware/Sensor.html
> [3] http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIDevice_Class/Reference/UIDevice.html
Received on Thursday, 17 January 2013 14:25:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:57 UTC