RE: Some questions about battery status API

Hi Anssi,

> -----Original Message-----
> From: Anssi Kostiainen [mailto:anssi.kostiainen@nokia.com]
> Sent: Friday, September 02, 2011 5:24 PM
> To: ext Kihong Kwon
> Cc: public-device-apis@w3.org
> Subject: 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.

OK! If platform can support low/critical event by smart way, that's the
best.
Still I think it's better if the spec support the setter method for
low/critical level ;)
> 
> > 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?

OK! I am wonder the below sentence could be worked in real world.
- the battery is plugged in, and the battery is being charged or is at its
full capacity.

Because if the battery is plugged in, and the battery is being charged then
"ok" event will be fired. And then the event listener will be released,
because one-time event handler. So if we suppose to this state(plugged and
charged) is kept going until battery is full charged, then "ok" event have
to be fired again regarding to the spec's description I indicated. But event
handler was already release, therefore "ok" event will not be worked at this
moment.

--------------------------------------------------------------------
Suppose to it is in the charging state,

Add 'batteryok' listener 
-> Fire a 'ok' event immediately (SPEC: when the battery is plugged in, and
the battery is being charged)
-> Battery is full charged
-> After that a 'ok' event is fired again??? (SPEC: by the battery is
plugged in and is at its full capacity)

I think two state are collapsed.
Am I misunderstood?

> 
> Let me know if there are any other questions.

> 
> -Anssi=

Received on Friday, 2 September 2011 10:53:03 UTC