RE: Battery feedback uses

Frederick wrote: 
> 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?

Let's use Windows NT as an example for a moment...
It maintains something called an "Event Log", in the "System" log, it records each time the computer is shut down and each time the computer is booted. You can view this in "Event Viewer", in Windows 7, it's Event Viewer (Local) > Windows Logs > System.

* The following are boot messages:
Information 6/20/2011 5:33:33 PM EventLog 6009 None
Microsoft (R) Windows (R) 6.01. 7600  Multiprocessor Free.

Information 6/20/2011 5:33:33 PM EventLog 6005 None
The Event log service was started.

* The following are shutdown messages:
Information 2/10/2011 3:29:03 PM Kernel-Power 109 (103)
The kernel power manager has initiated a shutdown transition.

Information 2/10/2011 3:29:26 PM Kernel-General 13 None
The operating system is shutting down at system time ‎2011‎-‎02‎-‎10T20:29:26.343750000Z.

Information 6/20/2011 5:32:04 PM Kernel-General 12 None
The operating system started at system time ‎2011‎-‎06‎-‎20T21:32:04.375199700Z.

Information 6/27/2011 7:05:52 PM EventLog 6006 None
The Event log service was stopped.

Generally I think the right pair of messages are "EventLog event 6005" and "EventLog event 6006". I believe they come in conveniently matched pairs, and you can do useful things with them. A user-agent could review the Event Log to determine that users, e.g. shut down daily at a certain time. If there's a pattern of shutting down at 5:30pm, or 4am, then the user-agent could use that to estimate when any applications running on the system will die (preferably with some margin...).

The event log can be used to determine if the user initiated the shutdown (likely for a 5:30pm shutdown), or if it was software initiated (periodic updates, likely for a 4am shutdown).

I think that the Software Update case which I'm mentioning here probably is similar to your OS X Lion behavior, but I don't know enough about Lion to be certain.

Another amusing case is "Nightly", it updates every day, which means any application hosted by that User-Agent will always have a life span of <24 hours (and when Nightly gets around to proper session behavior and actually automatically restarting instead of bothering me, it'll be even more consistent). Again, the UA (in this case, Nightly), should be able to learn and predict its own update cycle and thus factor that into the potential life span for any hosted app. If it turns out that the user asks Nightly to delay a restart for 4 hours (Windows has a delay option for its restarts), then Nightly could use the hypothetical adjustment notification to inform the hosted task that it has a 4 hour reprieve.

> (the bicycle example didn't help me here)

For the bicycle case, the right answer is probably for the user-agent to recognize that the battery was very close to empty, and that it's charging now, and provide a way for the user to indicate "I need to charge now, please be gentle so that my battery can charge". If the user does this a couple of days in a row, a good QoE user-agent should learn the pattern and default to this behavior on following days. We're creatures of habit; today was my second day biking to work, tomorrow should be my third.

I spoke to some service desk guys about batteries and they explained that they don't have time to sit down and charge their batteries (they're constantly moving). In their case, a good QoE user-agent should recognize that life span is probably only 75 minutes (number pulled out of the air, calculating it should be the job of the UA, not me), or that if the battery is low and they're near a Location where the device generally dies, to assume it's likely to die RSN (there's a battery charger at their desk, so they literally rip the battery out and swap it when they go by..., but especially if it's close to 5pm when they'd go home). Obviously the UA wouldn't actively check Location to determine if it was likely to die, but if the UA had already calculated a Location because something else needed it, then there's no reason that the UA couldn't do a quick check to see if it's likely to be in its kill zone. - And I do mean kill zone, they were really unceremonious about just pulling the battery out, they didn't even bother closing apps or powering down their phones.

I hope that helps.

---------------------------------------------------------------------
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:53:36 UTC