Go over the built-in network objects such as NSURLSession, NSURLSessionConfiguration, and NSURLSessionTask.
- [Instructor] Let's start with an overview of some of the building blocks in the native iOS SDK provided by Apple, starting with URLSession. URLSession is a class from which we generate network tasks called URLSessionTasks. These task objects are our primary method of transferring data to and from network services. All tasks created from a single session will have the same configuration based on that session. A URLSession will also manage all of the underlying network details required for each task it creates.
Many times, you'll use a single URLSession throughout your app. URLSession has a convenient property to hold on to the shared common session for use anywhere in your app. But having more than one session can be useful for a variety of scenarios. My rule of thumb for the number of sessions is one session per service plus another one for any general download task such as image caching from a public service. URLSessionConfiguration, as its name suggests, configures a URLSession.
Apple has provided convenience methods for creating three commonly used session configurations. The default session has characteristics that you'll use most often such as a disk based cache. The default configuration will also use the shared cookie storage, and store credentials in the user's keychain, while the ephemeral configuration saves all session related data into memory only. So caches, credentials and cookies will ultimately not be persistent. And finally, the background configuration is for use with background upload and download tasks.
You'll generally need an identifier for your background session, as this is how you'll resume your connection to upload or download tasks that you've handed to the URLs after it has been placed into the background. A session will use pieces of the configuration as a template to create tasks. For example, if you have a single service which needs all requests to be configured with a particular HTTP header, you will set that common header in the session configuration. URLSessionTask are the worker objects.
As mentioned previously, tasks are created by a session and the session will manage all underlying network code necessary for the task to operate. You can create four types of tasks, data, download, upload and streaming tasks. Data tasks will return responses directly in memory so you'll generally want to use these tasks for simple service API calls. Download tasks will save response data from a request directly to a temporary location on disk.
Use this task to save large files. Upload tasks are designed to support HTTP requests that require bodies of data such as PUT and POST. If your upload request results in a response from the server, this result will be in a URL response object loaded into memory. In addition to these request objects, we'll also be working with a number of other objects and protocols. The URL object, is as you might expect, used to specify the location of a resource. URLs can be local or remote.
In general, we'll use a URL with the URLRequest to help generate a URLSession task from the URLSession. The URLRequest may override some the session based defaults such as cache policy and request timeout. Once a request has been handled, we'll analyze a URLResponse object, and more commonly, an HTTP URLResponse object. The response will contain useful information such as HTTP status code, and any headers sent.
Occasionally, we'll need to build a URL from smaller parts. For this task, we have the URLComponents object at our disposal. This object can take the parts of a URL such as a scheme, a hostname, a path and query parameters and build a correctly formatted URL for use by any one of our APIs requiring a valid URL. We also have at our disposal objects such as URLCache and URLCredential to override some of the defaults for our URLSessionConfiguration.
HTTP cookie storage can also tweak how our network data is stored. And last, I want to mention several delegate protocols we have available. These protocols define various points in the life cycle of a type of a task, and let's us see the status of a task at these points. We'll dive more into these delegates later. For now, we'll be using the block based APIs to handle our responses. Well, that's a good overview of all the classes you'll encounter when working with network services on iOS.
Now let's dig into our example project and start writing our next awesome iOS application.
- Requesting data from an HTTP server
- Parsing with JSON
- Decoding JSON
- Parsing data with XML
- Loading data a page at a time to avoid HTTP errors
- Error handling
- Loading and caching image data