How offline reading works

Rescues happen in gorges, floodwater and mobile black spots. So the operator app is not an app that works offline too — it is an offline app that syncs when it can.

Reading never touches the network

Every screen in the operator app reads from a database on the device. Opening a guide in a tunnel is the same code path as opening it on wifi. There is no spinner waiting on a server, and no degraded mode to fall into, because the network was never in the path.

That is why publishing feels indirect from the console side: you are not pushing content to a screen, you are changing what the next sync will hand over.

When a device syncs

Nobody has to press Sync now. The app syncs on its own:

• when it opens, and straight after someone signs in;
• when it comes back to the front, if the last try was more than a minute ago;
• when the connection returns after being offline;
• every 15 minutes while it stays open.

When a critical item is published or released and someone sends the notification, phones also get a silent push that syncs them in the background, so the procedure is on the phone before anyone opens it. Phone systems limit background work (an iPhone the operator has swiped closed is not woken), so this speeds things up rather than replacing the syncs above.

What a sync does, in order

The order matters and surprises people:

1. Send first. Anything the operator did offline — favourites, checklist progress, quiz attempts, acknowledgements, a flagged issue — is sent to the server before anything is fetched. Their work is never overwritten by an incoming change. See how the offline queue works.
2. Ask for what changed. The device says which app version it is, and sends the point it last synced up to. It gets back what has changed since, plus a list of things that were deleted. That point comes from the database clock and allows for publishes still being saved at that moment, so an item published while a sync is running arrives on the next one instead of being missed.
3. Apply it locally, one item at a time. An item this version of the app cannot show (a new content type, say) is skipped rather than stopping the whole sync; Settings then says N items need a newer version of the app, and they arrive once the app is updated.
4. Fetch the media. Images attached to that content are pulled down afterwards, so the guide is genuinely readable with no signal — not just its text.

When the server says no

A sync can be refused, and the app acts on the reason:

• This version of the app is too old. ROK can retire old app versions (a platform setting). A retired version stops receiving changes and its home screen says Update ROK to keep receiving changes, with a link to the store. Everything already on the phone stays readable — an update prompt must never take a procedure away from someone in the field.
• The operator was removed from the agency, or suspended in it. The app deletes that agency's copy from the phone, including downloaded files. It also does this for any other agency the phone still holds that the person no longer belongs to.
• The agency is paused. Nothing new syncs and the home screen says so; what is saved stays readable.
• The phone was signed out remotely. After Sign out & wipe (on the member's page in People & access, or the person's own Account → Security), the app deletes the data and signs out. The phone's session is cut off at once, and the app also checks for a wipe every time it opens, even when it is no longer signed in, so a revoked session cannot hide one. A phone that never reconnects keeps what it had — no app can reach a device that stays offline.

What this means for authors

• Publishing is not instant on devices. It's instant on the server; a device sees it on its next sync — when the app opens or comes back to the front, or within 15 minutes while it is open. Mark urgent procedures critical and send the notification so phones sync in the background too.
• Saving a published item is not always releasing it. A change made without the Publish permission, or to an item that needs two-person sign-off, is held in the console until someone releases it. Devices keep the released version until then — see how publishing works.
• Unpublishing has the same lag. Withdrawn content disappears on the next sync, not the moment you click. If something is genuinely dangerous, withdraw it and tell people.
• Big media is slow on bad connections. A guide with a lot of video takes longer to become fully offline-ready. Operators can download a whole guide deliberately — see Download a guide for offline use.

What each device gets

A device only ever receives published content from its own agency. That isn't a filter the app applies — the server decides, per request, using the same rules that govern the console. An operator's device cannot hold a draft, and cannot hold another agency's content, even if something went wrong in the app. Of a published item, it gets the released copy — the title, summary, body, short description, images and colour as they were last published or released — never changes still waiting for release.

Each agency also gets its own separate local database on the device, so someone who belongs to two agencies has two isolated caches rather than one mixed pile.