I observed in iPhone that,When an app receive too frequent notification and that app is in background,iPhone does not show banner for all notification,instead it shows banner with message " You have 6 new Connect notification." ( 6 is the push notification count and connect is the name of app.).Is this behaviour documented anywhere?
As for your question of where it is stored, it is probably stored in the cache of the phone (which is cleared every so often) so you're not being monitored and watched as far as I know of. If you wish to turn off these notifications you can do so in the settings. Hope I answered your question!
Related
We noticed that the silent content push messages that we are sending to update the magazine cover of our Newsstand App suddenly stopped working specifically in iOS 7.1.
I just did some testing sending the content push to the following devices:
iOS-5.1.1 -> push received -> magazine cover updated -> OK
iOS-7.0.6 -> push received -> magazine cover updated -> OK
iOS-7.1 -> push never received -> NOK
However, if I send a push alert message to these devices, all alert messages are correctly received and shown, so I am sure that I am using the correct device tokens.
And this issue is on an existing App live in the App store, never having this issue before and it seems to be specific to iOS 7.1.
This is the content push message we are sending:
$payload = '{
"aps" :
{
"content-available" : 1,
}
}';
Anybody else having the same problems specific in iOS 7.1?
Thx!
I am having that issue also on 7.1 in development. If connected to XCODE we see the method application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler invoked... ONCE we disconnect from Xcode... that method does NOT get called based on reviewing the console.
EDIT :: Today during testing against the sandbox environment with a iPhone on iOS7 7.1 (11D167) the content-available starting working ?? We are getting calls into didReceiveRemoteNotification fetchCompletionHandler: NOW, even when phone is NOT connected to XCode or anything. Even if the Phone is Locked and Application is in the background... which is what we needed and very important.
Really odd... but we did find that the Manual Do Not Disturb was ON.. on this test phone.. not sure how that got on and if that was issue. Make sure that is NOT ON.. otherwise you will not get any remoteNotification calls into your application. We may have gotten off track with the other postings that content-available was broken on ios7.1.
If anyone knows anything else about this, please share.
From https://support.magplus.com/entries/84992596-About-Lower-Issue-Download-Counts-Since-iOS-7:
About Lower Issue Download Counts Since iOS 7
With the release of iOS 7, Apple changed the way Newsstand Push Notifications work, and it is a significant departure from how Newsstand Push Notifications were delivered with iOS 5 and iOS 6. With iOS 7, Apple attempted to change the way these notifications worked, primarily optimizing the mechanism for apps that receive e-mail and Twitter updates and notifications multiple times within a 24-hour period. Part of the problem with iOS 7 is that it is not clearly differentiating Newsstand Push Notifications (which initiate a background download of content) from standard Push Notifications (which just deliver text).
A key change in iOS 7 is that if an app is killed manually by the end user, then the app simply does not receive Newsstand Push Notifications to automatically download new content in the background. Users manually kill an app by bringing up a screen of currently running apps and swiping one up to force it to quit. Apple views this scenario as one where the end user has made a conscious decision that they do not want the app running/performing background operations which consume battery life.
The two unique features of Newsstand Apps as promoted by Apple self in 2011, 2012 and 2013 (in WWDC video's about newsstand) were:
A - background download of new Magazines and
B - changing the cover when a new Magazine is available and showing a badge.
Unfortunately, in the real world situation, since iOS 7, Apple has killed both these features. Content push messages needed for these two features don't work if the user has killed the Newsstand App. Which in real world situation will almost always be the case.
Suppose you have a Magazine that appears monthly. How big is te chance that the user will have your Newsstand App running all the time in the background? I think almost none...
Before iOS 7, this user could be notified via a content push message resulting in a badge and a new cover visible in the Newsstand.
Since iOS7, these features are gone in real world situations.
Result: much lower magazine views and downloads.
Thanks Apple!
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.
i m making an application where data is accesed from website and displayed with an application.i have made an action which will tell the user that new data has arrived.this will work properly if the application is open .but if the application is closed than ,is there any way to tell the user that new data has arrived ,,so that he can open the application and check the data?
If you are using the Apple Push Notification Service (APNs), your messages will be delivered whether the application is running or not. For information on how to control what information is presented to the user, read the Apple Push Notification Programming Guide.
You should use Apple Push Notification Service, like codelark said.
I would recommend looking into Urban Airship for help getting started. It's a third party service, but it makes things much easier. Urban Airship does have their own tutorials and code samples which may be easier than Apple's.
As a follow up to the reference to apple push notification, as of ios4.0 I believe you, you may have a few more options, 1) you can send local notifications (just like push notifications, but they originate from inside your app) that could be timed to be delivered even if the app is not running..assuming you know approximately how long it will take for data to arrive. 2) if your data update will occur soon after the app closed.. your app can request a certain amount of time to complete an operation (even though the user has closed the app) and wait for the data, then send a local notification to tell the person to come back into the app. 3) if your functions based on gps updates, music streaming, or voip you can set a flag so your app continues to run in the background
sorry for the unstructuredness of the answer, this was just off the top of my head, hope it helps
My app asks the user to fill in and save a form locally. I want him to be reminded 48 hrs after the app has been closed that he has a pending form.
Is push notification the only way out? Does it cost money to use a provisioning service?
iPhone OS 4 adds timer-based alerting for apps that aren't running. See here for a brief description. I'm guessing this means that push notifications are your only option prior to version 4.
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.