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.
Related
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 think I had once seen a way to tell the Apple Push Notification Service to re-send notifications that were unsuccessfully delivered on their first attempt. Is there a way to do this and can you point me to some information regarding this?
My goal is to send a notification to 100 people and if 10 of them fail to be delivered, have those 10 failures retry.
Unfortunately, as far as I know, no such functionality exists directly. You can check that the notification time to live is long enough, go with a persistent notification solution (Urban Airship), or do your own delivery verification and redelivery through some back end service of your own which would work with Apple's feedback service.
If a delivery failed (APNS connection is lost), APNS would attempt to deliver only the latest notification when the connection to APNS is re-established. Your other notifications would not be delivered if this is the case. If you are looking for something persistent, look at Urban Airship and similar services (Pusher may be another, though I have not used it) that offer functionality similar to an e-mail inbox for various mobile platforms including iOS.
If you're seeing issues with the latest notification not making it through, you might want to check that the TTL is not too short on that notification. That's all that comes to mind.
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
I want to create an iOS chatting app using APNS. If I have 10,000 active and they are continuing chatting, will apple block my developer account ? Is there any limitation regarding this?
I would discourage you from using APNS as a backbone of an "chatting app".
If you need fast chatting functionality you should write your own TCP-socket based server.
If every-few-second syncing is o.k. you can get away with a HTTP-based server backend (but all the pull-syncing can be hard on network traffic - so TCP-socket is still better choice).
You could however use APNS for fallback - when your app on certain device is not responding (i.e. is not connected to server) you can send an initial message trough APNS (to wake up your app & to notify the user there is a message waiting for him).
As soon as the user opens your app you should switch back to your TCP-socket or HTTP request based server communication.
As for your question: no, Apple would most probably (one can never know for sure) not reject your app just because of using APNS for chatting. But note (as the others said allready): messages between two users will get "lost" if they would interact too frequently - see the link Roman Barzyczak gave you.
"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."
more information: http://developer.apple.com/library/ios/#technotes/tn2265/_index.html
but Apple wont block your developer account :)
You can use them for messaging but you are going to quickly find out that there is no guarantee they will arrive. This is known as the black hole of push notifications. ;-)
I like this answer here.
First try to use an APNS only solution.
Make your push notifications stateless (they only serve as "Hey you have some new stuff in the server").
So when the client gets a push notification it asks the server for new data (messages or other stuff).
Use OneSignal to simplify the code that sends push notifications (from the back-end). If a user in your app gets a message after 10 seconds he dose not care if you used TCP,socket.io or xmpp...
Even Whatsapp's messages can take couple of seconds to arrive.
A chat app is not a realtime game. A delay of couple of seconds will be acceptable by end users.
My company offers an iPhone app for day traders which basically tells them when it's a good time to buy or sell. A cluster of servers generate these BUY and SELL signals and need to be delivered to a customer's iOS device in a minute or less. For all other mobile clients we've developed, we are allowed to poll the server in the background (once per minute), to check for updates.
In iOS, however, it seems that doing anything in applicationDidEnterBackground that has to do with times or polling isn't an option.
This led me to look at push notifications, but from what I am reading, they aren't reliable. They employ a send-and-forget methodology, which there's no guarantee they will be received.
You can see the problem with this. If we issue a BUY signal and the user acts on it, then a SELL signal is generated 10 minutes later and send via push, but never arrives, they could lose a lot of money.
So, is there a good way to do this or am I out of luck? Thanks!
There are two intermediaries between your server and the user's device: a) Apple and b) the network.
Apple does not guarantee the delivery of all notifications; only the most recent is guaranteed to arrive and only for a limited period of time. For more information, check out the "Quality of Service" section in Apple Push Notification Service.
If the device is accessing the network through a mobile carrier, things may get ugly. I have experienced situations where, some notifications didn't arrive until much later, and some got lost entirely. From my experience, carriers protect -with zeal- the quality of their own services, rather than those of third parties like Apple. An SMS/MMS will not normally be lost, while a push notification might.
Polling the server would be a viable alternative for your app. Alas, Apple doesn't allow networking operations to take place for apps that have been put in the background state (except for Newsstand downloads and VoIP).
Some apps seem to do push notifications really well (GroupMe) while others don't. If you're really worried, you could use a service like Twilio to send the user an SMS message with a link that would open your app and give it some information. So the SMS could say "SELL SELL SELL yourapp://stock=APL" or something like that. This obviously won't work for iPod touch users or iPad users (although I don't know if that will be a problem for you.
Try using Apple's own push notification service: http://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
It's quite easy to implement, with just a few lines of code in the application and a bit of PHP and JSON on the server to do the sending. The good thing is that your server sends the request to Apple, and Apple's own servers handle the delivery to the device securely and reliably. Notifications are usually delivered within 10 seconds of being sent (unless the device is offline, then it will be delivered when the device comes online).
From my experience with push notifications, I haven't lost a single one, and there is a delivery option that continuously attempts to deliver it until it is successful, and there is even a server side callback API of some sort available that lets you check the status of your notifications. You could also try a service like Urban Airship to do the work for you.
You could also try using one of Apple's background modes as part of this (such as receive the 'BUY' as a notification and have the app wait for the 'SELL' in the background. The biggest limitation is that the app can only run in the background for about 10 minutes at a time, so you would have to use a workaround like playing music in the background (or making stock announcements like a music track ;P), or prompting the user to reopen the app to continue the background session.