AFNetworking 缺少哪些主要的 ASIHTTPRequest 功能? [英] What major ASIHTTPRequest features is AFNetworking missing?

问题描述

使用 最近在 ASIHTTPRequest 上停止工作，似乎注意力正在转移到 AFNetworking.

With work having recently stopped on ASIHTTPRequest, it seems like attention is shifting to AFNetworking.

但是，我还没有找到两个库的功能的很好的比较，所以我不知道如果/当我切换时我可能会失去什么.

However, I've not yet found a good comparison of the features of the two libraries, so I don't know what I might lose if/when I switch over.

到目前为止我发现的主要区别是:

Major differences I've spotted so far are:

1. AFNetworking 的代码量要小得多(这很好)
2. AFNetworking 正在迅速改进(所以它可能还不成熟，可能还没有稳定的 API?)
3. 两者似乎都有缓存，尽管我看到了一些提示，因为 AFNetworking 使用 NSURLConnection 它不会缓存超过 50K 的对象
4. ASIHTTPRequest 对手动& 有很好的支持自动 (PAC) http 代理；我找不到有关 AFNetworking 对代理的支持级别的任何信息
5. AFNetworking 需要 iOS 4+，而 ASIHTTPRequest 可以直接返回到 iOS 2(对我来说不是问题，但对某些人来说是问题)
6. AFNetworking(还)没有内置的持久缓存，但有一个持久缓存，它有一个挂起的拉取请求:https://github.com/gowalla/AFNetworking/pull/25

有没有人看到过对这两个库的任何很好的比较，或者任何从一个库切换到另一个库的记录经验?

Has anyone seen any good comparisons of the two libraries or any documented experiences of switching from one to the other?

推荐答案

我喜欢 ASIHTTPRequest，但看到它消失我很难过.然而，ASI 的开发者是对的，ASIHTTPRequest 变得如此庞大和臃肿，以至于他甚至无法花时间将其与 iOS 和其他框架的最新功能相提并论.我继续前进，现在使用 AFNetworking.

I loved ASIHTTPRequest and I was sad to see it go. However, the developer of ASI was right, ASIHTTPRequest has become so large and bloated that even he couldn't devote time to bring it to par with newest features of iOS and other frameworks. I moved on and now use AFNetworking.

也就是说，我必须说 AFNetworking 比 ASIHTTP 不稳定得多，对于我用它做的事情，它需要改进.

That said, I must say that AFNetworking is much more unstable than ASIHTTP, and for the things I use it for, it needs refinement.

在屏幕上显示结果之前，我经常需要向 100 个 HTTP 源发出 HTTP 请求，并且我已将 AFHTTPNetworkOperation 放入操作队列.在下载所有结果之前，我希望能够取消操作队列中的所有操作，然后关闭保存结果的视图控制器.

I often need to make HTTP requests to 100 HTTP sources before I display my results on screen, and I have put AFHTTPNetworkOperation into an operation queue. Before all results are downloaded, I want to be able to cancel all operations inside the operation queue and then dismiss the view controller that holds the results.

这并不总是有效.

我在使用 AFNetworking 时会随机崩溃，而使用 ASIHTTPRequest 时，此操作完美无缺.我希望我能说出 AFNetworking 的哪个特定部分崩溃，因为它在不同的点不断崩溃(但是，大多数情况下，调试器指向创建 NSURLConnection 对象的 NSRunLoop).因此，AFNetworking 需要成熟才能像 ASIHTTPRequest 一样完整.

I get crashes at random times with AFNetworking, while with ASIHTTPRequest, this operations were working flawlessly. I wish I could say which specific part of AFNetworking is crashing, as it keeps crashing at different points (however, most of these times the debugger points to the NSRunLoop that creates an NSURLConnection object). So, AFNetworking needs to mature in order to be considered as complete as ASIHTTPRequest was.

此外，ASIHTTPRequests 支持客户端身份验证，AFNetworking 目前缺乏这种身份验证.实现它的唯一方法是继承 AFHTTPRequestOperation 并覆盖 NSURLConnection 的身份验证方法.但是，如果您开始使用 NSURLConnection，您会注意到将 NSURLConnection 放在 NSOperation 包装器中并编写完成块并不像听起来那么难，您会开始思考是什么阻止了您转储第 3 方库.

Also, ASIHTTPRequests supports client authentication, which AFNetworking lacks at the moment. The only way to implement it is to subclass AFHTTPRequestOperation and to override NSURLConnection's authentication methods. However, if you start getting involved with NSURLConnection, you will notice that putting NSURLConnection inside an NSOperation wrapper and writing completion blocks isn't so hard as it sounds and you will start thinking what keeps you from dumping 3rd party libraries.

ASI 使用完全不同的方法，因为它使用 CFNetworking(基于 C 的低级基础框架)使下载和文件上传成为可能，完全跳过 NSURLConnection，并且触及我们大多数 OS X 和 iOS 开发人员都太害怕的概念到.因此，您可以获得更好的文件上传和下载，甚至是网页缓存.

ASI uses a whole different approach, since it uses CFNetworking (lower-level foundation frameworks based on C) to make downloading and file uploading possible, skipping NSURLConnection completely, and touching concepts most of us OS X and iOS developers are too afraid to. Because of this, you get better file uploading and downloading, even web page caches.

我更喜欢哪个?很难说.如果 AFNetworking 足够成熟，我会比 ASI 更喜欢它.在那之前，我不得不佩服 ASI，以及它成为 OS X 和 iOS 有史以来最常用的框架之一的方式.

Which do i prefer? It's hard to say. If AFNetworking matures enough, I will like it more than ASI. Until then, I can't help but admire ASI, and the way it became one of the most used frameworks of all time for OS X and iOS.

我认为是时候更新这个答案了，因为在这篇文章之后情况发生了一些变化.

这个帖子是前段时间写的，AFNetworking已经足够成熟了.1-2 个月前 AF 发布了一个 POST 操作的小更新，这是我对框架的最后一次抱怨(一个小行结束错误是 AF 的 echonest 上传失败但使用 ASI 完成的原因).身份验证不是 AFnetworking 的问题，对于复杂的身份验证方法，您可以将操作子类化并进行自己的调用，而 AFHTTPClient 使基本身份验证变得轻而易举.通过继承 AFHTTPClient，您可以在很短的时间内创建一个完整的服务消费者.

This post was written some time ago, and AFNetworking has matured enough. 1-2 months ago AF posted a small update for POST operations that was my last complaint about the framework (a small line ending fault was the reason that echonest uploads failed with AF but were completed fine with ASI). Authentication is not an issue with AFnetworking, as for complex authentication methods you can subclass the operation and make your own calls and AFHTTPClient makes basic authentication a piece of cake. By subclassing AFHTTPClient you can make an entire service consumer in little time.

更不用说 AFNetworking 提供的绝对必要的 UIImage 附加功能.使用块和自定义完成块以及一些巧妙的算法，您可以非常轻松地制作具有异步图像下载和单元格填充的表格视图，而在 ASI 中，您必须制作操作队列以进行带宽限制，并注意根据以下情况取消和恢复操作队列表视图可见性，以及类似的东西.此类操作的开发时间已减半.

Not to mention the absolutely necessary UIImage additions that AFNetworking offers. With blocks and custom completion blocks and some clever algorithm, you can make table views with asynchronous image downloading and cell filling pretty easily, whereas in ASI you had to make operation queues for bandwidth throttling and mind yourself to cancel and resume the operation queue according to table view visibility, and stuff like that. Development time of such operations has been halved.

我也喜欢成功和失败块.ASI只有一个完成块(其实就是NSOperation的完成块).您必须检查完成时是否有错误并采取相应措施.对于复杂的 Web 服务，您可能会迷失在所有的ifs"和else"中；在 AFNetworking 中，事情变得更加简单和直观.

I also love the success and failure blocks. ASI has only a completion block (which is actually the completion block of NSOperation). You had to check whether you had an error on completion and act accordingly. For complex web services, you could get lost in all the "ifs" and "elses"; In AFNetworking, things are much more simple and intuitive.

ASI 在那个时代非常棒，但是使用 AF，您可以以一种好的方式完全改变处理 Web 服务的方式，并更轻松地制作可扩展的应用程序.我真的相信没有任何理由再坚持使用 ASI，除非您想针对 iOS 3 及更低版本.

ASI was great for its time, but with AF you can change the way you handle web services completely in a good way, and make scalable applications more easily. I really believe that there is no reason whatsoever to stick with ASI anymore, unless you want to target iOS 3 and below.

这篇关于AFNetworking 缺少哪些主要的 ASIHTTPRequest 功能?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！