We've successfully asked the user for permission to monitor their location.

But we haven't actually started monitoring their location or

requested a location fix.

With permissions taken care of though,

now we can actually work on the main logic of this component of the app.

There are several ways we can monitor location given our choice of

authorization.

A GPS app, for example,

will constantly monitor the location until you tell it to stop.

If we did this,

every time the user moves to a new location, we are continuously updated.

We want something much simpler.

We just want to know the user's current location and

once we have that fixed, we don't care for any more information.

To do this, we'll simply call the request location method on the location manager.

This method requests the one time delivery of the users location.

Typically, we would need to call start updating location, which is one method,

and then stop updating location, which is its counterpart.

So that we can both begin and end the location request when we need to.

But since the system knows that we only want a single location fix, start and

stop are automatically going to be called for us in the background.

Now remember that we created the location manager, this underlying one,

the CLLocationManager instance as a private object in this class.

So let's add a public method to expose this functionality.

And we'll do that right after the request location authorization method.

So I'll say func requestLocation.

And in here, we'll just say manager.requestLocation.

When we call this method, just like the permission request,

we're not going to get a response immediately.

There is no return value from this function because getting a location fix

is no simple task.

It involves receiving information from a minimum of four different satellites

orbiting the Earth.

And using a bunch of math and physics to find a user's position.

If you're interested in understanding that process at a high level,

you should check out the video linked in the teacher's notes.

It's pretty amazing.

It's actually really amazing because this device that you're holding in your hand is

communicating with some other flying metal object in space.

Okay, because asking for a location fix isn't instantaneously executed,

we're again going to be dealing with callbacks through delegate methods.

One of the reasons the response time varies is because we

can specify the accuracy of a location fix.

Location managers have a property named desired accuracy.

So for example, I can type manager.desiredAccuracy here.

And this takes a value of type CLLocation accuracy.

By default the setting is kCLLocationAccuracyBest,

which is the highest level of accuracy.

But you can see from the values here that you can also set it to a value like

a single kilometer, three kilometers, a hundred meters, or

even the nearest ten meters.

This means that if the core location framework gets a location fix

to the value you that specified.

So let's say three kilometers away from you,

it will accept that as the current location.

But if you have a higher accuracy setting, it's going to keep searching.

So the higher the accuracy, the longer it takes to get a location fix.

And obviously, the more battery life it consumes on your phone.

We're gonna get rid of this, because we're gonna stick to the default,

which is that best value.

As a somewhat related aside, if you're wondering why

delegates are used in some places for callbacks, and closures in others.

Like URL session, for example, with our networking code, it's mostly for

historic reasons.

All of these underlying classes are written in Objective-C.

Xcode is just bridging things over to swift for us automatically.

What are closures to us, in Swift, are known as blocks in Objective-C.

So Objective-C does have the ability to create units of code that can be

passed around, but this is a relatively recent addition to the language.

Objective-C was developed in the early 1980s.

Objective-C 2.0 was released in 2006.

So compare that to Swift, where we got Swift 1.0 in 2014 and 2.0 in 2015.

So here we have Objective-C 2.0 coming out in 2006.

And then in 2010, blocks where introduced as a language feature.

Essentially, when writing a lot of these classes,

Apple's developers could only implement callbacks via delegates.

Newer classes like URL session, or NsURL session,

as the actual Objective-C class is named, were written in a post-block world.

And therefore, could use completion handlers for better encapsulation and for

a different pattern with callbacks.

CLLocationManager, on the other hand, was written prior to that, so

we use delegates.

To get the location information back, we need to implement a few delegate methods,

which we'll do inside the locationManager class.

The first delegate method we need to implement is locationManager

didFailWithError.

locationManager didFailWithError is called if we ask for

a location fix, but for some reason or another, cannot obtain one.

Now this method is marked as optional, but if your location request does fail.

And there's no implementation for this method, the app is going to crash.

So let's go ahead and provide an implementation.

Now, when we were working on the permissions portion, just a video or

two ago, we decided that we didn't want to handle the delegate

events inside this class, locationManager.

Instead, we handled the events in the same object that requested permission.

Or in this case,

we want to handle the events in the same object that requested the location.

So just like we did with the permission stuff, we'll use the delegate pattern

here as well to kinda defer handling these events and

communicate it on to another object.

We could simply stuff these additional events

into the LocationPermissionsDelegate protocol we defined earlier.

But that wouldn't make much sense.

Requesting permission to use location and

then using the location itself are two different bits of functionality.

We don't want the same delegate to communicate permission and

location events.

Because then our permissions controller would have to

implement the location-based methods, even though it will never use them.

Now in Objective-C, the pattern is to include optional protocol requirements.

So you generally tend to see these large protocols, like UITableViewDataSource or

UITableViewDelegate that have a bunch of requirements where you choose what

you want to implement.

Since we can't do that in Swift, we're going to create smaller,

focused delegate protocols.

And ultimately, that's better than the Objective-C approach.

You know exactly what this delegate protocol is doing.

So let's create a new protocol, and we'll name this LocationManagerDelegate.

Again, this is going to be class bound.

And the reason for that is we want to set it to a weak property, which we

can't do if this is not class bound because we could assign a struct there.

Okay, the protocol is going to communicate a success event and

provide the location obtained.

So here, we'll say func obtainedCoordinates,

coordinate: Coordinate.

Now core location defines a location as a CLLocation object.

But we're going to return a coordinate value to keep it consistent

with the rest of the API.

We'll also communicate a failure event, so func failedWithError.

And we'll pass along an error value from the type we defined earlier,

which is LocationError.

Okay, next we need to add a delegate stored properties.

So we'll say a weak var delegate, LocationManagerDelegate.

Make it optional and then we'll make a slight modification to the init method so

that we can pass the delegate in on initialization.

So delegate LocationManagerDelegate, and

then inside just like we did earlier, we'll say self.delegate = delegate.

So far so good.

Now again, this is going to raise an error in the permissions controller where

we're creating an instance of the type.

So really quick, let's jump to the Permissions Controller.

And over here, under the creation of our LocationManager object,

we'll specify the delegate parameter, and we'll pass in nil.

And then, this way, we can easily say that, hey,

this class is not going to act as a delegate for the location update events.

But just for the permission stuff.

Now, back in the CLLocationManagerDelegate method, which we added at the bottom.

So that's this first one, DidFailWithError.

We need to respond to this.

Now, you'll notice here that this is a generic error that we're getting

through and not a more specific error type.

If you check the core location framework reference however, you'll see that there

is indeed a more specific error type when working with location.

And that's the type CLError.

So what we're going to do here is, we'll try and

cast this generic error to CLError first.

So guard let error = error as?

CLError else, if this doesn't work, we'll call our delegate.

And just for the sake of ease, we'll say we have no idea what's going on here

because we really only expect a CLError back.

I mean, we could get some other type of error, but let's keep this course easy.

So here we'll say this is an unknown error.

And then, because this is guard statement, we need to return.

Now, in the event that we do have a CLError object, we'll use the error code

that's defined on the type to communicate more specific error through our delegate.

So we'll switch on the errors.code property.

And despite being named code, this property actually returns enum values

defined for each code, and we can match against those.

So here we'll say, if the error has a value, locationUnknown,

or a network error, then we'll tell the delegate that we

failed because we were unableToFindLocation.

If the reason for failing it is because we attempted to get the location despite

the user saying no, we'll communicate that as well.

So I'll say case.denied deligate.failwithError.disallowedbyUser.

Now, I don't expect to reach this because we won't be

calling request location if we failed with error, but just in case, who knows?

Now, for the rest of the error codes, we'll just use a default statement and

do nothing, purely because this is just a tutorial, folks.

Now, if you're using any of this code in a real app,

definitely make this more robust and cover all your error cases.

Let's take a break here.

In the next video, we'll handle the success case.