We are using the DelegateAuthenticationProvider approach with Graph in order to manage Graph subscriptions on behalf of our users. I am in the process of writing a service that processes any lifecycle notifications that we receive as per https://learn.microsoft.com/en-us/graph/webhooks-outlook-authz.
I am just wondering with regards to the "subscriptionRemoved" life cycle event, if we are managing the subscriptions using essentially a generic account, does this mean that we won't get notified if the users account password changes or is revoked? In this case, will the notifications keep on flowing as the generic account won't be revoked or is it based on the account that we are creating the subscription for?
Sorry if thats confusing.
Ok i will do like the following: If my app is subscribing and when i see one of the event happens, (1) User's password has been reset (2) User's device is out of compliance (3) User's account has been revoked, then Microsoft Graph sends a special lifecycle notification, subscriptionRemoved.
As my app is subscribing to change notifications then i would listen to the subscriptionRemoved and missed signals. In addition, i will do this: (a) when i receive a subscriptionRemoved lifecycle notification, the app should recreate the subscription in order to maintain a continuous flow. (b) On receiving a missed lifecycle notification, the app should resynchronize resource data using Microsoft Graph.
Related
I have application who is getting notifications from Outlook, it is subscribed for update,create changes in users mailboxes. I am getting notifications all day long even if the users are not active (It is their sleep time). Can I know how notifications are sent to me?
There are all sorts of background tasks (assistants), both time based and event based that wake up and do work on the system. In addition, there may be apps that the user has given permissions to operate on their mailbox that may be doing something behind the scenes. Exchange doesn't differentiate. When a change is made that matches the criteria in the subscription, a notification will be generated.
I cannot seem the have my head around this. APNS as stated in the documentation has best-effort delivery, i.e. delivery is not guaranteed. However, if I am to use the push-notification model in my client/server application, I have to use them somehow.
The general model looks as follows: there is new data on the server -> the server then sends a push notification informing the client(s) that there is new data available -> client downloads new data.
The question is then, if I cannot rely 100% on the notification to be delivered, what kind of fallback mechanism can I use so that I can ensure that the client receives the new data available on the server ? What is the way to ensure that the client has the most-up-to-date data using APNS ?
What is the way to ensure that the client has the most-up-to-date data using APNS ?
There is no way to do this with just APNS. Your client needs to query your server when the app is brought to the foreground to see if there is new data, regardless of any push notifications you may have lost or received.
It all depends on how you are planning on using APNS.
Lets say you were making an App that sold items like eBay. You have:
- bids being placed by multiple users
- countdown to item closing time
You would not use APNS to update the timer on the persons device or notify them of the current price of the item. These are too crucial to rely on a best-effort delivery and was not the intended use of APNS.
It would be best if, in this scenario, you had the app poll the server every X seconds for updated information. You could then user APNS for non-crucial features like notifying the user if they are outbid or if they have won the item.
I'm currently struggle with annoying store-and-forward function limitation of APNS. Here is a quote from the Apple docs:
If APNs attempts to deliver a notification but the device is offline,
the notification is stored for a limited period of time,
and delivered to the device when it becomes available. Only ONE recent
notification for a particular application is stored. If multiple notifications
are sent while the device is offline, each new notification causes the prior
notification to be DISCARDED.
I specifically make ALL CAPS for the keywords of my problem. In Google Cloud Messaging notifications service their store and forward function have much more capabilities:There is a limit on how many messages can be stored without collapsing. That limit is currently 100. If the limit is reached, all stored messages are discarded. - so Google service can store up to 100 push messages for a max time of 28 days. And in addition to this they have also coalescing (collapsible) notifications but for 4 different collapsible messages. And in APNS all we have is - one recent
notification for a particular application is stored - it is quite a limited behaviour for my app (I need to store at least four different push notifications while the device is offline at one given moment of time).
So I'm interested are there some ways I can improve store and forward capability of APNS?? Can I in some way make APNS to store more push notifications for a specific device?Or at least store several coalescing notifications as in Google collapsible messages? Some third party solutions or whatever? May be I missed something in APNS docs? I know we can orchestrate apple push notification on google platform - but I think it is not a solution because of its unjustified complexity.
As you found yourself in Apple's APNS docs, there is no way to store more than one notification per application for a single device. If you want to compare it to GCM, APNS server acts as if all notifications have the same collapse key.
No third party solutions can work around that, since Apple doesn't return an acknowledgment of delivery to the sender of the notification, so the server (whether it's implemented by you or by some third party provider) has no way of knowing which messages to store and resend (assuming that all the messages are valid and were not rejected by APNS server).
Apple Push Notifications are not intended to deliver important data. Their purpose is to notify the user of the app that new data is available at the server, which allows the app to load that data if the user chooses to open the app. That's the reason why they don't store more than one message per app for the same device.
I need to update my users for things that happened around their current location while the app is in the background.
To my understanding:
If my server sends a Push Notification to a client, the client would immediately show that message.
I can set up the app so that there is a specific location, with a given radius could fire a message.
So what I want to understand if it is even possible to update my users about things that are new in their locations.
I was thinking of two possible solutions, I am not sure they are possible.
One, I guess if the Push Notifications would allow a function to run prior to its display,
deciding if the message should appear.
For example: something happened in area x,y - The server initiates a message to all devices. Only the devices within range of x,y and a radius z, would show the message to the users.
Maybe the Regional Monitoring service can send a message to my server and my server can then decide if to send a Push Notification back to the client...
For example
The user has entered a defined location, determined by the app. The app sends a message to the server. The server decides if a message is due.
Any ideas? is that even possible?
Filtering push notifications by topic is something you need to do on the server side, not the client side. Apple specifically states not to send messages to users that aren't relevant and you won't be able to block them when the app isn't running. Additionally, if you are using a service to manage your push notifications you don't want to pay for messages that aren't relevant.
So when you register a device into your database, you should register what topics that person is subscribing to (ie. save a list of topics that user is eligible to receive). Then when the event is triggered that generates the push notification only send to devices that are registered to that topic. I believe a number of push platforms have this capability already built in. On UrbanAirship and Azure Notification Hubs you can use their tags feature. Or you can develop it yourself if you do your own push server.
Take a look at Parse. They have this kind of functionality baked right in, just send the push to clients that match a geoPoint query.
I am working on an application that must notify the user of a server-initiated event. These notifications are only useful for a short space of time (30-60 seconds). For this reason, I am looking for a method that can both deliver a notification quickly, and, importantly, can somehow invalidate (retract/cancel/timeout) the notification after it has already been delivered.
My understanding is that the APNS is not suitable for this. They 'send and forget', giving no ability to check/modify/delete a notification. This functionality is integral to my app though, so I am open to any suggestions for methods or services that might let me achieve this.
In my mind there are several options:
Server sends notification to user. Server then later sends 'cancel' message to user, which removes the notification.
Server sends notification to user, which has a built in timer. This timer is monitored locally, and once it elapses, the notification is removed.
App periodically polls server and schedules/cancels a local notification according to what the server says.
My preference is option 2, because it is self contained and efficient. One message initiates both the scheduling and cancellation. Option 3 has issues with iOS shutting down the app if it's in the background (not to mention the rate at which it would have to poll the server given the notification would only be useful for ~30 seconds).
Do any services such as Urban Airship offer some functionality that could achieve this? Any other suggestions/complete work around methods? All very appreciated.
Thanks for your time!
Matt
EDIT: In the interests of encouraging out of the box thinking, another idea might be that the server initiates an automated phone call with the app user. If the user answers the call, the required information is given to them. If not, the information is no longer available. Bit wacky, and my instinct is that it would be costly, but I'm open to anything!
Anything that happens asynchronously can be done with push notifications as it already provides a unidirectional, instant communication channel between you and your customers, so no need to do strange phone calls (which can interrupt your users' activities, bothering them).
You can go for a dual solution, in which you notify your users of how many unread notifications they have in their inbox. Then can you implement your own in-app message inbox, which connects to your servers and fetches the relevant data (in case it hasn't expired - if it has, just let the user know -).
This way users would be able to know how many notifications have been made available to them, but they could only check the ones that are still valid. UrbanAirship employs this approach for their Rich Push feature.
Apart from this, you need to bear in mind push notifications can be very intrusive for the user, so use them wisely or you'll see your users unsubscribing from them or even worse, uninstalling your app.
Well my guess you are out of luck, since your only option is APNS.
There is no support for canceling notifications.
Apps can't access the notifications for the app, only the one the user uses to open the app. Also you can't really run apps in the background is they are not used for location, media, VOIP or need to access some kind accessory.
See my point where you can't really run app in backgroud.
Third party services can not add extra functionality to the APNS server as provided by Apple.
As to your suggest that the server will the app, you can't intercept call, sms,... on iOS. I really you only solution is to build a VOIP app that will call the user when ever the notification needs to be displaid.
Apple has no solution that will suite you needs, guess it will have to be an android app then :S