Sending Push Notifications To Your Mobile App Users
Late last night I came in from the office and gave Karen the iPad. I then sat down with my laptop, and sent her a message, like below. Proud as punch, I was!
Her response?
"Stop dicking about it's the climax of Miss Marple!"
Seriously, what do you have to do to impress a woman nowadays. Did she not realise it took me two hours of "dicking about" with SSL certificates, Provisioning Profiles, secret keys and the like to get that to work!
Notice in the image above there's an app (row 2 column 2) called NotificationTest with an "unread" count of 2. This is the app I made. The app isn't actually running on the iPad, but if you were to press the View button it would launch and action the message in some way. That's how push notifications work.
Push Notifications?
If you're not a smart phone user you might not have seen a push notification before. If you do use an iPhone, an Android or Blackberry you're probably familiar with the notices popping up to tell you it's your move on Words With Friends or that somebody mentioned you on Twitter.
They're a useful way of "engaging" your users. I say engaging. Potentially they could be annoying. Look at how many other apps want to push things in my face:
Why would Angelina Ballerina or Talking Tom want to send me push notifications?
There's a potential for spam, as I see it, but, for now, if used properly, they can be really useful. You can of course disable them either completely or by application.
Apple have made improvements in iOS5 to the way notifications work to make them more like Android's -- less in your face and easier to manage. Like them or loathe them they're here to stay.
How Did I Do It?
Here's what you need in order to do what I did and add them to your app:
- An Apple Mac (massively over-priced).
- A copy of Appcelerator's Titanium Studio (free).
- An enrolment in the Apple Developer Program (paid)
- An account with Urban Airship (free).
- Patience, guess-work and a few hours to spare (free?).
To get it working I first Googled "titanium urban airship" and quickly found a good tutorial to get me started. What followed was a couple of hours creating and importing SSL certificates, rebuilding and re-installing over and over again (you can only test on the actual device!).
A lot of what followed involved encountering an error, Googling it and applying the suggested solution. But, isn't that what being a developer is about nowadays?
A couple of gotchas that caught me out:
- You'll need a new Provisioning Profile tied to the new app's ID, rather than a generic one.
- The App "key" and "secret" referred to in the sample code are from Urban Airship. You need to register your app on there and copy the key and secrets over.
Good luck!
How Do They Work?
While I got them to work and the geek in me was satisfied with that. The true geek in me isn't completely satisfied. How do they actually work!? How does it know where my device is? Who is actually sending the notification - Apple or Urban Airship?
Anybody know the exact path the packets take to get to the intended device?
Skip to the 
You can subscribe to an individual
"Seriously, what do you have to do to impress a woman nowadays." :-)
Other than that, I'd also like to know more about how it works. The "How It Works" section on Urban Airship's site doesn't really say anything about it.
Reply
I dare say "how to impress a woman" or "how they work" is out of reach for Urban Airship, though I confess no knowledge of their skill or achievement in this area. Being as they have their own airship, perhaps it's just having the best ride in town that impresses the ladies...
Reply
Only Apple is allowed to send the message. Therefore Apple provides a framework which could be leveraged by 3rd party applications.
http://en.wikipedia.org/wiki/Apple_Push_Notification_Service
Reply
Urban Airship simply provide an easy to use service for developers that implements a normal APNS provider behind the scenes. You can use you own web server to act as an APNS provider: http://developer.apple.com/library/.. ..eNotificationsPG/ApplePushService/ApplePushService.html
Reply
Woh. Can anybody translate that page in a Tweet-size nugget that explains how it works?
Reply
How it works with Blackberry is that channel pushes, notification pushes and application / content pushes all are initiated by a web service call. The XMl spells out who gets it. So the path is just like any other network path - it's server to client - where the client has a PIN or Mac Address providing some unique destination. With no infrastructure that I'm familiar with for the iPad, I can't say it's similar but I would guess somewhere in the bowels it's the same approach.
Reply
But surely to know the destination it needs the IP address of where the MAC address was last seen. If, as mobile devices do, the IP changes how does APNS get to know about this? Does the device automatically update the "last seen at" address? Same goes if I toggle between Wifi and mobile network on my phone -- does it update Apple about this?
Jake
Reply
Show the rest of this thread
Push is a very powerful way to keep users up-to-date; we avoid the potential to be "annoying" by updating mobile apps in the background from server data. For example, when a workflow document in a Notes app is ready for approval by a certain individual, it's automatically pushed to their BlackBerry and the application icon changes to an exclamation mark to "subtly" notify them (there's also an option to notify by e-mail too). "Behind the scenes" of our product we're using the web service call approach mentioned in Jerry Carter's comment.
Reply
Bill,
Your comment greatly helps me validate my suggestion to my customer that we implement an icon on desktop feature. Thanks! John Wargo's book - Blackberry Development Fundamentals has a good section on this.
Jerry
Reply
"Anybody know the exact path the packets take to get to the intended device?"
I can explain a bit (I'm one of the Urban Airship co-founders). Each of the major push notification systems work by keeping a persistent connection open between the device and some server. To work around NAT issues, the connection is initiated by the device; that way it works behind most firewalls. So in Apple's case, the device opens a secure connection to Apple, and Apple's push gateway routes messages for each app to that device; a daemon on the device then displays the messages or passes them to an application. C2DM and BlackBerry push work in similar ways, although some details differ.
As for sending a message, we either talk with the platform gateway (in the case of APNS on iOS, C2DM on Android, or BlackBerry Push), or directly to a device for our own Helium messaging system. We open these connections to platform gateways using the app developer's keys on their behalf. So for a normal message the flow is:
1. Your server or application makes an API call to Urban Airship.
2. We transform that message into 1 or more (up to millions if this is a broadcast) messages in the platform's proprietary formats (after verifying them for correctness and that the recipients are available to receive messages) and deliver them to the platform gateway or into our Helium messaging system.
3. The platform gateway sends them to the device.
Hope that helps explain the basics!
Reply
Thanks Adam. It makes more sense now.
It's all just a bit foreign to me, as a web developer, used to stateless connections. The concept of persistent connections doesn't compute in my simple mind. How does a connection stay persistent?
Reply
Show the rest of this thread