Re: Feedback about Battery Status Events

Hi,

On 18.10.2011, at 2.15, ext Jonas Sicking wrote:

> I'm not terribly worried about the case when the battery subsystem
> hasn't started yet. It seems unlikely that you'll have started
> applications (including browsers) quickly enough during device startup
> that the battery subsystem isn't up and running yet. Possibly I could
> see it happening if you are implementing the battery status UI which
> is rendered as part of the default device UI since that starts
> immediately on startup.
> 
> So while it can happen, it seems rare enough that we shouldn't worry
> too much about it. I think I prefer Mounir's suggestion to return 100%
> in that case. Any UI could be updated quickly enough anyway as soon as
> the battery subsystem is up and running, by simply firing the
> appropriate events and updating the status properties.
> 
> The advantage of returning 100% rather than null is that it seems that
> in most cases that'll make applications how you'd like them to in many
> cases.
> 
> The main use cases I've had in mind for battery are:
> 
> * An application wanting to go into low-power-usage mode when battery
> is getting close to running out. For example turning off smooth
> animations, or doing less frequent status updates.
> * A utility application which automatically puts the phone in
> low-power-usage mode when battery is getting close to running out. For
> example by turning off 3G data or decreasing back-light intensity.
> * A battery application displaying the current battery charge,
> possibly in combination with other status information about the
> device.
> 
> For the first two it seems better to default to 100% rather than null
> if battery isn't accessible yet. For the last one it would be wrong,
> but likely only for a few fractions of a second until the battery
> subservice is up and running so I don't know that it's worth worrying
> about.

I agree with you on setting the 'level' default to 100 (and the 'charging' default to true).

>>> In addition, we changed the complex set of events to something more simple: every time an attribute is changed, an event is fired. That means, there are 'levelchange', 'chargingchange' and 'statuschange' events instead of the other four events that seem a bit odd to us. The event handler can then access to BatteryManager to get the new values.
>> 
>> Doug Turner initially proposed the Battery{Low|CriticallyLow} events which were then folded into battery{status|low|critical|ok} events. The discussion started at [1]. Your alternative proposal seems to handle all the use cases we've discussed. Only in some corner cases, such as if the app is only interested in the critically low state, some unneeded events may get fired (each time a status attribute changes its value compared to only when status changes its value to 'critical'). On the other hand, your proposal handles situations better where the app is only interested in a single attribute's value change.
>> 
> Most likely you also want to be notified when you are transitioning
> out of critical mode, right? So I think statuschange is better than
> batterycritical. But see also below regarding if we should keep this
> at all.

The 'batteryok' event is fired when you transition out of low or critical state. You can experiment with the following demo to get an idea how it should work (enable console and check the isPlugged checkbox after the 'batterylow' or 'batterycritical' event has been fired):

  http://dev.w3.org/2009/dap/docs/battery-status/battery-status.html

>>> 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.

>>> 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.

>>> So, the idea of this email is to give our feedback about the Battery Status Events specification and why there are some parts of it we don't like but we also want to know why those parts are like that. We believe those were the results of some discussions and we might be missing a lot. We are eagerly waiting for your feedbacks!
>> 
>> Thanks for your feedback and implementation, very helpful! Hopefully I was able to shed some light on the past discussions and design decisions made. If something is missing or unclear, let me know. Generally, I like your simpler proposal and would like to align the spec to your proposal once the minor issues discussed above are resolved, and no further issues or concerns are raised by other members. There's a proposed WebKit patch [6] by Kihong, so feedback from WebKittens regarding Mozilla's proposal would be helpful to get too.
>> 
>> So let's iron out the kinks together and come up with an updated proposal soon.
> 
> I'd like to make to the original proposal in this thread:
> 
> * Remove the .status property (and the statuschange event) for the
> reason stated above

If the implementations are wise about 'level' (i.e. use battery time for calculating it), then this could be indeed dropped. If we could expose time remaining even more so: without knowing the time remaining the meaning of 10% (or 0.1) 'level' could be totally different, think laptop vs. Kindle, for example.

> * 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.

> But otherwise I agree with where this is heading :-)

Thanks for your feedback!

-Anssi

Received on Tuesday, 18 October 2011 14:35:15 UTC