Ten-Day Offline Inspections with Sync Conflicts
An environmental agency sends 6 inspectors to remote watersheds for up to 10 days with no cellular coverage. Each inspector carries an iPad and must view about 1,800 assigned stream-monitoring sites from a hosted feature layer of 46,000 features, create new inspection points, and attach 2 to 4 photos per site. The developer built the field app with the ArcGIS Maps SDK for JavaScript and pre-cached map tiles in IndexedDB. In the first field test the basemap appeared, but the feature layer was blank in the field, new inspections could not be saved, and photos did not upload. When the tablets returned, one inspector's edits overwrote another's. The layers are hosted feature layers shared to a group, and sync is currently disabled. The agency wants a repeatable deployment for each trip and no more than 2 GB stored on each device.
1. Assess the offline architecture choice and identify what must change before the next trip.
Read the worked answer
The JavaScript Maps SDK is the weak link. It can cache tiles and, with custom work, some data, but it is not the supported path for a multi-day offline editing workflow with attachments and bidirectional sync. The blank layer and failed saves are what happens when the app has tiles but no offline copy of the feature data and no edit queue that survives restarts.
Move to an SDK designed for offline: ArcGIS Maps SDK for .NET, Kotlin, Swift, or Java, or a configurable app such as ArcGIS Field Maps or QuickCapture if the workflow fits. Those provide offline map areas that package the basemap, the feature data as a geodatabase, and attachments, plus a sync task that can be resumed.
The layers must be prepared as well. Sync must be enabled on the hosted feature layers, and attachments must be enabled if photos are expected to travel with features. Verify both in the layer settings and republish if a layer cannot support sync in its current configuration.
Finally, stop hand-rolling IndexedDB caching. It will not handle schema changes, attachment association, or conflict resolution, and it creates an unmaintainable second data store. Test the rebuilt app in airplane mode on the actual devices before deployment.
2. Design the editing and sync model, including how conflicts should be resolved.
Read the worked answer
Design around replicas. Each trip takes an offline map area and creates a replica of the sync-enabled layers for the assigned extent. Restrict each inspector's area and site assignment so replicas do not overlap; overlapping replicas are the direct cause of the overwrite, because two devices hold versions of the same feature and the last sync wins.
Configure conflict handling deliberately. Last-write-wins is simplest but silently discards work; per-field or manual reconcile preserves both versions for review. Decide per data type: photo attachments are additive, but an inspection status is not, so a status conflict should surface for a human decision rather than vanish. Use globalId to correlate attachments with features, and sync attachments with their feature rather than separately.
On the device, queue edits and attempt sync when connectivity appears; make sync resumable, log failures, and show the inspector an explicit pending and failed count. Define what an inspector does with an unresolved conflict in the field: mark it and continue rather than blocking the day.
Test three cases before deployment: two devices editing the same site in airplane mode and then syncing, an interrupted sync, and an attachment that exceeds the size limit.
3. How do you keep each device under 2 GB while still delivering the assignment?
Read the worked answer
Budget the storage before the trip rather than after a failed download. 1,800 sites times 3 photos at 1 MB is already 5.4 GB before the geodatabase and tiles, well over the 2 GB cap.
Options, usually combined: compress images at capture to roughly 300 to 500 KB with a 1,600-pixel long edge, cap attachments per site, and store photos outside the geodatabase so they upload separately when connectivity returns. Reduce the offline area to the assigned watershed boundary rather than the whole region, and choose the coarsest tile level of detail that still supports navigation, measuring the resulting package rather than guessing. Limit the feature layer to assigned sites through a definition expression or a filtered view.
Then measure the actual geodatabase and tile package on a test device and add a margin for the edit queue and photo cache.
Make deployment repeatable with a pre-trip checklist: generate the area, verify sync and attachment settings, install the current build, record free space, and run a short airplane-mode test. Give inspectors a fallback, such as paper forms or a spare device, if sync fails at the trailhead.