Working offline
Basements, lift shafts, tunnels, the far end of a slab, a site an hour past the last tower. Teralo is built on the assumption that the place the work happens is often the place with no coverage.
Offline is a native app capability. It is not something a browser tab can do, and the two apps do different amounts of it.
Which apps do what
The mobile app does all of it. Documents kept on the device, inspections filled in, photos taken, observations raised, markups drawn, all queued and sent when the signal comes back.
The desktop app does documents only. A pinned document stays readable with no connection. Creating and editing records offline is a phone capability.
A browser does none of it. Teralo in a browser needs the network, on a laptop and on a phone alike.
Pin a document
In the document register, the row menu carries Available offline. Turning it on downloads that document to the device and keeps it there; the same menu then offers Remove from offline.
A pinned document is marked with a small glyph in the Document Number column, so the register itself tells you what you already have.
Selecting several rows and using Make Available Offline pins them in one go. Do that on the wifi in the site office before you go out, not standing in the basement wondering why nothing opens.
What can be pinned
Not every file type can be read without a connection, and the register is honest about which is which rather than letting you pin something you will not be able to open.
PDFs, images and Excel workbooks pin normally.
Word and PowerPoint files cannot. They are viewed through an online viewer, so there is nothing useful to keep on the device. The option is there but disabled, with a tooltip saying why.
IFC models cannot either, and this one is deliberate. The 3D viewer loads its engine from the internet when you open a model, so a pinned .ifc would download successfully and then fail to open in exactly the situation you pinned it for.
Anything else has no offline option at all.
Large files
Over 100 MB, Teralo asks you to confirm before downloading, because on a phone plan that is a real amount of data.
Over 1 GB it refuses. That is a device memory limit rather than a policy, and it applies to a single file.
A bulk pin auto-confirms the first of those and still refuses the second, file by file.
A pin follows the document, not the revision
This is the design decision most worth understanding.
Pinning means keep this document available, not freeze this exact revision. When somebody uploads a newer revision, your pinned copy becomes superseded rather than staying correct.
When a pin is superseded
Teralo shows that: the glyph on the row turns muted red with a tooltip saying the copy is out of date, and a Sync button appears in the register header with a count of how many pins are stale. Pressing it tells you how much data the update will cost before it starts, then replaces each stale copy with the current revision. A single row can be updated on its own with Update offline copy in its menu.
Staleness can only be worked out online, so the check runs when you have a connection. The practical rule is the same one as pinning: do it before you leave.
The trade-off is that there is no way to deliberately hold on to an old revision offline. See Versions and revisions.
Pins belong to the device
Pinning is per device, not per account. Pinning a drawing on your phone does not pin it on your tablet, and the list does not follow you between them. The files themselves are per device anyway, so there would be nothing to sync but the intention.
When a pin is taken back
If a document is deleted, or your access to it is withdrawn, the device gives its copy up. The check runs when you open the register with a connection, and a removal is announced with a message naming the file rather than happening silently.
Everything about it fails in the direction of keeping your files. A refusal, a network error, a document belonging to some other project: each of those ends in nothing happening. The only thing that deletes a copy is a clear answer naming documents this device actually pinned.
What works on a phone with no signal
Pinned documents open, including their markups, and you can draw new ones.
Inspections. Start one against a cached template, answer items, add custom items, edit notes, delete a custom item you added, take photos against items.
Observations. Raise one, including from a failed inspection item, edit it, attach photos.
Everything above is written to the device immediately and sent when you reconnect. You keep working; you do not wait.
What still needs a connection
Completing or closing an inspection, and re-opening one. Those transitions fire notifications and downstream work, so they wait for a connection and the buttons say so.
Creating inspection plans. Plans are made at a desk; the field runs them.
Anything not listed above. Mail, contracts, procurement, claims, permits, meetings and the rest are online tools. The app will tell you it cannot rather than pretending.
The sync queue
A strip appears when you are offline, and a banner counts what is waiting once you are back. Tapping either opens the queue.
The queue lists every change waiting to go up, grouped by the tool it belongs to, each with what it is, when you made it, and a status:
- Queued. Waiting its turn.
- Syncing. On its way now.
- Waiting. Held behind something else that has to land first. A photo cannot be attached to an observation that has not been created yet, so Teralo chains them and sends them in order.
- Retrying, N of 8. It failed for a reason that might be temporary and will be tried again.
Sync now forces a pass. You should rarely need it: Teralo syncs by itself when the connection returns, when you bring the app back to the foreground, and on a timer while it is open.
When a change has failed to sync
A change that fails permanently, or that has been retried eight times, stops being retried and moves to a Failed section in the queue with the reason on it. Waits between retries lengthen from one second up to a minute, so eight attempts covers a good deal more than a brief dropout.
Once you are back online with nothing left queued, a banner appears saying how many changes failed and offering to show you. Do look. That banner is the only thing standing between a failed change and quietly losing it.
Retry or discard a failed change
Each failed row has two buttons. Retry puts it back in the queue with a clean slate. Discard throws it away, after a confirmation warning that anything chained behind it goes too, which is what stops a discarded observation leaving orphaned photos.
Anything that failed because its parent failed is revived or discarded along with the parent, so you deal with the cause rather than with a list of consequences.
Two people changing the same thing: the last write wins
The last change to arrive wins. If you edit an inspection note offline and somebody edits the same note in the office while you are out, whichever reaches the server later is what the record ends up saying.
Teralo does not currently detect that this has happened, or ask you to choose. There is a conflicts screen in Settings and it says so plainly in its empty state. It is worth knowing before you plan a week of offline work on records other people are also editing.
Signing out clears it
Signing out removes the offline database, the queued changes and the cached files from the device. Anything still waiting in the queue goes with it.
So before you sign out on a shared site phone, open the queue and check it is empty.
Photos held on the device while they wait to upload are encrypted, and so is the offline database itself, which is what makes a lost phone a lost phone rather than a disclosure.