Monday
Jun092008
Apple's iPhone to Use a Centralized Push Based Notification Architecture
Monday, June 9, 2008 at 5:10AM
Update 2: Hank Williams says iPhone Background Processing: Not Fixed But Halfway There. Excellent analysis of all the reasons you need real background processing. Hey, you can't even build an alarm clock! Hard to believe some commenters say it's not so..
Update: Josh Lowensohn of Webware tells us Why users should be scared of Apple's new notification system.
A big item on the iPhone developer iWishlist has been background processing. If you can't write an app to poll for new data in the background how will you keep your even more important non-foreground app in sync? Live from the Apple developer conference we learn the solution is a centralized push based architecture.
Here's the relevant MacRumorsLive transcript:
Thanking the developers for their hard work. Now talking about how the #1 request has been background support. Apple wants to solve this problem.
The wrong solution would be to allow for background processes -- bad for battery life and performance. Poking fun at Windows Mobile's task manager.
Apple has come up with a far better solution -- a push notification service available for all developers.
When the user quits the application, Apple will push updates from their servers to the iPhone. The developer's servers push the notifications to Apple. These updates can include badges, sounds, and custom messages. This requires just one persistent connection and is extremely scalable.
Apple has come up with a far better solution -- a push notification service available for all developers.
A poll based architecture is good when system capabilities are relatively symmetric. Clearly mobile phones are restricted along a number of dimensions, the most important being battery power. Having a large number of apps constantly polling for updates sucks down battery power faster than vampires at phlebotomist convention.
So Apple's logic is sound. Keep a single connection over which data is pushed and work on the phone is minimized. You also maximize battery life and maximize bandwidth usage because data can be aggregated on the server side and be sent in large chunks rather than a random distribution of small packets.
The mechanics of how this works isn't clear. Must all apps needing to push data to a phone become part of Apple's private iPhone cloud? Smart for Apple as it gives them complete control. For sculptors of the ultimate user experience you want total control. Not so good for developers as it's just another garden with a very high wall protecting it.
Update: Josh Lowensohn of Webware tells us Why users should be scared of Apple's new notification system.
A big item on the iPhone developer iWishlist has been background processing. If you can't write an app to poll for new data in the background how will you keep your even more important non-foreground app in sync? Live from the Apple developer conference we learn the solution is a centralized push based architecture.
Here's the relevant MacRumorsLive transcript:
A poll based architecture is good when system capabilities are relatively symmetric. Clearly mobile phones are restricted along a number of dimensions, the most important being battery power. Having a large number of apps constantly polling for updates sucks down battery power faster than vampires at phlebotomist convention.
So Apple's logic is sound. Keep a single connection over which data is pushed and work on the phone is minimized. You also maximize battery life and maximize bandwidth usage because data can be aggregated on the server side and be sent in large chunks rather than a random distribution of small packets.
The mechanics of how this works isn't clear. Must all apps needing to push data to a phone become part of Apple's private iPhone cloud? Smart for Apple as it gives them complete control. For sculptors of the ultimate user experience you want total control. Not so good for developers as it's just another garden with a very high wall protecting it.
Reader Comments (8)
The thing that bugs me the most about this is that you can't have the iphone with all it's capabilities act independently of your servers. Want a chat program? You're servers have to login for your iphone and push the messages to your phone. So something that only cost development time (for you anyway) now has to be an ongoing service.
This is "Background as a Service" and while I agree apple has valid concerns, I'd rather some sort of background network framework, then an entire service.
This is dumb. How about giving us some guidelines for memory/processor usage when backgrounding apps and let the customer decide if the battery hit is worth it?
What about an RSS reader that is to pull updates every 30 minutes? Or a third-party calendar / task list app? Is Apple suggesting that we have to run a *server* (for an app that doesn't inherently require a service backend) and we push an event to the iphone that just tells the app to update? What if your app has more than just a few users? It's definitely not scalable and only seems to be a "fix" for IM or chat applications - which make up a small portion of apps that require backgrounding.
It just seems so silly... Apple, just let us run background apps and be the ones responsible to our customers.
Get over it people. This is an excellent solution. This is 2008 and software as a service is the only way to. Besides, If im not wrong, The iphone whould have the ical services for any calendar related services.
Enough of giving people half assed software without any backend support. The only way to go is a full server to customer service.
My main problem with this is the fact that this has pretty big security implications. If you want an IM client you'll have to give out your usernames/passwords to the developers of that app because it's their servers that need to maintain connections to a Jabber server, AIM, MSNM, etc. I really don't want to do that. I also really don't want all my instant messages to go through the server of some third party developer. It's already bad enough that those messages get routed through Microsoft/AOL.
If this is "an excellent Solution", then please tell me how to collect GPS data from local device through Apples servers if the users opens another app or their iphone goes to sleep. I can't consider this an excellent solution because it does address an entire class of problems.
Software as a service is the only way to go if you have very deep pockets to pay for massive server farms or cloud resources and enjoy dealing with massive scalability issues. It is 2008, and Peer 2 Peer is still more reliable and economical then massive server farms.
And alas software as a service doesn't do a thing for customer service. My MS Office and Google Docs have the same non existent customer service.
Fine, they are going on with their this new featured push button architecture but lets hope its doesn't go around bugging more to use than it was in the usual case.
-----
http://underwaterseaplants.awardspace.com">sea plants
http://underwaterseaplants.awardspace.com/seagrapes.htm">Sea grapes...http://underwaterseaplants.awardspace.com/plantroots.htm">Plant roots
ASince I tapped into iPhone Development with SDK, i’ve always wondered where is the background processing? Basically, poll a new data to keep things in sync with the main server. That was basically the wish that everyone was asking for.
But now, with iPhone 2.0 announcement, it was announced that the centralized push based notification architecture will be used. Basically, Apple servers (mediator) will push data to iPhone and iPhone Application will push back once the App is closed. And the push will be based on persistent connection with a huge chunks of packets instead of small ones.
Here is something I got from Todd Hoff, A poll based architecture is good when system capabilities are relatively symmetric. Clearly mobile phones are restricted along a number of dimensions, the most important being battery power. Having a large number of apps constantly polling for updates sucks down battery power faster than vampires at phlebotomist convention.
So Apple’s logic is sound. Keep a single connection over which data is pushed and work on the phone is minimized. You also maximize battery life and maximize bandwidth usage because data can be aggregated on the server side and be sent in large chunks rather than a random distribution of small packets.
The mechanics of how this works isn’t clear. Must all apps needing to push data to a phone become part of Apple’s private iPhone cloud? Smart for Apple as it gives them complete control. For sculptors of the ultimate user experience you want total control. Not so good for developers as it’s just another garden with a very high wall protecting it.
And oh, I am getting the new iPhone for sure in less than a month….
___________________
Submited by : http://www.librosgratisya.com/php_Autores_Libros.php?Autor=513">Descargar Libros
There is an open source PHP/MySQL back-end for APNS. So if you want your own integration of push notifications on your own server, here you go :)
Main Link: http://www.easyapns.com
Google Code: http://code.google.com/p/easyapns/
Google Group: http://groups.google.com/group/easyapns