Specializarea : Informatică [626743]

1

UNIVERSITATEA „LUCIAN BLAGA” DIN SIBIU
FACULTATEA DE ȘTIINȚE

Specializarea : Informatică

LUCRARE DE LICENȚĂ

Coordonator științific
Lect.Univ.Dr.Alina Elena Pitic Absolvent: [anonimizat]
2017

2
UNIVERSITATEA „LUCIAN BLAGA” DIN SIBIU
FACULTATEA DE ȘTIINȚE

Specializarea : Informatică

Aplicaț ie Android pentru
verificarea cunoștințelor HTML
și CSS

Coordonator științific
Lect.Univ.Dr.Alina Elena Pitic Absolvent: [anonimizat]
2017

3

CUPRINS
CAPITOLUL 1. Android ………………………….. ………………………….. ………………………….. ……………. 5
1.1. Scurt istoric si evoluția versiunilor sistemului de operare Android ………………………….. . 5
1.2. Android 1.5 Cupcake ………………………….. ………………………….. ………………………….. …….. 5
1.3. Android 1.6 Donut ………………………….. ………………………….. ………………………….. ………… 5
1.4. Android 2.0 -2.1 Éclair ………………………….. ………………………….. ………………………….. …… 6
Prezentat la sfârșitul anului 2009, Android 2.0 a apărut pentru prima oară pe Motorola
Droid, Eclair a fost un pas destul de mare în fața predecesorilor săi. A adus îmbunătățiri în
browser, Google Maps și o nouă interfață cu utilizatorul. Navigarea de hărți Google,
apropiindu -se repede de platforme cu alte sisteme de navigație GPS. ………………………….. …. 6
1.5. Android 2.2 – 2.2.3 Froyo ………………………….. ………………………….. ………………………….. . 6
1.6. Android 2.3 – 2.3.7 Gingerbread ………………………….. ………………………….. …………………. 6
1.7. Android 3.x Honeycomb ………………………….. ………………………….. ………………………….. .. 6
1.8. Android 4.0 – 4.0.4 Ice Cream Sandwich ………………………….. ………………………….. ……… 7
1.9. Android 4.1 – 4.3.1 Jelly Bean ………………………….. ………………………….. ……………………. 7
1.10. Android KitKat (4.4 – 4.4.4) ………………………….. ………………………….. ……………………. 8
1.11. Android Lollipop (5.0 – 5.1.1) ………………………….. ………………………….. ………………… 8
1.12. Android Marshmallow (6.0 – 6.0.1) ………………………….. ………………………….. …………. 8
1.13. Android Nougat (7.0 – 7.1.1) ………………………….. ………………………….. ………………….. 8
CAPITOLUL 2. ANDROID STUDIO ………………………….. ………………………….. ……………………. 10
2.1 Structura proiectului în A ndroid Studio ………………………….. ………………………….. ……… 10
2.2 Interfața cu utilizatorul ………………………….. ………………………….. ………………………….. … 10
2.3 Setări Structura proiectului ………………………….. ………………………….. ……………………….. 12
2.3.1 Elementele de bază ale fluxului de lucru pentru dezvoltarea aplicației Android ……… 12
2.3.2 Investigarea cantității de memorie RAM folosită ………………………….. ……………………. 13
2.3.3 Scrierea și vizualizarea de loguri ………………………….. ………………………….. ……………… 13
2.3.4 Folosirea utilitarului DDMS (Dalvik Debug Server Monitor) ………………………….. ….. 14
CAPITOLUL 3. ANDROID INTERFAȚA GRAFICĂ – XML ………………………….. ……………….. 16
3.1 Linea rLayout ………………………….. ………………………….. ………………………….. ………………….. 16
3.2 Relative Layout ………………………….. ………………………….. ………………………….. ………….. 16
3.3 Table Layout ………………………….. ………………………….. ………………………….. ……………… 17
3.4 ScrollView Layout ………………………….. ………………………….. ………………………….. ……… 17
3.5 Cum funcționează Java și A ndroid împreună? ………………………….. …………………………. 17
CAPITOLUL 4. Configurarea și utilizarea widget -urilor ………………………….. ……………………….. 22

4
4.1 Dimensionarea folosind pixeli independenți ………………………….. ………………………….. ……. 22
4.2 Dimensionarea folosind pixeli scalabili ………………………….. ………………………….. ………….. 22
4.3 Folosirea padding -ului și a marginii ………………………….. ………………………….. ……………….. 22
4.4 Folosirea proprietății’ layout_weight’ ………………………….. ………………………….. …………….. 23
4.5 Folosirea proprietății ‘gravity’ ………………………….. ………………………….. ………………………. 23
4.6 Fazele unei aplicații Android ………………………….. ………………………….. ………………………… 23
CAPITOLUL 5. SQLite ………………………….. ………………………….. ………………………….. ……………. 25
5.1 Despre SQLite ………………………….. ………………………….. ………………………….. ………………… 25
5.2 Trăsăturile cele mai importante ale SQLite -ului ………………………….. ………………………….. . 26
5.3 Tabele ………………………….. ………………………….. ………………………….. ………………………….. .. 29
5.4 Cheile primare ………………………….. ………………………….. ………………………….. ………………… 32
CAPITOLUL 6. JSON ………………………….. ………………………….. ………………………….. ……………… 34
6.1 Despre JSON ………………………….. ………………………….. ………………………….. ………………….. 34
6.2 Maparea între entitățile JSON și Java ………………………….. ………………………….. …………….. 37
CAPITOLUL 7 ………………………….. ………………………….. ………………………….. ……………………….. 38
7.1 Interfața Aplicației ………………………….. ………………………….. ………………………….. …………… 38
7.2 Activitățile Aplicaței Qu iz App ………………………….. ………………………….. ……………………… 51
7.2.1 AndroidManifest.xml ………………………….. ………………………….. ………………………….. … 51
7.2.2 Clasa AllQuestionsHtml și Clasa AllQuestionsCss ………………………….. …………………. 51
7.2.3 Clasa DatabaseHandler ………………………….. ………………………….. ………………………….. . 52
7.2.4 Clasa AppUsers ………………………….. ………………………….. ………………………….. ………… 53
7.2.5 Clasa CssLevel și Clasa HtmlLevel ………………………….. ………………………….. ………….. 53
7.2.6 Clasa SignUp ………………………….. ………………………….. ………………………….. ……………. 53
7.2.7 Clasa Login ………………………….. ………………………….. ………………………….. ………………. 54
7.2.8 Clasa ChooseLevel ………………………….. ………………………….. ………………………….. ……. 54
7.2.9 Clasa Reviews ………………………….. ………………………….. ………………………….. …………… 55
7.2.10 Clasa TotalScore ………………………….. ………………………….. ………………………….. ……… 56

5

CAPITOLUL 1. Android
1.1. Scurt istoric si evoluț ia versiunilor sistemului de operare Android

Inițial, Andy Rubin a fondat Android Incorporation în Palo Alto, California, Statele
Unite în octombrie 2003. În 17 august 2005, Google a achiziționat un sistem de incorporare
Android. D e atunci, este în filiala Google Incorporation. Angajații cheie ai Android
Incorporation sunt Andy Rubin, Rich Miner, Chris White și Nick Sears. Inițial destinat pentru
camera foto, dar a fost mutat mai târziu la telefoanele inteligente, din cauza pieței r eduse numai
pentru aparatul de fotografiat. Android este nick name -ul lui Andy Rubin dat de colegii datorat
dragostei lui față de roboți. În 2007, Google anunță dezvoltarea sistemului de operare Android,
iar in 2008 HTC a lansat primul telefon Androi d.
De la versiunea 1.5, Android are nume de cod bazate pe dulciuri in ord ine alfabetică .
Incep ând de la Cupcake (1.5), Donut (1.6), Éclair (2.0 – 2.1), Froyo (2.2 – 2.2.3), Gingerbread
(2.3 – 2.3.7), Honeycomb (3.0 – 3.2.6), Ice Cream Sandwich (4.0 – 4.0.4), J elly Bean (4.1 – 4.3.1),
KitKat (4.4 – 4.4.4), Lollipop (5.0 – 5.1.1), Marshmallow (6.0 – 6.0.1) și versiunea Nougat (7.0 –
7.1.1).
1.2. Android 1.5 Cupcake
Cupcake a fost prima revizuire majoră a sistemului de operare Android. Android 1.5
SDK a fost lansat în aprilie 2009 și a adus o mulțime de modificări ale UI -ului, cel mai probabil
fiind suportul pentru widget -uri și foldere pe ecranele de start.Cupcake a adus caracteristici cum
ar fi îmbunătățirea suportului Bluetooth, a funcțiilor camerei video și a servi ciilor de încărcare
noi precum YouTube și Picasa. Android 1.5 a inaugurat epoca telefonului Android modern .

1.3. Android 1.6 Donut

Donut, lansat în septembrie 2009, a extins caracteristicil e care au venit cu Android
1.5.Android , 1.6 a adus unele îmbunătățir i majore. Donut a adus suport pentru ecranele
touchscreen de înaltă rezoluție, asistență pentru ecrane WVGA si suport mult îmbunătățit pentru
camere și galerii.

6
1.4. Android 2.0 -2.1 Éclair
Prezentat la sfârșitul anului 2009, Android 2.0 a apărut pentru prima o ară pe Motorola
Droid, Eclair a fost un pas destul de mare în fața predecesorilor săi. A adus îmbunătățiri în
browser, Google Maps și o nouă interfață cu utilizatorul. Navigarea de hărți Google, a propiindu –
se repede de platforme cu alte sisteme de navigați e GPS.
1.5. Android 2.2 – 2.2.3 Froyo
Android 2.2 Froyo a fost anunțat în mai 2010 la conferința Google IO din San
Francisco. Cea mai mare schimbare a fost introducerea compilatorului Just -In-Time – sau JIT –
care accelerează în mod semnificativ puterea de pro cesare a telefonului. Împreună cu JIT,
Android 2.2 aduce de asemenea suport pentru Adobe Flash 10.1 .Froyo a adus, de asemenea,
suport nativ pentru tethering, ceea ce înseamnă că se poate utiliza conexiunea de date pentru
smartphone -ul Android pentru a ofer i Internet (fără fir sau cu un cablu USB) la aproape orice
dispozitiv.

1.6. Android 2.3 – 2.3.7 Gingerbread
Android 2.3 Gingerbread a fost lansat î n decembrie
2010. Gingerbread aduce câteva îmbunătățiri ale interfeței,
precum o simțire mai consistentă în m eniuri și dialoguri, s i o
nouă bară de notificare neagră. Gingerbread aduce suport și
pentru noile tehnologii. NFC (Near Field Communication)
este acum acceptată și suportul SIP (Internet calling) e ste
acum disponibil pe Andro id, plus o optimizare ulterioa ră
pentru o viață ma i bună a bateriei completează acest upgrade .
1.7. Android 3.x Honeycomb
Android 3.0 Honeycomb a fost lansat î n februarie
2011 cu Motorola Xoom. Este prima versiune Android
produsă în mod specific pentru tablete și a adus la masa o
mulțime d e noi elemente de interfață. O nouă bara de sistem
in partea de jos a ecranului pentru a înlocui bara de stare pe
care o vedem pe telefoane și un nou buton pentru aplicații le
recente .
Unele dintre aplicațiile Google standard au fost, de

7
asemenea, actualiz ate pentru utilizarea cu Honeycomb, inclusiv aplicația Gmail și aplicația Talk.
Ambele au folosit foarte mult fragmente, iar aplicația Talk a adăugat o conversație prin chat
video și o asistență pentru apelare încorporată.
Google nu a lansat niciodată sur sa de tip Honeycomb. Îmbunătățirile pentru Honeycomb au fost
anunțate la Google IO în mai 2011 ca Android 3.1, iar Android 3.2 a urmat ulterior. Însă
Honeycomb este în principiu considerată o versiune uitată.1
1.8. Android 4.0 – 4.0.4 Ice Cream Sandwich

Andro id 4.0 oferă o interfață rafinat ă pentru telefoane și tablete. Introduce caracteristici
inovatoare pentru utilizatori și dezvoltatori. Acest document oferă o imagine a numeroaselor noi
caracteristici și tehnolo gii care fac Android 4.0 simplu si frumos.
Android 4.0 se bazează pe lucrurile pe care le iubesc cei mai mulți oameni despre Android –
multitasking ușor, notificări bogate, ecrane de pornire personalizabile, widget -uri
redimensionabile și interactivitate profundă și adaugă noi modalități puternice de comunicare și
partajare. Face ca acțiunile comune să fie mai vizibile și 2permit e navigatorilor să navigheze cu
gesturi simple și intuitive.
Butoanele virtuale din bara de sistem permit utilizatorilor să navigheze instantan eu la Back,
Home și aplicatii re cente . Bara de sistem și butoanele virtuale sunt prezente în toate aplicațiile.
Widgeturile sunt redimensionabile, astfel încât utilizatorii le pot extinde pentru a afișa mai mult
conținut sau a le micșora pentru a economisi spațiu. De pe ecranul de blocar e a diapo zitivelor,
utilizatorii pot merge direct la cameră pentru o fotografie sau pot trage in jos fereastra de
notificări pentru a v erifica mesajele. Când asculta muzică, utilizatorii pot chiar să gestioneze
piese le muzicale și să vadă arta albumelor.
1.9. Android 4.1 – 4.3.1 Jelly Bean

Android 4.3 include optimizări de performanță și caracteristici noi pentru utilizatori și
dezvoltatori. Este mai rapid, ș i mai receptiv prin îmbunataț irea conectivităț ii Bluetooth ,
optimizarea găsirii locaț iei, configurarea layout -ului tastaturii capabilităților senzoriale și
filtrarea specifică notificărilor aplicațiilor .

1 http://www.androidcentral.c om/android -versions
2 https://developer.android.com/about/versions/nougat/index.html

8
1.10. Android KitKat (4.4 – 4.4.4)

Android 4.4 este conceput pentru a funcționa rapid, neted și sensibil pe o gamă mult mai
largă de dispozitive decât înainte – inclusiv pe milioane de dispozitive de din întreaga lume care
au doar 512 MB RAM. KitKat simplifică fiecare componentă majoră pentru reducerea utilizării
memoriei și introduce noi API -uri și in strumente pentru a ajuta să creă m aplicații inovatoare,
recep tive, cu o memorie eficientă.
1.11. Android Lollipop (5.0 – 5.1.1)

Lollipop extinde Android chiar mai departe, de la telefoane, tablete și pana la mașini.
Android TV oferă o platformă TV completă pentru experiența pe ecran mare a aplicației. Permite
utilizatori lor să descopere cu ușurință conținutul, cu recomandări personalizate și căutare vocală.
Android 5.0 int roduce API -uri noi pentru cameră .

1.12. Android Marshmallow (6.0 – 6.0.1)

Android 6.0 (M) oferă funcții noi utilizatorilor și dezvoltatorilor de aplicații . Această
versiune oferă noi interfețe API pentru a permite autentificarea utilizatorilor utilizând scanările
dactiloscopice pe dispozitivele acceptate. Aplicația poate autentifica utilizatorii în funcție de
ultima dată când au deblocat dispozitivul. Aceast ă caracteristică scutește utilizatorii de la
necesitatea de a -și aminti parole suplimentare pentru anumite aplicații. Sistemul poate efectua o
copiere de rezervă automată/backup și o restaurare completă pentru aplicații. Oferă API -uri
pentru a face partaja rea intuitivă și rapidă pentru utilizatori. Utilizatorii pot adopta dispozitive
externe de stocare, cum ar fi cardurile SD. 3

1.13. Android Nougat (7.0 – 7.1.1)

Introduce o varietate de caracteristici și capabilități noi pentru utilizatori și dezvoltatori.
Acum utilizatorii pot deschide instantaneu două aplicații pe ecran, viteza instalărilor de aplicații
și actualizarea sistem ului este îmbunătățită , introduce emoji suplimentar. De asemenea, oferă un
API care permite furnizorilor de servicii să mențină o listă b locată de contacte. Lista nu este

3 https://developer.android.com/about/versions/marshmallow/android -6.0.html

9
accesibilă altor aplicații. Nougat permite aplicației implicite de telefon să afișeze apelurile
primite.4 Cu toate acestea, a plicaț iile native Android sunt dezvoltate folosind limbajul de
programare Java , și poate fi usor adaptată pentru alte sisteme de operare mobile, cum ar fi
Blackberry, Symbian și Ubuntu. În plus, aplicaț iile Android pot fi, de asemenea folosite cu
usurință de că tre Chrome OS.
Android Studio este un IDE excelent bazat pe InteliJ. După cum sugerează și n umele este un IDE
proiectat ș i dezvoltat speci al pentru dezvoltarea de aplicaț ii Android. Este extraordinar de rapid
și eficient, și putem seta un nou proiect Android pentru diferite tip uri de aplicații Android în
câteva secunde. Atunci c ând Android a fos t lansat, dezvoltarea unei aplicaț ii s-a facut cu Eclipse
și pluginul Android Developer. De c ând a fost la nsat Android Studio s -a schimbat , plus acesta
conține și anumite îmbunătăț iri: bazat pe Gradle si stem cu timp real de redare, opț iunea de
exam inare a aspectului de configurație pe ecran în timpul editării, construirea de variante ș i
generare a de fișiere multiple apk, suportă dezvoltarea de aplicații Android Wera, TV ș i Auto,
permitere a integrării aplicaț iei cu platforma Google Cloud.

Java este un limba j de pr ogramare folosit pe o gama largă de dispozitive ș i sisteme de operare.
Se folosește și în dezvoltarea de aplicaț ii pentru alte sisteme de operare (Windows, Linux ).
Aplicaț iile And roid pot fi publicate î n magazinul Google Play și disponibile pentru d escărcare a
de către utilizatori în termen de c âteva ore, în comparație cu termenul de c âteva săptăm âni pentru
magazinul de aplicații pentru Apple. O aplicaț ie poate fi literalmente actua lizată de mai multe ori
pe zi, pe magazinul Google Play, ca răspuns la plângerile utilizatorilor și/ sau probleme, în timp
ce pe App Store, aplicația ar trebui să treacă prin același proces de lungă durată ori de c âte ori
trimitem o actualizare sau un bug fix. Pentru o nouă aplicaț ie sau un joc care ar avea nevoie să
fie în mod constant și rafinat actualizat ca ră spuns la feedback -ul utilizatorilor, magazinul Play
este o platformă perfectă .
O alta caracteristică excelentă a Play Store -ului este abilitatea d e a elibera o aplicație alfa ș i/ sau
beta care ar fi disponibilă numai pentru mem brii unui grup selectat de testă ri. Cu aceasta, poate
oferi i acces rap id la un subset de utilizatori ș i de a folosi feedback -ul lor pentru a lustrui aplicația
înainte de final. Dezvoltarea unei aplicaț ii Android se poate face pe Windows, Mac ș i Linux .

4 https://developer.android.com/about/versions/nougat/android -7.0.html

10
CAPITOLUL 2. ANDROID STUDIO

Android este oficial un mediu pentru dezvoltarea de aplicații Android. Android Studio oferă
mai multe caracteristici care sporesc chiar și în momentul construirii aplicațiilor de productivitate
Android, cum ar fi: un sistem constructiv de bază Gradle flexib il; un emulator rapid ; un mediu
unificat în cazul în care dorim să dezvoltă m pentru toate dispozitivele Android; executare
instantanee pentru a împinge modificări la aplicația î n funcționare, fără a construi un nou A PK;
instrumente extinse de testare; instrumente pentru a prinde performanță, usurinț a în utilizare,
compatibilitate, suport C ++ ș i suport S DK.

2.1 Structura proiectului î n Android Studio

Fiecare proiect din Android Studio conține unul sau mai multe module cu fișiere de cod sursă și
fișierele sursă. Include urmă toarele tip uri de modele: module de aplicaț ii Android, module de
bibliotecă , module pentru Google App Engine. În mod implicit, Android Studio afișează fișierele
de proiect în vizualizarea proiectului Android. Această organizare pe module oferă acces rapid la
fișierele sursă -cheie ale proiectului dumneavoastră. Aplicatia conține următoarele foldere:
‘manifests ‘care conține AndroidManifest.xml ;’ java’ conține fișierele de cod sursă Java,
inclusiv codul de test JUnit; ‘ res’care conține toate resursele de bază non -cod, cum ar fi machete
XML, imagini.

2.2 Interfaț a cu utilizatorul

Fereastra principală î n Android Studio este alc ătuită din mai multe zone:
Bara de instrumente ne permite să efectuă m o gamă lar gă de acțiuni, inclusiv rularea aplicației și
lansarea de instrumente Android.
Bara de navigare ne ajută să navigam prin proiectul și fișierele deschise pentru editare. Acesta
oferă o vizualizare mai compactă a structurii vizibile în fereastra proiectului.
Fereastra Editor este locul unde putem creea ș i modifica codul. În funcție de tipul de fișier
curent, editorul se poate schimba. De exemplu, atunci când vizualizam un fișier se va afișa
editorul Layout.
Fereastra barei de instrumente se execută în jurul e xteriorul ferestrei IDE și conține butoane care
ne permit extinderea sau restrângerea ferestrelelor individuale.

11
Ferestrele de intrumente oferă acces la sarcini specifice, cum ar fi managementul de proiect, de
căutare, de control al versiunii, și multe alt ele. Avem posibilit atea de a le extinde sau sa le
închidem.
Bara de stare afișează starea proiectului și IDE în sine, precum și orice avertismente sau mesaje.
În Android Studio avem posibilitatea să organizăm fereastra principală cum dorim pentru
a ne ofer i mai mult spațiu pe ecran prin ascunderea barelor de instrumente și ferestrelo r care sunt
deja deschise. Put em utiliza, de asemenea, comenzi rapide de la tastatură pentru a avea acces la
cele mai multe caracteristici IDE. În orice moment, putem căuta în c odul sursă, baze de date,
acțiuni, elemente ale interfeței cu utilizatorul, și așa mai departe, prin dubla apăsare pe tasta
Shift, sau făcând clic pe lupa din colțul din dreapta sus al programului. Acest lucru poate fi foarte
util în cazul în care, de exem plu, încercam să găsim o anumită acțiune IDE pe care am uitat cum
să o declanșam.
Pentru a vedea efectiv structura pe fiș iere a proiectului, inclusiv toate fișierele ascunse din
ecranul Android, putem selecta Project din meniul derulant din partea de sus a ferestrei
proiectului. Atunci când selectă m Vizualizare proiect, putem vedea mult mai multe fișiere și
directoare. Cele mai importante dintre acestea sunt următoarele:
module -name/ care cuprinde:
• build/ conține outputurile;
• libs/conține biblioteci priva te.
• src/conține toate fișierele de cod și resurse pentru modulul în următoarele subdirectoare:
o androidTest /conține un cod pentru testele care rulează pe un dispozitiv Android,
o main /conține "principalele" fișiere: codul și resursele partajate de toate var iantele
Android construite:
• AndroidManifest.xml descrie fiecare dintre componentele sale
• java/ conține sursele java
• jni/conține cod nativ folosind nativ Interface Java (JNI)
• gen/conține fișierele Java generate de Android Studio, cum ar fi
fișierul R.java și interfețele create din fișiere AIDL.
• res/conține resurse pentru aplicații, cum ar fi fișierele drawable,
fișierele cu aspect UI.
• assets/ conține un fișier care ar trebui să fie compilat într -un fișier.
apk așa cum este. Put em naviga cu acest director în același mod ca
și cu un sistem de fișiere tipic folosind URI -uri și citi fișiere ca un
flux de octeți folosind AssetManager.
• test/conține un cod pentru testele locale care rulează pe gazda JVM.
• build. gradle (modul) Aceasta defineș te configurațiile build modulelor specifice.

12
• build. gradle (proiect) Aceasta defineș te configurația de construire care se aplică tuturor
modulelor. Acest fișier este parte integrantă a proiectului, astfel încât să le mențină în
control cu toate celelalte coduri sursă.

2.3 Setări St ructura proiectului

Pentru a modifica diverse setări pentru proiectul Android Studio, putem deschide dialogul
Structura proiectului făcând clic pe Fișier> Structura proiectului. Acesta conține următoarele
secțiuni:
• SDK Locul de amplasare : setează locația JDK, Android SDK -ul, și Android NDK care o
foloseș te proiectul creat.
• Project /Proiect: setează versiunea pentru Gradle și pl ugin-ul Android pentru Gradle, ș i
numele locației.
• Developer Services /Servicii dezvoltator: conține setări pentru Android Studio add -in
componente de la Google sau alte părți.
• Modules /Module: permite să editam configurațiile specifice modulului, inclusiv SDK -ul,
semnătura aplicației, și dependențele de bibliotecă.
Setările din Modules ne permit să modificam opțiunile de configurare pen tru fiecare dintre
modulele proiectului creat. Pagina cu setări a fiecarui modul este împărțita în următoarele taburi:
Properties /Proprietăți: specifică versiunile de SDK și instrumentele de compilare a modulului;
Signing / Semnă tura: utilizat pentru a semn a fișierul APK.
Flavors care perm ite să cream mai multe construcț ii, în cazul în care fiecare are un set specific de
setări de configurare, cum ar fi versiunea minimă și SDK -ul țintă al modulului, precum și numele
și versiunea.
Build Types /Construi Tipuri, care permite să cream și să modificăm configurații de construcț ie.

2.3.1 Elementele de bază ale fluxului de lucru pentru dezvoltarea aplicaț iei
Android

Fluxul de lucru pentru a dezvolta o aplicație pentr u Android este conceptual acelaș i ca și
alte pla tforme pentru dezvoltarea de aplicaț ii. Cu toate acestea, pentru a construi în mod eficient
o aplicație bine conceputa pentru Android, avem nevoie de unele instrumente specializate. Lista
de mai jos oferă o prezentare generală a procesului de a construi o aplicație Android care ar
trebui utilizate în timpul fiecărei faze de dezvoltare.

13
Configurarea spațiului de lucru . Instalarea programului Android Studio și creearea unui proiect.
Scrierea aplicației . Android Studio include o varietate de instrumente și de informații pentru a ne
ajuta să lucram mai rapid, scrie cod de calitate, designUI, și de a crea resurse pentru diferite
tipuri de dispozitive.
Construirea si rularea apli cației. În timpul acestei faze, se construieș te proiec tul într -un pachet
APK pe care îl putem instala și rula pe emulator sau un dispozitiv cu Android.
Depanarea și testarea . Acest pas se face tot in faza î n scrierea aplicației, dar cu accent pe
eliminarea erorilor și optimizarea performanței aplicației. Desigur, crearea testel or ne ajuta în
aceste eforturi. Pentru a vizualiza și analiza diferite valori de performanță, cum ar fi utilizarea
memoriei, traficul de rețea, impactul CPU, și mai mult, putem utiliza Android Monitor.
Publicarea . Când suntem pregatiț i să lansă m aplicația pentru utilizatori, trebuie luate c âteva
lucruri î n considerare, cum ar fi versionarea aplicației și semnarea acesteia cu o cheie.

2.3.2 Investigarea cantităț ii de memorie RAM folosit ă

Atunci când dezvoltam aplicații Android, trebuie să acordă m întotdeauna atenție la cât de
multă memorie RA M folosește aplicația construită . Cu t oate că Dalvik și ART efectuează
runtime de colectare a gunoiului de rutină (GC) pentru a oferi i utilizatorilor o experiență stabilă
în cazul în care si stemul de operare Android comută rapid între aplicații, asigurarea că aplicația
nu consumă în mod inutil memorie atunci când utilizatorul nu interacționează cu ea este un punct
important pentru performanță . Android Runtime (ART) este un mediu de aplicație de rulare
utilizat d e sistemul de opera re Android. Î nlocuind Dalvik, care este procesul de mașină virtuală
utilizată inițial de Android, ART realizează traducerea bytecode a aplicației în instrucțiuni native,
care sunt ulterior executate de mediu runtime al dispozitivului.

2.3.3 Scrierea ș i vizualizarea de loguri

Android Monitor include un monitor de loguri care afișează informaț iile necesare
depană rii. Afișează mesaje în timp real, și, de asemenea, păstrează o istorie, astfel încât să pute m
vizualiza mesajele mai vechi. Pentru a afișa doa r informația care ne interesează , putem crea
filtre, modifica, c ât de multa informație este afisată î n mesaje, nivelele de prioritate stabilite,
mesaje de afișare produse numai în funcție de codul aplicației și căutarea în istoric. În mod
implicit, monitorul logcat afiseaza output -ul celei mai recente lurări ale aplicaț iei.
Atunci când o aplicație aruncă o excepție, monitorul logcat prezinta un mesaj care conține link –

14
uri că tre cod. Această caracteristică poate ajuta la repararea erorilor și la îmbunătațirea
funcționă rii aplicației.

2.3.4 Folosirea utilitarului DDMS ( Dalvik Debug Server Monitor)

Android Studio include un instrument de depanare numit Dalvik Debug Server Monitor
(DDMS) care la r ândul său foloseș te ADB (Andro id Debug Bridge) care se bazează pe linia de
comandă și ne permite să comunicăm cu o instanță de tip emulator sau un dispozit iv Android
conectat. Facilitează o varietate de acț iuni ale dispozitivului, cum ar fi instalarea sau depanarea
aplicațiilor. Este un program client -server care include trei componente, ș i anume: un client care
trimite comenzi. Clientul rulează pe calculatorul de dezvoltare a aplicaț iei. Putem invoc a un
client din linia de comandă prin scrierea unei comenzi adb. Un daemon care execută comenzi pe
un dispozitiv. Acesta rul ează ca un proces pe fundal pentru fiecare emulator sau dispozitiv. Un
server, care gestionează comunicarea între client și daemon. Serverul rulează ca un proces de
fundal pe calculatorul de dezvoltare.
DDMS ne ajută la vizualizarea pa rametrilor dispozitiv ului, dar ș i a programelor care rulează . Se
poate accesa și din Eclipse, dacă dorim. Rolurile cele mai importa nte ale acestui utilitar este să
afiseze log -urile dispozitivelor, să afișeze informații despre procesele care rulează în acel
moment dar și ajută la controlarea simulatoarelor.
Acesta afisează informații de depanare ș i pentru simulatoarele care sun t conectate la calculator,
dar ș i la acele simulatoare pornite.
Logurile, care sunt mesajele im portante pe care le ofera DDMS și care apar în panoul Log Cat
conțin urmatoa rele date, fiecare fiind afisată pe o coloană :
• Tipul mesajului : I (Information ) care reprezintă mesajul, D(Debug) reprezintă mesajul
util depană rii, W (Warning ) reprezintă mesajul de avertizare, adică anumite excepții care
nu au o importa ntă ridicată ș i nu au un efect major asupra unor componente, E (Error)
reprezintă mesajul de eroare, V (Verbose ) reprezintă informațiile extra afișate de către
programe ș i care au o prioritate scazută.
• Timpul(Time) reprezintă data ș i ora cand mesajul a fos t scris
• PID reprezintă id-ul unui anumit proces care a determinat procesul
• Tag-ul util pe ntru filtre, deoarece reprezintă eticheta mesajului
• Mesajul (Message) care reprezintă un mesaj de tip text
Pentru a putea genera loguri pu tem folosi din clasa ‘Log’ fu ncțiile statice sau pu tem utiliza
mesajele (stdout) că tre consola care este standard.

15
Mesajele de tip log se pot filtra dupa PID și Tag în cazul în care dorim să urmă rim ceva speci fic,
și nu să vedem toate mesajele afișate î n LogCat. Cu ajutorul panoului d e control putem simula
primirea SMS -ului, apelului telefonic sau verificarea conexiunii vocii sau ce date sunt transmise
de că tre GPS.
Putem vizualiza ierarhia de view -uri cu ajutorul ‘hierachyviewer’ care atunci c ând este pornită
afișează o listă cu dispo zitivele Android conectate sau alte si mulatoare. Avem posibilitatea să
alegem un dispozitiv ș i pe ce componenta rulează, apăs ând pe ‘Load View Hierarchy ’. Ierarhia
de view -uri va f i în forma unui arbore cu proprietățile aferente afișate alăturat. Prioritat ea
vizualiză rii ierarhiei este destul de ridicată deoarece putem face anumite ajustă ri la realizarea
design -ului.
Din cele menționate mai sus putem spune că Android Studio este cel mai rapid mod de a construi
de înalta calitate aplicaț ii performante pentru platfor ma Android, inclusiv telefoane ș i table te,
Android Auto, Android Wear și Android TV. Av ând în vedere că este mediul oficial Google,
Android Studio include tot ce ai nevoie pentru a construi o aplicaț ie, inclusiv un editor de cod,
instrume nte de ana liza cod, emulatoare ș i multe altele. Ultima versiune are viteze de a construi
rapid ș i un emulator rapid cu suport p entru cea mai recentă versiune ș i servicii Google Play.
Android Studio este construit in c oordonare cu platforma Android ș i suporta toate c ele mai
recente API -uri. Cele mai noi caracteristici fiind: Run Instant pentru fiecare dezvoltator care
iubeș te a construi cu viteze mai mari și care face modificări ș i care are po sibilitatea de a le vedea
în mod direct. Android Emulator este un nou emulat or care ruleaza de 3 ori mai rapid dec ât
emulatoarele anterioare Android. În comparație cu opț iunea de conectare a unui dispozitv fizic
Android, acest emulator include, de asemeanea, Google Play S ervices incorporate, astfel înc ât să
putem testa mai multe f uncționalităț i API. În cele din urmă, noul emulator are noi caracteristici
bogate pentru a gestiona apeluri, bateria, rețea, GPS și multe altele.
Previzualizare GPU Debugger care este dedicat celor în curs de dezvoltare jocuri sau aplicații
bazate pe Open GLES, se poate vedea fiecare cadru și starea GL cu noul debugger GPU. 5

5 https://developer.android.com/studio/workflow.html
https://developer.android.com/studio/profile/investigate -ram.html
http://android.rosedu.org/2015/laborator -02-structura -android -depanare
http://www.and roidauthority.com/develop -apps-for-android -rather -than-ios-607219/

16
CAPITOLUL 3. ANDROID INTERFAȚA GRAFICĂ – XML

În cadrul aplicație o parte importantă o reprezintă interfața grafică care s e scrie separat de
codul aplicaț iei. Aceasta cuprinde elemen tele care afi sează informațiile pentru utilizatorul
aplicației. Interfața grafică se poate declara în două moduri:
Declararea elementelor UI î n XML
Instanț ierea obiectelor de tipul componentelor direct î n codul sursă. Aplicația poate creea obiecte
View ș i ViewGroup pen tru manipularea programatică. Avantajul declarării elementelor UI î ntr-
un fisier cu extensia .xml in di rectorul res/layout este usurința ș i lizibilitatea cu care se poate
întreț ine codul pe viitor. Cele mai uti lizate containere Android sunt: LinearLayout ,
RelativeLayout, TableLayout ș i ScrollView.

3.1 LinearLayout

Orien tarea sa indică dacă va ară ta ca și r ând sau coloană prin se tarea valorii ‚horizontal’
sau ‚vertical’ pentru orientarea android: orientation . Orientarea se poate modifica î n momentul
rulării prin apelarea metodei setOrientation ( ). Este obligatoriu să declară m atributele android:
layout_width ș i android: layout_height. Valorile u tilizate pentru aceste proprietăti pentru
definirea înălțimii ș i lungimii pot fi de o dimensiune d eclarată de noi, ca de exemplu 100px, sau ‚
wrap_content’ însemn ând că elementul UI va avea mărimea sa naturală în funcție de conț inut,
‚fill_par ent’ care va face ca widgetul să ocupe tot spațiul pă rintelui care este disponibil.
Proprietatea android: layout _weight care poate avea o v aloare (1,2,3…) este utilizată pentru a
aloca o anumită proporție de spațiu în funcție de valoarea atribuită, alocată widgetului respectiv
din spaț iul disponibil.

3.2 Relative Layout

Plasează widgeturile pe baza relației dintr e ele î n container ș i containerul părinte. Anumite
proprietăți XML(boolean) care ajută la poziț ionarea widgetului în concordantă cu pă rintele sunt:
android: layout _alignParentTop, android: layout _alignParentBottom, android :
layout_ alignParentLeft, android: layout_alignParentRight,android:layout_centerHorizontal,
android: layout_centerVertical, android: layout_centerInParent. Proprietăți care se folosesc
pentru poziționarea unui widget în concordanță cu un alt widget, ca de exemplu android:

17
layout_above, andr oid: layout_below, android: layout_toRightOf e tc. Pentru a putea utiliza
notația 'Relative ' în proprietăți trebuie în mod consistent să adaugăm identificator tuturor
elementelor cărora ne adresă m. Sintaxa este: @+id/…

3.3 Table Layout

Permite poziț ionarea w idget -urilor într -o grilă realizată din rânduri și coloane identificabile.
Coloanele se pot micșora sau extinde pentru a se adapta conținutului lor. TableLayout
funcționează împreună cu TableRow. Numă rul de coloane est e determinat de Android. Chiar ș i
așa un singur widget poate ocupa mai mult de o coloană incluz ând proprieta tea android:
layout_span, indic ând numă rul de coloane pe care w idgetul se poate extinde. O altă proprietate
definitorie pentru acest layout este android: stretchColumns=” … ” dacă conținu tul este mai
restrâns decât spațiul disponibil.

3.4 ScrollView Layout

Utilizat atunci când avem mai multe date decât ceea ce se poate afișa pe un singur ecran.
Acesta oferă defilare datelor . În acest fel, utilizatorul poate vedea doar o parte din interfaț a cu
date la un moment dat, iar restul este disponibil prin derulare.6
3.5 Cum funcț ionează Java ș i Android împreună ?

Java este un limbaj de programare orientat pe obiect. Acest lucru înseamnă că folosește
conceptul de obiecte de programare reutilizabil. Java este un limbaj care ne permite să scriem
cod o dată si care poate fi utilizat din nou. Acest lucru este foarte util, deoarece ne economiseș te
timp și ne permite să utiliză m codul altor persoane pentru a efectua anumite sarcini.
În Android este nevoie sa sc riem ș i propriul nostru cod î n Java, dar de asemenea ne folosim de
codul Java din Android API. Codul nostru compilat impreuna cu alte resurse este plasat intr -o
mulțime de fișiere ca ș i pachet Android, sub denumirea de ‘APK’ .
Android Studio este un mediu d e dezvoltare integrat (IDE), care are grijă de toate complexitatea
de compilare a codului nostru și face legătura dintre JDK și API -ul Android. Odată ce am instalat
JDK și Android Studio, putem face tot ceea ce avem nevoie în interiorul acestei aplicații.

6 Victor Matos, ‘Android Basic XML Layouts’, © 2008‐2009 CommonsWare, LLC. , p.2 -p.33

18
Ori de câte ori vom crea o nouă aplicație Android, vom alege un nume unic, cunoscut ca un
pachet. Pachetele sunt adesea separate în subpachete, astfel încât acestea să poată fi grupate
împreună cu alte pachete similare. Ne putem gândi pur și simplu la aces tea ca foldere și
subfoldere. Toate pachetele pe care API -ul Android le face dispo nibile pentru noi sunt ca si niș te
cărți care conțin cod, dintr -o bibliotecă. Anumite pachete Android comune, includ următoarele:
android graphics; android database; android. view. animation. Sunt aranjate ș i denumite sugestiv
pentru a fi c ât mai evident posibil ceea ce conțin. Aceste pachete conț in clase.
O clasă va fi aproape întotdeauna în propriul să u fișier, cu același nume ca și clasă, și cu extensia
.java. Î n Java, în continuare putem rupe î n continuare c lasele noastre în secțiuni care efectuează
diferite acțiuni pentru clasa noastră. Aceste secțiuni fiind cunoscute sub denumirea de metode.
Acestea sunt, de cele mai multe ori, metodele din clasa pe care o vom folosi pen tru a accesa
funcționalitatea oferită în cadrul tuturor acelor milioane de linii de cod. Noi nu avem nevoie
pentru a citi codul. Trebuie doar să știm ce clasă face ceea ce avem nevoie, î n care pachet este, și
care metode din cadrul clasei ne dau exact rezu ltatele.
Un 'Activityclass ' este o cla să specială Java și fiecare aplicație Android trebuie să aibă cel puțin
una. Este partea codului atunci can d aplicația noastră este lansată de către utilizator, iar acest
lucru se ocupă, de asemenea de orice interacțiu ne cu utilizatorul. Există î n Android Studio și
diferite șabloane gata făcute ale codului de clasă de activitate, în scopul de a oferi
programatorilor un start rapid atunci când creă m diferit e tipuri de aplicații. Pe masură ce
începem de la zero, opțiunea cea mai potrivită este Activity Blank.
Diagrama următoare prezintă o reprezentare a API -ului pentru Android. Putem vedea structura
codului, cu toate că vom avea cel mai probabil, doar un singur pachet pentru o aplicație. Desigur,
din cauza nat urii orienta te spre obiect de că tre Java, vom folosi piese selective din acest API. De
asemenea, fiecare clasă are propriile sale date distincte. De
obicei, în cazul în care dorim să facem acces la datele într -o
clasă, trebuie să aibă un obiect al acelei clase .
Activi tatea Numele ( ‘Activity Name’) este numele clasei
care va conține codul nostru.
Layout -urile Android UI sunt de obicei definite într -un fișier
text XML separat, nu î mpreuna cu codul Java. ‘ Package
declaration’ conține numele pachetului care î l alegem la
crearea proiectului. Fiecare fiș ier Java pe care îl alegem î l va
avea declarat deasupra codului. Unde sunt liniile de cod care
încep cu ‘import’ se fac importurile anumi tor clase. Putem
importa clase și ulterior atunci c ând dorim să îmbunătățim
aplicaț ia.

19
Daca ne uităm î ntr-unul din multitudinea de fiș iere cu exten sia’.xml’ primul lucru pe care îl
observă m este eticheta ‘RelativeLayout’, care este un element de interfață , care este utilizat
pentru a încadra alte părț i ale in terfeței de utilizare. Atunci c ând adăugăm un nou element UI,
întotdeauna î ncepem cu ‘<’ urmat de numele elementului. Codul care urmează după definește
proprietățile acelui element pe care îl avem. În XML putem avea proprietăți ca ș i
‘layout_height’, ’paddingRight’,’paddingTop’,’paddingBott om’. Propriet ățile pentru
‘RelativeLayout’ se vor î ncheia la primul simbol ‘>’. C odul </RelativeLayout> marchează
sfârșitul pentru RelativeLayout. Orice între acest simbol’>’ ș i </RelativeLayout > este considerat
copil al acelui element.
În programare, acea sta este întotdeauna o idee bună a scrie comentariile din belșug printre codul
scris.
Ne putem concentra pe punctele de vedere de design pe care Android Studio ne oferă:
• Bara de men iu, ca și în cazul a mai multor aplicaț ii, putem ajunge la aproape orice
opțiune de aici.
• Bara de instrumente, de la care se poate avea acces la una dintre numeroasele pictograme
de lansare rapidă. De aici, unele dintre cele mai frecvent utilizate opțiuni pot fi accesate
cu un singur clic.
• Bara de navigare. Ea ne arată locația f ișierului care este deschis în p rezent în fereastra de
editare î n cadrul proiectului nostru și ne permite să navigam rapid într -un fișier sau un
folder.
• Filele editor. Pot face clic pe o filă pentru a vedea conținutul său în fereastra editorului.
Există ma i multe fișiere în proiectul nostru decât sunt afișate în filele editor. Putem
adăuga un fișier la filele editor făcând dublu -clic pe ele în proiect ul explorator.
• Editorul unde ne vom petrece cea mai mare parte a timpului nostru. Fereastra editorului
se transformă într -un mini -studio de design. Și, de asemenea, efectuează alte transformări
sensibile la context pentru alte tipuri de fișiere.
Consola este un element principal î n Android Studio, care cuprinde urmatoarele tab -uri:
• Logcat: acesta este locul în care erorile, va apărea ieșirea Log, și alte informații utile.
• Logurile ADB: aceasta este ca o consolă virtuală în cazul în care putem executa din linia
de comandă.
• Memoria: se face clic pe această filă atunci când aplicația rulează pentru a vedea un
grafic de utilizare a memoriei aplicației. Putem folosi această filă pentru a căuta vârfuri
neașteptate în utilizarea de memorie și de a încerca și de a face aplicațiile noastre mai
eficiente în memorie.

20
• CPU: Accesă m această filă atunci când aplicația rulează pentru a vedea graficul de
utilizare a procesorului aplicației. Ajută la îmbunătățirea performanței aplicațiilor noastre
pentru a fi mai eficiente.
Există încă patru file in partea de jos. Dacă facem clic pe una dintre aceste file, fereastra Android
schimb ă numele ferestrei sau împarte fereastra curentă în două. Aici este ceea ce se poate face cu
cele patru file care se află sub fereastra Android:
• TODO: arată comentariile TODO răspândite pe întreg codul proiectului. Acest lucru este
cu adevărat util;
• Androi d: aceasta ne duce înapoi la fereastra An droid și cele patru file am menț ionat
anterior.
• Terminal: puteți utili za acest lucru pentru a naviga î n sistemul de operare și de a face tot
ce se poate face dintr -o fereastră consolă (DOS).
• Mesaje: după cum sugerea ză și numele, putem primi mesaje de eroare de sistem și în
această fereastră.
Alte elem ente ale consolei sunt cele două elemente din pa rtea st ânga jos a programului, ș i
anume: jurnalul de evenimente/Event Log ș i consola Gradle/Gradle Console
Imediat sub ce le două este bara de stare. Atunci când Android Studio este ocupat de a face ceva
ne va anunța aici.
De fiecare dată când Android Studio completează un eveniment important, este conectat la
jurnalul de evenimente. Î n cazul î n care nu ne amintim pașii pe c are i-am luat până atunci sau
dacă un anumit proces a fost finalizat cu succes, putem verifica aici.
Gradle este un sistem constructiv. Android Studio a utilizat Gradle pentru a automatiza procesul
de transformare a fișierelor din proiectul nostru într -o aplicație care poate fi rulată pe un
dispozitiv. Această consolă permite să dea instrumentului Gradle câteva comenzi și să vedem
răspunsul.
Fereastra de paleta/Pallete conț ine zeci de diferite elemente de design pe care le putem folosi.
Acestea sunt împărți te în categorii, ș i anume widget -uri și layout -uri.
Layout -urile sunt aspecte după cum sugerează și numele lor, folosite pentru aranja elementele
dintr -un cadru. Ceea ce este esențial, cu toate acestea, este modul în care diferite aspecte sunt
mai potr ivite pentru anumite situații. Î n plus, putem utiliza aceleași widget -uri pe diferite tipuri
de layout -uri, precum și codul XML care va fi generat poate varia destul de mult. Trebuie doar să
fim conștienți de diferitele situații adaptate fiecărui tip de aspect .
Widget -urile: sunt cele mai frecvent utilizate elemente de pe paletă. De obicei, vor exista mai
multe widget -uri conținute într -un aspect. Widget -urile sunt parte din aspectul pe care u tilizatorul
îl va vedea cel mai des și va interacț iona, ca de exempl u buton și widget -uri PlainTextView.

21
Câmpurile text sunt ca și PlainTextView din categoria Widgets, dar sunt foarte specifice tipului
de text care sunt cele mai potrivite și care sunt cel mai des utilizate atunci când utilizatorul
interacționează efectiv s au modifică valorile. Numele elementelor din categoria text Fields au
nume care fac aluzie la utilizarea lor probabilă.
Containere le sunt ca machete cu un anumit scop. De exemplu, Radio Groupcontainer va
avea mai multe elemente de buton radio din categoria widget. Containerul ScrollView va
organiza o grămadă de alte elemente și permite utilizatorului pentru a defila prin ele.
VideoView este un mod rapid și ușor pentru a permite utilizatorului să aibă un player video
complet funcțional cu foarte puțină codif icare.
De asemenea există elemente pentru data și oră, care se pot folosi în aplicaț ie sau elemente
avansate, ca de exemplu Surface View, NumberPicker, TextureView.
Elemtele Personalizate/Custom sunt acele blocuri constructive ale elementelor de aspect
specializate. Fragment este, probabil, cel mai puternic și versatil din toate elementele de aspect.
Aspectul de previzualizare/Layout preview este locul unde facem examinarea. Putem comuta
între peisaj și portret, refresh sau zoom previzualizare, și schimbare a dispozitivului virtual.
Arborele de componente. Pe parcurs ce layout -ul noastru poate deveni mai complicat, cu
elemente de aspect imbricate în interiorul altor elemente de layout -uri și widget -uri peste tot,
codul XML poate deveni greu pentru navigare. Componenț a Arborelui ne permite să vedem
structura, precum și elementele individuale ale design -ului nostru. Ne oferă ș i posibilitatea de
extindere, restrângere, glisare sau mutarea la o anumită secț iune a codului XML.

22
CAPITOLUL 4. Configurar ea și utilizarea widget -urilor

4.1 Dimensionar ea folosind pixeli independenț i

Widget -urile sunt toate elementele UI sub rubrica Widgets. Unele widget -uri au
proprietăți unice, dar există o mulțime de proprietăți care sunt comune. Widget -urile au
propriet ăți pe car e fie le putem seta în XML sau î n fereastra de Proprietăți.
Setarea dimensiunii widget -ului poate depinde de o serie de proprietăți și contextul în care
acestea sunt utilizate. Android utilizează o densitate de pixeli independenți sau dp ca unita te de
măsură. Modul în care funcționează este prin calcularea mai întâi a densitatii pixelilor de pe
dispozitiv a unei aplicații care rulează. Putem calcula prin împărțirea densitatii rezoluției
orizontale a dimensiunii orizontale, în inch, a ecranului. Ac est lucru se face tot on -the-fly, pe
dispozitivul pe care aplicația se execută. Din păcate, densitate de pixeli independenți este doar o
parte a soluției pentru ca aplicațiile sa arate foarte bine pe o gamă de diferite ecrane.
Putem schimba înălțimea și lă țimea unui widget în mod direct, prin adăugarea de cod pentru
proprietățile sale inaltime si latime. În mod alternativ, putem folosi fe reastra de proprietăți și
adaugăm valorile î n casetele de editare corespunzătoare.

4.2 Dimensionarea folosind pixeli sca labili

O altă unitate de măsură dependentă de dispozitiv, utilizat pentru dimensionarea
fonturilor Android sunt pixelii scalabili sau sp. Este utilizat pentru fonturi. Calculul extra pe care
un dispozitiv Android îl va lua î n considerare atunci când se de cide cât de mare va fi fontul,
bazat pe valoare a de sp utilizați, fiind propriile dimensionări ale fontului de că tre utilizator.

4.3 Folosirea padding -ului ș i a marginii

Padding -ul este spațiul dintre colțul widget -ului și conț inut.
Marginea este spaț iul dintre care este lăsată între widget -uri. Padding -ul afectează numai widget –
ul în sine, dar marginea poate afecta și alte widget -uri în layout sau putem specifica valori
diferite pentru margine s au padding sus, jos, margine st ânga, margine dreapta. Devine evident că
modul în care proiectam layo ut-ul no stru este extrem de flexibil. Specificarea valorilor este

23
opțională , și o valoare de zero, se va presupune dacă nu se specifică nimi c. Putem alege, de
asemenea menț ionarea unor valori pentru padding sau margi ne doar pentru an umite poziț ii și nu
pentru toate.

4.4 Folosirea proprietăț ii’ layout_weight’

Se referă la spaț iul dintre elementele UI. Așa că, pentru layout_weight să fie utilă, avem
nevoie de a atribui o valoare proprietății layout_weight pe două sau mai multe elemente. Acest
lucru este util mai ales pentru divizarea spațiului pe ecran între elementele UI în cazul în care
dorim spațiul pe care îl ocupă să rămână același, indiferent de dimensiunea ecranului. Cu ajutorul
layout_weight împreuna cu unități le de sp și dp putem face un aspect foarte simplu și flexibil.
Putem folosi numere întregi, procente, precum și orice alt număr pentru a da valoare proprietății
layout_ weight, și atâta timp cât acestea sunt una în raport cu cealaltă vor realiza, probabil, efectul
pe care îl dorim. Layout_weight funcționează numai în anumite contexte.
Cu ajutorul g ravityGravity, poate fi folosit în multe feluri în layout -urile noastre. Ne ajută să
modificăm poziția unui widget prin mutarea într -o anumită direcție; așa cum a fost a fi acționat
prin gravitație.

4.5 Folosirea proprietăț ii ‘gravity’

Se poate folosi î n diferite moduri. Ne ajută să modificăm poziția unui anumit widget într-
o anumită direcție aș a cum dorim.
Alte proprietăți mai des utilizate î n Android Studio sun t: background, textColor, a lignment,
typeface, visibility ș i shadowColor.
4.6 Fazele unei aplicaț ii Android

Sistemul Android are mai multe f aze, în care o aplicaț ie se poate afla la un mome nt dat.
În funcție de tipul fază , sistemul Android determină modul în care aplicația este văzută de către
utilizator. Android are aceste faze, astfel încât a ceasta poate decide care aplicaț ie este în curs de
utilizare și pentru a putea aloca cantitatea corectă de resurse, cum ar fi memoria și puterea de
procesare. Permit e, de asemenea, ș i dezvoltatorilor de aplicații interacționarea cu aceste faze.
Fiecare aplicaț ie de pe un dispozitiv Android este într -una dintre urmatoarele faze: creare,
pornire, reluare, rulare, pauza.

24
Mai jos am de scris pe scurt activitatea fiecă rei m etode:
• ‘onCreate’este executată atunci când se creează activitatea. Aici vom obține totul gata
pentru aplicaț ie, inclusiv interfața de utilizare (cum ar fi apelarea setContentView),
grafică și sunet.
• onStart este executată atunci când aplicația se află în faza de pornire.
• onResume se execută după onStart dar poate fi, de asemenea, introdusă ș i în cazul în care
activitatea noastră este reluată după ce a fost întreruptă anterior. Am putea reîncărca
datele utilizatorului salvate anterior din momentul în care a plicația a fost întreruptă,
probabil printr -un apel telefonic sau utilizatorul a executat o altă aplicație.
• onPause se execută atunci când aplicația este oprită temporar. Aici am putea salva datele
nesalvate care ar putea fi reîncărcate în onResume.
• onSto p se referă la faza de oprire. Acest lucru este în cazul în care ne -am putea anula tot
ceea ce am făcut în onCreate, cum ar fi eliberarea de resurse de sistem sau scrierea de
informații într -o bază de date.
• onDestroy este atunci când activitatea noastră es te în cele din urmă distrusă . Nu există
nici o cale de întoarcere în această fază. Aceasta este ultima noastră șansă de a desființa
aplicația noast ră într -o manieră ordonată. Dacă ajungem în această faza, când pornim
aplicaț ia din nou vo m trece din nou pri n fazele iniț iale.
Aceste metode pot fi suprascrise.
Numele metodelor corespund metodelor ciclului de viață și fazelelor de mai sus. Toate
declarațiile de metode sunt precedate de linia de cod @Override. Prima linie de cod în interiorul
fiecărei metode est e super. on. Ceea ce se întâmplă este că Android solicită metodele noastre în
diferite momente.
@Override indică faptul că, cuvântul cheie de suprascriere a acestor metode suprascrie versiunea
original ă a metodei, care este furnizată ca parte integranta a A PI-ului Android.
Sintaxa ‘ super. on’, care este prima linie de cod în cadrul fiecăreia dintre metodele de
suprascriere, solicită apoi aceste versiuni originale ale Androidului.
În concluzie nu trecem peste aceste metode originale, în scopul de a adăuga pro priul cod, noi le
numim, și de asemenea, codul lor este executat.7

7 http://android .rosedu.org/2015/laborator -02-structura -android -depanare
http://www.androidauthority.com/develop -apps-for-android -rather -than-ios-607219/
http://blog.venturesity.com/why -learn -android -programming -in-java
http://www.bestprogramminglanguagefor.me/why -learn -java
http://www.cnet.ro/2012/12/21/o -introducere -in-java-orientata -spre-aplicatii -pentru -android/

25

CAPITOLUL 5. SQLite

5.1 Despre SQLite
SQLite este o bibliotecă care implementează un motor de baze de date SQL și care nu
necesită configurare sau administrare. Codul pentru SQLite este public și liber pentru a fi utilizat
în orice scop, comercial sau privat. SQLite este baza de da te cel mai des folosit în lume în
aplicaț ii destul de variate, chiar și în aplicații de nivel foarte înalt, av ând un cod sursă comentat și
care oferă o acoperir e majoră prin teste.
SQLite este un motor de baze de date SQL încorporat. Spre deosebire de cele mai multe alte baze
de date SQL, SQLite nu are un proces server separat. SQLite citește și scrie în mod direct pe
fișierele de pe disc. O bază de date completă SQL cu mai multe tabele, indici, declanșatoare și
view -uri, este conținută într -un singur fișier de pe disc. Formatul de fișier de bază de date este
cross -platform avand posibilitatea să copiem în mod liber o bază de date între sistemele pe 32 de
biți și pe 64 de biți sau între arhitecturi. Aceste caracteristici fac SQLite o alegere populară ca un
format de fișier de tip Application. SQLite nu este un înlocuitor pentru Oracle, ci ca un înlocuitor
pentru fopen ().
SQLite este o bibliotecă compactă. Cu toate caracteristicile activate, dimensiunea bibliotecii
poate fi mai mică decât 500KiB, în funcție de set ările de platforma țintă și setă rile
compilatorului. În cazul în care caracteristicile opționale sunt omise, dimensiunea bibliotecii
SQLite pot fi reduse s ub 300KiB. SQLite poate fi, de asemenea, făcut pentru a rula într -un spațiu
minim(4KiB) și foarte puțin heap (100KiB), ceea ce face o alegere populara pentru SQLite ca
motor de baze de date cu memorie limitata pentru gadget -uri, cum ar fi telefoanele, play ere MP3
si PDA -uri. Există un compromis între util izarea memoriei și viteza. Cu c ât are mai multă
memorie SQLite se execută, în general mai rapid. Cu toate acestea, performan ța este de obicei
destul de bună chiar și atunci c ând, c antitatea de memorie este redusă .
SQLite este testat înainte de fiecare lansare și a re reputația de a fi foarte de î ncredere. Cea mai
mare parte a codului sursă SQLite este dedicată exclusiv testării și verificării. O suită de teste
automate rulează milioane și milioane de cazuri d e testare care implică sute de milioane de
declarații SQL individuale și atinge 100% acoperire pe fiecare ramura. SQLite răspunde cu grație
eșecurilor de alocare de memorie și disc I /O erori. Există teste speciale care simuleaza defecț iuni
ale sistemului, căderi de tensiune. Desigur, chiar și cu toate aceste teste, există încă bug -uri.
Spre deosebire de unele proiecte similare (în special concurenți comerciali) SQLite este deschis
la toate bug -urile și oferă liste de fiecare dată c ând sunt efectuate modif icări ale codului.

26
Baza de cod SQLite este sprijinită de o echipă internațională de progra matori care lucreaza la
SQLite î n mod permanent. Dezvoltatorii continuă să extindă capacitățile SQLite și de a
îmbunătăți fiabilitatea și performanțele sale menținând în același timp compatibilitatea cu
versiunile anterioare, sintaxa SQL, și formatul de fișier de baze de date. Codul sursă este absolut
gratuit pentru oricine care vrea, dar sprijinul profesional este de asemenea disponibil.

5.2 Trăsă turile cele mai impo rtante ale SQLite -ului

1.Nu este necesar un server special

SQLite nu are nevoie de un server cu proces separat sau un sistem special pentru a
funcț iona. Biblioteca SQLite accesează fiș ierele direct. Spre deosebire de cele mai multe produse
RDBMS, SQLite nu are o arhitectură client / server. Sistemele de baze de date la scară largă au
un pachet de server mare, care alcătuiește motorul bazei de date. De obic ei serverul bazei de date
constă î ntr-o multitud ine de procese, care gestionează conexi unile client, cache, optimizare
interog are și procesare de interogare. O bază de date de exemplu în mod obișnuit constă dintr -un
număr mare de fișiere organizate într -un singur sau mai mulți arbori de director pe sistem ul de
fișiere pe server. Pentru a putea accesa baza de date, toate fișierele trebuie să fie prezente și
corecte. Acest lucru poate fi dificil. Toate aceste componente necesită resurse și sprijin de la
calculatorul gazdă. Cea mai bună practică de asemenea, este ca sistemul gazdă să fie configurat
cu un serviciu de utilizator dedicate conturilor, scripturilor de pornire și de stocare. Din acest
motiv și pentru preocupările de performanță, se obișnuiește să se dedice un sistem informatic
gazdă exclusiv pentru software -ul serverului bazei de date.
Pentru a accesa baza de date, biblioteci software client sunt de obicei furnizate de către baza de
date furnizor. Aceste biblioteci trebuie să fie integrate în orice aplicație client care dorește să
acceseze serverul d e baze de date. Aceste biblioteci client oferă API -uri pentru a găsi și a se
conecta la serverul de baze de date, dar și configurează și execută interogări de baze de date și

27
comenzi.

Figura 1 -1 prezintă modul în care totul se potrivește într -un RDBMS ti pic client / server.

Mai jos este o imagine, care reprezinta arhitectura SQLite.Această simplitate face destul de
simpla portarea la SQLite pentru orice mediu, inclusiv telefoane, playere media portabile,
console de jocuri și altele.

Figura 1 -2. SQL ite-server cu mai puțina arhitectură .

SQLite este proiectat pentru a fi integrat direct într -un executabil. Ace sta elimină
necesitatea
unei biblioteci externe și simplifică distribuția și instalarea. Î nlătura de asemenea, cele mai multe
probleme a versiun ilor sau ca biblioteca c lient este versiunea compatibilă cu serverul de baze de
date. Eliminând serverul impune unele restricții, cu toate acestea. SQLite este conceput pentru a

28
aborda necesitățile de depozitare localizate, cum ar fi un server web care acc esează o bază de
date locală. Eliminarea se rverului impune anumite restricț ii. SQLite este c onceput pentru a
aborda necesităț ile de depozitare localizate, cum ar fi server web care accesează o bază de date
locală. Acest fapt înseamnă că nu este potrivită p entru situațiile în care mai multe masini client
au nevoie pentru acces la o bază de date centralizată.

2. Configurare zero

Din punct de vedere al ut ilizatorului, SQLite nu necesită instalare ș i configurare sau anumite
setari speciale. Este destul de practi c pentru proiectarea unei aplicații astfel încat selectarea unui
fișier este singura interacț iune pe care clientul o efectuează .
SQLite împachetează întreaga bază de date într -un singur fișier. Un singur fișier conține
structura bazei de date, precum și da tele reale din toate tabele le și indexurile.
Formatul de fișier este cross -platform și poate fi accesat de pe orice mașină. Având întreaga bază
de date într-un singur fișier se poate creea, copia, sau face o copie de rezervă a imaginii bazei de
date de pe disc. Baze de date întregi pot fi trimise prin email la colegi, postate sau revizuite.
Baze le de date întregi pot fi mutate, modificate, și partajate cu aceeași ușurință ca și un document
de procesare de text sau foaie de calcul. Nu există nici o șansă ca o bază de date sa fie corupta
sau indisponibile prin mutarea, stergerea sau redenumirea unui fisier accidental.

3. Acoperire pe toate platformele

SQLite oferă mai multe caracteristici care nu se găsesc în multe alte sisteme de baze de
date. Cea mai mare dif erență notabilă este că SQLite folosește un sistem de tip dinamic pentru
tabele. Motorul SQLite ne permite să punem orice valoare în aproape orice coloană, indiferent de
tipul acestora. Aceasta este o abatere majoră de la sistemele de baze de date tradițio nale. În multe
cazuri, sistemul de tip dinamic în SQLite este similar cu cel găsit în limbaje de scripting
populare, care au adesea un singur tip de scalare poate accepta orice de la numere întregi la ș iruri
de caractere. O altă caracteristică utilă este a bilitatea de a manipula mai mult de o bază de date la
un moment dat. SQLite permite o singură conexiune de baze d e date pentru a se asocia cu fiș iere
de baze de date multiple simultan. Acest lucru permite procesarea in strucțiunilor SQL care
accesează mai m ulte baze de date. Întreaga instantă a bazei de date se află într-un singur fișier,
care este c ompatibil pe toate platformele și care nu necesită administrare. O singură bibliotecă
conține întregul sistem de baze de date, care se integrează în mod direct î ntr-o aplicație gazdă.

29
4. Timpul de rulare foarte mic

Construcț ia implicita este mai mică decât un megabyte de cod și necesită doar câtiva
megaocteți de memorie. Cu unele ajustări, atât dimensiunea bibliotecii și uti lizarea memoriei
poate fi redusă semnifi cativ.Tran zactiile SQLite permit accesul în condiții de sigurantă la mai
multe procese sau fire oferin d un mediu de baze de date relaționale foarte funcțional ș i flexibil,
care con sumș resurse minime și care nu creează probleme dezvoltatorilor ș i utilizato rilor.
Dimensiunea mica a codu lui SQLite face sa fie potrivită ș i pentru sistemele de operare limitate.
Codul sursa ANSI C tinde spre un stil mai conservator care ar trebui sa fie acceptat chiar și de
către cele mai avansate compilatoare.
Scopul unei baze de date este de a păstra datele în siguranță și organizate. Dezvoltarea SQLite
pentru a menține un nivel ridicat de fiabilitate, procesul bibliotecii de baza SQLite
este testat în mod agresiv, înainte de fiecare lansare.
În totalitate, suitele standard de testare SQLite sunt alcatuite din peste 10 milioane de teste
unitare. Oferă o acoperire de 100%. Acest nivel ridicat de testare păstreaza numă rul de bug -uri
relativ scazut. Cele mai multe bug -uri care scapă sunt legate de performanță. Actualizarea la o
noua versiune a SQLite rareori cauzează probleme de compatibilitate. Acest lucru permite
echipei să facă modificări semnificative cu un risc relativ mic, redirection ând în mod constant
produsul și performanța.

5.3 Tabele

Cea mai comună comanda DDL este CREA TE TABLE. Nu există valori de date care pot
fi stocate într -un bază de date până când un tabel este definit pentru stocarea datelor. La crearea
tabelului se definește numele tabelului, plus numele fiecăr ei coloane. De obicei se defineș te un
tip pentru fiec are coloană, dar atunci cand se utilizeaza SQLite tipurile sunt opționale.
Constrângerile , condițiile și valorile implicite opționale pot fi de asemenea fi alocate fiecărei
coloane.

30

Figura. Crearea tabelelor

Nume clare și concise de identificare sunt importante păstrând în același timp scopul lor clar.
La fel ca și proiectarea bazei de d ate în sine.Cele mai multe baze de date folosesc tipuri de
coloane statice. Aceasta înseamnă că elementele unei coloane pot stoca numai valori compatibile
cu tipul def init coloanei. SQLite utilizează o tehnică dinamică cunoscută sub denumirea de
‘manifest typing’
Pentru fiecare valoare de pe fiecare r ând, se salvează valoarea cu tipu l specific. Acest lucru ne
oferă opțiunea să salvă m orice data de orice tip.
În cel mai strict mod, SQLite oferă doar cinci tipuri de date concrete. Acestea sunt cunoscute
ca și clase de depozitare, ș i reprezintă diferitele moduri î n care SQLite ar putea alege pentru a
stoca date pe disc. Fiecare valoare are una dintre aceste cinci clase de stocare native:
• NULL considerat propriul tip distinct. Un tip NULL nu deține o valoare.
Nuluri literale sunt reprezentate de cuvântul cheie NULL.
• Integ er considerat un număr întreg fă ra semn. Valorile întregi sunt de lungime variabilă,
fiind 1, 2, 3, 4, 6, sau 8 octeți în lungime, în funcție de dimensiunea minimă necesară
pentru a menține speci ficul valorii.
• Float reprezintă un număr în virgulă mobilă, care stocheaza o valoare de 8 octeți în
Numerele în virgulă mobilă sunt reprezentate de orice serie de cifre care includ un punct
zecimal sau exponent.
• Text reprezent ând un șir de lungime variabil ă, stocat utilizând codificarea bazei de date
(UTF -8, UTF -16BE, sau UTF -16LE)
• BLOB care reprezintă o lungime de bytes ca șiruri de text hexazecimale precedate de un
x. De exemplu, notația x'1234ABCD 'reprezintă un BLOB de 4 octeți.

31
Valorile de tip text și BLOB SQLite sunt întotdeauna de lungime variabilă. Dimensiunea
maximă a unui text sau valoarea BLOB este limitată de o directivă în timpul compilării. Limita
implicită este exact un miliard de bytes, sau puțin mai mic decât un gigabyte. Valoarea maximă
pentru această directivă este de doi gigabytes.
Având în vedere că elementele coloanelor pot stoca orice tip de valo are, "tip" al unei coloane
este un concept oarecum înșelător. Mai degrabă decât a fi un tip absolut, la fel ca în cele mai
multe baze de date, un tip coloană SQLite (așa cum este definit în CREATE TABLE), devine
mai mult o sugestie decât o regulă. Acest lucru este cunoscut ca un tip de afinitate, și reprezintă
în esență o categorie dorită de tip. Fiecare tip de afinitate are reguli sp ecifice cu privire la ce
tipuri de valori pot fi stocate, și modul în care diferite valori vor fi convertite atunci când sunt
depozitate în coloană. În general, un tip de afinitate va duce la o conversie sau migrarea tipului
numai dacă se poate face fără a pierde dat e sau precizie.
Fiecare coloană de tabel trebuie să aibă una dintre cele cinci tipuri de afinități:
• Text
O coloană cu o afinitate de tip text va stoca numai valori de tip NULL, text sau BLOB. Dacă
încercam să stocam o valoare de tip numeric (float sau întreg), acesta va fi convertită într-o
reprezentare de tip text, înainte de a fi stocate ca tip de valoare de tip text.
• Numeric.
O coloană cu o afinitate numerică va stoca oricare dintre cele cinci tipuri. Valori cu număr
întreg, float , împreună cu tipuri NULL și BLOB, stocate fără conversie. De fiecare dată când o
valoare de tip de text este memorată , se face o încercare de a converti valoarea la un tip numeric
(întreg sau float). În cazul în care conversia eșuează, valoarea text este stocată fără nici un fel de
conversie.
• Integer
O coloană cu o afinitate întreagă lucrează în mod esențial aceeași cu o afinitate numerică.
Singura diferență este că orice valoare cu un tip plutitor, care nu are o componentă fracționată
vor fi convertite într -un tip întreg.
• Float
O coloană cu o virgulă flotantă ca afinitate, de asemenea, funcționează în mod esențial la fel ca
afinitatea numerică. Singura diferență este că cele mai multe valori de tipuri de întregi sunt
convertite în valori în virgulă mobilă și stocate ca tip fl oat.
• None
O coloană cu afinitate nula nu are prioritate față de clasa de stocar e. Fiecare valoare este stocată
cu tipul prevăzut, cu nici o încercare de a converti nimic.

32
Din mo ment ce aceste tipuri de afinităț i nu fac parte din standardul SQL, SQLite ar e o serie de
reguli care încercă să mapeze tipurile de coloane la tipul de afinitate cea mai logică. Tipul de
afinitate a unei coloane este determinat de tipul declarat al coloanei.
În cazul în care s -a definit un tip de coloană, coloanei nu î i este asociat ă nici o afinitate. În cazul
în care tipul de coloană conține subșirul "INT", coloanei i este data
afinitate întreagă. În cazul în care tipul de coloană conține oricare dintre subșiruri "CH AR",
"CLOB," sau "TEXT"coloanei i este dată afinitatea textului . În cazul în care tipul de coloană
conține subșirul "BLOB ”, coloanei nu i s e asociază nici o afinitate. În cazul în care tipul de
coloană conține oricare dintre subșiruri "REAL", "FLOA," sau "DOUB" atunci i este dată
afinitatea float. În cazul în care nu i se potriveste nici u n tip, coloanei i este atribuită afinitatea
numerică.
Constrângerile de coloană pot impune limite pe o coloană, cum ar fi negarea NULL (NOT
NULL) sau care necesită o valoare unică pentru fiecare rând (UNIQUE). NULL nu este
considerată o va loare, deci UNIQUE nu implică NULL. Dacă dorim să păstram date NULL î n afara
unei coloane de tip UNIQUE, atunci este nevoie de a marca în mod explicit coloana NOT NULL. În
scopul de a pune în aplicare o constrângere de coloană UNIQUE , un index unic va fi a utomat creat
peste acea coloană. Un indice diferit va fi creat pentru fiecare coloană (sau un set de coloane)
marcate UNIQUE. Impunerea unei constrângeri pe o coloană unice poate avea considerente de
performanță.

5.4 Cheile primare

În plus față de aceste alte constrângeri, o singură coloană (sau set de coloane) pot fi
desemnate ca 'PRIMARY KEY '. Fiecare tabel poate avea doar o singură cheie primară. În cazul
în care o col oană este marcata atât UNIQUE c ât și PRIMARY KEY, va fi creat doar un singur
index. În SQLite, PRIMAR Y KEY nu implică NOT NULL. Acest lu cru este în contradicție cu
SQL standard și este considerat un bug. Ca urmare, este întotdeauna recomandat de a marca în
mod explicit cel puțin o coloană din fiecare PRIMARY KEY ca NOT NULL.
SQLite t rebuie să aibă o anumit ă coloană, care pot fi utilizată pentru indicele de stocare d e bază
pentru tabel. Coloana acț ionează ca un index. La fel ca multe alte sisteme de baze de date,
SQLite va crea o coloană ROWID ascunsă. Pentru a menține compatibilitatea , SQLite va
recunoaște numele ca ROWID ca referință pentru coloana ră dacină . În cazul în care un tabel
include o coloană ca si INTEGER PRIMARY KEY, atunci acea coloană devine un alias pentru
coloana automată ROWID. Ave m posibilitatea de a ne referenț ia în continuare la coloana
respectivă prin ROWID , sau prin numele definit de utilizator. Spre deosebire de PRIMARY

33
KEY simpla, coloanele INTEGER PRIMARY KEY au constr ângere NOT NULL automată . De
asemenea accepta numai valori întregi.
Există două avantaje semnif icative ale coloanelor INTEGER PRIMARY KEY. Coloana alias
coloanei ROWID rădăcina tabelului, nu are nevoie de un index secundar. Tabelul se comportă ca
index, oferind căutări eficiente.
În al doilea rând, coloanele INTEGER PRIMARY KEY pot furniza în mod au tomat
valori unice implicite. Atunci când inseram un rând fără o valoare explicită pentru RowId (sau
alias ROWID) coloană, SQLite va alege automat o valoare care este una mai mare decât cea mai
mare valoare existentă din coloană . Acest lucru oferă un mijlo c ușor de a genera automat chei
unice. În cazul în care se atinge valoarea maximă, baza de date va încerc a în mod aleatoriu alte
valori, în căutarea unei chei neutilizate. Cheile primare de tip numar întreg opț ional pot fi
marcate ca AUTOINCREMENT. În acest caz, valorile ID generate vor creș te în mod constant,
împiedic ând reutili zarea unei valori ID de la un r ând șters anterior. Dacă valoarea maximă este
atinsă, inserții cu valori automate INTEGER PRIMARY KEY nu mai sunt posibile. Cu toate
acestea pe rmite aproximativ 1000 de inserț ii pe secundă .
În plus față de o cheie primară, coloanele pot fi, de asemenea, marcate ca o cheie externă
FOREIGN KEY. Pot fi folosite pentru a crea legături între rânduri în tabele diferite.
Tabele virtuale pot fi folosite pentru a conecta orice sursă de date SQLite, inclusiv alte
baze de date. Un tabel virtual este creat cu comanda CREATE TABLE VIRTUAL. Cu toate că
foarte similar cu CREATE TABLE, există diferențe importante. Tabelele virtuale
nu poate fi create temporar, și nici nu permit o clauza IF NOT. Pentru a ren unța la un
tabel virtual, utiliză m comanda normală DROP TABLE.

34
CAPITOLUL 6. JSON
6.1 Despre JSON
Formatul de date JSON, un acronim în limba engleză pentru 'JavaScript Object
Notation ', este derivat din litera lii limbajului de programare JavaScript. Acest lucru face din
JSON un subset limbajului de programare JavaScript. Ca subset, JSON nu posedă nici un
caracter suplimentar pe care JavaScript nu îl are deja. JSON nu este un limbaj de programare, ci,
de fapt, u n format de schimb de date. Acesta este cunoscut ca standardul de transfer de date,
utilizat ca format de date ori de câte ori are loc schimbul de date. 8
JSON, pe scurt, este o reprezentare textuală definită de un mic set de reguli despre cum se
structur ează datele. Specificația JSON afirmă că datele pot fi structurate în oricare dintre aceste
variante:
1. O colecție de perechi de nume / valoare
2. O listă ordonată de valori

Figura . Diagrama de sin taxă a unei colecții de perechi/ valori in JSON

După c um arată diagrama, o colecție începe cu utilizarea parantezelor de deschidere ({), și se
termină cu utilizarea brațului de închidere (}). Conținutul colecției poate fi compus din oricare
din următoarele trei posibile căi: calea de sus ilustrează faptul că, colecția poate rămâne lipsită de
orice pereche sir / valoare. Calea de mijloc ilustrează faptul că , colecția poate fi cea a unui
singure perechi . Calea de jos ilustrează faptul că după o singură pereche de șir / valoare se poate
adauga orice număr de perechi de șir / valoare, înainte de a ajunge la sfârșit. Fiecare pereche de
șir / valoare trebuie să fie delimitat a sau separat a de cealalta prin virgulă (,).
Caracterele [ ] reprezinta un array, iar caracterele { } reprezinta un obiect. Acestea vin direct d in
limbajul Javascript.
Important de reț inut este faptul c ă, cheia unui membru trebuie să fie cuprinsă în ghilimele duble.
Cheia unui membru și valoarea sa trebuie să fie separata de către cele doua puncte(:). Valorile
null sunt scrise ca si ‚null’.

8 Ben Smith, ‘Beginning JSON’, Appress © 2015 , p.55 – p.58

35

JSON este caracterizat de simplitate ,viteză , reprezentarea efi cientă a da telor, citirea și înțelegerea
ușoară de către oameni, care ajută la transmitrea informațiilor între limbajul de pe server ș i cel de
pe partea clientului. Este un instrument mai de s folosi t decat XML -ul. Datorită acestui fapt
implementarea acestui a s-a facut posibilă î n majoriat atea limbajelor de programare, încep ând de
la C ++, Java, C#, chiar ș i Ruby, Perl, Phyton, PHP.
Formatul JSON acceptă urmă toarele tipuri de date:
• Numă r – de la 0 la 9, fracții, exponent, dublă precizie î n format Javascript
• String – trebuie scris î ntre ghilimele
Sintaxa: var json -nume -obiect = {”string”: valoare,….}
• Boolean – care poate fi adevă rat sau fals
Sintaxa: var json -nume -obiect = {string:true/false,….}
• Array – o secvență de valori cuprinsă î ntre paranteze drepte [] .Un array poate conț ine
mai multe obiecte.
Sintaxa: [valoare, …. ]
• Valoare – poate fi string, numă r, true/false, null etc.
• Obiect – o colecție neordonată de perechi cheie: valoare
• Spațiu liber – se poate utiliza î ntre token -uri
Sintaxa: {string: ” ”,…. }
• Null – utilizat pentru stocarea valorilor nule
Deoarece formatul JSON este numai text, acesta poate fi trimis cu ușurință către și de la
un server și utilizat ca format de date de căt re orice limbaj de programare. JavaScript are o
funcție construită pentru a converti un șir, scris în format JSON, în obiecte JavaScript native:
JSON.parse ()9
Un fișier JSON constă din mai multe componente. Ceea ce definește componentele unui fișier
JSON și descriere a acestora sunt: array -ul ([), î ntr-un fișier JSON, brațul pătrat ([) reprezintă o
matrice JSON; o biecte le ({), într-un fișier JSON suportul curl ({) reprezintă un obiect JSON ;
Cheia, u n obiect JSON conține o cheie care este doar un șir. Perech i de cheie / valoare alcătuiesc
obiect ul JSON ; Valoarea, f iecare cheie are o valoare care ar putea fi șir, număr întreg sau dublu
e.t.c.Pentru parsarea unui obiect JSON, vom crea un obiect de clasă JSONObject și vom
specifica un șir care conține date JSON. Ultimul pas este de a analiza JSON -ul. Un fișier JSON
este alcătuit dintr -un obiect diferit, cu o pereche de chei / valori diferite e.t.c. JSONObject are o
funcție separată pentru parsarea fiecărei componente a fișierului JSON. Metoda getJSONObject
return ează obiectul JSON. Metoda getString returnează valoarea șirului pentru tasta specificată.

9 https://www.w3schools.com/js/js_json_intro.asp

36
În afară de aceste metode, există alte metode furnizate de această clasă pentru o parsare mai bună
a fișierelor JSON. Aceste metode sunt :
• get (String nume) Această metodă returnează doar valoarea, dar sub forma tipului de
obiect .
• getBoolean (String nume) Această metodă returnează valoarea booleană specificată .
• getDouble (String nume) Această metodă returnează valoarea dublă specificată .
• getInt (String nume) Această metodă returnează valoarea întregului specificată de tastă .
• getLong (String name) Această metodă returnează valoarea specificată.
• length () Această metodă returnează numărul de mapări de nume / valori din obiect.
• names () Această metodă returnează o matri ce care conține numele de șir din acest
obiect.10

In org. json exista clasele JSONArray (o secvență densă indexată de valori),
JSONObject (un set modificabil de mapări de nume / valori), JSONStringer (implementează
toString () ), JSONTokener (parsează un ș ir codificat JSON (RFC 4627) în obiectul
corespunzător). Clasa JSONException care indică dacă este o problemă cu API -ul JSON. 11
JSONArray reprezintă o secvență densă indexată de valori. Valorile pot fi orice mix de
JSONObjects, alte JSONArrays, Strings, Bo oleans, Integers, Long, Double, sau Null. Valorile nu
pot fi NaNs, infinități sau orice alt tip care nu l -am enumerat mai sus.
JSONArray are același tip de comportament de constrângere ca JSONObject.
JSONObject reprezintă un set modificabil de mapări de nu me / valori. Numele sunt șiruri unice,
non-null. Valorile pot fi orice mix de JSONObjects, JSONArrays, Strings, Booleans, In tegers,
Long, Double sau NULL. JSONStringer oferă o modalitate rapidă și convenabilă de a produce
textul JSON. Textele au fost întoc mite în conformitate cu regulile sintaxei JSON. Nu se ad augă
spații albe, astfel încât rezultatele să poate fi stocate sau trimise mai departe. Fiecare instanță a
JSONStringer poate produce un text JSON.12
Un JSONTokener ia un șir sursă și extrage caractere din acesta. Este folosit de constructorii
JSONObject și JSONArray pentru a analiza șirurile de surse JSON.

10 https://www.tutorialspoint.com/android/android_json_parser.htm
11 https://developer.android.com/reference/org/json/package -summary.html
12
https://docs.oracle.com/cd/E51273_03/ToolsAndFrameworks.110/apid oc/assembler/com/endeca/serialization/js
on/JSONStringer.html

37

6.2 Maparea între entitățile JSON și Java

In tabelul d e mai jos sunt clasificate libră riile din Java care se utilizează pentru
conversia obiect elor Java î n obiecte de tip uri diferite JSON , dar și î n mod invers prin c lasa
org.json.simple.JSONObject.
JSON Java
string java.lang. String
number java.lang. Number
true| false java. lang. Boolean
null null
array java. util. List
object java. util. Map
13
6.3 JSON în comparaț ie cu XML
• Performanță – în termeni de performanță, JSON este cea mai bună opțiune. Acest lucru
este valabil atât pentru transferul real al datelor, cât și pentru parsarea datelor. Acest lucru
se datorează costurilor reduse neces are pentru formatarea JSON, care nu necesită
structura rigidă a copacilor / nodurilor XML.
• Lizibilitatea – Majoritatea browserelor (adică Chrome, Firefox) au JSON și display
XML construite și ambele sunt bine stabilite. Cu toate acestea, voi menționa că pe ntru
structuri de date mai complexe, XML tinde să o afișeze într -un mod mai intuitiv, ceea ce
mă conduce la al treilea punct.
• Complexitate – în timp ce JSON este proiectat pentru structuri de date rapide și slabe,
XML este construit pentru a gestiona struc turi de date de complexitate și adâncime
variată . Dacă luam în considerare o str uctură de date care are câmpuri, iar acestea au mai
multe straturi profunde (adică un obiect al unei companii care are o listă de obiecte de
clasă care au fiecare câte o listă de obiecte Angajat, fiecare având o listă cu alte date ). În
această situație , poate fi mai dificil prin JSONArray după ce JSONArray încearcă să
acceseze JSONObjectul corect. Aici, având un parser XML, în special unul care este
echipat cu limbi de tranziție , cum ar fi XPATH, poate fi un instrument extrem de puternic
pentru identificarea nod urilor precise pe care le dorim14.

13 Tutorials Point (I) Pvt. Ltd.,’JSON javascript object notation’, 2017, p.5 -p.15, p.29
14 https://thinkandroid.wordpress.com/2012/09/10/parsing -json-on-android/

38
CAPITOLUL 7
7.1 Interfața Aplicaț iei
Aceast ă aplicație este creată pentru testarea și îmbunătățirea cunoștințelor despre HTML
și CSS a tât la nivel începator, c ât și la nivel avansat. HTML este tehnologia fundamental ă a ceea
ce vedem într -un browser web, folosit ală turi de alte tehnologii precum CSS și Javascript.
Nivelul î ncepator HTML cuprinde î ntrebari referitoare la structura de bază a unei pagini web ,
taguri, definire antete pentru secț iuni, stilu ri de text, subliniere, modificări de text, combinare

proprietăți, adăugarea de referințe că tre alte pagini web. Nivelul avansat HTML cuprinde
întrebă ri compl exe care extind ceea se v erifică î n primul n ivel de teste c od, pe l ângă întrebări
despre alte noț iuni noi, cum ar fi sunet, animaț ie, inserarea unui script, blocuri, span etc.
Capitolul CSS cuprinde întrebări at ât la nivel începător, c ât și la nivel avansat. Av ând în
vedere ca HT ML suportă formatarea de baza a te xtului, CSS -ul se utilizează pentru stilizare,
prezentare și formatarea textului. Astfel că aceasta aplicație ajută la asimilarea și testarea
informațiilor învatate anterior. Nivelul începă tor CSS cuprinde întrebă ri refe ritoare la Figura 7.1 Ecranul Splash -Logo –

39

background, proprietăț i fonturi, poziționare, proprietăț i marg ini, padding, borduri, proprietăț i
liste etc. Următorul nivel cuprinde întrebă ri de dificultate mult mai ridicată referit oare la aspectul
paginii, animaț ie, tipografie, efecte, CSS3 si alte concepte.
La rularea aplica ției ecranul splash se va afișa pentru c âteva secunde. Acesta afisează
sigla aplicației și titlul, asigur ând o experiență plăcută utilizatorului la pornirea aplicaț iei android .
Instrumentul folosit pe ntru construirea aceste i aplicaț ii mobile este platforma open -source
Android, respectiv Android Studio ca ș i mediu integrat de d ezvoltare. Baza de date folosită este
SQLite care gestionează informația la nivel local, înregistrarea utlizatorilor, întrebarilor și
răspunsurilor pentru teste, nefiind necesară conexiunea la un server pentru trimiterea ș i preluarea
datelor din baza de date. Structura interfeței este construită din mai multe layout -uri prin
intermediul limbajului de mar care XML. Layout -urile salvate în directorul de res urse, î n
subdirectorul cu numel e de layout efectuează diferite roluri în cadrul aplicaț iei: ecranul splash
întâmpinare a utilizatorului, î nregistrarea utlizatorului, autentificarea utilizatorului în cazul î n
care are deja un cont creat, afiș area capitolelo r pentru teste, afiș area timpului efec tuat pentru
teste, revizuirea răspunsurilor corecte și incorecte și afiș area scorului final.

Figura 7.2 Layout Autentificare

40

Layout -ul pentru autentificarea utilizatorulu i activ ity_login .xml (figura 7.2) conține două casete
de text editabile. Pr ima casetă de text “Nume” pentru introducerea nu melui utilizat atunci cand s –
a înregistrat în aplicație, iar cea de a doua casetă “Parola” este pentru intro ducerea parolei pentru
contul să u. Sub cele două casete d e text există alte doua butoane pe care utilizatorul le poate
folosi , respectiv “L OGARE ” și “ÎNREGISTRARE ”. Atunci c ând utilizatorul completează
câmpurile corect și verificare a utilizatorului în cadrul tabelei destinată util izatorilor din baza de
date SQLite se execută cu success, atunci acesta este autentificat și poate accesa testele din
cadrul aplicației.

Figura 7.3 Autentificarea utilizatorului

41

În cazul în care utilizatorul apasă butonul ' LOGARE ', dar nu sunt compl etate toate c âmpurile se
afișează mesajul ' Completați toate câmpurile! ', după cum se observă în figura 7.3 . Dacă
utilizatorul introduce numele de logare sau parola incorect, atunci primeș te mesajul 'Utilizator
incorect ' apelând layout -ul 'customtoast.xml' și este invitat să introducă datele din nou în căsuțe ,
care sunt golite de informațiile eronate .
Butonul 'ÎNREGISTRARE' este creat cu scopul de a obține informații le de identificare
de la un utilizator nou. Apăs ând acest buton se face comutarea la un alt layout din cadrul
aplicației 'activity_signup.xml'.

În acest layout sunt create patru componente grafice de tip textView pentru inserare
nume, adresa de email, parola și confirmare parolă. Datele inserate de către utilizator în aceste
Figura 7.4 Înregistrarea unui nou utilizator în aplicație

42

căsuțe se v or folosi la autentificare. Pentru adresa de email se verifică daca conține cararcterul
arond @. În caz contrar, este afișat mesajul 'Email incorect' dupa cum se observă in figura 7.5.
La fel de important este faptul că se verifică daca parolele sunt ident ice, în caz contrar printr -un
obiect toast se afișează mesajul “Parolele introduce nu se potrivesc!” . Noul utilizator trebuie să
facă modificările necesare pentru a se putea înregistra cu success.

Figura 7.5 Mesaj de atenționare pentr u adresă de email și parole introduse incorect

43
Atunci c ând înregistrarea s -a efectuat , datele se salvează în baza de date în tabelul destinat
utilizatorilor. Persoana care s -a înregistrat primește mesajul “Înregistrarea s -a efectuat cu
succes ”, dup ă car e este activat layout -ul 'activity_chapters.xml ' , care permite afișarea și
selectarea capitolelor HTML și CSS (figura 7.6). Astfel că, utilizatorul care este înregistrat în
aplicație se poate loga mai t ârziu c ând dorește să facă un nou test din aplicație, fară a fii nevoit sa
se înregistreze din nou.

Figura 7.6 Înregistrare utilizator
În continuare utilizatorul poate selecta unul dintre cele două capitole disponibile HTML sau
CSS. Atunci c ând selectează butonul 'CAPITOLUL HTML ', se va accesa layout -ul
'activity_html_level.xml' , iar atunci când selecteaz ă 'CAPITOLUL CSS' se va accesa layout -ul
'activity_css_level.xml' .

44

Testele sunt clasificate în funcție de dificultate. Pentru fiecare buton selectat se f ace o
verificare în baza de date pentru a v erifica existența testelor, după care prin apelararea unui nou
layout denumit 'activity_questionlist.xml ' se afi șează fiecare întrebare . Este necesar ca
utilizatorul s ă aleagă o variantă de răspu ns, astfel înc ât butonul 'CONTINUĂ' să fie activat
pentr u afișarea următoarei întrebări (Figura 7.8).
Dacă este selectat butonul 'NIVEL ÎNCEPĂTOR', se vor accesa testele cu dificultate scăzută at ât
în capitolul HTML, cât și în capitolul CSS. Alegerea testelor de nivel avans at se face prin
accesarea butonului ' NIVEL AVANSAT'.

Figura 7.7 Meniul cu cele dou ă capitole de teste pe nivele de dificultate diferite

45

Figura 7.8 Întrebări nivel începător capitolul HTML

Nivelul începător are pentru fie care test zece întrebări cu cel puțin două variante de
răspuns. Acest layout cupride într -o componentă gra fică TableLayout un TableRow unde este o
altă componentă UI textView , care afișează întrebarea și un radioGroup cu butoane pentru
variantele de răspuns pentru fiecare întrebare. Din baza de date se vor prelua întrebările și de
asemenea răspunsul corect pentru fiecare întrebare . Dacă utilizatorul selectează răspunsul corect
acesta va fi luat în considerare în calcularea scorului. În ultima imagine din figura 7.8 se observă
faptul ca dacă o variantă de răspuns nu este selectată butonul 'Continuă' este inactiv . La finalul
parcurgerii întrebărilor din test se va afișa scorul total definit de numărul de întrebări la care s -a
răspuns corect, durata testului și opțiunea de a verifica răspunsurile corecte și g reșite pentru
fiecare întrebare sau reînceperea testului.

46

Nivelul avansat are pentru fie care test cinci întrebări cu patru variante de răspuns. Într-o
componentă grafică TableLayout este declarant un TableRow unde este o altă componentă UI
textView inserată , care afișează întrebarea și un radioGroup cu butoane pentru variantele de
răspuns pentru fiecare întrebare. Din baza de date se vor prelua întrebările și de asemenea
răspunsul corect pentru fiecare întrebare. Dacă utilizatorul selectează răspunsul corect acesta va
fi luat în considerare în calcula rea scorului. În ultima imagine din figura 7.9 se observă faptul ca
dacă o variantă de răspuns nu este selectată butonul 'Continuă' este inactiv. La finalul parcurgerii
întrebărilor din test se va afișa scorul total definit de numărul de întrebări la care s-a răspuns
corect, durata testului și opțiunea de a verifica răspunsurile corecte și greșite pentru fiecare
întrebare, opțiunea de reînceperea testului sau iesirea din aplicație.

Figura 7.9 Întrebări nivel avansat capitolul HTML

47
Figura 7.10 Întrebări nivel începător capitolul CSS

Nivelul începăt or din cadrul capitolului CSS are pentru fie care test zece întrebări cu cel
puțin două variante de răspuns (Figura 7.10) . Acest layout cupride într -o componentă grafică
TableLayout un TableRow unde este o altă component grafică UI textView, care afișează
întrebarea și un radioGroup cu butoane pentru variantele de răspuns pentru fiecare întrebare .
Preluarea întrebărilor și a răspunsului corect se face din baza de date, după ce se verifică
existența întrebărilor în tabel. Dacă utilizatorul selectează răspunsu l corect acesta va fi luat în
considerare pentru calcularea scorului final al testului efectuat . La fel ca și în cadrul capitolului
HTML, dacă o variantă de răspuns nu este selectată butonul 'Continuă' este inactiv. La finalul
parcurgerii întrebărilor din test se va afișa scorul total definit de numărul de întrebări la care s -a
răspuns corect, durata testului, opțiunea de a verifica răspunsurile corecte și greșite pentru fiecare
întrebare, opțiunea de reîncepere a testului sau iesirea din aplicație.

48

Nivelul avansat din cadrul capitolului CSS are pentru fie care cinci întrebări cu patru
variante de răspuns (Figura 7.11). Acest layout cupride într -o componentă grafică TableLayout
un TableRow unde este o altă component grafică UI textView, care afișe ază întrebarea și un
radioGroup cu butoane pentru variantele de răspuns pentru fiecare întrebare. Din baza de date se
preiau întrebările și răspunsul corect pentru fiecare întrebare. Dacă utilizatorul selectează
răspunsul corect acesta va fi luat în consid erare în calcularea scorului. Ca și în cadrul nivelului
începător, dacă o variantă de răspuns nu este selectată butonul 'Continuă' este inactiv. La finalul
parcurgerii întrebărilor din test se va afișa scorul total definit de numărul de întrebări la care s -a
răspuns corect, durata testului, opțiunea de a verifica răspunsurile corecte și greșite pentru fiecare
întrebare, opțiunea de reîncepere a testului sau se poate selecta butonul pentru iesirea din
aplicație de testare a cunoștințelor HTML și CSS.

Figura 7.11 Întrebări nivel avansat capitolul CSS

49

Figura 7.12 Layout -ul care afișează rezultatele testului

În figura de mai sus se accesează un nou layout 'activity_total_score.xml', după ce
întrebările din cadrul testului s -au terminat de parcurs. Într-un TextView se afișează scorul final.
Scorul a fost calculat în timp ce se răspundea la fiecare întrebare. Dacă răspunsul unei întrebări
ales de utilizator este același cu răspunsul corect preluat din baza de date, atunci se adaugă c âte
un punct.
Într-un alt TextView este afișat în cât timp a rezolvat uti lizatorul testul. Cele trei butoane
cu nume suggestive oferă utilizatorului posibilitatea de a reîncepe testul apăsând butonul
'REÎNCEPE' , posibilitatea de a revizui întrebarile și răspunsurile corecte și incorecte apăsând
butonul 'REVIZUIRE' și un buton c are permite ieșirea din aplicație, prin reîntoarcerea la ecranul
telefonului.
Accesarea butonului de reîncepere a întrebărilor va apela metoda 'retake(View)' din clasa
'TotalScore ’, care printr -un nou intent accesează din nou întrebările din clasa cu capit ole.
Accesarea butonului de revizuire a întrebărilor și răspunsurilor accează layout -ul
'activity_reviews.xml ', unde într -un TextView se afișează enunțul întrebării, iar variantele de

50

răspuns tot în cadrul elementelor de tip TextView, astfel înc ât nu se p ot edita. Răspunsul corect
ales de către utilizator semnifică faptul că, coincide cu răspunsul corect din baza de date si va fi
afișat în culoarea verde (Figura 7.13). În cazul în care utilizatorul alege un răspuns diferit de
răspunsul corect, acesta va fi afișat în culoarea roșie, în semnând faptul că nu a ales răspunsul
corect la întrebarea respectivă la oricare dintre capitole indiferent de nivelul de dificultate
(Figura 7.14).

Figura 7.13 Exemplu afișare întrebare
cu răspunsul corect selectat de utilizator
din revizuire
Figura 7.14 Afișarea unei întrebări în
care utilizatorul a ales variantă de răspuns
incorectă.

51
7.2 Activitățile Aplicaței Quiz App

7.2.1 AndroidManifest.xml

Elementul <manifest> este radacina pentru fișierul AndroidManifest.xml. Conține in mod
obligatoriu un element <application>, în care sunt cuprinse specifiicatiile despre
‘xmlns:android ’și package.
Atributul xmlns:android definește spaț iul de nume Android. Întotdeauna trebuie setat la
‘http://schemas.android.com/apk/res/android ’, și la fel este și in Quiz App.
La package, am adăugat un nume complet de pachet în stilul limbajului Java pentru aplicație.
Numele trebuie să fie unic "com.example.ralucabaila.quizapp". Pe l ânga aceste attribute, sunt
declarate alte atribute care au scopul de a permite aplicației să participe la infrastructura de
backup, să ofere support pentru afișarea l ayout -urilor din partea dreapta spre st ânga, tipuri de
intenții (‘intent filter’). La final, tot în elemental rădăcină manifest sunt declarate activitățile care
implementează interfața vizuală a aplicației. Toate activitățile trebuie să fie reprezentate de
elementele <activity> din fișierul manifest. În cazul în care nu este declarată o anumita activitate,
atunci nu va fi văzuta de system și nu va rula niciodată. În aplicația curentă, sunt opt activități, și
anume Login, SignUp, HtmlLevel, QuestionList, Tot alScore, Reviews, Chapters, CssLevel. În
randurile ce urmeaza, sunt descries mai detaliat.

7.2.2 Clasa AllQuestionsHtml și Clasa AllQuestionsCss

În clasa AllQuestionsHtml sunt cuprinse toate întrebările pentru capitolul HTML , nivel
începător și nive l avansat, iar în clasa AllQuestionsCss sunt cuprinse toate întrebările pentru
capitolul CSS. Clasa HashMap utilizată folosește un hashtable pentru fiecare clasă , pentru
implementarea interfeței Map . Având în vedere că fiecă rui element i se asociază o chei e unică de
tipul perechii cheie – valoare, nu o să existe chei duplicate. Se creează o listă pentru fiecare
întrebare din fiecare capitol , în care se vor pune opțiunile. Fiecare întrebare are o listă golă, unde
se vor memora opțiunile de răspuns ale aceste ia. Există o listă cu întrebări pentru nivelul
începător și o listă cu întrebă ri pentru nivelul avansat. Am declarat un HashMap numit
'htmlQuestionOptions' pentru clasa 'AllQuestionsHtml' și ’ cssQuestionOptions’ pentru clasa
'AllQuestionsCss' , unde într ebarea reprezintă cheia HashMap -ului ca și string, iar valoarea o
reprezintă variantele de răspuns ale întrebării respective ca și listă de string -uri. Prin aceasta
metodă de lucru, timpul de lucru al operațiilor de bază get () și put() pentru introducerea
informațiilor în HashMap -ul creat în aplicație rămâne constant chiar și pentru seturile mari.

52
7.2.3 Clasa DatabaseHandler

Importăm clasa SQLiteDatabase , care are metode de creare, ștergere, executare a
comenzilor SQL și realizarea altor activități comune de gestionare a bazelor de date și
clasa SQLiteOpe nHelper , care gestionează crearea bazei de date și versiunile acesteia. Clasa
declarată în această aplicație DatabaseHandler este o subclasă a clasei SQLiteOpenHelper.
Astfel că funcția onCreate ( SQLiteDatabase ) este apelată c ând baza de date este creată pentru
prima dată. Aici se inițializează crearea tabelelor și popularea inițială a tabelelor. Funcția
onUpgrade (SqliteDatabase, int versiuneAnterioară, int versiuneNouă) se apelează c ând trebuie
să fie actualizată baza de date, dacă dorim. Mai exact se pot adăuga sau șterge tab ele sau pentru a
trece la o nouă versiune de schemă.
În această aplicație este definită o constantă, cu scopul de a actualiza versiu nea bazei de date,
atunci cand se va schimba, după care este declarată variabila care contine numele bazei de date
actuale. Pentru tabelul utilizatorilor este declarată o variabila cu numele de ‘id’, care este un
identificator unic pentru fiecare utilizato r înregistrat în aplicație, o alt ă variabilă care reține
numele utilizatorului, dar și variabile pentru reținerea adresei de email și a parolei.
În baza de date SQLite din această aplicație sunt create două tabelele pentru capitolele cu teste
HTML și CSS: ‘TABLE_NAME_HTMLQUESTIONS’ și ‘TABLE_NAME_CSSQUESTIONS’.
Fiecare tabel are o coloană pentru cheile primare, care se autoincrementează și alte coloane
pentru întrebă ri și opțiunile de răspuns.
Metoda “addUser(newUser)” este creată pentru adăugarea unui nou utilizator în tabel. Prin
metoda publică getWritableDatabase() se deschide baza de date utilizată pentru citire și scriere.
Se cre ează un set gol de valori . În acest set de adaugă numele utilizatorului, adresa de email și
parola. La final se inserează în tabel întregul set de valori.
Pe lângă aceste metode, sunt create alte metode cu scopul de a insera întrebările î n tabelul
corespunzător fiecărui capitol în parte.
Metodele ‘getHTMLQuestions’ și ‘getCSSQuestions’ folosind o interogare SQL preiau
întrebăril e din tabelul corespunzător fiecărui capitol. Întrebările sunt parcurse prin intermediul
cursorului prin interație, utiliz ând un m odel de obiect pentru întrebare (clasa ‚Questions’).
Întrebările sunt prelua te de la primul identificator p ână la ultimul iden tificator. În obiectul
declarat anterior în fiecare metodă separat, setarea întrebărilor, opțiunilor și a răspunsului corect
se face tot cu ajutorul cursorului.
Metoda ‚checkUsers()’ este c reată pentru a verifica existenț a utilizatorului în tabela destinat ă
acestora. Prin intermedul unei interogări SQL, variabila 'counter' reține numărul utilizatorilor din
baza de date, care se va face prin intermediul curso rului. Pentru a valida faptul că sunt utilizatori
înregistrați în tabel, counter -ul trebuie să fie ma i mare dec ât zero.

53
Clasa Context permite accesul la resurse și la apeluri pentru operații la nivel de aplicație, cum
sunt activitățile de lansare, primirea intețiilor etc.

7.2.4 Clasa AppUsers

Clasă utilizată ca și model a tunci c ând se înregistrează utilizatorii.
În clasa DatabaseHandler este folosit un obiect de tipul acestei clase pentru adăugarea fiecărui
utilizator în tabelul utilizatorilor din baza de date. Utilizat ă de asemenea în clasa ‘SignUp’.
Această clasă este descrisă de atributele userName, email , password iar comportamentul este
definit de metodele setUserName (), setEmail ( ), setPassword ( ), getUserName ( ), getEmail ( ),
getPassword ( ).

7.2.5 Clasa CssLevel și Clasa HtmlLevel

Interacționează cu activitatea ‘activity_css_level ’, respectiv cu activitatea
‘activity_html_level’ și cu baza de date. Scopul acestor clase este de a inițializa o instanță a bazei
de date, de a număra c âte întrebari sunt în baza de d ate, iar în cazul în care în baza de date nu
sunt întrebări din capitolul CSS, respectiv HTML, însemnand că, counterul este egal cu zero,
atunci se adaug ă întrebările în baza de date apelând metoda ‚fillQuestions()’. În acestă metodă se
preiau întrebările d in clasa 'AllQuestionsCss ’, respectiv 'AllQuestionsHtml ’ nivel începător și
nivel avansat și se adaug ă fiecare întrebare într -un obiect de tip 'Questions'. Modelul acestui
obiect fiind creat in clasa 'Questions'. La final se salvează în baza de date.În caz ul în care
utilizatorul selectează componenta UI responsabilă de selectarea nivelului, începător , atunci se
va apela metoda
beginnerQuestions(View view)' gener ându-se în mod aleator întrebările prin
apelarea metodei create 'getRandomB()' . În cazul în care utilizatorul selectează componenta UI
responsabilă de selectarea nielului avansat , atunci se va apela metoda
advancedQuestions(View
view)' gener ându-se în mod aleator întrebările prin apelarea metodei create 'getRandomA()' .

7.2.6 Clasa SignUp

Cuprinde patru elemente de interfa ță pentru introducerea și mod ificarea textului. Aceste
câmpuri preiau numele utilizatorului, adresa de email, parola și confirmarea parolei. Apel ând
activitatea ‘activity_sign_up’, se vor ini țializa toate c ampurile UI prin metoda ‚findViewById

54
()’. La apăsarea butonului ‚Înregistrare ’, care este declarat in layout se apelează metoda
‚register() ’ . În această metodă se verifică dacă dacă fieldurile sunt completate, se verifică dacă
conțin caractere și dacă pa rolele coincid. De asemenea, se verifică în campul de introducere a
adresei de e mail dacă se gă sește caracterul arond '@'. În cazul în care nu se regăsește acest
caracter, atunci cu ajutorul unei ferestre de tip 'Toast', utilizatorul primește mesajul de "Email
incorect". Dacă unul din c âmpuri nu este comp letat atunci utilizatorul primeș te un alt mesaj "Vă
rog să completați toate fieldurile !" sau este anunțat de faptul că parolele intro duse nu sunt la fel
în ambele c âmpuri destinate acesteia, daca este cazul . La final, c ând activitatea se incheie c u
succes și datele sunt introduse ș i salvate în baza de date, utilizatorul poate accesa capitolele
HTML și CSS cu testele disponibile.
7.2.7 Clasa Login

Access ând layot -ul ‘activity_login.xml’, are rolul de autenti ficare a utilizatorului cu
numele de utilizator și parola contului. Se inițializează un obiect de tip DatabaseHandler,
casetele EditText care rețin numele și parola fiecărui cont și un obiect ‚Toast ’.
Se verifică daca sunt introduse datele în cele doua cas ete de editare, dacă numele și parola
utilizatorului sunt corecte. În caz contrar, se accesează un layout customizat 'custom_toast.xml'
care afișeaza o poză alături de un mesaj sugestiv ‚Utilizator incorect ’. În cazul în care se face
autentificarea fără sc rierea datelor în amebele câmpuri, se afișează prin intemediul unui obiect
'Toast' un mesaj de eroare 'Vă rog sa completați toate fieldurile!'.
Accesarea butonului 'Înregistare' a contului utilizatorului din acest layout apelează metoda
'signUp ( )' unde se declară și inițializează un nou intent, iar prin apelarea funcției
'startActivity(signUp)' se face trecerea către layout -ul, care se ocupă de înr egistrarea unui
utilizator nou.
7.2.8 Clasa ChooseLevel

În acestă clasă se inițializează un obiect de tip Dat abaseHandler, obiectul de interfață
grafică TextView, unde se afișează enunțul întrebării, butonul care face tranziția la următoarea
întrebare, butoanele de tip RadioButton care rețin variantele de răspuns, JSONArray -ul în care se
rețin întrebările din baz a de date.
Se utilizează layout -ul 'activity_questionList', iar prin metoda 'findViewById ( )' se accesează
fiecare component ă grafică de care este nevoie prin furnizarea unui nume identificator.
În intentul declarat se transmite nivelul de dificultate, pri n variabila 'level' și opțiunea selectată
din activitatea anterioară prin variabila 'option'. Opțiunile disponibile sunt pentru HTML

55
începător sau avansat și CSS începăto r sau avansat. Sunt scrise funcț ii care vor extrage din baza
de date în funție de opțiune și nivel întrebări din tabelul corespunzător fiecareia. În funcție de
opțiunea ș i nivelul selectat se apeleaz ă funcția din cadrul acestei clasei.
Nivelul începător ca avea c âte zece întrebări la fiecare test, iar la nivelul avansat sunt cinci
întrebăr i la fiecare test, cu mai mult de două variante de răspuns. Funcția 'placeQu estionUI', cu
ajutorul obiectului JSON declarat inițial plasează întreabarea și opțiunile de răspuns în TextView
și butoanele radio. Tot aici, se reține opțiunea aleasă și varianta corectă. Contorizarea întrebărilor
se reține în varaibila 'questionNO'.
Func ția 'enableDisableButton ( View view) ’ are rolul de a activa butonul care face tranziția către
următoarea întrebare din test. Înt âi, se verific ă dacă utilizatorul a selectat una di ntre opțiunile de
răspuns și prin apelarea metodei ' authenticateQuestion ( String question, String answer, String
tableName) ’ se preia din baza de date următoarea întrebare.
După parcurgerea setului complet de întrebări se lansează o nouă activitate, care trimite
durata efectuării testul ui prin variabila 'elapsedTimeMillis' , scorul testului apel ând clasa
'TotalScore.java'. La final se închide activitatea prin metoda ' onStop ( )'.

7.2.9 Clasa Reviews

În această clasă se face revizuirea întrebărilor pentru ca utilizatorul să poată verifica
răspunsurile corecte și greșite din cadrul testului. Se acceseaz ă layout -ul „activity_reviews” , în
care este declarat un TextView pentru afișarea întrebării, alte componente grafice TextView
pentru afișarea răspunsurilor, un buton denumit „Continuă” în partea dreaptă pentru a merge la
următoarea întrebare și un alt buton denumit “Capitole” pentru a revenii la Capitolele HTML și
CSS. Pe l ângă variabilele necesare p entru reținerea numelui tabelului, contorizare întrebări, se
creează o instanță a bazei de date dbHandler și de asemenea, se declară un JSONArray, unde se
pun întrebările puse și opțiunile lor. În metoda 'viewReview(int index ) ' întrebările se ajustează
pentru afișare. În prin cipiu fiecare întrebare are două varian te de răspuns, iar pentru a treia și a
patra variantă de răspuns dacă nu este disponibilă atunci se setează vizibilitatea 'setVisibility' pe
'INVISIBLE'.
O altă ramură a funcției este de a face ca răspunsul corect dat de utilizator să fie afișat în
culoare a verde , iar r ăspunsul incorect selectat este afișat în culoarea roșu. Celelalte variante de
răspuns care nu au fost selectate de utilizator vor rămane în culoarea negru.
La apăsarea butonului 'Continuă' fieldurile pentru opțiuni se resetează prin 'setText Color' și
'setVisibility'. La apăsarea butonului Capitole, se apelează clasa 'Chapters'. După parcurgerea

56
lungimii JSONArray -ului butonul 'Continuă' este dezactivat. La final activitatea se inchide prin
apelarea metodei 'onStop()'.

7.2.10 Clasa TotalScore

Afișează scorul total obținut de utilizator și numărul de întrebări rezolvate corect din
totalul acestora, acces ând layout -ul 'activity_total_score.xml ' . La ap ăsarea butonului 'Revizuire'
se acces ează metoda 'reviews(View)'apel ând clasa Reviews. Apăsa rea butonului 'Reîncepe testul'
apelează metoda retake(View), care apelează clasa Chapters . Atunci c ând se dorește ieșirea din
aplicație utili zatorul poate apăsa butonul 'Ieșire', apel ând metoda 'moveTaskToBack(true)'.