To stop blocking the main threat and write concurrent networking code,

we're going to use the URLSession set of classes.

Back in our view controller,

let's get rid of the two lines of code using the data type to retrieve it, and

print out the contents of the URL request using JSONSerialization.

So all of that, gone.

Instead of using the data type to fetch our JSON data synchronously,

which is a big no-no, we're going to use the URLSession collection and

its set of related classes to conduct an asynchronous request.

A URLSession object provides us with API

to download content over the web using HTTP.

Either using delegate methods or closures, with a URLSession API you create

a session object which carries out all of your networking tasks.

The first thing we need to do to create a session object

is to configure a URLSession configuration object.

A configuration object defines rules to use when uploading and

downloading data using a session.

So always remember, when uploading or downloading data,

creating a configuration object is always the first step you must take.

The session object lets you configure a bunch of different things,

like authentication and cashing policies.

But we're not going to dive in to the nitty-gritty for this course.

We just want a default configuration so we can get started.

And luckily, there's a class method that creates an object with all the options

set to default.

So we're gonna say let configuration = URLSessionConfiguration.default.

Now that we have a configuration for our networking needs,

we can create a session object to manage the network session.

So we'll say let session = URLSession,

and it takes the configuration and we can pass that through.

Now, another easy way, since this is a static property on the type,

we actually can just get rid of this.

And here, since it knows the type that it wants to accept,

we can say .default, and the compiler knows what we mean.

Using the session object, we can create a task to carry out.

The base class for this purpose is URLSession task.

But there are two subclasses that are more suited for our purpose,

URLSessionDataTask and URLSessionDownloadTask.

Now, which of the two do we use?

URLSessionDownloadTask retrieves the contents of the URL and

saves it to a temporary file on disc.

in contrast, the URLSessionDataTask returns data directly to the app,

in memory, as a data object.

We don't need to save our data to the disc, so we're going to use the dataTask.

A task is created as a method on this session object we just created.

Okay, so we're going to use the dataTask method to fetch our data.

There are two versions of this method.

So let me just start typing it out, so we'll say session.datatask.

And here you can see two versions, we'll focus on these ones,

one that takes a URL and one that takes a request object.

If we use the URL version of the method, a request is created for

us with the configuration options on that request set to some sensible defaults.

So the second version of this method takes a request that is an instance of

URLRequest and performs a GETRequest to fetch data from the web.

The method also has a completion handler that is called when the task is completed.

We'll get into what a completion handler is in just a second.

So we're gonna use this one, that takes a request.

What's a request again?

Well, when interacting with an HTTP server, a client sends an HTTP

request to the server that contains information about the data you want.

Request object encapsulates information about the type of request message,

which in our case is a get method, a URI, and e set of header fields.

We are going to be creating a very basic request object using the URL request

class.

To learn more about HTTP requests in general,

check out the course linked in th Teacher's Notes.

The URL request class has an initializer method

that we can use to construct a request object with a URL.

The forecastUrl we created earlier is an optional URL.

So first, we'll go up here and we'll use a guard, G-U-A-R-D,

guard statement to unwrap this.

Else return, so if we don't have a URL object, we'll just exit viewDidLoad.

Okay, now that we have a URL, up here, let's create a request.

So we'll say let request = URLREQUEST.

This takes a URL, and we can pass in the forecastUrl.

Now, when we do this, we initialize a request with a URL,

it creates an HTTP request that defaults to a get request.

Now that we have a request, we can use this to create a dataTask.

So right below, we'll say session.dataTask, and as you can see,

there are four versions of the method.

First, we're gonna choose the one that takes a URL request.

And then second, we're going to choose the one that takes a URL request and

a completion handler.

Here we'll pass the request through.

The second parameter in the dataTask is a completion handler.

A completion handler, this one that you see here, has a type or

a signature that seems like a function.

And that's exactly what this is, it is a closure.

The function takes three arguments, an instance of data, optional data, and

instance of optional URL response, and an optional error.

Return type is void.

A completion handler is a closure that we define

containing the logic of what we want to do after this request has completed.

When we write asynchronous code, because it happens in the background,

we cannot control when our code is executed.

For this reason, this method has no return type.

Rather it doesn't give us a data object back

like the method we used earlier because it's not going to finish right now.

So over here you see, when you call this method, it executes immediately.

It's a synchronous method, it has a return value that we can assign to a constant.

These methods don't work that way.

Because it's asynchronous and it's shuttled off into the background for

the system to handle with, we have no idea when it will be finished.

So what we do is we define a function containing some logic.

We define a closure containing some logic, and this closure is packaged up.

And the system executes this closure whenever the request is done.

Now we use a closure because a closure can capture references to

all the objects we need and execute the logic at a later time.

The closures used in this way are called callbacks.

The dataTask is executed, and

then when it is done, it calls back to our closure and executes the body.

Another way we can implement the same kind of behavior is by using

the delegate pattern.

An object can complete the task, and

when it's done, it can inform or call back to the delegate.

The delegate then performs further actions with whatever data is returned.

When we learned about closures, we defined a simple function.

Let me throw that up on the screen again.

We defined a function that accepted, as an argument, a function named operation.

And here we can write a trailing closure.

In the body of the function, we call the function or

closure expression and provided argument.

The method we're using, dataTask,

works in the same way, except we haven't defined it.

So we don't know what the body of this method looks like.

This function accepts another function, or a closure expression.

And our job is to provide that closure.

Much like our apply operation had a single argument, this closure accepts three

arguments, an instance of data, containing the data returned by the network request,

an instance of URL response, which defines the response returned by the remote

server, and any errors that may have occurred.

All of these objects are optional because if we have valid data,

then we won't have an error and vice versa.

Now, inside this closure, we define what we want to do with these instances.

When the dataTask is complete,

just like we called operation in our closure and passed in an argument,

the dataTask method will call our closure and provide the data, response,

and error objects it obtains by making the network call as arguments to our closure.

So in this way, we define a callback.

Now back to our code, the completion handler takes a closure expression with

three parameters, optional data, optional response, and optional error.

The bulk of our work is going to happen inside this closure.

So let's take a detailed look at these arguments.

And the first argument here contains

a data object with the results of our get request.

Just like when we used the initializer, contentsOf, directly on the data type.

Now the second argument here is a response object.

URLResponse contains a bunch of metadata about how the request was carried out so

we can check to see if the request succeeded.

And then if it did, we can access the data.

Finally, if we have any errors, they're stored in the error object.

Since this is the last parameter in the function, we can write this

out as a trail enclosure, so we have data, response, error in.

Now, inside the crucial body for now, I'm simply going to print out the data

object to the console to see if this works.

So what I'm doing here is I'm defining a closure and

giving that to this dataTask method.

The body of the closer just simply says, print the data.

Whenever this dataTask is complete, it's going to unpack this disclosure,

look at the body, and do whatever the body says, which is print the data.

It may seem like it's happening immediately,

like it's a synchronous method, but again, we're fetching very little data, and

this is happening very quickly.

So it just feels like it, but it is indeed happening in the background.

Now, this method dataTask that we're calling on the session object

creates that task for us.

Along with the closure we define, packs it all together, and

returns that task itself.

So we can assign this back to a constant.

Now, it's very important to keep in mind that what is being returned here is not

a return type from executing the network request.

All we're doing here is creating a task,

we're not calling out to the network at all right now.

And you can verify this by running the app and waiting, and

nothing is going to work because all we're doing here is creating the task.

There won't be anything printed out.

To run the task, we actually have to call dataTask.resume.

You may be confused, I never called start or stop, so how can I call resume?

Well, that's just the way Apple wrote this API.

The task is added to the session and made active when we call resume.

When it's done, the task automatically stops.

So now, if we go ahead and run it, may take a second, but just like before,

you should see the byte information pop up in the console.

You'll see that it's optional because remember,

this is an optional instance of data.

How is what we did different, though?

The difference is mainly how URLSession conducts a network request.

The APIs are asynchronous,

which again means that it is not carried out on the main thread.

Our dataTask is carried out on a background thread.

And when the task is complete, we use the closure as a callback mechanism.

Now, you can see this in action by adding a couple log statements.

So right before the dataTask is carried out, we'll say print ("First").

And then in order, we'll say print ("Second") over here, right,

because we're writing this line of code after.

And then right below, we'll say print ("Third").

If I run this again.

You should see something unusual.

So instead of printing in the order it was written, First, Second,

Third, we have First, Third, and Second.

And that's because obviously we hit the print statement First first, and

we print it out, but this is just packaged up and given to the background.

Immediately then we call Third, and

then once the task actually starts in the background and finishes, it calls Second.

Now, again, you might say, well, Third is called before you start the task, so

that's why it's happening.

But if you put it down below here and

run this again, you'll see that we get the same results.

So First, Third, and then Second.

And that's because anything that's inside this closure is executed in

the background, whereas everything else is on the main thread and

happens immediately.

All right, let me get rid of this.

So this is a much better implementation than our previous one

where we blocked the main thread.

But if you remember, I mentioned that we were doing more than one thing wrong.

Well, we just talked about the first issue, writing synchronous code,

and the second one is that our code is tightly coupled.

Everything is in the view controller.

Now, this is bad because we can't reuse any of this code.

Let's fix that.

There's also a third issue,

but we'll wait a second, we'll talk about that in a few videos.