When I try to start a basic NSURLSession transfer while the network is offline (air plane mode), with NSURLSessionConfiguration defaultSessionConfiguration and ephemeralSessionConfiguration, I of course immediately receive the NSError :
Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline."
But with NSURLSessionConfiguration backgroundSessionConfigurationWithIdentifier, the NSURLSession never returns, no response in any way, no timeout fired, it get stucked.
This happens with iOS 8.x. With iOS 7.x, I got the NSError as expected.
Why that ? Is there a way to get some error back ?
1
votes
Hmm. One of the key features of background sessions is that it won't try to initiate the connection until the remote server is reachable. Is it possible that you just check reachability before initiating the request?
– Rob
Yes, of course, I know I could use Apple Reachability sample code, to check the reachability before initiating the request. But I didn't knew background sessions don't try to initiate connection while offline. By the way, if I start the background transfer with a reachable network, and then I cut the network off, the session gets sucked too. If I reconnect to the network again, the transfer resumes.
– user3048615
WWDC 2014 What's New in Foundation Networking discusses this feature of background sessions. Regarding timeout behavior in iOS 7 v iOS 8, see stackoverflow.com/q/26379449/1271826.
– Rob
@Rob I dont think it would be a good idea to use reachability to determine if the original request should be sent. It has been widely discussed at github.
– Utsav Dusad
@utsavdusad - In general, that's right: A governing design principle is that it is often better to try something and let it fail, rather than checking if it could succeed before trying. This is why that README says what it does. But the OP's scenario is different: a background session won't trigger an error, so if you want to see if the network is available or not, then you have to check.
– Rob
1 Answers
3
votes
In general, an NSURLSession background session does not fail a task if something goes wrong on the wire. Rather, it continues looking for a good time to run the request and retries at that time. This continues until the resource timeout expires (that is, the value of the timeoutIntervalForResource property in the NSURLSessionConfiguration object you use to create the session). The current default for that value is one week! In other words, the behaviour of failing for a timeout in iOS7 was incorrect. In the context of a background session, it is more interesting to not fail immediately because of network problems. So since iOS8, NSURLSession task continues even if it encounters timeouts and network loss. It continues however until timeoutIntervalForResource is reached.
So basically timeoutIntervalForRequest won't work in Background session but timeoutIntervalForResource will.
I got this answer from one of the members of Apple Staff at the developer forum. Also, I have verified this by implementing.
