W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2011

Re: Battery feedback uses

From: <Frederick.Hirsch@nokia.com>
Date: Tue, 28 Jun 2011 19:23:26 +0000
To: <jsoref@rim.com>
CC: <Frederick.Hirsch@nokia.com>, <public-device-apis@w3.org>
Message-ID: <918DA7C3-4242-43FF-8704-5505A18FB05D@nokia.com>
Josh

I'm not sure I understand the following:

> * A device or widget host should be able to discover, learn or be taught the items in the Reality Checks section

If I the user decide to shut my device off, how would it help for the app to anticipate that, or are we talking about Mac OS X Lion app backups/versioning/app restart to give an example?

(the bicycle example didn't help me here)

regards, Frederick

Frederick Hirsch
Nokia



On Jun 23, 2011, at 11:33 AM, ext Josh Soref jsoref@rim.com wrote:

> I'm sorry that I wasn't able to provide this feedback earlier. I just joined RIM and DAP. This week I spent time talking with two implementation teams here. What follows seems to cover the needs of application developers and users.
> 
> Battery use cases
> * Showing a battery indicator, especially in full-screen
> * Determining if a task can be completed before the device dies or kills the application
> * Trying to be polite: is the user in economy mode / has the user asked to aggressively manage power?
> 
> 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
> * Some mobile devices can use more power than they can take in, e.g. the Nokia n900
> 
> 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 he app will be terminated
> * Allow application to ask if it could use certain resources for a certain amount of time without being quit
> * Getting an update on such estimates / profiles
> 
> 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.
> ---------------------------------------------------------------------
> 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 19:24:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:21 GMT