What is an event in programming?

Something that happens — a click, key press, message, or timer tick — that a program can respond to

An error that crashes the program

What is an event handler?

The code that runs when a particular event occurs

How does an event-driven program spend most of its time?

Running instructions as fast as possible from top to bottom

In a drawing app, "when mouse is dragged → draw a line" is an example of...

an event (mouse drag) attached to a handler (draw a line)

What is the event loop?

The hidden cycle that waits for events and dispatches each one to its handler

A loop that never contains events

A rollercoaster for programmers

Why should an event handler finish its work quickly?

While a handler runs, the program cannot respond to new events — long handlers make apps freeze

Handlers are charged by the second

Select ALL examples of event-driven behaviour.

A game character jumps when the space bar is pressed

A phone alarm rings when its timer fires

A chat app shows a message when one arrives from the network

A script calculates 100 sums and exits

Events

⏱ 8 min✏️ Quiz at the end

Programs That Wait

The algorithms you have written so far run like recipes: start at step one, proceed in sequence, finish, stop. But think about the apps you actually use. A drawing app does nothing until you drag. A game waits for the space bar. A chat app sits idle until a message lands. These programs are not recipes — they are receptionists: sitting quietly, ready to spring into action when something happens.

That something is an event: a click, a tap, a key press, a timer firing, a message arriving from the network. Programs built around responding to events are called event-driven — and almost every program with a screen and a user is one.

Events and Handlers

Event-driven programming has two halves:

The event — the happening. button clicked, key pressed, timer finished, message received.
The event handler — the code that runs in response, usually a function you attach to the event.

The design reads as when–do pairs:

WHEN green-flag clicked  → startGame()
WHEN space-bar pressed   → jump()
WHEN timer reaches 0     → showGameOver()
WHEN message received    → displayMessage()

If you have used Scratch, you know those yellow "when" blocks — that is event-driven programming, undiluted. Designing an app becomes a listening exercise: list what can happen, and decide what to do about each one. Inside each handler, everything you already know applies: sequences, conditions, loops, variables.

The Event Loop

Who is watching for the events? Under every event-driven program runs a hidden engine, the event loop:

WHILE program is running
    wait for the next event
    find the handler attached to it
    run that handler
ENDWHILE

That's all. Your handlers are the personality; the loop is the heartbeat. When you tap an icon, the operating system collects the touch from the input hardware, packages it as an event, and delivers it to the right app's queue — where the loop picks it up and runs your handler. Events even queue up politely if they arrive faster than they can be handled, which is why frantic clicking eventually registers every click.

The Golden Rule: Handle Fast

One consequence bites every app developer eventually. While a handler runs, the event loop is busy — no other event gets processed. Write a handler that grinds for five seconds and for five seconds the app is deaf: clicks dead, screen frozen. You have felt this — the greyed-out window, the spinning cursor. That is somebody's slow event handler.

Hence the golden rule: handlers finish fast. Long jobs (big downloads, huge calculations) get sent elsewhere — to a background task — so the loop can keep listening. You will meet this exact idea again wherever responsiveness matters: servers answering thousands of requests are event loops at heart, fielding request arrived events all day.

Two Shapes of Program

It is worth seeing the contrast plainly:

Recipe-style (batch)	Event-driven
Runs top to bottom, then exits	Waits; runs handlers as events fire
Order fixed by the programmer	Order chosen by the user and the world
e.g. a script that processes a file	e.g. games, apps, websites

Neither is "better" — a sorting script has no business waiting for clicks. But interactive software is event-driven by nature, because users decide what happens next, and the program's job is to be ready for anything.

Try It Yourself

Design (on paper, as when–do pairs) the events for a simple whack-a-mole game: mole pops up on a timer, player taps it for points, game ends at 30 seconds. You will need at least three events, a variable for the score, and a condition somewhere. Which handler must be fastest, and why?

Worked Example — Designing a Simple Quiz Game's Events

Take a small quiz app and list its events properly, the way a real designer would before writing any code:

WHEN "Start" button clicked   → loadFirstQuestion()
WHEN an answer button clicked → checkAnswer(chosenAnswer)
WHEN checkAnswer confirms correct  → score ← score + 1, showNextQuestion()
WHEN checkAnswer confirms wrong    → showCorrectAnswerHighlighted()
WHEN timer for current question reaches 0  → treatAsWrong(), showNextQuestion()
WHEN final question answered  → showFinalScore()

Notice how this list surfaces design questions that a plain top-to-bottom algorithm would hide: what happens if the timer runs out and the player taps an answer in the same instant? What happens if "Start" is clicked twice by an impatient tapper? Listing events explicitly, before writing a single line of code, is exactly how real interface designers catch these edge cases early — the event-driven equivalent of tracing an algorithm before trusting it.

Multiple Handlers for the Same Event

Sometimes more than one thing should happen in response to a single event. A "player scores a point" moment in a game might need to: update the score variable, play a sound effect, and check whether that score triggers a "new high score!" message. Rather than cramming all three into one giant handler, well-designed event systems can attach several handlers to the same event, each with one clear job — updating the score, playing the sound, checking the high score — echoing the same decomposition principle used everywhere else in this course: many small, focused pieces are easier to build, test, and change independently than one handler trying to do everything at once.

Key Words

Event — a happening a program can respond to: click, key, timer, message
Event handler — the code attached to an event, run when it fires
Event-driven — a program structured around waiting for and responding to events
Event loop — the hidden cycle that waits, dispatches, and repeats
Responsiveness — keeping handlers quick so the app never goes deaf