Volver a tu curso / CR1-S04
Computación y Robótica · 1.º ESO · Con pictos
Apps que ayudan
Una app útil ayuda a realizar una tarea.
Sus respuestas deben entenderse.
Trabajarás en pareja durante nueve sesiones con MIT App Inventor.
Usarás acceso del centro y datos ficticios.
Relacionarás interfaz, evento, dato y resultado.
Tu misión
Crea «Mi ayudante de aula».
Incluye dos pantallas o vistas, botones, variable y condición.
La ruta inicial usa Inicio y Ayuda en Screen1.
Añade lista o recordatorio y una lectura marcada como simulada.
Entrega .aia y guía.
Prueba recuento y navegación.
Corrige y comprueba una mejora con otra pareja.
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.
4.1. Decide a quién ayuda tu app
Aprende y practica
Una app combina interfaz y reglas para una tarea.
La interfaz incluye controles, textos y mensajes.
Describe la necesidad antes de elegir botones.
Preparar materiales es una tarea.
Tener muchas pantallas no explica por sí solo su utilidad.
Dibuja abrir, actuar y revisar el resultado.
Un requisito indica un comportamiento comprobable.
Decir bonita no define una respuesta esperada.
Los mensajes explican qué hacer y qué ha ocurrido.
Usa texto además de color.
Cuida letra, etiquetas y navegación desde el boceto.
Investiga una tarea ficticia sin recopilar nombres ni hábitos personales.
- Persona y tarea
- Necesidad
- Recorrido
- Requisito
Mira este ejemplo
Una app ficticia muestra «Sí» sin pregunta.
Otra pareja no sabe qué confirma.
Añadir colores no explica la acción.
El equipo cambia la etiqueta y añade un mensaje de resultado.
Después pide la misma tarea sin señalar botones.
Así comprueba si se entiende mejor.
Ahora hazlo tú
- En Google Docs describe una dificultad de aula. Consulta a otra pareja sin registrar datos personales.
- Dibuja inicio, acción y resultado en diagrams.net. Escribe dos requisitos comprobables.
- Revisa etiquetas y mensajes. Deben entenderse con texto además de color.
Comprueba qué has aprendido¿Qué tarea resuelve el botón y cómo comprobarías que ayuda?
4.2. Relaciona botones y bloques
Aprende y practica
El Diseñador coloca componentes y prepara propiedades.
Las propiedades incluyen texto, tamaño y disposición.
Bloques programa respuestas.
Un evento indica un hecho que inicia instrucciones.
Click ocurre al pulsar un botón.
Una etiqueta muestra información.
Una CheckBox conserva marcado o desmarcado.
Componentes parecidos pueden tener funciones distintas.
Cambiar texto inicial no programa una respuesta al botón.
Los nombres internos ayudan a leer bloques y los textos visibles ayudan al usuario.
Un evento puede cambiar la propiedad de otro componente.
Prueba la ejecución en emulador o dispositivo y no solo el dibujo del Diseñador.
- Pulsación
- Click
- Bloques
- Propiedad nueva
- Mensaje
Mira este ejemplo
Una etiqueta empieza con «Pendiente».
Añadir un botón «Revisar» no cambia ese texto durante el uso.
Necesitas unir el evento del botón con Text de la etiqueta.
Distingue componente, valor inicial y respuesta a una acción.
Revisa cada parte en el lugar correspondiente del proyecto.
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.
Ahora hazlo tú
- Crea una prueba en App Inventor con botón, etiqueta y CheckBox. Usa nombres internos claros y textos comprensibles.
- Programa un evento del botón para cambiar la etiqueta. Predice y prueba en el emulador o dispositivo preparado.
- En Google Docs identifica componente, propiedad, evento y resultado. Guarda una primera exportación .aia.
Comprueba qué has aprendido¿En qué se diferencian nombre interno, texto visible y evento del botón?
4.3. Cuenta lo preparado sin duplicar
Aprende y practica
El estado de una app describe su situación actual.
Las casillas de una lista indican qué materiales están preparados.
Una variable puede conservar el recuento durante la ejecución.
Pulsar Comprobar inicia una acción.
La pulsación no representa un material nuevo.
Si las casillas no cambian, otra comprobación debe describir la misma situación.
Contar pulsaciones conserva una historia de acciones.
Contar casillas marcadas responde a una pregunta sobre el presente.
Esa diferencia indica qué dato necesitamos calcular.
El recuento actual puede empezar desde cero en cada comprobación.
Después se revisan las casillas marcadas.
El resultado depende del estado actual y no del número de pulsaciones.
Los pendientes dependen del total de elementos y de los preparados.
Una condición distingue si no falta nada o si queda algo pendiente.
Desmarcar también cambia el estado.
La app debe reflejar esa rectificación de forma coherente.
La lista y su cálculo están relacionados.
Añadir un material afecta a los componentes y al recuento.
También afecta a la condición de completo, las instrucciones y las pruebas.
Revisar esas relaciones conecta lo que promete la pantalla con los bloques.
Esta coherencia se estudia durante el uso de la app.
Una variable en memoria no garantiza conservar datos después de cerrar.
Guardar permanentemente sería otra función con decisiones y pruebas propias.
- Casillas
- Contar desde cero
- Total y preparados
- Pregunta
- Resultado
Mira este ejemplo
Una prueba tiene carpeta y tarjeta.
Solo carpeta está marcada.
Comprobar dos veces debe describir el mismo estado.
No hay dos carpetas preparadas.
Si aumenta el número, el cálculo acumula comprobaciones.
Después desmarca carpeta.
Así compruebas que la app refleja también las rectificaciones.
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.
Ahora hazlo tú
- En Google Docs prepara ninguna, algunas y todas las casillas. Añade Comprobar repetido y desmarcar.
- Programa recuento con variable y condición en App Inventor. Predice cada caso y prueba en emulador.
- Propón un material más. Señala todo lo que cambiaría. Prueba una copia sin cambiar la entrega principal.
Comprueba qué has aprendido¿Por qué dos pulsaciones no significan dos materiales preparados?
4.4. Navega entre Inicio y Ayuda
Aprende y practica
Una vista organiza una zona de la interfaz para una finalidad.
Inicio puede mostrar la lista y el resultado.
Ayuda puede explicar cómo utilizarlos.
La ruta inicial usa dos disposiciones verticales dentro de Screen1.
Cada disposición agrupa componentes.
Su propiedad Visible indica si se muestra.
Cambiar de vista cambia la presentación de la misma pantalla.
Así la atención se centra en la tarea o en su explicación.
No hace falta mostrar todos los elementos a la vez.
Ir a Ayuda muestra Ayuda y oculta Inicio.
Volver realiza los dos cambios contrarios.
Ocultar una zona sin mostrar otra puede dejar la pantalla aparentemente vacía.
Mostrar ambas puede dificultar saber dónde estamos y qué hacer.
El regreso debe ser fácil de encontrar.
La ayuda explica tarea, mensajes y límite del dato simulado.
Debe permitir continuar después de consultarla.
Ocultar una vista mantiene sus componentes y variables en la misma ejecución.
Una casilla puede seguir marcada al regresar.
El componente no se ha creado de nuevo.
Eso explica conservar el estado durante el uso.
No demuestra conservarlo después de cerrar completamente la app.
Ocultar no guarda en almacenamiento permanente.
Dibujar y probar ida y vuelta permite comprobar navegación y estado.
Un camino sin salida es un fallo de funcionamiento, como un recuento incorrecto.
- Inicio
- Ayuda
- Vista Ayuda
- Volver
- Inicio con sus datos
Mira este ejemplo
Una app oculta la lista para mostrar instrucciones.
Al volver conserva una casilla marcada.
El componente sigue siendo el mismo.
Eso explica conservarla durante el uso.
No demuestra guardarla tras cerrar.
Para esa conclusión haría falta otro mecanismo y una prueba diferente.
Ahora hazlo tú
- Dibuja Inicio, Ayuda, ida y regreso en diagrams.net. Indica qué disposición se ve en cada caso.
- Construye las vistas en Screen1 de App Inventor. Comprueba que no queda vacío ni se muestran ambas zonas juntas.
- Marca una casilla, visita Ayuda y vuelve. En Google Docs explica qué se conserva y qué falta probar tras cerrar.
Comprueba qué has aprendido¿Qué diferencia hay entre volver de Ayuda y cerrar completamente la app?
4.5. Reconoce un dato simulado
Aprende y practica
Un sistema conectado puede llevar datos del sensor a una app.
La cadena obtiene, envía, recibe e interpreta información.
Nuestro botón cambia una variable simulada.
La cifra no procede de una conexión física.
Muestra DATO SIMULADO junto al valor.
Un dibujo o botón Conectar no demuestra comunicación.
La simulación prepara entradas conocidas para probar mensajes.
20 y 80 son valores didácticos sin unidad física.
Si usas umbral, explica los casos y la igualdad.
Una conexión real necesitaría comunicación y formato adecuados.
También necesitaría responder si no llega información sin llamar nueva a una lectura antigua.
Dibuja la cadena y marca qué partes has construido y cuáles representas.
- Variable
- Dato simulado
- Regla
- Mensaje
- Límite
Mira este ejemplo
Un panel cambia una cifra con un botón.
Alguien cree que mide el aula.
El equipo explica que viene de una variable y añade la etiqueta simulada junto al valor.
Puede probar la regla del aviso.
No ha demostrado precisión del sensor ni recepción desde una placa.
Ahora hazlo tú
- En App Inventor prepara una variable que alterne 20 y 80. Muestra DATO SIMULADO con el valor.
- Predice y prueba mensaje o condición. Si usas umbral, prueba igualdad. Anota el origen en Google Docs.
- Dibuja sensor, placa, comunicación y app en diagrams.net. Marca lo construido y lo representado. Explica qué faltaría si no llegan datos reales.
Comprueba qué has aprendido¿Has probado la regla o una conexión real? ¿Qué demuestra tu ensayo?
4.6. Comprueba uso y funcionamiento
Aprende y practica
Una prueba funcional comprueba una regla de la app.
Una prueba de uso observa si otra persona entiende la tarea.
Quien construye ya conoce los botones.
Pide una tarea a otra pareja sin señalar dónde pulsar.
Anota dudas, mensajes interpretados y regreso encontrado.
Describe la dificultad del diseño sin culpar a la persona.
Relaciona la mejora con etiqueta, cálculo o navegación.
Repite la tarea y comprueba otra función después del cambio.
Exporta e importa .aia para conservar componentes y bloques.
Una captura muestra un estado y .aia no es una app compilada para instalar.
A01 reúne diseño y microapp y A02 producto, pruebas y mejora.
Incluye fuentes, permisos, datos mínimos y explicación individual en ambas.
- Tarea
- Duda observada
- Cambio
- Repetir tarea
- Revisar funciones
Mira este ejemplo
Una persona busca Ayuda arriba.
El botón está después de un texto largo.
El equipo anota la duda y cambia posición y etiqueta en una copia.
Repite la tarea.
Comprueba también el recuento.
Mejorar navegación no demuestra por sí solo que el cálculo siga correcto.
Ahora hazlo tú
- En Google Docs prepara recuento, pulsación repetida, rectificación, Ayuda/Volver y dato simulado. Anota esperado y observado.
- Otra pareja realiza una tarea sin guía en el emulador. Registra una dificultad. Cambia una parte y repite tarea y prueba funcional.
- Exporta .aia e impórtalo en el entorno preparado de App Inventor. Guarda instrucciones, fuentes y explicación individual.
Comprueba qué has aprendido¿Qué duda has observado y qué mejora la responde? ¿Qué conserva .aia que no conserva una captura?
Tu proyecto y tus entregas
A01 · Diseña la solución
- Crea CR1-S04_A01_Apellidos en Google Docs. Explica necesidad, destinatario y requisitos. Usa datos ficticios mínimos.
- Dibuja dos vistas y navegación en diagrams.net. Relaciona componentes, propiedades, eventos, variable, condición y botones.
- Explica recuento, rectificación y dato simulado. Prepara al menos tres pruebas de usuario y sus resultados esperados.
- Incluye microapp ejecutada de 03 o 04 con archivo y observaciones. Anota fuentes, permisos, revisión y aportación individual.
Qué debes entregar
- Dossier, boceto, mapa editable y PNG, datos mínimos y algoritmo.
- Microapp .aia ejecutada con predicción y resultado de un evento.
- Tres pruebas previstas, fuentes, permisos, aportaciones y explicación de interfaz, evento, dato y respuesta.
Haz tu copia en Documentos de Google · Ver la plantilla vacía
A02 · Mi ayudante de aula
- Construye la app revisada con dos vistas, botones, recuento, variable y condición. Marca la lectura como simulada y explica su límite.
- En CR1-S04_A02_Apellidos prueba ninguna, una y tres casillas. Añade desmarcar, Comprobar repetido y Ayuda/Volver conservando estado durante el uso.
- Prueba con otra pareja. Anota incidencia, causa, corrección y nueva prueba. Comprueba una mejora sin romper cálculo ni navegación.
- Exporta CR1-S04_app_Apellidos.aia y comprueba recuperarlo. Entrega guía, registro y fuentes. Cada integrante explica un evento, predice y realiza o describe un cambio.
Qué debes entregar
- Proyecto .aia y guía con tarea, navegación, simulación y límites.
- Pruebas de recuento, rectificación, repetición, navegación y simulación. Incluye esperado y observado.
- Corrección, mejora, recursos permitidos y explicación individual. Consulta las rúbricas de la página.
Haz tu copia en Documentos de Google · Ver la plantilla vacía
Revisa antes de entregar
- Relaciono botones y componentes con una necesidad.
- Distingo propiedad, evento, variable y respuesta. Sigo una pulsación en los bloques.
- Calculo el estado actual sin duplicar materiales y permito corregir.
- Explico conservación durante el uso, límites de persistencia y dato simulado.
- Otra pareja usa la app y compruebo una mejora. Recupero el proyecto. Son ayudas de autoevaluación y no criterios oficiales nuevos.
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, boceto, mapa editable y PNG, datos mínimos y algoritmo.
- Microapp .aia ejecutada con predicción y resultado de un evento.
- Tres pruebas previstas, fuentes, permisos, aportaciones y explicación de interfaz, evento, dato y respuesta.
A02 · Mi ayudante de aula
Haz tu copia en Documentos de Google · Ver la plantilla vacía
- Proyecto .aia y guía con tarea, navegación, simulación y límites.
- Pruebas de recuento, rectificación, repetición, navegación y simulación. Incluye esperado y observado.
- Corrección, mejora, recursos permitidos y explicación individual. Consulta las rúbricas de la página.
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.1.2.1 Algoritmo reutilizable y trabajo en pareja
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. Esquema de recuento, microapp ejecutada y aportación individual al diseño.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | El recuento no representa el problema y no puede explicar una parte propia. |
| 3–4,9 | Relaciona casillas y contador, pero acumula pulsaciones o no distingue lo aportado por cada integrante. |
| 5–6,9 | Expresa el recuento actual, ejecuta una microprueba y explica su aportación. Revisa la propuesta de su pareja con una razón. |
| 7–8,9 | Adapta el recuento a una lista de otra longitud y señala qué pasos son generales. |
| 9–10,0 | Comprueba la adaptación con casos extremos y explica al equipo cómo evitar duplicar lógica. |
CYR.1.2.2 Aplicación móvil ajustada a una necesidad
Conocer y resolver la variedad de problemas posibles desarrollando una aplicación móvil, particularizando las soluciones.
Evidencia. Boceto de vistas, botones, datos mínimos y microapp funcional de 03 o 04.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | El boceto no permite realizar la tarea móvil y no identifica la función de los componentes. |
| 3–4,9 | Hay pantallas, pero faltan eventos o sus acciones no responden a la necesidad elegida. |
| 5–6,9 | Construye una microapp con componentes y eventos adecuados y relaciona cada botón con la tarea y los datos necesarios. |
| 7–8,9 | Prueba el recorrido con otra persona y particulariza una instrucción o componente según su dificultad. |
| 9–10,0 | Adapta la solución a otra lista o destinatario y justifica los cambios de interfaz sin añadir datos innecesarios. |
CYR.1.5.1 Funcionamiento interno y uso respetuoso de la app
Conocer la construcción de aplicaciones informáticas y web, entendiendo su funcionamiento interno, de forma segura, responsable y respetuosa.
Evidencia. Relación interfaz evento dato respuesta y revisión de recursos del microprototipo.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | Atribuye la respuesta al aspecto del botón sin identificar el evento o usa datos personales innecesarios. |
| 3–4,9 | Reconoce un evento, pero no lo relaciona con la variable y el mensaje o deja recursos sin origen. |
| 5–6,9 | Explica interfaz, evento, variable y respuesta en la microapp, usa datos ficticios y registra origen y permiso de los recursos utilizados. |
| 7–8,9 | Justifica una decisión de minimización o mensaje accesible y la comprueba en el prototipo. |
| 9–10,0 | Compara otra forma de organizar la interacción y justifica su efecto en comprensión y privacidad. |
Consultar la rúbrica de A02
Producto pruebas y mejora
CYR.1.2.1 Algoritmo reutilizable y trabajo en pareja
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. App, pruebas repetidas del recuento y explicación de una variante.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | La lógica no calcula los elementos pendientes y no puede seguir una pulsación. |
| 3–4,9 | Calcula un caso, pero falla al pulsar dos veces o cambiar el número de elementos. |
| 5–6,9 | Resuelve el recuento, repite pruebas y corrige un fallo. Cada integrante explica una decisión y colabora en la mejora. |
| 7–8,9 | Generaliza el recuento a una lista distinta y verifica ninguna, algunas y todas las casillas. |
| 9–10,0 | Resuelve una variante propuesta y justifica la parte reutilizable del algoritmo y la revisión acordada con la pareja. |
CYR.1.2.2 Aplicación móvil ajustada a una necesidad
Conocer y resolver la variedad de problemas posibles desarrollando una aplicación móvil, particularizando las soluciones.
Evidencia. Proyecto App Inventor editable y pruebas de recuento navegación y lectura simulada.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | La app no permite completar la tarea o solo se entregan imágenes sin funcionamiento revisable. |
| 3–4,9 | Funciona parcialmente, pero la navegación bloquea la tarea o se presenta como conexión real la lectura simulada. |
| 5–6,9 | La app responde a la necesidad, usa componentes y eventos, calcula y permite navegar. Identifica la lectura simulada y prueba con otro usuario. |
| 7–8,9 | Corrige una dificultad de uso observada y comprueba el recorrido completo sin ayuda del autor. |
| 9–10,0 | Particulariza la app para otro destinatario y demuestra que conserva cálculo y navegación, explicando las decisiones de componentes. |
CYR.1.5.1 Funcionamiento interno y uso respetuoso de la app
Conocer la construcción de aplicaciones informáticas y web, entendiendo su funcionamiento interno, de forma segura, responsable y respetuosa.
Evidencia. App revisable, explicación de un evento, mensajes y revisión de privacidad y recursos.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | No explica el funcionamiento interno o difunde información que no necesita el producto. |
| 3–4,9 | La app funciona, pero confunde interfaz y lógica o deja mensajes y recursos sin revisar. |
| 5–6,9 | Explica el recorrido de un evento, conserva archivos editables y aplica mensajes comprensibles, datos mínimos y uso permitido de recursos. |
| 7–8,9 | Detecta y corrige una incoherencia entre interfaz y lógica o una barrera de comprensión y verifica el cambio. |
| 9–10,0 | Transfiere el patrón a otra interacción y justifica qué protege su decisión y qué límite mantiene la simulación. |
Vídeos y fuentes
App Inventor 1: Introducción
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.
App Inventor 3.1: Mi primera App (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.
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 · Variable Blocks
- MIT App Inventor · Layout
- MIT App Inventor · Sharing and Remixing Apps
- MIT App Inventor · Tutorials
Pictogramas: Sergio Palao · ARASAAC · Propiedad del Gobierno de Aragón. Esta adaptación con pictogramas se comparte para uso no comercial bajo CC BY-NC-SA 4.0. Los recursos externos conservan sus respectivas licencias.
Contenido revisado en octubre de 2026.