Quali caratteristiche principali di ASIHTTPRequest manca AFNetworking?

Con il lavoro recentemente interrotto su ASIHTTPRequest , sembra che l'attenzione si stia spostando su AFNetworking .

Tuttavia, non ho ancora trovato un buon confronto tra le caratteristiche delle due librerie, quindi non so cosa potrei perdere se / quando cambio.

Le principali differenze che ho notato finora sono:

1. AFNetworking ha una dimensione del codice molto più piccola (che è buona)
2. AFNetworking viene rapidamente migliorato (quindi potrebbe non essere ancora maturo, potrebbe non avere ancora un'API stabile?)
3. Entrambi sembrano avere la memorizzazione nella cache, anche se ho visto suggerimenti che poiché AFNetworking utilizza NSURLConnection non memorizzerà nella cache oggetti superiori a 50K
4. ASIHTTPRequest ha un ottimo supporto per proxy http manuali e automatici (PAC); Non riesco a trovare alcuna informazione sul livello di supporto di AFNetworking per i proxy
5. AFNetworking richiede iOS 4+, mentre ASIHTTPRequest funziona direttamente su iOS 2 (non è davvero un problema per me, ma è un problema per alcune persone)
6. AFNetworking non ha (ancora) una cache persistente incorporata, ma c'è una cache persistente che ha una richiesta pull in sospeso: https://github.com/gowalla/AFNetworking/pull/25

Qualcuno ha visto qualche buon confronto tra le due biblioteche o esperienze documentate di passaggio dall'una all'altra?

Ho adorato ASIHTTPRequest ed ero triste di vederlo andare. Tuttavia, lo sviluppatore di ASI aveva ragione, ASIHTTPRequest è diventato così grande e gonfio che nemmeno lui poteva dedicare tempo per portarlo alla pari con le nuove funzionalità di iOS e altri framework. Sono andato avanti e ora uso AFNetworking.

Detto questo, devo dire che AFNetworking è molto più instabile di ASIHTTP e, per le cose per cui lo uso, necessita di raffinamento.

Ho spesso bisogno di effettuare richieste HTTP a 100 sorgenti HTTP prima di visualizzare i miei risultati sullo schermo e ho inserito AFHTTPNetworkOperation in una coda di operazioni. Prima che tutti i risultati vengano scaricati, voglio essere in grado di annullare tutte le operazioni all'interno della coda delle operazioni e quindi chiudere il controller di visualizzazione che contiene i risultati.

Non sempre funziona.

Ottengo arresti anomali in momenti casuali con AFNetworking, mentre con ASIHTTPRequest, queste operazioni stavano funzionando perfettamente. Vorrei poter dire quale parte specifica di AFNetworking si sta bloccando, poiché continua a bloccarsi in punti diversi (tuttavia, la maggior parte di queste volte il debugger punta a NSRunLoop che crea un oggetto NSURLConnection). Quindi, AFNetworking deve maturare per essere considerato completo come lo era ASIHTTPRequest.

Inoltre, ASIHTTPRequests supporta l'autenticazione del client, di cui AFNetworking manca al momento. L'unico modo per implementarlo è creare una sottoclasse AFHTTPRequestOperation e sovrascrivere i metodi di autenticazione di NSURLConnection. Tuttavia, se inizi a essere coinvolto con NSURLConnection, noterai che inserire NSURLConnection all'interno di un wrapper NSOperation e scrivere blocchi di completamento non è così difficile come sembra e inizierai a pensare a cosa ti impedisce di scaricare librerie di terze parti.

ASI utilizza un approccio completamente diverso, poiché utilizza CFNetworking (framework di base di livello inferiore basati su C) per rendere possibile il download e il caricamento di file, saltando completamente la connessione NSURLC e toccando concetti che la maggior parte di noi sviluppatori OS X e iOS ha troppa paura. Per questo motivo, ottieni un caricamento e un download di file migliori, anche la cache delle pagine web.

Quale preferisco? È difficile da dire. Se AFNetworking matura abbastanza, mi piacerà più dell'ASI. Fino ad allora, non posso fare a meno di ammirare ASI e il modo in cui è diventato uno dei framework più utilizzati di tutti i tempi per OS X e iOS.

EDIT: Penso che sia ora di aggiornare questa risposta, poiché le cose sono cambiate un po 'dopo questo post.

Questo post è stato scritto tempo fa e AFNetworking è maturato abbastanza. 1-2 mesi fa AF ha pubblicato un piccolo aggiornamento per le operazioni POST che è stata la mia ultima lamentela sul framework (un piccolo errore di fine riga è stata la ragione per cui i caricamenti più onesti non sono riusciti con AF ma sono stati completati bene con ASI). L'autenticazione non è un problema con AFnetworking, poiché per i metodi di autenticazione complessi è possibile sottoclassare l'operazione ed effettuare le proprie chiamate e AFHTTPClient rende l'autenticazione di base un gioco da ragazzi. Sottoclassando AFHTTPClient puoi rendere un intero consumatore di servizi in poco tempo.

Per non parlare delle aggiunte assolutamente necessarie a UIImage offerte da AFNetworking. Con blocchi e blocchi di completamento personalizzati e alcuni algoritmi intelligenti, puoi creare visualizzazioni di tabelle con download asincrono di immagini e riempimento di celle abbastanza facilmente, mentre in ASI dovevi creare code di operazioni per la limitazione della larghezza di banda e badare a te stesso di annullare e riprendere la coda di operazioni in base a visibilità della vista tabella e cose del genere. Il tempo di sviluppo di tali operazioni è stato dimezzato.

Amo anche i blocchi di successo e fallimento. ASI ha solo un blocco di completamento (che in realtà è il blocco di completamento di NSOperation). Dovevi controllare se avevi un errore al completamento e agire di conseguenza. Per servizi web complessi, potresti perderti in tutti i "se" e gli "altri"; In AFNetworking, le cose sono molto più semplici e intuitive.

ASI era eccezionale per i suoi tempi, ma con AF puoi cambiare completamente il modo in cui gestisci i servizi web e rendere più facilmente scalabili le applicazioni. Credo davvero che non ci sia alcun motivo per restare più fedeli all'ASI, a meno che tu non voglia scegliere come target iOS 3 e versioni precedenti.

Sto solo terminando un progetto in cui sto usando AFNetworking invece di ASI. Hanno utilizzato ASI su progetti precedenti; è stato di grande aiuto in passato.

Ecco cosa manca AFNetworking (ad oggi) che dovresti sapere:

• Niente

L'ASI se ne va . Usa AF adesso. È piccolo, funziona e continuerà a essere supportato. È anche organizzato in modo più logico, soprattutto per i client API. Ha un numero di grandi classi per casi speciali usati spesso come il caricamento asincrono di immagini nelle viste tabella.

AFNetworking non supporta clientCertificateIdentity e clientCertificates per l'autenticazione del client TLS.

Possiamo farlo con il - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challengemetodo in una sottoclasse di AFURLConnectionOperation ma non è così facile.

Uso ASI * da un po 'di tempo e adoro l'approccio di fileupload di ASI e, sebbene sia entusiasta di passare ad AFNetworking, il supporto di fileupload in AfNetworking non è così facile da usare rispetto ad ASI *.

Fino ad ora non sono riuscito a capire come impostare un timeout con AFNetworking quando si esegue una richiesta POST sincrona . AGGIORNAMENTO: Ho finalmente capito: https://stackoverflow.com/a/8774125/601466
Ora sto passando ad AFNetworking:]

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

Apple sovrascrive il timeout per un POST, impostandolo su 240 secondi (nel caso in cui fosse impostato più breve dei 240 secondi) e non è possibile modificarlo. Con ASIHTTP devi solo impostare un timeout e funziona.

Un esempio di codice con una richiesta POST sincrona:

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;

Ho provato a impostare un timeout qui, ma niente ha funzionato. Questo problema mi impedisce di migrare ad AFNetworking.

Vedi anche qui: Come impostare un timeout con AFNetworking

AFNetwork non ha la capacità di caricare file di grandi dimensioni. Si presuppone che il contenuto del file sia nella RAM. ASI era abbastanza intelligente da trasmettere semplicemente il contenuto del file dal disco.

In ASIHTTP ho apprezzato il fatto di poter allegare un dizionario userinfo alle singole richieste. Per quanto vedo non c'è supporto diretto per questo in AFHTTPRequestOperation. Qualcuno ha già trovato una soluzione elegante? A parte la banale sottoclasse ovviamente.

AFNetworking funziona con "blocchi", il che è più naturale per me che lavorare con delegati come fa ASIHTTPRequest.

Lavorare con i blocchi è come lavorare con la funzione anonima in javascript.