Angela Yu Xcode 12 Course - Part 21 (lectures 193 to 197)
Yes, so I have found some sort of rhythm, hence another entry today! Just continue from where we got to....
*Ended up continuing from 4th April instead!
Start Time - 17:09
Swift Closures (advanced Swift!)
My understanding of these is that they are like functions without a specific name. So they can be shorter/easier etc. I tried conceptualising them before with Bob's course but it was at that point that I gave up on them!
Function - bread analogy. An input with a machine that cuts up the bread, then an output (sliced bread!).
Three variations on functions -
1.Those that do something without any input/parameters or have an output
2. Those that take an input with no specific output
3. Those that take an input and give an output
So closures are a step beyond that!
Simple function - with input, output and something that happens.
Then an adding one, which we're going to use into the original function...
Here's how it now looks -
Ahh so I can pass in a function instead of operation. Then the numbers will add.
This is clever code!
The nice thing here is how it links to my TimesTables app. With that, I could bring in multiply and division - rather than creating loads of new code.
So this is a breakdown of the function block -
And to get from this to a closure, we have removed the keyword func and sum, moved the opening curly bracket, then included in. That's it!
So we can shorten the original calculator function -
And I know where this is going - it ends with just a * button within something - the dollar signs will be next!
Yep there we go..
So this is a TRAILING closure (it's at the end). The downside - readability. Makes sense - having more expressive syntax I prefer.
Balance between simplicity and readability!
Map function - transforms items in a collection type e.g. in arrays.
Example with adding one.
The point here is why so much code? Closures are clearly going to be preferable!
Wow!
Map, reduce and filter.
A good point to 'pause'. I have to stop there so will continue tomorrow so I can get my head around closures a bit more!
Paused at 17:40 (31 minutes so far)
Continued on 4th April at 9:40
Yes I had to leave things there but have picked things back up, now in the UK! Going to do about another half hour for this entry...Not going to do anymore on closures as they are coming back into Angela's course. Will look up when I need to!
Event driven nature of apps
To illustrate different elements in an app. These work by sending and receiving messages. Specifically, the VC is the one who gets sent messages and sends them back. With a cloud database (like we do for this project) we get messages from there too!
Event Driven!
Memory intensive nature - life cycle of apps. During an app there are CONSTANT messages going back and forth.
Coding is anticipating the coding and knowing what messages to send when an event happens.
Completion Handlers
So the code above means a completion handler is needed. There needs to be a message to know that a TASK WAS COMPLETED!
In the myApp class -
And now back to the Firebase class -
The 'void' keyword is essential here as it refers to the fact that a function is used...
Here is how the new class looks for Firebase -
Getting more complex but I'm following. The closure block is simpler than creating another method. The closure only gets triggered when a certain event is completed. A process happening in the background - when it's completed, a callback happens. The app is not frozen or blocked up while that is happening. When complete, then a message comes up and next stage is triggered!
Navigation Controllers
First thing is about 'logging out'...
A recap with error testing -
The do/catch block is one I've seen before but have not used for a while. \
Next point is about navigation controller - this links to nested views as there are lots that link together...
She mentions views being stacked on one another....Got it! So if I have gone from screen 1 to 2 then to 3, then it means I've got 3 stacked on 2, 2 on 1.
So they are nested in the NC.
Example with 2 controllers - to embed!
Different types of segues - show is best for doing nested ones linked to NC.
Present modally - the VC that is used is not linked. It will pop up now and then but will disappear. Not part of the NC stack.
Pancake analogy.
You wouldn't grab out the third one, you would have to eat the top two!
For the last pancake - the ROOT VIEW CONTROLLER.
So back inside the do/catch - the navigationController line means that you can pop back to the first screen.
*Ended up continuing from 4th April instead!
Start Time - 17:09
Swift Closures (advanced Swift!)
My understanding of these is that they are like functions without a specific name. So they can be shorter/easier etc. I tried conceptualising them before with Bob's course but it was at that point that I gave up on them!
Function - bread analogy. An input with a machine that cuts up the bread, then an output (sliced bread!).
Three variations on functions -
1.Those that do something without any input/parameters or have an output
2. Those that take an input with no specific output
3. Those that take an input and give an output
So closures are a step beyond that!
Simple function - with input, output and something that happens.
Then an adding one, which we're going to use into the original function...
Here's how it now looks -
Ahh so I can pass in a function instead of operation. Then the numbers will add.
This is clever code!
The nice thing here is how it links to my TimesTables app. With that, I could bring in multiply and division - rather than creating loads of new code.
So this is a breakdown of the function block -
And to get from this to a closure, we have removed the keyword func and sum, moved the opening curly bracket, then included in. That's it!
So we can shorten the original calculator function -
And I know where this is going - it ends with just a * button within something - the dollar signs will be next!
Yep there we go..
So this is a TRAILING closure (it's at the end). The downside - readability. Makes sense - having more expressive syntax I prefer.
Balance between simplicity and readability!
Map function - transforms items in a collection type e.g. in arrays.
Example with adding one.
The point here is why so much code? Closures are clearly going to be preferable!
Wow!
Map, reduce and filter.
A good point to 'pause'. I have to stop there so will continue tomorrow so I can get my head around closures a bit more!
Paused at 17:40 (31 minutes so far)
Continued on 4th April at 9:40
Yes I had to leave things there but have picked things back up, now in the UK! Going to do about another half hour for this entry...Not going to do anymore on closures as they are coming back into Angela's course. Will look up when I need to!
Event driven nature of apps
To illustrate different elements in an app. These work by sending and receiving messages. Specifically, the VC is the one who gets sent messages and sends them back. With a cloud database (like we do for this project) we get messages from there too!
Event Driven!
Memory intensive nature - life cycle of apps. During an app there are CONSTANT messages going back and forth.
Coding is anticipating the coding and knowing what messages to send when an event happens.
Completion Handlers
So the code above means a completion handler is needed. There needs to be a message to know that a TASK WAS COMPLETED!
In the myApp class -
And now back to the Firebase class -
The 'void' keyword is essential here as it refers to the fact that a function is used...
Here is how the new class looks for Firebase -
Getting more complex but I'm following. The closure block is simpler than creating another method. The closure only gets triggered when a certain event is completed. A process happening in the background - when it's completed, a callback happens. The app is not frozen or blocked up while that is happening. When complete, then a message comes up and next stage is triggered!
Navigation Controllers
First thing is about 'logging out'...
A recap with error testing -
@IBAction func logOutPressed(_ sender: AnyObject) {
//TODO: Log out the user and send them back to WelcomeViewController
do {
try Auth.auth().signOut()
}
catch {
print("Error with logging out")
}
}
Next point is about navigation controller - this links to nested views as there are lots that link together...
She mentions views being stacked on one another....Got it! So if I have gone from screen 1 to 2 then to 3, then it means I've got 3 stacked on 2, 2 on 1.
So they are nested in the NC.
Example with 2 controllers - to embed!
Different types of segues - show is best for doing nested ones linked to NC.
Present modally - the VC that is used is not linked. It will pop up now and then but will disappear. Not part of the NC stack.
Pancake analogy.
You wouldn't grab out the third one, you would have to eat the top two!
For the last pancake - the ROOT VIEW CONTROLLER.
So back inside the do/catch - the navigationController line means that you can pop back to the first screen.
do {
try Auth.auth().signOut()
navigationController?.popToRootViewController(animated: true)
}
catch {
print("Error with logging out")
}
}
Finish Time - 10:21 (41 more minutes; 1 hour 11 total)
OK so some complex stuff here but I'm just about keeping up. I love Angela's explanation - MUCH better than anyone else out there. Closures are making more sense as they are easier than all of the methods being used. That is something I will do another entry for I think after all, as it seems important to see with more examples. This extra entry could use some of Bob's stuff (where I gave up with him before!) and anything else I can find just to get some more context. Another entry for sure today!
Comments
Post a Comment