Written for a project. I developed the backend for a social network app - My own startup business, will release soon.
One of the most common uses for a backend connected to a mobile application is to use it to send push notifications to users. Once you’ve wrapped your head around it, it’s pretty straightforward, but it’s also a common source of confusion for developers new to the topic. This frequent confusion is also the reason I’ve decided to cover it for my introductory technical story for my own startup business app, where I’m a CEO.
Before I continue, you should know that there are plug-n-play services that will provide you with a notification-sending backend, if you’re willing to pay for it (Parse, mobDB, Pushwoosh, Urban Airship, etc.), but since that’s not the way of the warrior, let’s see how you do it from scratch (and for free).
“If you wish to make an apple pie from scratch, you must first invent the universe.” - Carl Sagan
There are several components in my own startup business app that play various roles in the notification sending feature:
1. API endpoint for getting tokens from mobile devices.
2. Resque worker which remains connected to Apple/Google notification servers and feeds off a queue of notifications in Redis.
3. The code that does the actual sending and feedback processing in the worker.
Before anything else, you need to ask the user if they’d like to receive push notifications (iOS notifications, Google Cloud Messaging) and if they say yes, get their device token and send it from the mobile device to the backend server. We store these tokens in a simple ActiveRecord model called Device:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Instances of Device get created when the mobile app calls an API endpoint, which looks something like this (we’re using grape gem for our API needs):
1 2 3 4 5 6
With our mobile app user having a stored device token, we’re now ready to queue notifications for her, which we do through a simple Redis list backed Notification model, which ensures data validity among other things. If a user has multiple devices, the Notification model also ensures they get sent to all of them. Queuing notifications is then as easy as:
In an essence, the Notification model is a Redis list, which serves as the queue for a background worker (NotificationSender):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Having NotificationSender be a queued job constantly running on a worker as opposed to a synchronous connection has the advantage of not trying to establish a connection to Apple’s notification servers for every notification, which is something Apple actively discourages: Apple’s note about notification servers connections.
Thus NotificationSender is a Resque job, which is run every minute and just gobbles up the Redis list of notifications, and sends them according to the platform. We’re using the awesome grocer gem for iOS and the GCM gem for Android. Both are working perfectly and the documentation is very good. The only caveat is that you should watch out for certificates magic in iOS, as you need to have your Apple certificates on the server as well, and you need to export them in a certain way (including the private key) - just follow instructions for the grocer gem to the letter, and you’ll be fine.
With this, you should have a working and easily extendible system for sending important notifications about in-app events to your users. Notifications can drastically increase user retention, just don’t abuse them or they’ll have an opposite effect.