The work we did in the previous video is perfectly valid working code but

it's not good code, and moreover it's not obvious that it's not good code.

Before I explain why, a history lesson if I may.

In the early days of computing hardware limitations were a pretty big problem.

The amount of work that we could do was extremely dependent on the speed of

the processor, or the brains of the computer.

We could only do one thing at a time, and we had to wait until a single task was

done before we could move on to the next one.

In time, we innovated and made more powerful processors that were smaller than

their predecessors and could do more work in the same amount of time.

But soon we ran into another problem.

As processors got smaller,

we were limited in the amount of work we could do because of physical constraints.

Now hindrances breed innovation.

And soon we figured out we could add more cores or

more brains to the processor, thereby allowing us to do more work without

affecting the speed of the processor or the size.

Aha, problem solved.

Well, not really.

We have solved hardware issue but now we have to figure out how neatly

take advantage of all this extra cost to do even more work.

At first we came up with decent solution.

We created software that can do multiple thing simultaneously by creating

multiple threads to use these multiple cores.

We use the term thread to refer to a path of execution for code.

This concept is known as concurrency,

the notion of multiple things happening at the same time.

Now in the past, when you wanted to do multiple things, you just did them one

after the other since you could only execute one thing at a time.

With threading we could create multiple threads that use different cores to

execute tasks simultaneously.

This isn't an easy job, though.

Your applications have to know how many threads can be created based

on the number of cores there are.

You need to make sure your threads are executed in some order and

you can't let them interfere with one another.

It is a painful job and they put the burden on us, the developers.

Luckily, even more smart people came along to better solve this problem.

iOS does not rely on threads up front.

It takes an asynchronous design approach to solving concurrency.

A synchronous task means doing something once and waiting until it's done.

Asynchronous means doing something behind the scenes and continuing the main work

regardless of whether the background task is actually complete.

Now this is still done through the use of threads, but

luckily you don't need to worry about it.

The system handles it.

It's abstracted for us.

Instead of managing threads ourselves, we add our tasks to queues.

The system then takes care of creating the needed threads and

scheduling task behind the scene.

But why are we bothering with this, and how is this relevent to us?

You can think of iOS as a highway with multiple lanes.

Each lane here is a queue.

On this highway, we have vehicles speeding along.

Think of these vehicles as blocks of your code executing.

The main lane, the central one, is used for the user interface.

When a user taps, swipes, scrolls, or interacts with the user interface in any

way, this code is given top priority and added to the main queue.

We never want this main queue to get backed up,

because then our app would feel slow or even unresponsive.

When we make a networking call, If we have any issues, and

the request takes a long time because of a slow connection,

for example, it can block the UI if the networking code is on the main thread.

None of the user interface code would get executed, and

the user wouldn't be able to do anything with the app.

They would think it is unresponsive, or broken, and get frustrated.

All of our networking code should be done in a background queue.

One of the side limits, so that we don't block the UI from being responsive.

When the network request complete, we need to move back from the background queue

to the main queue to update our UI since all UI updates are done on the main queue.

And the code we just wrote is synchronized code.

This is like blocking a lane with a slow moving truck.

It's not obvious because our network is pretty fast, at least mine is.

And when I fetch the data, it returns immediately.

But if you had a slow connection and you're trying to update the UI at the same

time that would be like putting a slow moving truck in there.

The app would be unresponsive.

When we write asynchronous code, we move this truck to another lane, and

it keeps the traffic on the main lane flowing as normal.

We need to change our code here to be asynchronous.

Concurrency can improve the responsiveness of your code by ensuring that your main

thread is free to respond to user events.

But before we do that, we need to look at how we can write concurrent code in Swift.