- First run in the native app shows only the pairing screen (VenuesPage):
scan the manager's pairing QR or type the server address; the server must
answer /api/system/identity as xenia-pos with a supported api_version, and
a QR's ?pair=<site_id> must match - a code from another venue is refused
- /venues (native only): list of paired venues, switch (reloads into that
venue's own token/IndexedDB), remove (data kept - may hold unsynced
orders). Reachable from the login screen, the user menu and the offline page
- QrScannerModal: WebView camera via qr-scanner (no Google Play Services
dependency, carries over to iOS); requests the camera once up front so the
Android prompt appears a single time and "denied" gets its own message
- Hardware back: @capacitor/app listener - no-op on root screens (/, /tables,
/login), otherwise history back. Path-based because Chrome's history
intervention makes the WebView report canGoBack=false for the sentinel
entry AndroidBackGuard pushes
- Before pairing no IndexedDB is opened, so nothing is created under the
un-namespaced name
- InstallAppBanner now shows in plain-HTTP browser mode only when the venue
server actually serves the APK (HEAD /downloads/xenia-waiter.apk)
Verified on an Android 15 emulator (API 35) with real taps via adb and state
via WebView DevTools: wrong address -> error; other venue's QR -> refused;
pairing -> venue-namespaced storage, live WebSocket; back on /tables keeps the
app open; restart keeps venue + session; second venue pairs logged-out and
switching back keeps venue 1's session; camera deny -> one prompt + message;
allow -> live preview. Signed release APK installed and paired. Web modes
(same-origin, plain-HTTP LAN IP, VITE_SERVER_URL) re-verified in Edge.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
bonaminandClaude Opus 5.5
a486e3ff63