Feedback about Battery Status Events

Hi,

As part of the WebAPI effort at Mozilla [1], we did write a draft 
implementation of something we are calling Battery API [2] (inspired by 
the Battery Status Events). Those two specifications are close and we 
would like to give some feedback on the changes we did and the changes 
we might want to discuss.

The major change we did is actually making the API synchronous: the 
BatteryManager object has a few attributes that give the current state 
of the device's battery. The DAP specification requires to use an event 
handler to get those information but we believe there are use cases 
where a developer might just want to get some information at a given 
moment without caring about changes and this shouldn't be harder than 
reading an attribute. For example, a game might disable some features if 
the battery is low but these features will not magically appear during 
the game if the device is plugged, it might change between two levels 
instead.

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.

Furthermore, we are adding a 'mozBattery' attribute in window.navigator 
[3] instead of using a constructor [4]. This attribute could be 'null' 
if the device has no battery. It prevents returning some specific values 
for the attributes when there is actually no battery. One disadvantage 
is that there is no way to know if a battery is hot plugged.

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

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!

[1] https://wiki.mozilla.org/WebAPI
[2] https://wiki.mozilla.org/WebAPI/BatteryAPI
[3] Ideally, that should be window.navigator.devices
[4] We are actually looking for large feedback about which pattern 
should be usually preferred. There are a few new APIs we are working on 
that use an object in navigator and some have a constructor.

Thanks,
--
Mounir

Received on Tuesday, 4 October 2011 14:56:03 UTC