This has been on the burner for a while. With all of the iPhone OS 4 / iPad / iSlate hoopla, I figured I better get it out the door before it all becomes a moot point.
One of the most perplexing omissions in the current SDK has been the CalendarStore API. It seemingly goes hand-in-hand with the AddressBook APIs and is every bit as important for contact management on a mobile device.
But alas, here we are on OS 3.1.X without any support for accessing a user’s calendar. Not even the “second-class citizen” readonly kind.
Although I’m sure the iPhone team at Apple has a pretty big todo list, I can’t help but think there is something more to this mystery…
I submit to you, the reader, that the forthcoming Calendar API is intimately linked to a background processes API. Huh?
I know, but let me explain.
When iPhone OS 3 appeared on the scene, Apple bestowed upon us a gift known as Push Notifications. But lets face it, they suck. For one, they only serve a few specific types of applications. And, perhaps even more detrimental, Push Notifications are hard. Hard to implement. Hard to host. Hard to scale.
Now some will disagree regarding degree of difficulty in setting up a Push Notification server, but none can argue that requiring developers to deploy a server just to fake background tasks is ludicrous.
But to my point: If only we had something like Push Notifications, but more flexible with no server requirement. Also, why not let us execute arbitrary snippets of code when our app isn’t running.
Now were getting somewhere. So, lets put it all together.
I have an app, say an alarm clock app (I know easy example). I want to schedule an alarm, so I call the calendar API and schedule an event.
CalAppEvent *newEvent = [CalAppEvent event];
[newEvent setStartDate:someDate];
[newEvent setRecurranceRule:hourly];
CalCalendar* appCalendar = [[CalCalendarStore defaultCalendarStore] sharedAppCalendar];
[newEvent setCalendar:appCalendar];
[[CalCalendarStore defaultCalendarStore] saveEvent:newEvent span:CalSpanFuture error:nil];
But wait, instead of a simple alarm, maybe I want to play a sound file from my app bundle and deliver a context specific message to the user. Maybe I even want to open a network connection.
If only we had an easy way to capture lexical scope and pass off some code to be executed by another process. How about:
[newEvent setAlarmBlock:myBlock];
Now when my event fires, I can run any arbitrary piece of code!
Now you see the possibilities. Is this true background process support? Not quite. But it is close, very close.
It provides nearly all the flexibility we need, while preserving battery life. Not to mention it avoids deploying and maintaining a server. We’ve effectively leveraged existing technologies (albeit 10.6) and since the calendar process is always running, why not exploit it for all of our multitasking needs?
Additionally, this implementation provides users with a familiar, easy to understand UI for managing background apps: the Calendar app. Simply open the special “Background Tasks” calendar to view all upcoming events scheduled tasks all of your apps.
Of course this is all speculation as I can assure you I have no inside information. I am sure that Apple has a much more elegant solution, but I can’t help but think I am on to something…
Thank you for indulging me in my little though experiment.
real time twitter by: