Skip to content

Read an anchored short form back in the app - #62

Merged
octopranav merged 1 commit into
mainfrom
android-read-anchor
Sep 23, 2026
Merged

octopranav merged 1 commit into
mainfrom
android-read-anchor

Conversation

@octopranav

Copy link
Copy Markdown
Owner

What

The app now reads the line it shares, -98NM9 near Old Toronto, Ontario, Canada. It can arrive typed or pasted into the search field, or as text selected in another app. A line retyped without its dash or in other capitals reads too.

  1. The name before the first comma is looked up in the website's name index, and the row whose Name, Region matches is kept: as written first, then folded, so Tra Mhor, Munster, Ireland finds Trá Mhór.
  2. That row's code says which archive shard holds the landmark. The shard gives the archive's own coordinates, which are the ones the sender's anchor list was drawn from.
  3. The five characters are recovered against those coordinates. The place arrives labelled Read against a landmark, and the anchor list offers the same landmark first, so passing it on keeps its reference.

Refused, with the reason, and nothing moves

Line Why Message
... near Nowhereville, Ontario, Canada nothing called that cannot be read against it
... near Scarborough several places answer to it give the region
... near Salem, Ontario, Canada the index has it once; the archive has none, because Ontario has several could be read against the wrong one
any line, offline index or archive unreachable needs a connection

A name on its own is accepted only when nothing else in the index shares it (CN Tower).

An anchored line is never recovered against wherever the screen is. A bare short form is, on purpose: the place shown is the reader's own reference. An anchored one names its reference, and recovering it against anything else names somewhere plausible and wrong. Read against London, -98NM9 is #R0NJ0-98NM9, a real place about 2.8 km east of Westminster. PlaceState.opened refuses rather than guessing, and a test fails if that ever changes.

Checks

  • AnchoredTest (14 tests), on live index rows and archive entries:
    • the reader, including lines retyped by hand, and what is not an anchor
    • matching as written, folded, name alone unique or several, and the wrong region
    • the archive's coordinates agreeing with the index row's code, and Salem being absent
    • the transitions: it moves and drops old directions; a bad short form stays put; a refusal stays put
    • never recovering against the screen
    • every line the anchor list writes for the Toronto landmarks reads back to #G3RJM-98NM9
  • Breaking the rules on purpose fails the right tests. Recovering against the screen moved London to #R0NJ0-98NM9, and taking the first of several Scarboroughs picked the English one.
  • On the emulator, against the live files:
    • From a London code, the Toronto Old City Hall line, sent as selected text, went to #G3RJM-98NM9 with Old City Hall chosen in the anchor list.
    • Salem, Scarborough, Nowhereville and airplane mode each showed their message, and the place stayed where it was.

A line such as "-98NM9 near Old Toronto, Ontario, Canada", typed, pasted
or selected in another app, is now read: the place is found by name in the
website's index, then in the landmark archive, and the five characters are
recovered against the archive's own coordinates for it, the ones the
sender's list was drawn from. The anchor list then offers the same
landmark first, so passing the place on keeps its reference.

Anything short of one certain landmark is refused with the reason and the
place stays where it was: nothing called that, a name several places answer
to, a name that is not unique in its own region (Salem, Ontario is in the
index once and not in the archive at all), or no connection. An anchored
line is never recovered against wherever the screen is: -98NM9 read against
London names a real place three kilometres east of Westminster, and a test
fails if that path ever comes back.
@octopranav
octopranav merged commit 14621e5 into main Sep 23, 2026
21 checks passed
@octopranav
octopranav deleted the android-read-anchor branch September 23, 2026 22:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant