Angela Yu Xcode 12 Course - Part 11 (lectures 132 to 143)
So a poor effort recently! Life gets in the way...Shouldn't feel too bad though as I did a marathon session six days ago (2 hours worth) so another hour today should still help me to meet my three hours per week target. Just writing that makes me feel so proud - at one point I made a vow to try to get an hour a week. The fact that three hours doesn't seem like that much is something to be very pleased about. Anyway, the next part of Angela's course is all Intermediate Swift. Stuff that I will pay attention to but it should be familiar. It dovetails in with what I've been doing for the past few months, well it should at least. I doubt it'll be as technical as Bob's course! Anyway time to go for it!
Start Time - 17:34
Classes
Right so command line tool file created. I don't actually remember this AT ALL! So glad I am going over it!
This sounds exciting - creating a new class and seeing the purpose for it. Cool.
It doesn't like calling a variable 'class' - using these keywords is a NO-NO! Backticks around the word fixes this but this is definitely best to avoid.
So properties are needed in classes etc. etc.
class Car {
var colour = "Black"
var numOfSeats = 5
}
Moving on to Enums...
The point here is that we don't have custom types in built for everything - for this car class, we want car types. And we want these to have set selections to choose from.
Right I have done this before Angela's idea....
enum CarType {
case saloon, hatchback, sports
}
class Car {
var colour = "Black"
var numOfSeats = 5
var type = CarType.saloon
}
Very, very similar!
The . has been used before - with the Destini app.
For the .normal state - there were many other options to choose! Those enumerations were created by Apple. Not visible but in-built.
So I totally get now the point of using enums within classes and having all of these in a separate file to the main view controller file. Cool!
let myCar = Car()
print(myCar.colour)
print(myCar.numOfSeats)
print(myCar.type)
And that's using the class as an object - as myCar.
Initialisation
The point here is creating 'custom' objects. So you're not just using the same colour as what is in the class block of Car.
Let's have a go first - well one way of doing it is changing the value after the object is made. Not a good idea.
class Car {
var colour: String
var numOfSeats = 5
var type = CarType.saloon
init(colour: String) {
self.colour = colour
}
}
So that's one way of doing it. I could make it another type of initialiser...
Ok Angela's solution is typically better as it gives the OPTION to have a change in colour -
class Car {
var colour: String
var numOfSeats = 5
var type = CarType.saloon
init(chosenColour: String) {
colour = chosenColour
}
}
So that means the creation of the object without any parameters means a bog standard, black car.
OH no it doesn't! In fact, Angela's solution is no better than mine, as the myCar() object still needs a parameter! So my original way was more succinct in a way.
So yes a convenience initialiser is what I instinctively started doing!
Confusing though - the auto complete is not giving both options! But I'm not the only one - must be an update on Swift or something...
Methods
Function in the class - no problem. It is called a METHOD as it is within the confines of a class.
Inheritance
This is all clear in my head so skimming through...
I'm watching this play out as the point will be that it is a faff to create a brand new class every time - inheriting is much better!
A really neat way of looking at inheritance!!
Overriding - for functions:
class SelfDrivingCar: Car {
override func drive() {
print("Super charged start!")
}
}
Right so I get what the super.drive() bit is used for - above the print line - so that the original method is carried out, plus anything afterwards!
Optionals
Right - my nemesis! Something I have always battled with! To be fair, I really gained a lot from Bob's explanations on these. The whole point of these is that something may or may not contain a value and unwrapping has to happen.
Force unwrap - dangerous! The programmer has to KNOW FOR SURE if they know that the value is NOT nil (nothing). We see ! with labels and other objects etc.
This is the error when unwrapping happened when there was no value!
class SelfDrivingCar: Car {
var destination: String?
override func drive() {
super.drive()
if destination != nil {
print("Destination is \(destination)")
} else {
print("Destination needs a value!")
}
}
}
OPTIONAL BINDING -
if let userDestination = destination {
print("Destination is \(userDestination)")
} else {
print("Destination needs a value!")
}
*I added in the else line there because I always think it's useful to print that to the console.
No force unwrapping - much, much safer!
OK last bit for today - Optionals explained!
Right I get the analogy - we don't know whether a value or nothing is contained. Until we open it, we do not know ...
A key point to remember is that a string is a separate type to an optional string. All that was actually OK. Phew!
Finish Time - 18:51 (1 hour 17 minutes total)
So a great session. Really useful to go through classes, including inheritance, inits, properties, as well as enums, methods, optionals...lots covered! Two big sessions this week but the gap in between is not good. Must have at least another session or two during the week to keep the momentum going. Enjoyed going over these more complex concepts and there were no nasty surprises. Next time it's the start of the biggest project - the weather app! I failed at this before, or the course was outdated. Either way, I really am looking forward to the JSON elements with APIs. That will take a good couple of weeks so I must be patient and thorough with it. At that point I will have surpassed by effort with the Xcode 11 Angela course. As I've said, I WILL see this one through to the end!
Comments
Post a Comment