Re: Ambient light API redesign

On Mon, Sep 8, 2014 at 11:56 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:

> I think the proposal above would be better than having sensor.value
> sometimes returning null because it would at least be consistent as far
> as web developers are concerned. However, there is no direct synchronous
> access to the value.
>
> I think Tim's proposal is less elegant (ie. getDeviceOrientationSensor()
> is less elegant than new DeviceOrientationSensor()) but it solves all
> the requirements: it is an asynchronous API that is easy to use for
> developers because after it is initialized, they have direct access to
> the value.
>
> I would consider the cosmetic issue less important than developer
> friendliness.
>

Given the requestAnimationFrame use cases exposed by Rick, it seems that
obtaining the Sensor instance immediately is more developer friendly than
getting it through a resolved promise. Especially if numerous sensors need
to interact.

That said, only concrete examples (i.e. code) will allow choosing one API
over the other.

Also, keep in mind that there's always the promised base static API for
one-offs.

--tobie