• Choose a category
• All
• Classic-Fiction

GameConnectionMessageSessionId,

GameConnectionMessageData,

GameConnectionMessageCustom

} GameConnectionMessageType;

@protocol GameConnectionDelegate

@optional

- (void) receiveMessage:(NSString*)message

ofType:(GameConnectionMessageType)messageType;

@end

@interface GameConnection: NSObject {

id _delegate;

}

@property(nonatomic,assign) id /**/ delegate;

- (void) connectWithPlayerName: (NSString*)playerName;

- (void) connectWithSessionId:(NSString*)sessionId;

- (void) sendMessage:(NSString*)message

asType:(GameConnectionMessageType)messageType;

+ (GameConnection*) createWithName:(NSString*)gameConnectionClassName delegate:(id)gameConnectionDelegate;

@end

There is very little in the implementation of this interface. This class defines how a game connection should send and receive messages in a common fashion. Now the implementation can be deferred to overloading classes. This gives you the ability to extend your application by adding new implementations of the GameConnection class. Each implementation can introduce a new type of connection without changing the actual code for the Game View.

This class can also create the overloading class by passing in the name of the game connection class you want to create to the method createWithName: delegate:. Here are the details of this powerful method:

+ (GameConnection*) createWithName:(NSString*)gameConnectionClassName

delegate:(id)gameConnectionDelegate {

id obj = [[NSClassFromString(gameConnectionClassName) alloc] init];

if (obj == nil) {

[NSException raise:@”Invalid game connection class name” format:

@”The game connection class ‘%@' was not found and cannot be created”,

gameConnectionClassName];

}

GameConnection *gameConnection = (GameConnection*)obj;

gameConnection.delegate = gameConnectionDelegate;

return gameConnection;

}

This method uses NSClassFromString to instantiate a GameConnection class from its name. If the class cannot be constructed, the method throws an exception. This method is very nice because now the class GameConnection can be completely oblivious to the implementation of any other GameConnection derivative classes.

Examining the details

Now that you have an understanding of how to separate your connection concerns, you can look at the details of this example that differ from the applications you have reviewed up until now. There are a lot of details to this application, but most should be quite familiar to you by now. You can download the full application source to the completed version (Figure 8.13) of Amuck-Tac-Toe from http://appsamuckcom/amktactoe.

FIGURE 8.13

Amuck-Tac-Toe is an example of a multiplayer turn-based game.

Here are a few items that you may not be familiar with:

Displaying data in a UITableView

Calling Web services using NSURLConnection

Receiving notifications from Apple Push Notification

These items are fairly straightforward to grasp, and they add a tremendous amount of power to your application. We will start by examining the table view.

Presenting options with a table view

Even though we have not covered it, you should be familiar with the appearance of a table view. The UITableView is a very common element in iPhone development. You see it in many of the native apps, such as Settings, Contacts, and Phone. The UITableView is an ideal choice for you to use in your game menus, as shown in Figure 8.14.

In most cases, the UITableView works in close relation to a UINavigationBar. Together these two components create the slide in and out navigation you have become accustomed to on the iPhone. To create this effect, you need to implement the UITableViewDelegate method and push and pop view controllers to the navigation stack. The following listing comes from the main menu screen of Amuck-Tac-Toe, which does just that.

The method viewDidLoad is used to set up a background color that is tiled. This is done