Reference

How events work

The trickiest thing about a real app is that it doesn’t run in a straight line — it waits, and reacts. To read one, you trace the EVENTS over time, not the lines top to bottom. Here’s the model. Open the events lab →

• An app sits and reacts

  Most code you write runs once, top to bottom. A real app is different: it waits, and runs a little handler each time something happens — a tap, a shake, a timer tick.

• A handler runs every time

  `onTap { … }` runs its body once for EACH tap. A counter inside it remembers its value between runs, so it climbs 1, 2, 3.

• Events run in TIME order

  Handlers can be written in any order — they run in the order the EVENTS happen. Reading the timeline, not the code order, tells you what prints first.

• Handlers share state

  Two handlers can change the same counter. A shake can reset what a tap built up, so the next tap starts over. The state carries across all of them.

• A timer fires on its own

  `every(2) { … }` needs no tap — it fires by itself at 2s, 4s, 6s, and reads the counter’s value at the moment it fires.

The handler kinds

• onTapRuns when the screen is tapped.
• onShakeRuns when the device is shaken (a scripted stand-in here — real shake is device-only).
• onTiltRuns when the device is tilted.
• onLoudRuns on a loud sound, like a clap (a scripted stand-in here — real sound is device-only).
• every(n)A timer: runs by itself every n seconds, with no input at all.

The taps, shakes, and claps in the lab are scripted — a stand-in for real sensors, so every program runs the same way on any device (a real shake or microphone works only in the phone app). The point is the READING: predict the log by tracing the events in time order. Read an event program →