MIT App Inventor - Oricine poate crea o aplicație mobilă. MIT App Inventor - Oricine poate crea o aplicație mobilă App Inventor Blocks. Concepte și principii importante

Astăzi pe piața muncii asistăm la un adevărat boom pentru specialiștii în domeniul dezvoltării de aplicații pentru dispozitive mobile. Profesia de dezvoltator de aplicații mobile devine una dintre cele mai solicitate. Dar este sistemul de învățământ pregătit să răspundă acestei provocări? La urma urmei, pentru a diagnostica abilitățile de programare și pentru a pune o bază solidă de cunoștințe și abilități în timp, trebuie să începeți de la vârsta școlară timpurie.

Până de curând, problema predării programării elevilor de gimnaziu părea insolubilă - în primul rând din cauza lipsei unui instrument care, pe de o parte, ar fi destul de ușor de învățat și, pe de altă parte, să permită crearea de produse cu adevărat valoroase. . Încercările de a preda universal școlari BASIC sau Pascal au dus doar la faptul că materia „informatică” a fost dură doar pentru un cerc foarte restrâns de elevi - cei care, datorită caracteristicilor intelectuale, educației în familie sau norocului extrem cu un profesor, au reușit pentru a avansa mai departe în stăpânirea programării decât altele . Pentru majoritatea celorlalți școlari, informatica a rămas ceva inaccesibil.

Situația a început să se schimbe la începutul anilor 2000, odată cu apariția și dezvoltarea limbajelor de programare vizuală, al căror flagship este limbajul Scratch. Acest limbaj a făcut o adevărată revoluție în predarea școlară a programarii pentru sistemele de operare desktop. Programarea în Scratch este la fel de ușoară ca și asamblarea unui puzzle pentru copii. Declarațiile și procedurile limbajului sunt reprezentate prin blocuri colorate. Tragându-le și conectându-le, creăm programe. Este pur și simplu imposibil să faci o greșeală în sintaxa acestui limbaj - dacă blocurile nu se potrivesc una lângă alta, puzzle-ul pur și simplu nu se va aduna.

App Inventor

O extensie naturală a acestei abordări a fost limbajul de programare App Inventor, dezvoltat de profesorul Institutului de Tehnologie din Massachusetts (MIT) Hal Abelson în 2010. Se bazează pe același principiu de a trage cărămizi vizuale și de a asambla un program din blocuri.

Diferența dintre App Inventor și Scratch este că App Inventor nu se concentrează pe utilizarea desktopului, ci este destinat creării de aplicații pentru un dispozitiv mobil - un smartphone sau o tabletă care rulează sistemul de operare Android. El poate, de exemplu, „înțelege” datele accelerometrului unui gadget mobil, poate controla camera încorporată, poate vedea cum este orientat telefonul în spațiu și multe altele.

App Inventor este o aplicație complet bazată pe cloud. Pentru a începe programarea pe el, aveți nevoie doar de Internet și de un browser. Puteți accesa pagina de limbă folosind acest link. Interfață în engleză și rusă.

Interfața limbajului de programare MIT App Inventor constă din două părți principale - proiectantȘi editor de blocuri.

ÎN proiectant Construim aplicația noastră din elemente - ecrane, butoane, celule, imagini, sunete.

ÎN editor de blocuri programăm comportamentul acestor elemente.

Interfața App Inventor este simplă și intuitivă. Dacă doriți să încercați să predați programarea folosind App Inventor la școală, vă recomandăm site-ul appinvent.ru, care conține materiale de instruire pentru profesori.

Concurs pentru școlari

Și școlarii care au fost instruiți în programare folosind App Inventor la școală sau pe cont propriu pot participa la o competiție pentru a-și dezvolta propriile aplicații mobile folosind App Inventor. Câștigătorul concursului va primi o tabletă de la Samsung. Data limită de depunere a lucrărilor este 15 mai 2016.

App Inventor- un mediu de dezvoltare vizuală pentru aplicații Android care necesită cunoștințe minime de programare din partea utilizatorului. Dezvoltat inițial la Google Labs, după închiderea acestui laborator a fost transferat la Massachusetts Institute of Technology. La început martie 2011 anul, Massachusetts Institute of Technology a lansat o versiune beta publică a proiectului, disponibilă pe site-ul web appinventor.mit.edu.

Acest mediu de dezvoltare funcționează direct din browser. Nu este nevoie să descărcați sau să instalați nimic. Rezultatul poate fi vizualizat pe un dispozitiv Android. Aplicațiile gata făcute pot fi plasate pe Play Market.

Din august 2015, App Inventor 2 este compatibil Limba rusă.

În editorul online MIT App Inventor 2, aplicațiile sunt construite pe baza componentelor standard, care sunt elementul principal al dezvoltării aplicațiilor Android.

Blocurile App Inventor. Concepte și principii importante

Blocurile App Inventor sunt instrumente pentru manipularea componentelor și arată ca puzzle-uri.

Blocurile din acest designer de aplicații Android sunt împărțite în două grupuri mari în funcție de ceea ce influențează și la ce se leagă:

legate direct de componente
legate de aplicația în ansamblu

Sa incepem cu blocuri care aparțin componentelor. Ele pot fi împărțite în trei tipuri, care se disting ușor prin culoare:

1. blocuri care descriu proprietățile componentei. Sunt verzi și arată așa:

acest bloc denotă proprietatea curentă a componentei. Această imagine arată blocul de culoare de fundal pentru componenta text TextBox1. Ea presupune obținerea unei valori existente.

iar acesta setează valoarea necesară componentei (dați TextBox1 o culoare de fundal...). „set” - set. Acest tip de bloc de proprietăți ar putea fi clasificat ca comenzi (handlers), deoarece oferă de fapt o comandă pentru a modifica orice proprietate a componentei, inclusiv valorile câmpului. Cu toate acestea, dezvoltatorii App Inventor au decis în acest fel - până la urmă, acestea sunt și proprietăți.

2. blocuri de evenimente, adică acele blocuri care monitorizează apariția unui eveniment în aplicație, de exemplu, apăsarea unui buton și apoi lansarea unei comenzi de blocare. Sunt vopsite cu bronz și arată astfel:

acest bloc, de exemplu, efectuează o acțiune atunci când se face clic pe un buton (când se face clic pe Buton3, face...)

3. comandă bloc, în App Inventor acest bloc este adesea numit un handler. Acest bloc specifică ce trebuie făcut cu componenta căreia îi aparține blocul:

Acest bloc particular apelează date de la temporizatorul dispozitivului.

Al doilea grup de blocuri relevante pentru întreaga aplicație, este organizat oarecum diferit.

Pentru început, iată lista lor de subgrupuri:

Blocuri logice– blocuri logice
Blocuri matematice– blocuri de matematică
Blocuri de text– blocuri de text
Listează blocuri– blocuri pentru gestionarea listelor
Blocuri de culoare– blocuri pentru managementul culorilor
Blocuri variabile– blocuri pentru controlul variabilelor
Blocuri de proceduri– blocuri de proceduri.

Toate acestea, cu excepția blocurilor Proceduri, sunt încorporate în alte blocuri. Adică, nu pot servi ca bloc inițial, spre deosebire de blocurile de evenimente aparținând componentelor - toate acțiunile sunt efectuate atunci când apar unele evenimente cu componente.

Aici merită să vorbim mai mult despre tipurile de „puzzle-uri”. Deci, probabil ați observat că există patru tipuri de puzzle-uri.

Din forma lor este destul de evident că orice lanț dintr-o aplicație mobilă începe cu primul tip. Acesta este un eveniment și este destul de logic că inițiază toate acțiunile ulterioare. Și acest tip nu este diferit de cel adoptat în acest designer de aplicații Android.

Dar următoarele două tipuri de blocuri, conform tipologiei App Inventor, aparțin unor tipuri diferite: proprietăți și, respectiv, comenzi (handlers). Dar în funcție de forma puzzle-ului și de semnificație, ele ar putea fi clasificate ca comenzi, deoarece stabilesc acțiunea. Sa spunem al doilea puzzle-ul prezentat în imagine dă o comandă pentru a atribui o anumită valoare unei componente, A al treilea Puzzle - apelează o componentă cu o anumită valoare. În plus, aceste puzzle-uri sunt „intermediare”; nu pot fi folosite pentru a finaliza lanțul.

Si aici Al patrulea specia este valoarea finală, existentă sau calculată, și încheie lanțuri cu aceasta. De exemplu, a patra imagine reprezintă valoarea curentă a componentei Clock1.

Compania IT anunță un concurs pentru dezvoltarea de aplicații mobile pentru sistemul de operare Android, create în limbajul de programare App Inventor.

Datele Concursului

Recepția și înregistrarea lucrărilor la concurs: de la 1 ianuarie până la 15 mai 2017.
Recenzia lucrărilor de către Juriul competitiv - în perioada 15 mai - 30 mai 2017.
Anunțul rezultatelor concursului pe 30 mai pe portalul competiției.

Puteți crește funcționalitatea încorporată a App Inventor folosind tehnologii și extensii web. Puteți găsi extensii plătite și gratuite pe Internet (aproximativ 200 pe puravidaapps.com), dar apar întrebări: cât de dificil este să vă creați propria dvs., ce pot face și merită să petreceți timp pe ele sau este mai bine Fă altceva?

Toate componentele și blocurile disponibile în App Inventor sunt încorporate (interne), iar extensiile sunt externe.

Caracteristicile încorporate oferă funcționalități interesante pentru utilizatorii începători, satisfăcătoare pentru cei experimentați și insuficiente pentru programatori. Cu toate acestea, majoritatea utilizatorilor vor prefera să descarce extensii gata făcute decât să le dezvolte. De aici rezultă o concluzie simplă că dezvoltarea extensiilor poate fi de interes în principal pentru utilizatorii experimentați și entuziaști. Începătorii vor fi destul de mulțumiți de capabilitățile încorporate și de extensiile disponibile, dar programatorii nu sunt interesați să lucreze cu extensii din cauza necesității de a face o muncă dublă. De ce să petreceți timp creând și depanând o extensie de funcționalitate limitată, apoi folosind-o pentru a crea o aplicație cu funcționalitate limitată, când puteți scrie imediat cod în Java, profitând de toate caracteristicile disponibile ale IDE-ului Android Studio și ale API-ului Android?

Crearea de extensii pentru AI nu este dificilă dacă aveți o experiență de programare și o înțelegere a elementelor de bază ale OOP, dar din motivele menționate mai sus, doar câțiva se angajează serios în acest lucru. Nu este practic să scrieți extensii funcționale, dar scrierea de suplimente simple pentru a extinde funcționalitatea încorporată sau pentru a crea altele noi poate fi distractivă și utilă în ceea ce privește practica. Dar aici trebuie să vă decideți asupra abordării. Puteți fie să urmați conceptul de AI - programare vizuală, fie să îl extindeți cu elemente de programare text.

Pentru a spune aproximativ, App Inventor este ca un aisberg, al cărui vârf este vizibil pentru utilizatori sub formă de funcționalitate încorporată, iar mult mai mult este sub apă și inaccesibil. Acest lucru se face în mod specific în conformitate cu scopul acestui IDE, care necesită cunoștințe minime de programare din partea utilizatorilor. Modelul de lucru inerent în App Inventor nu este conceput inițial pentru o funcționalitate mai mare. Adăugarea de noi proprietăți va face ca numărul de blocuri să crească exponențial. De exemplu, adăugarea unei proprietăți de transparență va avea ca rezultat două blocuri pentru fiecare widget (pentru setarea și returnarea valorii). Dacă există 5 astfel de widget-uri, atunci numărul de blocuri va crește cu 10. Am adăugat 10 proprietăți, iar rezultatul a fost de 100 de blocuri. În plus, în designer vor apărea noi câmpuri de proprietate. În aceste circumstanțe, abordarea „simple IDE + extensii” pare rezonabilă, dar nu pentru cei care preferă o funcționalitate bună din cutie, fără a fi nevoiți să găsească și să instaleze suplimente.

Setarea individuală a proprietăților obiectelor și specificarea unei conexiuni rigide a blocurilor în etapa de dezvoltare a aplicației, pe de o parte, simplifică dezvoltarea și evită un număr mare de erori, dar duce la apariția aplicațiilor statice. Dacă un bloc este atașat unui alt bloc, atunci este pentru totdeauna. Puteți modifica o proprietate sau selecta un alt obiect în timpul rulării aplicației numai dacă această caracteristică a fost inclusă inițial în etapa de dezvoltare. Pentru a face acest lucru, trebuie să utilizați acces indirect la obiecte. De exemplu, puteți crea o listă de perechi nume obiect-obiect pentru toate obiectele și apoi o puteți utiliza în funcții pentru a accesa diferite obiecte. În acest caz, blocul de recepție nu va fi asociat cu un obiect anume, ci cu o listă din care poate fi obținut cel dorit prin cheia de nume.

Dacă adăugăm la cele de mai sus dificultățile cu implementarea operațiunilor de grup, lipsa widget-urilor, metodelor și a altor nuanțe de funcționalitate încorporată, atunci motivul apariției AppyBuilder, Thunkable, Makeroid etc. va deveni clar, în care se realizează o creştere a funcţionalităţii datorită numărului de componente. Mai multe componente - mai multe blocuri. Dar cu ajutorul unei extensii, puteți crește funcționalitatea într-un mod calitativ, de exemplu, folosiți un bloc pentru a accesa zeci de proprietăți a zeci de obiecte. Acest lucru este cu adevărat interesant, deoarece completează programarea vizuală cu elemente textuale pentru a compensa o serie de deficiențe ale funcționalității AI încorporate.

Vor putea cei cu puține cunoștințe de programare să creeze extensii? Da, oamenii simpli o pot face folosind abordarea „copiere și schimbă”, dar este încă necesară o anumită pregătire. Fără el, nu va fi clar de ce extensia nu se compila și ce este scris pe ecran. De asemenea, trebuie spus că o parte a extensiei care funcționează cu obiecte Android este mai convenabilă de creat și de depanat în Android Studio.

Dezvoltarea extensiilor este potrivită pentru cei care, în principiu, sunt mulțumiți de App Inventor, dar ar dori să adauge, să îmbunătățească și să simplifice ceva și, în același timp, să exerseze în Java. Dacă acesta este cazul dvs., atunci să începem prin a implementa mediul de dezvoltare.

Există un grup pe VKontakte Extensii pentru App Inventor, unde îndrumări pas cu pas privind crearea și configurarea unui mediu de lucru sunt furnizate sub formă de video și text, precum și un exemplu simplu care returnează cuvântul Test. Nu are sens să duplicați acest material, dar să ne uităm la exemplul în sine ca o introducere rapidă a subiectului.

pachet vlad; import com.google.appinventor.components.runtime.*; import com.google.appinventor.components.annotations.DesignerComponent; import com.google.appinventor.components.annotations.DesignerProperty; import com.google.appinventor.components.annotations.PropertyCategory; import com.google.appinventor.components.annotations.SimpleEvent; import com.google.appinventor.components.annotations.SimpleFunction; import com.google.appinventor.components.annotations.SimpleObject; import com.google.appinventor.components.annotations.SimpleProperty; import com.google.appinventor.components.common.ComponentCategory; import com.google.appinventor.components.common.PropertyTypeConstants; import com.google.appinventor.components.common.YaVersion; import com.google.appinventor.components.runtime.util.SdkLevel; @DesignerComponent(version = YaVersion.NOTIFIER_COMPONENT_VERSION, categorie = ComponentCategory.EXTENSION, description = „Aceasta este o extensie de testare”, nonVisible = true, iconName = „images/notifier.png”) @SimpleObject(external=true) clasă finală publică TestExtension extinde AndroidNonvisibleComponent implementează Componenta ( public TestExtension(ComponentContainer container) ( super(container.$form()); ) @SimpleFunction(description = "Această funcție returnează șirul \"Test\"") public String Test() ( returnează "Test "; ))

Codul extensiei include codul java al clasei și adnotări care încep cu simbolul @. Adnotările sunt folosite pentru a indica faptul că un bloc de cod dedesubt ar trebui să fie procesat de un simplu compilator. Un compilator simplu analizează adnotările și integrează extensia în mediul de dezvoltare App Inventor - creează un bloc (funcție sau proprietate) pentru funcția specificată, un câmp de editare în designer și efectuează alte lucrări.

@DesignerComponent indică parametrii generali ai componentei și că este clasificată ca extensie și nu este vizuală (în prezent pot fi create numai componente de extensie non-vizuale)

@SimpleObject indică o componentă, iar câmpul external=true indică faptul că componenta este externă

@SimpleFunction îi spune compilatorului funcția pentru care să creeze un bloc. Dacă funcția returnează o valoare, atunci va apărea o crestătură în partea stângă. Dacă o funcție are parametri, atunci crestăturile corespunzătoare vor fi în partea dreaptă.

Codurile sursă ale claselor pot fi găsite în directoarele corespunzătoare numelor pachetelor:

com/google/appinventor/components/runtime - clase de obiecte încorporate.
com/google/appinventor/components/annotations - clase de adnotare
com/google/appinventor/components/common - clase comune
com/google/appinventor/components/runtime/util - clase de utilitate

În prezent, puteți crea doar o componentă non-vizuală folosind extensia. Dacă trebuie să creați o componentă vizuală care poate fi trasă în spațiul de lucru al designerului, cum ar fi widget-urile încorporate, atunci veți avea nevoie de propria copie locală a App Inventor pentru aceasta.

Încercați să schimbați eticheta, să compilați, să instalați și să executați blocul. Dacă totul a funcționat, atunci mediul de lucru este setat și poți trece mai departe pentru a crea lucruri mai practice și mai interesante.

Prin operare înțelegem o succesiune de acțiuni, fiecare dintre acestea putând conține un număr diferit de blocuri.

Orice operație poate fi plasată fie într-un bloc de procesare a evenimentelor, fie într-un bloc de procedură. Locația operației în blocul de procesare a evenimentelor este simplă, dar în viitor acest lucru poate duce la multe probleme, spre deosebire de utilizarea acesteia într-o procedură, care vă va permite să obțineți un algoritm flexibil. Să luăm în considerare acest lucru folosind exemplul unei operații simple de atribuire la o variabilă globală a unei liste goale, formată din două blocuri (Fig. 1).

Orez. 1. Opțiuni pentru locația operațiunii.

Când o operațiune este plasată în blocul de procesare a evenimentelor unei componente (opțiunea de sus), aceasta este strâns legată de acesta și devine inaccesibilă pentru apeluri din alte blocuri. Dacă această operație trebuie apelată dintr-un alt bloc, va trebui să fie copiată. Nu este indicat să creați copii ale operației, deoarece dacă algoritmul acesteia se modifică, va trebui să faceți modificări la fiecare dintre ele. Acest lucru crește probabilitatea apariției diferitelor erori: puteți uita să corectați o copie, să faceți o greșeală când copiați blocuri, le lipiți etc. Plasarea unei operații într-un bloc de procedură vă va permite să o apelați din alte blocuri și să evitați erorile descrise mai sus.

Când lucrați în editorul de blocuri, uneori trebuie să apelați versiuni diferite ale aceleiași operațiuni sau operațiuni diferite. Pentru a face acest lucru, puteți fie să creați componente noi cu blocuri noi de procesare a evenimentelor, fie să utilizați un bloc btnExecute existent, efectuând un apel la o anumită operațiune din acesta. Ca urmare a înlocuirii, operațiunile detașate se vor transforma în blocuri „plutitoare” (Fig. 2), care nu aparțin niciunui bloc de grup.

Orez. 2. Blocuri „plutitoare”.

Dacă există o mulțime de astfel de blocuri plutitoare pe câmpul de lucru, atunci tratarea lor poate să nu fie ușoară. Dacă totul este clar cu blocul de jos - acesta este un bloc de apel de procedură, atunci ce face concatenarea blocurilor în partea de sus a imaginii? Este aceasta o operațiune separată sau o acțiune care este sau a fost inclusă într-o altă operațiune? Dar atunci unde este restul acestei operațiuni? Adăugarea unei operații la un bloc de procedură vă va permite să scăpați de blocurile „plutitoare” ciudate.

Pentru a executa un bloc, nu este necesar să îl plasați într-un handler de evenimente. Puteți face clic dreapta pe el și selectați opțiunea Do it din meniul contextual care apare.

Un alt dezavantaj al plasării unei operații într-un handler de evenimente este că, dacă ștergeți accidental o componentă din designer, nu numai toate blocurile care aparțin acestei componente vor fi șterse, ci și toate blocurile imbricate în ele. Va fi deosebit de enervant dacă operațiunea a constat dintr-un număr mare de blocuri (Fig. 3). Dacă ștergeți componenta btnTest, blocul btnTest.Click cu tot conținutul său va fi șters.

Orez. 3. Gruparea nedorită de blocuri în gestionarea evenimentelor.

Ce operație efectuează blocurile din această imagine? E greu să răspunzi imediat. Și când le plasați într-o procedură separată, totul va deveni imediat clar din numele său setVarValue - setează valoarea variabilei (Fig. 4).

Orez. 4. Gruparea laturilor în procedură.

Blocurile de procedură și variabile locale au setări disponibile făcând clic pe pictograma roată. Pentru blocurile de procedură, constă în adăugarea parametrilor de intrare la acestea, iar pentru blocurile de variabile locale, crearea de intrări suplimentare. Acest lucru va transforma patru blocuri de variabile într-un singur bloc cu patru variabile (Fig. 4). Este această conversie echivalentă? Nu. Un bloc cu mai multe variabile locale are un singur domeniu de aplicare, ceea ce împiedică recuperarea valorilor variabilelor sale în interiorul său. De exemplu, este imposibil să se atribuie variabilei valoare (Fig. 4) variabilei cheie.

Enumerăm neajunsurile pe care le-am descoperit în plasarea operației în blocul de procesare a evenimentelor:

Legare rigidă la un bloc de evenimente de un anumit tip al componentei selectate
Este imposibil să apelați o operație din alte blocuri (ceea ce înseamnă că nu poate deveni o operație de bibliotecă)
Operația de ștergere la ștergerea unei componente
Formarea unor grupuri ciudate de blocuri „plutitoare”.
Este greu de înțeles rapid ce face operația

Este foarte ușor să scapi de toate aceste neajunsuri dacă toate operațiunile sunt plasate în proceduri.

Când creați algoritmi pentru simplitate și viteză, doriți să puneți diferite operații într-o singură procedură, ceea ce va duce la o creștere rapidă a numărului de blocuri și la dificultăți în înțelegerea funcționării acesteia. Pentru a elimina acest lucru în programare, o regulă simplă este utilizată pe scară largă:

O singură funcție (procedură) - o singură operație

Această regulă este luată din practica de viață. Imaginați-vă că aprindeți lumina în cameră și, în același timp, televizorul și aerul condiționat se aprind și computerul se stinge. Îți va plăcea? Nu, pentru că va duce la confuzie și la situații neplăcute.
În fig. 4, la începutul blocului, sunt numite patru proceduri - getKey (obțineți o cheie), getNewVal (obțineți o nouă valoare), getKeys (obțineți o listă de chei) și getIndex (obțineți un index). Fiecare dintre aceste proceduri efectuează o singură operație. După ele vine un bloc if, în care se execută o operație a procedurii setVarValue1.
Este posibil să folosiți variabile globale în loc de variabile locale în proceduri? Este posibil, dar nu ar trebui să o faci. Utilizarea variabilelor globale în interiorul unei proceduri, în primul rând, o leagă strict de acestea și, în consecință, de o aplicație dată și, în al doilea rând, cu ajutorul variabilelor globale, blocurile externe din diferite locuri în aplicație pot influența mecanismul intern de procedura, care este foarte nedorită. Ce s-ar putea întâmpla dacă pasagerii autobuzului au acces la mecanismul acestuia?

Variabilele locale sunt un fel de buffer. Dacă numele unei variabile globale se schimbă, acest lucru nu va perturba funcționarea procedurii, deoarece în interiorul acesteia sunt folosite numele variabilelor locale care nu s-au schimbat. În App Inventor, atunci când schimbați numele unei variabile globale, aceasta se va schimba automat în toate blocurile care o folosesc. Aceasta duce la o concluzie importantă că automatizarea existentă în App Inventor pentru verificarea corectitudinii tipurilor de variabile, redenumirea variabilelor etc., pe de o parte, simplifică dezvoltarea aplicației, eliberând dezvoltatorul de a se gândi la aceste probleme și, pe de altă parte. de mână, contribuie la dezvoltarea abilității de compilare neglijentă a algoritmilor. În general, această abilitate poate fi dezvoltată prin programare în orice limbaj. Cum să evitați acest lucru? Folosiți recomandări pentru a crea „cod curat”, despre care s-au scris multe cărți. MIT App Inventor va folosi doar o mică parte din aceste recomandări, dar respectarea acestora va îmbunătăți algoritmii și lizibilitatea lor în orice mod în care sunt creați - pe o bucată de hârtie, pe o tablă, la editarea codului sau la lucrul cu blocuri.

Regula de mai sus ar trebui folosită și atunci când se utilizează blocuri de procesare a evenimentelor. În fig. 4, handlerul de evenimente Click efectuează o singură operație - apelează o procedură. Ce se întâmplă dacă trebuie să apelați mai multe proceduri de la un handler de evenimente? Atunci trebuie să înțelegeți dacă acest grup de proceduri efectuează una sau mai multe operații? Dacă există doar unul, atunci totul este bine. De exemplu, atunci când o aplicație este inițializată, sunt apelate multe proceduri, dar toate sunt unite printr-o singură operație - inițializare.

Cu cât o procedură efectuează mai multe operațiuni, cu atât este mai strânsă legătura sa cu un proiect dat și cu atât este mai dificilă adaptarea acestuia pentru a funcționa într-o altă aplicație. În mod ideal, este recomandabil să faceți o procedură de uz general independentă de o anumită aplicație, astfel încât să o puteți pune în biblioteca dvs. pentru a fi reutilizată în alte aplicații.

Puteți utiliza ecranele de aplicații neutilizate ca stocare pentru procedurile bibliotecii în App Inventor. Bibliotecile cu un număr mic de proceduri pot fi plasate împreună pe un singur ecran, iar cele mari - pe altele separate. În acest din urmă caz, mutarea tuturor blocurilor de bibliotecă în rucsac se poate face folosind o singură operație.

Dacă ai acumulat o mulțime de biblioteci, le poți aranja sub forma unui șablon de aplicație, în care primul ecran este lăsat necompletat. Folosim acest șablon atunci când creăm o nouă aplicație, iar după ce este gata, creăm o copie din care sunt șterse toate ecranele bibliotecii.

Pentru a evita redenumirea variabilelor globale și întreruperea funcționării procedurilor bibliotecii atunci când le copiați din rucsac pe ecranul aplicației, care pot avea variabile globale cu aceleași nume, este necesar să compuneți în prealabil numele blocurilor de bibliotecă cu prefixe care să indice către bibliotecă. Dacă biblioteca pentru lucrul cu o listă de perechi se numește libPairs. Apoi puteți numi variabilele, procedurile și componentele din el astfel: libPairs_name, libPairs_setValue, libPairs_btnExecute.

Pentru a lucra mai convenabil cu un număr mare de blocuri și pentru a le muta în spațiul de lucru, pe lângă butoanele de zoom din zona de vizualizare, este de asemenea util să măriți spațiul de lucru al browserului folosind combinația de taste Ctrl- sau Ctrl+.

Stație meteo în MIT App Inventor 2 – o aplicație de stație meteo pentru telefoane Android creată folosind serviciul online.

Această stație meteo este descrisă în articol, unde am analizat funcționarea stației meteo, am creat o schiță pentru arduino și designul stației meteo. Ei bine, astăzi ne vom uita mai detaliat la modul de a crea o aplicație pentru Android și de a afișa toate datele primite de la stația noastră meteo pe telefon.

Pentru a crea o aplicație de stație meteo în MIT App Inventor 2, veți avea nevoie de:

1. Dimensiunea imaginii de fundal 540x960 pixeli (dimensiunea imaginii de fundal depinde de dimensiunea ecranului dispozitivului dvs.)

2. Pictograma aplicației pentru ecranul principal 128x128 pixeli (în format PNG32)

3. Pictogramele butoanelor din aplicație în două culori, cu dimensiunea de 80x80 pixeli

Când am pregătit toate imaginile necesare pentru aplicație, putem începe să lucrăm în MIT App Inventor 2. Pentru a începe, vom avea nevoie de următoarele componente:

ListPicker1 – pentru a porni o conexiune Bluetooth, selectați dispozitivele Bluetooth disponibile și afișați starea conexiunii
Label3 – backup, pentru afișarea informațiilor suplimentare (temporar nu funcționează, nu este nevoie să adăugați)
Label1 – pentru afișarea datelor primite de la arduino
Label2 – pentru a afișa o etichetă (temperatura în cameră, temperatura exterioară, presiunea etc.)
HorizontalArrangement1 – modul de aliniere orizontală a elementelor, în cazul nostru butoane de comutare a modului)
Buton1 – buton pentru a activa modul „temperatura exterioară”.
Buton2 – buton pentru a activa modul „temperatura camerei”.
Buton3 – buton pentru a activa modul „presiune în mmHg”.
Buton4 – buton pentru a activa modul „umiditate în %”.
Button5 – butonul de dezactivare (invizibil)
Clock1 – temporizator
BluetoothClient1 – componentă pentru lucrul cu Bluetooth (primirea și trimiterea datelor)