Offline Mode

How Offline Mode Works

The Scanner app is designed to work fully offline after the initial enrollment. All ticket validation (signature verification, expiration checks, duplicate detection) is performed locally using cached data. Only the check-in confirmation step requires a network connection, and even that is queued if the network is unavailable.

Local Database

The app maintains a local SQLite database with the following data:

Data	Purpose
Enrollments	Enrolled events with API keys and gate assignments
Issuer keys	Cached public keys for verifying ticket signatures
Scan history	Record of every scan attempt and its result
Pending check-ins	Queue of check-ins waiting to sync with the server
Ticket statuses	Cached ticket statuses (revoked, checked in) downloaded from the server

This local data enables the scanner to validate tickets and detect already-used or revoked tickets even without an internet connection.

Pending Check-In Queue

When you mark a ticket as used while offline, the check-in is added to a pending queue.

Viewing Pending Check-Ins

Go to menu > Pending Sync. The menu item shows a badge with the count of pending items.

If there are no pending items, the screen shows "All synced."

Each pending item displays:

• Ticket identifier
• Event name
• Last sync attempt time (if a retry was attempted)

Manual Retry

Tap Retry now to attempt syncing all pending check-ins immediately. This is useful when you know the connection has been restored.

Automatic Sync

The app automatically attempts to sync pending check-ins when:

• Network connectivity is restored after being offline
• The app returns to the foreground

No manual action is needed in most cases.

Ticket Status Sync

The app periodically downloads updated ticket statuses from the server for each enrolled event. This sync:

• Runs in the background every few minutes
• Also triggers when the app returns to the foreground
• Downloads the current state of all tickets (which ones are revoked, which are already checked in)

This enables the scanner to reject revoked or already-used tickets even when offline, because the latest known status is cached locally.

Idempotency

Every check-in is assigned a unique identifier (idempotency key) when it is created. This means:

• It is safe to retry pending check-ins multiple times
• The server deduplicates based on this key
• There is no risk of a ticket being marked as used twice due to network retries

Connectivity Detection

The app monitors network connectivity in real time. When the connection drops:

• Scanning and validation continue working normally
• Check-ins are queued locally instead of being sent to the server
• The "Admitted (pending sync)" message appears after each offline check-in

When connectivity is restored:

• The pending queue is automatically flushed
• Successfully synced items are removed from the queue
• The scan history is updated from "pending" to "valid" for synced tickets
• Failed items remain for the next retry attempt

Note: If you are viewing the scan history while a background sync completes, you may need to navigate away and back to see the updated statuses.

Best Practices

• Enroll your device while online. The initial enrollment requires an internet connection to download keys and ticket statuses.
• Sync before the event starts. Open the app while connected to ensure you have the latest ticket statuses and public keys.
• Check the Pending Sync count after the event to ensure all check-ins have been synced.
• Do not remove an event until all pending check-ins have synced. The app will block removal if pending items exist.