Adding the Image View

Next, take a look at the Utilities pane to the right of the screen and make sure the controls list is visible. The small blue cube icon should be selected—you can see it in Figure 4-6. Scroll down the list until you see the “Image View” control. See Figure 4-7.

Drag and drop this to the “View Controller” gray area in the center of the designer. If you have trouble, you can also drag it directly to the “View” entry on the “View Controller Scene” list to the left of the window. See Figure 4-8, where the image view is added to the view, and where it is visible on the storyboard.

With the image view selected, you should now look at the attributes inspector at the top-right-hand side of your Xcode window. You’ll see a list option called “Image.” See Figure 4-9.

Drop down the list beside “Image” at the top, and you should see an item for the image you added earlier. We used “geek1.png,” so you can see that in Figure 4-10. When you select it, the image view will also load your picture and render it.

Adding a Label

Next you should drag a label from the library onto the “view design” area, placing it near the center of the view, as shown in Figure 4-11. Make sure it’s centered as indicated by the blue line. Later you’ll be adding a button, and your code will invoke an action that will change the text on this label.

The text is quite difficult to read, so let’s fix that. With the label selected, drag the corners to change the width of the label, making it wider, and then go to the attributes inspector and make three changes.

• Change the alignment to centered.
• Change the text color to white.
• Delete the default text (label).

You can see what the attributes inspector should look like for the label in Figure 4-12.

Adding a Button

Next up, you should drag a button to the design surface and center it horizontally. Double click it and you will get a chance to change its text. Set the text to “Are you a Geek?” as shown in Figure 4-13.

In iOS7, buttons are flat and look like labels, so you’ll need to change the text of the button to make it more readable. As it’s set against a dark background, the only change you’ll need to make is to set the Text Color property on the attribute inspector. We set it to white, as you can see in Figure 4-14.

Now that you’re done with designing the app, the next step is to add the code that you’ll use to bring it to life. You’ll see that in the next section.

Digging the Button Code

When you made the button an action, you created something very important: a method. A method is the code that runs in response to an action performed upon an object. In this case, the object is the button, and the action is the user clicking on it. You specify that the method to run in this instance is called btnClick.

A method is also a function, and a function has a return type. Consider something simple, like a function that adds two numbers together—you give it two numbers, and it returns one number, which is the result of the addition. You specify the return type in Objective-C by enclosing the return type in brackets before the method name declaration:

- (IBAction)btnClick:(id)sender;

In this case, the return type is IBAction, which is short for “Interface Builder Action,” which should make sense, as you specified that this function is an action when you dragged the button to the code surface.

This is a special type of return value, which you don’t have to explicitly set yourself. Objective-C now understands that this function is going to be used by controls you put on the designer.

The name of the method comes next. If the method requires values to be passed to it as parameters, the method name will be followed by a colon (“:”) and a list of those parameters. In this case the method is called btnClick.

- (IBAction)btnClick:(id)sender;

Last is the list of parameters or arguments that you send to the function. In this case you are sending an argument of type id, with the name “sender.” This just allows Objective-C to keep track of which object raised the method, because it knows its id.

- (IBAction)btnClick:(id)sender;

The method itself will be implemented in the ViewController.m file. You’ll see in a moment that an empty function was created for you there too that matches the declaration in the .h file.

Editing Your Code

The first step is to add some code to your header file. This will be used to track the state of how the user has pressed the button. The label is going to alternate between two messages, so you can use a Boolean variable, which has only two states, to keep track of them. Boolean variables can be set to false and true, so we’ll write some code that says, “If it’s true, make it false, and if it’s false, make it true.” So, in order to set the label to alternate between the two states, we can say, “If it is true, make the text this, otherwise, make the text that.”

Variables like this—that you use in your implementation (.m) file—can be defined in your header (.h) file. Thus, to declare a Boolean, you use bool, and give the variable a name. In this case we’ll call it ruaGeek.

#import <UIKit/UIKit.h>
 
bool ruaGeek;
 
@interface ViewController : UIViewController
- (IBAction)btnClick:(id)sender;
@property (strong, nonatomic) IBOutlet UILabel *geekLabel;
 
@end

Now, within your .m file, you can reference ruaGeek, and Objective-C will know that it’s a Boolean that can be true or false.

Open ViewController.m, and you’ll see the code that was generated for you when you created the action for the button. You called it btnClick , so the code will look like this:

- (IBAction)btnClick:(id)sender {
}
@end

Earlier, we mentioned that when the button is pressed, we’ll check ruaGeek, and if it is true, we’ll set the text to one value, otherwise we’ll set it to a different one. In Objective-C, rules like this are performed using an if-else statement.

The syntax for this statement looks like this in Objective-C:

if(condition)
{
    do something;
}
else
{
    do something else;
}

The condition is tested to see if it is true, and if it is, the first “do something” is executed, otherwise the “do something else” is executed. This is really convenient, because ruaGeek is a Boolean variable, which can either be true or false. In Objective-C, you use two “=” signs when you are checking if something is equal. This might look a little strange at first, but it’s a way to help the computer understand the difference between using “=” to set a value and using “==” to determine if values are equal.

In English, you can say “x=1” and you’d understand that you are making x have the value of one. You can also say if(x=1), and you’d understand that you are checking if x is 1 before going further. Computer languages can’t tell the difference here, so for checking if the value is equivalent, you use two “=” signs like this: if(x==1).

So, to check if ruaGeek is true, you can do this:

if(ruaGeek==true)
{
    do something;
}
else
{
    do something else;
}

A convenient shorthand is this: if you want to check if a condition is true, you don’t need to say ==true. This code is exactly the same:

if(ruaGeek)
{
    do something;
}
else
{
    do something else;
}

So now, let’s set the text of the labels according to the value of ruaGeek:

- (IBAction)btnClick:(id)sender {
    if(ruaGeek)
    {
_geekLabel.text = @"No you're not!";
    }
    else
    {
        _geekLabel.text = @"Definitely a geek!";
         
    }

So, what do you think would happen if you ran this code now? Run it and give it a try. The app will launch, you’ll press the button, and it will tell you that you’re definitely a geek. But then when you press the button again, nothing happens. Why?

Go back to look at the preceding code. When you first run the app, ruaGeek hasn’t been set, so it’s considered to be false. As a result, the text “Definitely a geek!” gets rendered. But ruaGeek is still false. So when you press it again, the same text is rendered. You have to change the value of ruaGeek in code when you click the button.  You do this by setting it to true in the branch of the function where the code goes when ruaGeek is false, and vice versa.

Here’s the code:

- (IBAction)btnClick:(id)sender {
    if(ruaGeek)
    {
        _geekLabel.text=@"No, you're not!";
        ruaGeek = false;
    }
    else
    {
        _geekLabel.text=@"Definitely a geek!";
        ruaGeek = true;
    }
}

Now if you run the app, you’ll see that the label changes whenever you press the button.

Figure 4-19 shows the label upon pressing the button once.

Pressing the button again, you’ll see that the label changes. See Figure 4-20.

And that’s it. You’ve now created an app that, as well as managing user I/O, has conditional logic within the code. It’s a quantum leap from your first “Hello, World!” app, but as you move through this book, you’ll get introduced to more and more concepts that build upon these foundations! You’re well on your way to being an iOS7 developer!

Storyboards

A few times already you’ve done user-interface work by editing a file that ended with the extension .storyboard. This is a curious name for something that is your user interface—why is it called a storyboard? Well, the logic behind that is that it separates, in the developer’s mind, the actual user interface and the instructions that are used to construct that interface. In movie making, before the director films anything, the writer, director, and artists get together to sketch out the scenes and what they should look like in a process called storyboarding. When you storyboard a movie, you effectively make the entire movie on paper, showing each scene and how they are all connected. It’s similar in iOS user interfaces.

Apple introduced storyboards so that developers could design what they wanted their user interfaces (UI) to look like, and how they connected to each other, and Objective-C would use that to create the actual UI that ran. It’s no coincidence that your user interface “screen” that you’ve been building was called a “scene.” See Figure 4-21.

Each app you’ve built so far is a single view app, so your storyboard had only one scene. It’s like a very short movie.

In this book, so far, you’ve opened your storyboards, and you’ve dragged and dropped controls onto them. This created the behind-the-scenes instructions that Objective-C uses to construct your user interface, and the storyboard editor gave a graphical interpretation of that to help you design your UI.

You can see what the scene really looks like by right clicking on the storyboard file in Xcode, and selecting “Source Code” on the “Open As . . .” menu that pops up. This code is written in a language called XML (Extensible Markup Language). Despite its name, XML isn’t really a language in which you can communicate actions, but more one in which data and its structure are expressed together. It’s a very useful way to define and exchange information.

Figure 4-22 shows some of this XML opened in the Xcode editor.

XML is commonly used in development for storing data, and, as you can see, your user interface definition is just data. Tweaking the XML by hand is a neat way to quickly edit your user interface if you don’t want to use the assistants. But for now you won’t do anything with it. It’s just good to get an understanding of how the Objective-C compiler reads your design.

Classes

It’s almost impossible to avoid classes when writing software in just about any modern programming language for just about any platform, including iOS. You should think of a class as the set of instructions for building an object. An object that is built from a class is an instance of that class.

So, for example, if you were to define a cow, you would say that the class of a cow is that it’s an animal with four legs and a tail that makes a “moo” sound. It’s typically a certain size and produces milk and beef.

An instance of that class is any particular cow.

Of course there are lots of species of cow, so each of these can be designed as a different class. To get around having to define the same things again and again, object oriented (OO) programming provides things such as inheritance, where one class can borrow stuff from its parent class, and interfacing, where common stuff can be put into one class, and other classes extend on that. Indeed, our cow class has already inherited from a base class of type “animal,” which would distinguish it from a vegetable or mineral. But that’s getting into complex territory, so for now just think in terms of classes as defining objects. Everything in an iOS app is an object, so it’s important to start thinking in terms of the classes that define them. For example, in the app in this chapter, the button is a class, and you told the program to create an instance of the button class at runtime. You give it various attributes, such as its text (“Are you a Geek?”), and you listened for actions on that button. Ditto for the label, the image view, and even the view controllers. It’s classes all the way down . . .

Methods

A method is a function that you can call to act on an object. So, for example, if you define the class for a car, you’d likely define a method for “accelerate,” so that when there’s an object for the car, whoever is driving could push it forward by accelerating it. In a real-life car, the interface is the gas pedal, and by pushing on the gas pedal you are “calling the accelerate method.”

You saw how to declare a method earlier when you looked at a method and a method signature.

-(IBAction)btnClick:(id)sender

In this case, btnClick is the name that was chosen for the method. You could have called it anything you liked, as it’s not a reserved keyword. It’s good practice to give it a descriptive name like btnClick, geekButtonTouched, or btnGeekClicked. That way, when you read your code, you can glean an understanding for what triggered this event.

-(IBAction)monkey:(id)sender

Sometimes as you write code you’ll notice that there’s a “-”  to the left of the method declaration, and sometimes there’s a “+.”

When there’s a “-,” that means it’s an instance method, where the method can be used on any object created from the class.

When there’s a “+,” that means it’s a class method, and the method is used on the class itself, typically when constructing an object. When you come across a class method being used later in the book, I’ll leave a note showing this.

Header Files

Some programming languages—and Objective-C is one of them—like classes to be defined using two files—a header file (.h) and an implementation file (.m)—where the header file defines the data and methods that the class is going to use, and the implementation file implements them.

Let’s look at our ViewController.h a little more closely. Here’s the code:

#import <UIKit/UIKit.h>
 
bool ruaGeek;
 
@interface ViewController : UIViewController
@property (strong, nonatomic) IBOutlet UILabel *geekLabel;
- (IBAction)btnClick:(id)sender;
 
@end

There are lots of concepts here that you’ll understand in due course, but two important ones that you’ll use a lot are #import and @interface.

#import: Think about all the code that is used to draw the button, handle the messages from the user, lay out the user interface, draw the label, etc. This all seems to happen without you doing anything. That’s because you are just using an instance of a button, a label, and other controls, and their code is held elsewhere. Well, Objective-C isn’t smart enough to know where that elsewhere is, and that’s what the import statement is for. The iOS development environment has many libraries that you can use for different functions, and the library that supports the UI is naturally called UIKit. Thus, when you import the UI kit, you are telling Objective-C to look for code that you haven’t written, such as the class definitions for the UILabel and the UIButton as it compiles your app. Putting the # in front of import tells the compiler what to do, and isn’t code that will execute in your app.

@interface: Whenever you see an “@” in front of a command, it’s effectively a directive to Xcode to do something. In this case, you are defining the user interface of your application as a class called ViewController. The syntax for telling it what type of class it should be is a ”:” so the following line:

@interface ViewController : UIViewController

means “Define the interface with the ViewController class. This class inherits from the UIViewController.”

That’s a funny word: inherits. In the real world, you inherit something that belonged to somebody else, and they pass it on to you. In Objective-C it’s very similar. Consider a class of type “cow” as before, and then another class of type “Angus cow.” It would be best for “Angus cow” to have not only everything a cow has, but also some extra stuff that only an Angus cow has. That’s inheritance—your Angus cow class would inherit from the cow, but would have some extras.

In this case, your ViewController inherits from UIViewController, and your instance of the ViewController has some extras, such as the button, label, and image.