Push Notifications: Behind The Scenes

What are push notifications for? They are a way for companies to notify users of updates and other information that is of interest to them. They also serve as a reminder to the user that they have the app on their device in the first place. As long as the mobile app is either inactive on their device or active in the background, notifications can be sent to them with valuable and relevant information. From there, you may be able to convert their actions into a sale or lead for your products. This is why implementing them into the app is a smart move and is really important for the success of a mobile application.

The whole point of this article is to discuss the technology behind push notifications to let the startup entrepreneurs understand how do push notifications work.

iOS Push Notifications

iOS Push notifications on Apple devices like iPhone will work just like on Android devices. Here are the features they have:

• Send a short text message
• Play a sound
• The icon of the app can have a badge count set.

These functionalities do not all have to be used. Just use the ones which are needed.

Apple mobile push notifications architecture tutorial

Here are the steps on how do push notifications work on Apple devices

1. Apple Push Notification Service receives a request from iOS for a device token.
2. The iOS app gets this device token. It now serves as the address for where the push notification will be sent to.
3. Your server receives the device token from the app.
4. The server sends the device token and push notification to the Apple Push Notification Service when it is told to do so.
5. The device receives the push notification from the Apple Push Notification Service.

What are the push notifications?

To enable iOS push notifications, a provisioning profile must be established first. Also, the server needs to have an SSL certificate installed that makes it secure since the server is what sends the iOS push notifications. Certain ports need to have an outgoing TLS connection set up as well.

Recommended Reading: “Building an app that makes money”

Badges

The iOS mobile app icon has a small red circle which is located in the upper right corner. This is called a badge and it lets the user know if there is a new message, call, news update, or event notice which they haven’t read yet. The badge will have a number which represents the number of unread notifications and/or messages.

Badges are made primarily for iOS devices. However, there are ways in which you can customize them for Android as well.

The downside to badges is that the number displayed on the icon may not be the exact number of unread messages that are in the app. For instance, you could have a number “three” showing on the icon and then find four unread messages after the app is opened.

Users will often get confused by this and it annoys them. In some cases, the badge will show a number but then they’ll open the app and there is no message there. This makes it impossible to clear the message count because the app needs to have that functionality built into it. That is why the badge count and the total number of messages need to be synchronized.

Badge Count and the Server

Badge counts are not just the responsibility of iOS apps developers. The server is where the badge counts are delivered from. The number of unread notifications on the iOS app is usually managed for each user by the server. When a certain device receives a push notification from the server, the payload and badge count get sent together.

After the push notification is received, the app icon’s badge count is set automatically from iOS. The server keeps the value of the badge count updated at all times.

The server must be notified after you have read a message. This is how the badge count will be lowered. The process for this is as follows:

1. The badge counter gets updated locally.
2. The user sends a request to the server which informs them about the read messages.

Server Request is sent but does not get delivered

After new messages are read, the app icon’s badge count is locally updated. The server then receives a request to update the number on this count. But if the request is unable to reach the server because of a weak or non-working internet connection, then this number won’t get updated. This means when an iOS push notification is successfully sent the next time, the local information is not going to correspond with the count on the icon.

Recommended Reading: “Guide to creating a successful app”

The iOS app developer needs to ensure the request will get delivered to the server. So this can be done by locally saving the badge count’s new value. If there is a failure to deliver the request, have it get resent whenever it gets the next chance to do so.

Remember that users are not the ones who subscribe to these push notifications. So, the devices are the entities that subscribe to them. So, if a user lets someone else use the mobile app on their Apple device after they log out, the device must be what unsubscribes from these notifications or else the push notifications will go to the wrong person. For that reason, pay attention to the permission requests of users.

The device of a user needs to be accessed in order to send them their push notifications. As a result, this requires permission from the user to do that.

The permission request must be received by the user in the right away. If they tap “Don’t Allow” when they first use the app, then it will greatly limit the functionality of the mobile application until this permission is changed.

Explanatory Window

Prior to the permission request showing up on the user’s screen, there can be an explanatory window that shows up which explains the purpose of subscribing to these push notifications. The explanation can emphasize how limited the app’s functionality will be if the permission request is not allowed.

Cheat

The system can be cheated by sending a permission request window to a user that has better appealing options. For instance, the options of the window could show “Later” or “Yes.” Then if they tap “Yes,” the user must confirm their choice one more time by tapping “Okay.” So, it is always better to have the window ask twice for choosing one option. It ensures the user selects the right option.

If they choose “Later,” the user will be given the chance to see the window again, so they can make a choice of “Yes.”

Android Push Notification Services

Google Cloud Messaging

There are many push notification services now available for Android devices. And the Google Cloud Messaging is the basis for most of these services. So, they just expand further on the existing functionality of it. Google Cloud Messaging is considered to be a Google Play Service where information can be sent over just 1 connection to an Android device from a server or the other way around.

The type of data that Google Cloud Messaging can transmit includes the following:

1. Messages which tell the Android app about incoming information from the server that can be downloaded at any time. In most cases, this would be referring to a new text message that can be downloaded.
2. Text messages that have under 4 kilobytes worth of data. The Google Cloud Messaging service is what manages the priority of delivering push notifications.

You can use Google Cloud Messaging for free. Therefore there are no limitations on the number of them you can send.

Firebase Cloud Messaging

Firebase Cloud Messaging allows you to subscribe to the push notifications that you want to receive. It also lets you exchange information with one or more devices which come from the same user.

Here is the breakdown of the process:

1. If someone opens a push notification on a single device, then this notification will no longer be there on the other devices. Obviously, if we were to open a notification on our smartphone and then go on our tablet later in the day, we don’t want the tablet to show us the same new notifications which we’ve already seen before.
2. Pushes can be exchanged between devices by transmitting them with a notification key to the server. So actions and alerts which take place on each mobile device can be synchronized together.

Google Cloud Messaging’s Cloud Connection Server

1. The Google Cloud Messaging server receives the application ID and sender ID information from an Android device.
2. After the registration is successfully completed, the Google Cloud Messaging server sends the Android device a registration ID.
3. Once a smartphone or a table receives registration ID, it goes to the server.
4. Your registration ID will be stored in the database on your server, so it can be used later.

Android push notifications

When a request is sent for a push notification, the Google Cloud Messaging server receives a message from your server which includes the registration ID of the device. Then, the Google Cloud Messaging server sends the message to the mobile device which has that registration ID.

Remember that using Google Cloud Messaging means you must use the mobile app to implement it and then use the server side to implement it. Plus, the registration ID of the device will need to be sent to the server from the Android mobile app.

Alternatives (for iOS and Android)

Other servers are available which allow Firebase Cloud Messaging to have more possibilities or have their own unique solutions which are not dependent on Google Play Services. One alternative is Carnival and Urban Airship. The main benefit of these alternatives is that you can use them on more than one platform. The only downside is that the functionality can be limited in certain cases.

Recommended Reading: “iOS or Android: Which app should you build”

A service alternative such as Parse will give you plenty of functionality and is great if you don’t want to implement push notifications yourself. However, Parse may be too much for the regular functionality of push notifications.

If you want to create an iOS or Android mobile application that will have flawlessly working mobile application, contact us!

Check out our app development services.