La interfaz es la parte que permite a una persona introducir órdenes y recibir información. La lógica interpreta entradas y decide cambios de estado. En App Inventor, el Diseñador organiza componentes y propiedades, mientras los bloques programan respuestas. Una etiqueta dibujada con la palabra ENCENDIDO no controla ningún dispositivo. Tampoco demuestra que una orden haya llegado. Debemos definir audiencia, tarea y mensajes antes de elegir colores o añadir pantallas que no resuelvan una necesidad.

Un panel accesible ofrece nombres concretos, separación entre controles, texto legible y una respuesta visible a cada acción. No comunica información esencial solo mediante color: combina palabras y señales. En nuestro simulador puede declararse APAGADO como inicio del modelo; en un aparato real no conocemos el estado solo por abrir la app. La interfaz distingue último dato confirmado y situación actual desconocida. Esta precisión permite corregirse sin confiar en una confirmación inventada. La prueba de uso observará si otra pareja puede aplicar un nivel y volver a los ajustes sin instrucciones verbales iniciales.

Una app responde a hechos que activan instrucciones: pulsar Aplicar, iniciar una pantalla o recibir una respuesta son eventos. Cada evento tiene un manejador, el grupo de bloques que indica cómo reaccionar. Su posición visual en el editor no establece una secuencia continua de ejecución de toda la app. Lo que conecta unas acciones con otras es la información que dejan en las variables compartidas. Por eso comprender el comportamiento exige saber qué evento lee un dato y cuál puede modificarlo.

En el panel, el texto introducido, el nivel solicitado y el último nivel confirmado representan momentos distintos de una misma petición. La validación comprueba si la entrada es aceptable; no demuestra que el dispositivo la haya ejecutado. El estado de comunicación añade otra información: puede haber una petición pendiente, una confirmación o falta de respuesta. En este último caso se conserva el último valor conocido sin presentarlo como confirmación nueva. Cambiar de vista tampoco aporta evidencia sobre lo ocurrido en el dispositivo.

Un procedimiento reúne bajo un nombre una tarea reutilizable, como presentar los datos actuales en las etiquetas. Utilizarlo desde varios eventos evita mantener versiones distintas del mismo mensaje, aunque su corrección sigue dependiendo de que use el dato adecuado. El mapa de eventos y variables permite seguir esa relación. Cuando dos eventos escriben sobre la misma variable, importa comprobar qué responsabilidad tiene cada uno: una navegación o un reinicio no deben convertir información antigua en confirmación de una acción nueva.

Validar significa comprobar si una entrada cumple el contrato de uso antes de modificar el sistema. Para un nivel entre 0 y 100 hay preguntas diferentes: si existe contenido, si puede tratarse como número y si pertenece al intervalo. Una casilla vacía no expresa cero. Un texto como «alto» no es un nivel numérico. Un número como 101 tiene formato numérico, pero queda fuera del rango. El mensaje debe explicar qué puede corregir la persona.

El contrato también aclara si se admiten decimales y cómo se escriben en el entorno de prueba. No conviertas silenciosamente una entrada ambigua en otra decisión. En App Inventor puedes combinar comprobación numérica y comparaciones, ordenando las ramas para no actualizar valores confirmados con datos rechazados. Ensaya vacío, letras, -1, 0, 100 y 101, además del caso decimal que hayas definido. Verifica mensaje y memoria después del error: mostrar una alerta no demuestra que la variable haya quedado protegida. Una entrada aceptada todavía necesita una respuesta del simulador antes de considerarse ejecutada.

La memoria de una app puede durar lo que dura su ejecución o mantenerse entre aperturas. Una variable conserva información mientras el programa funciona, pero al iniciarse de nuevo recibe los valores de inicialización. TinyDB proporciona persistencia local: guarda un valor asociado a una etiqueta y permite recuperarlo en otra ejecución. La preferencia de tamaño de texto sirve para estudiar esa continuidad sin almacenar claves ni datos personales. La etiqueta identifica qué información se recupera, no qué componente visual cambia.

StoreValue guarda el valor y GetValue lo recupera; si la etiqueta no existe, este último devuelve el valor por defecto previsto. En el panel se utiliza CR2S03_texto tanto al guardar como al recuperar, porque ambos pasos deben referirse a la misma información. Después hace falta aplicar la preferencia a los textos previstos. Guardar, recuperar y presentar tienen responsabilidades diferentes: una lectura correcta de TinyDB puede coexistir con una etiqueta cuyo tamaño no se haya actualizado.

Esa diferencia orienta la comprobación. Ir de Control a Ajustes durante una misma ejecución puede conservar una variable y no demuestra persistencia. El primer inicio sin preferencia permite observar el valor por defecto; guardar, cerrar y abrir permite comprobar la recuperación posterior. En AI Companion, proyectos distintos pueden compartir TinyDB, por lo que no se borran indiscriminadamente datos de otros trabajos. Este almacenamiento no crea cuentas ni sincroniza dispositivos. Además, restaurar una preferencia no equivale a conocer el estado actual de un aparato: una confirmación guardada sigue siendo el último dato conocido.

La navegación organiza cómo se pasa entre vistas sin perder la información pertinente. Control y Ajustes pueden representarse con disposiciones visibles u ocultas dentro de una pantalla; dos vistas no obligan a crear dos pantallas independientes. Define qué se conserva al volver, qué se valida y dónde aparece la respuesta. La opción Volver debe mantener su significado y no ejecutar por accidente una orden del panel. Las etiquetas y controles necesitan orden comprensible y posibilidad de corregir una elección.

Notifier puede mostrar un diálogo con Parar y Cancelar. ShowChooseDialog abre la pregunta; AfterChoosing permite interpretar la elección posterior. Mostrar el diálogo no equivale a elegir Parar. Cancelar vuelve al panel sin inventar confirmación, y confirmar todavía necesita la respuesta del simulador para mostrar APAGADO confirmado. También contempla cerrar el diálogo sin seleccionar una acción. Esta práctica estudia eventos y decisiones de una interfaz simulada. No representa una parada de emergencia de una máquina: esa función real no debe depender de un diálogo que retrase o confunda la respuesta. Comprueba regreso, lectura y uso en el dispositivo disponible.

El selector Responde/No responde representa si existe confirmación del dispositivo simulado. No establece Bluetooth ni WiFi, ni demuestra ejecución física. Con una entrada válida y respuesta disponible puede actualizarse el valor confirmado del modelo. Sin respuesta se muestra la incertidumbre y se identifica el valor anterior como último conocido. En la versión mínima el selector no introduce espera real; sirve para estudiar la diferencia entre solicitud y confirmación antes de trabajar con comunicación auténtica.

Una prueba funcional relaciona entrada, evento, mensaje y datos posteriores. Incluye petición válida, inválida, respuesta y ausencia de respuesta, además de persistencia. Una prueba de accesibilidad observa si otra pareja completa una tarea sin ayuda inicial y qué mensajes interpreta. No equivale a certificar accesibilidad universal. Registra dudas concretas y corrige una antes de repetir la tarea. Exporta el proyecto .aia para conservar bloques y componentes editables: una imagen o una app instalada no sustituye ese archivo. Documenta el dispositivo o emulador utilizado y qué funciones siguen siendo simuladas en la entrega.

El laboratorio sigue una petición a través de varias capas: entrada, validación, solicitud, respuesta y presentación. Cada capa tiene una responsabilidad. Un fallo visible puede proceder de una variable incorrecta, de un evento equivocado o de una etiqueta que no refleja los datos. Para investigar, escribe la predicción y observa una capa cada vez. El registro de síntoma, hipótesis, cambio y nueva prueba explica mejor la reparación que una colección de capturas sin relación con el comportamiento.

También conviene anticipar una respuesta tardía. Si llegan dos solicitudes seguidas, podría confundirse qué respuesta corresponde a cada una. El prototipo puede limitarse a una petición pendiente para mantener esa relación comprensible; una conexión más compleja necesitaría identificar solicitudes. A01 reúne pantallas, eventos, datos, validación, cuatro pruebas previstas y una microapp ya ejecutada. A02 incorpora persistencia comprobada, navegación, cuatro casos y prueba de accesibilidad, con una mejora. La explicación individual sigue un evento y una decisión propia. Estas prácticas se integran en las dos entregas y no añaden otra actividad calificable.

Asíncrono describe un proceso cuyo resultado llega en otro momento. En el componente Web, iniciar una petición y recibir GotText son hechos separados; TimedOut informa de que se agotó el tiempo de espera configurado. Esa documentación sirve para comprender la separación, aunque nuestro selector no use una red real. Una respuesta recibida todavía necesita comprobar que corresponde a la solicitud y contiene una confirmación válida: recibir cualquier texto no demuestra que un aparato haya ejecutado una orden.

La conexión física es una ampliación que exige interfaz compatible, protocolo de mensajes y pruebas adicionales. Debe describir qué se envía, qué respuesta se acepta, cuánto se espera y qué se presenta si falla. No es necesario añadirla para resolver el panel simulado. Consulta tutoriales oficiales con una pregunta concreta sobre componentes, almacenamiento o eventos y registra el bloque que aclara tu duda. Los vídeos opcionales pueden pausarse y sustituirse por explicación escrita. Conservar .aia y un breve registro de decisiones facilita adaptar el panel a otra necesidad, revisando datos y validación en vez de copiar mensajes sin comprobar su significado.