2013-11-02 29 views
31

我正在使用AngularJS開始我的第一個PhoneGap項目。它是一個數據庫驅動的應用程序,使用REST API作爲後端。首先,我不會在本地存儲數據,所以沒有互聯網就不會有太多的工作。但是,我最終希望能夠在本地存儲數據,並在互聯網可用時進行同步,因爲我知道我個人禁用手機上的互聯網連接(空中飛機,電池電量不足),或者沒有酒吧。我在想,如果你能指出我爲這種類型的同步提供了一些好的資源。一些推薦的庫?或者也許是一些關於陷阱的討論以及如何繞行它們。我已經Google了一下,但我想現在,我不知道要問的問題。在PhoneGap中與服務器同步數據的策略

此外,我的意圖是建立它依賴互聯網的第一個,然後添加同步....這是一個好主意,或者我是在拍攝自己的腳?我是否需要從一開始就構建它同步?

我曾經有人建議先將應用程序構建爲本地應用程序,而不是僅限於Internet的部分,這對於它具有一定的邏輯性。遠程存儲對我來說非常重要。我知道這個決定與我的應用目標有很大關係,但從構建這個目標的立場來看,最終的目標是本地存儲+互聯網存儲以及雙向同步,哪些會更容易?或者它甚至有所作爲?

首先,我想使用UUID而不是順序整數主鍵。我也想過爲每個設備分配一個在其生成的任意鍵上加上前綴的ID,但這看起來很微妙。任何人都使用任何技術思考?

我想我需要一個很好的系統來告訴哪些數據已被同步。在客戶端,我猜想任何創建/編輯的記錄都可以標記爲同步。但在服務器端,你有多個客戶端,所以這是行不通的。我想你可以有一個last_updated時間戳,並同步一切更新同步上次成功的同步。

在多個地方編輯記錄呢?如果兩個客戶端進行編輯,然後想要同步,則合併時會出現一些模糊不清的情況,例如在git或其他版本控制系統中合併分支時。你如何處理?我想通過存儲每個提交的差異來做到這一點。我想你可以存儲差異?我想到的越多,聽起來就越複雜。我是在過度思考還是在低思考?

客戶端存儲怎麼樣?我想過SQLite,或者PhoneGap本地存儲的東西(http://docs.phonegap.com/en/1.2.0/phonegap_storage_storage.md.html)。建議?同步將在REST API上進行,交換JSON,所以我想的是將數據實際存儲爲JSON的東西,或者類似JSON的易於轉換的東西,會很好。另一方面,如果我將不得不交換某種數據差異格式,也許這就是我需要存儲的內容?

+0

有沒有人使用過? http://pouchdb.com/似乎與我的很多擔憂有關,但是如果你一直沿着這條路走下去,會很樂意聽到你的想法嗎? – eimajenthat

回答

26

讓我根據我有關同步部分的經驗提供您的問題的答案,因爲我沒有足夠的PhoneGap使用經驗,所以會跳過關於PhoneGap本地存儲v SQLite的問題。

我想知道您是否可以指示我爲這種類型的同步提供一些好的資源。一些推薦的庫?

有許多用於同步PhoneGap應用程序與遠程服務器的開源項目。但是您可能需要根據自己的需求進行調整或實現​​自己的同步功能。下面我列出了一些開源項目。如果你要搜索網絡,你一定已經意識到了它們。

此外,你可以考慮其他的選擇,但是這取決於你的服務器端:

而且,我的意圖來構建它的互聯網依賴的第一,然後添加同步....那是一個好主意,還是我在腳下開槍?我是否需要從一開始就構建它同步?

我認爲同步功能更像是一個額外的模塊,不應該與其他業務邏輯緊密結合。一旦開始考慮測試同步測試策略,您會發現如果您的同步設備與主代碼分離,則測試更容易。

我認爲您可以儘快啓動您的應用程序,並且不需要同步的最低要求的功能。但是你最好先考慮一下你的架構和事先添加同步設備的方式。

首先,我想使用UUID而不是順序整數主鍵。我也想過爲每個設備分配一個在其生成的任意鍵上加上前綴的ID,但這看起來很微妙。任何人都使用任何技術思考?

這取決於你的項目規格,特別是你的服務器端。例如,Azure移動服務僅允許主鍵使用整數類型。雖然作爲主鍵的唯一標識符在分佈式系統中非常方便(也有一些缺點)。

與分配設備ID相關 - 我不確定我是否理解這一點,但我不知道您的項目細節。查看我們系統中使用的同步算法(bidirectional sync using REST between multiple Android clients and central SQL Server)。

怎麼樣在多個地方編輯記錄?如果兩個客戶端進行編輯,然後想要同步,則合併時會出現一些模糊不清的情況,例如在git或其他版本控制系統中合併分支時。你如何處理?我想通過存儲每個提交的差異來做到這一點。我想你可以存儲差異?我想到的越多,聽起來就越複雜。我是在過度思考還是在低思考?

這是您需要考慮如何處理系統中的衝突解決方案的地方。

如果系統中的衝突可能性很高,例如用戶會經常更改相同的記錄。那你最好跟蹤記錄哪些字段(列)已在您的同步進行了修改,然後一旦檢測到衝突:在衝突

  1. 迭代通過服務器端記錄的每個修改後的字段
  2. 比較服務器的每個修改字段都會記錄客戶端的相關字段。
  3. 如果客戶端字段沒有被修改,那麼就不會有衝突,因此只需要用服務器來覆蓋它。
  4. 否則會有衝突,因此將兩個字段的內容保存到報告的臨時位置
  5. 在同步結束時會產生衝突記錄報告。
+0

設備ID背後的想法是爲每個設備使用自己的順序ID,但前綴爲自身唯一的設備ID。因此,例如,我的設備將獲得ID 1,並且您的設備將獲得2.然後,您創建我創建ID爲1的記錄,但如果您願意,它可以是2-1或2-00001。然後當我創建我的第一個記錄時,它將是1-1或1-00001。因此,每個設備都保留自己的序列,並按順序創建ID,但它們可以合併,因爲前綴可區分它們。我不喜歡這個解決方案,儘管我無法完全理解爲什麼。 – eimajenthat

+0

很多很棒的信息@Havrl。謝謝! – eimajenthat

+0

我傾向於UUID。我的服務器端將由我指定。我最初想到的是PostgreSQL或MySQL,但正如我讀到的CouchDB一樣,這聽起來很有吸引力。 – eimajenthat