Hour 3

Discovering Objective-C: The Language of Apple Platforms

This hour’s lesson marks the midpoint in our exploration of the Apple iOS development platform. It will give us a chance to sit back, catch our breath, and get a better idea of what it means to “code” for iOS. Both OS X and iOS share a common development environment and a common development language: Objective-C.

Objective-C provides the syntax and structure for creating applications on Apple platforms. For many, learning Objective-C can be daunting, but with patience, it may quickly become the favorite choice for any development project. This hour takes you through the steps you need to know to be comfortable with Objective-C and starts you down the path to mastering this unique and powerful language.

To provide you with the information you need to be successful in iOS development, this hour concentrates on fundamentals—the core concepts that are used repeatedly throughout the examples and tutorials in this book. The approach in this hour is to introduce you to a programming topic in general terms and then look at how it will be performed when you sit down to write your application. Before we begin, let’s look a bit closer at Objective-C and object-oriented programming.

The problem with imperative programming is that it lends itself to growing, without structure, into an amorphous blob. Applications gain features when developers tack on bits of code here and there. Often, instructions that implement a piece of functionality are repeated over and over wherever something needs to take place. Procedural programming refers to an imperative programming structure that attempts to avoid repetition by creating functions (or procedures) that can be reused. This works to some extent, but long-term still often results in code bloat. The benefit of this approach, however, is that it is quite easy to pick up and learn: You create a series of instructions, and the computer follows them.

Consider a program that enables you to track reminders. With each reminder, you want to store information about the event that will be taking place—a name, a time to sound an alarm, a location, and any additional miscellaneous notes that you may want to store. In addition, you need to be able to reschedule a reminder’s alarm time or completely cancel an alarm.

In the imperative approach, you have to write the steps necessary to track all the reminders, all the data in the reminders, check every reminder to see whether an alarm should sound, and so on. It’s certainly possible, but just trying to wrap your mind around everything that the application needs to do could cause some serious headaches. An object-oriented approach brings some sanity to the situation.

In an object-oriented model, you could implement a reminder as a single object. The reminder object would know how to store the properties such as the name, location, and so on. It would implement just enough functionality to sound its own alarm and reschedule or cancel its alarm. Writing the code, in fact, would be very similar to writing an imperative program that only has to manage a single reminder. By encapsulating this functionality into an object, however, we can then create multiple copies of the object within an application and have them each fully capable of handling separate reminders. No fuss and no messy code!

Most of the tutorials in this book make use of one or two objects, so don’t worry about being overwhelmed with OOP. You’ll see enough to get accustomed to the idea, but we’re not going to go overboard.

Another important facet of OOP is inheritance. Suppose that you want to create a special type of reminder for birthdays that includes a list of birthday presents that a person has requested. Instead of tacking this onto the reminder object, you could create an entirely new “birthday reminder” that inherits all the features and properties of a reminder and then adds in the list of presents and anything else specific to birthdays.

• Class: The code, usually consisting of a header/interface file and implementation file, which defines an object and what it can do.
• Subclass: A class that builds upon another class, adding additional features. Almost everything you use in iOS development will be a subclass of something else, inheriting all the properties and capabilities of its parent class.
• Superclass/parent class: The class that another class inherits from.
• Singleton: A class that is instantiated only once during the lifetime of a program. For example, a class to read your device’s orientation is implemented as a singleton because there is only one sensor that returns tilt information.
• Object/instance: A class that has been invoked and is active in your code. Classes are the code that makes an object work, whereas an object is the actual class “in action.” This is also known as an instance of a class.
• Instantiation: The process of creating an active object from a class.
• Instance method: A basic piece of functionality, implemented in a class. For the reminder class, this might be something like setAlarm to set the alarm for a given reminder. Methods are public or private, depending on whether they can be accessed only within the class where they are defined (private), or within other classes as well (public).
• Category: Provide a means of extending a class without modifying the class code itself.
• Class method: Similar to an instance method, but applicable to all the objects created from a class. The reminder class, for example, might implement a method called countReminders that provides a count of all the reminder objects that have been created. If you’re familiar with other OO languages, you may recognize this as a static method.
• Message: When you want to use a method in an object, you send the object a message (the name of the method). This process is also referred to as calling the method.
• Instance variable: A storage place for a piece of information specific to a class. The name of a reminder, for example, might be stored in an instance variable. All variables in Objective-C have a specific “type” that describes the contents of what they will be holding. Instance variables are very rarely accessed directly and, instead, should be used via properties.
• Variable: A storage location for a piece of information. Unlike instance variables, a “normal” variable is accessible only in the method where it is defined.
• Parameter: A piece of information that is provided to a method when it is messaged. If you were to send a reminder object a setAlarm method, you would presumably need to include the time to set. The time, in this case, would be a parameter used with the setAlarm method.
• Property: An abstraction of an instance variable that has been configured using special directives to provide easy access to your code. Like methods, properties can be public or private, depending on whether they can be accessed only within the class where they are defined (private), or within other classes as well (public).
• Protocol: Protocols declare methods that can be implemented by a class—usually to provide functionality needed for an object. A class that implements a protocol is said to conform to that protocol. This is similar to a Java interface.
• Self: A way to refer to an object within its own methods. When an instance method or property is used in an application, it must be used with a specific object. If you’re writing code within a class and you want it to access one of its own methods or properties, you use self to refer to the object.

It’s important to know that when you develop for iOS you’re going to be taking advantage of hundreds of classes that Apple has already written for you. Everything from creating onscreen buttons to manipulating dates and writing files is covered by prebuilt classes. You’ll occasionally want to customize some of the functionality in those classes, but you’ll be starting out with a toolbar already overflowing with functionality.

Confused? Don’t worry! This book introduces these concepts slowly, and you’ll quickly get a feel for how they apply to your projects as you work through several tutorials in the upcoming hours.

Objective-C statements are easier to read than other programming languages and often can be deciphered just by looking at them. For example, consider the following line that compares whether the contents of a variable called myName is equal to John:

[myName isEqualToString:@"John"]

It doesn’t take a very large mental leap to see what is going on in the code snippet. In traditional C, this might be written as follows:

strcmp(myName,"John")

The C statement is a bit shorter, but it does little to convey what the code is actually doing.

Because Objective-C is implemented as a layer on top of C, it is still fully compatible with code that is written entirely in C. For the most part, this isn’t something that you should concern yourself with, but unfortunately, Apple has left a bit of “cruft” in its iOS software development kit (SDK) that relies on C-language syntax. You’ll not encounter this often, and it isn’t difficult to code with when it does occur, but it does take away from the elegance of Objective-C just a little.

Now that you have an idea of what OOP and Objective-C are, let’s take a look at how you’ll be using them over the course of this book.

Okay, sounds simple enough, but where will the coding take place? If you create a new project look, you’ll see quite a few different files staring back at you.

Let’s review the structure of the very short, and entirely made-up, interface file in Listing 3.1.

LISTING 3.1 A Sample Interface File

 1: #import <UIKit/UIKit.h>
 2:
 3: @interface myClass : myParent <myProtocol> {
 4:   NSString *_myString;
 5:   IBOutlet UILabel *_myLabel;
 6: }
 7:
 8: @property (weak, nonatomic) NSString *myString;
 9: @property (weak, nonatomic) NSString *myOtherString;
10: @property (weak, nonatomic) IBOutlet UILabel *myOtherLabel;
11:
12: +(NSString)myClassMethod:(NSString *)aString;
13:
14: -(NSDate)myInstanceMethod:(NSString *)aString anotherParam:(NSURL *)aURL;
15:
16: -(IBAction)myActionMethod:(id)sender;
17:
18: @end

First, in line 1, the interface file uses the #import directive to include any other interface files that our application will need to access. The string <UIKit/UIKit.h> designates the specific file (in this case, UIKit, a system framework which gives us access to a vast majority of the classes).

New in Xcode 5, you can use a variation of #import—the module @import directive. Unlike #import, which usually requires you to add additional files to your project, a single @import statement takes care of everything. The only drawback is that frameworks you’re using must support modules for this to work. Because the iOS system frameworks do, you should be in good shape using this feature, unless you are using code from a third party.

The syntax for importing modules is @import <module name>;. (Note the need for the trailing semicolon.)

For example, line 1 could be rewritten as follows:

1: @import UIKit;

Importing modules dramatically speeds compilation of your application and automatically links appropriate frameworks into your app as needed. Most of Apple’s examples still use the older-style #import statement, but I suspect they’ll migrate to @import over time.

Whenever we need to import something, I explain how and why in the text. The UIKit example is included by default when Xcode sets up your classes and covers most of what you need for this book’s examples.

3: @interface myClass : myParent <myProtocol> {
4:   NSString *_myString;
5:   IBOutlet UILabel *_myLabel;
6: }

In this example, a variable that contains an object of type NSString named _myString is declared, along with an object of type UILabel that will be referenced by the variable _myLabel. An additional keyword IBOutlet is added to the front of the UILabel declaration to indicate that this is a user interface object that will be defined in Interface Builder (IB). You learn more about IBOutlet in Hour 5, “Exploring Interface Builder.”

Notice that the instance variables I’ve used in this example start with an underscore (_) character. This is a naming convention used in Objective-C to denote instance variables (versus other variables, such as a counter, that you might use in a portion of your code). You can create instance variables without underscores, but when using Xcode’s code-generation tools, it will follow this approach.

One very, very important thing to note is that this is not the only way to define instance variables (or outlets). It is certainly a legitimate way to do so, but not necessarily the most efficient. In fact, in much of your development, you won’t even need to create instance variables. Instead, you’ll implicitly create your instance variables by defining properties. We get to this approach in the next section.

Notice that line 3 includes a few additional items after the @interface directive: myClass : myParent <myProtocol>. The first of these is the name that we’re giving the class that we’re working on. Here, we’ve decided the class will be called myClass. The class name is then followed by a colon (:) and a list of the classes that this class is inheriting from (that is, the parent classes). Finally, the parent classes are followed by a list of protocols enclosed within angle brackets, <>.

 8: @property (weak, nonatomic) NSString *myString;
 9: @property (weak, nonatomic) NSString *myOtherString;
10: @property (weak, nonatomic) IBOutlet UILabel *myOtherLabel;

The @property directive is used to simplify how you interact with the instance variables that you’ve defined in your interface—and, as you’ll learn shortly, can even act as a shortcut for creating the instance variables themselves. In essence, defining a property provides a layer of abstraction on top of an instance variable. Instead of interacting with a variable directly (and potentially in ways you shouldn’t), you use a property instead. Line 8, for example, defines a property that we can use to access the instance variable defined previously in line 4.

Traditionally, to interact with the contents of your instance variables, you have to use (and write!) methods called getters and setters (or accessors and mutators, if you want to sound a bit more exotic). These methods, as their names suggest, are created to get and set values stored in your instance variable objects without touching the actual variables themselves.

What @property does is write the getter and setter for us and give us a really nice way of using them. The getter is simply the name of the property, while the setter is the property name (capitalized) with the prefix set. For example, to set the instance variable _myString through a property, you could use the following:

[myClassObject setMyString:@"Hello World"];

And to retrieve value from _myString, you might type this:

theStringInMyObject=[myClassObject myString];

Not too tough, but it’s not as easy as it could be. Using @property also allows us to read and write instance variable values just by typing the name of the object that contains the property, followed by a period, and the name of the property. This is called dot notation:

myClassObject.myString=@"Hello World";
theStringInMyObject=myClassObject.mystring;

We make use of this feature nearly everywhere that we need easy access to instance variables. After we’ve given the “property” treatment to an instance variable (line 8), we almost always refer to the property rather than the variable itself. That leads us to two final points that can lead to a ton of confusion.

First, because properties and instance variables are so closely related, Objective-C makes it possible to implicitly declare an instance variable just by declaring the property. In other words, consider line 9:

9: @property (weak, nonatomic) NSString *myOtherString;

This single line is all that is actually needed to declare a new instance variable _myOtherString and an associated property named myOtherString; no explicit declaration of the instance variable is required.

In addition, property declarations can be used to create a property, instance variable, and an IBOutlet, all in one, as shown in line 10:

10: @property (weak, nonatomic) IBOutlet UILabel *myOtherLabel;

You’ll encounter this often in Apple’s iOS project templates: a property declaration that implicitly defines an instance variable. We’ll use this approach ourselves because writing a single line of code is easier (and less prone to errors) than writing several lines to do the same thing.

The second extremely important point in this discussion is understanding the relationship between the names of properties and instance variables. As previously mentioned, instance variables typically begin with an underscore (_). The same cannot be said for properties. Properties don’t begin with an underscore, but refer to instance variables that do. If you declare an instance variable named myVariable and want to create a property that references it, you can’t do it by creating a property named myVariable. Doing so creates a new instance variable with, you guessed it, an underscore at the start: _myVariable. Although there are ways to change this naming convention, it’s best to stick with a standard. We will be using the @property directive to create both our properties and their corresponding instance variables (just as in lines 9 and 10). Whatever we name a property, just keep in mind that in the background, a variable with almost the same name (but starting with an _) is automatically created.

12: +(NSString)myClassMethod:(NSString *)aString;
13:
14: -(NSDate)myInstanceMethod:(NSString *)aString anotherParam:(NSURL *)aURL;
15:
16: -(IBAction)myActionMethod:(id)sender;

Prototypes follow a simple structure. They begin with a + or -. The + denotes a class method, and - indicates an instance method. Next, the type of information the method returns is provided in parentheses, followed by the name of the method itself. If the method takes a parameter, the name is followed by a colon, the type of information the method is expecting, and the variable name that the method will use to refer to that information. If multiple parameters are needed, a short descriptive label is added, followed by another colon, data type, and variable name. This pattern can repeat for as many parameters as needed.

In the example file, line 12 defines a class method named myClassMethod that returns an NSString object and accepts an NSString object as a parameter. The input parameter is made available in a variable called aString.

Line 14 defines an instance method named myInstanceMethod that returns an NSDate object, also takes an NSString as a parameter, and includes a second parameter of the type NSURL that will be available to the method via the variable aURL.

The third instance method, myActionMethod declared in line 16 is different from the others because it defines an action. The return type is set to IBAction—a special keyword that indicates that this is a method that will be triggered via a connection created in IB. In other words, methods that use IBAction as their return type will be called when the user touches a button, presses a switch, or otherwise interacts with your application’s UI. These methods take a single parameter, usually denoted as sender that is set to whatever object the user interacted with. Just as for the IBOutlet mentioned earlier, you’ll be learning much more about IBAction in Hour 5.

18: @end

That’s it for the interface. Although that might seem like quite a bit to digest, it covers almost everything you’ll see in an interface/header file.

LISTING 3.2 An Implementation File

 1: #import "myClass.h"
 2:
 3: @interface myClass () {
 4:   NSString *_myPrivateString;
 5: }
 6:   @property (weak, nonatomic) IBOutlet UILabel *myPrivateLabel;
 7:    -(IBAction)myPrivateActionMethod:(id)sender;
 8: @end
 9:
10: @implementation myClass
11:
12: +(NSString)myClassMethod:(NSString *)aString {
13:   // Implement the Class Method Here!
14: }
15:
16: -(NSString)myInstanceMethod:(NSString *)aString anotherParam:(NSURL *)aURL {
17:   // Implement the Instance Method Here!
18: }
19:
20: -(IBAction)myPrivateActionMethod:(id)sender {
21:   // Implement the Private Method Here!
22: }
23: @end

1: #import "myClass.h"

When you create your projects and classes in Xcode, this is automatically added to the code for you. If any additional interface files need to be imported, you should add them to the top of your interface file rather than here.

You can put instance variables, properties, outlets, and method definitions in this block, but the items that you put here are considered private to your class. In other words, if another application wants to use your class, it cannot directly access the items you add in this block; they are available only to you within the class itself (appropriate for internal calculations, counters, error handling, and the such). This is known, in Objective-C, as an empty category.

10: @implementation myClass

12: +(NSString)myClassMethod:(NSString *)aString {
13:   // Implement the Class Method Here!
14: }
15:
16: -(NSString)myInstanceMethod:(NSString *)aString anotherParam:(NSURL *)aURL {
17:   // Implement the Instance Method Here!
18: }
19:
20: -(IBAction)myPrivateActionMethod:(id)sender {
21:   // Implement the Private Method Here!
22: }

Notice that even these represent a class method, a public instance method, and a private method; the coding all takes place in the implementation file. Whatever you’ve declared as public in your interface file, and private at the top of the implementation file, must be implemented here. (I’ve left out the implementation of the public method myActionMethod to save space.)

23: @end

In addition to writing classes, you can define functionality through Objective-C categories and protocols. A category enables you to add methods to a class without subclassing or override a class’s existing methods. This means that you could, for example, add new methods to built-in classes, like NSString.

A protocol does not implement functionality, but defines what another class may or must implement to comply with the protocol. In other words, you can define a protocol that enables other classes to interface with your code, which is often done with objects like the UITable, which expects certain methods to exist in your code so as to provide it with data. For Java developers, this is similar to the idea of an interface.

@interface ClassNameToUpdate (CategoryName)
       // Declarations for new (or overridden) methods go here
@end

The implementation file follows:

@implementation ClassNameToUpdate (CategoryName)
       // Implementations of new methods go here
@end

The naming conventions for category files are the class name you want to update plus (+) the name of the category (for example, ClassNameToUpdate+CategoryName.h and ClassNameTo Update+CategoryName.m).

After you have created your category, you can import the interface file into your other classes and code away. Your application will behave as if the original class now includes the methods you wrote.

@protocol ANewProtocol <NSObject>
       @optional
               // Declarations for optional methods
       @required
               // Declarations for required methods
@end

The <NSObject> denotes the base protocol that this protocol will be based on (similar to inheriting from a class). Methods that must be implemented to conform to the protocol are found under the @required directive, and optional ones are under the @optional directive.

• Declaring variables
• Allocating and initializing objects
• Using an object’s instance methods
• Making decisions with expressions
• Branching and looping

Most commonly, you’ll be declaring several variables at the start of your methods, using them for various calculations, and then getting rid of them when you’ve finished with them.

Whatever the purpose, you declare your variables using this syntax:

<Type> <Variable Name>;

The type is either a primitive data type or the name of a class that you want to instantiate and use.

• int: Integers (whole numbers such as 1, 0, and –99)
• float: Floating-point numbers (numbers with decimal points in them)
• double: Highly precise floating-point numbers that can handle a large number of digits

For example, to declare an integer variable that will hold a user’s age, you might enter the following:

int userAge;

After a primitive data type is declared, the variable can be used for assignments and mathematical operations. The following code, for example, declares two variables, userAge and userAgeInDays, and then assigns a value to one and calculates the other:

int userAge;
int userAgeInDays;
userAge=30;
userAgeInDays=userAge*365;

Pretty easy, don’t you think? Primitive data types, however, will make up only a very small number of the variables types that you use. Most variables you declare are used to store objects.

Unfortunately for us, for a computer to work with an object, it can’t just store it like a primitive data type. Objects have associated instance variables and methods, making them far more complex. To declare a variable as an object of a specific class, we must declare the variable as a pointer to an object. A pointer references the place in memory where the object is stored, rather than a value. To declare a variable as a pointer, prefix the name of the variable with an asterisk. For example, to declare a variable of type NSString with the intention of holding a user’s name, we might type this:

NSString *userName;

Once declared, you can use the variable without the asterisk. It is only used in the declaration to identify the variable as a pointer to the object.

Even after a variable has been declared as a pointer to an object, it still isn’t ready to be used. Xcode, at this point, only knows what object you intend the variable to reference. Before the object actually exists, you must manually prepare the memory it will use and perform any initial setup required. This is handled via the processes of allocation and initialization, which we review next.

[[<class name> alloc] init];

But we can simplify that a bit by just using the new message, which does the same thing as calling alloc then init:

[<class name> new];

For example, to declare and create a new instance of the UILabel class, you could use the following code:

UILabel *myLabel;
myLabel=[UILabel new];

Once allocated and initialized, the object is ready to use.

These configuration steps are sometimes a necessary evil, but Apple’s classes often provide a special initialization method called a convenience method. These methods can be invoked to set up an object with a basic set of properties so that it can be used almost immediately.

For example, the NSURL class, which you use later to work with web addresses, defines a convenience method called initWithString.

To declare and initialize an NSURL object that points to the website http://www.teachyourselfios.com, we might type the following:

NSURL *iOSURL;
iOSURL=[[NSURL alloc] initWithString:@"http://www.teachyourselfios.com/"];

Without any additional work, we’ve allocated and initialized a URL with an actual web address in a single line of code.

For example, imagine that you are implementing a method that receives, as one of its parameters, an object of the type id named unknownObject. We know, however, that the only object that would be passed to the method is an instance of a class called anImportantClass. The id type can refer to anything, so until we tell Xcode what type of object it is, we can’t access its properties or methods.

To typecast a variable so that it is recognized as another type, place the type inside of parentheses in front of the variable:

(anImportantClass *)unknownObject

Using this, we can assign the unknownObject to a new variable of the correct type:

anImportantClass *myKnownObject=(anImportantClass *)unknownObject;

After the cast variable is assigned to an object of the correct type, we can interact with it directly as that type. We can also choose to just typecast it whenever we need it. We can even use typecasting to access properties within an object.

If the anImportantClass defined a property called anImportantProperty, we could access that by including an extra set of parentheses around the object we’re casting:

((anImportantClass *)unknownObject).anImportantProperty

This looks a bit unusual, I know, but it will come in very handy later in the book. It’s easier to understand when you see it in an actual application; so for the moment, just be aware that it is an available development tool.

[<object variable or class name> <method name>];

Things start to look a little more complicated when the method has parameters. A single parameter method call looks like this:

[<object variable> <method name>:<parameter value>];

Multiple parameters look even more bizarre:

[<object variable> <method name>:<parameter value>
                   additionalParameter:<parameter value>];

An actual example of using a multiple parameter method looks like this:

[userName compare:@"John" options:NSCaseInsensitive];

Here an object userName (presumably an NSString) uses the compare:options method to compare itself to the string "John" in a non-case-sensitive manner. The result of this particular method is a Boolean value (true or false), which could be used as part of an expression to make a decision in your application. (We review expressions and decision making next.)

In both of these cases, using the results directly avoids the need to create a variable to hold the results. Want an example that puts all of this together? We’ve got one for you.

Assume you have two NSString variables, userFirstName and userLastName, that you want to capitalize and concatenate, storing the results in another NSString called finalString. To keep this simple, we’ll assume there is already a space concatenated onto the userFirstName variable.

The NSString instance method capitalizedString returns a capitalized string, and stringByAppendingString takes a second string as a parameter and concatenates it onto the string invoking the message. Putting this together (disregarding the variable declarations), the code looks like this:

tempCapitalizedFirstName=[userFirstName capitalizedString];
tempCapitalizedSecondName=[userLastName capitalizedString];
finalString=[tempCapitalizedFirstName
                 stringByAppendingString:tempCapitalizedSecondName];

Instead of using these temporary variables, however, you could just substitute the method calls into a single combined line:

finalString=[[userFirstName capitalizedString]
                 stringByAppendingString:[userLastName capitalizedString]];

This can be a powerful way to structure your code, but it can also lead to long and rather confusing statements. Do what makes you comfortable; both approaches are equally valid and have the same outcome.

For example, imagine a personInformation object with a method called setDisplayName that would define a format for showing a person’s name. Instead of just showing the name, however, setDisplayName might use a block to let you define, programmatically, how the name should be shown:

[personInformation setDisplayName:^(NSString firstName, NSString lastName)
                {
                   // Implement code here to modify the first name and last name
                   // and display it however you want.
                }];

Interesting, isn’t it? Blocks are relatively new to iOS development and are used sparingly in this book. When you start developing motion-sensitive apps, for example, you will pass a block to a method to describe what to do when a motion occurs.

Where blocks are used, we walk through the process. To learn more about these strange and unusual creatures, read Apple’s A Short Practical Guide to Blocks in the Xcode documentation.

A simple numeric comparison checking to see whether a variable userAge is greater than 30 could be written as follows:

userAge>30

When working with objects, we need to use properties within the object and values returned from methods to create expressions. To check to see whether a string stored in an object userName is equal to "John", we could use this:

[userName compare:@"John"]

Expressions are not limited to the evaluation of a single condition. We could easily combine the previous two expressions to find a user who is over 30 and named John:

userAge>30 && [userName compare:@"John"]

As mentioned repeatedly, you’re going to be spending lots of time working with complex objects and using the methods within the objects. You cannot make direct comparisons between objects as you can with simple primitive data types. To successfully create expressions for the myriad objects you’ll be using, you must review each object’s methods and properties.

if (<expression>) {
  // do this, the expression is true.
} else {
  // the expression isn't true, do this instead!
}

For example, consider the comparison we used earlier to check a userName NSString variable to see whether its contents were set to a specific name. If we want to react to that comparison, we might write the following:

if ([userName compare:@"John"]) {
  userMessage=@"I like your name";
} else {
  userMessage=@"Your name isn't John, but I still like it!";
}

Another approach to implementing different code paths when there are potentially many different outcomes to an expression is to use a switch statement. A switch statement checks a variable for a value and then executes different blocks of code depending on the value that is found:

switch (<numeric value>) {
  case <numeric option 1>:
    // The value matches this option
    break;
  case <numeric option 2>:
    // The value matches this option
    break;
  default:
    // None of the options match the number.
}

Applying this to a situation where we might want to check a user’s age (stored in userAge) for some key milestones and then set an appropriate userMessage string if they are found, the result might look like this:

switch (userAge) {
  case 18:
    userMessage=@"Congratulations, you're an adult!";
    break;
  case 21:
    userMessage=@"Congratulations, you can drink champagne!";
    break;
  case 50:
    userMessage=@"You're half a century old!";
    break;
  default:
    userMessage=@"Sorry, there's nothing special about your age.";
}

In a count-based loop, the statements are repeated a certain number of times. In a condition-based loop, an expression determines whether a loop should occur.

The count-based loop you’ll be using is called a for loop and consists of this syntax:

for (<initialization>;<test condition>;<count update>) {
  // Do this, over and over!
}

The three “unknowns” in the for statement syntax are a statement to initialize a counter to track the number of times the loop has executed, a condition to check to see whether the loop should continue, and finally, an increment for the counter. A loop that uses the integer variable count to loop 50 times could be written as follows:

int count;
for (count=0;count<50;count=count+1) {
  // Do this, 50 times!
}

The for loop starts by setting the count variable to 0. The loop then starts and continues as long as the condition of count<50 remains true. When the loop hits the bottom curly brace (}) and starts over, the increment operation is carried out and count is increased by 1.

In a condition-based loop, the loop continues while an expression remains true. There are two variables of this loop type that you’ll encounter, while and do-while:

while (<expression>) {
  // Do this, over and over, while the expression is true!
}

and

do {
  // Do this, over and over, while the expression is true!
} while (<expression>);

The only difference between these two loops is when the expression is evaluated. In a standard while loop, the check is done at the beginning of the loop. In the do-while loop, however, the expression is evaluated at the end of every loop. In practice, this difference ensures that in a do-while loop, the code block is executed at least once; a while loop may not execute the block at all.

For example, suppose that you are asking users to input their names and you want to keep prompting them until they type John. You might format a do-while loop like this:

do {
  // Get the user's input in this part of the loop
} while (![userName compare:@"John"]);

The assumption is that the name is stored in a string object called userName. Because you wouldn’t have requested the user’s input when the loop first starts, you would use a do-while loop to put the test condition at the end. Also, the value returned by the string compare method has to been negated with the ! operator because you want to continue looping as long as the comparison of the userName to "John" isn’t true.

Loops are a very useful part of programming and, along with the decision statements, will form the basis for structuring the code within your object methods. They allow code to branch and extend beyond a linear flow.

Although an all-encompassing picture of programming is beyond the scope of this book, this should give you some sense of what to expect in the rest of the book. Let’s now close out the hour with a topic that causes quite a bit of confusion for beginning developers: memory management.

If you’ve read previous editions of this book, or even browsed online iOS source code, chances are you’ve encountered the retain and release messages (many, many times). These messages, when passed to an object, indicate that the object is needed, or is no longer being used (release).

Behind the scenes, the iOS maintains a “retain” count to determine when it can get rid of an object. For example, when an object is first allocated, the retain count is incremented. Any use of the retain message on the object also increases the count.

The release message, in contrast, decrements the count. As long as the retain count remains above 0, the object is not removed from memory. When the count reaches 0, the object is considered unused and is removed.

In your applications, you previously needed to add release code for any object you allocated. Think about that on a large scale: applications with hundreds or thousands of objects, needing to be manually retained or released. If you missed one, memory leaks and application crashes occurred! If you released an object too soon, more application crashes occurred.

Consider the earlier example of allocating an instance of NSURL:

NSURL *iOSURL;
iOSURL=[[NSURL alloc] initWithString:@"http://www.teachyourselfios.com/"];

Suppose that after you allocate and initialize the URL, you use it to load a web page. After the page loads and you’re done with the object, you must manually tell Xcode that you no longer have a need for it by writing the following:

[iOSURL release];

Thankfully, releasing and retaining objects is a thing of the past, courtesy of Automatic Reference Counting.

All new projects that you build in Xcode, including those in this book, will automatically take advantage of ARC. In fact, ARC is so good at what it does that it will not let you write applications that include release, retain, dealloc, or autorelease. So, how does this translate into your development process? Just as you would hope: You write the code you need, initialize and use objects when you want, and when they are no longer referenced by anything else, the memory they occupied is automatically freed.

For most objects you declare and use in a method, you do not need to do anything—when the method is finished, there are no more references to the object and it is automatically freed. The same goes for instance variables/properties you’ve declared with the weak attribute. Of course, it’s hyperbole to say that errors won’t happen with ARC; we have to use strong in a few places in this book to keep iOS from deciding that we have finished with an object before we actually do.

When the strong attribute has been used, you need to tell Xcode that you’re finished using an object if you want it removed from memory. How do you do that? Easy: by setting its reference to nil.

For a property named myObject, you write the following:

self.myObject=nil;

If you’ve done any Objective-C development before ARC, you’ll quickly appreciate how little time you now need to spend on memory management. If you’re new to Objective-C, just relax and enjoy!

You’ve learned quite a bit in this hour’s lesson, and there are plenty of places for even the most experienced developer to make mistakes. As with everything, practice makes perfect, and you’ll have plenty of opportunities for applying what you’ve learned in the book’s tutorials.

Keep in mind that a typical book would spend multiple chapters on these topics, so our goal has been to give you a starting point that future hours will build on, not to define everything you’ll ever need to know about Objective-C and OOP.

To learn more about Objective-C, check out Programming in Objective-C 2.0, Third Edition (Addison-Wesley Professional, 2011), Objective-C Phrasebook (Addison-Wesley Professional, 2011), and Xcode 4 Unleashed (Sams, 2012).

Of course, Apple has its own Objective-C documentation that you can access directly from within the Xcode documentation tool. (You learn more about this in the next hour.) I recommend the following documents provided by Apple:

• Learning Objective-C: A Primer
• Object-Oriented Programming with Objective-C
• Programming with Objective-C

You can read these within Xcode or via the online Apple iOS Reference Library at http://developer.apple.com/library/ios/. One quick warning: These documents are several hundred pages long, so you might want to continue your Objective-C education in parallel with the lessons in this book.

Much of the functionality that you’ll be using in your applications will come from the hundreds of built-in classes that Apple provides within iOS, which we delve into in Hour 4.

A. For the most part, yes. OS X includes thousands of additional application programming interfaces (APIs), however, and provides access to the underlying UNIX subsystem.

Q. Can an if-then-else statement be extended beyond evaluating and acting on a single expression?

A. Yes. The if-then-else statement can be extended by adding another if statement after the else:

if (<expression>) {
  // do this, the expression is true.
} else if (<expression>) {
  // the expression isn't true, do this instead.
} else {
  // Neither of the expressions are true, do this anyway!
}

You can continue expanding the statement with as many else-if statements as you need.

Q. Why are primitive data types used at all? Why aren’t there objects for everything?

A. Primitive data types take up much less memory than objects and are much easier to manipulate. Implementing a simple integer within an object would add a layer of complexity and inefficiency that just isn’t needed.

Q. Why can’t I release objects if I know I have finished using them? How can ARC do a better job?

A. ARC is built around the idea that Objective-C is very structured and predictable. By being able to analyze your code at compile time, ARC and LLVM can optimize memory management in a way that mere mortals would have a difficult time replicating.

 

 

 

2. Return to the Apple iOS Dev Center (http://developer.apple.com/library/ios) and begin reviewing the Learning Objective-C: A Primer tutorial.