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.
Related
I have an app that allows users to create recurrent events. Each one of the events may or may not have reminder/alerts at a specific time of day. If they have so, the app sends a local notification at that time of day.
Events are stored in CoreData.
Event(name: "Go to London",
date: 2020-04-03 21:40:55.419925+0200,
reminders: [2020-04-03 20:00:00.419925+0200,
2020-04-03 10:00:00.419925+0200,
2020-04-03 12:00:00.419925+0200]
)
An event may occur on each day of the year or everyday for the next X years.
A user may create unlimited number of events per day. And hence, the total number of notifications to be sent can easily surpasses 64 (total number of local notification that you can schedule in iOS). So I can not schedule all the notifications while the app is in foreground.
I need a mechanism to periodically schedule notifications if there are less than 64 notifications pending. This should be done even if the app is in the background.
I would be happy if you provide a solution or guide me towards finding a solution for this scenario.
info
I tried to set up a Timer that periodically checks total number of pending notifications and their due dates. . But it did not work, because timers won’t fire once the app goes in background.
I am not sure if I understand your problem right. But my impression is the following:
Your users set up and update a database of events where each event has a certain date and time.
They do this simply be entering new events into the database.
It is easy then to fetch the first n (say, 10) events from the database.
It is required to fetch more than one, since the delivery of a local notification is not guaranteed, see the docs:
Every attempt is made to deliver local and remote notifications in a
timely manner, but delivery isn't guaranteed.
Register these n local notifications with the notification center, and cancel any notification for events that are no longer among the n next ones. The docs say:
Typically, you cancel a request when conditions change and you no
longer need to notify the user. For example, if the user completes a
reminder, you would cancel any active requests associated with that
reminder. To cancel an active notification request, call the
removePendingNotificationRequests(withIdentifiers:) or
removePendingNotificationRequests(withIdentifiers:) method of
UNUserNotificationCenter.
So, even if your app is in the background or suspended, the local notification will wake it up, handle the event, remove it from the database, and update the n next events. Even if a notification could not be delivered (which is not probably, but possible), you could handle the missed event, and schedule the next ones.
I hope this meets your requirements!
Have you tried the background fetch feature? Official document link here.
And in my opinion, it would be better to use remote notification, just setup a simple server to store the users' data.
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
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
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.