IPhone and IPad Apps for Absolute Beginners

186 Pages·2010·10.12 MB·English

by  Lewis Rory

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.

CHAPTER 6: Switch View with Multiple Graphics
153
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:
154
CHAPTER 6: Switch View with Multiple Graphics
#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;

CHAPTER 6: Switch View with Multiple Graphics
155
@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 S to save your work. You’re done
with that file … Scooby-Dooby-Doo! Now, we move on to the implementation
file. Well done!

Figure 6–28. Once SwitchViewController.h is complete, save it, and go to the
Lazy Load!
Ready for Lazy Load—Implementation File
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.

156
CHAPTER 6: Switch View with Multiple Graphics

Figure 6–29. SwitchViewController’s implementation file is loaded with code
Figure 6–29. SwitchViewController’s implementation file is loaded with code
that’s associated with comments.
NOTE: If you are knowledgeable about comments and lazy loads, skip this
section and go to Step 16. If you're not sure, stay with us here and read on.
A Note about Comments and Lazy Loads
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:
CHAPTER 6: Switch View with Multiple Graphics
157
#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.