Use the app offline and reconnect
Customer App can show loading, connection-related, unavailable, stale, or reconnecting states. These states describe different parts of the experience; one connection signal does not prove that the current service, data, realtime stream, or previous action is settled.
The current Customer App does not establish one automatic recovery, safe retry, exactly-once action, or current-data contract across every screen. A reconnect, reload, app restart, returned screen, or connected realtime indicator does not prove that an earlier account, cart, order, payment, or message action failed or completed.
Separate the connection layers
| Layer | What it can tell you | What it does not prove |
|---|---|---|
| Device connection signal | The device reports that a network interface is connected or disconnected | That the internet or an Ordering service is reachable |
| Internet and service reachability | A required service can currently answer | That the response belongs to the latest customer/account/project state |
| Screen data | The current screen has loading, available, empty, unavailable, error, or retained information | That retained information is fresh or that a write settled |
| Realtime connection | A realtime channel reports connecting, connected, or disconnected | That every missed event was replayed or that displayed data is current |
| Operation settlement | Ordering returns the authoritative result for one exact operation and context | That a connection error means no server or provider effect occurred |
Treat each layer separately. “Connected” is not a substitute for current data or an authoritative operation result.
States you may see
| Observable state | Safe interpretation |
|---|---|
| Loading before a customer screen appears | Startup, configuration, session, order context, or another dependency is unresolved; no customer action is confirmed |
| Connection-unavailable screen | The current navigation state received a disconnected signal; the exact service/data result is still separate |
| Existing screen remains visible | The route can remain mounted even while connection changes; displayed information can be stale |
| Empty or unavailable content | The current read did not produce usable content; it does not identify whether the cause is connectivity, authorization, configuration, or resource state |
| Realtime status says connecting/disconnected | The event channel is not currently reported as connected; missed data and room/listener cleanup remain unverified |
| Realtime status says connected | The channel connected at a point in time; it does not prove complete event history or current screen data |
| An action lost its response | The result is unknown until the same authorized operation is reconciled |
A dedicated connection screen is conditional. It is not a universal overlay or firewall for every mounted customer screen.
Restart and retry boundaries
Some current connection controls request a full app restart. A restart is not a retry of one read or action, and it does not prove that in-flight work was cancelled, rolled back, or completed.
Do not use restart, reload, foreground return, Back, account switch, project switch, or repeated tapping as a way to test an uncertain result. A future safe implementation must classify work as:
- read-only refresh: can request current authorized data without changing product state;
- resumable operation: continues one existing idempotent operation using its authoritative receipt; or
- never automatically retry: payment, order placement, message send, account/session mutation, provider handoff, or another consequential action without a proven operation contract.
The current pinned paths do not establish that classification globally.
Lost response means unknown
If connection changes after an action is requested, an error or missing response does not prove that no effect occurred. Keep the exact account, project, cart, order, amount, conversation, or other operation context unchanged while the owning screen reconciles its authoritative status.
Do not repeat the action until the app presents a final supported result. For checkout, continue to follow Checkout status and retry guidance.
Persisted choices and account changes
Some choices can exist in local storage, App state, Ordering state, or more than one layer. Reconnecting can expose a difference among those layers; it does not guarantee that one copy wins or that a delayed write is safe.
Logout, login, account switch, project switch, app reinstall, and cleared local storage can change the owner of cached data and pending work. Old responses, realtime events, rooms, listeners, provider callbacks, and stored choices must not update the new context. The current Customer App does not establish that cleanup across every journey.
Realtime cleanup boundary
Realtime clients can queue room, listener, leave, or reconnect work while disconnected. A future accepted implementation must expire, deduplicate, and clear that work on unmount, logout, account/project change, or replacement by a new connection generation.
Until that lifecycle is verified, do not interpret reconnect as proof that:
- every room was left or rejoined correctly;
- every listener exists exactly once;
- every missed event was delivered;
- a prior account can no longer receive updates; or
- the current screen is synchronized.
What to do
- Read the exact current message and keep the current task unchanged.
- Do not assume retained information is current.
- Avoid repeating any action that could change an account, cart, order, payment, message, review, favorite, address, or provider state.
- Wait for the owning screen to show an available, unavailable, failed, completed, or still-unknown result.
- Use trusted in-app navigation to review current state; do not reuse a private link, callback, notification, or identifier.
Troubleshooting safely
The app shows a connection screen
Do not press a restart/reload control solely to prove the last action's result. If no consequential action is pending, use only the visible supported recovery and then verify the destination data separately.
The app looks connected but data has not changed
A network or realtime indicator does not certify freshness. Keep the current state and use the screen's supported read-only refresh or status path when one is explicitly available.
Connection changed during checkout, payment, or order placement
Treat the result as unknown. Do not place, pay, confirm, reopen a provider, or switch methods to test it. Reconcile the existing operation through its owning guidance.
A message or account change has no response
Do not send or submit again automatically. Check the current thread or account state through trusted navigation without copying private content into support notes.
Realtime repeatedly connects and disconnects
Do not infer missed-event recovery. Record only the value-free screen/status class and approximate time; keep account, order, message, location, socket, and provider identifiers private.
The state changes after logout, login, or project change
Stop. Old cached data or late callbacks can belong to another lifecycle. Do not continue until the current account/project and owning screen are clearly established.
Accessibility
Connection, loading, stale, unavailable, realtime, and unknown-operation states should be conveyed with text and semantic status, not color or animation alone. Screen readers need a concise announcement, a labeled recovery control, and a safe return path. Restart/reload must not be the only way to leave an error state, and large text must not hide the message or action.
This is the required verification posture, not a claim that every current state already meets it.
When to recertify
Repeat isolated zero-effect review after changes to connectivity classification, startup/navigation registration, restart/reload, read refresh, operation receipts, foreground recovery, persisted choices, account/project teardown, realtime queue/room/listener handling, provider callbacks, status wording, accessibility semantics, or App/shared-components/API authority pins.
Related references: Customer App overview · Startup, connection, and update states · Customer App routing behavior · Account settings · Checkout status and retry guidance