Quais são os principais recursos ASIHTTPRequest que o AFNetworking está faltando?

Como o trabalho foi interrompido recentemente em ASIHTTPRequest , parece que a atenção está mudando para AFNetworking .

No entanto, ainda não encontrei uma boa comparação dos recursos das duas bibliotecas, então não sei o que posso perder se / quando mudar.

As principais diferenças que identifiquei até agora são:

1. AFNetworking tem um tamanho de código muito menor (o que é bom)
2. AFNetworking está sendo aprimorado rapidamente (então pode ainda não estar maduro, pode não ter uma API estável ainda?)
3. Ambos parecem ter cache, embora eu tenha visto dicas de que, como o AFNetworking usa NSURLConnection, ele não armazena em cache objetos acima de 50K
4. ASIHTTPRequest tem um suporte muito bom para proxies http manuais e automáticos (PAC); Não consigo encontrar nenhuma informação sobre o nível de suporte que AFNetworking tem para proxies
5. AFNetworking requer iOS 4+, enquanto ASIHTTPRequest funciona desde o iOS 2 (não é realmente um problema para mim, mas é um problema para algumas pessoas)
6. AFNetworking (ainda) não tem um cache persistente integrado, mas há um cache persistente que tem uma solicitação de pull pendente: https://github.com/gowalla/AFNetworking/pull/25

Alguém viu boas comparações das duas bibliotecas ou alguma experiência documentada de troca de uma para a outra?

Eu adorei ASIHTTPRequest e fiquei triste em vê-lo ir embora. No entanto, o desenvolvedor do ASI estava certo, ASIHTTPRequest se tornou tão grande e inchado que nem mesmo ele poderia dedicar tempo para torná-lo compatível com os recursos mais novos do iOS e outras estruturas. Eu mudei e agora uso AFNetworking.

Dito isso, devo dizer que AFNetworking é muito mais instável do que ASIHTTP, e para as coisas para as quais eu o uso, ele precisa de refinamento.

Freqüentemente, preciso fazer solicitações HTTP para 100 fontes HTTP antes de exibir meus resultados na tela e coloquei AFHTTPNetworkOperation em uma fila de operação. Antes de todos os resultados serem baixados, quero poder cancelar todas as operações dentro da fila de operações e, em seguida, dispensar o controlador de visualização que contém os resultados.

Isso nem sempre funciona.

Eu recebo travamentos em momentos aleatórios com AFNetworking, enquanto com ASIHTTPRequest, essas operações estavam funcionando perfeitamente. Eu gostaria de poder dizer qual parte específica do AFNetworking está travando, já que continua travando em pontos diferentes (no entanto, na maioria das vezes o depurador aponta para o NSRunLoop que cria um objeto NSURLConnection). Portanto, AFNetworking precisa amadurecer para ser considerado tão completo quanto ASIHTTPRequest era.

Além disso, ASIHTTPRequests oferece suporte à autenticação de cliente, que falta no AFNetworking no momento. A única maneira de implementá-lo é subclassificar AFHTTPRequestOperation e substituir os métodos de autenticação de NSURLConnection. No entanto, se você começar a se envolver com NSURLConnection, notará que colocar NSURLConnection dentro de um wrapper NSOperation e escrever blocos de conclusão não é tão difícil quanto parece e você começará a pensar no que o impede de despejar bibliotecas de terceiros.

ASI usa uma abordagem totalmente diferente, uma vez que usa CFNetworking (estruturas básicas de nível inferior baseadas em C) para fazer download e upload de arquivos possível, ignorando NSURLConnection completamente e tocando os conceitos que muitos de nós, desenvolvedores de OS X e iOS, temos muito medo de fazer. Por causa disso, você obtém um melhor upload e download de arquivos, até mesmo caches de páginas da web.

Qual eu prefiro? É difícil dizer. Se AFNetworking amadurecer o suficiente, vou gostar mais do que ASI. Até então, não posso deixar de admirar o ASI, e a maneira como ele se tornou um dos frameworks mais usados ​​de todos os tempos para OS X e iOS.

EDIT: Acho que é hora de atualizar essa resposta, pois as coisas mudaram um pouco depois desse post.

Esta postagem foi escrita há algum tempo e a AFNetworking amadureceu o suficiente. 1-2 meses atrás, o AF postou uma pequena atualização para operações POST que foi minha última reclamação sobre o framework (uma pequena falha de finalização de linha foi a razão pela qual os uploads echonest falharam com AF, mas foram concluídos sem problemas com ASI). A autenticação não é um problema com AFnetworking, pois para métodos de autenticação complexos você pode criar uma subclasse da operação e fazer suas próprias chamadas e AFHTTPClient torna a autenticação básica um pedaço de bolo. Ao criar uma subclasse de AFHTTPClient, você pode tornar um consumidor de serviço inteiro em pouco tempo.

Sem mencionar as adições UIImage absolutamente necessárias que a AFNetworking oferece. Com blocos e blocos de conclusão personalizados e algum algoritmo inteligente, você pode fazer visualizações de tabela com download de imagens assíncronas e preenchimento de células com bastante facilidade, enquanto em ASI você tinha que fazer filas de operação para limitação de largura de banda e se preocupar em cancelar e retomar a fila de operação de acordo com visibilidade da visualização da mesa e coisas assim. O tempo de desenvolvimento de tais operações foi reduzido pela metade.

Eu também adoro os blocos de sucesso e fracasso. ASI tem apenas um bloco de conclusão (que é realmente o bloco de conclusão de NSOperation). Você tinha que verificar se havia um erro na conclusão e agir de acordo. Para serviços da Web complexos, você pode se perder em todos os "ses" e "outros"; Na AFNetworking, as coisas são muito mais simples e intuitivas.

O ASI era ótimo para a época, mas com o AF você pode mudar completamente a maneira como lida com os serviços da web de uma maneira boa e tornar os aplicativos escaláveis ​​com mais facilidade. Eu realmente acredito que não há mais razão para continuar com o ASI, a menos que você queira usar o iOS 3 e versões anteriores.

Estou terminando um projeto em que estou usando AFNetworking em vez de ASI. Ter usado ASI em projetos anteriores; tem sido uma grande ajuda no passado.

Aqui está o que está faltando AFNetworking (a partir de hoje) que você deve saber:

• Nada

ASI está indo embora . Use AF agora. É pequeno, funciona e continuará a ter suporte. Também é organizado de forma mais lógica, especialmente para clientes API. Ele tem várias classes excelentes para casos especiais frequentemente usados, como carregamento assíncrono de imagens em visualizações de tabela.

AFNetworking não oferece suporte a clientCertificateIdentity e clientCertificates para autenticação de cliente TLS.

Podemos fazer isso com o - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challengemétodo em uma subclasse de AFURLConnectionOperation, mas não é tão fácil.

Estou usando ASI * há um tempo e adoro a abordagem de fileupload do ASI e, embora esteja animado para pular para AFNetworking, o suporte de fileupload em AfNetworking não é tão fácil de usar em comparação com ASI *.

Até agora, não consegui descobrir como definir um tempo limite com AFNetworking ao fazer uma solicitação POST síncrona . ATUALIZAÇÃO: finalmente descobri: https://stackoverflow.com/a/8774125/601466
Agora mudando para AFNetworking:]

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

A Apple substitui o tempo limite de um POST, definindo-o para 240 segundos (caso tenha sido definido mais curto que 240 segundos), e você não pode alterá-lo. Com ASIHTTP você apenas define um tempo limite e funciona.

Um exemplo de código com uma solicitação POST síncrona:

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;

Tentei definir um tempo limite aqui, mas nada funcionou. Esse problema me impede de migrar para AFNetworking.

Veja também aqui: Como definir um tempo limite com AFNetworking

AFNetwork não tem a capacidade de fazer upload de arquivos grandes. Ele assume que o conteúdo do arquivo está na RAM. ASI foi inteligente o suficiente para simplesmente transmitir o conteúdo do arquivo do disco.

No ASIHTTP, adorei poder anexar um dicionário de informações do usuário a solicitações individuais. Pelo que vejo, não há suporte direto para isso em AFHTTPRequestOperation. Alguém já descobriu uma solução alternativa elegante? Além da subclasse trivial, é claro.

AFNetworking funciona com "blocos", o que é mais natural para mim do que trabalhar com delegados como o ASIHTTPRequest faz.

Trabalhar com blocos é como trabalhar com função anônima em javascript.