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".
Related
I have implemented application:didReceiveRemoteNotification:fetchCompletionHandler:, which is necessary to run after receiving a push notification. I have also turned on "Background Fetch" and "Remote notifications" background modes. And my push notifications include the content-available flag, set to 1.
If my app is in the Active, Background or Suspended state, this function gets called appropriately and the app temporarily moves into the Inactive state. However, if my app has been purged from the Suspended state due to a low memory issue (i.e. the user has opened a number of other apps since launching my app, a fairly common occurrence), it moves into the Not Running state. At that point, it doesn't call the didReceiveRemoteNotifications function.
The documentation for this function states:
If you enabled the remote notifications background mode, the system launches your app (or wakes it from the suspended state) and puts it in the background state when a remote notification arrives. However, the system does not automatically launch your app if the user has force-quit it. In that situation, the user must relaunch your app or restart the device before the system attempts to launch your app automatically again.
The scenario where the user force quits the app and so the app doesn't call this function is acceptable. But what I'm seeing instead is if the system terminates the app for a fairly common reason, then this function doesn't get called.
I've also tried implementing application:didReceiveRemoteNotification:, the deprecated function, to see if that gets called when the app is in the Not Running state. It doesn't.
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
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
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 tried various samples from the web (the last one being this one) in order to get a better understanding of NSUrlSession.
What I was hoping to see: file downloads will continue even if the app that triggered them gets killed (for instance by the user through the task manager). However this does not seem to happen.
Is this a configuration issue or does background file transfer not work if the app gets terminated?
I thought the whole idea was that iOS will restart the app.
If the system kills your app and your background session has active downloads, your downloads will continue and the system will launch your app when the downloads complete. However, if a user force quits your app, all tasks get cancelled.
Documentation for backgroundSessionConfigurationWithIdentifier:
If an iOS app is terminated by the system and relaunched, the app can
use the same identifier to create a new configuration object and
session and retrieve the status of transfers that were in progress at
the time of termination. This behavior applies only for normal
termination of the app by the system. If the user terminates the app
from the multitasking screen, the system cancels all of the session’s
background transfers. In addition, the system does not automatically
relaunch apps that were force quit by the user. The user must
explicitly relaunch the app before transfers can begin again.
No - the app is not relaunched for background downloads when the user has force quit.
The iOS8 documentation for application:didReceiveRemoteNotification:fetchCompletionHandler: says:
Use this method to process incoming remote notifications for your app.
Unlike the application:didReceiveRemoteNotification: method, which is
called only when your app is running in the foreground, the system
calls this method when your app is running in the foreground or
background. In addition, if you enabled the remote notifications
background mode, the system launches your app (or wakes it from the
suspended state) and puts it in the background state when a push
notification arrives. However, the system does not automatically
launch your app if the user has force-quit it. In that situation, the
user must relaunch your app or restart the device before the system
attempts to launch your app automatically again.