incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon MacDonald <>
Subject Re: State of battery API
Date Wed, 18 Jan 2012 16:14:02 GMT
Yeah, as Drew said at one point in time what was implemented was the
state of the art in Battery API specification. I love Drew's
suggestion of implementing the new API while keeping the old one
around as deprecated.

I think the best way to handle the battery drain from constantly
monitoring the battery (that irony right?) is for us to handle it in
the configuration files. If application developer doesn't want to
monitor the battery level, and that is a pretty specific piece of
functionality, that they should remove the line from plugins.xml,
plist, etc.

I can take on the task of implementing the new Battery API on Android
as I've got experience with the previous implementation.

Simon Mac Donald

On Tue, Jan 17, 2012 at 9:58 PM, Drew Walters <> wrote:
> What is implemented currently in PhoneGap was at one time the latest
> draft of the battery spec.  As Fil noted it has changed drastically in
> the last couple months.  I've been working in my sandbox to implement
> the latest draft in BlackBerry.  Since the spec is so drastically
> different, it is possible to implement the new API while maintaining
> the old version we currently support.  My thought was to take this
> approach so we could deprecate the old API while also providing the
> new API.  This would give current users a version or two to switch
> over to the new one before removing the old.
> The new API provides support for event based listeners on
> navigator.battery, navigator.battery.on* API and directly accessing
> battery information through navigator.battery.level etc..  The old API
> only supported event based listeners which allowed us to only enable a
> battery listener in native code when the application was actually
> listening for battery status.  With the new API, I don't see how this
> would be possible as it appears the battery state should always be
> available.  This is undesirable from a battery drain standpoint as
> many apps don't care about the battery state.  I'm open to suggestions
> on how to best handle this.
> The other tricky part with the new API is estimating remaining battery
> time and time to charge fully.  Since BlackBerry doesn't provide an
> API for this I'm currently doing this crudely by keeping track of time
> between battery level changes and then performing some math to
> calculate seconds.
> On Tue, Jan 17, 2012 at 8:30 PM, Brian LeRoux <> wrote:
>> I wonder if its time we became more formal than a 'quirks' section in
>> the docs. Its things like this we need to draw to the attention of the
>> operating system vendors.
>> A special place in the wiki? A certain type of bug in JIRA?
>> On Tue, Jan 17, 2012 at 5:50 PM, Jesse <> wrote:
>>> Windows Phone does not expose any battery info other than
>>> DeviceStatus.PowerSource
>>> and it will fire the event PowerSourceChanged when plugging/unplugging the
>>> phone.
>>> PowerSource is an enum of either Battery | External
>>> On Tue, Jan 17, 2012 at 4:25 PM, Filip Maj <> wrote:
>>>> The battery API in phonegap/cordova/callback 1.3.0 [1] is a simple
>>>> event-based one. However, it doesn't look like it's a full implementation
>>>> of any existing spec and is event-based only, which is annoying when you
>>>> just want to know the battery level in a synchronous way. It looks like
>>>> it's about 80% of the Battery Status Events W3C DAP spec [2]. Ours is
>>>> missing the 'batteryok' event, as well as the attachment point for event
>>>> handlers is different (we attach via a window.addEventListener call,
>>>> whereas the spec calls for a new BatteryEventSource().addEventListener).
>>>> The event names seem pretty arbitrary (batterycritical, batterylow,
>>>> batterystatus and batteryok) and don't mention any guidelines for
>>>> thresholds.
>>>> To confuse matters further, there is a newer Battery Status API DAP spec
>>>> [3] that looks more complete and, in my opinion, is a nicer API and
>>>> provides a non-evented approach to querying the battery state on top of
>>>> supporting the events. [3] is the "Stable Draft" whereas [2] is the "Public
>>>> Working Draft". The events make more sense too:
>>>>             attribute <
>>>> Function? onchargingchange;
>>>>             attribute Function? onchargingtimechange<
>>>> >;
>>>>             attribute Function? onlevelchange<
>>>> >;
>>>>             attribute Function? ondischargingtimechange<
>>>> >;
>>>> I think we should change our implementation to match the one described in
>>>> [3], and am wondering what everyone else thinks. If there is consensus on
>>>> it, perhaps we can figure out when we want to incorporate this change: 1.4,
>>>> 1.5, etc.
>>>> Curious to hear what everyone else thinks.
>>>> -Fil
>>>> [1]
>>>> [2]
>>>> [3]

View raw message