我是否應該使用不同的類/方法/模式來處理數據的本地雲同步？

Question

我不熟悉Azure移動服務以及移動開發。

根據我在網頁開發方面的經驗，當用戶請求更多數據時，從數據庫中檢索數據是一部分完成的，即網站不會一次加載所有數據。

我在移動應用中實現這個原理，其中數據被加載（如果已經在本地數據庫中）或者在用戶滾動時下載（如果還沒有在本地數據庫中）。

我正在使用Azure移動服務同步表來處理應用程序中的數據加載。但是，我不能分頁下載數據。根據post，PullAsync方法會下載自上次同步後更改/添加的所有數據，並且不允許使用take/skip方法。這是因爲PullAsync使用增量同步。

這意味着應用程序首次啓動期間將會有大量數據下載，或者即使用戶未請求上述數據，應用程序仍未上線一段時間（即滾動到它）。

這是處理移動應用程序中數據的好方法嗎？我喜歡使用SyncTable，它可以處理很多重要的數據上傳/下載內容，例如數據上傳排隊，數據更改的下載/上傳。我只關心下載用戶不需要的數據。

或者，也許有我能做的事情來限制項目PullAsync下載？ （除了deleted = false和UserId =當前用戶的UserId）

當前，我限制了用戶登錄後以及用戶拉動刷新時PullAsync被調用到加載屏幕。

Answer 1

移動開發與網站開發有很大不同。雖然將大量數據加載到無狀態網頁是一件壞事，但將相同的數據加載到移動應用程序可能實際上是一件好事。它可以幫助應用程序的性能和可用性。

使用類似脫機數據存儲的主要目的是偶爾斷開連接的情況。總是需要考慮建築的權衡。 「多少太多」是這些折衷之一。到服務器的往返數量是多少？多少數據傳輸太多？你能找到你傳遞給移動設備的數據的正確平衡嗎？當載波信號丟失時，與服務器「喋喋不休」的移動應用程序可能無法使用。

在你的問題中，你建議「也許有我能做的事情來限制項目PullAsync下載」。爲了避免大量下載，您可以設計您的應用程序以允許用戶設置下載標準。如果UserId沒有意義，可能是服務日期或在計劃中向前或向後的天數。尋找正確的「分區」數據加載到設備將是您的應用程序可用性的關鍵考慮因素...在線和離線。

您的解決方案沒有一個正確的答案。但是，關鍵考慮因素應該是帶寬，數據計劃限制，運營商覆蓋範圍以及用戶體驗連接和斷開連接。記住......你的移動應用程序是「有狀態的」，並且你不限於往服務器進行數據往返。這意味着你有一點自由去做你不想在網頁上做的事情。