转自朋友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可以相互发送信息!
期间,你有任何有关这篇教程的问题或者评论,都可以在下面进行讨论!