The model portion of your program typically includes one or more Objective-C class files that do all the necessary calculations so your program can solve a specific problem. The purpose of the model is to isolate the calculation portion of your program so it operates completely independently of the user interface. This gives you the flexibility to change the user interface without worrying about making any changes to the model portion of your program.

The controller portion of your program consists of one or more Objective-C class files, which act as a middleman in between your model and your view portion of your program. The idea is to isolate your model portion of your program from the view portion of your program (the user interface). Whenever the model needs to interact with the user interface, it sends data or requests information through the controller.

The only way the model ever communicates with the view is through a controller. This lets you replace or modify the view at any time without worrying about its effect on the model. Likewise, this also lets you modify the model at any time without worrying about its effects on the view. Any time you make a change to either the model or the view, you just have to worry about making the appropriate changes to the controller.

Essentially, the controller keeps the model and the view separate so they act more like building blocks that can be easily swapped in and out of your program.

The view portion of your program typically includes one or more .xib files that contain your user interface. In many cases, you can create a mock-up of your program's user interface and show this mock-up to potential users to get their feedback, as shown in Figure 22-1.

Figure 22-1. Designing a mock-up of a user interface can be as simple as drawing it on a piece of paper or on the computer.

A mock-up of your program's user interface lets you create a rough draft of your program without expending any effort writing an actual program. Instead, you just draw pictures, show users what the program could look like, and get their feedback on what's missing, what should be rearranged, and what should be eliminated altogether.

After potential users have examined your user interface and determined what and how it should work, you can take the next step and create that actual user interface as a .xib file using Interface Builder, as shown in Figure 22-2.

Figure 22-2. Turning a rough draft of a user interface into an actual .xib file

Although your program at this point will showonly what your program might look like, it won't actually do anything. With a mock-up of your program, you can focus on the main features of your program and how they should work.

Remember, designing your user interface can be one of the hardest parts to creating your program because if your program works perfectly but nobody likes or can understand your program's user interface, nobody will want to use your program. Since there is no scientific measurement for what makes a good user interface, consider the following tips for creating your program's user interface.

When designing a program, follow the basic conventions that users expect from a Mac program. That includes pull-down menus with familiar menu titles in the expected order (such as the File menu first followed by Edit, View, Window, and Help) along with windows and user interface elements that behave identically to other Mac programs.

Using the elements of a typical Mac user interface offers two huge benefits. First, users can immediately become familiar with the basic ways of controlling your program. As a result, they'll be more receptive to using it and will know how to find and choose commands to control your program.

Second, creating your user interface out of common Mac user interface elements also makes your job, as a programmer, much easier since Apple has already written the code needed to create common user interface elements such as windows and pull-down menus. All you have to do is connect these existing user interface elements to your program, and you can create a working program with little or no additional coding whatsoever.

Look at some of your own favorite programs and ask yourself what makes them so useful. Chances are good that for each program you like, there are probably a handful of rival programs offering the same, or maybe even more, features, so what is it about the program you use that makes it stand out?

You might like the way the program looks on the screen because the information and commands you need are thoughtfully laid out. Maybe you like the way the program guides you from one task to another, making the transition effortlessly while showing you relationships between diverse information that you may never have spotted on your own. Perhaps you like the way a program provides power features for advanced users yet remains accessible to novices.

Whatever you find useful in other programs, see whether you can adapt those designs in your own program. By doing so, you can take the best features from multiple programs and use them to create a great program that other users will rave about.

Besides looking at other programs to imitate, look at physical, real-world objects that represent tools that users might already be familiar using. For example, the Stickies program on the Mac mimics those familiar sticky notes that people use to jot down notes and stick them on desks, monitors, and chairs to remind them of something. If you're creating a program that lets users jot down ideas and notes, modeling your program after physical sticky notes can make your program easier for users to understand and use, as shown in Figure 22-3.

Figure 22-3. The Stickies program mimics sticky notes that people use in an office.

By studying existing programs and real-world tools that your program may be mimicking, you may be able to discover the optimum appearance for displaying information and allowing input for your program.

Closely adhering to conventional user interface designs like pull-down menus and resizable windows can make your program more comfortable and easier to use. However, take a moment to think how your program might need to behave in unconventional ways that actually might make your program easier and more intuitive to use.

For example, suppose your program displayed a 3D image of a piece of equipment such as a tractor or a missile. You could display pull-down menu commands that would let you rotate that image, you might display a horizontal and vertical slider that would let you rotate that image by dragging the mouse, or you could throw all conventional user interface ideas away and design your own user interface that lets the user directly manipulate the item by dragging the mouse or by tracking finger gestures on a trackpad.

By offering a specialized way of interacting with the 3D image, your program might not look and work like anything the user might have ever used before, but it could make your program more intuitive and simpler to use.

As a general rule, use standard user interface elements whenever possible, but don't be afraid to create custom interface elements. Creating such custom user interface elements will take time to design, write, and test, but the end result can be a user interface uniquely customized for your users and program.

With a rough design of your program and a clear idea what problem your program needs to solve, another step to completing your program is deciding how your program will work. First you must consider what type of data your programwill accept and manipulate to create a useful result for the user.

The type of data your program needs to store and the way it manipulates that data can determine the type of data structure you use. Choose the right data structure, and your program can be easy to write. Choose the wrong data structure, and you could wind up writing a lot of extra (and unnecessary) code to make your program work.

For example, suppose you created a simple database program for storing names. One option might be to store each name as a separate variable. Unfortunately, you may not know how many possible names someone might want to store, so you would have to create a large number of variables to store a fixed number of possible names, or you could choose a more flexible data structure such as an array, which can grow as the user adds more data.

By choosing the right data structure, you can greatly simplify the way your program works by writing less code and creating a more reliable program in the process.

Besides choosing the best data structure for your program, you must also know how to solve a particular problem step-by-step. (If you don't know how to do this, then you need to find someone who does because if no one knows how to solve a particular problem, the computer will never know how to do it either.)

The step-by-step instructions you need to solve a problem are called an algorithm. Since there might be a million different ways to solve the same problem, your goal is to find an algorithm that starts with the data a user might input into your program and then manipulates that data to achieve a specific result.

First, identify the end result. Next, identify the data that your program will start with. Now your goal is to find all the missing steps in between.

The type of algorithm you create depends on the type of data structures your program uses, so part of your algorithm will need to know how to accept data from the user, how to store data in a data structure, and how to send a new calculated result back to the user again.

One way to create an algorithm is to pick typical data that your program might accept, determine the result your program would calculate from this initial data, and then write out the steps you would need to solve that problem using a pencil and paper.

For example, suppose you wanted to implement a simple encryption algorithm known as the Caesar Cipher. The basic idea behind this cipher is to shift one letter a fixed number of places. So if you shifted all letters to the right by three places, the letter D would actually represent the letter A, the letter E would represent the letter B, and so on. Shifting all letters three places to the right would create a coded message "EDG" that would represent the actual message "BAD."

To implement such a simple letter substitution algorithm, we could start by assigning each letter a number. The number 0 would represent the letter A, the number 1 would represent the letter B, and so on. This could easily be implemented by creating an array, storing each letter in that array, and using the array index to represent each letter where the letter A would appear in the first array element, which has an index of 0, the letter B would appear in the second array element, which has an index of 1, and so on, as shown in Figure 22-5.

Figure 22-5. The index position of an array can represent each stored letter.

To encrypt a message, you need to define how many letters to shift to the right, which can be any value ranging from 1 to 25. (Shifting 0 places or 26 places essentially means that each letter represents itself, which would obviously not hide the actual message.)

To encrypt a message, the program needs two pieces of data:

To encrypt a letter, you can use this simple encryption formula:

With this formula, the variable x represents the letter to shift (where 0 represents the letter A, 1 represents the letter B, and so on), and n represents the number of places to shift.

When you know what problem you want to solve and how you can solve it, you should write out those steps to look for any flaws in your logic. Essentially the steps to solve the problem of encrypting a text string might look like this:

Encoded text = GEX

Once you've created an algorithm, go through the steps manually to verify that they work. You may know how to solve a problem, but you may not have clearly stated all of the steps needed to solve that particular problem. By forcing yourself to follow the exact steps a computer would follow, you can see if you're missing a step or if a particular step isn't working right.

Ideally, have someone else go through the steps because that person won't have all the assumptions and knowledge about the algorithm beforehand, so they'll be more likely to follow your instructions literally, which is exactly how the computer will do it too.

When you're satisfied that your instructions are both accurate and complete, the next step is to translate your algorithm into a simplified programming language called pseudocode. The purpose of pseudocode is to write instructions like a programming language but without worrying about proper syntax or commands.

Examining the previous algorithm, you could break this down into pseudocode like this:

inputText = String to encrypt.
n = number of characters to shift
lengthString = length (inputText)
for I = 1 to lengthString)
        strippedText = first letter of inputText
        remainderText = remaining characters of inputText
        letterValue = numeric equivalent (strippedText)
        encryptedText = (letterValue + n) mod 26
        cipherText = letter equivalent (encryptedText)
        encodedText = encodedText + cipherText
Print encodedText.

The goal of translating your algorithm from a wordy description into shorter, more computer-like pseudocode is to gradually translate your algorithm from English to actual Objective-C code.

When you've defined the steps to solving a problem using pseudocode, you can convert your defined steps and turn them into actual commands in any programming language. For Mac programming using Xcode, you'll be using Objective-C code. If you create a new Mac OS X Cocoa application, you can edit the AppDelegate.m file's applicationDidFinishLaunching method with the following Objective-C code:

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
    // Insert code here to initialize your application
    NSString *object1 = @"A";
    NSString *object2 = @"B";
    NSString *object3 = @"C";
    NSString *object4 = @"D";
    NSString *object5 = @"E";
    NSString *object6 = @"F";
    NSString *object7 = @"G";

NSString *object8 = @"H";
    NSString *object9 = @"I";
    NSString *object10 = @"J";
    NSString *object11 = @"K";
    NSString *object12 = @"L";
    NSString *object13 = @"M";
    NSString *object14 = @"N";
    NSString *object15 = @"O";
    NSString *object16 = @"P";
    NSString *object17 = @"Q";
    NSString *object18 = @"R";
    NSString *object19 = @"S";
    NSString *object20 = @"T";
    NSString *object21 = @"U";
    NSString *object22 = @"V";
    NSString *object23 = @"W";
    NSString *object24 = @"X";
    NSString *object25 = @"Y";
    NSString *object26 = @"Z";

    NSArray *letterArray;
    letterArray = [NSArray arrayWithObjects: object1, object2, object3, object4,
object5, object6, object7, object8, object9, object10, object11, object12, object13,
object14, object15, object16, object17, object18, object19, object20, object21,
object22, object23, object24, object25, object26, nil];

    NSString *inputText;
    inputText = @"CAT";
    int lengthString = [inputText length];

    NSMutableString *plainText; // = [[NSMutableString alloc] init];
    plainText = [NSMutableString stringWithString: inputText];

    NSMutableString *encodedText; // = [[NSMutableString alloc] init];
    encodedText = [NSMutableString stringWithString: @""];

    NSString *remainderText;
    NSString *strippedText;
    NSInteger letterValue;
    NSInteger encryptedText;
    NSString *cipherText;
    NSInteger n; //Shift
    n = 4;

    //Loop -- Strip away first character and leave remaining characters behind
    int i;
    for (i = 1; i <= lengthString; i++)
    {
        remainderText = [plainText substringFromIndex:1];
        strippedText = [plainText substringToIndex:1];

        NSLog (@"Stripped character = %@", strippedText);
        plainText = [NSMutableString stringWithString: remainderText];
        NSLog (@"Plaintext left = %@", plainText);

        letterValue = [letterArray indexOfObject: strippedText];

encryptedText = (letterValue + n) % 26;

        cipherText = [letterArray objectAtIndex: encryptedText];
        [encodedText appendString: cipherText];
        NSLog (@"Encoded text = %@", encodedText);
        NSLog (@"**********");
    }
    // End loop
}

This Objective-C code stores the letters of the alphabet into an array where the index position of each character represents its numeric value, so the letter A is located at index position 0, the letter B is located at index position 1, and so on.

This code also uses a fixed value for the input text (CAT) and the number of places to shift the characters (4). Ideally, you'll want to allow the user to input different values for the text and the number of places to shift. If you ran this code, the NSLog commands would print the following to show you how the program strips away each character of the input text and creates a new coded version of that text, converting the string CAT to GEX:

2010-12-12 16:08:33.418 Cipher[27523:a0f] Stripped character = C
2010-12-12 16:08:33.420 Cipher[27523:a0f] Plaintext left = AT
2010-12-12 16:08:33.421 Cipher[27523:a0f] Encoded text = G
2010-12-12 16:08:33.421 Cipher[27523:a0f] **********
2010-12-12 16:08:33.422 Cipher[27523:a0f] Stripped character = A
2010-12-12 16:08:33.423 Cipher[27523:a0f] Plaintext left = T
2010-12-12 16:08:33.424 Cipher[27523:a0f] Encoded text = GE
2010-12-12 16:08:33.424 Cipher[27523:a0f] **********
2010-12-12 16:08:33.425 Cipher[27523:a0f] Stripped character = T
2010-12-12 16:08:33.425 Cipher[27523:a0f] Plaintext left =
2010-12-12 16:08:33.426 Cipher[27523:a0f] Encoded text = GEX
2010-12-12 16:08:33.426 Cipher[27523:a0f] **********

For small projects, you can start creating a simple version of your program right away. However, for a large project, you may want to take one additional step and create a prototype of your program.

Just as architects often build miniature skyscrapers out of cardboard or plastic to help them visualize the final appearance of a project, so do computer programmers create a prototype of their program using a variety of tools. When you create a prototype of a program, your prototype simply shows what the program will look like and how it will behave, but your prototype isn't an actual program.

For example, you might create a rough design of your program using a presentation program like PowerPoint or Keynote where each slide represents a different part of your user interface. Clicking various commands or buttons displays a different slide, depending on how your program works.

Prototyping lets potential users see and use your program so they can provide feedback on the user interface, what features the program needs, and what features may need to be changed or eliminated altogether.

Other prototyping tools might include simple drawing and paint programs or web page–designing programs that let you create a series of web pages that represent different appearances of your working program. You could even create a prototype of your program by simply drawing pictures on different sheets of paper.

The goal of a prototype is to create the appearance and behavior of your program without forcing you to spend a lot of time creating that prototype so it doesn't matter how you create your prototype. This lets you freely modify and change the prototype until it behaves and looks exactly the way you want. After you've finalized the design of your program by creating a prototype, then you'll be ready to create your actual program.

You're not going to write your entire program in one try. Instead, you'll gradually create a program and add more features one by one until you finally create the program you initially envisioned. Think of creating a program like shaping a clay sculpture. You would never take a chunk of clay, throw it on a table, and expect it to be perfect right away. Instead, you'd take that lump of clay and gradually shape it into the form you want. You might add a little extra clay here, remove a chunk of clay there, and move clay to one spot and slap it on a different spot.

In the same way that you'd create a work of art by starting with a lump of clay and gradually shaping it into your final design, so will you gradually create your program a little bit at a time. Testing your program doesn't mean waiting until the whole thing is complete. Instead, testing means you create a little bit of your program, test to make sure that the little bit you added works as expected, and then add another little bit to your program and test how that newly added portion of your program works.

Each time you add a new portion to your program, you'll need to test that new portion to make sure it works correctly and then test how that new portion interacts with the rest of your program.

When writing your program, divide your program into specialized parts and reusable parts. A specialized part of your program might perform unique calculations, such as a stock market prediction program that uses an algorithm to analyze stock price data and calculate which stocks will likely rise in the near future.

A reusable part of your program might be the part of your program that retrieves data from the Internet, such as stock market data. Retrieving data from the Internet might be handy to use in another program, such as one that needs to retrieve updated weather reports from the Internet. By clearly dividing your program into specialized and reusable, general portions, you can gradually create a library of your general-purpose code so you can plug each bit into future programs, allowing you to create new programs quickly, easily, and reliably.

By building your program slowly and testing each newly added feature along the way, you can catch problems as they occur and fix them before you rush ahead and create the entire program and wind up spending all your time tracking down and fixing bugs in your software.

The first goal of your program is to get it to work. Once you've gotten one part of your program to work, you can see what needs to be fixed or modified. Maybe your program doesn't look the way you wanted, so you might need to change the user interface. Maybe the program runs too slowly. Then you might need to use a different data structure or create a better algorithm.

The more testing you can do, the better, so you can spot problems with your program before releasing it to your customers and users. (Fixing a bug-ridden program after you've sold or distributed it to people is rarely the quickest way to make others happy or look favorably at your programming abilities.)

When you've created a workable program with the majority of its features available, you might start testing your program with other people so they can give you feedback on what they like, what they didn't like, and what changes you should make. At this point, you can choose to make those changes (or ignore them if you have a good reason for doing so), and then after you modify your program, you can repeat the whole testing cycle all over again.

Repeat several times, and you'll gradually create a working program that you can give away or sell to others. The whole process of designing, creating, and testing a program can be frustrating, fun, tiresome, and challenging all at the same time.

The more programs you create, the more confident you'll get and the more experience you'll have to avoid problems and take shortcuts to simplify your program. Like any skill, designing, writing, and testing a program may seem hard and confusing at first, but after enough practice, you'll soon find that it's not as difficult as you might have initially thought.