Re: Battery Status Event Spec

On Mar 30, 2011, at 19:03 , Anssi Kostiainen wrote:
> My proposal was to take the Power properties of SysInfo API as a starting point (because they're probably fairly well thought out) but apply them to the DOM Events -based model instead. The main benefits of the DOM Events-based model are re-usability and better integration to the web platform. This means we have to do some re-thinking, and we can not just simply split the existing spec into smaller pieces and be done with it.

Agreed. Reusing the thinking that was put into the modelling of these properties, and reusing other thinking that was put into DOM Events (and there's been quite a fair bit of that) seems to me like the best approach.

> 3) If there's a change in battery status, what is the granularity of a change?
> 
> Proposal: Come up with a reasonable default that is good enough for all the Power properties. The timeRemaining and isCharging properties are probably the ones requiring the finest granularity. Perhaps the resolution of say 1000 ms would be enough for all the Power properties for majority of the high value use cases? I propose we align with the model used by the DeviceOrientation and add an interval attribute to the BatteryStatusEvent: "The event must fire at regular intervals and the interval must be reported, in milliseconds, using the interval attribute of the BatteryStatusEvent object."

I'd like to suggest that this is a quality-of-implementation issue, and that we shouldn't try to specify it beyond stating that implementations ought to do their best to trigger events when a relevant change happens. I don't think that putting a specific value in the spec actually helps with interoperability, I think that implementors will likely try to make this API useful when they implement it, and finally I'm pretty sure that different hardware can call for very different granularity. For instance, when watching video on my phone a drop of 1% capacity is likely to happen rather often, whereas on the Kindle the battery only seems to run out at the beginning of a flight once every three or four months.

At any rate I don't think that 1000 ms is that great a value. For timeRemaining, I'd think 60000 ms would make most sense (you don't normally get a seconds countdown, that would be quite stressful :). As for isCharging, you only need to fire it when the device is plugged/unplugged. When that happens, I'd expect the event to trigger more or less immediately, but I wouldn't expect it to require regular updates (and if you're pulling the cable in and out continuously, well, you're being silly).

Maybe the best thing would be to provide some guidelines, maybe as SHOULDs?

   • UAs SHOULD dispatch an event when timeRemaining varies by a minute or more.
   • UAs SHOULD dispatch an event when isCharging or isBattery changes.
   • UAs SHOULD dispatch an event when level varies by a 1% or more.

-- 
Robin Berjon - http://berjon.com/

Received on Thursday, 31 March 2011 13:37:57 UTC