AFNetworking缺少哪些主要的ASIHTTPRequest功能?


93

由于最近在ASIHTTPRequest上停止了工作,看来注意力正在转移到AFNetworking

但是,我还没有很好地比较这两个库的功能,所以我不知道如果/当我切换时可能会丢失什么。

到目前为止,我发现的主要差异是:

  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

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


AFNetworking缺乏非常详细的文档和示例,因此我不能多说。我使用ASIHTTPRequest的主要原因是因为它支持iOS 3.0并且ASIFallbackToCacheIfLoadFailsCachePolicy非常好。而且,我认为AFNetworking没有持久性缓存支持。对我来说这是不行的。
iwat 2011年

请注意,您是第一个使用问题标记问题的人afnetworking
iwat 2011年

有一个缓存正等待拉入AFNetworking,我已在问题中添加了一个链接。
JosephH 2011年

1
@iwat AFNetworking完全支持NSURLCache。如果您正在寻找磁盘缓存,我会衷心建议Peter Steinberger的SDURLCache fork
mattt 2011年

2
您是否尝试过我的网络框架MKNetworkKit?blog.mugunthkumar.com/products/…基本,摘要和NTLM身份验证,自动缓存,内置图像缓存,超级容易的文​​件上传支持,出色的文档等是其中的一些优点。
Mugunth 2011年

Answers:


59

我爱ASIHTTPRequest,我很伤心看到它去。但是,ASI的开发人员是对的,ASIHTTPRequest变得如此庞大且肿,以至于他甚至都不能花时间将其与iOS和其他框架的最新功能相提并论。我继续前进,现在使用AFNetworking。

就是说,我必须说,AFNetworking比ASIHTTP更加不稳定,对于我用于AFNetworking的事情,它需要改进。

在屏幕上显示结果之前,我经常需要向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-2个月前,AF对POST操作发布了一个小更新,这是我对框架的最后一次抱怨(一小行结尾错误是AF失败回显上载,而ASI则正常完成的原因)。身份验证对于AFnetworking而言不是问题,因为对于复杂的身份验证方法,您可以将操作子类化并进行自己的调用,而AFHTTPClient则使基本身份验证变得轻而易举。通过将AFHTTPClient子类化,您可以在短时间内使整个服务使用者受益。

更不用说AFNetworking提供的绝对必要的UIImage添加。借助块和自定义完成块以及一些巧妙的算法,您可以轻松地通过异步图像下载和单元填充来创建表视图,而在ASI中,您必须为带宽节流创建操作队列,并要根据以下内容取消和恢复操作队列表格视图的可见性,诸如此类。这种操作的开发时间减少了一半。

我也喜欢成功和失败的障碍。ASI只有一个完成块(实际上是NSOperation的完成块)。您必须检查完成时是否有错误并采取相应措施。对于复杂的Web服务,您可能会迷失在所有的“ ifs”和“ elses”中;在AFNetworking中,事情变得更加简单直观。

ASI当时非常出色,但是使用AF可以很好地改变完全处理Web服务的方式,并使可伸缩应用程序更容易。我真的相信,除非您要针对iOS 3及更低版本,否则没有理由再坚持使用ASI。


1
+1非常令人感叹。也许值得将您的崩溃报告为关于stackoverflow的问题?我希望看到更多详细信息。
JosephH 2011年

谢谢。当我有关于崩溃的具体数据时,我将这样做。
csotiriou 2011年

3
稳定性问题还是个问题吗?
约翰·卡尔森

1
根据几天前我根据测试得出的初步数据,没有。不是。但是,即使使用最新版本的框架,我也有一个示例,当在一定条件下(执行立即分配/取消/立即取消/重新分配/重新分配/启动)进行一系列操作时,在AFURLConnection的运行循环上有时会崩溃。它必须与NSOperation完成块和NSRunLoop有关。我已经检查了AFNetworking的实现,找不到原因。
csotiriou 2012年

ASI确实有一个故障块。
Kekoa

17

刚完成我正在使用AFNetworking而不是ASI的项目。在以前的项目中使用过ASI;过去是很大的帮助。

您应该了解的AFNetworking缺少的内容(截至今天):

  • 没有

ASI 正在消失。立即使用自动对焦。它很小,可以正常工作,并且将继续得到支持。它还进行了更合理的组织,尤其是对于API客户端。对于常用的特殊情况(例如在表视图中异步加载图像),它具有许多很棒的类。


9
正如@iwat在该问题的与会者中提到的那样,AFNetworking缺少可靠的缓存。这很有趣并且与问题相关,因此“无”是错误的答案。除此之外,我完全同意您的观点。
肯尼·温克

1
@KennyWinker请在该评论主题中查看我的回复。我很高兴地说,AFNetworking并非按设计内置在缓存中。而是可以自由地交换他们最喜欢的NSURLCache基于解决方案的。
马特2011年

1
在任何方面-我如何在请求中使用代理?
Alex Volovoy

@AlexVolovoy您最好将其作为一个新问题提出来
JosephH 2011年

我什么也不会说。请在下面查看我的答案。
borisdiakur'1

4

AFNetworking不支持TLS客户端身份验证的clientCertificateIdentity和clientCertificates。

我们可以使用- (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challengeAFURLConnectionOperation的子类中的方法来做到这一点,但这并不容易。


5
现在,您可以setAuthenticationChallengeBlock:继续AFURLConnectionOperation其子类,并传递逻辑以根据需要处理任何身份验证挑战,而不必子类化。
mattt 2012年

2

我已经使用ASI *已有一段时间了,我绝对喜欢ASI的文件上传方法,尽管我很高兴跳到AFNetworking,但与ASI *相比,AfNetworking中的文件上传支持不那么容易使用。


2

到目前为止,我还不知道如何在执行同步POST请求时使用AFNetworking 设置超时更新:我终于想通了:https ://stackoverflow.com/a/8774125/601466现在切换到AFNetworking:]

==================

Apple会覆盖POST的超时,将其设置为240秒(如果将其设置为短于240秒),则无法更改它。使用ASIHTTP,您只需设置一个超时即可。

带有同步POST请求的代码示例:

NSDictionary *params = [NSDictionary dictionaryWithObjectsAndKeys:
                                @"doSomething", @"task",
                                @"foo", @"bar",
                                nil];

AFHTTPClient *httpClient = [[AFHTTPClient alloc] initWithBaseURL:[NSURL URLWithString:baseURL]];

NSMutableURLRequest *request = [httpClient requestWithMethod:@"POST" path:requestURL parameters:params];
[httpClient release];

AFHTTPRequestOperation *operation = [[[AFHTTPRequestOperation alloc] initWithRequest:request] autorelease];
[operation setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {}
failure:^(AFHTTPRequestOperation *operation, NSError *error) {
    NDLog(@"fail! %@", [error localizedDescription]);
}];

NSOperationQueue *queue = [[[NSOperationQueue alloc] init] autorelease];
[[AFNetworkActivityIndicatorManager sharedManager] incrementActivityCount];

[queue addOperation:operation];
[queue waitUntilAllOperationsAreFinished]; // Stuck here for at least 240 seconds!

[[AFNetworkActivityIndicatorManager sharedManager] decrementActivityCount];
if (![[operation responseString] isEqualToString:@""]) {
    return [operation responseString];
}

return nil;

我试图在此处设置超时,但没有任何效果。这个问题使我无法迁移到AFNetworking。

另请参见此处:如何使用AFNetworking设置超时


您对超时的观点很好,感谢您的分享!我不了解这与同步发出请求有何关系,您能对此进行扩展吗?
JosephH 2012年

@JosephH你是对的。当然,有时在执行异步请求时还需要设置超时。我已经更新了我的
答案

Apple解决了timeoutInterval不能少于240秒的问题,但是这仍然是一个问题,因为即使您设置了timeoutInterval,请求也不以某种方式尊重它。
Jasper 2014年

2

AFNetwork缺乏上传大文件的能力。假定文件内容在RAM中。ASI足够聪明,可以简单地从磁盘流式传输文件内容。


0

在ASIHTTP中,我喜欢将userinfo词典附加到各个请求。据我所知,尚无直接支持AFHTTPRequestOperation。有没有人想出一种优雅的解决方法?当然除了琐碎的子类化。


2
不要问答案中的问题,获得回复的机会非常低。请改用评论或新问题;)
Michal

-8

AFNetworking使用“块”工作对我而言比像使用ASIHTTPRequest这样的委托工作更自然。

使用块就像使用javascript中的匿名函数一样。


没错,但我认为这不是使用ASIHTTPRequest开发的主要方法
torhector2 2011年

7
那只是因为在编写ASIHTTP之后出现了块,所以我总是将块与ASI一起使用,而不是委托。
hypercrypt
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.