Fitur ASIHTTPRequest utama apa yang hilang dari AFNetworking?


93

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?


AFNetworking tidak memiliki dokumentasi dan contoh yang sangat rinci, jadi saya tidak bisa mengatakan banyak tentangnya. Alasan utama saya menggunakan ASIHTTPRequest karena mendukung iOS 3.0 dan ASIFallbackToCacheIfLoadFailsCachePolicysangat bagus. Dan, menurut saya AFNetworking tidak memiliki dukungan cache yang persisten. Ini adalah larangan bagi saya.
iwat

Perhatikan saja bahwa Anda adalah orang pertama yang menandai pertanyaan dengan afnetworking.
iwat

Ada cache yang menunggu untuk ditarik ke AFNetworking, saya telah menambahkan link ke pertanyaan saya.
JosephH

1
@ iwat AFNetworking mendukung penuh NSURLCache. Jika Anda mencari cache disk, saya dengan senang hati menyarankan garpu SDURLCache milik Peter Steinberger .
mattt

2
Sudahkah Anda mencoba kerangka kerja jaringan saya MKNetworkKit? blog.mugunthkumar.com/products/… Basic, Digest dan NTLM Authentication, auto-caching, built-in image caching, dukungan upload file super mudah, dokumentasi yang sangat baik adalah beberapa kelebihannya.
Mugunth

Jawaban:


59

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.


1
+1 sangat tidak masuk akal. Mungkin ada baiknya memposting kerusakan Anda sebagai pertanyaan tentang stackoverflow? Saya tertarik untuk melihat lebih detail.
JosephH

Terima kasih. Ketika saya memiliki data konkret tentang crash, saya akan melakukannya.
csotiriou

3
Apakah masalah stabilitas masih menjadi masalah?
Johan Karlsson

1
Pada data awal berdasarkan tes yang saya jalankan beberapa hari yang lalu, tidak. Ini bukan. Namun, bahkan dengan versi kerangka kerja terbaru, saya memiliki contoh yang kadang-kadang macet pada putaran run AFURLConnection ketika cukup tertekan dengan serangkaian tindakan dalam kondisi tertentu (alokasikan / batalkan segera / alokasikan / alokasikan kembali / mulai). Ini pasti ada hubungannya dengan blok penyelesaian NSOperation dan NSRunLoop. Saya telah memeriksa penerapan AFNetworking dan tidak dapat menemukan penyebabnya.
csotiriou

ASI memang memiliki blok kegagalan.
Kekoa

17

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.


9
Seperti yang disebutkan @iwat di bagian commants pada pertanyaan tersebut, AFNetworking kehilangan cache yang kuat. Itu menarik dan relevan dengan pertanyaan, jadi "tidak ada" adalah jawaban yang salah. Selain itu, saya setuju sepenuhnya dengan sentimen Anda, tho.
Kenny Winker

1
@KennyWerter Silakan lihat balasan saya di utas komentar itu. Saya senang untuk mengatakan bahwa AFNetworking tidak membangun cache dengan sengaja. Sebaliknya, seseorang bebas untuk menukar NSURLCachesolusi berbasis favorit mereka .
mattt

1
pada bagian Nothing - bagaimana saya dapat menggunakan proxy dalam permintaan?
Alex Volovoy

@AlexVolovoy Anda mungkin sebaiknya menanyakannya sebagai pertanyaan baru
JosephH

Saya tidak akan mengatakan 'tidak ada'. Silakan lihat jawaban saya di bawah ini.
borisdiakur

4

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.


5
Anda sekarang dapat melakukan setAuthenticationChallengeBlock:pada AFURLConnectionOperationdan subclass-nya, dan lulus dalam logika untuk menangani tantangan otentikasi yang Anda butuhkan, tanpa harus subclass.
mattt

2

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 *.


2

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


Poin Anda tentang timeout bagus, terima kasih telah berbagi! Saya tidak mengerti bagaimana ini berhubungan dengan membuat permintaan secara sinkron, bisakah Anda memperluasnya?
JosephH

@JosephH Anda benar. Tentunya terkadang Anda juga perlu menyetel waktu tunggu saat melakukan permintaan asinkron. Saya telah memperbarui jawaban saya:]
borisdiakur

Apple memperbaiki masalah dengan timeoutInterval yang tidak bisa kurang dari 240 detik, namun ini masih menjadi masalah bahkan jika Anda mengatur timeoutInterval, permintaan tersebut tidak menghormatinya.
Jasper

2

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


0

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.


2
Jangan mengajukan pertanyaan dalam jawaban, peluang Anda untuk mendapatkan tanggapan sangat rendah. Gunakan komentar atau pertanyaan baru sebagai gantinya;)
Michal

-8

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.


Benar, tetapi menurut saya itu bukan pendekatan utama untuk mengembangkan dengan ASIHTTPRequest
torhector2

7
Itu hanya karena blok datang setelah ASIHTTP ditulis, saya selalu menggunakan blok dengan ASI, tidak pernah ada delegasi.
hypercrypt
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.