16. IBActions

We have been doing quite a bit of work in Interface Builder recently, and we are going to keep at it in this post as well. IB is an amazing tool that can make app creation a lot easier. In this post we are going to talk about IBActions, and how they are similar to IBOutlets, but very different at the same time.

Let's see if you remember what our last post was all about. We talked about IBOutlets, can you remember what they are? What they do? How to make them? How to hook them up?

We use IBOutlets to hook up graphical objects in IB to corresponding object declarations in code. So if you have an IBOutlet object in code, and you change some of it's properties, those changes will reflect in the object in your view. Pretty straight forward.

The concept of IBActions is very similar. Instead of hooking a graphical object up to an object reference in code, you are hooking up a graphical object to a method, or an action. Let's think about that for a second. Why would we want to hook up a Button to a method? Well, do we remember what methods do? Methods allow us to run specific pieces of code exactly when we mean/need to. So if we have a button on our view, and somebody touches the button, chances are we want something to happen. This is easily accomplished with the IBAction. We can hook up the IBAction to a graphical object in code (usually a button), and so every time that button is pressed, or that action is fired, the associated IBAction, or method is executed. Let's take a look at what this looks like in the header file:

As you can see the IBOutlet from the last post is still in there. IBActions are declared in the header file just beneath the @interface. You may notice that the declaration looks very similar to that of a method. This is because they are in fact very similar.

So the above code declares an IBAction for us, so what is left? We need to do something with it, right? Based on what we've talked about already, where would we do that? The .m file! Go ahead and put this in your implementation file:

As you may have noticed, the top line of our method, or our method signature, is the exact same as in the .h file. So something that is easy to do after you declare the IBAction in the header file is to copy that line and paste it right into the .m file. Then you put the brackets in and you're ready to fill out the implementation of the action.

So based on what we have learned about NSLog, what would you expect the result of this IBAction to be? We are printing a message to the console. How do you get to the console? Try Cmd-Shift-R.

So we have our IBAction declared in our .h file, and implemented in our .m file, are we done? What is missing? Well, we have an action that is ready to be used, but we haven't hooked it up to anything! The fact that we are using an IBAction, as opposed to just a regular method, means that the actual hooking up for the action will take place in Interface Builder.

In order to return to IB, go ahead and click on the ExampleViewController.xib (or whatever your file is called) file in Xcode. Similar to how we did it in the previous post, go ahead and right-click on the File's Owner button on the left, and notice what has changed. If you're building on the previous post's content, you should still see your IBOutlet hooked up, but at the bottom of the black popup we see a new area called Received Actions has shown up. Do you recognize anything in there? It's our IBAction!

By setting up the IBAction in the .h/.m file, we have the ability to hook up our action in IB. Similar to how we did it with the IBOutlet, go ahead and grab the open circle to the right and click-drag it to the button that we have on our view. You'll know you did it right when a black popup prompts you to select which type of touch event you want to respond to.

I haven't ever really found much use for all of these different options, but you are basically looking at all of the different ways that a touch can be recognized in proximity to a button. The one that we want to use (and that you'll want 99% of the time) is the third from the bottom: Touch Up Inside. This means we want to IBAction to fire if we touch inside the bounds of the button. Pretty straight forward.

With that, we're done! Go ahead and fire up your app and see what we have done. If you want to observe the effects of our IBAction, open up the console and you can see that for every time you press the button, a message is printed in the console.

This might seem like a simple concept, or result, but the concept behind it will be used very often. We just went through and hooked up a graphical object to our code, and are able to respond to events that happen.

Because just printing to the console is kind of boring, I want to spice it up. For our next post, we are going to review many of the different operations we can do within the scope of a method/action implementation.

15. IBOutlets

When you hear the word outlet, what do you think of? There are a few different ways that the word can be used, but the one I'd like to talk about is an electrical outlet. Our homes are filled with them, and we use them all the time. The idea is quite simple; a big company does a lot of work to transport the electricity to your home and outlets, and all you have to do is plug your appliance into the outlet and you can begin using it.

Interface Builder operates in a similar manner. IB uses outlets to plug in graphical objects to their corresponding place in code. An IB outlet, or IBOutlet as they are formerly called, function a little bit differently because it isn't exactly a one-size-fits-all solution like our outlets are at home. In code, you setup an outlet for lets say a Button, and then in IB, you make the button, and then you can plug it into the IBOutlet that you made in code. Once your button is plugged into the proper outlet, you can begin to handle the events that happen on the button, like a click for example. It's that easy!

Let's dig into some code and take a look at how we need to setup an IBOutlet for our Label, Button, etc, to plug into. IBOutlets need to be declared in the .h file, so that is where we are going to add the following code:

Your .h file may have more code in it than the picture above. You can leave it there, or make it look just like what I have. Can you see what we are doing with the one line of code that we are declaring here? It should look somewhat familiar. We are in the header file and we are declaring a class variable. This isn't just any type of variable though, it is a class variable that is also an IBOutlet. Adding in that IBOutlet keyword is all we need to do to create the outlet in code that will allow us to plug in the Label in IB. Pretty easy!

Now that we have created this IBOutlet in code, lets go hook it up in IB. If you followed the last step of the last post, your view should have a Label and a Button on it all ready to go. The process of hooking the Label in to the IBOutlet we just created is really easy. Go ahead and right click on the File's Owner thing off to the left, and you should see the name of the Label variable we just made. In my case it is called greetingLabel. If you look to the right of where the variable name is listed, you should see a circle that is hollowed out. Click within the circle that is next to the right variable, and drag to the Label on the view we already have setup. It should highlight blue signifying that it recognizes that the outlet that you are hooking up to the Label is an outlet made for Labels. Let go of the mouse, and you have officially hooked up your first IBOutlet! Way cool!

One other point that I need to stress is the meaning of File's Owner. We made the IBOutlet in code in the .h file, and then it became available/visible in the File's Owner portion of IB. Do you notice any correlation? The File's Owner area can be thought of as a graphical representation of any and all IB objects that are available for hooking into.

Now you may be wondering why that is as cool as I am trying to make it sound. We just connected a graphical, movable, editable IB element to the code portion of our app. We need to go ahead and make the following changes in our .m file to better grasp the point of setting up IBOutlets:

This line of code that we are adding to the viewDidLoad method of our viewController is pretty straight forward. We are accessing the text attribute of the UILabel object that is named greetingLabel, and setting it's value as "IBOutlets are really cool". So if you go ahead and build and run the app, instead of displaying the text that you were displaying in the .xib file, it should now show the text we just set in this viewDidLoad method.

Do you see what we are doing here? We are making these variables, hooking them up to IB, and then we have access to them in code if we need it. Let me remind you that the main point of IB is to have the ability set everything up graphically the way you want it to look. It isn't always the case that you can do everything in IB because sometimes your content is dynamic in nature. This is where IBOutlets come in handy.

In our next post we are going to go over another aspect of IB called IBActions. Fun stuff!

14. Interface builder and those strange looking .xib files

How are you feeling so far on this material? We haven't really gone over very much by way of mind bending material, but it can be a lot to take in at first. I'd like to move on now and talk about the .xib files you can see on the left side in Xcode. You have probably noticed that the names of any .xib files you see also correspond with the names of existing .h and .m files. If you can recall, I mentioned that the .h, and the .m files together make up a class. This might be a little confusing, but some classes are designed to be viewed on your screen, or in other words they have a visual component to them, and then some do not. The .xib file is the designated place for setting up the visual objects for the view of a particular class.

The concept behind using .xib files to handle the visual objects of your view is that it is easier to lay things out graphically then it is to do it in code. I completely agree with this. There are those that don't prefer the graphical method, but I am definitely one that is ready and willing to take advantage of all of the tools at my disposal. Interface Builder (the built-in program that allows you to do all the cool graphical editing stuff we're going to dive into) is a very powerful tool that we are going to take advantage of. It is very important to understand that Interface Builder is a tool that let's you connect graphical objects that you can easily interact with, to your code. That's the whole point. Setting up things graphically, and then linking them into the code so that they actually do things. This will make more sense as we go along.

If you have been following along with my previous posts, we have been playing around with a simple view-based application with a single blank view controller as the main view. If you go ahead and click on the only .xib file that there is on the left (in my case it's called ExampleViewController.xib), Xcode will load the file in Interface Builder. In previous versions of Xcode, Interface Builder, or IB as I will refer to it, was a separate program that ran along side Xcode. Ever since Xcode version 4.0+, IB has been integrated into Xcode, which is great.

You'll notice that a number of different things have just popped up. You are probably thinking, "I can't handle any more stuff!". Don't worry, you can. The image below will help make sense of all of the tools that IB provides:

Similar to how we've been doing, I'm just going to go through and talk about the points I have labeled:

A - Files owner is one of the more confusing components of IB, but it doesn't need to be. I mentioned earlier that the purpose of IB is to connect graphical objects to code so that they do things. A button doesn't do anybody any good unless it is hooked up to some code that does something, right? Files owner (right clicking on file'w owner more specifically) allows you to see in IB all of the objects from the .h file that are available to you in that particular class. This will all make sense as we go along, but make sure you understand that File's owner is basically a graphical representation of the .h file (which is where you declare all of your class variables! Right?).

B - This pane is a simple graphical representation of your view's hierarchy. This can be quite a useful tool, especially when you are nesting different view's inside of each other. Based on what you see going on in the middle of the screen, with all the buttons and stuff, what can you deduce from this pane? The container view is called View, and then (because of the fact that it is indented) we know that the Button, Label, etc, are objects that are nested in that View. We put those things in the view, and this pane represents that very well.

C - As mentioned before, this list of items are the things that are actually on the container view. So you might say this is a list of subviews.

D - The graphical representation of the view itself. IB does a great job of laying out a nice canvas to begin adding all the objects you need for your view. Just so you aren't confused, I went ahead and added a number of UI objects to illustrate how easy it is to set things up in the .xib file.

E - This row of icons is actually quite important when it comes to changing the attributes of different objects in IB. For our basic purposes, we won't need to change to a lot of them, but as we go along, know that that row is the Batman utility belt of IB.

F - In this sub-toolbar, it is important to remember that you are selecting that cube that is third from the left. This gives you access to the UI element library that you can pull things from.

G - To a large extent, this is where all the magic comes from. If you scroll through this pane, you'll see a large number of things that you can add to the view that we are building. Some of these you have seen in your use with an iOS device, others you haven't. Apple has done a great job of making it very easy to add and implement all of these tools. As we move along, you will become more familiar with this area.

Before we wrap up our little intro of IB and.xib files, let's get ready to so some nifty stuff with IB. Your view should be blank still (unlike mine), and so now I want you to add two things to your view. Where do you get items to add to the view? If you look up at the image, the item library is identified in F & G. Let's go ahead and grab a Label and drag it onto your view. You will notice that if you want to center it, IB will tell you where you need to line it up. Change the text of the Label by double-clicking on it, and change it to whatever you like.

Now go ahead and grab a Button fro the library and drag it beneath your Label. You can add some text to your button in the same way you did the Label. After you save the file, run your project and see what you've done!

Okay so adding a button to the screen that doesn't do anything isn't exactly a monumental achievement, but we are making progress! In our next post we are going to go over how to hook up the graphical side of things (in the .xib file) to the code side of things (in the .h/.m files).

13. The objects in object-oriented programming

Have you heard of the term object-oriented programming before? This is what we're doing. We haven't done much with objects yet, but Objective-C is an object-oriented language, and it is something that we are going to get into a lot more going forward.

What do you think of when you hear the word object? Kind of a vague, general word, right? The idea is that objects can be anything. This is what we want for our programming purposes. We make and use objects that can be anything. We use these objects to fulfill whatever needs or purposes we have. To better understand the importance of objects in programming, lets dive in a little deeper.

Look around you right now and grab the nearest object. Hold it in your hand and look at it. What are some ways that you could describe the object to someone that is blind, and never seen it before? In my case, the object I'm using is my blanket on my bed. I might start describing this blanket as being red, and big, and having golden swirly designs on it. The blanket is pretty thick, and does a great job of keeping me warm.

I just did an adequate job of describing what the blanket is. Now if you think harder about our description of this object, what else could we say about it? The computer only knows what you tell it to know, so it is very important we understand the process of making objects. We just talked about what the object is, but what can be said about what the object has? The blanket has a texture, it has a color, it has a width, a height, and a thickness. The blanket also has a name, a manufacturer, a thread count, and even a tag on it somewhere describing the washing instructions.

Can you tell the difference between what an object is, and what an object has? This distinction is extremely important to understand very clearly. In object-oriented programming, objects are comprised of three important components:

1) The type

2) The property

3) The values

This makes sense. If we were comparing two objects that both had the same width, height, color, and shape, does it necessarily mean that they are the same type of object? Not necessarily. One object could be of type pan, and the other could be of type paper. The type is used to generally classify the object into groups.

The properties of an object describe what an object has. That shouldn't be too hard to grasp. Examples of properties are the shape, color, weight, size, etc. of an object. If it helps, think back to science class when you studied the properties of different minerals and rocks and things.

The final component of an object are the values. Properties and values are very closely related. The value is kind of the answer to the question that is raised by the existence of the property. The sheer existence of the height property doesn't necessarily mean that you know what the height ob that object is, right? It merely means that the object has a height. The value of the height property is where you understand what the object's height actually is.

So to quickly recap, object are comprised of three things. Without looking above, can you name them? Ok, an object is made of a type, properties, and values.

You may be wondering what in the world this object stuff has to do with actual programming, and the answer to that is that it has everything to do with programming. Let's think back to the very beginning, when I introduced you to variables. What are some basic types of variables? Integers, doubles, and booleans. Those three primitive (basic) data types are not objects. They don't have properties, they only have values. But if you'll remember, we also talked about another type of variable, the NSString.

Do you remember that? The NSString data type is an object because it has all three ingredients for what makes up an object. A type, properties, and values. That might sound confusing, but there is a lot more information about the NSString object that is available to us besides it's text value. We can ask the NSString object how long it is, or how much memory it uses, or what it's memory address is. Objects become really powerful (especially ones you make yourself) because you can put in and pull out as much information as you could possibly want or need.

So now that we have a better idea of how objects work, let's do a quick intro to what types of objects there are in iOS. Can you think of any besides NSString? Try and think about things that you see on your iPhone/iPad when you are using it. Anything that you see an object? Answer: everything is an object! The buttons that you press are objects. They have sizes, shapes, colors, positions, and things that they are supposed to do when pressed. Labels are objects, they have properties that you can set and adjust and change to fit your needs. Textviews, tableViews, scrollViews, webViews, mapViews, sliders, steppers, navigation bars, toolbars, activity indicators, alertViews, and even tabBars are all objects! Basically everything we do in iOS development (and many other computer programming languages for that matter) is object-oriented.

We could go on and on and on about how to make custom objects, and how to use them, and where to put them, and so on. I don't want to overwhelm you at this point, but I want to make it very clear that objects are very powerful, and that from here on out that will be a word you see more often than 'the'.

As we progress through different phases of development, we will get to understand objects a lot better. But for now, we are going to take advantage of all the amazing work that Apple has done and use the objects that they have made available for our use.