An application combines an interface and rules for completing a task. The interface includes what a person sees and uses: controls, text and messages. Before choosing buttons, describe a need. Preparing materials without forgetting one is a task; having many screens is a design choice that does not yet explain usefulness. Represent use through three moments: opening and understanding, acting, and reviewing the result. This route helps choose components and remove elements without a function.

A requirement specifies behavior we can check. ‘Show how many materials are missing’ supports test cases; ‘look nice’ does not establish an expected response. Messages should explain both what to do and what just happened. Color can reinforce text but should not be the only signal. Readable lettering, specific labels and clear navigation help different people from the first sketch. Investigating a need does not require names or personal habits: discussing a fictional classroom task supplies enough context for this project.

In App Inventor‘s Designer we place components and set properties such as text, size and arrangement. In Blocks we program responses. A property describes an aspect or state of a component; an event identifies something that can launch instructions. A button’s Click event occurs when it is tapped. A label displays information, and a CheckBox maintains a checked or unchecked state. Components have different functions even when occupying similar screen areas. Changing a label’s initial text does not itself program a response to a button.

Internal names such as BotonAyuda or EtiquetaResultado identify pieces when reading blocks. Visible wording is for the user and need not match those names. This distinction avoids exposing unnecessary technical instructions. Responding to an event can change another component‘s property, linking action and result. Building a small screen and testing one event lets us investigate each part before adding counting and navigation. The emulator or school device shows execution; the Designer represents preparation of the interface.

An application’s state describes its current situation. In a materials list, checkboxes indicate which items are ready, and a variable can retain a count during execution. Pressing Check starts an action, but does not represent a new item. If the boxes stay unchanged, checking again should describe the same situation. Counting presses retains a history of actions; counting checked boxes answers a question about the present. That difference determines which value we need to calculate.

To obtain the current count, we can start from zero at each check and inspect which boxes are checked. The result then depends on the materials represented at that moment rather than how often the button was pressed. Missing items relate to the total number of items and the number prepared. A condition distinguishes whether nothing is missing or something remains. Unchecking also changes the state: allowing this correction keeps the response consistent when the person revises their selection.

The list and its calculation form a whole. Adding an item affects components, counting, the completion condition, instructions and tests. Reviewing these relationships prevents the screen from promising a function the blocks do not yet represent. We investigate this consistency while the app is in use. A variable in memory does not guarantee that data survives closing; permanent storage would be another function requiring its own decisions and tests.

A view organizes an area of the interface for a particular purpose. Home can contain the list and result, while Help explains how to use them. In the introductory route, both are built with two vertical arrangements inside Screen1. Each arrangement groups components and has a Visible property indicating whether it is shown. Changing views changes the presentation of that same screen; it focuses attention on the task or its explanation without mixing every element at once.

Navigation connects an action with two coordinated changes: going to Help shows that group and hides Home; Back does the reverse. Hiding one area without showing the other can leave an apparently empty screen. Showing both may make it harder to recognize where we are and what to do. The return must therefore be easy to find, and Help must explain the task, messages and limits of simulated data. Its usefulness depends on the person being able to continue afterward.

Even when a view is hidden, its components and variables still belong to the same execution. A checkbox can remain checked on return because a new component has not been created. This retention during use explains the observation, but does not establish that data survives fully closing the app: hiding does not save to permanent storage. Drawing the routes and testing both directions checks navigation and state. Encountering a dead end is a functional fault, just like obtaining an incorrect count.

A connected system can move information from a sensor and board to an application through communication. This chain must obtain, send, receive and interpret the value. Our project represents part of it through simulation: a button changes a variable and the interface displays the result. The number comes from neither a board nor a physical connection. It must appear beside a SIMULATED DATA label. A sensor drawing or a button named Connect does not demonstrate device communication.

Simulation provides known cases for checking messages and conditions before implementing a connection. The teaching values 20 and 80 represent two trial inputs without an assigned physical unit. If the interface uses a threshold, explain each response and what happens at the boundary. Replacing simulated input with a real source would require reviewing communication, format and the response to missing information. An old value should not be presented as a new reading. Drawing the complete chain distinguishes implemented parts from represented ones.

A functional test checks a rule: counting, correction, navigation or simulated-value change. A usability test observes whether another person understands how to complete a task. The builder already knows where controls are, so their ease of use does not represent the whole audience. Give the prepared emulator or device to another pair and state a task without pointing at buttons. Record hesitation, message interpretation and whether they find a return. Describe the design rather than blaming the tester.

Connect improvement to the observed problem. A specific label can aid understanding; recalculation prevents accumulation; moving Back helps navigation. Repeat the task and check another function for unwanted effects. Keep the .aia source project through App Inventor export and import. A screenshot shows one state, whereas .aia preserves editable components and blocks; it differs from a compiled installable app. A01 includes design and an executed microapp; A02 combines product, tests and improvement. Both retain sources, permissions, minimum data and individual explanation.