When does the method applicationDidBecomeActive get called? What is the purpose of this method?
Understand the states and transitions of an iOS
States
Non-running - The app is not running.
Inactive - The app is running in the foreground, but not receiving events. An iOS app can be placed into an inactive state, for example, when a call or SMS message is received.
Active - The app is running in the foreground, and receiving events.
Background - The app is running in the background, and executing code.
Suspended - The app is in the background, but no code is being executed.
The seven most important application delegate methods
The operating system calls specific methods within the application delegate to facilitate transitioning to and from various states. The seven most important application delegate methods a developer should handle are:
application:willFinishLaunchingWithOptions
Method called when the launch process is initiated. This is the first opportunity to execute any code within the app.
application:didFinishLaunchingWithOptions
Method called when the launch process is nearly complete. Since this method is called is before any of the app's windows are displayed, it is the last opportunity to prepare the interface and make any final adjustments.
applicationDidBecomeActive
Once the application has become active, the application delegate will receive a callback notification message via the method applicationDidBecomeActive.
This method is also called each time the app returns to an active state from a previous switch to inactive from a resulting phone call or SMS.
applicationWillResignActive
There are several conditions that will spawn the applicationWillResignActive method. Each time a temporary event, such as a phone call, happens this method gets called. It is also important to note that "quitting" an iOS app does not terminate the processes, but rather moves the app to the background.
applicationDidEnterBackground
This method is called when an iOS app is running, but no longer in the foreground. In other words, the user interface is not currently being displayed. According to Apple's UIApplicationDelegate Protocol Reference, the app has approximately five seconds to perform tasks and return. If the method does not return within five seconds, the application is terminated.
applicationWillEnterForeground
This method is called as an app is preparing to move from the background to the foreground. The app, however, is not moved into an active state without the applicationDidBecomeActive method being called. This method gives a developer the opportunity to re-establish the settings of the previous running state before the app becomes active.
applicationWillTerminate
This method notifies your application delegate when a termination event has been triggered. Hitting the home button no longer quits the application. Force quitting the iOS app, or shutting down the device triggers the applicationWillTerminate method. This is the opportunity to save the application configuration, settings, and user preferences.
need additional information ref this link1 or apple link2
When a user is using an application he is in an active state. The user switch to inactive state from a resulting phone call or when a pull down notification center is pulled or when the home screen is pressed(This is when the app is told to be in background state) and then the app is opened again(This is when the app is told to be back to foreground state).
So every time the user switches from inactive state to active state
applicationDidBecomeActive this delegate is called
Related
In iOS, we all know that there is AppDelegate method applicationWillTerminate, and it is called when my app is closed by user when it is currently running(i.e. not in background). But I want to do something(save data, for example) when my app is terminated(closed by user or killed by OS) when it runs in background.
PS: my app can run in background.
Do you have any solutions? thanks.
Sorry but you should use applicationWillTerminate:
This method lets your app know that it is about to be terminated and
purged from memory entirely. You should use this method to perform any
final clean-up tasks for your app, such as freeing shared resources,
saving user data, and invalidating timers. Your implementation of this
method has approximately five seconds to perform any tasks and return.
If the method does not return before time expires, the system may kill
the process altogether.
For apps that do not support background execution or are linked
against iOS 3.x or earlier, this method is always called when the user
quits the app. For apps that support background execution, this method
is generally not called when the user quits the app because the app
simply moves to the background in that case. However, this method may
be called in situations where the app is running in the background
(not suspended) and the system needs to terminate it for some reason.
So if you need to save data ALSO when user manually kill the app use applicationDidEnterBackground that it's called if your app support background mode.
If you need to execute code when your app isn’t running, there are
several options open to you depending on what you’re trying to do.
Background fetch will let your app run in the background for about 30 seconds at scheduled intervals. The goal of this is to fetch data
and prepare your UI for when the app runs next.
Push notifications let your app fetch fresh data from your server. You can make a message appear on the device if you want, but it’s not
required – silent push notifications let you skip that part.
Local notifications let you display an alert to the user, along with any media attachments you want and some options for the user to
select from. If they choose those options then your app can be
launched in the foreground or background to handle them.
From:
https://www.hackingwithswift.com/example-code/system/how-to-run-code-when-your-app-is-terminated
You can also use Silent Push Notification
as I mentioned in a similar question: https://stackoverflow.com/a/57245980/6157415
In the GCM client guide for iOS, it shows you to call [[GCMService sharedInstance] connectWithHandler:...] in -applicationDidBecomeActive:, and later it shows you to call [[GCMService sharedInstance] disconnect]; in -applicationDidEnterBackground:.
The placement of connect and disconnect seems asymmetric to me. Is there a reason it is done this way? I feel that it should either be
Connect in -applicationDidBecomeActive: and disconnect in -applicationWillResignActive:, or
Connect in -applicationWillEnterForeground: and disconnect in -applicationDidEnterBackground:
If you look at the Execution States for Apps in Apple's App Programming Guide for iOS, it states that:
applicationWillResignActive:—Lets you know that your app is transitioning away from being the foreground app. Use this method to put your app into a quiescent state.
Compare to
applicationDidEnterBackground:—Lets you know that your app is now running in the background and may be suspended at any time.
For example, if you press the Home button of your device twice, the applicationWillResignActive method will be call immediately, your app is in a transitioning state now. see the image below (Your app leave foreground, but not yet in background):
If you select other app, the applicationDidEnterBackground of your app will be called, and your app enters background. So it is better to call GCMService.sharedInstance().disconnect() when your app is actually in a background state compared to a transitioning state.
Similarly, applicationWillEnterForeground vs applicationDidBecomeActive.
If you are in other app now, and you switch back to your own app, the applicationWillEnterForeground will be called immediately, but your app is might still in an inactive state(which is currently not receiving events).
It might only last for less than half a second, and applicationDidBecomeActive will called immediately after. Because applicationWillEnterForeground is more a transitioning state. So it is better to call GCMService.sharedInstance().connectWithHandler() when your app is actually in an active state(app is running in the foreground and is receiving events).
You might think applicationDidBecomeActive and applicationDidEnterBackground are asymmetric, but these two methods all have a word Did. But two other methods have the word Will, which means a transitioning state.
You can also see the Life Cycle picture from this StackOverflow answer.
Edit after #user102008's comment:
If you do connect in the applicationWillEnterForeground method, then connect method wont be called when the app is first launched. Also, the GCM doc says that Call disconnect when the client app is in the background or when it needs to stop exponential background connection retry, so I think its better to call disconnect when the app is in background, instead of when phone call comes? I think you can use enum with 3 different states connecting , not connected and connected, when the applicationDidBecomeActive method is called, you can check if its not connected or connecting, then you call the connect method again.
I was wondering which event in my AppDelegate is called when I swipe out my running app from within the app switcher? My target iOS is >= 7.0 (i.e. with multitasking support).
Maybe I just don't understand the multitasking paradigm itself... When I swipe out my app from within the app switcher, the app is going to be terminated, right? Or does it continue running in the background?
EDIT-1: Why I am asking: During startup of the app, I connect to my Linux game server by plain sockets. I want to disconnect the socket when the app terminates.
EDIT-2: I am not sure if I am using background execution. I register my network socket within a run-loop object to asynchronously receive inputs from the server socket. Moreover I have a kind of network service installed that periodically tests for network connectivity. This service is using SCNetworkReachabilityScheduleWithRunLoop.
There are situations where applicationWillTerminate: will be called and sometimes not.
More can be read up from the Apple documentation here
Excerpt:
For apps that do not support background execution or are linked
against iOS 3.x or earlier, this method is always called when the user
quits the app. For apps that support background execution, this method
is generally not called when the user quits the app because the app
simply moves to the background in that case. However, this method may
be called in situations where the app is running in the background
(not suspended) and the system needs to terminate it for some reason.
What's interesting to note is that
After calling this method, the app also posts a
UIApplicationWillTerminateNotification notification to give interested
objects a chance to respond to the transition.
It is - (void)applicationWillTerminate:(UIApplication *)application
I am trying to accurately track sessions in our app, and I would like to understand how I can determine if an app open was initiated by a user, as opposed to the operating system.
I define 'session' as when the app has entered the foreground -- this may happen from interacting with a remote or local notification, explicitly opening the app, tapping a deep-link, etc.
Currently I consider a new session every time applicationDidBecomeActive gets called, but that can be initiated by the operating system periodically when it refreshes the app.
I don't want to use willEnterForeground because it's not called when the app is first opened.
I don't want to use didFinishLaunchingWithOptions either because it gets called when a push notification occurs.
It looks like applicationDidBecomeActive is where this code should live, but how do I know when it is called by the system and not by the user action?
I have an app with multiple views. I would like the app to always display a "start view" when it is opened again, even if the user is on another view when the app is quit.
In applicationWillEnterForeground: save the state of the app in a local file.
In applicationDidBecomeActive: load that state of the app.
Hope this helps. Cheers!
Your UIApplicationDelegate offers a place where you can hook up into to define what happen when the app become active or comes into the foreground.
Have a look at the method:
– applicationDidBecomeActive:
This method is called to let your application know that it moved from the inactive to active state. This can occur because your application was launched by the user or the system. Applications can also return to the active state if the user chooses to ignore an interruption (such as an incoming phone call or SMS message) that sent the application temporarily to the inactive state.
You should use this method to restart any tasks that were paused (or not yet started) while the application was inactive. For example, you could use it to restart timers or throttle up OpenGL ES frame rates. If your application was previously in the background, you could also use it to refresh your application’s user interface.
In this method you can define which view your app displays when it is launched, both when the app is initially launched and when the app comes back from the background state.
An alternative would be to prevent the app from entering the background state, which means that the app would be always launched and go into the initial state you define. You can do that by setting the "Application does not run in background" (UIApplicationExitsOnSuspend) key in your app plist file to "YES".