[battery] Disseminating Cordova's feedback (was: [admin] Agenda - DAP Distributed Meeting 12 June 2014)

Hi Lisa, All,

On 10 Jun 2014, at 23:29, Lisa Seacat DeLuca <ldeluca@us.ibm.com> wrote:

> I can give an update on the Cordova w3c alignment progress as well at the meeting this thursday. 

Lisa - thanks for the update. I read through the thread on the org.apache.incubator.callback-dev list you pointed us to during the call.

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

Received on Monday, 16 June 2014 09:11:30 UTC