Introduction
Push notifications - love them or hate them, you can't avoid them. Some people never seem to have problems with them, others seem to be plagued with unreliable notifications. There are a lot of things that can interfere with notifications, and hardly any of them are directly related to your device. This article is an attempt to remove some of the mystery from this subject, and perhaps give you some pointers on where to look next time you think you're having a problem.
Why we need them
Push notifications are now the dominant method for sending notifications from online services to mobile devices.
There are a number of reasons why this method makes sense, but the biggest one is simple – it’s much more efficient in terms of battery life than having each application checking for its own notifications using its own method. That consumes processor time, data, battery - all precious resources on a mobile device.
It's far more efficient - in most cases - to have notifications "pushed" to your apps.
Notifications to Windows Phones are sent using the cleverly-named Microsoft Push Notification Service (MPNS), which is a cloud service provided by (no surprises) Microsoft.
Types of push notification
There are three different sorts of push notification:
For all three notification types, your app's cloud service can request that MPNS delivers the notification immediately, within 450 seconds or within 900 seconds.
Toast notifications can be deep-linked to the app - so if you tap the notification it takes you to a specific screen in the app
For toast and tile notifications, the app itself does not need to be running for the notifications to be processed - the OS (via the Push Client service, see below) keeps the notification channel open and handles these notification types.
For raw notifications, the app has to be running on the device for the notification to be handled.
How they work
The process of getting push notifications for your app starts with the app itself.
(From Push notifications for Windows Phone)
MPNS will provide feedback (a response code) to the app's cloud service to acknowledge that the notification has been received by MPNS and will be sent on to the device as soon as possible. MPNS doesn't provide any confirmation that the notification has actually been delivered to the device, although it can give some indication that a notification won't be sent by using a different response code. If the response code that is fed back to the app cloud service indicates a problem, it is the responsibility of the app cloud service to resend the notification.
The response code from MPNS can give a number of different responses depending on what state MPNS believes your device to be in. I'm not going to list them all here (although if you are interested the full list is here: Push Notification Service response codes for Windows Phone). For the purposes of this article, I will focus on one area - the device connection status that MPNS can feed back to the app cloud service.
Device Connection Status
There are three states that MPNS can determine that your device is in.
Connected - the device has an active connection to MPNS and can receive notifications in real time
Temp Disconnected - the device has lost connection with MPNS. The device (more exactly the Push Client service) will try and reconnect to MPNS as soon as a working internet connection exists. In the Temp Disconnected state, up to 30 notifications are queued for up to 24 hours.
Disconnected - After 24 hours in Temp Disconnected, MPNS will change the device status to Disconnected. Once MPNS has decided that your device is disconnected, it will discard all notifications in the queue and not queue any more until the device reconnects. It's still possible for the Push Client service on the device to reconnect to MPNS once internet connectivity is restored, but only notifications sent after connectivity is restored will be sent.
Temp Disconnected is an important state to understand. It is a perfectly valid state for a device to be in, for a variety of reasons:
There are also some reasons that are less obvious:
I think my notifications are broken.... what can I do?
As we've seen in the article above, there's quite a few factors involved with push notifications. So diagnosing problems with them is tricky, and it's hard to come up with a definitive list of do's and don'ts for tracking down issues. But there are a few questions to ask and a few steps you can try.
Is battery saver off?
Do you have a working internet connection?
If you're a Data Sense user, are you within your usage limits?
If the answers to all the above are yes then about the only thing you can do (short of hard-resetting your phone) is simply to power your phone off and back on again.
If you're certain only one app is having a problem then you can uninstall it, restart your phone and then reinstall the app.
If you're having problems with one live tile not updating, it's definitely worth unpinning the tile, restarting your phone and then re-pinning the tile.
Particularly if only one app is having a problem, it's well worth checking the forums here in case others are having problems.
And it's worth testing with an app that you know should generate a notification - Whatsapp (now they've finally got a version using MPNS) is really good for this.
Conclusion
Push notifications aren't as simple as they first appear. There are quite a few reasons why push notifications can appear to be unreliable, and a lot of those reasons are nothing to do with your phone. It's important that an app's cloud service is written to handle the responses from MPNS properly. There can be transient conditions in wifi and data networks which are not immediately apparent to you that can delay notifications, and if these conditions persist then notifications will be discarded.
And finally....
For some apps (Facebook in particular), the logic behind what causes a notification to be sent to the app is not always clear. From observation, it seems to me that Facebook notifications are triggered only in relation to posts that you make (so if someone else likes or comments on your post, or if you comment on someone else's post and then someone else does) or when you are tagged in photos. I get these notifications reliably and consistently. From memory the Android and iPhone versions of these apps triggered notifications for just about everything. So I am theorising that the notification logic for the Windows Phone app is different to those platforms - if you are getting notifications from Facebook for other things, please comment below.
As with all these guides, feel free to post your comments and suggestions below. It's great to get feedback, corrections or clarifications.
Push notifications - love them or hate them, you can't avoid them. Some people never seem to have problems with them, others seem to be plagued with unreliable notifications. There are a lot of things that can interfere with notifications, and hardly any of them are directly related to your device. This article is an attempt to remove some of the mystery from this subject, and perhaps give you some pointers on where to look next time you think you're having a problem.
Why we need them
Push notifications are now the dominant method for sending notifications from online services to mobile devices.
There are a number of reasons why this method makes sense, but the biggest one is simple – it’s much more efficient in terms of battery life than having each application checking for its own notifications using its own method. That consumes processor time, data, battery - all precious resources on a mobile device.
It's far more efficient - in most cases - to have notifications "pushed" to your apps.
Notifications to Windows Phones are sent using the cleverly-named Microsoft Push Notification Service (MPNS), which is a cloud service provided by (no surprises) Microsoft.
Types of push notification
There are three different sorts of push notification:
- Toast - displays a message at the top of the screen for 10 seconds
- Tile - increments a counter on a Live Tile
- Raw - used to send 'other' data to the app - useful for games
For all three notification types, your app's cloud service can request that MPNS delivers the notification immediately, within 450 seconds or within 900 seconds.
Toast notifications can be deep-linked to the app - so if you tap the notification it takes you to a specific screen in the app
For toast and tile notifications, the app itself does not need to be running for the notifications to be processed - the OS (via the Push Client service, see below) keeps the notification channel open and handles these notification types.
For raw notifications, the app has to be running on the device for the notification to be handled.
How they work
The process of getting push notifications for your app starts with the app itself.
(From Push notifications for Windows Phone)
- The app communicates with the OS on your phone (specifically a part of the OS known as the Push Client Service) and requests to be registered for push notifications.
- The Push Client Service then talks to MPNS, and MPNS provides a URI (Uniform Resource Identifier - see Uniform resource identifier - Wikipedia, the free encyclopedia) for the app
- The Push Client then gives the URI to the app.
- Your app then sends the URI to it's own cloud service
- When the app's cloud service has a notification to send, it uses the notification URL to send the notification to MPNS.
- MPNS then routes the notification to your app.
MPNS will provide feedback (a response code) to the app's cloud service to acknowledge that the notification has been received by MPNS and will be sent on to the device as soon as possible. MPNS doesn't provide any confirmation that the notification has actually been delivered to the device, although it can give some indication that a notification won't be sent by using a different response code. If the response code that is fed back to the app cloud service indicates a problem, it is the responsibility of the app cloud service to resend the notification.
The response code from MPNS can give a number of different responses depending on what state MPNS believes your device to be in. I'm not going to list them all here (although if you are interested the full list is here: Push Notification Service response codes for Windows Phone). For the purposes of this article, I will focus on one area - the device connection status that MPNS can feed back to the app cloud service.
Device Connection Status
There are three states that MPNS can determine that your device is in.
Connected - the device has an active connection to MPNS and can receive notifications in real time
Temp Disconnected - the device has lost connection with MPNS. The device (more exactly the Push Client service) will try and reconnect to MPNS as soon as a working internet connection exists. In the Temp Disconnected state, up to 30 notifications are queued for up to 24 hours.
Disconnected - After 24 hours in Temp Disconnected, MPNS will change the device status to Disconnected. Once MPNS has decided that your device is disconnected, it will discard all notifications in the queue and not queue any more until the device reconnects. It's still possible for the Push Client service on the device to reconnect to MPNS once internet connectivity is restored, but only notifications sent after connectivity is restored will be sent.
Temp Disconnected is an important state to understand. It is a perfectly valid state for a device to be in, for a variety of reasons:
- Battery Saver is on
- You have exceeded your carrier's data plan limits
- Data Sense is enabled and you have exceeded your specified limit
There are also some reasons that are less obvious:
- Corporate wifi networks (and public hotspots) can have firewalls, packet inspection devices and proxy servers that can interfere with push notifications
- Your mobile carrier can (and will) limit how long your device is allowed to keep a data connection open on its network. Your device's Push Client service can try and prevent this but there's only so much that can be done. There are a lot of factors that can influence this but it will certainly depend on how busy your local cell tower is.
- Poor coverage, intermittent coverage, or frequent transitions between data and wifi is making your connection appear unstable.
I think my notifications are broken.... what can I do?
As we've seen in the article above, there's quite a few factors involved with push notifications. So diagnosing problems with them is tricky, and it's hard to come up with a definitive list of do's and don'ts for tracking down issues. But there are a few questions to ask and a few steps you can try.
Is battery saver off?
Do you have a working internet connection?
If you're a Data Sense user, are you within your usage limits?
If the answers to all the above are yes then about the only thing you can do (short of hard-resetting your phone) is simply to power your phone off and back on again.
If you're certain only one app is having a problem then you can uninstall it, restart your phone and then reinstall the app.
If you're having problems with one live tile not updating, it's definitely worth unpinning the tile, restarting your phone and then re-pinning the tile.
Particularly if only one app is having a problem, it's well worth checking the forums here in case others are having problems.
And it's worth testing with an app that you know should generate a notification - Whatsapp (now they've finally got a version using MPNS) is really good for this.
Conclusion
Push notifications aren't as simple as they first appear. There are quite a few reasons why push notifications can appear to be unreliable, and a lot of those reasons are nothing to do with your phone. It's important that an app's cloud service is written to handle the responses from MPNS properly. There can be transient conditions in wifi and data networks which are not immediately apparent to you that can delay notifications, and if these conditions persist then notifications will be discarded.
And finally....
For some apps (Facebook in particular), the logic behind what causes a notification to be sent to the app is not always clear. From observation, it seems to me that Facebook notifications are triggered only in relation to posts that you make (so if someone else likes or comments on your post, or if you comment on someone else's post and then someone else does) or when you are tagged in photos. I get these notifications reliably and consistently. From memory the Android and iPhone versions of these apps triggered notifications for just about everything. So I am theorising that the notification logic for the Windows Phone app is different to those platforms - if you are getting notifications from Facebook for other things, please comment below.
As with all these guides, feel free to post your comments and suggestions below. It's great to get feedback, corrections or clarifications.
Facebook
Twitter
Instagram