Device API w3c Working Group Response to Cordova feedback on Battery

Cordova Team~

This morning on the Device API's w3c Working Group call we discussed the 
battery implementation.  I had shared with the team some of the concerns 
some of the Cordova team had around battery as discussed in this thread: 
http://apache.markmail.org/search/?q=org.apache.incubator.callback-dev+list%3Aorg.apache.incubator.callback-dev+order%3Adate-backward+battery#query:org.apache.incubator.callback-dev%20list%3Aorg.apache.incubator.callback-dev%20order%3Adate-backward%20battery+page:1+mid:ympctdea7cxxm76z+state:results


Anssi went through each of the concerns and sent a note with his 
takeaways.  This note can be publically seen here: 
http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0068.html


I am pasting it again here for your reference.  If each of you could take 
a look and see if his response addresses any concerns we have that would 
be great.  The DAP team is very interested in our feedback.

--------------

Here are my takeaways from that thread, please let me know if I missed 
any:

### Calculate charging and discharging rate

[[

However, this spec requires that we calculate charging and discharging 
rate as well,
which I think is extra information that we don't need.

http://markmail.org/message/kxgb5ia4tmzerqnx


]]

This was addressed by the following clarification (the behaviour was like 
this in the previous version, but this clarification aims to make this 
even more clear):

https://dvcs.w3.org/hg/dap/rev/7476e089d3d9


This is what I said on the public-device-apis related to this change:

[[

I think it is fair to assume some platforms may want to implement this API 
even if they could only support a subset of the attributes (say, support 
charging and level, but not chargingTime and dischargingTime). Requiring 
an aggregate would mean we’d cripple such implementations as they’d fall 
back to defaults for all the attributes when the promise resolves, and 
only after the corresponding events fire they’d be able to report the real 
values.

http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0044.html


Here’s an attempt to clarify this so that the attributes are not 
considered an aggregate:

https://dvcs.w3.org/hg/dap/rev/7476e089d3d9


]]

### Granularity of events

[[

Couldn't cordova-android-battery just choose to notify on a larger change 
... say 5%?

http://markmail.org/message/qu34dehgtk4bsnig


]]

This would qualify as a conforming implementation given the spec states: 
"The definition of how often the chargingtimechange, 
dischargingtimechange, and levelchange events are fired is left to the 
implementation.”

### Pre-populating BatteryManager

[[

The big problem is that this BatteryManager object has read-only
properties that we'd have to pre-populate.  I really dislike this, and
would like for this plugin to be entirely async if possible.

http://markmail.org/message/kxgb5ia4tmzerqnx


]]

The concern with "read-only properties that we'd have to pre-populate" is 
addressed by this clarification to the spec:

https://dvcs.w3.org/hg/dap/rev/7476e089d3d9


The async request was addressed by exposing the BatteryManager via 
getBattery() returning a Promise instead of a synchronous accessor.

### Android specifics #1

[[

http://developer.android.com/training/monitoring-device-state/battery-monitoring.html


http://developer.android.com/reference/android/content/Intent.html#ACTION_BATTERY_CHANGED



So, using this, you can tell whether your device is charging and how
it's charging, but you can't get numbers without subscribing to the
ACTION_BATTERY_CHANGED intent.  If you have a receiver for this
intent, it will fire constantly, and this will consume battery.

http://markmail.org/message/kxgb5ia4tmzerqnx


]]

This seems to suggest Android’s ACTION_BATTERY_CHANGED intent 
implementation has issues with battery consumption. This is something the 
spec cannot mitigate other than saying it is up to the implementation how 
often the events are fired, which it does already.

### Android specifics #2

[[

> It may be a tad offtopic, but does that mean that every app/widget on
> Android suffer from the same issues, including the native ones? It's 
almost
> hard to believe, if it is so.

Yes and no.  Nobody registers a receiver to ACTION_BATTERY_CHANGED,
because this will kill your battery.

http://markmail.org/message/4auqqxne2pfvnpm2


]]

Further evidence that suggests this is an issue with the Android 
implementation.

###

Further concrete feedback from implementers on how to improve the 
specification is much appreciated, preferably on the public-device-apis 
mailing list. If other venues are used for feedback, please send a pointer 
to the feedback to this mailing list (similarly to what Lisa did).

Lisa - could you bridge the gap between the Cordova and W3C communities 
and make sure that the Cordova folks' feedback is properly addressed? 
Cordova is a significant implementer, and as one of the editors of the 
spec I’d like to do my best and make sure this working group addresses 
Cordova's feedback. That said, we’d like to publish an updated LC within a 
couple of weeks, so we’d appreciated swift feedback.

Thanks,

-Anssi
-----------------
Thanks,


Lisa

Lisa Seacat DeLuca
Mobile Engineer | t: +415.787.4589 | ldeluca@apache.org | | 
ldeluca@us.ibm.com | lisaseacat.com | |