objective-c - AFHTTPClient - 解析响应对象

Question

我刚开始使用 AFNetworking，我正在尝试学习如何正确使用它。
我将 AFHTTPClient 子类化并创建了我自己的 MyAppClient使用正确的基本 URL。
我正在使用 HTTP POST 请求和服务器响应与 xml 进行通信。

发送请求我做:

    [[MyAppClient sharedClient] postPath:somePath parameters:nil success:^(AFHTTPRequestOperation *operation, id responseObject) {

    // need to parse the data here...

} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
    //
    NSLog(@"%@", [error localizedDescription]);
}];  

几个问题:

为什么AFHTTPClient如果无论如何它正在使用异步操作，请使用操作 NSURLConnection那不会阻塞主线程？

在我获得需要解析的数据后，我现在应该创建一个新的操作来解析数据吗？
在我看来，最好也在操作中解析数据，然后返回解析的对象，不是吗？

在同一主题中，我有一个自定义的通用 XMLParser 类，该类获取 NSData并将其解析为 NSDictionary ，我想将它用于所有响应，我如何将它集成到 AFHTTPClient 中AFHTTPRequestOperation以便已经解析响应？

Answer 1

Why does the AFHTTPClient use operation if anyway it's using an asynchronous NSURLConnection that doesn't block the main thread?

这实际上是一个很好的问题。

事实上，从 NSOperation 子类化并不需要一个可行的“HTTPRequestOperation”类。 . AFHTTPRequestOperation的设计很可能基于 Apple 工程师“Quinn”介绍的“原始”设计，他与他的类(class)一起发明了第一个“引用设计” QHTTPOperation并提供了许多宝贵的 sample - 这些 sample 仍然强烈推荐，值得一看。第一个设计子类 NSOperation并封装了一个 NSURLConnection目的。

这种设计有很多优点:

因为它是 NSOperation 的子类，网络请求看起来像一个“异步操作”。这意味着基本上，网络请求具有主要方法 start和 cancel并有一个完成处理程序来通知请求的最终结果。这个通用 API 对于异步网络操作很重要，因此它成为更通用的异步操作。

由于它是一个类，它封装了请求的所有相关状态变量。例如，请求、响应、响应数据、错误(如果有)和一些更相关的状态变量。然后，“网络请求对象”变得非常易于使用，这与委托(delegate)方法不同，当在一个委托(delegate)对象中的委托(delegate)方法中应该处理多个请求时，它开始变得困难。

安 NSOperation对象可以排队进入 NSOperationQueue .这使得可以定义请求的顺序，特别是任何其他操作，以及同时事件操作(请求)的数量(如果您有很多)。

与 NSOperation可以在其他操作之间定义或多或少复杂的依赖关系，这使您可以添加一些额外的“业务逻辑”层。有时，这对于解决更复杂的异步问题变得非常方便。

那么，问题为什么已经是异步的 NSURLConnection被封装在 NSOperation 的子类中这些都是上述优点。原因是永远不会像同步函数一样将它包装到 NSOperation 中。以便它可以在 NSOperationQueue 中执行.

事实上，对此存在广泛的误解。看来，很多人认为网络请求操作的方法会在 NSOperation的执行上下文上执行。 (例如，当添加到 NSOperationQueue 时)。然而，情况并非如此(在各种其他实现中可能有一些小异常(exception))。方法的执行上下文(主要是 NSULRConnection 的委托(delegate)方法)是一个专用的私有(private)线程，它将由 NSOperation 创建。子类。底层功能 NSURLConnection无论如何也要在他们的私有(private)执行上下文(一个或多个线程)上执行。

只有 start方法将在操作的执行上下文中执行，该上下文快速返回。也就是说，如果有一个队列(比如调度队列或 NSOperationQueue)在其中调度了操作，则只有 start方法在队列的执行上下文中执行。
NSOperation的 isFinished然而，状态将被推迟到网络请求确实完成的点。这种状态对其他 NSOperation具有重要意义对象和 NSOperationQueue :它向队列和其他操作发出此请求已完成的信号。

所以， NSOperation不是定义网络请求功能的执行上下文的工具，而是组织和设置与其他操作的关系的手段。

After I'm getting the data I need to parse it, should I now create a new operation to parse the data? It seems to me that it would be better to parse the data also in the operation and then return the parsed objects no?

嗯，你可以这样做。但是，我不认为这是一个好的设计决策:一个操作应该只处理一个特定的任务。网络操作是一个，解析任务_是另一个任务，也可以是一个操作。

这样做的一个原因是，操作可以根据它们主要需要哪些系统资源进行“分类”:CPU、内存、IO 等。合并不同的“任务类型”使得无法利用将它们关联到专用队列以进行控制系统资源的利用(见下文)。

好吧，当然，您可以将解析任务设为操作。不过，这是否有意义取决于:

决定是否要使特定任务(或功能)成为 NSOperation取决于以下考虑:

“操作”是合理的，如果该任务可能需要很长时间才能完成(从用户的角度来看)，因此您(作为开发人员)希望用户有机会取消该任务:(您记住:异步操作有主要方法 cancel )

另一个原因是将操作与特定的执行上下文相关联，该执行上下文本身与特定的共享和有限的系统资源相关联 - 如 CPU、内存、IO 等。这使您可以控制例如需要特定操作的并行执行操作的数量系统资源。假设您有一个“磁盘绑定(bind)”任务。在这种情况下，您可以创建一个 NSOperationQueue其并发操作数为 1，并为其指定一个特定的“角色”和一个合适的名称，例如“DiskBoundQueue”。队列帮助您控制操作的创建和启动，并强制限制并行执行操作的数量，以便不会耗尽受限制的系统资源。然后，将“磁盘绑定(bind)”操作仅添加到专用的“DiskBoundQueue”。由于同时从不同的任务访问磁盘时，磁盘的操作不是最佳的，因此并发操作的数量设置为 1。也就是说，这种专用队列有助于优化系统资源的利用率。

如果操作之间存在依赖关系，假设您只想在操作 A AND 操作 B 成功完成后才开始操作 C。 NSOperation提供一种建立这种依赖关系的方法。

另一个原因可能是控制对共享资源的并发访问:如果有多个操作访问某个共享资源(例如 ivar)，这些操作被添加到串行 NSOperationQueue ，对共享资源的访问是序列化的，因此是“线程安全的”。但是，如果并发是唯一的要求，我更愿意使用利用调度队列和块的更简单的方法。

因此，为了更准确地回答您的问题:不，是 NSOperation可能会超大。您最好使用专用的调度队列，可能是一个串行队列，它也解决了共享资源的并发访问。

At the same subject I have a custom generic XMLParser class that gets a NSData and parse it to NSDictionary, and I would like to use it for all of the responses, how can I integrate it in the AFHTTPClient AFHTTPRequestOperation so that the response will be already parsed?

一种可行的方法是在 AFHTTPRequestOperation 的完成处理程序中启动 XML 解析器。或 AFClient 例如。

如果您有另一个依赖于 XML 解析器结果的操作，那么一种方法是将 XML 解析器封装在 NSOperation 中。 ，然后使其他操作依赖于 XML 解析器操作。 (不过，对于此类依赖项，还有其他更简单的解决方案)