RE: Some questions about battery status API

Hi. Anssi.

> -----Original Message-----
> From: public-device-apis-request@w3.org [mailto:public-device-apis-
> request@w3.org] On Behalf Of Anssi Kostiainen
> Sent: Thursday, September 01, 2011 7:22 PM
> To: ext Kihong Kwon
> Cc: public-device-apis@w3.org
> Subject: Re: Some questions about battery status API
> 
> Hi Kihong,
> 
> On 1.9.2011, at 11.09, ext Kihong Kwon wrote:
> 
> > Hi. This is Kihong Kwon who is a code contributor of battery status
> event spec to the webkit
> > So far I had done the implementation for webkit EFL port and demo
> application in according to this spec. but unfortunately I didn't apply
> latest version of spec(31th August version) to my implementation.
> > It works fine, and the battery status seems to be quite useful for web-
> apps.
> > I will open it as soon as I get a grant from company.
> 
> Excellent work! Great to hear the implementation is working fine and that
> you'll continue to work in the open. I assume you will update the
> following WebKit bug soon with the latest patch?
> 
>   https://bugs.webkit.org/show_bug.cgi?id=62698
> 
> > 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)
It means low and critical levels are based on the battery level(%), even if
it is presented by platform.
If so, I think, It is good to change the low and critical levels according
to the characteristics of apps.
As you know, one-time event(critical and low) is more efficient than the
monitoring batterystatus-event.
How do you think about this?

> > 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?
It means device is already in the charging state when listener is added.(If
device is not in the charging state, event is already fired when it is
plugged in)
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'?

> Alternatively, you could listen to batterystatus and test for isPlugged
> and level, but that would mean many more events would get fired (each time
> isPlugged/level/status changes), potentially causing performance issues.
> Also, it would be cumbersome for developers to find out is the device
> actually charging if it's plugged in (would need to monitor level over
> time to find out).
> 
> Let me know if you have any other comments or questions while implementing
> the specification, and thanks for your comments so far.
> 
> -Anssi

Received on Friday, 2 September 2011 02:07:01 UTC