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.
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.
Lets say I have a chat application and I am messaging another user (User B), our messages are being received normally using sockets, however when the User B goes offline he is disconnected from the socket server however user A is continues to text him so my server issues a push notification to User B's device for every message User A sends. My question is will APNS act as a message broker and queue all the messages until User B logs back in and receives them? Or do I have to store unreceived messages elsewhere
The answer is readily found in Apple's documentation
Apple Push Notification service includes a Quality of Service (QoS) component that performs a store-and-forward function. If APNs attempts to deliver a notification and the destination device is offline, APNs stores the notification for a limited period of time and delivers it when the device becomes available again. This component stores only the most recent notification per device and per app. If a device is offline, sending a notification request targeting that device causes the previous request to be discarded. If a device remains offline for a long time, all its stored notifications in APNs are discarded.
So, no, you can't use APN as a message broker.
You can use the push notification as a signal to wake up and sync with a server-side message queue. RabbitMQ or Kafka might be candidate brokers, and MQTT looks promising as a protocol. You will need to work out how and when you discard the contents of message queues that are not successfully delivered to a device.
I have implemented push notifications in my application and receiving them without any issue. Problem occurs when my app is in offline, if I send more than one notification at that time (eg.5 notifications), when my device comes to online it is receiving only the latest notification.
Even when I checked with the apple documentation it is clearly mentioned that APNS will retain only the latest push notification received from 3rd party server.
But how all the other apps like(social networking and chat apps) could able to send multiple notifications when device goes to online from offline.
Do we have to implement specifically or we have any 3rd party providers or frameworks which gives the service.
If any 3rd party providers are giving the service, how they are doing? does apple gives any feedback server whether the notification is delivered to the device or not so that our 3rd party server can send the undelivered message again?
You can resolve this by external services which gives you several advantages:
1) send push notifications asynchronouslly
2) send multiple push notifications
3) easilly subscribe unsubscribe
I have used Urban Airship and have been sutisfied.
I'm working with AWS SNS API for mobile notification,
along with AWS CloudWatch for message monitoring.
There's currently only 5 metrics to be watched:
NumberOfMessagesPublished
PublishSize
NumberOfNotificationsDelivered
NumberOfNotificationsFailed
SMSSuccessRate
None of these seems to be like message content, recipient platforms, or delivered date/time. (contents that make more sense to marketers rather than developers)
How could I query the history of all my sent messages or a specific message?
SNS does not retain sent messages. You would have to archive the sent messages yourself as you send them.
One idea is to let SNS itself do the message archiving for you, so that you can then query the archive for the analytics that are relevant to you.
This can be done by subscribing a Kinesis Data Firehose to the SNS topic that you use for sending these mobile notifications. You can configure your Firehose stream to store the SNS notifications in S3, Redshift, Elasticsearch, Datadog, Splunk, New Relic, or MongoDB.
Check this out: https://aws.amazon.com/about-aws/whats-new/2021/01/amazon-sns-adds-support-for-message-archiving-and-analytics-via-kineses-data-firehose-subscriptions/
SNS is a wrapper around a number of similar notification APIs. The APIs for Apple (APNS) and Google (Most Android) GCN don't offer any kind of receipt confirmation.
If you need receipt confirmation you would have to build that into the application on the mobile device to inspect messages received that were for that application and there is no universal way to do that either. The other issue is that you are totally at the mercy of the user authorizing notifications.
I suggest you incorporate messaging of your own inside the app and have push notifications as an optional enhancement. In order to get badges to work right you also need cooperation with the app since there is no way using SNS to react to actions taken in the app to clear the notifications or adjust the badge value.
The documentation specifically states that the feedback service will report devices where the app has been uninstalled and won't report devices if the push merely expired.
My question is, will it report devices that have the app installed but the app called unregisterForRemoteNotifications (e.g. the user "signed out" of the app)?
Documentation:
APNs has a feedback service that maintains a per-application list of devices for which there were failed-delivery attempts (that is, APNs was unable to deliver a push notification to an application on a device). Periodically, the provider should connect with the feedback service to see what devices have persistent failures so that it can refrain from sending push notifications to them.
Source: https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Introduction.html#//apple_ref/doc/uid/TP40008194-CH1-SW14
The Apple Push Notification Service includes a feedback service to give you information about failed push notifications. When a push notification cannot be delivered because the intended app does not exist on the device, the feedback service adds that device’s token to its list. Push notifications that expire before being delivered are not considered a failed delivery and don’t impact the feedback service.
Source: https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW3
My answer is YES, APNS does have this service in place along with its feedback service, mainly because the server triggering the push service will have to be notified back to stop sending push notification to the devices which have manually opted out of push notification service.
And since there is no way this information can reach back to the server directly except through APNS, APNS manages to hold this information to provide it back to the server.