2016/6/25

行動裝置的資料存取選項

今天如果是要開發一個在行動平台上的應用程式,應用程式的功能要夠豐富,就勢必得牽涉到資料存取的議題。否則使用者在操作程式時,就如同和海底總動員的 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 方案的便利性。

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

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


Peer-To-Peer

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

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






0 意見:

張貼留言