Programare Vizuală. Curs. Ingineria Sistemelor. Dr.ing. Loredana STANCIU, PhD

Transcription

1 Curs Ingineria Sistemelor Dr.ing. Loredana STANCIU, PhD

2 Cuprins 1 PROGRAMAREA VIZUALĂ INTRODUCERE ISTORIC STRATEGII ÎN PROGRAMAREA VIZUALĂ CLASIfiCAREA LIMBAJELOR DE PROGRAMARE VIZUALĂ TEORIA LIMBAJELOR DE PROGRAMARE VIZUALĂ Specificarea formală a Limbajelor de Programare Vizuală Analiza Limbajelor de Programare Vizuală PROBLEMELE LIMBAJELOR VIZUALE Controlul fluxului Abstractizarea procedurală Abstractizarea datelor EXEMPLE DE LIMBAJE DE PROGRAMARE VIZUALĂ Chimera. Programarea vizuală imperativă prin demonstrație Forms/3. Programarea vizuală bazată pe foi de calcul tabelar Prograph. Programarea vizuală cu fluxuri de date KidSim/Cocoa. Programarea vizuală bazată pe reguli Cube. Limbaje de programare vizuală 3D PROGRAMAREA VIZUALĂ ȘI ABSTRACTIZAREA CONCLUZII PRIVIND PROGRAMAREA VIZUALĂ MODELARE CU APP INVETOR SISTEMUL DE OPERARE ANDROID Scurt istoric Caracteristici Evoluția sistemului Android și impactul său pe piață Arhitectura Android SDK ul Android MIT (GOOGLE) APP INVENTOR Ce se poate face cu App Inventor? Capacități și limitări Modul de lucru Selectarea componentelor pentru crearea de aplicații Deschiderea editorului de blocuri și pornirea emulatorului Componente App Inventor Blocuri din App Inventor Exemplu de realizare a unei aplicații cu App Inventor BIBLIOGRAFIE

3 1 Programarea Vizuală 1.1 Introducere Limbajele de programare convenționale sunt dificil de învățat și folosit, necesitând abilități pe care foarte mulți oameni nu le au. Din acest motiv, interfețele cu utilizatorul de la o gamă largă de programe au început să vină cu facilități care să suplinească și să ușureze capabilitățile de programare. Spre exemplu, succesul foilor de calcul poate fi parțial atribuit abilității utilizatorilor de a scrie programe (sub formă de colecții de formule ). Pe măsură ce distribuția de calculatoare personale a crescut, foarte mulți utilizatori au ajuns să dețină unul, fără ca marea majoritate să aibă cunoștințe în a scrie programe. Ei cumpără calculatoarele și pachetele software fără să fie capabili să aducă o modificare cât de mică software ului. Pentru a permite utilizatorului final să reconfigureze și să modifice sistemul, pachetele software ar trebui să ofere aceste opțiuni, fapt care ar putea induce transformarea sistemului într unul și mai complex fără să rezolve problemele utilizatorului. Sisteme software ușor de utilizat, precum sistemele de manipulare directă (Direct Manipulation) nu fac decât să mărească distanța dintre utilizator și programator în condițiile în care codul este mult mai complicat (din cauza suplimentului necesar manipulării interfețelor pentru utilizator), chiar dacă mai mulți utilizatori vor putea folosi software ul (fiind ușor de utilizat). (1) Cel mai bun exemplu de sistem cu manipulare directă este sistemul de operare cu pictograma Recycle Bin. Pentru a șterge ceva, utilizatorul selectează și duce efectiv cu mausul (prin tehnica drag and drop) elementele în coș. Pe de altă parte, oamenii au comunicat multă vreme folosind imagini, ca urmare, pe parcursul anilor 80 și 90 s au făcut numeroase eforturi pentru a pune în valoare abilitatea umană de a procesa informații vizuale. Spre exemplificare, se poate considera următoarea situație: un om poate urmări pe ecranul televizorului o imagine și să discearnă un șablon constând în milioane de pixeli pe secundă, care se modifică în timp și spațiu. Dacă, însă, privește imaginea din Fig. 1.1 (2), probabilitatea este aproape nulă ca cineva să deslușească șablonul reprezentat de următorul set de numere: un set de perechi X, Y, unde prima linie reprezintă valorile lui X, iar a doua linie valorile lui Y. Chiar și știind că sunt perechi de coordonate în plan, majoritatea oamenilor tot ar avea probleme în a discerne un șablon din acest exemplu numeric. Dacă, însă, aceste puncte sunt desenate, șablonul reiese rapid, așa cum se poate observa în Fig. 1.2 (2) Fig. 1.1 Perechi de coordonate X,Y Din aceste considerente limbajele de programare vizuală întreabă: de ce, atunci, să persistăm în încercarea de a comunica cu calculatoarele noastre folosind limbaje de programare textuale? N am fi mai productivi şi puterea de calcul a calculatoare moderne n ar fi mai accesibilă la o gamă mai largă de oameni, dacă am fi capabili de a instrui un computer prin simpla desenare a imaginilor pe care le vedem cu ochii minţii noastre atunci când ne gândim la soluţiile unor probleme speciale? Evident, susţinătorii limbajelor de programare vizuală susţin că răspunsul la ambele întrebări este afirmativ. 3

4 Fig. 1.2 Puncte Întrebările de mai sus subliniază motivarea principală a cercetării în limbajele de programare vizuală. În primul rând, majoritatea oamenilor gândesc și își amintesc lucrurile în imagini. Ei se referă la lumea înconjurătoare într un mod grafic și folosesc imaginile drept componente principale în gândirea creatoare. Reducând sau înlocuind în totalitate necesitatea traducerii ideilor vizuale în reprezentări textuale artificiale poate ajuta la diminuarea problemelor de învățare. Mai mult, numeroase aplicații se împacă foarte bine cu metodele de dezvoltare vizuală. (3) Programarea vizuală este programarea în care mai mult de o dimensiune este folosită pentru a transmite informație. Exemple de astfel de dimensiuni adiționale sunt: folosirea obiectelor multi dimensionale, folosirea relaționărilor spațiale, sau folosirea dimensiunii timp pentru specificarea relațiilor semantice de tip înainte după. Fiecare multi dimensional sau relație este un jeton (token), așa cum în limbajele de programare textuală tradiționale fiecare cuvânt este un jeton. O colecție de unul sau mai multe astfel de jetoane este o expresie vizuală. Exemple de expresii vizuale folosite în programarea vizuală includ diagrame, schițe, icoane sau demonstrații de acțiuni realizate cu obiecte grafice. Atunci când sintaxa unui limbaj de programare (semnificativă din punct de vedere semantic) include expresii vizuale, limbajul de programare este un limbaj de programare vizuală (LPV). Deși limbajele de programare textuală tradiționale adeseori încorporează sintaxă bidimensională într un sens foarte limitat o dimensiune x pentru a transmite șir de caractere liniar legal în limbaj și o dimensiune y care permite spațierea opțională a liniilor în document doar una dintre aceste dimensiuni transmite semantică, pe când cea de a doua dimensiune a fost limitată la o informație legată de tastarea relațiilor spațiale astfel încât să poată fi exprimate într o gramatică unidimensională. Astfel, multidimensionalitatea este principala diferență dintre LPV uri și limbajele strict textuale. Când expresiile vizuale sunt folosite într un mediu de programare drept o facilitate de editare rapidă pentru generarea de cod, acesta este denumit mediu vizual de programare (MVP). Aceste medii de programare vizuală pentru limbajele de programare textuală tradiționale reprezintă o trecere între LPV uri și cunoscutele limbaje textuale. Spre deosebire de acum câțiva ani, când mediile de programare strict textuale și în linie de comandă reprezentau normalul, astăzi MVP urile pentru limbajele textuale tradiționale au preluat controlul în lumea programatorilor. MVP urile comerciale pentru limbajele tradiționale sunt gândite pentru programatorii de profesie. Acești programatori folosesc limbajele textuale pe care le cunosc deja și sunt ajutați de tehnici de interfațare grafică cu utilizatorul și de nivelul de accesibilitate al informației pe care metodele vizuale îl pot aduce. MVP urile pentru limbajele tradiționale reprezintă o modalitate de a transfera avansurile datorate cercetării din LPVuri în practică prin aplicarea acestor noi idei limbajelor tradiționale deja familiare programatorilor. În acest fel se permite migrarea graduală de la tehnicile de programare textuale către cele vizuale. (4) 4

5 1.2 Istoric Programarea vizuală a apărut din combinarea graficii pe calculator, a limbajelor de programare și a interacțiunii om calculator. Nu este o surpriză, deci, faptul că dezvoltările din programarea vizuală au reprezentat avansuri în unul dintre aceste domenii. Sistemul revoluționar Sketchpad, dezvoltat de Ivan SUTHERLAND, este cel mai bun exemplu în acest sens. Sketchpad, realizat în 1963 pe calculatorul TX 2 la MIT, a fost considerat prima aplicație de grafică pe calculator. Sistemul permitea utilizatorilor să lucreze cu un creion cu lumină pentru a crea grafice 2D prin combinarea unor primitive simple, precum linii și cercuri, și aplicarea unor operații (precum copierea) și a unor constrângeri asupra geometriei formelor. Interfața sa grafică și suportul pentru specificarea constrângerilor de către utilizator reprezintă contribuțiile cele mai importante ale lui Sketchpad la dezvoltarea LPV urilor. Prin definirea constrângerilor potrivite, utilizatorii puteau realiza structuri complexe precum legături mecanice complicate și să le miște în timp real. Fratele lui Ivan SUTHERLAND, William, a adus, de asemenea, o contribuție importantă la dezvoltarea programării vizuale în 1965, când a folosit TX 2 pentru a implementa un limbaj vizual simplu de fluxuri de date. Sistemul permitea utilizatorilor să creeze, să depaneze și să execute diagrame de fluxuri de date într un mediu vizual unificat. Următorul jalon în geneza LPV urilor l a reprezentat publicarea în 1975 a tezei de doctorat a lui David CANFIELD SMITH intitulată Pygmalion: A Creative Programming Environment. Această lucrare a constituit puncte de plecare pentru câteva direcții de cercetare în acest domeniu care continuă și în ziua de astăzi. Spre exemplu, Pygmalion se baza pe o paradigmă de programare bazată pe icoane în care utilizatorul crea, modifica și conecta mici obiecte, denumite icoane, care aveau proprietăți definite pentru a realiza calcule. De atunci s au adus multe îmbunătățiri acestei metode, însă multe LPVuri încă se bazează pe această paradigmă. Pygmalion a folosit și conceptul de programare prin exemple, unde utilizatorul îi arăta sistemului cum să realizeze o sarcină într o situație specifică, iar sistemul folosea această informație pentru a genera un program care să realizeze sarcina în cazuri generale. În acest sistem, utilizatorul seta modul memorare, realiza calculele de interes, reseta modul de memorare și primea ca ieșire un program care realiza calcule asupra unor intrări arbitrare. (3) Inițial, dezvoltarea programării vizuale a avut loc în două direcții: abordări vizuale asupra limbajelor de programare tradiționale (precum diagramele executabile de fluxuri de date) și noi abordări vizuale de programare care s au depărtat semnificativ de abordările tradiționale (precum programarea prin demonstrarea pe ecran a acțiunilor dorite). Multe dintre aceste sisteme incipiente au avut avantaje care păreau interesante și intuitive când au fost utilizate pe programe jucărie, dar care au indus probleme dificile când s a încercat extinderea lor în programe realiste. Aceste probleme au dus la o decădere incipientă a programării vizuale, făcându i pe mulți să creadă că programarea vizuală este nepotrivită pentru industrie, fiind doar un exercițiu academic. Pentru a depăși aceste probleme, cercetătorii din domeniul vizual au început să dezvolte căi de folosire a programării vizuale doar în anumite domenii software, crescând astfel numărul proiectelor în care programarea vizuală ar putea ajuta. În acest sens, tehnici vizuale au fost: încorporate pe larg în medii de programare care suportă limbaje de programare textuale 5

6 folosite pentru a înlocui specificațiile textuale din interfețele grafice pentru utilizator folosite pentru a realiza formele electronice ale diagramelor din ingineria software în crearea și/sau vizualizarea relaționărilor dintre structurile de date folosite pentru a combina vizual unitățile programate textual pentru a construi noi programe În curând au început să apară MPV uri comerciale de succes. Printre primele exemple au fost Microsoft Visual Basic (pentru Basic) și sistemele VisualWorks (pentru Smalltalk) de la Cincom. Alt grup de MPV uri comerciale, orientate în principal pe programarea de tip large grained, sunt uneltele CASE (Computer Aided Software Engineering) care suportă specificații vizuale (spre exemplu, folosind diagrame) ale relațiilor dintre modulele programului, culminând prin generarea automată a codului. Alți cercetători din programarea vizuală au preferat o altă cale. Ei au contribuit la dezvoltarea acelor proiecte potrivite pentru programarea vizuală prin implementarea sistemelor specifice unor anumite domenii. Folosind această strategie, prin determinarea unui nou domeniu care să suporte această facilitate au crescut numărul proiectelor care pot fi programate vizual. Un beneficiu imediat a fost creşterea nivelului de accesibilitate pentru utilizatorii care ajungeau în contact cu acele sisteme. Dezvoltatorii domeniilor specifice pentru LPV şi MPV au descoperit că, găsind modalităţi de a scrie programe pentru rezolvarea unei anumite probleme dintr un domeniu, au eliminat multe dintre dezavantajele metodelor iniţiale, deoarece au lucrat direct în stilul de comunicare al domeniului respectiv şi au folosit artefacte vizuale (spre exemplu, anumite icoane sau meniuri) care să reflecte nevoile particulare, diagramele de rezolvare a problemelor şi vocabularul specific acelui domeniu, nefiind niciodată obligaţi să părăsească acel stil de comunicare. Această abordare a dat rezultate atât în cercetare, cât şi pe piaţă. Astăzi există LPV uri şi MPV uri pentru diverse domenii: programarea achiziţiilor de date de laborator (LabView de la National Instruments), programarea vizualizărilor specifice (AVS de la Advanced Visual Systems), programarea telefoniei şi a mail ului de voce (Phone Pro de la Cypress Research) şi programarea simulărilor grafice şi a jocurilor (Cocoa de la Stagecoach Software). De asemenea, agenţi pentru generarea de software încep să fie incluşi în software ul pentru calculatoarele personale, permiţând ca macro comenzi care ajută cu sarcini repetitive să fie deduse prin manipulările utilizatorului final (ca în Chimera, de exemplu). Încercarea iniţială de a concepe LPV uri cu destulă putere şi generalitate pentru a rezolva orice varietate de probleme de programare reprezintă un domeniu de cercetare în plină dezvoltare. Un scop al acestei cercetări îl reprezintă îmbunătăţirea continuă a modalităţilor prin care programarea vizuală poate fi folosită. Un alt scop este acela de a asigura aceleaşi modalităţi de îmbunătăţire în dezvoltarea software în general, precum cele deja disponibile pentru programarea unor domenii specifice. Deşi toate acestea sunt încă la nivel de cercetare, au apărut deja LPV uri comerciale cu caracteristici necesare pentru programarea de uz general, fiind folosite pentru a produce pachete software comerciale. Un exemplu este Prograph CPX de la Pictorius International. (4) 1.3 Strategii în Programarea Vizuală În ceea ce priveşte cercetarea în programarea vizuală în general şi în LPV în particular, există o părere greşită precum că acestea au drept scop eliminarea textului. În fapt, majoritatea LPV urilor includ 6

7 text într o oarecare măsură într un context multidimensional. Scopul lor este de a aduce îmbunătăţiri designului limbajului de programare. Şansa de a atinge acest deziderat se bazează pe simplul fapt că LPV urile au mai puţine restricţii sintactice privind modul în care un program poate fi exprimat (de către calculator sau de către om), situaţie ce oferă o libertate de a explora mecanismele programării care nu a mai fost atinsă din simplul motiv că nu era posibil în trecut. Ţelurile care s au dorit a fi atinse prin cercetarea în LPV uri au fost de a: face programarea mai accesibilă unei audienţe particulare îmbunătăţi corectitudinea cu care oamenii realizează sarcini de programare îmbunătăţi viteza cu care oamenii realizează sarcini de programare. Pentru a atinge aceste scopuri, există patru strategii utilizate în LPV uri: Concret: este opusul lui abstract și presupune exprimarea unor aspecte ale programului folosind instanțe particulare. Spre exemplu, unui programator i se permite specificarea unor aspecte semantice privind un obiect sau o valoare specifice, sau sistemul să poată afișa în mod automat efectele unui porțiuni din program asupra unui obiect sau valori specifice. Direct: în contextul manipulării directe, această strategie este descrisă ca fiind sentimentul pe care îl are cineva manipulând direct un obiect. Din perspectivă cognitivă, direct în calculatoare înseamnă o distanță cât mai mică între scop și acțiunile necesare pentru a atinge acest scop. Un exemplu în acest sens ar fi să i se permită programatorului să manipuleze un obiect sau o valoare specifice în mod direct, prin semantică, în loc să descrie această semantică textual. Explicit: anumite aspecte ale semanticii sunt explicite în mediu dacă pot fi precizate direct (textual sau vizual), fără necesitatea ca programatorul să le specifice. Un exemplu îl reprezintă sistemul care generează explicit relaționări între fluxurile de date (sau părți din program) prin desenarea unor arce direcționale între variabilele relaționate ale programului. Răspuns vizual imediat (feedback vizual): în contextul programării vizuale, acest deziderat presupune afișarea imediată a efectelor produse prin editarea programului. Tanimoto (5) a introdus termenul de liveness (adaptat în limba română ca timp de răspuns ), termen care caracterizează cât de imediat este răspunsul semanticii oferit în mod automat pe parcursul procesului de editarea a programului. Tanimoto descrie patru niveluri de timp de răspuns: o Nivelul 1: nu se aplică nicio semantică, deci sistemul nu oferă niciun răspuns programatorului. Un exemplu în acest sens îl reprezintă diagramele de tip entitate relaționare pentru documentație. o Nivelul 2: programatorul poate să obțină răspuns despre o porțiune a programului, dar acest răspuns nu este automat. Compilatoarele suportă minimal acest nivel, iar interpretoarele ceva mai mult deoarece nu sunt restricționate doar la valorile finale de ieșire. o Nivelul 3: un răspuns semantic incremental este asigurat în mod automat de fiecare dată când programatorul realizează o editare incrementală a programului, caz în care toate valorile afișate pe ecran și afectate de modificare sunt retipărite automat. Aceasta asigură consistența dintre starea afișată și starea sistemului dacă singura acțiune care determină schimbarea stării sistemului este editarea programului. Facili 7

8 o tatea de recalculare automată a foilor de calcul tabelar suportă acest nivel de timp de răspuns. Nivelul 4: sistemul răspunde la editările programului ca în nivelul 3, dar și la alte evenimente, precum întreruperi de la ceasul de timp al sistemului sau clicuri de maus, asigurând în orice moment acuratețea dintre datele afișate și starea curentă a sistemului pe tot parcursul rulării. 1.4 Clasificarea Limbajelor de Programare Vizuală Pe măsură ce domeniul LPV a început să se maturizeze, a apărut interesul creării unei clasificări standard și robuste pentru tot ce s a descoperit. O astfel de clasificare nu este de interes doar pentru cercetători, care vor putea găsi mai ușor lucrări asemănătoare, ci asigură și o bază pentru compararea și evaluarea diferitelor sisteme. Această clasificare se datorează unor nume importante din domeniu, incluzând pe Chang, Shu sau Burnett, care s au străduit să identifice caracteristicile care definesc principalele categorii de LPV. Următoarea listă (3) prezintă un sumar al schemei de clasificare ce va fi dezvoltată pe parcursul acestui subcapitol: Limbaje vizuale pure Sisteme hibride (text și vizuale) Sisteme de programare prin exemplificare Sisteme orientate pe constrângeri Sisteme bazate pe formulare În fapt, aceste categorii nu sunt mutual exclusive, numeroase limbaje putând fi încadrate la mai mult de o categorie. În contextul acestui curs, cea mai importantă categorie o reprezintă limbajele pur vizuale. Aceste limbaje sunt caracterizate de faptul că ele se bazează pe tehnici vizuale pe toată durata procesului de programare. Programatorul manipulează icoane sau alte reprezentări grafice pentru a și crea programul care, apoi, este depanat și executat în același mediu vizual. Programul este compilat direct prin reprezentarea sa vizuală și nu este niciodată tradus într un limbaj intermediar bazat pe text. Exemplu de astfel de sistem complet vizual este Prograph. În literatura de specialitate a domeniului, această categorie este subdivizată în secțiuni precum limbaje cu icoane și fără icoane, orientate pe obiect, funcționale și imperative. Un subset important al LPV încearcă să combine elementele vizuale cu cele textuale. Această categorie de sisteme hibride include atât sistemele în care programele sunt create vizual și apoi translatate într un limbaj textual de nivel înalt, cât și sistemele care folosesc elemente grafice într un limbaj textual. Exemple din această categorie includ Rehearsal World și rezultatul cercetării lui Erwing și a echipei sale (6). În Rehearsal World, utilizatorul antrenează sistemul să rezolve o problemă particulară prin manipularea unor actori grafici, după care sistemul generează un program Smalltalk pentru implementarea soluției. Erwing a dezvoltat extensii la limbajele C și C++ care permit programatorilor să insereze în cod diagrame. Spre exemplu, se poate defini textual o structură de date de tip listă înlănțuită, după care se realizează asupra listei operații (precum ștergerea unui nod) prin desenarea pașilor în cadrul procesului. 8

9 Pe lângă aceste două categorii majore, numeroase LPV uri sunt clasificate într o varietate de ramificații. Spre exemplu, o parte dintre LPV uri se aseamănă cu Pygmalion, permițând utilizatorului să creeze și să manipuleze obiecte grafice cu care să învețe sistemul să realizeze o anumită sarcină. Și Rehearsal World, pomenit în paragraful anterior, se încadrează în această categorie de programare prin exemple. Alte LPV uri se bazează pe manipularea constrângerilor, creată de Sutherland în Sketchpad. Aceste sisteme orientate pe constrângeri sunt populare pentru design de simulare, în care programatorul modelează obiectele fizice ca obiecte ale mediului vizual cărora li se impun constrângeri gândite să copieze comportamentul legilor naturale (precum gravitatea). De asemenea, sisteme orientate pe constrângeri se mai folosesc și în dezvoltarea de interfețe grafice pentru utilizatori. Thinglab și ARK, ambele LPV uri de simulare, reprezintă exemple de limbaje bazate pe constrângeri. Câteva LPV uri au împrumutat modul de vizualizare și metaforele de programare de la foile de calcul tabelar. Aceste limbaje pot fi clasificate drept LPV uri bazate pe formulare. Ele înțeleg programarea ca modificarea în timp a unui grup de celule interconectate, deseori permițând programatorului să vizualizeze execuția programului ca pe o secvență de stări diferite ale celulelor care progresează în timp. Form/3 este un exemplu de astfel de LPV. Este important de evidențiat faptul că în fiecare dintre categoriile menționate anterior se pot găsi atât exemple de LPV uri de uz general, cât și limbaje speciale pentru aplicațiile unor anumite domenii. Domeniul programării vizuale s a dezvoltat foarte mult în ultimii ani. Dezvoltarea continuă și rafinarea limbajelor din categoriile menționate mai sus au dus la unele rezultate care au fost inițial considerate ca făcând parte din domeniul vizual, dar ulterior au fost reclasificate ca apropiate de domeniu pentru că nu exemplifică, de fapt, programarea vizuală. Aceste LPV uri orfane includ sisteme de animare folosind algoritmi, precum BALSA, care asigură display grafic interactiv al execuției programelor și unelte de dezvoltare a interfețelor grafice, precum cele livrate cu numeroase compilatoare moderne (precum Microsoft Visual C++). Ambele tipuri de sisteme includ, cu certitudine, componente vizuale, dar acestea sunt, mai degrabă, aplicații grafice sau generatoare de șabloane decât limbaje de programare. (3) 1.5 Teoria Limbajelor de Programare Vizuală Pentru a stabili un cadru pentru discuțiile teoretice privind limbajele de programare vizuale, este necesară prezentarea câtorva definiții (7): icoană (icoană generalizată): un obiect cu reprezentare duală: partea logică (sensul) și partea fizică (imaginea). sistem iconic: un set structurat de icoane relaționate. propoziție iconică (propoziție vizuală): o aranjare spațială a icoanelor pentru sistemul iconic. limbaj vizual: un set de propoziții iconice construit pe baza unei sintaxe și a unei semantici date. analiză sintactică (analiză spațială): analiza unei propoziții iconice pentru determinarea structurii de bază. 9

10 analiză semantică (interpretare spațială): analiza unei propoziții iconice pentru determinarea sensului de bază. Detaliile care urmează sunt restrânse la limbajele vizuale 2D, dar tot ce este expus poate fi generalizat pentru 3D (sau mai mult) Specificarea formală a Limbajelor de Programare Vizuală Un aranjament spațial care constituie o propoziție vizuală reprezintă omologul bidimensional al unui aranjament unidimensional de jetoane în limbajele de programare convenționale (textuale). În acele limbaje, un program este exprimat sub forma unui șir de caractere în care jetoane terminale sunt concatenate pentru a forma o propoziție ale cărei structură și sens sunt determinate prin analiză sintactică și semantică. Astfel, regula de construcție este implicită în limbaj și nu trebuie să fie precizată explicit ca parte a specificațiilor limbajului. Invers, în limbajele de programare vizuală se disting trei reguli de construcție care sunt folosite pentru aranjarea icoanelor: concatenare orizontală (notată cu &), concatenare verticală (notată cu ^) și suprapunere spațială (notată cu +). Fig. 1.3 Câteva icoane din setul Heidelberg. Icoane obiect elementare: (a) un caracter şi (b) un caracter selectat. Icoane de proces: (c) operaţia de inserţie şi (d) operaţia de ştergere. Icoane obiect compozite: (e) un şir de caractere (compus din caractere) şi (f) un şir selectat (compus dintr un caracter şi două caractere selectate). Propoziţie vizuală (g) reprezentând înlocuirea unui subşir într un şir. Pentru a putea formaliza limbajele de programare vizuală, trebuie făcută distincția dintre icoanele de proces (care exprimă calcule) și icoanele obiect. Acestea din urmă pot fi subdivizate în icoane obiect elementare (identifică obiecte primitive în limbaj) și icoane obiect compozite (identifică obiecte formate printr o aranjare spațială a icoanelor obiect elementare). De fapt, termenul icoane elementare se referă atât la icoanele de proces, cât și la icoanele obiect elementare și specifică acele icoane care sunt primitive în limbaj. Și cum o imagine (sau icoană, în acest caz) valorează 1000 de 10

11 cuvinte, toate aceste concepte sunt ilustrate în Fig. 1.3, care prezintă câteva icoane din setul de icoane Heidelberg (8) și o propoziție vizuală completă. Un limbaj de programare vizuală este specificat de o tripletă de forma (DI,G0,B), unde DI este dicționarul de icoane, G0 este gramatica și B este o bază de cunoștințe specifică unui anumit domeniu (9). Dicționarul de icoane este setul de icoane generalizate, fiecare fiind reprezentată printr o pereche de forma (Xm,Xi), cu o parte logică Xm (sensul) și o parte fizică Xi (imaginea). Gramatica G0 precizează modul în care icoanele obiect compozite pot fi construite din icoane elementare folosind operatori de aranjare spațială. Trebuie remarcat faptul că este obligatorie specificarea acestor operatori spațiali de compoziție ca elemente terminale deoarece ei nu mai fac parte implicit din definirea limbajului. Baza de cunoștințe B conține informații specifice domeniului necesare pentru construirea sensului propoziției vizuale dorite. Aceasta conține informații privind numele evenimentelor, relații conceptuale, numele obiectelor rezultate și referințele la obiectele rezultate Analiza Limbajelor de Programare Vizuală Propoziţiile vizuale sunt construite din icoane elementare cu ajutorul operatorilor iconici. Analiza sintactică a propoziţiilor vizuale (cunoscută şi sub denumirea de analiză spaţială (10)) se bazează pe câteva abordări (7): Gramatici pentru procesarea imaginilor: iniţial gândite pentru distribuirea imaginilor digitale pe o reţea de pătrate, aceste gramatici se bazează pe faptul că imaginile digitale sunt compuse din pixeli. Aceste gramatici descoperă structura unei propoziţii vizuale compunând pixelii în elemente vizuale recognoscibile (linii, arce etc.) (11). Această metodă este folositoare când un sistem iconic trebuie să recunoască icoane cu o anumită toleranţă de eroare (spre exemplu, digiţi din scrisul de mână). Gramatici de precedenţă: aceste gramatici de analiză spaţială pot fi folosite pentru analiza expresiilor matematice bidimensionale. Ele sunt foarte potrivite pentru analiza sintactică a propoziţiilor vizuale construite din icoane elementare şi operatori iconici. Arborele de analiză este construit prin compararea precedenţei operatorilor într un şablon principal şi subdivizarea şablonului într unul sau mai multe şabloane secundare. Gramatici independente de context şi gramatici dependente de context: aceste gramatici sunt folosite pentru a determina compoziţia propoziţiile vizuale folosind formalisme cunoscute. Gramatici gen graf: acestea sunt, de departe cele mai puternice (deşi mai puţin eficiente) specificaţii ale limbajelor vizuale. Aceste formalisme prevăd cele mai multe mijloace pentru stabilirea unor relaţii contextuale și mare parte din cercetarea recentă în acest domeniu a fost dedicată încercării de a face analiza cu gramatici de acest tip fezabile din punct de vedere computațional. Arborele de analiză determinat printr una dintre metodele enunțate anterior este analizat ulterior folosind metode tradiționale de analiză semantică. 11

12 1.6 Problemele limbajelor vizuale În cele ce urmează vor fi prezentate câteva dintre problemele comune ale limbajelor vizuale (4). Aceste probleme se întâlnesc mai ales în limbajele vizuale de uz general (potrivite pentru a genera programe executabile de dimensiuni rezonabile), deși unele dintre ele apar și în limbajele vizuale specifice unor anumite domenii (proiectate pentru domenii particulare precum ingineria software sau vizualizarea științifică) Controlul fluxului La fel ca în limbajele de programare convenționale, limbajele vizuale folosesc două metode pentru controlul fluxului în programe: Metoda imperativă: în acest caz, programul vizual realizează una sau mai multe diagrame de control al fluxului sau diagrame de flux de date, care indică modul în care se realizează controlul pe parcursul programului. Un avantaj particular al acestei metode îl reprezintă faptul că asigură o reprezentare vizuală efectivă a paralelismului. Dezavantaj este faptul că programatorul trebuie să fie atent la modul în care secvențierea operațiilor modifică starea programului, ceea ce nu este o caracteristică dorită pentru sistem (mai ales dacă este destinat unor începători) Metoda declarativă: este o alternativă la metoda imperativă și presupune că programatorul trebuie să prevadă ce calcule se efectuează și nu cum se execută acele calcule. Modificarea explicită a stării este evitată prin folosirea atribuirii singulare: programatorul creează un nou obiect prin copierea unuia existent și precizarea diferențelor dorite și nu prin modificarea stării obiectului existent. De asemenea, în loc să specifice o secvență de modificării ale stării, programatorul definește operații prin specificarea dependențelor dintre obiecte. Spre exemplu, dacă programatorul definește Y ca X+1, atunci această formulare, de fapt, stabilește explicit că Y trebuie calculat folosind obiectul X, iar sistemul înțelege că valoarea lui X trebuie calculată prima. Astfel, încă este prezentă secvențierea operațiilor, dar ea trebuie dedusă de către sistem și nu definită de programator. În acest caz, sistemul are de rezolvat problema dependențelor circulare, care trebuie detectate și semnalizate ca eroare Abstractizarea procedurală Există două niveluri de abstractizare procedurală. Limbajele de programare vizuală de nivel înalt nu sunt limbaje de programare complete deoarece, spre exemplu, nu este posibilă scrierea și menținerea unui întreg program într un astfel de limbaj și, inevitabil, există și module non vizuale care sunt incluse în limbaj. Această metodă de programare vizuală este întâlnită în diverse sisteme orientate pe un anumit domeniu, precum uneltele de mentenanță software și mediile de vizualizare științifică. De cealaltă parte sunt limbajele vizuale de nivel scăzut care nu permit programatorului să combine în modulele procedurale logică fin granulată. Această metodologie este folosită în limbaje orientate pe domenii specifice, precum simulatoarele logice. Limbajele de programare vizuală de uz general acoperă întregul spectru de facilități de programare, pornind de la proprietăți de nivel scăzut (incluzând condiționările, recursivitatea, iterația) la proprietăți de nivel ridicat care permit combinarea logicii de nivel scăzut în module abstracte (proceduri, clase, biblioteci etc.). 12

13 1.6.3 Abstractizarea datelor Facilitățile de abstractizare a datelor sunt întâlnite doar în limbajele de programare de uz general. Noțiunea de date abstracte în programarea vizuală este foarte similară cu cea din limbajele de programare convenționale, cu singura deosebire că tipurile de date abstracte trebuie definite vizual (și nu textual), au o reprezentare vizuală (iconică) și asigură un comportament vizual. 1.7 Exemple de limbaje de programare vizuală În această secțiune vor fi prezentate câteva exemple de LPV uri pentru a demonstra câteva modalități prin care au fost implementate strategiile prezentate anterior Chimera. Programarea vizuală imperativă prin demonstrație Chimera este o exemplificare a modului prin care programarea imperativă este suportată în LPV uri, prin punerea programatorului să își demonstreze acțiunile dorite. Sistemul a fost conceput de D.J. Kurlander în cadrul tezei sale de doctorat (12). În cazul Chimera, programatorul este un utilizator final, ca urmare este și un exemplu de LPV destinat îmbunătățirii nivelului de accesibilitate al programării anumitor tipuri de sarcini. Domeniul Chimera este editarea grafică. Pe măsură ce un utilizator final lucrează la o scenă grafică, poate constata apariția unor sarcini de editare repetitive, caz în care poate indica o secvență de manipulări tocmai realizate asupra unei scene ca putând fi generalizate și tratate ca un macro. Acest lucru este posibil deoarece istoricul acțiunilor utilizatorului este prezentat folosind o tehnică de benzi desenate, iar utilizatorul poate selecta paneluri din istoric. Istoricul folosește același limbaj vizual ca interfața, deci utilizatorul le va înțelege fără probleme. Spre exemplu, Fig. 1.4 a) prezintă o ilustrație conținând două pătrate și o săgeată. Istoricul generat prin crearea ilustrației este prezentat în Fig Fig. 1.4 Două versiuni ale unei scene simple. Scena initială (a) și modificată (b) Primul panel al Fig. 1.5 înfățișează activarea grilei din panelul de control al editorului. Numele comenzii (Toggle Grids) apare deasupra panoului. Al doilea panel prezintă un dreptunghi creat în scena editorului cu ajutorul comenzii Add Box. În panelul trei dreptunghiul este selectat, în caseta Text Input este tastată o culoare (galben) și este invocată comanda Set Fill Color. Acest panel este împărțit pentru a vizualiza atât partea de control, cât și partea de editare. Următoarele paneluri prezintă modificări ale grosimii și culorii marginii dreptunghiului, adăugarea unei linii paralelă cu dreptunghiul și a încă două linii deasupra acesteia pentru a forma o săgeată. A doua parte a istoricului înfățișează adăugarea unui nou dreptunghi, tragerea săgeții până la acest dreptunghi, rotirea săgeții pentru a i alinia baza cu primul dreptunghi și, în final, întinderea săgeții pentru a atinge primul dreptunghi. 13

14 Fig. 1.5 Programarea prin demonstrație în Chimera. În acest exemplu, utilizatorul a desenat o cutie cu o săgeată indicând spre ea (ca într o diagramă), iar această demonstrație este prezentată după realizarea ei printr o serie de paneluri. Acest set de demonstrații poate fi generalizat într un macro pentru utilizarea sa ulterioară. Pentru a face istoricele mai scurte și mai simplu de înțeles, se folosesc mai multe strategii. Mai multe operații înrudite se unesc într un singur panel. Spre exemplu, panelul doi conține mai multe operații: selectarea unei scene obiect și modificarea culorii fundalului pentru obiectele selectate. Eticheta panelului indică numărul de comenzi pe care le reprezintă și poate fi desfăcut pentru a vizualiza panelurile incluse. Panelul doi se deschide în primele două paneluri prezentate în Fig Pentru ca istoricul să nu fie foarte încărcat, fiecare panel arată doar obiectele care participă în operațiile sale și contextul adiacent cu el al scenei. Obiectele în panel sunt distribuite conform cu rolul pe care îl au în explicație. Spre exemplu, în primul panel sunt importante caseta pentru marcaj și eticheta ei, motiv pentru care sunt evidențiate, dar nu și celelalte elemente de control ale panelului. Fig. 1.6 Folosirea istoricului pentru modificarea unei scene: (a) panourile selectate pentru refolosire, (b) noi operații adăugate în istoric Istoricul grafic editabil poate fi folosit pentru revizuirea operațiilor dintr o sesiune, pentru anularea (undo) sau reluarea (redo) unei secvențe din aceste operații. Pentru exemplul din Fig. 1.4, se dorește aplicarea pentru dreptunghiul de sus a comenzilor care stabilesc culoarea de umplere, grosimea și culoarea linei la fel ca la dreptunghiul de jos. Se selectează dreptunghiul de jos, se caută în istoric panelurile relevante și se selectează și ele (în cazul exemplului de față, ultimele trei paneluri din Fig. 1.6), panelurile selectate fiind evidențiate cu etichete albe pe fundal negru. În pasul următor se apelează operația Redo Selected Panels, iar dreptunghiul de sus se va modifica în mod corespunzător. Istoricele grafice editabile din Chimera reduc repetiția prin faptul că oferă o interfață pentru operația de reluare a operațiilor. Chimera are și un mecanism pentru inserarea de operații noi în orice punct al unui istoric. Istoricele pot fi făcute editabile, ceea ce transformă fiecare panel static într un editor 14

15 grafic. În acest fel, panelurile pot fi modificate, iar comenzile invocate își propagă modificările în întreg istoricul. Pentru a insera o comandă nouă în mijlocul unui istoric, sistemul anulează toate comenzile ulterioare panelului afectat, execută noile comenzi, după care le reface pe cele anulate. Spre exemplu, dacă se dorește modificarea săgeții (Fig. 1.6 b), se modifică ultimul panel din primul rând al istoricului din Fig Se modifică acest panel și nu altul pentru că, ulterior, săgeata nu mai este aliniată cu axele grilei, iar modificarea ar fi mult mai dificilă. După propagarea acestor modificări, o nouă scenă va fi disponibilă (Fig. 1.4 b). Fig. 1.7 Istoric grafic prezentând crearea și alinierea a două dreptunghiuri Chimera include și o componentă de programare prin exemple, sau macro uri prin exemple, care folosește istoricele grafice editabile ca reprezentare vizuală pentru revizuirea, editarea, generalizarea programului și raportarea erorilor. Spre exemplu, se consideră problema de aliniere la stânga a două dreptunghiuri. Pașii necesari sunt capturați în istoricul grafic din Fig Se creează inițial cele două dreptunghiuri (panelurile 1 și 2), după care se activează liniile pentru aliniere de 0 și 90 de grade (panelurile 3 și 4) și se selectează colțul din stânga sus al dreptunghiului de jos (panelul 5) și colțul din dreapta jos al dreptunghiului de sus (panelul 6) pentru generarea acestor linii. La final se selectează dreptunghiul de sus și se trage până ajunge la intersecția celor două linii. Fig. 1.8 Fereastra pentru construirea macro ului, care conține un macro pentru alinierea la stânga a două dreptunghiuri Dacă se dorește generalizarea acestei proceduri și încapsularea ei într un macro, nu se repetă procedura într un mod special de învățare, ci se parcurge istoricul, se selectează panelurile relevante și se execută comanda de transformare în macro. Pentru exemplul anterior, se selectează toate panelurile, cu excepția celor de creare a dreptunghiurilor, deoarece ele vor fi argumente al macro ului. Va apărea o fereastră de construcție a macro ului conținând panelurile selectate. În pasul următor se vor alege argumentele, prin selectarea obiectelor dorite (cele două dreptunghiuri), se vor denumi și se va invoca comanda Make Argument. Efectul va fi adăugarea a două paneluri la începutul istoricului pentru declararea argumentului (Fig. 1.8). Pentru a folosi macro ul ulterior, pentru un alt set de dreptunghiuri, va apărea o fereastră de invocare (Fig. 1.9) ce va permite selectarea și vizualizarea argumentelor. 15

16 Fig. 1.9 Fereastra de invocare a unui macro Chimera folosește inferența pentru determinarea versiunii generalizate a unui macro. Folosirea inferenței este un lucru comun în limbajele prin demonstrație, iar succesul ei depinde de limitabilitatea domeniului de aplicare (așa cum este cazul Chimera). Cu toate acestea, sunt și limbaje prin demonstrație care nu folosesc inferența și un exemplu este Cocoa Forms/3. Programarea vizuală bazată pe foi de calcul tabelar Forms/3 este un exemplu de LPV bazat pe paradigma foilor de calcul tabelar, implementat de către Margaret Burnett în 1991, ca prototip al lucrării sale de disertație (13). În acest caz, programatorul își realizează programul prin crearea unui formular și specificarea conținutului acestuia. Această paradigmă este folosită uzual în foile de calcul tabelar comerciale, unde formularul este sub formă de grilă marcată, iar conținutul este specificat prin formulele celulelor. Programele Forms/3 includ formulare (foi de calcul tabelar) cu celule, doar că celulele nu sunt încastrate într o grilă. Un programator Forms/3 creează un program manipulând direct celulele pentru a le plasa pe formular și definind o formulă pentru fiecare celulă prin folosirea unei combinații flexibile de indicare, tastare și gesturi (Fig. 1.10). Calculele unui program sunt determinate complet de aceste formule. Formulele se combină într o rețea (unidirecțională) de constrângeri, iar sistemul asigură în mod continuu că toate valorile afișate pe ecran satisfac aceste constrângeri. Fig Definirea suprafeței unui pătrat folosind celule de tip calcul tabelar și formule în Forms/3. Tipurile grafice sunt suportate ca valori de primă clasă, iar programatorul poate crea celula cu formula pătratului fie desenând un pătrat, fie tastând textual specificațiile (spre exemplu, box ) Forms/3 este un limbaj Turing complet. Scopul lui este să mărească domeniul de utilitate al conceptului de foi de calcul tabelar prin suportul funcționalităților avansate necesare pentru programare. 16

17 Astfel, suportă facilități precum grafică, animație și recursivitate, dar fără a recurge la macrouri de modificare a stării sau conexiuni cu limbajele de programare tradiționale. Spre exemplu, Forms/3 oferă o colecție de tipuri bogată și extensibilă prin faptul că permite ca atributele unui tip să fie definite prin formule, iar o instanță a unui tip să fie valoare a unei celule, care poate fi referită ca o celulă. În Fig. 1.10, o instanță a tipului box a fost specificată prin desenarea grafică. Această specificare poate fi modificată, dacă este necesar, prin întinderea elementului grafic prin manipulare directă. În ambele cazuri este asigurat un răspuns vizual imediat, conform nivelului 4 de timp de răspuns. Facilitatea concret este prezentă prin faptul că elementul grafic rezultat este văzut imediat ce suficiente formule au fost oferite pentru a face acest lucru posibil. Facilitatea direct este prezentă prin mecanismul de manipulare directă pentru specificarea elementului grafic, deoarece programatorul demonstrează specificațiile direct pe elementul grafic creat. Grupul țintă al Forms/3 sunt viitorii programatori, adică aceia a căror treabă va fi să creeze aplicații, dar a căror formare nu a pus accent pe limbajele de programare tradiționale actuale. Un scop al lui Forms/3 a fost să reducă numărul și complexitatea mecanismelor necesare pentru programarea aplicațiilor, cu speranța că programatorilor le va fi mai ușor decât dacă ar folosi limbajele tradiționale, iar programarea va fi mai corectă și/sau accelerată. În studii empirice, programatorii au demonstrat corectitudine mai ridicată și viteză atât în crearea programului, cât și în depanarea lui, folosind Forms/3 în comparație cu o varietate de tehnici alternative Exemplu de calcul al ariei unui pătrat în Forms/3 Fereastra principală a Forms/3 (versiune recentă de implementare) (13), prezentată în Fig. 1.11, apare pe ecran la pornirea aplicației. Formularul System, listat în fereastra principală a formularelor, este întotdeauna încărcat la pornirea sistemului. Pentru a crea un formular nou se apasă butonul New Form, acțiune urmată de apariția unei ferestre de dialog (Fig. 1.12) pentru specificarea numelui formularului. După crearea unui nou formular, acesta apare listat în fereastra principală. Fig Caseta de dialog pentru New Form Fig Fereastra principală a Forms/3 După deschiderea formularului Area_box creat anterior (Fig. 1.13), se selectează butonul de introducere a unei celule cu butonul din stânga al mausului (butonul din stânga este folosit pentru selecție, butonul din dreapta este folosit pentru alte sarcini). Cu un clic în spațiul formularului se introduce o nouă celulă, care constă într un chenar și un tab pentru formulă. După inserare, apare un cursor pe numele implicit al celulei, care poate fi modificat (în cazul exemplului, Abox). Pentru a introduce o formulă se apasă pe butonul ce indică un cursor pe paleta din stânga, după care se acționează butonul asociat tabului formulei pentru celulă. Va apărea un câmp unde se tastează formula (Fig ), 17

18 în cazul de față valoarea 5, după care se apasă butonul Apply. Valoarea celulei este acum afișată. Acesta este un exemplu de răspuns imediat: de fiecare dată când se introduce o formulă toate valorile afectate sunt reafișate în mod automat. Fig Formular conținând o celulă nouă Fig Casetă pentru formulă în care se inserează o formulă Repetând procedura se creează o nouă celulă în care se va calcula aria pătratului (Fig. 1.15,) ca fiind formula Abox * Abox. Noua celulă (denumită Area) va afișa numărul 25. Modificarea valorii lui Abox va atrage după sine modificarea valorii celulei Area. Fig Formularul finalizat pentru calculul ariei pătratului Prograph. Programarea vizuală cu fluxuri de date Prograph a fost conceput în 1983 de către Tomasz Pietrzykowski și Philip T. Cocs (14). Cel de al doilea rămânând în proiect mai multă vreme i a adus îmbunătățiri de a lungul anilor. Prograph este un LPV bazat pe fluxuri de date destinat programatorilor profesioniști. Paradigma bazată pe fluxuri de date este modalitatea de programare vizuală folosită larg în industrie, dar și de mediile vizuale de programare pentru anumite domenii, precum sistemele de vizualizare științifică și sistemele de simulare Prograph este un limbaj funcțional și ușor de folosit. Datele sunt reprezentate prin linii, iar metodele prin diverse dreptunghiuri. Fiecare dreptunghi conține noduri pentru intrări și ieșiri. Datele sunt transmise prin valori, ceea ce permite metodelor să folosească drept intrări, ieșirile de la alte metode. Prograph nu are variabile, ci doar date care curg prin metode. Prograph este un limbaj de programare Turing complet, adică orice program care poate fi scris în C++ (sau orice alt limbaj de nivel înalt) poate fi scris și în Prograph. Programele sunt create construind diagrame de fluxuri de date în cadrul editorului. Clasele, metodele și atributele Prograph sunt reprezentate și manipulate grafic. Fig prezintă un program care calculează valoarea ipotenuzei unui triunghi dreptunghic. Datele sunt introduse textual și curg de a lungul liniilor conectate la operații. Operațiile colectează datele și le transmit spre alte operații până se obține rezultatul final, care este vizualizat. 18

19 Prograph asigură un mecanism puternic pentru depanare, folosind extensiv tehnici de vizualizare dinamică. Pentru valorile datelor nivelul de timp de răspuns este 2, deoarece programatorul cere explicit vizualizarea acestora când dorește să le vadă. Cu toate acestea, activitățile din timpul rulării și ordinea de execuție a nodurilor pot fi vizualizate pe tot parcursul execuției, iar dacă programatorul modifică o parte din date sau cod, acestea sunt în mod automat aplicate asupra sistemului. Acest aspect are nivelul 3 de timp de răspuns. Fig Programarea prin fluxuri de date în Prograph. Programatorul folosește operații de nivel scăzut (primitive) pentru a calcula ipotenuza unui triunghi dreptunghic. Prograph permite numirea și compunerea unor astfel de grafuri de nivel scăzut în grafuri de nivel ridicat, care pot fi compuse ulterior în alte grafuri etc. O cale prin care această paradigmă de programare se distinge de alte paradigme (prin prezentarea explicită a arcelor în graf) este explicitatea sa privind relaționările fluxurilor de date în cadrul programului. Cum numeroase limbaje bazate pe fluxul de date guvernează chiar și fluxul de control prin fluxul de date, arcele sunt suficiente și pentru a reflecta, în mod explicit, fluxul de control KidSim/Cocoa. Programarea vizuală bazată pe reguli Cocoa (denumit inițial KidSim) este un LPV bazat pe reguli, în care programatorul specifică reguli pentru demonstrarea unei postcondiții plecând de la o precondiție. Programatorii vizați sunt copiii, iar domeniul asociat este specificarea simulărilor grafice și jocuri. Cocoa este un limbaj Turing complet, doar că facilitățile lui nu au fost proiectate pentru programarea de uz general, ci pentru a facilita accesul copiilor la programarea propriilor simulări. Felul în care atributele concret și direct sunt atinse în Cocoa sunt similare cu Chimera, deoarece ambele folosesc demonstrația ca modalitate de a specifica semantica. Cu toate acestea, nivelul de timp de răspuns este diferit, în Cocoa fiind între 2 și 3. Nu este nivel 3 pentru anumite tipuri de modificări ale programului (spre exemplu, adăugarea unor noi reguli) care nu afectează afișarea curentă a variabilelor până la cererea expresă a programatorului de reluare a rulării. Pentru alte modificări ale programului (modificarea aspectului unui obiect), modificările sunt imediat propagate pe afișaj. În indicarea proprietăților comune tuturor sistemelor bazate pe reguli, Hayes Roth include abilitatea de a le explicita comportamentul (15). În Cocoa, un copil poate crea lumi care să conțină o varietate de caractere, aspecte și proprietăți. O regulă specifică ce face un caracter într o situație particulară, aspectul permite caracterului să își modifice înfățișarea, iar proprietățile sunt folosite pentru a reține informații despre caracter. Simularea se face pe baza unui ceas, astfel încât la fiecare tact al acestuia 19

20 fiecărui caracter din scenă i se permite funcționarea conform propriilor lumi. Fig (16) prezintă un ecran Cocoa tipic. Fig Ecranul Cocoa. Fereastra din colțul stânga sus constituie placa de lucru, cu caseta de copiere sub ea. În dreapta, utilizatorul a deschis carnețele pentru cele două personaje de pe placă Fiecare caracter are o listă de reguli. Când unui caracter îi vine rândul să acționeze, sistemul parcurge lista de reguli, selectează prima regulă aplicabilă stării curente și o execută. Regulile se creează prin specificarea propriu zisă de către programator a acțiunilor care vor fi incluse, după care sistemul le generalizează (creează regula) pentru a putea fi folosite în mod automat de câte ori este nevoie. Fig Crearea unei noi reguli Cea mai simplă regulă este cea care mută un caracter. Fig (16) prezintă un exemplu de creare a unei reguli care permite mutarea unui caracter un pătrățel la dreapta. După apăsarea butonului New Rule, întreaga placă se întunecă, cu excepția unui spot de lumină în jurul caracterului, care poate fi dimensionat pentru a include contextul regulii (pătratul din dreapta caracterului). În pasul următor, se demonstrează regula prin mutarea caracterului în zona dorită (Fig. 1.18). Reprezentarea vizuală a unei reguli prezintă o imagine cu starea regulii înainte (stânga) și după (dreapta), unite cu o săgeată. Regula se interpretează: dacă este spațiu liber la dreapta mea, mă mut în el. Cum regulile sunt 20

21 revizuite la fiecare tact al ceasului, doar această simplă regulă este suficientă pentru deplasarea caracterului de a lungul plăcii. Fig Regula de salt. Caseta acțiunii din dreapta a fost expandată pentru a vizualiza acțiunile realizate de regulă Pot fi create și reguli pentru modificarea aspectului unui caracter. Fig (16) prezintă realizarea unei reguli pentru saltul unui gard. Programatorul mută caracterul un pătrat deasupra gardului, duce aspectul de salt în caseta aspectului curent (current appearance box) de pe pagina de aspect din carnețelul caracterului, mută caracterul un pătrat la dreapta gardului, după care revine la aspectul normal. Fig Modificarea regulii de mers la dreapta De multe ori simulările devin interesante deoarece caracterele se modifică pe parcurs: îmbătrânesc, obosesc, devin mai puternice sau mai deștepte. Pentru a permite modificarea stării interne a caracterelor, Cocoa oferă atribuirea de proprietăți, care pot fi predefinite sau create de utilizator. Spre exemplu, utilizatorul poate crea proprietăți precum vârstă sau flămând pentru un anumit caracter. Aceste proprietăți joacă rolul instanțelor din programarea orientată pe obiecte. Fig (16) prezintă modificarea regulii de mers la dreapta astfel încât caracterul să flămânzească. Utilizatorul creează proprietatea denumită hunger în lista de proprietăți a caracterului cu valoare inițială 0. Pentru a modifica regula, se folosește butonul Add On pentru acea regulă, care execută acțiunile asociate regulii, după care permite utilizatorului să demonstreze noi acțiuni. În acest caz, utilizatorul modifică valoarea din proprietatea hunger din 0 în 1. Sistemul generalizează această demonstrație, dându i sensul Adună 1 la foamea mea. Dacă nu este aceasta interpretarea demonstrației, utilizatorul îi poate edita descrierea. Cocoa include și un calculator pentru a permite editarea unor reguli complicate. 21

22 În fiecare ciclu de execuție, regulile asociate fiecărui caracter sunt parcurse în lista acestuia de sus în jos (Fig. 1.21). Indicatorul din dreptul unei reguli este off (gri) înainte ca regula să fie luată în considerație. Apoi, dacă regula nu poate fi aplicată la starea curentă a caracterului, indicatorul devine roșu. Dacă regula poate fi aplicată, este executată și indicatorul din dreptul ei devine roșu. După aplicarea unei reguli pentru un caracter, acesta este oprit și nu se mai verifică nicio regulă pentru el până în următorul ciclu. (4) Fig Un cățărător de zid în Cocoa care urmează regulile demostrate pentru el. Tocmai a terminat regula 2, care îl pune în poziția cerută de regula 1 (în pasul următor) Fig Function to compute the factorial of a number in Cube 22

23 1.7.5 Cube. Limbaje de programare vizuală 3D Cube, realizat de M. Najork, reprezintă un avans important în design ul limbajelor de programare vizuale, fiind primul limbaj vizual 3D. Deoarece programele Cube sunt traduse în reprezentări interne mai simple pentru verificare și interpretare, limbajul ar fi mai degrabă unul hibrid. Cu toate acestea, utilizatorul nu este expus niciodată la nicio reprezentare textuală, ca urmare este mai corect dacă se spune că limbajul este foarte aproape de a fi complet vizual. Cube folosește o paradigmă de flux de date pentru construcția programelor. Lucrul în 3D asigură un număr de avantaje asupra limbajelor 2D tradiționale. Spre exemplu, lucrul în 3D îi permite sistemului să afișeze mai multe informații într un mediu cu care este mai ușor de interacționat decât cu o reprezentare 2D care folosește aceleași dimensiuni ale ecranului (3). Într o vizualizare 3D, programatorul este liber să își modifice punctul de vedere în interiorul lumii virtuale pentru a se uita la orice secțiuni particulară a programului. Acest tip de flexibilitate nu este disponibil în LPV urile 2D Fig Folosirea programului factorial, după evaluare Fig prezintă principalele componente ale unui program Cube, folosite pentru a descrie o funcție recursivă pentru calculul factorialului unui număr dat (17). Programele Cube sunt compuse din cuburi suport, cuburi predicat, cuburi de definire, porturi, conducte și planuri. Întreaga structură din Fig este înconjurată de un cub de definire care asociază icoana! cu funcția definită în interiorul cubului. Cubul de definire are două porturi conectate la el, unul la stânga și unul la dreapta. Portul din stânga asigură intrarea, iar portul din dreapta este ieșirea, deși, tehnic vorbind, ambele porturi pot asigura ambele funcții, în Cube porturile fiind bidirecționale. Cele două porturi sunt conectate prin conducte la cuburile suport în planul de jos al diagramei, care reprezintă cazul de bază al recursivității. Fiecare plan reprezintă o diagramă de fluxuri de date. Pentru situația de start, diagrama asigură valorile implicite pentru porturi și indică ce tip de valori poate accepta sau produce fiecare port. Dacă valoarea de la portul de intrare este zero, atunci planul de jos este activ și valoarea din cubul de suport din dreapta (unu) pleacă spre portul de ieșire. Dacă intrarea este mai mare decât zero, atunci este satisfăcut predicatul din planul de sus, este extrasă valoarea unu din intrare de către ramura de jos a diagramei de fluxuri de date din partea de sus. Diferența este introdusă în apelul recursiv al funcției factorial, iar rezultatul este multiplicat cu valoarea de intrare. Rezultatul este tri 23

24 mis la portul de ieșire. După definirea funcției factorial în program, ea poate fi apelată prin simpla conectare a cubului predicat etichetat cu icoana! la cuburi de suport, prin cele două porturi (Fig (18)). 1.8 Programarea vizuală și abstractizarea Una dintre provocările legate de programarea vizuală o reprezintă scalarea limbajelor pentru a dezvolta programe cât mai extinse. Aceasta este o problemă mai mare pentru LPV uri decât pentru limbajele tradiționale textuale din motive legate de reprezentarea, designul și implementarea limbajului și noutatea relativă a domeniului. Spre exemplu, unele mecanisme vizuale folosite pentru a obține caracteristici precum explicit pot ocupa un spațiu atât de mare încât devine dificilă menținerea contextului. De asemenea, este dificil de aplicat tehnici dezvoltate pentru limbajele tradiționale, deoarece ele pot aduce cu sine reintroducerea complexității pe care LPV urile au încercat să o înlăture sau să o simplifice. Dezvoltări recente în domeniul abstractizării au fost foarte importante pentru scalabilitatea LPV urilor. Cele două tipuri de abstractizare, cele mai răspândite atât în programarea vizuală, cât și în programarea textuală, sunt abstractizarea procedurală și abstractizarea datelor. În particular, abstractizarea procedurală s a demonstrat a fi suportată într o varietate de LPV uri. Un atribut cheie în suportul abstractizării procedurale în LPV uri l a reprezentat consistența cu restul programării în același LPV. Soluții reprezentative includ: posibilitatea programatorului de a selecta, numi și iconifica o secțiune a unui graf de flux de date (Fig. 1.16), care adaugă un nod, reprezentând subgraful, la o bibliotecă de noduri funcții într un limbaj de tip flux de date; setarea unor foi de calcul separate (Fig. 1.10), care pot fi generalizate în mod automat pentru a permite funcții definite de utilizator într un limbaj bazat pe formulare; înregistrarea și generalizarea unei secvențe de manipulări directe (Fig. 1.5), într un limbaj prin demonstrare. Abstractizarea datelor a cunoscut un proces mai lent de dezvoltare în LPV uri, mai ales pentru că, de multe ori, este dificil de găsit o cale pentru a menține caracteristici precum concret și răspuns direct, și a adăuga suport pentru ideile centrale legate de abstractizarea datelor, precum generalitate și ascunderea informației. Cu toate acestea, în anumite LPV uri a apărut suport pentru abstractizarea datelor. Spre exemplu, în Form/3, un nou tip de dată este definit în foaia de calcul tabelar astfel: cu celule obișnuite se definesc operații sau metode și cu două celule diferențiate se permite compunerea obiectelor complexe din cele simple și definirea modului de vizualizare pe ecran al obiectului. În Cocoa, aspectul fiecărui caracter este desenat folosind un editor grafic și fiecare demonstrație a unui noi reguli aparține tipului caracterului manipulat, asigurând aproximativ funcționalitatea unei operații sau metode. Ambele, Form/3 și Cocoa, asigură și un suport limitat pentru moștenire. 1.9 Concluzii privind programarea vizuală Domeniul limbajelor de programare vizuală abundă cu exemple ale eforturilor de a lărgi accesibilitatea și mări puterea programării calculatoarelor. Deși numeroasele proiecte existente variază în detaliile oferite, în special în metafora vizuală implicată și în domeniul de aplicare țintit, toate împărtășesc scopul comun al îmbunătățirii procesului de programare. În plus, cercetările recente pentru solidificarea fundamentelor teoretice ale programării vizuale și eforturile serioase depuse pentru 24

25 dezvoltarea unor clasificări formale standard ale LPV urilor indică faptul că domeniul a început să se reevalueze și să se maturizeze. Chiar dacă domeniul s a dezvoltat în ultimii douăzeci de ani, contribuții incipiente importante, precum Sketchpad și Pygmalion, și au menținut influența în numeroase design uri de LPV uri. În ciuda migrării spre afișajele grafice și a interacțiunilor incluse în LPV uri, un studiu al domeniului arată că nu se justifică, încă, excluderea în totalitate a textului. În timp ce multe LPV uri pot reprezenta toate aspectele unui program în mod vizual, aceste programe sunt, în general, mai greu de citit și de folosit decât cele care folosesc text pentru etichete și anumite operații atomice. Spre exemplu, deși o operație precum adunarea poate fi reprezentată grafic în LPV uri, făcând acest lucru se poate încărca foarte mult afișajul. Pe de altă parte, folosind text pentru a reprezenta o astfel de operație atomică se obține un afișaj mult mai simplu, fără a pierde metafora vizuală globală. În condițiile în care grafica computerizată, atât hardware, cât și software, continuă să și îmbunătățească performanța și să și scadă prețul, LPV uri tridimensionale, precum Cube, atrag atenția comunității de cercetători. LPV urile 3D nu doar rezolvă problema includerii unei cantități mari de informații pe un ecran destul de mic, ci și exemplifică sinergia inerentă dintre limbajele de programare, grafica pe calculator și interfețele om calculator, ceea ce a fost o marcă a programării vizuale încă de la începuturile sale. 25

26 2 Modelare cu App Invetor 2.1 Sistemul de operare Android Scurt istoric Android (al cărui logo este prezentat în Fig Logo Android (20)) este o platformă software și un sistem de operare pentru dispozitive digitale și telefoane mobile, dezvoltată inițial de compania Google, iar mai târziu de consorțiul comercial Open Handset Alliance. Android permite dezvoltatorilor să scrie cod gestionat în limbajul Java, controlând dispozitivul prin intermediul bibliotecilor Java dezvoltate de Google. Aplicațiile scrise în C și în alte limbaje pot fi compilate în cod mașină ARM și executate, dar acest model de dezvoltare nu este sprijinit oficial de către Google. Fig Logo Android În iulie 2005, Google a achiziționat Android Inc., o companie de tip startup, cu sediul în Palo Alto, California, SUA. Cofondatorii companiei Android, care au continuat să muncească la Google, au fost Andy Rubin (cofondator al Danger), Rich Miner (cofondator al Wildfire Communications, Inc.), Nick Sears (fost vicepreședinte al T Mobile) și Chris White (unul dintre primii ingineri ai WebTV). La acea dată se cunoștea foarte puțin despre Android, Inc., doar că făceau software pentru telefoane mobile. Această achiziție a generat zvonuri cum că Google ar plănui să intre pe piața telefoniei mobile, deși era neclar la vremea respectivă ce funcție ar putea îndeplini în această piață. La Google, echipa condusă de Rubin a dezvoltat un sistem de operare pentru dispozitive mobile bazat pe Linux, pe care l au prezentat producătorilor de telefoane mobile și operatorilor de rețele de telefonie mobilă, cu perspectiva de a asigura un sistem flexibil, reînnoibil. Google a raportat că a aliniat deja o serie de parteneri producători de componente hardware și software la noul concept și a semnalat operatorilor de rețele de telefonie mobilă că este deschis la diferite grade de cooperare din partea acestora. Mai multe speculații că Google ar intra pe piața telefoniei mobile au apărut în decembrie Rapoarte de la BBC și Wall Street Journal au remarcat faptul că Google își dorea căutarea web și aplicațiile sale pe telefoane mobile și că lucra din greu către acest țel. Presa și siturile de știri au publicat curând zvonuri că Google ar dezvolta un dispozitiv mobil marca Google. A urmat și mai multă speculație, susținând că în timp ce Google definea specificațiile tehnice, ar fi demonstrat prototipuri producătorilor de telefoane mobile și operatorilor de rețea. S a raportat că până la 30 de telefoane prototip operau deja pe piață. În septembrie 2007 Information Week a publicat un studiu care dezvăluia că Google a depus cereri pentru mai multe brevete de invenție în domeniul telefoniei mobile. Lansarea platformei Android la 5 noiembrie 2007 a fost anunțată prin fondarea Open Handset Alliance, un consorțiu de 48 de companii de hardware, software și de telecomunicații, printre care și 26

27 Google, HTC, Intel, Motorola, Qualcomm, T Mobile, Sprint Nextel și Nvidia, consacrat dezvoltării de standarde pentru dispozitive mobile. Google a lansat cea mai mare parte a codului Android sub licența Apache, o licență de tip free software și open source. În 9 decembrie 2008, s a anunțat că 14 noi membri au aderat la proiectul Android, incluzând: Sony Ericsson, Vodafone Group Plc, ARM Holdings Plc, Asustek Computer Inc, Toshiba Corp și Garmin Ltd. Începând cu 21 octombrie 2008, Android a fost disponibil ca open source. Google a deschis întregul cod sursă (inclusiv suportul pentru rețea și telefonie), care anterior era indisponibil, sub licența Apache. Sub licența Apache, producătorii sunt liberi să adauge extensii proprietare, fără a le face disponibile comunității open source. În timp ce contribuțiile Google la această platformă se așteaptă să rămână open source, numărul versiunilor derivate ar putea exploda, folosind o varietate de licențe Caracteristici Printre caracteristicile și specificațiile actuale se numără următoarele (21): platforma Android este adaptabilă la configurații mai mari mașina virtuală Dalvik este optimizată pentru dispozitive mobile navigatorul web disponibil este bazat pe platforma de aplicații open source WebKit biblioteci grafice 2D incluse biblioteci grafice 3D incluse, bazate pe specificația OpenGL ES 1.0 suport media software ul de baze de date SQLite este utilizat în scopul stocării datelor Android suportă tehnologii de conectivitate incluzând GSM/EDGE, CDMA, EV DO, UMTS, Bluetooth și Wi Fi SMS și MMS sunt formele de mesagerie instant disponibile, inclusiv conversații de mesaje text. Software ul scris în Java poate fi compilat în cod mașină Dalvik și executat de mașina virtuală Dalvik, care este o implementare specializată de mașină virtuală concepută pentru utilizarea în dispozitivele mobile, deși teoretic nu este o Mașină Virtuală Java standard. Android acceptă următoarele formate media audio/video/imagine: MPEG 4, H.264, MP3, AAC, OGG, AMR, JPEG, PNG, GIF. Android poate utiliza camere video/foto, touchscreen, GPS, accelerometru, și grafică accelerată 3D. Include un emulator de dispozitive, unelte de depanare, un plug in pentru mediul de dezvoltare Eclipse. Similar cu App Store de pe iphone, Android Market (acum Google Play) este un catalog de aplicații care pot fi descărcate și instalate pe hardware ul țintă prin comunicație fără fir, fără a se utiliza un PC. Inițial au fost acceptate doar aplicații gratuite. Aplicații contra cost sunt disponibile pe Android Market începând cu 19 februarie Android are suport nativ pentru multi touch, dar această funcționalitate este dezactivată (posibil pentru a se evita încălcarea brevetelor Apple pe tehnologia touch screen). O modificare neoficială, care permite multi touch a fost dezvoltată. Primele aprecieri cu privire la dezvoltarea aplicațiilor pentru platforma Android au fost amestecate. Problemele citate includeau bug uri, lipsa de documentație, infrastructura de testare inadecvată și 27

28 lipsa unui sistem de gestionare public a problemelor. Google a anunțat un sistem de gestionare a problemelor la data de 18 ianuarie În decembrie 2007, fondatorul startup ului mobil Merge Lab, Adam MacBeth, a declarat: "Funcționalitatea lipsește, este prost documentată sau pur și simplu nu funcționează. Este clar că nu este gata pentru prime time". În ciuda acestui fapt, aplicațiile pentru Android au început să apară, deja, în săptămâna următoare celei în care a fost anunțată platforma. Prima aplicație publică a fost jocul Snake. Telefonul Android Dev este un dispozitiv cu SIM și hardware neblocate care este destinat dezvoltatorilor avansați. Cu toate că dezvoltatorii pot utiliza un dispozitiv de consum achiziționat de pe piață pentru a și testa și a utiliza aplicațiile, unii dezvoltatori pot alege să nu utilizeze un dispozitiv de pe piață, preferând un aparat neblocat sau fără contract Evoluția sistemului Android și impactul său pe piață Android ar putea deveni pentru telefoane ceea ce e Windows pentru PC uri. Sistemul de operare mobil Android de la Google concurează cu sistemul de operare iphone în piața telefoanelor inteligente, iar compania de cercetare NPD a anunțat recent ca Android are o cotă de piață mai mare decât Apple în Statele Unite. (22) Adopția Android a crescut în ultimul an datorită disponibilității acestuia la un număr mare de producători de telefoane mobile. Conform analiștilor financiari ai companiei de cercetare Trefis, există o paralelă între strategia Google din piața smartphone urilor și campania Microsoft împotriva Apple, care a ajutat Windows să devină sistemul de operare dominant în piața PC urilor. Microsoft a oferit licența sistemului său de operare pentru orice producător de computere interesat, iar Google face un lucru asemănător cu sistemul său de operare pentru producătorii de telefoane. Acest lucru ar putea însemna că iphone nu va obține o cotă de piață la cât estimaseră anterior analiștii. Android deja este compatibil cu majoritatea producătorilor de telefoane mobile, de la Motorola la HTC, care nu dețin un sistem de operare propriu. Primul telefon Android a fost vândut la mai bine de un an după lansarea iphone. Cu toate că a fost lansat mai târziu, Android a depășit iphone în piața de smartphone uri din SUA și din întreaga lume. Deși piața din Statele Unite este una atipică, și este foarte diferită față de ceea ce se întâmplă în restul lumii, aceasta prezintă un trend interesant, care s ar putea să fie împărtășit și în alte regiuni ale globului. Astfel, la sfârșitul primului trimestru al anului 2010, cota de piață a Android a crescut cu 4% față de trimestru precedent, ajungând la sfârșitul lunii mai la 13%. Această creștere este cu atât mai spectaculoasă cu cât Android este singurul sistem de operare mobil care reușește să câștige cota de piață, ceea ce înseamnă că Google reușește să fure o bucată foarte mare din piața rivalilor săi Arhitectura Android Diagrama din Fig (21) prezintă principalele componente ale sistemului de operare Android. Astfel, acesta este oferit cu un set de aplicații incluse, precum client de , program SMS, calendar, hărți, navigator pe Internet, contacte etc. (nivelul aplicații). Asigurând o platformă de dezvoltare deschisă, Android oferă dezvoltatorilor posibilitatea de a construi aplicații complexe și inovative. Aceștia sunt liberi să se folosească de hardware ul echipamentului, de informații despre accesarea locației, de rularea de servicii de background, să seteze alarme, să adauge notificații pe bara de stare etc. Dezvoltatorii au acces total la aceleași API uri ca și aplicațiile distribuite cu Android. Arhitectura aplicațiilor este gândită pentru a simplifica reutilizarea compo 28

29 nentelor: orice aplicației își poate publica capabilitățile, iar orice altă aplicație poate utiliza, apoi, aceste capabilități. Același mecanism permite și înlocuirea componentelor de către utilizator. Fig Arhitectura sistemului Android Ca suport pentru toate aplicațiile, se află un set de servicii și sisteme, incluzând: Un set bogat și extensibil de vizualizări (Views) care pot fi folosite pentru a construi o aplicație, incluzând liste, griduri, casete de text, butoane, chiar și un browser web încorporat. Furnizori de conținut (Content Providers) care permite aplicațiilor să acceseze date din alte aplicații (precum Contacts), sau să își partajeze propriile date. Un manager de resurse (Resource Manager), care asigură acces la resursele care nu sunt cod (șiruri de caractere, grafice, fișiere) Un manager de notificare (Notification Manager) care permite tuturor aplicațiilor să afișeze alerte pe bara de stare. Un manager al activităților (Activity Manager) care managerizează ciclul de viață al aplicațiilor și navigare comună backstack (istorie de parcurgere a aplicațiilor pe baza căreia, cu tasta back, se poate reveni la activități anterioare). Android include un set de biblioteci C/C++ folosite de diverse componente ale sistemului. Capabilitățile asociate sunt oferite dezvoltatorilor prin suportul descris anterior. Câteva dintre aceste biblioteci sunt: Biblioteci media: asigură suport de redare și de înregistrare a numeroase formate audio și video populare, precum și fișiere cu imagini statice, incluzând MPEG4, H.264, MP3,AAC, AMR, JPG și PNG Managerul suprafeței de lucru (Surface Manager): asigură accesul la subsistemul afișorului și compune layer e grafice 2D și 3D pentru aplicații LibWebCore: un motor de căutare pe Internet SGL: motorul grafic 2D Biblioteci 3D: API implementat pe baza OpenGL ES 1.0 SQLite: un puternic motor de baze de date disponibil tuturor aplicațiilor. 29

30 Android include un set de biblioteci principale care asigură majoritatea funcționalităților disponibile în bibliotecile limbajului de programare Java. Fiecare aplicație Android rulează în propriul proces și în propria instanță a mașinii virtuale Dalvik, scrisă astfel încât un dispozitiv să ruleze eficient multiple instanțe ale mașinii virtuale. Mașina virtuală Dalvik se bazează pe un nucleu Linux pentru funcționalități de bază precum lucrul cu fire de execuție și managementul memoriei low level. Sistemul Android are la bază versiunea 2.6 de Linux pentru servicii de sistem precum securitatea, managementul memoriei, managementul proceselor etc. Nucleul funcționează și ca un nivel de abstractizare între hardware și software SDK ul Android SDK ul Android include un set complet de instrumente de dezvoltare. Acestea conțin un program de depanare, biblioteci, un emulator de dispozitiv (bazat pe QEMU), documentație, mostre de cod și tutoriale. Platformele de dezvoltare sprijinite în prezent includ calculatoare bazate pe x86 care rulează Linux (orice distribuție Linux desktop modernă), Mac OS X sau mai recent, Windows XP sau Vista. Cerințele includ, de asemenea, Java Development Kit, Apache Ant, și Python 2.2 sau o versiune ulterioară. Mediul de dezvoltare (IDE) suportat oficial este Eclipse (3.2 sau mai recent), utilizând plug in ul Android Development Tools (ADT), deși dezvoltatorii pot folosi orice editor de text pentru a edita fișiere XML și Java și apoi să utilizeze unelte din linia de comandă pentru a crea, construi și depana aplicații Android. O versiune pentru examinare a Android Software Development Kit (SDK) a fost lansată la data de 12 noiembrie La 18 august 2008, a fost lansat Android SDK 0.9 beta. Această versiune oferă un API actualizat și extins, instrumente de dezvoltare îmbunătățite și un design actualizat pentru ecranul de bază. Instrucțiuni detaliate pentru actualizare sunt disponibile pentru cei care lucrează deja cu o versiune anterioară. La 23 septembrie 2008 a fost lansat SDK ul Android 1.0 (Release 1). Conform documentației de lansare, includea "în principal remedii pentru probleme, deși au fost adăugate unele capabilități mai puțin semnificative". Includea, de asemenea, câteva modificări ale API ului față de versiunea 0.9. Pe 9 martie 2009, Google a lansat versiunea 1.1 pentru telefonul Android Dev. Deși există câteva actualizări estetice, câteva actualizări cruciale includ suport pentru "căutare prin voce, aplicații contra cost, remedii pentru ceasul cu alarmă, remediu pentru blocarea la trimiterea gmail, notificări de poștă electronică și intervale de împrospătare". O altă schimbare importantă este că telefoanele Dev pot acum accesa aplicații plătite și dezvoltatorii le pot vedea pe piața Android. Deși este un produs de tip open source, o parte din dezvoltarea software pentru Android a fost continuată într o ramură privată. În scopul de a face acest software public, a fost creată o ramură oglindă read only, cunoscută sub numele unui desert, anume cupcake. Se crede că numele vine de la Marissa Mayer (vicepreședinte la Google), care are o pasiune pentru acesta. Cupcake este în mod obișnuit interpretat greșit ca numele unei actualizări, dar după cum este declarat pe situl de dezvoltare al Google: Cupcake [ ] este o ramură de dezvoltare, nu o versiune stabilă. Modificări notabile la software ul Android introduse în cupcake includ modificări la download manager, platformă, Bluetooth, software ul de sistem, radio și telefonie, instrumente de dezvoltare, sistemul de dezvoltare și câteva aplicații, precum și o serie de remedieri de probleme. Și alte versiuni Android au fost numite după deserturi: donut, eclair, gingerbread etc. 30

31 2.2 MIT (Google) App Inventor Google App Inventor este un limbaj de programare vizuală inițiat de Google și preluat de MIT din Acesta este conceput pentru utilizatorii obişnuiţi, fără cunoştinţe speciale de programare și permite crearea unor aplicații pentru sistemul de operare Android. Pentru a interacţiona într un mod cât mai simplu cu utilizatorul, programul a fost conceput vizual: pentru a crea o aplicaţie, utilizatorul desenează vizual modul în care aplicația va arăta și folosește blocuri pentru a specifica comportamentul aplicației lui. App Inventor folosește o interfaţă grafică, foarte asemănătoare cu interfaţa de utilizator de la Scratch şi StarLogo TNG, care permite utilizatorilor să așeze obiectele vizuale pentru a crea o aplicație, care poate rula pe sistemul Android sau alte sisteme. Raţionamentul este că, dacă tinerii dezvoltă aplicația, o vor face pentru a şi îndeplini propriile necesități cu ajutorul telefonului mobil. (23) Prin crearea lui App Inventor pentru Android, Google a făcut cercetări semnificative prealabile în programarea educațională. Editorul de blocuri folosește biblioteca Java Open Blocks pentru crearea de limbaje de programare cu blocuri vizuale. Open Blocks este distribuit de Massachusetts Institute of Technology Scheller Teacher Education Program (STEP) şi provine din dizertația de master a lui Ricarose Roque. Profesorul Eric Klopfer şi Daniel Wendel din Programului Scheller au sprijinit distribuirea Open Blocks sub licenţă MIT. Blocurile de programare vizuală sunt strâns legate de TNG Star Logo, proiectul STEP al lui Klopfer lui şi Scratch un proiect al MIT Media Laboratory Lifelong Kindergarten Group. Aceste proiecte sunt ele însele susținute de către teoriile constructive de învăţare, care subliniază că programarea poate fi un vehicul pentru angajarea de idei puternice prin învăţare activă. Ca atare, aceasta este parte a unei mişcări în curs de desfăşurare în computere şi educaţie, care a început cu munca lui Seymour Papert şi MIT Grupul Logo în anii Compilator care traduce limbajul vizual al blocurilor pentru implementarea pe sistemul Android foloseşte cadrul de lucru al limbajului de programare Scheme şi dialectul Kawa, dezvoltat de Per Bothner şi distribuit ca parte a sistemului de operare GNU Free Software Foundation. În august 2011 Google a anunțat că App Inventor nu va mai fi un produs Google, ci parte a MIT Center for Mobile Learning din cadrul MIT Media Lab, condus chiar de creatorul App Inventor, Hal Abelson Ce se poate face cu App Inventor? App Inventor permite, ca orice mediu vizual, crearea de aplicaţii pentru Android fără a scrie cod de program, prin crearea aplicației și specificarea comportamentului său prin configurarea de blocuri. Echipa App Inventor a creat blocuri pentru aproape orice se poate face cu un telefon Android, precum şi blocuri pentru a face aproape programare: variabile pentru memorare, blocuri for şi while pentru repetarea operaților şi condiţii (blocuri, if ), astfel încât aplicația să poată să pună întrebări şi să se ghideze pe răspunsuri. Există chiar şi blocuri pentru a stoca informaţiile într o bază de date şi conexiune la servicii online, precum Twitter. Se poate construi aproape orice aplicație imaginabilă cu App Inventor: jocuri, aplicații informaţionale cu datele generate de utilizatori, aplicații personale, aplicații pentru a ajuta oamenii să comunice, aplicaţii care folosesc senzorii telefonului şi chiar aplicaţii care se conectează la rețele de socializare. Astfel, pe lângă aplicaţiile de pe telefonul personal sau cele din Android Market, pot fi create aplicații personalizate. 31

32 O modalitate de a începe programarea cu App Inventor o constituie realizarea de jocuri. Se poate folosi chiar și senzorul de orientare al telefonului pentru a construi, spre exemplu, un joc în care se mișcă o minge printr un labirint în timp ce jucătorul înclină telefon. Dar App Inventor nu este doar pentru a construi jocuri. Se poate utiliza, de asemenea, pentru a construi software uri educaţionale: chestionare şi alte aplicaţii care permit unui utilizator să înainteze printr o secvenţă de informaţii. Se pot crea aplicații test pentru diverse studii. Se pot adăuga la aceste chestionare toate sunetele dorite, utilizând componenta Music Player, sau componenta video pentru a crea un test care arată clipuri din filmele preferate. Cu componenta TextToSpeech s ar putea programa telefonul să pună întrebări sau să răspundă cu voce tare. Aplicațiile construite nu trebuie neapărat să se bazeze pe date fixe, dar pot stoca, în loc de date fixe, date generate de utilizatori într o bază de date. Astfel, se poate crea o aplicație antrenament care permite utilizatorului să introducă numărul de abdomene făcute în fiecare zi, sau se poate modifica o aplicație test astfel încât întrebări noi pot fi create din zbor. Deoarece App Inventor oferă acces la un senzor pentru locație prin GPS, se pot construi, de asemenea, aplicații de orientare în spațiu. Se pot scrie aplicații care să utilizeze funcţionalități ale telefonului cu Android. De exemplu, o aplicație care periodic trimite anumite texte, sms uri, sau o aplicație cu titlul Nu trimit sms în timp ce conduc, care răspunde la toate sms urile automat cu Îmi pare rău, eu sunt la volan și vă voi contacta mai târziu. Se pot crea chiar aplicații de citit sms urile primite cu voce tare. Nu în ultimul rând, App Inventor este prevăzut cu componente care permit aplicaţiilor să comunice cu Internetul. TinyWeb DB este o componentă mult mai generală pentru comunicarea cu serviciile de web, astfel încât se poate utiliza App Inventor pentru a scrie Android front end uri care vorbesc cu siturile preferate. De exemplu, un programator ar putea scrie o aplicație web în App Inventor pentru accesarea datelor de pe situl Amazon, o aplicație de navigare prin librărie care să permită vizualizarea preţului unei cărți. Nu se pot construi chiar orice fel de aplicații cu App Inventor. Acest instrument oferă, totuși, un număr limitat de componente de nivel înalt şi nu oferă acces la toate funcţionalităţile definite în setul Android (care este accesibil prin intermediul limbajului de programare Java, prin SDK Android). Dar se pot construi mai multe aplicaţii doar cu instrumente şi componenta TinyWebDB care oferă o punte de legătură pentru mai multe elemente de calcul complexe şi servicii web, astfel încât App Inventor poate fi folosit în colaborare cu programatori back end Capacități și limitări Capacităţile App Inventor includ: accesul la cea mai mare parte a funcționalităților telefonului: convorbiri telefonice, mesaje text SMS, senzori de locație, orientare şi accelerare, funcția text to speech sau recunoaşterea vorbirii, sunet, video. capacitatea de a invoca alte aplicații, cu componenta ActivityStarter programare de control ca într un limbaj textual. Există blocuri pentru condiționare (if, if else), foreach şi o listă destul de cuprinzătoare de blocuri de matematică și logică. baza de date de acces, atât pe dispozitiv, cât şi pe web accesul la surse de informare web (API) 32

33 În ceea ce privește limitările App Inventor, acestea sunt: interfață cu utilizatorul limitată: constructorul interfeței cu utilizator s a îmbunătățit, dar este încă un pic defectuos și limitat, astfel încât nu se poate construi orice interfaţă de utilizator. De exemplu, nu pot fi create aplicații cu ecrane multiple şi care să permită schimbări în orientarea ecranului. Aceste probleme nu sunt fundamentale pentru proiectarea App Inventor şi vor fi în curând rezolvate. acces limitat la funcțiile aparatului: nu există componente pentru toate datele şi funcționalitățile telefonului. De exemplu, nu se pot salva şi prelua fişiere din sistem şi există doar un acces limitat la lista de contacte (nu se pot crea grupuri). acces limitat la Web: pot fi accesate doar API uri care să urmeze un protocol special (API App Inventor compatibile). nu există componente polimorfe: funcțiile blocurilor sunt legate de componentele specifice și nu există nici o modalitate de a apela funcții pe o componentă generică. De exemplu, dacă se creează o procedură MutaXY, ea trebuie să fie legată de o imagine specifică, nu de o imagine generală. accesul limitat la Android Market: aplicațiilor generate de App Inventor le lipsește configurarea necesară pentru includerea direct pe piață. Cu toate acestea, există în prezent o soluție pentru publicarea pe piață Modul de lucru App Inventor a fost conceput pentru a dezvolta aplicaţii pentru telefoanele cu Android, folosind un browser web şi un telefon conectat la Internet sau emulatorul (Fig. 1.26). Serverele App Inventor stochează aplicațiile dezvoltate şi oferă, de asemenea, o formă a managementului versiunilor dezvoltate, prin urmărirea modificării (change tracking). Practic, aceasta înseamnă că mediul de programare face uz de metoda numită cloud computing utilizatorul/programatorul folosește computerul său doar să se conecteze la Internet şi la server şi utilizează serverul cu resursele lui partajate spaţiu de stocare sau chiar puterea de procesare. Aplicaţiile pot fi construite în App Inventor astfel: în App Inventor Designer, sunt selectate componentele care vor alcătui aplicația în App Inventor Blocks Editor, blocurile din program sunt asamblate pentru a specifica modul în care componentele trebuie să se comporte. Se pot asambla programele vizual, montând piesele împreună, ca piesele unui puzzle. Aplicația apare pe telefon pas cu pas, pe măsură ce piesele sunt adăugate în ea, aşa că poate fi testată în timp ce este construită. Când e gata, poate fi ambalată pentru a produce o aplicaţie de sine stătătoare care ulterior se poate instala. Dacă nu este disponibil un telefon cu Android, aplicațiile pot fi rulate cu ajutorul emulatorului Android, un software care rulează pe calculator şi se comportă exact ca pe telefon. Mediul de dezvoltare App Inventor poate rula pe Mac OS X, GNU/Linux, sistemele de operare Windows, şi pe modele de telefon deja populate cu Android. Aplicațiile create cu App Inventor pot fi 33

34 instalate pe orice telefon Android. Înainte ca App Inventor să fie folosit, este necesară instalarea pachetului App Inventor pentru computer. Fig Mediul de dezvoltare App Inventor Pentru a putea lucra cu App Inventor, sunt absolut necesare o conexiune la Internet și un cont Gmail. Cu un browser web se navighează la pagina (App Inventor clasic disponibil până în toamna lui 2014) sau la (App Inventor 2) unde se cere logarea cu contul Gmail. Ceea ce se deschide este App Inventor Designer (Fig App Inventor Designer), unde se creează proiectele și se adaugă componentele viitoarei aplicații. Pentru a stabili comportamentul aplicației, este necesară pornirea editorului de blocuri (Blocks Editor), care se va deschide conform cu (Fig. 1.28), dacă este instalată, în prealabil, Java Selectarea componentelor pentru crearea de aplicații Componentele App Inventor sunt situate pe partea stângă a ecranului Designer (Fig App Inventor Designer), sub titlul Palette și sunt elementele de bază care pot fi utilizate pentru a face aplicații pentru telefon cu Android. Unele componente sunt foarte simple, ca Label, care arată doar textul de pe ecran, sau o componentă buton care se apasă pentru a iniţia o acţiune. Alte componente sunt mai elaborate: o pânză de desen, care poate conţine imagini statice sau animații, un accelerometru (senzor pentru mişcare), care funcţionează ca un controler Wii şi detectează deplasarea sau scuturarea telefonului, componentele care fac sau trimit mesaje text, componente care rulează muzică şi video, componente care obţin informaţii de la situri web etc. 34

35 Fig App Inventor Designer Pentru a utiliza o componentă în aplicație, aceasta se selectează printr un clic şi se trage pe mijlocul Designer ului. După adăugare, componenta va apărea și în lista de componente, pe partea dreaptă a afișorului. Componentele au proprietăţi care pot fi ajustate pentru a schimba modul în care aceasta apare în aplicație. Pentru a vizualiza şi modifica proprietăţile unei componente, ea trebuie selectată, mai întâi, din listă. Fig App Inventor Blocks Editor Deschiderea editorului de blocuri și pornirea emulatorului Designer ul este unul dintre cele trei instrumente cheie folosite în crearea de aplicații. Al doilea este editorul de blocuri, utilizat pentru a atribui comportamente componentelor, cum ar fi ceea ce ar trebui să se întâmple atunci când utilizatorul apasă un buton. Editorul de blocuri (Fig. 1.28) se rulează într o fereastră separată. La deschiderea editorului de blocuri din fereastra Designer, un fișier care 35

36 permite computerului să comunice cu un dispozitiv conectat va fi descărcat şi ar trebui să se deschidă în mod automat. Acest proces poate dura 30 de secunde sau mai mult. În cazul în care nu se deschide editorul, atunci s ar putea ca browser ul să nu fie configurat pentru a rula aplicaţii descărcate în mod automat. În acest caz, se deschide fişierul descărcat numit AppInventorForAndroidCodeblocks.jnlp. În partea stângă a ferestrei editorului există trei categorii de seturi de blocuri (pallete): Built in, My Blocks (unde vor apărea blocurile adăugate în Designer) și Advanced. Când se acționează un set, printr un clic de maus, vor fi vizibile blocurile stocate în acea zonă. Categoria Built in conține setul standard de blocuri necesare pentru orice aplicație (text, liste etc.). Categoria Advanced conține blocuri pentru realizarea unor aplicații mai avansate, cu o logică mai complexă. Designer ul rulează în browser, iar editorul rulează folosind Java. Cu toate acestea, ele sunt conectate astfel încât chiar dacă se închide fereastra editorului, toate informațiile din acesta sunt salvate în Designer. Când se face click pe butonul Open the Blocks Editor, un nou fișier.jnlp este descărcat pe calculator și acesta va fi deschis. În acest fel, editorul de blocuri va conține toate blocurile care fuseseră deja programate în pași anteriori. Programatorul are posibilitatea să utilizeze un telefon sau tabletă cu Android sau un emulator. Dacă se selectează emulator (Fig. 1.29), atunci încărcarea va dura câteva minute, timp în care nu se va întreprinde nicio acțiune. După pornirea emulatorului, acesta trebuie conectat la editor, prin selectarea lui din lista disponibilă în colțul din dreapta sus. Mai departe, editorul va începe comunicarea cu emulatorul și aplicația ar trebui să apară pe emulator. Se poate folosi mausul pentru a acționa butoanele de pe emulator, dar dacă butonul nu a fost programat, atunci nimic nu se va întâmpla. Mergând mai departe, orice modificări aduse aplicației în Designer şi în editorul de blocuri, acestea vor apărea pe emulator. Fig Emulatorul App Inventor 36

37 2.2.6 Componente App Inventor Fiecare componentă poate avea metode, proprietăți și evenimente. Majoritatea proprietăților pot fi modificate de către aplicații, prin blocurile de citire și setare pe care le dețin, restul de proprietăți putând fi doar citite. În cele ce urmează sunt prezentate doar câteva categorii de componente disponibile în App Inventor. Mai multe se pot afla la (24) Componente de bază Button componentă pe care utilizatorul o apasă pentru a realiza o acțiune asociată. Butoanele detectează când sunt apăsate și își pot modifica aspectul. Proprietăți: BackgroundColor: culoare pentru fundalul butonului. Enabled: dacă este setat, butonul poate fi apăsat. FontBold: dacă este setat, textul de pe buton este bold. FontItalic: dacă este setat, textul de pe buton este italic. FontSize: dimensiunea textului de pe buton. FontTypeface: tipul fontului de pe buton. Height: înălțimea butonului (dimensiunea y). Width: lățimea butonului (dimensiunea x). Image: imagine afișată pe buton. Text: text afișat pe buton. TextAlignment: stânga, centru, dreapta. TextColor: culoarea textului de pe buton. Evenimente: Click(): utilizatorul a apăsat și a eliberat butonul. GotFocus(): butonul a devenit componenta activă LostFocus(): butonul nu mai este componenta activă. CheckBox componentă care detectează acționarea de către utilizator și își modifică starea booleană. Proprietăți: BackgroundColor: culoarea fundalului. Checked: Adevărat dacă este marcată și fals altfel. Enabled: dacă este setat, componenta poate fi acționată. Height: înălțimea casetei (dimensiunea y). Width: lățimea casetei (dimensiunea x). Text: text afișat pe casetă. TextColor: culoarea textului din casetă. Visible: dacă este setat, componenta este vizibilă Evenimente: 37

38 Click(): utilizatorul a apăsat și a eliberat caseta. GotFocus(): caseta a devenit componenta activă LostFocus(): caseta nu mai este componenta activă. Label componentă pentru afișare de text specificat de proprietatea Text. Proprietăți: BackgroundColor: culoare pentru fundalul etichetei. FontBold: dacă este setat, textul din etichetă este bold. FontItalic: dacă este setat, textul din etichetă este italic. FontSize: dimensiunea textului din etichetă. FontTypeface: tipul fontului textului din etichetă. Height: înălțimea etichetei (dimensiunea y). Width: lățimea etichetei (dimensiunea x). Text: text afișat pe etichetă. TextAlignment: stânga, centru, dreapta. TextColor: culoarea textului din etichetă. Visible: dacă este setat, componenta este vizibilă. ListPicker componentă folosită pentru ca utilizatorul să poată selecta un element dintr o listă care apare la acționarea componentei. Elementele listei pot fi specificate în proprietatea ElementsFrom String sub forma (selecție1, selectie2, selectie3), sau dintr o listă externă prin setarea proprietății Elements la o listă List în editorul de blocuri. Proprietăți: Selection: elementul selectat din listă. Items: listă de elemente separate prin virgulă. ElementsFromString: folosirea listei de elemente. BackgroundColor: culoare pentru fundalul listei. FontBold: dacă este setat, textul din listă este bold. FontItalic: dacă este setat, textul din listă este italic. FontSize: dimensiunea textului din listă. FontTypeface: tipul fontului textului din listă. Height: înălțimea listei (dimensiunea y). Width: lățimea listei (dimensiunea x). Text: text afișat în listă. TextAlignment: stânga, centru, dreapta. TextColor: culoarea textului din listă. Visible: dacă este setat, componenta este vizibilă. Evenimente: AfterPicking(): Utilizatorul a selectat un element din listă. BeforePicking(): Utilizatorul a acționat lista, dar nu a selectat nimic din ea. 38

39 GotFocus(): lista a devenit componenta activă LostFocus(): lista nu mai este componenta activă. Screen nu apare în paletă ca alte componente, dar apare automat odată cu proiectul. Fiecare proiect pornește cu un ecran, numit Screen1. Acest nume nu poate fi schimbat. Ulterior se pot adăuga și alte ecrane. Proprietăți AlignHorizontal: un număr care codifică alinierea pe orizontală a conținutului ecranului. Valorile pot fi 1= aliniere la stânga, 2=centrare, 3=aliniere la dreapta. AlignVertical: un număr care codifică alinierea pe verticală a conținutului ecranului. Valorile pot fi 1= aliniere sus, 2=centrare, 3=aliniere jos. BackgroundColor: culoarea de fundal pentru ecran. BackgroundImage: o imagine care se încarcă pe fundalul a ecranului. Height: înălţimea ecranului (dimensiunea y). Icon: o imagine care poate fi utilizată ca pictogramă pentru aplicația instalată pe telefon. Aceasta ar trebui să fie PNG sau JPG; 48x48 este o dimensiune bună. În cazul folosirii altor imagini decât PNG sau JPG, de exemplu fişiere ICO, App Inventor nu va putea să împacheteze aplicația. ScreenOrientation: orientarea ecranului. Valorile posibile sunt: unspecified, landscape, portrait, sensor, user. Scrollable: opțiunea este specificată printr un checkbox în designer. Când este selectat, va exista o bară de derulare verticală pe ecran şi înălţimea aplicației poate depăşi înălţimea fizică a dispozitivului. Când nu este bifat, înălţimea aplicației va fi constrânsă la înălţimea dispozitivului. Title: titlu pentru ecran (text). Aceasta va apărea în partea stângă sus a telefonului atunci când aplicaţia rulează. O alegere normală pentru titlu este chiar titlul aplicației, dar ar putea fi altceva, sau poate fi chiar schimbat în timp ce aplicație se execută. Width: lăţimea ecranului (dimensiunea x). Evenimente: BackPressed(): apăsarea butonului de pe spatele echipamentului. Initialize(): semnalat atunci când aplicaţia începe. Acesta poate fi utilizat pentru stabilirea valorilor iniţiale şi efectuarea altor operaţiuni de configurare. ErrorOccurred(): semnalat atunci când apare o eroare. Este utilizat în prezent pentru un set limitat de erori. OtherScreenClosed(text otherscreenname, any result): închiderea unui alt ecran și returnarea controlului ecranului curent. ScreenOrientationChanged(): modificarea orientării ecranului Metode: 39

40 CloseScreenAnimation(text animtype): pregătește animația pentru închiderea ecranului curent și întoarcerea la ecranul anterior. Opțiuni valide sunt: default, fade, zoom, slidehorizontal, slidevertical și none. OpenScreenAnimation(text animtype): pregătește animația pentru trecerea la alt ecran. Opțiuni valide sunt: default, fade, zoom, slidehorizontal, slidevertical și none. TextBox componentă pentru introducerea de text. Se poate stabili o valoare inițială (în proprietatea Text), sau se poate oferi o sugestie de completare (în proprietatea Hint). Textul introdus poate avea una sau mai multe rânduri (proprietatea MultiLine). Dacă este permisă o singură linie de text, la completarea ei, tastatura se va închide automat la semnalizarea utilizatorului (apăsarea tastei Done). De regulă, casetele de text sunt folosite în combinație cu butoane, astfel încât utilizatorul să acționeze un buton când a finalizat introducerea textului. Proprietăți: BackgroundColor: culoare pentru casetă. Enabled: dacă este setat, se poate introduce text în casetă. FontBold: dacă este setat, textul din casetă este bold. FontItalic: dacă este setat, textul din casetă este italic. FontSize: dimensiunea textului din casetă. FontTypeface: tipul fontului testului din casetă. Height: înălțimea casetei (dimensiunea y). Width: lățimea casetei (dimensiunea x). Text: text afișat în casetă. TextAlignment: stânga, centru, dreapta. TextColor: culoarea textului din casetă. Visible: dacă este setat, componenta este vizibilă Hint: text pentru sugestionarea utilizatorului. Vizibil doar dacă Text nu conține nimic. MultiLine: dacă este adevărat, atunci este permisă introducerea mai multor linii. NumbersOnly: dacă este adevărat, atunci caseta acceptă ca intrări doar valori numerice Evenimente: GotFocus(): caseta a devenit componenta activă. LostFocus(): caseta nu mai este componenta activă. Metode: HideKeyboard(): ascunde tastatura. Este necesară pentru mai multe linii. La o singură linie se apasă tasta Done. TinyDB se face pentru a stoca datele care vor fi disponibile de fiecare dată când aplicaţia se execută. TinyDB este o componentă non vizibilă (adică utilizatorul nu o vede pe ecranul aplicației). Aplicațiile create cu App Inventor sunt iniţializate de fiecare dată când rulează. Dacă o aplicaţie stabileşte valoarea unei variabile şi utilizatorul închide apoi aplicația, valoarea acelei variabile nu va fi memorată data viitoare când aplicația rulează. TinyDB este un stocator de date persistent pentru 40

41 aplicație, adică datele stocate vor fi disponibile de fiecare dată când aplicaţia se execută. Un exemplu ar putea fi un joc care a salvat scorul cel mai mare, care este refăcut de fiecare dată când jocul este jucat. Instanțele de date sunt stocate în tag uri. Ulterior, se poate prelua un element care a fost stocat într un anumit tag. Dacă nu există nici o valoare depozitată într un tag, atunci valoarea returnată este textul gol. Prin urmare, pentru a vedea dacă o etichetă are o valoare stocată sub ea, se testează dacă valoarea returnată este egală cu text gol (de exemplu, o casetă text cu nici un text completat). Există doar o singură stocare de date pentru o aplicație. Dacă e nevoie de mai multe componente TinyDB, ele vor folosi aceleaşi date. De asemenea, fiecare aplicație are propriul loc de stocare. Nu se poate utiliza TinyDB pentru a muta date între două aplicaţii diferite de pe telefon. Pentru a şterge din baza de date a unei aplicaţii, de pe telefon din meniul Settings Applicaons Manage applications, se alege aplicaţia şi se apasă Clear data. Datele din TinyDB sunt persistente numai după împachetarea şi descărcarea aplicației. Dacă aplicația este în curs de dezvoltare și telefonul este conectat la PC şi se repornește aplicaţia App Inventor, sau dacă se deconectează şi apoi reconectează telefonul, baza de date va reîncepe în stare proaspătă (refresh). Acesta este cazul în care aplicația nu este doar oprită şi repornită, ci este ștearsă din telefon şi apoi reîncărcată. Proprietăți: nu are Evenimente: nu are Metode: StoreValue(text tag, valuetostore): salvează valoarea în tag, care trebuie să fie un text. Valoarea poate fi un text sau o listă. GetValue(text tag): citește valoare salvată în tag. Dacă nu e nimic, returnează textul vid Componente de tip senzor AccelerometerSensor Această componentă detectează accelerometrul dispozitivului Android care, la rândul lui, detectează scuturarea telefonului și măsoară accelerația în 3 dimensiuni. Dacă telefonul este așezat pe o suprafață plană, pe spate, accelerația Z este 9.8m/s 2. Componenta produce trei valori: XAccel: pozitiv când dispozitivul este înclinat spre dreapta (adică partea stângă este ridicată) și negativ când este înclinat spre stânga. YAccel: pozitiv când partea de jos este ridicată și negativ când partea de sus este ridicată. ZAccel: pozitiv când ecranul este orientat în sus și negativ când ecranul este orientat în jos. Proprietăți Available: dacă există accelerometru. Enabled: activarea accelerometrului. XAccel: accelerație pe dimensiunea X. YAccel: accelerație pe dimensiunea Y. 41

42 ZAccel: accelerație pe dimensiunea Z. MinimumInterval: intervalul de timp minim între scuturarea telefonului. Evenimente: AccelerationChanged(number xaccel, number yaccel, number zaccel): apelat când se modifică accelerația. Shaking(): apelat repetitiv când echipamentul este scuturat. Metode: Nu are. LocationSensor Această componentă oferă locaţia dispozitivului Android, folosind GPS ul dacă este disponibil şi o metodă alternativă altfel, cum ar fi turnuri celulare sau reţele fără fir cunoscute. LocationSensor este o componentă non vizibilă care furnizează informaţii de locație, inclusiv longitudine, latitudine, altitudine (dacă este acceptată de aparat) şi adresa. Această componentă poate oferi, de asemenea, geocodare, de conversie a unei adrese date (nu neapărat pe cea curentă) la o latitudine şi o longitudine. Pentru a funcţiona, componenta trebuie să aibă proprietatea Enabled setată pe true, iar dispozitivul să aibă activată funcția de detectare a locației. Proprietăți: Accuracy: indică nivelul de exactitate al dispozitivului Android, în metri. Altitude: altitudinea dispozitivului Android, dacă este disponibilă. AvailableProviders: lista furnizorilor de servicii disponibile, cum ar fi GPS sau de reţea CurrentAddress: adresa fizică a dispozitivului Android. Enabled: dacă este setat, informaţiile de localizare sunt disponibile. HasAccuracy: dacă este adevărat, dispozitivul Android poate raporta nivelul de precizie. HasAltitude: dacă este adevărat, dispozitiv Android pot raporta altitudinea sa. HasLongitudeLatitude: dacă dispozitivul Android poate raporta longitudinea şi latitudinea. Latitude: latitudinea dispozitivului Android. Longitude: longitudinea dispozitivului Android. ProviderLocked: dispozitivul nu va schimba furnizorul de servicii. ProviderName: furnizorul de servicii actual Evenimente: LocationChanged (number latitude, number longitude, number altitude): apelat atunci când dispozitivul Android găsește o locaţie nouă. StatusChanged(text provider, text status): apelat atunci când starea furnizorului de servicii se modifică. Metode: LatitudeFromAddress (text locationname): determină latitudinea adresei indicate. LongitudeFromAddress (text locationname): determină longitudinea adresei indicate. 42

43 OrientationSensor este o componentă ce se folosește pentru a determina spaţial orientarea telefonului. Acesta este o componentă non vizibilă care raportează următoarele trei valori, în grade: Roll: 0 atunci când dispozitivul este drept, crescând la 90 când dispozitivul este înclinat cu partea de sus spre partea stângă şi scăzând la 90 atunci când dispozitivul este înclinat cu partea de sus spre partea dreaptă. Pitch: 0 atunci când dispozitivul este drept, crescând la 90 când dispozitivul este înclinat astfel încât vârful său este îndreptat în jos, creşterea în continuare la 180 când acesta devine întors invers. În mod similar, când aparatul este înclinat astfel încât partea sa de jos este îndreptată în jos, scade la 90, apoi până la 180 pe măsură ce este răsucit tot drumul peste cap. Azimuth: 0 atunci când partea de sus a aparatului este îndreptată spre nord, la 90 atunci când este îndreptat spre est, la 180 atunci când este îndreptat spre sud, la 270 de grade atunci când este îndreptat spre vest, etc Aceste măsurători presupun că aparatul în sine nu este în mişcare. Proprietăți: Available: arată dacă senzorul de orientare este prezent pe dispozitivul Android. Enabled: dacă este setat, senzorul de orientare este activat. Azimuth: returnează unghiul de deviaţie al dispozitivului. Pitch: returnează unghiul de întoarcere peste cap al dispozitivului. Roll: returnează unghiul de rotire al dispozitivului. Magnitude: returnează un număr între 0 şi 1, care indică gradul de înclinare al dispozitivului. Mărimea dă magnitudinea forţei pe care ar simţi o o bilă pe suprafaţa de rulare a dispozitivului. Angle: returnează unghiul care spune direcţia în care dispozitivul este îndreptat. Adică, se spune direcţia forţei pe care ar simţi o o bilă pe suprafaţa de rulare a dispozitivului. Evenimente OrientationChanged(number yaw, number pitch, number roll): numit atunci când orientarea s a schimbat Blocuri din App Inventor În cele ce urmează sunt prezentate principalele tipuri de blocuri care pot fi utilizate pentru realizarea unei aplicații cu App Inventor. Materialul complet poate fi găsit la (24) Blocuri de definire procedure (procedurewithresult) grupează o secvență de blocuri care, ulterior, poate fi utilizată în mod repetat, ca apel de procedură. La crearea unei proceduri, App Inventor creează în mod automat un bloc de apel (call) care va fi plasat în zona My Definitions. Acest bloc de apel poate fi folosit pentru a invoca procedura. La crearea unui nou bloc de acest tip, App Inventor alege un nume care poate fi, ulterior, modificat. Acest nume, la nivel de aplicație, trebuie să fie unic. Fig prezintă modul de afișare al acestor blocuri. 43

44 a) b) Fig Blocuri de proceduri, fără a) și cu b) returnare de rezultat name creează un argument cu nume care poate fi utilizat la apelul unei proceduri. Argumentul procedurii se specifică prin plasarea unui astfel de bloc la intrarea arg a procedurii. Numărul de argumente nu este limitat, la completarea unuia apărând, de fiecare dată, un port nou. La specificarea unui argument, App Inventor va asocia acest argument cu blocul call generat pentru procedură: sloturile pentru argumente ale blocului de apel vor vizualiza numele argumentelor. Pentru fiecare bloc name definit, App Inventor creează un bloc value asociat și îl plasează în zona My Definitions. Aceste blocuri vor fi folosite pentru referirea la valori la apelul procedurilor. variable creează o valoare care poate fi modificată pe parcursul rulării aplicației și dă un nume pentru această valoare. Variabilele sunt globale și pot fi folosite oriunde în aceeași aplicație. Numele variabilei trebuie să fie unic. Fig prezintă modul de afișare a blocurilor name și variable. a) b) Fig Bloc de tip nume a) și bloc de tip variabilă b) Handler de evenimente Programele App Inventor descriu cum ar trebui se comporte telefonul în anumite circumstanțe: un buton a fost apăsat, telefonul a fost scuturat etc. Aceste acțiuni specifice sunt descrise de un handler de evenimente care începe cu cuvântul when. Majoritatea handler elor au culoare verde. Fig Handler de evenimente Evident, când un eveniment apare, handler ul asociat va fi executat Comenzi și expresii Când este executat un handler de evenimente, de fapt se rulează o secvență de comenzi din corpul său. O comandă este un bloc care specifică o acțiune care va fi realizată pe telefon. Majoritatea comenzilor sunt mov sau albastre. 44

45 Fig Exemplu de comenzi Anumite comenzi au nevoie de una sau mai multe valori de intrare (cunoscute și sub numele de parametrii sau argumente) pentru a și putea realiza acțiunea. Spre exemplu (Fig. 1.33), Sound1.Vibrate are nevoie de un timp de vibrare, în milisecunde. Nevoia unui parametrul este marcată de socket ul din partea dreaptă a comenzii. Socket ul poate primi valori și de la o expresie, adică blocuri cu valori. Blocurile de expresii au un capăt de prindere în partea stângă, prin care își transmit valoarea socket ului. Pot fi construite expresii foarte complexe folosind expresii mai simple, prin compunere orizontală (Fig. 1.34). Fig Expresii Forma comenzilor este astfel realizată, încât ele se pot compune pe verticală într o stivă de comenzi. De fapt, aceasta este o comandă complexă compusă din comenzi mai simple. Fig Comenzi compuse Dacă o astfel de stivă este plasată în handler ul unui eveniment, comenzile vor fi executate de sus în jos. Spre exemplu, în Fig telefonul va emite un sunet, apoi va vibra, apoi eticheta își va schimba culoarea și va afișa textul specificat. Dat fiind faptul că execuția are lor foarte repede, toate acțiunile au loc aproape simultan Aranjarea elementelor pe ecran Implicit, componentele sunt aranjate pe verticală. Dacă se dorește modificarea acestui mod de aranjare, atunci se poate folosi una dintre componentele HorizontalArrangement, VerticalArrangement sau TabletArrangement din secțiunea ScreenArrangement. 45

46 Manipularea stării componentelor Fiecare componentă este caracterizată de numeroase proprietăți. Valorile curente ale acestor proprietăți reprezintă starea componentei. Un program App Inventor poate determina și schimba starea oricărei componente prin blocuri specifice de tip getter și setter (exemplu pentru etichetă). Fig Getter e și setter e pentru etichetă Evenimente ale butoanelor Cel mai frecvent eveniment legat de butoane este Click. Alte evenimente asociate sunt LongClick, GetFocus și LostFocus. Majoritatea componentelor primesc focusul când sunt atinse și îl pierd când nu mai sunt atinse. Butonul este special pentru că, atunci când este atins, lansează evenimentul Click Comentarii O parte importantă din munca de programare o constituie realizarea unei documentații. App Inventor permite încorporarea de comentarii chiar în cod care explică diverse elemente și aspecte ale codului. Adăugarea unui comentariu pentru blocuri se face cu clic dreapta pe bloc (Fig. 1.37). Fig Adăugarea de comentarii Exemplu de realizare a unei aplicații cu App Inventor. În continuare, este prezentată realizarea unui joc (Fig. 1.38) în cadrul căruia utilizatorul are pe ecran o poartă de fotbal, o minge, un indicator de forță a șutului, un indicator de direcție și un portar. Scopul jocului este de a înscrie gol, având mingea în punctul de 11 m. Portarul, direcția și forța sunt în continuă mișcare, fiecare având viteze diferite. Portarul se mișcă pe linia porții efectuând o cursă completă, care se repetă până când mingea ajunge la el, sau mingea intră în poartă, sau mingea trece pe lângă poartă. Utilizatorul are la dispoziție două butoane: unul pentru a șuta, iar celălalt pentru a repune mingea pe punctul de la 11 m. În funcție de indicatorul de forță și de direcție, mingea va merge mai repede sau mai încet, respectiv mai la stânga sau mai la dreapta. În momentul în care mingea intră în poartă este afișat mesajul GOOOOL, când mingea este prinsă de portar, mesajul, iar când mingea trece pe lângă poartă, mesajul Ce ratare. 46

47 Elemente vizuale Terenul de fotbal este reprezentat de un element Canvas al cărui fundal este o imagine cu extensia.jpg ce conține, în partea superioară, poarta de fotbal, imaginată într o manieră tridimensională, punctul de la 11 m, de unde se va executa lovitura de pedeapsă și două marcaje folosite pentru orientarea direcției și stabilirea forței șutului. Portarul este reprezentat printr un element de tipul ImageSprite, având ca fundal o imagine sugestivă a unui portar, după cum se poate observa în Fig Portarul se mișcă pe orizontală, între barele porții, cu viteza constantă. Mingea este reprezentată printr un control de animație de tip Ball, având dimensiunea 5 și culoarea inspirată din jocurile de fotbal, galbenă. Fig Joc realizat cu App Inventor Indicatorul de direcție (Fig. 1.39) si indicatorul pentru forța șutului (Fig. 1.40) sunt realizați tot cu controale de animație de tipul Ball. Aceștia execută o mișcare în plan orizontal, respectiv vertical, iar limitele sunt evidențiate prin indicatoarele din fundal. Butonul Shoot este folosit pentru a lansa mingea către poartă. Aceasta va avea direcția dată de indicatorul de direcție și forța dată de indicatorul de forță al șutului. Butonul Retry repune mingea pe punctual de la 11 m, pentru a se putea efectua un nou șut pe poartă Stabilirea acțiunii Acțiunea jocului este realizată foarte simplu și constă în sincronizarea a patru ceasuri. Ceasul utilizat pentru mișcarea portarului are intervalul setat la 100 milisecunde. Poziția portarului are ordonata constantă, de valoare 40, în sistemul de coordinate carteziene cu originea în colțul din stânga sus. Abscisa variază între 104 și 186, bazat pe dimensiunea porții, simulând perfect realitatea. Incrementarea si decrementarea abscisei se face cu un pas de 3 pixeli, astfel încât, într o cursă completă, portarul să acopere suprafața întregii porți. 47

48 Fig Indicator de direcție Fig Indicator pentru forța șutului Fig Stabilirea poziției portarului 48

49 Fig descrie modul de programare al ceasului portarului. Poziția portarului este stabilită de valoarea curentă a variabilei globale pozg. La fiecare pas, se verifică dacă mișcarea este spre stânga sau spre dreapta (dată de valoarea variabilei globale wayg) și dacă, după ajustarea corespunzătoare a poziției portarului, acesta este între limitele admise. Fig Stabilirea forței șutului Fig Determinarea direcției mingii Forța șutului este dată de poziția bilei albastre din Fig Acest indicator are abscisa fixă, cu valoarea 306, iar ordonata variabilă, cu valori între 302 și 225. Intervalul este împărțit în 11 părți, viteza 49

50 fiind incrementată cu pas egal de la poziția 302 spre 255, și decrementată invers. Fig descrie modul de programare al ceasului asociat forței șutului. Poziția bilei este stabilită de valoarea curentă a variabilei globale Ball3.y. La fiecare pas, se verifică dacă mișcarea este în sus sau în jos (dată de valoarea variabilei globale wayy) și dacă, după ajustarea corespunzătoare a poziției bilei, acesta este între limitele admise. Indicatorul de direcție a mingii este programat similar cu cel de stabilire a forței șutului, folosind un ceas pentru a realiza mișcarea orizontală între punctele 236 si 306, ordonata 320. Intervalul este împărțit la 17, rezultând, astfel, o viteză diferită de deplasare față de indicatorul de forță a șutului. Dacă butonul Shoot este apăsat când bila se află în centrul intervalului, aceasta va fi șutată perpendicular pe direcția porții. Cu cât abaterea este mai mare față de centrul intervalului, cu atât mingea se va deplasa mai la stânga sau mai la dreapta față de centrul porții. Mingea se deplasează între pozițiile 103 și 190 pe abscisă și 50 și 306 pe ordonată. Viteza este dată de indicatorul de viteză, în timp ce direcția este influențată atât de indicatorul de direcție, cât și de șut (Fig. 1.43). La fel cum în realitate, un șut puternic este mai puțin plasat, și în cadrul acestui joc un șut cu viteză mai mică va avea șanse mai mari de a nimeri direcția porții. În cazul în care între minge și portar există coliziune, jocul se încheie cu mesajul Saved (Fig. 1.44). Dacă mingea intră în poartă, mesajul este GOOOOOL, iar dacă mingea trece pe lângă poartă, va fi afișat mesajul Ce ratare (Fig. 1.44). Fig Rezultatele posibile Metoda CollidedWith a componentei de tip ImageSprite, care implementează portarul, surprinde momentul în care mingea se ciocnește de portar (Fig. 1.45). În acest caz, sunt oprite toate ceasurile și se afișează pe ecran mesajul corespunzător. Evident, fiecare buton are asociată o acțiune proprie. Apăsarea butonului este surprinsă de metoda Click asociată acestuia. Butonul Retry aduce jocul în stare inițial. Ca urmare, va opri ceasul mingii, va porni celelalte trei ceasuri (pentru portar, direcție și forță) și va pune mingea la poziția punctului de 11 m. Butonul Shoot, va opri ceasurile direcției și forței, va determina direcția de deplasare și va 50

51 porni ceasul mingii. Fig prezintă, în detaliu, modul în care cele două butoane au fost programate. Fig Portarul prinde mingea Fig Acțiunile asociate celor două butoane 51