It Does Not Ask — Why Polling Is Worse Than Wasteful

Through part 4, knowing the latest value meant asking — every second, or when a person refreshed.

Subscribe

client.onResourceUpdated((uri) {
  // The notification says only that it changed. Read to learn what to.
  seen.add(uri);
  stdout.writeln('notified: $uri');
});

await client.subscribeResource('desk://waiting');

Then make the value change.

await client.callTool('desk.admit', {'count': 1});

subscribed to desk://waiting
notified: desk://waiting
after the notification, reading gives {waiting: 2}
notifications received: 1

The notification carries only the uri

The handler receives one uri. How many are waiting does not arrive. Server part 6 covered why no value rides along; on the receiving side it means you have to read.

final now = await client.readResource('desk://waiting');

One more round trip looks like a loss, and it is always right. However many notifications arrive and in whatever order, the value at the moment you read is the current one.

The real problem with polling

Polling is usually rejected on cost. Knocking on the server every second is wasteful.

That is secondary. The real problem is that you cannot see between two polls.

09:00:00    poll → waiting 3
09:00:00.4  two admitted → waiting 1
09:00:00.7  one arrives  → waiting 2
09:00:01    poll → waiting 2

The screen went from 3 to 2. It never saw the moment it was 1. If only the final value matters, fine — but a rule like "alert when it reaches zero" will never fire.

Shortening the interval does not remove this. It narrows it. And the narrower it gets, the more the waste grows.

Unsubscribe when done

await client.unsubscribeResource('desk://waiting');

When the screen closes, drop the subscription. Leave it and the server keeps sending to nobody.

The ESP32 in the real-board piece put this inside the screen definition — subscribe on onReady, release on onDestroy. With the lifecycle written into the screen, the client cannot forget.