> I was under the impression that the mechanics of each were nearly identical.
They're actually very different: with Android you create what's basically a daemon server, no UI but does everything it want, while with OS4 you register against service (there are 7 service types to choose from) and the OS itself runs and manages it, calling your registered service hooks.
Android gives far more control, at the cost of more (programmatic) complexity and more battery life risks (a badly implemented daemon/service will kill your battery life quick, whereas on the OS4 since the OS keeps full control of the execution it has a much better shot at managing battery/power issues, and it can more efficiently handle multiple applications registering for the same service).
The part that is similar is the handling of non-multitasking-aware applications (regular applications in OS4, applications with no daemon in Android): they're simply frozen in RAM, and killed if memory pressure becomes an issue.
Yes but that puts the onus of battery-care on the user of the phone. It's fine for geeks (nb: not a put down, I'm in that category myself) which are going to spend half their time between that and the task killer anyway, but that's not the demographic Apple targets, and that's not the kind of tradeoffs they'd find acceptable. Hence their selection of a different solution, which (they believe) gets you 90% of the way with 10% of the costs.
Not necessarily. It could also be the developer of the application that is taking advantage of the battery monitor functionality to see if their application needs improvement.
I agree that no end user should have to be keeping a watch for applications that use too much battery, but it sure is nice to have that information easily accessible for developers.
It doesn't work very well. There have been occasions where I've accidentally left the PandoraService running on my Droid overnight (not playing music mind you, but that doesn't stop it from sapping battery) and woke up in the morning to find my battery nearly dead and the battery tool claiming that it was "Android System."
Though I suppose it's possible that was a bug in the service management stuff...
Your quote is incomplete, the phrase before it is important:
> If an app needs to continue functioning indefinitely while in the background
Operative word here being indefinitely, in the paragraph above he describes task completion as well (an application can request up to 10mn [or something, might have changed] to finish handling a task)
I was under the impression that the mechanics of each were nearly identical.