- From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- Date: Thu, 1 Sep 2011 13:22:14 +0300
- To: ext Kihong Kwon <kihong.kwon@samsung.com>
- Cc: <public-device-apis@w3.org>
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. > 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? 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 Thursday, 1 September 2011 10:22:55 UTC