In the last video, we added a button to our view.

We can click that button but, unfortunately, it doesn't do anything.

To control what goes on in our view, we need to use a View Controller.

A view controller is an important component of our app

that links the app's data to its visual appearance.

Now, our app is somewhat minimal and has only two objects but most apps have a fair

amount of information to display in a limited amount of space.

The showing and hiding of this information is handled by a view controller.

And by having different view controllers control different sections of our

app's information, we can separate our code into more manageable chunks and

keep it somewhat neat and tidy.

If we navigate to our project directory in the navigator area, we can see that when

we created our project template, Xcode added some files for us automatically,

including a file called view controller that has two separate files here.

Objects in interface builder, that is in our main.storyboard file, can be

associated with a class so that we can talk to these objects through our code.

Now, if we go back to our main.storyboard file and in the document outline here,

which you can bring up using this icon, if you don't have it up.

Click on the View Controller Scene at the very top.

Now, go to the identity inspector, which is the third icon in the Utilities area.

Over here, where it says Custom Class, it lists our view controller file,

which is this same file that you see here.

You can even verify that by clicking on the arrow to go to that file, and

it's selected over here.

Now, this Custom class means that this object in

interface builder is controlled by this class in our code.

So we can write code in our view controller files that manipulate what we

see in our storyboard, but there are two files here.

So, which one do we use to add code?

Well, we actually use both.

Now, we've covered this in the Objective C basics content, but

let's revise what we've learned.

Our two view controller files have different extensions each.

One ends with a .h, and is known as a header file,

while the other ends with a .m, and is called an implementation file.

Some programming languages, of which objective C is one,

uses files called a header file that allows you to

separate certain elements of our code into reusable files.

Generally, everything public in our classes, that is,

anything we want to expose to other parts of our app, we place in the header file.

Everything else then goes into the implementation file.

The header file also makes it easier for others to understand how your class is

structured by quickly glancing at the public properties and methods.

Now, this distinction will become more clear as we write more code.

Head back to the main.storyboard file.

Now, to wire things up from our visual interface to our code, we use

a feature of Xcode called the Assistant Editor that displays files side by side.

Let's make some more room.

I'm going to get rid of the document outline and

you can also get rid of the project navigator and utility areas by clicking

the Show Hide navigator area and utilities areas button in the Tool bar.

In the toolbar, on the top right, this first set of icons, the second icon,

which is the set of inter locking circles here, is the Assistant Editor button.

Click it, now the assistant editor is somewhat smart and

tries to figure out which file you need to work on.

As you can see, it automatically brought up the view controller implementation file

for me, but if it did not do that for you, you can bring it up manually.

Up on top over here we have a fin bar called the jump bar.

Click right here where it says Automatic and go to Manual instead.

From there you can navigate through your project directory to

find the file that you need.

Look for viewcontroller.m.

The first thing we want to do is hook up our button so

that when we click on it we can make it do something.

To do that, click on the button.

And then with the Ctrl key on your keyboard pressed, click and

drag over to the implementation file, below the didReceiveMemoryWarning method,

until you have a pop up that says Insert Action and let go.

When naming our actions we want to give it a name that signifies what we're

doing when the action executes.

In our app, every time we tap on a button, we want to see a different fun fact.

So let's name our action, showFunFact.

You'll notice that I wrote out the action name with no spaces.

With the first letter lowercase and

the first letter of subsequent words as uppercase.

This is called Camel Casing, and it is the naming convention for

methods when writing Objective C code.

You can see that over here and in the viewDidLoad method as well.

Let's leave the event as it is and change the arguments to none.

And hit Connect.

Let's take a look at this function that we created for a second.

First we have the keyword IBAction in

parenthesis which indicates a return type of IB action.

What is an IB action?

The keyword IB action lets Interface Builder know that this

method is linked up to an object in Interface Builder by an action.

The IB over here stands for Interface Builder.

Now, when you click on this control, that is, the button,

you instruct the app to reference this method in our ViewController class and

execute the code inside this function.

This is a common design pattern when writing iOS apps, and

it's known as Target Action.

The action is the message that the control sends and

the receiving object is our target.

So in our case,

the ViewController class is the target, and the showFunFact is the action.

The action and its target is tied to an event.

In our case, that's the touch event.

And when the touch event occurs on this control, the sequence is initiated.

With the target action method, you can also send information about the sender and

the event that took place.

Okay, let's write our first bit of code.

Inside this showFunFact method, let's add NSLog, and

then in between parentheses, let's add a string that says, You pressed me.

Whoops, I need to close the string off, there you go.

Now NSLog is a function that simply writes out text to the console when executed.

In our case, we're passing in a string to the function saying, you pressed me.

Now, remember, we need to start our string with an at symbol, and

enclose the string with double quotes, which I almost forgot.

We then end the line of code with a semicolon.

Let's give this a try.

I'm gonna run the app, and when I press the button,

it should execute the action and run the code inside this method.

Look at that.

In your console,

the text, you pressed me appears, meaning that our code is getting executed.

Also, this seems super simple, but it's just the start.

We're going to build on top of this to do some really cool stuff.