设计iOS平台CS架构客户端的基本框架-发送者

上一篇最后提到了Poster的设计思想,将网络状态封装到Poster的内部,使得外部的调用者可以不必考虑网络的复杂性


最简单的情况,当加入一个命令包时,判断当前网络状态,若可用,执行命令,若不可用,放入列表中,当检测到网络可用时,检查列表中是否有命令包,有的话,开始依次执行


但这里还有一个问题需要考虑,当网络断开以后,与服务器的逻辑连接是否断开了,如果是的(相当于未登录的时候),那么网络再次可用后,列表中的命令包对于服务器来说已经是无效的了,所以在网络重连后,需要将登录命令插入到列表的第一个


这里引入了逻辑连接,实际上不光是物理连接断开会导致逻辑连接的中断,在物理连接正常的情况下面,逻辑连接也会断开,比如在网络状况差的情况下面,心跳包没有及时回应等,所以在发送命令包前,不光要检查物理连接,还要检查逻辑连接是否正常


同网络状态类似,我们将逻辑连接也视作Poster的内部状态,由Poster自身负责维护物理和逻辑的连接,还是拿上一篇的登录,获取信息,登出为例,当发送给登录命令给Poster后,Poster检查网络物理状态,若连接中,直接发送登录命令,在登录成功到登出过程中,若网络断开,首先停止发送命令,然后自动重连,重连成功后,插入登录命令,开始发送命令,若逻辑连接断开,也是首先停止发送命令,插入登录命令,开始发送命令(此时不需要重连)


由于Poster的内部状态比较多,可以预期的变化也是存在的,如果使用其他的方式重连,使用其他的方式保存逻辑连接等,我们引入状态模式来代替大量的switch-case语句


@interface PosterStatus:NSObject  

@end  

@interface PosterStatusIdle:PosterStatus  

@end  

@interface PosterStatusConnecting:PosterStatus  

@end  

@interface PosterStatusConnected:PosterStatus  

@end  

@interface PosterStatusLoging:PosterStatus  

@end  

@interface PosterStatusLogin:PosterStatus  

@end   

以上列举了一些状态,在需要按照Poster状态使用不同的处理时,可以按照如下方式调用:

  1. -(void)postCommand:(Command*)cmd{  

  2.     [self.status postCommand:cmd toPoster:self];  

  3. }  

其中status是Poster维护的当前状态,是PosterStatus的一个子类

你可能感兴趣的:(设计iOS平台CS架构客户端的基本框架-发送者)