Navigation
Who's online
User login
Syndicate
Apple's iPhone to Use a Centralized Push Based Notification Architecture
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:
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.
Comments
Re: Apple's iPhone to Use a Centralized ....
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.
Just silly
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.
Re: Just silly
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.
Re: Apple's iPhone to Use a Centralized Push Based Notification
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.
Re: Just silly
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.
Re: Apple's iPhone to Use a Centralized Push Based Architecture
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.
-----
sea plants
Sea grapes...Plant roots
Post new comment