RE: Battery Status Event Spec

> Isn't that what level is for?
Yes, that is right. However, I don't know it make sense to have both timeRemaining and level. Isn't they kind of represent the same thing. It is hard to accurately calculate timeRemaining. At least on my computer, I noticed that timeRemaining fluctuate and sometime it gave me something like 4hr 20mins then later it gives me 4hr 32mins. 

Thanks
Dzung Tran


-----Original Message-----
From: Robin Berjon [mailto:robin@berjon.com] 
Sent: Thursday, March 31, 2011 6:41 AM
To: Tran, Dzung D
Cc: Anssi Kostiainen; public-device-apis@w3.org Group WG
Subject: Re: Battery Status Event Spec

On Mar 31, 2011, at 00:02 , Tran, Dzung D wrote:
> One concern is that I don't particular think that firing events on regular intervals make sense for Battery status. It makes sense for DeviceOrientation, since the use case is different in a sense that you want to update the map on regular interval. As for battery, you might just want to get an event when you are at a certain threshold such as 20% of battery left, unless you have a web app that display the battery meter, but how useful is a battery meter app.

I certainly don't expect the implementation to be dispatching events all the time, as it would with orientation. But events are a useful model nevertheless. They integrate well into the stack. For isCharging/isBattery they're pretty much what you want in any case. And I can see use cases other than battery meters. For instance, you could listen to timeRemaining to see if there's still enough time to finish the video currently being watched.

> Also I don't particular like the use of timeRemaining. Maybe it should be percentage charged?

Isn't that what level is for?

-- 
Robin Berjon - http://berjon.com/

Received on Thursday, 31 March 2011 14:14:41 UTC