So, now that we've learned about the different ways that we can use name parameters in Swift functions, 1
let's go ahead and modify our delegate method didUpdateWeather to be more in line with the way that 2
Apple formats their delegate methods. 3
So you can see that the first thing that by convention, we always have in a delegate method is the identity 4
of the object that caused this delegate method. 5
So in their case, it's the text field which triggers the textFieldDidEndEditing. 6
And in our case, it would actually be the weatherManager that does this. 7
So this is, obviously, going to be of data type WeatherManager and we can now separate out our two 8
parameters. 9
Now, notice how they actually have an emitted parameter name here, 10
so we can do the same. And we can add an underscore here and remember to separate the underscore from 11
the internal parameter name. And we, of course, have to update this in the protocol that defines how our 12
delegate methods are meant to look. 13
So let's update that here as well. 14
So, now when we actually call this didUpdateWeather, you can see that it's telling us that we're missing 15
the parameter for the first input which is the WeatherManager. 16
So the weather manager is going to be "self," this current object, which is the one that triggered 17
the didUpdateWeather and it's also the one that knows all about the current weather conditions and passes over 18
this weather object. 19
So by using these omitted parameter names, we can actually clean up a lot of our method names and make 20
them more succinct and easier to understand. 21
For example, when we say parseJSON and we're passing in a piece of weatherData, now that's quite useful 22
within the function, especially when we want to actually use it to decode, 23
but from outside the function, this is a little bit extraneous self.parseJSON weatherData: 24
safeData. 25
I think it's entirely possible to omit that external argument and simply just have parseJSON with this 26
particular data. And in other places, you'll see that Swift likes to use words from English that make 27
the method names a lot more readable. For example, here where we've got performRequest (urlString: 28
urlString) that feels a little bit extra as well. 29
Instead, it would read a lot nicer and be more clear in English at least if we simply said performRequest 30
with your urlString. 31
So that method named now reads really nicely and when we call performRequest, 32
we can say performRequest with: and then we pass in the urlString that we're going to perform the 33
request with. 34
These are all ways of making our code more readable, more easily understood by other programmers and 35
also ourselves in the future. 36
Now, with this in mind, I'm going to go ahead and add one other delegate method. And the delegate method 37
is going to help us be able to pass errors out of our weather manager. 38
I'm going to call the method didFailWithError and the input is going to be called error, and it's 39
going to be of type Error. 40
So, now we can trigger this delegate method whenever our code might fail in the WeatherManager, so that 41
we can notify the delegate, "Hey, there's an issue here," so that we can pass this error out of our 42
WeatherManager. And a good place to do that is, for example, here, 43
if during our networking session, we somehow, say, lost connection to the internet, went underground, some 44
sort of issue there, then we'd probably end up with an error. 45
So instead of printing it here, we can pass it back to the delegate by saying delegate.didFailWithError, 46
and pass in the error object that's unwrapped. And, of course, because we're inside a closure, 47
we have to add the word "self" in front to complete that line of code. 48
Now, down here inside where we parse our JSON, we can also possibly fail when our data can actually 49
be decoded successfully. 50
Say, maybe we had an issue with the way that we constructed our weatherData or maybe, in fact, we got 51
a JSON that doesn't even match this format that we've created. 52
So in that case, we're going to catch the error and we can, again, call our delegate.didFailWithError, 53
and we can pass in the error that we've caught. So, now back over in the WeatherViewController, 54
we, of course, must implement this method didFailWithError and we can handle any errors that occur 55
while using the WeatherManager. 56
So the simplest way is to, of course, simply just print the error. But depending on what kind of errors 57
you might get, you might want to relay some of that back to the user. 58
Now, in my case, because the errors that were getting are "couldn't parse JSON," or networking errors, I don't 59
think the user is going to understand what that's all about. 60
So in fact, all that we're going to do is we're just going to print the error to the console. And during 61
the testing of our app, say, we could switch off the Wi-Fi, switch off the 3G Internet, and see if we get 62
any errors that gets printed. In the next lesson, 63
we're going to update the weather that's being shown on the screen.