Re: Feedback about Battery Status Events

On Thu, Oct 20, 2011 at 12:13 PM,  <Cathy.Chan@nokia.com> wrote:
>
>> On Tue, Oct 18, 2011 at 1:57 AM, Mounir Lamouri <mounir@lamouri.fr>
>> wrote:
>> > On 10/18/2011 01:15 AM, Jonas Sicking wrote:
>> >>
>> >> I think the idea was to return null on devices which don't use
>> >> battery at all. On my desktop machine there is no way I'm going to
>> >> hot plug a battery and start carrying it away (I probably wouldn't
>> >> get past the downstairs security guards anyway, despite 5 years of ice
>> hockey).
>> >
>> > And how can you know that? Do we have a sure way to know if a system
>> > is a laptop or a desktop? Off hand, I would say a desktop doesn't have
>> > a battery and a laptop has one... I don't see how to differentiate a
>> > desktop with a battery-less laptop. In addition, it might increase the
>> > risk of fingerprinting with a desktop returning null and a laptop
>> > returning a BatteryManager with level=1.0 and state="charging".
>>
>> It's possible that we can't tell the difference yeah. In which case we
> should
>> return a object with level=1.0 and .charging=true (or .state="charging" or
>> whatever we agree on is the method for indicating being plugged in).
>>
>> What I was thinking was that if we *know* that it's a device that can't
> have
>> battery, we should return null for .battery.
>>
>> However, the more I think about it, it's bad if the edge case is that
> .battery
>> doesn't exist, since that means that script will come to depend on it
> existing
>> and throw when it doesn't.
>>
>> So I'm sold on the idea of .battery existing and returning "full charge
> and
>> charging" state when we can't find battery information.
>>
>> >> On a device which has battery, but where one isn't currently plugged
>> >> in it seems appropriate to return 0 for level of charge and true for
>> >> charging. If a battery which is charged to 50% is plugged in simply
>> >> change the charge level to 50% and fire the appropriate events.
>> >
>> > It would be probably be better to have level=1.0 and state="charging"
>> > when the battery is removed. That way, script will not disable stuff
>> > thinking the device power is low.
>>
>> I don't really have strong feelings either way. In a sense the battery is
>> completely empty since if you unplugged the cable the device would
>> immediately shut down.
>>
>> On the other hand the user is unlikely to do so, and instead more likely
> to
>> plug in a battery before unplugging the cable. So we don't really know
> what
>> the battery level is going to be once it actually matters.
>>
>> So I'm fine with going level=1.0 and charging=true here too.
>>
>
> In that case, when the user plugs in a battery (with whatever amount of
> juice remaining), he would see a drop in battery level from 1 to some
> value <1, which seems counter-intuitive.
>
> IMO if the device does not have a battery, level should be 0 (device will be
> dead if you pull the plug), chargingState should be charging (the web app
> can feel free to use full functionality without worrying about power),
> remaining should be 0 (in sync with the level).
>
> These values together, and the fact that they remain unchanged over time,
> can be used as an (almost consistent?) indication that the device does not
> have a battery, if that information is of interest to the web app.

I agree that it feels strange to return 1. This was my initial
reaction too. But if we look at it from the perspective of what is
likely to make webpages behave the way we'd want them to behave, then
I think it makes more sense to return 1.

I think it's most likely that pages will not keep this usage scenario
in mind. I.e. they are unlikely to think about the situation where the
device is plugged in but has no battery. Because of this it seems most
likely that their code will simply look like:

var battery = navigator.battery;
var animationsRunning = false;
battery.onlevelchange = function() {
  if (battery.level < 0.3 && animationsRunning) {
    stopAnimations();
    animationsRunning = false;
  }
  if (battery.level > 0.3 && !animationsRunning) {
    startAnimations();
    animationsRunning = true;
  }
}

If we made .level return 0 for such code when the battery isn't
plugged in but a power cable is, then the page would stop animations
to try to conserve power. This doesn't seem useful as no battery is
plugged in which could be drained.

Put it another way, returning 0 is much more likely to put
applications into low-power-consumption mode, which is entirely
unnecessary when no battery is plugged in.

But I agree that 0 is technically more correct. I just don't think
it'll have the effect we want.

/ Jonas

Received on Saturday, 22 October 2011 02:29:47 UTC