Beginning Networking with URLSession

Before you go any further, there are two very important concepts to understand: 1. Priorities. 2. And cache policies.

Let’s start with priorities first. When you create a task, such as a downloading task, you can suggest a priority level for that task to run at. This priority suggests how to organize the session tasks from your app.

The keyword being suggests as, at the end of the day, the operating system will determine the ultimate priority for your task, but a little help goes a long way.

For instance, you may be downloading some data in the background, but the data isn’t that important. Maybe you are downloading the latest version of your documentation. By default, the system will assume your task is a default priority, but you can set it to a low priority instead.

The OS may respond to your suggestion to run at low priority, or if the system isn’t particularly busy, it may keep your task running at a default priority. Later it may switch it to a lower priority when more resources are taken.

This priority is a number that ranges for 0 to 1.

The default priority of a task starts at .5. That is, the midpoint.

URLSessionTask does provide named priorities such as defaultPriority which is .5, lowPriority for 0 and highPriority for 1.

You set the priority on the priority property of any task object. Once you set the priority level, you aren’t locked to it. You can switch a task’s priority level at any time.

Along with sessions, you also have caching. Larger downloads can make good use of a cache to reduce network traffic.

This flowchart is from Apple’s documentation. It’s pretty much the way you’d expect a cache to be used: If a cached response does not exist for the request, the URL loading system fetches the data from the originating source.

You have lots of different caching options; from ignoring all caches and making a fresh request every single time, to using a cache regardless of age of expiration time. You have a lot of options.

The default cache policy is to use the protocol’s cache policy. The protocol is usually HTTP. You set your cache policy on a URLRequest or you can set the cache policy on the session configuration object using the property, requestCachePolicy.

If any of those policies don’t fit your use case, you can manage the caching yourself. You implement the delegate method willCacheResponse. This delegate method is only for uploads and data tasks. It is also not called for background or ephemeral configurations.

For more information on caching and how to access the cached data, see Apple’s Accessing Cached Data article on the developer portal.

Now it’s time to put some of these concepts into practice. So I’ll see you in the next episode! :)