iphone firmware 2.2.1 to have push notifications

[stuntfreak]

iPhone firmware 2.2.1 to have push notifications According to RussianiPhone.ru, the iPhone 2.2.1 beta firmware apparently contains support for both push notifications as well as over-the-air MobileMe syncing with Notes support.

For those of you who don't know what is push notifications, push notifications allow you to receive notifications pertaining to a specific application (e.g. instant messanging) on your mobile device without actually having the entire application running in the background, in the other hand saving battery power and improving performance.

iPhone-users were originally supposed to receive push notifications back in September, but according to an email sent by Steve Jobs, ”We’re running a bit late. We want to get it 100% right the first time.”

So lets hope this rumour is true and we will be able to see Push Notification in the next update.

http://reviewinc.blogspot.com/2008/12/iphone-firmware-221-to-have-push.html

 

[Sky Blue]

dude, seriously. Check the front page. You're a couple days late.

https://forums.macrumors.com/threads/608561/

 

[leez]

Ok, let's say it's true then. I'm looking forward for Palringo with push notifications, gadu gadu protocol to be precise.... but the question is, how would it work ? Does the creator of Palringo needs to rewrite the app, so it can have a small code running in the background handling the status and messages of your account, or do they need to start their own server handling your account and when you receive something, they'll push the message to your phone ? And the same thing for every other app (iTunes - new podcasts, Movies - new movies, eBay - auction changes etc.)...

Long story short : Server based or phone background ? (or maybe totally MobileMe connected)

 

[cere]

Ok, let's say it's true then. I'm looking forward for Palringo with push notifications, gadu gadu protocol to be precise.... but the question is, how would it work ? Does the creator of Palringo needs to rewrite the app, so it can have a small code running in the background handling the status and messages of your account, or do they need to start their own server handling your account and when you receive something, they'll push the message to your phone ? And the same thing for every other app (iTunes - new podcasts, Movies - new movies, eBay - auction changes etc.)...

Long story short : Server based or phone background ? (or maybe totally MobileMe connected)

My understanding is that it will be iPhone OS and Apple server based. The apps themselves will not be running at all. The OS will have a listen thread that will accept notifications from the Apple servers. So, for example, when a new IM comes in for AIM, the Apple server push out a notification to your phone (Apple will maintain a persistent connection to your phone), the OS will then update the badge of the app to indicate a message is pending (i.e. put a 1 or 2 etc in the icon) and play a sound of the developers choice.

There are major downsides to this. From a developer perspective, they will have to register their apps with Apple for push notifications. There shouldn't be a lot of additional code required by the developers, if any, for the apps themselves. The OS updates the badge and plays the sounds in the manner specified by the developer when registering the app with Apple. It will probably require the developers to maintain their own servers to handle the messages coming in and then passing them to the Apple servers. This could be a cumbersome and expensive requirement for small developers. It also means a loss of flexibility for many apps. There are some updates that just do not lend themselves well to Push. i.e. GPS notifications because of the inherent lag.

Overall, I think it is a good solution. VoIP apps would benefit hugely. You could be notified of a call coming in without having to have the VoIP app running constantly. Obviously apps like IMs and Facebook will benefit. Carriers will likely hate the fact that their network provided SMS becomes almost irrelevant as other apps can quickly and easily replace the functionality.

The success of Push will come down to how onerous the load on developers is to implement (especially in terms of cost and infrastructure) and then how well the developers implement innovative apps that take advantage of Push.

 

[kdarling]

Ok, let's say it's true then.

Apparently it was just another hoax.

My understanding is that it will be iPhone OS and Apple server based.

Yep.

Originally, the idea was that apps would talk directly to their specific server until such time as the app had to shut down. Then the server was supposed to send user notifications via the Apple servers, at which time you manually restart the app to talk directly to its servers again.

Obviously that idea was full of state holes. How do you know when an app really has shut down vs just bad comms? I suppose an app server could simply start sending Apple based notifications after a delay. This could get into annoying states, though.

There are some updates that just do not lend themselves well to Push. i.e. GPS notifications because of the inherent lag.

GPS notifications wouldn't work at all. How would an app server know where your phone was, unless the phone app was always running? Or perhaps, Apple could add yet another kludge and have the phone always sending its position to an Apple server, to send notifications to another server. Woof.

 

[cere]

Apparently it was just another hoax.



Yep.

Originally, the idea was that apps would talk directly to their specific server until such time as the app had to shut down. Then the server was supposed to send user notifications via the Apple servers, at which time you manually restart the app to talk directly to its servers again. Obviously that idea was full of state holes. How do you know when an app really has shut down vs just bad comms?



GPS notifications wouldn't work at all. How would an app server know where your phone was, unless the phone app was always running? Or perhaps, Apple could add yet another kludge and have the phone always sending its position to an Apple server, to send notifications to another server. Woof.

I think Apple may allow background apps at some point, but only after Push is out and established and only with very strict requirements. I think they want all apps that can use Push to do so. If they were to allow BG now and for all, no devs would ever use Push. If they first establish Push and force devs to at least try to use it for their apps, they could then start allowing some apps that absolutely need to be running as BG apps, but only if the dev applies and can prove that Push just won't work. This would force those that can use Push to do so, allow those apps that have to run as BG to do so and yet still keep the number of BG apps down.

Or they will simply never allow BG apps. Push is a very good solution for some apps, but forcing all updating apps to try to use it is not a workable solution.

 

[leez]

I think Apple may allow background apps at some point, but only after Push is out and established and only with very strict requirements. I think they want all apps that can use Push to do so. If they were to allow BG now and for all, no devs would ever use Push. If they first establish Push and force devs to at least try to use it for their apps, they could then start allowing some apps that absolutely need to be running as BG apps, but only if the dev applies and can prove that Push just won't work. This would force those that can use Push to do so, allow those apps that have to run as BG to do so and yet still keep the number of BG apps down.

Or they will simply never allow BG apps. Push is a very good solution for some apps, but forcing all updating apps to try to use it is not a workable solution.

Ok, right, but at the end of the day the user decides, which app should run in the background (he should anyway). For example IM apps, you're deciding if you want to be online or not.

By the way, I know that iPhone SDK has restrictions about the background running apps. But was thinking, is there any way to code the app so it can reduce its code after pressing the home button (to release RAM occupation) and sort of minimize its window area ? Something like a work around the restrictions of the SDK and make a "fake background run" for itself.

 

[cere]

Ok, right, but at the end of the day the user decides, which app should run in the background (he should anyway). For example IM apps, you're deciding if you want to be online or not.

User decides which to run, but perhaps Apple would decide which are capable of running as BG apps.

By the way, I know that iPhone SDK has restrictions about the background running apps. But was thinking, is there any way to code the app so it can reduce its code after pressing the home button and sort of minimize its window area ? Something like a work around the restrictions of the SDK and make a "fake background run" for itself.

Sure, they could go into an idle state, ideally using very little memory or CPU or other resources and just wait to wake on a thread that listens for updates. This still means that if many apps are waiting, they are potentially cumulatively using lots of resources. It also means lots of open ports, which is less than ideal.

 

[leez]

User decides which to run, but perhaps Apple would decide which are capable of running as BG apps.


Sure, they could go into an idle state, ideally using very little memory or CPU or other resources and just wait to wake on a thread that listens for updates. This still means that if many apps are waiting, they are potentially cumulatively using lots of resources. It also means lots of open ports, which is less than ideal.

Ok agree and that's probably the reason, why Apple is restricting that. Because an average user could experience slow downs while running to much apps in the background. But hey, it shouldn't be so bad at all, when you know what you're doing and when the programmers are coding them well (really small and necessary code in the background.