URL Loading System Programming Guide - Apple Developer

Life Cycle of a URL Session
Life Cycle of a URL Session with Custom Delegates
If the task failed, most apps should retry the request until either the user cancels the download or the
server returns an error indicating that the request will never succeed. Your app should not retry immediately,
however. Instead, it should use reachability APIs to determine whether the server is reachable, and should
make a new request only when it receives a notification that reachability has changed.
If the download task can be resumed, the NSError object’s userInfo dictionary contains a value for the
NSURLSessionDownloadTaskResumeData key. Your app should pass this value to call
downloadTaskWithResumeData: or downloadTaskWithResumeData:completionHandler: to
create a new download task that continues the existing download.
If the task cannot be resumed, your app should create a new download task and restart the transaction
from the beginning.
In either case, if the transfer failed for any reason other than a server error, go to step 3 (creating and
resuming task objects).
Note: NSURLSession does not report server errors through the error parameter. The only
errors your delegate receives through the error parameter are client-side errors, such as being
unable to resolve the hostname or connect to the host. The error codes are described in URL
Loading System Error Codes.
Server-side errors are reported through the HTTP status code in the NSHTTPURLResponse
object. For more information, read the documentation for the NSHTTPURLResponse and
NSURLResponse classes.
14. If the response is multipart encoded, the session may call the delegate’s didReceiveResponse method
again, followed by zero or more additional didReceiveData calls. If this happens, go to step 7 (handling
the didReceiveResponse call).
15. When you no longer need a session, invalidate it by calling either invalidateAndCancel (to cancel
outstanding tasks) or finishTasksAndInvalidate (to allow outstanding tasks to finish before invalidating
the object).
After invalidating the session, when all outstanding tasks have been canceled or have finished, the session
sends the delegate a URLSession:didBecomeInvalidWithError: message. When that delegate
method returns, the session disposes of its strong reference to the delegate.
Important: The session object keeps a strong reference to the delegate until your app explicitly
invalidates the session. If you do not invalidate the session, your app leaks memory.
If your app cancels an in-progress download, the NSURLSession object calls the delegate’s
URLSession:task:didCompleteWithError: method as though an error occurred.
2013-10-22 | Copyright © 2003, 2013 Apple Inc. All Rights Reserved.
69