Recap of User Interaction Demo and More Programming Concepts

Updated Oct 3 2013: This tutorial is compatible with XCode 5 AND XCode 4!

We’re taking a practical approach to learning iOS programming. This means lots of hands on work and practice!
In order to benefit the most from these lessons, you should open XCode and try to follow along.

This is part 7 of the lesson plan. Click here for the entire Learning Plan.

In the previous tutorial on user interaction, we introduced some new concepts and worked with some new UI elements such as the UIButton and UITextField.

Let’s take a moment to recap what you’ve accomplished in the last practice session without even knowing it!

Model View Controller Design Pattern

So all along, I’ve explained to you that the Main.storyboard file is the view and ViewController.h/.m is the class that manages the view.

What I haven’t told you is that iOS programming follows a software design pattern called Model View Controller (MVC for short) and the Main.storyboard and ViewController.h/.m falls into this pattern.

The MVC pattern is really easy to understand with a diagram:

MVC Design Pattern

The diagram above illustrates 3 distinct roles or responsibilities.

View: The View is responsible for displaying the data on the screen from the Controller and receiving user gestures and relaying that back to the Controller.

Controller: The Controller is responsible for updating and retrieving information from the Model and handles user interaction from the View.

Model: The Model is responsible for retrieving the data from whatever data sources that powers the app (database, feeds etc).

The XCode projects that we’ve started so far are all single-view applications and by default, XCode creates storyboard file which describes the view and a class to manage that view called ViewController.h/.m.

Well, the view described by Main.storyboard falls into the “View” category of the MVC pattern and ViewController.h/.m falls into the “Controller” category of the pattern.

What about the “Model”?

Well, since XCode doesn’t know what your data is going to be, it can’t generate any model class for you. We need to create a class to represent the “Model” ourselves and this is exactly what we’ll do in Practice #3.

The Model View Controller design pattern also dictates how communication should function between the three roles.

This diagram below illustrates the rules:

MVC Design Pattern showing communication routes

1. The View never directly sends or receives information to/from the Model.

2. The Controller serves as the “middle-man” between the View and the Model

3. The Model never communicates with the View.

So why do we have these communication rules?

Nothing is going to blow up or crash if we don’t follow these rules however, by following the MVC design pattern and it’s communication rules, we’re “de-coupling” the different components as much as possible.

The idea is that, the more de-coupled things are, the easier it will be to:
a) swap components in and out as needed because there are less intertwining relationships and dependencies
b) easier to read, understand and thus solve any bugs that may crop up

If we didn’t follow the rules and had all the components communicating with every other component, it would be like sorting through a plate of spaghetti and you’re trying to trace the root of a bug.

The MVC pattern may seem very abstract to you right now but don’t worry because as we build more demo apps together, it’ll become increasingly apparent how our apps follow this software design pattern.

In fact, we’ll use the full MVC pattern in our next practice demo!

If you’d like to explore MVC further or need some clarification, try reading Apple’s reference on MVC

IBOutlets and IBActions

When you were working on the user interaction demo in the previous tutorial, you had to drag some UIElements over to the ViewController.h header file and create some properties so that you could reference those UIElements from the code in the ViewController.m implementation file.

Did you notice that when you created those properties, there was a keyword called “IBOutlet”?

The keyword IBOutlet simply denotes that the property can be exposed to Interface Builder and connect with UIElements created from Interface Builder.

The way in which we dragged the UIElement to the ViewController.h file is just one of the ways to connect the UIElement with a property. Another way we could’ve approached it is to first manually create the property in ViewController.h by manually typing it out (making sure to include the keyword IBOutlet). Then we could’ve gone into Interface Builder and connected a UIElement to that property like shown below:

Connecting IBOutlet property via Interface Builder

Similarly, when you dragged the UIButton into ViewController.m and created a method to handle the button click, did you notice that the method was created with a keyword “IBAction”?

The IBAction keyword denotes that this method should be visible from Interface Builder so when you’re in Interface Builder and looking for a method to hook up to a certain event, you can see that method.

The way in which we dragged the UIButton to ViewController.m to create the method is just one of the ways to do it. Another way we could’ve done it is by creating the IBAction method first in ViewController.m, and then going into Interface Builder, selecting the UIButton and selecting an existing IBAction method to connect with the click event.

Connecting IBAction method via Interface Builder

Declaring and Using Properties

Since you’ve had practice using properties and creating some properties via Interface Builder, let’s take a moment now to learn about how to manually declare properties in our class.

You declare properties in the .h (header) file and it’ll be in a format like this:

@property (attributes) ClassType PropertyName;

Attributes: For what you have to do right now, your attributes will probably be “strong, nonatomic”. To understand what that means, you’ll need to have a good grasp of how memory allocation works and some notion about threading so I won’t get into all of that here, however, if you are really curious, I actually explain that stuff and about what “strong” and “nonatomic” means here. So you can go and read that if you’re interested!

ClassType: This will be the type of object that this property will reference.

PropertyName: This will be the name of your property. Usual name convention starts with a lower case first letter with any following words having a capital letter. Example: “viewController” or “macBook”. You may notice that in our previous property declarations, there’s an asterisk(*) in front of the property name or variable name. This means that it will be referencing an object rather than a primitive type. For more information about when to use the asterisk, here. And more information about primitive type values, here.

Here’s an example of a property in ViewController.h:

And here’s how I could use the property in a method in ViewController.m

Declaring and Using Methods

We’ve also seen methods quite a few times now so let’s take a deeper look at how to declare and use methods!

When you declare methods, first consider if it only needs to be exposed to that object. If so, then we’re going to declare a private method, meaning that it can only be accessed by that instance using the “self” keyword.

If that method performs duties that may need to be triggered by other objects/instances, then we need to make it a public method.

If you’re not sure, then you’ll want to leave it as a private method. You can always turn it into a public method later.

Declaring a private method
In order to declare a private method, all we have to do is declare it in the .m Implementation file.

For example, if I declare a method in ViewController.m like below:

This method can only be accessed by other methods in ViewController.m like this:

Declaring a public method

Now what if I wanted to expose that method to the public so that other instances and objects can use it?

All I would have to do is add the method signature to the .h Header file.
The method signature is what identifies the method and it’s the line before the opening curly brace “{“.
So for example, to expose the “sampleMethod” I declared above and make it public, I would add the following to ViewController.h:

Remember, the header file is like a table of contents and it allows other classes to “see” that the method exists.

Now other classes can access this method like this:

Even though sampleMethod is now a public method, you can still call it from the same .m file using the “self” keyword.

Anatomy of a method

This is a very basic method:

– (ReturnType)methodName;

This method signature starts with a dash, “-“, signifying that it’s an instance method. These are the types of methods we’ve been talking about so far. There is another type called a “class” or “static” method which we’ll get to in the future (and that’s denoted by “+”). But for now, let’s talk about instance methods which is what you’ve seen and what you know.

The return type specifies the type of data that this method returns when it’s called. If this method doesn’t return any sort of data, then the keyword “void” is used here. Otherwise, you put in the data type or the Class Type if it returns an object. If you specify a return type, then you must use the “return” keyword inside your method to return some data.
You’ll get familiar with these return types as you see more and more of them in our demos.

The method name is the name of the method.

In a lot of cases, we’ll use methods to take some input, perform some processing on it and then return the result.

To specify that the method should accept inputs, your method signature would look like this:

– (ReturnType)methodName: (parameterDataType)parameterName;

In the method signature above, you’re saying that it will expect one piece of data passed into the method when you call it and that data will be of type “parameterDataType” and inside the method, you can access this piece of data with “parameterName”.

As an example, the following method will take a numerical input, add 5 to it and return it.

Since I’m preaching practical learning, I don’t want to bombard you with a ton of examples right now.
Instead, let’s move on and as we do more hands on practical demos, you’ll pick up on more ways you can declare and use methods.

In the next tutorial, we’re going to put into practice the MVC design pattern, declaring properties and methods and also navigating between 2 different views.

Click here to go to the next lesson now!

Frequently Asked Questions

If you have a question related to this tutorial or need me to clarify something, please ask in the comments below and I’ll update this FAQ section for everyone’s benefit.