aioff.
中文
Product design
PRODUCT DESIGN·7 min

Beam: bring one window from another Mac to your desk

Beam is a tool for using app windows across Macs. It lets people working with two computers bring an editor, terminal or document from the other Mac onto the desktop in front of them and keep interacting with it.

Break down the problem and try your own design and implementation first. Then explore the reasoning to check states, edge cases, trade-offs, and ways to test your approach. The guide offers a reasoning path, not a complete implementation.

01
CODE EXERCISEAdvanced

Merge window events without reviving closed instances

Design an event merger for a teaching example of a remote-window list, not the real Beam protocol. The server gives each window instance an instanceId that is never reused; titles may repeat.

  1. Events have the shape {instanceId, seq, state, title}. For each instance, seq is a strictly increasing positive integer starting at 1. Each event contains complete state: visible, hidden or closed. The network may duplicate or reorder delivery. Events with the same instanceId and seq are guaranteed to have identical data.
  2. closed is the last legal event for that instance; no higher seq will be produced afterward. The receiver must output the latest state for each instance and prevent late old events from reviving a closed instance. Record hidden even when the instance is unknown; visible need not arrive first.
  3. Trace A/2/hidden → A/1/visible → A/3/closed → A/2/hidden → B/1/visible, where A and B have the same title. Explain the list and retained records after each event.
  4. Deliver the state and data structures, reasons for the merge rules, at least three counterexamples, and time and space costs. Assume ID comparison and dictionary access take average constant time. Without a server watermark or acknowledgment mechanism, a timeout alone cannot justify discarding all closed-instance records.
Explore the reasoning
  1. Separate instanceId from title, and use seq to compare events for the same instance. Complete state means missing intermediate events need not block progress; sequence numbers from different instances are not comparable.
  2. Check the supplied trace: A is initially recorded as hidden; late event 1 cannot roll it back. After event 3 closes it, event 2 cannot revive it. B remains a separate visible instance.
  3. Retain the latest sequence number or an equivalent tombstone for a closed instance. Reclamation is safe only with an additional protocol proving that old messages can no longer arrive; this exercise provides no such mechanism.
  4. Also trace empty input, identical duplicates, an unknown instance first received as closed, and multiple same-title windows. Separate average processing cost per event from storage that grows with historical instances; do not claim that memory has an inherent fixed bound.
02
FRONTEND EXERCISEAdvanced

Keep focus and selection stable in a live picker

Design a teaching example of a web window picker. It is a modal dialog whose background cannot be operated. Its list refreshes every second, and entries can disappear or change names. Every item has a stable instanceId and a computer name; duplicate titles are allowed.

  1. Make the items ordinary buttons, support Tab, Shift+Tab and Esc, and give the dialog an accessible name. You need not implement remote video or invent a complex keyboard widget.
  2. While the user focuses A, a refresh removes A and inserts B. Explain changes to focus and selection without silently transferring selection to B. Recheck that the selected instanceId exists before submitting. If it disappears during submission, show failure and allow selection again.
  3. Return focus to the opener when the dialog closes. If the opener no longer exists, define a sensible fallback. Include empty-list, offline and retry states.
  4. Deliver a state diagram, key DOM semantics and keyboard acceptance steps, including a focus–refresh–submit timeline. Explain your choices using the W3C modal dialog pattern, without writing a complete implementation.
Explore the reasoning
  1. Track focus, selected instanceId and request state separately. Focus supports keyboard navigation; selection determines the submitted target. Neither should be confused with a row’s changing list position.
  2. Move focus into the dialog on opening, cycle Tab within it and close on Esc. Provide a clear title and close button. On closing, restore focus to the surviving trigger or a sensible fallback.
  3. If A disappears, clear the invalid selection, provide an accessible message and move focus to an explicit surviving control such as Refresh. B appearing does not mean the user selected B. Revalidate when starting the connection, and keep failures recoverable.
  4. Trace empty lists, repeated refreshes, A disappearing and the opener disappearing before close. Check that focus does not fall onto the background, errors can be perceived and retry does not retain invalid selection.