Before reading this article, it is recommended to start by understanding the Direct Push technology:
Today I would like to write about Push Notifications. You all heard the term, but how exactly does it work? How do those notifications are managed by iOS or Windows Phone 7?
A workaround to a real multi-tasking
Usually, a push is done by having an application running in the background, pulling information, or listening to specific events that are pushed from a server.
This is not the case with iOS and Windows Phone 7 which are both lacking a true multi-tasking mechanism – by design, in order to save battery life and improve performance.
Since no application can run in the background and raise its' own alerts, iOS and WP7 include a different approach for providing the functionality of waking up the device, and present a notification/popup message/badge/information label, etc.
How exactly does it work
No server in the world can send notifications to an iOS or a WP7 device. The only servers that can do that are the Apple Push Notification Server (known as APN) for iOS devices and and the Microsoft Push Notifications Server (MPN) for WP7 devices.
In other words, if your app needs to get a notification when a certain even happened, it needs to "ask" to receive this notification from Apple or Microsoft.
Typically, you will have to set up a server side application that will register to the push notifications service, (of course it requires SSL certification, registration, etc. in order to keep this entire mechanism safe). Once a notification needs to be sent – your application server will have to notify the push notification service (this one is Apple's and Microsoft's global services), by sending the message type, body, and other pre-defined parameters. Only those services will be responsible of sending the notification to the proper device.
The device, on the other hand, which is running Apple's iOS or Windows Phone 7 OS, provides some API's for the different apps to "do something" whenever a notification is sent to them. This "handlers" can be activated even if the application is not running (usually it's part of the app configuration settings, and can be turned off if you wish to cancel it). When a push notification message is sent to application 'A', then the operating system receives that message, calls a particular function inside application 'A' in which application 'A' can do whatever it wants: show a message, mark a number inside the badge, etc. Usually, since the push notification message is small, the app (in our example: application 'A') will create a secondary call, this time to its' own application server, to retrieve more information.
From the developer's point of view, if he wants to have push notifications capability in his app, he must have a server with some logic and capability to send a message to the push notification services. He also need to implement a few additional functions in his client side app, that will "do something" whenever a notification is received.
Apple and Microsoft, on the other hand, will take care of the actual "push" of those notifications, and will remember to "wake up" his little app, once those notifications were received in the device. This design is considered to be safer and save battery life, by reducing all the multi-tasks usually required to implement push.
Both push notifications services (Apple's and Microsoft's) are using a persistent IP connection for implementing their push notifications functionality. It is a similar approach to the Direct Push algorithm, only in this case, the push notification server gets the information (and the trigger) when and what to push from many different sources – the server side applications…