转自朋友Tommy 的翻译，自己只翻译了第三篇教程。
译者: Tommy | 原文作者: Matthijs Hollemans写于2012/07/06
原文地址: http://www.raywenderlich.com/12865/how-to-make-a-simple-playing-card-game-with-multiplayer-and-bluetooth-part-2
这篇文章是由iOS教程团队成员Matthijs Hollemans发表的，一个经验丰富的开发工程师和设计师。你可以在Google+和Twitter上找到他。
欢迎回到使用UIKit通过蓝牙或者Wi-Fi制作多人卡片游戏系列教程。
如果你之前没有接触过本系列教程，请先看这里。这里你可以看到这个游戏的一些视频，接下来将邀请你进入本系列教程的学习。
在第一篇教程，你创建了主菜单和基本的Host Game and Join Game界面。
你已经创建了一个能散播消息的server和能够侦测server的client，但是到目前为止，很明显还有些功能仅仅是在Xcode的输出窗口中打印些log而已。
在第二部分中，也就是本篇教程，你将在屏幕上展示出一些可用的server和一些能够相连的client，并且完成卡片的配对。开始吧!
开始：将server展示给用户
MatchmakingClient类有一个_availabelServers变量，一个NSMutableArray数组，这些是为了储存client侦测到的server的。当GKSession侦测到一个新的server时，你就把这个server的peer ID加到这个数组中。
你怎么能知道什么时候有新的server呢？MatchmakingClient是GKSession的Delegate，你可以用它的delegate方法 session:peer:didChangeState: 来侦测server。用下面的方法替换MatchmakingClient.m中的那个方法:
- (void)session:(GKSession *)session peer:(NSString *)peerID didChangeState:(GKPeerConnectionState)state
{
#ifdef DEBUG
NSLog(@"MatchmakingClient: peer %@ changed state %d", peerID, state);
#endif
switch (state)
{
// The client has discovered a new server.
case GKPeerStateAvailable:
if (![_availableServers containsObject:peerID])
{
[_availableServers addObject:peerID];
[self.delegate matchmakingClient:self serverBecameAvailable:peerID];
}
break;
// The client sees that a server goes away.
case GKPeerStateUnavailable:
if ([_availableServers containsObject:peerID])
{
[_availableServers removeObject:peerID];
[self.delegate matchmakingClient:self serverBecameUnavailable:peerID];
}
break;
case GKPeerStateConnected:
break;
case GKPeerStateDisconnected:
break;
case GKPeerStateConnecting:
break;
}
}
最新发现的server是通过peerID这个参数来标示的。这是一个类似@"663723729"，包含一些数组的一些字符串。对于标示server，这些数字是非常重要的。
第三个参数"state"，告诉你peer当前的状态。一般情况下，只有在状态转变为GKPeerStateAvailable和GKPeerStateUnavailable的时候，我们才处理。正如你从状态的名字中看到的那样，这些状态预示着新的server被发现或者一个server断开了连接（有可能是用户退出游戏或者是他玩游戏时走神儿了）。是把这个它的peer ID加到_availabelServers列表中，还是从列表中删除，视情况而定。
现在还不能编译，因为它还要通知它的delegate，这是个还没有定义的属性。MatchmakingClient通过delegate方法让JoinViewController知道有新的server可用了（或者server变的不可用）。将下面的代码添加到MatchmakingClient.h文件的上方：
@class MatchmakingClient;
@protocol MatchmakingClientDelegate <NSObject>
- (void)matchmakingClient:(MatchmakingClient *)client serverBecameAvailable:(NSString *)peerID;
- (void)matchmakingClient:(MatchmakingClient *)client serverBecameUnavailable:(NSString *)peerID;
@end
将下面这个新属性添加到@interface：
@property (nonatomic, weak) id <MatchmakingClientDelegate> delegate;
在.m文件中完成synthesize:
@synthesize delegate = _delegate;
现在JoinViewController要变成MatchmakingClient的delegate了，所以将这个protocol添加到JoinViewController.h文件中的@interface一行:
@interface JoinViewController : UIViewController <UITableViewDataSource, UITableViewDelegate, UITextFieldDelegate, MatchmakingClientDelegate>
在JoinViewController.m中的viewDidAppear方法中，当MatchmakingClient对象创建后添加如下一行代码：
_matchmakingClient.delegate = self;
最后，实现delegate的方法：
#pragma mark - MatchmakingClientDelegate
- (void)matchmakingClient:(MatchmakingClient *)client serverBecameAvailable:(NSString *)peerID
{
[self.tableView reloadData];
}
- (void)matchmakingClient:(MatchmakingClient *)client serverBecameUnavailable:(NSString *)peerID
{
[self.tableView reloadData];
}
上面只是告诉tableview去重新加载，这就以为着你还要在加载的data source方法里去处理新数据，使得tableview能够显示新数据。
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
if (_matchmakingClient != nil)
return [_matchmakingClient availableServerCount];
else
return 0;
}
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
static NSString *CellIdentifier = @"CellIdentifier";
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
if (cell == nil)
cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier];
NSString *peerID = [_matchmakingClient peerIDForAvailableServerAtIndex:indexPath.row];
cell.textLabel.text = [_matchmakingClient displayNameForPeerID:peerID];
return cell;
}
这只是一些基本的tableview代码。你只是简单的告诉MatchmakingClient，tableview中的那些行应该重新显示，我们还需要一些新的辅助方法，将下面的方法声明添加到MatchmakingClient.h文件中：
- (NSUInteger)availableServerCount;
- (NSString *)peerIDForAvailableServerAtIndex:(NSUInteger)index;
- (NSString *)displayNameForPeerID:(NSString *)peerID;
添加它们的实现到MatchmakingClient.m中：
- (NSUInteger)availableServerCount
{
return [_availableServers count];
}
- (NSString *)peerIDForAvailableServerAtIndex:(NSUInteger)index
{
return [_availableServers objectAtIndex:index];
}
- (NSString *)displayNameForPeerID:(NSString *)peerID
{
return [_session displayNameForPeer:peerID];
}
这都是些简单的方法，将_availabelServers和_session对象封装起来。在作为客户端的设备上启动app，你应该能够看到下面这个界面：
成功了，client显示出了server的名字(看，上面的截图，我用我的ipod作为server).
可惜，界面看起来并不是那么漂亮。这很容易结局。添加一个新的类，继承UITableViewCell，命名为PeerCell。（我建议创建一个叫做"Views"的group，然后把刚创建好的类放进去。）
你可以先把PeerCell.h放一放，用下面的内容替换PeerCell.m文件的内容:
#import "PeerCell.h"
#import "UIFont+SnapAdditions.h"
@implementation PeerCell
- (id)initWithStyle:(UITableViewCellStyle)style reuseIdentifier:(NSString *)reuseIdentifier
{
if ((self = [super initWithStyle:style reuseIdentifier:reuseIdentifier]))
{
self.backgroundView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@"CellBackground"]];
self.selectedBackgroundView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@"CellBackgroundSelected"]];
self.textLabel.font = [UIFont rw_snapFontWithSize:24.0f];
self.textLabel.textColor = [UIColor colorWithRed:116/255.0f green:192/255.0f blue:97/255.0f alpha:1.0f];
self.textLabel.highlightedTextColor = self.textLabel.textColor;
}
return self;
}
@end
PeerCell是一个正规的UITableViewCell，但是它改变了原本cell里的textlabel的字体和颜色，并且换个一个新的背景。在JoinViewController的cellForRowAtIndexPath方法中，用下面一行代码替换创建table view cell的代码:
cell = [[PeerCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier];
不要忘了导入PeerCell.h头文件，现在table view cell看起来跟界面非常匹配了:
试试这样：退出作为server的设备上的app，client就会从它的列表中删掉这个server的名字。如果你有多台设备，不妨试试用多台设备作为server。这样，client就会找到所有的server并在列表中显示出它们的名字。
注意：当server出现或者消失的时候，client要等一会才能察觉到，需要几秒的反应时间。所以如果列表没有及时刷新，不要大惊小怪哦！
一个简单的状态机
下件要做的事情就是让client和server连接。到目前为止，你的app还没有做任何的通讯-client已经能够显示出可用的server，但是server还不知道client的任何信息。现在只是能看出，你点击了哪个server就表明client要连接哪个server。
因此，MatchmakingClient要做两件事情。第一，寻找server，连接你选择的server。第二，如果连接成功，保持通讯，这时，MatchmakingClient就不再关心其它的server了。所以就没有理由再去侦测其它新的server和更新_availabelServers列表了（不用将这些告诉它的delegate）。
MatchmakingClient的状态可以用状态示意图来展现出来。下面就是MatchmakingClient各种状态的示意图：
MatchmakingClient有四种状态。开始是"idle"状态，这是一开始的状态，什么都没做。当调用startSearchingForServersWithSessionID:这个方法的时候，就会进入"Searching for Servers"状态。这些也就是你代码目前所做的。
当用户决定连接一个server的时候，client就进入了"connecting"状态，尝试连接一个server。确保连接成功后就进入了"connected"状态。如果在连接期间两者有一个断开了（或者一起消失），client就又进入"idle"状态。
MatchmakingClient根据所处不同的状态有不同的表现。在"searching for servers"状态，它会从_availabelServers列表中添加或者删除一个server，但是在"connecting"和"connected"状态，是不会的。
用这样的示意图来描述对象各种可能的状态，当状态变化时，你可以很明确地做出一些处理动作。在这边教程中，还会使用一些类似的其它的一些示意图，包括整个游戏状态的管理（这个要比你在这里看到的复杂一些）。
状态示意图的实现叫做"state machine"。你可以用一个enum和实例变量来监视MatchmakingClient的状态。在MatchmakingClient.m中，@implementataion上方的添加如下代码：
typedef enum
{
ClientStateIdle,
ClientStateSearchingForServers,
ClientStateConnecting,
ClientStateConnected,
}
ClientState;
这四个值代表者这个对象的四种不同的状态。添加一个新的实例变量：
@implementation MatchmakingClient
{
. . .
ClientState _clientState;
}
这个状态是这个对象的内部东西，没有必要把它放进属性里。初始化时，这个状态应该设置成"idle"，所以添加这个初始化的方法到类中：
- (id)init
{
if ((self = [super init]))
{
_clientState = ClientStateIdle;
}
return self;
}
现在我们要完善先前写过的方法来响应不同状态的改变。首先是startSearchingForServersWithSessionID:，当MatchmakingClient进入idle状态时，这个方法应该有所响应，改变如下：
- (void)startSearchingForServersWithSessionID:(NSString *)sessionID
{
if (_clientState == ClientStateIdle)
{
_clientState = ClientStateSearchingForServers;
// ... existing code goes here ...
}
}
最后，改变session:peer:didChangeState:中的这两个case语句:
// The client has discovered a new server.
case GKPeerStateAvailable:
if (_clientState == ClientStateSearchingForServers)
{
if (![_availableServers containsObject:peerID])
{
[_availableServers addObject:peerID];
[self.delegate matchmakingClient:self serverBecameAvailable:peerID];
}
}
break;
// The client sees that a server goes away.
case GKPeerStateUnavailable:
if (_clientState == ClientStateSearchingForServers)
{
if ([_availableServers containsObject:peerID])
{
[_availableServers removeObject:peerID];
[self.delegate matchmakingClient:self serverBecameUnavailable:peerID];
}
}
break;
在ClientStateSearchingForServers状态中，你只需要关心GKPeerStateAvailable和GKPeerStateUnavailable这两种状态就可以了。注意状态有两种类型：一种是peer的状态，就是delegate方法传进来的，另一种是MatchmakingClient状态。为了不使那么困惑，我称后者为_clientState。
连接Server
添加新的方法声明到MatchmakingClient.h文件中:
- (void)connectToServerWithPeerID:(NSString *)peerID;
见名知意，你将用这个方法让client连接特定的server。在.m中添加如下方法实现：
- (void)connectToServerWithPeerID:(NSString *)peerID
{
NSAssert(_clientState == ClientStateSearchingForServers, @"Wrong state");
_clientState = ClientStateConnecting;
_serverPeerID = peerID;
[_session connectToPeer:peerID withTimeout:_session.disconnectTimeout];
}
在"searching for servers"这个状态，你只能调用上面这个方法。如果不调用此方法，就让程序退出。这只是为了程序更加健壮，确保状态机正常工作。
当状态改变为"connecting"时，保存server的peer ID到一个新的实例变量_serverPeerID中，告诉GKSession对象这个client要和那个PeerID连接。对于timeout值-断开连接，没有响应时等待的时间。在这里，你用GKSession默认的timeout时间就可以了。
添加你个新的实例变量_serverPeerID：
@implementation MatchmakingClient
{
. . .
NSString *_serverPeerID;
}
这些就是MatchmakingClient的东西。现在你必须在某个地方调用connectToServerWithPeerID:这个方法。最合适的地方就是JoinViewController的tableview delegate。添加如下代码到JoinViewController.m文件中:
#pragma mark - UITableViewDelegate
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
[tableView deselectRowAtIndexPath:indexPath animated:YES];
if (_matchmakingClient != nil)
{
[self.view addSubview:self.waitView];
NSString *peerID = [_matchmakingClient peerIDForAvailableServerAtIndex:indexPath.row];
[_matchmakingClient connectToServerWithPeerID:peerID];
}
}
这就十分明确了。首先，你要确定server的peer ID(通过锁定的indexPath.row属性)，然后调用这个新的方法去连接。注意，为了盖住table view和其它的控件，你还要显示"waitView"这个界面。waitView是nib中的第二个top-level试图，你就是用它来作为loading页面。
当你在客户端运行app，并点击一个server的名字，会看到如下界面：
MatchmakingClient已经进入"connecting"状态，并且在等待这个server的回应。你不想用户在此时再进入其它的server，所以你显示这个临时的等待画面.
如果你稍微看下server app的Debug输出窗口，你会发现输出了一些东西：
Snap[4503:707] MatchmakingServer: peer 1310979776 changed state 4
Snap[4503:707] MatchmakingServer: connection request from peer 1310979776
这些事GKSession的通知消息，告诉server，有个client（在这个例子中ID为"1310979776"）试图连接进来。在下个部分，你将让MatchmakingServer变得更聪明一些，让它能够接受连接请求和显示要连接的client到屏幕上。
注意：debug窗口打印出的"changed state 4"，对应着GKPeerState常量中的一个:
- 0 = GKPeerStateAvailable
- 1 = GKPeerStateUnavailable
- 2 = GKPeerStateConnected
- 3 = GKPeerStateDisconnected
- 4 = GKPeerStateConnecting
提示:如果你同时在Xcode中运行了多个设备，你可以在debugger bar中切换debug输出窗口：
在server端接受连接请求
现在你有一个正试图连接的client，在后续事情完成之前，你必须先接受连接。这些都是在MatchmakingServer完成的。
在完成那些事情之前，要先在server设置一个state machine。添加如下的typedef到MatchmakingServer.m文件的上部:
typedef enum
{
ServerStateIdle,
ServerStateAcceptingConnections,
ServerStateIgnoringNewConnections,
}
ServerState;
不像client，server只有三个状态。
这真是太简单了。当游戏开始时，server就进入"ignoring new connections"状态了。从那时起，新的client将被忽略。下面，添加一个新的实例变量来跟踪这些状态：
@implementation MatchmakingServer
{
. . .
ServerState _serverState;
}
就如当初的client，给server一个init方法,把状态初始化为idle:
- (id)init
{
if ((self = [super init]))
{
_serverState = ServerStateIdle;
}
return self;
}
添加一个if语句到startAcceptingConnectionsForSessionID:这个方法中，用来检测是否是"idle"状态，然后将_serverState设置为"accepting connections":
- (void)startAcceptingConnectionsForSessionID:(NSString *)sessionID
{
if (_serverState == ServerStateIdle)
{
_serverState = ServerStateAcceptingConnections;
// ... existing code here ...
}
}
酷，现在为什么不让GKSessionDelegate做点什么呢。就像client发现有新的可用server被通知一样，当发现有新的client请求连接时，应当通知server。在MatchmakingServer.m文件中，更改session:peer:didChangeState:这个方法：
- (void)session:(GKSession *)session peer:(NSString *)peerID didChangeState:(GKPeerConnectionState)state
{
#ifdef DEBUG
NSLog(@"MatchmakingServer: peer %@ changed state %d", peerID, state);
#endif
switch (state)
{
case GKPeerStateAvailable:
break;
case GKPeerStateUnavailable:
break;
// A new client has connected to the server.
case GKPeerStateConnected:
if (_serverState == ServerStateAcceptingConnections)
{
if (![_connectedClients containsObject:peerID])
{
[_connectedClients addObject:peerID];
[self.delegate matchmakingServer:self clientDidConnect:peerID];
}
}
break;
// A client has disconnected from the server.
case GKPeerStateDisconnected:
if (_serverState != ServerStateIdle)
{
if ([_connectedClients containsObject:peerID])
{
[_connectedClients removeObject:peerID];
[self.delegate matchmakingServer:self clientDidDisconnect:peerID];
}
}
break;
case GKPeerStateConnecting:
break;
}
}
是关注GKPeerStateConnected和GKPeerStateDisconnected这两个状态的时候了，这里的逻辑跟先前设置client是一样的：把peer ID加到数组里，然后通知delegate。
当然，我们现在还没有为MatchmakingServer定义delegate protocol。现在就做，添加如下代码到MatchmakingServer.h文件的上方：
@class MatchmakingServer;
@protocol MatchmakingServerDelegate <NSObject>
- (void)matchmakingServer:(MatchmakingServer *)server clientDidConnect:(NSString *)peerID;
- (void)matchmakingServer:(MatchmakingServer *)server clientDidDisconnect:(NSString *)peerID;
@end
你知道该怎么做，添加一个属性到@interface中:
@property (nonatomic, weak) id <MatchmakingServerDelegate> delegate;
在.m文件中synthesize这个属性:
@synthesize delegate = _delegate;
但是谁来担当MatchmakingServer的delegate呢？HostViewController，当然是它。跳转至HostViewController.h文件并且添加MatchmakingServerDelegate到protocol列表中：
@interface HostViewController : UIViewController <UITableViewDataSource, UITableViewDelegate, UITextFieldDelegate, MatchmakingServerDelegate>
添加如下一行代码到HostViewController.m的viewDidAppear方法中，因为还要给_matchmakingServer的delegate赋值，所以刚好放在MatchmakingServer alloc之后：
_matchmakingServer.delegate = self;
添加delegate实现方法：
#pragma mark - MatchmakingServerDelegate
- (void)matchmakingServer:(MatchmakingServer *)server clientDidConnect:(NSString *)peerID
{
[self.tableView reloadData];
}
- (void)matchmakingServer:(MatchmakingServer *)server clientDidDisconnect:(NSString *)peerID
{
[self.tableView reloadData];
}
就像你对MatchmakingClient和JoinViewController这两个类做的一样，你就是很简单地刷新table view的内容。说到这儿，别忘了实现data source方法。替换numberOfRowsInSection和cellForRowAtIndexPath方法：
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
if (_matchmakingServer != nil)
return [_matchmakingServer connectedClientCount];
else
return 0;
}
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
static NSString *CellIdentifier = @"CellIdentifier";
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
if (cell == nil)
cell = [[PeerCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier];
NSString *peerID = [_matchmakingServer peerIDForConnectedClientAtIndex:indexPath.row];
cell.textLabel.text = [_matchmakingServer displayNameForPeerID:peerID];
return cell;
}
这非常像你之前做的，不同的是，现在列表里显示的是连接的client，而不是可用的server。因为点击table view cell在屏幕上是不需要任何效果的，所以添加如下方法来紧用选中的效果：
#pragma mark - UITableViewDelegate
- (NSIndexPath *)tableView:(UITableView *)tableView willSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
return nil;
}
在文件的上方导入PeerCell的头文件：
#import "PeerCell.h"
马上就好了。你还需要添加这些缺少的方法到MatchmakingServer。添加如下方法声明到MatchmakingServer.h文件中：
- (NSUInteger)connectedClientCount;
- (NSString *)peerIDForConnectedClientAtIndex:(NSUInteger)index;
- (NSString *)displayNameForPeerID:(NSString *)peerID;
添加方法的实现部分到.m文件中：
- (NSUInteger)connectedClientCount
{
return [_connectedClients count];
}
- (NSString *)peerIDForConnectedClientAtIndex:(NSUInteger)index
{
return [_connectedClients objectAtIndex:index];
}
- (NSString *)displayNameForPeerID:(NSString *)peerID
{
return [_session displayNameForPeer:peerID];
}
喔，敲了不少代码啊！现在你可以运行app了。重新启动你的设备，它可以作为server起作用了（你可以在client设备上启动app，但是你还没有改变client端代码，所以这真的没有必要）。
现在，你点击client设备上的一个server名称，在这个server的table view列表里就可以看到这个client了。试试吧。
可惜...什么都没有发生（哦，我知道了！）。就像先前我说的，如果一个client试图连接server，直到这个server接受，两者才能建立起完全的连接。
GKSession有另外一个delegate方法做这个，就是session:didReceiveConnectionRequestFromPeer:方法。为了接受新的连接，server必须实现这个方法并且向session对象发送acceptConnectionFromPeer:error: 消息。
在MatchmakingServer.m文件中，已经有了这个方法的框架，现在我们要做的就是用下面的代码完善它：
- (void)session:(GKSession *)session didReceiveConnectionRequestFromPeer:(NSString *)peerID
{
#ifdef DEBUG
NSLog(@"MatchmakingServer: connection request from peer %@", peerID);
#endif
if (_serverState == ServerStateAcceptingConnections && [self connectedClientCount] < self.maxClients)
{
NSError *error;
if ([session acceptConnectionFromPeer:peerID error:&error])
NSLog(@"MatchmakingServer: Connection accepted from peer %@", peerID);
else
NSLog(@"MatchmakingServer: Error accepting connection from peer %@, %@", peerID, error);
}
else // not accepting connections or too many clients
{
[session denyConnectionFromPeer:peerID];
}
}
首先，你要检测server的状态是不是"accepting connections"。如果不是，你就不能接受新的连接请求，拒绝请求你可以用denyConnectionFromPeer:方法。当client连接数到达上限的时候，你也可以调用那个方法来禁止连接，在Snap!中，我们用maxClients这个属性来控制最大连接数，值为3。
如果一切准备就绪，你可以调用acceptConnectionFromPeer:error:方法，之后，另一个GKSession delegate方法将会被调用，然后就会有新的client显示在table view列表中。再次试一下，在server设备上启动app。
现在,在server的debug窗口应该输出了：
Snap[4541:707] MatchmakingServer: Connection accepted from peer 1803140173
Snap[4541:707] MatchmakingServer: peer 1803140173 changed state 2
state 2就是GKPeerStateConnected状态。恭喜！现在server和client已经连接成功。两者可以通过GKSession对象相互发送消息了(这些也是你将要做的)。
下面就是我的iPod（服务器）截图，里面有三个已经连接进来的client:
注意:即使你可以在屏幕上方的文本框中输入另外一个名称，但是，在table view列表中显示的永远是设备的名称（换句话说，也就是文本框的placeholder内容）。
错误和断开连接的处理
马上就要写有关网络处理的代码，你要记住：事情总是不可预测的。在任何时候，连接都有可能断开，而且你还要妥善的处理好两端，不管是client还是server。
如何处理client端。比如说client等待被连接，或者连接已经被确认，然后server突然离开。你如何处理要依据于你的app，但是在Snap!中，你将让玩家退回主界面。
处理这样的情况，你必须在你GKSession的delegate方法检查GKPeerStateDisconnected状态，像下面这样在MatchmakingClient.m文件中处理:
- (void)session:(GKSession *)session peer:(NSString *)peerID didChangeState:(GKPeerConnectionState)state
{
. . .
switch (state)
{
. . .
// You're now connected to the server.
case GKPeerStateConnected:
if (_clientState == ClientStateConnecting)
{
_clientState = ClientStateConnected;
}
break;
// You're now no longer connected to the server.
case GKPeerStateDisconnected:
if (_clientState == ClientStateConnected)
{
[self disconnectFromServer];
}
break;
case GKPeerStateConnecting:
. . .
}
}
先前，在GKPeerStateConnected和GKPeerStateDisconnected状态中，你没有实现任何东西，但是现在你在前者语句中将状态机调整为"connected"状态，在后者语句中调用了一个新的方法disconnectFromServer。添加方法到类中：
- (void)disconnectFromServer
{
NSAssert(_clientState != ClientStateIdle, @"Wrong state");
_clientState = ClientStateIdle;
[_session disconnectFromAllPeers];
_session.available = NO;
_session.delegate = nil;
_session = nil;
_availableServers = nil;
[self.delegate matchmakingClient:self didDisconnectFromServer:_serverPeerID];
_serverPeerID = nil;
}
这里你又让MatchmakingClient回到了"idle"状态，并且清理和销毁了GKSession对象。你还要调用一个新的delegate方法，让JoinViewController知道这个client现在已经断开连接了。
添加新的delegate方法声明到MatchmakingClient.h文件中的protocol中：
- (void)matchmakingClient:(MatchmakingClient *)client didDisconnectFromServer:(NSString *)peerID;
这个delegate方法是处理一个已经连接了server的client失去连接的情况，还有一种断开连接的情况是正在试图连接server的client突然断开了。那么后面这种情况是另一个GKSessionDelegate方法来处理的。用下面的方法替换MatchmakingClient.m中的方法：
- (void)session:(GKSession *)session connectionWithPeerFailed:(NSString *)peerID withError:(NSError *)error
{
#ifdef DEBUG
NSLog(@"MatchmakingClient: connection with peer %@ failed %@", peerID, error);
#endif
[self disconnectFromServer];
}
这里没什么特别的。你只是在连接断开的时候调用了disconnectFromServer方法。注意这个delegate方法在server明确调用denyConnectionFromPeer:方法拒绝client的连接请求时也会被调用，比如已经连接了3个client的时候。
因为你添加了一个新的方法声明到MatchmakingClientDelegate protocol中，所以你要在JoinViewController.m中实现它:
- (void)matchmakingClient:(MatchmakingClient *)client didDisconnectFromServer:(NSString *)peerID
{
_matchmakingClient.delegate = nil;
_matchmakingClient = nil;
[self.tableView reloadData];
[self.delegate joinViewController:self didDisconnectWithReason:_quitReason];
}
除了最后一行，都太简单了。因为你想要用户回到主界面，那么JoinViewController就必须让MainViewController知道用户失去连接了。用户失去连接有很多不同的原因，并且你需要让主界面知道为什么，因此，在必要的时候可以用alert view提示。
比如，如果用户主动退出游戏，那么就没有必要提示，因为用户知道问什么失去连接-毕竟是他自己按了退出按钮。但是如果是网络出错导致的，做个友好的提示还是不错的。
这就意味着有两件事情要做：添加新的delegate方法到JoinViewControllerDelegate中，添加_quitReason变量。
在JoinViewController.h文件适当的地方添加如下delegate方法声明：
- (void)joinViewController:(JoinViewController *)controller didDisconnectWithReason:(QuitReason)reason;
Xcode将会警告，因为它并不知道有这变量QuitReason。这是一个在很多类中都要用到的结构，所以将它加入到Snap-Prefix.pch中，使得所有的代码都能看到它。
typedef enum
{
QuitReasonNoNetwork, // no Wi-Fi or Bluetooth
QuitReasonConnectionDropped, // communication failure with server
QuitReasonUserQuit, // the user terminated the connection
QuitReasonServerQuit, // the server quit the game (on purpose)
}
QuitReason;
这里有四个原因，JoinViewController需要一个实例变量来储存退出的原因。你将会在几个不同的地方给这个变量设置合适的值，在client真正失去连接的时候，你还要把这个消息传递给delegate。
添加实例变量到JoinViewController:
@implementation JoinViewController
{
. . .
QuitReason _quitReason;
}
在viewDidAppear:方法中初始化它:
- (void)viewDidAppear:(BOOL)animated
{
[super viewDidAppear:animated];
if (_matchmakingClient == nil)
{
_quitReason = QuitReasonConnectionDropped;
// ... existing code here ...
}
}
_quitReason默认值是"connection dropped"。除了用户主动点击退出按钮，server都会认为是网络原因，而不是一些故意的情况。
因为你添加了一个新的方法到JoinViewController的delegate protocol中，因此你还要在MainViewController做一些工作。添加如下方法到MainViewController.m中的JoinViewControllerDelegate部分：
- (void)joinViewController:(JoinViewController *)controller didDisconnectWithReason:(QuitReason)reason
{
if (reason == QuitReasonConnectionDropped)
{
[self dismissViewControllerAnimated:NO completion:^
{
[self showDisconnectedAlert];
}];
}
}
如果由于网络出错断开了连接，那么你要关闭Join Game界面并且显示alert。showDisconnectedAlert的代码如下：
- (void)showDisconnectedAlert
{
UIAlertView *alertView = [[UIAlertView alloc]
initWithTitle:NSLocalizedString(@"Disconnected", @"Client disconnected alert title")
message:NSLocalizedString(@"You were disconnected from the game.", @"Client disconnected alert message")
delegate:nil
cancelButtonTitle:NSLocalizedString(@"OK", @"Button: OK")
otherButtonTitles:nil];
[alertView show];
}
试试吧。连接一个client到server，然后点击server设备的home键（或者完全退出）。一两秒后，client将连接不到server。（server端也会丢失client的连接，但是因为server端现在是暂停状态，在没有重新回到游戏界面之前是看不到任何东西的。）
client端debug窗口输出：
Snap[98048:1bb03] MatchmakingClient: peer 1700680379 changed state 3
Snap[98048:1bb03] dealloc <JoinViewController: 0x9570ee0>
State 3当然就是GKPeerStateDisconnected状态。app回到主界面会有一个提示信息：
就像你在debug窗口看到的那样，JoinViewController已经deallocate了。随着这个view controller一起的还有MatchmakingClient对象。如果你要确认，可以添加NSLog()到dealloc中：
- (void)dealloc
{
#ifdef DEBUG
NSLog(@"dealloc %@", self);
#endif
}
非常好，但是如果用户连接server成功后，点击了退出按钮再怎么办？这种情况，client应该断开连接并且不要显示alert。在JoinViewController.m中完成exitAction:方法来做这些事情。
- (IBAction)exitAction:(id)sender
{
_quitReason = QuitReasonUserQuit;
[_matchmakingClient disconnectFromServer];
[self.delegate joinViewControllerDidCancel:self];
}
首先，你设置了退出原因为"user quit"，然后告诉client失去连接。当你接收到matchmakingClient:didDisconnectFromServer:回调消息时，它会告诉MainViewController退出的原因是"user quit"，而且没有提示信息。
Xcode会提示"disconnectFromServer"方法没有找到，这只是因为你咩有把它放到MatchmakingClient.h中。将下面的一行加进去：
- (void)disconnectFromServer;
再次运行app，连接，然后在client端点击退出按钮。你将会在server debug输出窗口看到client已经失去连接的输出，client的名字也将会在server端的列表中消失。
如果你在server端点击home键进入后台之后又恢复server app，之后你就需要重新回到主界面，并再次按下Host Game。但是在app暂停之后，原来的GKSession对象将不再有效。
"无网络"错误
GameKit只是允许你通过蓝牙或者Wi-Fi来实现peer-to-peer连接。如果在连接的过程中，任何一方蓝牙和Wi-Fi不可用了，你应该给一个友好的错误提示。GKSession的严重错误有，比如在session:didFailWithError:通知的错误，所以在matchmakingClient.m中用下面的方法替换原方法：
- (void)session:(GKSession *)session didFailWithError:(NSError *)error
{
#ifdef DEBUG
NSLog(@"MatchmakingClient: session failed %@", error);
#endif
if ([[error domain] isEqualToString:GKSessionErrorDomain])
{
if ([error code] == GKSessionCannotEnableError)
{
[self.delegate matchmakingClientNoNetwork:self];
[self disconnectFromServer];
}
}
}
真正的错误被封装到NSError对象中，如果是一个GKSessionCannotEnableError错误，那么仅仅网络不可用。这种情况你要告诉你的delegate(带有一个新的方法)并且与server断开连接。
添加新的delegate方法到MatchmakingClient.h中的protocol里：
- (void)matchmakingClientNoNetwork:(MatchmakingClient *)client;
在JoinViewController.m中添加实现:
- (void)matchmakingClientNoNetwork:(MatchmakingClient *)client
{
_quitReason = QuitReasonNoNetwork;
}
很简单吧：你只是设置退出的原因为"no network"，因为MatchmakingClient调用了disconnectFromServer方法，JoinViewController也得到了didDisconnectFromServer消息，而且你还要把这些告诉MainViewController。你现在要做的就是让MainViewController能够收到退出原因的消息。
在MainViewController.m中实现如下方法:
- (void)joinViewController:(JoinViewController *)controller didDisconnectWithReason:(QuitReason)reason
{
if (reason == QuitReasonNoNetwork)
{
[self showNoNetworkAlert];
}
else if (reason == QuitReasonConnectionDropped)
{
[self dismissViewControllerAnimated:NO completion:^
{
[self showDisconnectedAlert];
}];
}
}
showNoNetworkAlert的代码:
- (void)showNoNetworkAlert
{
UIAlertView *alertView = [[UIAlertView alloc]
initWithTitle:NSLocalizedString(@"No Network", @"No network alert title")
message:NSLocalizedString(@"To use multiplayer, please enable Bluetooth or Wi-Fi in your device's Settings.", @"No network alert message")
delegate:nil
cancelButtonTitle:NSLocalizedString(@"OK", @"Button: OK")
otherButtonTitles:nil];
[alertView show];
}
测试一下这些代码吧，在飞行模式下运行app(在这种模式下，Wi-Fi和蓝蓝牙被关闭了)。
注意：在我的设备上，我必须要先进入Join Game界面（这儿什么都没有发生），点击退出按钮回到主界面，然后再次进入Join Game界面。我不清楚为什么GameKit第一次没有意识到这个问题。或许Reachability API中有更准确的方法来检测蓝牙和Wi-Fi的可用性吧。
debug窗口输出：
MatchmakingClient: session failed Error Domain=com.apple.gamekit.GKSessionErrorDomain Code=30509 "Network not available." UserInfo=0x1509b0 {NSLocalizedFailureReason=WiFi and/or Bluetooth is required., NSLocalizedDescription=Network not available.}
显示alert view的界面：
对于"no network"错误，确实没有必要离开Join Game界面，即便你停用了session和任何的网络活动。我觉得跳到主界面会使用户感到迷惑。
注意：显示alertview的代码-事实上，在app上显示文本的任何代码-都应该使用NSLocalizedString()宏命令来进行国际化。即使你的app前期只需要English，为你项目以后的国际化做准备是非常明智的。更多有关国际化信息，看这里。
这里还有一个你要在client端处理的问题。在我的测试中，我发现有时候server变的不可用时，client仍然很执着地去尝试连接。这种情况，client会收到一个状态改变为GKPeerStateUnavailable的回调。
如果你没有处理这种情况，client端的连接最终会timeout，用户也会得到一些错误的提示信息。但是你也是可以在代码中检测这种连接断开错误的。
在MatchmakingClient.m，改变GKPeerStateUnavailable的case语句：
// The client sees that a server goes away.
case GKPeerStateUnavailable:
if (_clientState == ClientStateSearchingForServers)
{
// ... existing code here ...
}
// Is this the server we're currently trying to connect with?
if (_clientState == ClientStateConnecting && [peerID isEqualToString:_serverPeerID])
{
[self disconnectFromServer];
}
break;
在server端处理错误
在server端，处理断开连接和错误与client端的非常相似，因为你已经在client端有处理的相关代码了。所以非常简单。
首先，处理"no network"问题。在MatchmakingServer.m文件中，改变session:didFailWithError:方法：
- (void)session:(GKSession *)session didFailWithError:(NSError *)error
{
#ifdef DEBUG
NSLog(@"MatchmakingServer: session failed %@", error);
#endif
if ([[error domain] isEqualToString:GKSessionErrorDomain])
{
if ([error code] == GKSessionCannotEnableError)
{
[self.delegate matchmakingServerNoNetwork:self];
[self endSession];
}
}
}
除了现在你要调用一个叫endSession的方法用来清理之外，这里跟你在MatchmakingClient做的几乎相同。添加endSession:
- (void)endSession
{
NSAssert(_serverState != ServerStateIdle, @"Wrong state");
_serverState = ServerStateIdle;
[_session disconnectFromAllPeers];
_session.available = NO;
_session.delegate = nil;
_session = nil;
_connectedClients = nil;
[self.delegate matchmakingServerSessionDidEnd:self];
}
这里没什么惊奇的。你还要调用两个新的delegate方法，matchmakingServerNoNetwork:和matchmakingServerSessionDidEnd:，添加它们到MatchmakingServer.h的protocol中，然后在HostViewController.m中实现它们。
首先，添加声明到protocol中：
- (void)matchmakingServerSessionDidEnd:(MatchmakingServer *)server;
- (void)matchmakingServerNoNetwork:(MatchmakingServer *)server;
然后，在HostViewController.m文件中添加对应的实现方法：
- (void)matchmakingServerSessionDidEnd:(MatchmakingServer *)server
{
_matchmakingServer.delegate = nil;
_matchmakingServer = nil;
[self.tableView reloadData];
[self.delegate hostViewController:self didEndSessionWithReason:_quitReason];
}
- (void)matchmakingServerNoNetwork:(MatchmakingServer *)server
{
_quitReason = QuitReasonNoNetwork;
}
再一次，你在之前见到过同样地逻辑。来吧，添加_quitReason实例变量到HostViewController中：
@implementation HostViewController
{
. . .
QuitReason _quitReason;
}
在HostViewController.h中添加新的方法到它的delegate protocol中：
- (void)hostViewController:(HostViewController *)controller didEndSessionWithReason:(QuitReason)reason;
最后，在MainViewController.m中实现这个方法：
- (void)hostViewController:(HostViewController *)controller didEndSessionWithReason:(QuitReason)reason
{
if (reason == QuitReasonNoNetwork)
{
[self showNoNetworkAlert];
}
}
在飞行模式下启动app，然后试着开一局游戏。你将会得到"no network"错误。（如果第一次你没有得到错误提示，那么退到主界面，再次点击Host Game按钮试试。）进入设置，关闭飞行模式，然后在切换回Snap!再一次，点击Host Game按钮，新的client应该能够找到这个server了。
为了完整一些，在用户点击Host Game界面退出按钮的时候，你还应该结束会话。所以替换HostViewController的exitAction:方法：
- (IBAction)exitAction:(id)sender
{
_quitReason = QuitReasonUserQuit;
[_matchmakingServer endSession];
[self.delegate hostViewControllerDidCancel:self];
}
当然，endSession不是一个public方法，所以还是把它加在MatchmakingServer的@interface中比较好:
- (void)endSession;
哎呀，仅仅是让server和client相互找到对方就做了这么多工作！（相信我，如果没有GKSession，你还有大量的工作要做！）
非常酷的事情是，你可以把MatchmakingServer和matchmakingClient类免费引用到其它的工程中！因为设计的这些类独立于所有的view controller，它们在其它项目中很容易重用。
下一步该做什么？
这是到目前为止教程的范例工程。
准备着手处理第三部分吧，在那部分，client和server可以相互发送信息！
期间，你有任何有关这篇教程的问题或者评论，都可以在下面进行讨论！