Here's my app scenario: When user swipes a notification I will launch some other app via URL.
So it basically launches some other app when notification arrives.
Currently to handle swiping notification scenario, when
- (BOOL)application:(UIApplication *)app didFinishLaunchingWithOptions:(NSDictionary *)
method is invoked, within this method, I call processNotification: method, which contains:
...
[[UIApplication sharedApplication] openURL:url];
...
If push received while app is active, url is opened perfectly fine.
If push received by swiping or clicking on notification, url is opened in the background but the currently viewed app is my application. For example if my url is tel:123-456-7890, iOS starts the call (you can hear the sound) but active app is not Phone.app, it is my app.
That seemed pretty strange to me. However if I wait for UI to load, and call processNotification: after that, it brings up Phone.app window correctly. (bug in platform? because call happens but my UI is on the top.)
I need a method to delay execution of this processNotification: call, (maybe through an operation queue) until a view controller is loaded. Otherwise, my app stays on top and the URL is opened in the background.
I was facing the same issue, I moved the openURL into main_queue and it seems to be working fine. I did not have to even make that change in didBecomeActive
dispatch_async(dispatch_get_main_queue(), ^(void){
[[UIApplication sharedApplication] openURL:url];
});
You should delay your handling of the push notification (i.e. calling openURL:) until applicationDidBecomeActive:. Keep the parameters you need from application:didFinishLaunchingWithOptions: but only call your handling code in applicationDidBecomeActive:.
I think the problem here is that SpringBoard is unable to cope with one app transition being called while another is in progress. An iOS bug of course. You should open a bug report at https://bugreport.apple.com
Related
I've been using interactive notification and it works well when my app is suspended in the background, but causes problems when my app has been terminated.
I've used NSLog to determine the app's lifecycle when the interactive notification is triggered when the app has not launched.
The following goes on, in the order listed, without the app visibly launching:
didfinishlaunching
handleActionWithIdentifier
viewdidload
viewwilllayoutsubviews
viewdidlayoutsubviews
viewdidappear
The app then seems to terminate without calling
didenterbackground or willTerminate
The reason why it's causing issues for me is because I create timers in viewdidload that are invalidated in didenterbackground.
Because didenterbackground isn't being called, when the app is subsequently launched after triggering an interactive notification I'm ending up with two instances of the timer.
Could anyone shed some light on why the app terminates but didenterbackground or willTerminate aren't being called?
You should not assume that a call to didfinishlaunching means that you are in the foreground. As #PaulW11 says in his comment, for local notifications when your app is not running, you get launched directly into the background, and never see a foreground-to-background transition, because you were never in the foreground in the first place.
The system will call applicationDidBecomeActive: if you are being launched into the foreground. You should put your code that starts your timers there.
The docs say that local notification notices get invoked in the background:
When the user taps a custom action in the alert for a remote or local
notification’s, the system calls the
application:handleActionWithIdentifier:forRemoteNotification:completionHandler:
or
application:handleActionWithIdentifier:forLocalNotification:completionHandler:
method in the background so that your app can perform the associated
action.
You should write your application:handleActionWithIdentifier:forLocalNotification:completionHandler: method to check to see if it's being called from the foreground or from the background.
I use (Objective-C) code like this to tell if I'm in the foreground or the background:
BOOL inBackground = [UIApplication sharedApplication].applicationState == UIApplicationStateBackground;
Our application use UIBackgroundMode "voip" so it can be launch in background.
In our case application was launched in background by iOS and application:didFinishLaunchingWithOptions was called. Then user immediately tapped to the app icon. We don't know when it actually occurred but its look like after several seconds from background launch. After that user made some work in application, interacted with UI, but application wasn't got applicationWillEnterForeground method invoke and notifications. This method was called after 30 minutes after user worked with application. And all of this time UIApplication applicationState value was UIApplicationStateBackground.
Why did applicationWillEnterForeground was called so later?
There is not steps to reproduce this situation because it is rare case. iOS Version is 8.1
Sliding from the lock screen and/or pressing a notification from the notifications page... do both pass from applicationDidFinishLunchingWithOptions when the app is totally closed?
My concern is because, when the app is closed and not in background, whenever I press on the app from the notification, my app opens and goes where it has to go... but whenever I press slide to open, the app opens but it does not go to the page it should go.
The docs say that if the action button on the notification is pressed, it calls application:didFinishLaunchingWithOptions and passes in the notification payload. Later it says if the app is running in the foreground, it delivers the notification via application:didReceiveRemoteNotification:. This implies to me that when the app is backgrounded or not running, then application:didFinishLaunchingWithOptions is called. Otherwise, application:didReceiveRemoteNotification: is called.
application:didFinishLaunchingWithOptions: will only be called if your app is not launched already. While it is true that the options will include info on notifications if that is what ended up launching the app, what you want is to handle your local notification logic here:
- (void)application:(UIApplication *)application didReceiveLocalNotification:(UILocalNotification *)notification
I am currently building a music app which takes controls from the iOS7 control center. One of the features I noticed is that if I press the "play" control button, my app will start, even if it has been killed. This is not something which I want to happen, so I added return NO in didFinishLaunchingWithOptions if the app is launching in the background to prevent the initialization process.
Unfortunately, this does not change the fact that the app has still started, and didFinishLaunchingWithOptions is not called again (and nothing is initialized). Since I cannot have the app forcefully kill itself when I don't want it to start, is there any way to prevent the app from launching? I had thought that returning NO would have done the trick, but this does not appear to be the case.
I have found one of the main causes to this issue. It had to do with the audio session and the various notifications/delegates which the app was registered for. In the AppDelegate's applicationWillTerminate: I had to make sure to call:
[[UIApplication sharedApplication] endReceivingRemoteControlEvents];
[[AVAudioSession sharedInstance] setActive:NO withOptions:AVAudioSessionSetActiveOptionNotifyOthersOnDeactivation error:&audioSessionError];
And also unregister for any audio notifications (interrupts and route changes).
Do you want your app to run in the background at all?
If not, you can simply add a info.plist value so it doesn't enter background and just closes when a user hits the home button.
Which is the proper delegate to implement when an application is waking up from being in the background and you want it to prep it to be active?
applicationWillEnterForeground vs applicationDidBecomeActive -- What's the difference?
Which is the proper delegate to implement for when an application is going to sleep and you want to prep it to cleanup and save data?
applicationWillResignActive vs. applicationDidEnterBackground -- What's the difference?
Also, I've noticed that applicationWillResignActive gets called when an incoming SMS or call comes in but the user chooses to click Ok and continue. I don't want my app to take any action in these cases. I just want it to keep running without any intermediate cleanup since the user didn't exit the app. So, I would think it makes more sense to do cleanup work just in applicationDidEnterBackground.
I would appreciate your input on best practices to follow on choosing which delegates to implement for waking up and going to sleep as well as considering events like being interrupted by SMS/calls.
Thanks
When waking up i.e. relaunching an app (either through springboard, app switching or URL) applicationWillEnterForeground: is called. It is only executed once when the app becomes ready for use, after being put into the background, while applicationDidBecomeActive: may be called multiple times after launch. This makes applicationWillEnterForeground: ideal for setup that needs to occur just once after relaunch.
applicationWillEnterForeground: is called:
when app is relaunched
before applicationDidBecomeActive:
applicationDidBecomeActive: is called:
when app is first launched after application:didFinishLaunchingWithOptions:
after applicationWillEnterForeground: if there's no URL to handle.
after application:handleOpenURL: is called.
after applicationWillResignActive: if user ignores interruption like a phone call or SMS.
applicationWillResignActive: is called:
when there is an interruption like a phone call.
if user takes call applicationDidEnterBackground: is called.
if user ignores call applicationDidBecomeActive: is called.
when the home button is pressed or user switches apps.
docs say you should
pause ongoing tasks
disable timers
pause a game
reduce OpenGL frame rates
applicationDidEnterBackground: is called:
after applicationWillResignActive:
docs say you should:
release shared resources
save user data
invalidate timers
save app state so you can restore it if app is terminated.
disable UI updates
you have 5 seconds to do what you need to and return the method
if you don't return within ~5 seconds the app is terminated.
you can ask for more time with beginBackgroundTaskWithExpirationHandler:
The official documentation.
Managing Your App's Life Cycle is helpful to your questions. For quick concept, you can see Figures in that document.
You can also read the comment from the code generated by the XCode Wizard. Listed as follows:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
// Override point for customization after application launch.
return YES;
}
- (void)applicationWillResignActive:(UIApplication *)application
{
/*
Sent when the application is about to move from active to inactive state.
This can occur for certain types of temporary interruptions (such as an
incoming phone call or SMS message) or when the user quits the application
and it begins the transition to the background state.
Use this method to pause ongoing tasks, disable timers, and throttle down
OpenGL ES frame rates. Games should use this method to pause the game.
*/
}
- (void)applicationDidEnterBackground:(UIApplication *)application
{
/*
Use this method to release shared resources, save user data, invalidate
timers, and store enough application state information to restore your
application to its current state in case it is terminated later.
If your application supports background execution, this method is called
instead of applicationWillTerminate: when the user quits.
*/
}
- (void)applicationWillEnterForeground:(UIApplication *)application
{
/*
Called as part of the transition from the background to the active state;
here you can undo many of the changes made on entering the background.
*/
}
- (void)applicationDidBecomeActive:(UIApplication *)application
{
/*
Restart any tasks that were paused (or not yet started) while the
application was inactive. If the application was previously in the
background, optionally refresh the user interface.
*/
}
- (void)applicationWillTerminate:(UIApplication *)application
{
/*
Called when the application is about to terminate.
Save data if appropriate.
See also applicationDidEnterBackground:.
*/
}
For more detailed explanations, please refer to official document for UIApplicationDelegate
I was still a bit confused with Dano's answer so I did a little test to get the flow of events in certain scenarios for my reference, but it might be useful to you too. This is for apps that DO NOT use UIApplicationExitsOnSuspend in their info.plist. This was conducted on an iOS 8 simulator + confirmed with iOS 7 device. Please excuse Xamarin's event handler names. They are very similar.
Initial and all subsequent launches from a not-running state:
FinishedLaunching
OnActivated
Interruption (phone call, top slide-down, bottom slide-up):
Home button double-press listing inactive apps, then reselecting our app:
OnResignActivation
OnActivated
Home button double-press listing inactive apps, selecting another app, then relaunching our app:
Home button single press, then relaunch:
Lock (on/off button), then unlock:
OnResignActivation
DidEnterBackground
WillEnterForeground
OnActivated
Home button double-press, and terminate our app: (subsequent relaunch is first case)
OnResignActivation
DidEnterBackground
DidEnterBackground (iOS 7 only?)
Yes, DidEnterBackground is called twice on iOS7 device. Both times UIApplication state is Background. However, iOS 8 simulator does not. This needs testing on iOS 8 device. I will update my answer when I get my hand on it, or someone else could confirm.
applicationWillEnterForeground is called:
when app is relaunched(comes from background to foreground)
This method is not invoked when app starts for the first time i.e when applicationDidFinishLaunch is called but only when comes from background
applicationDidBecomeActive
applicationDidBecomeActive is called
when app is first launched after didFinishLaunching
after applicationWillEnterForeground if there’s no URL to handle.
after application:handleOpenURL: is called.
after applicationWillResignActive if user ignores interruption like a phone call or SMS.
after disappearing of alertView anywhere from the application
applicationWillResignActive is called when system is asking for permissions. (in iOS 10). Just in case someone hit into the same trouble as me...
In iOS 8+ there is a subtle but important difference for taking phone call.
In iOS 7 if user takes phone call both applicationWillResignActive: and applicationDidEnterBackground: are called. But in iOS 8+ only applicationWillResignActive: is called.
For iOS 13+ the following methods will be executed:
- (void)sceneWillEnterForeground:(UIScene *)scene
- (void)sceneDidBecomeActive:(UIScene *)scene