我喜歡ASIHTTPRequest,我很難過看到它。然而,ASI的開發者是正確的,ASIHTTPRequest已經變得如此龐大和臃腫,以至於他無法花時間將其與iOS和其他框架的最新特性相提並論。我繼續前進,現在使用AFNetworking。
也就是說,我必須說AFNetworking比ASIHTTP更不穩定,而且對於我使用它的東西,它需要改進。
我在屏幕上顯示我的結果之前,經常需要向100個HTTP源發出HTTP請求,並且我已將AFHTTPNetworkOperation放入操作隊列中。在下載所有結果之前,我希望能夠取消操作隊列中的所有操作,然後關閉包含結果的視圖控制器。
這並不總是奏效。
隨着AFNetworking在隨機時間發生崩潰,而ASIHTTPRequest,這項操作完美無缺。我希望我可以說AFNetworking的哪個特定部分崩潰,因爲它在不同的點上一直崩潰(但是,大多數時候調試器指向創建NSURLConnection對象的NSRunLoop)。因此,AFNetworking需要成熟才能像ASIHTTPRequest一樣被認爲是完整的。
此外,ASIHTTPRequests支持客戶端認證,AFNetworking目前缺乏。實現它的唯一方法是繼承AFHTTPRequestOperation並覆蓋NSURLConnection的身份驗證方法。但是,如果您開始涉足NSURLConnection,您會注意到將NSURLConnection放入NSOperation包裝器並寫入完成塊並不像聽起來那麼困難,您會開始思考是什麼讓您無法轉儲第三方庫。
ASI使用了一種完全不同的方法,因爲它使用CFNetworking(基於C的更低級別的基礎框架)來完成下載和文件上傳,完全跳過NSURLConnection以及觸摸我們大多數人的概念OS X和iOS開發人員也是如此害怕。正因爲如此,你可以更好地上傳和下載文件,甚至是網頁緩存。
我更喜歡哪一種?這很難說。如果AFNetworking足夠成熟,我會比ASI更喜歡它。在此之前,我不禁讚賞ASI,以及它成爲OS X和iOS所有時間最常用的框架之一。
編輯: 我覺得是時候更新這個答案,因爲事情已經這篇文章後改變了一點。
這篇文章是前段時間寫的,AFNetworking已經夠成熟了。 1個月前AF發佈了POST操作的一個小更新,這是我對框架的最後一次投訴(小行結束錯誤是因爲AF上傳失敗,但在ASI中完成正常)。身份驗證不是AF網絡的問題,對於複雜的身份驗證方法,您可以對操作進行子分類並創建自己的呼叫,AFHTTPClient使基本身份驗證成爲小菜一碟。通過繼承AFHTTPClient,您可以在很短的時間內創建一個完整的服務使用者。
更不用說AFNetworking提供的絕對必要的UIImage補充。通過塊和自定義完成塊以及一些聰明的算法,您可以非常容易地實現異步映像下載和單元填充的表格視圖,而在ASI中,您必須針對帶寬限制設置操作隊列,並介意取消並恢復操作隊列表格視圖可見性以及類似的東西。這類行動的開發時間減半。
我也喜歡成功和失敗的塊。 ASI只有一個完成塊(實際上是NSOperation的完成塊)。您必須檢查完成時是否出現錯誤並採取相應措施。對於複雜的Web服務,您可能會迷失在所有「ifs」和「elses」中;在AFNetworking中,事情更加簡單直觀。
ASI當時非常棒,但通過自動對焦,您可以更好地改變處理Web服務的方式,並且更輕鬆地製作可擴展的應用程序。我真的相信沒有任何理由繼續堅持使用ASI,除非你想要瞄準iOS 3和更低版本。
AFNetworking缺乏非常詳細的文檔和示例,所以我不能多說這些。我使用ASIHTTPRequest的主要原因是因爲它支持iOS 3.0和'ASIFallbackToCacheIfLoadFailsCachePolicy'非常好。而且,我認爲AFNetworking沒有持久的緩存支持。這對我來說是不行的。 – iwat
只需注意您是第一個用'afnetworking'標記問題的人。 – iwat
有一個等待被拉入AFNetworking的緩存,我在我的問題中添加了一個鏈接。 – JosephH