MIT App Inventor: cualquiera puede crear una aplicación móvil. MIT App Inventor: cualquiera puede crear una aplicación móvil App Inventor Blocks. Conceptos y principios importantes

Hoy en el mercado laboral asistimos a un auténtico boom de especialistas en el campo del desarrollo de aplicaciones para dispositivos móviles. La profesión de desarrollador de aplicaciones móviles se está convirtiendo en una de las más demandadas. Pero, ¿está preparado el sistema educativo para responder a este desafío? Después de todo, para diagnosticar las habilidades de programación y sentar una base sólida de conocimientos y habilidades a tiempo, es necesario comenzar desde la edad escolar temprana.

Hasta hace poco, el problema de enseñar programación a estudiantes de secundaria parecía insoluble, principalmente debido a la falta de una herramienta que, por un lado, fuera bastante fácil de aprender y, por otro, permitiera crear productos verdaderamente valiosos. . Los intentos de enseñar universalmente a los escolares BASIC o Pascal sólo condujeron al hecho de que la materia "informática" era difícil sólo para un círculo muy reducido de estudiantes: aquellos que, debido a características intelectuales, educación familiar o suerte extrema con un maestro, lograron avanzar más que otros en el dominio de la programación. Para la mayoría de los demás escolares, la informática seguía siendo algo inaccesible.

La situación empezó a cambiar a principios de la década de 2000, con la aparición y desarrollo de los lenguajes de programación visual, cuyo buque insignia es el lenguaje Scratch. Este lenguaje ha supuesto una auténtica revolución en la enseñanza escolar de la programación para sistemas operativos de escritorio. Programar en Scratch es tan fácil como armar un rompecabezas infantil. Las declaraciones y procedimientos del lenguaje están representados por bloques de colores. Arrastrándolos y conectándolos creamos programas. Es simplemente imposible cometer un error en la sintaxis de este lenguaje: si los bloques no encajan uno al lado del otro, el rompecabezas simplemente no encajará.

Inventor de aplicaciones

Una extensión natural de este enfoque fue el lenguaje de programación App Inventor, desarrollado por el profesor del Instituto Tecnológico de Massachusetts (MIT), Hal Abelson, en 2010. Se basa en el mismo principio de arrastrar ladrillos visuales y armar un programa a partir de bloques.

La diferencia entre App Inventor y Scratch es que App Inventor no está enfocado al uso de escritorio, sino que está diseñado para crear aplicaciones para un dispositivo móvil: un teléfono inteligente o una tableta con sistema operativo Android. Puede, por ejemplo, "comprender" los datos del acelerómetro de un dispositivo móvil, controlar la cámara integrada, ver cómo se orienta el teléfono en el espacio y mucho más.

App Inventor es una aplicación completamente basada en la nube. Para empezar a programar en él, solo necesitas Internet y un navegador. Puede ir a la página de idiomas usando este enlace. Interfaz en inglés y ruso.

La interfaz del lenguaje de programación MIT App Inventor consta de dos partes principales: diseñador Y editor de bloques.

EN diseñador Construimos nuestra aplicación a partir de elementos: pantallas, botones, celdas, imágenes, sonidos.

EN editor de bloques programamos el comportamiento de estos elementos.

La interfaz de App Inventor es sencilla e intuitiva. Si desea intentar enseñar programación utilizando App Inventor en la escuela, le recomendamos el sitio web appinvent.ru, que contiene materiales de formación para profesores.

Concurso para escolares

Y los escolares que hayan recibido formación en programación utilizando App Inventor en la escuela o de forma independiente pueden participar en un concurso para desarrollar sus propias aplicaciones móviles utilizando App Inventor. El ganador del concurso recibirá una tableta de Samsung. La fecha límite para la presentación de trabajos es el 15 de mayo de 2016.

Inventor de aplicaciones- un entorno de desarrollo visual para aplicaciones de Android que requiere conocimientos mínimos de programación por parte del usuario. Desarrollado originalmente en Google Labs, tras el cierre de este laboratorio fue transferido al Instituto Tecnológico de Massachusetts. En primer lugar marzo 2011 año, el Instituto Tecnológico de Massachusetts lanzó una versión beta pública del proyecto, disponible en el sitio web appinventor.mit.edu.

Este entorno de desarrollo funciona directamente desde el navegador. No es necesario descargar ni instalar nada. El resultado se puede ver en un dispositivo Android. Las aplicaciones listas para usar se pueden colocar en Play Market.

Desde agosto de 2015, App Inventor 2 admite idioma ruso.

En el editor en línea MIT App Inventor 2, las aplicaciones se crean sobre la base de componentes estándar, que son el elemento principal del desarrollo de aplicaciones para Android.

Bloques de App Inventor. Conceptos y principios importantes

Los bloques de App Inventor son herramientas para manipular componentes y parecen rompecabezas.

Los bloques de este diseñador de aplicaciones para Android se dividen en dos grandes grupos según en qué influyen y con qué se relacionan:

directamente relacionado con los componentes
relacionado con la aplicación en su conjunto

Empecemos con bloques que pertenecen a componentes. Se pueden dividir en tres tipos, que se distinguen fácilmente por el color:

1. bloques que describen las propiedades del componente. Son verdes y se ven así:

este bloque denota la propiedad actual del componente. Esta imagen muestra el bloque de color de fondo para el componente de texto TextBox1. Implica obtener un valor existente.

y este establece el valor requerido para el componente (dale a TextBox1 un color de fondo...). “establecer” - establecer. Este tipo de bloque de propiedades podría clasificarse como comandos (controladores), ya que en realidad proporciona un comando para cambiar cualquier propiedad del componente, incluidos los valores de los campos. Sin embargo, los desarrolladores de App Inventor decidieron esto; después de todo, estas también son propiedades.

2. bloques de eventos, es decir, aquellos bloques que monitorean la ocurrencia de un evento en la aplicación, por ejemplo, presionar un botón y luego ejecutar un comando de bloqueo. Están pintados de bronce y lucen así:

este bloque, por ejemplo, realiza una acción cuando se hace clic en un botón (cuando se hace clic en el Botón3, haga...)

3. comando de bloque, en App Inventor este bloque a menudo se denomina controlador. Este bloque especifica lo que se debe hacer con el componente al que pertenece el bloque:

Este bloque en particular solicita datos del temporizador del dispositivo.

El segundo grupo de bloques. relevante para toda la aplicación, está organizado de forma algo diferente.

Para empezar, aquí está su lista de subgrupos:

Bloques lógicos– bloques lógicos
bloques matemáticos– bloques matemáticos
Bloques de texto– bloques de texto
Bloques de listas– bloques para gestionar listas
Bloques de colores– bloques para la gestión del color
Bloques variables– bloques para controlar variables
Bloques de procedimientos– bloques de procedimientos.

Todos ellos, a excepción del bloque de Procedimientos, están integrados en otros bloques. Es decir, no pueden servir como bloque inicial, a diferencia de los bloques de eventos que pertenecen a componentes: todas las acciones se realizan cuando ocurren algunos eventos con los componentes.

Aquí vale la pena hablar más sobre los tipos de “rompecabezas”. Probablemente hayas notado que hay cuatro tipos de acertijos.

Por su forma, resulta bastante obvio que cualquier cadena en una aplicación móvil comienza con el primer tipo. Este es un evento y es bastante lógico que inicie todas las acciones posteriores. Y este tipo no es diferente del adoptado en este diseñador de aplicaciones de Android.

Pero los siguientes dos tipos de bloques, según la tipología de App Inventor, pertenecen a tipos diferentes: propiedades y comandos (handlers), respectivamente. Pero según la forma del rompecabezas y el significado, se podrían clasificar como comandos, ya que fijan la acción. Digamos segundo el rompecabezas que se muestra en la imagen da un comando para asignar un valor específico a un componente, A tercero rompecabezas - llamar a un componente con un valor específico. Además, estos acertijos son “intermedios”, no pueden usarse para completar la cadena.

Y aquí cuatro la especie es valor final, existente o calculado, y finaliza con él las cadenas. Por ejemplo, la cuarta imagen representa el valor actual del componente Clock1.

La empresa de TI convoca un concurso para el desarrollo de aplicaciones móviles para el sistema operativo Android, creadas en el lenguaje de programación App Inventor.

Fechas del Concurso

Recepción e inscripción de trabajos competitivos: del 1 de enero al 15 de mayo de 2017.
Revisión de trabajos por parte del Jurado competitivo - del 15 al 30 de mayo de 2017.
Anuncio de los resultados del concurso el 30 de mayo en el portal del concurso.

Puede aumentar la funcionalidad integrada de App Inventor utilizando tecnologías y extensiones web. Puedes encontrar extensiones de pago y gratuitas en Internet (unas 200 en puravidaapps.com), pero surgen dudas: ¿qué tan difícil es crear la tuya propia, qué pueden hacer y si vale la pena dedicarle tiempo o es mejor? ¿hacer algo más?

Todos los componentes y bloques disponibles en App Inventor están integrados (internos) y las extensiones son externas.

Las funciones integradas proporcionan una funcionalidad interesante para los usuarios novatos, satisfactoria para los experimentados e insuficiente para los programadores. Sin embargo, la mayoría de los usuarios preferirán descargar extensiones ya preparadas en lugar de desarrollarlas. De esto se desprende una simple conclusión: el desarrollo de extensiones puede interesar principalmente a usuarios experimentados y entusiastas. Los principiantes estarán bastante satisfechos con las capacidades integradas y las extensiones disponibles, pero los programadores no están interesados en trabajar con extensiones debido a la necesidad de realizar un doble trabajo. ¿Por qué dedicar tiempo a crear y depurar una extensión de funcionalidad limitada y luego usarla para crear una aplicación de funcionalidad limitada, cuando puedes escribir código inmediatamente en Java, aprovechando todas las características disponibles del IDE de Android Studio y la API de Android?

Crear extensiones para IA no es difícil si tienes cierta experiencia en programación y comprendes los conceptos básicos de la programación orientada a objetos, pero por las razones expuestas anteriormente, solo unos pocos se dedican seriamente a esto. No es práctico escribir extensiones funcionales, pero escribir complementos simples para ampliar la funcionalidad integrada o crear otras nuevas puede ser divertido y útil en términos de práctica. Pero aquí debes decidir el enfoque. Puede seguir el concepto de IA (programación visual) o ampliarlo con elementos de programación de texto.

En pocas palabras, App Inventor es como un iceberg, cuya punta es visible para los usuarios en forma de funcionalidad incorporada, y mucho más está bajo el agua y es inaccesible. Esto se hace específicamente de acuerdo con el propósito de este IDE, que requiere conocimientos mínimos de programación por parte de los usuarios. El modelo de trabajo inherente a App Inventor no está diseñado inicialmente para una mayor funcionalidad. Agregar nuevas propiedades hará que la cantidad de bloques crezca exponencialmente. Por ejemplo, agregar una propiedad de transparencia dará como resultado dos bloques para cada widget (para configurar y devolver el valor). Si hay 5 de estos widgets, entonces la cantidad de bloques aumentará en 10. Agregamos 10 propiedades y el resultado fue 100 bloques. Además de esto, aparecerán nuevos campos de propiedades en el diseñador. En estas circunstancias, el enfoque de “extensiones IDE + simples” parece razonable, pero no para aquellos que prefieren una buena funcionalidad lista para usar sin tener que buscar e instalar complementos.

Establecer individualmente las propiedades de los objetos y especificar una conexión rígida de bloques en la etapa de desarrollo de la aplicación, por un lado, simplifica el desarrollo y evita una gran cantidad de errores, pero conduce a la aparición de aplicaciones estáticas. Si un bloque está unido a otro bloque, entonces es para siempre. Puede cambiar una propiedad o seleccionar otro objeto en tiempo de ejecución de la aplicación solo si esta característica se incluyó inicialmente en la etapa de desarrollo. Para hacer esto, necesita utilizar el acceso indirecto a los objetos. Por ejemplo, puede crear una lista de pares de nombre de objeto-objeto para todos los objetos y luego usarla en funciones para acceder a diferentes objetos. En este caso, el bloque receptor no estará asociado a un objeto específico, sino a una lista de la que se puede obtener el deseado por su clave de nombre.

Si a lo anterior le sumamos las dificultades con la implementación de operaciones grupales, la falta de widgets, métodos y otros matices de la funcionalidad integrada, entonces quedará claro el motivo de la aparición de AppyBuilder, Thunkable, Makeroid, etc. en el que se consigue un aumento de la funcionalidad debido al número de componentes. Más componentes, más bloques. Pero con la ayuda de una extensión, puede aumentar la funcionalidad de manera cualitativa, por ejemplo, usar un bloque para acceder a docenas de propiedades de docenas de objetos. Esto es realmente interesante, ya que complementa la programación visual con elementos textuales para compensar una serie de deficiencias de la funcionalidad de IA incorporada.

¿Aquellos con pocos conocimientos de programación podrán crear extensiones? Sí, la gente sencilla puede hacerlo utilizando el enfoque de “copiar y cambiar”, pero aún se requiere algo de preparación. Sin él, no quedará claro por qué la extensión no se compila y qué está escrito en la pantalla. También hay que decir que parte de la extensión que funciona con objetos de Android es más conveniente de crear y depurar en Android Studio.

El desarrollo de extensiones es adecuado para aquellos que, en principio, están satisfechos con App Inventor, pero les gustaría agregar, mejorar y simplificar algo, y al mismo tiempo practicar en Java. Si este es su caso, comencemos por implementar el entorno de desarrollo.

Hay un grupo en VKontakte. Extensiones para App Inventor, donde se proporciona orientación paso a paso sobre cómo crear y configurar un entorno de trabajo en formato de vídeo y texto, así como un ejemplo sencillo que devuelve la palabra Prueba. No tiene sentido duplicar este material, pero veamos el ejemplo en sí como una introducción rápida al tema.

paquete vlad; importar com.google.appinventor.components.runtime.*; importar com.google.appinventor.components.annotations.DesignerComponent; importar com.google.appinventor.components.annotations.DesignerProperty; importar com.google.appinventor.components.annotations.PropertyCategory; importar com.google.appinventor.components.annotations.SimpleEvent; importar com.google.appinventor.components.annotations.SimpleFunction; importar com.google.appinventor.components.annotations.SimpleObject; importar com.google.appinventor.components.annotations.SimpleProperty; importar com.google.appinventor.components.common.ComponentCategory; importar com.google.appinventor.components.common.PropertyTypeConstants; importar com.google.appinventor.components.common.YaVersion; importar com.google.appinventor.components.runtime.util.SdkLevel; @DesignerComponent(version = YaVersion.NOTIFIER_COMPONENT_VERSION, categoría = ComponentCategory.EXTENSION, descripción = "Esta es una extensión de prueba", nonVisible = true, iconName = "images/notifier.png") @SimpleObject(external=true) clase final pública TestExtension extiende AndroidNonvisibleComponent implementa Componente ( public TestExtension(Contenedor ComponentContainer) ( super(contenedor.$form()); ) @SimpleFunction(descripción = "Esta función devuelve la cadena \"Prueba\"") public String Test() ( return "Prueba "; ) )

El código de extensión incluye el código java de la clase y anotaciones que comienzan con el símbolo @. Las anotaciones se utilizan para indicar que un compilador simple debe procesar un bloque de código subyacente. Un compilador simple analiza las anotaciones e integra la extensión en el entorno de desarrollo de App Inventor: crea un bloque (función o propiedad) para la función especificada, un campo de edición en el diseñador y realiza otros trabajos.

@DesignerComponent indica los parámetros generales del componente y que está categorizado como una extensión y no es visual (actualmente solo se pueden crear componentes de extensión no visuales)

@SimpleObject indica un componente y el campo externo = verdadero indica que el componente es externo

@SimpleFunction le dice al compilador la función para la cual crear un bloque. Si la función devuelve un valor, aparecerá una muesca en su lado izquierdo. Si una función tiene parámetros, las muescas correspondientes estarán en el lado derecho.

Los códigos fuente de las clases se pueden encontrar en los directorios correspondientes a los nombres de los paquetes:

com/google/appinventor/components/runtime: clases de objetos integrados.
com/google/appinventor/components/annotations - clases de anotaciones
com/google/appinventor/components/common - clases comunes
com/google/appinventor/components/runtime/util - clases de utilidad

Actualmente, sólo puedes crear un componente no visual usando la extensión. Si necesita crear un componente visual que pueda arrastrarse al espacio de trabajo del diseñador, como widgets integrados, necesitará su propia copia local de App Inventor para ello.

Intente cambiar la etiqueta, compilar, instalar y ejecutar el bloque. Si todo salió bien, entonces el entorno de trabajo estará listo y podrás pasar a crear cosas más prácticas e interesantes.

Por operación nos referimos a una secuencia de acciones, cada una de las cuales puede contener un número diferente de bloques.

Cualquier operación se puede colocar en un bloque de procesamiento de eventos o en un bloque de procedimiento. La ubicación de la operación en el bloque de procesamiento de eventos es simple, pero en el futuro esto puede generar muchos problemas, a diferencia de usarlo en un procedimiento, lo que permitirá obtener un algoritmo flexible. Consideremos esto usando el ejemplo de una operación de asignación simple a una variable global de una lista vacía, que consta de dos bloques (Fig. 1).

Arroz. 1. Opciones para la ubicación de la operación.

Cuando una operación se coloca en el bloque de procesamiento de eventos de un componente (opción superior), queda estrechamente vinculada a él y se vuelve inaccesible para llamar desde otros bloques. Si es necesario llamar a esta operación desde otro bloque, será necesario copiarla. No es recomendable crear copias de la operación, ya que si cambia su algoritmo, tendrás que realizar cambios en cada una de ellas. Esto aumenta la probabilidad de que aparezcan diversos errores: puedes olvidarte de corregir alguna copia, cometer un error al copiar bloques, pegarlos, etc. Colocar una operación en un bloque de procedimiento le permitirá llamarla desde otros bloques y evitar los errores descritos anteriormente.

Cuando se trabaja en el editor de bloques, a veces es necesario llamar a diferentes versiones de la misma operación o de diferentes operaciones. Para hacer esto, puede crear nuevos componentes con nuevos bloques de procesamiento de eventos o usar un bloque btnExecute existente y realizar una llamada a una operación particular en él. Como resultado de la sustitución, las operaciones separadas se convertirán en bloques "flotantes" (Fig. 2), que no pertenecen a ningún bloque de grupo.

Arroz. 2. Bloques "flotantes".

Si hay muchos bloques flotantes de este tipo en el campo de trabajo, puede que no sea fácil lidiar con ellos. Si todo está claro con el bloque inferior: este es un bloque de llamada a procedimiento, entonces ¿qué hace la concatenación de bloques en la parte superior de la imagen? ¿Se trata de una operación separada o de una acción que está o estuvo incluida en alguna otra operación? ¿Pero entonces dónde está el resto de esta operación? Agregar una operación a un bloque de procedimiento le permitirá deshacerse de bloques "flotantes" extraños.

Para ejecutar un bloque, no es necesario colocarlo en un controlador de eventos. Puede hacer clic derecho sobre él y seleccionar la opción Hacerlo en el menú contextual que aparece.

Otra desventaja de colocar una operación en un controlador de eventos es que si elimina accidentalmente un componente en el diseñador, no solo se eliminarán todos los bloques que pertenecen a ese componente, sino también todos los bloques anidados en él. Será especialmente molesto si la operación consistió en una gran cantidad de bloques (Fig. 3). Si elimina el componente btnTest, se eliminará el bloque btnTest.Click con todo su contenido.

Arroz. 3. Agrupación de bloques no deseada en el controlador de eventos.

¿Qué operación realizan los bloques de esta imagen? Es difícil responder de inmediato. Y al colocarlos en un procedimiento separado, todo quedará claro inmediatamente por su nombre setVarValue: establece el valor de la variable (Fig. 4).

Arroz. 4. Agrupar los lados en el procedimiento.

Los bloques de procedimientos y variables locales tienen configuraciones disponibles haciendo clic en el ícono de ajustes. Para bloques de procedimiento, consiste en agregarles parámetros de entrada, y para bloques de variables locales, crear entradas adicionales. Esto convertirá cuatro bloques de variables en un bloque con cuatro variables (Fig. 4). ¿Es esta conversión equivalente? No. Un bloque con varias variables locales tiene un alcance único, lo que impide que los valores de sus variables se recuperen dentro de él. Por ejemplo, es imposible asignar la variable de valor (Fig. 4) a la variable clave.

Enumeramos las deficiencias que descubrimos al colocar la operación en el bloque de procesamiento de eventos:

Enlace rígido a un bloque de eventos de un determinado tipo del componente seleccionado
Es imposible llamar a una operación desde otros bloques (lo que significa que no puede convertirse en una operación de biblioteca)
Eliminar operación al eliminar un componente
Formación de extraños grupos de bloques “flotantes”
Es difícil entender rápidamente qué hace la operación.

Es muy fácil deshacerse de todas estas deficiencias si todas las operaciones se organizan en procedimientos.

Al crear algoritmos por simplicidad y velocidad, desea poner diferentes operaciones en un solo procedimiento, lo que conducirá a un rápido aumento en el número de bloques y dificultades para comprender su funcionamiento. Para eliminar esto en programación, se utiliza ampliamente una regla simple:

Una función (procedimiento) - una operación

Esta regla está tomada de la práctica de la vida. Imagina que enciendes las luces de la habitación y al mismo tiempo se encienden el televisor y el aire acondicionado y se apaga la computadora. ¿Te gustará? No, porque provocará confusión y situaciones desagradables.
En la Fig. 4, al comienzo del bloque, se llaman cuatro procedimientos: getKey (obtener una clave), getNewVal (obtener un nuevo valor), getKeys (obtener una lista de claves) y getIndex (obtener un índice). Cada uno de estos procedimientos realiza una operación. Después de ellos viene un bloque if, en el que se ejecuta una operación del procedimiento setVarValue1.
¿Es posible utilizar variables globales en lugar de variables locales en los procedimientos? Es posible, pero no deberías hacerlo. El uso de variables globales dentro de un procedimiento, en primer lugar, lo vincula estrictamente a ellos y, en consecuencia, a una aplicación determinada y, en segundo lugar, con la ayuda de variables globales, los bloques externos de diferentes lugares de la aplicación pueden influir en el mecanismo interno de el procedimiento, que es muy indeseable. ¿Qué podría pasar si los pasajeros del autobús tuvieran acceso a su mecanismo?

Las variables locales son una especie de buffer. Si el nombre de una variable global cambia, esto no interrumpirá el funcionamiento del procedimiento, porque dentro de él se utilizan los nombres de las variables locales que no han cambiado. En App Inventor, cuando cambias el nombre de una variable global, cambiará automáticamente en todos los bloques que la utilicen. Esto lleva a una conclusión importante: la automatización existente en App Inventor para verificar la exactitud de los tipos de variables, cambiar el nombre de las variables, etc., por un lado, simplifica el desarrollo de aplicaciones, liberando al desarrollador de pensar en estos problemas y, por el otro. Por otro lado, contribuye al desarrollo de la habilidad de compilar descuidadamente algoritmos. En términos generales, esta habilidad se puede desarrollar programando en cualquier lenguaje. ¿Cómo evitar esto? Utilice recomendaciones para crear "código limpio", sobre el cual se han escrito muchos libros. MIT App Inventor utilizará solo una pequeña parte de estas recomendaciones, pero seguirlas mejorará los algoritmos y su legibilidad en cualquier forma en que se creen: en una hoja de papel, en una pizarra, al editar código o trabajar con bloques.

La regla anterior también debe usarse cuando se utilizan bloques de procesamiento de eventos. En la Fig. 4, el controlador de eventos Click realiza solo una operación: llama a un procedimiento. ¿Qué sucede si necesita llamar a varios procedimientos desde un controlador de eventos? Entonces, ¿necesita comprender si este grupo de procedimientos realiza una o más operaciones? Si solo hay uno, entonces todo está bien. Por ejemplo, cuando se inicializa una aplicación, se llaman muchos procedimientos, pero todos están unidos por una operación: la inicialización.

Cuantas más operaciones realiza un procedimiento, más estrecha es su conexión con un proyecto determinado y más difícil es adaptarlo para que funcione en otra aplicación. Idealmente, es recomendable crear un procedimiento de propósito general independiente de una aplicación determinada para que pueda guardarlo en su biblioteca para reutilizarlo en otras aplicaciones.

Puede utilizar pantallas de aplicaciones no utilizadas como almacenamiento para procedimientos de biblioteca en App Inventor. Las bibliotecas con una pequeña cantidad de procedimientos se pueden colocar juntas en una pantalla y las grandes, en otras separadas. En el último caso, mover todos los bloques de la biblioteca a la mochila se puede realizar mediante una sola operación.

Si ha acumulado muchas bibliotecas, puede organizarlas en forma de plantilla de aplicación, en la que la primera pantalla se deja en blanco. Usamos esta plantilla al crear una nueva aplicación y, una vez que esté lista, creamos una copia de la cual se eliminan todas las pantallas de la biblioteca.

Para evitar cambiar el nombre de las variables globales e interrumpir el funcionamiento de los procedimientos de la biblioteca al copiarlos desde la mochila a la pantalla de la aplicación, que puede tener variables globales con los mismos nombres, es necesario componer de antemano los nombres de los bloques de la biblioteca con prefijos que apunten al biblioteca. Si la biblioteca para trabajar con una lista de pares se llama libPairs. Luego puede nombrar las variables, procedimientos y componentes de esta manera: libPairs_name, libPairs_setValue, libPairs_btnExecute.

Para trabajar más cómodamente con una gran cantidad de bloques y moverlos por el espacio de trabajo, además de los botones de zoom en el área de visualización, también es útil hacer zoom en el espacio de trabajo del navegador usando la combinación de teclas Ctrl- o Ctrl+.

Estación meteorológica en MIT App Inventor 2: una aplicación de estación meteorológica para teléfonos Android creada utilizando el servicio en línea.

Esta estación meteorológica se describe en el artículo, donde revisamos el funcionamiento de la estación meteorológica, creamos un boceto para arduino y el diseño de la estación meteorológica. Pues hoy veremos con más detalle cómo crear una aplicación para Android y mostrar en el teléfono todos los datos recibidos de nuestra estación meteorológica.

Para crear una aplicación de estación meteorológica en MIT App Inventor 2 necesitará:

1. Tamaño de la imagen de fondo 540x960 píxeles (el tamaño de la imagen de fondo depende del tamaño de la pantalla de su dispositivo)

2. Icono de aplicación para la pantalla principal 128x128 píxeles (en formato PNG32)

3. Iconos de botones en la aplicación en dos colores, de 80x80 píxeles de tamaño

Cuando hayamos preparado todas las imágenes necesarias para la aplicación, podremos empezar a trabajar en MIT App Inventor 2. Para empezar, necesitaremos los siguientes componentes:

ListPicker1: para iniciar una conexión Bluetooth, seleccione los dispositivos Bluetooth disponibles y muestre el estado de la conexión
Label3: copia de seguridad, para mostrar información adicional (no funciona temporalmente, no es necesario agregarla)
Label1 – para mostrar los datos recibidos de arduino
Etiqueta2: para mostrar una etiqueta (temperatura en la habitación, temperatura exterior, presión, etc.)
HorizontalArrangement1 – modo de alineación horizontal de elementos, en nuestro caso botones de cambio de modo)
Botón 1 – botón para activar el modo “temperatura exterior”
Botón2 – botón para activar el modo “temperatura ambiente”
Botón3 – botón para habilitar el modo “presión en mmHg”
Botón4 – botón para activar el modo “humedad en %”
Botón 5: botón de desactivación (invisible)
Reloj1 – temporizador
BluetoothClient1 – componente para trabajar con Bluetooth (recibir y enviar datos)