ISSUE-170: light levels are not retrievable until a change causes the devicelight event to fire.
light levels are not retrievable until a change causes the devicelight event to fire.
- State:
- CLOSED
- Product:
- Generic Sensor API
- Raised by:
- Frederick Hirsch
- Opened on:
- 2014-08-26
- Description:
- on behalf of Anne Van Kesteren
see http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0058.html
Mozilla bug report (see URL for discussion thread)
[[
The current event-based Ambient Light API has one limitation: light levels are not retrievable until a change causes the devicelight event to fire.
Scenario:
A newly loaded page wants to retrieve the ambient light levels.
Expected result:
The app can get the value from window.deviceLight or some such interface.
Actual result:
The app must wait until a devicelight event fires before receiving the light value. This could cause errant behavior on the part of the app, such as optimizing the interface for bright environments when it is actually dark.
]]
Anne's message:
In https://bugzilla.mozilla.org/show_bug.cgi?id=1057185 we discovered
that the current API for ambient lights is lacking and would require
hacks to addEventListener() to salvage. Since the API is not widely
adopted (only by Firefox per caniuse) we'd rather come up with a
better solution. Perhaps even establishing a pattern for how we should
expose hardware sensors to the web.
Perhaps something like this:
var as = new AmbientSensor()
var currentVal = await as.value
as.onvaluechange = ...
as long as you have a reference to the object or the object has a
listener attached it cannot be GC'd.
- Related Actions Items:
- No related actions
- Related emails:
- Re: [ambient-light] implementation and spec status update (from anssi.kostiainen@intel.com on 2015-05-29)
- Re: [ambient-light] implementation and spec status update (from waldron.rick@gmail.com on 2015-04-09)
- RE: [ambient-light] implementation and spec status update (from adrianba@microsoft.com on 2015-04-09)
- [ambient-light] implementation and spec status update (from anssi.kostiainen@intel.com on 2015-04-09)
- Draft minutes - 2014-12-11 teleconference (from w3c@fjhirsch.com on 2014-12-11)
- [admin] Agenda - DAP Distributed Meeting 11 December 2014 (from w3c@fjhirsch.com on 2014-12-09)
- [admin] Minutes (v3) from teleconference, 2014-11-13 (corrected) (from w3c@fjhirsch.com on 2014-11-18)
- [admin] Minutes (v2) from today's teleconference, 2014-11-13 (corrected) (from w3c@fjhirsch.com on 2014-11-13)
- [admin] Minutes from today's teleconference, 2014-11-13 (from w3c@fjhirsch.com on 2014-11-13)
- Re: [sensors] Ambient Light and the generic sensor API design (from mounir@lamouri.fr on 2014-10-03)
- [sensors] Ambient Light and the generic sensor API design (from anssi.kostiainen@intel.com on 2014-10-03)
- [admin] Agenda - DAP Distributed Meeting 2 October 2014 (from w3c@fjhirsch.com on 2014-09-30)
- [admin] Agenda - DAP Distributed Meeting 18 September 2014 (from w3c@fjhirsch.com on 2014-09-15)
- [admin] Draft minutes 2014-09-04 teleconference (corrected) (from w3c@fjhirsch.com on 2014-09-04)
- [admin] Draft minutes 2014-09-04 teleconference (from w3c@fjhirsch.com on 2014-09-04)
- [admin] Agenda - DAP Distributed Meeting 4 September 2014 (from w3c@fjhirsch.com on 2014-09-02)
- [light] Update - not requesting CR transition for Ambient Light given new implementer feedback (from w3c@fjhirsch.com on 2014-08-26)
- DAP-ISSUE-170: light levels are not retrievable until a change causes the devicelight event to fire. [Ambient Light Events API] (from sysbot+tracker@w3.org on 2014-08-26)
Related notes:
see also http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0060.html
[[
> How far are we in terms of getting the needed language-level improvements in ES? I guess await and friends is a ES7 feature?
Well promises are here now. The synchronous syntax sugar will come
later. I used it to show what the code will look like going forward.
Thinking about it some more it should probably be more something like
getValue() as we want to return a new promise each time.
> Also, this proposal supports N number of sensors of the same type (we can pass arguments to the constructor) -- something that the current API cannot do.
I suspect we probably still want a constructor per sensor for ease of
detection, but there could be a generic superclass.
]]
[fjh]: under discussion as part of generic sensor API discussion, http://lists.w3.org/Archives/Public/public-device-apis/2014Nov/att-0016/minutes-2014-11-13.html#item05
11 Dec 2014, 15:37:41Display change log