Is this possible to download data when the application is terminated? I want to download data at a particular time to get new updates in my API. And if data download in the background after that if user run application again, the user has no need to wait for download new data.
If the application [server] that is serving the content has been terminated the answer is no. (There is nothing to continue writing data out to the buffer/stream)
You will need to provide more details regarding your applications concerns to determine if there is some sort of caching layer that could be implemented which would allow your downloads to be resumable in some cases.
No, you can't continue download when your app get terminated by user! Your app must require to remains in background state!!! Because if user force close app that means, he doesn't want to run it anymore. If your app is suspended by system then it can be wake up but not if it's terminated by user!
See there are two types of termination, one if user do from app switcher and another one is if iOS do. If user terminates its not possible to do any thing in background. But in case of iOS terminates your app it can continue download or background task. Check about NSURLsession background download for more info.
https://developer.apple.com/documentation/foundation/url_loading_system/downloading_files_in_the_background?language=objc
https://www.raywenderlich.com/567-urlsession-tutorial-getting-started
I agreed with other answer. You can't continue download when your app get terminated by user!
But I'm not agree with you about Background app refresh.
Background app refresh
Here is Apple's definition :
After you switch to a different app, some apps run for a short period of time before they're set to a suspended state. Apps that are in a suspended state aren’t actively in use, open, or taking up system resources. With Background App Refresh, suspended apps can check for updates and new content.
And here some parts from another doc
Apps that need to check for new content periodically can ask the system to wake them up so that they can initiate a fetch operation for that content.
...
Enabling this mode is not a guarantee that the system will give your app any time to perform background fetches.
iOS try to predict when user will launch app on next time. iOS launches the app in background to update content right before the momnent when user launch the app.
Another approach to update content is use the Push Notifications
Here is from Apple's doc
If your server sends push notifications to a user’s device when new content is available for your app, you can ask the system to run your app in the background so that it can begin downloading the new content right away.
Notification’s payload must include the content-available key with its value set to 1. This key lets iOS to know that the notification is silent.
Pushing Updates to Your App Silently.
Related
This app communicates with a hardware accessory. I would like to have the app woken up once every 24 hours to search for firmware updates for that hardware. If an update is available, a notification will be sent to the notification center and the user can tap it to open the app and download the update.
None of the background modes discussed here seem appropriate. The closest is "background fetch" which is meant for an app that "regularly downloads and processes small amounts of content from the network."
The problems with this (all can be worked around) are:
No way to specify how often to wake up to check for updates
An expectation that if content is available, the app will download it immediately (instead, I just want to send the user a notification so they know an update is available)
So should I use background fetch and work around its limitations, is there a different background mode or API that would be better suited, or is this something an app shouldn't do?
You can use background fetch for this, although you can't control if and when this happens (since the user can disable it). Instead of immediately downloading the firmware update, if you want to inform the user you can schedule a local notification to inform them.
Push notifications are a more appropriate solution for this problem though. Just send a push notification when a new firmware update is available.
I want to use iOS7's Background Fetch functionality in order to ping the server once a day.
I don't want to pull any new data - but I just want to know the app is still installed on the phone.
I can enable Background Fetch, set a Minimum Background Fetch Interval of 24 hours and always return UIBackgroundFetchResultNoData to the completionHandler.
I don't need it to be at an exact time each day. Once a day is more than enough.
Will Apple approve my app on the App Store?
Can I rely on the iOS to wake my app at least once a day and perform this action?
I'm afraid that if the answer will always be UIBackgroundFetchResultNoData iOS will stop waking my app.
Looks like Background Fetch and Remote Notifications WILL NOT work if your app was killed by the user.
According to the UIApplicationDelegate Protocol Reference:
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.
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.
I have created background nsurlsession to perform download task. It worked well when the app was in background. However, download task seems to be canceled and failed when I closed the app (double click "Home" button and swipe up), and it made me to download from the beginning again when I relaunched the app. According to Apple document, background transfer works even the app is no longer running. Am I doing anything wrong?
From the NSURLSessionConfiguration Class Reference:
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.
So, while background transfers will continue if iOS itself closes your app during the normal course of things, if you force the quit from the multitasking screen, it will kill all your transfers.
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.
In the first paragraph of NSURLSession documentation, we can observe:
This API provides a rich set of delegate methods for supporting
authentication and gives your app the ability to perform background
downloads when your app is not running or, in iOS, while your app is
suspended.
Now notice where it states:
or, in iOS, while your app is suspended.
It looks like only OS X applications have the ability to finish background tasks while your app isn't running.
Has anyone created an iOS app reacts to events or triggers from external sources other than push (APNS)? For example, could an iOS app subscribe to a remote topic or queue? Or listen for HTTP or socket requests?
No.
Application could be launched if:
User tapped the icon
User selected the Push-notification/Local-notification
Application supports url-schemes and is launched while opening URL
Application supports view/edit of documents and user've selected your app to do this
If anyone has other ideas - feel free to edit or add comments.
App could run in background and have active http-connection/socket. But it couldn't be opened automatically.
In addition to user action and push/local notifications, an app can be woken by a significant location change, if the app has indicated that it wants to monitor such events.
See: CLLocationManager Docs
Look for a method called startMonitoringSignificantLocationChanges. If a significant location change occurs while your app is not in the foreground or isn't running at all, your application will be launched in the background, allowing the app to perform background-only operations (e.g. no view code will run).
The app will not launch into the foreground, however, if it is launched due to a significant location change.