Google Gears 架構簡介

離線資料庫的考量

在一般的 web application 中，資料的儲存都是在 server 端負責的，因此一般的流程都是從 server 取得資料後在 client browser 中顯示，若要讓 web application 可以離線(offline)運作，有幾個因素必須要考量到：

1. 必須將 data layer 的部分獨立出來
2. 有哪些功能是需要離線運作的
3. server 與 client 資料同步的問題
   

Google Gears 離線架構說明

以下用圖來比較以下一般的 web 架構與 Google Gears 所提出的離線 web 架構：

一般架構：

離線架構：

看了上面的架構圖後，其實應該也不太難揣測 Google Gears 是怎麼運作的了。

將一般架構與離線架構相比較，可以發現在離線架構中扮演最重要的角色的即為「Data Layer」與「Data Switcher」，說明以下兩者所負責的工作。

Data Layer

Data Layer 所負責的工作其實很簡單，最主要的部分是將 application 的資料需求 pass 到 server，並接收 server 所回來的資料，再將資料交給 application 做處理。

通常提供了一組 API 供 application 來呼叫，可能有些複雜的資料處理、轉換工作都會在 Data Layer 中完成。

Data Switcher

Data Switch 所扮演的角色就相對很重要了，在整個架構中，Data Switch 為 Application 與 Data Layer 的中介橋樑，在 Data Switch 中會決定來自 Application 的資料需求是要 pass 給 server，或是在 local 端進行處理。

因此，在考量系統中的哪些部分必須加入離線(Offline)運作的功能，或是何時需要使用到離線運作的功能，就必須實作於 Data Switch 中，此部分則端看系統實際的使用需求了! 有些功能是必須要 on-line 才有意義的，例如：即時通訊；基本上，存取越頻繁的資料越適合移到 local data layer 來處理，這樣可以大大減少 remote connect 的機會，提升系統效能。


離線系統的模式

離線系統的模式，大致上可以分為兩種，一種是讓使用者可以決定何時讓系統連線，何時離線，稱為 Modal；另一種則是會自動偵測網路連線情況來決定處理方式，稱為 Modeless。

當然不同的模式有不同的優缺點，以 Modal 為例，由於 on-line 與 off-line 的情況是由使用者決定，因此程式開發上較為容易，不過若是使用者搞不清楚狀況，可能就會有沒有資料可用的情形發生(在進入 off-line狀況之前忘了先抓取一些資料來用)，或是僅有舊資料可用的狀況(一直忘記更新 server 中的資料)；而 Modeless 的優缺點大致上跟 Modal 是相反的，因此開發較為複雜。

而開發時要選取何種模式，則是要根據系統實際會運用的狀況以及使用者對電腦系統操作的熟稔程度來決定。


資料同步

開發 off-line 的系統，資料同步是最重要的問題，這個部分有兩種方式可以達成，其中一種是讓使用者決定何時進行讓 local storage 與 server 的資料同步，通常在 UI 上擺著按鈕用來進行此項操作；而另外一種則是系統會自動偵測連線狀況，在不影響正常使用的情況下，每次一部份一部份的將 local storage 與 server 上的資料進行同步

讓使用者自行選擇資料同步時間點的作法是很容易的，但是也必須考慮到使用者對於資訊系統的操作是否瞭解；而比較困難的是自動偵測連線狀況，必須有一個額外的機制來處理資料同步的工作，通常稱為 Sync Engine，以下用一張圖來說明整個架構：

透過上面這張圖，可以看到 Sync Engine 必須與 local database 及 server(Internet) 進行溝通，因此這個部分的開發勢必較為困難，不過由於所有工作使隱藏起來在背景執行，因此不會影響到系統的使用；至於 Sync Engine 如何實作，最主要還是根據系統需求來決定囉!!