“Works offline” is an attractive promise for an event upload page. In practice, a browser cannot send media without a network, may not retain a selected File after restart, and cannot rely on background execution across mobile platforms. A useful offline design is honest about those constraints.
Define what offline means
There are several different capabilities:
- the page shell can open from cache;
- selected-file metadata survives a temporary disconnect;
- an in-progress chunk can retry when connectivity returns;
- the full original file survives a page reload;
- upload continues after the browser closes.
Do not group them under one badge. Test and document each supported behavior.
Cache only the application shell
A service worker can cache HTML, CSS, JavaScript, and static instructions. Avoid caching private album responses or signed upload URLs. Version the shell and provide a safe fallback when an old client talks to a new API.
self.addEventListener('fetch', event => {
if (isStaticAsset(event.request)) {
event.respondWith(cacheFirst(event.request));
}
});
Event state should come from the network when available and fail closed when authorization cannot be checked.
Persist resumable metadata
IndexedDB can store upload IDs, committed parts, file size, type, and expiry. It usually cannot guarantee access to the original File after a restart. The interface should say “Reconnect to continue” for a live page and “Select the same file to resume” after a full restart.
Verify reselected files with name, size, modification time, and an optional partial fingerprint. Do not upload a different file into the old session merely because the filename matches.
Treat connectivity events as hints
online and offline events do not prove that the upload host is reachable. Captive portals, DNS problems, and blocked storage domains are common. Pause after repeated network failures and probe the control API with a bounded timeout.
When connectivity returns, fetch committed parts before resending. A response may have been lost while the server stored the bytes.
Be cautious with Background Sync
One-off Background Sync is not uniformly supported and may not run promptly. Passing large File objects from a closed page to a worker is especially unreliable. Use it as an optimization for small control messages, not as the only path for important media.
Keep the page awake only when the user has chosen to continue, and avoid hidden battery-draining loops.
Design the recovery UI
Show each file separately with states such as waiting for connection, ready to resume, needs re-selection, expired, or accepted. Preserve the guest's progress and explain the next action. A global red banner is less useful than per-file recovery.
If the event closes while offline, do not discard the local record immediately. Tell the guest to keep the original and offer the organizer's support route if appropriate.
Test real interruptions
Use airplane mode, a captive portal, screen lock, tab eviction, browser restart, and Wi-Fi-to-cellular transitions. Test on actual iOS and Android devices. Development tools that toggle “offline” do not reproduce mobile lifecycle behavior.
I help build Gathmo and have a commercial interest in resilient event uploads. The Gathmo no-app browser flow provides product context; the recovery principles here apply to other PWAs and upload tools.
A trustworthy offline experience never implies that bytes have left the phone when they have not. It preserves safe state, detects reconnection, reconciles with the server, and tells the user exactly what remains to do.
Top comments (0)