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

On Mon, 16 Jun 2014, at 19:10, Kostiainen, Anssi wrote:
> 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
> 
> ]]

If implementations are happy with removing chargingTime and
dischargingTime, I guess it could happen. The default values are here
when there is a strong limitation from the platform. If they are more
used than not, removing the attributes is probably the sanest thing to
do.

It seems that the charging/discharging remaining time is usually
provided on Desktop but rarely on Mobile.
Cocoa:
https://developer.apple.com/library/mac/documentation/IOKit/Reference/IOPowerSources_header_reference/Reference/reference.html#//apple_ref/c/func/IOPSGetTimeRemainingEstimate
Windows:
http://msdn.microsoft.com/en-gb/library/windows/desktop/aa373232(v=vs.85).aspx
Linux (via upower):
http://upower.freedesktop.org/docs/Device.html#Device:TimeToEmpty

> ### 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
> 
> ]]

I've never seen real data about ACTION_BATTERY_CHANGED being actually
battery consuming on Android. Android fires that event for every 1%
change so it sounds very odd to me that listening to it would kill
battery life. Any serious data on this would very helpful.

A bit off-topic: it is really great to see Cordova contributing to this
API (and others). Your feedback is very valuable and we hope to see more
of that! :)

-- Mounir

Received on Monday, 23 June 2014 15:21:00 UTC