We create an application that receives notifications that there was a call. For this we create a subscription (communications / callRecords) to receive notification.
My question is, if there are errors when renewing the subscription, then all the notifications that occurred when the subscription was inactive will be lost?
Also I found that we can use Azure Event Hub (Get change notifications delivered in different ways) to send notifications to the hub and then read data from it, but for this case we need to keep subscription up-to-date?
Is there a way to guarantee receiving notifications?
Related
For regular single-device push notifications through APNS, less important pushes can "replace" more important ones, because if the device is temporarily offline, only the last notification per device/app is retained and delivered with APNS.
https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW5
Let's say I'm delivering critical pushes to single devices, and informational, non-critical pushes via a topic-based pushes in Firebase FCM. Would it still be true that the topic-based pushes could replace the critical pushes for an offline device?
A predecessor of mine left behind a design document that said topic-bases push subscriptions would avoid the problem of informational pushes replacing critical ones, but I haven't found any documentation to support that. I'm thinking I might be better off using websockets or similar (maybe via PubNub) for the the informational pushes when the app is in the foreground, and only use APNS/FCM for the critical pushes. Am I right?
disclaimer: this does not directly address the Firebase topic-based aspect of
this question, rather, it provides an alternative solution that has
the same features/implementation for both FCM and APNs with respect to QoS, or more specifically, the ability to retrieve messages that might have been missed while offline.
Publish, Persist & Push with PubNub
PubNub Storage Service
Well, putting APNs and FCM aside, PubNub will persist all of your messages for later retrieval when you enable the Storage service. So when devices are offline, they can receive push notifications (APNs/FCM), and whether or not those notifications are received/acknowledged by the end-user, your app can easily retrieve all messages that were sent while the device was offline.
PubNub Mobile Push Service
The other advantage of using PubNub is that you include the APNs/FCM push payloads in the realtime publish payload and if the device is active/online and subscribed to that channel, then it receives the message in realtime. If the device is not subscribed to the channel, it still receives the FCM/APNs push notification.
NOTE: you must enable the Storage service on your PubNub key set and
configure the retention as required: 1 day, 3 days, ... 30 days or
Unlimited.
When device is offline or not in network, then after getting network access it should receive all the undelivered notification messages. Is SNS taking care of this scenario or it depends on GCM/APNS/WNS services?
The SNS service uses its connections with GCM/APNS/WNS etc, to send push notifications to the mobile devices. It requires credentials from "Push notification Service Providers" in order to send the notification. The notifications are kept in a queue for certain period of time, and it is not guaranteed to be delivered if the SNS service fails to establish the communication with GCM/APNS/WNS.
Have a look at this to know more about working of SNS.
According to this post, the best practice is filtering channel messages on client side. I haven't found a feasible way to do that when push notification is integrated yet. Right now our iOS client gets notified for a lot of useless messages when app is not running.
Filtering PubNub Messages and Push Notifications
This is a shortcoming with APNS, not PubNub. PubNub works in such a way that all subscribers of a channel receive all messages published on that channel. But when an app is in the background on iOS or not running at all, your app does not have the opportunity to process the push notification before it is displayed by the iOS device. Android/GCM does allow your app to intercept the message before it is displayed.
Fortunately, there is only one scenario (that I can think of) where the sender of a msg would receive their push notification version of the message (meaning, you couldn’t intercept and not display it).
user publishes msg
then immediately (quickly) leaves the app (home button, switch to another app, etc)
push msg appears
But if the user stays in the app for a second or two (or long enough to receive the realtime msg AND the push notification), then you can prevent the push msg from being displayed. But there is no need to filter on UUID because you should be suppressing all push notifications from being displayed when the app is active in the didReceiveRemoteNotification delegate, because you already have the realtime message on the subscribe callback.
That link you referenced (Filter Owner Messages on PubNub Data Streams) is only for realtime push notifications and Stephen is calling out a feature that we will be rolling out in the near future which allows you to subscribe to a channel but provide a query that allows you to filter/query condition for the messages on the channel, like, “where uuid != ”, where is the uuid of the subscriber. Then the subscriber would not receive realtime or push notification messages because the server filters them out for you.
For a good overview of push notifications see Sending APNS and GCM Messages to Subscribers and Mobile Push Notification Services in One API Call
For complete push notification setup, configuration and implementation, see the docs for each of our SDKs.
Also, see my answer that describes how to use iOS silent push notifications to do on device filtering. Same thing can be done on Android but no need to do anything special because you always get the opportunity to process the push notification before it is displayed.
The topic I want to discuss may be a duplicate of this question. But still I've a few queries regarding Apple Push Notifications.
I have one app supported on both Android and iOS. The app needs a background service which hits a remote server every minute. The job is simple for Android app but since background tasking is not supported in iOS I need to employ push notifications for iOS app. I am using PushSharp library to deliver push notifications. Apple says that the delivery of push notification is not acknowledged. I cannot afford push notification failure since I need to send a very crucial message through notification. My questions are:
1) What is the failure rate of push notifications?
2) Are push notifications always reliable to send important messages?
3) Assume that the server which is supposed to send push notifications sends a large number of push notifications every minute. What are the chances of push notification failure in such a case?
4) Which circumstances cause push notification delivery to fail?
If you have any useful resources please provide the same. Thanks.
Please find my comments below.Hope this helps.
What is the failure rate of push notifications?
Apple has not disclosed it so far.
Are push notifications always reliable to send important messages?
Delivery of notifications is a “best effort”, not guaranteed. It is not intended to deliver data to your app, only to notify the user that there is new data available.
Please refer - https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html
Assume that the server which is supposed to send push notifications sends a large number of push notifications every minute. What are the chances of push notification failure in such a case?
Only one recent notification for a particular application is stored. If multiple notifications are sent while the device is offline, each new notification causes the prior notification to be discarded. This behavior of keeping only the newest notification is referred to as coalescing notifications.
Please refer - https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html
Which circumstances cause push notification delivery to fail?
If APNs attempts to deliver a notification but the device is offline, the notification is stored for a limited period of time, and delivered to the device when it becomes available.
Please refer - https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html
I think I had once seen a way to tell the Apple Push Notification Service to re-send notifications that were unsuccessfully delivered on their first attempt. Is there a way to do this and can you point me to some information regarding this?
My goal is to send a notification to 100 people and if 10 of them fail to be delivered, have those 10 failures retry.
Unfortunately, as far as I know, no such functionality exists directly. You can check that the notification time to live is long enough, go with a persistent notification solution (Urban Airship), or do your own delivery verification and redelivery through some back end service of your own which would work with Apple's feedback service.
If a delivery failed (APNS connection is lost), APNS would attempt to deliver only the latest notification when the connection to APNS is re-established. Your other notifications would not be delivered if this is the case. If you are looking for something persistent, look at Urban Airship and similar services (Pusher may be another, though I have not used it) that offer functionality similar to an e-mail inbox for various mobile platforms including iOS.
If you're seeing issues with the latest notification not making it through, you might want to check that the TTL is not too short on that notification. That's all that comes to mind.