iOS网络高级编程：iPhone和iPad的企业应用开发之错误处理

接口契约还应该指定怎样向client发送错误信息。服务接口应该使用业界标准方式在可能的情况下传递错误信息。

比方。server不应该为服务端失败定义新的HTTP 状态值；相反，应该使用恰当的500 级别的状态。假设使用了标准值，那么client与服务端开发人员就能对怎样传递错误信息达成共识。

应用绝不应该依赖于非标准的状态或是其它属性值来确定错误出现与否。
应用开发人员也不应该依赖于当前server软件栈的行为来决定该怎样处理错误。在部署了iOS 应用后，server软件栈可能会因为未来的升级或替换而改变行为。

5.2.2 错误状态可能不对
移动网络有例如以下有别于传统Web 应用错误的不那么明显的行为：模糊不清的错误报告。

从移动设备发往server的不论什么网络请求都有3 种可能的结果：
● 设备全然可以确认操作是成功的。比方。NSError 与HTTP 状态值都表明成功。返回的负载包括语义上正确的信息。
● 设备全然可以确认操作是失败的。

比方。返回的应用负载包括来自于server的特定于本次操作的失败标识。

● 设备模糊地确认操作是失败的。比方，移动应用发出HTTP 请求以在两个账户间转账。请求被银行系统接收并正确地处理；然而，因为网络失败应答却丢失了，NSURLConnection 报告超时。超时发生了，但却是在转账请求成功之后发生的。假设重试该操作。那就会导致反复转账。可能还会造成账户透支。

第3 种场景会导致应用出现意外和检測不到的错误行为。假设应用开发人员不知道第3种场景的存在。那么他们可能就会错误地假设操作失败，然后不小心重试已经成功的操作。

知道整个操作失败还不够，开发人员必须考虑导致请求失败的原因，以及自己主动重试每一个失败的请求是否是恰当的。

5.2.3 验证负载
应用开发人员不应该觉得假设没有OS 错误或HTTP 错误，负载就是有效的。在非常多场景下，请求似乎是成功的，只是负载却是无效的。client与server之间传递的负载都一种验证机制。JSON 与XML 就是具备了验证机制的负载格式。只是以逗号分隔的值文件与HTML 就没有这样的机制。

分离错误与正常的业务状况会让代码保持恰当的关注分离。仅仅有当出现故障时才应该将之看成错误。

5.2.5 总是检查HTTP 状态
总是检查HTTP 响应中的HTTP 状态，理解成功的状态值。甚至向同样的服务发出反复的调用也是如此。server的状态可能随时会发生变化，甚至在并行的调用间也是如此。
5.2.6 总是检查NSError 值
应用代码应该总是检查返回的NSError 值来确保OS 层没有出现故障。

即便知道应用总是执行在信号良好的Wi-Fi 网络下也应该这样做。不论什么东西都有出错的可能性，代码在处理网络时也须要做好防御工作。
5.2.7 使用一致的方法来处理错误
网络错误的产生原因是许多的，很难一一列举出来，影响的多样性及范围也是很大的。

在设计应用时，请不要仅仅关注于一致的用户界面模式或是一致的命名模式。

你还应该设计一致的模式来处理网络错误。该模式应该考虑到应用可能会遇到的全部类型的错误。

假设应用的内部没有以一致的模式处理这些错误，那么应用就无法以一致的方式向用户报告这些错误。
5.2.8 总是设置超时时间
在iOS 中。HTTP 请求的默认超时时间间隔是4 分钟，这对于移动应用来说过长了，大多数用户都不会在不论什么应用中等待4 分钟。开发人员须要选择合理的超时时间，方式是评估网络请求的可能响应时间。然后将最差的网络场景下的网络延迟考虑进去。例如以下演示样例展示了怎样创建具有20 秒超时时间的请求：

● server错误异常通知名——特定的异常处理器对象会监听该通知。当server超时、返回与认证相关的OS 错误或HTTP 错误时。命令对象会通过NSNotificationCenter并使用该名字来广播消息。通常情况下。全部的命令类会共享同样的异常名，因此也会共享同样的异常监听器。只是不同的命令类可能须要使用不同的异常监听器，而且有不同的server错误异常名。
● 可达性异常通知名——当检測到无法到达Internet 或目标主机时，命令对象会生成该类型的通知。还有一个异常监听器能够监听该类型的异常。在某些应用中，这类常是不须要的。由于server错误异常监听器会处理可达性异常。
● 认证异常通知名——假设确定用户没有认证或是server报告了未认证状态，那么命令对象可能会产生该类型的通知。

第3 个异常监听器会等待该类型通知的出现。认证通知名一般会在应用的全部通知中共享。
● 自己定义属性——这些属性特定于发出的请求。

控制器一般会提供这些值。由于它们特定于服务调用所需的业务数据。并且不同的调用数据也是不同的。异常监听器
一般来说。每一个异常监听器都是由应用托付实例化的。位于后台并等待着特定类型的通知。在非常多情况下。异常监听器在接收到通知时会显示模态视图控制器，这将在“异常监听器行为”部分进行介绍。
命令队列
控制器会将命令提交到命令队列进行处理，应用可能有一个或多个命令队列。在iOS中，命令队列是NSOperationQueue 的子类。不应该将主队列用作命令队列，由于它的操作执行在用户界面线程上， 在执行长时间执行的操作时会影响到用户体验。
NSOperationQueues 提供了管理活动操作以及操作间依赖的内置功能。
2. 对象上述每个对象都在成功完毕网络交易的过程中扮演着各自不同的角色。

以下介绍它们在该模式中各自的角色。
控制器行为
控制器重点关注于运行UI 与业务逻辑。当控制器想要从服务获取数据时，应该採取例如以下动作：
(1) 创建一个网络命令对象。
(2) 针对命令对象的详细属性初始化请求。

(5) 等待NSNotificationCenter 发送完毕通知。
当操作完毕时，控制器会接收到完毕通知并採取例如以下动作：
(1) 检查操作状态，看看操作是否成功。
(2) 假设成功，那么控制器会处理接收到的数据。接收到的数据是通过NSNotification对象的userInfo 属性提供给控制器的。NSOperationQueues 会在自己的线程上执行NSOperation 对象。当操作完毕后，会通过NSNotificationCenter 发送NSNotification。该通知回调方法会在NSOperation 执行的线程上得到调用，在该例中这会确保它不会进入主线程中。

假设控制器操纵UI，那么须要在主线程上做这些改变，一般是通过Grand CentralDispatch(GCD)实现的。
(3) 假设不成功，那么控制器依据应用需求能够有非常多选择。比方，能够将自己从视图栈中弹出或是更新UI，表明数据不可用。控制器不应该重试或是显示模态警告。由于这
些动作是异常监听器的职责。

一般来说，命令对象须要运行例如以下步骤：
(1) 检查可达性。

假设网络不可达。那就广播一条可达性异常通知。
(2) 假设须要，检查认证状态。假设用户尚未授权，那就广播一条可达性异常通知。
(3) 使用控制器提供的自己定义属性构建网络请求。通常情况下，端点URL 是命令对象类的静态属性或是从配置子系统中载入。
(4) 使用同步请求方式发出网络请求。參见第3 章的3.3.2 节“同步请求”以了解详情。
(5) 检查请求状态。假设状态是OS 错误或HTTP 错误。那就广播一条server异常通知。假设是认证错误，那就广播一条认证异常通知。
(6) 解析结果，參见第4 章。

(7) 广播一条成功状态的完毕通知。
当命令对象广播通知时，不管是成功还是其它通知。都须要创建字典对象，字典对象中包括自身的副本、调用状态与返回的数据。以此作为调用的结果。自身复制是有必要的，由于NSOperation 实例仅仅能运行一次。稍后将会介绍，在监听器处理异常时，命令可能会被再次提交。

假设请求发出或是返回的数据量超出期望在内存中处理的数据量。应用就须要使用异步请求了。

由于NSOperation 的主要功能是一个方法。操作必须实现并发锁来堵塞main 方法，直到异步调用完毕为止。

异常监听器行为
这样的模式之所以如此强大，异常监听器功不可没。

这些对象通常都是由应用托付创建的，驻留在内存中并监听着通知。当接收到通知时，监听器会通知用户。还可能会接收来自用户的响应。当异常发生时，通知中包括了触发该异常的命令副本，当用户作出响应后。监听器一般会再次将命令发回到队列中并重试。

关于异常监听器有趣的一点是：因为多个命令可能同一时候发生，因此在用户响应第一个异常时可能还会同一时候产生多个异常通知。出于这一点。异常监听器必须收集异常通知，然后在用户响应完第一个异常后又一次提交全部的触发命令。这个错误集合能够避免一种常见的应用行为不当——用户被同样问题触发的多个UIAlertView 连续轰炸。

(3) 假设用户选择重试，那么关闭对话框并又一次提交全部收集到的命令。

(4) 假设用户选择取消，那么关闭对话框。监听器应该将全部收集到的命令的完毕状态设为失败，然后让每一个命令广播一条完毕通知。
可达性异常的流程例如以下所看到的：
(1) 呈现一个美丽的模态对话框，通知用户须要网络连接。
(2) 收集可能会被广播的其它服务异常。
(3) 监听可达性变更。当网络可达时。关闭对话框并又一次提交收集到的命令。

认证异常的流程略微有点复杂。

请记住，命令之间是独立的，在随意时刻可能会有多个命令同一时候发生。

认证流程并不会生成认证异常通知，流程例如以下所看到的：
(1) 呈现一个模态登录视图。
(2) 继续收集因为认证错误导致的失败命令。
(3) 假设用户取消，那么监听器应该针对收集到的命令使用失败状态发送一条完毕通知。
(4) 假设用户提供了认证信息，那么创建一个登录命令，将其放到命令队列中。
(5) 等待登录命令的完毕通知。
(6) 假设因为username/password不匹配而导致登录失败，那么回到步骤(2)。否则关闭登录视图控制器。

(7) 假设登录命令成功，那么又一次向命令队列提交触发命令。
(8) 假设登录命令失败，那么让触发命令使用失败状态发送一条完毕通知。

在默认情况下，命令队列遵循着先进
先出(FIFO)的顺序。

在代码向NSOperationQueue 中加入命令对象后，运行例如以下动作：

(2) 等待。直到队列头有可用位置。
(3) 当命令对象到达队列头时，命令对象的start 方法会被调用。

(4) 命令对象的main 方法得到调用。
请參考iOS API 文档中关于NSOperation 与NSOperationQueue 对象的介绍来了解队列与命令对象之间交互的具体信息。

● 设备可能无法联网。
● YouTube 可能没有及时响应或是出于某些原因失败了。

应用须要以一种优雅且可靠的方式处理每一种情况。该例将会阐述基本的代码组件并介绍一些实现细节。项目中的应用是个演示样例应用，仅仅用于演示目的。
1. 前提条件
要想成功执行该应用。你须要准备好例如以下内容：
● 一个YouTube 账号。
● 至少向你的YouTube 账号上传一个视频(无须公开，仅仅要上传到该账号就可以)。
● 从Wrox 站点上下载的项目压缩文件。
该项目使用Xcode 4.1 与iOS 4.3 开发，应用使用的是截止到2011 年10 月份的YouTubeAPI，只是该API 处于Google 的控制下，并且可能会发生变化。
2. 主要对象
下载好项目并在Xcode 中载入后。你会看到例如以下类：
1) 命令
命令分组中有例如以下一些类。

BaseCommand
BaseCommand 是全部命令对象的父类。

它提供了每一个命令类所需的众多方法。这些方法有：
● 发送完毕、错误与登录通知的方法。

此外，假设设计恰当。那么全部的网络服务调用都会使用同样的基础命令类，这会降低命令类的数量。

借助于Reachability 框架，代码能够主动对变化的网络状况作出响应，从而避免不必要的网络错误的出现。

在发出网络请求以及处理成功与失败的结果时遵循一致的模式，能够确保代码更加整洁、更加具有可维护性。