Offline and retry

An offline screen distinguishes device network connectivity from actual API reachability. Retry rechecks the service and keeps the previous screen state when still offline.

Never retry a payment blindly. A customer should first see the existing draft/order state reconciled with the server. The native SQLite driver is still missing; persistent offline ordering cannot be promised yet.

Three different kinds of unavailable

No device connection means Android reports that no viable network link is present. A service outage means the phone may have Wi-Fi/mobile connectivity but the configured HSLG health endpoint is unreachable, times out or reports an unexpected service state. An uncertain transaction means the network or app lost contact after submitting a request, so the server/provider may already have processed it. These must be distinct UI states because the correct next action differs.

What Retry should do

On Retry the app checks device connectivity and the HTTPS service health route again. It preserves the current venue, table and visible draft while checking. If still offline, the message remains and the customer can return to local views where safe. If the service responds, only supported non-financial reads may automatically refresh. Draft/order/payment requests require their existing idempotency key and a reconciliation read before retransmission.

Current implementation limits

The shared UI contains an offline/Retry journey. The Capacitor Network adapter and explicit API health fetch are written in source. The native SQLite driver and reliable offline outbox have not been verified on a real phone. Do not promise that a basket or queued draft survives an OS crash until a test has demonstrated it, and never show a fabricated paid confirmation merely because the device regained internet.

Operator testing

On a genuine APK, enter a venue and build a nonpayable draft. Toggle airplane mode, then reconnect with the HSLG server deliberately unavailable. Observe that the UI distinguishes the two conditions. Repeat during an order create response timeout and verify the server is queried by its original idempotency key rather than producing duplicates. Reboot the device with the basket open to test persistence once the native driver exists. Record exact API status and phone build in the evidence report.