[解決済み] AFNetworkingに欠けているASIHTTPRequestの主な機能は何ですか？

質問

と の動作が最近停止しました。 に関心が移っているようです。 AFNetworking .

しかし、2つのライブラリの機能の良い比較はまだ見つかっていないので、切り替えた場合に何が失われるかはわかりません。

私がこれまでに発見した主な違いは以下のとおりです。

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

どなたか、2 つのライブラリの良い比較や、一方から他方への切り替えの経験を文書化したものを見たことはありませんか？

どのように解決するのですか？

私は ASIHTTPRequest が大好きで、それがなくなってしまうのを見るのは悲しいことでした。しかし、ASI の開発者は正しく、ASIHTTPRequest は非常に大きく肥大化し、彼でさえ iOS や他のフレームワークの最新機能と同等にするために時間を割くことができませんでした。私は移動して、今はAFNetworkingを使っています。

とはいえ、AFNetworking は ASIHTTP よりもずっと不安定で、私が使っているものには改良が必要だと言わざるを得ません。

私はしばしば、結果を画面に表示する前に100のHTTPソースにHTTPリクエストを行う必要があり、AFHTTPNetworkOperationを操作キューに入れました。すべての結果がダウンロードされる前に、操作キュー内のすべての操作をキャンセルし、結果を保持するビューコントローラを解除できるようにしたいです。

それはいつもうまくいくわけではありません。

ASIHTTPRequest では、この操作は完璧に動作していたのに、AFNetworking では、不定期にクラッシュが発生します。異なるポイントでクラッシュし続けるので、AFNetworking の特定のどの部分がクラッシュしているのか言えるとよいのですが (ただし、これらの時間のほとんどは、デバッガーが NSURLConnection オブジェクトを作成する NSRunLoop を指しています)。したがって、AFNetworking は、ASIHTTPRequest がそうであったように完全であると見なされるために、成熟する必要があります。

また、ASIHTTPRequestsはクライアント認証をサポートしていますが、これは今のところAFNetworkingに欠けています。それを実装する唯一の方法は、AFHTTPRequestOperation をサブクラス化し、NSURLConnection の認証メソッドをオーバーライドすることです。しかし、NSURLConnection に関わり始めると、NSURLConnection を NSOperation ラッパー内に置き、補完ブロックを書くことがそれほど難しくないことに気づき、何がサードパーティライブラリを捨てずに済むのかを考えるようになるでしょう。

ASI は、CFNetworking (C に基づく低レベルの基礎フレームワーク) を使用してダウンロードとファイル アップロードを可能にし、NSURLConnection を完全にスキップし、OS X と iOS 開発者のほとんどが怖くてできない概念に触れるため、まったく別のアプローチを使用します。このため、より優れたファイルのアップロードとダウンロード、さらには Web ページのキャッシュを得ることができます。

どちらが好きですか? それは何とも言えません。AFNetworking が十分に成熟すれば、ASI よりも好きになるでしょう。それまでは、ASI と、それが OS X と iOS で最も使用されるフレームワークの 1 つになった方法に感心せずにはいられません。

EDIT。 この投稿の後、少し状況が変わったので、この回答を更新する時期だと思います。

この投稿はしばらく前に書かれたもので、AFNetworkingは十分に成熟しています。1～2 か月前、AF は POST 操作の小さな更新を投稿し、それがフレームワークについての私の最後の不満でした (小さな行末の障害は、echonest アップロードが AF では失敗するが ASI では正常に完了した理由でした)。認証はAFnetworkingの問題ではありません。複雑な認証方法については、操作をサブクラス化して独自の呼び出しを行うことができますし、AFHTTPClientを使えば基本的な認証は朝飯前です。AFHTTPClientをサブクラス化することで、サービスコンシューマ全体を短時間で作成することができる。

AFNetworking が提供する絶対に必要な UIImage の追加については言うまでもありません。ブロックとカスタム補完ブロック、およびいくつかの巧妙なアルゴリズムにより、非同期の画像ダウンロードとセル充填を行うテーブル ビューを非常に簡単に作成できます。このような操作の開発時間は半分になりました。

成功ブロックと失敗ブロックも気に入っています。ASIには完了ブロック（実はNSOperationの完了ブロック）しかありません。完了時にエラーが発生したかどうかを確認し、それに応じて行動する必要がありました。複雑な Web サービスの場合、すべての "ifs" と "elses" で迷子になることがあります。AFNetworking では、物事ははるかにシンプルで直感的です。

ASIは当時としては素晴らしいものでしたが、AFを使えば、Webサービスを扱う方法を良い意味で完全に変えることができ、スケーラブルなアプリケーションをより容易に作ることができます。iOS 3以下をターゲットにするのでなければ、もうASIにこだわる理由は何もないと、私は本当に信じています。