ProgramareVizualăCurs I n g i n e r i a S i s t e m e l o r
Dr.ing. Loredana STANCIU, PhD
Programare Vizuală
Pagina2
Cuprins
1 PROGRAMAREA VIZUALĂ ..................................................................................................................... 3
1.1 INTRODUCERE ........................................................................................................................................ 3
1.2 ISTORIC ................................................................................................................................................ 5
1.3 STRATEGII ÎN PROGRAMAREA VIZUALĂ ........................................................................................................ 6
1.4 CLASIfiCAREA LIMBAJELOR DE PROGRAMARE VIZUALĂ ..................................................................................... 8
1.5 TEORIA LIMBAJELOR DE PROGRAMARE VIZUALĂ ............................................................................................ 9
1.5.1 Specificarea formală a Limbajelor de Programare Vizuală ........................................................... 10
1.5.2 Analiza Limbajelor de Programare Vizuală .................................................................................. 11
1.6 PROBLEMELE LIMBAJELOR VIZUALE ............................................................................................................ 12
1.6.1 Controlul fluxului.......................................................................................................................... 12
1.6.2 Abstractizarea procedurală .......................................................................................................... 12
1.6.3 Abstractizarea datelor ................................................................................................................. 13
1.7 EXEMPLE DE LIMBAJE DE PROGRAMARE VIZUALĂ .......................................................................................... 13
1.7.1 Chimera. Programarea vizuală imperativă prin demonstrație ...................................................... 13
1.7.2 Forms/3. Programarea vizuală bazată pe foi de calcul tabelar .................................................... 16
1.7.3 Prograph. Programarea vizuală cu fluxuri de date ....................................................................... 18
1.7.4 KidSim/Cocoa. Programarea vizuală bazată pe reguli .................................................................. 19
1.7.5 Cube. Limbaje de programare vizuală 3D ..................................................................................... 23
1.8 PROGRAMAREA VIZUALĂ ȘI ABSTRACTIZAREA ............................................................................................... 24
1.9 CONCLUZII PRIVIND PROGRAMAREA VIZUALĂ ............................................................................................... 24
2 MODELARE CU APP INVETOR ............................................................................................................. 26
2.1 SISTEMUL DE OPERARE ANDROID .............................................................................................................. 26
2.1.1 Scurt istoric .................................................................................................................................. 26
2.1.2 Caracteristici ................................................................................................................................ 27
2.1.3 Evoluția sistemului Android și impactul său pe piață .................................................................... 28
2.1.4 Arhitectura Android ..................................................................................................................... 28
2.1.5 SDK‐ul Android ............................................................................................................................. 30
2.2 MIT (GOOGLE) APP INVENTOR ................................................................................................................ 31
2.2.1 Ce se poate face cu App Inventor? ............................................................................................... 31
2.2.2 Capacități și limitări ..................................................................................................................... 32
2.2.3 Modul de lucru ............................................................................................................................. 33
2.2.4 Selectarea componentelor pentru crearea de aplicații ................................................................. 34
2.2.5 Deschiderea editorului de blocuri și pornirea emulatorului .......................................................... 35
2.2.6 Componente App Inventor ........................................................................................................... 37
2.2.7 Blocuri din App Inventor ............................................................................................................... 43
2.2.8 Exemplu de realizare a unei aplicații cu App Inventor. ................................................................. 46
3 BIBLIOGRAFIE .................................................................................................................................... 52
Programare Vizuală
Pagina3
1 ProgramareaVizuală
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 pro‐
grame 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 pro‐
grame (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ți‐
nă 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 ma‐
nipulare directă (Direct Manipulation) nu fac decât să mărească distanța dintre utilizator și progra‐
mator î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 ani‐
lor ’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 secun‐
dă, 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).
47 42 93 122 68 85 105 133 137
58 100 95 46 126 133 181 108 68 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.
Programare Vizuală
Pagina4
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 lu‐
mea î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 tran‐
smite 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 specifica‐
rea 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ă unidimensio‐
nală. Astfel, multidimensionalitatea este principala diferență dintre LPV‐uri și limbajele strict textua‐
le.
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 progra‐
mare 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 LPV‐
uri î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)
Programare Vizuală
Pagina5
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 calculato‐
rul TX‐2 la MIT, a fost considerat prima aplicație de grafică pe calculator. Sistemul permitea utilizato‐
rilor să lucreze cu un creion cu lumină pentru a crea grafice 2D prin combinarea unor primitive sim‐
ple, 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 utili‐
zator 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 Da‐
vid 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 defi‐
nite pentru a realiza calcule. De atunci s‐au adus multe îmbunătățiri acestei metode, însă multe LPV‐
uri î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 mo‐
dul “memorare”, realiza calculele de interes, reseta modul de memorare și primea ca ieșire un pro‐
gram 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 vizua‐
le 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 avan‐
taje 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 folo‐
sire 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
Programare Vizuală
Pagina6
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 crea‐
rea și/sau vizualizarea relaționărilor dintre structurile de date
folosite pentru a combina vizual unitățile programate textual pentru a construi noi progra‐
me
În curând au început să apară MPV‐uri comerciale de succes. Printre primele exemple au fost Micro‐
soft 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 dia‐
grame) 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 pen‐
tru calculatoarele personale, permiţând ca macro comenzi care ajută cu sarcini repetitive să fie de‐
duse 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înProgramareaVizuală
În ceea ce priveşte cercetarea în programarea vizuală în general şi în LPV în particular, există o păre‐
re greşită precum că acestea au drept scop eliminarea textului. În fapt, majoritatea LPV‐urilor includ
Programare Vizuală
Pagina7
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 expri‐
mat (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 fo‐
losind 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 calcu‐
latoare î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ă seman‐
tică 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 reprezin‐
tă 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 pro‐
gramatorului. Un exemplu în acest sens îl reprezintă diagramele de tip entita‐
te‐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 ca‐
re 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‐
Programare Vizuală
Pagina8
tatea de recalculare automată a foilor de calcul tabelar suportă acest nivel de timp
de răspuns.
o 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 ma‐
us, asigurând în orice moment acuratețea dintre datele afișate și starea curentă a
sistemului pe tot parcursul rulării.
1.4 ClasificareaLimbajelordeProgramareVizuală
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 pen‐
tru cercetători, care vor putea găsi mai ușor lucrări asemănătoare, ci asigură și o bază pentru compa‐
rarea ș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 clasifica‐
re 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 di‐
rect 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ă catego‐
rie 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ă particula‐
ră 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.
Programare Vizuală
Pagina9
Pe lângă aceste două categorii majore, numeroase LPV‐uri sunt clasificate într‐o varietate de ramifi‐
caț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 con‐
strâ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 utiliza‐
tori. Thinglab și ARK, ambele LPV‐uri de simulare, reprezintă exemple de limbaje bazate pe constrân‐
geri.
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 limba‐
je speciale pentru aplicațiile unor anumite domenii.
Domeniul programării vizuale s‐a dezvoltat foarte mult în ultimii ani. Dezvoltarea continuă și rafina‐
rea limbajelor din categoriile menționate mai sus au dus la unele rezultate care au fost inițial consi‐
derate 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 progra‐
melor ș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, componen‐
te vizuale, dar acestea sunt, mai degrabă, aplicații grafice sau generatoare de șabloane decât limbaje
de programare. (3)
1.5 TeoriaLimbajelordeProgramareVizuală
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 par‐
tea 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ă.
Programare Vizuală
Pagina10
analiză semantică (interpretare spațială): analiza unei propoziții iconice pentru determina‐
rea sensului de bază.
Detaliile care urmează sunt restrânse la limbajele vizuale 2D, dar tot ce este expus poate fi generali‐
zat pentru 3D (sau mai mult).
1.5.1 SpecificareaformalăaLimbajelordeProgramareVizuală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 preci‐
zată 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ă (nota‐
tă 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ă obiec‐
te formate printr‐o aranjare spațială a icoanelor obiect elementare). De fapt, termenul icoane ele‐
mentare 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
Programare Vizuală
Pagina11
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țio‐
narul 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 precizea‐
ză modul în care icoanele obiect compozite pot fi construite din icoane elementare folosind opera‐
tori 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 lim‐
bajului. 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.
1.5.2 AnalizaLimbajelordeProgramareVizuală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 com‐
puse din pixeli. Aceste gramatici descoperă structura unei propoziţii vizuale compunând pi‐
xelii î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 subdiviza‐
rea ş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 cunos‐
cute.
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 vede‐
re computațional.
Arborele de analiză determinat printr‐una dintre metodele enunțate anterior este analizat ulterior
folosind metode tradiționale de analiză semantică.
Programare Vizuală
Pagina12
1.6 Problemelelimbajelorvizuale
Î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ă).
1.6.1 ControlulfluxuluiLa 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ă con‐
trolul pe parcursul programului. Un avantaj particular al acestei metode îl reprezintă faptul
că asigură o reprezentare vizuală efectivă a paralelismului. Dezavantaj este faptul că pro‐
gramatorul trebuie să fie atent la modul în care secvențierea operațiilor modifică starea pro‐
gramului, 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 tre‐
buie calculată prima. Astfel, încă este prezentă secvențierea operațiilor, dar ea trebuie dedu‐
să de către sistem și nu definită de programator. În acest caz, sistemul are de rezolvat pro‐
blema dependențelor circulare, care trebuie detectate și semnalizate ca eroare.
1.6.2 Abstractizareaprocedurală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ține‐
rea 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 (inclu‐
zâ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.).
Programare Vizuală
Pagina13
1.6.3 AbstractizareadatelorFacilităț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 pro‐
gramare 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 Exempledelimbajedeprogramarevizuală
În această secțiune vor fi prezentate câteva exemple de LPV‐uri pentru a demonstra câteva modali‐
tăți prin care au fost implementate strategiile prezentate anterior.
1.7.1 Chimera.ProgramareavizualăimperativăprindemonstrațieChimera 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 pro‐
gramă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 ma‐
nipulă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. 1.5.
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 co‐
menzii (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.
Programare Vizuală
Pagina14
Fig. 1.5 Programarea prin demonstrație în Chimera. În acest exemplu, utilizatorul a desenat o cutie cu o săgeată indi‐câ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 pa‐
nelurile incluse. Panelul doi se deschide în primele două paneluri prezentate în Fig. 1.6. 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 ape‐
lează 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
Programare Vizuală
Pagina15
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 co‐
menzile 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. 1.5. 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, generaliza‐
rea 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. 1.7. Se creează inițial cele
două dreptunghiuri (panelurile 1 și 2), după care se activează liniile pentru aliniere de 0 și 90 de gra‐
de (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 selec‐
tează 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ă proce‐
dura î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 paneluri‐
le, 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 istoricu‐
lui 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.
Programare Vizuală
Pagina16
Fig. 1.9 Fereastra de invocare a unui macro
Chimera folosește inferența pentru determinarea versiunii generalizate a unui macro. Folosirea infe‐
renț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 demon‐
strație care nu folosesc inferența și un exemplu este Cocoa.
1.7.2 Forms/3.ProgramareavizualăbazatăpefoidecalcultabelarForms/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ă para‐
digmă 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 încas‐
trate î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. 1.10 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 30 30“)
Forms/3 este un limbaj Turing complet. Scopul lui este să mărească domeniul de utilitate al concep‐
tului de foi de calcul tabelar prin suportul funcționalităților avansate necesare pentru programare.
Programare Vizuală
Pagina17
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 defi‐
nite prin formule, iar o instanță a unui tip să fie valoare a unei celule, care poate fi referită ca o celu‐
lă. Î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. Facili‐
tatea „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 meca‐
nismul de manipulare directă pentru specificarea elementului grafic, deoarece programatorul de‐
monstrează 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.
1.7.2.1 ExempludecalculalarieiunuipătratînForms/3Fereastra 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. 1.11 Fereastra principală a Forms/3
Fig. 1.12 Caseta de dialog pentru New Form
După deschiderea formularului Area_box creat anterior (Fig. 1.13), se selectează butonul de intro‐
ducere 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 introdu‐
ce 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ă bu‐
tonul asociat tabului formulei pentru celulă. Va apărea un câmp unde se tastează formula (Fig. 1. 14),
Programare Vizuală
Pagina18
î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 valo‐
rile afectate sunt reafișate în mod automat.
Fig. 1.13 Formular conținând o celulă nouă
Fig. 1. 14 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. 1.15 Formularul finalizat pentru calculul ariei pătratului
1.7.3 Prograph.ProgramareavizualăcufluxuridedatePrograph a fost conceput în 1983 de către Tomasz Pietrzykowski și Philip T. Cocs (14). Cel de‐al doi‐
lea 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 simu‐
lare
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 meto‐
de. 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 repre‐
zentate și manipulate grafic.
Fig. 1.16 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.
Programare Vizuală
Pagina19
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. 1.16 Programarea prin fluxuri de date în Prograph. Programatorul folosește operații de nivel scăzut (primitive) pen‐tru 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 pro‐
gramului. 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.
1.7.4 KidSim/Cocoa.ProgramareavizualăbazatăpereguliCocoa (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 com‐
plet, doar că facilitățile lui nu au fost proiectate pentru programarea de uz general, ci pentru a facili‐
ta accesul copiilor la programarea propriilor simulări.
Felul în care atributele concret și direct sunt atinse în Cocoa sunt similare cu Chimera, deoarece am‐
bele 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 vari‐
abilelor 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
Programare Vizuală
Pagina20
fiecărui caracter din scenă i se permite funcționarea conform propriilor lumi. Fig. 1.17 (16) prezintă
un ecran Cocoa tipic.
Fig. 1.17 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. 1.18 Crearea unei noi reguli
Cea mai simplă regulă este cea care mută un caracter. Fig. 1.18 (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
Programare Vizuală
Pagina21
revizuite la fiecare tact al ceasului, doar această simplă regulă este suficientă pentru deplasarea ca‐
racterului de‐a lungul plăcii.
Fig. 1.19 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. 1.19 (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. 1.20 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 carac‐
terelor, 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 carac‐
ter. Aceste proprietăți joacă rolul instanțelor din programarea orientată pe obiecte. Fig. 1.20 (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. Pen‐
tru a modifica regula, se folosește butonul Add On pentru acea regulă, care execută acțiunile asocia‐
te regulii, după care permite utilizatorului să demonstreze noi acțiuni. În acest caz, utilizatorul modi‐
fică valoarea din proprietatea hunger din 0 în 1. Sistemul generalizează această demonstrație, dân‐
du‐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 com‐
plicate.
Programare Vizuală
Pagina22
Î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 consi‐
deraț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. 1.21 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. 1.22 Function to compute the factorial of a number in Cube
Programare Vizuală
Pagina23
1.7.5 Cube.Limbajedeprogramarevizuală3DCube, 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 re‐
prezentare 2D care folosește aceleași dimensiuni ale ecranului (3). Într‐o vizualizare 3D, programato‐
rul 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. 1.23 Folosirea programului factorial, după evaluare
Fig. 1.22 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 cu‐
buri suport, cuburi predicat, cuburi de definire, porturi, conducte și planuri. Întreaga structură din
Fig. 1.22 este înconjurată de un cub de definire care asociază icoana „!“ cu funcția definită în interio‐
rul cubului. Cubul de definire are două porturi conectate la el, unul la stânga și unul la dreapta. Por‐
tul din stânga asigură intrarea, iar portul din dreapta este ieșirea, deși, tehnic vorbind, ambele por‐
turi pot asigura ambele funcții, în Cube porturile fiind bidirecționale. Cele două porturi sunt conecta‐
te prin conducte la cuburile suport în planul de jos al diagramei, care reprezintă cazul de bază al re‐
cursivităț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‐
Programare Vizuală
Pagina24
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.
1.23 (18)).
1.8 Programareavizualășiabstractizarea
Una dintre provocările legate de programarea vizuală o reprezintă scalarea limbajelor pentru a dez‐
volta programe cât mai extinse. Aceasta este o problemă mai mare pentru LPV‐uri decât pentru lim‐
bajele 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 con‐
textului. De asemenea, este dificil de aplicat tehnici dezvoltate pentru limbajele tradiționale, deoa‐
rece 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, ab‐
stractizarea 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 compune‐
rea 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 ope‐
rații sau metode. Ambele, Form/3 și Cocoa, asigură și un suport limitat pentru moștenire.
1.9 Concluziiprivindprogramareavizuală
Domeniul limbajelor de programare vizuală abundă cu exemple ale eforturilor de a lărgi accesibilita‐
tea și mări puterea programării calculatoarelor. Deși numeroasele proiecte existente variază în deta‐
liile 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
Programare Vizuală
Pagina25
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 repre‐
zenta 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 comu‐
nității de cercetători. LPV‐urile 3D nu doar rezolvă problema includerii unei cantități mari de infor‐
maț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.
Programare Vizuală
Pagina26
2 ModelarecuAppInvetor
2.1 SistemuldeoperareAndroid
2.1.1 ScurtistoricAndroid (al cărui logo este prezentat în Fig. 1.24 Logo Android (20)) este o platformă software și un
sistem de operare pentru dispozitive digitale și telefoane mobile, dezvoltată inițial de compania Go‐
ogle, 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 dez‐
voltate de Google. Aplicațiile scrise în C și în alte limbaje pot fi compilate în cod mașină ARM și exe‐
cutate, dar acest model de dezvoltare nu este sprijinit oficial de către Google.
Fig. 1.24 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 ba‐
zat 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 2006. 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 demon‐
strat 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 Alli‐
ance, un consorțiu de 48 de companii de hardware, software și de telecomunicații, printre care și
Programare Vizuală
Pagina27
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 li‐
cenț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 Hol‐
dings 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 Apa‐
che. Sub licența Apache, producătorii sunt liberi să adauge extensii proprietare, fără a le face dispo‐
nibile 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.
2.1.2 CaracteristiciPrintre 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 2009.
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
Programare Vizuală
Pagina28
lipsa unui sistem de gestionare public a problemelor. Google a anunțat un sistem de gestionare a
problemelor la data de 18 ianuarie 2008. Î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 hardwa‐
re neblocate care este destinat dezvoltatorilor avansați. Cu toate că dezvoltatorii pot utiliza un dis‐
pozitiv 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.
2.1.3 EvoluțiasistemuluiAndroidșiimpactulsăupepiață“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 inteligen‐
te, 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 produ‐
că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 specta‐
culoasă 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.
2.1.4 ArhitecturaAndroidDiagrama din Fig. 1.25 (21) prezintă principalele componente ale sistemului de operare Android.
Astfel, acesta este oferit cu un set de aplicații incluse, precum client de email, program SMS, calen‐
dar, hărți, navigator pe Internet, contacte etc. (nivelul aplicații).
Asigurând o platformă de dezvoltare deschisă, Android oferă dezvoltatorilor posibilitatea de a con‐
strui aplicații complexe și inovative. Aceștia sunt liberi să se folosească de hardware‐ul echipamentu‐
lui, 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‐
Programare Vizuală
Pagina29
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. 1.25 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ții‐
lor ș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.
Programare Vizuală
Pagina30
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ționali‐
tăț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 ab‐
stractizare între hardware și software.
2.1.5 SDK‐ulAndroidSDK‐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 ru‐
lează Linux (orice distribuție Linux desktop modernă), Mac OS X 10.4.8 sau mai recent, Windows XP
sau Vista. Cerințele includ, de asemenea, Java Development Kit, Apache Ant, și Python 2.2 sau o ver‐
siune ulterioară. Mediul de dezvoltare (IDE) suportat oficial este Eclipse (3.2 sau mai recent), utili‐
zâ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, con‐
strui și depana aplicații Android.
O versiune pentru examinare a Android Software Development Kit (SDK) a fost lansată la data de
12 noiembrie 2007. 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 ecra‐
nul 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 con‐
tra 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 con‐
tinuată într‐o ramură privată. În scopul de a face acest software public, a fost creată o ramură oglin‐
dă read only, cunoscută sub numele unui desert, anume cupcake. Se crede că numele vine de la Ma‐
rissa 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ă, Blue‐
tooth, 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.
Programare Vizuală
Pagina31
2.2 MIT(Google)AppInventor
Google App Inventor este un limbaj de programare vizuală inițiat de Google și preluat de MIT din
2012. 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, utili‐
zatorul desenează vizual modul în care aplicația va arăta și folosește blocuri pentru a specifica com‐
portamentul aplicației lui. App Inventor folosește o interfaţă grafică, foarte asemănătoare cu inter‐
faţ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 tele‐
fonului 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 distri‐
buirea 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 Kinder‐
garten 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 1960.
Compilator care traduce limbajul vizual al blocurilor pentru implementarea pe sistemul Android folo‐
seş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.
2.2.1 CesepoatefacecuAppInventor?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, pre‐
cum şi blocuri pentru a face „aproape” programare: variabile pentru memorare, blocuri „for” şi „whi‐
le” pentru repetarea operaților şi condiţii (blocuri ,„if ”), astfel încât aplicația să poată să pună între‐
bă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.
Programare Vizuală
Pagina32
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 aseme‐
nea, aplicații de orientare în spațiu. Se pot scrie aplicații care să utilizeze funcţionalități ale telefonu‐
lui 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 nu‐
mă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 pun‐
te de legătură pentru mai multe elemente de calcul complexe şi servicii web, astfel încât App Inven‐
tor poate fi folosit în colaborare cu programatori back‐end.
2.2.2 CapacitățișilimităriCapacităţ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şte‐
rea 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)
Programare Vizuală
Pagina33
Î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 es‐
te încă un pic defectuos și limitat, astfel încât nu se poate construi orice interfaţă de utiliza‐
tor. 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 Inven‐
tor şi vor fi în curând rezolvate.
acces limitat la funcțiile aparatului: nu există componente pentru toate datele şi funcționali‐
tățile telefonului. De exemplu, nu se pot salva şi prelua fişiere din sistem şi există doar un ac‐
ces 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 ima‐
gine generală.
accesul limitat la Android Market: aplicațiilor generate de App Inventor le lipsește configura‐
rea necesară pentru includerea direct pe piață. Cu toate acestea, există în prezent o soluție
pentru publicarea pe piață.
2.2.3 ModuldelucruApp 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 dez‐
voltate, prin urmărirea modificării (change tracking). Practic, aceasta înseamnă că mediul de pro‐
gramare face uz de metoda numită cloud computing ‐ utilizatorul/programatorul folosește compute‐
rul 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 tes‐
tată î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 Win‐
dows, şi pe modele de telefon deja populate cu Android. Aplicațiile create cu App Inventor pot fi
Programare Vizuală
Pagina34
instalate pe orice telefon Android. Înainte ca App Inventor să fie folosit, este necesară instalarea
pachetului App Inventor pentru computer.
Fig. 1.26 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 http://beta.appinventor.mit.edu/, (App Inventor clasic
disponibil până în toamna lui 2014) sau la http://ai2.appinventor.mit.edu (App Inventor 2) unde se
cere logarea cu contul Gmail. Ceea ce se deschide este App Inventor Designer (Fig. 1.27 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.
2.2.4 SelectareacomponentelorpentrucreareadeaplicațiiComponentele App Inventor sunt situate pe partea stângă a ecranului Designer (Fig. 1.27 App Inven‐
tor 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 scutura‐
rea 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.
Programare Vizuală
Pagina35
Fig. 1.27 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. 1.28 App Inventor Blocks Editor
2.2.5 DeschidereaeditoruluideblocurișipornireaemulatoruluiDesigner‐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 rulea‐
ză într‐o fereastră separată. La deschiderea editorului de blocuri din fereastra Designer, un fișier care
Programare Vizuală
Pagina36
permite computerului să comunice cu un dispozitiv conectat va fi descărcat şi ar trebui să se deschi‐
dă în mod automat. Acest proces poate dura 30 de secunde sau mai mult. În cazul în care nu se des‐
chide 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 AppInventorForAndroidCode‐
blocks.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 conecta‐
te 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 fuse‐
seră 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 selecta‐
rea 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 bu‐
toanele de pe emulator, dar dacă butonul nu a fost programat, atunci nimic nu se va întâmpla. Mer‐
gând mai departe, orice modificări aduse aplicației în Designer şi în editorul de blocuri, acestea vor
apărea pe emulator.
Fig. 1.29 Emulatorul App Inventor
Programare Vizuală
Pagina37
2.2.6 ComponenteAppInventorFiecare 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 dis‐
ponibile în App Inventor. Mai multe se pot afla la (24).
2.2.6.1 Componentedebază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 boo‐
leană.
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:
Programare Vizuală
Pagina38
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.
Programare Vizuală
Pagina39
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ău‐
ga și alte ecrane.
Proprietăți
AlignHorizontal: un număr care codifică alinierea pe orizontală a conținutului ecranului. Va‐
lorile 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, por‐
trait, 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 fizi‐
că a dispozitivului. Când nu este bifat, înălţimea aplicației va fi constrânsă la înălţimea dispo‐
zitivului.
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 va‐
lorilor 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 returna‐
rea controlului ecranului curent.
ScreenOrientationChanged(): modificarea orientării ecranului
Metode:
Programare Vizuală
Pagina40
CloseScreenAnimation(text animType): pregătește animația pentru închiderea ecranului cu‐
rent și întoarcerea la ecranul anterior. Opțiuni valide sunt: default, fade, zoom, slidehorizon‐
tal, 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 proprieta‐
tea 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țione‐
ze 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 stabi‐
leş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
Programare Vizuală
Pagina41
aplicație, adică datele stocate vor fi disponibile de fiecare dată când aplicaţia se execută. Un exem‐
plu 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→Applica ons→ Manage applica‐
tions, 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 tele‐
fon ş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. Va‐
loarea poate fi un text sau o listă.
GetValue(text tag): citește valoare salvată în tag. Dacă nu e nimic, returnează textul vid.
2.2.6.2 ComponentedetipsenzorAccelerometerSensor — 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/s2. 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.
Programare Vizuală
Pagina42
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 modifi‐
că 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 longitu‐
dine, 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.
Programare Vizuală
Pagina43
OrientationSensor — este o componentă ce se folosește pentru a determina spaţial orientarea tele‐
fonului. 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 as‐
tfel î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 în‐
dreptată î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 dispoziti‐
vului.
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.
2.2.7 BlocuridinAppInventorÎ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).
2.2.7.1 Blocuridedefinireprocedure (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 au‐
tomat 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. 1.30 prezintă
modul de afișare al acestor blocuri.
Programare Vizuală
Pagina44
a)
b) Fig. 1.30 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 ar‐
gumente 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ă: slo‐
turile 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. 1.31 prezintă modul de afișare a blocurilor name și variable.
a)
b)
Fig. 1.31 Bloc de tip nume a) și bloc de tip variabilă b)
2.2.7.2 HandlerdeevenimenteProgramele 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. 1.32 Handler de evenimente
Evident, când un eveniment apare, handler‐ul asociat va fi executat.
2.2.7.3 ComenzișiexpresiiCâ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 co‐
menzilor sunt mov sau albastre.
Programare Vizuală
Pagina45
Fig. 1.33 Exemplu de comenzi
Anumite comenzi au nevoie de una sau mai multe valori de intrare (cunoscute și sub numele de pa‐
rametrii 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 ex‐
presii foarte complexe folosind expresii mai simple, prin compunere orizontală (Fig. 1.34).
Fig. 1.34 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. 1.35 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. 1.35 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.
2.2.7.4 AranjareaelementelorpeecranImplicit, componentele sunt aranjate pe verticală. Dacă se dorește modificarea acestui mod de aran‐
jare, atunci se poate folosi una dintre componentele HorizontalArrangement, VerticalArrangement
sau TabletArrangement din secțiunea ScreenArrangement.
Programare Vizuală
Pagina46
2.2.7.5 ManipulareastăriicomponentelorFiecare componentă este caracterizată de numeroase proprietăți. Valorile curente ale acestor pro‐
prietăț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. 1.36 Getter‐e și setter‐e pentru etichetă
2.2.7.6 EvenimentealebutoanelorCel 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.
2.2.7.7 ComentariiO parte importantă din munca de programare o constituie realizarea unei documentații. App Inven‐
tor 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. 1.37 Adăugarea de comentarii
2.2.8 ExempluderealizareauneiaplicațiicuAppInventor.Î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. Sco‐
pul 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 tre‐
ce 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.
Programare Vizuală
Pagina47
2.2.8.1 ElementevizualeTerenul de fotbal este reprezentat de un element Canvas al cărui fundal este o imagine cu exten‐
sia .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 ori‐
entarea direcției și stabilirea forței șutului. Portarul este reprezentat printr‐un element de tipul Ima‐
geSprite, având ca fundal o imagine sugestivă a unui portar, după cum se poate observa în Fig. 1.38.
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. 1.38 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 min‐
gea 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ă.
2.2.8.2 StabilireaacțiuniiAcț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 ordona‐
ta 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. Incremen‐
tarea si decrementarea abscisei se face cu un pas de 3 pixeli, astfel încât, într‐o cursă completă, por‐
tarul să acopere suprafața întregii porți.
Programare Vizuală
Pagina48
Fig. 1.39 Indicator de direcție
Fig. 1.40 Indicator pentru forța șutului
Fig. 1.41 Stabilirea poziției portarului
Programare Vizuală
Pagina49
Fig. 1.41 descrie modul de programare al ceasului portarului. Poziția portarului este stabilită de va‐
loarea 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. 1.42 Stabilirea forței șutului
Fig. 1.43 Determinarea direcției mingii
Forța șutului este dată de poziția bilei albastre din Fig. 1.40. Acest indicator are abscisa fixă, cu valoa‐
rea 306, iar ordonata variabilă, cu valori între 302 și 225. Intervalul este împărțit în 11 părți, viteza
Programare Vizuală
Pagina50
fiind incrementată cu pas egal de la poziția 302 spre 255, și decrementată invers. Fig. 1.41 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ă perpendi‐
cular 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. 1.44 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
Programare Vizuală
Pagina51
porni ceasul mingii. Fig. 1.46 prezintă, în detaliu, modul în care cele două butoane au fost programa‐
te.
Fig. 1.45 Portarul prinde mingea
Fig. 1.46 Acțiunile asociate celor două butoane
Programare Vizuală
Pagina52
3 Bibliografie
1. Mayers, Brad A. Taxonomies of Visual Programming and Program Visualization. Pittsburgh :
Carnegie Mellon University, 1989.
2. Direct Manipulation Systems. [Online]
http://www.gale.cengage.com/pdf/samples/sp655664.pdf.
3. Boshernitsan, M., Downes M. Visual Programming Languages: A Survey. Berkeley : University of
California, 2004. UCB/CSD‐04‐1368.
4. Burnett, Margaret M. Visual Programming. Encyclopedia of Electrical and Electronics
Engineering. 1999.
5. Tanimoto, S. VIVA: a visual language for image processing. Journal of Visual Languages
Computing 2(2). 1990, Vol. 2, 2.
6. Heterogeneous visual languages : Integrating visual and textual programming. Meyer, M.,
Erwig B. s.l. : 1995 IEEE Symposium Visual Languages, 1995.
7. Chang, S.‐K. Principles of Visual Programming Systems. New York : Prentice Hall, 1990.
8. Rhor, G. Using visual concepts. [book auth.] S.‐K., Ichikawa, T., and Ligomenides, P. Chang.
Visual Languages. New York : Plenum Press, 1986.
9. Tortora, G. Structure and interpretation of visual languages. [book auth.] S.‐K. Chang. Visual
Languages and Visual Programming. New York : Plenum Press, 1990.
10. Lakin, F. Spatial parsing for visual languages. [book auth.] S.‐K., Ichikawa, T., and Ligomenides,
P. Chang. Visual Languages. New York : Plenum Press, 1986.
11. Golin, E. J. A method for the specification and parsing of visual languages. PhD dissertation.
s.l. : Brown University, 1990.
12. Kurlander, D.J. Graphical editing by example in Chimera. [Online] Columbia University.
http://kurlander.net/DJ/Pubs/PBEBookChap12.PDF.
13. Burnett, Margaret. Forms/3. [Online]
http://web.engr.oregonstate.edu/~burnett/Forms3/forms3.html.
14. David Heise, Tomas Joyner. Prograph: A Visual Programming Language. [Online]
http://students.cs.byu.edu/~dheise/cs330/Prograph_final_report.pdf.
15. Hayes‐Roth, F. Rule‐based systems. Communications of the ACM. 1985, Vol. 28, 9.
Programare Vizuală
Pagina53
16. Smith, Allen Cypher and David Canfield. KIDSIM: END USER PROGRAMMING OF SIMULATIONS.
[Online] http://www.sigchi.org/chi95/proceedings/papers/ac1bdy.htm.
17. Visual programming in 3‐d. Najork, M. 12, s.l. : Dr. Dobb’s Journal, 1995, Vol. 20.
18. MArk A. Najork, Simon M. Kaplan. A Prototype Implementation of the CUBE Language. [Online]
http://www.google.ro/url?sa=t&rct=j&q=a%20prototype%20implementation%20of%20the%20cu
be%20language&source=web&cd=1&sqi=2&ved=0CBkQFjAA&url=http%3A%2F%2Fciteseerx.ist.ps
u.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.67.7089%26rep%3Drep1%26type%3Dpdf&ei=2
22pTr3gC.
19. Android operating system. Wikipedia. [Online]
http://en.wikipedia.org/wiki/Android_(operating_system).
20. What is Android? Android developers. [Online]
http://developer.android.com/guide/basics/what‐is‐android.html.
21. Varban, G. Wall‐Street.ro. [Online] http://www.wall‐street.ro/articol/IT‐C‐
Tehnologie/86693/Android‐ar‐putea‐deveni‐pentru‐telefoane‐ceea‐ce‐e‐Windows‐pentru‐PC‐
uri.html.
22. Google App Inventor. Wikipedia. [Online] http://en.wikipedia.org/wiki/App_inventor.
23. Reference Documentation. App Inventor. [Online]
http://appinventor.mit.edu/explore/support.html.
Top Related