Hour 3

Discovering Swift and the iOS Playground

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: Swift.

Swift provides the syntax and structure for creating applications on Apple platforms. Swift is a brand-new language developed internally in Apple that still has that “new language smell,” but also a few disconcerting knocks under the hood. It can seem a bit daunting at first, but after a few hours of practice, you’ll begin to feel right at home. This hour takes you through the steps you need to know to be comfortable with Swift 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 Swift 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 single Swift 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 this 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, by default, available within the class they are defined and within other classes defined in the same project.
• Extensions: Provide a means of extending a class without modifying the class code itself.
• Type method: Similar to an instance method, but applicable to all the objects created from a class. The reminder class, for example, might implement a type 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 or a class method.
• Variable property: A storage place for a piece of information specific to a class. The name of a reminder, for example, might be stored in a variable property. All variables have a specific “type” that describes the contents of what they will be holding. Variable properties only differ from normal variables in where they are defined and where they can be accessed.
• Variable: A storage location for a piece of information. Unlike variable properties, a “normal” variable is accessible only in the method where it is defined.
• Constant: A Swift constant is another type of variable, but one that cannot be modified after it has been declared.
• Parameter: A piece of information that is provided to a method when it is use. If you were to use a setAlarm method, you would presumably need to include the time to set. The time, in this case, would be a parameter.
• 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 variable property is used in an application, it should 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 variable properties, you can self to refer to the object. In Swift, self is usually implied and only needs to be used explicitly in very specific circumstances.

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.

Released in 2014, Swift carries with it many of the niceties of Objective-C, but loses much of the baggage. The biggest issue with Swift is that it is still evolving, and developers (including yours truly) are still trying to figure out the best way to use it. It will be several years before this churn settles down—but, in the meantime, the core of Swift is fast, flexible, and easy to learn.

Swift statements are easier to read than other programming languages and can often be deciphered just by looking at them. For example, code that checks to see if two dates are equal might be written like this:

if myBirthday.isEqualToDate(yourBirthday) {
    // We're the same age!
}

It doesn’t take a very large mental leap to see what is going on in the code snippet. Throughout the book, I will try to explain what each line of code is doing—but chances are you can pick up on the intention just by reading the lines.

Now that you have an idea of what OOP and Swift 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 an entirely made-up class file in Listing 3.1.

LISTING 3.1 A Sample Interface File

 1: import UIKit
 2:
 3: class myClass: myParent, myProtocol {
 4:
 5:     var myString: String = ""
 6:     var myOtherString: String?
 7:     var yetAnotherVariable: Float!
 8:     let myAge: Int = 29
 9:
10:     @IBOutlet weak var userOutput: UILabel!
11:     @IBOutlet var anotherUserOutput: UILabel!
12:
13:     class func myTypeMethod(aString: String) -> String {
14:         // Implement a Type method here
15:     }
16:
17:     func myInstanceMethod(myString: String, myURL: NSURL) -> NSDate? {
18:         // Implement the Instance method here
19:     }
20:
21:     override func myOverriddenInstanceMethod() {
22:         // Override the parent's method here
23:     }
24:
25:     @IBAction func myActionMethod(sender: AnyObject) {
26:         // React to an action in the user interface
27:     }
28:
29: }

First, in line 1, the interface file uses the import declaration to include any other files that our application will need to access. The string UIKit designates a system framework that gives us access to a vast majority of the classes.

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: class myClass: myParent, myProtocol {

Notice that line 3 includes a few additional items as well: that is, myParent, myProtocol. The class name (myClass) is always followed by a colon (:) and a list of the classes that this class is inheriting from (that is, the parent classes) and any protocols it will be implementing. In this example, myClass is going to by inheriting from myParent and will be implementing the myProtocol protocol.

The class line ends with an opening curly brace {. All blocks of code are contained in curly braces. The rest of the class code will follow this brace and eventually by terminated with a closing brace } (line 29).

5:     var myString: String = ""
6:     var myOtherString: String?
7:     var yetAnotherVariable: Float!

In this example, a variable named myString that contains a String is declared and initialized with an empty string (""). A second String (myOtherString) is also declared, but designated as “optional” with the ? modifier. A third variable property, yetAnotherVariable, is declared as a floating-point number and set to be “implicitly unwrapped” by including the ! modifier. We’ll get to the point of these modifiers in a little bit. (They look confusing, but they have an important role to play.)

8:     let myAge: Int = 29

This creates a constant (myAge) and sets it to the integer value 29. Constants declared alongside variable properties (that is, outside of a method) are nearly identical to variable properties in how they are used—but with one important difference—they can’t be changed or reassigned. In other words, I’m 29 forever.

10:     @IBOutlet weak var userOutput: UILabel!
11:     @IBOutlet var anotherUserOutput: UILabel!

You learn more about IBOutlet in Hour 5, “Exploring Interface Builder.”

13:     class func myTypeMethod(aString: String) -> String {
14:         // Implement a Type method here
15:     }
16:
17:     func myInstanceMethod(myString: String, myURL: NSURL) -> NSDate? {
18:         // Implement the Instance method here
19:     }
20:
21:     override func myOverriddenInstanceMethod() {
22:         // Override the parent's method here
23:     }
24:
25:     @IBAction func myActionMethod(sender: AnyObject) {
26:         // React to an action in the user interface
27:     }

Method declarations follow a simple structure. They begin with the word func, but can include the prefix modifiers class and override. A method that begins with class func is a Type method (often also referred to as a Class method). A method starting with override func is one that is redefining a method already provided in a parent class. This indicates that rather than inheriting functionality from a higher class, we’re going to write our own logic.

In the example file, line 13 defines a Type method named myTypeMethod that returns a String and accepts a String 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 optional NSDate object, taking a String and an NSURL as parameters. These are made available to the code in the method via the variables myString and myURL. I’ll rant about what optional values are and how to deal with them later in the hour. For the moment, just understand that by saying this method has an optional return type, it may return an NSDate object, or nothing (nil).

Line 21 declares an instance method, myOverriddenInstanceMethod, that takes no parameters and returns no results. What makes this interesting is that it uses the keyword override to indicate that it will be replacing a method provided by the parent class (myParent). When you start defining methods in your classes, Xcode knows what methods are inherited, so the moment you go to define a method provided by a parent class, it will automatically add the override keyword for you.

The fourth instance method, myActionMethod, declared in line 25 differs from the others because it defines an action, as indicated by the @IBAction keyword. Methods that begin with @IBAction are called when the user touches a button, presses a switch, or otherwise interacts with your application’s user interface (UI). These methods take a single parameter, usually denoted as sender that is set to whatever object the user interacted with. Just as with the @IBOutlet mentioned earlier, you’ll be learning much more about IBAction in Hour 5.

29: }

Although this might seem like quite a bit to digest, it covers almost everything you’ll see in a Swift class file.

• Declaring variables and constants
• Understanding built-in swift data types
• Making sense of optional values
• Initializing objects
• Using an object’s instance methods
• Making decisions with expressions
• Branching and looping

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

var <Variable Name>[: Variable Type][Optional modifier][ = Initialization]

Holy cow—that looks complicated! In practice, nearly everything but the var keyword and the variable name are optional. I make a point of always trying to provide the variable type, but if you don’t, Swift will try to figure it out for you. The type is either a Swift data type or the name of a class that you want to instantiate and use.

Let’s begin by taking a look at a few Swift data types and how they are declared and used.

• 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.
• String: Collections of characters (numbers, letters, and symbols). Throughout this book, you’ll often use strings to collect user input and to create and format user output.
• Bool: A Boolean value (that is, true or false), often used to evaluate conditions within your code.
• Arrays: A collection of ordered values that are accessed via a numeric index.
• Dictionaries: A collection of key/value pairs. A given value is accessed by providing its key.

var userAge: Int

If you wanted, you could even initialize it with a value, all in the same line:

var userAge: Int = 30

After a variable is declared, it can be used for assignments and mathematical operations. The following code, for example, declares two variables, userAge and userAgeInDays, and uses the first (an age in years) to calculate the second (the age in days):

var userAge: Int = 30
var userAgeInDays: Int
userAgeInDays = userAge * 365

Notice that for the userAgeInDays, I declare it, then use it later. You’re welcome to do this, or declare and initialize the variables on the exact same line.

Floating-point numbers work the same way—you declare them, then use them. A simple example to calculate the circumference of a circle (circumference = diameter * 3.141), for example, could be written like this:

var diameter: Float = 2.5
var circumference: Float = diameter * 3.141

Pretty easy, don’t you think? Swift data types have much more to offer as well. Let’s see what else they can do!

var myName: String = "John"

Here, a string (myName) is initialized to the value "John". Once initialized, the string can be manipulated using a number of techniques. String concatenation (adding two or more strings together) is performed with the addition (+) operator. To change myName to include my last name, I’d write the following:

myName = myName + " Ray"

You can even use a process called string interpolation to combine existing Strings, values returned by methods, and other Swift data types into a new String. Consider this line:

var sentence: String = "Your name is \(myName) and you are \(userAge) years old"

Here I’ve combined the myName string and userAge integer into a single string, assigned to a new variable named sentence. Any time Swift encounters the pattern \(<variable or method name>) in your code, it takes the result, turns it into a string, and substitutes it in place of the pattern. You can use this to quickly format strings based on other variables and methods.

In many languages, strings require special functions to check for equality. In Swift, the same comparison operators you’d use to compare two numbers also work for strings. We’ll look at comparisons a bit later.

var myFlag: Bool = false

You might, for instance, want to create an array that contains all the user feedback strings you want to display in an application:

var userMessages: [String] = ["Good job!", "Bad Job", "Mediocre Job"]

Notice that the word Array doesn’t even appear in the declaration and initialization? That’s because all we need to do to declare an array is wrap the type we want to store (in this case, String values) in square brackets. If I wanted an array of integers, I’d use a type of [Int] and so on. The initialization values are provided as a comma-separated list enclosed in square brackets; if you use [] alone, the array is initialized as empty.

To access the strings in the userMessages array, you use an index value. This is the number that represents a position in the list, starting with 0. To return the "Bad job" message, we use the number 1 (the second item in the list):

userMessages[1]

You can also use the index to assign values to an array, replacing what is currently stored:

userMessages[1]="Try again"

Swift lets you add new items to the end of the list using the array’s append method. For example, to add a new message (“Meh”) to the end of userMessages, I might write the following:

userMessages.append("Meh")

There are several other means of accessing and modifying arrays that we’ll use over the course of the next 21 hours.

var userMessages: [String:String] =
       ["positive":"Good job!", "negative":"Bad Job", "indifferent":"Mediocre Job"]

Similar to declaring the strings, I declare the dictionary without ever using the word dictionary. Instead, I provide the type data types that will form the keys and values within square brackets—for example, [<key data type>:<value data type>]. For the userMessage dictionary, I’m using keys that are strings, and values that are strings. The initialization is similar to an array, but consists of the key, a colon (:), and then the value. Each key/value pair is separated by a comma. Empty dictionaries can be created with the initializer [:].

To access a value in the dictionary, I index into userMessages just like an array, but using the key rather than an integer. To access the “Bad Job” message (tied to the “negative” key), I could type the following:

userMessages["negative"]

Keys can also be used to modify or assign new values. Here the key “apathy” is assigned the value “Meh”:

userMessages["apathy"] = "Meh"

Dictionaries are useful because they let you store and access data in abstract ways rather than in a strict numeric order.

Objects are declared and initialized just like Swift data types. For example, to declare and create a new instance of the UILabel class, you could use the following code:

var myLabel: UILabel = UILabel()

Here, the initializer is UILabel(). This returns a new, ready-to-use instance of the UILabel class. You can initialize all classes using this same syntax <class name>(), but most will require additional setup after initialization. To speed things along, many will provide convenience methods. Convenience methods speed the process of creating a new object by taking the basic parameters needed to create and configure the object, all at once.

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 configuration 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. We can use it to create a brand-new NSURL object, complete with the URL, just by typing the following:

var iOSURL: NSURL = NSURL(string: "http://www.teachyourselfios.com/")!

This is where we (briefly) go off the tracks. Notice that nowhere in that line does initWithString appear. The initWithString method is the name of a convenience method in Objective-C. The method still goes by the same name when used in Swift, but it takes on a simplified form.

The general rule of thumb is that, in Swift, the initWith is removed from the name of convenience method. Whatever remains of the name becomes the first named parameter of the method. A named parameter, as you’ll learn a bit later, is a parameter that requires you to spell out its name in the method call (in this case, string).

Because Xcode supports autocompletion, it is usually pretty easy to start typing in a method named and find it in the list that appears. Just keep in mind that what you see in the Xcode documentation doesn’t necessarily apply to both Objective-C and Swift.

CGFloat(myFloat)

Swift does everything it can to silently bridge these older data types with the new built-in Swift types—and it is usually very successful. Unfortunately, sometimes this manual conversion will have to happen.

Another common circumstance is when a method returns an object of one type when it needs to be another. When this happens, you must type cast the result.

For example, the NSDate class includes several methods that return a date, but instead of being of the type NSDate, they are of the type AnyObject. The NSDate type method distantPast is one of these methods:

var myPastDate: NSDate = NSDate.distantPast() as NSDate

Because distantPast() results in an object of the type AnyObject, we must “tell” Xcode that it is really an NSDate by adding as NSDate to the end of the assigment. Using the syntax as <class name> after any object will attempt to type cast that object as being of whatever class you name.

After a variable is cast to an object of the correct type, we can interact with it directly as that type. This looks a bit unusual, I know, but it will come in 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.

let lastName: String = "Ray"

The key difference between a constant and a variable is that constants, once assigned, cannot be changed or reassigned. This, however, isn’t as limiting as you might think. When you assign an object to a constant, you can access and modify all the variable properties in that object, execute all its methods, and so on. It can still be used just like any other variable—you just can’t reassign it later.

Constants are more efficient than variables and should be used in their place wherever possible. I think you’ll be surprised to find that we use more constants in our applications than actual variables.

In Swift, Apple decided that developers should acknowledge when they’re using a value that might not contain what they expect. The result requires interesting additions to the development process:

1. Method, variable, and constant declarations should state when they may not have, or may not return, a value. These are known as optional values.

2. Why would a method programmed to return a result ever make that result optional? If the method has bad input, or otherwise can’t complete the operation it is tasked with performing, it makes perfect sense to return “nothing”—represented in Swift using the keyword nil.

3. When attempting to access methods or variables that are optional, developers must unwrap the values. This means that the developer acknowledges that he or she knows what is in a variable (or returned by a method), and wants to access and use the results.

Now, you might think to yourself, “Hey, I know what I’m doing, I’m not going to write any code where I name a variable or method return type as optional! That would just be extra work!” You’re right, it is extra work—but it’s utterly unavoidable.

All the code that makes up the Cocoa Touch classes is being updated by Apple to denote which variable properties and methods return optional values—and there are many (and the list is growing). I could tell you stories about the number of times I’ve opened a project while writing this book, only to find that Apple has changed a class somewhere that breaks the code I’ve written. That’s one of the difficulties of being an early technology adopter.

Okay, enough ranting. What does all of this actually mean in terms of coding?

var myOptionalString: NSString? = "John"

This also means that if the string isn’t immediately initialized, it automatically contains the value nil.

For method definitions, you denote an optional return value by adding ? after the return type. In the sample class in Listing 3.1, I defined the method as having an optional return value of NSDate using this syntax in the declaration:

func myInstanceMethod(myString: String, myURL: NSURL) -> NSDate? {

In other words, each time I wanted to use the value in myOptionalString, I would reference it as follows:

myOptionalString!

The same goes for the myInstanceMethod method. To use it, I might write a line like this:

var myReturnedDate: NSDate = myInstanceMethod("A cool string", myURL: iOSURL)!

The addition of the ! tells Xcode that we want to access the return value and that we don’t care if it is nil. We can take this a step further by defining what is called an implicitly unwrapped optional. This is just an optional value that will always be unwrapped automatically when we use it.

To create an implicitly unwrapped variable, you add a ! after the type name. For example, I could write the preceding line of code using an implicitly unwrapped variable, like this:

var myReturnedDate: NSDate! = myInstanceMethod("A cool string", myURL: iOSURL)

This declares myReturnedDate as an optional NSDate variable, but one that will be implicitly unwrapped. I can assign it the result of an optional method without unwrapping the return value of the method (because both are optional). However, when I go to use myReturnedDate elsewhere in my code, it will automatically be unwrapped for me—just as if I had put the ! after it each time.

You really won’t be doing this very often, but Xcode is going to do it a lot when it writes code for you. Why? Because every interface object that connects to your code will be referenced through an implicitly unwrapped variable. An interface object may be nil before it is loaded, so it has to be optional; but once your code is active, it should always have a value, and there’s no point in hindering its use—thus, it is implicitly unwrapped for you.

Applying optional binding to the myOptionalString variable, I might write this simple logic to test to see whether an optional value should be used:

if let stringValue:String = myOptionalString {
    // myOptionalString has a non-nil value.
}

This is a good approach for working with optionals in production-ready code. It gives you an opportunity to react to situations where optionals are set to nil and errors may have arisen. If you unwrap an optional and try to work with it even if it is nil, you may crash your code.

For most of the examples in the book, I manually unwrap values with ! because the code is simple and we know how the different components are going to interact. In apps bound for the App Store, I recommend using optional binding to trap for error conditions that you may not have anticipated.

<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 or class name>.<method name>([parameter:]<parameter value>)

Earlier I noted that convenience initialization methods will usually include at least one named parameter, such as string when initializing an NSURL object:

var iOSURL: NSURL = NSURL(string: "http://www.teachyourselfios.com/")!

This is important to note because the style of using an initial named parameter is only really used in convenience initialization methods. In other (general use) methods, the first parameter is just provided as a value.

For example, let’s look at a method that takes multiple parameters:

var myFullName: String = "John Ray"
var myDescription: String =
myFullName.stringByReplacingOccurrencesOfString(myFullName, withString: "is awesome!")

This code fragment stores my name in the myFullName variable, then uses the stringByReplacingOccurrencesOfString:withString method to change my last name from “Ray” to “is awesome!”

In this example, the first parameter to the stringByReplacingOccurrencesOfString:with-String method has no name; I just put in the value (myFullName). The second parameter does have a name (withString:), which must be provided along with the value.

The syntax for multiple parameter method calls looks like this:

<object variable or class name>.<method name>([parameter:]<parameter value>,
     <parameter>:<parameter value>, <parameter>:<parameter value> ...)

Chaining results directly eliminates the need for temporary variables and can make code shorter and easier to maintain.

For example, consider this completely contrived code:

var myString: String = "JoHN ray"
myString = myString.lowercaseString
myString = myString.stringByReplacingOccurrencesOfString("john", withString: "will")
myString = myString.capitalizedString

Here I’ve created a string (myString) that holds my name with very very poor capitalization. I decide that I want to replace my first name (John) with my brother’s name (Will). Because I cannot just search and replace on John because my capitalization is all messy and I don’t want to try to remember how I wrote my name (this is contrived folks), I decide to first convert myString to lowercase by accessing the lowercaseString variable property. Once complete, I can just search for john and replace it with will without worrying about capitalization. Unfortunately, that means I still need a properly capitalized version of the string when I’m done. So, I access the capitalizedString variable property of my string when finished, and use its value for myString. (In case you’re wondering, capitalizedString provides a copy of the string with all of the first letters capitalized.)

The code should make sense, even if my logic is a bit shaky. That said, each of the methods and variable properties I’ve used return a string. Instead of assigning things over and over, I can chain each of these actions together into a single line:

var myString: String = "JoHN ray".lowercaseString.stringByReplacingOccurrencesOfString("john", withString: "will").capitalizedString

Chaining can be a powerful way to structure your code, but when overused it may lead to lines that can be difficult to parse. 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 closure to let you define, programmatically, how the name should be shown:

personInformation.setDisplayName({(firstName: String, lastName: String) in
                   // Implement code here to modify the first name and last name
                   // and display it however you want.
                })

Interesting, isn’t it? Closures are relatively new to iOS development and are used throughout this book. You’ll first encounter closures when writing alerts. The closure will provide the instructions that are executed when a person acts on an alert.

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 variable properties within the object and values returned from methods to create expressions. If I have stored an NSDate object with my birthday in it (myBirthday), I could check to see whether the current day is my birthday with the expression:

myBirthday.isEqualToDate(NSDate())

Expressions are not limited to the evaluation of a single condition. We could easily combine the previous two expressions to find a person who is over 30 and is celebrating their birthday today:

userAge > 30 && myBirthday.isEqualToDate(NSDate())

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 data types. To successfully create expressions for the myriad objects you’ll be using, you must review each object’s methods and variable 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 myBirthday NSDate variable to see whether it was equal to the current date. If we want to react to that comparison, we might write the following:

if myBirthday.isEqualToDate(NSDate()) {
    let myMessage: String = "Happy Birthday!"
} else {
    let myMessage: String = "Sorry, it's not your birthday."
}

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 (<some value>) {
  case <value option 1>:
    // The value matches this option
  case <value option 2>:
    // The value matches this option
  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:
        let userMessage: String = "Congratulations, you're an adult!"
    case 21:
        let userMessage: String = "Congratulations, you can drink champagne!"
    case 50:
        let userMessage: String = "You're half a century old!"
    default:
        let userMessage: String = "Sorry, there's nothing special about your age."
}

The for loop you’ll encounter most often 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 variable 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:

for var 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.

for loops can also iterate over collections using the following syntax:

for  <variable> in <collection> {
  // Do this for each value in the collection, where <variable> contains the value
}

Consider the array of messages we created earlier in the hour:

var userMessages: [String] = ["Good job!", "Bad Job", "Mediocre Job"]

To loop over this array of messages, we can write a “for in” loop as follows:

for message in userMessages {
    // The message variable now holds an individual message
}

The same applies to dictionaries as well, but the syntax changes just a little bit. If userMessages is defined as a dictionary:

var userMessages: [String:String] =
       ["positive":"Good job!", "negative":"Bad Job", "indifferent":"Mediocre Job"]

We can loop over each key/value pair like this:

for (key, value) in userMessages {
    // The key and value variables hold an individual dictionary entry
}

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 != "John"

The assumption is that the name is stored in a string 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.

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.

In the latest Xcode releases, Apple has implemented a new compiler called LLVM, along with a feature known as Automatic Reference Counting (ARC). ARC uses a powerful code analyzer to look at how your objects are allocated and used, and then it automatically retains and releases them as needed. When nothing is referencing an object, ARC ensures it is automatically removed from memory. No more retain or release messages to be sent, no more phantom crashes and memory leaks; you just code and it works.

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 variable 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 references in a few places in this book to keep iOS from deciding that we have finished with an object before we actually do.

When using a variable property that has a strong reference, you should 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 example, assume we’ve created a giant object called myMemoryHog:

var myMemoryHog: SomeHugeObject? = SomeHugeObject()

To tell Xcode when we’re done using the object and let it free up the memory, we would type the following:

myMemoryHog = nil

Once the huge object isn’t directly reference by any variables, it can be removed from memory, and all will be well with the world.

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, which is why our final topic focuses on a tool that makes practicing Swift fun.

When Apple introduced Swift in Xcode 6, they realized that developers would need a way to get their feet wet (or hands dirty, if you prefer) without all the steps of creating new iOS applications. Heck, why would you want to try building an application if you aren’t sure you’re even going to be writing code that works? Therefore, the iOS Playground was born. The Playground gives you an area to type in experimental code and see the result—immediately—without even pressing a Run button.

To create a new Playground, choose File, New, Playground from the Xcode menu, as shown in Figure 3.2.

When prompted, provide a name for the playground and make sure that the platform is set to iOS, as demonstrated in Figure 3.3. The name can be anything you’d like. Unlike a project, a Playground creates a single file, so it’s easy to rename later. Click Next to continue.

Finally, choose where the Playground will be saved, and then click Create. After a few seconds, the Playground window opens, as shown in Figure 3.4.

So, what do you do now? You play. Any code that you enter is immediately evaluated and the results appear in the margin on the right.

For example, remember the calculation of a person’s age in days? Try typing this code into the playground:

var userAge: Int = 30
var userAgeInDays: Int
userAgeInDays = userAge * 365

As you type the lines, watch what happens in the margin on the right. For the first statement, declaring userAge, you’ll see 30 appear in the margin because the variable contains the value 30. The second line won’t generate any output because it doesn’t contain anything yet. The third line, however, calculates and stores the age in days, which is displayed in the margin (10,950, if you’re interested). You can see this in Figure 3.5.

Add these lines to the end of the code in the Playground:

for var count = 0; count < 50; count++ {
    println("Count is \(count)")
}

Shortly after typing the lines, you’ll see a value in the margin quickly count to 50. This is a count of the number of times the println statement was executed. What you don’t see, however, is the output that is generated.

To view the output, position your cursor over the line that reads “(50 times).” You’ll notice two icons appear; the first (an outline of an eye) is the Quick Look icon and lets you inspect some variable contents more closely. (We’ll do this in the next hour.) The second icon, a circle, opens the assistant editor and displays a value history for that item, as well as any output that was generated.

Go ahead and click the circle by the println statement. The assistant editor displays the output from the println statement, as well as a draggable timeline at the bottom. If your code has values that change over time, you can drag the timeline to inspect their value at an arbitrary point in time. These controls are visible in Figure 3.6.

The beauty of the Playground is that you can do anything you want. Go back and try some of the Swift syntax discussed in this hour. Try comparing dates, test a few loops and switch statements... whatever you want.

We’ll be using the Playground often to explore new code concepts, even making it do a few things that might surprise you. I recommend using it now to gain experience writing Swift.

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

Apple has also published a book (The Swift Programming Language) that covers the entirety of the Swift language, including Playground exercises. It is available directly with the iBook store on your Mac or iOS device. This isn’t just recommended reading; it’s a required download for any serious developer-to-be.

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 Swift and OOP.

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 is the Playground better than coding up a new project? Seems the same to me.

A. The biggest advantage of the iOS Playground is that it lets you see instant feedback from the code you enter. In addition, you don’t even have to add output statements to inspect the contents of variables you declare; they appear automatically in the Playground margin.

Quiz