Sam Oliver
The capability to produce these applications, sometimes called background apps, has been atop the wish lists of iPhone developers, mainly because Apple prevents the iPhone from running more than one application at a time.
That means that an instant message conversation in AOL's free AIM app for the iPhone would abruptly terminate should a user receive a phone call. The user wouldn't receive any new incoming messages until the phone call was over and the AIM application was relaunched. The same would happen if a user clicked on a web link sent via instant message, triggering the Safari app to launch and the AIM app to quit.
Apple's argument against traditional background-capable applications is a sound one, and one that's in the best interest of iPhone users. During the company's recent developers conference, iPhone chief Scott Forstall noted that implementations of background applications on rival mobile operating systems are largely flawed in that they lead users to believe that they've quit applications when those apps remain open.
This in turn eats at battery life, where the iPhone 3G is already limited by power-hungry 3G and location services, and also weighs on processor performance with each additional application that continues to run as a background process.
To solve this problem, Forstall said Apple was developing an alternative to background applications known as a "Push Notification Service" that developers could tap through a series of APIs, or easy to use programming functions, beginning in September. Instead of allowing potentially dozens of third party services to simultaneously access an iPhone directly, the push service would funnel all transmissions from developers' servers through a central Apple server, which would then relay the data to iPhones through a single persistent and well-managed background connection.
Apple's overview of its Push Notivation Service.
Through this technique, Forstall said developers can push badges to icons (like the email count indicator seen on the iPhone's Mail icon), notification sounds, or pop-up text alerts like those that currently appear when an iPhone receives a text message. This management system was also developed to scale easily with larger apps, the exec said.
The first beta release of iPhone Software 2.1 last week whet the appetite of iPhone developers waiting on the push capabilities when it included some references to the feature. However, a second beta that arrived last night finally includes a rough implementation of the push services API, according to MacRumors.
"This is the second beta of the iPhone SDK targeting iPhone OS 2.1, including bug fixes to iPhone OS as well as an early implementation of the Apple Push Notification Service API," Apple said. "This API is not yet integrated with a live push server."
Only a select group developers are reported to have received the latest beta, which as Apple noted, isn't fully functional. Still, the iPhone maker has two months left to meet its self-imposed deadline to roll out Push Notification Service tools to its broader developer community. If it makes good on its promise, the first background-conscious iPhone applications should start cropping up on the App Store later this fall.
-m.jpg)
Charles Martin
Christine McKee
Wesley Hilliard
Malcolm Owen
Andrew Orr
William Gallagher
Sponsored Content
41 Comments
Okay... so we're not really talking about applications running in the background as the article sounds at the start, are we? We're talking about the push notification service which has already been announced and is expected? Big difference...
I think this ability will be both popular and useful. I've already had quite a few iPhone developers contact me about getting some Mac servers set up to push their notifications. They're excited to have the ability.
I suppose the biggest worry is that it will be overused. (digg.com shouts anyone?) but as long as there are options to turn them off, and you keep an eye on what apps you install that use them, I suppose it will be bearable.
"Their" is not the same as "they're" - sorry to be a grammar Nazi, just noticed that mistake in the opening sentence.
Okay... so we're not really talking about applications running in the background as the article sounds at the start, are we? We're talking about the push notification service which has already been announced and is expected? Big difference...
I hope this doesn't become the new twitter(always exceeding capacity).
I wonder if they learned their lesson from the mobileMe launch?
Hopefully they will have adequate server capacity to handle all the notifications.
Every developer and his uncle is going to want to use this.
I hope this doesn't become the new twitter(always exceeding capacity).
I wonder if they learned their lesson from the mobileMe launch?
Hopefully they will have adequate server capacity to handle all the notifications.
Every developer and his uncle is going to want to use this.
Interesting... I didn't really consider possible network issues. But I can't imagine how that would be a problem now that I do. Not only will the volume of data in this case be much smaller than anything Apple is dealing with in terms of activating an iPhone (and especially media-rich activity on MobileMe), but the consequences of delay or trouble at the start are much smaller. They're probably going to be transmitting a simple notification (one for each badge, or a numerically weighted notification) which is then assigned to an app. It might not actually be transmitting the app's data, though it could be pretty cool if they make that possible. Say they underestimate it -- delay will mean badges don't show up on time or don't show up at all (either not much worse than the present case of having no notification of all). I imagine it will go smoothly, though.
But yes, I imagine there will be a huge demand for this. Nearly half the apps on my iPhone, by my count, could take advantage of some kind of notification service. I think it would be a great service.
I got curious when I first started reading the article. It makes it sound like background activity will be allowed (are you misbehaving, AppleInsider? Trying to get clicks?) -- something which would be very cool for programs like Pandora. Apple's reason for avoiding this is, indeed, very legitimate, though. They'd have to police an author's implementation to prevent instability and bogged down phones.