Angela Yu Xcode 12 Course - Part 15 (lectures 169 to 171)
OK so last week was a bit of a bust! I started well with some progress at the start of the week but nothing for 8 days...not good! Anyway, I'm coding - unusually from Ras Al Khaimah - one of the other Emirates in UAE. Away with Cath for a several days and while she's reading, a good half hour of cracking on with Clima seems perfect! Before I start this properly, a good opportunity to assess things...
It's been six weeks or so since I went back to Angela's course, well technically started her 'new' one, and I don't regret it one bit. I'm technically 31% through it all, which is a good number of hours. However, that isn't totally realistic as I did 'skim' through a number of the lessons. The main point I want to make here is that I DON'T feel the need to switch to another course or supplement my understanding through other resources or websites. Having been a committed Swift learner for 8 months now, I've realised and accepted that Angela's course is the best - better than anything else out there. Also, I should be proud of the progress I have made in that time, considering that I've been doing it a fraction of the time committed to my actual job as a teacher - around three hours a week! And three hours a week needs to increase a bit. From now on, I am going to aim for 4 hours a week. That means 4 good sessions a week to increase my rate of progress. That starts from this week and essentially now! So, continuing - or pretty much finishing - with Clima...
Start Time - 16:03
Delegates and Protocols
Good, this is what I want to find out more about! This is an 'advanced' topic and Angela has dedicated 16 and a half minutes to this lecture.
We have been using these already within the Clima app. This is going to be a consolidation - understanding how it all links together.
STAGE 1 -
This was the first protocol we used - a required method was within it -
A good point here is that there is no body within the method (userEnteredANewCityName).
Thinking of it like a job contract - e.g. you must be able to use photoshop for a designer contract.
STAGE 2 -
We added the protocol (ChangeCityDelegate) to our WeatherViewController Class:
Now my understanding is that the class now needs to have the same method that is inside that protocol.
We have CONFORMED to that protocol. WeatherViewController INHERITS from the UIViewController (does the same behaviour as that) but it will also take up the contract of the ChangeCityDelegate. The error comes up as we have not implemented the required method!
STAGE 3 -
So this method was used
OK, making more sense. The method above needs to be put into the body of the WeatherViewController class as it conforms to that protocol. It has taken up the contract and now needs to use the same method, and also specify what it will actually do!
STAGE 4 -
Create a delegate PROPERTY.
STAGE 5 -
Right so we need to want the WeatherViewController to receive the messages and set that as the delegate. The above override func is needed for that. Confusing stuff.
Going from the sender to destination, via the segue, a new copy is created. WeatherViewController is set as the delegate to receive that message.
STAGE 6 -
Calling the method. This is involving the segue of going from ChangeCity to WeatherView
The constant of cityName is needed to be created here. If the delegate is set - which is what we have - then the delegate method is called. Which is userEnteredANewCityName.
So it is very easy to send data from A to B using segues. But to send backwards e.g. from B to A, a DELEGATE is necessary. And PROTOCOL is the keyword used to create this.
Sender (ChangeCityController)
Receiver (WeatherViewController)
Protocol (EnteredANewCityName)
These are all different things all linked together.
To summarise
1. Create a protocol with a required METHOD
2. If receiver class decides to adopt that protocol, it must include the required METHOD(s). This is called the DELEGATE method.
3. In the Sender class, a new property (called delegate for our one) is created as an optional - could be nil or could contain something. We set the delegate in the receiver class - a reference to the sender class and setting it to self (the receiver class). So the receiver class is volunteering to be the messenger/responsible for that.
4. In the sender class, the delegate property is equal to the receiver - no longer nil. The delegate method checks to see if it is nil or not. If nil - nothing happens. If not nil - delegate method is triggered and data is passed from the sender class to the receiver class.
Making a bit more sense!
Big advantage of using this - reuses data components from Apple, or ones that we have created ourselves.
Gets more complicated with more aspects to it e.g. if we had a third class..! In that case, it would need to know the properties and methods of two other classes.
Real life example - Tetris app. Different types of games. Change music volume - go to a new view controller - gets rid of that view controller and back to the game one.
Right, good things are happening - this advanced level of Swift is making me think of how I could have F1Quiz which would have multiple view controllers, with different levels of difficulty. It would be worth exploring at least!
Number 1 rule - programmers are lazy! Look for ways to avoid duplicate code!
So going back to F1Quiz, it would definitely be worth trying to create multiple view controllers, using Angela's info for how to use the segues with all of the code, including the protocols and delegates. Until I start putting that into practice, it won't really sink in or make proper sense. That is true!
*Pause for 10 mins
OK...my app does not actually work properly! But I'm honestly fine with that - I followed along and if I missed something, it's not the end of the world. I don't need THIS app per se. It's great to see the concepts in action!
Finish Time - 16:48 (total time - 35 minutes)
Well, that was really interesting and useful half hour or so. I think during the week, it's going to be hard to get in full hour sessions, but at the weekend, that is very doable! Loads of good stuff about protocols and delegation which I WILL try out with F1Quiz. Next time it is CommandLine, which I have no idea what that's about. Then after that it will be a Bitcoin tracker app challenge - using the skills learned here. SO that will be interesting! Even if I don't get it all, a great opportunity to put that into practice. THEN after that, I'm going to take a slight detour from Angela to try out segues and delegation with the F1Quiz app. In no way is that going to be be stopping Angela's course - it is just to try out the ideas while they are fresh. If it doesn't work, no problem. If it does, then that's great - I will continue with Angela's course either way!
It's been six weeks or so since I went back to Angela's course, well technically started her 'new' one, and I don't regret it one bit. I'm technically 31% through it all, which is a good number of hours. However, that isn't totally realistic as I did 'skim' through a number of the lessons. The main point I want to make here is that I DON'T feel the need to switch to another course or supplement my understanding through other resources or websites. Having been a committed Swift learner for 8 months now, I've realised and accepted that Angela's course is the best - better than anything else out there. Also, I should be proud of the progress I have made in that time, considering that I've been doing it a fraction of the time committed to my actual job as a teacher - around three hours a week! And three hours a week needs to increase a bit. From now on, I am going to aim for 4 hours a week. That means 4 good sessions a week to increase my rate of progress. That starts from this week and essentially now! So, continuing - or pretty much finishing - with Clima...
Start Time - 16:03
Delegates and Protocols
Good, this is what I want to find out more about! This is an 'advanced' topic and Angela has dedicated 16 and a half minutes to this lecture.
We have been using these already within the Clima app. This is going to be a consolidation - understanding how it all links together.
STAGE 1 -
This was the first protocol we used - a required method was within it -
A good point here is that there is no body within the method (userEnteredANewCityName).
Thinking of it like a job contract - e.g. you must be able to use photoshop for a designer contract.
STAGE 2 -
We added the protocol (ChangeCityDelegate) to our WeatherViewController Class:
Now my understanding is that the class now needs to have the same method that is inside that protocol.
We have CONFORMED to that protocol. WeatherViewController INHERITS from the UIViewController (does the same behaviour as that) but it will also take up the contract of the ChangeCityDelegate. The error comes up as we have not implemented the required method!
STAGE 3 -
So this method was used
OK, making more sense. The method above needs to be put into the body of the WeatherViewController class as it conforms to that protocol. It has taken up the contract and now needs to use the same method, and also specify what it will actually do!
STAGE 4 -
Create a delegate PROPERTY.
STAGE 5 -
Right so we need to want the WeatherViewController to receive the messages and set that as the delegate. The above override func is needed for that. Confusing stuff.
Going from the sender to destination, via the segue, a new copy is created. WeatherViewController is set as the delegate to receive that message.
STAGE 6 -
Calling the method. This is involving the segue of going from ChangeCity to WeatherView
The constant of cityName is needed to be created here. If the delegate is set - which is what we have - then the delegate method is called. Which is userEnteredANewCityName.
So it is very easy to send data from A to B using segues. But to send backwards e.g. from B to A, a DELEGATE is necessary. And PROTOCOL is the keyword used to create this.
Sender (ChangeCityController)
Receiver (WeatherViewController)
Protocol (EnteredANewCityName)
These are all different things all linked together.
To summarise
1. Create a protocol with a required METHOD
2. If receiver class decides to adopt that protocol, it must include the required METHOD(s). This is called the DELEGATE method.
3. In the Sender class, a new property (called delegate for our one) is created as an optional - could be nil or could contain something. We set the delegate in the receiver class - a reference to the sender class and setting it to self (the receiver class). So the receiver class is volunteering to be the messenger/responsible for that.
4. In the sender class, the delegate property is equal to the receiver - no longer nil. The delegate method checks to see if it is nil or not. If nil - nothing happens. If not nil - delegate method is triggered and data is passed from the sender class to the receiver class.
Making a bit more sense!
Big advantage of using this - reuses data components from Apple, or ones that we have created ourselves.
Gets more complicated with more aspects to it e.g. if we had a third class..! In that case, it would need to know the properties and methods of two other classes.
Real life example - Tetris app. Different types of games. Change music volume - go to a new view controller - gets rid of that view controller and back to the game one.
Right, good things are happening - this advanced level of Swift is making me think of how I could have F1Quiz which would have multiple view controllers, with different levels of difficulty. It would be worth exploring at least!
Number 1 rule - programmers are lazy! Look for ways to avoid duplicate code!
So going back to F1Quiz, it would definitely be worth trying to create multiple view controllers, using Angela's info for how to use the segues with all of the code, including the protocols and delegates. Until I start putting that into practice, it won't really sink in or make proper sense. That is true!
*Pause for 10 mins
OK...my app does not actually work properly! But I'm honestly fine with that - I followed along and if I missed something, it's not the end of the world. I don't need THIS app per se. It's great to see the concepts in action!
Finish Time - 16:48 (total time - 35 minutes)
Well, that was really interesting and useful half hour or so. I think during the week, it's going to be hard to get in full hour sessions, but at the weekend, that is very doable! Loads of good stuff about protocols and delegation which I WILL try out with F1Quiz. Next time it is CommandLine, which I have no idea what that's about. Then after that it will be a Bitcoin tracker app challenge - using the skills learned here. SO that will be interesting! Even if I don't get it all, a great opportunity to put that into practice. THEN after that, I'm going to take a slight detour from Angela to try out segues and delegation with the F1Quiz app. In no way is that going to be be stopping Angela's course - it is just to try out the ideas while they are fresh. If it doesn't work, no problem. If it does, then that's great - I will continue with Angela's course either way!
Comments
Post a Comment