I have set up a microsoft graph webhook to monitor changes in messages, with my application, that was working great in production.
What is happening is the webhook is not sending notifications as quickly as I would expect it to send its notifications. Sometimes it is immediate, sometimes it takes an hour, I do not understand why this is happening.
Any help would be much appreciated.
Webhooks subscriptions expire after a certain time and/or if your webhook crashes often or takes too long to reply on regular basis.
You need to renew your subscription on regular basis in order to keep it going.
You can find more information about that here https://www.eliostruyf.com/creating-and-renewing-your-microsoft-graph-webhook-subscriptions/
I don't think you should be expecting any guaranties that the notification will be instantaneous (or almost). The reason is all that works with a message queue pattern and a reduce pattern behind the scenes. Notifications are async, and can be delayed depending on the service, on the number of notifications to go to the same subscriber and so on
Related
The Apple docs talk about notification webhooks retrying messages if they fail. However, this adds the complexity of trying to figure out the order of events as they may reach your server in the wrong sequence.
Surprisingly, the only timestamp I can find on a notification is the signedDate. Should/can this be used to order the notifications? I'm making the assumption that when a notification is retried (up to 72hrs later) that the message isn't re-signed, but there's no documentation saying whether or not this assumption is true.
Is there some other way to do this?
We want to use push notifications to inform our users about new app features or great content. These will only be sent occasionally, but should go to all users of our app.
We've already implemented push notifications and calculate the badge number based on server side. This works fine when sending push notifications as transactional information (e.g. somebody has followed you), but if we send them to thousands or millions of users, obtaining and sending the badge count as payload seems to be crazy.
This would actually result not only in one database lookup for every user, but also for thousands (or millions) of calls to APN.
From what I found in the docs, I don't see any way around this, also because you have to keep the badge count in sync with your own data. So, if so many calls to APN are actually necessary, what is the best practice to do these calls? All in one giant burst, or maybe send smaller chunks (like 1.000 at a time) and then pause for a minute?! I can't find any recommendation on Apple's pages on how to handle this and what they expect.
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 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
One thing I haven't found is when to call the Apple's Feedback Service for push notifications. The Local and Push Notification Programming Guide says:
Providers should periodically query the feedback service to get the list of device tokens for their applications, each of which is identified by its topic. Then, after verifying that the application hasn’t recently been re-registered on the identified devices, a provider should stop sending notifications to these devices.
But is there a best practice to follow? E.g.:
Everyone calls it before sending any notification, or
Everyone calls it once a day, or
Everyone calls it once a week, or
...
You can call the feedback service every day, or if you send lots of notifications in a day, every hour if it's not a problem for you.
The reason to call the feedback service is to reduce the number of subscribers to include in the next send.
The frequency of calling depends of the frequency of the sending of notifications.