Fitur ASIHTTPRequest utama apa yang hilang dari AFNetworking?

Dengan pekerjaan yang baru-baru ini berhenti di ASIHTTPRequest , sepertinya perhatian beralih ke AFNetworking .

Namun, saya belum menemukan perbandingan yang baik dari fitur-fitur kedua perpustakaan, jadi saya tidak tahu apa yang mungkin hilang jika / ketika saya beralih.

Perbedaan utama yang saya temukan sejauh ini adalah:

1. AFNetworking memiliki ukuran kode yang jauh lebih kecil (yang bagus)
2. AFNetworking sedang ditingkatkan dengan cepat (jadi mungkin belum matang, mungkin belum memiliki API yang stabil?)
3. Keduanya tampaknya memiliki cache, meskipun saya telah melihat petunjuk bahwa karena AFNetworking menggunakan NSURLConnection, itu tidak akan menyimpan objek lebih dari 50K.
4. ASIHTTPRequest memiliki dukungan yang sangat baik untuk proxy http manual & otomatis (PAC); Saya tidak dapat menemukan informasi apa pun tentang tingkat dukungan yang dimiliki AFNetworking untuk proxy
5. AFNetworking membutuhkan iOS 4+, sedangkan ASIHTTPRequest berfungsi kembali ke iOS 2 (tidak benar-benar menjadi masalah bagi saya, tetapi ini adalah masalah bagi sebagian orang)
6. AFNetworking belum (belum) memiliki cache persisten bawaan, tetapi ada cache persisten yang memiliki permintaan penarikan tertunda: https://github.com/gowalla/AFNetworking/pull/25

Adakah yang pernah melihat perbandingan yang baik dari dua perpustakaan atau pengalaman terdokumentasi dari satu perpustakaan ke yang lain?

Saya menyukai ASIHTTPRequest dan saya sedih melihatnya pergi. Namun, pengembang ASI benar, ASIHTTPRequest telah menjadi sangat besar dan membengkak bahkan dia tidak dapat mencurahkan waktu untuk membuatnya setara dengan fitur terbaru iOS dan kerangka kerja lainnya. Saya pindah dan sekarang menggunakan AFNetworking.

Meskipun demikian, saya harus mengatakan bahwa AFNetworking jauh lebih tidak stabil daripada ASIHTTP, dan untuk hal-hal yang saya gunakan, perlu penyempurnaan.

Saya sering kali perlu membuat permintaan HTTP ke 100 sumber HTTP sebelum saya menampilkan hasil saya di layar, dan saya telah meletakkan AFHTTPNetworkOperation ke dalam antrian operasi. Sebelum semua hasil diunduh, saya ingin dapat membatalkan semua operasi di dalam antrian operasi dan kemudian menutup pengontrol tampilan yang menyimpan hasil.

Itu tidak selalu berhasil.

Saya mengalami crash secara acak dengan AFNetworking, sementara dengan ASIHTTPRequest, operasi ini bekerja dengan sempurna. Saya berharap saya bisa mengatakan bagian tertentu dari AFNetworking yang crash, karena terus crash pada titik yang berbeda (namun, sebagian besar kali ini debugger menunjuk ke NSRunLoop yang membuat objek NSURLConnection). Jadi, AFNetworking harus matang agar dianggap selengkap ASIHTTPRequest dulu.

Juga, ASIHTTPRequests mendukung otentikasi klien, yang tidak dimiliki AFNetworking saat ini. Satu-satunya cara untuk mengimplementasikannya adalah dengan subclass AFHTTPRequestOperation dan mengganti metode otentikasi NSURLConnection. Namun, jika Anda mulai terlibat dengan NSURLConnection, Anda akan melihat bahwa meletakkan NSURLConnection di dalam pembungkus NSOperation dan menulis blok penyelesaian tidak sesulit kedengarannya dan Anda akan mulai berpikir apa yang membuat Anda tidak membuang pustaka pihak ketiga.

ASI menggunakan pendekatan yang sangat berbeda, karena menggunakan CFNetworking (kerangka kerja dasar tingkat rendah berdasarkan C) untuk memungkinkan pengunduhan dan pengunggahan file, melewatkan NSURLConnection sepenuhnya, dan menyentuh konsep yang kebanyakan dari kita pengembang OS X dan iOS terlalu takut untuk melakukannya. Karena itu, Anda mendapatkan pengunggahan dan pengunduhan file yang lebih baik, bahkan cache halaman web.

Mana yang saya sukai? Sulit untuk mengatakannya. Jika AFNetworking cukup matang, saya akan menyukainya lebih dari ASI. Sampai saat itu, saya tidak bisa tidak mengagumi ASI, dan cara ini menjadi salah satu kerangka kerja yang paling banyak digunakan sepanjang masa untuk OS X dan iOS.

EDIT: Saya pikir sudah waktunya untuk memperbarui jawaban ini, karena banyak hal telah berubah sedikit setelah posting ini.

Postingan ini ditulis beberapa waktu lalu, dan AFNetworking sudah cukup matang. 1-2 bulan yang lalu AF memposting pembaruan kecil untuk operasi POST yang merupakan keluhan terakhir saya tentang kerangka kerja (kesalahan akhir baris kecil adalah alasan mengapa unggahan echonest gagal dengan AF tetapi diselesaikan dengan baik dengan ASI). Otentikasi bukanlah masalah dengan AFnetworking, karena untuk metode otentikasi yang kompleks Anda dapat melakukan subkelas operasi dan membuat panggilan Anda sendiri dan AFHTTPClient membuat otentikasi dasar menjadi sangat mudah. Dengan subclass AFHTTPClient Anda dapat membuat seluruh layanan konsumen dalam waktu singkat.

Belum lagi tambahan UIImage yang benar-benar diperlukan yang ditawarkan AFNetworking. Dengan blok dan blok penyelesaian khusus dan beberapa algoritma pintar, Anda dapat membuat tampilan tabel dengan pengunduhan gambar asinkron dan pengisian sel dengan cukup mudah, sedangkan di ASI Anda harus membuat antrean operasi untuk pelambatan bandwidth dan memikirkan diri Anda sendiri untuk membatalkan dan melanjutkan antrean operasi sesuai dengan visibilitas tampilan tabel, dan hal-hal seperti itu. Waktu pengembangan operasi semacam itu telah dibelah dua.

Saya juga menyukai penghambat kesuksesan dan kegagalan. ASI hanya memiliki satu blok penyelesaian (yang sebenarnya merupakan blok penyelesaian NSOperation). Anda harus memeriksa apakah Anda memiliki kesalahan dalam penyelesaian dan bertindak sesuai. Untuk layanan web yang kompleks, Anda bisa tersesat di semua "jika" dan "lainnya"; Dalam AFNetworking, segala sesuatunya jauh lebih sederhana dan intuitif.

ASI sangat bagus untuk masanya, tetapi dengan AF Anda dapat mengubah cara Anda menangani layanan web sepenuhnya dengan cara yang baik, dan membuat aplikasi yang dapat diskalakan dengan lebih mudah. Saya sangat percaya bahwa tidak ada alasan apa pun untuk tetap menggunakan ASI, kecuali jika Anda ingin menargetkan iOS 3 ke bawah.

Baru saja menyelesaikan proyek di mana saya menggunakan AFNetworking alih-alih ASI. Telah menggunakan ASI pada proyek sebelumnya; itu sangat membantu di masa lalu.

Inilah AFNetworking yang hilang (mulai hari ini) yang harus Anda ketahui:

• Tidak ada

ASI akan dihentikan . Gunakan AF sekarang. Ini kecil, berhasil, dan akan terus didukung. Ini juga diatur lebih logis, terutama untuk klien API. Ini memiliki sejumlah kelas bagus untuk kasus khusus yang sering digunakan seperti pemuatan gambar yang tidak sinkron dalam tampilan tabel.

AFNetworking tidak mendukung clientCertificateIdentity dan clientCertificates untuk otentikasi klien TLS.

Kita dapat melakukannya dengan - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challengemetode dalam subclass AFURLConnectionOperation tetapi itu tidak semudah itu.

Saya telah menggunakan ASI * untuk beberapa waktu sekarang dan saya sangat menyukai pendekatan fileupload dari ASI, dan meskipun saya bersemangat untuk beralih ke AFNetworking, dukungan fileupload di AfNetworking tidak semudah digunakan dibandingkan dengan ASI *.

Hingga saat ini saya tidak dapat menemukan cara untuk mengatur batas waktu dengan AFNetworking saat melakukan permintaan POST sinkron . PEMBARUAN: Saya akhirnya menemukan: https://stackoverflow.com/a/8774125/601466
Sekarang beralih ke AFNetworking:]

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

Apple mengganti batas waktu untuk POST, mengaturnya menjadi 240 detik (jika diatur lebih pendek dari 240 detik), dan Anda tidak dapat mengubahnya. Dengan ASIHTTP Anda cukup menyetel batas waktu dan berfungsi.

Contoh kode dengan permintaan POST sinkron:

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;

Saya mencoba menetapkan waktu tunggu di sini, tetapi tidak ada yang berhasil. Masalah ini membuat saya tidak dapat bermigrasi ke AFNetworking.

Lihat juga di sini: Cara mengatur waktu tunggu dengan AFNetworking

AFNetwork tidak memiliki kemampuan untuk mengupload file besar. Ini mengasumsikan konten file dalam RAM. ASI cukup pintar untuk melakukan streaming konten file dari disk.

Di ASIHTTP saya senang bisa melampirkan kamus userinfo untuk permintaan individu. Sejauh yang saya lihat, tidak ada dukungan langsung untuk ini AFHTTPRequestOperation. Adakah yang sudah menemukan solusi yang elegan? Terlepas dari subclassing yang sepele tentunya.

AFNetworking bekerja dengan "blok" yang lebih alami bagi saya daripada bekerja dengan delegasi seperti yang dilakukan ASIHTTPRequest.

Bekerja dengan blok seperti bekerja dengan Fungsi Anonim di javascript.