The interface lets a person enter commands and receive information. Logic interprets inputs and decides state changes. In App Inventor, the Designer organises components and properties, while blocks program responses. A label displaying ON does not control a device. It does not prove that a command arrived either. Define audience, task and messages before choosing colours or adding screens that do not address a need.

An accessible panel offers specific names, space between controls, readable text and visible feedback for each action. Essential information is not communicated through colour alone: combine words and signals. Our simulator may declare OFF as the model’s starting state; a real device’s state is not known merely by opening the app. The interface distinguishes the last confirmed value from an unknown current situation. This precision supports correction without trusting an invented confirmation. The usage test observes whether another pair can apply a level and return to settings without initial spoken instructions.

An app responds to occurrences that activate instructions: pressing Apply, initialising a screen or receiving a response are events. Each event has a handler, the group of blocks that specifies how to react. Their visual position in the editor does not establish a continuous execution sequence for the entire app. Actions are connected by the information they leave in shared variables. Understanding behaviour therefore requires knowing which event reads a piece of data and which can change it.

In the panel, entered text, requested level and last confirmed level represent different stages of one request. Validation checks whether the input is acceptable; it does not show that the device executed it. Communication state adds another piece of information: a request may be pending, confirmed or unanswered. In the last case, the last known value is retained without presenting it as a new confirmation. Changing views also provides no evidence about what happened at the device.

A procedure groups a reusable task under a name, such as presenting current data in labels. Calling it from several events avoids maintaining different versions of the same message, although correctness still depends on using the right data. The event-and-variable map traces that relationship. When two events write to the same variable, each one’s responsibility needs checking: navigation or a restart must not turn old information into confirmation of a new action.

Validation checks whether input meets the usage contract before changing the system. For a level between 0 and 100, ask separate questions: whether content exists, whether it can be treated as a number and whether it lies in the interval. An empty field does not express zero. Text such as ‘high’ is not a numerical level. A number such as 101 has numerical format but lies outside the range. The message should explain what the person can correct.

The contract also clarifies whether decimals are allowed and how they are entered in the test environment. Do not silently transform ambiguous input into another decision. In App Inventor, combine numerical checks and comparisons, ordering branches so rejected data cannot update confirmed values. Test empty input, letters, -1, 0, 100 and 101, plus your defined decimal case. Check both message and memory after errors: an alert does not prove the variable was protected. Accepted input still needs a simulator response before being considered executed.

An app’s memory may last for one execution or persist between launches. A variable retains information while the program runs, but receives its initialisation values when the program starts again. TinyDB provides local persistence: it stores a value under a tag and retrieves it during another execution. The text-size preference explores that continuity without storing passwords or personal data. The tag identifies the information to retrieve, rather than the visual component to change.

StoreValue saves the value and GetValue retrieves it; if the tag does not exist, the latter returns the planned default value. The panel uses CR2S03_texto for both saving and retrieving, because both steps must refer to the same information. The preference then needs applying to the intended text components. Saving, retrieving and presenting have different responsibilities: a correct TinyDB retrieval can coexist with a label whose size has not been updated.

That distinction guides checking. Moving from Control to Settings within one execution may retain a variable and does not demonstrate persistence. A first launch without a preference shows the default; saving, closing and reopening checks later retrieval. In AI Companion, different projects can share TinyDB, so other projects’ data must not be erased indiscriminately. This storage neither creates accounts nor synchronises devices. Restoring a preference also differs from knowing a device’s current state: a stored confirmation remains the last known value.

Navigation organises movement between views without losing relevant information. Control and Settings may use visible or hidden arrangements within one screen; two views do not require two independent screens. Define what remains on return, what is validated and where feedback appears. Back must keep its meaning and must not accidentally execute a panel command. Labels and controls need a comprehensible order and opportunities to correct a choice.

Notifier can display a dialog with Stop and Cancel. ShowChooseDialog opens the question; AfterChoosing interprets the later choice. Showing the dialog does not mean choosing Stop. Cancel returns to the panel without inventing confirmation, and confirmation still requires the simulator’s response before showing confirmed OFF. Also handle dismissal without choosing an action. This exercise studies events and decisions in a simulated interface. It is not a machine emergency stop: that real function must not depend on a dialog delaying or confusing response. Check return, reading and operation on the available device.

The Responds/Does not respond selector represents whether confirmation from the simulated device exists. It establishes neither Bluetooth nor WiFi and demonstrates no physical execution. With valid input and an available response, the model’s confirmed value may update. Without a response, show uncertainty and identify the previous value as last known. In the minimum version, the selector introduces no real waiting; it studies request versus confirmation before authentic communication.

A functional test connects input, event, message and subsequent data. Include valid and invalid requests, response and no response, plus persistence. An accessibility test observes whether another pair completes a task without initial help and how messages are interpreted. This does not certify universal accessibility. Record specific difficulties, fix one and repeat the task. Export the .aia project to preserve editable blocks and components: neither an image nor an installed app replaces it. Document the device or emulator and which functions remain simulated in the submission.

The laboratory traces a request through input, validation, request, response and presentation. Each layer has a responsibility. A visible fault may come from an incorrect variable, a wrong event or a label that does not reflect data. To investigate, write the prediction and observe one layer at a time. Recording symptom, hypothesis, change and retest explains a repair better than unrelated screenshots.

Anticipate late responses too. With two consecutive requests, the app might confuse which response belongs to which request. The prototype can allow only one pending request to keep that relationship understandable; a more complex connection would need request identifiers. A01 combines screens, events, data, validation, four planned tests and an already executed micro-app. A02 includes verified persistence, navigation, four cases and an accessibility test, with an improvement. The individual explanation traces an event and a personal decision. These practices contribute to the two assignments without adding another graded activity.

Asynchronous describes a process whose result arrives at another time. With the Web component, starting a request and receiving GotText are separate events; TimedOut reports expiry of the configured waiting time. This documentation explains the separation even though our selector uses no real network. A received response must still be checked for correspondence with the request and valid confirmation: receiving arbitrary text does not prove that a device executed a command.

Physical connection is an extension requiring a compatible interface, message protocol and additional tests. It must describe what is sent, which response is accepted, how long to wait and what is shown on failure. It is unnecessary for completing the simulated panel. Consult official tutorials with a specific question about components, storage or events and record the block resolving it. Optional videos can be paused and replaced by written explanation. Keeping .aia and a short decision record supports adaptation to another need by reviewing data and validation rather than copying messages without checking meaning.