Logging a Place With No Signal: What Gets Saved and What Waits

The places most worth writing down are often the ones with no signal: a monastery at the end of a valley road, a ferry between two islands, a market hall with walls a metre thick. You open the app, an amber strip across the top says "Offline", and you type the name anyway. What happens to it next is worth knowing before you rely on it.

This is a plain account of what MapMyWorld keeps when there is no connection, what it quietly leaves out, and what happens in the minute after your phone finds a network again.

"Works offline" is three separate promises

When an app says it works offline it can mean any of three things, and they are not equally hard to deliver.

1. It opens. The screens load without a network.
2. You can read. What you logged before is still there to look at.
3. You can write. Something new you type survives until the connection returns, and then arrives exactly once.

Most apps manage the first, a fair number manage the second, and the third is where the trouble lives. MapMyWorld does all three for one kind of entry, a place, and only that one. Each promise has an edge, so take them in turn.

Opening: the app itself is stored on your device

MapMyWorld is an installable web app. The first time you load it, a service worker saves the application files to your device: the scripts, the styles, the page, and the file of country outlines the map draws from. That list is set in vite.config.ts. From then on the app starts with no network at all, and the country outlines still draw.

The street-level map underneath is a different matter. Map tiles are saved only after you have looked at them, up to 500 tiles, for up to 30 days. There is no "download this region" button. If you scrolled around Lisbon on hotel wifi last night, Lisbon will draw on the metro today. A town you have never opened will be a blank grid until you reconnect.

Reading: about a day of what you last looked at

Your places, trips and statistics come from the server. Each time the app fetches them it keeps a copy, and when a request gets no answer within five seconds it falls back to that copy. The limits are deliberately tight: at most 100 saved responses, none older than 24 hours.

So the rule is simple. What you opened on this device in the last day is readable offline; what you did not open is not. A trip page you have never visited on this phone will not appear on a mountain. Thirty seconds on wifi before you leave, opening your trip and your places list, is what makes them available later.

One more edge. That saved copy is wiped whenever anyone logs in or out (client/src/lib/pwa-cache.ts), so that a second person using the same device is never shown the first person's record. The cost is that logging out while offline leaves you with nothing to read.

Writing: a place goes into a queue on your phone

Add a place with no connection and the form changes. Search is switched off, because search needs the network, and the form asks you to type a name instead. Press save and you get a message, "Saved for sync", and the place joins a small queue held in the browser's own database on your device (client/src/lib/pending-places.ts). Your places list shows a panel headed with the number of places pending sync.

Here is exactly what goes into that queue:

• the name you typed
• the status: visited, lived, or bucket list
• your notes
• coordinates, if you entered any
• the trip, if you attached one

And here is what does not, even if you filled it in on the same form:

• the visit date
• the star rating
• a photo of your own
• an expense

The form tells you about the last one. If you entered an amount, the message says to add the expense from the trip afterwards. It says nothing about the date or the rating, and it should. The practical fix is one habit: when you are offline, put the date and what you paid into the notes. Notes survive. "14 Sept, lunch 4,200 forint cash" in the notes field turns into a correct date and a correct expense in a minute once you are back on wifi. Leave it out and you are reconstructing from memory, which is the thing a record exists to prevent.

Expenses on their own do not queue at all. Neither do new trips, edits to existing places, or marking a country. Offline writing covers adding a place, and nothing else.

Reconnecting: how the queue empties

The queue drains when the browser reports a connection, when you next open the app, or when you press "Sync now" on the pending panel (client/src/lib/pending-sync.ts). Drafts go one at a time, oldest first.

For each one, the server takes the name you typed and looks it up with Google. It asks for a single best match, and if you supplied coordinates it looks within 50 kilometres of them. From that match it fills in the proper name, coordinates, city, country, a map link and a photo, then creates the place (server/routes/places.ts).

Two consequences follow, and both are about the name.

The name has to be findable. "Lunch place" or "the viewpoint" will find nothing, and a draft with no match is refused. It stays in the pending panel with the error shown beneath it. After five failed attempts it stops retrying, and the only move left is to discard it and add the place again while online.

The name has to be specific. The server takes the top result. "Central Market" with no town and no coordinates may come back as a Central Market in another country. "Central Market Hall, Budapest" will not. Type the name you would say to a taxi driver, plus the town.

The failure that matters: twice, or not at all

Bad connections fail in an awkward way. Your phone sends the draft, the server creates the place, and the reply is lost on the way back. From the phone's side that looks like a failure, so it tries again. A careless design now gives you the same café twice. A timid one gives up and you have it zero times.

MapMyWorld handles this on the server. Before creating anything, it checks whether you already have a place with that Google identity, and if you do, it hands back the existing one instead of making another. The phone treats "already exists" as success and removes the draft. Engineers call this idempotent: sending the same request five times leaves the same result as sending it once. For you it means a retry is always safe, and pressing "Sync now" repeatedly on a train does no harm.

A refusal for sending too fast is handled separately. The queue simply stops and picks up later, without counting it against the five attempts.

How the app decides you are offline

Browsers offer a built-in online flag, and it is weak. MDN's documentation is blunt about it: a device joined to a local network counts as online even when that network has no route to the internet, and the property is described as "inherently unreliable". Anyone who has joined hotel wifi and met a login page knows the case.

So the amber strip does not rely on the flag alone. The app also asks its own server a small question once a minute and shows "Offline" after two unanswered attempts in a row (client/src/hooks/use-online-status.ts). In practice "Offline" means "cannot reach MapMyWorld", which is the fact you care about.

The price is a short lag. On a connection that is technically up but going nowhere, the strip can take a minute or two to appear, and a save attempted in that gap can fail outright instead of queueing. If a save errors and the strip then appears, save again.

Where the queue lives, and how it can be lost

The queue is on your device, in that browser. It is not on our servers, and it will not appear on your laptop. Until it syncs, that phone holds the only copy.

Three things can remove it:

• Clearing site data or browsing data deletes it along with everything else the browser stored.
• Browser housekeeping. MDN describes ordinary website storage as best-effort: it lasts while the device has room and you have not cleared it. A site can ask for persistent storage instead. MapMyWorld does not currently ask.
• Safari's seven-day rule. Since 2020, Safari with its cross-site privacy protection switched on deletes script-written storage for a site you have not interacted with in seven days of browser use. WebKit's own announcement notes that a web app added to the home screen has its own counter, and that it does not expect such an app to lose its data.

The conclusion is modest. Install the app to your home screen, and sync within days, not weeks. A queue is a waiting room. It is not a backup, and we wrote separately about how to back up a travel record properly.

Your plan's limits apply when the draft syncs

The queue does not check your plan. The server does, at sync time. On the Free plan the allowance is 5 places, counted over the lifetime of the account, so deleting one does not free a slot. If you queue a sixth place offline, the app will accept it into the queue and the server will refuse it on sync, where it sits in the pending panel with an error. Pro has no place limit. If you are on Free and near the allowance, the queue is the wrong place to discover it.

A routine for a day with no signal

Before you leave wifi. Open the app. Open your trip and your places list so both are readable later. If the app is not on your home screen, add it.

During the day. Add each place by its real name and town. Put the date, the amount, the currency and whether it was card or cash into the notes.

Back on wifi. Open the app and watch the pending panel empty. Then go through the new places once: set the visit date, add the rating, attach a photo if you want one, and enter the expenses from your notes. Discard and re-add anything that failed to match.

This slots into the daily pass described in how to log a trip while you are still on it. The spending half is covered in how to stop guessing what your trips cost.

What this will not do

• No offline maps. You see tiles you have already viewed, not a region you chose to download.
• No offline search. You cannot look a place up without a network; you can only name it.
• No offline expenses, trips or edits. Only new places queue.
• No syncing while the app is closed. The queue drains when the app is open and connected. Nothing happens in your pocket.
• No date, rating or photo from an offline save. Those are added afterwards.

That is a narrower offline mode than a native app with a full local database would give you. It does one thing: it makes sure the name of the place you are standing in is not lost between the valley and the hotel. For a record meant to last decades, that is the part that cannot be recovered later. The date can be worked out from a photo, and a card payment from a statement. A name you never wrote down is gone.