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.
Related
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
Consider this scenario:
1) Launch the app
2) Put the app in background (pressing Home button)
3) Server send a PUSH notification to client
4) The user resume the app clicking on its icon from menu
In this case didReceiveRemoteNotification and didFinishLaunchingWithOptions are not called, so how do I get notifications ?
Simple answer: In this scenario you cannot get it.
If the push notification contains important payload then it should not contain it because you should not rely on it for anything important because:
notifications are not guaranteed to be delivered to the device in the first place
the user can turn off notifications
they could ignore them
if the device is turned off when it is due to be displayed then it will be lost
If you need to know if the server has sent a notification then make a connection home when you become active and ask it if it did so.
You should check in the applicationWillEnterForeground: method.
I think the app will not see anything if the user chooses to ignore the push notification. The workaround that comes into mind first would be to offer a way of checking the server if anything worth a push notification has happened since the last time the app was opened and correlating that with the local data.
I think the idea behind this system is to separate actual functionality from push notifications and making sure the notifications are used for only one purpose - notifying of new data/event/etc, thus leaving the downloading and processing of data to the app once it's fully in the foreground. I.e everything should be duplicated in the launching sequence to make sure the app is always up-to-date, even if the notifications during downtime were not received/ignored.
application:didReceiveRemoteNotification: is therefore meant for not transferring the data and updating the model, but reacting to the event and starting the necessary procedures. Although most of the time, the data may be so small that it fits in the notification and therefore the application can proceed without downloading any further content.
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 trying to mimic a pager with my app by sending push notifications to the user until he or she responds. My thought was to send a push every few seconds and play the default sound on arrival. Not perfect, but better than nothing.
It's working all right. However, I am finding that the sound starts to stutter/interrupt a bit after a few notifications have been sent -- as if it's trying to play the sound more than once. This happens even if I only send the push every 10 seconds. I just tested it at 20 second intervals and even then it starts to sound interrupted after about 10 times.
Any idea how to resolve this so each message plays the sound crisply?
p.s. Testing performed on an iPad.
This is an answer, in the sense I'm going to advise you don't do this. I'm pretty sure sending push notifications every few seconds until the user responds violates section 2 of the Apple Push Notification guidelines (it's appendix A of you Apple developer agreement). You probably won't find a satisfactory answer here for two reasons:
Nobody will have done it before, because it probably breaks the developer agreement
Apple don't guarantee order or delivery of push notifications, and the speed at which they are delivered depends upon the device's network and connection speed.
I got it working. Turns out in my attempt to keep the connection open per Apple's guideline I was mistakenly reusing my MemoryStream object.
The retry interval will be user definable so I hope this won't break any of Apple's rules.
Thanks for your input!
How are push notification better than pull notification on iPhones?
Are there any links with more information about this?
Any help would be appreciated.
Pull notification requires the user to be running your app, and your app to be wasting battery power constantly polling some server (or waiting on some network socket in another thread , or using the new background services).
Push notifications, when enabled by the user, and if the phone has a network connection, allows a message to be sent to a phone even when it's not running your app, prompting the user that your app wants some attention. It uses a much lower power network connection than any frequent polling method.
If you want to know about push notifications, I'm guessing you are interested in the Apple Push Notification Service.
You can read about its architecture here:
http://developer.apple.com/iphone/library/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
There is no such thing as a "pull" notification, but using APNs gives you the advantage that you don't have to manually poll a server every so often within an app, which usually saves you a lot of battery life in the long run if you are interested in telling the user about sporadic, infrequent events. Using push notifications also allows you to interrupt the user if they are not currently running your app, which of course can be very useful in certain use cases.
You should think about what kind of message flow you expect to see between your app and any server components in your system. Push notifications make the most sense where some event external to your app is going on which requires the app to be updated in some way, and where the frequency of those updates is low or highly variable.