- From: Marcos Caceres <marcos@marcosc.com>
- Date: Tue, 26 Aug 2014 17:17:40 -0400
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>, Anssi Kostiainen <anssi.kostiainen@intel.com>, public-script-coord <public-script-coord@w3.org>, Doug Turner <dougt@mozilla.com>, Rick Waldron <waldron.rick@gmail.com>, Domenic Denicola <domenic@domenicdenicola.com>, Anne van Kesteren <annevk@annevk.nl>, Tobie Langel <tobie.langel@gmail.com>
On August 26, 2014 at 5:00:58 PM, Jonas Sicking (jonas@sicking.cc) wrote: > On Tue, Aug 26, 2014 at 2:43 AM, Anne van Kesteren wrote: > > > > Perhaps something like this: > > > > var as = new AmbientSensor() > > var currentVal = await as.value > > as.onvaluechange = ... > > Would as.value just return a Promise reflecting the first reading? And > after that it would quickly be outdated? If so that could potentially > be confusing. Or does the property return a new, immediately resolved, > Promise every time that onvaluechange fires? 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. It's initially set to null. IIUC, it means you don't need onvaluechange either. For very chatty sensors, an polling option might be passed with the constructor to control how often updates happen. If you don't want to subscribe (by creating an instance), you can do something like: ``` AmbientSensor.getCurrentValue().then(data => ... ) ``` Rick is capturing a lot of this here: https://gist.github.com/rwaldron/5016343
Received on Tuesday, 26 August 2014 21:17:58 UTC