成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

iPhone和iPad的企業應用開發之錯誤處理

作者：louise
移動開發 iOS
到目前為止，我們所介紹的iPhone與其他系統的網絡交互都是基于一切正常這個假設。本章將會放棄這個假設，并深入探究網絡的真實世界。在真實世界中，事情是會出錯的，有時可能是非常嚴重的錯誤：手機進入與離開網絡、包丟掉或是延遲；網絡基礎設施出錯；偶爾用戶還會出錯。如果一切正常，那么編寫iOS應用就會簡單不少，不過遺憾的是現實并非如此。本章將會探討導致網絡操作失敗的幾個因素，介紹系統如何將失敗情況告知應用，應用又該如何優雅地通知用戶。此外，本章還將介紹如何在不往應用邏輯中添加錯誤處理代碼的情況下，以一種整潔且一

5.1  理解錯誤源

早期的iOS有個很棒的天氣預報應用。它在Wi-Fi和信號良好的蜂窩網絡下使用正常，不過當網絡質量不那么好時，這個天氣預報應用就像感冒似的，在主屏幕上崩潰。有不少應用在出現網絡錯誤時表現很差勁，會瘋狂彈出大量UIAlertView以告訴用戶出現了“404 Error on Server X”等類似信息。還有很多應用在網絡變慢時界面會變得沒有響應。這些情況的出現都是沒有很好地理解網絡失敗模式以及沒有預期到可能的網絡降級或是失敗。如果想要避免這類錯誤并能夠充分地處理網絡錯誤，那么你首先需要理解它們的起源。

考慮一個字節是如何從設備發往遠程服務器以及如何從遠程服務器將這個字節接收到設備，這個過程只需要幾百毫秒的時間，不過卻要求網絡設備都能正常工作才行。設備網絡與網絡互聯的復雜性導致了分層網絡的產生。分層網絡將這種復雜環境劃分成了更加易于管理的模塊。雖然這對程序員很有幫助，不過當數據在各個層之間流動時可能會產生之前提到的網絡錯誤。圖5-1展示了Internet協議棧的各個層次。

  每一層都會執行某種錯誤檢測，這可能是數學意義上的、邏輯意義上的，或是其他類型的檢測。比如，當網絡接口層接收到某一幀時，它首先會通過錯誤校正碼來驗 證內容，如果不匹配，那么錯誤就產生了。如果這個幀根本就沒有到達，那就會產生超時或是連接重置。錯誤檢測出現在棧的每一層，自下而上直到應用層，應用層 則會從語法和語義上檢查消息。

     在使用iOS中的URL加載系統時，雖然手機與服務器之間的連接可能會出現各種各樣的問題，不過可以將這些原因分成3種錯誤類別，分別是操作系統錯誤、 HTTP錯誤與應用錯誤。這些錯誤類別與創建HTTP請求的操作序列相關。圖5-2展示了向應用服務器發出的HTTP請求(提供來自于企業網絡的一些數 據)的簡單序列圖。每塊陰影區域都表示這3種錯誤類型的錯誤域。典型地，操作系統錯誤是由HTTP服務器問題導致的。HTTP錯誤是由HTTP服務器或應 用服務器導致的。應用錯誤是由請求傳輸的數據或應用服務器查詢的其他系統導致的。

 

  如果請求是安全的HTTPS請求，或是HTTP服務器被重定向客戶端，那么上面這個序列的步驟將會變得更加復雜。上述很多步驟都包含著大量的子步驟，比如在建立TCP連接時涉及的SYN與SYN-ACK包序列等。下面將會詳細介紹每一種錯誤類別。

5.1.1  操作系統錯誤

    操作系統錯誤是由數據包沒有到達預定目標導致的。數據包可能是建立連接的一部分，也可能位于連接建立的中間階段。OS錯誤可能由如下原因造成：

沒有網絡——如果設備沒有數據網絡連接，那么連接嘗試很快就會被拒絕或是失敗。這些類型的錯誤可以通過Apple提供的Reachability框架檢測到，本節后面將會對此進行介紹。

無法路由到目標主機——設備可能有網絡連接，不過連接的目標可能位于隔離的網絡中或是處于離線狀態。這些錯誤有時可以由操作系統迅速檢測到，不過也有可能導致連接超時。

 沒有應用監聽目標端口——在請求到達目標主機后，數據包會被發送到請求指定的端口號。如果沒有服務器監聽這個端口或是有太多的連接請求在排隊，那么連接請求就會被拒絕。

無法解析目標主機名——如果無法解析目標主機名，那么URL加載系統就會返回錯誤。通常情況下，這些錯誤是由配置錯誤或是嘗試訪問沒有外部名字解析且處于隔離網絡中的主機造成的。

在iOS的URL加載系統中，操作系統錯誤會以NSError對象的形式發送給應用。iOS通過NSError在軟件組件間傳遞錯誤信息。相比簡單的錯誤代碼來說，使用NSError的主要優勢在于NSError對象包含了錯誤域屬性。

不過，NSError對象的使用并不限于操作系統。應用可以創建自己的NSError對象，使用它們在應用內傳遞錯誤消息。如下代碼片段展示的應用方法使用NSError向調用的視圖控制器傳遞回失敗信息：

 

  1. -(id)fetchMyStuff:(NSURL*)url error:(NSError**)error 
  2. { 
  3. BOOL errorOccurred = NO; 
  4.   
  5. // some code that makes a call and may fail 
  6.   
  7. if(errorOccurred) //some kind of error 
  8. { 
  9. NSMutableDictionary *errorDict = [NSMutableDictionary dictionary]; 
  10. [errorDictsetValue:@"Failed to fetch my stuff" 
  11. forKey:NSLocalizedDescriptionKey]; 
  12. *error = [NSErrorerrorWithDomain:@"myDomain" 
  13. code:kSomeErrorCode 
  14. userInfo:errorDict]; 
  15. return nil; 
  16. } else { 
  17. return stuff 
  18. } 
  19.   
  20. } 

域 屬性根據產生錯誤代碼的庫或框架對這些錯誤代碼進行隔離。借助域，框架開發者無須擔心覆蓋錯誤代碼，因為域屬性定義了產生錯誤的框架。比如，框架A 與B 都會產生錯誤代碼1，不過這兩個錯誤代碼會被每個框架提供的唯一域值進行區分。因此，如果代碼需要區分NSError 值，就必須對NSError 對象的code 與domain 屬性進行比較。

NSError 對象有如下3 個主要屬性：
code——標識錯誤的NSInteger 值。對于產生該錯誤的錯誤域來說，這個值是唯一的。
domain —— 指定錯誤域的NSString 指針， 比如NSPOSIXErrorDomain 、NSOSStatusErrorDomain 及NSMachErrorDomain。
userInfo——NSDictionary 指針，其中包含特定于錯誤的值。
URL 加載系統中產生的很多錯誤都來自于NSURLErrorDomain 域，代碼值基本上都來自于CFNetworkErrors.h 中定義的錯誤代碼。與iOS 提供的其他常量值一樣，代碼應該使用針對錯誤定義好的常量名而不是實際的錯誤代碼值。比如，如果客戶端無法連接到主機，那么錯誤代碼是1004，并且有定 義好的常量kCFURLErrorCannotConnectToHost。代碼絕不應該直接引用1004，因為這個值可能會在操作系統未來的修訂版中發 生變化；相反，應該使用提供的枚舉名kCFURLError。
      如下是使用URL 加載系統創建HTTP 請求的代碼示例：

 

  1. <span style="font-family:Microsoft YaHei;font-size:14px;"><span style="font-family:Microsoft YaHei;font-size:14px;">NSHTTPURLResponse *response=nil; 
  2. NSError *error=nil; 
  3. NSData *myData=[NSURLConnectionsendSynchronousRequest:request 
  4. returningResponse:&response 
  5. error:&error]; 
  6. if (!error) { 
  7. // No OS Errors, keep going in the process 
  8. ... 
  9. } else { 
  10. // Something low level broke 
  11. }</span></span> 

注 意，NSError 對象被聲明為指向nil 的指針。如果出現錯誤，那么NSURLConnection對象只會實例化NSError 對象。URL 加載系統擁有NSError 對象；如果稍后代碼會用到它，那么應該保持這個對象。如果在同步請求完成后NSError 指針依然指向nil，那就說明沒有產生底層的OS 錯誤。這時，代碼就知道沒有產生OS 級別的錯誤，不過錯誤可能出現在協議棧的某個高層。
如果應用創建的是異步請求，那么NSError 對象就會返回到委托類的下面這個方法：

  1. <span style="font-family:Microsoft YaHei;font-size:14px;"><span style="font-family:Microsoft YaHei;font-size:14px;">- (void)connection:(NSURLConnection *)connection 
  2. didFailWithError:(NSError *)error</span></span> 

這是傳遞給請求委托的最終消息，委托必須能識別出錯誤的原因并作出恰當的反應。在如下示例中，委托會向用戶展UIAlertView：

 

  1. <span style="font-family:Microsoft YaHei;font-size:14px;"><span style="font-family:Microsoft YaHei;font-size:14px;">- (void) connection:conndidFailWithError:error { 
  2. UIAlertView *alert = [UIAlertViewalloc] initWithTitle:@"Network Error" 
  3. message:[error description] 
  4. delegate:self 
  5. cancelButtonTitle:@"Oh Well" 
  6. otherButtonTitles:nil]; 
  7. [alert show]; 
  8. [alert release]; 
  9. }</span></span> 

上述代 碼以一種生硬且不友好的方式將錯誤展現給了用戶。在iOS 人機界面指南(HiG)中，Apple 建議不要過度使用UIAlertViews，因為這會破壞設備的使用感受。5.3 節“優雅地處理網絡錯誤”中介紹了如何通過良好的用戶界面以一種干凈且一致的方式處理錯誤的模式。
      iOS 設備通信錯誤的另一主要原因就是由于沒有網絡連接而導致設備無法訪問目標服務器。可以在嘗試發起網絡連接前檢查一下網絡狀態，這樣可以避免很多OS 錯誤。請記
住，這些設備可能會很快地進入或是離開網絡。因此，在每次調用前檢查網絡的可達性是非常合情合理的事情。
      iOS 的SystemConfiguration 框架提供了多種方式來確定設備的網絡連接狀態?？梢栽赟CNetworkReachability 參考文檔中找到關于底層API 的詳盡信息。這個API 非常強大，不過也有點隱秘。幸好，Apple 提供了一個名為Reachability 的示例程序，它為SCNetworkReachability實現了一個簡化、高層次的封裝器。Reachability 位于iOS 開發者庫中。
      Reachability 封裝器提供如下4 個主要功能：

標識設備是否具備可用的網絡連接
標識當前的網絡連接是否可以到達某個特定的主機
標識當前使用的是哪種網絡技術：Wi-Fi、WWAN 還是什么技術都沒用
在網絡狀態發生變化時發出通知要想使用Reachability API，請從iOS 開發者庫中下載示例程序，地址是http://developer.apple.com/library/ios/#samplecode /Reachability/Introduction/Intro.html，然后將Reachability.h與Reachability.m 添加到應用的Xcode 項目中。此外，還需要將SystemConfiguration 框架添加到Xcode 項目中。將SystemConfiguration 框架添加到Xcode 項目中需要編輯項目配置。圖5-3 展示了將SystemConfiguration 框架添到Xcode 項目中所需的步驟。
(3) 選擇SystemConfiguration.framework

  選定好項目目標后，找到設置中的Linked Frameworks and Libraries，單擊+按鈕添加框架，這時會出現框架選擇界面。選擇SystemConfiguration 框架，單擊add 按鈕將其添加到項目中。
      如下代碼片段會檢查是否存在網絡連接。不保證任何特定的主機或IP 地址是可達的，只是標識是否存在網絡連接。

  1. <span style="font-family:Microsoft YaHei;font-size:14px;"><span style="font-family:Microsoft YaHei;font-size:14px;">#import "Reachability.h" 
  2. ... 
  3. if([[Reachability reachabilityForInternetConnection] 
  4. currentReachabilityStatus] == NotReachable) { 
  5. // handle the lack of a network 
  6. }</span></span> 

     在某些情況下，你可能想要修改某些動作、禁用UI 元素或是當設備處于有限制的網絡中時修改超時值。如果應用需要知道當前正在使用的連接類型，那么請使用如下代碼：

  1. <span style="font-family:Microsoft YaHei;font-size:14px;"><span style="font-family:Microsoft YaHei;font-size:14px;">#import "Reachability.h" 
  2. ... 
  3. NetworkStatus reach = [[Reachability reachabilityForInternetConnection] 
  4. currentReachabilityStatus]; 
  5. if(reach == ReachableViaWWAN) { 
  6. // Network Is reachable via WWAN (aka. carrier network) 
  7. } else if(reach == ReachableViaWiFi) { 
  8. // Network is reachable via WiFi 
  9. }</span></span> 

     知道設備可達性狀態的變化也是很有必要的，這樣就可以主動修改應用行為。如下代碼片段啟動對網絡狀態的監控：

  1. <span style="font-family:Microsoft YaHei;font-size:14px;"><span style="font-family:Microsoft YaHei;font-size:14px;">#import "Reachability.h" 
  2. ... 
  3. [[NSNotificationCenterdefaultCenter] 
  4. addObserver:self 
  5. selector:@selector(networkChanged:) 
  6. name:kReachabilityChangedNotification 
  7. object:nil]; 
  8. Reachability *reachability; 
  9. reachability = [[Reachability reachabilityForInternetConnection] retain]; 
  10. [reachability startNotifier];</span></span> 

上述代碼將當前對象注冊為通知觀察者，名為kReachabilityChangedNotification。
NSNotificationCenter 會調用當前對象的名為networkChanged:的方法。當可達性狀態發生變化時，就向該對象傳遞NSNotification 及新的可達性狀態。如下示例展示了通知監聽者：

  1. <span style="font-family:Microsoft YaHei;font-size:14px;"><span style="font-family:Microsoft YaHei;font-size:14px;">- (void) networkChanged: (NSNotification* )notification 
  2. { 
  3. Reachability* reachability = [notification object]; 
  4. 第Ⅱ部分 HTTP 請求：iOS 網絡功能 
  5. 98 
  6. if(reachability == ReachableViaWWAN) { 
  7. // Network Is reachable via WWAN (a.k.a. carrier network) 
  8. } else if(reachability == ReachableViaWiFi) { 
  9. // Network is reachable via WiFi 
  10. } else if(reachability == NotReachable) { 
  11. // No Network available 
  12. } 
  13. }</span></span> 

  可達性還可以確定當前網絡上某個特定的主機是否是可達的?？梢酝ㄟ^該特性根據應用是處于內部隔離的網絡上還是公開的Internet 上調整企業應用的行為。如下代碼示例展示了該特性：

 

  1. <span style="font-family:Microsoft YaHei;font-size:14px;"><span style="font-family:Microsoft YaHei;font-size:14px;">Reachability *reach = [Reachability 
  2. reachabilityWithHostName:@"www.captechconsulting.com"]; 
  3. if(reachability == NotReachable) { 
  4. // The target host is not reachable available 
  5. }</span></span> 

  請記住，該特性對目標主機的訪問有個來回。如果每個請求都使用該特性，那就會極大增加應用的網絡負載與延遲。Apple 建議不要在主線程上檢測主機的可達性，因為嘗試訪問主機可能會阻塞主線程，這會導致UI 被凍結。
      OS 錯誤首先就表明請求出現了問題。應用開發者有時會忽略掉它們，不過這樣做是有風險的。因為HTTP 使用了分層網絡，這時HTTP 層或是應用層可能會出現其他類型的潛在失敗情況。

#p#

5.1.2 HTTP 錯誤
HTTP 錯誤是由HTTP 請求、HTTP 服務器或應用服務器的問題造成的。HTTP 錯誤通過HTTP 響應的狀態碼發送給請求客戶端。
404 狀態是常見的一種HTTP 錯誤，表示找不到URL 指定的資源。下述代碼片段中的HTTP 頭就是當HTTP 服務器找不到請求資源時給出的原始輸出：

 

  1. <span style="font-family:Microsoft YaHei;font-size:14px;"><span style="font-family:Microsoft YaHei;font-size:14px;">HTTP/1.1 404 Not Found 
  2. Date: Sat, 04 Feb 2012 18:32:25 GMT 
  3. Server: Apache/2.2.14 (Ubuntu) 
  4. Vary: Accept-Encoding 
  5. Content-Encoding: gzip 
  6. Content-Length: 248 
  7. Keep-Alive: timeout=15, max=100 
  8. Connection: Keep-Alive 
  9. Content-Type: text/html; charset=iso-8859-1</span></span> 

響應的***行有狀態碼。HTTP 響應可以帶有消息體，其中包含友好、用戶可讀的信息，用于描述發生的事情。你不應該將是否有響應體作為判斷HTTP 請求成功與否的標志。
一共有5 類HTTP 錯誤：

● 信息性質的100 級別——來自于HTTP 服務器的信息，表示請求的處理將會繼續，不過帶有警告。
● 成功的200 級別——服務器處理了請求。每個200 級別的狀態都表示成功請求的不同結果。比如，204 表示請求成功，不過沒有向客戶端返回負載。
● 重定向需要的300 級別——表示客戶端必須執行某個動作才能繼續請求，因為所需的資源已經移動了。URL 加載系統的同步請求方法會自動處理重定向而無須通知代碼。如果應用需要對重定向進行自定義處理，那么應該使用異步請求。
● 客戶端錯誤400 級別——表示客戶端發出了服務器無法正確處理的錯誤數據。比如，未知的URL 或是不正確的HTTP 頭會導致這個范圍內的錯誤。
● 下游錯誤500 級別——表示HTTP 服務器與下游應用服務器之間出現了錯誤。比如，如果Web 服務器調用了JavaEE 應用服務器，Servlet 出現了NullPointerException，那么客戶端就會收到500 級別的錯誤。
      iOS 中的URL 加載系統會處理HTTP 頭的解析，并可以輕松獲取到HTTP 狀態。如果代碼通過HTTP 或HTTPS URL 發出了同步調用，那么返回的響應對象就是一個NSHTTPURLResponse 實例。NSHTTPURLResponse 對象的statusCode 屬性會返回數值形式的請求的HTTP 狀態。如下代碼演示了對NSError 對象以及從HTTP 服務器返回的成功狀態的驗證：

  1. <span style="font-family:Microsoft YaHei;font-size:14px;"><span style="font-family:Microsoft YaHei;font-size:14px;">NSHTTPURLResponse *response=nil; 
  2. NSError *error=nil; 
  3. NSData *myData = [NSURLConnectionsendSynchronousRequest:request 
  4. returningResponse:&response 
  5. error:&error]; 
  6. //Check the return 
  7. if((!error) && ([response statusCode] == 200)) { 
  8. // looks like things worked 
  9. } else { 
  10. // things broke, again. 
  11. }</span></span> 

  如果請求的URL不是HTTP，那么應用就應該驗證響應對象是否是NSHTTPURLResponse對象。驗證對象類型的***方法是使用返回對象的isKindOfClass:方法，如下所示：

  1. <span style="font-family:Microsoft YaHei;font-size:14px;"><span style="font-family:Microsoft YaHei;font-size:14px;">if([response isKindOfClass:[NSHTTPURLResponse class]]) { 
  2. // It is a HTTP response, so we can check the status code 
  3. ...</span></span> 

要想了解關于HTTP 狀態碼的權威信息，請參考W3 RFC 2616，網址是http://www.w3.org/Protocols/rfc2616/rfc2616.html。
5.1.3 應用錯誤
      本節將會介紹網絡協議棧的下一層(應用層)產生的錯誤。應用錯誤不同于OS 錯誤或HTTP 錯誤，因為并沒有針對這些錯誤的標準值或是原因的集合。這些錯誤是由運行在服
務層之上的業務邏輯和應用造成的。在某些情況下，錯誤可能是代碼問題，比如異常，不過在其他一些情況下，錯誤可能是語義錯誤，比如向服務提供了無效的賬號等。對于前者來說，建議生成HTTP 500 級別的錯誤；對于后者來說，應該在應用負載中返回錯誤碼。
      比如，如果用戶嘗試從賬戶中轉賬的金額超出了賬戶的可用余額，那么手機銀行就應該報告應用錯誤。如果發出了這樣的請求，那么OS 會說請求成功發送并接收到了響應。HTTP 服務器會報告接收到了請求并發出了響應，不過應用層必須報告這筆交易失敗。報告應用錯誤的***實踐是將應用的負載數據封裝在標準信封中，信封中含有一致的 應用錯誤位置信息。在上述資金轉賬示例中，成功的轉賬響應的業務負載應該如下所示：

  1. <span style="font-family:Microsoft YaHei;font-size:14px;"><span style="font-family:Microsoft YaHei;font-size:14px;">{ "transferResponse":{ 
  2. "fromAccount":1, 
  3. "toAccount":5, 
  4. "amount":500.00, 
  5. "confirmation":232348844 
  6. } 
  7. }</span></span> 
  8.  
  9. <span style="font-family:Microsoft YaHei;font-size:14px;"><span style="font-family:Microsoft YaHei;font-size:14px;"> 
  10. </span></span> 

響 應包含了源賬號與目標賬號、轉賬的資金數額及確認號。直接將錯誤碼與錯誤消息放到transferResponse 對象中會導致錯誤碼與錯誤消息的定位變得困難。如果每個動作都將錯誤信息放到自己的響應對象中，就無法在應用間重用錯誤報告邏輯了。使用如下代碼中的數據 包結構可以讓應用快速確定是否出現了錯誤，方式是檢查響應的JSON 負載中是否存在“error”對象：

  1. <span style="font-family:Microsoft YaHei;font-size:14px;"><span style="font-family:Microsoft YaHei;font-size:14px;">{"error":{ 
  2. "code":900005, 
  3. "messages":"Insufficient Funds to Complete Transfer" 
  4. }, 
  5. "data":{ 
  6. "fromAccount":1, 
  7. "toAccount":5, 
  8. "amount":500.00 
  9. } 
  10. }</span></span> 

報告錯誤的UI 代碼是很容易重用的，因為錯誤信息總是位于響應負載的error 屬性中。此外，實際的交易負載處理得到了簡化，因為它總是位于相同的屬性名之下。
無論請求失敗的原因是什么，OS、HTTP 層還是應用，應用都必須能知道如何作出響應。你應該在開發時就提前考慮好應用所有的失敗模式，并設計好一致的方式來檢測并響應錯誤。
#p#

5.2 錯誤處理的經驗法則
錯誤可能是由多種原因造成的，***處理方式也隨編寫的應用不同而不同。雖然很復雜，不過有一些經驗法則可以幫助處理錯誤原因不可控的本質。
5.2.1 在接口契約中處理錯誤
在 設計服務接口時，只指定輸入、輸出與服務操作的做法是不正確的。接口契約還應該指定如何向客戶端發送錯誤信息。服務接口應該使用業界標準方式在可能的情況 下傳遞錯誤信息。比如，服務器不應該為服務端失敗定義新的HTTP 狀態值；相反，應該使用恰當的500 級別的狀態。如果使用了標準值，那么客戶端與服務端開發者就能對如何傳遞錯誤信息達成共識。應用絕不應該依賴于非標準的狀態或是其他屬性值來確定錯誤出現 與否。
應用開發者也不應該依賴于當前服務器軟件棧的行為來決定該如何處理錯誤。在部署了iOS 應用后，服務器軟件?？赡軙捎谖磥淼纳壔蛱鎿Q而改變行為。
5.2.2 錯誤狀態可能不正確
移動網絡有如下有別于傳統Web 應用錯誤的不那么明顯的行為：模糊不清的錯誤報告。從移動設備發往服務器的任何網絡請求都有3 種可能的結果：
● 設備完全能夠確認操作是成功的。比如，NSError 與HTTP 狀態值都表明成功，返回的負載包含語義上正確的信息。
● 設備完全能夠確認操作是失敗的。比如，返回的應用負載包含來自于服務器的特定于本次操作的失敗標識。 設備模糊地確認操作是失敗的。比如，移動應用發出HTTP 請求以在兩個賬戶間轉賬。請求被銀行系統接收并正確地處理；然而，由于網絡失敗應答卻丟失了，NSURLConnection 報告超時。超時發生了，但卻是在轉賬請求成功之后發生的。如果重試該操作，那就會導致重復轉賬，可能還會造成賬戶透支。第3 種場景會導致應用出現意外和檢測不到的錯誤行為。如果應用開發者不知道第3種場景的存在，那么他們可能就會錯誤地假設操作失敗，然后不小心重試已經成功的 操作。知道整個操作失敗還不夠，開發者必須考慮導致請求失敗的原因，以及自動重試每個失敗的請求是否是恰當的。
5.2.3 驗證負載
應用 開發者不應該認為如果沒有OS 錯誤或HTTP 錯誤，負載就是有效的。在很多場景下，請求似乎是成功的，不過負載卻是無效的?？蛻舳伺c服務器之間傳遞的負載都一種驗證機制。JSON 與XML 就是具備了驗證機制的負載格式，不過以逗號分隔的值文件與HTML 就沒有這種機制。

5.2.4 分離錯誤與正常的業務狀況
服務契約不應該將正常的業務狀況報告為錯誤。比如有個用戶，由于可能的欺詐導致賬戶被鎖定，鎖定狀態應該在數據負載中進行報告而不應該當作錯誤情況。分離錯誤與正常的業務狀況會讓代碼保持恰當的關注分離。只有當出現問題時才應該將之看成錯誤。
5.2.5 總是檢查HTTP 狀態
總是檢查HTTP 響應中的HTTP 狀態，理解成功的狀態值，甚至向相同的服務發出重復的調用也是如此。服務器的狀態可能隨時會發生變化，甚至在并行的調用間也是如此。
5.2.6 總是檢查NSError 值
應用代碼應該總是檢查返回的NSError 值來確保OS 層沒有出現問題。即便知道應用總是運行在信號良好的Wi-Fi 網絡下也應該這樣做。任何東西都有出錯的可能性，代碼在處理網絡時也需要做好防御工作。
5.2.7 使用一致的方法來處理錯誤
網 絡錯誤的產生原因是非常多的，很難一一列舉出來，影響的多樣性及范圍也是非常大的。在設計應用時，請不要只關注于一致的用戶界面模式或是一致的命名模式。 你還應該設計一致的模式來處理網絡錯誤。該模式應該考慮到應用可能會遇到的所有類型的錯誤。如果應用的內部沒有以一致的模式處理這些錯誤，那么應用就無法 以一致的方式向用戶報告這些錯誤。
5.2.8 總是設置超時時間
在iOS 中，HTTP 請求的默認超時時間間隔是4 分鐘，這對于移動應用來說過長了，大多數用戶都不會在任何應用中等


iOS 簡化了網絡通信，不過對可能發生的所有類型的錯誤與邊界條件作出響應則不是那么輕松的事情。常見的做法是在網絡代碼中放置鉤子來快速查看結果，接下來再對 所有的錯誤情況進行處理。對于非移動應用來說，通?？梢允褂眠@種方式，因為來自工作站的網絡連接是可預測的。如果在應用加載時有網絡，那么當用戶加載下一 個頁面時基本上也會有網絡。絕大多數情況都是這樣的，開發者可以依賴瀏覽器向用戶顯示消息。如果在移動應用中沒有及時添加異常處理，那么當后面遇到新的錯 誤源時就需要大幅重構網絡代碼。
#p#

5.3 優雅地處理網絡錯誤

本節將會介紹一種設計模式，用來創建一個優雅且健壯的異常處理框架，并且在未來遇到新的錯誤時幾乎不需要做什么工作就能很好地進行擴展?？紤]如下3 個移動通信中的主要異常情況：
● 由于設備沒有充分的網絡連接導致遠程服務器不可達。
● 由于OS 錯誤、HTTP 錯誤或是應用錯誤導致遠程服務器返回錯誤響應。
● 服務器需要認證，而設備嘗試發出未認證的請求。
隨著可能的異常數量呈現出線性增長，處理這些異常的代碼量則呈指數級增長。如果代碼要在每一類請求中處理所有這些錯誤，那么代碼的復雜性與數量就會呈指數級增長。本節將要介紹的模式會將這種指數級的曲線壓成線性曲線。

5.3.2 指揮調度模式示例

本節通過調用YouTube 的一項認證服務來介紹指揮調度模式。在此類通信過程中需要考慮很多失敗模式：
● 用戶可能沒有提供有效的身份信息。
● 設備可能無法聯網。
● YouTube 可能沒有及時響應或是出于某些原因失敗了。
應用需要以一種優雅且可靠的方式處理每一種情況。該例將會闡述主要的代碼組件并介紹一些實現細節。項目中的應用是個示例應用，只用于演示目的。
1. 前提條件
要想成功運行該應用，你需要準備好如下內容：
● 一個YouTube 賬號。
● 至少向你的YouTube 賬號上傳一個視頻(無須公開，只要上傳到該賬號即可)。
● 從Wrox 網站上下載的項目壓縮文件。
該項目使用Xcode 4.1 與iOS 4.3 開發，應用使用的是截止到2011 年10 月份的YouTubeAPI，不過該API 處于Google 的控制下，而且可能會發生變化。
2. 主要對象
下載好項目并在Xcode 中加載后，你會看到如下類：
1) 命令
命令分組中有如下一些類。
BaseCommand
BaseCommand 是所有命令對象的父類。它提供了每個命令類所需的眾多方法，這些方法有：
發送完成、錯誤與登錄通知的方法。

用于讓對象監聽完成通知的方法。
用于支持實際的NSURLRequests 的方法。
BaseCommand 繼承了NSOperation，因此所有的命令邏輯都位于該類的每個子類對象的main 方法中。
GetFeed
如 代碼清單5-1 所示，該類的main 方法會調用YouTube 并加載當前登錄用戶上傳的視頻列表。YouTube 通過請求HTTP 頭中的令牌來確定登錄用戶的身份。如果沒有這個頭，YouTube 就會返回HTTP 狀態碼0 而不是更加標準的4xx HTTP 錯誤。

代碼清單5-1 CommandDispathDemo/service-interface/GetFeed.h

  1. <span style="font-family:Microsoft YaHei;font-size:14px;">- (NSMutableURLRequest *) createRequestObject:(NSURL *)url { 
  2. NSMutableURLRequest *request = [[[NSMutableURLRequestalloc] 
  3. initWithURL:url 
  4. cachePolicy:NSURLCacheStorageAllowed 
  5. timeoutInterval:20 
  6. autorelease]; 
  7. return request; 
  8. }</span> 

在 上述代碼清單中，通過self 調用的很多方法都是在BaseCommand 父類中實現的。GetFeed 命令就是指揮調度模式的原型。main 方法會對用戶登錄進行檢查，因為如果這個調用失敗了，那就沒必要再調用服務器了。如果用戶已經登錄，那么代碼就會構建請求，將認證頭添加到請求中，然后發 送一條同步請求。代碼的***一部分會調用一個父類方法來確定調用是否成功。該方法使用來自于NSHTTPURLResponse 對象的NSError 對象與HTTP 狀態碼來確定是否成功。如果調用失敗，就會廣播一條錯誤通知或是需要登錄的通知。
LoginCommand
該命令會向YouTube 發出對用戶進行認證的請求。該命令比較獨立，因為并沒有使用BaseCommand 對象的輔助方法。之所以沒有使用這些方法，是因為如果登錄失敗，就不應該生成需要認證的失敗消息，而只會報告正常完成或是失敗的狀態。
登 錄監聽器會處理來自于登錄失敗的錯誤。要想了解關于YouTube 所需協議的詳細信息，請參考 http://code.google.com/apis/youtube/2.0 /developers_guide_protocol_understanding_video_feeds.html。
2) 異常監聽器
監 聽器分組中有視圖控制器， 當錯誤發生或是用戶需要登錄時會呈現出來。NetworkErrorViewController 與LoginViewController 都繼承了InterstitialViewController，后者提供了幾個常用的輔助方法。這兩個視圖控制器都會以模態視圖控制器的形式呈現出來。
● NetworkErrorViewController：向用戶提供重試或是放棄失敗操作的選擇。如果用戶選擇重試，那么失敗命令就會放回到操作隊列中。
● LoginViewController：向用戶請求用戶名與密碼。位于視圖棧的頂部，直到用戶成功登錄為止。 InterstitialViewController：作為其他異常監聽器的父監聽器，提供了一些支持功能，比如收集多個錯誤通知以及當錯誤解析完畢時 重新分發錯誤的代碼等。監聽器的關鍵代碼位于viewDidDisappear:方法中(如代碼清單5-2 所示)，當視圖完全消失時會調用該方法。如果在視圖完全消失前命令已進入隊列中，那么其他錯誤就有可能導致再一次呈現視圖，這會導致應用出現嚴重的錯誤。 iOS 5 提供了處理這個問題的更好方式，因為在視圖消失時用戶可以指定執行的代碼塊。在處理觸發命令前，代碼并不需要確定消失的原因。

代碼清單5-2 CommandDispatchDemo/NetworkErrorViewController.m

  1. <span style="font-family:Microsoft YaHei;font-size:14px;">- (void) viewDidDisappear:(BOOL)animated { 
  2. if(retryFlag) { 
  3. // re-enqueue all of the failed commands 
  4. [self performSelectorAndClear:@selector(enqueueOperation)]; 
  5. } else { 
  6. // just send a failure notification for all failed commands 
  7. [self performSelectorAndClear: 
  8. @selector(sendCompletionFailureNotification)]; 
  9. } 
  10. self.displayed = NO; 
  11. }</span> 

應用委托會將自身注冊為網絡錯誤與需要登錄通知的監聽器(如代碼清單5-3 所示)，收集異常通知并在錯誤發生時管理正確的視圖控制器的呈現。上述代碼展示了需要登錄通知的通知處理器。由于要處理用戶界面，因此其中的內容必須使用GCD 在主線程中執行。
代碼清單5-3 CommandDispatchDemo/CommandDispatchDemoAppDelegate.m

  1. <span style="font-family:Microsoft YaHei;font-size:14px;">/** 
  2. * Handles login needed notifications generated by commands 
  3. **/ 
  4. - (void) loginNeeded:(NSNotification *)notif { 
  5. // make sure it all occurs on the main thread 
  6. dispatch_async(dispatch_get_main_queue(), ^{ 
  7. // make sure only one thread adds a command at a time 
  8. @synchronized(loginViewController) { 
  9. [loginViewController addTriggeringCommand: 
  10. [notif object]; 
  11. if(!loginViewController.displayed) { 
  12. // if the view is not displayed then display it. 
  13. [[self topOfModalStack:self.window.rootViewController] 
  14. presentModalViewController:loginViewController 
  15. animated:YES]; 
  16. } 
  17. loginViewController.displayed = YES; 
  18. } 
  19. }); // End of GC Dispatch block 
  20. }</span> 

3) 視圖控制器
在 這個簡單的應用中有個主要的視圖控制器。RootViewController(參見下面的代碼)繼承了UITableViewController。當 該控制器加載時，會創建并排隊命令以加載用戶的視頻列表(又叫做YouTube 種子)，并且會將控制流放回到主運行循環中以耐心等待命令的完成。
***次調用總是失敗的，因為這時用戶還沒有登錄。CommandDispatchDemo/RootViewController.m 的requestVideoFeed 方法會啟動加載視頻列表的過程，如下所示：

  1. <span style="font-family:Microsoft YaHei;font-size:14px;">(void)requestVideoFeed { 
  2. // create the command 
  3. GetFeed *op = [[GetFeedalloc] init]; 
  4. // add the current authentication token to the command 
  5. CommandDispatchDemoAppDelegate *delegate = 
  6. (CommandDispatchDemoAppDelegate *)[[UIApplication 
  7. sharedApplication] delegate ]; 
  8. op.token = delegate.token; 
  9. // register to hear the completion of the command</span> 
  10.  
  11. <span style="font-family:Microsoft YaHei;font-size:14px;"><span style="background-color: rgb(255, 255, 255);">[op listenForMyCompletion:self selector:@selector(gotFeed:)];</span></span> 
  12.  
  13. <span style="font-family:Microsoft YaHei;font-size:14px;">// put it on the queue for execution 
  14. [op enqueueOperation]; 
  15. [op release]; 
  16. }</span> 

注意，代碼并不需要檢查用戶是否已經登錄；在執行時命令會做檢查。
gotFeed:方法會處理來自于YouTube 的最終返回數據。在此例中，requestVideoFeed:方法會將gotFeed:方法注冊為完成通知的目標方法。如果調用成功，該方法會將數據加載
到表視圖中，否則顯示UIAlertView：

  1. <span style="font-family:Microsoft YaHei;font-size:14px;">- (void) gotFeed:(NSNotification *)notif { 
  2. NSLog(@"User info = %@", notif.userInfo); 
  3. BaseCommand *op = notif.object; 
  4. if(op.status == kSuccess) { 
  5. self.feed = op.results; 
  6. // if entry is a single item, change it to an array, 
  7. // the XML reader cannot distinguish single entries 
  8. // from arrays with only one element 
  9. id entries = [[feed objectForKey:@"feed"] objectForKey:@"entry"]; 
  10. if([entries isKindOfClass:[NSDictionary class]]) { 
  11. NSArray *entryArray = [NSArrayarrayWithObject:entries]; 
  12. [[feed objectForKey:@"feed"] setObject:entryArrayforKey:@"entry"]; 
  13. } 
  14. dispatch_async(dispatch_get_main_queue(), ^{ 
  15. [self.tableViewreloadData]; 
  16. }); 
  17. } else { 
  18. dispatch_async(dispatch_get_main_queue(), ^{ 
  19. UIAlertView *alert = [[UIAlertViewalloc] 
  20. initWithTitle:@"No Videos" 
  21. message:@"The login to YouTube failed" 
  22. delegate:self 
  23. cancelButtonTitle:@"Retry" 
  24. otherButtonTitles:nil]; 
  25. [alert show]; 
  26. [alert release]; 
  27. }); 
  28. } 
  29. } 
  30. YouTubeVideoCell 是UITableViewCell 的子類，它會異步加載視頻的縮略圖。它通過LoadImageCommand 對象完成加載處理： 
  31. /** 
  32. * Start the process of loading the image via the command queue 
  33. **/ 
  34. - (void) startImageLoad { 
  35. LoadImageCommand *cmd = [[LoadImageCommandalloc] init]; 
  36. cmd.imageUrl = imageUrl; 
  37. // set the name to something unique 
  38. cmd.completionNotificationName = imageUrl; 
  39. [cmd listenForMyCompletion:self selector:@selector(didReceiveImage:)]; 
  40. [cmdenqueueOperation]; 
  41. [cmd release]; 
  42. }</span> 

這個類會改變完成通知名，這樣它(也只有它)就可以接收到特定圖片的通知了。否則，它還需要檢查返回的通知來確定是否是之前發出的命令。
指 揮調度模式的優雅之處在于能將應用中所有凌亂的異常處理邏輯和登錄呈現邏輯與主視圖控制器分離開來。當視圖控制器發出命令時，會忽略掉所有的異常處理與認 證處理，只是完成請求而已。只是發出請求，等待響應，然后處理響應。并不關心用戶注冊的請求是不是重試了5 次才成功。此外，服務請求代碼并不需要知道請求來自于哪里，結果去向哪里；只是關注于執行調用并廣播結果。

指揮調度模式還有其他優勢，開發者一開始會編寫一些代碼并論證結果，如果順利，那么會添加異常處理器，而這對之前的代碼不會造成任何影響。此外，如果設計恰當，那么所有的網絡服務調用都會使用相同的基礎命令類，這會減少命令類的數量。

在通用應用中，可以通過異常監聽器調整展示的視圖，這樣iPhone 上的錯誤顯示界面就會適配于該平臺，iPad 上的錯誤顯示界面也會適配于更大的平臺。

這種模式可以快速展示結果，對業務邏輯與異常處理進行關注分離，減少重復代碼以及提供更好的用戶體驗。

5.4 小結
代碼使用網絡時會出現很多錯誤源，理解錯誤源有助于快速診斷并解析網絡問題。借助于Reachability 框架，代碼

本文鏈接：http://my.oschina.net/louiseliu/blog/289253

責任編輯：chenqingxiang 來源： oschina
iPhoneiPad
相關推薦

2011-06-28 09:28:32

InformationiPadiPhone

2021-04-14 07:08:14

Nodejs錯誤處理

2017-03-08 08:57:04

JavaScript錯誤堆棧

2017-04-06 14:40:29

JavaScript錯誤處理堆棧追蹤

2024-03-27 08:18:02

Spring映射HTML

2011-08-10 10:10:21

iPhoneUIPopoverCo

2014-11-17 10:05:12

Go語言

2021-04-29 09:02:44

語言Go 處理

2023-11-08 15:04:55

事務GORM

2011-07-06 15:04:41

ASP

2011-08-11 10:03:43

iPhonecocoaNSRunLoop

2025-06-06 06:45:54

2023-10-26 15:49:53

Go日志

2022-05-06 08:00:51

Golang編程語言Java

2014-07-16 10:08:30

2023-12-26 22:05:53

并發代碼goroutines

2011-12-13 14:15:26

微軟OneNoteiPad

2011-08-04 15:24:53

iPhone開發 交互 MVC

2022-11-16 08:41:43

2011-07-06 15:59:38

iPad iPhone iOS
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 在线看片国产 | 亚洲精品一区在线观看 | а天堂中文最新一区二区三区 | 精品国产乱码一区二区三 | 日韩毛片播放 | 久久久久国产精品午夜一区 | 亚洲人人舔人人 | 日本不卡一区二区三区 | 在线观看亚洲欧美 | 久久久久一区 | 精品国产18久久久久久二百 | 日韩中文久久 | 国产精品日韩在线观看一区二区 | 欧美8一10sex性hd | 成人午夜av | 国产精品久久久久久久久久三级 | 一级a性色生活片久久毛片 午夜精品在线观看 | 亚洲精品高清视频在线观看 | 粉嫩国产精品一区二区在线观看 | 欧美精产国品一二三区 | 亚洲精品国产综合区久久久久久久 | 久久精品亚洲一区二区三区浴池 | 午夜影院普通用户体验区 | 日韩精品 电影一区 亚洲 | 亚洲欧美中文日韩在线v日本 | 日韩电影中文字幕 | 夜夜爽99久久国产综合精品女不卡 | 天天色综 | 超碰520 | 亚洲一区久久久 | 欧美一区二区 | 福利久久 | 国产精品毛片一区二区在线看 | 桃花av在线 | 一区二区在线免费观看视频 | 欧美精品在线一区二区三区 | 欧美一区二区三区久久精品视 | 天天久久 | 国产成在线观看免费视频 | 成人国内精品久久久久一区 | 欧美日韩国产一区二区三区不卡 |