第6章已經討論過和遠程服務交互的用戶接口所面臨的一些大的挑戰，例如UI線程中不要綁定運行時間較長的任務。第3章還探討過Android的內容提供者API共享方式和REST風格的Web服務間的對應關係。內容提供者的數據操作可以直接映射到REST風格的數據操作，本章將介紹如何使用內容提供者的URI來請求網絡數據。建議充分利用這種對應優勢，在實現內容提供者時，把它作為位於應用和需要從應用獲取數據的網絡請求之間的異步緩衝區。使用這種方式編寫的應用會簡化，而且可以規避掉在Android和其他Java編程中遇到的一些常見的UI和網絡編程錯誤。
一般而言，Java UI編程人員，無論是對企業應用還是移動應用，編寫的移動和桌面應用都過於脆弱，有時直接在UI線程上執行了網絡請求，而且通常情況下還沒有緩存這些請求所獲取到的數據。在大多數應用中，每次用戶請求時，在UI上顯示的所有數據都需要通過網絡來獲取。信不信由你，在20世紀80年代和90年代，當遠程的文件系統不可用時，UNIX工作站經常僵死。如果採用了本地動態緩存機制，那麼在無法訪問遠程文件系統時，這些工作站理應還可以繼續運行，在可以訪問時再執行數據同步。開發人員需要在潛意識中就注意確保其應用能夠正確地訪問和存儲網絡數據。
在J2ME中依然存在這個問題，開發人員會把網絡狀態緩存到名為RMS的記錄管理系統中，該RMS庫不支持查詢，也不支持MVC通知機制。J2ME開發人員需要擴展自己的純Java線程，添加對網絡請求的支持，這通常導致應用很脆弱。如果Web瀏覽器需要在UI線程上加載網絡數據，你會發現當因網絡掛掉而導致UI線程被鎖定時，該Web瀏覽器就完全僵死了，必須由操作系統殺死這個進程才能退出。瀏覽器所顯示的頁面和所有圖片在每次用戶查看時都需要重新下載，這使得用戶體驗非常差——假定請求沒有導致整個應用掛掉。造成這種現象的一個原因是，操作系統通常把對網絡數據的加載和緩存工作全部留給應用本身，只提供很少的庫來幫助開發人員正確地實現這些任務。
要解決這些問題，可以使用完全異步的接口來處理網絡交互和數據存儲。通過這種方式，開發人員必須要思考什麼時候可以請求網絡數據——在UI線程上使用該API是否都是安全的。在移動環境中，這種思想變得更加重要，因為間歇性的網絡連接增加了不良代碼被掛起的可能性。
建議使用內容提供者API作為網絡的異步模型，緩存網絡狀態，這樣應用的視圖和控制器不需要自己的打開連接或訪問數據庫機制。可以很簡單地把provider的API映射到已有的基於REST的Web服務的API——提供者只是作為應用間的橋樑，把請求轉發到網絡，並緩存需要的結果。本章將說明這種方式會如何簡化應用，並解釋這種技術的更多優勢，包括它如何把Web和AJAX編程的一些良好的特性結合到Android應用中。關於AJAX編程的更多信息，可參考http://en.wikipedia.org/wiki/Ajax_(programming)。