可以將第二種模式理解成網絡版的MVC，內容提供者從網絡中獲取數據，再把這些數據推送給普通的Android MVC。可以把內容提供者理解成網絡狀態模型——提供者可以在數據請求中包含本地狀態，或者可以從網絡中獲取數據。通過這種方式，控制器和視圖代碼不應該直接創建網絡請求來訪問和管理應用數據。相反，應用視圖和控制器應該使用ContentResolver API向內容提供者請求數據，內容提供者會異步加載網絡資源，並把結果保存到本地緩存中。此外，提供者應該盡量避免網絡調用，優先使用本地數據庫的數據來快速響應請求。通過這種方式處理請求可以確保不再無故阻塞UI線程，UI可以盡快顯示某些數據，從而提高用戶對UI的整體滿意度。以下是關於提供者查詢數據的更詳細的說明：
1.提供者匹配輸入的URI，查詢本地數據庫，獲取已有的能夠匹配該查詢的內容項。
2.提供者總是想要獲取該查詢的最新狀態，擴展異步REST請求，從網絡中獲取數據。你可以把該行為實現成可以根據請求進行配置。
3.提供者給客戶端返回最初的本地查詢的結果游標。
4.異步加載線程應該決定在提供者緩存中的數據是否需要刷新；如果需要刷新，提供者就從網絡加載並解析數據。
5.當網絡上有新的內容時，提供者直接向數據庫中插入新的數據項，然後通知該URI的客戶端。因為在內容提供者中已經執行了插入操作，因此不需要調用ContentResolver.insert方法。擁有包含老版本數據的光標的客戶端可以調用Cursor.requery方法刷新數據。
以上操作序列執行之後，視圖和控制器最終會更新網絡數據，但只是由內容提供者創建網絡請求。我們把對當前不在提供者的數據集中的資源請求作為加載資源請求——活動提供者查詢的負面效果是網絡請求會向緩存中加載數據。
圖13-1說明了在上述操作序列執行期間，內容提供者內部所執行的操作。
圖13-1：網絡提供者替客戶端緩存數據
對於每個查詢，該操作序列使用提供者所創建的唯一Cursor對象，然後返回到視圖。當數據發生變化時，只需要提供者通知UI。視圖和控制器不需要收集數據，也不需要更新模型。當數據可用時，內容提供者通知光標重新查詢。數據管理的功能被封裝在內容提供者內部，這種方式簡化了視圖和控制器中的代碼。提供者客戶端請求數據，並快速接收到游標；當網絡數據到達時，通知游標。重要的是，是否執行通知取決於數據是否已經在本地數據庫，而且只要內容提供者客戶端仍在使用光標，該光標對象就不會關閉。游標和數據庫關閉會導致客戶端查詢不到任何結果，這會造成難以確定某個組件（如列表）為空是因為錯誤地關閉了游標，還是某個查詢確實沒有結果。