Re: Ambient light API redesign

"new Sensor.." does not sound natural in the context of sensors. There is
only one sensor per browser so it doesn't seem great to have multiple
objects for the same sensor. Furthermore having a promise for value of
high-frequency sensors does not seem efficient. Instead we could register
once (using a promise) and then the data should be accessible
'synchronously' (with a possible sensor sampling delay of course). Having a
promise also means we can reject it if the sensor is not available..

So how about something like this:
(taking Device Orientation API as example)

enum SamplingFrequencyType {
 "low",
 "normal",
 "high"
};

partial interface Navigator {
 Promise<DeviceOrientationSensor>
getDeviceOrientationSensor(SamplingFrequencyType);
};

interface Sensor : EventTarget {
 readonly attribute double samplingFrequency;
 attribute EventHandler onchange;
};

interface DeviceOrientationSensor : Sensor {
 readonly attribute OrientationData currentOrientation;
 DOMMatrix getCurrentOrientationAsRotationMatrix();  // by means of example
};


Example 1:

function sensorSuccess(sensor) {
 console.log(sensor.currentOrientation);
 sensorManager.addEventListener(‘change’, function() {
     console.log(this.currentOrientation);
 });
}

function sensorFailed() {
 console.log(“failed to obtain orientation sensor”);
}

navigator.getDeviceOrientationSensor(“high”).then(sensorSuccess,
sensorFailed);


Example 2 (using requestAnimationFrame):

var sensor = null;
function updateFrame() {
  window.requestAnimationFrame(updateFrame);
  if (sensor)
    console.log(sensor.currentOrientation);
  // do something else
}

navigator.getDeviceOrientationSensor(“high”).then(
  function(orientationSensor){ sensor = orientationSensor; },
  function() { console.log("error"); });

window.requestAnimationFrame(updateFrame);


thanks,
Tim


On Mon, Sep 1, 2014 at 7:45 PM, Rick Waldron <waldron.rick@gmail.com> wrote:

>
>
>
> On Fri, Aug 29, 2014 at 10:10 AM, Rick Waldron <waldron.rick@gmail.com>
> wrote:
>
>>
>>
>>
>> On Fri, Aug 29, 2014 at 7:05 AM, Tobie Langel <tobie.langel@gmail.com>
>> wrote:
>>
>>> On Tue, Aug 26, 2014 at 11:17 PM, Marcos Caceres <marcos@marcosc.com>
>>> wrote:
>>>
>>>> We are actually discussing this on Twitter right now. It seems you don'
>>>> t need the promise. The constructor causes the subscription to the
>>>> sensor, and then you can potentially just observe `.value` until it
>>>> gets updated.
>>>
>>>
>>> How do you handle permissioning with that model?
>>>
>>
>>> More precisely, how do you handle cases when access is refused?
>>>
>>
>> For the instances: "onerror" with an appropriately named event.type or
>> event.data
>>
>> For the currentValue promise: reject and allow the program to handle the
>> rejected promise
>>
>
> When applied to a Battery sensor, the word "current" becomes ambiguous, so
> I've updated the proposal sketch to `requestValue()` (replacing
> `currentValue()`). https://github.com/rwaldron/sensors
>
> Rick
>
>
>
>