Re: Feedback about Battery Status Events

On Tue, Oct 18, 2011 at 7:34 AM, Anssi Kostiainen
<anssi.kostiainen@nokia.com> wrote:
>>>> Finally, the Battery Status Events specification introduces a 'status' attribute that can be 'ok', 'low' or 'critical' our implementation keeps that but we might be tempted to remove it. Indeed, from where the thresholds should come from? The Battery Status Events specifications say it should be left to the implementation but how can the implementation set sensitive values? Do battery internally have a 'low' indicator? In addition, even if the UA set the thresholds, they might not fit what applications are expecting. In that case, we should probably allow those applications to set them. However, that would be very similar than just listening to level changes and put the very simple logic in the event handler.
>>>
>>> The rationale for statuses was that not all batteries are equal and that the underlying platforms typically know better when the battery's level is low or critical, depending on the decay rate and other parameters. Mapping statuses to certain level thresholds may not be an optimal approach, but is a viable implementation strategy if the platform does not expose more than that. This issue was discussed at [1] and [5].
>>
>> I'm still not sure that I buy the value of ok/low/critical. If the UA
>> (or OS) knows that a battery decays faster towards the end, then it
>> should take that into account when exposing the battery level. I.e.
>> the battery level should represent how much battery time (mAh) is
>> left. Not the electrical potential difference or anything like that,
>> which would be affected by battery type etc.
>
> Do all the B2G backends expose battery time? If broadly supported this would indeed provide the best estimate for 'level', i.e.:
>
> level = 100 * (cur_battery_time / max_battery_time)
>
> It seems not all platforms provide this much, but I may be mistaken.

I suspect that none of the B2G backends will expose battery time :-).
But we can calculate it using the above formula if it exposes level.

The real question is

1. Are there platforms which expose "low"/"critical"/"ok", but that
don't expose battery time?
2. Do those platforms do any more complex logic rather than simply
compare the level to fixed values in order to figure out the status?

>>>> One solution would be to replace the 'plugged' ('charging' in our implementation) and 'status' attribute with a 'state' attribute that could be 'charging' or 'discharging' for the moment.
>>>
>>> It is possible that the battery depletes even if it is plugged in under heavy load if the charging currency is low enough. Should the design support such a corner case? If not, your proposal is simpler, and simpler is typically better, but we should make sure it is unambiguous.
>>
>> I think by having the 'level' property still available even when
>> .charging is true we're covering that case.
>
> That's true. I'll rename 'isPlugged' to 'charging' and change its semantics accordingly.

Just to be clear. I was expecting that if the device is plugged in
we'd always have "charging" returning true and "level" returning the
batteries current charge level.

This still allows the page to detect the situation when the device is
plugged in but still not accumulating charge due to heavy load since
it'd notice that the level is still decreasing.

Further, if we expose remaining time, the page would be able to notice
that it's non-infinite (or whatever other value we use to signal that
battery level won't run out).

>> * Make .level be a float between 0 and 1 instead. That tends to make
>> using it in math easier (the <progress> and <meter> elements have
>> similar APIs which go from 0 to 1).
>
> For <input type=range> the defaults for min and max are 0 and 100 respectively, but I don't have a strong preference here.

Range is just a generic number input mechanism. It doesn't go from a
conceptual 0% to a conceptual 100%. So I think it's less similar to
the .level property than HTMLProgressElement.progress.

/ Jonas

Received on Saturday, 22 October 2011 02:12:58 UTC