Aplicație pentru dispositive mobile [623061]

FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
2017

Aplicație pentru dispositive mobile
(Android), cu scopul de a calcula suprafețe
de teren, prin coordinate GPS
LUCRARE DE DIPLOMĂ

Autor: George Michael TAȘCU

Conduc ător științific: Prof.dr .ing. Honoriu VĂLEAN

FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE

DECAN
Prof.dr.ing. Liviu MICLEA Vizat,

DIRECTOR DEPARTAMENT AUTOMATIC Ă
Prof.dr.ing. Honoriu VĂ LEAN

Autor : George Michael TAȘCU

Aplicație pentru calcul ul unor suprafețe de teren, prin coordonate
GPS

1. Enunțul temei: Crearea unei aplica ții pentru identificarea poziț iei in timp real al
autobuzului dorit

2. Conținutul proiectului: (enumerarea p ărților componente) Pagina de prezentare ,
Declara ție privind autentic itatea proiectului, S inteza proiectului , Cuprins,
Introducere , Studiu Bibliografic , Tehnologii folosite, Analiză , Proiectare,
Implementare, Concluzii, Bibliografie.

3. Locul documentației: Universitatea Tehnic ă din Cluj -Napoca

4. Consultanți:

5. Data emiterii temei: 15 noiembrie 2016

6. Data predării: septembrie 2017

Semnătura autorului
Semn ătura c onduc ătorului științific

FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE

Declarație pe proprie răspundere privind
autenticitatea proiectului de diplomă

Subsemnatul(a) George Michael TAȘCU , legitimat(ă)
cu CI seria HD nr.609615 ,CNP [anonimizat] ,
autorul lucrării:
Aplicație pentru calculul unor suprafețe de teren, prin coordonate GPS

elaborată în vederea susținerii examenului de finalizare a studiilor de licență
la Facultatea de Automatică și Calculatoare ,
specializarea Automatică și Informatică Aplicată ,
din cadrul Universității Tehnice din Cluj -Napoca,
sesiunea Septembrie 2017 a anului universitar 2016 -2017 ,
declar pe proprie răspundere, că această lucrare este rezultatul propriei activități
intelectuale, pe baza cercetărilor mele și pe baza informațiilor obținute din surse care au
fost citate, în textul lucrării, și în bib liografie.
Declar, că această lucrare nu conține porțiuni plagiate, iar sursele bibliografice au
fost folosite cu respectarea legislației române și a convențiilor internaționale privind
drepturile de autor.
Declar, de asemenea, că această lucrare nu a mai fost prezentată în fața unei alte
comisii de examen de licență.
In cazul constatării ulterioare a unor declarații false, voi suporta sancțiunile
administrative, respectiv, anularea examenului de licență .

Data George -Michael TAȘCU
1.09 .2017
(semnă tura)

FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
SINTEZA
proiectului de diplomă cu titlul:
Aplicație pentru calculul unor suprafețe de teren, prin coordonate
GPS

Autor: George Michael TAȘCU
Conduc ător științific: Prog.dr .ing. Honoriu VĂLEAN

1. Cerințele temei: Implementarea unei aplicaț ii care permite utilizatorului s ă
masoare o suprafa ță de teren direct prin coordonate GPS .

2. Soluții alese: Proiectarea unui sistem de trasare a suprafeței pe harta și calcularea
acesteia .

3. Rezultate obținut e: Finalizarea aplicație i cu cateva funcționalități in plus, care vor
servi dezvoltării ulterioare .

4. Testări și verificări: Calcularea unei suprafețe deja cunoscute și verificarea
funcțiilor implementate .

5. Contribuții personale: Analiza , structurarea și implementarea aplicație i și încă
cateva funcții adiționale;

6. Surse de documentare: articole științ ifice, site-uri web, tutoriale online, cărți.

Semnătura autorului
Semn ătura conduc ătorului științific

1
Cuprins
1. INTRODUCERE ………………………….. ………………………….. ………………………….. ………………………….. 3
1.1 CONTEXT GENERAL ………………………….. ………………………….. ………………………….. …………………….. 3
1.2 OBIECTIVE ………………………….. ………………………….. ………………………….. ………………………….. …… 4
1.3 SPECIFICAȚII ………………………….. ………………………….. ………………………….. ………………………….. … 4
1.3.1 Specifica ții hardware ………………………….. ………………………….. ………………………….. …………. 4
1.3.2 Specificații software ………………………….. ………………………….. ………………………….. …………… 5
2. STUDIU BIBLIOGRAFIC ………………………….. ………………………….. ………………………….. ……………….. 6
2.1 PROGRAMARE ORIENTATĂ PE OBIECTE (POO) ………………………….. ………………………….. …………………. 6
2.1.1 Definire POO ………………………….. ………………………….. ………………………….. …………………….. 6
2.1.1.1 Obiectul ………………………….. ………………………….. ………………………….. ………………………….. ………. 6
2.1.1.2 Clasa ………………………….. ………………………….. ………………………….. ………………………….. …………… 6
2.1.2 Conceptele POO ………………………….. ………………………….. ………………………….. ………………… 6
2.1.2.1 Abstractizarea ………………………….. ………………………….. ………………………….. ………………………….. 7
2.1.2.2 Moștenirea ………………………….. ………………………….. ………………………….. ………………………….. ….. 7
2.1.2.3 Încapsularea ………………………….. ………………………….. ………………………….. ………………………….. … 7
2.1.2.4 Polimorfismul ………………………….. ………………………….. ………………………….. ………………………….. . 8
2.2 DEZVOLTAREA SOFTWARE PE ANDROID ………………………….. ………………………….. ………………………….. 8
2.2.1 Arhitectura software Android ………………………….. ………………………….. ………………………….. 8
2.2.1.1 Kernel Linux ………………………….. ………………………….. ………………………….. ………………………….. …. 9
2.2.1.2 Biblioteci ………………………….. ………………………….. ………………………….. ………………………….. …….. 9
2.2.1.3 Motorul Android ………………………….. ………………………….. ………………………….. ………………………. 9
2.2.1.4 Cadrul pentru aplicații ………………………….. ………………………….. ………………………….. ……………… 10
2.2.1.5 Aplicații ………………………….. ………………………….. ………………………….. ………………………….. ……… 10
2.2.2 Caracteristici Android ………………………….. ………………………….. ………………………….. ………. 10
2.2.3 Componentele unei aplicații Android ………………………….. ………………………….. ………………. 11
2.2.3.1 Activitatea ………………………….. ………………………….. ………………………….. ………………………….. … 11
2.2.3.2 Serviciul ………………………….. ………………………….. ………………………….. ………………………….. …….. 11
2.2.3.3 Intenția ………………………….. ………………………….. ………………………….. ………………………….. ……… 11
2.2.3.4 Mana gerul de conținut ………………………….. ………………………….. ………………………….. …………….. 11
2.2.3.5 Broadcast reciver ………………………….. ………………………….. ………………………….. ……………………. 11
2.2.4 Funcționalitățile unui sistem Android ………………………….. ………………………….. ……………… 12
2.2.5 Ciclul de viață al unei activități ………………………….. ………………………….. ………………………. 12
2.2.5.1 Running (În execuție) ………………………….. ………………………….. ………………………….. ………………. 13
2.2.5.2 Paused (Întreruptă temporar) ………………………….. ………………………….. ………………………….. …… 13
2.2.5.3 Stopped (Oprită) ………………………….. ………………………….. ………………………….. …………………….. 13
2.2.5.4 Destroyed (Inexistentă) ………………………….. ………………………….. ………………………….. ……………. 13
2.2.5.5 Metodele de navigare între stări ………………………….. ………………………….. ………………………….. .. 13
3. TEHNOLOGII FOLOSITE ………………………….. ………………………….. ………………………….. …………….. 15
3.1 ANDROID STUDIO ………………………….. ………………………….. ………………………….. …………………….. 15
3.1.1 Generalit ăți ………………………….. ………………………….. ………………………….. …………………….. 15
3.1.2 Structura unui proiect ………………………….. ………………………….. ………………………….. ………. 15
3.1.2.1 Application ………………………….. ………………………….. ………………………….. ………………………….. … 15
3.1.2.2 Gradle Scripts ………………………….. ………………………….. ………………………….. …………………………. 17
3.1.3 Interfața grafică ………………………….. ………………………….. ………………………….. ………………. 18
3.2 ANDROID SDK ………………………….. ………………………….. ………………………….. ………………………….. … 19
3.2.1 Generalități ………………………….. ………………………….. ………………………….. …………………….. 19
3.2.2 Android SDK Manager ………………………….. ………………………….. ………………………….. ……… 19

Introducere
2 3.2.3 Managerul AVD ………………………….. ………………………….. ………………………….. ………………. 20
3.2.4 Instrumente de depanare (Debugger) ………………………….. ………………………….. …………….. 21
3.3 FIREBASE ………………………….. ………………………….. ………………………….. ………………………….. ….. 21
3.3.1 Generalități ………………………….. ………………………….. ………………………….. …………………….. 21
3.3.2 Implementarea ………………………….. ………………………….. ………………………….. ……………….. 22
3.4 GOOG LE MAPS API V2 ………………………….. ………………………….. ………………………….. ……………… 23
3.4.1 Generalități ………………………….. ………………………….. ………………………….. …………………….. 23
3.4.2 GPS(Global Positioning System) ………………………….. ………………………….. ……………………… 23
3.4.3 Implementarea și consola Google pentru dezvoltatori ………………………….. …………………… 24
4. ANALIZĂ, PROIECTARE ȘI IMPLEMENTARE ………………………….. ………………………….. ………………. 27
4.1 ANALIZA ………………………….. ………………………….. ………………………….. ………………………….. …… 27
4.2 PROIECTAREA ………………………….. ………………………….. ………………………….. …………………………. 27
4.2.1 Diagrama claselor (UML) ………………………….. ………………………….. ………………………….. ….. 27
4.2.2 Diagrama cazurilor de utilizare (UML) ………………………….. ………………………….. …………….. 29
4.3 IMPLEMENTAREA ………………………….. ………………………….. ………………………….. ……………………… 30
4.3.1 Mediul de dezvoltare ………………………….. ………………………….. ………………………….. ……….. 30
4.3.2 Crearea și configurarea unei aplicații ………………………….. ………………………….. ……………… 30
4.3.3 Configurarea dispozitivului sau emulatorului ………………………….. ………………………….. …… 33
4.3.3.1 Configurarea dispozitivului mobil ………………………….. ………………………….. ………………………….. . 33
4.3.3.2 Configurarea emulatorului ………………………….. ………………………….. ………………………….. ……….. 34
4.3.4 Implementarea aplica ției ………………………….. ………………………….. ………………………….. ….. 35
4.3.4.1 Login Activity ………………………….. ………………………….. ………………………….. ………………………….. 36
4.3.4.2 Register Activity ………………………….. ………………………….. ………………………….. ……………………… 37
4.3.4.3 Map Activity ………………………….. ………………………….. ………………………….. ………………………….. . 38
4.3.4.4 Help Activity ………………………….. ………………………….. ………………………….. ………………………….. . 41
5. TESTARE ȘI VALIDARE ………………………….. ………………………….. ………………………….. ……………… 42
6. CONCLUZII ………………………….. ………………………….. ………………………….. ………………………….. …. 45
6.1 REZULTATE ………………………….. ………………………….. ………………………….. ………………………….. … 45
6.2 CONTRIBUȚII PERSONALE ………………………….. ………………………….. ………………………….. …………….. 45
6.3 DIRECȚII DE DEZVOLTAR E ………………………….. ………………………….. ………………………….. …………….. 46
7. BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. …………………………. 47

Introducere
3 1. Introducere
1.1 Context general
În prezent, dezvoltarea este bazat ă pe viteza de obținere a informaț iei și
accesibilitatea acesteia, iar cel mai important instrument pentru a maximiza aceste
lucruri este internetul. O altă caracteristică foarte importantă a vitezei de acces la
informație este reprezentată de dispozitivele cu acces la internet. Relativ cu două
decenii în urmă, principala unealtă folosită pentru accesul la internet a fost calculatorul,
dar în ziua de astăzi este preferat un smartphone. Acesta poate fii achiziționat la un preț
accesibil oricui și cu o performanță foarte ridicată, insoțită și de funcționalități cum ar fi
GPS, Wi -Fi, 4G, cameră foto/video, etc… Totuși, cea mai importantă caracteristică a
acestuia este portabilitatea, deoarece toate aceste funcționalităț i le avem la dispoziție, în
buzunar.
Un studiu ne arată că în 2016, 99.6% din piața mondială a smartphone -urilor
rulează ca sistem de operare Android sau iOS, Android deținând procentajul major de
81.7%[1]. Android este și o platforma software pentru smartphone -uri și tablete care
are la bază un kernel Linux. Dezvoltatorii siste mului sunt Andy Rubin, Rich Miner, Nick
Sears și Chris White, care au înființat compania Android în anul 2003, ce a fost
cumpărată de Google în 2005. În anul 2008, Android devine o platformă open source,
datorită coaliției Open Handset Alliance[2][3].
Din 2008 până în prezent, aplicațiile Android au devenit foarte frecvent utilizate
datorită faptului că sunt disponibile unui public larg, iar implementarea lor a devenit
accesibilă.
Limbajul nativ folosit în dezvoltarea aplicațiilor Android este Java, împreun ă cu
unele librării oferite de Google. Pentru a implementa o aplicație cu succes, se utilizează
un SDK (Software Development Kit), deoarece acesta compilează codul și resursele
adăugate în proiect. SDK -ul folosit în acest proiect și în multe altele este An droid SDK.
Acesta mai conține diferite unelte folositoare programatorului, cum ar fi: emulator,
debugger, documentație, tu toriale, secvențe de cod, etc… Rezultatul după compilare, este
un fișier de tip APK (Android application package), care va fi portat pe dispozitivul
Android sau pe un AVD (Android Virtual Device).

Introducere
4 1.2 Obiective
Aplicația a fost dezvoltată în așa fel încât orice utiliztor să poată beneficia de
aceasta, indiferent de locația sa. Utilitatea acestieia variază în funcție de in teresul
utilizatorului și este ușor de folosit.
Obiectivele principale ale dezvoltării acestei aplicații sunt:
 Posibilitatea de autentificare a user -ului cu un cont personal;
 Posibilitatea de înregistrare a unui cont nou de utilizator;
 Interfață simplă pentru o utilizare ușoară;
 Folosirea gesturilor în lucrul cu Google Maps pentru a beneficia de un ecran
puțin încărcat de butoane;
 Formarea suprafeței ce se dorește a fi calculată prin markeri plasați la
locația atingeri ecranului;
 Calculul suprafeței a formelor ne regulate, nu doar a triunghiurilor;
 Posibilitatea de curățare a hărții după fiecare calcul;
 Vizualizarea hărții în diferite tipuri, în funcție de natura suprafeței ce se
dorește a fi măsurată;
 Navigarea cu ușurință între activitățile aplicației;
 Și nu în u ltimul rând, dezvoltarea abilității personale de a utiliza și
aprofunda cunoștințe legate de implementarea aplicațiilor pe Android .

1.3 Specificații
Specificațiile unei aplicații reprezintă un set de infor mații pe care un sistem trebuie
să le îndeplineas că pentru a putea rula un program, o aplicație, etc… Aceste specifica ții
pot fi de doua tipuri :

1.3.1 Specifica ții hardware
Specificațiile hardware reprezintă descrierea componentelor fizice, aflate într -un
sistem informatic. Aceste componente servesc la culegerea, stocarea, prelucrarea,
transmiterea, afișarea, verificarea datelor, în funcție de rolul fiecăreia.
Specificațiile hardware folosite și minime:
 Pentru PC:
– Procesor: Intel Core i7 -4500U 1.8 GHz || minim Intel Pentium 4
2.4GHz;
– Memorie RAM: 8GB || minim 4GB;
– Memore pe hard: minim 2GB, recomandat 4GB;
– Rezoluție ecran: 1366×768 || minim 1280×800.

Introducere
5
 Pentru dispozitiv mobil:
– Procesor: Quad -Core 1.3GHz;
– Memorie RAM: 2GB;
– Memorie de stocare: 16GB;
– Rezolutie ecran: 1280×800;
– GPS: Da;
– USB: Da;
– Wi-Fi: Da.

1.3.2 Specificații software
Specificațiile software reprezintă descrierea părților logice a unui sistem
informatic. Produsul final trebuie să fie format pe baza specificațiilor cerute de client,
deoarece specificațiile software stau la baza înțelegerii dintre cum părător și dezvoltator.
Cu cât aceste specificații sunt mai bine stabilite înaintea începerii etapei de proiectare,
cu atât mai mult se poate reduce timpul reproiectării sau dezvoltării produsului final.
Specificații software folosite și minime:
 Pentru PC:
– Sistem de operare: Microsoft® Windows® 10 64 -bit || minim
Microsoft® Windows® 7 32 -bit, Mac® OS X® 10.10 (Yosemite) sau
Linux GNOME or KDE desktop;
– IDE(Integrated Development Environment): Android Studio;
– Adițional: Android SDK și JDK(Java Development Kit ).

 Pentru dispozitiv mobil:
– Sistem de operare: Android;
– Versiune: 5.1.1(Lollipop) || minim 4.2(Jelly Bean).

Dispozitivul mobil folosit pentru această lucrare este o tabletă Lenovo YT3 -X50F.
Am ales acest dispozitiv pentru a evidenția faptul că aplicația poate rula fără nicio
problema și pe o versiune de android învechită, dar și datorită dimensiunii ecranului,
mai exact 10.1 inch.
Dezvoltarea și testarea aplicației au fost realizate tot pe acest dispozitiv, ceea ce
reprezintă neutilizarea u nui AVD(Android Virtual Device), însemnând că toate fazele
aplicației au fost realizate pe un dispozitiv real.

Studiu bibli ografic
6 2. Studiu bibl iografic
2.1 Programare Orientată pe Obiecte(POO)
2.1.1 Definire POO
Programarea orientată pe obiecte(POO), sau OOP(Object -Oriented Programming) în
engleză, este o paradigmă, un model pe programare, ci nu un limbaj în sine. Există o
varietate de limbaje de pro gramare care implementează acest model, cum ar fi: Java, C#,
python, etc…
La baza POO se află 4 mari concepte, însă pentru a ne putea însuși aceste concepte,
mai întâi trebuie să înțelegem ce este un obiect și ce este o clasă.
2.1.1.1 Obiectul
Din punct de ved ere strict și pur OOP, un obect reprezintă o instant a unei clase.
Acesta poate fi văzut ca un lucru ce poate efectua un set de activități conexe, iar
comportamentul său este definit de acest set. Se identifică unic prin nume și poate fi
considerat un atri but al altei clase. Un obiect poate fi caracterizat de metode și attribute
definite în clasa căreia îi aparține.
2.1.1.2 Clasa
O clasa reprezintă un șablon prin care sunt descrise detaliile unui model după care
sunt create obiecte individuale. Clasa se caracterizează prin nume, attribute și metode.
Metodele reprezintă acțiunile sau operațiile pe care un obiect le poate executa, iar
atributele descriu valoric proprietățile unui obiect.
2.1.2 Conceptele POO
O aplicație OOP este constituită dintr -o mulțime de clase ce trebuie prelucrate și
manevrate. Pentru reducerea complexității unei aplicații, există diferite tehnici de
gestionare a claselor, ce le putem grupa în 4 concepte, anume [4][5] :
a) Abstractizare;
b) Încapsulare
c) Moștenire;
d) Polimorfism.

Figura 2.1 Concepte POO ;

Studiu bibliografic
7 2.1.2.1 Abstractizarea
Ascunderea detaliilor interne și demonstrarea funcționalității caracterizează cel
mai bine termenul de abstractizare. De exemplu, un apel telefonic, nu cunoaștem
procesarea internă, dar vedem efectul.
Abstractizarea înseamnă reprezentarea complexității prin utilizarea unor lucruri
simple. Știm cu toții cum să pornim televizorul, dar nu trebuie să știm cum funcționează
pentru a ne bucura de el.
Pentru a declara o clasă abstractă, folosim cuvântul cheie „ abstract”. Aceste clase
nu pot fi instantiate ci doar folosite drept super -clasă pentru a fi moștenită de alte clase.
O clasă abstractă este implementată atunci când se realizează o subclasă a acesteia,
însemnând că trebuie suprascrise toate metodele și pr oprietățile abstacte ale acestiea .

2.1.2.2 Moștenirea
Moștenirea este o caracteristică specială a programării orientate pe obiecte.
Aceasta permite programatorilor să creeze clase noi care să preia unele, sau toate
atributele unei clasei deja existente prin extinderea acesteia. Acest lucru ne permite să
ne bazăm pe munca anterioară fără a rescrie bucăți mari de cod de fiecare dată.
Pentru o înțelegere mai ușoară a aces tui concept, cel mai bine ar fi să luăm un
exemplu din lumea reală. Dacă spunem că un leu este un mamifer, ne referim la faptul că
acesta își însușește calitățile unui mamifer, de exemplu: naște pui vii, îi hrănește cu lapte,
are păr, etc…, dar pe lângă ac estea mai este și felină, prădător și se hrănește cu carne,
s.a.m.d. O vacă este tot un mamifer care își însușește caracteristicile generale ale
acestora, însă are alte caracteristici specifice cum ar fi: este bovină, animal domestic, se
hrănește cu iarbă, s.a.m.d. Atât leul cât și vacă moștenesc clasa mamifer datorită
caracteristicilor generale, dar și specializează mamiferele la propriile lor subtipuri
specifice.

2.1.2.3 Încapsularea
Încapsularea reprezintă păstrarea câmpurilor într -o clasă privată, oferind apoi
acces la ele prin metode publice. Este o barieră de protecție care păstrează datele și
codul în siguranță în clasa însăși, deoarece în acest fel putem reutiliza obiectele drept
componente de cod sau variabile, fără a permite accesul direct la date. Practic , ne
permite să reutilizăm funcționalitatea codului fără a compromite siguranță.
Încapsularea e ste un concept puternic în OOP, deoarece ne ajută să economisim
mult timp. De exemplu, putem crea o bucată de cod care să apeleze date specifice dintr -o
bază de date sau să reutilizăm acest cod cu alte baze de date deja existente. Încapsularea
ne permite să facem acest lucru păstrând, în același timp, datele originale private. De
asemenea, ne permite să modificăm codul original fără a îi afecta pe alții care l -au
adoptat între timp.

Studiu bibliografic
8 2.1.2.4 Polimorfismul
Polimorfismul este un termen generic care provine din două cuvinte grecești, poli
și morf.Poli înseamnă mai multe, iar morf înseamnă forme, așadar cuvântul s -ar traduce
„cu mai multeforme”. Mai precis, polimorfismul înse amnă capacitatea de a solicită ca
aceleași operațiuni săfie efectuate de către o gamă largă de tipuri diferite de lucruri.
În Java, polimorfismul funcționează utilizând o referință la o clasă părinte pentru a
afecta un obiect din clasa copil. Am putea crea o clasă numită „cal” prin extinderea clasei
„animal”. Această clasă ar putea, de asemenea, să pună în aplicare clasa „animale de
curse”. Clasa „cal” este „polimorfă”, deoarece moștenește atribute atât din clasa „animal”,
cât și din categoria „animale de c urse”. Putem folosi supraîncărcarea metodei și
suprascrierea metodei pentru a realiza polimorfismul.
În supraîncărcarea metodei, o singură metodă poate avea diferite rezultate, în
funcție de contextul în care se apelează. Aceasta înseamnă că un singur apel al metodei,
ar putea funcționa în moduri diferite, în funcție de argumentele pe care le transmitem.
În suprascrierea metodei, clasa copil poate folosi conceptul de polimorfism din
OOP, pentru a suprascrie o metodă a clasei părinte. Aceasta permite unui p rogramator
să utilizeze o metodă în moduri diferite, determinate de faptul că este invocată de un
obiect al clasei părinte sau de un obiect al clasei copil. Dezvoltarea software pe Android
2.2 Dezvoltarea software pe Android
2.2.1 Arhitectura software Android

Figura 2 .2 Arhitectura software Android ;

Studiu bibliografic
9 După cum se observă în figura 2.2, arhitectura sistemului de operare Android
cuprinde 5 secțiuni grupate pe 4 niveluri [6]:

2.2.1.1 Kernel Linux
Kernelul Linux (cu unele modificări) conține driver -ele pentru diferitele
componente hardware (ecran, camera foto, tastatură, antena WiFi, memoria flash,
dispozitive audio), fiind responsabil cu gestiunea proceselor, memoriei, perifericelor
(audio/video, GPS, WiFi), dispozitivelor de intrare/ieșire, rețelei și a consu mului de
energie.

2.2.1.2 Biblioteci
Bibliotecile (user -space) conțin codul care oferă principalele funcționalități a
sistemului de operare Android, făcând legătura între kernel și aplicații. Sunt incluse aici
motorul open -source pentru navigare WebKit, bibliotec a FreeType pentru suportul
seturilor de caractere, baza de date SQLite utilizată atât ca spațiu de stocare cât și pentru
partajarea datelor specifice aplicațiilor, biblioteca libc (Bionic), biblioteca de sistem C
bazată pe BSD și optimizată pentru dispozit ive mobile bazate pe Linux, biblioteci pentru
redarea și înregistrarea de conținut audio/video (bazate pe OpenCORE de la
PacketVideo), biblioteci SSL pentru asigurarea securității pe Internet și Surface Manager,
biblioteca pentru controlul accesului la sis temul de afișare care suportă 2D și 3D. Aceste
biblioteci nu sunt expuse prin API, reprezentând detalii de implementare Android.

2.2.1.3 Motorul Android
Moto rul Android este reprezentat de:
 un set de biblioteci de bază care permit utilizatorilor să dezvolte aplic ații
Android folosind limbajul de programare Java; acestea includ acces la
funcțiile telefonului (telefonie, mesaje, resurse, locații), interfața cu
utilizatorul, furnizori de conținut și gestiunea pachetelor (instalare,
securitate)
 mașina virtuală (Java) Dalvik este optimizată special pentru Android
(dispozitive mobile alimentate de o baterie, resurse de procesare și de
memorie limitate, sistem de operare fără swap). Arhitectura sa se bazează
pe registri, fiind echipată cu un compilator JIT (just -în-time), executabilul
obținut putând fi modificat când este instalat pe dispozitivul mobil. Întrucât
este utilizată o bibliotecă proprie ce pornește de la un subset al
implementării Java realizată de Apache Harmony, nu sunt conținute
pachetele pentru AWT / Swing, imprimare sau alte componente speciale.
Prin urmare, deși de poate utiliza versiunea curentă de Java (7) pentru
dezvoltarea aplicației, facilitățile ce pot fi folosite sunt limitate aproximativ
la versiunea 6. Bytecode -ul este compilat în fișiere .dex – Dalvik Executable
(în loc de .class), datele duplicate provenind din clase diferite (șiruri de
caractere, alte constante) fiind incluse o singură dată, motiv pentru care un

Studiu bibliografic
10 astfel de fișier necomprimat va avea o dimensiune mai mică decât o arhivă
.jar (compr imată). De asemenea, se permite ca fiecare aplicație Android să
ruleze în procesul propriu, într -o instanță a mașinii virtuale Dalvik.

2.2.1.4 Cadrul pentru aplicații
Cadrul pentru Aplicații expune diferitele funcționalități ale sistemului de operare
Android cătr e programatori, astfel încât aceștia să le poată utiliza în aplicațiile lor.

2.2.1.5 Aplicații
La nivelul de aplicații se regăsesc atât produsele împreună cu care este livrat
dispozitivul mobil (Calculator, Camera, Contacts, Clock, FM Radio, Music Player, S Note, S
Planner, Video Player, Voice Recorder), cât și produsele instalate de pe Play Store sau
cele dezvoltate de programatori.

2.2.2 Caracteristici Android
Principalele caracteristici ale unei aplicații Android [7]:
 La baza, e ste o aplicație Java executată de către o mașină virtuală Dalvik ș mașina
virtuală (VM) Dalvik execută fișiere „ .dex ”, obținute din fișiere „ .class ” Java , cu
ajutorul unei unelte „dx”, cu care se realizează conversia din cod Java în byte –
code ;
 Se distribuie într-un pachet Android (Android Package), care este un fișier de tip
„ .apk ”
 Aplicatia este executată de către sistemul de operare Android (un Linux multi –
utilizator), într -un sandbox;
 Fiecare aplicație are un ID utilizator unic și resursele sale pot fi accesate numai
de către acel utilizator;
 Fiecare aplicație rulează în procesul Linux propriu și în propria instanța de
mașină virtuală; în ciuda acestui fapt, două aplicații diferite pot avea același ID de
utilizator pentru a partaja resursele lor;
 Opera țiile critice (acces la Internet, citire/scriere date de contact, monitorizare
SMS, acces la modulul GPS), pot fi restricționate sau se poate solicita permisiunea
utilizatorului, utilizând fișierul manifest de configurare a aplicației,
„AndroidManifest.xml ”;
 O aplicație Android înseamnă una sau mai multe activități (o activitate poate fi
asociată cu un ecran sau o fereastră, dar este mai mult decât atât) și procesul
Linux;
 Ciclul de viață al unei activități nu este legat de ciclul de viață al procesului;
activitatea poate rula chiar în cazul în care procesul sau nu mai există;
 O a plicație poate executa o componentă (activitate) din altă aplicație;
componenta (activitatea) este executată de procesul de care aparține;
 O aplicație Android NU are un punct unic d e intrare, cum ar fi metoda „main() ” în
aplicațiile Java, C sau C++.

Studiu bibliografic
11 2.2.3 Componentele unei aplicații Android
Componentele principale ale unei aplicații Android sunt[7]:

2.2.3.1 Activitatea
 Activitatea reprezin tă o interfață cu utilizatorul și este resp onsabilă de
interacțiunea utilizatorului cu ecranul dispozitivului mobil ;
 O aplicație Android poate avea una sau mai multe activități;Fiecare
Activitate are propriul sau ciclu de viață, independent de ciclul de viață al
procesului asociat aplicației;
 Fiecare activitate are propria stare și datele acesteia pot fi salvate sau
restaurate;
 Activitățile pot fi pornite de aplicații diferite (dacă este permis);
 Are un ciclu de viață complex deoarece aplicațiile pot avea activități
multipl e și doar una este în prim -plan ;
 În SDK, Activitatea este implementată folosind o subclasă a clasei Acti vity
care extinde clasa Context.

2.2.3.2 Serviciul
 Un task care se execută în fundal, fără interacțiunea directă cu utilizatorul;
 Este gestionat de o instanță a clasei Serv ice.

2.2.3.3 Intenția
 Reprezintă o metodă de a comunica între componente folosită pentru a
descrie o operațiune care urmează să fie executată;
 Comunică printr -un mesaj asincron, pentru a activa alte activități sau
servicii, din cadrul activității curente;
 Este gestionat ă de o instanță a clasei Intent.

2.2.3.4 Managerul de conținut
 Este un API folosit pentru a gestiona datele private ale aplicației;
 Se ocupă cu transferul de date de la o aplicație la alt ape baza de permisiuni;
 Utilizează diferite metode p entru manevrarea datelor(fișiere, bază de date,
rețele, etc…);
 Implementat de o subclasă a clasei ContentProvider.

2.2.3.5 Broadcast reciver
 O componentă care răspunde la evenimentele difuzate la nivel de sistem;
putem spune că se comport ca un event handler global;
 Și aplicațiile pot iniția astfel de broadcast -uri;
 Implementat de o subclasă a clasei BroadcastReceiver.

Studiu bibliografic
12 2.2.4 Funcționalitățile unui sistem Android
În funcție de tipul dispozitivului (telefon, tabletă, smartwatch, smartTV, etc…),
funcționa litățile variază constant de la una la cealaltă. Totuși, putem enumera câteva
funcții care se regăsesc în toate aceste dispositive, anume:
 Wi-Fi;
 Posibilitate de stocare a datelor;
 Conectivitate pentru semnal de rețea și internet;
 Suport pentru fișiere mul timedia;
 Suport pentru mai multe limbi;
 Interfață grafică;
 Ecran tactil.

2.2.5 Ciclul de viață al unei activități
Acest ciclu este un aspect cheie înspre înțelegerea arhitecturii unei aplicații mobile
Android, și trebuie stăpânit de programator pentru a -l putea controla. Ciclul este format
din 4 stări (etape) controlate de 7 metode „ callback ”, oferite de clasa „Activity” , ce vor fi
prezentate ulterior [7].

Figura 2.3 Ciclul de viață al unei activități ;

Studiu bibliografic
13 2.2.5.1 Running (În execuție)
Activitatea a fost creată ( onCreate() ), pornită ( onStart() ) și este afișată pe
ecranul aparatului; în cazul în care activitatea a mai fost utilizată și aplicația a salvat
starea acesteia ( onSaveInstanceState() ), activitatea este reluată din acel punct
( onRestoreInstanceState() și onResume() ); în această stare utilizatorul interacționează
cu activitatea prin intermediul interfeței dispozitivului (t astatură, touchscreen, display).

2.2.5.2 Paused (Întreruptă temporar)
Activitatea pierde prim -planul ( onPause() ), deoarece o altă activitate este
executată, cum ar fi o fereastră de dialog; de asemenea, în cazul în care aparatul intră în
modul sleep, activitatea este oprită temporar; activitatea își poate relua execuția
( onResume() ) și e ste plasată înapoi în prim -plan.

2.2.5.3 Stopped (Oprită)
Activitatea nu este mai în uz și pentru că este oprită ( onStop() ), nu este vizibilă;
pentru a fi reactivată (ea deja există), activitatea trebuie să fi repornită ( onRestart() și
onStart() ) și rel uată ( onResume() ).

2.2.5.4 Destroyed (Inexistentă)
Activitatea este distrusă ( onDestroy()) și memoria s -a eliberat, deoarece nu mai
este necesară sau sistemul are nevoie de memorie suplimentară pentru rutinele proprii
ori pentru alte activități; deoarec e managementul memoriei este un aspect important
pentru sistemul de operare Linux al dispozitivului mobil, procesul care găzduiește o
activitate întreruptă, oprită sau distrusă, poate fi terminat pentru a elibera memorie
pentru noi activități; doar procese le ce gestionează activ ități ce rulează sunt protejate.

2.2.5.5 Metodele de navigare între stări

1) onCreate(Bundle) – apelată când activitatea este creată; folosind argumentul
metodei de tip Bundle există posibilitatea să restabiliți starea activității, ca re a
fost salvată într -o sesiune anterioară; după ce activitatea a fost creată, va fi
pornită ( onStart() );

2) onStart( ) – apelată în cazul în care activitatea urmează să fie afișată; din acest
punct, activitatea poate veni în prim -plan ( onResume() ) sau rămâne ascunsă în
fundal ( onStop() );

3) onResume( ) – apelată când activitatea este vizibilă iar utilizatorul poate
interacționa cu această; din această stare, activitatea poate fi plasată în fundal,
devenind întreruptă ( onPause() );

Studiu bibliografic
14 4) onRestart( ) – apela tă în cazul în care activitatea revine în prim -plan dintr -o
stare oprită (stopped); după această, activitate este pornită ( onStart() ) din nou;

5) onPause( ) – apelată atunci când sistemul aduce în prim -plan o altă activitate;
activitatea curentă este mutată în fundal și mai târziu poate fi oprită ( onStop() )
sau repornită și afișată ( onResume() ); acesta este un moment bun pentru a
salva datele aplicației î ntr-un mediu de stocare persistent (fișiere, baze de date)
deoarece după această faza activitatea poate fi terminată și distrusă fără a se
anunță acest lucru.

6) onStop( ) – apelată în cazul în care activitatea nu mai este utilizată și nu mai
este vizibilă d eoarece o altă activitate interacționează cu utilizatorul; din acest
punct, activitatea poate fi repornită ( onRestart() ) sau distrusă ( onDestroy() );

7) onDestroy( ) – apelată în cazul în care activitatea este distrusă, iar memoria sa
eliberată; acest luc ru se poate întâmplă în cazul în care sistemul necesită mai
multă memorie sau dacă programatorul termină explicit activitatea apelând
metodă finish() din clasa Activity[7].

Tehnologii folosite
15 3. Tehnologii folosite
3.1 Android Studio
3.1.1 Generalit ăți
Android studio este IDE-ul (Integrated Development Environment) oficial pentru
dezvoltarea de sofware pe android. Acesta este bazat pe un nucleu IntelliJ, dar mai are și
alte unelte suplimentare, specifice dezvoltării pe android, pentru a face munca mai
ușoară pentru programa tori. Înainte de Android Studio, programatorii foloseau ca
mediu de dezvoltare android, Eclipse împreună cu un ADT (Android Developmnet
Tools). Și -a făcut apariția în mai 2013 cu prima versiune 0.1 dată spre testare, iar în
decembrie 2014 a apărut și prima versiune stabilă 1.0. Ultima versiune stabilă fiind
2.3.3, voi aborda cât eva dintre beneficiile acesteia:
 Integrare cu GitHub pentru a importa cod sau pentru a construi părți
comune ale aplicațiilor;
 Integrarea unor template -uri pentru tipuri de activităț i comune;
 Un sistem Gradle mai flexibil;
 Suport C++ și NDK;
 Suport încorporat cu Google Cloud Platform;
 Instrumente pentru testare mai performante;
 Emulator mai performant și mai rapid;
 Mediu unificat în care se poate dezvolta pe toate dispozitivele;
 Instant Run.

3.1.2 Structura unui proiect
Pentru a putea naviga cu ușurință printre fișierele componente ale unui proiect
android, este impotant ca programatorul să cunoască structura acestui pr oiect. Implicit,
structura proie ctului este afișată sub form a „Android project view”, însă Android studio
ne permite să selectăm și alte 9 view -uri pe langa acesta, în funcție de interesul nostru,
acelea fiind: Project, Packages, Scratches, Project Files, Production, Problems, Tests,
Local Unit Tests și Android Ins trumented Tests. În continuare voi prezenta view -ul sub
formă „Android project”, care se împarte în 2 mari părți, anume Application și Gradle
Scripts.

3.1.2.1 Application
Această parte a proectului este structurată la rândul ei în 3 părț i:
 Manifests: Acest folder conține fișierul AndroidManifest.xml. Acesta este unul dintre
cele mai importante fișiere ale unei aplicații Android și este conținut de toate
acestea. Aici se definesc informațiile de care are nevoie sistemul înainte de a rula o
aplicație, câteva d intre acestea fiind:

Tehnologii folosite
16  permisiunile de care are nevoie sistemul pentru a accesa func ții ale
dispozitivului;
 descrierea componentelor aplicației: activități, servicii, etc…;
 setarea unui nume de pechet ce servește drept identificator unic fiecărei aplicaț ii;
 definește relațiile de conexiune între părțile componente ale aplicației sau
conexiunile cu alte aplicații;
 realizează integrarea cu API -urile folosite în cadrul aplicației.

Figura 3.1 Android Manifest file;

 Java : Acest foler conține fișierele sursă ale aplicației, acelea fiind: Clase, Activități,
etc…, dar și codul de test JUnit. Practic aici se vor găsi funcționalitățile aplicației pe
care programatorul dorește să le implementeze.

 Res: După cum spune și numele, î n acest folder se găsesc toate resursele unui proiect
Android, ce nu conțin cod sursă, organizate în felul următor:
 Drawable : în acest director se găsesc toate imaginile din cadrul proiectului, cum
ar fi: background -urile de la unele activități, imagini fol osite în proiect, etc..; dar
poate conține și fișiere .xml, definite de utilizator, care servesc dr ept model
pentru o componenț ă cum ar fi forma sau backgroundul unui buton. Putem spune
că este asemenea unui ListAdapter personalizat.

 Layout: acest directo r conține fișierele .xml ce reprezintă interfața grafică a
activităților aflate în directorul Java. Se poate spune că aceste fișiere reprezintă
partea de front -end pentru aplicațiile android, iar activitățile reprezintă partea de
back -end. Sunt formate din unul sau mai multe layout -uri ( Linear, Relative, etc…)

Tehnologii folosite
17 sau fragmente, ce c onțin elemente de interacțiune ( Butoane, textViews, etc…), iar
acestea formează i nterfaț a cu care interacționează utilizatorul.
 Mipmap: aici se găsesc iconițele aplicației în di ferite dimensiuni, pentru a avea o
claritate bună pe orice rezoluție, în funcție de dispozitivul utilizatorului.

 Values: în acest director se regăsesc fișiere .xml, care definesc un set de valori
care sunt recunoscute în tot proiectul. De exemplu, în fiși erul „strings.xml” se pot
defini șiruri de caractere folosite în cadrul proiectului cum ar fi: numele aplicației
sau cheia de la Google API, sau elementele dintr -un spinner, s.a.m.d. În fișierul
”colors.xml”, după cum îi spune și numele, se pot defini culo ri în cod hexazecimal,
sub un nume stabilit de utili zator.

3.1.2.2 Gradle Scripts

Figura 3.2 Gradle.build file;

Pe scurt, putem spune că gradle este un build system. Acest sistem ia automat
toate fișierele .java sau .xml și aplic ă unealtă necesară construirii( de exempu dx ia
fișierele .java și le transformă în .dex, pentru a putea fi rulate de mașina virtuală Dalvik),
după care le grupează într -un fișier comprimat, acesta fiind APK -ul.
Tot în gradle, există și un sistem bazat pe plugin. Acest sist em ne permite
introducerea API -urilor și a pachetelor de pe GitHub sau alte surse externe, direct prin
compilarea acestora.

Tehnologii folosite
18 Google a implementat acest sistem de construcție, deoarece utilizatorii pot crea
scripturi personale, fără a fi necesar să dețină c unoștințe de Groovy sau alte limbaje noi
și fără a fi nevoiți să învețe detalii importante de programare „low level” pentru a
înțelege ce tool -uri să folosească din SDK.

3.1.3 Interfața grafică
În această secțiune vă voi prezenta pe scurt i nterfața mediul ui de dezvoltare
Android Studio, pentru a vă familiariza cu aspectul grafic al acestuia.

Figura 3.3 Interfața grafică Android Studio;

1. Bara de unelte (Toolbar): Aceasta conține scurtături la funcțiile de bază
ale unui editor de text (Salvare, Deschidere, Înapoi, Decupare, Lipire,
Copiere, etc…), dar și scurtături la câteva funcții principale și des folosite în
Android Studio (Rulare, Depanare, Oprire, Build, Android SDK, AVD, etc…);
2. Bara de navigare (Navigation bar): Aduce o vizualizare mai compactă a
casetei ce conține fișierele proiectului și ajută la o navigare mai ușoară între
fișiere, pentru editarea acestora;
3. Editorul de text (Editor window): În această fereastră se întâmplă magia.
Aici introducem sau modificăm codul, indiferent de tipul fișierulu i. Acesta

Tehnologii folosite
19 se adaptează tipului de fișier care este deschis, de exemplu: dacă avem
deschis un fișier layout de tip .xml, editorul va deveni LayoutEditor.
4. Bara de instrumente (Tool window bar): Această bară se situează în
afara IDE -ului, înconjurând -ul, și d eține butoane care extind și comasează
instrumente individuale .
5. Fereastra de instrumente (Tool window): Ne permite accesul la task -uri
specifice, cum ar fi: project management, search, console, terminal, android
monitor, etc…
6. Bara de stare (Status bar): Aici se afișează starea curentă a proietului
împreună cu mesajele de eroare, avertismentele, durata execuției, etc.. .

3.2 Android SDK
3.2.1 Generalități
Android SDK (Software Development Kit) este o colecție de tool -uri ce servesc
programatorilor la dezvoltarea de aplicații, care folosește cele mai recente caracteristici
lansate de pe platforma Android. La fiecare versiune de software Android lansată pe
piață, Google atașează și o versiune a SDK -ului corespunzătoare acesteia.
Acest kit de dezvoltare c uprinde o varietate de instrumente necesare dezvoltării
aplicațiilor pentru această platformă, unele dintre cele mai importante fiind Managerul
Android SDK, Managerul AVD și un emulator al acestora.

3.2.2 Android SDK Manager

Figura 3.4 Managerul Android SDK;

Tehnologii folosite
20 Managerul Android SDK este componentă care conține toate elementele necesare
dezvoltării Android, iar acestea sunt organizate în pachete gata de instalare.
După cum se observă și în figura 3.4, sub fiecare versiune de Android există un set
de instrumente corespunzătoare acelei versiuni, care este necesar să fie instalat pentu a
putea realiza o aplicație compatibilă cu acea versiune. Pe lângă API -uri și servicii, se
regăsesc și o serie de instrumente care sunt necesare AVD -urilor, ce vor fi detaliate mai
jos.

3.2.3 Managerul AVD

Figura 3.5 AVD Manager;

După cum precizăm și mai deveme, Managerul AVD este furnizat tot de către
Android SDK, iar scop ul acestuia este de a gestiona l ucrul cu dispozitivele virtuale. Un
dispozitiv virtual poate fi creat cu o serie d e caracteristici persona lizate de user, care
imită caracteristicile u nui dispozitiv real, cum ar fi: memoria RAM, procesorul,
dimensiunile ecranului, func ționalităț i fizice (camera, accelerometru, aspect, etc…).
Rostul emulatorului este de a simula acest dispozitiv creat de programator, pentru a
testa aplicațiile direct pe el, fără a fi nevoie de un dispozitiv extern conectat.
În figura 3.4 se poate observă la fiecare versiune de SDK, o serie de procesoare ce
pot fi descărcate și instalate. Aceste proceso are sunt necesare în simularea cu succes a
unui AVD, iar unele dintre aceștia pot fi accelerate cu ajutorul unor software -uri
specifice.
Totuși, una dintre cele mai importante unelte în dezvoltare este chiar Androidul în
sine, deoarece elimină necesitatea AVD -ului și permite crearea de aplicații, gestionarea
proiectelor și actualizarea SDK -ului, direct pe dispozitivul real.

Tehnologii folosite
21
3.2.4 Instrumente de depanare (Debugger)
Un alt instrument important din cadrul SDK -ului este ADB -ul (Android Debug
Bridge), acesta fiind re sponsabil cu depanarea aplicațiilor Android. ADB -ul permite
testarea atât pe emulator cât și pe un dispozitiv fizic. În scenariul în care dispozitivul
devine „bricked”, adică dispozitivul este blocat sau nu mai pornește, ADB -ul se ocupă cu
restaurarea, rep ornirea acestuia, chiar și instalarea, dezinstalarea de aplicații sau
crearea de back -up-uri.
ADB -ul este constituit din 3 părți, anume [9]:
 Serverul: procesul care execută în fundal;
 Clientul: capătul „bridge -ului” ce rulează pe PC, Laptop, Mac, etc…;
 Daemon: capătul „bridge -ului” ce rulează pe dispozitivul sau emulatorul
supus testării.
În cazul în care testarea se face pe un dispozitiv fizic, acesta trebuie să aibă
modulul de debugging prin USB activat.

3.3 Firebase
3.3.1 Generalități
Pentru a putea inte gra inregis trarea și autentificarea unui utilizator în aplicația
realizată, am avut nevoie de o bază de date pentru a stoca credențialele și pentru a le
accesa. Am ales Firebase, deoarece este o platformă care permite aceste lucruri și multe
altele, dar es te și integrată cu Android studio.
Firebase are utilitate pentru pratformele de dezvoltare mobile și web, înființată în
anul 2011 de către Andrew Lee și James Tamplin. Compania a fost cumpărată de Google
în anul 2014, singura utilitate a acestei platforme fiind o bază de date sincronă pentru un
număr vast de clienți. În anul 2016 lista funcționalităților acestei platforme se lungește,
astăzi putând beneficia de următoarele servicii:
 Firebase Auth ;
 Firebase Cloud Messaging;
 Realtime Database;
 Firebase Hostin g;
 Firebase Storage;
 Firebase test lab for Android;
 Firebase Crash Reporting;
Firebase integrează multe limbaje de programare cu platforma lor, de exemplu:
iOS, Android, JavaScript, Node, etc… Platforma reprezintă un serviciu back -end pentru
aplicațiile ce implementează una sau mai multe funcții dintre cele enumerate mai sus.

Tehnologii folosite
22 3.3.2 Implementarea
Înaintea începerii prorpriu -zise a implementării, ca prim pas trebuie să
înregistrăm proiectul care se dorește să implementeze servicii oferite de Firebase, pe
serveru l acestora.
Înregistrarea proiectului este relativ simplă, tot ce trebuie făcut este alegerea
platformei de lucru, Android, iOS, sau web, după care se înregistrează pachetul din care
face parte aplicația, acesta regăsindu -se în fișierul androidmanifest.xm l, descris anterior.
O caracteristică opțională, totuși recomandată, ar fi atașarea unei chei SHA -1, unică
fiecărui proiect, care restricționează accesul serviciilor doar pentru acel proiect.
Obținerea acestei chei va fi prezentată în cadrul înregistrării proiectului cu Google Maps
API.
După obținerea cheii SHA -1 și înregistrarea cu succes a proiectului în cadrul
Firebase, mai sunt câțiva pași de urmat pentru a putea începe lucrul cu serviciile
acestora.
Serviciul folosit în acest proeict este Firebase Auth , însă acesta, ca oricare altul,
trebuie activat și integrat în proiect. Activarea se face în consola Firebase, accesată
direct din browser, iar integrarea în proie ct se face cu ajutorul sistemului gradle, pe care
l-am descris anterior.

Figura 3.6 Dependențele Firebase;

Ca ultim pas mai trebuie adăugate și librăriile folosite în proiect. Am adăugat mai
multe dintre acestea pentru o dezvoltare ulterioară a aplicației.

Figura 3.7 Integrarea librăriilor Firebase în proiect;

Tehnologii folosite
23 3.4 Google Maps API V 2
3.4.1 Generalități
API-ul (Application Programming Interface) este un set de proceduri și
instrumente care permit crearea aplicațiilor ce accesează date de la o altă aplicație sau
serviciu. În consola Google se regăsesc mai multeAPI -uri cu diferite funcț ii cum ar fi:
hărți, traducere, mail, etc… Pachetul acestor servicii se numește Google play services,
acesta fiind responsabil pentru comunicarea aplicațiilor cu serviciile Google.
În ace st proiect se utilizează API -ul ce se ocupă cu gestionarea hărților . Voi detalia
subiectul cu Google Maps API în câteva momente, dar mai întâi vreau să menționez
faptul că acest API implementează hărțile prin GPS.

3.4.2 GPS (Global Positioning System)
Cu ceva timp în urmă, GPS -ul era considerat o tehnologie rară. În prezent,
majoritatea dispozitivelor mobile implementează această tehnologie.
GPS -ul reprezintă o rețea de sateliți care orbitează în jurul planetei și trimit detalii
specifice privind poziț ia lor, înapoi pe pământ. Semnalele sunt traduse de receptorii GPS,
cum ar fi dispozitivele ce calculează poziția, viteza și timpul unei mașini într -o locație.
Înainte ca semnalul să fie obținut de aceste dispozitive receptoare, pentru o acuratețe
mai mare , semnalul este captat de cele mai apropiate 3 releuri de poziția dorită, prin
triangulație.
Sistemul GPS a fost dezvoltat în anii 1960 de către americani, pentru o navigare
mai ușoară a unităților navale pe oceane. Din anii 1980, acest serviciu a fost dat liber și
gratuit înspre utilizare, oricui avea un receptor GPS.
Sistemul GPS este format din 3 parți numite segmente [10] :
1) Segmentul spațial : este alcătuit din rețeaua de 31 de sateliți din orbită
(februarie 2016) , care transmit semnale modulare. Fiecare d intre aceștia
emit câte două unde radio, una receptată de sistemul militar și una de
sistemul civil;
2) Segmentul de control : se află pe pământ și este alcătuit din stații de
recepție cu rolul de a intercepta toate mesajele de la toți sateliții și de a
calcula poziția fiecăruia, retransmițând -o înapoi la sateliți;
3) Segmentul de utilizator : reprezintă mulț imea utilizatorilor care folosesc
un receptor GPS, indif erent dacă este militar sau civil.
Am tot amin tit de acești receptor i GPS, însă nu am dat nicio d efiniție pentru ei,
așadar, un receptor GPS este un aparat capabil de a percepe semnalele emise de sateliți
prin care poate determina poziția sa pe P ământ, sub formă de coordonate, care sunt
reprezentate în sistemul geodezic mondial WGS84. Locația este exp rimată în plan 2D
prin latitudine și longitudine.

Tehnologii folosite
24 Majoritatea dispozitivelor mobile au preinsatalata o aplicație ce implementează un
software pentru navigație. Cel mai popul ar printre acestea este Google M aps, iar acesta
va fii folosit și în acest proiect.

3.4.3 Implementarea și consola Google pentru dezvoltatori
Înainte de a putea folosi API -ul oferit de Google în proiectul nostru, acesta va trebui
înregistrat cum că implementează servicii oferite de Google. Procesul este absolut
gratuit, însă absolut necesar p entru ca astfel de aplicații să funcționeze.
Acest lucru poate fi realizat în consola pentru dezvoltatori Google, ce se accesează
direct din browser și arată în felul următor:

Figura 3.8 Consola pentru dezvoltatori Google 1;

După cum spuneam, în aceast ă consolă vom crea un proiect nou cu numele
aplicației (punctul 1 din figura 3.8), iar după ce crearea a fost finalizată cu succes, se vor
activă API -urile care dorim să le utilizăm în proiect (punctul 2 din figura 3.8).
La apăsarea butonului „Enable API’s and services” , consola va trece în tab -ul
Library, unde se pot vizualiza toate API -urile și servcile care pot fi incluse în proiectul
dvs. În acest proiect singurul API de care vom avea nevoie este Google Maps Android API
v2.

Tehnologii folosite
25

Figura 3.9 Consola pentru dezvoltatori Google 2;

După selectarea API -ului dorit și activarea acestuia, Google va oferi o cheie unică
(API key), care trebuie introdusă în fișierul androidmanifest.xml al proiectului, pentru a
putea beneficia de acest API.

Figura 3.10 Introducerea cheii în proiect;

Pentru siguranță și securitate în aplicația dvs., această cheie trebuie restricționată
pentru proiectul în care doriți să o utilizați, iar restricționarea acesteia se face prin
atașarea unor credențiale în consola.

Figura 3.11 Consola pentru dezvoltatori Google 3;

Tehnologii folosite
26 Datele necesare pentru restricționare sunt: numele pachetului din care face parte
aplicația și amprenta digitală SHA -1. Numele pachetului se găsește în fișierul
androidmanifest.xml din cadrul aplicației, iar ampre nta SHA -1 se obține prin aplicarea
unei comenzi asupra a două fișiere, anume „keytool -ul” din cadrul JDK -ului (Java
Developement Kit) și „keystore -ul” din cadrul Android SDK -ului.
Odată ce cheia API -ului a fost introdusă în proiect, tot ce rămâne de făcut este
obținerea hărții prin cod. Pentru a folosi harta în cadrul unei aplicații android se poate
folosi un MapFragment sau MapView. Acestea reprezintă două tipuri de layout -uri din
cadrul fișierelor .xml, harta fiind descărcată automat pe bucăți și vizualiz ată in acestea.
În acest proiect este utilizat MapFragment.
MapFragment -ul acționează că un suport pentru harta, această putând fii mutată,
mărită, micșorată, înclinată, etc…
Google Maps oferă 5 tipuri de harți:
 Normal – conține elemente din natură și dr umuri;
 Hibrid – conține imagini din satelit și drumuri;
 Satelit – conține doar imagini din satelit;
 Teren – conțin date topografice;
 Niciuna – conține doar grile goale.

Figura 3.12 Tipuri de hărți;
Informații suplimentare despre vederile și implementare a hărții se vor găsi în
secțiunea de implementare a aplicației.

Analiză, Proiectare și Implementare
27 4. Analiză, Proiectare și Implementare
4.1 Analiza
În ceea ce privește construirea și dezvoltarea aplicației, am analizat mai multe
programe disponibile în momentul prezent. Având în vedere că dezvoltarea pe Android
are o amploare foarte mare la ora actuală și că pentru dezvolatrea pe iOS este necesară
detin erea unui dispozitiv ce rulează macOS sau o mașină virtuală cu acest sistem de
operare, m -am decis să implementez această aplicație pe Andro id.
Ca medii de dezvoltare ale aplicației am luat în considerare Xamarin împreună cu
Visual Studio și Android Studio. Limbajul de programare nativ pentru Android este Java,
iar aplicațiile implementate cu Xamarin, spre deosebire de cele implementate cu
Android Studio, folosesc C# ca limbaj de programare. La început, am considerat Xamarin
pentru a realiza implementarea, deoarece personal, mereu am fost mai atras de C# decât
de Java, însă după realizarea unei variante inițiale a aplicației în Xamarin, neavân d o
experiență vastă în realizarea aplicații lor mobile, iar sursa principală de informații fiind
internetul, m -am regăsit în postura în care informațiile în concordanță cu Java erau mai
accesibile decât cele cu C#. Așadar, într -un final am ales ca mediu de dezvoltare Android
Studio.
La ora actuală, pe piață există diferite tipuri de aplicații ce măsoară suprafețe de
teren prin coordonate GPS, însă marea majoritate sunt cu caracter profesional ce
necesită anumite cunoștințe pentru a fi utilizate, sau sunt in accesibile multora dintre
utilizatori.
Luând în considerare faptul că în prezent tot mai multă lume folosește
smartphone -uri, scopul principal al acestui proiect a fost de a oferi o interfață intuitivă și
cât mai ușor de folosit, indiferent de utilizator. De asemenea, s -a încercat pe cât se poate
că aplicația să fie bine structurată pentru a fi ușor de îmbunătăți și actualizat.

4.2 Proiectarea
Pentru etapa de proiectare am pregătit două tipuri de diagrame, anume diagrama
claselor UML și diagrama cazurilor de utilizare. Datorită structurii acestor diagrame se
pot înțelege cu ușurință principiile de funcționare și structura aplicației.

4.2.1 Diagrama claselor ( UML )
In aceasta diagram a se pot observa activitățile aplicației, î mpreuna cu legăturile
de asociere și î mplementarea interfețelor necesare realiză rii acesteia.
Cu portocaliu sunt prezentate clasel e activităților, împărțite în 3 secț iuni:
 În prima secțiune se observă numele clasei;

Analiză, Proiectare și Implementare
28  În a doua secțiune avem atributele împreună cu tipul acestora;
 În a treia se cțiune sunt metodele (operaț iile) din cadrul clasei cu tot cu
specificatorii tipului de date returnat.
Cu alb sunt afișate interfețele implementate de clasa MapActivity. Acestea au tot
aceeași structură de 3 secțiuni, însă deoarece interfețele sunt abstrac te, în clasa care le
implementează trebuie suprascrise metodele și atributele c e dorim să le utilizăm, așa că
le-am adugat doar pe cele folosite.

Figura 4.1 Diagrama claselor UML;

Analiză, Proi ectare și Implementare
29 4.2.2 Diagrama cazurilor de utilizare (UML)
Prin această diagramă s -a încercat acoperirea cât mai bună a cazurilor în care se
poate află utilizatorul în interacțiunea sa cu aplicația. Această are scopul de a observa și
analiza acțiunile utilizatorului asupra aplicației și ce cazuri pot apărea în dif erite
instanțe ale sale.

Figura 4.2 Diagrama cazurilor de utilizare;

Structura acestei diagrame este formată din:
 Actori: în cazul de față este utilizatorul;
 Sistem: acesta este fundalul gri ce conține toate elementele, reprezentând
de fapt toată aplic ația;
 Cazuri: ovalele verzi reprezintă cazurile de utilizare ale aplicației;
 Relații: săgețile dintre elementele diagramei reprezintă tipul relației dintre
acestea.

Analiză, Proiectare și Implementare
30 4.3 Implementarea
4.3.1 Mediul de dezvoltare
Generalități despre mediul de dezvoltare folosit au fost prezentate anterior în
această lucrare, așa că aici voi aminti pe scrut. IDE -ul folosit este Android Studio și
reprezintă 90% din implementare, iar pentru înregistrarea și autentificarea
utilizatoril or am folosit Firebase.
Uneltele necesare pentru implementarea unui proiect Android:
1) JDK (Java Development Kit) – de preferat ultima versiune stabilă;
2) IDE (Integrated Development Environment) – Android Studio în acest caz;
3) SDK (Android SDK) – pentru API -urile necesare dezvoltării;
4) AVD (Android Virtual Device) sau un dispozitiv fizic – pentru testare;

4.3.2 Crearea și configurarea unei aplicații
Asumând faptul că uneltele precizate mai sus sunt instalate, pentru crearea unei
aplicații se deschide Android S tudio ș i se selectează opțiunea Start a new Android Studio
project.

Figura 4.3 Crearea unui proiect nou;

Dup ă finalizarea acestui pas , fereastra următoare va reprezenta începutul
configură rii proiectului dvs .

Analiză, Proiectare și Implementare
31

Figura 4.4 Configurarea unei aplica ții 1;

În aceast ă fereastră va fii necesar să introduceți numele aplicației, domeniul, iar
din acestea se va forma numele pachetului corespunzător . În josul ferestrei se poate
selecta și locația unde doriți să salvați proiectul.

Figura 4.5 Configurarea unei aplica ții 2;

Analiză, Proiectare și Implementare
32 În fereastra din figura 4.5 se va configura platforma pe care se dorește
dezvoltarea aplicației și cel mai mic API Android pe care aceasta poate rula. Cu cât API -ul
selectat este mai mic, cu atât raza de acoperire a dispozitivelor este mai mare, da r în
același timp și func ționalităț ile ce pot fi implementate sunt în număr redus, deoarece un
nivel mai scăzut al API -ului conține mai puține caracteristici țintind și dispozitive mai
vechi care sunt depreciate. Cu cât API -ul selectat este mai mare, perfo rmanța și
caracteristicile acestuia sunt ridicate, însă numărul de dispozitive care pot rula aplicația
este limitat.
În cazul de față s -a ales API 21: Android 5.0 (Lollipop), deoarece are o vechime de
3 ani, acesta fiind lansat la sfârșitul anului 2014, și o acoperirie de 71.3% din piața
dispozitivelor ce sunt active în Google Play Store. Totodată am ales acest nivel de API
deoarce dispozitivul pe care am realizat testarea rulează versiunea Android 5.1.1
(Lollipop).
Telefoanele și tabletele fiind cele ma i răspândite dintre dispozitivele cu Android,
această platformă a fost și target -ul ales în proiect.

Figura 4.6 Configurarea unei aplica ții 3;

Deoarece orice aplicație A ndroid conține c el puțin o activitate, Android S tudio ne
oferă opțiunea de a adăug a una direct din faza de configurare. Activitatea selectat ă va
deveni cea principală până la intervenția programatorului în acest aspect.
În figura 4.6 se observă un set de șabloane pentru activități, acestea fiind
ajutătoare programatorului, fiecare avân d un caracter specific, util în functe de tipul
aplicației dorite.

Analiză, Proiectare și Implementare
33 În cazul în care se alege crearea unei activități după unnul dintre șabloane,
automat se va genera și un fișier .xml corespunzător acestuia. Dacă se sele ctează o
activitate necompletată (Empty Activity), în fereastră următoare există posibilitatea de a
atașa și un fișier .xml necompletat, după dorința programatorului.

Figura 4.7 Configurarea unei aplica ții 4;

Figura 4.7 reprezintă ultimul pas în configurarea aplicației. Tot ce rămâne de
făcut este selectarea numelui activității și a fișierului .xml. Orice activitate creată
moștenește clasa Activity, dar la selectarea opțiunii Backwards Compatibility, activitatea
va moșteni clasa AppCompatActivity, această la rândul ei fiind extinsă tot de clasa
Activity, dar aduce câteva noțiuni de estetică, cum ar fi corelarea între tema aplicației și
bară de activități.
La câteva momente după apăsarea butonului Finish, Android Studio va intra în
forma prezentată în figura 3.3, de unde puteți începe i mplementarea ulterioară a
aplicației.

4.3.3 Configurarea dispozitivului sau emulatorului
4.3.3.1 Configurarea dispozitivului mobil
Pentru încărcarea și rularea cu success a unei aplicații pe un dispozitiv mobil,
acesta trebuie să aibă modulele de dezvoltare și debugging active. În general,
majoritatea dispozitivelor mobile vor deschide automat fereastră din figura 4.8 în
momentul co nectării acestuia la un PC sau L aptop. Dacă fereastra nu apare a utomat,
aceasta se poate găsi în setările dispozitivului.

Analiză, Proiectare și Implementare
34

Figura 4.8 Configurarea dispozitivului mobil;

4.3.3.2 Configurarea emulatorului
Pentru a putea încarcă aplicația pe un emulator, în primul rând trebuie să se creeze
unul. Ace st lucru se realizează din AV D M anager, făcând click pe buton Create New
Virtual Device. Puteți vizualiza interfață grafică a managerului AVD în figura 3.5. După ce
s-a făcut click pe butonul de Create New Virtual Device, se va deschide fereastră din
figura 4.9.

Figura 4.9 Crearea u nui dispozitiv virtual ;

Analiză, Proiectare și Implementare
35 După selectarea modelului de dispozitiv, următoarea setare pe care va trebui să o
facem este selectarea versiunii API -ului care să fie instalat pe emulator. Managerul AVD
va descarcă versiunea dorită și o va instala automat pe dispo zitivul virtual, acesta
funcționând la fel că un dispozitiv fizic, însă spre deosebire de cel fizic, emulatorul nu își
poate adapta API -ul la o versiune mai nouă, iar pentru acest lucru va trebui creat unul
nou.

Figura 4.10 Configurarea emulatorului;

Ultima parte din configurarea emulatorului ține de denumirea și dimensionarea
dispozitivului, dar și adăugarea unor caracteristice fizice cum ar fi: camera foto,
performanțe grafice, performanțe hardware referitoare tipul de procesor și memoria
Cache a ace stuia, sau memoria RAM.
După configurarea cu succes a dispozitivelor și a IDE -ului, totul este pregătit
pentru dezvoltarea completă a unei aplicații Android.

4.3.4 Implementarea aplica ției
Acest proiect este format din 4 activități care comunică intre ele, anume:
 Login Activity;
 Register Activity;
 Map Activity;
 Help Activity;
Fiecare are o funcție bine definită care va fi prezentată mai ulerior.

Analiză, P roiectare și Implementare
36 4.3.4.1 Login Activity

Figura 4.11 Activitatea de logare a utilizatorului;

Am început cu această activitate, deoare es te activitatea principala a aplicației,
adică este prima cu care interacționează utilizatorul după pornirea aplicației.
După cum se poate observă în figura 4.11, elementele regăsite în această activitate
sunt: două câmpuri EditText , un TextView și două Butoane . În spatele acestora este și o
imagine de fundal personalizată pentru a fi în tema cu aplic ația, dar totodată fără a
reduce vizibilitatea elementelor de interacțiune. Câmpurile EditText au, în mod implicit,
sugestii cu ce trebuie introdus, iar butoan ele au numele acțiunii care este implementată
fiecăruia.
Această activitate este conectată cu alte două ac tivități, anume activitatea de
înregstrare a utilizatorului (figura 4.12) și activitatea cu harta (figura 4.13). Navigarea
între aceste activități se face prin apăsarea butoanelor, fiecare fiind legat la o altă
interfață.
În cazul în care datele introdus e în câmpurile E -mail și Password se află
înregistrate în Firebase, la apăsarea butonului LOGIN, aplicația va trece în activitatea
hărții, iar aceasta v a fi distrusă. În cazul în care datele nu sunt înregistrate, utilizatorul
trebuie să treacă la interfață de înregistrare, prin apăsarea butonului REGISTER, unde își
va putea înregistra un con t cu care se poate loga.

Analiză, Proiectare și Implementare
37 4.3.4.2 Register Activity

Figura 4.12 Activitatea de înregistrare a utilizatorului;

După apăsarea butonului REGISTER din activitatea de logare, fereastra din figura
4.12 va fii deschisă. În această activitate se regăsesc următoarele elemente: 4 câmpuri
EditText , un RadioGroup cu două RadioBut tons și încă două Butoane.
La ap ăsarea butonului REGISTER, cont ul utilizatorului va fii salvat în Firebase, însă
ca acest lucru să fie realizat cu succes, toate câmpurile trebuie comple tate cu date valide
și corespunză toare cerinței fiecăruia.
 User Name – numele utilizatorului ; poate conț ine cifre, litere și caractere
speciale;
 Password – parola stabilită de utilizator; poate co nține doar cifre și litere și
trebuie să fie mini m 6 caractere pentru a fi validă ;
 Re-enter password – trebuie să aibă exact acelaș i conținut ca și câ mpul
password;
 E-mail – se introduce o adresă de email de forma standard user@gmail.com ;
 Gender – se selectea ză una dintre cele dou ă opț iuni.
În colțul din stânga sus este un buton sub formă de săgeata. În cazul înregistrării cu
succes a contului de utilizator, acest buton va trece direct la activitatea hărții. În cazul în
care utilizatorul nu s -a înregistrat cu succes, acest buton va trece înapoi la activitatea de
logare.

Analiză, Proiectare și Implementare
38 4.3.4.3 Map Activity

Figur a 4.13 Activitatea hărții;

La autentificarea cu succes a unui utilizator înregistrat în Firebase, se va deschide
fereastra din figura 4.13. Aceasta va fi fereastra cu cea mai mare interacțiune, așa că voi
detalia puțin implementarea acestiea și a elemente lor corespunzătoare.
În secțiunea 3.4.3 am explicat faptul că harta trebuie conținută de un layout de tip
fragment. În figura 4.13 se poate observa re zultatul acelui fragment ce conț ine harta.
Primu pas fiind realizat, rămân de implementat funcționalități ale hărții.
În primul rând, elementele regăsite în această interfață sunt doar două Butoane și
un Spinner , restul funcționalităț ilor fiind implementate prin gesturi.
Butonul negru din colțul dreapta jos este butonul de deconectare a utilizatorului.
La apăsarea acestu buton aplicația va reveni la activitatea de logare. Butonul din colțul
stânga jos va face aplicația să treacă din activitatea curentă în activitatea de ajutor,
pentru informații suplimentare asupra utilizării funcțiilor. Voi detalia această activ itate
în secțiunea următoare.
Spinner -ul din colțul dreapta sus oferă posibilitatea de a selecta între tipurile de
hărți oferite de Google, care au fost prezentate în figura 3.12. Selectarea tipului de harta
poate conta în funcție de ce fel de supraf ață se dorește a fi măsurată.
In continuare vor fi prezentate op eratiile prin care se realizează calculul suprafeț ei.

Analiză, Proiectare și Implementare
39 1) Adăugarea unui marcator pe hartă ;

public void onMapClick (final LatLng latLng) {

if (isClicked == false) {

mMap.addMarker( new MarkerOptions()
.draggable( true)
.position(latLng)
.icon(BitmapDescriptorFactory. defaultMarker (
BitmapDescriptorFactory. HUE_CYAN ))
.title(String. format("%.3f", latLng.latitude ) + "," +
String. format("%.3f", latLng.longitude )));
arrayList .add(latLng) ;
}

Activitatea h ărții implementeaz interfata OnMapClickListener, si prin
suprascrierea metodei din acceast interfata, putem adauga markerii la locatia atingerii
ecranului.
Obiect ul Map reprezintă harta pe care o vizualizam în fragment, iar addMarker este
una dintre operațiile ce pot fi efectuate pe hartă. Această operație adaugă pe hartă un
marker de tipul MarkerOptions , care are un set de caracteristici pentru fieare marker în
parte. Cea mai importantă caracteristică, care este și necesară, este position . Prin această
caracteristică se specifică locația la care se amplasează marker -ul pe hartă. În cazul de
față, această poziție este obținută de la atributul metodei onMapClick , cee a ce ne permite
să amplasăm marker -ul la poziția atingerii hărții. Celelalte atribute sunt pentru
perso nalizarea acestora, de exemplu: icon poate schi mba formă sau culoarea
marcatorilor, title adaugă un titlu , vizibil la apăsarea pe marker, draggable activează
opțiunea ca marcatorii să poată fi mutați, s.a.m.d.
Linia de cod „arrayList.add(latLng)” va salva poziția fiecărui marcator plasat pe
hară într-un tablou bidimensional ce conține date de tip LatLng, adică coordonate. Acest
tablou va fi folosit p entru a forma poligonul format din punctele amplasate de utilizator.

2) Formarea poligonului;

public void polygonPoints () {

if (arrayList .size() >= 3) {
isClicked = true;
polygon = mMap.addPolygon( new PolygonOptions()
.clickable( true)
.addAll( arrayList )
.strokeColor(Color. CYAN)
.strokeWidth( 3)
.fillColor(Color. argb(127, 255, 0, 0)));

}
}

Analiză, Proiectare și Implementare
40 În metoda „polygonOptions() ” se creează practic poligonul. Prima condiție pentru a
putea face acest lucru este să înțelegem ce înseamnă un poligon. Un poligon reprezintă o
formă neregulă închisă, formată din 3 sau mai multe puncte, deoarece două puncte sunt
întotdeauna coloniare și n u se poate forma o suprafață închisă doar din acestea. Așadar
am pus condiția ca mulțimea punctelor salvate în arrayList să fie mai mare sau egală cu
3. În momentul în care această condiție este îndeplinită putem forma un poligon cu acele
puncte, prin oper ația addPolygon .
Caracteristica principală a acestuia este adăugarea punctelor, cu metoda
addAll(arrayList) . În momentul acesta poligonul este format, restul metodelor fiind
pentru personalizare. Am activat opțiunea ca poligonul să fie clickable , deoarece la
efectuarea unui click pe acesta, se va obține aria suprafeței formate de poligon, într -un
mesaj Toast .

3) Calculul suprafeței;

Codul pentru calculul suprafeței este conținut de o metodă numită
„computeArea()”, din pacetul SphericalUtil . Metodă a fost in vocată în cadrul listener -ului
la efectuarea unui click pe poligon, și transmite un mesaj de tip Toast cu aria poligonului
calculată în metrii pătrați.
Codul metodei „computeArea()” este relativ vast pentru a fi introdus în această
documentație, însă îl pu teți vedea în proiectul atașat.

4) Curățarea hărții.

public void onMapLongClick (LatLng latLng) {

mMap.clear() ;
arrayList .clear() ;
isClicked = false;
}

După ce suprafața dorită a fost formată și măsurată, la apăsarea lungă a ecranului,
înafara poligonului, toate elementele adăugate vor fi curățate pentru a putea efectua altă
măsurare.
Cu „mMap.clear()” se va curăța harta de elementele adăugate, iar cu
„arrayList .clear() ” se vor șterge coordonatele salvate. După ce ștergerea a fost efectuată,
poligonul revine în starea inițială.

Analiză, Proiectare și Implementare
41 4.3.4.4 Help Activity

Figura 4.14 Activitatea cu informații despre utilizare;

Deoarece majoritatea funcționalităț ilor sunt realizate cu gesturi, un utilizator nu
are de unde să știe toate uneltele și operațiile aplicației. Așadar am implementat o
activitate ce arată, clar și pe scurt, care sunt utilitățile aplicației.
Activitatea este compusă dintr -un TextView și un Buton. În interiorul TextView –
ului este încărcat un fișier de tip text, care se află în folderul cu asset -urile aplicației.
Fișierul text conține un scurt manual de instrucțiuni în limba engleză. Butonul din colțul
dreapta jos, sub formă de săgeata de cul oarea albastră, are rolul de a trece aplicația
înapoi la activitatea hărții, odată ce utilizatorul a terminat de citit informațiile. Această
activitate se poate accesa oricând în timpul funcționarii, dar va întrerupe procesele ce
rulează în activitatea hăr ții.

Testare și Validare
42 5. Testare și Validare
După finalizarea aplicației, pasul următor este testarea acesteia, deoarece trebuie
să ne asigurăm că nu apar eventuale probleme cu interfață sau funcționa litatea, dar și că
aceasta se ridică la așteptările menționate. Câteva dintre aspectele testate vor fi
prezentate mai jos, iar cele mai importante dintre acestea vor fi evidențiate printr -o
serie de imagini drept dovezi.
 Crearea unui cont de utilizator;
 Login/ Logout;
 Interfață;
 Menținerea a utentificării;
 Validarea campurilor de text;
 Corectitudine și coerență în text;
 Compatibilitatea cu diferite dispozitive;
 Integrarea cu Google Maps;
 Corectitudinea coordonatelor;
 Corectitudinea măsurării;
 Performanța aplicației.

Testarea a fost realizată de mine, dar și de alți colegi, prieteni sau membri ai
familie, scopul fiind de a observa aplicația utilizată de mai multe tipuri de utilizatori, cu
mai multe sau mai puține cunoștințe legate de acest domeniu.
În continuare se vor observa câteva din test ele realizate pe interfețele de logare,
înregistrare și corectitudine a măsurării.

Figura 5.1 Testare interfață de logare;

Testare și Validare
43 Pentru interfața de logare am testat atât adrese de email sub formă greșită cât și
modele corecte, dar neînregistrate în Firebase. Până la introducerea unui cont de
utilizator valid, aplicația va afișa mesajul din figura 5.1. Mai există și cazul în care nu se
introduce nimic, unde aplicația va afișa un Toast cu mesajul „Please enter a registered
account” .

Figura 5.2 Testare interfață de înregistrare;

În interfața de înregistrare pot apărea tot felul de erori în funcție de fieare câmp,
acestea având me saje de notificare independente. În secțiunea 4.3.4.2 am menționat ce
fel de date trebuie să conțină fiecare câmp pentru a putea înregistra cu succes un
utilizator.
La introducerea corectă a tuturor câmpurilor, utiliza torul va primi un mesaj de
notificare cum că a fost înregistrat cu s ucces, iar acesta se poate loga cu contul proaspăt
creat.
Dintre aceste câmpuri, cele care contează sunt email și password, deoarece aceste
date vor fii folosite pentru autentificare. Cele late câmpuri sunt obligatorii de introdus
pentru a crea cu succes un cont, deoarece ele vor fii folositoare la consituirea unui profil
de utilizator într -o bază de date, pe viitor.

Testare și Validare
44
Figura 5.3 Suprafața caminului 7 Observator;

Figura 5.4 Suprafața terenului Cluj Arena;

Pentru a verifica corectitudinea măsurătorii, am ales o suprafață de teren
cunoscută, aceea fiind terenul de fotbal din Cluj Arena (figura 5.4). Conform unui articol
realizat în anul 2011 [11], terenul are 105m lungime și 68m lățime, însemnând 7140m2.
Doarece măsurătoarea din aplicație se fa ce cu click -ul ci nu prin coordo nate exacte, are o
eroare relative mică. Tehnic vorbind, nu putem pune marcatorul pe hartă exact în același
punct în care putem pune ruleta pe iarbă. Așadar chiar da că nu am reușit să fixăm
punctele exact în colțurile terenului, suprafață selectată tot este correct calculată.

Concluzii
45 6. Concluzii
6.1 Rezultate
Implementarea aplicației prezentată în acest document, ce poartă numele EriaGon,
a reprezentat o provocare personală și un drum spre cunoștințe noi. Înainte să mă apuc
de acest pro iect, singurele cunoștințe legate de mobile development pe care le dețineam,
erau acumulate în cadrul laboratorului de „Transmisia datelor”, din cadrul facultății. În
momentul în care am ales această tema , primul scop ce l -am avut în minte a fost să învăț
dezvoltare de aplicații pe dispozitive mobile.
Am considerat această tema d e aplicație o experiență benefică în dezvoltarea
personală și profesională, deoarece, în prezent, există o varietate de locuri de muncă pe
piață, în care informațiile acumulate pe parcursul acestui proiect sunt valoroase.
Pentru partea de implementare am avut de studiat destul de multe documente de
natură diferită: cărți de specialitate, site -uri academice, tutoriale online, etc… Indiferent
ce specializare aveau informațiile, OOP, Android, Firebase sau Google Maps, acestea au
fost necesare pentru a obțin e produsul final în întregime și mi le -am însușit cu drag.
Bineînțeles, am întâmpinat și momente în care nu credeam că voi putea implementa
aplicația cu succes în întregime , însă răspunsul era la o pagină distanță sau cu un
paragraf mai jos.
După cum am p recizat și la inceputlul lucrării, pe lângă viteză, în ziua de azi
contează foarte mult accesibilitatea la informație și portabilitatea acesteia. Așadar,
rezultatele obținute consider că au atins obiectivele setate la început, acestea fiind mai
multe decâ t cele cerute de tema în sine. Obiectivele au fost împărțite la rândul lor în
task -uri mai mici, pentru o structurare mai ușoară.
În cadrul unei corporații din domeniu, împărțirea sarcinilor este bine stabilită de la
începutul fiecărui proiect, însă în ace st proiect individual, analizarea, proiectarea,
structurarea și implementarea au fost realizate de o singură persoa nă. Consider că
aplicația poate fii îmbunătățită din foarte multe perspective de la design la
implementare de funcționalități noi, dar ce est e realizat în momentul de față constituie
un prototip reușit ce poate servi drept punct de start pentru o dezvoltare ulterioară.

6.2 Contribuții personale
Pe parcursul acetui document s -a prezentat procesul de realizare a unei aplicații
mobile pe Android, atât din punct de vedere al funcțiilor cât și ale design -ului. Tema
cerută de acest proiect a fost implementarea unei aplicații mobile ce poate măsură
suprafețe de teren prin coordonate GPS, practic tot ce se întâmplă în activitatea hărții. În
plus pe l ângă funcționalitatea principală , au fost aduse caracteristici ce vor fi folositoare
pentru o dezvoltare ulterioară, despre care voi discuta puțin mai jos.

Concluzii
46 Funcționalitățile implementate pe lângă tema inițială sunt:
 Crearea unei interfețe user -friendly care f acilitează utiliarea aplicației
pentru orice fel de utilizator;
 Posibilitatea de înregistrare a unui cont de utilizator;
 Posibilitatea de logare a utilizatorului;
 Un manual de instrucțiuni ce cuprinde tot ce este necesar în utilizarea
aplicației;
 Impl ement area neîncărcată a interfețelor, în așa fel încâ t să se distingă cu
ușurință elemntele componente.

6.3 Direcții de dezvoltare
După cum am precizat anter ior, această aplicație poate fii îmbunătățită în fel și
chip, starea actuală fiind o versiune incipientă a sa, ce poate sta la baza unor dezvoltări
ulterioare.
Utilizatorii vor de la o aplicație să fie cât mai complexă din punct de vedere al
setului de funcționalități, dar și cât mai compactă în același timp. Câteva dintre
funcționalitățile pe care vreau să le implementez pe viitor sunt prezentate mai jos:
 Facebook and Google Login – tot mai multe aplicații de orice fel au început
să abordeze această tehica de logare, deoarece majoritatea utilizatorilor au
un profil de Facebook sau Google și este mai rapid și ma i ușor să se
importeze setările de la aceste profile, cu un singur click, decât crearea
unuia nou;
 Map Search – opțiunea de a căuta locații pe hartă prin introducerea de
cuvinte cheie;
 Database points – posibilitatea de a salva punctele dorite de pe harta, într-o
bază de date;
 Database areas – posibilitatea de a salva măsurătorile efetuate într -o bază
de date, pentru comparare sau folosire ulterioară;
 Posibilitatea de a formă poligonul măsurat direct prin introducerea
coordonatelor;
 Posibilitatea de a formă mai multe poligoane în același timp;
 Reproiectarea aplicației pentru optimizare.

Bibliografie
47 7. Bibliografie

[1] https://www.theverge.com/2017/2/16/14634656/android -ios-
market -share -blackberry -2016
[2] https://en.wikipedia.org/wiki/Android_(operating_system)
[3] https://www.phon earena.com/news/Googles -Android -OS-Past –
Present -and-Future_id21273
[4] https://stackify.com/oops -concepts -in-java/
[5] https://www.javatpoint.com/java -oops -concepts
[6] http://pdsd2014.andreirosucojocaru.ro/wiki/laboratoare/laborator00
[7] http://www.itcsolutions.eu/2011/09/08/android -tutorial -concepte –
activitati -si-resurse -ale-unei -aplicatii -android/
[8] https://developer.android.com/studio/intro/index.html
[9] http://www.makeuseof.com/tag/new -adb-make -process -simple -easy/
[10] https://ro.wikipedia.org/ wiki/Global_Positioning_System
[11] http://ziuadecj.realitatea.net/sport/terenul -de-pe-cluj-arena -cel-mai-
mare -din-liga-i–75338.html
[12] https://stackoverflow.com/questions
[13] https://www.youtube.com/watch?v=QAbQgLGKd3Y&list=PL6gx4Cwl9
DGBsvRxJJOzG4r4k_zLKrn xl
[14] https://github.com/
[15] Mark Murphy , „Beginning Android 3 ”, APress, 2011
[16] http://studytipsandtricks.blogspot.ro/2012/04/features -of-object –
oriented -programming.html