DineGlobeDocs

Docs / Platform & trust / Offline & installable app

Offline & installable app

Install DineGlobe on a device, what works offline, what the offline screen says, and why nothing ever queues on a device.

GuestHostDoor

DineGlobe installs as a web app: you add it to a home screen from the browser, with no app store, and it opens full-screen like an installed app. What it refuses to do is pretend. If the network drops, the app shows an honest offline screen and every write fails visibly — nothing is stored on the device and nothing is queued for later. This page explains how to install the app, exactly what the offline screen says, which surfaces stay network-only, and why a device can never half-record an arrival.

Install the app on a device

The install metadata lives in the web app manifest served at /manifest.webmanifest: the app is named “DineGlobe”, opens with its own window (display: standalone), starts at the public home page (start_url: "/"), and carries real icons including a maskable one for adaptive home screens. To install, open dineglobe.com in a mobile or desktop browser and choose the browser’s “Add to Home Screen” / “Install” action.

Two boundaries are built in:

  • The install target is the public root. A home-screen launch never opens a guest booking link or any private surface.
  • Installation grants no authority. The server enforces exactly the same permissions whatever the viewport or installation state — an installed app is not a more privileged app.

The service worker that powers the shell registers only on public surfaces. It never registers from /b, /api, /app or /health, so a guest arriving on a booking link has no service worker in play at all.

What works offline: the offline screen

The only HTML document the app stores is the explicit offline screen at /offline. When you navigate anywhere while the device has no connection, you land there. It reads, verbatim:

You are offline

This device cannot reach DineGlobe right now. Nothing you submitted was recorded, and nothing is waiting to be sent — DineGlobe never stores bookings or arrivals on a device.

Its “What needs a connection” list names the three things that always require the network:

  • Creating, changing or cancelling a booking
  • Recording an arrival or scanning a check-in pass
  • Reading the service book, guest details or payment status

And “What to do now” walks three steps: check the venue’s network or switch to mobile data; reload the page once you are back online — “reloading is safe, since no action was half-completed”; and if the scanner is unavailable when you return, “take the arrival by hand: staff can enter the confirmation code and party count on the arrivals form without any pass.” A “Try DineGlobe again” link returns you to the home page.

What is deliberately network-only

The shell cache is intentionally tiny. The worker’s own strategy:

Request type Behaviour
Any non-GET (every write) Network only — never stored, never replayed
/b, /api, /app, /health Network only, never cached in either direction
Navigations (any page HTML) Network first, never cached — server-rendered HTML may carry session content
/_next/static and /icons Cache first — content-hashed, immutable assets
The /offline page The only document kept in the cache, always available

So the honest summary is: offline you get the offline screen and the static assets. You do not get a stale copy of the service book, a cached guest portal page, or anything that looks like data. A cached response that is marked private or carries a cookie is refused even if a path rule were ever wrong — the header check is a second gate behind the path rules.

Offline writes fail loudly: 503 OFFLINE

If you submit anything while offline — a booking, an arrival, a cancellation — the request never pretends to succeed. The worker answers 503 {"code":"OFFLINE"} and the UI shows an error. Nothing was recorded on the server, nothing was parked on the device, and there is no replay surface of any kind: no “queued admission” exists in the product. When you reconnect, you submit again and the submission lands as a normal, complete request.

The check-in scanner applies the same rule with its own banner. When the device is offline it shows: “Offline — check-ins are online-only. Nothing has been committed or queued; no success is shown without the server.” Its confirm button is disabled while offline, and a rejected scan writes nothing — an arrival exists only when the server has answered.

Why nothing is queued on your device

A queue that sends later would need to store guest data on the device and would eventually create double effects — an arrival recorded twice, a booking that conflicts with one the venue already took. DineGlobe’s answer is structural: the device keeps nothing, so it can never misreport anything. The floor falls back to the manual path the offline screen names — type the confirmation code and party count into the arrivals form — and the system of record stays the server.

If a screen ever appears to have recorded something while you were offline, treat it as a bug: no success message in DineGlobe is ever rendered without the server’s answer.