[Battery Status Event Specification] RE: Battery feedback uses

> Battery use cases
> * Showing a battery indicator, especially in full-screen

This is addressed by the proposed API

> * Determining if a task can be completed before the device dies or
> kills the application

This is not addressed by the proposed API

Battery life varies from battery to battery and device to device. In order to do anything remotely useful with the battery event status API as proposed, each consumer will have to:
1. Register for the signal.
2. At the first event, get the current time and value.
3. Wait for a second event, get the current time and value.
4. Compare the levels and calculate a degree of decay or improvement.
5. Divine how resources were used by all applications on the entire device during the time interval between 2 and 3.
6. Use this to decide roughly how long it has before the device dies.

This is hardly a practical approach. I doubt anyone will actually do this, instead developers will make really poor assumptions about how much 1% of a battery is. This differs significantly between a 2, 4, 6, or 8 cell laptop battery, and it can also differ between a phone's normal or extended life batteries. This doesn't even go into the fact that depending on what else is running in the background, more or less power may be consumed, or that a device can be charged at .1, .5, 1, 1.2, 5, or 10 amperes depending on the connection kind (which should *not* be reflected through an API). 

> * Trying to be polite: is the user in economy mode / has the user asked
> to aggressively manage power?

This is not addressed by the proposed API

If I'm about to go on a trip, my devices are likely to be plugged in because I need them to be charged once I leave my house. It took me 80 minutes to bicycle to work this morning, during that time I did not have a power source available for my phone -- I haven't added that to my bike yet.... Before that time, my devices were charging, it's possible that one day I will forget to charge them overnight, which could easily mean that I'll wake up, plug them in, and give them 30-60 minutes before I leave. During that time, I'm likely to want to read my email or check the weather, or plan my route, each of which are things which should be using whatever API we define.

> Reality Checks
> * On a desktop computer running Windows, it's likely that the computer
> will reboot within three weeks
> * Some users have a tendency to turn off their computers every evening

(and some people forget to plug in their mobile devices overnight, I do not look forward to being one of them.)

> * Some mobile devices can use more power than they can take in, e.g.
> the Nokia n900

This isn't usefully addressed by the API.

Most consumers are likely to check isPlugged before level and will probably not consider that even though the device is plugged in, it isn't gaining power.

> Notes
> * A device or widget host should be able to discover, learn or be
> taught the items in the Reality Checks section
> 
> Goals
> * Tell an app how long it likely has before the app will be terminated

This is not addressed by the proposed API

> * Allow application to ask if it could use certain resources for a
> certain amount of time without being quit

This is not addressed by the proposed API

> * Getting an update on such estimates / profiles

This is not addressed by the proposed API

> Ideally, an application should be able to say:
> 1. I'd like to create a long task
> 2. I'm going to need these services: (list - e.g. Location, Graphics)
> 3. I expect it to finish by time: x
> 4. Platform, will this be ok?
> 5. Answer: Currently, that will be fine, if things change, we'll let
> you know
> 6. <Time passes>
> 7. Application updates query indicating a new completion estimate (for
> better or worse)
> 8. Platform updates application if it discovers that it will have to
> kill the application before its completion window expires
> 
> I'll try to take some time to see how this maps to the current
> proposal.

OK, I took the time, from my perspective, and the metrics defined above, the current proposal fails to address the vast majority of use cases. It would indeed be usable for a battery icon indicator widget/applet.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Tuesday, 28 June 2011 14:54:12 UTC