My application currently uses the application:didReceiveRemoteNotification:fetchCompletionHandler and application:didFinishLaunchingWithOptions: delegate methods to handle background remote notifications. Intermittently, a push notification will appear, and I will not receive a log that says that it has called either of my application delegate methods. I have tested for suspended, active, background, and suspended states, and they all seem to be working correctly. About 1 in every 30 pushes I get a 'dead' push notification.
****NOTE: This case only happens when I do NOT enter by touching the push notification, and happens unpredictably.**
The error came from an iOS 8 "feature" in Apple's docs. If an iPhone has less than great cellular or wifi signal, low battery, or is not plugged into a charger, the phone will receive the notification on the lock screen, but will not launch the app into a suspended state. Therefore, background events such as application:didReceiveRemoteNotification:fetchCompletionHandler will not be fired IF you do not enter directly into the application by swiping the notification itself.
This was offset in testing by the fact that the device was always plugged into my development machine during debugging with a strong wifi signal, so I would never be put into a bad state.
This is extremely specific, but crucial if your app relies heavily on push notifications for background functionality.
Related
I guess it is a background mode related to ExternalAccessory.framework.
But the document about External Accessory says, "If your app is suspended in the background when an accessory notification arrives, that notification is put in a queue. When your app begins running again (either in the foreground or background), notifications in the queue are delivered to your app. Notifications are also coalesced and filtered wherever possible to eliminate any irrelevant events. For example, if an accessory was connected and subsequently disconnected while your app was suspended, your app would ultimately not receive any indication that such events took place.".
This means that the external accessory communication will be just queued until the app enters foreground mode, But the other background modes like Location, Bluetooth LE are working as real-time in background mode. So I doubt that just queued is the only thing that can do. Is it really?
If your external device is "Made for iPhone/iPod/iPad" - MFi you can use this option. It's not for BLE communication.
Currently i am working on app in which i want to play continues sound when app receives push notification. as i know apple allow to play custom sound of length of 30 sec here is link..
but in well known app it plays continues sound in driver side when app is in back ground and driver receives order.
and another issue is of when my app is in back ground and receives push notification Rather clicking on notification if i open app by pressing app icon it does not show me data of push. it is not possible to load data when press on app icon here is link
iOS Push notification issue
but same thing is done in well known app
With iOS 7+, use application:didReceiveRemoteNotification:fetchCompletionHandler:, which is called even if your app is in the background. iOS will even launch your app in the background if it's not already running, but if the user force quits the app, it will not be re-launched. If you enable the remote-notification background mode, you can run app code when the notification arrives. If you include the audio background mode, you could initiate a sound that continues to play while app is in background.
For second question, typically, your app should query a server for updates if it's launched directly. However, you could leverage a remote notification as above, which you'd get in most cases (except if the app were force quit).
I am using remote notifications to ping IOs devices so to issue a call to my server once the application is brought to foreground (or is already in foreground).
I see is the following behaviour:
App is in foreground: - application:didReceiveRemoteNotification:fetchCompletionHandler is called.
App is brought to foreground by clicking on the alert popup: - application:didReceiveRemoteNotification:fetchCompletionHandler is called.
App is brought to foreground by clicking on the app's icon - none of the didReceiceRemoteNotification (nor didFinishLaunchingWithOptions) are called.
Since I need to make sure the device gets the ping in all of these scenarios, I must make sure option (3) works as well. Is it possible to get notified about the remote notification is this scenario?
I am detecting for iBeacon in background. When my device comes in a particular region application should comes to foreground.
It cannot be done without user interaction. The only option is you can generate a push notification to tell the user to bring the application to foreground.
This is from the Apple documentation about this issue:
When the operating system delivers push notification (iOS or OS X)
and the target application is not running in the foreground, it
presents the notification (alert, icon badge number, sound). If there
is a notification alert and the user taps or clicks the action button
(or moves the action slider), the application launches and calls a
method to pass in the local-notification object or remote-notification
payload. If the application is running in the foreground when the
notification is delivered, the application delegate receives a local
or push notification.
To answer to some comments about WhatsApp, with it, when you receive a classic vocal call, IOS use CallKit to display your call and wake up your phone, but it's not inside app. I try to make a video call with WhatsApp, and in this case, there is a notification. Press notification open app and answer to the call.
Conclusion : It's impossible to wake up app from background to foreground in IOS, but it's not really a problem because you can use notification to display what you want and get the user to your app after a touch on your notification. All of iPhone users are familiar with this kind of interaction, it's better to deal with it.
I've implemented
application:didReceiveRemoteNotification:
to store data in my app when a push notification is received.
However when my app is in background and I receive a notification, the data is stored only if I touch the notification banner appearing on top:
Instead, if I touch the app icon to reopen it, the content of the notification is not stored:
Since I'm receiving the notifications only when I use the distribution profile, I'm not sure if application:didReceiveRemoteNotification: is invoked only when I push the notification banner on top.
I thought it is always invoked at the time a notification is received, and not after a user action on the device.
UPDATE.
I don't know if this can help but, just to let you know, I haven't implemented any of these methods:
– applicationDidEnterBackground:
– applicationWillEnterForeground:
- applicationDidBecomeActive:
I think I've found out why. From documentation:
If the action button is tapped (on a device running iOS), the system
launches the application and the application calls its delegate’s
application:didFinishLaunchingWithOptions: method (if implemented); it
passes in the notification payload (for remote notifications) or the
local-notification object (for local notifications).
If the application icon is tapped on a device running iOS, the
application calls the same method, but furnishes no information about
the notification.
http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/IPhoneOSClientImp/IPhoneOSClientImp.html
However, I'm wondering if there is a way to load the payload even if the app has been re-opened by touching the icon.