Here's how the sequence went with the Old School generic controller:

As I said at the end of Chapter 1 of this minibook, this implementation of the WebViewController is predicated on Trip being able to identify the content object that owned the content that needed to be displayed. In the case of the content in Book V, this wasn't an issue because for any given choice of content (car information, car servicing information, or the weather) there was indeed only one possible object that was associated with a user choice. For example, if the user chose Car Information, there was only one CarInformation object for Trip to get the NSURLRequest from. But in the case of Sight, that isn't true. How does Trip know which Sight object to send a message to?

You may remember from Chapter 1 that, although I'd like to include that information as a selector argument, the performSelectorOnMain Thread::: method can't return a value and can only take either a single argument of type id or no arguments at all. Unfortunately, as you saw in Step 3 in the preceding section, you're already using your single argument allowance to send a reference to the WebViewController that is used to send it the loadWebView: message. (The bolded code in the following block is the smoking gun here.)

[trip performSelectorOnMainThread:tripSelector
   withObject:self waitUntilDone:NO];

-(void) returnWeather:(id) theViewController {

[theViewController loadWebView:[weather weatherRealtime]];

}

Although it isn't very PC to say this, there are other ways to skin a cat.

One way is to have the SightListController set some kind of index in Trip to let it know which Sight object in the sights array the user has requested information about. Although this would work, you're starting down a slippery slope of tighter coupling between the Trip, SightListController, and the sights array. We would, after all, like all of our objects to be as ignorant as possible of how other objects work. That makes changing things much easier.

A better alternative is to use a pattern that the framework uses when faced with a similar problem.

After all, the challenge you face here is one that is faced by the framework on a regular basis. For example, when you start up an application, the framework wants to give you the opportunity to do some application-specific initialization. But because its code was probably written before your application was a gleam in your eye, it has no idea that your application even exists.

The solution to that is to have you create an application delegate that implements the ApplicationDidFinishLoading method. At start up, the UIApplication object's delegate instance variable is assigned a reference to your app delegate object — if you have implemented it. (I show you later how the application object knows that fact.) The UIApplication object then sends your app delegate the ApplicationDidFinishLoading message.

You can use the same technique here. I show you how to make the Weather, CarInformation, CarServicing, and all of the Sight objects I've come up with so far delegates of the WebViewController and then change just a few things so that instead of sending the performSelectorOnMain Thread::: message to the Trip object, it sends a similar request to its delegate instead.

I start with more about delegation.

To help you recognize a delegate method, Apple has implemented some naming conventions that it uses in the framework

You declare formal protocols with the @protocol directive. To have your WebViewController require that its delegates implement a WebView Controller:nsurlRequestProcessMethod: method, you would code the following:

@protocol WebViewControllerDelegate <NSObject>

- (void) webViewController:
         (WebViewController *) controller
         nsurlRequestProcessMethod:(SEL)theProcessMethod;

@end

Methods can be optional or required. If you don't mark a method as optional, it is assumed to be required; but you can make that designation specific via the use of the @required keyword.

In the WebViewControllerDelegate protocol I just declared, I have a required method — WebViewController:nsurlRequestProcessMethod:

The more formal representation is

@protocol ProtocolName

method declarations

@end

Generally, protocol declarations are in the file of the class that defines it. In this case, you will add the WebViewControllerDelegate protocol declaration to the WebViewController.h file.

To implement delegation in WebViewController, start by adding the code in bold to WebViewController.h. You'll also have to add the code in bold that has been commented out and then delete the code in bold that has been formatted with a strikethrough in Listing 2-6.

This business about deleting the bolded stuff with strikethrough and adding the unstruck bolded stuff will be the general operating procedure for the rest of this chapter (and minibook), so I won't bore you by repeating these instructions over and over and over.

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

@interface WebViewController : UIViewController
   <UIWebViewDelegate> {

// SEL                    tripSelector;
    id                    delegate;
    Trip                 *trip;
    IBOutlet UIWebView   *webView;
    BOOL                  webControl;
  }
  - (void)loadWebView:(NSURLRequest*) theNSURLRequest;
 //- (id) initWithTrip:(Trip*)aTrip tripSelector:(SEL)
     aTripSelector webControl:(BOOL) ifWebControl
     title:(NSString*) aTitle;
  - (id) initWithTrip:(Trip*)aTrip  delegate:(id) theDelegate
     webControl:(BOOL) ifWebControl title:(NSString*) aTitle;

  @end

  @protocol WebViewControllerDelegate <NSObject>
  - (void) webViewController:(WebViewController*)
                                                controller
           nsurlRequestProcessMethod:(SEL)theProcessMethod;

  @end

You did several things here:

With the changes you have made to WebViewController, you'll have to make some changes in the RootViewController code that allocates and initializes it.

More specifically, make the following changes to the RootViewController's tableView:didSelectRowAtIndexPath: method, as shown in Listing 2-7.

switch (menuOffset) {
      case 0:
        if (realtime) targetController = [[MapController
                                alloc] initWithTrip:trip];
        else [self displayOfflineAlert:
             [[menuList objectAtIndex:menuOffset]
                                objectForKey:kSelectKey]];
        break;
      case 1:
        targetController = [[SightListController alloc]
                                       initWithTrip:trip];
        break;
      case 2:
  //     targetController =
              [[HotelController alloc] initWithTrip:trip];
        break;
      case 3:
//    if  (realtime) targetController =
            [[WebViewController alloc] initWithTrip:trip
            tripSelector:@selector(returnWeather:)
 //         webControl:YES title:
               NSLocalizedString(@"Weather", @"Weather")];
       if  (realtime) targetController =
         [[WebViewController alloc] initWithTrip:trip
          delegate:[ trip returnWeatherDelegate]
          webControl:YES title:
          NSLocalizedString(@"Weather", @"Weather")];
       else [self displayOfflineAlert:
            [[menuList objectAtIndex:menuOffset]
                               objectForKey:kSelectKey]];
       break;
     case 4:
//     targetController = [[WebViewController alloc]
         initWithTrip:trip tripSelector:@selector
         (returnCarServicingInformation:)
//       webControl:NO title: NSLocalizedString
                   (@"Car Servicing", @"Car Servicing")];
       targetController =
        [[WebViewController alloc] initWithTrip:trip
          delegate: [trip returnCarServicingDelegate]
          webControl:NO title:NSLocalizedString
                  (@"Car Servicing", @"Car Servicing")];
       break;
     case 5:
//     targetController = [[WebViewController alloc]
          initWithTrip:trip tripSelector:@selector
          (returnCarInformation:)
//        webControl:NO title:NSLocalizedString
                       (@"The Car", @"Car Information")];

targetController = [[WebViewController alloc]
            initWithTrip:trip
            delegate: [trip returnCarInformationDelegate]
            webControl:NO title:NSLocalizedString
                       (@"The Car", @"Car Information")];
    break;
}

The change you made here was simply to initialize WebViewController with the right delegate, depending on what the user selected in the table view. You changed it from using a selector as an argument to using its delegate instead.

The only involvement now by Trip is to pass back the delegate for each of the selections.

Of course, you'll also need to change the initialization method in the WebViewController. Make the changes shown in Listing 2-8 to WebViewController.m.

//- (id) initWithTrip:(Trip*)aTrip tripSelector:(SEL)
   aTripSelector webControl:(BOOL) ifWebControl
   title:(NSString*) aTitle {
- (id) initWithTrip:(Trip*)aTrip delegate:(id) theDelegate
   webControl:(BOOL) ifWebControl title:(NSString*) aTitle{

  if (self = [super initWithNibName:@"WebViewController"
   bundle:nil]) {
    self.title = aTitle;
//    tripSelector = aTripSelector;
    delegate = theDelegate;
    trip = aTrip;
    webControl = ifWebControl;
    [trip retain];
  }
  return self;
}

All you've done here is eliminate the tripSelector assignment and replace it with the delegate assignment instead.

You also need to make some changes in viewDidLoad, as shown in Listing 2-9. You'll be sending the delegate a message instead of performing the selector. Make these changes to WebViewController.m.

- (void)viewDidLoad {

  [super viewDidLoad];
  if (webControl) {
    UIBarButtonItem *backButton = [[UIBarButtonItem alloc]
                                   initWithTitle:@"Back" styl
    e:UIBarButtonItemStylePlain
                                   target:self action:@
    selector(goBack:)];
     self.navigationItem.rightBarButtonItem = backButton;
     [backButton release];
  }
  // [trip performSelectorOnMainThread:tripSelector
   withObject:self waitUntilDone:NO];
  [delegate webViewController:self
       nsurlRequestProcessMethod:@selector(loadWebView:)];
}

Again, this change is very straightforward. You've changed the method so that it now simply sends a message to its delegate to construct the NSURLRequest. You'll see in a second that this will essentially set off a chain of events — similar in end result, but very different in execution — to the chain of events I described at the beginning of this chapter.

One further note here.

Because the delegate method WebViewController:nsurlRequestProc essMethod: is required by the WebViewControllerDelegate protocol, you really don't have to be concerned if it's implemented. If it were optional though, as many of the framework delegate methods are, you would need to know whether the delegate implemented the method.

To do that, you can use the respondsToSelector: message:

if ([delegate respondsToSelector: @selector
       (webViewController:nsurlRequestProcessMethod:)]) {
  ... do something
}

respondsToSelector: is an NSObject method that tells you whether a method has been implemented. As I said, because this particular method is required, I don't have to determine that. However, I wanted to show you how much information is available at runtime in Objective-C and how to implement delegation for the optional methods of formal protocols and for all methods of informal protocols.

Adopting a protocol is similar in some ways to declaring a superclass. In both cases, you're adding methods to your class. When you use a superclass, you're adding inherited methods; when you use a protocol, you're adding methods declared in the protocol list. A class adopts a formal protocol by listing the protocol within angle brackets after the superclass name.

@interface ClassName : ItsSuperclass < protocol list >

A class can adopt more than one protocol, and if so, names in the protocol list are separated by commas.

@interface Translator : NSObject < English, Italian >

Just as with any other class, you can add instance variables, properties, and even nonprotocol methods to a class that adopts a protocol.

In this case, the model classes will be adopting the WebViewControllerDelegate protocol.

Add the code in Listing 2-10 to the Sight.h. I show you how this works with the Sight class because it was the cause of the problems in the first place. Later, I have you apply it to the rest of the classes that will need to use it — CarInformation, CarServicing, and Weather.

#import <MapKit/MapKit.h>
  #import "WebViewController.h"
  @class Trip;
  @class ServerManager;
  @interface Sight : NSObject <WebViewControllerDelegate> {

    NSString               *sightName;
    CLLocationCoordinate2D  coordinate;
    NSString               *title;
    NSString               *subtitle;
    NSString               *resource;
    NSString               *resourceType;
    NSString               *image;
    NSString               *imageType;
    Trip                   *trip;
    ServerManager          *sightServerManager;
    NSMutableData          *receivedData;
    SEL                     processMethod;
    UIViewController       *viewController;
  }

@property (nonatomic, retain) NSString *sightName;
@property (nonatomic, retain) NSString* image;
@property (nonatomic, retain) NSString* imageType;;
@property (nonatomic) CLLocationCoordinate2D coordinate;
- (NSString*) title;
- (NSString*) subtitle;
- (id) initWithTrip: (Trip*) the Trip
                      sightData:(NSDictionary*) sightData;

@end

As you can see, besides adopting the WebViewControllerDelegate protocol, there are a few new instance variables you need to add — I explain them in the next chapter.

Now, add the code in Listing 2-11 to Sight.m to implement the protocol method.

- (void) webViewController:
                          (WebViewController *) controller
         nsurlRequestProcessMethod:(SEL)theProcessMethod {

  viewController = controller;
  processMethod = theProcessMethod;
  RoadTripAppDelegate *appDelegate = (RoadTripAppDelegate *)
   [[UIApplication sharedApplication] delegate];
  BOOL realtime = !appDelegate.useStoredData;
  if (realtime) {
    NSString* urlString = [[NSString alloc] initWithFormat:
   @"%@%@.%@", @"http://nealgoldstein.com/", resource,
   resourceType];
    [self downloadData: urlString];
  }
  else {
    [self get Data];
  }
}

Before I explain what is going on here, I want to discuss a little more about protocols.

When you adopt a protocol, you must implement all the required methods the protocol declares; otherwise, the compiler issues a warning. As you can see, the Sight class does define all the required methods declared in the WebViewControllerDelegate protocol.

As you noticed, though, the file access looks very different from what you're used to. That's because I have a second problem to deal with: the issue of file loading. That's what I explain starting in the next section