Re: Battery Status Event Spec

Anssi Kostiainen wrote:
> On 6.4.2011, at 16.54, ext Rich Tibbett wrote:
>
>> Frederick.Hirsch@nokia.com wrote:
>>> Can't your battery be at 20% even when plugged into the power source,  and wouldn't it be useful to be able to know that (even when plugged in)?
>> Do you have a use case for this particular scenario?
>>
>> The battery information only becomes critical once the device is unplugged from the mains. An event would then immediately fire, saying, for example "You've got 20% and 2580 seconds until power down". A web app could then respond accordingly to that information and a user could respond to however a web app manifests that information by plugging their device back in to the mains or e.g. wrapping up their session / saving their current progress.
>
> How about this use cases: "Is it ok to unplug this device now and have x % or y mins left?"
>
> if (event.isCharging&&  event.level>  50) {
>    console.log('Unplug now and you have 50% left.');
> }
>
> In implementation supporting timeRemaining, a more useful version would be:
>
> if (event.isCharging&&  event.timeRemaining>  60*60) {
>    console.log('Unplug now and you have about one hour left.');
> }
>
> On 6.4.2011, at 15.58, ext Rich Tibbett wrote:
>
>> Rather than isBattery or isCharging, I'd prefer to remove these attributes. Instead we could change the spec to say that 'if the device is plugged in to a power source, the 'level' MUST be set to 100 and the timeRemaining MUST be set to Infinity'. If and when the device is unplugged, an event would fire, providing an updated timeRemaining attribute set to a non-Infinity value and an updated level attribute set to<= 100. For each subsequent move in those figures, a new event would fire (but when and how often should be left up to implementers).
>
> With the above examples in my mind and my developer hat on I can think of additional cases where isCharging would simplify the code a bit, e.g.:
>
> if (event.isCharging) {
>    // we're charging
> }
>
> instead of:
>
> if (event.level === 100&&  event.timeRemaining === Infinity) {
>    // we're charging
> }
>
> Functionally they're equivalent. So it's a matter of taste. But by dropping isCharging we would not be able to handle the two "Unplug now and ..." use cases described above.
>
> For isBattery there's at least one use case I can think of:
>
> if (event.isBattery) {
>    // you're running on a battery so we'll disable the
>    // power-hungry feature z to save the battery
>    // (of course, you can enable z manually if you wish)
> }
>

The only absolutely locked-in, useful use case I see is the following:

if(event.level > 20) {
   // No problem!
} else {
   // you're running on low battery so we'll disable the
   // power-hungry feature z to save the battery
   // (of course, you can enable z manually if you wish)
   // + we'll step up the automatic saving of your ongoing
   // session just in case your machine dies mid-sentence.
}

Every other method or property is negotiable. I don't see the need to 
know which power source I'm currently connected to hence the proposal to 
remove isBattery and isCharging. In fact, I could infer that I'm 
connected to the wall if I don't receive any subsequent callbacks after 
an initial power source event has been fired (with event.level = 100).

Furthermore, it should be easy to produce a timeRemaining guesstimate 
based on event callbacks that don't contain this data. As an example, if 
an event starts at time t and I receive an event.level = 99 at t+180 
seconds and then an event.level = 98 at t+120 seconds and then an 
event.level = 97 at t+120 seconds I can make a guesstimate, via 
Javascript, that at time t+420 the machine is likely to remain 
responsive for the next 3 hours and 12 minutes at current battery 
consumption levels. There's little need to provide that data (and have 
two separate power level attributes) in the returned event itself.

Based on that, I'd propose to also drop the timeRemaining attribute, 
leaving only the 'level' attribute in an event callback.

Dzung's proposal to rename the event to PowerSourceEvent also makes a 
lot of sense for this also.

- Rich

Received on Friday, 8 April 2011 10:59:40 UTC