Skip to content

Phones: instant open for bots, the uberbot, rooms and threads; the person's taps ahead of streaming - #79

Merged
i2cjak merged 7 commits into
mainfrom
backplane/ios-snappy-phone-cache
Oct 13, 2026
Merged

i2cjak merged 7 commits into
mainfrom
backplane/ios-snappy-phone-cache

Conversation

@i2cjak

@i2cjak i2cjak commented Oct 13, 2026

Copy link
Copy Markdown
Collaborator

Tapping Bub (the uberbot) took about a second while it streamed: the page moved only once Bend answered, the engine thread was one FIFO queue saturated by streaming frames (~100 ms each), and a tap's own screen was dropped whenever frames waited behind it.

What changes (iOS and Android, same behaviour)

  • Every tappable row carries nav: the selection its page will have (bots, uberbot card, rooms, remote bots, Status-plane rows; MBots.nav*, Hubs.nav*, Plane rows; laws in # ios-snappy: nav, test/mnav_test.bend with one and two hubs).
  • A tap opens the page at once: the last screen of that page (24 kept per kind) or a skeleton with its title and cat, inert until live; double taps are ignored (350 ms). A late screen of an older selection no longer re-pushes a page just left (awaitedNav; expires after 3 s so notifications still move the stack). Thread rows on Android now open at once too.
  • Person lane: taps, typing and screen requests run ahead of queued hub frames, and a person's screen is never dropped because hub frames wait behind it.
  • Streaming throttle: a streaming frame builds at most one screen per 250 ms, with an owed screen flushed by a timer (Backplane.flush), so the last state shows within 250 ms. A burst (cold join, catching up) still builds one a second, as before.
  • Debug: tap timing (Backplane tap <nav> first N ms full N ms), ACTS @open=<name> and @times.

Measured in an iOS 26.5 simulator with JSC_useJIT=0, on a sandbox hub with a copy of the real log (push registrations and hooks stripped), with Bub streaming (stand-in agent):

tap → Bub's page main this PR
first content = full 0 ms
full content, 6 taps after sync 748–1161 ms (median ~1.1 s) 94–217 ms
full content, first open during the initial sync 6247 ms 328 ms
engine steps over 100 ms in the run 102 12

Checks: scripts/check.sh (with PROOF), mnav, mbots, hubs, mplane, plane, onboard tests, the engine/flush harnesses, build-mobile.sh (bridge + release APK), and the Mac Debug build all pass. Synthesis of two independent implementations (Codex GPT-6.1-Sol as base; notes in bp-coord/ios-snappy/synthesis-1.md).

🤖 Generated with Claude Code

i2cjak and others added 7 commits October 13, 2026 15:51
…ts page gives up after 3 s; rows without nav open as before

Synthesis of ios-snappy inc 1 (B as base):
- a background frame with more queued behind it stays quiet until a second
  since the last screen (as before the 250 ms window), so a cold join or a
  catch-up builds no more screens than it did
- iOS decodes an answer's screen only when it is drawn
- iOS awaitedNav / Android opening expire after 3 s: a page that never
  comes no longer holds the stack (iOS) or every action (Android)
- iOS open() with no nav (an older bridge's row) acts as before (from A)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@i2cjak
i2cjak merged commit 7bb923e into main Oct 13, 2026
9 checks passed
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