- From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- Date: Mon, 11 Apr 2011 16:00:50 +0300
- To: ext Suresh Chitturi <schitturi@rim.com>
- CC: <public-device-apis@w3.org>
Hi, On 8.4.2011, at 22.10, ext Suresh Chitturi wrote: > On 6.4.2011, at 16.46, ext Suresh Chitturi wrote: > >> Thanks for the Editor's draft. >> I like the approach here based off of the events model but wondering > if >> there should be an alternate way as well such as the one shot API. >> The idea is specify a core interface with battery info that can be > used >> by event model and navigator implementations to allow for >> flexibility/choice for implementations and developers. > > > I added an example how to assign a function expression (aka anonymous > function) to the onbatterystate property. It provides a simpler (in > terms of loc) alternative. Do you think that would satisfy your concern > re flexibility/choice? > > My concern re exposing this information on navigator is that it makes > the misuse easier (think using setInterval() with a 1 ms delay to poll > the properties). > > Suresh>> This alternative works for me Anssi, however, I was just > looking for a way to minimize the event generation and let the > developers poll for this info as needed...perhaps battery status change > occurs too often compared some other properties. I believe the events-based model is a better fit for the battery status for the reason you mention above. I will not include the navigator proposal in the spec at this point if you're fine with that. That said, we can re-evaluate your proposal later on if we find evidence that the events-based model does not cut it. -Anssi
Received on Monday, 11 April 2011 13:00:57 UTC