Becoming a Great  iPhone/iPad or Mac
Programmer

Now that you’re ready to become a software developer and have read the Introduction
of this book, you need to become familiar with some key concepts. Your computer
program will do exactly what you tell it to do, no more and no less. It will follow the
programming rules that were defined by the operating system and programming
language. Your program doesn’t care if you are having a bad day or how many times
you ask it to perform something. Your program will do whatever you tell it to do. Often,
what you think you’ve told your program to do and what it actually does are to different
things.

NOTE: If you haven’t already, take a few minutes to read the Introduction to this book. You will
better understand why we are using the Alice programming language and how to be successful
in developing your iPhone/iPad and Mac apps.

Depending on your background, working with something absolutely black and white
may be frustrating. Many times, programming students have lamented, “That’s not what
I wanted it to do!” As you begin to gain experience and confidence programming, you’ll
begin to think like a programmer. You will understand software design and logic, and
you will experience having your programs perform exactly as you tell them to do as
enormously satisfying.

Thinking Like a Developer

 Software development involves writing a computer program and then having the

computer execute the program. A computer program is the set of instructions that we

want the computer to perform. Before we begin to write a computer program, it is
helpful to list the steps that we want our program to perform, in the order we want them
accomplished. This step-by-step process is called an algorithm.
If we want to write a computer program to toast a piece of bread, we would first write an
algorithm. This algorithm might look something like this:

1. Take the bread out of the bag.
2. Place the bread in the toaster.
3. Press the toast button.
4. Wait for the toast to pop up.
5. Remove the toast from the toaster.
At first glance, this algorithm seems to solve our problem. However, our algorithm leaves
out many details and makes many assumptions, for example:
1. What kind of toast does our user want? Does the user want white bread, wheat,
or some other kind of bread?
2. How does the user want the bread toasted, light or dark?
3. What does the user want on the bread after it is toasted: butter, margarine, honey,
or strawberry jam?
4. Maybe the user wanted another kind of toast, like French toast or garlic toast,
which is prepared by means other than a toaster.
5. Does this algorithm work for all your users in their cultures and languages?
Now, you might be thinking we are getting too detailed for just doing a simple toast
program. Over the years, software development has the reputation of taking too long,
costing too much, and not being what the user wants. This reputation came to be
because computer programmers often start writing their programs before they have
really thought through their algorithms.
The key ingredients to making successful applications starts with design requirements.
Design requirements can be very formal and detailed or a simple list on a piece of paper.
The importance of design requirements is they help the developer flesh out what the
application should do and not do when complete. Design requirements should not be
completed in a programmer’s vacuum but should be a collaboration between
developers, users, and customers.

NOTE: If you take anything away from this chapter, take away the importance of considering
design requirements and user interface design before starting software development. This is the
most effective (and cheapest) use of time in the software development cycle. Using a pencil and
eraser is a lot easier and faster than making changes to code because you didn’t have others
look at the designs before starting to program.
Another key ingredient to your successful app is the user interface (UI) design. Apple
recommends that you spend over 50% of the entire development process focusing on
the UI design. The design can be simple pencil-and-paper layouts created using the
iPhone Application Sketch Book by Dean Kaplan (Apress, 2009) or on-screen layout
created with the Omni Group’s OmniGraffle software application with the Ultimate
iPhone Stencil plug-in. Many software developers start with the UI design, and after
laying out all the screen elements and having many users look at paper mock-ups, they
then write out the design requirements from their screen layouts.
Once you have done your best to flesh out all the design requirements, laid out all the
user interface screens, and had the client(s) or potential customers look at your design
and give you feedback, coding can begin. Once coding begins, design requirements
and user interface screens can change, but the changes are typically minor and easily
accommodated by the development process. See Figures 1–1 and 1–2.

Figure 1–1. This is a UI mock-up of the Account Balance screen for an iPhone mobile banking app before
development begins. This UI design mock-up was completed using OmniGraffle.

Figure 1–2. This screenshot shows a completed iPhone mobile banking application as it appeared on the iTunes
App Store. This app is called Woodforest Mobile Banking.

Completing the Development Cycle

Now that we have our design requirements and user interface designs and have written
our program, what’s next? After programming, we need to make sure our program
matches the design requirements and user interface design and that there are no errors.
In programming vernacular, errors are called bugs. Bugs are undesired results of our
programming and must be fixed before released to the App Store. The process of
finding bugs in our programs and making sure the program meets the design
requirements is called testing. Typically, someone who is experienced in software
testing methodology and who didn’t write the app performs this testing. Software testing
is commonly referred to as Quality Assurance (QA). Figure 1–3 shows the complete
software development cycle.
NOTE: When an application is ready to be submitted to the iTunes App Store, Xcode gives the file
an .app extension, for example, appName.app. That is why iPhone, iPad, and Mac applications
are called apps. We will use “program,” “application,” and “app” to mean the same thing
throughout this book.
During the testing phase, the developer will need to work with QA staff to determine why
the application is not working as designed. The process is called debugging. It requires  the developer to step through the program to find out why the application is not working

as designed. Figure 1–3 shows the complete software development cycle.

 

 

 

 

 

 

Figure 1–3. The typical software development cycle

 

 

Frequently during testing and debugging, changes to the requirements (design) need to
occur to make the application more usable for the customer. Once the design
requirements and user interface changes are made, the process begins over again.
At some point, the application that everyone has been working so hard on must be
shipped to the iTunes App Store. Lots of considerations are taken into account when
this happens:

1.Cost of development

2.Competition

3.Stability of the application

4.Return on investment

There is always the give-and-take between developers and management. Developers
want the app perfect, and management wants to start realizing revenue from the
investment as soon as possible. If the release were left up to the developers, the app
would never ship to the App Store. Developers would continue to tweak the app forever,
making it faster, more efficient, and more usable. At some point, however, the code
needs to be pried from the developers’ hands and shipped to the user, so it can do what
it was meant to do.

Introducing Object Oriented Programming

As discussed in detail in the Introduction to this book, Alice enables us to focus on
object oriented programming (OOP) without having to cover all the Objective-C
programming syntax and complex Xcode development environment in one big step.
Instead, we can focus on learning the basic principles of OOP and using those principles
quickly to write our first programs.
For decades, developers have been trying to figure out a better way to develop code
that was reusable, manageable, and easily maintained over the life of a project. OOP
was designed to help achieve code reuse and maintainability while reducing the cost of
software development.
OOP can be viewed as a collection of objects in a program. Actions are performed on
these objects to accomplish the design requirements.
An object is anything that can be acted on. For example, an airplane, person, or
screen/view on the iPad can all be objects. We may want to act on the plane by making
the plane bank. We may want the person to walk or to change the color of the screen of
an app on the iPad. Actions are all being applied to these objects; see Figure 1–4.

 

 

Figure 1–4. These are two objects in an Alice application, a plane and aircraft carrier. Both objects can have
actions applied—take off and landing for the plane and “turn to port” and “ahead flank” for the aircraft carrier.

Like the play button in Alice, the Xcode integrated development environment (IDE)
enables us to run our application from within our programming environment See Figure
1–5.

Figure 1–5. This sample iPhone app contains UITableView objects. Actions such as “rotate left” or “user did
select row 3” can be applied to this object.

Actions that are performed on objects are called methods. Methods manipulate objects
to accomplish what we want our app to do. For example, for our jet object in Figure 1–4,
we might have the following methods:
goUp
goDown
bankLeft
turnOnAfterBurners
lowerLandingGear
For our iPhone application’s UITableView object in Figure 1–5, we could have the
following methods:
loadView
shouldAutorotateToInterfaceOrientation
numberOfSectionsInTableView
cellForRowAtIndexPath
didSelectRowAtIndexPath
All objects have data that describes those objects. Our properties hold values that
describe the state of the objects. This data is defined as properties. Each property
describes the associated object in a specific way. For example, the jet object’s
properties might be as follows:
altitude = 10,000 feet
heading = North
speed = 500 knots

pitch = 10 degrees
yaw = 20 degrees
latitude = 33.575776
longitude = -111.875766
For our UITableView object in Figure 1–5, these might be our properties:
backGroundColor = Red
selectedRow = 3
animateView = No
An object’s properties can be changed at any time as our program is running, as the
user interacts with the app, or as the programmer designs the app to accomplish the
design requirements. The values stored in the properties of an object at a specific time
are collectively called the state of an object.
State is an important concept in computer programming. When teaching students about
state, Gary asks them to go over to a window and find an airplane in the sky. He then
asks them to snap their figures and make up some of the values that the plane’s
property might have at that specific time. Those values might be
altitude = 10,000 feet
latitude = 33.575776
longitude = -111.875766
Those values represent the state of the object at the specific time that they snapped
their fingers.
After waiting a couple of minutes, Gary asks the students to find that same plane, snap
their fingers again, and record the plane’s possible state at that specific point in time.
The values of the properties might then be something like this:
altitude = 10,500 feet
latitude = 33.575665
longitude = -111.875777
Notice how the state of the object changes over time.

Working with the Alice Interface

Alice offers a great approach in using the concepts that we have just discussed without
all the complexity of learning Xcode and the Objective-C language at the same time. It
just takes a few minutes to familiarize yourself with the Alice interface and begin writing
a program.
The Introduction of this book describes how to download Alice. Once it’s downloaded,
you need to open Alice. See Figure 1–6

Figure 1–6. It is worth your time to click on the Tutorial tab to familiarize yourself with the Alice application and
user interface. Additionally, there are several great examples on the Examples tab.

Alice has great tutorials and examples that are highly recommended for developers to
work through, like the one shown in Figure 1–7.

Figure 1–7. An Alice tutorial describing the user interface

Technically speaking, Alice is not a true IDE like Xcode, but it is pretty close and a whole
lot easier to learn than Xcode. A true IDE combines code development, user interface
layout, debugging tools, documentation and simulator/console launching for a single
application; see Figure 1–8. However, Alice offers similar look, feel, and features to
Xcode. This will serve you well later when we start writing Objective-C code.

Figure 1–8. The Xcode integrated development environment (IDE)) with the iPad Simulator

In the next chapter, we will go through the Alice interface and write our first program.

Summary

Congratulations, you have finished the first chapter of this book. It is important that you
have an understanding of the following terms, because they will be reinforced
throughout this book:

1.Computer program

2.Algorithm

3.Design requirements

4.User interface

5.Bug

6.Quality assurance (QA)

7.Debugging

8.Object oriented programming (OOP)

9.Object

10.Property

11.Method

12.State of an object

13.Integrated development environment (IDE)
í¯€3.3

   Objective C1
   Objective C2
   Objective C3
   Making Decisions About?ˆ¦and Planning Program Flow
   Object Oriented Programming with Objective-C
   Introducing Objective-C and Xcode
   Objective-C Classes, Objects, and Methods
   Programming Basics in Objective-C
   Comparing Data
   Creating User Interfaces with Interface Builder
   Memory, Addresses, and Pointers
   Debugging Programs with Xcode
   Storing Information
   Protocols and Delegates