Lecture overview:

• Total time: ~55 minutes
• Prerequisites: L6/L7 (Information hiding, design for change), L28 (Accessibility)
• Connects to: GA1 (Core Features), L30 (MVVM and TestFX)

Structure (~23 slides):

• Arc 1: From CLI to GUI (~10 min) — event-driven programming, event loop, Java GUI history
• Arc 2: MVC (~15 min) — separation of concerns applied to UIs, Model/View/Controller with code
• Arc 3: Building It (~15 min) — JavaFX components, layout, live coding, properties, CSS
• Arc 4: Accessibility from the Start (~8 min) — accessible text, keyboard nav, focus management
• Arc 5: What's Next (~5 min) — MVVM preview, GA1 architecture, takeaways

Running example: SceneItAll device dashboard — the IoT/smarthome control app from L2, L13, and Lab 11. We build a panel that shows devices in a room and lets you control them. By slide 14, students have a complete working app.

Transition: Let's start with the learning objectives...

CS 3100: Program Design and Implementation II

Lecture 29: GUIs in Java

©2026 Jonathan Bell, CC-BY-SA

Context from previous lectures:

• L6/L7: Information hiding, coupling, cohesion — we'll apply these to UI architecture
• L28: Accessibility — standard components, keyboard navigation, POUR framework
• L2/L13: SceneItAll domain — students already know lights, fans, shades, areas, scenes
• Today: we build our first GUI, using the principles we've learned all semester

Transition: Here's what you'll be able to do after today...

Learning Objectives

After this lecture, you will be able to:

1. Explain the difference between sequential and event-driven programming
2. Apply the Model-View-Controller pattern to separate UI from business logic
3. Build a simple JavaFX interface using FXML, controllers, and standard components
4. Use JavaFX properties and binding to keep the View synchronized with the Model
5. Apply accessibility practices (accessible text, keyboard navigation, focus management) in JavaFX

Time allocation:

• Objective 1: Event-driven programming (~10 min)
• Objective 2: MVC (~15 min)
• Objectives 3-4: JavaFX components, layout, properties, CSS (~15 min)
• Objective 5: Accessibility in JavaFX (~8 min)

Connection to GA1: Students will implement one of four core CookYourBooks features using these exact patterns. We use SceneItAll today so they arrive at GA1 with fresh eyes for their own project.

Transition: Let's start with a fundamental shift in how your code runs...

Your Code Has Been Telling Users What to Do — Now They Tell You

Sequential (CLI) — you're in control

System.out.println("Enter room name:");
String room = scanner.nextLine(); // blocks here
System.out.println("Enter brightness (0-100):");
int brightness = scanner.nextInt(); // blocks here
light.setBrightness(brightness);
System.out.println("Set to " + brightness + "%");

Your code decides the order. The user waits for you.

Event-driven (GUI) — the user is in control

brightnessSlider.setOnMouseReleased(e -> {
    // runs when user releases the slider
});
sceneButton.setOnAction(e -> {
    // runs when user clicks "Activate Scene"
});
// code continues immediately
// doesn't wait for any interaction

The user decides the order. Your code waits for them.

This is called inversion of control. You don't call the framework — the framework calls you.

This is the single biggest mental model shift in the lecture. Students have written sequential code for their entire programming education. Now the user — not their code — decides what happens next.

Analogy: CLI is like a phone tree ("Press 1 for lights, press 2 for shades"). GUI is like a smart home dashboard — the user can tap any device, in any order, at any time.

Connection to prior concepts: Students have already used callbacks — in list.forEach(item -> ...), in list.sort((a, b) -> ...), in JUnit's @Test methods. GUI callbacks are the same pattern, just with user events instead of list elements.

Transition: How does the framework know when to call your code?

The Event Loop: Your Code Is a Guest in Someone Else's House

Every GUI framework has an event loop at its core:

// Pseudocode - what the framework does
while (applicationIsRunning) {
    Event event = waitForNextEvent();     // block until click, keypress, timer...
    EventHandler handler = findHandler(event); // look up your registered callback
    handler.handle(event);                // call YOUR code
}

What this means for you:

• Your code runs inside the framework's loop — you are a guest
• If your handler takes too long, the entire UI freezes (no events can be processed)
• In JavaFX, this loop runs on the JavaFX Application Thread — all UI updates must happen here

"Your code is a guest" is the key metaphor. Students need to understand that they don't own the main() function anymore. The framework does.

Freezing demo idea: If you have time, show a button handler with Thread.sleep(5000) — the entire UI becomes unresponsive for 5 seconds. This viscerally demonstrates why long-running handlers are a problem. (We'll solve this properly in L31-32 with concurrency.)

SceneItAll connection: "Imagine a user dims the living room lights and then immediately tries to close the shades. If your light-dimming handler takes 5 seconds to talk to the physical device, the shade button is frozen. The user thinks the app crashed."

Transition: Java has gone through three generations of GUI toolkits. Let's see the evolution...

Java's Three GUI Toolkits Tell the Story of UI Evolution

	AWT (1995)	Swing (1997)	JavaFX (2008/2014)
Approach	Wraps native OS widgets	Draws its own widgets in Java	Scene graph + CSS + FXML
Consistency	Looks different on each OS	Identical everywhere	Styleable, consistent
Code	Button b = new Button("Go");	JButton b = new JButton("Go");	Button b = new Button("Go");
Strength	Native look and feel	Cross-platform consistency	Modern architecture
Weakness	Lowest common denominator	Looks dated, no CSS/FXML	Unbundled from JDK since Java 11

We'll use JavaFX because its architecture — scene graphs, declarative UI, CSS styling, property binding — reflects patterns used in modern frameworks (React, SwiftUI, Flutter).

Don't dwell here — this is context, not content. 2-3 minutes max. The point is: JavaFX isn't arbitrary. Its patterns transfer to whatever UI framework students use next.

AWT's problem: A button was 80px on Windows, 95px on Mac. Layouts broke across platforms. Only features available on all platforms could be used.

Swing's legacy: Still widely used in IDEs (IntelliJ is partly Swing), enterprise tools, and legacy apps. Students may encounter it in industry.

JavaFX's status: Unbundled from the JDK in Java 11 into OpenJFX. Still actively developed by the community. For learning GUI concepts, it's excellent.

Transition: Now let's talk about how to organize GUI code so it doesn't become an unmaintainable mess...

The JavaFX API: Stage, Scene, and Scene Graph

Before we organize our code, let's understand what the GUI toolkit gives us:

• Stage = the application window (title bar, minimize/maximize/close)
• Scene = the content inside the window
• Scene Graph = a tree of nodes — every widget, every layout container, every label is a node in this tree
• Rendering = the framework walks the tree and draws each node. You build the tree; the framework draws it.

The scene graph is the key concept. Students need to understand that a GUI is a tree of objects — not a canvas you paint on. Every button, every label, every container is an object with properties, methods, and events. The framework traverses this tree to render the UI, handle focus order, and dispatch events.

Analogy: HTML is also a tree (the DOM). If students have web experience, this will click immediately. FXML is to JavaFX what HTML is to the browser — a declarative way to define the tree.

Stage vs. Scene: A Stage can swap its Scene (like a browser tab loading a different page). For GA1, students will typically have one Stage and one Scene.

Transition: Let's see this in code...

Your First JavaFX Application

Note: Code examples in these slides omit import statements and some boilerplate for clarity. See the lecture notes for complete, runnable versions.

public class SceneItAllApp extends Application {

    @Override
    public void start(Stage stage) {
        // Build the scene graph — a tree of nodes
        Label title = new Label("Living Room");
        title.setStyle("-fx-font-size: 20px; -fx-font-weight: bold;");

        Slider brightness = new Slider(0, 100, 70);
        Button activate = new Button("Activate Scene");
        activate.setOnAction(e -> System.out.println("Scene activated!"));

        ListView<String> devices = new ListView<>();
        devices.getItems().addAll("Ceiling Light: 70%", "Shades: Open", "Fan: Speed 2");

        VBox root = new VBox(10, title, brightness, devices, activate);

        // Wrap the tree in a Scene, put the Scene in a Stage
        Scene scene = new Scene(root, 400, 300);
        stage.setTitle("SceneItAll");
        stage.setScene(scene);
        stage.show();
    }

    public static void main(String[] args) { launch(args); }
}

This works — but all the UI construction, event handling, and data are in one method. That won't scale.

This is the "everything in one place" starting point. Students see a complete, runnable JavaFX app in 20 lines. The start() method builds the tree, wires an event, and shows the window.

Key API concepts to point out:

• Application is the base class — JavaFX calls start() for you (inversion of control!)
• Stage is the window, Scene is the content, VBox is a layout container
• new Button("Activate Scene") creates a node; setOnAction() registers a callback
• VBox(10, title, brightness, devices, activate) — 10px spacing, children in order

The problem: Everything is in start(). UI construction, event handling, styling, data. As the app grows, this method grows. We need to separate concerns.

Don't skip this slide. Students need to see the raw API before FXML abstracts it away. FXML is just a different way to build the same tree — XML instead of Java constructor calls.

Transition: This works for 20 lines. But real apps have thousands of nodes and dozens of event handlers. We need a way to organize this code...

FXML: Building the Same Tree Declaratively

Java (imperative)

Label title = new Label("Living Room");
title.setStyle("-fx-font-size: 20px;");

Slider brightness = new Slider(0, 100, 70);

ListView<String> devices = new ListView<>();

Button activate = new Button("Activate");
activate.setOnAction(e -> { ... });

VBox root = new VBox(10,
    title, brightness, devices, activate);

Build the tree with constructor calls. Mix structure with behavior.

FXML (declarative)

<VBox spacing="10">
    <Label text="Living Room"
           style="-fx-font-size: 20px;"/>

    <Slider min="0" max="100" value="70"/>

    <ListView fx:id="deviceList"/>

    <Button text="Activate"
            onAction="#handleActivate"/>
</VBox>

Declare what exists. Behavior lives elsewhere (Controller).

Same scene graph tree. Different way to define it. FXML separates structure (what exists) from behavior (what happens).

The key insight: Both approaches build the exact same tree of objects. FXML is not a different technology — it's a different notation for the same thing. The JavaFX runtime reads the FXML and calls the same constructors and setters you'd call in Java.

Why FXML wins for larger apps:

1. Structure is easier to read as XML than as nested constructor calls
2. Behavior is separated into a Controller class
3. Visual tools (Scene Builder) can generate and edit FXML
4. Designers can work on FXML while developers work on Controllers

fx:id and onAction: These are the bridge between FXML and Java. fx:id="deviceList" means "make this node available to the Controller as a field." onAction="#handleActivate" means "when this button is clicked, call the Controller's handleActivate() method."

Transition: Now that we know what the API gives us, let's talk about how to organize our code around it...

MVC Is Hexagonal Architecture for User Interfaces

In L16 we learned to separate domain logic from infrastructure so code is testable. MVC applies that principle to GUIs:

The Model is cleanly domain-side — no UI imports, fully testable. But the Controller does everything else: it reads from the Model, makes decisions, AND manually pushes updates to View widgets. It straddles the hexagonal boundary. We'll fix this in L30.

Model

Data + business logic. Knows nothing about the UI.

View

What the user sees. Widgets, layout, styling. No business logic.

Controller

Translates user actions into model updates. The thin middleman.

Frame through hexagonal architecture: "In L16 we drew a hexagon with domain code in the middle and infrastructure on the outside. MVC is that same picture for GUIs. The Model is your domain core — pure business logic, no UI imports. The View is infrastructure — JavaFX widgets, FXML, rendering."

But flag the leak: "The Controller is supposed to be the port between them. But look at what it imports — @FXML widgets, JavaFX types. It straddles the boundary. It has domain-level decisions (what to do when the user clicks) mixed with infrastructure dependencies (which widget to update). That's a leaky hexagonal boundary. MVC gets you 80% of the way; in L30 we'll fix the last 20%."

SceneItAll example: The Model knows about lights, fans, and scenes. The View knows about sliders, buttons, and labels. The Model doesn't know sliders exist. The View doesn't know how dimming works. The Controller translates "slider moved to 75" into "set brightness to 75%."

Why this matters for testing: "In L16 we said: domain code is easy to test, infrastructure code is hard to test. The Model is domain code — you can unit test light.setBrightness(150) without any UI. That's the payoff of separation. The Controller? Not so easy — and we'll see why at the end of this lecture."

Transition: Let's see what happens when you don't separate these concerns...

What Goes Wrong Without MVC

This is what code looks like when UI and business logic are tangled together:

// Everything in one place — the "Big Ball of Mud"
dimButton.setOnAction(event -> {
    int brightness = Integer.parseInt(brightnessField.getText());
    // Business logic mixed into the click handler
    if (brightness < 0 || brightness > 100) brightness = 50;
    for (int i = 0; i < deviceList.getItems().size(); i++) {
        String device = deviceList.getItems().get(i);
        if (device.contains("Light")) {
            deviceList.getItems().set(i, device.split(":")[0] + ": " + brightness + "%");
        }
    }
    // Network call in the UI handler
    zigbeeController.sendCommand(deviceId, "brightness", brightness);
    // Logging in the UI handler
    auditLog.record("Brightness set to " + brightness + " by " + currentUser);
});

How do you unit test the brightness validation logic? You can't — it's trapped inside a button click handler.

Ask students to identify the problems:

• What happens when you want to control brightness from a voice command? Rewrite everything.
• What happens when you change from a list to a grid layout? Business logic breaks.
• How do you test the brightness clamping? You can't — you'd need to simulate a button click.
• How many reasons does this method have to change? At least four (UI, brightness logic, networking, logging).

Connection to L7: This is high coupling and low cohesion in action. The click handler has logical cohesion at best — things that happen at the same time but for different reasons.

Transition: Let's fix this by separating the Model...

The Model: Business Logic with No UI Dependencies

// Model: Light.java — pure business logic, fully testable
public class Light extends SmartDevice {
    private int brightness;  // 0-100
    private boolean isOn;

    public void setBrightness(int level) {
        this.brightness = Math.clamp(level, 0, 100);
        this.isOn = (brightness > 0);
    }

    public void toggle() {
        this.isOn = !this.isOn;
    }

    public int getBrightness() { return brightness; }
    public boolean isOn() { return isOn; }
    public String getStatus() {
        return isOn ? getName() + ": " + brightness + "%" : getName() + ": Off";
    }
}

// You can test this right now — no GUI required
@Test
void brightnessClampedToValidRange() {
    Light light = new Light("Desk Lamp");
    light.setBrightness(150);
    assertEquals(100, light.getBrightness());
}

@Test
void settingBrightnessToZeroTurnsOff() {
    Light light = new Light("Desk Lamp");
    light.setBrightness(0);
    assertFalse(light.isOn());
}

Key point: The Model has zero imports from javafx.*. It's a plain Java class. You can test it in isolation, use it from a CLI, expose it via a REST API — the Model doesn't care how it's displayed.

Connection to course arc: Students have been writing domain model classes all semester (HW1-HW5). Those classes are Models in MVC. They've been building the M without knowing it.

Transition: Now let's define what the user sees...

The View: What the User Sees (FXML)

JavaFX separates UI structure into FXML — an XML file that declares what widgets exist and how they're arranged:

<!-- View: area-dashboard.fxml -->
<?xml version="1.0" encoding="UTF-8"?>
<?import javafx.scene.control.*?>
<?import javafx.scene.layout.*?>

<VBox spacing="10" xmlns:fx="http://javafx.com/fxml"
      fx:controller="sceneitall.AreaDashboardController">

    <Label fx:id="areaNameLabel" style="-fx-font-size: 18px;"/>

    <HBox spacing="5" alignment="CENTER_LEFT">
        <Label text="Brightness:"/>
        <Slider fx:id="brightnessSlider" min="0" max="100"/>
        <Label fx:id="brightnessValueLabel" text="50%"/>
    </HBox>

    <ListView fx:id="deviceList"/>

    <Button fx:id="sceneButton" text="Activate Scene"
            onAction="#handleActivateScene"/>
</VBox>

No business logic here. The View defines what appears — not what it means.

Key FXML concepts to point out:

• fx:controller links this FXML to a Java class that handles events
• fx:id gives each widget a name the Controller can reference
• onAction="#handleActivateScene" wires the button click to a Controller method
• spacing, alignment — layout properties, not logic

Scene Builder: This FXML can be created visually by dragging and dropping in Scene Builder. Show a screenshot if you have one. Students will use Scene Builder for GA1.

Analogy: FXML is to JavaFX what HTML is to the web. Structure and layout, not behavior.

Transition: The Controller connects the View to the Model...

How FXML and Java Find Each Other: @FXML Wiring

fx:controller tells JavaFX which class to create. fx:id matches @FXML fields by name. onAction="#method" matches @FXML methods by name. The framework does the wiring — you just make the names match.

This is the "how does it work" slide. Students will be confused by @FXML if they think it's just a decorator. Explain the runtime mechanism:

1. When you load an FXML file with FXMLLoader, JavaFX reads the fx:controller attribute and creates an instance of that class using reflection.
2. For each fx:id in the FXML, JavaFX looks for a field in the Controller with the same name and the @FXML annotation. It assigns the widget to that field (again via reflection).
3. For each onAction="#methodName", JavaFX looks for a method with that name and @FXML, and registers it as the event handler.

The names must match exactly. fx:id="brightnessSlider" must correspond to a field named brightnessSlider (not slider or brightness). This is a common source of "null pointer" bugs — if the names don't match, the field stays null.

Why @FXML? It tells the JavaFX runtime "this field/method should be accessible for injection, even though it's private." Without @FXML, JavaFX can't see private members via reflection.

Common student mistake: Renaming a field in Java but not updating the fx:id in FXML (or vice versa). The app compiles fine but crashes at runtime with a null pointer.

Transition: But before we see the full Controller, let's understand when each piece of code runs...

The JavaFX Component Lifecycle: What Runs When

This is the mental model students need. The most common bug in GA1 will be trying to use @FXML fields in the constructor — they're null until step 3.

Walk through each step:

1. start(Stage stage) — JavaFX calls this for you (inversion of control). You create the stage, load FXML, and show the window. This is the only code you write in Application.

2. FXMLLoader.load() — reads the XML, calls constructors for every widget. The VBox, Label, Slider, Button — all created here. The Controller class is also instantiated here (via fx:controller).

3. @FXML injection — the loader looks at each fx:id in the FXML, finds the matching @FXML field in the Controller, and assigns the widget to that field. Before this step, all @FXML fields are null.

4. initialize() — called automatically after injection completes. This is the safe place to set up listeners, bind properties, and configure widgets that depend on other widgets. The constructor runs before injection, so @FXML fields are null there.

5. Event handlers — once setup is done, the event loop takes over. Your setOnAction, addListener, and onAction="#method" callbacks fire whenever the user interacts. This phase runs indefinitely until the window closes.

The warning is critical: Every semester, students write code like areaNameLabel.setText("Hello") in the constructor and get a NullPointerException. The label doesn't exist yet — it won't be injected until step 3. Use initialize() instead.

Transition: Now let's see the full Controller with this lifecycle in mind...

The Controller: The Translator Between User Actions and Business Logic

// Controller: AreaDashboardController.java
public class AreaDashboardController {

    @FXML private Label areaNameLabel;
    @FXML private Slider brightnessSlider;
    @FXML private Label brightnessValueLabel;
    @FXML private ListView<String> deviceList;

    private Area model;  // the Controller knows the Model

    public void setModel(Area model) {
        this.model = model;
        areaNameLabel.setText(model.getName());
        updateDeviceList();
    }

    @FXML
    private void initialize() {
        // Update label as slider moves
        brightnessSlider.valueProperty().addListener((obs, oldVal, newVal) -> {
            brightnessValueLabel.setText(newVal.intValue() + "%");
            model.setAllLightsBrightness(newVal.intValue()); // delegate to Model
            updateDeviceList();
        });
    }

    @FXML
    private void handleActivateScene() {
        model.activateScene("Evening");  // delegate to Model
        updateDeviceList();
    }

    private void updateDeviceList() {
        deviceList.getItems().setAll(
            model.getDevices().stream()
                .map(SmartDevice::getStatus).toList()
        );
    }
}

The Controller is thin. It does three things:

1. Receives events from the View (slider change, button click)
2. Delegates to the Model (model.setAllLightsBrightness(), model.activateScene())
3. Updates the View (updateDeviceList())

@FXML annotation: This is how JavaFX connects the FXML file to the Java class. When the FXML is loaded, JavaFX finds the fields and methods with @FXML and wires them to the widgets with matching fx:id values.

initialize() method: Called automatically by JavaFX after the FXML is loaded and all @FXML fields are injected. This is where you set up listeners that aren't simple one-line handlers.

Compare to the anti-pattern: The handleActivateScene method is 2 lines. The tangled version was 10+ lines with networking and logging. That's the power of separation.

Transition: Let's trace a complete user interaction through all three layers...

Following a Click Through All Three Layers

User clicks "Activate Scene" for the "Evening" scene. Trace the code:

// 1. VIEW (FXML) — button wired to Controller method
<Button text="Activate" onAction="#handleActivateScene"/>

// 2. CONTROLLER — receives the event, delegates to Model
@FXML private void handleActivateScene() {
    String scene = sceneSelector.getValue();    // read from View
    model.activateScene(scene);                 // delegate to Model
    updateDeviceList();                         // refresh the View
}

// 3. MODEL — pure business logic, no UI
public void activateScene(String name) {
    Scene scene = scenes.get(name);             // "Evening" → dim to 30%, close shades
    for (SmartDevice device : devices) {
        scene.applyTo(device);                  // sets brightness, shade position, fan state
    }
}

// 4. Back in CONTROLLER — View shows updated state
private void updateDeviceList() {
    deviceList.getItems().setAll(                // "Ceiling Light: 30%", "Shades: 80%", "Fan: Off"
        model.getDevices().stream().map(SmartDevice::getStatus).toList());
}

The Model never imports javafx. The View never calls activateScene(). Each layer does one job.

Walk through each numbered section. This is real code students can trace — not a diagram.

Ask: "Which sections could run without a GUI at all?" Answer: section 3. You could call activateScene("Evening") from a unit test, a CLI, or a REST endpoint. That's the point of MVC.

Ask: "Which section is the one we'd like to eliminate?" Answer: section 4 — the manual refresh. Every time you change the model, you have to remember to call updateDeviceList(). That's the problem MVVM will solve in L30.

Transition: Let's check your understanding before we start building...

Comprehension Check

Open Poll Everywhere and answer the next 4 questions.

Run 4 multiple-choice questions on Poll Everywhere. Give ~60 seconds per question, then briefly discuss the answer.

---

Question 1: Event-driven programming

A user clicks "Activate Scene" and then immediately drags the brightness slider. The handleActivateScene() handler takes 3 seconds to run. What happens to the slider drag?

• A. The slider moves smoothly — the framework handles both events in parallel
• B. The slider drag is queued and processed after handleActivateScene() finishes ✅
• C. The slider drag is silently dropped — the event is lost
• D. The app throws a ConcurrentModificationException

Discussion: The event loop is single-threaded. While handleActivateScene() is running, no other events can be processed — the slider drag is queued. The UI appears frozen for 3 seconds. This is why long-running handlers are a problem (and why we'll cover concurrency in L31-32). B and C are both plausible — discuss why it's B: the OS buffers input events in a queue. The event loop isn't ignoring them — it's busy and can't drain the queue yet. Once the handler returns, queued events are processed (the slider may "jump" to the final position). Intermediate move events may get coalesced, but the user's final intent is preserved.

---

Question 2: MVC separation

You need to add a "turn off all lights" feature. Which MVC component should contain the logic for iterating through devices and setting brightness to 0?

• A. The View (FXML file)
• B. The Controller
• C. The Model ✅
• D. The CSS stylesheet

Discussion: The Model contains all business logic. The Controller would call model.turnOffAllLights(), and the View would have a button wired to the Controller — but the logic itself (iterating devices, setting brightness) belongs in the Model where it's testable without the UI.

---

Question 3: @FXML and the lifecycle

Given this Controller, what happens when the FXML is loaded?

public class DashboardController {
    @FXML private Label areaNameLabel;

    public DashboardController() {
        areaNameLabel.setText("Living Room");
    }

    @FXML private void initialize() {
        areaNameLabel.setText("Living Room");
    }
}

• A. The constructor sets the text; initialize() overwrites it with the same value
• B. The constructor crashes with a NullPointerException; initialize() would have worked ✅
• C. Both fail — you can only set text from FXML, not from Java
• D. The constructor works; initialize() is never called because the text is already set

Discussion: JavaFX creates the Controller (constructor runs) before injecting @FXML fields. In the constructor, areaNameLabel is still null → NPE. The initialize() method runs after injection, so the field is populated. This is the #1 lifecycle bug — use initialize(), not the constructor, for anything that touches @FXML fields.

---

Question 4: Testability (forward-looking)

You want to write a unit test that verifies: when the user activates the "Evening" scene, the device list shows "Ceiling Light: 30%". In our MVC architecture, what's the problem?

• A. The Model doesn't have an activateScene method — you'd need to add one
• B. The Controller's handleActivateScene() depends on @FXML widgets, so you can't call it without starting the full JavaFX runtime ✅
• C. Unit tests can't verify String values in lists — you'd need an E2E test
• D. There's no problem — you can test the Controller the same way you test any Java class

Discussion: B is the key insight that motivates the entire next lecture (L30). The Controller contains the logic we want to test, but it also depends on Slider, Label, ListView, ComboBox — all of which need the JavaFX runtime to instantiate. You can't just new AreaDashboardController() and call methods on it. D is what students want to be true — and it's exactly what MVVM will make true by extracting the logic into a ViewModel with no widget dependencies. "What if there was a class that had the Controller's logic but none of its widget dependencies? That's next lecture."

JavaFX Components Are the Standard Components from L28

Remember from L28: standard components get accessibility for free. These are the real buttons, not the fakes:

Component	What it does	SceneItAll use case	Accessibility
Button	Clickable action	"Activate Scene"	Screen reader: "Activate Scene, button"
Label	Display-only text	"Living Room"	Screen reader reads the text
Slider	Continuous value	Brightness control	Arrow keys adjust, announced as "Brightness, slider, 75%"
ComboBox	Dropdown selection	Choose a scene	Arrow keys navigate options
ListView	Scrollable list	Device list	Arrow keys navigate, Enter selects
CheckBox	Toggle on/off	Device power	Space to toggle
TextField	Text input	Rename a device	Screen reader: "Device name, text field"
Spinner	Numeric up/down	Fan speed (1-4)	Arrow keys increment/decrement

All of these support Tab navigation, Enter/Space activation, and screen reader announcements — automatically.

Connection to L28: "Remember the side-by-side? A real button announces itself to a screen reader. A fake button is invisible. These are the real buttons."

Practical tip: If students find themselves styling a Label to look like a button and adding a click handler, they should use a Button instead. Always use the component that semantically matches what the user is doing.

Transition: Components need to be arranged on screen. That's what layout containers do...

Layout Containers: How Components Arrange Themselves

Nesting is the key insight: You combine these. A BorderPane with a TreeView of areas on the left and an area dashboard VBox in the center containing HBox rows for each device control. Students will figure this out quickly once they see the pattern.

Scene Builder makes this visual: Drag a VBox, drop an HBox inside it, drop a Slider inside that. The FXML writes itself.

Tab order follows document order: The order components appear in FXML is the order Tab visits them. This is why layout structure matters for accessibility.

Transition: Let's put this together and build our area dashboard...

Building the Area Dashboard: Putting It All Together

area-dashboard.fxml

<VBox spacing="10"
  fx:controller="sceneitall.AreaDashboardController">

  <Label fx:id="areaNameLabel"
         style="-fx-font-size: 20px;
                -fx-font-weight: bold;"/>

  <HBox spacing="5" alignment="CENTER_LEFT">
    <Label text="Brightness:"/>
    <Slider fx:id="brightnessSlider"
            min="0" max="100"/>
    <Label fx:id="brightnessValueLabel"/>
  </HBox>

  <ListView fx:id="deviceList"
            prefHeight="200"/>

  <HBox spacing="5">
    <ComboBox fx:id="sceneSelector"
              promptText="Choose scene..."/>
    <Button text="Activate"
            onAction="#handleActivateScene"/>
  </HBox>
</VBox>

AreaDashboardController.java

public class AreaDashboardController {
  @FXML private Label areaNameLabel;
  @FXML private Slider brightnessSlider;
  @FXML private Label brightnessValueLabel;
  @FXML private ListView<String> deviceList;
  @FXML private ComboBox<String> sceneSelector;
  private Area model;

  public void setModel(Area model) {
    this.model = model;
    areaNameLabel.setText(model.getName());
    sceneSelector.getItems().setAll(
      model.getSceneNames());
    updateDeviceList();
  }

  @FXML private void initialize() {
    brightnessSlider.valueProperty()
      .addListener((obs, old, val) -> {
        int level = val.intValue();
        brightnessValueLabel.setText(level + "%");
        model.setAllLightsBrightness(level);
        updateDeviceList();
    });
  }

  @FXML private void handleActivateScene() {
    String scene = sceneSelector.getValue();
    if (scene != null) {
      model.activateScene(scene);
      updateDeviceList();
    }
  }

  private void updateDeviceList() {
    deviceList.getItems().setAll(
      model.getDevices().stream()
        .map(SmartDevice::getStatus).toList());
  }
}

This is the complete working example. If you have time and a projector, run it live. If not, walk through the code explaining how each piece connects.

Key things to point out:

• The FXML and Controller are two halves of the same feature — the FXML defines structure, the Controller defines behavior
• @FXML annotations match fx:id values — this is the wiring
• onAction="#handleActivateScene" in FXML calls handleActivateScene() in the Controller
• The Controller calls model.activateScene() — it doesn't implement scene logic
• The ComboBox is populated from the Model — scene names come from model.getSceneNames()
• updateDeviceList() is the manual refresh — we'll automate this with binding next

Transition: That manual refresh is annoying. What if the View could update automatically?

Properties and Binding: When the Model Changes, the View Updates Automatically

JavaFX properties are observable values. When they change, anything bound to them updates automatically:

// Model with JavaFX properties
public class Light extends SmartDevice {
    private final IntegerProperty brightness = new SimpleIntegerProperty();
    private final BooleanProperty on = new SimpleBooleanProperty();
    private final StringProperty status = new SimpleStringProperty();

    public IntegerProperty brightnessProperty() { return brightness; }
    public BooleanProperty onProperty() { return on; }
    public StringProperty statusProperty() { return status; }

    public void setBrightness(int level) {
        brightness.set(Math.clamp(level, 0, 100));
        on.set(brightness.get() > 0);
        status.set(on.get() ? getName() + ": " + brightness.get() + "%" : getName() + ": Off");
    }
}

// Controller: bind once, never manually refresh
brightnessSlider.valueProperty().bindBidirectional(light.brightnessProperty());
brightnessValueLabel.textProperty().bind(
    light.brightnessProperty().asString("%d%%")
);
// When light.setBrightness(30) is called anywhere, the slider and label update automatically.

Bind once. Never call updateUI() again. The View and Model stay in sync automatically.

This is the "magic" moment. Students will find this powerful once they see it work.

Explain the pattern:

• SimpleIntegerProperty wraps an int and fires change events when it's modified
• bind() is one-way: Label always shows whatever the property contains
• bindBidirectional() is two-way: moving the slider changes the model AND vice versa

SceneItAll payoff: When the user activates the "Evening" scene, the model sets brightness to 30%. The slider physically moves to 30% without the Controller telling it to. That's binding.

When to use properties vs. plain fields:

• Use properties for data that the UI displays or edits
• Use plain fields for internal state the UI doesn't need to see
• In L30 (MVVM), we'll formalize this with ViewModel classes

Transition: Let's make it look good...

CSS Styling: Your App Doesn't Have to Look Like 1997

JavaFX supports CSS — the same language used to style websites:

Before (default styling)

Gray widgets, system font, no visual hierarchy. Functional but uninviting.

After (with CSS)

Dark theme for a smart home dashboard, accent colors for active devices, hover effects. Same widgets, different experience.

/* styles.css */
.root {
    -fx-font-family: "Inter", sans-serif;
    -fx-base: #1a1a2e;           /* dark background */
    -fx-accent: #e94560;          /* accent color */
}
.button {
    -fx-background-color: #0f3460;
    -fx-text-fill: white;
    -fx-padding: 8px 16px;
    -fx-cursor: hand;
}
.button:hover { -fx-background-color: #16213e; }
.slider .track { -fx-background-color: #333; }
.slider .thumb { -fx-background-color: #e94560; }

<!-- Link the stylesheet in FXML -->
<VBox stylesheets="@styles.css">

Keep this brief — 2 minutes. Students will learn CSS by doing in GA1. The point here is: styling is separate from structure and behavior. That's the third separation (after Model from View and View from Controller).

Dark theme for SceneItAll makes sense — smart home dashboards often use dark themes for ambient use. This also shows students that CSS can dramatically change the look without touching any Java code.

Key JavaFX CSS differences from web CSS:

• Properties are prefixed with -fx- (e.g., -fx-background-color not background-color)
• Selectors use JavaFX class names (.button not button)
• No flexbox/grid — layout is done with containers, not CSS

Transition: Now let's connect this to what we learned about accessibility in L28...

Every Widget Needs a Name: Accessible Text in JavaFX

From L28: if a screen reader can't announce it, it doesn't exist. In JavaFX:

<!-- Accessible: screen reader says "Living room brightness, slider, 75 percent" -->
<Slider fx:id="brightnessSlider" min="0" max="100"
        accessibleText="Living room brightness"
        accessibleHelp="Use arrow keys to adjust brightness from 0 to 100 percent"/>

<!-- Accessible: screen reader says "Activate scene, button" -->
<Button text="Activate Scene" onAction="#handleActivateScene"/>

<!-- NOT accessible: screen reader says "button" (no label!) -->
<Button onAction="#handleToggleLight">
    <graphic><ImageView image="@lightbulb-icon.png"/></graphic>
</Button>

<!-- Fixed: icon button WITH accessible text -->
<Button onAction="#handleToggleLight"
        accessibleText="Toggle desk lamp on or off">
    <graphic><ImageView image="@lightbulb-icon.png"/></graphic>
</Button>

The icon-only button is the most common accessibility mistake students will make. A lightbulb icon makes visual sense, but is unnamed to assistive technology.

Rule of thumb: If your button has text, you're fine — the text is the accessible text. If your button has only an icon or graphic, you must add accessibleText.

accessibleHelp provides additional context read after the main announcement. Use it for widgets where the purpose isn't obvious from the label alone (e.g., sliders, spinners).

Transition: Keyboard navigation...

Keyboard Navigation and Focus Management

Focus is which widget is currently "selected" for keyboard input — the one that will respond when you press Enter, type text, or press arrow keys. Only one widget has focus at a time.

• Standard components get keyboard navigation for free. Tab moves focus between widgets in FXML document order. Enter activates buttons. Arrow keys adjust sliders. No extra code.
• Tab order = FXML document order. Arrange your FXML so Tab visits elements in a logical sequence.
• Focus must be visible. The focused widget shows a highlight ring so keyboard users know where they are. Never remove this with CSS.
• Dialogs trap focus. Use JavaFX's built-in Dialog and Alert — they handle focus trapping and return automatically.

Define focus first — students may not have a mental model for this. "Focus is the cursor for keyboard users. In a text editor, the cursor shows where your typing goes. In a GUI, focus shows which widget your keypresses go to."

Demo option: Tab through your slides or the course website right now. Show students the focus ring moving between elements. This is more effective than any diagram.

GA1 tips:

• If you're tempted to paint something clickable on a Canvas, use a Button with CSS styling instead — Canvas elements can't receive focus
• Use Alert for confirmations, Dialog for forms — don't build custom popups
• If you must use a custom popup, call requestFocus() when it opens
• Never remove focus outlines with CSS — keyboard users need them to navigate

Transition: Let's look ahead at what comes next...

The Problem MVC Doesn't Solve: Testability of the View

We can unit test the Model — it's pure Java. But the Controller has a problem:

// Can we unit test this?
public class AreaDashboardController {
    @FXML private Label areaNameLabel;     // needs JavaFX runtime
    @FXML private Slider brightnessSlider; // needs JavaFX runtime
    @FXML private ListView<String> list;   // needs JavaFX runtime

    // To test handleActivateScene(), we'd need to:
    // 1. Start the JavaFX runtime
    // 2. Load the FXML
    // 3. Create all the widgets
    // 4. Simulate a button click
    // That's an integration test, not a unit test.
}

The Controller is tangled with JavaFX widgets. We can't test the logic without the framework.

Could JavaFX solve this by providing a testing library that mocks all your FXML components? Sure — but that's a lot of software just to help you test software. There's a simpler answer.

Next lecture (L30): The Model-View-ViewModel (MVVM) pattern solves this by extracting testable logic into a ViewModel that has no UI dependencies. No mock framework needed.

Set up the cliffhanger. Students now understand MVC and can see its limitation. L30 will introduce MVVM as the natural evolution — and TestFX for end-to-end GUI testing.

The mock framework point: This is worth dwelling on. The instinct is "just mock the widgets." But that means building and maintaining fake versions of Label, Slider, ListView, Button, ComboBox... and keeping them in sync with the real ones across JavaFX versions. It's a massive maintenance burden. The better answer is architectural: move the logic out of the class that depends on widgets, so you don't need to mock anything.

This is hexagonal architecture again: In L16 we said "don't mock your domain — separate it from infrastructure." The Controller is infrastructure (it depends on JavaFX). The fix isn't to mock JavaFX — it's to pull the logic into a plain Java class (the ViewModel) that doesn't depend on JavaFX at all.

The key insight to plant: "What if the Controller's logic — reading the slider value, deciding to activate a scene, deciding what to display — lived in a plain Java class with no @FXML annotations? Then we could unit test it just like the Model."

That's the ViewModel. Next lecture.

Transition: Here's how your GA1 architecture looks...

Your GA1 Architecture at a Glance

• Each team member owns one feature (View + Controller + ViewModel)
• All features share the same Model layer (your domain classes from HW1-HW5)
• ViewModel interfaces are provided — they define the contract between features
• Today we used SceneItAll; in GA1 you'll apply the same patterns to CookYourBooks

This is the GA1 architecture. Each student owns one vertical slice — their own FXML, Controller, and ViewModel — but they all plug into the shared Model.

Why SceneItAll today: We used a different domain so you'd arrive at GA1 with fresh eyes for CookYourBooks. The patterns — MVC, FXML, properties, accessibility — are identical regardless of domain.

The ViewModel interfaces serve the same role as the interfaces from earlier assignments: they define what your feature must do without prescribing how. Your TA will evaluate your ViewModel implementation independently.

Transition: Key takeaways...

Key Takeaways

1. GUI programming inverts control. The framework runs the event loop; your code responds to events via callbacks.
2. MVC separates concerns. Model = business logic (testable). View = presentation (FXML). Controller = translation (thin).
3. Use standard components. Button, Slider, ComboBox, ListView — they get accessibility, keyboard navigation, and screen reader support for free.
4. FXML separates structure from behavior. Layout in XML, logic in Java, styling in CSS — three files, three concerns.
5. Properties and binding keep the View in sync. Bind once, never manually refresh. The Model and View stay connected automatically.
6. Accessibility is not extra work — it's using the right components. Standard components + accessible text + focus management covers the baseline.

Reinforce #3 and #6: These are the most common mistakes in GA1. Students who use standard components and add accessible text will save themselves debugging time AND score higher on the accessibility criteria.

Transition: Looking ahead...

Looking Ahead

Lab 12 (next Monday): Hands-on GUI practice

• Build SceneItAll GUI components yourself — using the examples from this lecture and L30
• Bring your laptop with Scene Builder installed

Next up: GUI Patterns and Testing (L30)

• Model-View-ViewModel (MVVM) — the testable evolution of MVC
• Data binding deep dive — observable lists, computed properties
• TestFX — automated end-to-end GUI testing

Your group project:

• GA0 (due Mar 26): Design Sprint — wireframes, personas, accessibility plan
• GA1 (due Apr 9): Core Features — each person owns one feature (Library, Editor, Import, or Search)
• Start exploring Scene Builder and the OpenJFX documentation

Today you learned the architecture. Next, you learn to test it. Then you build it for real.

Encourage early exploration: Students should download Scene Builder and try dragging components around before GA1 starts. The learning curve is in the tooling, not the concepts.

AI policy reminder: AI is encouraged for GA1. It's great for generating FXML boilerplate and wiring up property bindings. Students must understand the code well enough to debug and explain it in code walks.

That's it for today. Questions?