As always, let us start off with a clean desktop. Then we will prepare for this first example by adding four items to our desktops to join the ever-present Macintosh HD icon: three .png image files and a text file. As shown in Figure 6-2, download these from the zip file located at http://www.rorylewis.com/xCode/006_Chapter6h_EinSwitch01.zip. Once you have downloaded the zip file, you may need to go to your Downloads folder.

Figure 6.2. Your downloaded zip file will most likely default to your Downloads folder.

After you have located the zip file, drag it onto your desktop, as shown in Figure 6-3. Double-click on the file to access the 006_Chapter_6hEinSwitch01 folder and extract the four items onto your desktop, as shown in Figures 6-3 and 6-4.

Figure 6.3. Extract 006_Chapter_6hEinSwitch01.zip from your Downloads folder and move it to your desktop.

Figure 6.4. Make a note of the four files located in the 06_Chapte_6hEinSwitch01.zip folder.

The first two items are the black and white photographs of my grandfather, alone and with his bride. As I stated in Point 2, I really want you to use these images I have supplied, for it will make the rest of the chapter flow more easily and be less distracting. One less variable to worry about!

The third item in the 006_Chapter_6hEinSwitch01.zip file is the icon image for our app, with smaller dimensions of course. Once you have all three of these images: the bottom layer - my grandfather as a bachelor (Figure 6-5), the top layer - grandpa and his bride (Figure 6-6), and the icon (Figure 6-7), save them on your desktop.

Figure 6.5. We'll use this image as the bottom layer of our switch view app.

Figure 6.6. Here is the top layer image, a smart switch!

Figure 6.7. This smaller image is for the screen icon.

The fourth item in the zip file is the SwitchViewController.txt document, which has boilerplate code that you will see again and again. In this chapter, you will be directed to copy and paste portions of this text into your code to manage certain functions. We will go over it all, and I will explain it to you at length, but, at this point in your coding journey, just save it conveniently on your desktop.

At the point when we do insert this ready-made code, we call it a Lazy Load. You can see what it looks like below ... mark this page. I will be referring back to this code in a little while–when it is time to copy and paste it.

#import "SwitchViewController.h"
#import "Ein1Controller.h"
#import "Ein2Controller.h"

@implementation SwitchViewController
@synthesize ein1Controller;
@synthesize ein2Controller;

- (void)viewDidLoad
{
Ein1Controller *ein1Controller = [[Ein1Controller alloc]

 initWithNibName:@"Einstein1View"
bundle:nil];
        self.ein1Controller = ein1Controller;
        [self.view insertSubview:ein1Controller.view atIndex:0];
        [ein1Controller release];
}

- (IBAction)switchViews:(id)sender
{
        // Lazy load - we load the Einstein2View nib the first time the button

 is pressed
        if (self.ein2Controller == nil)
        {
                Ein2Controller *ein2Controller =
                [[Ein2Controller alloc] initWithNibName:@"Einstein2View"
                                                bundle:nil];
                self.ein2Controller = ein2Controller;
                [ein2Controller release];
        }

        if (self.ein1Controller.view.superview == nil)
                //This is with no animation
        {
                [ein2Controller.view removeFromSuperview];
                [self.view insertSubview:ein1Controller.view atIndex:0];
        }
        else
        {
                [ein1Controller.view removeFromSuperview];
                [self.view insertSubview:ein2Controller.view atIndex:0];
        }
}

-(id)initWithNibName:(NSString *)nibNameOrNil
                           bundle:(NSBundle *)nibBundleOrNil {
        if (self = [super initWithNibName:nibNameOrNil
                                 bundle:nibBundleOrNil]) {

        }
        return self;
}

-(BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)

interfaceOrientation {
return (interfaceOrientation == UIInterfaceOrientationPortrait);
}

- (void)didReceiveMemoryWarning {
        [super didReceiveMemoryWarning];
        if (self.ein1Controller.view.superview == nil)
                self.ein1Controller = nil;
        else
                self.ein1Controller = nil;
}

- (void)dealloc {
        [ein2Controller release];
        [ein1Controller release];
        [super dealloc];
}

@end

Open Xcode and enter

Figure 6.8. Enter

to open a new Window-based Application.

Figure 6.9. Save your new Window-based Application as "EinSwitch01" to your desktop by entering

.

A ROAD MAP: HOW SHALL WE PROCEED?

Note

You may jump ahead to the Create the first UIViewController Subclass section and skip this slight digression. Because this is the most complex code you will have encountered so far, we will use a road map. Most students find this useful—just as we all do when it comes to large-scale projects.

Let's sit back and draw out a road map. This project is going to allow a person to switch between two views, each of which contains a photograph of my grandpa at different stages in his life. Look at Figure 6-10 to see a diagram of an analogy that I hope you will find useful. The top-level character, einSwitchAppDelegate, tells SwitchViewController when to activate. The second-level character tells the Ein#Controllers to use their .xib tools to hold up their respective photos. You can also see how we use Xcode to program einSwitchAppDelegate and SwitchViewController and then how we use Interface Builder to work with the two Ein#Controllers and the .xib files.

Figure 6.10. Here is a road map of the einSwitch001 application.

Here's a summary:

Head Honcho Delegator: Delegates work to the Switch View Controller

Switch View Controller: Tells which Controller to appear on the screen

Einstein 1 Controller: Carries the 1st photo

Einstein 2 Controller: Carries the 2nd photo

Unfortunately, we cannot use the aforementioned nomenclature. In Objective-C, as in many other computer languages, we need to use a special style of designation: camelCase. Referring to the "hump" in the middle, that's the name for the way geeky coders write compound words or phrases. The first letter is usually not capitalized, the elements are joined without spaces, and each element's initial letter is capitalized within the compound. As some of you now realize, we have already been using this nomenclature throughout the book. It's a very easy pattern, and you'll catch on immediately.

For example, if you were to write code that gets a map from a Google parser, you might call it getMapFromGoogleParser. This is a personal thing, and it's up to you ... but try to be consistent. I will typically use lower case for the first word as long as it's not a proper noun (for example, the name of a city or a person) or a Class. Using these basic guidelines, let's rename the players in our code.

In essence, follow Apple's lead in their naming of entities. In general, when making up your own names, letTheFirstLetterNotBeCapitalized! Here are the names we'll use:

einSwitchAppDelegate: Delegates work to the Switch View Controller

SwitchViewController: Tells which Assistant Controller to appear on the screen

Ein1Controller: Carries the bottom layer photo

Ein2Controller: Carries the top layer photo

Now that we've named our characters, we need to define the tools the carriers use to hold up those pictures. They will pick up and present the photographs with nib (.xib) files, which we've come to love. This is what we have then:

• einSwitchAppDelegate

  • SwitchViewController

    • Ein1Controller

    • Nib file: Einstein1ViewwxibbEin2Controller

      • Nib file: Einstein2View.xib

The last step in identifying all the files we will need is to remember that each of those files needs both a header and an implementation file, as shown in Figure 6-11. Redrawing our road map we have:

• einSwitchAppDelegate.h and einSwitchAppDelegate.m

  • SwitchViewControllerr.h and SwitchViewController.m

    • Ein1Controller.h and Ein1Controller.m

      • Einstein1View.xib

    • Ein2Controller.h and Ein2Controller.m

      • Einstein2View.xib

Figure 6.11. Each of these needs its own header (.h) file and implementation (.m) file.

Cool, huh?! Now we need to create them. Specifically, we need to create three Cocoa Touch sub-classes called SwitchViewController, Ein1Controller, and Ein2Controller, and we will also create each player's header and implementation files. Then, we need to make two nib files: Einstein1View.xib and Einstein2View.xib.

Once you have saved your window-based application as einSwitch01 to your desktop, click the Classes folder in your Groups and Files sidebar. Enter

Figure 6.12. Create the first of three Cocoa Touch UIViewController subclasses.

Figure 6.13. Save the file as "SwitchViewController.m." Remember to check the box Also Create "SwitchViewController.h."

In this chapter's other projects, we will select the With XIB for User Interface option, but right now we are going to build our nib files from scratch. Once you've done it here, you will feel good knowing what happens when you let Apple build the nib files. This way, you can always make a change and add your own bells and whistles when you want. On the other hand, if you always have this key file built for you, you won't ever get to know what's going on under the hood.

According to our road map ...

Here, we repeat what we have just done to create the second and third of the three Cocoa Touch UIViewController subclasses. We name them Ein1Controller and Ein2Controller. Remember–these two aforementioned characters are the subordinates of SwitchViewController, and they will present the photos to the user of your app. If you can do this on your own, go ahead now and try it. If not, just read along and follow me. You'll see that we're just repeating these steps again.

Once you have saved SwitchViewController, enter

Figure 6.14. Create the second of the three Cocoa Touch UIViewController subclasses.

According to our road map ...

Quickly check to see that both the header and implementation files have been created for Ein1Controller. This step may seem redundant, but often we forget to check all the appropriate boxes, such as the one to create the .h file. If I can help you get into the habit of double-checking this requirement here, you will save time in the long run. Once you proceed and write actions to one file without the other, it can be a real drag trying to recreate matching files down the road.

Also, while we are here, let's quickly review the relationship between an item's header and implementation files. Recall from Chapter 1 that all classes consist of two parts: a header (.h) file and an implementation (.m) file. Do you remember how I asked you to read aloud the following phrase? "We inform the computer in our header files about the types of commands we will have it execute in the implementation files." This is still the case, but now I'd like you to add a little phrase in front: "Each class is a product of its header (.h) and implementation (.m) files. We inform the computer in our header files about the types of commands we will have it execute in the implementation files."

First, we inform; then, we execute!

Once you have saved Ein1Controller, select

Figure 6.15. Create the third of the three Cocoa Touch UIViewController subclasses.

According to our road map ...

We created the einSwitchAppDelegate.h and einSwitchAppDelegate.m files when we created the Window-based app at the very beginning of this example. We have just finished creating the Cocoa Touch UIViewController subclasses and named them SwitchViewController, Ein1Controller, and Ein2Controller. At this point, we have created all the characters in our play, but we still need to equip some of them with the tools they will use to display the bottom and top layer photographs - i.e. our switch view images.

For this, we will create two sets of tools, .xib files, that each of our helpers will use. In the New File dialog, go to your Resources folder, give it a click, enter

Figure 6.16. Select the View XIB option to create the first of your two nib files.

Figure 6.17. Save the first of your two nib files, "Einstein1View.xib."

Before moving on through the Objective-C forest, let's take a break and see where we are:

Save Einstein2View.xib as shown in Figure 6-18, and check that your Resources folder contains both the .xib files you have created. Now, as we glance at our road map, we see that we have come a long way:

So, you're looking at this list and thinking that we've got all our characters now, and we can start to code. Right?! Hmm ... not so fast. Do you see what is missing?

Figure 6.18. Save the second of your two nib files, Einstein2View.xib.

We do indeed have all our characters and their tools, but we lack some essential materials. We need to insert three items into our Resources folder: the top and bottom layer photos, as well as the icon image.

As you did in Chapter 5, Step 7, drag your first image into the Resources folder. Make sure, as you did before, to check the "Copy items into destination's group folder (if needed)" box, as well as the "Recursively create groups for any added folders" box. Then, click Add or press Return. Similarly, drag the second image into the Resources folder, and grab the icon image while you're at it.

As some of you may not know, you can multi-select by click-dragging and boxing in all the desired items, by control-clicking (non-adjacent items), or by shift-clicking (adjacent items) the first and last items desired (in a list). See Figures 6-19 and 6-20.

Figure 6.19. Save the first of your two image files, einstein01.png.

Figure 6.20. Save the second of your two image files, einstein02.png.

As you did before, you need to associate the icon image with this project. Open up the Info.plist file in the Resources folder and double-click the Icon file Value cell. In that space, type in the name of your icon file, icon.png, as shown in Figure 6-21. Now, save your work by entering

Figure 6.21. Assign your icon file in the Information Property List: the "plist."

OK! We've created all the players, we've associated all the files, and we've associated the icon file with the program. This means only one thing my fellow geeks! We're ready to code!

Let's go back to the Classes folder, as shown in Figure 6-22, and do what we always do: open the application's delegate header file. As we do this, let's review what we now know about how the file structures are created. When Xcode instantiates our project, it creates the role that's going to delegate and preside over the other files, EinSwitch01AppDelegate (see Figure 6-11). In the instantiation process, we saw how the system creates both a header (.h) and an implementation file (.m) for our AppDelegate, and it places the program name right before the phrase AppDelegate.

To summarize, because we named our program EinSwitch01, Xcode then automatically labeled our AppDelegate file EinSwitch01AppDelegate. Furthermore, within this file, the system generated the two more specific files: EinSwitch01AppDelegate.h and EinSwitch01AppDelegate.m.

Go to your Classes folder, then, and open up your EinSwitch01AppDelegate.h file. It should look as follows:

#import <UIKit/UIKit.h>

@interface EinSwitch01AppDelegate   NSObject <UIApplicationDelegate>{
UIWindow *window;
}

@property (nonatomic, retain) IBOutlet UIWindow *window;

@end

Figure 6.22. Prepare to insert new code into the EinSwitch01AppDelegate.h file.

At this point, we could easily do what we did in the past: enter the three lines of code we want to add ... and move on in blindness. But this time, we're going to open the hood on our car and examine the engine. I am not going to overload you with too much information. I don't expect you to remember everything. My goal is to challenge you here, and to see if you can make sense of some of the details of the code.

Going back to Figure 6-10, you will notice that EinSwitch01AppDelegate communicates with and delegates work to SwitchViewController. The SwitchViewController.h file needs to have all the goodies and stuff that the SwitchViewController.m needs to have in order to tell the SwitchViewController which pawn will display its image. We provide this by adding the SwitchViewController class that we created (see Figures 6-12 and 6-13).

Recall that when we add a class, we put the @ symbol in front of it to get the computer's attention. We will insert what is called an @class precompiler directive that announces our intention to call the SwitchViewController in the implementation file. These @class compiler directives tell the compiler that a class (of whatever type we're interested in creating) will be accessible for our use. Some programmers call this a forward declaration because we're giving the compiler a head's up before the class is declared in the implementation file. Therefore, we add @class SwitchViewController right after the #import code as follows:

#import <UIKit/UIKit.h>

@class SwitchViewController;
@interface EinSwitch01AppDelegate : NSObject <UIApplicationDelegate> {
    UIWindow *window;
}

@property (nonatomic, retain) IBOutlet UIWindow *window;

@end

We now know that when we code the implementation file that corresponds with this header file, to delegate work to the SwitchViewController, it will have the ability to do so. Cool!

Next, we move to the IBOutlet for the UIWindow portion of the code: the user interface window and its associated pointer window. We need to create an IBOutlet for all of the SwitchViewController bells and whistles. Therefore, after the UIWindow *window section, add SwitchViewController *switchViewController into the code. Once this is done, we can add an @ property directive and take care of the IBOutlet:

#import <UIKit/UIKit.h>

@class SwitchViewController;

@interface EinSwitch01AppDelegate : NSObject <UIApplicationDelegate> {
        UIWindow *window;
        SwitchViewController *switchViewController;
}

@property (nonatomic, retain) IBOutlet UIWindow *window;

@end

To address the property directive line, we shall use a shortcut. Highlight and copy this entire line

@property (nonatomic, retain) IBOutlet UIWindow *window;

and then paste it below itself. Then, highlight and copy this line:

SwitchViewController *switchViewController

See Figure 6-23.

Figure 6.23. Copy your SwitchViewController *switchViewController code.

As shown in Figure 6-24, paste the

SwitchViewController *switchViewController;

code by entering (

IBOutlet UIWindow *window;

portion of the code you just inserted.

#import <UIKit/UIKit.h>

@class SwitchViewController;

@interface EinSwitch01AppDelegate : NSObject <UIApplicationDelegate> {
        UIWindow *window;
        SwitchViewController *switchViewController;
}

@property (nonatomic, retain) IBOutlet UIWindow *window;
@property (nonatomic, retain) IBOutlet SwitchViewController *switchViewController;
@end

Figure 6.24. Paste your SwitchViewController *switchViewController code.

Remember that the @property directive declares that our object has a property with a specific type, while the @synthesize directive, which we are just about to address, puts into play the methods we declared in the @property directive. Save your work on the header file and move on to the implementation file, eEinSwitch01AppDelegate.m. See Figure 6-25.

Figure 6.25. Save your header file. It's time to move onto the implementation file!

In the Classes folder, scroll down to the corresponding implementation file, EinSwitch01AppDelegate.m, and open it. As shown in Figure 6-26, you will see that it looks as follows.

#import "EinSwitch01AppDelegate.h"

@implementation EinSwitch01sAppDelegate

@synthesize window;
- (void)applicationDidFinishLaunching:(UIApplication *)application {
// Override point for customization after application launch
    [windowmakeKeyAndVisible];
}
- (void)dealloc {
    [windowrelease];
    [superdealloc];
}
@end

Figure 6.26. Open the implementation file.

As you can see, Apple has been kind enough to import the header file of the AppDelegate on which we have been working, EinSwitch01AppDelegate.h. Therefore, all the shout-outs we asked it to send this implementation file will be in here. Hmm ... let's think about this for a second.

What other shout-outs or notices do we need here? If you go back to Figure 6-10, then you may recall that EinSwitch01AppDelegate orders the SwitchViewController to tell its subordinates to do specific actions–like hold up photographs of our subject. Thus, we need to also import all the shout-outs of the SwitchViewController.h, as seen here:

#import "EinSwitch01AppDelegate.h"
#import "SwitchViewController.h"
@implementation EinSwitch01AppDelegate

@synthesize window;

- (void)applicationDidFinishLaunching:(UIApplication *)application {

    // Override point for customization after application launch
    [window makeKeyAndVisible];
}
- (void)dealloc {
    [window release];
    [super dealloc];
}
@end

Note that the following line has code that Apple automatically instantiated for us:

@implementation EinSwitch01AppDelegate

This line has been something that we have skipped over in the past, but let's consider it now. One way that we can think of this, or pronounce this, is: "In this implementation file, we hereby realize those commands and directives that were announced and defined in the EinSwitch01AppDelegate header file.

What else do we need to insert here? Recall that the @property directive, which is always located in the header file, declares that our object has a property with a specific type. In contrast, the @synthesize directive, located in the implementation file, notifies the compiler about these directives. Recall, too, that we had an @property directive

@property (nonatomic, retain) IBOutlet UIWindow *window

for the window IBOutlet. Then we added another @property directive for the SwitchViewController IBOutlet:

@property (nonatomic, retain) IBOutlet SwitchViewController *switchViewController

The @synthesize directive for the window is done for us already by Apple, but we need to add the missing element, the @synthesize directive for the switchViewController. Let's do this as illustrated in the following code:

#import "EinSwitch01AppDelegate.h"
#import "SwitchViewController.h"

@implementation EinSwitch01AppDelegate

@synthesize window, switchViewController;
- (void)applicationDidFinishLaunching:(UIApplication *)application {

    // Override point for customization after application launch
    [window makeKeyAndVisible];
}

- (void)dealloc {
    [window release];
    [super dealloc];
}

@end

Cool, huh? I hope you are beginning to see the logic behind adding these statements. Now, look at the next line:

(void)applicationDidFinishLaunching:(UIApplication *)application

and right-click on the applicationDidFinishLaunching portion. Scroll down and click on the Find Selected Text Documentation option. This will take you to a place where we have not yet ventured in this book, a wonderful little rabbit hole that leads to the Apple documentation of Xcode and Objective-C. Whatever portion of the code you do not know in the months and years to come–no problem, just check it out in the Apple documentation.

By clicking on it, we see that it states - in part - the following:

applicationDidFinishLaunching:
Tells the delegate when the application has finished launching.
- (void)applicationDidFinishLaunching:(UIApplication *)application
Parameters
application
The delegating application object.
Discussion
This method is the ideal place for the delegate to perform various initialization

 and configuration tasks, especially restoring the application to the previous state

 and setting up the initial windows and views of the application...

What this is basically saying is: "Hey, I wrote this out for you without you having to really deal with it. If you really must know, it's where your delegates perform various initialization and configuration tasks."

Right below this, inside the brackets, Apple has indeed handled the initialization and configuration of an essential task: [window makeKeyAndVisible]. This bit of code causes the UIWindow to become visible and makes it the "first responder" of touches by the user when your app is run on the iPhone/iPad.

We need something else here, though. Can you think of it? We also need to make sure that the character that the Head Honcho Delegate is ordering around, the SwitchViewController, is visible to the user. We do this by adding a subview. The code that accomplishes this is [window addSubview:switchViewController.view].

As the name suggests, this procedure adds a view to switchViewController's subviews. What's going on here is that, when switchViewController tells its subordinates to display the photographs of my grandpa, we want to add a view to a window as its subview. So, we're really asking switchViewController for the view it controls, which, when handled, displays the window to the user and enables it to accept touches and other input. Insert that line as shown here:

#import "EinSwitch01AppDelegate.h"
#import "SwitchViewController.h"

@implementation EinSwitch01AppDelegate

@synthesize window, switchViewController;

- (void)applicationDidFinishLaunching:(UIApplication *)application {

    // Override point for customization after application launch
    [window addSubview:switchViewController.view];
    [window makeKeyAndVisible];
}

- (void)dealloc {
    [window release];
    [super dealloc];
}

@end

Our last step here is to deallocate the memory of all these actors in our play. Apple knows it has to deallocate the memory of various windows, and, for safety, it also performs a "super-deallocation." Just accept it for now ... we're close to brain overload here.

We need to deallocate the memory we are using for ... what? Hmm. Have a guess. The one item to which we have been continually referring in this section? The switchViewController?

Yes. Let's do it!

#import "EinSwitch01AppDelegate.h"
#import "SwitchViewController.h"

@implementation EinSwitch01AppDelegate

@synthesize window, switchViewController;

- (void)applicationDidFinishLaunching:(UIApplication *)application {

    // Override point for customization after application launch
    [window addSubview:switchViewController.view];
    [window makeKeyAndVisible];
}

- (void)dealloc {
    [window release];
    [switchViewController release];
          [super dealloc];
}

@end

Now enter

You have taken care of the EinSwitch01AppDelegate in terms of both its header and its implementation files. Referring back to Figure 6-10, we see that we have created the code for the einSwitchAppDelegate–represented by the chess queen!

Whew - time for a break!

Continuing with our chess metaphor, you can tell yourself that you are finished working with the AppDelegate file–the queen. Now it's time to focus on her immediate subordinate, the SwitchViewController. As you know, this figure, represented by the knight, has the role of commanding either of its underlings to hold up its image. In the steps ahead, we will deal with the header (.h) file and the implementation (.m) file of the SwitchViewController.

Now we need code that tells the Ein1Controller to displays its photograph of our subject; then we can tell the Ein2Controller to display its photograph. So, scroll down in your Classes folder and open up the header file: SwitchViewController.h. We first need to make sure that the precompiler will even know who the Ein#Controllers are. See Figure 6-27. Remember that the @ symbol gets the computer's attention for the establishment of a specific relationship, and we use the @class precompiler directive to do this.

#import <UIKit/UIKit.h>
@class Ein1Controller;
@class Ein2Controller;
@interface SwitchViewController : UIViewController {

}

@end

Figure 6.27. Copy the @class precompiler directive for Ein1Controller in order to create one for Ein2Controller.

Next, we need to make sure that the implementation file will know who these Ein#Controllers are ... that they even exist. In technical terms, we say that we need to declare the instance variables that we need to use throughout the class. This is done inside the brackets, immediately following the directive @interface SwitchViewController: UIViewController.

We do this by using a pointer–yes, the asterisk, which, thus far, I've been telling you to ignore. Well, it's time to consider it. We need to tell the implementation file to reserve a place in memory for Ein1Controller and Ein2Controller, and we do this by using a pointer ... for each of the subordinate roles:

#import <UIKit/UIKit.h>
@class Ein1Controller;
@class Ein2Controller;

@interface SwitchViewController : UIViewController {
        Ein1Controller *ein1Controller;
        Ein2Controller *ein2Controller;
        }
@end

Next, we need to use the @property directive to define these variables as properties, and we do this with the same code we've used many times before:

@property (retain, nonatomic) Ein#Controller *ein#Controller

making sure to do it individually for each Ein#Controller that presents the user with a photograph of my grandfather. We do this as follows:

#import <UIKit/UIKit.h>
@class Ein1Controller;
@class Ein2Controller;

@interface SwitchViewController : UIViewController {
        Ein1Controller *ein1Controller;
        Ein2Controller *ein2Controller;
}

@property (retain, nonatomic) Ein1Controller *ein1Controller;
@property (retain, nonatomic) Ein2Controller *ein2Controller;
@end

Our next item to address is that we need an action of some type to switch views. We've called this an instance before, and we will still do so. Technically, we say: "We need an instance method (and use the "minus" sign) to advertise to the implementation file that we will be incorporating an IBAction." In other words, it will "shout out" to the implementation file that a method in your code needs to be triggered, or called into action, and that these commands will be implemented in Interface Builder.

We need to give this new action that's going to switch views a name, so let's call it ... hmm ... switchViews! Yeah! Thus, we will enter this code:

-(IBAction)switchViews:

This segment of our code, in turn, needs to point to a specific construct or role, and we use (id) for this purpose. Finally, we will need to add the "sender" component that will trigger the event.

Thus, our latest code insertion is

(IBAction)switchViews:(id)sender

By the way, remember that we generally follow up all these lines of code with a semicolon, to alert the computer that we are finished with that line.

#import <UIKit/UIKit.h>
@class Ein1Controller;

@class Ein2Controller;

@interface SwitchViewController : UIViewController {
        Ein2Controller *ein2Controller;
        Ein1Controller *ein1Controller;
}
@property (retain, nonatomic) Ein2Controller *ein2Controller;
@property (retain, nonatomic) Ein1Controller *ein1Controller;

-(IBAction)switchViews:(id)sender;
@end

As shown in Figure 6-28, it's time to enter

Figure 6.28. Once SwitchViewController.h is complete, save it, and go to the Lazy Load!

In the Classes folder, go to the SwitchViewController's implementation file, SwitchViewController.m, and click it open. When you open it, you will see all the basic code we've seen before, which Apple automatically and conveniently instantiates for us. As shown in Figure 6-29, the details of this code are invisible to the compiler because each set of classes is placed inside a comment. I think now is a good time to address the nature and function of comments–in the context of coding apps.

Figure 6.29. SwitchViewController's implementation file is loaded with code that's associated with comments.

We know that Xcode uses, and is based on, the programming language Objective-C, and that applications are run by virtue of code getting compiled into ones and zeroes that microprocessors understand. In Objective-C, as in other languages–particularly the C language it's based on, our preprocessor supports two styles of comments. These comments, in essence, make things invisible to the innards of the machine.

We have already examined and discussed the double forward slash signal: //, after which comments can be inserted–and which prohibits the compiler from seeing those comments. These are called BCPL-style comments. There is also the slash-asterisk: /* and the asterisk-slash: */, between which comments can be placed. These are known as C-style comments. For example, we might see something like this:

/* This is material that will be "invisible" to the compiler. */

Apple knows that, most of the time, we will use at least one of the classes, so it inserts comments for our convenience as follows:

#import "SwitchViewController.h"

@implementation SwitchViewController

/*
 // The designated initializer.  Override if you create the controller

programmatically and want to perform customization that is not appropriate

 for viewDidLoad.
- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil {
    if (self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil]) {
        // Custom initialization
    }
    return self;
}
*/

/*
// Implement viewDidLoad to do additional setup after loading the view, typically

 from a nib.
- (void)viewDidLoad {
    [super viewDidLoad];
}
*/

/*
// Override to allow orientations other than the default portrait orientation.
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)

interfaceOrientation {
    // Return YES for supported orientations
    return (interfaceOrientation == UIInterfaceOrientationPortrait);
}
*/

- (void)didReceiveMemoryWarning {
        // Releases the view if it doesn't have a superview.
    [super didReceiveMemoryWarning];

        // Release any cached data, images, etc that aren't in use.
}
- (void)viewDidUnload {
        // Release any retained subviews of the main view.
        // e.g. self.myOutlet = nil;
}
- (void)dealloc {
    [super dealloc];
}
@end

Going further into this brief tangent on comments would not serve us at this time. I wanted you to take a quick peek, though, so that you would have some appreciation for where and how some of the details are hidden away. I want you to realize that there are some very successful iPhone/iPad app developers out there who do not understand all the gobbledy-gook in the example above. However, a good developer does know how to utilize these comment styles when the need arises–and even how to beg, borrow, and steal other developers' work along these lines.

At the beginning of this chapter, I mentioned that we would be dumping–into the implementation file–one of the most widely used, generic, boilerplate chunks of code that loads views onto the iPhone or iPad. This method is called a Lazy Load. This process has this name for a number of reasons. First, we are somewhat lazy for using it! True enough.

Second, it's lazy in terms of memory management. This is OK for smaller programs, but as we move to creating larger applications, we will need to get more sophisticated. We will probably use Shark and other tools to fix "memory leaks," which are often caused by lazy loads. Don't worry, though! You can still create excellent (and lucrative) apps that rely on a lazy load.

Earlier in this chapter you downloaded the 006_Chapter_6hEinSwitch01.zip file. Inside this zip file, you found and copied the SwitchViewController.txt file to your desktop. Now it's time to open this file and to select all the contents by entering

Figure 6.30. Click the SwitchViewController.txt file on your desktop, click inside the window, select all by entering

, and then copy the highlighted text by entering

.

With your Lazy Load copied onto your clip board, open the implementation file, SwitchViewController.m, enter

Figure 6.31. Open the SwitchViewController.m file and paste your lazy load into it by entering

and, then immediately,

.

Guess what? You're done with the code for that particular character of our play! You can now move directly to the next step, if you like, and start connecting everything in your nib files. That would be perfectly acceptable.

You don't have to memorize it, or understand every symbol, but I do want you to come away with at least a vague understanding of how this all works. The first portion of this file is code I programmed for you, which I included in the Lazy Load. I simply imported and synthesized the two Ein#Controller.h header files as follows:

#import "SwitchViewController.h"
#import "Ein1Controller.h"
#import "Ein2Controller.h"

@implementation SwitchViewController
@synthesize ein1Controller;
@synthesize ein2Controller;

// We've done the above about 7 times already, so I figured you'd be cool

with me inserting the import
// and synthesis files for you.   The next piece of code in here is the

 (void)viewDidLoad.

- (void)viewDidLoad
{
        Ein1Controller *ein1Controller = [[Ein1Controller alloc]

        initWithNibName:@"Einstein1View" bundle:nil];
        self.ein1Controller = ein1Controller;
        [self.view insertSubview:ein1Controller.view atIndex:0];
        [ein1Controller release];
}

The - (void)viewDidLoad method, given to us by Apple, is called after the SwitchViewController view is loaded into memory. You may recall that this method, or process, is called (or activated) regardless of whether the views were stored in .xib files or created programmatically via the loadView method. Right now, give all this code a simple and friendly nod of acknowledgement. You will find yourself cutting and pasting this stuff as you do further work, and I want to help you make sure that your .xib files properly load. Moving on, the next method we view is the essence of the Lazy Load:

- (IBAction)switchViews:(id)sender
{
        // Lazy load - we load the Einstein2View nib the first time the button

 is pressed
        if (self.ein2Controller == nil)
        {
                Ein2Controller *ein2Controller =
                [[Ein2Controller alloc] initWithNibName:@"Einstein2View"
bundle:nil];
                self.ein2Controller = ein2Controller;
                [ein2Controller release];
        }

        if (self.ein1Controller.view.superview == nil)
                //This is with no animation
        {
                [ein2Controller.view removeFromSuperview];
                [self.view insertSubview:ein1Controller.view atIndex:0];
        }
        else
        {
                [ein1Controller.view removeFromSuperview];
                [self.view insertSubview:ein2Controller.view atIndex:0];
        }
}

Can you gather what is going on with this portion of the code? You can see that we first command the computer to load our second photograph and then, depending on whether the other one is loaded or not, we swap them around–according to when the user presses the button to switch views. Apple provides us with the next set of methods. These initialize the nib files, enable the screen to use certain tools (such as "auto-rotate," if the user rotates the iPhone), receive memory warnings (if the user starts to run out of memory), and deallocate memory once the user is done with the app.

// Initialization code
- (id)initWithNibName:(NSString *)nibNameOrNil
                           bundle:(NSBundle *)nibBundleOrNil {
        if (self = [super initWithNibName:nibNameOrNil
                                                           bundle:nibBundleOrNil]) {
        }
        return self;
}
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)

interfaceOrientation {
        // Return YES for supported orientations
        return (interfaceOrientation == UIInterfaceOrientationPortrait);
}
- (void)didReceiveMemoryWarning {
        [super didReceiveMemoryWarning]; // Releases the view if it doesn't

 have a superview
        // Release anything that's not essential, such as cached data
        if (self.ein1Controller.view.superview == nil)
                self.ein1Controller = nil;
        else
                self.ein1Controller = nil;
}
- (void)dealloc {
        [ein2Controller release];
        [ein1Controller release];
        [super dealloc];
}
@end

This brief overview is sufficient given your level of understanding. Meanwhile it's worth mentioning that, at a recent conference, I heard a husband and wife team, who are making about $50K/month, admit to hundreds of iPhone developers that they barely understand Apple's boilerplate implementation code. The key, as you may be gathering, is that they are clever enough to know where to paste the names of their views! For instance, do you see where I inserted Einstein1View and so forth in the (void)viewDidLoad method? Very good!

Let's go to Interface Builder and connect everything up. We're almost done!

As indicated by Figure 6-32, go to the Resources folder and open the MainWindow.xib file. As always, this will open Interface Builder.

Figure 6.32. Go to the Resources folder and open the MainWindow.xib file.

Once Interface Builder is open, go to your Library window by entering

Figure 6.33. Drag a View Controller (top left icon) into your Document window.

With the View Controller still activated (if it isn't, click on it once), have a look in the Inspector window and note that, by default, it is associated with a generic UIViewController. We really don't want that, though. We want our View Controller interacting with the code that we programmed for our own creation–a character that we have named SwitchViewController. So, click on the drop-down menu and select SwitchViewController, which will be associated with this View Controller in the Document window. Refer to Figure 6-34.

Figure 6.34. Select SwitchViewController to associate it with the View Controller in the Document window.

Scroll down to the Windows, Views & Bars folder in your Library and drag a view onto your screen as shown in Figure 6-35. We are doing this because we need views for the SwitchViews that we are generating. We could make our own buttons to switch between the different views, but we've already done this. You know how to do that. So, I thought it would be nice to use one of the pre-coded buttons that is in the Windows, Views & Bars folder. Go ahead then and drag a Toolbar onto your screen, and place it at the bottom of the workspace. Refer to Figure 6-36. We now want to give the button on the toolbar a name. Click on it, and call it Switch Views, as demonstrated in Figure 6-37.

Figure 6.35. Drag a view onto your screen.

Figure 6.36. Drag a toolbar onto your screen and place it at the bottom of the workspace.

Figure 6.37. Name the button "Switch Views."

We need to connect the mechanism inside the Switch Views button to the code we have now associated with the SwitchViewController. Control-drag from the Switch Views button downward to the Switch View Controller icon. At this point, your screen should look similar to Figure 6-38.

Figure 6.38. Control-drag from the Switch Views button downwards to the Switch View Controller icon.

Now we want to connect the Switch Views button to the appropriate option. As you drag over the Switch View Controller icon, the Sent Actions black drop-down menu opens, and you can select the switchViews option, as shown in Figure 6-39.

Figure 6.39. Connect the Switch Views button to the switchViews option.

What is going on here? Remember, back in Step 14, when we created an action that would advertise that we have a switch view? It looked like this:

-(IBAction)switchViews:(id)sender

The code we're seeing here, in the drop-down menu, is a result of that code. I have bolded it below to jog your memory.

#import <UIKit/UIKit.h>
@class Ein1Controller;
@class Ein2Controller;

@interface SwitchViewController : UIViewController {
        Ein2Controller *ein2Controller;
        Ein1Controller *ein1Controller;
}

@property (retain, nonatomic) Ein2Controller *ein2Controller;
@property (retain, nonatomic) Ein1Controller *ein1Controller;

-(IBAction)switchViews:(id)sender;

Now we have connected the SwitchViewController to the View Controller, and that is why we see the file in the drop-down menu. We connect the code that we have previously entered to the button so that, when the user presses the Switch Views button on the toolbar, it invokes and runs this code.

Now, we want to connect the Ein1Controller to the SwitchViewController. So ... start to control-drag from the Ein1Controller to the View Controller that houses your SwitchViewController.

Figure 6.40. Control-drag from the Ein1Controller to the Switch View Controller icon.

Again, as you drag your cursor over the View Controller, you will see a black drop-down menu appear with SwitchViewController in it. Connect the fishing line to it, and then let go, as shown in Figure 6-41. Now, enter

Figure 6.41. In the drop-down menu, select the SwitchViewController option.

We're almost done!

In reference to our network of characters depicted in Figure 6-10, we have everything working except for the two nib files, Einstein1View.xib and Einstein2View.xib. We have referred to these nib files as the tools that the Ein#Controllers use to hold up and display their respective photographs of my grandpa.

Let's open up Einstein1View.xib as shown in Figure 6-42. Both of these nibs are doing one thing, and one thing only, and that is holding up an image. Hence, it makes perfect sense that the first thing we do here is to drag in an Image View from the Data Views folder in our Library, as shown in Figure 6-43. We need to associate a specific image file with the Image View that we've just dragged onto the screen. As depicted in Figure 6-44, go to the property inspector and, after clicking on the pull-down menu, select einstein01.png, the image file to be associated with the Image View of the first of the two Ein#Controllers.

Figure 6.42. Begin work on the nib files by selecting the Einstein1View.xib file.

Figure 6.43. Of course, images need Image Views.

Figure 6.44. Associate the first image, einstein01.png, with the Image View.

Now, we need to address the toolbar button and make sure we assign the correct action to it. First, click the File's Owner icon as shown in Figure 6-45. Watch out here. For some reason, students forget that, before changing the label of the File's Owner icon, they need to first click on it.

Figure 6.45. Click the File's Owner icon.

Once the icon is selected, go up to the Inspector Box. Once you get to the label, choose the Label option on the black drop-down menu, as shown in Figure 6-46.

Figure 6.46. Connect the Ein1Controller to the File's Owner.

Do you recall how we entered code that directed the Ein#Controllers to use nib files to display their images? Well, we need to make clear that the guy who controls everything here, the File's Owner, is indeed Ein1Controller. Click the File's Owner icon and then associate it, via the drop-down menu in the property box, with Ein1Controller, as shown in Figure 6-46.

Now, we need to control-drag from the File's Owner icon to the View icon. When you control-drag over the View icon, a drop-down menu appears with View as an option. Point to this option and then release. See Figures 6-47 and 6-48. With this done, we have completed working on the Einstein1View.xib file. Enter

Figure 6.47. Connect the File's Owner icon with the View.

Figure 6.48. Connect the File's Owner with the View option in the View.

We need to repeat the same steps shown in Figures 6-42 thru 6-48 in order to connect the second photograph, with both my grandparents, to Ein2Controller. Begin this final series of actions by opening the Einstein2View.xib file and going back into Interface Builder, as shown in Figure 6-49.

Just as for the first image, we need an Image View to house the second photograph. So, drag it onto the screen of the Einstein2View.xib, and, as we did before, click on the File's Owner icon, and associate it with the code in the Ein2Controller. Control-drag the File's Owner icon of this second character to its View. Recall that when you control-drag over the View icon, a drop-down menu appears with View as an option. Point to this option and then release. With this done, we have completed working on the Einstein2View.xib file. Enter

Figure 6.49. Repeat the process for the second image.

You are done. Congratulations!

Enter

Figure 6.50. Click the Switch Views button.

Figure 6.51. Hooray, our app works!

Figure 6.52. We see the initial image, the bachelor, in the iPad's iPhone View.

Figure 6.53. This is the initial image in 2x mode.

Figure 6.54. Here we see the switched view, the happy couple, in the iPad mode.

Remember, we've only done the first of the three Switch Views examples!

Holy cow! You should feel good about this accomplishment.

The hardest of our three exercises is behind us! Most people never do switch views this way. They do it the no-brainer way. Boy, is this next example going to be easy for you!

So come on–let's go for the no-brainer Switch View app. Check out how easy it is compared to what you've just done.