Volver a tu curso / CR2-S03
Computación y Robótica · 2.º ESO · Lectura fácil
Apps para controlar y ayudar
Una app útil ayuda a realizar una tarea.
Debe distinguir lo que pide la persona de lo que ha confirmado el sistema.
Tu misión
Crea un panel en App Inventor con Control y Ajustes.
Valida niveles de 0 a 100 y guarda una preferencia local.
Usa un dispositivo simulado que responde o no responde.
La conexión física es una ampliación.
Lee una explicación cada vez. Mira el esquema. Después haz la actividad. Puedes cambiar de versión cuando quieras.
Qué herramientas vas a usar
Escribe los textos en Documentos de Google. Haz los diagramas en diagrams.net. Guarda el archivo que puedas editar. Mira qué debes entregar en cada tarea.
3.1. Distingue controles y funcionamiento
Aprende y practica
La interfaz permite introducir órdenes y recibir información.
La lógica interpreta entradas y cambia estados.
El Diseñador organiza componentes y los bloques programan respuestas.
Una etiqueta ENCENDIDO no controla un aparato ni demuestra que recibió la orden.
Define público, tarea y mensajes antes de decorar.
Usa controles separados, nombres claros y texto legible.
Comunica con palabras y no solo con colores.
APAGADO puede ser el inicio declarado del simulador.
Abrir una app real no demuestra el estado del aparato.
Prueba si otra pareja puede aplicar un nivel y volver a Ajustes sin explicación inicial.
- Necesidad
- Control
- Respuesta
- Mensaje
Un círculo verde puede significar cosas distintas.
Una persona entiende conexión y otra confirmación.
Añade textos que distingan ambos datos.
Decide qué representa cada componente y comprueba que se entiende.
App Inventor 2: Repaso a la Interfaz de Diseño
Puedes ver el vídeo poco a poco. Puedes pararlo. Busca una idea que hayas leído en este apartado. Después prueba el ejemplo.
El vídeo tiene el idioma de su autor. Puedes usar los subtítulos disponibles. También puedes seguir la explicación escrita.
- Describe público, tarea e información necesaria en Google Docs.
- Dibuja Control, Ajustes, mensajes y navegación en diagrams.net.
- Coloca controles claros y estado con texto en el Diseñador de App Inventor.
¿En qué dato se apoya el mensaje de estado?
3.2. Conecta cada evento con su estado
Aprende y practica
Una app responde a hechos que activan instrucciones.
Pulsar Aplicar, iniciar una pantalla y recibir una respuesta son eventos.
Cada evento tiene un manejador con los bloques de respuesta.
La posición de los bloques en el editor no ordena una ejecución continua de toda la app.
Las acciones se relacionan mediante datos que quedan en variables compartidas.
Para comprender la app hay que saber qué evento lee cada dato.
También hay que saber cuál puede modificarlo.
El texto introducido, el nivel solicitado y el último confirmado son datos distintos.
Representan momentos diferentes de la petición.
Validar comprueba si la entrada es aceptable.
No demuestra que el dispositivo haya ejecutado la orden.
El estado de comunicación aporta otra información.
La petición puede estar pendiente, confirmada o sin respuesta.
Sin respuesta se conserva el último valor conocido.
Ese valor no se presenta como una confirmación nueva.
Cambiar de vista tampoco demuestra qué ocurrió en el dispositivo.
Un procedimiento reúne una tarea bajo un nombre para reutilizarla.
Puede presentar los datos actuales en las etiquetas.
Varios eventos pueden llamarlo y evitar versiones distintas del mismo mensaje.
El procedimiento solo será correcto si usa los datos adecuados.
El mapa de eventos y variables permite seguir esas relaciones.
Si dos eventos modifican la misma variable, importa la responsabilidad de cada uno.
Navegar o reiniciar no debe transformar información antigua en una confirmación nueva.
- Evento
- Instrucciones
- Dato
- Presentación
Volver de Ajustes muestra lo escrito como confirmado.
La navegación usa un dato equivocado.
Volver debe presentar datos conocidos.
Aplicar inicia la petición.
Un procedimiento común ayuda si sus datos tienen significado claro.
App Inventor 3.2: Mi primera App (Bloques)
Puedes ver el vídeo poco a poco. Puedes pararlo. Busca una idea que hayas leído en este apartado. Después prueba el ejemplo.
El vídeo tiene el idioma de su autor. Puedes usar los subtítulos disponibles. También puedes seguir la explicación escrita.
- Relaciona Initialize, Aplicar y Volver con sus datos en diagrams.net.
- Separa petición, confirmación y comunicación en variables de App Inventor.
- Crea un procedimiento de presentación y prueba que navegar no confirma órdenes.
¿Qué cambia al pedir y qué espera una respuesta válida?
3.3. Comprueba el dato antes de usarlo
Aprende y practica
Validar es comprobar una entrada antes de cambiar el sistema.
Revisa si hay contenido, si es numérico y si está entre 0 y 100.
Una casilla vacía no significa cero.
«Alto» no es un número y 101 queda fuera del intervalo.
Explica con el mensaje qué debe corregir la persona.
Define si admites decimales y cómo se escriben.
Combina comprobación numérica y comparaciones en App Inventor.
Prueba vacío, letras, -1, 0, 100, 101 y tu caso decimal.
Comprueba que el error no cambia el último valor confirmado.
Aceptar el dato todavía no confirma su ejecución.
- Texto
- Número
- Intervalo
- Petición
El último nivel confirmado es 25.
Una persona escribe «mucho».
La alerta no basta si el programa cambia 25 por cero.
Comprueba mensaje y memoria.
Después prueba un número válido para comprobar que puede corregirse.
- Define rango, decimales y mensajes en Google Docs.
- Programa la validación antes de cambiar la petición en App Inventor.
- Prueba seis casos y el decimal y registra mensaje y valor conservado en Google Docs.
¿Una casilla vacía expresa lo mismo que escribir 0?
3.4. Guarda y recupera una preferencia
Aprende y practica
La memoria puede durar una ejecución o mantenerse entre aperturas de la app.
Una variable conserva información mientras el programa funciona.
Al iniciar de nuevo recibe sus valores de inicialización.
TinyDB ofrece persistencia local entre ejecuciones.
Guarda un valor asociado a una etiqueta y permite recuperarlo después.
La preferencia de tamaño de texto permite estudiar esa continuidad.
No necesita claves ni datos personales.
La etiqueta identifica la información guardada y no el componente que cambia de aspecto.
StoreValue guarda el valor.
GetValue lo recupera.
Si la etiqueta no existe, GetValue devuelve el valor por defecto previsto.
El panel usa CR2S03_texto para guardar y para recuperar.
Los dos pasos deben referirse a la misma información.
Después se aplica la preferencia a los textos previstos.
Guardar, recuperar y presentar son responsabilidades distintas.
El dato puede recuperarse bien y el tamaño de una etiqueta seguir sin actualizarse.
Cambiar de Control a Ajustes durante la ejecución no demuestra persistencia.
La variable podría seguir conservada en esa ejecución.
El primer inicio sin preferencia permite comprobar el valor por defecto.
Guardar, cerrar y abrir permite comprobar la recuperación posterior.
En AI Companion, proyectos distintos pueden compartir TinyDB.
No se borran indiscriminadamente datos de otros trabajos.
TinyDB no crea cuentas ni sincroniza dispositivos.
Restaurar una preferencia no demuestra el estado actual de un aparato.
Una confirmación guardada sigue siendo el último dato conocido.
- Preferencia
- Etiqueta
- TinyDB
- Reabrir
- Aplicar
La app recupera «texto grande», pero solo cambia un botón.
Guardar y recuperar funcionaron.
Falta aplicar la preferencia a otros textos.
Comprueba los tres pasos por separado.
Prueba también el valor por defecto del primer inicio.
Tutorial App Inventor 2 Base de datos
Puedes ver el vídeo poco a poco. Puedes pararlo. Busca una idea que hayas leído en este apartado. Después prueba el ejemplo.
El vídeo tiene el idioma de su autor. Puedes usar los subtítulos disponibles. También puedes seguir la explicación escrita.
- Guarda una preferencia con StoreValue y CR2S03_texto en App Inventor.
- Recupera con GetValue y un valor por defecto en Initialize y aplica el tamaño.
- Registra primer inicio, navegación y nueva apertura en Google Docs sin borrar datos ajenos.
¿Cómo pruebas que el dato sigue después de cerrar la app?
3.6. Prueba respuesta y falta de respuesta
Aprende y practica
Responde o No responde representa la confirmación del simulador.
Ese selector no conecta Bluetooth ni WiFi.
Tampoco demuestra una acción física.
Solo una respuesta válida permite actualizar el valor confirmado.
Sin respuesta muestra la duda y el último valor conocido.
La versión mínima no necesita una espera de red real.
Prueba dato válido, inválido, respuesta, falta de respuesta y persistencia.
Pide a otra pareja una tarea sin ayuda inicial y registra dudas concretas.
Esa prueba no certifica accesibilidad universal.
Corrige una duda y exporta el .aia con el entorno y los límites de la simulación.
- Petición
- Respuesta o ausencia
- Estado
- Comprensión
No responde conserva el último nivel y muestra incertidumbre.
Otra pareja cree que significa apagado.
Las variables pueden estar bien y el mensaje confundir.
Aclara que es el último dato conocido.
Repite la prueba con usuarios.
- Prueba cuatro situaciones de petición y respuesta en App Inventor.
- Registra en Google Docs cómo otra pareja aplica un nivel y consulta ajustes sin ayuda.
- Corrige una dificultad, repite la tarea y exporta el .aia de App Inventor.
¿Usar Responde demuestra que hay un aparato conectado?
3.7. Sigue la petición de principio a fin
Aprende y practica
Sigue entrada, validación, petición, respuesta y presentación.
Cada parte tiene una responsabilidad distinta.
Un fallo visible puede empezar en una variable, evento o etiqueta.
Predice y observa una parte cada vez.
Registra síntoma, posible causa, cambio y prueba repetida.
Dos peticiones rápidas pueden confundir la relación con sus respuestas.
Puedes permitir una sola petición pendiente en el prototipo.
Una conexión más compleja necesitaría identificar peticiones.
A01 incluye diseño, cuatro pruebas y una microapp ejecutada.
A02 incluye cuatro casos, memoria, navegación, accesibilidad y mejora con explicación individual.
- Entrada
- Validación
- Petición
- Respuesta
- Mensaje
Se piden dos niveles antes de recibir respuesta.
Una respuesta antigua se confunde con la petición nueva.
No es un error de intervalo.
Una sola petición pendiente simplifica la prueba.
Explica esa decisión y su límite.
- Sigue una petición y sus datos en diagrams.net.
- Investiga un fallo en una copia de App Inventor y cambia una parte.
- Documenta reparación, prueba y predicción individual en Google Docs.
¿Cómo sabes a qué petición pertenece una respuesta?
3.8. Comprende cómo llegaría una respuesta real
Aprende y practica
Asíncrono significa que el resultado llega en otro momento.
Web separa iniciar la petición de recibir GotText.
TimedOut informa de que terminó la espera configurada.
El selector de esta unidad no usa una red real.
Recibir texto no demuestra que una orden se haya ejecutado.
Comprueba relación con la petición y confirmación válida.
La ampliación física necesita interfaz, mensajes y pruebas adicionales.
Define qué envías, qué aceptas y qué ocurre si falta respuesta.
Consulta una duda concreta y usa texto si no necesitas los vídeos opcionales.
Guarda .aia y decisiones para adaptar datos y validación a otra necesidad.
- Petición
- Espera
- Respuesta o falta
- Comprobar
- Informar
Get inicia una petición y GotText recibe después.
Dibuja dónde llegaría una respuesta verificada.
No necesitas copiar un servicio ajeno.
El mensaje pendiente ayuda a entender la espera aunque uses un selector.
- Consulta GotText y TimedOut en la referencia Web.
- Compara respuesta real y selector en diagrams.net.
- Explica una adaptación y sus nuevas validaciones y pruebas en Google Docs.
¿Cualquier mensaje recibido confirma la orden?
Tu proyecto y tus entregas
A01 · Diseña la solución
- Crea CR2-S03_panel_A01_Apellidos con necesidad y público en Google Docs.
- Dibuja vistas, navegación, eventos, datos y validación en diagrams.net.
- Define rango, decimales y estados y prepara cuatro pruebas y una de accesibilidad.
- Ejecuta una microapp con validación, TinyDB y respuesta simulada en App Inventor.
- Añade predicción, resultado, fuentes y aportaciones individuales.
Qué debes entregar
- Dossier con vistas, eventos y datos.
- Microproyecto .aia con validación, memoria y simulación identificada.
- Cuatro pruebas previstas, accesibilidad, microprueba realizada y explicación individual.
Haz tu copia en Documentos de Google · Ver la plantilla vacía
A02 · Panel móvil de control accesible
- Programa vistas, validación, diálogo y mensajes coherentes en App Inventor.
- Prueba validación con vacío, letras, -1, 0, 100 y 101, respuesta, falta de respuesta y memoria al reabrir.
- Pide a otra pareja aplicar un nivel y usar Ajustes sin ayuda y registra dificultades.
- Corrige un fallo, repite la prueba y explica mejora y límites simulados.
- Entrega CR2-S03_panel con .aia, instrucciones, pruebas, fuentes y explicación individual.
Qué debes entregar
- .aia con dos vistas, navegación, validación y TinyDB.
- Cuatro casos y uso accesible con diálogo y valor por defecto.
- Fallo reparado y mejora con explicación individual de petición y confirmación.
Haz tu copia en Documentos de Google · Ver la plantilla vacía
Revisa antes de entregar
- Relaciono control, evento y datos.
- Rechazo errores sin cambiar el último confirmado.
- Muestro cuando falta respuesta.
- Recupero la preferencia al reabrir.
- Cancelar y volver no inventan confirmaciones.
- Pruebo una mejora con otra pareja.
Plantillas y archivos
Abre la plantilla vacía de A01 o A02. Haz tu copia en Documentos de Google. Guarda también tu programa o proyecto editable.
La plantilla sirve para organizar tu trabajo. Mira qué pide esta unidad. Puedes quitar un campo si no lo necesitas. Haz una copia. No escribas sobre el modelo. No publiques tus respuestas. Compártelas como indique tu docente.
A01 · Diseña la solución
Haz tu copia en Documentos de Google · Ver la plantilla vacía
- Dossier con vistas, eventos y datos.
- Microproyecto .aia con validación, memoria y simulación identificada.
- Cuatro pruebas previstas, accesibilidad, microprueba realizada y explicación individual.
A02 · Panel móvil de control accesible
Haz tu copia en Documentos de Google · Ver la plantilla vacía
- .aia con dos vistas, navegación, validación y TinyDB.
- Cuatro casos y uso accesible con diálogo y valor por defecto.
- Fallo reparado y mejora con explicación individual de petición y confirmación.
Rúbricas de clase
Aquí están las rúbricas de clase. Cada rúbrica explica cómo se valora una entrega. Puedes pedir ayuda para entender una palabra.
Consultar la rúbrica de A01
Diseño y microprueba
CYR.2.2.2 Arquitectura de la app y estado confirmado
Entender el funcionamiento interno de las aplicaciones móviles y cómo se construyen, dando respuesta a las posibles demandas del escenario a resolver.
Evidencia. Boceto, microapp con validación, TinyDB y respuesta externa simulada identificada.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | Confunde texto introducido, solicitud y confirmación y no explica un evento. |
| 3–4,9 | Hay botones, pero anuncia confirmado al pulsar o confunde almacenamiento local con estado del dispositivo. |
| 5–6,9 | Relaciona interfaz, eventos, lógica y TinyDB en una microapp. Distingue solicitud, respuesta simulada y último valor confirmado para la necesidad elegida. |
| 7–8,9 | Prueba respuesta tardía y reapertura y explica qué dato persiste y qué no puede afirmarse actual. |
| 9–10,0 | Propone una organización alternativa de eventos y justifica cómo evitar respuestas fuera de contexto. |
CYR.2.2.3 Adaptar y generalizar soluciones móviles
Conocer y resolver la variedad de problemas posibles desarrollando una aplicación móvil y generalizando las soluciones.
Evidencia. Necesidad del panel, validación ejecutada y cuatro pruebas previstas.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | No relaciona las funciones del panel con el escenario ni identifica entradas admitidas. |
| 3–4,9 | Elige funciones, pero no distingue vacío, no numérico y fuera de intervalo. |
| 5–6,9 | Resuelve una parte de la necesidad con la microapp, define validación y anticipa cuatro pruebas y una comprobación de uso accesible. |
| 7–8,9 | Reutiliza una regla de validación en otro campo y explica sus límites. |
| 9–10,0 | Compara dos soluciones móviles para el escenario y justifica qué patrón puede generalizarse. |
CYR.2.2.1 Algoritmo de control y colaboración
Conocer y resolver la variedad de problemas posibles, desarrollando un programa informático y generalizando las soluciones, tanto de forma individual como trabajando en equipo, colaborando y comunicándose de forma adecuada.
Evidencia. Diagrama de validación, microprueba y explicación de contribuciones.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | No puede seguir el paso de entrada a decisión ni identificar una aportación propia. |
| 3–4,9 | Describe acciones sueltas, pero no ordena validar solicitar y confirmar ni revisa resultados. |
| 5–6,9 | Ordena el algoritmo, ejecuta una microprueba, contrasta una predicción y explica cómo su aportación se coordina con la pareja. |
| 7–8,9 | Revisa una condición tras detectar un caso inválido y expresa un procedimiento reutilizable. |
| 9–10,0 | Argumenta entre dos algoritmos de actualización y prueba el caso que permite distinguirlos. |
Consultar la rúbrica de A02
Producto pruebas y mejora
CYR.2.2.2 Arquitectura de la app y estado confirmado
Entender el funcionamiento interno de las aplicaciones móviles y cómo se construyen, dando respuesta a las posibles demandas del escenario a resolver.
Evidencia. Proyecto editable, validación, persistencia, navegación y estados de comunicación.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | La app no permite completar el control o presenta simulación como comunicación real. |
| 3–4,9 | Funciona con entrada válida, pero confirma sin respuesta o recupera una preferencia como si fuera estado actual. |
| 5–6,9 | Implementa interfaz, lógica y persistencia, distingue pendiente confirmado y sin respuesta y explica sus eventos y la simulación. |
| 7–8,9 | Corrige una actualización prematura o una preferencia no aplicada y verifica recorrido y reapertura. |
| 9–10,0 | Adapta el panel a otra entrada o respuesta y justifica coherencia de estado, navegación y dato persistido. |
CYR.2.2.3 Adaptar y generalizar soluciones móviles
Conocer y resolver la variedad de problemas posibles desarrollando una aplicación móvil y generalizando las soluciones.
Evidencia. Panel probado, cuatro casos, prueba de accesibilidad y adaptación explicada.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | El panel no resuelve la necesidad y no discrimina entradas incompatibles. |
| 3–4,9 | Admite datos, pero bloquea casos no válidos sin orientar o no permite completar el recorrido. |
| 5–6,9 | Resuelve el escenario, valida entradas, ejecuta los cuatro casos y prueba accesibilidad, justificando sus decisiones. |
| 7–8,9 | Adapta la validación o navegación a otro caso y comprueba que conserva la respuesta esperada. |
| 9–10,0 | Resuelve una variante nueva y explica una solución general que se puede reutilizar sin copiar mensajes erróneos. |
CYR.2.2.1 Algoritmo de control y colaboración
Conocer y resolver la variedad de problemas posibles, desarrollando un programa informático y generalizando las soluciones, tanto de forma individual como trabajando en equipo, colaborando y comunicándose de forma adecuada.
Evidencia. Código, pruebas de estado, incidencia y modificación individual.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | No explica la lógica del panel ni puede realizar una modificación coherente. |
| 3–4,9 | Cambia mensajes sin relacionar el fallo con evento o variable y no puede atribuir decisiones propias. |
| 5–6,9 | Resuelve el control programado, documenta una corrección y explica o modifica individualmente una decisión, colaborando en la revisión. |
| 7–8,9 | Aísla el evento responsable del fallo y transfiere la solución a otro estado del panel. |
| 9–10,0 | Resuelve un caso nuevo de orden de respuestas y comunica una regla general con evidencia y revisión compartida. |
Vídeos y fuentes
App inventor: primeros pasos
Puedes ver el vídeo poco a poco. Puedes pararlo. Busca una idea que hayas leído en este apartado. Después prueba el ejemplo.
El vídeo tiene el idioma de su autor. Puedes usar los subtítulos disponibles. También puedes seguir la explicación escrita.
Puedes aprender más
- MIT App Inventor: User Interface
- MIT App Inventor: Math Blocks
- MIT App Inventor: Storage, TinyDB
- MIT App Inventor: Connectivity, Web
- W3C WAI: Labeling Controls
Contenido revisado en octubre de 2026.