I'm having trouble figuring out how FCM behaves when I send a notification to an iOS device that is offline (e.g. in airplane mode, or turned off).
The documentation on the time_to_live property mentions that Currently, time_to_live is not supported for notification messages on iOS. but doesn't provide an explanation of what is done instead. I've tried testing it, and it seems like a push notification sometimes goes through, and sometimes does not, regardless of what I set the time_to_live property to be, although I'm not sure if that's due to throttling or something else happening on the FCM side.
Relatedly, I can't seem to get the delay_while_idle property to work on iOS, although the documentation does not explicitly mention that it isn't available for iOS - notifications that are sent while the phone is asleep still wake the phone, even if I set delay_while_idle to be true.
Does anyone have any insight into how this is supposed to work?
The time_to_live is AFAIK applicable to both Android and iOS. However, since the process of sending the message to iOS devices for FCM goes like this:
App Server > FCM Server > APNs > iOS device
It is safe to say that only the FCM Server makes use of the time_to_live, as per it's description:
This parameter specifies how long (in seconds) the message should be kept in FCM storage if the device is offline. The maximum time to live supported is 4 weeks, and the default value is 4 weeks. For more information, see Setting the lifespan of a message.
Looking around, the behavior for APNs when sending to offline devices is (from the Apple docs):
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.
As of now, delay_while_idle is now deprecated.
The way I know that you could do to wake up an iOS phone (online/connected to a decent network) is to simply set the priority to high.
Related
I have a requirement on communication between 2 android device. When one device triggers a request to another device to do something, the second device starts working until first device ask it to stop.I tried using FCM with only data as notification is not needed.
I have tried Firebase Cloud Messaging but notifications are not consistent i.e some time comes immediately/with 10 min delay/never comes at all.I was using Android simulator.With rest api call also same thing happens. With XMPP i have not tried (even it comes immediately i can not make more than 1000 connection per senderid).I have tried with both use cases with app in background and foreground.
from FCM notification point of view is this delay expected (as it is notification and not real time)?
I am also thinking of using some other XMPP server to have the connection always and send data in real time to achieve this. But don't wanted to spin and scale up/down ejabber kind of server for this kind some small but critical use case.Any pointer would be great !!
I am working on my first Windows UWP app. And planning use Windows push notifications to notify the app about some server updates. This app will not have internet access always. It might be offline for couple of days. So I wanted to make sure whether I can use Push notifications in such a situation. When the notification is sent from the server if that device is offline, how long it will be there without being removed from the queue?
In a article I have read "By default, push notifications expire three days from the time that they are received by Windows Push Notification Services (WNS). If needed, you can override this default with an explicit expiration time." But I am not sure whether this is referring to what I am asking or whether it's saying that when it's delivered to the device, the tile, badge etc will remove that after 3 days.
Can you please clarify this.
By default, push notifications expire three days from the time that they are received by Windows Push Notification Services (WNS). If needed, you can override this default with an explicit expiration time.
I'm not sure where you've read this. However, this is not quite right. The three days expiration time refers to the lifespan of tile and badge notifications when they have been delivered by the device. It does not start from the time that they are received by WNS.
By default, local tile and badge notifications don't expire, while push, periodic, and scheduled notifications expire after three days. So in Expiration of tile and badge notifications, it says
By default, tile and badge notifications expire three days after being downloaded.
And we can change the expiration time for each notification by setting the X-WNS-TTL header. This header is uaually used if you want to ensure that your notifications are not displayed later than a certain time. The TTL is specified in seconds and is relative to the time that WNS receives the request.
For your question, from the Important notes under Sending a notification in Windows Push Notification Services (WNS) overview, we can find that:
When the device is offline, by default WNS will store up to five tile notifications (if queuing is enabled; otherwise, one tile notification) and one badge notification for each channel URI, and no raw notifications. This default caching behavior can be changed through the X-WNS-Cache-Policy header. Note that toast notifications are never stored when the device is offline.
And in X-WNS-Cache-Policy header, we can get more information.
When the notification target device is offline, WNS will cache one badge and one tile notification per app. If notification cycling is enabled for the app, WNS will cache up to five tile notifications. By default, raw notifications are not cached, but if raw notification caching is enabled, one raw notification is cached. Items are not held in the cache indefinitely and will be dropped after a reasonable period of time. Otherwise, the cached content is delivered when the device next comes online.
So when your app is offline, WNS can cache some push notifications for you, but it's hard to say how long they will be cached.
WNS responds to indicate that the notification has been received and will be delivered at the next available opportunity. However, WNS does not provide end-to-end confirmation that your notification has been received by the device or application.
WNS does not guarantee the reliability or latency of a notification. If you want to make sure users can be notified about the server updates, you may need to use some other techniques. For example, you can send an active request to the server for the server updates when the app is online.
The idea of using the push notifications is only to have a notification mechanism that will send a notification when there is a new message waiting to download from the backend service: all the notifications are of the same type e.g. "refresh messages from the server" (the same for Android and iOS).
Are there any limits for the Apple/Google push notifications services?
Assuming that my application will handle more that 100k active users (or even 1M or more users) - would there be any problem with the Apple Push Notifications or GCM services?
If using the push notifications for such a service is not a good idea then what is other solution that could be used for mobile chat applications?
Don't forget that on iOS user may forbid sending notifications, so your app won't receive any even in foreground. Thus, you need to implement your own push mechanism.
Need for push notifications
Especially on iOS you don't have a choice but to use their push notifications service APNS. There is no other way to receive notifications immediately because iOS may kill or neglect the TCP connections of your background app.
On Android it seems possible to use your own background TCP connection to avoid having to use push notifications. But you may still consider the use of the push notifications through GCM for the sake of improved battery usage.
Pricing
Neither APNS (iOS) nor GCM (Android) charge you for the service and you are allowed to send an unlimited number of messages.
Limitations and Requirements
Both services will delete message, when there are too many messages accumulated in the queue for an offline device - which makes sense because there is no point in delivering those messages hours later. You have to take that in to account, when writing your app (just do a poll when going back online).
Depending on the app you are writing, there may also be privacy concerns. Even if you encrypt the message itself, at least Apple/Google know when a notification is sent to a certain device, which may be a deal-breaker for certain high-security applications.
You will also need a server that is able to communicate to both APNS and GCM. There are open source solutions for that (e.g. easyApns for iOS and python-gcm for Android), but how easy their integration is depends on your server and the language it is written in.
My API also provides Push Notifications for Android/iOS. However, I'm only providing the server-side and therefore don't have an Android or iOS client to check if my server really works.
Does anybody know of a dummy client I could use in order to test my server?
For Android, I suggest you create a test application. If you don't have an Android device to test on, you can run it on the emulator. Without an application to test against, it would be difficult to test all the possible error responses that can be returned by GCM to your server. It would also be difficult (if not impossible) to get valid Registration IDs to send notifications to.
For iOS it's more difficult, since Apple Push Notifications are not supported in the emulator. You'll need a real device and a test application. Since the APNS server normally doesn't return responses (unless the message is rejected), having a device to verify that the notifications actually arrive is even more important.
I want to collect device attributes and send them to the mdm server using push notification.
Steps involved are:
create a configuration profile with mdm payload
get device token
use apple push notification service to send a notification to the device.
get back device attributes
do same with multiple devices which the company manages
Questions:
Will the user always need to act on a message or I can send a message onto the device without user action and get the work done?
Do I need an app on the device to send back the token?
It sounds like you're trying to use push notifications to poll iOS devices and return information.
Push notifications do not provide a mechanism to execute code on a device without user interaction. You would have to have an application loaded on the device, and the user would have to click through from the notification to your app.
In iOS, applications generally don't run unless the user is actively interacting with them. There are a few exceptions (e.g. background audio.)
You do need to have an app running to get the device token. You call registerForRemoteNotificationTypes. See APNs docs for more information.
Edited to add more information:
Looks like the MDM protocol uses push notifications to do just what you describe. However, there's nothing about it in Apple's "Local and Push Notification Programming Guide" (linked above).
Apparently Apple keeps tight control over the MDM documentation (see here and here).
However, I did find this paper from blackhat describing how the system works.
My earlier point about not executing arbitrary code on a device without user interaction still applies. There's a finite set of commands that can be executed (see Appendix A).
I came across this question when searching for iOS push notification access payload without user interaction - Just want to add that, in iOS 7 and above, it is possible to send silent push notifications to app, and app can process them without user interaction.
However, I've also found some discussions saying that the silent push notifications are not delivered reliably, in this SO post. That's why I'm still looking for alternate ways to retrieve payloads of the normal remote push notifications. Doesn't look like there's a way.