Re: Some questions about battery status API

Hi Kihong,

On 2.9.2011, at 5.06, ext Kihong Kwon wrote:

>>> I have some questions about recently changing.
>>> 
>>> 1.     I think if web-app developers could configure batterylow and
>> batterycritical level, it would be better.
>>> Some web-apps doesn't want to use low and critical level from device.
>>> -       For example, In case of online RPG game, the exp. point and
> items
>> in the game are really important to the almost of gamers. Even better we
>> expected.
>>> Device must not be turned off during the playing time. If device is
>> turned off suddenly, user would be very upset.
>>> Therefore I guess it would be great, if game maker can handle batterylow
>> level and batterycritical level based on the characteristics of their
>> application. E.g. batterylow level = 30% and batterycritical level = 15%.
>> 
>> I think that in the above scenario it would be more appropriate to listen
>> to batterystatus events and monitor the value of level instead, and set
>> the threshold high enough.
>> 
>> Typically the OS knows better when the battery is e.g. critically low.
>> That is because the battery level could be different when hitting that
>> condition depending on factors such as whether the battery has been under
>> very heavy load recently, are there are other apps running in the
>> background etc. In such a case it may make sense to fire batterycritical
>> sooner than in a normal scenario, because it is likely that the battery
>> will continue to deplete faster than normally. For this reason, the spec
>> leaves it to the implementation to decide when is the most appropriate
>> time to fire battery{low|critical} events.
> 
> As far as I know, all of device platform can't estimate remaining time
> exactly.(It's very difficult and not accurate as you know)

That's true. Some platforms do not even give any timeRemaining estimates, thus the timeRemaining attribute was dropped, see:

  http://lists.w3.org/Archives/Public/public-device-apis/2011May/0043.html

As Josh pointed out, if we had kept the timeRemaining attribute it would had better addressed your use case (on such platforms that support it). But due to lacking platform support the group decided to drop it.

> It means low and critical levels are based on the battery level(%), even if
> it is presented by platform.

That is one (but not the only) valid implementation strategy. The more battery-related information is available to the underlying platform, the better estimate can be given to the web platform.

> If so, I think, It is good to change the low and critical levels according
> to the characteristics of apps.

This is up to the implementation, and a bit more advanced implementation could adapt to the characteristics of the app. You could, for example, monitor the CPU load (or other metrics affecting battery performance, such as whether the user is actively interacting with the app) and based on that information decide when to fire the events.

> As you know, one-time event(critical and low) is more efficient than the
> monitoring batterystatus-event.

Yes, better performance due to less events is one of the key benefits. The battery{critical|low|ok} events also abstract away details, which means developers have a simpler subset of the API to work with, good enough for most high value use cases. And the batterystatus event provides more, if that's needed.

> How do you think about this?

Feel free to provide a concrete proposal, if you feel there's something to be improved or clarified.

>>> 2.     Yesterday, I looked at the batteryok event as a new event in this
>> spec.
>>> When this event is occurred? The meaning of this event is not clear to
>> me.
>>> In addition, I don't think batteryok event is required for this spec. I
>> think just to have "ok" value in the state property of BatteryStatusEvent
>> is enough.
>> 
>> The idea behind batteryok is to provide a mechanism for developers to get
>> a single event when the device's battery is plugged in and the battery is
>> being charged or is at its full capacity. A kind of a signal that says:
>> "don't worry about the battery, it is doing fine now and you can restore
>> normal operation". Does this sound useful?
> 
> I understood what 'ok' event means, Thank you.:)
> However, I have a one more question. 
> The description about 'batteryok', in the spec is 
> - the battery is plugged in, and the battery is being charged or is at its
> full capacity.
> How event is occurred "at its full capacity" case?

This means that if the level == 100 and the device is plugged in the batteryok event is fired. In other words, the only case when plugging in the device does not fire the batteryok event is when the battery is depleting due to high load despite of being plugged in.

> It means device is already in the charging state when listener is added.

If the device is in the charging state (=the battery is not depleting) when the listener is added the batteryok event is fired.

> (If device is not in the charging state, event is already fired when it is
> plugged in)

If the device is not in the charging state (=the battery is depleting), plugged in or not, no batteryok event is fired.

> Consider a meaning of 'ok' event, it have to be fired immediately after
> listener is added.(because device is already 'ok' state.)
> Is there any other case about 'full capacity'?

Perhaps a couple of lines of (pseudo) code could clarify what you mean by this?

Let me know if there are any other questions.

-Anssi

Received on Friday, 2 September 2011 08:24:46 UTC