MIT App Inventor – N’importe qui peut créer une application mobile. MIT App Inventor - Tout le monde peut créer une application mobile App Inventor Blocks. Concepts et principes importants

Aujourd'hui, sur le marché du travail, nous assistons à un véritable boom des spécialistes dans le domaine du développement d'applications pour appareils mobiles. Le métier de développeur d’applications mobiles devient l’un des plus demandés. Mais le système éducatif est-il prêt à répondre à ce défi ? Après tout, pour diagnostiquer les capacités de programmation et établir à temps une base solide de connaissances et de compétences, vous devez commencer dès le plus jeune âge scolaire.

Jusqu'à récemment, le problème de l'enseignement de la programmation aux collégiens semblait insoluble - principalement en raison de l'absence d'un outil qui, d'une part, serait assez facile à apprendre et, d'autre part, permettrait de créer des produits vraiment intéressants. . Les tentatives visant à enseigner universellement le BASIC ou le Pascal aux écoliers ont seulement conduit au fait que la matière « informatique » n'était difficile que pour un cercle très restreint d'étudiants - ceux qui, en raison de leurs caractéristiques intellectuelles, de leur éducation familiale ou de leur extrême chance avec un enseignant, ont réussi d'avancer plus loin que les autres dans la maîtrise de la programmation. Pour la plupart des autres écoliers, l’informatique restait quelque chose d’inaccessible.

La donne a commencé à changer au début des années 2000, avec l’émergence et le développement des langages de programmation visuels dont le fleuron est le langage Scratch. Ce langage a révolutionné l’enseignement scolaire de la programmation pour les systèmes d’exploitation de bureau. Programmer dans Scratch est aussi simple que d'assembler un puzzle pour enfants. Les déclarations et procédures du langage sont représentées par des blocs de couleur. En les faisant glisser et en les connectant, nous créons des programmes. Il est tout simplement impossible de se tromper dans la syntaxe de ce langage - si les blocs ne s'emboîtent pas côte à côte, le puzzle ne s'assemblera tout simplement pas.

Inventeur d'applications

Une extension naturelle de cette approche était le langage de programmation App Inventor, développé par Hal Abelson, professeur au Massachusetts Institute of Technology (MIT), en 2010. Il repose sur le même principe consistant à glisser des briques visuelles et à assembler un programme à partir de blocs.

La différence entre App Inventor et Scratch est qu'App Inventor n'est pas axé sur une utilisation sur ordinateur de bureau, mais est destiné à créer des applications pour un appareil mobile - un smartphone ou une tablette exécutant le système d'exploitation Android. Il peut, par exemple, « comprendre » les données de l'accéléromètre d'un gadget mobile, contrôler la caméra intégrée, voir comment le téléphone est orienté dans l'espace, et bien plus encore.

App Inventor est une application entièrement basée sur le cloud. Pour commencer à programmer dessus, vous n'avez besoin que d'Internet et d'un navigateur. Vous pouvez accéder à la page des langues en utilisant ce lien. Interface en anglais et russe.

L'interface du langage de programmation MIT App Inventor se compose de deux parties principales : designer Et éditeur de blocs.

DANS designer Nous construisons notre application à partir d'éléments : écrans, boutons, cellules, images, sons.

DANS éditeur de blocs nous programmons le comportement de ces éléments.

L'interface d'App Inventor est simple et intuitive. Si vous souhaitez essayer d'enseigner la programmation avec App Inventor à l'école, nous vous recommandons le site Web appinvent.ru, qui contient du matériel de formation destiné aux enseignants.

Concours pour les écoliers

Et les écoliers formés à la programmation avec App Inventor à l'école ou seuls peuvent participer à un concours pour développer leurs propres applications mobiles à l'aide d'App Inventor. Le gagnant du concours recevra une tablette de Samsung. La date limite de dépôt des œuvres est le 15 mai 2016.

Inventeur d'applications- un environnement de développement visuel pour les applications Android qui nécessite des connaissances minimales en programmation de la part de l'utilisateur. Développé à l'origine chez Google Labs, après la fermeture de ce laboratoire, il a été transféré au Massachusetts Institute of Technology. D'abord Mars 2011 L'année dernière, le Massachusetts Institute of Technology a lancé une version bêta publique du projet, disponible sur le site appinventor.mit.edu.

Cet environnement de développement fonctionne directement depuis le navigateur. Il n'est pas nécessaire de télécharger ou d'installer quoi que ce soit. Le résultat peut être consulté sur un appareil Android. Des applications prêtes à l'emploi peuvent être placées sur le Play Market.

Depuis août 2015, App Inventor 2 prend en charge langue russe.

Dans l'éditeur en ligne MIT App Inventor 2, les applications sont construites sur la base de composants standards, qui constituent l'élément principal du développement d'applications Android.

Blocs App Inventor. Concepts et principes importants

Les blocs App Inventor sont des outils permettant de manipuler des composants et ressemblent à des puzzles.

Les blocs de ce concepteur d'applications Android sont divisés en deux grands groupes en fonction de ce qu'ils influencent et de ce à quoi ils se rapportent :

directement lié aux composants
liés à l'application dans son ensemble

Commençons avec blocs appartenant aux composants. Ils peuvent être divisés en trois types, qui se distinguent facilement par leur couleur :

1. des blocs décrivant les propriétés du composant. Ils sont verts et ressemblent à ceci :

ce bloc désigne la propriété actuelle du composant. Cette image montre le bloc de couleur d'arrière-plan du composant de texte TextBox1. Il s’agit d’obtenir une valeur existante.

et celui-ci définit la valeur requise pour le composant (donnez à TextBox1 une couleur d'arrière-plan...). "ensemble" - ensemble. Ce type de bloc de propriétés pourrait être classé comme commandes (gestionnaires), car il donne en fait une commande pour modifier n'importe quelle propriété du composant, y compris les valeurs des champs. Cependant, les développeurs d'App Inventor ont décidé de cette façon - après tout, ce sont aussi des propriétés.

2. les blocs d'événements, c'est-à-dire les blocs qui surveillent l'apparition d'un événement dans l'application, par exemple en appuyant sur un bouton puis en lançant une commande de bloc. Ils sont peints en bronze et ressemblent à ceci :

ce bloc, par exemple, effectue une action lorsqu'un bouton est cliqué (lorsque l'on clique sur Button3, faites...)

3. commande block, dans App Inventor, ce bloc est souvent appelé gestionnaire. Ce bloc précise ce qui doit être fait avec le composant auquel appartient le bloc :

Ce bloc particulier appelle les données de la minuterie de l'appareil.

Le deuxième groupe de blocs pertinent pour l’ensemble de la demande, est organisé un peu différemment.

Pour commencer, voici leur liste de sous-groupes :

Blocs logiques– des blocs logiques
Blocs mathématiques– des blocs mathématiques
Blocs de texte– des blocs de texte
Liste les blocs– des blocs pour gérer les listes
Blocs de couleur– des blocs pour la gestion des couleurs
Blocs variables– des blocs pour contrôler les variables
Blocs de procédures– des blocs de procédures.

Tous, à l'exception des blocs Procédures, sont intégrés à d'autres blocs. Autrement dit, ils ne peuvent pas servir de bloc initial, contrairement aux blocs d'événements appartenant aux composants - toutes les actions sont effectuées lorsque certains événements se produisent avec les composants.

Ici, il vaut la peine de parler davantage des types de « puzzles ». Ainsi, vous avez probablement remarqué qu’il existe quatre types d’énigmes.

D'après leur forme, il est évident que toute chaîne dans une application mobile commence par le premier type. Il s’agit d’un événement et il est tout à fait logique qu’il déclenche toutes les actions ultérieures. Et ce type n'est pas différent de celui adopté dans ce concepteur d'applications Android.

Mais les deux types de blocs suivants, selon la typologie App Inventor, appartiennent respectivement à des types différents : propriétés et commandes (gestionnaires). Mais selon la forme du puzzle et leur signification, ils pourraient être classés comme des commandes, puisqu'ils déterminent l'action. Disons deuxième le puzzle montré sur l'image donne une commande pour attribuer une valeur spécifique à un composant, UN troisième Puzzle - appeler un composant avec une valeur spécifique. De plus, ces énigmes sont « intermédiaires » ; elles ne peuvent pas être utilisées pour compléter la chaîne.

Et ici quatrième l'espèce est valeur finale, existante ou calculée, et termine les chaînes avec elle. Par exemple, la quatrième image représente la valeur actuelle du composant Clock1.

La société informatique annonce un concours pour le développement d'applications mobiles pour le système d'exploitation Android, créées dans le langage de programmation App Inventor.

Dates du Concours

Réception et inscription des œuvres du concours : du 1er janvier au 15 mai 2017.
Examen des œuvres par le Jury du concours - du 15 mai au 30 mai 2017.
Annonce des résultats du concours le 30 mai sur le portail du concours.

Vous pouvez augmenter les fonctionnalités intégrées d'App Inventor à l'aide de technologies et d'extensions Web. Vous pouvez trouver des extensions payantes et gratuites sur Internet (environ 200 sur puravidaapps.com), mais des questions se posent : est-il difficile de créer les vôtres, que peuvent-elles faire et vaut-il la peine d'y consacrer du temps ou vaut-il mieux faire autre chose ?

Tous les composants et blocs disponibles dans App Inventor sont intégrés (internes) et les extensions sont externes.

Les fonctionnalités intégrées offrent des fonctionnalités intéressantes pour les utilisateurs novices, satisfaisantes pour les utilisateurs expérimentés et insuffisantes pour les programmeurs. Cependant, la plupart des utilisateurs préféreront télécharger des extensions toutes faites plutôt que de les développer. De là découle une conclusion simple : le développement d’extensions peut intéresser principalement les utilisateurs expérimentés et les passionnés. Les débutants seront plutôt satisfaits des capacités intégrées et des extensions disponibles, mais les programmeurs ne sont pas intéressés à travailler avec des extensions en raison de la nécessité de faire un double travail. Pourquoi passer du temps à créer et à déboguer une extension à fonctionnalités limitées, puis à l'utiliser pour créer une application à fonctionnalités limitées, alors que vous pouvez immédiatement écrire du code en Java, en tirant parti de toutes les fonctionnalités disponibles de l'IDE Android Studio et de l'API Android ?

Créer des extensions pour l'IA n'est pas difficile si vous avez une certaine expérience en programmation et une compréhension des bases de la POO, mais pour les raisons indiquées ci-dessus, seuls quelques-uns s'y engagent sérieusement. Il n'est pas pratique d'écrire des extensions fonctionnelles, mais écrire des modules complémentaires simples pour étendre les fonctionnalités intégrées ou en créer de nouvelles peut être amusant et utile en termes de pratique. Mais ici, vous devez décider de l'approche. Vous pouvez soit suivre le concept de l'IA - programmation visuelle, soit l'étendre avec des éléments de programmation textuelle.

En gros, App Inventor est comme un iceberg dont la pointe est visible pour les utilisateurs sous la forme de fonctionnalités intégrées, et une grande partie se trouve sous l'eau et inaccessible. Ceci est fait spécifiquement conformément à l'objectif de cet IDE, qui nécessite des connaissances minimales en programmation de la part des utilisateurs. Le modèle de travail inhérent à App Inventor n’est pas initialement conçu pour une plus grande fonctionnalité. L'ajout de nouvelles propriétés entraînera une croissance exponentielle du nombre de blocs. Par exemple, l'ajout d'une propriété de transparence entraînera la création de deux blocs pour chaque widget (pour définir et renvoyer la valeur). S'il existe 5 widgets de ce type, le nombre de blocs augmentera de 10. Nous avons ajouté 10 propriétés et le résultat était de 100 blocs. En plus de cela, de nouveaux champs de propriétés apparaîtront dans le concepteur. Dans ces circonstances, l’approche « IDE simple + extensions » semble raisonnable, mais pas pour ceux qui préfèrent de bonnes fonctionnalités prêtes à l’emploi sans avoir à rechercher et installer des modules complémentaires.

La définition individuelle des propriétés des objets et la spécification d'une connexion rigide de blocs au stade du développement de l'application simplifient d'une part le développement et évitent un grand nombre d'erreurs, mais conduisent à l'émergence d'applications statiques. Si un bloc est attaché à un autre bloc, alors c'est pour toujours. Vous pouvez modifier une propriété ou sélectionner un autre objet au moment de l'exécution de l'application uniquement si cette fonctionnalité a été initialement incluse au stade du développement. Pour ce faire, vous devez utiliser un accès indirect aux objets. Par exemple, vous pouvez créer une liste de paires nom d'objet-objet pour tous les objets, puis l'utiliser dans des fonctions pour accéder à différents objets. Dans ce cas, le bloc récepteur ne sera pas associé à un objet spécifique, mais à une liste à partir de laquelle celui souhaité pourra être obtenu par sa clé de nom.

Si nous ajoutons à ce qui précède les difficultés liées à la mise en œuvre des opérations de groupe, le manque de widgets, de méthodes et d'autres nuances de fonctionnalités intégrées, alors la raison de l'apparition d'AppyBuilder, Thunkable, Makeroid, etc. deviendra claire, dans lequel une augmentation de la fonctionnalité est réalisée grâce au nombre de composants. Plus de composants - plus de blocs. Mais avec l'aide d'une extension, vous pouvez augmenter les fonctionnalités de manière qualitative, par exemple en utilisant un bloc pour accéder à des dizaines de propriétés de dizaines d'objets. C'est vraiment intéressant, car cela complète la programmation visuelle avec des éléments textuels pour compenser un certain nombre de défauts de la fonctionnalité IA intégrée.

Ceux qui ont peu de connaissances en programmation pourront-ils créer des extensions ? Oui, les gens simples peuvent le faire en utilisant l’approche « copier et modifier », mais une certaine préparation est quand même nécessaire. Sans cela, on ne saura pas pourquoi l'extension ne se compile pas et ce qui est écrit à l'écran. Il faut également dire qu'une partie de l'extension qui fonctionne avec les objets Android est plus pratique à créer et à déboguer dans Android Studio.

Le développement d'extensions convient à ceux qui, en principe, sont satisfaits d'App Inventor, mais souhaitent ajouter, améliorer et simplifier quelque chose, et en même temps s'entraîner à Java. Si tel est votre cas, commençons par déployer l'environnement de développement.

Il y a un groupe sur VKontakte Extensions pour App Inventor, où des conseils étape par étape sur la création et la configuration d'un environnement de travail sont fournis sous forme de vidéo et de texte, ainsi qu'un exemple simple qui renvoie le mot Test. Cela n’a aucun sens de dupliquer ce matériel, mais regardons l’exemple lui-même comme une introduction rapide au sujet.

paquet vlad; importer com.google.appinventor.components.runtime.* ; importer com.google.appinventor.components.annotations.DesignerComponent ; importer com.google.appinventor.components.annotations.DesignerProperty ; importer com.google.appinventor.components.annotations.PropertyCategory ; importer com.google.appinventor.components.annotations.SimpleEvent ; importer com.google.appinventor.components.annotations.SimpleFunction ; importer com.google.appinventor.components.annotations.SimpleObject ; importer com.google.appinventor.components.annotations.SimpleProperty ; importer com.google.appinventor.components.common.ComponentCategory ; importer com.google.appinventor.components.common.PropertyTypeConstants ; importer com.google.appinventor.components.common.YaVersion ; importer com.google.appinventor.components.runtime.util.SdkLevel ; @DesignerComponent(version = YaVersion.NOTIFIER_COMPONENT_VERSION,category = ComponentCategory.EXTENSION, description = "Ceci est une extension de test", nonVisible = true, iconName = "images/notifier.png") @SimpleObject(external=true) classe finale publique TestExtension extends AndroidNonvisibleComponent implémente le composant ( public TestExtension(ComponentContainer conteneur) ( super(container.$form()); ) @SimpleFunction(description = "Cette fonction renvoie la chaîne \"Test\"") public String Test() ( return "Test " ; ) )

Le code de l'extension inclut le code Java de la classe et les annotations commençant par le symbole @. Les annotations sont utilisées pour indiquer qu'un bloc de code en dessous doit être traité par un simple compilateur. Un simple compilateur examine les annotations et intègre l'extension dans l'environnement de développement App Inventor - crée un bloc (fonction ou propriété) pour la fonction spécifiée, un champ d'édition dans le concepteur et effectue d'autres travaux.

@DesignerComponent indique les paramètres généraux du composant et qu'il est classé comme une extension et qu'il est non visuel (actuellement, seuls les composants d'extension non visuels peuvent être créés)

@SimpleObject indique un composant, et le champ external=true indique que le composant est externe

@SimpleFunction indique au compilateur la fonction pour laquelle créer un bloc. Si la fonction renvoie une valeur, une encoche apparaîtra sur son côté gauche. Si une fonction a des paramètres, alors les encoches correspondantes seront sur le côté droit.

Les codes sources des classes se trouvent dans les répertoires correspondant aux noms de packages :

com/google/appinventor/components/runtime - classes d'objets intégrés.
com/google/appinventor/components/annotations - classes d'annotations
com/google/appinventor/components/common - classes communes
com/google/appinventor/components/runtime/util - classes utilitaires

Actuellement, vous ne pouvez créer un composant non visuel qu'à l'aide de l'extension. Si vous devez créer un composant visuel pouvant être glissé sur l'espace de travail du concepteur, comme des widgets intégrés, vous aurez alors besoin de votre propre copie locale d'App Inventor pour cela.

Essayez de changer l'étiquette, de compiler, d'installer et d'exécuter le bloc. Si tout s'est bien passé, alors l'environnement de travail est défini et vous pouvez passer à la création de choses plus pratiques et intéressantes.

Par opération, nous entendons une séquence d’actions dont chacune peut contenir un nombre différent de blocs.

Toute opération peut être placée soit dans un bloc de traitement d'événement, soit dans un bloc de procédure. L'emplacement de l'opération dans le bloc de traitement des événements est simple, mais à l'avenir cela peut entraîner de nombreux problèmes, contrairement à son utilisation dans une procédure qui permettra d'obtenir un algorithme flexible. Considérons cela en utilisant l'exemple d'une simple opération d'affectation à une variable globale d'une liste vide, composée de deux blocs (Fig. 1).

Riz. 1. Options pour le lieu de l'opération.

Lorsqu'une opération est placée dans le bloc de traitement d'événements d'un composant (option supérieure), elle y est étroitement liée et devient inaccessible pour les appels depuis d'autres blocs. Si cette opération doit être appelée depuis un autre bloc, il faudra la copier. Il n'est pas conseillé de créer des copies de l'opération, car si son algorithme change, vous devrez apporter des modifications à chacune d'elles. Cela augmente le risque d'apparition de diverses erreurs : vous pouvez oublier de corriger certaines copies, faire une erreur en copiant des blocs, en les collant, etc. Placer une opération dans un bloc de procédure vous permettra de l'appeler depuis d'autres blocs et d'éviter les erreurs décrites ci-dessus.

Lorsque vous travaillez dans l'éditeur de blocs, vous devez parfois appeler différentes versions de la même opération ou différentes opérations. Pour ce faire, vous pouvez soit créer de nouveaux composants avec de nouveaux blocs de traitement d'événements, soit utiliser un bloc btnExecute existant, en y appelant une opération particulière. À la suite du remplacement, les opérations détachées se transformeront en blocs « flottants » (Fig. 2), qui n'appartiennent à aucun bloc de groupe.

Riz. 2. Blocs "flottants".

S'il y a beaucoup de ces blocs flottants sur le champ de travail, il peut être difficile de les gérer. Si tout est clair avec le bloc du bas - il s'agit d'un bloc d'appel de procédure, alors que fait la concaténation des blocs dans la partie supérieure de l'image ? S’agit-il d’une opération distincte ou d’une action qui est ou a été incluse dans une autre opération ? Mais alors où est la suite de cette opération ? Ajouter une opération à un bloc de procédure vous permettra de vous débarrasser des étranges blocs « flottants ».

Pour exécuter un bloc, il n’est pas nécessaire de le placer dans un gestionnaire d’événements. Vous pouvez cliquer dessus avec le bouton droit et sélectionner l'option Faites-le dans le menu contextuel qui apparaît.

Un autre inconvénient du placement d'une opération dans un gestionnaire d'événements est que si vous supprimez accidentellement un composant dans le concepteur, non seulement tous les blocs appartenant à ce composant seront supprimés, mais également tous les blocs qui y sont imbriqués. Ce sera particulièrement ennuyeux si l'opération consistait en un grand nombre de blocs (Fig. 3). Si vous supprimez le composant btnTest, le bloc btnTest.Click avec tout son contenu sera supprimé.

Riz. 3. Regroupement indésirable de blocs dans le gestionnaire d'événements.

Quelle opération les blocs de cette image effectuent-ils ? Il est difficile de répondre tout de suite. Et en les plaçant dans une procédure distincte, tout deviendra immédiatement clair à partir de son nom setVarValue - définit la valeur de la variable (Fig. 4).

Riz. 4. Regroupement des côtés dans la procédure.

Les blocs de procédure et de variables locales ont des paramètres disponibles en cliquant sur l'icône d'engrenage. Pour les blocs de procédures, cela consiste à leur ajouter des paramètres d'entrée, et pour les blocs de variables locales, à créer des entrées supplémentaires. Cela transformera quatre blocs de variables en un seul bloc avec quatre variables (Fig. 4). Cette conversion est-elle équivalente ? Non. Un bloc avec plusieurs variables locales a une seule portée, ce qui empêche de récupérer les valeurs de ses variables à l'intérieur de celui-ci. Par exemple, il est impossible d'attribuer la variable valeur (Fig. 4) à la variable clé.

Nous listons les lacunes que nous avons découvertes en plaçant l'opération dans le bloc de traitement des événements :

Liaison rigide à un bloc d'événements d'un certain type du composant sélectionné
Il est impossible d'appeler une opération depuis d'autres blocs (ce qui signifie qu'elle ne peut pas devenir une opération de bibliothèque)
Opération de suppression lors de la suppression d'un composant
Formation d’étranges groupes de blocs « flottants »
Il est difficile de comprendre rapidement à quoi sert l'opération

Il est très facile de se débarrasser de toutes ces lacunes si toutes les opérations sont placées dans des procédures.

Lors de la création d'algorithmes pour plus de simplicité et de rapidité, vous souhaitez regrouper différentes opérations en une seule procédure, ce qui entraînera une augmentation rapide du nombre de blocs et des difficultés dans la compréhension de son fonctionnement. Pour éliminer cela en programmation, une règle simple est largement utilisée :

Une fonction (procédure) - une opération

Cette règle est tirée de la pratique de la vie. Imaginez que vous allumez la lumière dans la pièce et qu'en même temps le téléviseur et le climatiseur s'allument et l'ordinateur s'éteint. Est-ce que ça vous plaira ? Non, car cela entraînerait de la confusion et des situations désagréables.
En figue. 4, au début du bloc, quatre procédures sont appelées - getKey (obtenir une clé), getNewVal (obtenir une nouvelle valeur), getKeys (obtenir une liste de clés) et getIndex (obtenir un index). Chacune de ces procédures effectue une opération. Après eux vient un bloc if, dans lequel une opération de la procédure setVarValue1 est exécutée.
Est-il possible d’utiliser des variables globales au lieu de variables locales dans les procédures ? C'est possible, mais vous ne devriez pas le faire. L'utilisation de variables globales à l'intérieur d'une procédure, d'une part, la lie strictement à elles et, par conséquent, à une application donnée, et, d'autre part, à l'aide de variables globales, des blocs externes provenant de différents endroits de l'application peuvent influencer le mécanisme interne de la procédure, ce qui est très indésirable. Que pourrait-il se passer si les passagers des bus avaient accès à son mécanisme ?

Les variables locales sont une sorte de tampon. Si le nom d'une variable globale change, cela ne perturbera pas le fonctionnement de la procédure, car les noms des variables locales qui n'ont pas changé sont utilisés à l'intérieur. Dans App Inventor, lorsque vous modifiez le nom d'une variable globale, elle change automatiquement dans tous les blocs qui l'utilisent. Cela conduit à une conclusion importante selon laquelle l'automatisation existante dans App Inventor pour vérifier l'exactitude des types de variables, renommer les variables, etc., d'une part, simplifie le développement d'applications, libérant le développeur de la réflexion sur ces problèmes et, d'autre part. part, contribue au développement des compétences de compilation négligente d’algorithmes. D’une manière générale, cette compétence peut être développée par programmation dans n’importe quel langage. Comment éviter cela ? Utilisez les recommandations pour créer du « code propre », sur lequel de nombreux livres ont été écrits. MIT App Inventor n'utilisera qu'une petite partie de ces recommandations, mais les suivre améliorera les algorithmes et leur lisibilité quelle que soit la manière dont ils sont créés - sur une feuille de papier, sur un tableau blanc, lors de l'édition de code ou de l'utilisation de blocs.

La règle ci-dessus doit également être utilisée lors de l'utilisation de blocs de traitement d'événements. En figue. 4, le gestionnaire d'événements Click n'effectue qu'une seule opération : il appelle une procédure. Que se passe-t-il si vous devez appeler plusieurs procédures depuis un gestionnaire d'événements ? Ensuite, vous devez comprendre si ce groupe de procédures effectue une ou plusieurs opérations ? S’il n’y en a qu’un, alors tout va bien. Par exemple, lorsqu'une application est initialisée, de nombreuses procédures sont appelées, mais elles sont toutes unies par une seule opération : l'initialisation.

Plus une procédure effectue d'opérations, plus elle est étroitement liée à un projet donné et plus il est difficile de l'adapter pour fonctionner dans une autre application. Idéalement, il est conseillé de réaliser une procédure généraliste indépendante d'une application donnée afin de pouvoir la mettre dans votre bibliothèque pour la réutiliser dans d'autres applications.

Vous pouvez utiliser les écrans d'application inutilisés comme stockage pour les procédures de bibliothèque dans App Inventor. Les bibliothèques avec un petit nombre de procédures peuvent être regroupées sur un seul écran et les grandes sur des écrans séparés. Dans ce dernier cas, le déplacement de tous les blocs de la bibliothèque dans le sac à dos peut se faire en une seule opération.

Si vous avez accumulé de nombreuses bibliothèques, vous pouvez les organiser sous la forme d'un modèle d'application dans lequel le premier écran reste vide. Nous utilisons ce modèle lors de la création d'une nouvelle application et, une fois prête, nous créons une copie à partir de laquelle tous les écrans de la bibliothèque sont supprimés.

Pour éviter de renommer les variables globales et de perturber le fonctionnement des procédures de la bibliothèque lors de leur copie du sac à dos vers l'écran de l'application, qui peuvent avoir des variables globales portant les mêmes noms, il est nécessaire de composer à l'avance les noms des blocs de bibliothèque avec des préfixes pointant vers le bibliothèque. Si la bibliothèque permettant de travailler avec une liste de paires s'appelle libPairs. Ensuite, vous pouvez nommer les variables, procédures et composants comme ceci : libPairs_name, libPairs_setValue, libPairs_btnExecute.

Pour travailler plus facilement avec un grand nombre de blocs et les déplacer dans l'espace de travail, en plus des boutons de zoom sur la zone de visualisation, il est également utile de zoomer sur l'espace de travail du navigateur à l'aide de la combinaison de touches Ctrl- ou Ctrl+.

Station météo dans MIT App Inventor 2 – une application de station météo pour téléphones Android créée à l'aide du service en ligne.

Cette station météorologique est décrite dans l'article, dans lequel nous avons examiné le fonctionnement de la station météorologique, créé un croquis pour Arduino et la conception de la station météorologique. Eh bien, aujourd'hui, nous examinerons plus en détail comment créer une application pour Android et afficher toutes les données reçues de notre station météo sur le téléphone.

Pour créer une application de station météo dans MIT App Inventor 2, vous aurez besoin de :

1. Taille de l'image d'arrière-plan 540x960 pixels (la taille de l'image d'arrière-plan dépend de la taille de l'écran de votre appareil)

2. Icône d'application pour l'écran principal 128x128 pixels (au format PNG32)

3. Icônes de boutons dans l'application en deux couleurs, taille 80x80 pixels

Lorsque nous aurons préparé toutes les images nécessaires pour l'application, nous pouvons commencer à travailler dans MIT App Inventor 2. Pour commencer, nous aurons besoin des composants suivants :

ListPicker1 - pour démarrer une connexion Bluetooth, sélectionnez les appareils Bluetooth disponibles et affichez l'état de la connexion
Label3 – sauvegarde, pour afficher des informations supplémentaires (ne fonctionne temporairement pas, pas besoin d'en ajouter)
Label1 – pour afficher les données reçues d'arduino
Label2 – pour afficher une étiquette (température dans la pièce, température extérieure, pression, etc.)
HorizontalArrangement1 – mode d’alignement horizontal des éléments, dans notre cas boutons de changement de mode)
Button1 – bouton pour activer le mode « température extérieure »
Button2 – bouton pour activer le mode « température ambiante »
Button3 – bouton pour activer le mode « pression en mmHg »
Button4 – bouton pour activer le mode « humidité en % »
Button5 – bouton de désactivation (invisible)
Horloge1 – minuterie
BluetoothClient1 – composant pour travailler avec Bluetooth (réception et envoi de données)