I've configured my Azure Notification Hub to have a custom Registration Time to Live equals to 1 day.
However even if this TTL has expired for a particular registration, Azure Notification Hub still sends pushes there, and I receive them on my mobile devices.
Also expired registrations still visible at the Azure Notification Hub.
here is an example of expired installation:
GET https://{{hub-namespace}}.servicebus.windows.net/{{hub-name}}/installations/OLEKSA3?api-version=2015-01
with response
{
"installationId":"OLEKSA3",
"pushChannel":"{{my-app-device-push-channel}}",
"pushChannelExpired":false,
"platform":"apns",
"expirationTime":"2020-02-01T15:55:11.8088897Z", <<<<
"tags":["o:67890","r:dev","u:3"]
}
Is it possible to avoid sending pushes to expired registrations? Does notification hub remove expired registrations?
Thank you
Just for summary from this link created by yourself for others' references.
Does notification hub remove expired registrations?
It is expected behavior for Notification Hub that expire registrations will be deleted 7 days after the TTL expiration.
Is it possible to avoid sending pushes to expired registrations?
Not support yet so far.You post 2 points which could be improved by NH:
Expired registrations can still be availiable at the hub for up to 7 days (until the maintainance job clears them), and push notifications will be sent to them. Therefore, I suggested that the hub should avoid sending push notifications for expired registrations.
If for some reasons your device installation id has changed (for example, you are using iOS identifierForVendor property, which is unique but not constant) then hub will continue to send it push notification until you remove it (or you set the registration TTL and it will be removed by the maintainance job). This looks like an issue in hub when it unable to detect outdated channelIds.
Related
Need some design advice for on implementing a push notification system. I am using for the backend Symfony 3, Doctrine and postgres as the database. The notification system will have two types of notifications:
1. Instant notifications
2. Scheduled Notifications
Instant notifications are when an action is performed in the backend and a notification is instantly pushed. For example, a notification when a user is deleted in the database.
Scheduled notifications is for a notification that has not been triggered yet but will at some known time in the future. The notification will only be triggered when it reaches that set time. For example an Alarm clock.
Based on this I have designed simple tables as follows with some mock data:
So with above information the API concept is at user’s device such as mobile phone, it will run a GET/notifications API every 2 mins. The API will return notifications that are before the current date and has not been dismissed for that user. For example, if USER2 executes the GET/notifications with the current date at 18th April 2017 it will return record 3.
My question is this type of design acceptable if not what would be the conventional practice? Also with many users running the same GET API every 2 mins is there a potential to slow down the system? I’m guessing about at most 3000 users.
Finally, as the notifications table grows in records will postgres slow down when performing this API?
Who ever has taken the time to read it all the way through thank you, I am very grateful for any advice.
Push Notification.
If your client devices are asking for notifications via a GET API call, Its not called Push notifications. Down the time, it will be heavy on server side to handle too much unnecessary requests as all users might not have that much notifications.
You shouldn't let your clients call. You should push the notifications to client instead. The iOS and Android apps can be configured to get push notifications through deviceId and uuid. Ask your mobile developers for the same. These days even HTML5 browsers are supporting push notifications.
For storage :
I think you don't have to store instant push notifications in database at all, unless you have an application level requirement to store the logs.
You should only store scheduled notifications so that a Cron job can pick and push those notifications when they are due.
Hope this helps!
I have set up a CKSubscription* so that I receive changes to a record type.
I'm using the public database.
When I test with the same user (same iCloud account) I receive the notification.
If I use a different user (different iCloud account) I don't receive the notification.
Are subscriptions designed to only work between devices of the same user?
Here is the documentation that describes subscriptions:
Use a CKSubscription object to track changes occurring on the server.
A subscription acts like a persistent query on the server that can
track the creation, deletion, and modification of records. When
changes occur, they trigger the delivery of push notifications so that
your app can respond appropriately.
https://developer.apple.com/library/ios/documentation/CloudKit/Reference/CKSubscription_class/index.html#//apple_ref/occ/cl/CKSubscription
I would expect to receive a notification no matter which user edits the record, and subscription predicate should still match.
UPDATE
*Every user has a subscription with the same predicate, essentially focused on a single recordType with a particular property value.
The payload for this subscription is only to push shouldSendContentAvailable=YES.
The documentation reads:
When this property is YES, the server includes the content-available
flag in the push notification’s payload. That flag causes the system
to wake or launch an app that is not currently running. The app is
then given background execution time to download any data related to
the push notification, such as the set of records that changed. If the
app is already running in the foreground, the inclusion of this flag
has no additional effect and the notification is delivered to the app
delegate for processing as usual.
The recordType's security permission is:
FURTHER UPDATE
Checked the logs of the device not receiving the push when it should and saw:
apsd[85]: Silent Push: Deny app not available
Rebooted the device and now it works fine!
This behaviour was due to a mistake in how my CKSubscription was configured. If we want all users to receive notifications from the subscription then it should not have a zoneID set (should remain nil). I was setting the zoneID to the value from the defaultRecordZone, this will restrict the notifications to the current user only as the defaultRecordZone's user is the current user.
UPDATE
Finally solved the problem. Not only was it an issue of zoneID, but there also seems to be a bug. My subscription notificationInfo simply had shouldSendContentAvailable set to YES. This doesn't cause the subscription notification to fire for changes made by anyone other than the current user (u1d1->u1d2, but not u1d1>u2d2). I simply added an alertBody and the notifications start firing.
Anyone else face this issue?
UPDATE 2
Rebooting the device solved the issue.
And to add another dimension to the answers above, CKSubscriptions are logged 'per iCloud Account' not per device. All devices logged into the same iCloud Account (*) will receive all notifications based on any subscription entered by any device under that iCloud Account. When the above refers to 'user' they mean 'any device logged into that iCloud Account'.
except for the particular device that modified the file leading to the notification
Every user should create it's own subscription. A subscription is only valid for the user that created it. On app startup you should test if the subscriptions are there for the current user (you could use the database.fetchAllSubscriptionsWithCompletionHandler function for that)
Then if there is a subscription for a recordType and predicate, then that user should receive the notifications of there are any changes for records within this recorType and predicate.
There is no guarantee that every change will be pushed. If there are multiple notifications, it could happen that you won't receive all. This is why after receiving a notification you should also query for outstanding subscription notifications on the server (using CKFetchNotificationChangesOperation)
If you create a record on your device, then you should not receive a notification for that on that device. So if you have a data colleciont for a subscription in your app, then you should also update this after you modified the data.
If you think this is complex, then you could try EVCloudKitDao
I am developing an application which requires push notification.
I have provided Push Notification feature but I need to know what if a user has turned off his/her iDevice for 2-3 days or for whatever reason, the device is turned off for few hours/days/minutes etc.
If I send a push notification at that point of time, would the user receive the notification when he turns on his device.
Thanks
If you are sending multiple notifications to the same device or computer within a short period of time, the push service will send only the last one.
Here's why. The device or computer acknowledges receipt of each notification. Until the push service receives that acknowledgment, it can only assume that the device or computer has gone off-line for some reason and stores the notification in the quality of service (QoS) queue for future redelivery. The round-trip network latency here is of course a major factor.
All of this points out that the intent is that a notification indicates to an app that something of interest has changed on the provider, and the app should check in with the provider to get the details. Notifications should not contain data which isn't also available elsewhere, and they should also not be stateful.
Any push notification that isn't delivered immediately was queued for future redelivery because your device was not connected to the service. "Immediately" of course needs to take latency for your connection into account. Outlying cases would be beyond 60 seconds as APNs will time out at that point.
Still you have any query then you can refer the below link
http://developer.apple.com/library/ios/#technotes/tn2265/_index.html
Does anyone know what could cause a Apple Push Notification token to go stale? After some time the Push token no longer works for a given device, while other tokens work. If I delete that account for that device and create a new account for that device and receive a new Push token from Apple, then the new Push token works fine.
Edit 1 - This post claims that push notification connections fail after 200 notifications and the connection has to be restarted. Has anyone else had this experience?
Could the Push token go stale because Apple saw the Push connection for that device being brought up and down too often in a given period of time? If so, is there some way to programmatically know when a Push token has gone stale?
Your application should register for push notifications every time it is launched. This way you will get the current device token every time it is launched, and if it changes (you can store the old copy in the app in order to know that), you can send it to your server.
You can see a related answer with quotes from the APNS guide here.
When the app is not running and user receives, say 5 push notifications, are those push notifications saved somewhere? Or is that data gone? I need to access all 5 push notifications when the app runs the next time.
To clarify, I already understand that you can access the push notification that caused the app to run. What I'm asking is to get all push notifications since the app got terminated.
The APNS service will only retain the most recent pushed message to a device - assuming there is still at least one other app installed AND the user allows push notifications for it, then this one stored message will be delivered the next time the user has an Internet connection.
For better information on the quality of service that Apple has implemented for the APNS service, see my other answer here:
Clarification on Apple APNS