Re: [battery] Alternative design proposal (was: addEventListener side effects, ordering & boundary crossing ...)

On Sep 9, 2011, at 15:02 , <Frederick.Hirsch@nokia.com> <Frederick.Hirsch@nokia.com> wrote:
> Does a laptop actually know there is no battery, or just that the battery level is zero (when the battery is physically removed)?

In my experience, yes. Most devices I've had which you could run plugged with the battery removed display a specific icon to indicate the battery's absence.

> yet another corner case, thanks for pointing it out :)

There's no such thing as a simple spec once reality gets involved ;)

> On Sep 9, 2011, at 8:27 AM, ext Josh Soref wrote:
>> Technically a device can go from:
>> Corded + no battery (laptop w/ battery removed)
>> To
>> Corded + battery (user inserts in preparation for travel)
>> To
>> Battery (user unplugs)
>> 
>> If an app inits once (likely), then returning null for the first case would yield bad results for the session lifetime

Right, I think that if the implementation supports the battery spec, it should always expose some information about battery — even when there is no battery to speak of. The question is how to represent this? Is {isPlugged: true, level: null } or {isPlugged: true, level: -1 } enough? Is it confusing? Should we add a hasBattery field, which would be weird but accurate?

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

Received on Monday, 12 September 2011 09:46:02 UTC