If the device is offline for some period, APNS will only keep the last notification and re-send it when the device is back-online. My question is, if Parse or any other Push serivces provider has a feature to re-send the notifications that I missed during the offline period. If not, is there any way I can achieve this with current Parse features?
You can configure parse to send notifications when they became available https://www.parse.com/tutorials/ios-push-notifications
When a user's device is turned off or not connected to the internet,
push notifications cannot be delivered. If you have a time sensitive
notification that is not worth delivering late, you can set an
expiration date.
Also check here
Related
Now I have subscribed a push notification to EWS to receive Create or New mail events, but sometime I can’t get heartbeat event from EWS more than one hour.
So, if I want to check whether these push notification subscriptions succeed, is there any tool to check it directly?
Thanks in advance!
No, there is no way of enumerating the current Push subscriptions on a Mailbox, if you successfully subscribed to a Push notification then you would have got a response with the SubscriptionId and status success. To keep a push notification active you need to respond to the heart beat messages which will contain the SubscriptionId (you get at the time of subscription) which are sent every minute see https://blogs.msdn.microsoft.com/webdav_101/2014/04/17/ews-push-what-is-the-statusfrequency-for/ for details on the status frequency . If you have access to the server then server will log errors if it can't successfully send a push notification
Typically with Push notifications the issues are with the server communicating to your listener is that end point isn't reliable or accessible from the server. But the server Subscription can go away without notice if there is a Server issue, so your code needs to track the lack of status update from the server as a sign there maybe problems with the subscription there's a good sample https://blogs.msdn.microsoft.com/emeamsgdev/2011/08/19/ews-push-notification-example-application/ .
Streaming subscriptions can be a better fit for push notification application from a client application persepctive because the client connectivity is a lot more flexible, you can also easily check if a SubscriptionId is still available using a GetEvents request etc. Although if your using Office365 the new Webhooks in the REST API are a much better overall approach.
Cheers
Glen
I have a few problems listening to incoming invitetions,
1) onInvitationReceived is not called when an invite is received when app on (i registerInvitationListener to my gamesClient in onSignInSucceeded)
2) no notification will pop up when the app isnt open aswell.
i was trying to add plusClient in the BaseGameActivity but still no change, is something need to be done to make the app listen to invites that im missing?
do i need to publish it to see invite notifications?
sending invites to someone that doesnt have the app should send him to google play?
Invitations are delivered via push notification (like GCM), so several factors may influence in the system's ability to deliver them. If you don't get invites through the notification bar, there is something wrong with the network or with the device. Push messages are somehow not getting through to it. Can you send a gtalk ping to the device, and does it appear on the notification bar?
Once you do get to a state where notifications via notification bar are showing, but are not able to receive them in your app, I'd check:
(1) Are you registering an anonymous listener as an invitation listener? That's problematic. Take a look at this tip.
(2) Are you waiting a sufficient amount of time? Sometimes it may take > 30sec before a notification arrives, depending on network connectivity. With good network it should be faster, though.
We are developing a Newsstand app, and are currently working on the push notification to let users know a new issue has arrived. From the ambiguous Apple documentation it looks like we will need to send a separate push notification for each user that downloaded the app; each notification should contain a unique device token for each app instance.
The section titled Trust Components seems to imply that you can use the device token or the certificates to authenticate your push notification, but it also implies you need both.
Is it correct that we will need to send out a separate push notification for each installed instance? Can we really not send one push notification and have Apple notify all the users of the app that a new issue has arrived?
Short answer is YES the statement you made is correct.
You have to send out push notification to each device token which must be stored in your server (provider). The preferred way to send multiple notification is to not make multiple connections but reuse one to send multiple notifications. Below is the paragraph from Apple Doc
You should also retain connections with APNs across multiple
notifications. APNs may consider connections that are rapidly and
repeatedly established and torn down as a denial-of-service attack.
Upon error, APNs closes the connection on which the error occurred
Does APNS Feedback Service accounts all the reasons that could cause notifications delivery failure. There can be multiple reasons for failure like
a. The user has uninstalled the application.
b. The device is switched off for a longer duration.
c. The device does not have internet connection.
The apple doc on "Feedback Service" says that
"If a provider attempts to deliver a push notification to an application, but the application no longer exists on the device, the device reports that fact to Apple Push Notification Service. This situation often happens when the user has uninstalled the application"
This seems to suggest that APNS only invalidate the devices which have uninstalled the application. Can anyone please clarify if my assumption is correct?
How many times does APNS attempt to deliver the notification before it blacklist the device in the feedback service?
As you have correctly stated, the Feedback service will only return device tokens that have uninstalled the app.
Regarding situations b and c:
b) and c), taken from the Quality of Service section in the official Push Notification guide it states the following:
Apple Push Notification Service includes a default Quality of Service
(QoS) component that performs a store-and-forward function.
If APNs attempts to deliver a notification but the device is offline,
the QoS stores the notification.
It retains only one notification per application on a device: the last
notification received from a provider for that application.
When the offline device later reconnects, the QoS forwards the stored
notification to the device. The QoS retains a notification for a
limited period before deleting it.
I believe this answers those queries; in relation to "how many attempts before being blacklisted" - I sincerely doubt you will find any specific numbers for this. (else people would use them as workarounds)
After completing the delivery of a message, I would highly recommend connecting to the feedback service, seeing if any tokens were rejected and then immediately removing these from your database. Hope this helps!
It is widely known that you can disable the reception of Apple notifications from the applications that allow it. But does anyone know if the disabling is made locally (ignoring the notifications Apple sends to the app), or does Apple stop sending you notifications from it's servers?
I've finally discovered in depth how Apple Push Notifications work: if you disable the notifications on one app, Apple does not know of this behavior instantly, so it keeps sending notifications to the device whenever they are created. These notifications will try to reach your app, but instead they will be sent back to Apple with an error code. That feedback will be sent to your servers (the ones that order Apple to distribute your app notifications). You will have to check that information regularly so that if one device has returned a certain amount of "errors", it means that the user has disabled the notifications (or has even uninstalled the app)
Further information: Local and Push Notification Programming Guide