行動裝置的資料存取選項

今天如果是要開發一個在行動平台上的應用程式，應用程式的功能要夠豐富，就勢必得牽涉到資料存取的議題。否則使用者在操作程式時，就如同和海底總動員的 Dory 對話一般，每次開啟程式都只能反覆地進行基本的作業、無法累積操作狀態的資訊。

然而資料要怎麼存，其實會受到程式的需求、使用情境、營運預算等等因素的影響。所以選擇合適的資料存取方案是開發過程中很重要的考量，常見行動裝置的資料存取選項有以下幾種：

• Local
• Client-Server
• Master-To-Master
• Peer-To-Peer

Local

將資料留在程式運行的設備之上，這是最基本的資料存取模式，也是最直接、成本最低的一個選項。二大主要的行動平台都有在 SDK 中提供對應的功能，開發人員只要依照規格撰寫程式即可達到效果。這個選項的最大限制就是沒有辦法體現行動平台的移動特性，應用程式處於孤島的狀態，以致程式在跨裝置的使用上還是有很大的侷限性。

Client-Server

將資料留在遠端的伺服器的選項，這原本就是在 Web 平台上必備的一種方案，由於在瀏覽器上運作的程式無法直接讀寫磁碟機，所有的資料寫入與呈現都要靠與遠端的伺服器互動來提供。不管是要直接登入後端的資料庫來存取資料，還是要透過中介的應用層以 REST 方式傳遞 XML 或 JSON 格式的資料，在技術層面上來說都不是很高的門檻。很多的第三方函式庫都已經大幅地簡化了這部份程式碼的複雜度，開發人員只要把精力投注在資料處理的邏輯上。

這個方案也解決了 Local 選項的缺點，可以在跨裝置的使用情境之下編輯同一份資料，增加使用的彈性。但缺點是建置伺器需要支出額外成本，就算是使用雲端服務，不論是 CPU、儲存空間、還是網路流量，都是要按使用等級定期收費。所以盈收沒有到一定的程度，在營運上會產生很大的負擔。在開發上，由於資料全部都是透過網路的傳遞，如何在資料傳遞的過程中保護資料、如何避免遠端的伺服器遭到入侵是要很審慎地應對，否則可能會因為資料外洩所引起的消費糾紛造成額外的營運損失。在使用上則會因為資料都在遠端，一但網路失去連線就有可能會終止程式的運作，阻礙程式的使用經驗。

Master-To-Master

畢竟行動平台的應用程式有一個比 Web 平台還具優勢的特點是可以直接存取磁碟機，所以融合了前二個方案的優點就是分別在前、後端都設置一個資料儲存的機制，透過同步的方式讓本地端與伺服器端的資料保持一致。如此一來，當前端網路失去連線時，仍然在設備上保有一份資料可以維持程式的運作。而遠端所儲存的資料則可以用來提供在跨設備的情境之下交換資料，達到 Client-Server 方案的便利性。

目前這個選項已經有第三方的框架輔助簡化程式開發的成本，像是：CouchDB 、CouchBase Lite、PouchDB。不過，嚴格來說 PouchDB 應該算是網路不穩時的解決方案，而不是真正的離線使用。

這個架構的缺點除了和 Client-Server 一樣需在後端建置伺服器所可能產生的問題之外，在開發上會出現的是同步規則的處理，因為是多點同時讀寫資料，又混和了在線與離線的情境，所以很容易出現資料衝突的情況。要如何妥善的處理資料衝突，又不致會讓使用者不信任程式的處理模式，是一個需要投入心力思考的關鍵點。

Peer-To-Peer

如果以上的選項都沒有辦法滿足程式的需求，但又想要可以跨裝置來編輯同一份資料，那還可以有一種選擇是讓裝置進行點對點的同步。如果沒有第三方函式庫的搭配，就要自行選寫發送與聆聽網路訊息的程式，須俱有足夠的網路通訊知識才有辦法完成任務。除此之外，還是要自行解決資料交換後的同步與衝突解決的問題。

在缺點上，少了伺服器，當然就不會有建置伺服器所可能產生的問題。但相對地，要付出的開發成本就會提高，至於提到多高就要看對後續營運的品質要求有多少。畢竟這個選項很有可能要自行由網路通訊的中下層開始，重新打造一個輪子，要做到市面上成熟產品的驗證強度來達到相對的穩定度，就成本來看會很可觀。如果只是個簡單的小應用，就不用大費周章地做這種吃力不討好的選擇。