According to Apple:
Note
You don’t have to do all background network activity with background sessions as described in this article. Apps that declare appropriate background modes can use default URL sessions and data tasks, just as if they were in the foreground.
I'm trying to use my DataTask with default session configuration and delegates (not completion handler) but my data task is always failing if I press the home button and switch back to the app again:
Task <A25361F9-CAC0-4FA8-8663-777E1C6878A2>.<2> load failed with error Error Domain=NSPOSIXErrorDomain Code=53 "Software caused connection abort" UserInfo={_NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <A25361F9-CAC0-4FA8-8663-777E1C6878A2>.<2>, _kCFStreamErrorDomainKey=1, NSErrorPeerAddressKey=<CFData 0x108f07b40 [0x1db6c1420]>{length = 16, capacity = 16, bytes = 0x100201bb68118e240000000000000000}, _kCFStreamErrorCodeKey=53, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalDataTask <A25361F9-CAC0-4FA8-8663-777E1C6878A2>.<2>"
What I tried: using the shared session with or without completion handler, same problem.
My question is: what does this mean "Apps that declare appropriate background modes can use default URL sessions and data tasks"? How do you declare those background modes??
The only thing I came across is UIApplication.shared.beginBackgroundTask
Is this what Apple means by "Appropriate background modes"? Or Am I missing something?
thank you
Yes, beginBackgroundTask(withName:expirationHandler:) is the correct way to request the OS to give your app a little time to finish requests it started before the user left the app. See Extending Your App's Background Execution Time.
Is this what Apple means by “Appropriate background modes”?
They’re talking about any of the techniques that might have your app running in the background. See About the Background Execution Sequence. And a “background task”, in which you’re given a finite amount of time to finish a task even though your app is no longer in the foreground, is one of those modes.
Another is background fetch. If enabled, during background fetch, the OS may, at its sole discretion, fire up your app in the background, let you perform a request, and you then call the completion handler when it’s done. (In that case, you have even less than 3 minutes, something more like 30 seconds IIRC.) That is an example of an “appropriate background mode” for which you’d use a standard/default URLSessionConfiguration, not a background one. Apple makes a point of this because it would otherwise be easy to assume that any background-related network requests would require background URLSessionConfiguration. But that’s not the case.
So, if you’re just trying to let the app keep running a bit to finish the task even if the user hit the home button, then beginBackgroundTask in conjunction with a standard URLSession is adequate. Or if you happened to be using one of those “approved background modes” (which doesn’t sound like would be the situation in your case), then again, a standard URLSession is adequate.
A background URLSession is really for those cases where request may take longer than the allotted time. Perhaps you’re downloading many very large assets, such as a movies, that might take more than a few minutes. Only in that case do you need to use a background URLSessionConfiguration.background(withIdentifier:). It just depends upon how long the request(s) will take.
Related
How to handle the states in which the app goes into foreground setting off a number of requests (around 3-4 minimum) because that information is required in the app, and then going to background?
What I have tried is to use a RequestManager to suspend the URLSessionDataTasks when app goes into background and when app resumes, resume those tasks again. But I don't see this working very well.
Is there a standard way to go about this?
Suspending tasks won't work, because the session no longer exists if your app gets jettisoned for low memory.
The most straightforward approach would be to use a download task in a background session, then read the resulting temporary file when it finishes downloading. Download and upload tasks in background sessions are the only types of tasks that can survive your app getting jettisoned while in the background because of memory pressure.
If you absolutely must avoid downloading while the app is in the background (why?), you could create a download task in either a foreground or background session, then stop the download tasks by calling cancelByProducingResumeData: when your app gets backgrounded. You can later continue the request by calling downloadTaskWithResumeData:.
There is a rather large caveat with that approach, though, which is that the resume data portions of the API are not nearly as well tested as the background downloading portions. Case in point: in every version of iOS 10 from the first beta until 10.2, support for resume data was completely broken. (There is a rather horrific workaround, in case you choose to go down that path.)
So I would recommend the first approach unless you have some contractual or legal obligation not to do so.
We're working on an enterprise app that sends form data entered by the user to the server. The app attempts to send the data immediately after the user taps Save. If there is a problem sending the data (e.g. no network connection), we want to try again X minutes later, and periodically retry until the data is successfully sent. The requests are typically not very large or long-running, but the user is frequently in environments without network access, so retries are important.
It's simple enough to retry API requests when the app is running, but ideally we want to keep periodically retrying when the app is in the background. What is the best that we can achieve with iOS background execution features? Here are some options I see:
Use beginBackgroundTaskWithExpirationHandler: to make a one-time request for additional time. This would give us basically one additional attempt to send the data after the app goes to the background, but not repeated attempts
Use the "background fetch" feature, and attempt to send any new data to the server when the app is woken for background fetching. Sounds good in theory, but I'm concerned this may be an abuse of the background fetch feature?
Is one of these my best option? Is there another approach I'm missing?
This is a Xamarin app with iOS and Android implementations, though I don't think that has a significant impact on my question; I can write iOS specific code as needed.
I think there is one approach that you missed : background NSURLSessions. And I think this is what you should use.
I don't really know how many shots you can have with this. Here is what I recommend :
Begin a background task as well (with beginBackgroundTaskWithExpirationHandler:) when you start your background download.
As long as your background task hasn't expired, you will be able to restart the download, even if in the background.
If and when your background task expiration handler is called you need to end the background task immediately. At this point your app will stop executing and your download will continue in an external process.
When the download completes or fails, your app will be restarted in the background and given a chance to handle the result. The thing I don't know is if you will be able to start a new background download at this moment. You should just try or wait for someone that knows better than me...
Also be sure to check the -(void)URLSession:(NSURLSession *)session downloadTask:(NSURLSessionDownloadTask *)downloadTask didResumeAtOffset:(int64_t)fileOffset expectedTotalBytes:(int64_t)expectedTotalBytes; delegate method in order to restart your download where it failed and not start over.
HKObserverQuery has the following method that supports receiving updates in the background:
- initWithSampleType:predicate:updateHandler:
The updateHandler has a completionHandler which has the following documentation:
This block is passed to the update handler. You must call this block
as soon as you are done processing the incoming data. Calling this
block tells HealthKit that you have successfully received the
background data. If you do not call this block, HealthKit continues to
attempt to launch your app using a backoff algorithm. If your app
fails to respond three times, HealthKit assumes that your app cannot
receive data, and stops sending you background updates.
From looking at other posts it seems like there's a lot of confusion revolving around this handler. Below are some questions that I have about it:
When should the handler be called? If called too late, then HK might think that the app never received the query update causing you to hit the background update 3-strikes back-off algorithm. The documentation states that it should be called after handling other queries. Depending on how long it would take to run those queries, it sounds like you could get dangerously close to hitting the background update strikes.
Why is this needed? Shouldn't the system know that the app has been launched and has received the background update? When using CoreBluetooth in the background it just wakes your app up in the background for 10 seconds. No need to call any handler or deal with the background update 3-strikes.
If you hit the background update 3-strikes and HK stops sending updates is that permanent? Does HK ever start sending the background updates again? What if there's a bug that prevented the handler to be called and now you've fixed it. Is the app stuck never receiving the updates? Or will it reset when the app is re-launched or updated?
Does HK keep your app running in the background until the handler is called? Is that part of its purpose or just a side effect? If it's part of its purpose how long can we run before needing to stop (and hit the first background update strike)?
When should the handler be called?
Call it after you are done your job. Your code should not do complex operations. The app is in the background and the user does not see what's changed. You can just set a "flag" that data is updated and do complex operations after the user launched the app. If your decision about either notifies the user or not based on complex operations, then try to refactor code so that all necessary data is pre-calculated (e.g. in UserDefaults) and extra data is simply fetched with that data. So, 1-2 seconds is enough for your calculation.
Why is this needed?
All such handlers have completion closures. They are needed for iOS to know if your app works fine. If your app will eat too much CPU time, then iOS could become slow. Hence, Apple wants to be sure that iOS works fine despite bad apps.
If you hit the background update 3-strikes and HK stops sending updates is that permanent?
No.
Does HK ever start sending the background updates again?
Yes. But it depends on many factors. It may try to call your app again in 1-2 days. If nothing changes it will call it rarely.
Does HK keep your app running in the background until the handler is called?
This is unknown. It depends on many factors. Probably if iPhone is charging it will allow running your app longer just to estimate if the completion handle is called or not. If your iPhone is not charging and closed to 0% battery, then more likely iOS will kill your app. So, you should not do any job after you called the completion handler. And try to keep it simple.
Recommendations
You should process new data as quickly as possible. If you need to fetch a lot of data, then try to optimize this and pre-calculate it when the app is in foreground, then save somewhere (UserDefault), and use new data with cached data to make a decision (e.g. notify user about something; I believe you need background updates exactly for that).
1-2 seconds or less is a good time for background updates.
I'm writing a iOS/Swift application which reads data from a REST service each X minutes and updates the UI accordingly.
Now I would like that when the app is put in the background, a task keeps being invoked at X minutes intervals reading from the REST service and, in case the data just read satisfies a given condition, show a notification prompting the user to bring the app back to the foreground.
In my searches I've read that during applicationDidEnterBackground event, I should start a task with beginBackgroundTaskWithExpirationHandler.
The problem is that, if I've understood correctly, this allows a maximum of 10/15 minutes after which the app is terminated if the task is not stopped with endBackgroundUpdateTask, while I want the task to keep polling the service indefinitely (at least until the user disable it from the app's settings)
My question is:
How is this kind of functionality performed normally? Do some common solutions or best practices exist for the solution of such a problem?
Use iOS Background Fetch feature where you can specify minimum background fetch interval. But actual interval between successive invocation of your code will be determined by iOS framework. For details checkout this link: http://code.tutsplus.com/tutorials/ios-7-sdk-working-with-background-fetch--mobile-20520
I use this approach in my app and I think it is a preferred way of doing.
You can use a local notification that can be presented from the background in case your condition is met.
Correct, iOS will eventually shut down the background process, you can't enforce continuous background activity. Use the backgroundTimeRemaining property to check how much time your application has left and try to handle it as gracefully as possible by calling endBackgroundTask so that iOS does not force kill your app.
As a solution, you could think about using remote notifications with with content-available : YES, which runs the didReceiveRemoteNotification
Have a look at the Parse.com Their local datastore is an abstraction for what you are trying to acheive.
By the way, is it really necessary to refresh in the background. If call is relatively quick, there is no need to refresh until the user open's the app. Background processes like that, using the net can be quite battery consuming when the user are not on a Wifi. So consider the use case carefully!
After reading the Apple documentation about the background download with the new iOS7 api (NSURLSession), I'm a bit disappointed. I was sure that Apple was managing the pause/resume over the network availability in the background (or provide an option to do so) but no…
So reading the documentation, this is what we've got:
https://developer.apple.com/library/ios/documentation/cocoa/Conceptual/URLLoadingSystem/NSURLSessionConcepts/NSURLSessionConcepts.html
When any task completes, the NSURLSession object calls the
delegate’s URLSession:task:didCompleteWithError: method with either an
error object, or nil if the task completed successfully.
If the task is a resumable download task, the NSError object’s userInfo dictionary
contains a value for the NSURLSessionDownloadTaskResumeData key. Your
app should use reachability APIs to determine when to retry, and
should then call downloadTaskWithResumeData: or
downloadTaskWithResumeData:completionHandler: to create a new download
task to continue that download. Go to step 3 (creating and resuming
task objects).
So far I understand the solution, but my question is: What architecture is the best to handle the loss of the network and resume downloading in the background?
On my side I'm using reachability and each time the network is available, I resume all tasks (referenced over a NSArray when creating), and suspends them when network is lost. This works well in foreground but for the background I need help on the following points:
If my app has no connectivity in foreground, if I go to the background without connectivity all my tasks remains suspended and won't came back if network is available…
Losing network in background, stop all my downloads/tasks.
Scenario:
In foreground, I start downloading my tasks
I go to background and after 10s switch to "aireplan mode"
All my tasks got an error. So in the method URLSession:task:didCompleteWithError: I resume them using
downloadTaskWithResumeData or if I can't (because some have not
enough resume data) I'm creating a new task without resume-ing it (except if network is back at that time).
Then I put the wifi up
As I'm still in background I cannot trigger a "resume" when network is back without launching the application…
How do I address these points? Have I missed something?
As I'm still in background I cannot trigger a "resume" when network is back without launching the application…
you can use "background fetch"，when the app is launched by fetch，then you can check network and resume the download task.
You should create the NSURLSession with background configurations, then your task is sent to a background demon and your app get called when it is completed.
Implementing:
application:handleEventsForBackgroundURLSession:completionHandler:
in the app delegate - without calling the completionHandler - causes the app to hang around in the background after the device loses its connection whilst suspended. That way, the app can still listen to reachability notifications and restart the download when a network connection becomes available once again. However, this is a pretty dodgy approach and may not pass Apple's app store submission guidelines. Additionally, this approach isn't much help when the connection is lost while the app is in the foreground and the connection regained whilst the app is suspended.
In the end I did the following:
Made use of the application:handleEventsForBackgroundURLSession:completionHandler: notification to pause my downloads in the background.
Made use of the intermittent background fetch notification (ie. application:performFetchWithCompletionHandler:completionHandler) to check connection status and restart any paused downloads. (hat-tip #gugupluto)
This still doesn't provide optimal download performance and may lead users to wonder why their "background download" hasn't finished once they reopen the app, but it seems to be the best we can hope for from Apple for now.