In the previous video, we wrote code to indicate that our LocationManager class is

going to act as the delegate to the CLLocationManager instance we defined.

So that we can respond to location events.

We can navigate to the protocol reference in the docs, so Help > Documentation and

API Reference, and the protocol here, CLLocationManagerDelegate.

And in here, you'll see that we can implement methods to respond to

location events, to pause those updates, and so on.

We can do lots of different things. Now to receive the updates our class

LocationManager needs to conform to the delegate protocol,

which we went ahead and did.

So if you didn't, it is the CLLocationManagerDelegate protocol.

We don't get any errors here,

and that's because all the methods in the CLLocationManagerDelegate protocol

are marked as optional, being an Objective-C protocol and all.

Okay, so once you make the request, the LocationAuthorization request,

the LocationManager kicks into gear.

So over here is where we make the request.

It kicks into gear and

then fires off the results to its delegate when it gets it back.

Before we tackle delegate methods,

let's see what this authorization process looks like.

So head over to the PermissionsController, and right after the oauth stored property,

let's add a new stored property, and create an instance of the LocationManager.

So let locationManager = LocationManager.

Now, inside the requestLocationPermissions method, which you can get to easily by

going to the jump bar, and then looking for that one right there.

So inside this method, let's add the following code.

So we'll say do, since remember, this is a throwing method,

we're going to ask the locationManager to requestLocationAuthorization,

which calls the underlying manager's method.

And then we know that this is a throwing method so we need to catch on the relevant

errors, so we'll say catch LocationError.disallowedByUser.

And then over here, you can do something like Show an alert to users.

The compilers are gonna complain because we're not catching all errors, so

let's create a generic catch block.

And I'm just going to print Location Authorization Error:

error.localizedDescription.

Let's give this is a try.

So we'll hit play.

We should automatically get the modal pop-up because we don't have permissions.

And let's go ahead and click Request Location Permissions.

When you do this you should see the permissions alert pop up.

The alert title should say that location is only monitored while you use the app,

since that's the key that we used.

And you should also see the descriptive string you provided as the alert body.

Now before I click Allow here to grant access, remember that we won't be notified

of the result of this permission request immediately.

This is because I don't need to respond immediately.

I could put my phone down over here, and

walk away without interacting with the alert.

Instead, when we do eventually respond, we get notified through a callback.

So far, most of our callbacks that we've used throughout

our courses have been closures.

But CLLocationManager uses the delegate pattern.

You'll remember that we assigned self, that is, this locationManager instance or

the type is going to act as the delegate to the underlying CLLocationManager.

So to react to whatever action the user takes back in LocationManager,

we need to implement a single delegate method.

Now let's stop the app here before we grant access and

we'll implement that method.

The method is locationManager

didChangeAuthorization status, there we go.

In the body of this method, we'll check if it's the success case or

not, if it's the case we care about.

So we'll say if status == .authorizedWhenInUse.

Now, we're not going to handle it here.

We're not going to let the location manager handle it.

Instead, let's create our own delegate protocol and a delegate.

This way, we can let the relevant object handle it,

which in our case is the permissions controller.

So we can let the permissions controller subscribe to these events and

react appropriately.

So up at the top here, after the error,

we'll say protocol LocationPermissionsDelegate:.

We'll make this a class bound protocol.

And we will give it two methods here, two requirements.

And we're going to indicate that either the authorization, so

authorizationSucceeded, or that the authorization, Failed,

and to make it a bit clearer, we'll provide the status that it failed with.

So authorizationFailedWithStatus(_ status: CLAuthorizationStatus).

Okay, so now that we have a protocol,

the next step is to add a delegate stored property.

So in the LocationManager class, we'll say weak var permissionsDelegate:

LocationPermissionsDelegate?, this is an optional property.

And if you don't understand why this is optional or why this is weak,

you should check out the Delegates in iOS course.

Now that we have a delegate, back in our if statement, here in the delegate method,

we can inform the permissions delegate that the authorization succeeded,

because this is the status we want.

So we'll say

permissionsDelegate.authorizationSuccee- ded.

If the status is anything but authorized when in use,

we'll use an else clause to tell the permissions delegate that we failed.

So authorizationFailed and we'll pass the status through.

All we need to do now is assign an object to act as the permissions delegate.

So instead of leaving this as an implicit step and potentially forgetting it,

let's modify the init method of this class to accept a permissions delegate.

So let's get rid of the override keyword,

cuz now we're not overriding any initializer.

And we'll say init permissionsDelegate of type LocationPermissionsDelegate?,

we'll make this optional as well.

And then, before we call super.init,

we'll say self.permissionsDelegate = permissionsDelegate.

Modifying this init method, of course, raises an error in the permissions

controller, so we need to go ahead and fix it.

Which, by the way if you didn't realize, I don't know if you can see it in this

video, but in the scroll bar over here in Xcode, in the corner, when you have

an error, there's a thin, thin red line to show you where that error occurred,

so you can just zoom right over there.

Here we go.

So we have an error here, and we need to change this now to use a new initializer.

We want the permissions controller itself to act as a permissions delegate,

to the locationManager instance.

Which means that when we're initializing the property here,

we need to pass in self.

We can't do that when we do it as a simple stored property, so

instead, let's make this a lazy stored property.

We'll say lazy var locationManager of type LocationManager and

we'll assign a self or an immediately executing closure rather.

And then you will say return,

LocationManager(permissionsDelegate: self).

Obviously, you'll get an error.

Self is currently not conforming to the right delegate protocol.

So we'll go up to the top, class PermissionsController, and

conform to the LocationPermissionsDelegate.

Once you do that, you need to go down to the bottom.

You'll get another error because we're now not conforming to it, so

let's go to the very last method.

And below that, we'll add a comment marker,

Location Permissions Delegate.

And in here, we'll say authorizationSucceeded, and

authorizationFailedWithStatus.

If the user grants permissions, so if this method is called, we need

to update the location permissions button, much like we did for the oauth button.

So we'll say locationPersmissionButton.setTitle.

Location Permissions Granted, for status, or the state is disabled.

And then we'll go ahead and disable the button, oops, right here.

We'll say locationPermissionButton.isEnabled

= false.

Okay, and let's just comment this out for now.

Now, we have an error here for CLAuthorizationStatus, and

that's because we're not importing the CoreLocation framework.

So let's do that really quick up at the top.

Okay, let's run the app one more time.

And let's go ahead and request location access.

Since the alert is shown only if the status is not determined,

if I click Don't Allow, then we're going to hit a failure point.

Now I'm gonna leave that as an exercise for you to implement.

Here's a typical flow.

So if the user clicks deny, you're going to, or Don't Allow, you're

going to present an alert stating that the app cannot be used without location data.

And inform them how to change the permissions in their settings page.

iOS has a method that allows you to link directly

against the app's settings page via a URL.

But again, I want you to figure that out.

Read the docs, check things out, and try to solve the problem yourself.

If you can't, jump to the Treehouse community and ask around.

Let's go ahead and Allow location monitoring.

Nothing's going to happen after that, of course, and

that's because we need to implement the necessary delegate methods to proceed.

Now, I went ahead and restarted my simulator in between a couple videos, so

I don't have the oauth token anymore.

So I'm just gonna click Request again to get it, and there we go.

Now we have both sets of permissions, and I'll Dismiss.