2016-08-16 64 views
2

雖然與火力地堡發展,我手動在控制檯添加了一個數據記錄,但忘記一個條目,從而導致應用程序崩潰。我已在控制檯中更正了問題,但由於我使用的是Firebase的數據持久性,原始數據錯誤仍然存​​在,導致崩潰再次發生。如果我關閉持久性,一切都很好,但緩存存儲沒有被更新。有沒有人有這個問題,並找到了解決辦法?復位火力地堡緩存

回答

0

緩存應自動更新。由於這發生在沒有後臺線程的情況下,當它在主線程上調用你的代碼時,我希望它能夠更新磁盤緩存,即使你的應用程序代碼崩潰了。

但如果做不到這一點,找回良好的狀態最快的方法是清除應用數據,您的應用程序或完全卸載/重新安裝。

+0

謝謝弗蘭克,我設法解決這個問題,通過使db調用獲取正確的數據有條件。這意味着一開始緩存啓用時什麼都沒有發生。額外的重新啓動後,我可以讓緩存再次同步。看起來Firebase正在異步刷新緩存,但這比我的代碼開始時慢。有什麼我可以添加到我的代碼來防止這種問題?我正在考慮一種可能的解決方案,在發生崩潰時切換緩存並在數據庫同步後啓用持久性。 –

0

我也面臨這個問題,並陷入無盡的碰撞上,啓動循環已經失去了失眠用戶的想法。

至於建議,對於對出現的問題,在時間窗口開始之間創建了一個應用程序,並緩存更新從火力地堡服務器隨後到來的機會。如果在此時間窗口中從緩存中讀取數據,然後如果數據碰巧缺少預期值,並且如果應用程序以假定數據不爲零的方式使用數據,則應用程序崩潰。如果應用程序在緩存更新之前崩潰,則緩存永遠不會有機會更新,並且用戶將陷入無限循環(沒有從應用程序的內存中擦除應用程序的數據)。

至此,我已經對它們是在啓動時調用代碼零值的可能性更加發奮守着處理這個問題。如果nil被檢查並且發現不方便,那麼根據情況,或者(1)如果可能並且如果它不會導致進一步的數據損壞,則應用用適當的值代替零,否則(2)應用進入等待模式幾秒鐘,然後從問題節點開始重新讀取,然後重新嘗試啓動例程。

或許這個故事的寓意是永遠不會假定值不爲零或以其他方式在預期範圍之內。驗證接收時的值或在預期使用時檢查該值或兩者,然後相應地處理錯誤。