I noticed that the firebase documentation says the following:
If a notification payload is provided, or the content_available
option is set to true for a message to an iOS device, the message is
sent through APNs, otherwise it is sent through the FCM connection
server.
Can someone please explain what that means?
I thought ALL push notifications sent to iOS devices, are first sent to Apple, and then forwarded by Apple to the corresponding device/s, but here it is implied that they're sending messages directly to the device?
Is that even possible when the app is shut on iOS?
I'm confused,
thank you.
When the app is in the foreground, FCM can connect directly rather than go via APNs for data type messages. Messages sent when in the background are delivered via APNs as you'd expect. You can actually take a look at the source of the FCM client if you're so inclined!
You can control whether this is used with the shouldEstablishDirectChannel property.
From the sending perspective, you don't need to worry too much about this - its handled transparently as part of the FCM service based on the type of the message and whether there is a client connected.
From my understanding after reading the document, it might be trying to state that:
If the notification can be inferred to be targeted to an iOS device (whether from notification payload or the content-available key), it bypasses FCM and gets sent to APNS directly for optimization as it's known for 100% to be destined to APNS anyway.
Otherwise, it will be sent to FCM and be routed to wherever it should go from there. It might still be a notification for an iOS device and be sent to APNS from FCM, but it just can't be inferred.
Related
I googled but not able find my desired solution. My Questions are following related to push notification.
What if registered device turned off its push notification and server broadcast notification. Is notification place in waiting list (e.g when device turned on notification it gets notification) ? or Reject ? or Server keep sending ?
If server keep sending how to tackle this situation, I mean is there any way that we can find our some client turned off notification then we'll not send notification to APNS?
If someone already asked then kindly reference those question instead of down vote.
Looking for answer. Thanks
APNS docs here: https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1
Your server - what Apple calls the provider - maintains a list of device tokens that have registered for your notifications.
When a device turns off push notifications, you should remove its device token from your list.
So far as I know, if you attempt to push to a device that has turned off push notifications, your provider will receive an error, and the push notification will not be queued. It should be easy enough to test using a device.
My app gives and takes message by APNS.
but if client's notification set off , client doesn't receive message by the other client sent by APNS.
Is this wrong way?
If it is not, how does client receive message When client's notification sets off?
You can't rely on APNs alone for this. Notifications can be turned off and even if they are on, APNs is a "best-effort delivery" service. This means it makes no guarantee that the client will ever receive the notification, but it tries its best to deliver it. Your app should query the server for new messages, and notifications can help you make the query at the right moment. Your server can notify your app that there's a new message, then the app calls the server to get that message. But of course since notifications aren't guaranteed, your app has to reach out to the server at other times also i.e. when it enters foreground.
I want to add GCM 3.0 for iOS to my app for some specific communication between my client and server, but my app already uses regular Apple Push messages for other things, and I want to keep it that way (i.e. I don't want to switch everything over to GCM).
I understand that GCM for iOS sends downstream messages through APNS when the app is in the background. My question is, will this interfere with my existing uses of Apple Push messages? For example, maybe GCM's push message will have a badge of zero and that removes my app's badge that was set by my regular pushes?
If you will have both your own APNS provider and GCM sending notifications to APNS, they will interfere with each other, but not in the way you expect. The problem would be with receiving feedback from APNS: GCM will receive a part of feedback periodically without knowing what feedback your own provider received, and vice versa, which may cause bad behavior as it seems from APNS perspective and lead to APNS connection drops.
As for using GCM without APNS, apparently GCM doesn't encourage that.
How do iOS "push" notifications get delivered to a particular device without that device needing to poll a server?
For example, let's say I have received a new message on Facebook. Facebook notifies Apple that my device should receive a notification as such. But how does Apple know which device/IP to push the message to?
Each device can be updated with data using their own unique device tokens. This picture explains everything . .
It was too much for me to put in a comment so.
From the documentation.
Apple Push Notification service (APNs) propagates push notifications to devices having applications registered to receive those notifications. Each device establishes an accredited and encrypted IP connection with the service and receives notifications over this persistent connection. Providers connect with APNs through a persistent and secure channel while monitoring incoming data intended for their client applications. When new data for an application arrives, the provider prepares and sends a notification through the channel to APNs, which pushes the notification to the target device..
I suggest reading the documentation for more information and how to use and configure. It's all there.
Push Notifications
I created an infographic to explain the workflow of push notifications. Hope this is helpful.
Device does not keep polling the server for the push notifications.
To keep it simple, consider an iPhone is connected to internet. On connecting to internet iPhone establishes connection to Apple Push Notifications server this connection is open connection which means data can be thrown to iPhone from server the moment data arrives to server.
Apple does not use HTTP protocol for Push notifications but if you understand HTTP Protocol its almost a similar methodology.
http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push
There is a really nice exaplanation of push notifications in this article.
In iOS, apps can’t do a lot in the background. Apps are only allowed to do limited set of activities so battery life is conserved.
But what if something interesting happens and you wish to let the user know about this, even if they’re not currently using your app?
Our app uses APNS to receive Push Notifications. However, our client claims that some of their devices were not receiving notifications and argues to they 'must' make sure the notifications to be delivered 100%. But I have read somewhere that APNS is not 100% reliable and there should be cases which the notifications are not delivered.
I'm currently panic at how we could make sure APNS to received anytime. I have read that a case which may APNS not delivered (device may offline). But our test showing that even the device is online (Wifi or 3G), sometimes APNS were not delivered.
Is there any specific case which may APNS will not delivered? Or is there anything we (developers) can do with codes to make sure to receive all notifications? What I have done in the code is just registering the app to remote notification and write didRegisterForRemoteNotificationsWithDeviceToken, then throw the device token to our server.
Any help would be appreciated, for our client almost kill us if ALL of their devices not receiving APNS!
APNS is based on Apple Servers, and Apple doesn't give any guarantee on successful message delivery.
If the app is open (i.e. the user is using the app) while the notification arrives, iOS doesn't show a notification message, you need to handle it.
Notification shows up only when the app is backgrounded or killed.
Also implement feedback service on your server side; will help you get rid of old unwanted tokens (users who deleted the app or disabled notifications through settings).
Don't send too many notifications to a device within a short span of time, because APNS caches only 1 message/device (if the device is offline). So it can deliver the message when the device comes online. Am not sure how long the message is cached though.
Or just implement Pusher... http://pusher.com
We're facing the same problem. As everybody said, APNS is a best effort service so you can't be sure every notification will be delivered, but what you can do is to be sure of which ones have been received. This is what we're about to do. We register in our backend each notification que ship and the mobile app reports back each notification it receives. Then we set a maximum time of waiting for a notification to be received, if we don't receive the report back we try again.
I hope it might be helpful to someone (even 2 years later)
It says it quite clearly in the Apple Docs that it is not 100% gauranteed and nor should it be used as so. Its sent with "best effort".
As per Apple's guidelines, APNS is not 100% reliable service which means your app may not get push notifications from Apple servers due to some of the following reasons:
Device is offline
Your app is in the foreground state, you need to manage the push notification.
Note: Apple rejects apps which make compulsion to use notification services. (I have faced it in one of my App)
For more information, you can look into this answer
https://stackoverflow.com/a/25830955/3278326