Build a Simple iPhone App - Part 2
Continuing with this course! It's been a useful sidestep to remind myself how the layout of Xcode works. I think in the next few videos there will be some actual coding.
Designing with Interface Building
Interface builder does two main things - allows us to lay out elements on our view; interacting the visual elements - buttons etc.
It lets us connect the visual elements to code.
Within interface builder we work on a storyboard - showing screens of content and the connections between these.
I've now created a label and centralised it - using the blue lines. And then changed the text.
Introduction to Views
These handle user interaction. They are instances of the UIView Class. They are building blocks for the app. Text, images and other content...all used for views.
Having created a button, I've noticed that I didn't have to resize it - it may be that my Xcode version is updated and does this automatically.
Frameworks and UIKit
UIKit is one of the kits that can be used for coding. Foundation is another....there are a few more. We can pick and choose which apple code we work with by importing frameworks. So the point he makes is that there is code going on behind the scenes - code that is hidden from us that we do not need to worry about. The button is an instance of the UIButton class. So creating the button/label means that Xcode automatically creates an INSTANCE of that.
Introduction to View Controllers
A view controller links the app's data to its visual appearance. You have a limited amount of space. Different view controllers can control different sections of the app basically.
A view is always controlled by a view controller. We are using a subclass (in view controller). Every time we add a new scene to the storyboard, the identity inspector...a custom subclass can be used to manage that. We can use all of this to modify the appearance and behaviour of the views.
Not entirely sure about this...yet!
OK, so the bit above is where we would add code.
Creating IBOutlets
This is the line of code that connects the label to the view controller subclass. The @ part is Interface Builder and is a certain type. The weak part means it has a WEAK relationship. All IBoutlets do apparently. The ! at the end means there is a chance that the outlet and label won't be loaded before the view is. This is to do with OPTIONALS. So the value we are looking for may not exist yet. The value could be nil. I know about optionals but still not too sure about the ! at the end - I thought that was to do with forced unwrapping. Never mind for now!
Designing with Interface Building
Interface builder does two main things - allows us to lay out elements on our view; interacting the visual elements - buttons etc.
It lets us connect the visual elements to code.
Within interface builder we work on a storyboard - showing screens of content and the connections between these.
I've now created a label and centralised it - using the blue lines. And then changed the text.
Introduction to Views
These handle user interaction. They are instances of the UIView Class. They are building blocks for the app. Text, images and other content...all used for views.
Having created a button, I've noticed that I didn't have to resize it - it may be that my Xcode version is updated and does this automatically.
Frameworks and UIKit
UIKit is one of the kits that can be used for coding. Foundation is another....there are a few more. We can pick and choose which apple code we work with by importing frameworks. So the point he makes is that there is code going on behind the scenes - code that is hidden from us that we do not need to worry about. The button is an instance of the UIButton class. So creating the button/label means that Xcode automatically creates an INSTANCE of that.
Introduction to View Controllers
A view controller links the app's data to its visual appearance. You have a limited amount of space. Different view controllers can control different sections of the app basically.
A view is always controlled by a view controller. We are using a subclass (in view controller). Every time we add a new scene to the storyboard, the identity inspector...a custom subclass can be used to manage that. We can use all of this to modify the appearance and behaviour of the views.
Not entirely sure about this...yet!
import UIKit
class ViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view, typically from a nib.
}
Creating IBOutlets
@IBOutlet weak var funFactLabel: UILabel!
override func viewDidLoad() {
super.viewDidLoad()
This method is overridden. It means that there is come code that is written will always get run first. It ensures that the code we have written runs second to theirs.
Using IBAction to Execute Methods
@IBAction func showFact() {
This is what I've created by clicking on 'ctrl' and clicking and dragging it into the code. This was easier than scrolling through the options! This is called TARGET ACTION. We have a 'touch event'. The sender/event it took place - not for this one - not sure what this is at the moment. When you tap on the button, you can do this in multiple ways - tapping and sliding etc. Different events - ah!
@IBAction func showFact() {
print("You pressed me, dude!")
}
Pasan changed this so that the label changed its text, when the button was clicked, rather than printing to the console. Good stuff!
Asking for Help
Pasan basically shows in the Help menu where we can seek additional help e.g. for labels it has different sections with examples. So hovering over the mouse with the command button, then clicking on the question mark gives more information. We can check properties etc.
So that's the end of this part! Most of the information is logical but still very complex. I'm not going to pretend to understand it all but I've gleaned some key points - the best view to have in Xcode, how to create the label, button and have these attached to code, the fact that classes are linked to all of this, as are methods...it's a good start!
Comments
Post a Comment