I am writing an iOS VoIP app that has background mode permission. In background, it will be listening for incoming connection, and once I have an incoming connection, it should start a UIViewController for the user to accept the call. How and where to call and present a UIViewController from background?
I know how to do this in Android, a Service would call an Activity via an Intent.
But in iOS , I am not sure how would the flow go. Also, how do I go into background mode in iOS? I know it has to do with the appDelegate method applicationDidEnterBackground: , But not sure what to do next.
Thanks in advance.
there are two methods in appDelegate that will be called when the app returns to active state. First one is - (void)applicationWillEnterForeground:(UIApplication *)application and the second one is - (void)applicationDidBecomeActive:(UIApplication *)application
In the 2nd you have to restore your user interface.
How do I do something when the ios notification bar(or whatever it is called) is dropped down? I want to show my loading picture when the user checks the bar when in my app. Netflix does this (at least in my ipad) when you are in Netflix and you drop the notification bar down, the Netflix app changes so that it is the same picture as when it is loading(their logo on a red background that takes up the whole view) and when the notification bar hides, it goes right back to whatever you were looking at. I'm more familiar with android so forgive my bad ios vocab.
I don't think you can sense when the notification center is pulled down from the status bar.
However, you can simply react to the
- (void)applicationWillResignActive:(UIApplication *)application
method (doc), in your AppDelegate. This method gets called the exact same moment you start pulling down the notification center, but it also gets called in other situations (for example, every time your app moves to background, or a SMS message comes in...).
If you need to differentiate the behavior from the - say - "background" case, you should note that when pulling down the notification center the - (void)applicationDidEnterBackground:(UIApplication *)application method doesn't get called, while in the background case, it does.
Hope this can help!
Question 1.
I am seeing following behavior on iphone 4 and iOS 5.0.1
register using addPeriodicTimeObserverForInterval to receive updates every 250 ms and update UI.
works well till the app goes to background. For eg. hit the home button or lock the screen,
When app comes back to foreground the player starts playback again but the updates dont fire again. If user hits the play pause button again on the UI updates start firing again.
This can be seen in the demo app from apple as well.
Question 2
Can we not mix C based Audio Session APIs with AV foundation classes? For eg. I have my C based listener registered when AudioInterruptions. But when I use AVPlayer with kAudioSessionCategory_PlayAndRecord they dont get called. When app goes to background AVPlayer pauses without the C based listener getting called.
Is this expected or can I do something? Please note that once I have disposed the AVPlayer instance and my app goes to background again wiht kAudioSessionCategory_PlayAndRecord
set as category the listener function gets invoked.
For your first problem, most likely you are not releasing the addPeriodicTimeObserverForInterval as suggested. Try putting something like this in your AppDelegate:
- (void)applicationDidEnterBackground:(UIApplication *)application
{
[_audioManager.audioPlayer removeTimeObserver:_audioManager.timeObserver];
_audioManager.isUIActive = NO;
}
and the appropriate method to restart the periodic time observer:
- (void)applicationDidBecomeActive:(UIApplication *)application
{
[_audioManager setUpTransportUI];
_audioManager.isUIActive = YES;
}
where setUpTransportUI recreates your time observer.
When the ipad goes to sleep i.e. the screen turns off, the user will turn it back on and the current application at the time is still open. Is there a way to detect this event that the ipad has woken up from sleep?
I want to be show an UIAlert whenever it goes to sleep and wakes up.
Take a look at the - (void)applicationDidBecomeActive:(UIApplication *)application delegate method of the application delegate.
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