如何解決移動軟件中的連接狀態問題

原文地址: http://www.intel.com/cd/ids/developer/apac/zho/325176.htm

挑戰
確保移動應用在任何連接狀態下都能提供幾乎相同的用戶體驗。目前,在全世界數萬個熱點地區我們都能夠使用移動筆記本電腦與 Internet 連接。但即使公共網絡的數量如此之多,仍無法覆蓋大多數地區。真正意義上的無所不在的無線網絡連接可能永遠不會實現,即使在許多城區實現地毯式覆蓋也非一朝一夕能夠達到。與此同時,用戶仍會發現自己並沒有獲得穩定的網絡連接。在這些情況下,需要靜態連接的 Web 應用以及客戶端-服務器應用將失去意義。這種進退兩難的局面提供了一個機遇,各個公司紛紛開發新的應用,或改造現有產品,使其適用於移動環境。

無論是否具有穩定的網絡連接,移動軟件應用都必須平穩可靠地運行。對於多數應用而言,失去網絡連接將導致工作停滯。脫機工作時,我們頭腦中始終盤算着聯機時需要完成的“待處理”任務清單。而當聯機時,我們又不得不考慮各項工作與那些“待處理”清單的優先級,並不時提醒自己手動收集下次脫機時需要使用的所有文檔。最樂觀的結果是,這套工作流方案爲我們帶來了很多麻煩,最悲觀的結果是,它嚴重削弱了我們的工作能力。即使不考慮對工作效率的影響,這種方法也耗用大量帶寬,對內部網絡提出更高要求,增加了蜂窩連接成本。

解決方案
提供本地客戶端接口,與本地數據庫交互,當網絡連接可用時,本地數據庫自動與企業數據保持同步。 特別是,通過使用應用同步或發佈-訂閱模型即可獲得脫機功能。例如,使用企業數據庫引擎,如 Microsoft SQL Server*,您可以設置數據發佈。

在客戶端計算機上,可以安裝 SQL Server* Personal Edition,如果使用 Pocket PC*,則可安裝 SQL Server* CE。第一次對設備進行同步時,所有發佈數據將下載到設備上。但在後面的同步中,僅從客戶端上傳已修改的數據,並僅下載所有客戶端已合併的更新數據,這就降低了網絡帶寬要求。

相對而言,這種功能的實現比較簡單。設備中保存了應用需要的數據(初始同步後),因此,無論網絡連接是否可用,應用都能夠成功運行。根據應用的要求,應用可能僅需要偶爾與後端數據庫進行重新同步。雖然這具有一定可預測的風險(在客戶端應用中使用的數據可能是過時的),但卻降低了解決方案的複雜性。

還有若干種技術,可以擴展 Web 應用,以便更好地服務於經常需要脫機工作的移動用戶。

  • 內容高速緩存: 該技術包括門戶爲響應統一資源標識符(URI)(例如 Web 頁地址)請求而提供的內容脫機緩存。不緩存生成該內容的代碼。例如,超鏈接可能會引用 Java* Server Page(JSP)或 Active Server Page(ASP)。用戶訪問鏈接時,應用服務器運行生成頁面內容的腳本,將 HTML 流返回客戶端。緩存的就是 HTML,而不是 JSP 或 ASP。
  • 代碼複製: 該技術可使門戶內容更加動態化。在提供內容、與用戶交互以及收集和處理數據和數據存儲的過程中,門戶可以執行諸如 Java Servlet、JSP、ASP 等代碼以及服務器控件。該技術僅將代碼從門戶複製到客戶端。
  • 數據複製: 複製客戶端數據可以生成更多的交易型交互以及專門查詢。藉助該技術,應用可以從門戶向客戶端複製數據,也可以從客戶端向門戶複製數據,或者進行雙向複製。複製時將交換並應用所有新數據和更新數據。如果數據僅在客戶端或服務器上可寫,則部署比較簡單;而另一方面,如果多份數據之間的更新是獨立的,則方案的部署比較困難。
  • 仿真: 當用戶在瀏覽器中選擇 URI 時(通過在地址欄中輸入統一資源定位符(URL)或單擊超鏈接),瀏覽器將嘗試聯繫 URI 指定的服務器,並通過超文本傳輸協議 (HTTP) 請求資源。如果瀏覽器無法聯繫服務器,瀏覽器將返回一個錯誤。

通常情況下,本地 Web 瀏覽器將嘗試聯繫網絡上的演示服務器。當系統脫機時,Web 瀏覽器將重定向至提供緩存內容的本地演示服務器(駐留於客戶端)。通過使用多數瀏覽器支持的自動代理機制,開發人員可以輕鬆實現此功能。可以創建 JavaScript 函數以用於自動代理機制,該機制可動態重寫所請求的 URL,然後通過網絡提交請求。該函數會根據網絡狀態修改 URL,以將瀏覽器重定向至本地運行的演示服務器。

本文屬於“如何使軟件應用實現移動化 一文中所述系列內容的一部分。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章