Powering offline-first forestry in Europe's wilds
summary
An offline-first Flutter app uses two on-device stores—a data database for live reads and a diff database as a change log—and uploads batched diffs to a server via a sync queue. Implementation uses drift on Android, iOS and Web, solves duplicate-ID rejects by regenerating IDs, fixes out‑of‑memory by moving from the in‑memory DB to drift, and accepts long initial syncs (p50 ~30s, p999 occasionally hours). Result: far lower server cost, resilient UX during peaks, and recoverable sync failures.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 1:46First offline-first at Doodle
- 2:49Shift to offline-first
- 4:58OSA forest mission
- 6:02Forestry app demo
- 7:26Offline sync explained
- 9:31Sync queue in practice
- 12:24Sync errors and complaints
- 13:48Duplicate IDs offline
- 16:41Out of memory exceptions
- 18:08Long initial loads
- 19:12Cross-tab web issues
- 20:16Invalid token sync fails
- 22:25Offline benefits
- 25:13Why offline is user-friendly
- 25:55Tree classification demo
- 28:07Conclusion
related talks
33mSurviving Network Failures: Building Resilient Offline-First…
42mGoing Offline first with Flutter
21mOffline first Flutter applications
36mLessons Learned from Launching a Flutter app in Production
50mZero to app: Livecoding a cross platform app with Firebase and Flutter
28mFlutter App Implementation Seen in Code
44mBuilding Pieces for Developers Our Journey with Flutter and Dart
30mCat-like Development: Flutter for Efficiency