Apple begins stress testing iPhone 3.0 push notifications
Apple this week enlisted the services of the Associated Press and called upon many of its iPhone developers to help stress test its new Push Notification service slated for delivery in iPhone 3.0.
In an email sent to iPhone developers, Apple wrote, "We have selected a pre-release version of the Associated Press app for iPhone OS 3.0 to create a high-volume test environment for our servers."
The test application, which requires iPhone OS 3.0 beta 5, will be active over the next week and will then expire. During that time, "AP will be sending a high-volume of real news alerts" to give Apple an opportunity to monitor how well the system works and what optimizations can be made.
Originally planned to arrive last fall, Apple's Push Notification system was delayed after the company realized that it had underestimated the demand third parties would make of the system.
After realizing its original design would not adequately serve the needs of developers or users, Apple pulled the plug and returned to the proverbial drawing board to create a supportable system that was up to the task of serving alerts to the audience of tens of millions of iPhone and iPod touch users.
XMPP pubsub and push notifications
Apple's new iPhone 3.0 push notification system for sending alerts from third party application developers to mobile users is believed to use the same technology as its push notification system for MobileMe and the push notification system planned for Mac OS X Snow Leopard Server.
In all cases, the alert being "pushed" is minimal, essentially a tweet that indicates more information is ready. The notification alerts act like an instant message because that's exactly what they are; an analysis of MobileMe push messages indicates Apple is using the open source XMPP (eXtensible Messaging and Presence Protocol), used in Jabber.
In addition to powering basic Jabber instant messaging in products like GoogleTalk and Apple's iChat and iChat Server, the XMPP specification also supports pubsub (publish and subscribe), a feature that enables XMPP clients to post XML data to a Jabber server, and then allows other client systems to subscribe to the node and receive a notification whenever the data changes.
This powerful feature enables all sorts of applications, and Apple's apparent use of it to power everything from application alerts on the iPhone to email, calendar, and contact changes in its MobileMe cloud services and its server product only hints at the future possibilities and potential of the technology.
Apple's extensive use of the open source XMPP pubsub technology also highlights the absurdity of rumors that the company was about to buy Twitter, a private and proprietary messaging system that has been described as "SMS for the Internet."
In an email sent to iPhone developers, Apple wrote, "We have selected a pre-release version of the Associated Press app for iPhone OS 3.0 to create a high-volume test environment for our servers."
The test application, which requires iPhone OS 3.0 beta 5, will be active over the next week and will then expire. During that time, "AP will be sending a high-volume of real news alerts" to give Apple an opportunity to monitor how well the system works and what optimizations can be made.
Originally planned to arrive last fall, Apple's Push Notification system was delayed after the company realized that it had underestimated the demand third parties would make of the system.
After realizing its original design would not adequately serve the needs of developers or users, Apple pulled the plug and returned to the proverbial drawing board to create a supportable system that was up to the task of serving alerts to the audience of tens of millions of iPhone and iPod touch users.
XMPP pubsub and push notifications
Apple's new iPhone 3.0 push notification system for sending alerts from third party application developers to mobile users is believed to use the same technology as its push notification system for MobileMe and the push notification system planned for Mac OS X Snow Leopard Server.
In all cases, the alert being "pushed" is minimal, essentially a tweet that indicates more information is ready. The notification alerts act like an instant message because that's exactly what they are; an analysis of MobileMe push messages indicates Apple is using the open source XMPP (eXtensible Messaging and Presence Protocol), used in Jabber.
In addition to powering basic Jabber instant messaging in products like GoogleTalk and Apple's iChat and iChat Server, the XMPP specification also supports pubsub (publish and subscribe), a feature that enables XMPP clients to post XML data to a Jabber server, and then allows other client systems to subscribe to the node and receive a notification whenever the data changes.
This powerful feature enables all sorts of applications, and Apple's apparent use of it to power everything from application alerts on the iPhone to email, calendar, and contact changes in its MobileMe cloud services and its server product only hints at the future possibilities and potential of the technology.
Apple's extensive use of the open source XMPP pubsub technology also highlights the absurdity of rumors that the company was about to buy Twitter, a private and proprietary messaging system that has been described as "SMS for the Internet."
Comments
Seriously, I was a bit excited, now lets get it in a more useful app like BeejiveIM and FaceBook.
Won't allow us to play our radios on our existing iPhones though. Interesting, that's about it.
Of course not, that will come with background apps in the future. I would have thought Apple would have allowed you to import your iTunes radio into the iPod app so you could stream it by now, but I guess not.
I just got my first AP News Push. ZOMG common and well traveled technology works in a new way!!!!!
Seriously, I was a bit excited, now lets get it in a more useful app like BeejiveIM and FaceBook.
Ditto.
However, Apple has yet to tell us how it's going to manage sending lots of notifications to users at once. I mean, if servers get to send a message as often as you'd like, does that mean that you're going to constantly keep getting messages? I'd like to see more granular control on an app-by-app basis (like AIM could be real-time, or delayed by a minute, where as AP would be every 5 minutes or so)
Also, for those that aren't aware, push is limited to 256 bytes minus whatever is used to format the message (sound file names and badge numbers are sent as well as plain text). That means long messages definitely won't be allowed.
Oh no..... they are on to mobile phones now.....
Ditto.
However, Apple has yet to tell us how it's going to manage sending lots of notifications to users at once. I mean, if servers get to send a message as often as you'd like, does that mean that you're going to constantly keep getting messages? I'd like to see more granular control on an app-by-app basis (like AIM could be real-time, or delayed by a minute, where as AP would be every 5 minutes or so)
Also, for those that aren't aware, push is limited to 256 bytes minus whatever is used to format the message (sound file names and badge numbers are sent as well as plain text). That means long messages definitely won't be allowed.
I agree, the pop-up notification scheme (plus modifiable app badges) that Apple has been using is not ideal. I wish they would implement"a Today" screen that keeps that info in one place.
They could put it "above" the springboard, just as search is going to be "to the left", accessible with a swipe.
Ditto.
However, Apple has yet to tell us how it's going to manage sending lots of notifications to users at once. I mean, if servers get to send a message as often as you'd like, does that mean that you're going to constantly keep getting messages? I'd like to see more granular control on an app-by-app basis (like AIM could be real-time, or delayed by a minute, where as AP would be every 5 minutes or so)
I doubt we?ll be able to, at least at first. While each app developer will have to maintain servers for their connected apps any Push Notifications (PN) get pushed through Apple?s PN servers. With all the added issues with the service causing lengthy delays I?d expect it to just be a simple push when it gets the notification. comes in then repackaged and gets pushed out again in the queue. I doubt they?d even have an QoS for notifications like IM that one would expect would be more time sensitive than a new article on AP News.
Also, for those that aren't aware, push is limited to 256 bytes minus whatever is used to format the message (sound file names and badge numbers are sent as well as plain text). That means long messages definitely won't be allowed.
Nor should it be allowed. An email header is substantially larger than these messages. I love the concept of PN, I just hope they get it right before the 3.0 launch. Another mess up like last year?s MobileMe launch, even if just an issue for a couple days will not go over well for the service.
I agree, the pop-up notification scheme (plus modifiable app badges) that Apple has been using is not ideal. I wish they would implement"a Today" screen that keeps that info in one place.
They could put it "above" the springboard, just as search is going to be "to the left", accessible with a swipe.
Apple needs to rethink their whole notification system. I like the badges as they are, but they need to be accessible in a glance when you aren?t actively on that app icon. The ideas you mention sound good.
The text box that comes on top of the springboard is too simplistic at this point. There are many examples on nearly every smartphone that does a better job in this area. I hope this is changed by the 3.0 release.
Apple needs to rethink their whole notification system. I like the badges as they are, but they need to be accessible in a glance when you aren’t actively on that app icon. The ideas you mention sound good.
The text box that comes on top of the springboard is too simplistic at this point. There are many examples on nearly every smartphone that does a better job in this area. I hope this is changed by the 3.0 release.
Yep. It's sort of surprising. Apple can be so good with UI stuff, but in a case like this they seem to be feeling their way, as if it never occurred to anyone that "notifications" might become an issue once they scaled beyond a few.
OTOH, they seem to have done a pretty good job in getting a solid first iteration of the iPhone out there, and addressing any weaknesses over time, as they get a better idea of their market wants/expects/needs, so it seems like pretty much a given that they'll do something, at some point. It would be great if a new notifications scheme were part of 3.0, but that seems pretty unlikely at this point. Maybe a point release within the year?
How much of this was always the plan and how much of it is Apple responding to feedback is anybody's guess, but I guess it doesn't really matter as long as problems are solved.
Sheep...
What implications might this have for something like Growl?
I don?t see how Growl could work within this model at all.
Yep. It's sort of surprising. Apple can be so good with UI stuff, but in a case like this they seem to be feeling their way, as if it never occurred to anyone that "notifications" might become an issue once they scaled beyond a few.
OTOH, they seem to have done a pretty good job in getting a solid first iteration of the iPhone out there, and addressing any weaknesses over time, as they get a better idea of their market wants/expects/needs, so it seems like pretty much a given that they'll do something, at some point. It would be great if a new notifications scheme were part of 3.0, but that seems pretty unlikely at this point. Maybe a point release within the year?
How much of this was always the plan and how much of it is Apple responding to feedback is anybody's guess, but I guess it doesn't really matter as long as problems are solved.
I forget which newer OS had I pretty good setup, I think it was Android, but I?m not sure. They have to realize that their system will be limited without a change, and since the PN code wasn?t even setup until Beta 5 and they finally are doing developer testing with one app things cold change a lot in this area before release.
Maybe even a notification app or at least a 3rd-party app that could tie into your notifications. CLick on it and see all the ones you?ve received. Read the ones with text and then enter the app from the text if you wish. Having this accessible from double clicking the Home Button or double tapping the screen would be nice. Something absurdly simple and natural to do a million times a day.
I forget which newer OS had I pretty good setup, I think it was Android, but I?m not sure. They have to realize that their system will be limited without a change, and since the PN code wasn?t even setup until Beta 5 and they finally are doing developer testing with one app things cold change a lot in this area before release.
Maybe even a notification app or at least a 3rd-party app that could tie into your notifications. CLick on it and see all the ones you?ve received. Read the ones with text and then enter the app from the text if you wish. Having this accessible from double clicking the Home Button or double tapping the screen would be nice. Something absurdly simple and natural to do a million times a day.
Right. A full screen, with newest events listed and expandable to lists, with direct access to the relevant apps. Give folks the option to make it their home screen, or invoke it with a simple gesture or tap and give it a cool animation, to distinguish it from "normal" apps.
Of course, as the number of apps that want to let you know something has happened continues to grow, there may not be a great solution to handling everything on one small screen.
The whole point of notifications is that you want to know about them in real time, but if you've got several email accounts, chat , IM, Twitter, calendars, etc., etc. (with surely more to come) all vying for your attention I'm not quite sure how you incorporate that into a system that keeps you notified without driving you crazy. Maybe just an led somewhere to let you know something has happened, and it's up to you to go to the notifications screen? Maybe a secondary dock on the adjacent screen so you can put all of your chatty apps where you can keep an eye on them?
I agree, the pop-up notification scheme (plus modifiable app badges) that Apple has been using is not ideal. I wish they would implement"a Today" screen that keeps that info in one place.
They could put it "above" the springboard, just as search is going to be "to the left", accessible with a swipe.
sounds like more then an ideal solution to me
I agree, the pop-up notification scheme (plus modifiable app badges) that Apple has been using is not ideal. I wish they would implement"a Today" screen that keeps that info in one place.
They could put it "above" the springboard, just as search is going to be "to the left", accessible with a swipe.
That doesn't sound too bad with a nice animation. I don't even think the way search is implemented is a good idea. I would have like to see a triple home button click for search.
For worthless apps, like "news" applications, Pop up set to Off, Sound set to Off, Badge set to On.
For your primary IM application, Pop up set to On, etc...etc...etc...
For a Facebook Notification, a sound and badge might work.
It will take some time to decide how you like to use the combination of 3 notifiers. But it will work brilliantly for most apps that need some ability to receive and notify in the background.
1000X superior to horrible, battery-draining "background" processes. Sorry I like using my iPhone all day, not for 5 minutes while streaming 3G radio while typing an email with one thumb and an SMS with the other.
Watch the keynote. Customization is coming to push notifications. This changes everything. No, the default method is NOT intuitive for a large volume of notifications. No kidding. But you'd have to be a 2 year old not to see past this, to the difference made by.............OPTIONS.
For worthless apps, like "news" applications, Pop up set to Off, Sound set to Off, Badge set to On.
For your primary IM application, Pop up set to On, etc...etc...etc...
For a Facebook Notification, a sound and badge might work.
It will take some time to decide how you like to use the combination of 3 notifiers. But it will work brilliantly for most apps that need some ability to receive and notify in the background.
1000X superior to horrible, battery-draining "background" processes. Sorry I like using my iPhone all day, not for 5 minutes while streaming 3G radio while typing an email with one thumb and an SMS with the other.
I don't think it's a good idea. If the news app is so worthless, then why bother to have a notification in the first place. You have to sift through eleven pages of apps just to see the badge above the icon.
As for IM's, there will be constant stream of popups on the screen and I can see that getting annoying very quickly especially when you may be doing something more important. I can also see sound alerts getting annoying when listening to music. You could very easily be in a situation when you can have more than 3 apps running notifications. Maybe 5 or 6. I can see a situation like this being a real headache.
I think it would be poor way to go about it. There has to be some kind of unified system instead of everything being a scattershot. As for background processes, one day the iPhone will have to have the ability to do two things at once. The best solution is to have both the PNS and background apps but current hardware can't support the latter for third party apps.
Apple is usually far better than this when it comes to UI. I hope they surprise us with something special at WWDC. If you're reading this Apple, FIX THIS!