This question is probably the same as Duplicate Apple APNS push notifications?, but since that one didn't get an answer, and I have some more information, I'll try to ask it again.
Steps to reproduce the problem:
Set notification center to display notifications as alerts, this will make the problem more obvious.
Make sure the app isn't running in the foreground.
Send 3 identical push-notifications in rapid succession.
Wait until the messages arrive at the phone, you will now have to dismiss the alert 3 times.
Now send 1 more notification, that isn't identical with the previous ones.
You now get that last notification, but you'll also get one of the previous notifications showing up once more. This is the problem.
If you continue to send single notifications, one of the first 3 will keep popping up when it shouldn't.
Here is a video that follow these steps, which clearly shows the problem:
http://youtu.be/TSqt8S4FY6w
We have just as Remy Gale did in the linked question above made sure that our notifications are sent in the correct way, and only once per notification. We have also tested this with both the sandbox-apns and the production-apns, both behave exactly the same.
The problem disappears if the app-badge is set to 0, which in turn removes all notifications from notification center. Removing the notifications manually doesn't help.
UIApplication *app = [UIApplication sharedApplication];
app.applicationIconBadgeNumber = 0;
But that isn't a solution.
The problem doesn't appear if all notifications contain unique text. Adding a GUID to the alert-text will make the problem disappear. Adding it to the apns-payload as a custom property or as a localized argument will however not help, so this is also not a solution.
This will probably rarely happen in a production environment with a live app, but it can happen, and when it does, it is really annoying for the users!
Does anyone know why this happen? Does anyone have a viable solution?
This Google Group for Gmail has an entry from a user who has researched the bug a bit and includes a possible workaround. According to the entry the bug is not present in iOS 5 but was introduced with iOS 6.
The workaround is simply appending a random number of Zero-width non-joiner to the title in order to assure uniqueness.
This could be an issue with the timestamp that the server is picking while sending a push notification to APNs. Pick only the latest timestamp.
Related
I'm trying to send UILocalNotifications and delete them automatically after a certain interval from the Notification Center.
My app sends information to users that in about 5 minutes since sending would be irrelevant.
There are going to be at least 3 notifications a day.
Since the information of the notifications would be irrelevant in a few minutes, it would be much better to delete those notifications from Notification Center - because they would be irrelevant to the user.
Is there any way to achieve this? Sort kind of a "self-destruction" option of local notifications?
Thank you!
If your question is to remove the notifications from the notification centre even without bringing the application to foreground(new notification to clear the old notifications), then the answer is straight forward "NO".
Without user accepting the older notification or manually brings the
application to foreground - It is not possible.
A possibility if this feature may come out with iOS7!
My question has to do with what happens when the user ignores multiple local notification. In my testing, it appears that iOS 5.1 (perhaps earlier too) passes only the last ignored notification to the app and discards all of the previous ignored notifications.
With my app (and I'm sure many others out there) the user may not launch the app with every notification and thus the possibility exists that there may be several unacknowledged notifications before the user launches the app. The reason this is important to me is that I am trying to place an accurate badge on one of my apps tabs to reflect the number of fired but not yet acknowledged notifications.
Has anyone solved this problem? Apple's phone app keeps an accurate badge for missed calls, but of course they have more capabilities than we do. Unless I have to, I don't want to resort to changing from an numeric badge to something else like an exclamation point.
Regards,
-- John
Look at this app for example.
How does this work behind the scenes?
I know you can set the badge by using:
[UIApplication sharedApplication].applicationIconBadgeNumber = somenumber;
However, this would need to work in the background for it to be able to stay updated. However, there's a 10-minute restriction for backgrounded apps. I'm thinking it has something to do with push notifications, but I don't know how that would work exactly.
Any ideas?
I'm setting a bounty on this. If possible, I would like a detailed step-by-step process of how to set up my webserver to handle these push notifications.
APNS (Apple Push Notification Services) has an option of showing a notification with just a badge (no alert, no sound). You can specify it in the payload. That is how the badge can be updated.
You can have a server send out the message to the user or use local notifications. But since you want to get the user's weather information, I guess a message from the server would be the way to go.
You can also specify that the app uses background services to get updated location and use this location to get the weather info.
Here are a few good references. Once you get the hang of it, its actually pretty easy rolling out your own server/client
http://blog.boxedice.com/2009/07/10/how-to-build-an-apple-push-notification-provider-server-tutorial/
http://code.google.com/p/apns-php/
http://www.easyapns.com/
The 73 here, is normally how you'd see the amount of messages related to the app there are waiting for you.
I assume you can set & reset that number, so they just push an update to you, saying you have 73 in-app messages waiting for you, and they abuse that mechanism to display the tempreature in farenheit.
You're correct, they're doing it through APNS (Apple PUSH Notification Service). It's pretty complicated to set up, but google "iphone APNS" and you'll find much better guides than what I could whip up off the top of my head. Here's the one I used to get out service working. It does a good job of walking through the process step by step.
Once you get it set up, you'll want to pass along a "badge" count with your APNS notification. The documentation for how to do that is here.
I'm reading many things about Local Notifications and the way they can help to update the app badge number.
I'd like to update this badge at midnight, and set its value to a number I can't know before midnight. So I'd like, if possible, to launch a function at midnight that would update/load some datas, check the number to display, and display it on the badge.
Of course, the number to display is not relative to the displayed number, and can be lower or greater.
This is expected to work :
- When app is in background
- When app is in foreground
- When app is not launched
would you know a way to do this, even partially ? If not possible, let say I can make things to know the badge number before midnight... Would this help you for a working answer ? This is not wanted, but if I don't have the choice to make this work, I'll plan to write tons of useless code to do this...
Unless your application fits into one of the "official" multitasking cases (VOIP, location, and background audio), the only way you're going to be able to dynamically set the badge number when your application isn't running is with push notifications... applications can't run code in response to a local notification (until the user presses the "View" button in the notification popup, at least).
See this document for everything you could ever want to know about local and push notifications in iOS.
You can't reliably ensure that your local app will run when it needs to unless you register it as a VoIP app or as requiring continuous location monitoring; either of these, in an app that's not in fact used for VoIP or navigation, will almost certainly result in an App Store rejection.
Your best bet is to send the badge as a push notification. Assuming that a server you control can know what the badge number is supposed to be, it can send a notification with just that badge value—not necessarily an alert popup or sound—to your app. Urban Airship is a good, simple way to send push notifications without having to do a lot of configuration and setup.
You very well may be able to do this. Look at the Apple Guide to running code in the background.
I'm seeing some very strange behaviour from the Apple Push Notification Servers when the recipient iPhone is off. Here is my scenario:
-Send push notification A to Apple. Within a few seconds a push notification popup gets displayed as expected on the iPhone.
-Send blank notification to Apple to cancel previous one (the previous notification is pointless after about 10 seconds, that's why I want to get rid of it). Nothing displayed on the iPhone.
-Turn OFF iPhone completely (not asleep, it is powered down).
-Send push notification B to Apple. Wait 10 seconds.
-Send blank notification to Apple to cancel previous one. Wait 10 seconds.
-Send push notification C to Apple. Wait 10 seconds.
-Send blank notification to Apple to cancel previous one. Wait 30 seconds.
-Turn ON iPhone.
-After about 60 seconds a push notification popup is displayed for notification B on the iPhone.
-Notification C never seems to arrive.
This is very strange! From reading the Apple docs I was expecting only the latest push notification to be sent. I was hoping my blank notification would be sent, I certainly wasn't expecting the oldest unsent push notification to be sent!
The Apple docs say:
Apple Push Notification Service includes a default Quality of Service (QoS) component that performs a store-and-forward function. If APNS attempts to deliver a notification but the device is offline, the QoS stores the notification. It retains only one notification per application on a device: the last notification received from a provider for that application. When the offline device later reconnects, the QoS forwards the stored notification to the device. The QoS retains a notification for a limited period before deleting it.
Has anybody seen this behaviour? Am I just hitting some sort of timing window bug? What should happen?
Updates:
-If I turn the phone off and wait 5 to 15 minutes before sending any push notifications then this problem doesn't occur. In this case when I turn the phone on I don't see any notification popup, although I'm not sure if this is a result of Apple dropping the notification, or their 'queue' working correctly (i.e. holding the newest blank notification instead of the first one with the popup).
-I will investigate further by putting an APNsLogging.mobileconfig onto the iPhone to see what notifications it got.
-Turning wifi off doesn't seem to change the results.
-I have raised a bug report with Apple for this scenario.
You may want to check for this behavior across both the cellular and WiFi networks. There's a lot of strange behavior when the phone is on WiFi, especially if there are multiple NAT router involved, i.e. in a large corporation where there's a main router and per-floor WiFi routers, or in a home where you have multiple routers used to extend the range. But on cell it's been pretty solid.
Also, the 10-second cancellation delay may be cutting it too close. They don't guarantee timely delivery and I've gotten lags of as much as 3 minutes on the production server after queuing off a push request. You may want to plan for system congestion.
Either way, it sounds like it might be worthy of a bugreporter report.
For the record, I raised this as bug ID #7349660 with Apple on 29th Oct (https://bugreport.apple.com), then gave them the additional diagnostics they wanted on 30th Oct.
No response from Apple since then, so I am assuming this is probably just low on their priority list, which is fair enough as it is quite a small timing window where the problem can occur (which I didn't realize when I first opened this question).
In apple's document it is said that it can cache the push notification up to 30 days.so u may get push once you switch on your iphone (provided you are having interconnection)
How soon was C sent after B? It seems like it may be a bug where there's some kind of timeout server side, and they accidentally keep B if C was sent too soon after...
If you have a good test example (and this seems like a good test) I would file a Radar report on this.