推 Blueshiva: 這要看Firebase怎麼處理的啊，不過就算 60.251.43.139 05/14 11:10
→ Blueshiva: 寫到disk一樣有可能中途掛點資料毀損， 60.251.43.139 05/14 11:10
→ Blueshiva: 你要測試的話一個簡單的方法是把device 60.251.43.139 05/14 11:13
→ Blueshiva: 離線，然後產生資料，接著把App force 60.251.43.139 05/14 11:13
→ Blueshiva: quit掉重開，重新上線，看資料有沒有繼 60.251.43.139 05/14 11:13
→ Blueshiva: 續傳上去就知道了。 60.251.43.139 05/14 11:14
→ Blueshiva: 我猜Firebase這種規模的服務，應該會把 60.251.43.139 05/14 11:14
→ Blueshiva: 資料先存在disk避免遺失啦，如果沒有的 60.251.43.139 05/14 11:15
→ Blueshiva: 話，解決方法大概就是發發request/加入 60.251.43.139 05/14 11:16
→ Blueshiva: Firebase自己改/自己在Firebase外面多 60.251.43.139 05/14 11:16
→ Blueshiva: 加一層，自己做資料同步 - 你不會想幹 60.251.43.139 05/14 11:17
→ Blueshiva: 這種事的 60.251.43.139 05/14 11:17
推 iPhoneX: 這功能應該是存 disk 114.32.43.138 05/14 18:47
→ iPhoneX: 他叫 Disk Persistence 不是嗎 114.32.43.138 05/14 18:47
推 iPhoneX: 但是他文件後面說 114.32.43.138 05/14 18:50
→ iPhoneX: Transactions are not persisted 114.32.43.138 05/14 18:50
→ iPhoneX: across app restarts 114.32.43.138 05/14 18:50
→ iPhoneX: 所以你要自己想辦法存沒上傳的資料 114.32.43.138 05/14 18:51
→ Killercat: 我以前的作法是存core data再開一個 1.164.139.4 05/16 11:50
→ Killercat: thread去把core data的東西一筆筆dump 1.164.139.4 05/16 11:51
→ Killercat: 上去(目標不是firebase 但是我想應該在 1.164.139.4 05/16 11:51
→ Killercat: 這例子也能用上) 1.164.139.4 05/16 11:51
→ Killercat: 一筆存成功就砍一筆 1.164.139.4 05/16 11:52
謝謝各位解答 Killercat的想法也是我一開始的想法 我應該會這樣做 謝謝
※ 編輯: dream3325 (208.181.204.234), 05/17/2019 00:21:38