Comments on: iPhone OS 4 and Backgound Tasks or “Why We Don’t Have a Calendar API”

By: Ramkumar

Ramkumar — Fri, 27 Aug 2010 11:59:50 +0000

IPHONE OS4 : can we run NSTimer in background….if not please tell me some alternative

By: Jimbob

Jimbob — Thu, 21 Jan 2010 15:16:04 +0000

Apps running in the background don’t cause battery problems if they’re in suspended animation, just waiting to be woken by a timer. They’ll cause memory problems, though, since the iPhone doesn’t have paging (yet).

Local push notifications would be very good for a bunch of apps that implement some sort of calendar function. I can imagine both local and network push notifications to be used to wake up apps and let them execute code, but that would likely be abused with all kinds of polling anti-patterns, negating any improvements to battery life.

The solution depends on what you want to do. If you want faster app switching, the best solution is to implement paging and suspend running apps to disk. If you want background activity (such as location tracking or music scrobbling) apps should be allowed to spawn small background daemons with severely limited memory and no GUI.

By: Nathan de Vries

Nathan de Vries — Thu, 21 Jan 2010 05:26:03 +0000

Overloading the user-facing calendar as a system-level scheduler seems unlikely given that launchd does exactly what you’re trying to do. Something along the lines of SMJobBless() in the ServiceManagement framework is more likely to be exposed.

By: Corey

Corey — Wed, 20 Jan 2010 15:34:48 +0000

@Jimbob My guess is probably off here, at least technology wise. I don’t think that Apple would allow multiple apps to run as background processes. That would be a huge battery drain. Thats it woud be nice to have the Calendar App (or some other process) handle all “local push notifications”. Which is similar to how the Push Notifications work now, minus the ability to execute code.

@mare I actually doubt they would allow executing of arbitrary code as well. But if they wanted a simple solution that gives developers more flexibility without sacrificing (too much) battery life, they do have the pieces in place. There is some chatter about “Calendar Syncing”, I have to assume that the Calendar API is coming in the next major OS release.

By: mare

mare — Wed, 20 Jan 2010 14:53:42 +0000

I agree this would be cool. But I’m sure if Apple will enable such functionality it will be a bit more limited. I think they’ll never allow you to send some code to be executed by another process. If your code crashes (because it is just wrong/malformed or because of a fringe case that didn’t show up in debug/review) it’ll crash an Apple process. Apple doesn’t like that, even though that process will be re-spawned.

But they might very well at some point in the future (soon?!) provide a limited API where you can show a message at a certain time/date.

By: Jimbob

Jimbob — Wed, 20 Jan 2010 10:31:50 +0000

Two things: Blocks can’t be passed to another address space and don’t survive termination of the process. If the process is kept alive, NSTimer can be used for this, anyway. No reason to mess with exposed calendar entries.