Urban Airship sends half a billion push notifications(blog.urbanairship.com)
blog.urbanairship.com
Urban Airship sends half a billion push notifications
http://blog.urbanairship.com/2010/06/29/urban-airship-sends-half-a-billion-push-notifications/
1 comments
How exactly does this work? I dug around the website a bit but couldn't get a clear picture of the basic architecture in my head.
(cofounder here)
Since the post is just about Apple push notifications, I'm going to assume that's what you're asking about.
Apple maintains a persistent connection to every device with push notifications enabled. An application can show a user a dialog asking whether or not that user wishes to receive push notifications - if the user says yes, the application is given a unique identifier called a device token. That device token can then be used to deliver messages from the developer's server via a persistent socket connection to Apple using their binary protocol. According to Apple, this connection should be held open as long as possible - you can't just open it when you need to send messages. They also don't provide any grouping or broadcast functionality.
Where we come in (again, on the Apple push side) is allowing that application to register the device token with us along with any additional information they might want - tags, aliases, time zones, quiet time information. The application developer can then send messages through a simple RESTful API instead of maintaining the persistent connection to Apple. They also get the benefit of grouping, RSS to Push, scheduled notifications, broadcast messages and all of the other things we offer.
Our customers love it because not only do we take care of all of the difficult problems, as well as handling scaling to millions of devices, we provide a lot of features on top of the basic service. It's a lot of work that they don't have to implement and, any time that they have questions, they have a team of experts they can contact.
On top of that, we have AirMail, which allows application developers to use push notifications to drive users into a richer experience.
Since the post is just about Apple push notifications, I'm going to assume that's what you're asking about.
Apple maintains a persistent connection to every device with push notifications enabled. An application can show a user a dialog asking whether or not that user wishes to receive push notifications - if the user says yes, the application is given a unique identifier called a device token. That device token can then be used to deliver messages from the developer's server via a persistent socket connection to Apple using their binary protocol. According to Apple, this connection should be held open as long as possible - you can't just open it when you need to send messages. They also don't provide any grouping or broadcast functionality.
Where we come in (again, on the Apple push side) is allowing that application to register the device token with us along with any additional information they might want - tags, aliases, time zones, quiet time information. The application developer can then send messages through a simple RESTful API instead of maintaining the persistent connection to Apple. They also get the benefit of grouping, RSS to Push, scheduled notifications, broadcast messages and all of the other things we offer.
Our customers love it because not only do we take care of all of the difficult problems, as well as handling scaling to millions of devices, we provide a lot of features on top of the basic service. It's a lot of work that they don't have to implement and, any time that they have questions, they have a team of experts they can contact.
On top of that, we have AirMail, which allows application developers to use push notifications to drive users into a richer experience.