Offline Data Synchronization and Local Storage
Offline Data Synchronization and Local Storage
The exam tests your ability to choose between Local Entities, Sync Entities, and client variables, and to design sync that survives poor connectivity.
Core rules
- Local Entities live only on the device; they are ideal for drafts, cached lookups, and device-only data.
- Sync Entities are backed by the server and participate in Offline Data Sync. Define sync rules, then call the Sync action when connectivity is available.
- Client Variables persist on the device and are not encrypted by default; do not store secrets there.
- Sync is not automatic on every screen load. Trigger it deliberately, show status, and handle failures.
- Conflict handling needs a strategy: version columns, timestamps, or server-side validation; last-write-wins is not always acceptable.
Worked example
An inspection app captures notes and photos offline. Store notes in a Sync Entity so they upload later. Store photo files in a Local Entity and upload them through a Server Action after the note syncs, keeping the local file until the server confirms. Reasoning: syncing large binaries with every record increases payload and failure risk; separating metadata from files gives retry control.
Traps
- Using a Local Entity for data other users must see.
- Calling Sync in OnRender or on every list scroll.
- Ignoring sync errors and leaving the UI in a “synced” state.
- Assuming client variables are secure storage.
- Forgetting that a Sync Entity's local copy can be stale until sync completes.