我喜欢ASIHTTPRequest,我很难过看到它。然而,ASI的开发者是正确的,ASIHTTPRequest已经变得如此庞大和臃肿,以至于他无法花时间将其与iOS和其他框架的最新特性相提并论。我继续前进,现在使用AFNetworking。
也就是说,我必须说AFNetworking比ASIHTTP更不稳定,而且对于我使用它的东西,它需要改进。
我在屏幕上显示我的结果之前,经常需要向100个HTTP源发出HTTP请求,并且我已将AFHTTPNetworkOperation放入操作队列中。在下载所有结果之前,我希望能够取消操作队列中的所有操作,然后关闭包含结果的视图控制器。
这并不总是奏效。
随着AFNetworking在随机时间发生崩溃,而ASIHTTPRequest,这项操作完美无缺。我希望我可以说AFNetworking的哪个特定部分崩溃,因为它在不同的点上一直崩溃(但是,大多数时候调试器指向创建NSURLConnection对象的NSRunLoop)。因此,AFNetworking需要成熟才能像ASIHTTPRequest一样被认为是完整的。
此外,ASIHTTPRequests支持客户端认证,AFNetworking目前缺乏。实现它的唯一方法是继承AFHTTPRequestOperation并覆盖NSURLConnection的身份验证方法。但是,如果您开始涉足NSURLConnection,您会注意到将NSURLConnection放入NSOperation包装器并写入完成块并不像听起来那么困难,您会开始思考是什么让您无法转储第三方库。
ASI使用了一种完全不同的方法,因为它使用CFNetworking(基于C的更低级别的基础框架)来完成下载和文件上传,完全跳过NSURLConnection以及触摸我们大多数人的概念OS X和iOS开发人员也是如此害怕。正因为如此,你可以更好地上传和下载文件,甚至是网页缓存。
我更喜欢哪一种?这很难说。如果AFNetworking足够成熟,我会比ASI更喜欢它。在此之前,我不禁赞赏ASI,以及它成为OS X和iOS所有时间最常用的框架之一。
编辑: 我觉得是时候更新这个答案,因为事情已经这篇文章后改变了一点。
这篇文章是前段时间写的,AFNetworking已经够成熟了。 1个月前AF发布了POST操作的一个小更新,这是我对框架的最后一次投诉(小行结束错误是因为AF上传失败,但在ASI中完成正常)。身份验证不是AF网络的问题,对于复杂的身份验证方法,您可以对操作进行子分类并创建自己的呼叫,AFHTTPClient使基本身份验证成为小菜一碟。通过继承AFHTTPClient,您可以在很短的时间内创建一个完整的服务使用者。
更不用说AFNetworking提供的绝对必要的UIImage补充。通过块和自定义完成块以及一些聪明的算法,您可以非常容易地实现异步映像下载和单元填充的表格视图,而在ASI中,您必须针对带宽限制设置操作队列,并介意取消并恢复操作队列表格视图可见性以及类似的东西。这类行动的开发时间减半。
我也喜欢成功和失败的块。 ASI只有一个完成块(实际上是NSOperation的完成块)。您必须检查完成时是否出现错误并采取相应措施。对于复杂的Web服务,您可能会迷失在所有“ifs”和“elses”中;在AFNetworking中,事情更加简单直观。
ASI当时非常棒,但通过自动对焦,您可以更好地改变处理Web服务的方式,并且更轻松地制作可扩展的应用程序。我真的相信没有任何理由继续坚持使用ASI,除非你想要瞄准iOS 3和更低版本。
AFNetworking缺乏非常详细的文档和示例,所以我不能多说这些。我使用ASIHTTPRequest的主要原因是因为它支持iOS 3.0和'ASIFallbackToCacheIfLoadFailsCachePolicy'非常好。而且,我认为AFNetworking没有持久的缓存支持。这对我来说是不行的。 – iwat
只需注意您是第一个用'afnetworking'标记问题的人。 – iwat
有一个等待被拉入AFNetworking的缓存,我在我的问题中添加了一个链接。 – JosephH