App Lab Reference Card

The full trace

Every interaction is element ID → event type → handler → visible result. Say all four out loud before you type.

onEvent("greenBtn", "click", function() {
  setProperty("statusLabel", "background-color", "green");
});

Name it before you use it

Give every element a purposeful ID in Design Mode first. Code can't find an ID that doesn't match exactly — that's the most common first error.

Setup code vs. event code

Code outside any onEvent runs once, when the app starts. Code inside it runs only after that event.

var score = 0; // setup — runs once

onEvent("clickBtn", "click", function() {
  // event code — runs only on this click
});

Changing what's on screen

Five functions, one job each:

setText(id, text);    // change what a label/button says
getText(id);          // read what's currently there
setProperty(id, prop, value);  // change a style, e.g. color
hideElement(id);       // hide it
showElement(id);       // show it again

Multiple screens

Draw the screen flow on paper before wiring a single button. Every screen needs a way back — don't trap the user somewhere with no recovery path.

onEvent("toProfileBtn", "click", function() {
  setScreen("screen2");
});

Screens vs. state

Changing screens changes the view — it does not erase a variable's value. A variable declared outside every handler keeps its value no matter which screen is showing.

var visitCount = 0; // lives outside every screen

onEvent("toProfileBtn", "click", function() {
  setScreen("screen2");
  visitCount = visitCount + 1;
});

The state pattern

Name it → initialize it once → update it on an event → refresh the display. Skipping the last step is the #1 bug in this unit.

var currentValue = 0;  // 1 & 2: name it, initialize once

onEvent("increaseBtn", "click", function() {
  currentValue = currentValue + 1;       // 3: update
  setText("valueLabel", "Value: " + currentValue); // 4: refresh
});

Building display text

setText only accepts a string. Build one with + before you can show a number.

setText("valueLabel", "Value: " + currentValue);

Predict before you click

Before each click: what's the value now? What will it become? Click, then check. This is how you catch a bug instead of just noticing "it feels off."

One condition: if / else

One question, one fork. If it's true the first block runs; otherwise else runs, if there is one.

if (score < 60) {
  grade = "F";
} else {
  grade = "A";
}

if / else if / else — order matters

JavaScript checks top to bottom and stops at the first true condition. Put the smallest boundary first, or a later condition can wrongly catch a value meant for an earlier one.

if (score < 60) grade = "F";
else if (score < 70) grade = "D";
else if (score < 80) grade = "C";
else if (score < 90) grade = "B";
else grade = "A";

Reading input from the user

getText on a TextInput always returns a string, even for digits. Use getNumber instead when you need a number to compare or do math with — it reads and converts in one step.

var typed = getText("ageInput");
setText("echoLabel", "You typed: " + typed); // prove you read it
var age = getNumber("ageInput"); // reads AND converts to a number

Randomness + one round

randomNumber(min, max) picks a whole number in that range, inclusive. Keep the function that sets up a new round separate from the function that judges a click.

var colors = ["Red", "Blue", "Green"];
var target = colors[randomNumber(0, 2)]; // setup � a new round
// a different function compares the click to target � don't merge the two jobs

= vs == vs ===

= assigns a value. === compares value AND type — use this one for new JavaScript. == compares with coercion first, which can call two different types "equal" — avoid it.

score = 0; // assigns — changes score
if (typed == 0) // avoid — true even if typed is the string "0"
if (typed === 0) // prefer — only true if typed is the number 0

Habits that keep apps working

Test every screen transition from a fresh run — not just the path you built first.
Break one ID on purpose (misspell it), run it, and read the error before fixing it back — that's how you learn to read errors instead of panicking at them.
Force known values into a random-based condition (like a dice or Color Sleuth round) to prove each branch fires, instead of clicking until luck hits it.

Mismatched IDonEvent("greenBtn", ...) when Design Mode says greenButton — it just silently does nothing.

Forgot to refreshThe variable changed, but no setText call after it — the number's right, the screen just doesn't say so.

No way backA screen with a setScreen forward and nothing routing back traps the user.

Reset inside the handlervar currentValue = 0; placed inside onEvent resets it to 0 every click instead of accumulating.

Branch order flippedPutting a wider condition (like score < 90) before a narrower one (like score < 60) catches values that should've landed in the narrower branch first.

Compared without convertinggetText(id) returns a string — comparing it straight to a number gives surprising results. Use getNumber(id) instead when you need a number.

Function passed as a stringonEvent("nextBtn", "click", "checkGuess") — quoting the function name turns it into text instead of a callback. Pass checkGuess with no quotes.