How should a smart-glasses app manage requests and screen state?
Give each request a stable identifier and an explicit state such as pending, completed, failed or cancelled. When a response arrives, check that it still belongs to the active task before updating the display. A late result should not overwrite a newer task simply because it arrived last.
Arrival order is not user intent
Network delays can reverse the order of responses. The wearer may also dismiss a request or switch tasks while processing continues elsewhere. The application needs to remember those actions, reject stale results and keep approval inputs attached to the proposal originally shown.
Suppose a wearer asks question A, cancels it and asks question B. If A finishes later, its response should not replace B's screen. Exercise that sequence deliberately, because it often works perfectly in a fast demonstration and fails only when the network slows down.
Walk through a delayed response
This hypothetical sequence exercises cancellation without depending on a particular SDK.
- Send request A and show it as pending.
- Cancel A, then send request B with a different identifier.
- Deliver A’s result after B has become active.
- Confirm that A does not replace B or receive an input intended for B.
- Deliver B’s result and verify that the current display and host record agree.