Email The Bastard
About The Bastard

Fun, But Not Safe For Work
Today's Hot Babe (changes daily)
Preview Babe of the Day
Weekly Video
Even More Nekkidness
Why I have Nekkid Women on my Blog

Recent Comments

« Great Speech by Obama | Main | The Obama I Know »

iPhone Push API

Submitted to Apple as bug 5806232


iPhone developers need a push API. The iPhone is a breakthrough internet device, but its battery powered. Consequently, Apple has decreed that there will be no background tasks on the phone.


Fair enough. I could live with that. I've heard from others that regularly polling from the phone just sucks down the battery life faster then a:


if (person reading this is a man)

printf("sorority girl can suck down a Strawberry Daquiri")

else

printf("frat boy can suck down a beer keg")


Unlike many iPhone developers, I spent a year with EDGE as my main internet connection, so I know that polling really does suck.



So I don't want to poll anyways. What I'd like instead is a way to push a "hey dummy, wake up and pull some new data" notification to the phone. Besides, once you're on the internet anyways, it makes a lot of sense to setup a server to filter notifications since that server can be plugged into the wall.



Now I don't know about the internals of the iPhone phone radio hardware, so there might be a better way to do this, but it seems to me that there is at least 1 easy way to go about this.


The first way, which I know would work for sure, is to leverage the existing SMS mechanism. Since the SMS mechanism already exists, this would require the following additional bits of infrastructure to be added to the iPhone.


1. The phone would have to be able to recognize these special messages, and know to treat them differently. There are a number of ways these messages could be marked as special, either via the origin (special number), or via the content of the message itself (used here for clarity).


2. Inside the message would be data indicating the destination of the message. For example, this could be a simple as a reversed domain name: com.apple.Mail would indicate that the destination was Mail. In practice, given the short size of SMS messages (140 characters) this might be something shorter, but it makes the idea more obvious.


3. Registered on the phone inside the App bundle would be code for handling the message. The iphone would pass the message into the message handler code, which would have access to the enclosing apps filesystem.


Ex:


The iPhone gets a message saying:

<iPhone>com.apple.Mail|40!gmail.com</iPhone>


This sample message shows how mail could be pushed to the iPhone very reliably. In the sample above, gmail.com is indicating that there are 40 messages available. The handler for Mail can launch, parse the message, queues a sound, and quits. This would not be much more battery cost then that used for receiving an SMS message now.


However this is implemented, I think this is a necessary addition to the iPhone SDK. (perhaps there's some other way to push a data packet to the phone? I know that Blackberry's do this for email. )


Comments Welcome.

Comments (1)

Al Theolog:

The SMS based notification solution you propose works great in theory and engineering lab; but it doesn’t scale and fundamentally can’t provide guaranteed near-realtime notifications.

The wireless network is controlled by a hegemony of carriers who generally despise the openness of the Internet.

Carriers do use mechanisms like this to provide their own services; but the SMS messages used in those cases are not charged against the user’s quota. Also, the carriers firmly control the frequency of such messages, and when they allow such activity there is a firm contract in place and fees paid to the carrier. Finally, there is no implied timeliness for SMS- based notifications: they can arrive in seconds, minutes, or hours after being sent; depending on the carrier’s load and priorities.

Each carrier has slightly different rules, and SMS notifications may not be bridged between carriers in a timely manner. Navigating these waters is near impossible for an unknown or small outfit wishing to write software.

Allowing unrestricted SMS’s to be sent by uncontrolled 3rd party software is simply put, unfeasible.

Post a comment


Technorati

Technorati search

» Blogs that link here

Archives