APLICAȚIE DE DISPOZITIVE MOBILE (ANDROID) ÎN [623062]
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
DEPARTAMENTUL DE AUTOMATIC Ă
APLICAȚIE DE DISPOZITIVE MOBILE (ANDROID) ÎN
SCOPUL INFORMĂRII ASUPRA LOCALURILOR ȘI
OBIECTIVELOR TURISTICE DINTR -O LOCALITATE
PROIECT DE DIPLOM Ă
Autor : Cristian Adrian POP
Coordonator : Prof. dr. ing. Honoriu VĂLEAN
2016
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
DEPARTAMENTUL DE AUTOMATIC Ă
VIZAT,
DECAN, Director DEPARTAMENT ,
Prof. d r. ing. Liviu MICLEA Prof. dr. ing. Honoriu VĂLEAN
Autor Cristian Adrian POP
APLICAȚIE DE DISPOZITIVE MOBILE (ANDROID) ÎN SCOPUL INFORMĂRII
ASUPRA LOCALURILOR ȘI OBIECTIVELOR TURISTICE DINTR -O
LOCALITATE
1. Enunțul temei : Acest proiect își propune a fi o unealtă utilă pentru turiști, oferind
detalii importante despre localurile și obiectivele turistice dintr -o localitate .
2. Conținutul proiectului: Introducere, Obiective și specificații, Studiu bibliografic,
Analiză de proi ectare, Implementarea, Testare și validare, Concluzii, Bibliografie,
Acronime.
3. Locul documentației: Universitatea Tehnică din Cluj –Napoca
4. Consultanți:
5. Data emiterii temei: 04.11.2015
6. Data predării: 27.06.2016
Semnătura autorului ______________ _______
Semnătura coordonatorului _______________
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
DEPARTAMENTUL DE AUTOMATIC Ă
Declarația autorului,
Subsemnatul Cristian Adrian POP , student: [anonimizat], Universitatea Tehnică di n Cluj -Napoca, declar că ideile, analiza, proiectarea,
implementarea, rezul tatele și concluziile cuprinse în acest proiect de diplomă constituie
efortul meu propriu, mai puțin acele elemente ce nu îmi aparțin, pe care le indic și recunosc ca
atare.
Declar de asemenea că, după știința mea, lucrarea în această formă este originală și nu
a mai fost niciodat ă prezentată sau depusă în alte locuri sau alte instituții decât cele indicate în
mod expres de mine.
Data: 23.06.2016 Autor: Cristian Adri an POP
Număr matricol: 21021049
Semnătura:____________
FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
DEPARTAMENTUL DE AUTOMATIC Ă
SINTEZA
proiectului de diplomă cu titlul:
APLICAȚIE DE DISPOZITIVE MOBILE (ANDROID) ÎN SCOPUL INFORMĂRII
ASUPRA LOCALURILOR ȘI OBIECTIVELOR TURISTICE DINTR -O LOCALITATE
Autor: Cristian Adrian POP
Coordonator: Prof. dr. ing. Honoriu VĂLEAN
1. Cerințele temei :
Realizarea modelului unei aplicații în scopul informării asupra localurilor și obiectivelor
turistice dintr -o localitate astfel încât să faciliteze acomodarea persoanelor noi venite în
localitatea respectivă. Implementarea modelului folosind tehnici specifice programării
orientate pe obiect și păstrarea informațiilor într -o bază de date relațională.
2. Soluții alese:
Pentru implementarea aplicației s -a ales ca mediu de dezvoltare software Android Studio
2.0, care este mediul integrat de dezvoltare oficial pentru platforma Android, împreuna cu
Android SDK și Google API . Pentru baza de date s -a ales MySQL datorită ușurinței în
configurare și implementare.
3. Rezultate obținute:
S-a reușit implementarea unei aplicații pentru sistemul de operare Android, cu ajutorul
căreia u tilizatorii pot afla extrem de ușor și rapid informații despre diferite locații și
obiective turis tice dintr -o anumită localitate, precum și generarea unei rute de la poziția
curentă către locația dorită .
4. Testări și verificări:
Aplicația dezvoltată a fost supusă unui unor teste intense folosind numeroase tehnici și
metode de testare precum: testare unitară, testare de regresie, testare de domeniu, testare
folosind șcenarii de test și testare exploratorie astfel încat aplicația să funcționeze conform
cerințelor.
5. Contribuții personale:
Autorul a realizat o analiză a cerințelor, a implementat o bază de date care să corespundă
nevoilor programului, o interfață care să permită accesarea, adăugarea și modificarea
datelor cât mai ușor , care să faciliteze utilizarea acesteia.
6. Surse de documentare:
Internet, biblioteci digitale, site -uri de profil în programare.
Data: 23.07.2016 Semnătura autorului____________
Semnătura coordonatorului____________
Cuprins
1
Cuprins
Capitolul 1 INTRODUCERE ………………………….. ………………………….. ………………………….. …… 3
Capitolul 2 OBIECTIVE ȘI SPECIFICAȚII ………………………….. ………………………….. …………… 4
2.1 Obiective ………………………….. ………………………….. ………………………….. ……………………… 4
2.2 Specificații ………………………….. ………………………….. ………………………….. …………………… 5
2.2.1 Înregistrarea și autentificarea utlizatorului ………………………….. ………………………… 6
2.2.2 Afișarea unei hărți cu toate locațiile ………………………….. ………………………….. ……… 6
2.2.3 Listarea locațiilor în funcție de categorie ………………………….. ………………………….. 6
2.2.4 Generarea unei rute de la poziția curentă catre poziția locației dorite ……………….. 7
2.2.5 Abilitatea utilizatorului de a -și actualiza credențialele ………………………….. ……….. 7
Capitolul 3 STUDIU BIBLIOGRAFIC ………………………….. ………………………….. ………………….. 8
3.1 Programare orientată pe obiect ………………………….. ………………………….. ………………….. 8
3.1.1 Idei Generale ………………………….. ………………………….. ………………………….. …………. 8
3.1.2 Concept ele ce stau la baza programării orientate pe obiect ………………………….. …. 8
3.2 Dezvoltare de Software Android ………………………….. ………………………….. ………………… 11
3.2.1 Arhitectura Software Android ………………………….. ………………………….. …………….. 11
3.2.2 Fundamentele aplicației ………………………….. ………………………….. …………………….. 11
3.2.3 Compatibilitate ………………………….. ………………………….. ………………………….. …….. 14
3.3 Android SDK ………………………….. ………………………….. ………………………….. ………………. 14
3.3.1 Uneltele din Android SDK ………………………….. ………………………….. ………………….. 14
3.3.2 Instrumente de platformă ………………………….. ………………………….. ……………………. 16
3.4 Google API ………………………….. ………………………….. ………………………….. ………………… 16
3.4.1 Introducere în Google API ………………………….. ………………………….. …………………. 16
3.4.2 Google Maps API ………………………….. ………………………….. ………………………….. …. 16
3.4 Androi d și PHP ………………………….. ………………………….. ………………………….. …………… 18
3.4.1 Introducere PHP ………………………….. ………………………….. ………………………….. …… 18
3.4.2 PHP, MySQL și JSON ………………………….. ………………………….. ……………………….. 18
3.4.3 So licitările JSON cu HttpUrlConnection ………………………….. ………………………….. 19
Capitolul 4 ANALIZĂ ȘI PROIECTARE ………………………….. ………………………….. ……………… 20
4.1 Analiza aplicației ………………………….. ………………………….. ………………………….. ………… 20
4.2 Arhitectura Aplicației ………………………….. ………………………….. ………………………….. ….. 20
4.2.1 Diagrama de pachete ………………………….. ………………………….. …………………………. 20
4.2.2 Diagrama de clase ………………………….. ………………………….. ………………………….. … 21
4.2.3 Diagrama de Implementare ………………………….. ………………………….. ………………… 24
4.2.4 Diagrama Bazei de date ………………………….. ………………………….. …………………….. 24
Proiect de diplomă
2
4.3 Proiectarea aplicației ………………………….. ………………………….. ………………………….. …..25
Capitolul 5 IMPLEMENTAREA ………………………….. ………………………….. …………………………. 31
5.1 Mediul de dezvoltare ………………………….. ………………………….. ………………………….. …….31
5.2 Conf igurare ………………………….. ………………………….. ………………………….. ………………… 31
5.3 Implementarea aplicației ………………………….. ………………………….. ………………………….. 34
5.4 Implementarea bazei de date ………………………….. ………………………….. …………………….. 46
Capitolul 6 TESTARE ȘI VALIDARE ………………………….. ………………………….. ………………….. 48
6.1 Acoperire Testare ………………………….. ………………………….. ………………………….. ………… 48
6.2 Testare Unitară ………………………….. ………………………….. ………………………….. …………… 48
6.3 Testarea de regresie ………………………….. ………………………….. ………………………….. …….. 49
6.4 Testarea domeniului ………………………….. ………………………….. ………………………….. …….. 49
6.5 Testare folosind scenarii de test ………………………….. ………………………….. ………………… 53
6.6 Testarea exploratorie ………………………….. ………………………….. ………………………….. ……54
Capitolul 7 CONCLUZII ………………………….. ………………………….. ………………………….. ……….. 56
7.1 Contribuții personale ………………………….. ………………………….. ………………………….. ……56
7.2 Dezvoltări Ulterioare ………………………….. ………………………….. ………………………….. ……57
Biblio grafie ………………………….. ………………………….. ………………………….. …………………………. 58
Acronime ………………………….. ………………………….. ………………………….. ………………………….. …59
Capitolul 1 INTRODUCERE
3
Capitolul 1 INTRODUCERE
În ziua de azi totul se bazează accesibilitatea și viteza de accesare a informației, iar
cele mai importante lucruri care ne ajută să le maximizăm sunt calc ulatoarele și internetul.
Fară acestea accesul la numeroase informații ar fi extrem de greu și lent. Dar, aproape la fel
de importantă ca și acestea este și portabilitatea. Dacă acum un deceniu Intel lansa pe piața
ultima generație de procesoare de 166MHz, la prețul de 749 dolari americani, astăzi un
smartphone, care poate fi achiziționat la un preț extrem de accesibil de către oricine este chiar
și de 10 ori mai performant, mai mult de atât, performanța este însoțită de extrem de multe
funcționalități, pre cum o cameră foto, 4G, Wi -Fi, GPS ș.a într -o carcasă ce ne încape în
buzunar.
Această lucrare este bazată pe studiul și prezentarea dezvoltărilor aplicațiilor pentru
sistemele de operare Android, cu accent pe funcționalitatea de localizare cu ajutorul AP I-ului
Google Maps.
De-a lungul timpului, aplicațiile Android au devenit extrem de populare, acum fiind
disponibile pentru un public extrem de larg, acestea fiind ușor de implementat și de pus la
dispoziția publicului.
Originalitatea aplicației prezent ate în această lucrarea constă în funcționalitatea și
dedicarea ei pentru un anumit public. Aplicația este special implementată pentru persoanele ce
vizitează Clujul sau doresc să afle informații despre anumite localuri sau obiective turistice
din Cluj sau din apropierea Clujului .
Lucrare este structurată în șapte capitole, fiecare din acestea conținând unul sau mai
multe subcapitole cu titluri sugestive.
Primul capitol este o introducere a lucrării formată din căteva informații pe scurt
despre sistemul de operare Android și despre cum este structurată lucrarea de față.
În cel de -al doilea capitol, Obiective și specificații, sunt prezentate toate obiectivele și
specificațiile care au fost impuse și sunt îndeplinite de către aplicație.
Capitolul trei, St udiu Bibliografic, conține informații despre documentarea creată în
legatură cu sistemul de operare Android, Android SDK, API-urile necesare pentru dezvoltarea
aplicației cu scopul de a atinge toate obiectivele impuse în capitolul anterior.
Capitolul patru, Analiză și proiectare, oferă diagrame însoțite de explicații, precum
diagrama de utilizare , diagrama cazurilor sau diagrama de implementare pentru o mai bună
întelegere a modului în care s -a implementat și dezvoltat aplicația.
În capitolul cinci es te descrisă implementarea propri -zisă a aplicației: mediul de
dezvoltare a acesteia, configurările necesare, dar și modul de gândire adoptat pentru
implementarea aplicației.
Testarea aplicației folosind numeroase metode și tehnici de testare, precum testa re
unitară, testare de regresie, testare bazată pe șcenarii de test sau chiar testarea domeniului sunt
descrise în detaliu în capitolul șase al acestei lucrări.
La șfărșitul lucrării, desigur se află concluzia, care ilustrează pe scurt importanța
acestei lucrări.
Proiect de diplomă
4
Capitolul 2 OBIECTIVE ȘI SPECIFICAȚII
2.1 Obiective
Aplicația Android a fost gândită și dezvoltată astfel încat să faciliteze acomodarea
persoanelor noi venite într -o localitate, prin înglobarea unui număr mare de locații de interes
și obiectiv e turistice, însoțite de infomații de bază despre acestea și prin a oferii sprijin
utilizatorului în călătoria către locația căutată de acesta.
Orice turist iși dorește să aibă acces ușor și rapid la cât mai multe informații despre
orașul pe care îl vizi tează pentru a -și putea planifica cu ușurința perioada de vizită , prin acest
lucru minimizând timpul necesar deplasării între locații și timpul ocupat de documentarea
despre diferitele localuri și locații din localitatea ce urmeaza să o viziteze.
Aplicaț ia vine în ajutorul turiștilor, îngloband, după cum a mai fost specificat, o
mulțime locații de interes și obiective turistice precum: muzee, restaurante, hoteluri, cafenele
etc, împreună cu câteva informații de bază despre acestea: po ziție (latitudine + l ongitudine),
adresă, număr de telefon si program ul de funcționare, toate acestea fiind stocate într -o baza de
date. Mai mult de atât în baza de date mai sunt stocate informați despre utilizatorii aplicației,
acest lucru oferindu -ne o privire de ansamblu cu numărul de utilizatori ai aplicației. De
asemenea, cu ajutorul aplicației utilizatorul poate genera o rută de la poziția sa până la locația
dorită.
În dezvoltarea aplicației s -a ținut cont de următoarele aspecte:
Crearea unei interfețe intuitive care să faciliteze utilizarea aplicației pentru
utilizatori de toate vârstele .
Posibilitatea de vizionare a hărții orașului, unde sunt afișate toate locațiile
stocate in baza de date .
Posibilitatea de vizualizare a locațiilor aflate în apropierea utilizatorului
Posibilitatea de filtrare a locațiilor după categoria acestora.
Posibilitatea de cautăre a locațiilor după nume le acestora .
Afișarea câtorva informații de bază despre fiecare locație
Abilitatea de generare a unei rute de la poziția utilizatorului către poziția
locaț iei dorite.
Posibilitatea de extindere a ariei de acoperire a aplicației prin adăugarea de noi
locații în baza de date.
Posibilitatea de a evalua re a locației de către utilizator .
Modul login pe baza unei adrese valide de email.
Abilitatea de editare a credențialelor utilizatorilor de către aceștia .
Folosirea unei singure baze de date care să conțină toate locațiile și utilizatorii.
Criptarea datelor private ale utilizatorilor, pentru a fi asigurați că, în cazul în
care baza de date este compro misă, datele acestora nu pot fi accesate cu
usurință.
Capitolul 2 OBIECTIVE ȘI SPECIFICAȚII
5
2.2 Specificații
Aplicația are la bază două componente principale, o interfață grafică cu care
utilizatorul interacționează și interoghează baza de date, care se află pe un Server SQL.
Serverul necesită o instanță de MySQL în care se va afla baza de date, unde sunt
stocate toate informațiile despre utilizatori, locații și categorii, alături de fișiere PHP folosite
pentru interogarea bazei de date de către aplicație.
Tabelele prezente în baza de date:
Categorii: grupează locațiile după rolul îndeplinit de acestea pentru a
putea fi mai ușor de filtrat de către interfață
Locații: tabelul în care sunt stocate toate informațiile necesare unei locații,
acesta depinde printr -o cheie străina (FK) de tabelul Categorii .
Utilizatori: conține informații despre fiecare utilizator al aplicației în parte
Figura 2.1 Arhitectura Sistemului
Figura 2. 2 Arhitectura bazei de date
Proiect de diplomă
6
Pe parcursul lucrării se va descrie o imagine mai detaliată despre funcționalitățile
aplicației. Vor fi furzinate cazuri de utilizare și diagrame pentru a evidenția structura aplicației
și pentru a se putea vizualiza posibil ele interacțiuni ale utilizatorului cu aplicația.
Principalele funcționalități ale aplicației sunt:
1. Înregistrarea și autentificarea utlizatorului
2. Afișarea unei hărți cu toate locațiile din baza de date marcate pe aceasta
3. Listarea locații lor în funcție de categoria selectată din meniul aplicației
4. Generarea unei rute de la poziția curentă catre poziția locației dorite
5. Abilitatea utilizatorului de a -și actualiza /modifica credențialele
2.2.1 Înregistrarea și autentificarea utlizatorului
Primul ecran afișat odată cu lansarea aplicației este ecranul de Logare, unde
utilizatorul are trei opțiuni: dacă are deja un cont înregistrat în baza de date, se poate loga în
aplicație prin introducerea adresei de email și a parolei. Sau dacă utilizatorul nu are deja un
cont, din ecranul de Logare are posibilitatea să ajungă la ecranul de Înregistrare, unde acesta
își poate crea un cont prin introducerea numelui, adresei de email și a unei parole
În cazul logării, dacă datele de logare sunt valide, utilizatorul este redir ecționat catre
activitatea principală a aplicației. Dacă datele introduse în campurile text nu sunt valide,
utilizatorul va fi notificat printr -un mesaj de eroare afișat pe ecran.
În cazul înregistrării, dacă adresa de email nu există deja în baza de date , utilizatorul
este înregistrat și redirecționat către ecranul de Logare, în caz contrar un mesaj de eroare este
afișat pe ecran pentru a notifica utilizatorul de problemă.
Activitatea de înregistrare și logare va asigura un control al securității aplicaț iei, ea
utilizându -se de securitatea existentă în serverul de SQL pentru a permite unui utilizator să iși
creeze un cont, odătă îndeplinită această acțiune, acesta primește acces la aplicație . De
asemenea ea se ocupă și de crearea conexiunii cu serverul un de se află baza de date. Adresa
serverului, numele bazei de date, utilizatorul și parola de access pentru baza de date sunt luate
din fișierul de configurații, astfel nefiind nevoie de crearea unui executabil separat pentru
fiecare client .
2.2.2 Afișarea unei hărți cu toate locațiile
Activitatea principală a aplicației este harta, pe care sunt afișate pozițiile locațiilor
stocate în baza de date. Aplicația folosește Google Maps API pentru a afișa harta, iar pentru
acest lucru este necesar ca device -ul pe care rulează aplicația sa aibă instalat Google Services
și de asemenea GPS -ul sa fie activat. Din această activitate se poate folosii meniul lateral de
unde se pot accesa listele cu locațiile organizate pe categorii sau activitatea de unde
utilizatorul a re posibilitatea de a -și edita și actualiza credențialele.
2.2.3 Listarea locațiilor în funcție de categorie
Din meniul aplicației se pot accesa listele cu locațiile stocate in baza de date în funcție
de categoria selec tată, pentru fiecare locație fiind afișat numele și adresa unde este localizată.
Locațiile sunt împartite în cinci categorii:
Restaurante
Baruri/Cluburi
Hoteluri
Obiective Turistice
Transport
Capitolul 3 STUDIU BIBLIOGRAFIC
7
De asemenea utilizatorul are opțiunea de a căuta în listele respective locațiile după
numele acestora.
Odată selectată o locație utilizatorul este redirecționat către o nouă activitate, unde
sunt afișate câteva informații de bază despre locație. Printre acestea sunt incluse:
Numele locației
Adresa locației
Numărul de telefon (dacă are)
Programul de funcționare (dacă are)
Ratingul locației
O previzualizare a locației
Buton pentru generare rută
Așadar, cu ajutorul acestei activități utilizatorul află câteva informații de bază despre
locație și de asemenea poate sa genereze o rută către loc ația dorită.
2.2.4 Generarea unei rute de la poziția curentă catre poziția locației dorite
Utilizatorul are posibilitatea de a genera o rută de la poziția curentă până la poziția
locației dorite, prin apăsarea butonului situat după informațiile despre lo cația selectată. Acest
lucru este posibil deoarece pentru implementarea hărți din aplicație s -a folosit API -ul Google
Maps și folosind un API adiacent acestuia și anume Google Maps Directions API putem
genera o rută, de la poziția curentă, transmisă de GPS -ul dispozitivului pe care rulează
aplicația în latitudine si longitudine, către locația dorită, care are î n baza de d ate stocată
poziția sub formă de latitudine și longitudine . Dacă dispunem de latitudine ș i longitudine
pentru ambele locații, aplicația tr ansmite o cerere cu coordonatele originii, coordonatele
destinației, modul de parcurgere a distanței (pe jos sau cu mașina) urmate de cheia API
generat ă de Google Maps. Datorită acestei cereri aplicația prime ște un răspuns JSON prin
care se generează ruta către locație și se calculează distanț a până la aceasta și timpul în care
poate fi parcursă acestă distanță.
2.2.5 Abilitatea utilizatorului de a -și actualiza credențialele
Din meniu se poate accesa și pagina de setări, unde utilizatorul are posibilitatea de a-
și edita și actualiza credențialele sau de a se deloga din aplicație. Pentru a putea sa iși
schimbe cu succes credențialele, acesta trebuie să introducă corect parola veche și să
introducă noua parolă în câmpul text destinat pentr u noua parolă și în câmpul text destinat
pentru confirmarea noii parole. Dacă aceste două cerințe sunt î ndeplinite, un mesaj de succes
este afișat pe ecran, în caz contrar utilizatorul este notificat cu un mesaj de eroare de greșeala
facută: parola actuală introdusă este incorectă sau parola nouă nu se potrivește cu cea
introdusă în câmpul destinat confirmării parolei.
Proiect de diplomă
8
Capitolul 3 STUDIU BIBLIOGRAFIC
3.1 Programare orientată pe obiect
3.1.1 Idei Generale
Programarea Orientată pe Obiect (POO), sau Object – Oriented Programming (OOP),
în engleză e ste o filozofie de design. Ea util izează un set diferit de limbaje de programare,
decât vechile limbaje de programare procedurale (C, Pascal, etc.). Totul în POO este grupat ca
și “obiecte” auto-sustenabile. Prin urmare se câștigă reutilizabilitate prin intermediul a patru
mari concepte ce stau la baza POO.
Dar pentru a putea întelege clar aceste concepte trebuie să definim mai întâi ce este un
obiect ș i o clasă.
Un obiect poate fi considerat un lucru care p oate efectua o serie de activități conexe.
Setul de activități pe care îl execută obiectul respectiv definește comportamentul acestuia. Din
punct de vedere pur POO un obiect este o instanță a unei clase. El este identificat unic prin
nume și la randul său poate fi considerat un atribut al unei alte clase. Mai mult de atât el mai
poate fi caracterizat prin atribute ș i metode , acestea fiind definite în clasa din care face parte
obiectul.
O clasă este o reprezentare a unui tip de obiect. Este planul sau șabl onul care descrie
detaliile unui obiect sau șablonul din care sunt create obiectele individuale. O clasă este
compusă din trei lucruri: un nume, atribute și operații. Atributele pot fi asimilate cu proprietăți
ale unor obiecte, iar metodele cu acțiuni ce p ot fi executate de către obiecte.
3.1.2 Conceptele ce stau la baza programării orientate pe obiect
Un sistem software poate consta din mai multe clase, iar acesta clase trebuie
gestionane. [1] În scopul de a gestiona clasele sistemului și de a reduce complexitatea
aplicației se folosesc mai multe tehnici, care pot fi grupate în patru concepte principale numite
1. Încapsulare
2. Abstractizare
3. Moștenire
4. Polimorfism
Figura 3.1 Concepte POO
Capitolul 3 STUDIU BIBLIOGRAFIC
9
1. Încapsularea se poate defin i prin înglobarea în cadrul unui program obiect a tuturor
resurselor necesare pentru ca obiectul sa funcționeze, în principiu metodele și datele. În POO
încapsularea este realizată prin crearea de clase. Aceste clase expun metodel e publice și
proprietățile aplicației. Așadar, o clasă acționează precum un recipient sau o celulă, care
încapsulează un set de metode, atribute și proprietăți pentru a furniza funcționalitățile sale si
celorlalte clase. În acest sens încapsularea permite unei clase să își schimbe implementarea
internă fără a dăuna funcționarea generală a sistemului. Idea de încapsulare este aceea de a
ascunde modul de funcționare a unei clase, dar în acelaș i timp permițâ nd solicitări primite de
la alte clase.
În scopul de a definii funcționalitatea unei clase, clasa respectivă poate folosi funcțiile
sau proprietățile expuse de către alta clasă în numeroase moduri. În conformitate cu POO
există mai multe tehnic i de care clasele se pot folosi pentru a se unii una de cealaltă . Aceste
tehnici sunt numite: Asociere, Agregare si Compoziție.
Asocierea este o relație slabă semantic între obiecte care înafară de această legatură nu
au nicio altă legatură. O asociere folosește o relație între două sau mai multe obiecte în care
obiec tele au fiecare timpul lor de activitate și nici un proprietar. Un exemplu fiind relația între
un Profesor și un Student. Un profesor poate fi asociat cu mai mulți studenți î n același timp,
iar un student poate să participe la cursurile a mai mulți profeso ri. Fiecare dintre aceste
obiecte au propriile lor cicluri de viață (timp de acvititate) și nu există nici un proprietar. Cu
alte cuvinte, obiectele ce fac parte din relația de asociere pot fi create și distruse independent.
Agregarea este o formă specializată de asociere între două sau mai multe obiecte, în
care obiectele au propriul lor ciclu de viață, dar spre deosebire de asociere aici există o
stăpânire între cele obiecte. Agregarea denotă o relație de tip întreg -parte, d ar nu tot timpul
aceasta înseamnă și izolare fizică, obiectele pot sau nu să fie o parte din întreg. Așadar în
relația de agregare obiectele au propriul lor ciclu de viață, dar aceastea nu au dreptul la
proprietate. Spre exemplu un Profesor poate să facă p arte din mai multe Departamente din
cadrul unei Universități. Cu toate aceastea, în cazul in care Departamentul ar fi șters, obiectul
Profesor nu ar fi distrus.
Compoziția este o formă specializată de agregare în care, dacă obiectul este distrus și
obiect ele de tip copil ale acelui obiect ar înceta să existe. Cu alte cuvinte compoziția este un
tip puternic de agregare. În esența compoziția este de asemenea o relație întreg -parte, doar că
spre deosebire de agregare aici ciclul de viață este controlat de înt reg. Ca exemplu putem lua
relația dintre o Universitate și Facultațile acesteia. Fără o Universitate, nu ar exista nici un
obiect de tip Facultate, deci, timpul de viața al obiectelor de tip Facultate este atașatt de
timpul de viața al obiectului de tip Un iversitate.
În concluzie agregarea este un tip special de
asociere , iar compoziția este un tip special de agregare
(Asociere → Agregare → Compoziție).
Figura 3.2 Diagramă tehnici
Încapsulare
Proiect de diplomă
10
2. Abstractizarea este un accent pe ideea de sup rimare de detaliu (calitățile și proprietățile
sunt mai importante decât datele programului). Importanța abstractizării este derivată din
capacitatea sa de a ascunde detaliile irelevante și din utilizarea denumirilor obiectelor de
referință. Abstractizarea este esențială în construcția de programe, deoarece ea pune accentul
pe ceea ce este și ce face un obiect, nu pe cum este acesta reprezentat sau cum funcționează.
Astfel, ea este principalul mijloc de gestionare a complexității din programele mari.
Clasele abstracte sunt declarate cu ajutorul cuvântului cheie “abstract” și nu pot fi
instanțiate. Acestea pot fi folosite doar ca o super -clasă pentru restul clasel or care extind clasa
abstractă. Clasa abstractă este conceptul, iar implementarea este finalizată atunci c ând este
realizată de o subclasă. În plus față de aceasta o clasă poate moșteni numai de la o clasă
abstractă (dar ea poate implementa numeroase interfețe) și trebuie să suprascrie toate
metodele și proprietățile care sunt declarate abstracte.
3. Moștenirea este capacitatea de creare a unei clase prin extinderea unei clase deja existente,
fie folosind doar anumite părți și metode din clasa moștenită, fie întreaga clasă, plus alte
metode sau proprietăți adăugate ulterior în noua clasa.
Una din cele mai importante relații dintre obiectele din lumea reală este specializarea,
care poate fi descrisă ca o relație “este – o”. Când spunem ca un câine este mamifer, întelegem
că acest câine are specializarea de mamifer. El are toate caracteristicile unui mamifer (naște
pui vii, ii hrănește cu lapte, are păr etc.), dar specializează aceste caracteristici la grupa
familial ă de caracteristici a “canis domesticus ”. O pisică este tot un mamifer. C a atare, ne
așteptăm să împărtășească anumite caracteristici cu câinele, care sunt generalizate
mamiferului, dar s ă difere în caracteristicile specifice pisicilor. Relațiile de specializare și
generalizare sunt atât reciproce cât și ierarhice. Specializare a este doar cealaltă parte a
monedei de generalizare: Mamiferul generalizează ce este comun între câini și pisici, iar
câinii și pisicile specializează mamiferele la propriile lor subtipuri specifice.
4. Polimorfismu l este un termen generic care pr ovine din două cuvinte grecești, poli și morf .
Poli înseamnă mai m ulte, iar morf înseamnă forme , așadar cuvântul s -ar traduce cu mai multe
forme . Mai precis, polimorfismul înseamnă capacitatea de a solicita ca aceleași operațiuni să
fie efectuate de către o gamă largă de tipuri diferite de lucruri.
În POO polimorfismul se realizează pr in utilizarea mai multor tehnici diferite numite:
Supraîncarcarea metodelor , Supraîncarcarea operatorilor și Suprascrierea metodelor .
Supraîncarcarea metodelor este abilitatea de a definii mai multe metode, toate având
același nume.
Supraîncarcarea operatorilor (mai puțin frecvent cunoscută ca și polimorfism ad -hoc)
este un caz specific de polimorfism în care unii sau toti operatorii precum “+”, “ -” sau “= =”
sunt tratați ca funcții polimorfe și ca atare au comportamente diferite în funcție de tipurile de
argumente.
Suprascrierea metodelor este o caracteristică de limbaj care permite o subclasă să
suprascrie o implementare specifică a unei metode care este deja asigurată de u na dintre
super -clasele sale. O subclasă poate da o definiție proprie metodelor, dar t rebuie sa aibă
aceeași semnatură ca și metoda din super -clasă. Acest lucru înseamnă că, atunci când o
metodă este suprascrisă de către o metodă dintr -o sub -clasă, această metodă trebuie sa aibă
același nume și aceeași parametrii ca ș i metoda suprascrisă din super -clasă.
Capitolul 3 STUDIU BIBLIOGRAFIC
11
3.2 Dezvoltare de Software Android
3.2.1 Arhitectura Software Android
Următoarea imagine afișează componentele majore ale sistemului de operare Android. [2]
Figura 3.3 Componentele si stemului Android
3.2.2 Fundamentele aplicației
3.2.2.1 Componentele aplicației
Aplicațiile android sunt create pentru sistemul de operare Android și sunt de obicei
dezvoltate în limbajul de programare Java folosind un framework de aplicare larg ș i adaptiv
oferit de către Android. În general o aplicație Android est e formată din una sau mai multe
componente ce pot rula în mod individual. Există patru tipuri de componente, fiecare dintre
acestea având rolul său specific: Componenta de activitate, Componenta de servicii,
Furnizorul de conținut și Receptoarele de emisie .
Blocul de construcție a interfeței cu utilizatorul (UI) este activitatea [3]. Practic ea este
echivalentul unei ferestre dintr -o aplicație desk top. Activitățile sunt independente una de alta,
dar o aplicație are de obicei mai multe activit ăți care lucrează împreună pentru a forma o
Proiect de diplomă
12
aplicație bine definită , ele furnizând și partea de UI. O activitate poate fi pornită din altă
activitate folosind Intent -uri, care, de asemenea sunt folosite pentru a transmite informații
între cele două componente.
Una din activitățile folosite în aplicație este declarată ca activitatea principală, ea fiind
prima activitate afișată c ând utilizatorul pornește aplicaț ia. În momentul în care o altă
activitate este pornită, aceasta dobândește focusul utilizatorului, iar activitatea precedentă este
oprită, dar este pastrată în “stiva din spate”, astfel , atunci când butonul “Înapoi” este apăsat,
activitatea este repornită.
O activita te conține de obicei o interfață cu una sau mai multe View -uri. Un view este
o regiune dreptunghiulară aflată în interiorul ecranului, precum butoane, liste, view -uri pentru
text, care pot reacționa la click -uri, inserări de text etc. Primul view (View -ul părinte) conținut
de orice activitate este View -ul de Layout, care se ocupă de schema view -ului. Acesta
specifică unul din cele trei scheme disponibile: grilă ( eng. Grid Layout), relativ ( eng. Relative
Layout) și liniar ( eng. Linear Layout).
Cum a fost menționat mai sus, Intent -urile sunt elemente folosite pentru a trece de la o
activitate la alta. În plus, cu ajutorul acestora se pot transfera date. Există două tipuri de
intent -uri în Android: intent -uri implicite și intent -uri explicite. Ce le explicite sunt folosite
atunci când activitatea ce urmează să fie deschisă este definită ca și paramentru pentru Intent.
Pe de altă parte , Intent-urile implicite nu trebuie să cunoască activitatea care trebuie să fie
deschisă, doar acțiunea ce urmează s ă fie executată. De exemplu, dacă dorim să trimitem un
e-mail, stabilim acțiunea intent -ului cu Intent.ACTION_SEND, iar sistemul va recunoaște
automat acți unea și va decide care este cea mai indicată acțiune, pe care o va utiliza [4].
Transmiterea datelor de la o activitate la alta se mai poate face folosind pachete ce pot conține
toate tipurile de date.
Furnizorul de conținut poate fi utilizat pentru stocarea datelor locale în locații precum
SQLite, servere sau sisteme de fișiere. Aplicația poate interog a și modifica datele, ceea ce
înseamnă mai multe aplicații pot accesa aceleași date, dar doar dacă furnizorul de conținut
permite acest lucru. SQLite este o bază de date open -source și face parte din orice dispozitiv
Android. SQLite permite operații precum creare și actualizare, de asemenea acceptă tipuri de
date precum: text, întregi (integer) și reale, dar nu verifică dacă coloanele conțin tipurile de
date respective. De exemplu se poate introduce text intr -o coloană definita ca întreg.
Serviciul este c omponenta care rulează pe fundal, se ocupă de executarea operațiunilor
și nu oferă utilizatorului o interfață. Un serviciu poate rula în continuare pe fundal , chiar dacă
utilizatorul navighează către o alt ă aplicație. Printre acțiunile ce pot fi executate de serviciu se
număra: descărcări de pe internet, operații de intrare și iesire (I/O), modificarea furnizorilor de
conținut, redare muzică ș.a.m.d. Un serviciu poate lua, în esență, dou ă forme: Servicii pornite
explicit (eng. Started) și servicii atașate u nei/unor componente (eng. Bounded) [5]. Într -un
serviciu pornit explicit o componentă (spre exemplu o activitate) pornește serviciul care nu
are un rezultat și care poate rula în continuare chiar și după ce componenta sa oprit. Acest tip
de serviciu, de ob icei, se oprește singur, odată ce a terminat ce trebuie să facă. Spre deosebire
de serviciul pornit explicit, serviciul atașat unei componente este oprit, odată ce componenta
se eliberează.
Un receptor de emisie este o componentă care răspunde la un sistem de emisie a
anunțurilor. Practic o aplicație poate iniția emisia pentru a face restul aplicațiilor conștiente de
un transfer de date, spre exemplu.
Capitolul 3 STUDIU BIBLIOGRAFIC
13
3.2.2.2 Opțiuni de stocare
Sistemul de operare Android oferă posibilitatea de a stoca datele pentr u o aplicație,
indiferent dacă acestea sunt private sau accesibile și altor aplicații. Datele statice, cum ar fi
fișiere text de mici dimensiuni pot fi ambalate direct în aplicație. În plus față de asta opțiunile
de stocare sunt vaste: preferințe comune, s tocare internă, stocare externă, bază de date SQLite
și conexiune la rețea.
Metoda de stocare a preferințelor comune permite utilizatorului să stocheze date sub
formă de perechi cheie -valoare, spre exemplu într -un fișier XML. Odată ce aplicația este
dezinstalată sau datele aplicației sunt șterse de pe dispozitiv, datele se pierd.
Stocarea internă înseamnă stocarea datelor private ale aplicației, care nu pot fi accesate
de alte persoane. Odată ce aplicația este dezinstalată, datele sunt șterse.
Stocarea externă înseamnă stocarea datelor pe un mediu de stocare precum un Card
SD. Datele stocate folosind acest tip de metodă de depozitare sunt accesibile de către toți
utilizatorii și toate aplicațiile.
3.2.2.3 Rețele
Sistemul de operare Android permite acc esul la internet (folosind Wi -Fi sau o
conexiune mobilă de internet). Pentru a efectua operațiuni precum trimiterea sau primirea de
date, o mare parte din aplica țiile Android folosesc Conexiuni HTTP. Statusuril e conexiuni
sunt folosite pentru a determina d aca aplicația este conectată la internet sau în ce stagiu de
conectare se află. Statusurile unei conexiuni sunt următoarele: Conectare, Deconectare,
Conenctat, Deconectat, Suspendat și Necunoscut.
Există un client integrat în sistemul de operare pentru ef ectuarea de operațiuni ce
necesită conexiune la internet și anume HttpURLConnection. Datele trimise și receptate cu
ajutorul clientului pot fi de orice tip și lungime. De asemenea această clasă poate fi utilizată
pentru a trimite și primi date la care nu e ste cunoscută lungimea.
În plus pentru o performanță, o viteză de transmitere și receptare mai bună Android
pune la dispoziție încă un client, numit Volley. Acesta, spre deosebire de primul, nu este
integrat î n sistemul de operare ci se obține prin import area în program a librăriei clientului de
pe un AOSP Repository [6].
Volley oferă următoarele beneficii [7]:
Programarea automată a cererilor de rețea
Abilitatea de a avea multiple conexiuni concurente de rețea
Sprijin pentru prioritizarea solicitărilor
API pentru anularea solicitărilor
Ușurința de personalizare. Spre exmplu pentru reîncercare sau anulare
Ordonare puternică care facilitează popularea corectă a UI -ului cu datele
preluate în mod asincron de pe rețea
Instrumente pentru depanare și urmărire
3.2.2.4 GPS
Sistemul de operare Android oferă servicii de GPS, ceea ce face posibilă construirea
de aplicații care utilizează hărți pentru a afișa o anumită locație .
Proiect de diplomă
14
3.2.2.5 Servicii de telefonie
Aplicațiile Android sunt aplicații mobile, așadar ele sunt sunt capabile să furnizeze
servicii de telefonie precum apelarea unui număr de telefon sau trimiterea unui SMS către
numărul respectiv.
3.2.3 Compatibilitate
Sistemul de operare Android poate rula un număr mare de dispozitive, precum
smartphone -uri, tablete, smartwatch -uri și chiar televizoare, oferind aplicației un număr mare
de utilizatori. Pentru ca o aplicație să fie compatibilă cu o varietate de dispozitive, aceasta
trebuie să respecte anumite reguli în ceea ce privește caracteristicile si confi gurațiile de ecran.
Aplicațiile pot avea restricții in ceea ce privește compatibilitatea dispozitivelor: unele aplicații
sunt implementate doar pentru a rula pe anumite dispozitive, alte aplicații vor funcționa doar
în anumite țări, iar în ulimul rând exis tă aplicații care necesită o anumită versiune minimă de
Android pentru a putea rula.
3.3 Android SDK
3.3.1 Uneltele din Android SDK
3.3.1.1 Introducere în Android SDK
Kitul de dezvoltare Software Android reprezintă un set de instrumente disponibile
pentru dezvoltarea de aplicații, folosind cele mai recente caracteristici disponibile de pe
platforma Android. Fiecare versiune de SDK este lansată de către Goog le, odată cu lansarea
unei noi versiuni de Android [8].
Android SDK include o varietate de inst rumente care ajută la dezvoltarea de aplicații
mobile pentru platforma Android. Unele dintre cele mai importante instrumente din Android
SDK sunt Managerul Android SDK, Managerul AVD și un emulator pentru dispozitive
mobile.
Managerul Android SDK este o c omponentă care conține toate instrumentele necesare
pentru dezvoltarea de aplicații Android, organizate în pachete si disponibile pentru instalare.
3.3.1.2 Instrumentele dispozitivului virtual
Managerul AVD este furnizat de către Android SDK, cu scopul de a crea și gestiona
dispozitive virtuale. Emulatorul AVD ajută la testarea aplicației pe un mediu asemanător unui
dispozitiv, fără ca utilizatorul s ă fie nevoit s ă conecteze un dispozitiv fizic. Un AVD poate
imita o serie de caracteristici specifice disp ozitivelor fizice precum: prezența unei camere
foto, un tip specific de tastatură sau câtă memorie are; caracteristicile de design sunt de
asemenea disponibile, inclusiv dimensiunile ecranului, aspectul, etc.
AVD oferă un număr mare de dispozitive ce pot fi simulate pentru a testa aplicație, de
asemenea se poate configura un dispozitiv de la zero, dar este important să se aleagă un nivel
de API cel puțin egal cu cel necesar pentru rularea aplicației.
3.3.1.3 Instrumente de dezvoltare
Una din cele mai i mportante instrumente pentru dezvoltare este Androidul în sine
deoarece permite crearea, eliminarea AVD -ului, gestionarea proiectelor și actualizarea SDK –
ului. Utilizările caracteristicelor instrumentului din linia de comandă nu sunt necesare dac ă
aplicați a este dezvoltată în Eclipse sau în Android Studio IDE, încât acesta este integrat.
Capitolul 3 STUDIU BIBLIOGRAFIC
15
Vizualizatorul de ierarhie (eng. Hierarchy Viewer ) este folosit pentru optimizarea UI –
ului, deoarece oferă o interpretare vizuală a View -ului de layo ut, permițând dezvolta torului să
urmărească problemele legate de layout pe parcursul dezvoltării și depanării aplicației.
Instrumentul poate fi lansat din linia de comandă, dar, este de asemenea integrat ca o
perspectivă în Eclipse IDE.
Android Lint este un instrument a cărui scop este de a inspecta aplicația și de a
verifica eventualele bug -uri și/sau erori, cum ar fi traducerile absente, executarea layout -ului,
probleme cu pictogramele, gradul de utilizare a resurselor, dimensiuni incompatibile ale
vectorilor ș.a.m.d.
Manage rul Android SDK este un instrument care conține toate componentele necesare
pentru dezvoltarea de aplicații Android.
Instrumentul sqlit3 este util pentru gestionarea bazelor de date folosite de către
aplicațiile Android și pentru executarea comenzilor SQLite.
3.3.1.4 Instrumente de depanare
După cum este sugerat și din titlu, instrumentele de depare sunt utile pentru depanarea
aplicațiilor Android. Una din cele mai importante instrumente in acest scop este ADB -ul.
Acesta permite testarea aplicațiilor pe un dispozitiv fizic, precu m și pe un emulator. Î n cazul
în care dispozitivul Android ajunge să fie “bricked” (informațiile dispozitivului sunt
inutilizabile, dispozitivul nu mai pornește) ADB -ul permite restaurarea dispozitivului,
repornirea acestuia, instalarea și dezinstalarea de aplicații, crearea de copii de siguranț ă ș.a.
[9] ABD -ul este un instrument format din trei componente:
Clientul – care rulează pe un desktop/laptop sau orice alt dispozitiv de
dezvoltare
Serverul – proces ce rulează pe fundal
Daemon – rulează pe emulator sau pe dizpozitivul pe care este instalată
aplicația în curs de testare
În cazul în care dispozitivul este conectat la aparatul de dezvoltare prin USB,
utilizarea ADB va avea succes numai în cazul in care modul de de panare USB este activat pe
dispozitivul conectat.
DDMS -ul este metoda principală pentru depanarea aplicațiilor Android, deoarece
oferă caracteristici, cum ar fi serviciile de port -forwarding, funcția de print screen, log -urile
dispozitivului ș.a.m.d.
Monitorul dispozitivului (eng. Device Monitor) este un instrument de depanare și de
analiză de sine stătătoare, care încorporează o serie de alte instrumente, unele din ele deja
menționate precedent: DDMS, Hierarchy Viewer, Systrace si Traceview.
Systrace c apturează și prezintă timpul de execuție, în scopul de a analiza performanța
aplicației, iar Traceview este un instrument de depanare care prezintă grafic jurnalele de
executie salvate de către aplicație.
3.3.1.5 Instrumente de construcție
Instrumentele de construcție sunt unele din cele mai impornante instrumente din
Android SDK, deoarece ele sunt absolut necesare pentru implementarea și actualizarea în mod
regulat a codului aplicatiei.
[10] Fișierele OBB sunt utile pentru furnizarea de resurse suplime ntare pentru
aplicațiile Android, precum imagini și sunete. Acestea sunt obținute cu ajutorul instrumentului
Proiect de diplomă
16
JOBB buid, prin construirea de fișiere de extindere APK în formatul respectiv. Pentru a putea
utiliza acest instrument, nivelul API al Androidului trebuie sa fie mai mare sau egal cu nouă.
Alt instrument de construcție include ProGuard, care este utilizat pentru optimizarea
codului, deoarece elimină părțile neutilizate și redenumește elementele cu scopul de a reduce
memoria ocupată de către aplicați e și de a îmbunătății performanța aplicației.
3.3.1.6 Instrumente de Imagine
Instrumentele de imagine sunt utilizate pentru elemente UI, cum ar fi crearea de
bitmap -uri folosind instrumentul Draw -9-Patch, codarea sau decodarea de imagini PNG la și
de la compresie ETC1 folosind etc1tool și capturarea de imagini cadru cu cadru cu ajutorul
instrumentului Tracer pentru OpenGL ES .
3.3.2 Instrumente de platformă
Android este o platformă și un software oferit , de compania Google , gratis, care
include un sist em de operare, un middleware și de asemenea aplicații destinate utilizării pe
dispozitivele mobile, inclusiv pe smartphone -uri[11].
Platformele Android SDK sunt eliberate in mod regulat, sprijină un tip de arhitectură
de procesor și contine de asemenea AP I-uri Google.
3.4 Google API
3.4.1 Introducere în Google API
API-ul este un set de rutine, protocoale și instrumente pentru construirea de aplicații
software. Google a dezvoltat un set de API -uri care sunt utilizate pentru servicii precum e –
mail, căutar e, traducere și hărți. El permite comunicarea cu Serviciile Google (eng. Google
Services) . [12]
3.4.2 Google Maps API
Google Maps API permite utilizarea de hărți în aplicația Android folosind datele de la
Google Maps, ceea ce înseamnă că aplicația poate accesa serverele, descărca datele și afișa
hărțile. Hărțile suportă o varietate mare de caracteristici precum adăugarea de markere și
poligoane.
3.4.2.1 Certificatul Google și Cheia API pentru Google Maps
O cheie API pentru Google Maps este un șir de text de patruzeci de caractere, care
trebuie sa fie obținut pentru a putea accesa Serviciile Google API gratis din Consola pentru
dezvoltatori Google (eng. Google Developers Console).
Pentru a putea obțiune o cheie API, un certificat digital trebuie să fie “legat” de
aceasta, dar, mai multe aplicații cu același certificat pot folosii aceeași cheie, deși recomandat
este ca fiecare aplicație să aibă propriul certificat și folosească propria cheie API.
Cheia AP I pentru Google Maps se bazează pe o amprentă digitală SHA -1. Aceasta,
asemeni unei chei API, este un șir unic de caractere folosit de Google API pentru a identifica
aplicația.
Există două tipuri de certificate:
Certificat de Depanare (eng. Debug Certifi cate)
Certificat de Lansare (eng. Release Certificate)
Capitolul 3 STUDIU BIBLIOGRAFIC
17
Certificatul de depanare este generat de obicei de c ătre instrumentele SDK, atunci
când aplicația este depanată. Acest certificat nu ar trebui să fie utilizat pentru a obține o cheie
API, deoarece, a cesta este folosit pentru testare și depanare, nu și pentru a fi lansată și
publicată.
Certificatul de lansare este cel generat în momentul în care este construită o variantă
de lansare a aplicației. Amprenta digitală a acestui certificat trebuie folosită pentru generarea
chei API.
Cheia API este trasmisă c ătre serverul Google, care confirmă înregistrarea și accesul la
datele Google Maps, după care cheia este pusă în fișierul manifest al aplicației. Setările
suplimentare trebuie specificate în fișierul de manifest a l aplicației pe lângă cheia API, cum ar
fi versiunea de Servicii Google și permisiunile pentru a avea acces la serverul Google Maps.
3.4.2.2 Harta
După cum a fost menționat precedent, se pot folosii hărțile de la Google în aplicații
datorită API-ului Google Maps, care este fie reprezentat fie printr -un MapFragment, fie
printr -un MapView. Bucățile de hartă se vor descarca automat și harta afișata va fi putea fi
mișcată și mărită pentru a facilita găsirea unei locații. MapFragment -ul și MapView -ul
acționeaz ă precum un suport pentru hartă; diferența dintre cele dou ă, este ca fragmentul poate
fi o parte a interfeței utilizatorului și poate fi combinat cu alte fragmente în aceeași activitate,
în timp ce View -ul, are forma unui dreptunghi și ocupă o parte sau întregul ecran.
Există cinci tipuri de hărți oferite de cei de la Google prin intermediul API -ului:
Hărți Normale – conțin elementele naturale și drumuri
Hărți Hibride – conțin imagini din satelit și drumuri
Harți prin Satelit – care conțin nu mai imagini din satelit
Harți de teren – care conțin date topografice
Nici una – afișarea unei grile goale
Pe lângă tipul de hartă, se mai pot specifica și alte caracteristici ale hărții precum:
poziția camerei, butoanele de zoom și gesturile utilizator ului.
3.4.2.3 Datele privind locația
Una din cele mai remarcabile caracteristici ale Google Maps API este opțiunea de
accesare a datelor prinvind locația. Cu ajutorul acestei opțiuni avem posibilitatea de a accesa
poziția curentă a dispozitivului, direcț ia și chiar metoda de deplasare. Există trei straturi (eng.
layers) / interfețe cu care se poate lucra: My Location Layer, Google Play Services Location
API și Interfața Location Source.
My Location Layer poate furniza utilizatorului locația curentă a dispozitivului. Pentru
ca acesta să fie utilizat două permisiuni trebuie adăugate la fisierul manifest al aplicației:
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"
/>
<uses-permission android:name="android.permission.ACCESS_FIN E_LOCATION"
/>
API-ul Google Play Services Location este mai bogat în caracteristici. Acesta include
capacitatea de a stabilii locația curentă a dispozitivului, este capabil șa fie conștient de o
schimbare de locație și poate modifica modul de transport, în cazul deplasă rii.
Proiect de diplomă
18
3.4.2.4 Elementele grafice ale hărții
Elementele de marcaj (eng. Markers) sunt elemente grafice care arată locații de pe
hartă. Ace știa pot fi personalizați prin abilitatea de schimbare a culorii implicite sau chiar
abilitatea de a înlocuii pictog rama implicită, poziția, ancora, titlul, vizibilitatea ș.a.m.d.
Ferestrele de informații sunt popup -uri atașate elementelor de marcaj, făcând posibilă
afișarea unei mici bucăți de informa ție cu privire la o anumită locație, în momentul în care
elementul d e marcaj este apăsat.
Pentru conexiunea între două sau mai multe locații, API -ul Google Maps ne oferă
forme specializate pentru hartă. Formele includ: polilinii, poligoane și cercuri. Diferența
dintre cele trei forme este aceea că poliliniile sunt segment e care leagă două sau mai multe
locații, poligoanele, de asemenea conectează locații, doar că acestea se află într -o buclă
închisă (astfel definind o arie). Cercurile sunt similare cu poligoanele, doar că se folosesc de o
rază calculată de la o anumită loc ație considerată centru.
3.4 Android și PHP
3.4.1 Introducere PHP
Limbajul PHP este un limbaj de programare simplu, sigur eficient și flexibil folosit
pentru scripting pe partea de server cu conținut dinamic, baze de date și un tracker pentru
sesiune. Este un limbaj open -source, gratis și a devenit foarte popular dealungul timpului
deoarece stă la bazele multor CRM -uri, precum WordPress sau Drupal. Cu ajutorul PHP -ului
se pot efectua un numar mare de funcționalităti precum: generarea de conținuturi dinam ice,
crearea, deschiderea, citirea, scrierea, ștergerea și închiderea fișierelor de pe un server,
adăugarea, ștergerea și modificarea datelor dintr -o bază de date ș.a. Printre alte avantaje ale
utilizării PHP se numără și faptul ca rulează pe un număr extr em de mare de platforme,
deoarece este compatibil cu multe servere și baze de date.
3.4.2 PHP, MySQL și JSON
După cum a fost menționat precedent, PHP va sprijinii orice bază de date, dar una din
cele mai frecvent utilizate baze de date este MySQL.
MySQ L este una din cele mai populare baze de date, deoarece este gratuită, rapida,
consistentă, de bună calitate și ușor de utilizat cu JSON.
JSON este un format util pentru stocarea și schimbul de date. Acesta este format din
perechi nume – valoare și o li stă ordonată. De asemenea acesta este mai ușor decât formatul
XML, deci se transmite mai rapid.
PHP-ul este utilizat pentru conectarea la baza de date MySQL cu ajutorul a două
funcții:
mysql _connect – folosește cinci parametrii opționali (server, utilizat or, parol ă,
new_link, client_flag ) și returneaz ă un identificator de legătură în cazul în care
conexi unea a fost cu succes sau fals (eng. false), în cazul în care conexiunea nu
a reușit. Acestă funcție este utilizată pentru deschiderea unei conexiuni la ba za
de date
mysql_close – care returnează “adevărat” (eng. true), în cazul in care
conexiunea cu baza de date a fost închisă cu succes, sau fals în caz contrar.
Această funcție este utilizată pentru închiderea unei conexiuni la baza de date.
Capitolul 3 STUDIU BIBLIOGRAFIC
19
Pentru a crea o bază de date MySQL, este necesar s ă avem drepturi și privilegii de
Administrator. Funcția de a executa această funcționalitate este mysql_query și are nevoie de
doi parametrii (interogarea SQL corespunzătoare pentru crearea unei baza de date și a
conexiunii către ea). Dacă baza de date a fost creată cu succes, funcția va returna adevărat, iar
în caz va returna fals . Comanda mysql_query este predominant folosită pentru interogări ale
bazei de date, precum: creare, citire, actualizare și ștergere (oper ații CRUD).
Funcția mysql_fetch_array este folosită pentru extragerea datelor din baza de date, iar
dacă acest lucru se face cu succes, ea returneaza rândurile interogate și transmite datele într –
un format JSON.
3.4.3 Solicitările JSON cu HttpUrlConnection
Așa cum a fost menționat anterior, UI -ul și operațiunile de rețea ar trebui să fie
efectuate folosind fire de execuție (eng. Threads) diferite. [13] Acest lucru este posibil cu
ajutorul clasei AsyncTask, care permite execuția multifir (e ng. multithreading) prin operații
care rulează în fundal și trimit rezultatele către UI. AsyncTask este folosit pentru efectuarea
operațiunilor și extragerea datelor de pe server, după aceasta avem metoda doInBackground
(execută în fundal), care ruleaza p e un alt fir de execuție și se foloseste de HttpClient pentru a
prelua datele. După ce primește răspunsul, aceasta verifică dacă a realizat operația cu succes,
iar în caz afirmativ, acesta preia conținutul pe care îl convertește intr -un șir (eng. String).
După ce metoda doInBackground își incheie activitatea, metoda onPostExecute (post
execuție) îi preia locul.
Există două metode pentru a trimite solicitări și răspunsuri între client și server:
metoda POST și metoda GET .
Metoda GET trimite informațiile anexate cererii. Ea poate fi folosită pentru a trimite
date cu lungimi de până la 1024 de caractere, dar nu poate fi folosită pentru a transmite date
binare. De asemenea nu este recomandată transmiterea de date importante, precum parole
folosind tipul ace sta de metodă. Cererile trimise folosind metoda GET sunt de obicei salvate
în istoria navigatorului web sau pot rămâne stocate în memoria cache.
Metoda POST se folosește de corpul mesajului pentru a trimite informația. Spre
deosebire de metoda GET, aceast a metodă este mai flexibilă deoarece poate fi folosită pentru
a trimite o cantitate infinită de informații, precum și informație în cod ASCII și date binare.
Informațiile importante, precum parolele, pot fi trimise folosind această medotă, dar doar dacă
este folosit Secure HTTP. PHP foloște $_GET, respectiv $_POST pentru a aduna informațiile
trimise prin metodele GET si respectiv POST.
Alte diferențe între medotele POST și GET apar în momentul în care butonul de
întoarcere este declanșat: acest lucru nu af eactează informațiile cand metoda GET este
folosită, dar datele vor fi înaitate și retransmise în cazul metodei POST.
Datele în formatul JSON pot fi tratate folosind patru clase diferite oferite de Android:
JSONArray, JSONObject, JSONStringer și JSONToken izer. Începutul unui JSONArray este
marcat de prezența unei paranteze pătrate (“ [ ”) , JSONObject este reprezentat de o acoladă
(“ { ”) într -un nod JSON. Acest lucru ajută la decizia metodei ce trebuie folosite,
getJSONArray sau getJSONOb ject, bazat pe paranteza afișată la începutul nodului JSON.
Pentru a se putea efectua un apel de serviciu către server este necesar URL -ul către
acesta și metoda HTTP. Un nou client HttpClient este instanțiat, parametrii sunt ad ăugati la
adresa URL, în cazul în care există , toate acestea fiind urmate de solicitarea facută de către
client. Dacă aceasta a fost facută cu succes, un răspuns JSON este trimis înapoi de la server,
gata pentru a fi analizat.
Proiect de diplomă
20
Capitolul 4 ANALIZĂ ȘI PROIECTARE
4.1 Analiza aplicației
În ved erea dezvoltării și construirii aplicației s -au analizat programele disponibile în
momentul actual. Aplicațiile existente deja pe piața împart câteva detalii cu aplicația
dezvoltată, precum diferite funcționalități de bază, dar în rest au fost aduse numero ase
îmbunătățiri și funcționalități aplicației. Acest fapt a fost și din pricina ca este dezvoltat doar
pentru Android, unde i s -a accordat atenție deplină.
A fost luat în considerare și faptul că în ziua de azi, din ce în ce mai multă lume
folose ște smar tphone -uri, așadar s -a încercat crearea unei interfețe intuitive și cât mai ușor de
folosit de către oricine.
De asemenea s -a încercat pe cât se poate de mult ca aplicația să fie ușor de actualizat
și îmbunatațit, la nevoie, cu: locații, categorii de locații, funcționalități noi, etc.
4.2 Arhitectura Aplicației
Aplicația este dezvoltată pe modelul client – server [14] și folosește un server Apache,
o bază de date MySQL și fișiere PHP, pentru deschiderea și închiderea conecțiunii la baza de
date, de a semena și pentru inserarea, ștergerea, actulizarea și recuperarea informațiilor din
baza de date.
Pentru a reprezenta cât mai bine arhitectura aplicației, mai jos sunt ilustrate
următoarele diagrame, însoțite de explicații:
Diagrama de pachete
Diagrama de clase
Diagrama de implementare
Diagrama bazei de date
4.2.1 Diagrama de pachete
Diagrama de pachete reprezintă totalitatea pachetelor aplica ției. Aplicația este
compusă din cinci pachete:
com.cpop.travelerspocket.activity – care cuprinde toate acti vitățiile aplicației Android,
fiecare dintre acestea oferind UI
com.cpop.travelerspocket.maps – cuprinde toate clasele cu ajutorul cărora se
efectuează sarcini precum colectarea de informații pentru a oferi utilizatorului o hartă
și o rută.
com.cpop.travel erspocket.networking – din moment ce aplicația utilizează
comunicarea client -server, pachetul de rețea este folosit pentru conectarea la server,
pentru preluarea datelor și analizarea acestora folosind JSON.
com.cpop.travelerspocket.model – acest pachet co nține clase de entități
com.cpop.travelerspocket.views – cuprinde clasele personalizate pentru modificarea
blocurilor de UI inițiale.
com.cpop.travelers.pocket.fragments – conține fragmentele folosite pentru crearea
unei bucăți de UI
Capitolul 4 ANALIZĂ ȘI PROIECTARE
21
4.2.2 Diagrama de clase
Următoarea diagramă descrie clasele aplicației în ceea ce privește atributele, operațiile
și relațiile dintre acestea.
Din cauza unei diagrame de clase stufoase, în ceea ce privește num ărul de clase și
relații, unele asociații au fost omise din motive de claritate.
Figura 4 .1 Diagrama de pachete
Proiect de diplomă
22
Capitolul 4 ANALIZĂ ȘI PROIECTARE
23
Figura 4 .2 Diagrama de Clase
Proiect de diplomă
24
4.2.3 Diagrama de Implementare
Dispozitivul Android conține aplicația Android, iar utilizatorul se folosește de serverul
Apache, care oferă accesul la baza de date și la fișierele PHP, care sunt localizate pe un sistem
UNIX.
4.2.4 Diagrama Bazei de date
Scopul diagramei bazei de date este acela de a descrie structura tabelelor și relația
dintre acestea.
Figura 4 .3 Diagrama de Implementare
Figura 4 .4 Diagrama Bazei de date Figura 4.5 Diagrama de implementare
Capitolul 4 ANALIZĂ ȘI PROIECTARE
25
Relația dintre Categorii și Locații este de “unul -la-mai-mulți” (eng. one -to-many),
deoarece o categorie poate avea una sau mai multe locații.
4.3 Proiectarea aplicației
În vederea proiectării aplicației, ca prim pas a fost crearea diagramei Use Case prin
care s -a încercat acoperirea tuturor acțiunilor posibile pe care un utilizator le poate face cu
ajutorul aplicației.
Specificații Use Case
Use Case: Creare Cont
Descriere: Acest caz de utilizare descrie procesul de înregistrare a unui nou cont
Actori: Utilizatorul
Date: nume, adresa email, parola
Precondiții: Adre sa de email să nu fie deja existentă în baza de date
Postcondiții: Contul este creat, adresa de email este înregistrată in baza de date.
Scenariul de bază:
B1. Înregistrare
1. Cazul de utilizare începe în momentul în care utilizatorul lansează
aplicația .
2. Utilizatorul apasă butonul de “Înregistrare” din ecranul de start .
3. Sistemul deschide o nouă activitate cu câmpurile de text nume, adresă
email și parolă și un buton de înregistrare .
4. Utilizatorul completează datele necesare pentru înregistrare și apasă
butonu l de “Înregistrare” .
5. Sistemul trimite informațiile din câmpurile de text către server.
6. Server -ul verifică baza de date și trimite un răspuns sistemului aplicației.
Figura 4.5 Diagrama Use Case
Proiect de diplomă
26
7. Sistemul notifică utilizatorul că înregistrarea s -a făcut cu succes.
8. Cazul de utilizare se încheie.
Fluxuri Alternativ e (de eroare) :
A1. Câmpuri de text necompletate
În pasul cu numărul 5 din Scenariul de bază pentru Înregistrare, utilizatorul lasă unul
sau mai multe câmpuri goale (necompletate), așadar informația este invalidă.
1. Sistemul noti fică utilizatorul că unul din câmpuri este invalid. Eroarea
apare este afișată pentru câmpul lasat gol.
A2. Adresa de email nu respectă formatul corect (text + @ + domeniu)
În pasul cu numărul 5 din Scenariul de bază pentru Login, utilizatorul poate să
introducă o adresă de email cu un format greșit.
1. Sistemul notifică utilizatorul printr -un mesaj de eroare că adresa de email
introdusă este invalidă.
A3. Parola nu respectă formatul corect (trebuie să conțină între 7 și 16 caractere)
În pasul cu numărul 5 din Scenariul de bază pentru Login, utilizatorul poate să
introducă o parolă cu un număr mai mic/mare de caractere.
1. Sistemul notifică utilizatorul printr -un mesaj de eroare că parola introdusă
trebuie să conțină între 7 și 16 caractere.
A4. Adresa de email este deja stocată în baza de date
În pasul cu numarul 6 din Scenariul de bază pentru Înregistrare, adresa de email este
deja stocată în baza de date.
1. Server -ul trimite răspunsul către sistem.
2. Sistemul notifică utilizatorul că înregistrarea nu a avut succes din cauză ca
adresa de email există deja în baza de date.
Use Case: Login
Descriere: Acest caz de utilizare descrie procesul de autentificare
Actori: Utilizatorul
Date: adresă de email și parolă
Precondiții: Adresa de email trebuie să existe deja in baza de date și dispozitivul este
conecatat la internet.
Postcondiții: Utilizatorul este logat în aplicație.
Scenariul de bază:
B1. Login
1. Cazul de utilizare începe în momentul în care utilizatorul lansează
aplicația .
2. Aplicația afișează ecranul de star t format din: două câmpuri de text:
“Adresa Email” și “Parola”, butoanele de “Login” și “Înregistrare” și
caseta de bifat “Ramai Autentificat”.
3. Utilizatorul introduce datele necesare în câmpurile de text și apasă butonul
de login.
4. Sistemul trimite informaț iile din câmpurile de text către server.
5. Server -ul verifică baza de date și revine cu un răspuns către aplicație.
6. Sistemul redirectionează utilizatorul către hartă.
Capitolul 4 ANALIZĂ ȘI PROIECTARE
27
7. Cazul de utilizare se încheie.
Fluxuri alternative (de eroare):
A1. Câmpuri de text necom pletate
În pasul cu numărul 4 al Scenariului de bază pentru Login, utilizatorul lasă unul sau
mai multe câmpuri necompletate, deci informațiile sunt invalide.
1. Sistemul notifică utilizatorul că unul din câmpuri este invalid. Eroarea
apare este afișată pent ru câmpul lasat gol.
A2. Adresa de email și/sau parola este invalidă
În pasul cu numărul 5 din Scenariul de bază pentru Login, utilizatorul poate să nu fie
înregistrat în baza de date, sau parola poate să fie invalidă.
2. Sistemul notifică utilizatorul că unul din câmpurile “adresa email” sau
“parola” este greșit.
A3. Utilizatorul bifează casută “Ramai Autentificat”
În pasul cu numărul 3 din Scenariul de bază pentru Login, utilizatorul are opțiunea de
a bifa casuța “Ramai Autentificat”.
1. Sistemul o să țină utilizatorul logat în aplicație chiar și dacă acesta închide
aplicația. Singurul mod în prin care poate să se delogheze este din
activitatea: “Setari Cont”.
Use Case: Vizualizare hartă
Descriere: Acest caz de utilizare descrie procesul afișare a h ărții și a marcajelor locațiilor
stocate în baza de date.
Actori: Utilizatorul
Date: Poziția curentă a utilizatorului
Precondiții: Utilizatorul este este logat în aplicație, iar dispozitivul este conectat la internet și
are GPS -ul activat.
Postcondiții: Ut ilizatorul poate ve dea toate locațiile de pe hartă, vizualiza informații despre
aceastea și genera o rută pâna la locația dorită.
Scenariul de bază:
B1. Vizualizarea hărții
1. Cazul de utilizare începe după ce utilizatorul s -a logat cu succes.
2. Harta este afișată, în centrul acesteia este utilizatorul, pozitia acestuia fiind
găsită cu ajutorul GPS -ului.
3. Sistemul trimite o cerere server -ului.
4. Serverul returnează din baza de date cele mai apropiate locații stocate în
baza de date și le afișeaza pe hartă sub f orma de marcaje de diferite culori,
în funcție de categoria din care face parte locația respectivă.
5. Utilizatorul dă click pe un marcaj.
6. Sistemul afișează un buton în colțul din stânga jos al ecranului “Vezi
Informații”
7. Utilizatorul dă click pe butonul “Vez i Informații”.
8. Sistemul redirectionează utilizatorul la activitatea de “Vizualizare
Informatii locație”, unde sunt afișate informații precum numele, adresa,
Proiect de diplomă
28
numărul de telefon, programul de funcționare, rating -ul, o poziție pe hartă a
locației selectate și un buton de “Generare Rută”.
9. Utilizatorul dă click pe butonul “Generare Rută”.
10. Sistemul mărește harta, astfel încat aceasta acoperă întregul ecran și
afișează o rută albastră între doua marcaje, locația curentă și locația la care
dorește utilizatorul să a jungă. De asemenea sistemul afișeaza distanța in
kilometrii pâna la locație și un timp estimativ de parcurs pâna la aceasta
folosind mașina.
11. Cazul de utilizare se încheie.
Use Case: Accesare listă locații
Descriere: Acest caz de utilizare descrie procesu l afișare a listelor de locații în funcție de
categoria selectată.
Actori: Utilizatorul
Date: –
Precondiții: Utilizatorul este este logat în aplicație, iar dispozitivul este conectat la internet și
are GPS -ul activat.
Postcondiții: Utilizatorul poate ved ea listele cu locații, grupate pe categorii, poate cauta
locațiile după nume, poate vedea informații despre aceastea și genera o rută pâna la acestea.
Scenariul de bază:
B1. Vizualizarea listelor cu locații
1. Cazul de utilizare începe odată ce utilizatorul deschide meniul lateral.
2. Utilizatorul selectează una din cele cinci categorii afișate în meniu:
Restaurante, Baruri, Hoteluri, Locuri de vizitat sau Transport.
3. Sistemul trimite o cerere catre server cu categoria selectată de utilizator.
4. Server -ul returnea ză către sistem toate locațiile din categoria respectivă.
5. Sistemul afișează o lista cu locațiile returnate de către server și o bară de
căutare.
6. Utilizatorul dă click pe o locație din listă.
7. Sistemul redirectionează utilizatorul la activitatea de “Vizualiz are
Informatii locație”, unde sunt afișate informații precum numele, adresa,
numărul de telefon, programul de funcționare, rating -ul, o poziție pe hartă a
locației selectate și un buton de “Generare Rută”.
8. Utilizatorul dă click pe butonul “Generare Rută”.
9. Sistemul mărește harta, astfel încat aceasta acoperă întregul ecran și
afișează o rută albastră între doua marcaje, locația curentă și locația la care
dorește utilizatorul să ajungă. De asemenea sistemul afișeaza distanța in
kilometrii pâna la locație și u n timp estimativ de parcurs pâna la aceasta
folosind mașina.
10. Cazul de utilizare se încheie.
Fluxuri alternative :
A1. Utilizatorul folosește bara de căutare
După pasul 5 al Scenariului de bază al Vizualizări listelor cu locații, utilizatorul
introduce text în bara de căutare.
1. Dacă text introdus se regăsește în lista afișată precendent, doar locațiile ce
conțin textul vor rămâne afișate. În caz contrat nu se va afișa nimic.
2. Utilizatorul dă click pe o locație din listă.
Capitolul 4 ANALIZĂ ȘI PROIECTARE
29
3. Sistemul redirectionează utilizator ul la activitatea de “Vizualizare
Informatii locație”, unde sunt afișate informații precum numele, adresa,
numărul de telefon, programul de funcționare, rating -ul, o poziție pe hartă a
locației selectate și un buton de “Generare Rută”.
4. Utilizatorul dă clic k pe butonul “Generare Rută”.
5. Sistemul mărește harta, astfel încat aceasta acoperă întregul ecran și
afișează o rută albastră între doua marcaje, locația curentă și locația la care
dorește utilizatorul să ajungă. De asemenea sistemul afișeaza distanța in
kilometrii pâna la locație și un timp estimativ de parcurs pâna la aceasta
folosind mașina.
6. Cazul de utilizare se încheie.
Use Case: Modificare credențiale Cont
Descriere: Acest caz de utilizare descrie proce sul de modificare a informațiilor contului de
către utilizator.
Actori: Utilizatorul
Date: Nume, parolă veche, parolă nouă, confirmare parolă
Precondiții: Utilizatorul este este logat în aplicație, iar dispozitivul este conectat la internet și
are GPS -ul activat.
Postcondiții: Informațiile contului s unt actualizate și salvate în baza de date.
Scenariul de bază:
B1. Modificare credenți Cont
1. Cazul de utilizare începe odată ce utilizatorul selectează opțiunea “Setari
Cont” din meniul lateral al aplicației.
2. Sistemul redirectionează utilizatorul către ac tivitatea “Setari Cont”,
formată din patru câmpuri de text: nume, parolă veche, parolă nouă,
confirmare parolă și două butoane: “Salveaza Modificarile” și “Log Out”.
3. Utilizatorul completează datele necesare și apasă butonul “Salveaza
Modificarile”.
4. Sistemu l trimite o cerere cu informațiile din câmpurile text câtre server.
5. Baza de date este actualizată și server -ul trimite răspunsul catre sistem.
6. Un raspuns este afișat, pentru a inștiința utilizatorul ca actualizarea a avut
loc cu succes.
7. Cazul de utilizare se încheie.
Fluxuri Alternative (de eroare):
A1. Câmpuri de text necompletate
În pasul cu numărul 3 al Scenariului de bază destinat Modificărilor informa țiilor
contului, utilizatorul lasă unul sau mai multe câmpuri necompletate.
1. Sistemul notifică utiliz atorul că unul din câmpuri este invalid. Eroarea
apare este afișată pentru câmpul lasat gol.
A2. Introducerea unei parole noi, ce nu respectă formatul corect (trebuie să conțină
între 7 și 16 caractere)
În pasul cu numărul 3 din Scenariul de bază destin at Modificărilor informațiilor
contului, utilizatorul poate să introducă o parolă cu un număr mai mic/mare de caractere.
1. Sistemul notifică utilizatorul printr -un mesaj de eroare că parola introdusă
trebuie să conțină între 7 și 16 caractere.
Proiect de diplomă
30
A3. Introduc erea unei parole vechi incorecte
În pasul cu numărul 3 din Scenariul de bază destinat Modificărilor informațiilor
contului, utilizatorul introduce o parolă veche incorectă.
1. Sistemul notifică utilizatorul că modificarea parolei nu a avut loc, deoarece
parola veche introdusă este incorectă.
A4. Apăsarea butonului de “Log Out”
Odată cu afișarea activității utilizatorul poate să iși modifice credențialele, sau are
opțiunea de a se deloga din aplicație. Acest lucru face ca, în cazul în care utilizatorul a bi fat
casută “Ramai autentificat” când sa logat în aplicație, el să nu mai fie logat automat în
aplicație, cand acesta o deschide.
1. Sistemul deloghează utilizatorul din aplicație și il redirecționează pe acesta
la activitatea de login.
Capitolul 5 IMPLEMENTAREA
31
Capitolul 5 IMPLEMENTAREA
5.1 Mediul de dezvoltare
Mediul de dezvoltare folosit pentru aplicație este Android Studio, iar limbajul de
programare folosit în implementare este Java. Pentru realizarea bazei de date s -a folosit
MySQL, iar fișierele pentru accesarea și interogare a bazei de date au fost scrise î n PHP.
Sistemul de operare folosit a fost Windows 10.
5.2 Configurare
Primul pas în implementarea aplicației este crearea unui nou proiect în Android Studio
2.0. Pentru aceasta se deschide pr ogramul și din meniul Quick Start se poate deschide un
proiect existent, din lista de proiecte recente, se poate importa un proiect ce a fost dezvoltat în
alt IDE, precum Eclipse sau se poate crea un nou proiect cu un simplu click pe opțiunea Start
New And roid Studio Project, după aceasta se deschide fereastra din figura urm ătoare, unde
suntem nevoiți să introducem numele aplicației și domeniul companiei, aceasta împreună
formând numele pachetului, care este afișat sub cele doua câmpuri. Ca un ultim pas set ăm
calea unde vrem s ă fie salvat proiectul, după care putem da click pe Next.
Figura 5.1 Configurarea noului proiect
Fereastra deschisă după ce butonul Next este apasăt este destinată alegerii pe ce
platforme se dorește ca aplicația s ă fie implementată și API -ul Android cel mai mic pe care
aplicația poate rula. Cu cât acesta este mai mic, cu atât sunt acoperite mai multe dispozitive,
dar în același timp îi sunt limitate și funcționalitătile, deoarece nivelele joase de Android API
sunt folosite de dispoz itive Android destul de vechi și depreciate. Cu cât se alege un nivel de
API mai ridicat, crește numărul de funcționalități ce pot fi implementate, dar scade numărul
dispozitivelor ce pot rula aplicația. În cazul de față a m folosit API 18: Android 4.3
(JellyBean) deoarece acesta a fost lansat deja de 3 ani, iar conform programului Android
Studio, setând acest API ca fiind cerința minimă pentru a putea rula aplicația, acoperim 76.9%
din totalul dispozitivelor ce sunt active în Magazinul Google Play. Așadar s-a încercat găsirea
Proiect de diplomă
32
unui echilibru între numărul de dispozitive pe care poate rula aplicația și numărul de
funcționalități necesare pentru aceasta, iar API18 este cel mai potrivit. De asemenea s -a ales
implementarea doar pentru tablete și telefoane, deoa rece acestea sunt cele mai răspândite
dispozitive Android din ziua de azi.
Figura 5.2 Selectare dispozitive și API
După ce s -au ales dispozitivele pentru care se intenționează dezvoltarea aplicației și
API-ul minim necesar pentru rularea acesteia din l ista oferită de Android Studio, se poate da
click pe butonul Next care ne va direcționa către figura de mai jos. În această fereastră se
poate selecta una din activitățile predefinite in Android Studio, pentru a fi adaugată, odată cu
crearea proiectului. A ctivitatea adaugată în acest moment este activitatea inițială, care va fi
afișată prima dată, dupa inițializarea aplicației.
Android Studio ofer ă o listă de activități destul de mare printre care se numară: Login
Activity, Navigation Drawer Activity, Sc rolling Activity Settings Activity, Google Maps
Activity , se poate alege o activitate necompletată (eng. Blank) sau se poate opta pentru nici o
activitate de ad ăugat inițial, dar acestea pot fi adăugate și ulterior.
În cazul în care se alege o activitat e cu conținut, spre exemplu cea de Login, Android
Studio genereaza fișierul .xml, adică interfața activității cu toate câmpurile de text și
butoanele necesare pentru ca un utilizator să se poată loga în aplicație, dar și fișierul .class,
adică funcționalit atea activitații în care avem toate funcționalitățile câmpurilor de text și
Capitolul 5 IMPLEMENTAREA
33
butoanelor definite și implementate automat. Dar, dacă se dorește o altfel de implementare, se
poate alege o activitate goal ă, unde, la fel, se generează fișierele .xml și .class p entru
activitate, doar că acestea sunt goale, neavând nimic generat automat. În cazul de fața am ales
activitatea de login și am apăsat butonul Next.
Figura 5.3 Selectare Activitate
Ultima ferestră, marchează ultimul pas din crearea unui nou proiect și anume
introducerea unui nume pentru:
Activitate – numele fișierului .class
Șablon – numele fișierului .xml
Titlu – Titlul activității (Poate fi afișat în bara aplicației, dacă activitatea
conține una)
Proiect de diplomă
34
Figura 5.4 Denumire Activitate
5.3 Implementarea aplicației
Prima activitate afișată în aplicație, după pornirea acesteia de către utilizator este
activitatea de login. Din această activitate utilizatorul poate ajunge la activitatea principală,
unde este afișată harta, dac ă acesta are un c ont valid și se poate loga, în caz contrar își poate
crea un nou cont, cu ajutorul activității de înregistrare, către care este redirecționat în cazul
apăsării butonului “Inregistrare”.
Capitolul 5 IMPLEMENTAREA
35
Odată ce utilizatorul a introdus datele în câmpurile de login (adresa de email și
parola) , aplicați a trimite o cerere cu ajutorul librăriei Volley, cu datele că tre serverul pe care
se află fișierele PHP, cu ajutorul cărora, interogăm baza de date și verificăm dacă exist ă
utilizatorul în baza de date. În caz ca acesta exist ă, server -ul răspunde cu un mesaj JSON.
Aplicația interpretează mesajul, iar în cazul în care server -ul găsește utilizatorul în baza de
date și ne răspunde cu succes, ea redirecționează utilizatorul către activitatea principală a
aplicației, prin deschiderea acesteia cu ajutorul metodei startActivity() , oferită de Android
SDK.
În cazul în care utilizatorul nu are deja un cont creat, acesta are posibilitate a de a -și
face unul, după cum a fost menționat anterior. În activitatea de înregistrare, utilizatorul este
nevoit să își introducă numele, o adresă de email validă ( text + @ + domeniu) și o parolă
validă (între 7 și 16 caractere). Prima acțiune realizată de aplicație după ce utilizatorul a
introdus datele și a apăsat butonul de înregistrare este verificarea respectării unui format valid
pentru adresa de email folosind un șablon ( emailPattern = "[a -zA-Z0-9._-]+@[a -z]+\\.+[a-
z]+") și daca parola se încadreaz ă în limita de caractere, iar în cazul nerespectării acestora
aplicația notifica utilizatorul de acest lucru, prin afișarea unui mesaj de eroare.
Dacă sunt respectate formatele, aplicația trimite o cerere către server, dar de data
această, la un alt fiși er PHP, care verifică dacă există deja un utilizator cu adresa de mail
introdusă , prin metoda emailAvailable() , descrisă mai jos , iar dacă nu există nici un cont cu
adresă respectivă, creează unul cu ajutorul metodei registerUser() și trimite un răspuns de
succes către aplicație. În cazul în care deja există un utilizator cu adresa de mail respectivă,
trimite un răspuns de eroare către aplicație.
Figura 5. 5 Interfață Login Figura 5.6 Interfață Înregistrare
Proiect de diplomă
36
function emailAvailable(){
global $con, $email;
$statement = mysqli_prepare($c on, "SELECT * FROM user WHERE email =
?");
mysqli_stmt_bind_param($statement, "s", $email);
mysqli_stmt_execute($statement);
mysqli_stmt_store_result($statement);
$count = mysqli_stmt_num_rows($statement);
mysqli_stmt_close($statement);
if ($count < 1){
return true;
}else {
return false;
}
}
Metoda descrisă mai sus folosește variabilele con și email, care au primit valori
înaintea executării metodei (con = conexiunea la baza de date, email = adresa de email) și
formeaz ă o inte rogare pe care o va trimite bazei de date, pentru a verifica dacă există adresa
de email în baza de date. După ce interogarea are loc, în metodă se salvează rezultatele și se
află num ărul acestora, în cazul în care adresa de email este deja în baza de dat e, numărul
rezultatelor va fi egal cu 1 și metoda returnează fals, în caz contrar returnează true, adresa de
email nu există în baza de date.
În cazul în care contul a fost cr eat cu succes aplicația returnează utilizatorul înapoi la
activitatea de login.
Odată logat în aplicație, este a fișată harta și scurt timp după afișarea acesteia este citită
poziția utilizatorului, cu ajutorul API -ului oferit de cei de la Google
FusedLo cationProviderApi și are nevoie de următoarea metodă, pentru a “construii” clientul
google API, care ne permite accesarea poziției utilizatorului :
protected synchronized void buildGoogleApiClient() {
mGoogleApiClient = new GoogleApiClient.Bui lder(this)
.addConnectionCallbacks(this)
.addOnConnectionFailedListener(this)
.addApi(LocationServices.API)
.build();
}
Avem nevoie de poziția utilizatorului, pentru a putea mării și muta hartă exact pe
poziția acestuia, pentru ai ușura acestuia găsirea locațiilor aflate în vecinătatea sa.
În timpul animației hărții aplicația trimite o cerere către server, cu ajutorul librăriei
Volley, prin care se returnează într -un format JSON toate locațiile din baza de date, aflate în
vecinătatea utilizatorului și sunt afișate pe harta sub forma de marcaje de diferite culori, în
funcție de categoria din care fac parte (marcaj roșu – restaurant, marcaj verde – bar, marcaj
mov – hotel , marcaj galben – obiectiv turistic și marcaj albastru – transport). Acest lucru a
Capitolul 5 IMPLEMENTAREA
37
fost posibil datorită API -ului Google Maps care ne permite modificarea formei și culorii
marcajului inițial oferit de aceștia printr -o simpla comandă:
BitmapDescriptorFact ory.defaultMarker(BitmapDescriptorFactory.HUE_ BLUE ),
unde blue poate fi una din cele zece culori (Azure, Blue, Cyan, Green, Magenta, Orange, Red,
Rose, Violet, Yellow) declarate ca și constante in pachet.
În același timp cu afișarea hărții, este încarca t meniul lateral al aplicației, de unde se
pot accesa listele cu locații sau setările contului. Acesta a fost implementat cu ajutorul
activității ajutătoare din Android Studio, Navigation Drawer Activity, care genereaz ă automat
codul pentru interfața (fiși erul .XML) și funcționalitatea meniului (fișierul .class).
În interfața meniului s -au schimbat iconițele inițiale cu unele potrivite pentru fiecare
categorie. Acest lucru s -a realizat prin redimensionarea unei imagini vectoriale de înalte
calitate în cin ci rezoluții diferite pentru a asigura o calitate ridicată indiferent de rezoluția
dispozitivului pe care ruleaza aplicația. Acestea sunt categorizate dupa densitatea de pixeli a
ecranului:
ldpi – 120 dpi – imaginea a fost redimensionată la 36×36 pixeli
mdpi – 160 dpi – imaginea a fost redimensionată la 48×48 pixeli
hdpi – 240 dpi – imaginea a fost redimensionată la 72×72 pixeli
xhdpi – 320 dpi – imaginea a fost redimensionată la 96×96 pixeli
xxhdpi – 480 dpi – imaginea a fost redimensionată la 144×144 pi xeli
xxxhdpi – 640 dpi – imaginea a fost redimensionată la 192×129 pixeli
[15] Pentru redimensionarea imaginilor s -a folosit Android Asset Studio , care a
redimensionat imaginea inițială, in toate cele cinci rezoluții simultan.
Figura 5. 7 Harta Figura 5. 8 Meniul Aplicației
Proiect de diplomă
38
Din meniul aplicației se poate accesa una din listele de locații prin apăsarea unuia
dintre butoanele din meniu.
Odată cu selectarea unei opțiuni, prin apăsarea unui buton, se deschide un fragment în
care este afișată lista cu locații. Un fragment este de obicei folosit ca o parte UI -ului, a unei
activități și contribuie la aspectul activității. Avantajul de a folosi un fragment față de o
activitate este acela c ă pentru o activitate putem avea mai m ulte fragmente. În aplicație nu
doar listele sunt implementate sub formă de fragmente, ci și harta. Acest lucru a fost
implementat așa pentru a reduce apelurile și cererile inutile către server și baza de date,
deoarece aceastea ar îngreuna extrem de mult aplicație, creând extrem de mulți timp morți, în
care utilizatorul, nu poate folosi aplicația deoarece aceasta este ocupată cu trimiterea și
recuperarea de informații de la server. Cu ajutorul fragmentelor, hartă este pornită odat ă cu
meniul și rămâne desc hisă atât timp cât rămâne și aplicația deschisă. Restul fragmentelor și
activităților fiind afișate “deasupra” acesteia.
Fiecare opțiune selectată, trimite o cerere către server cu ajutorul unui fișier PHP, care
recuperează din baza de date locațiile ce fac parte din categoria selectată. Din baza de date
sunt luate numele, adresa, descrierea, ratingul, programul și latitudinea și longitudinea pentru
fiecare locație, dar în fiecare element din listă este afișat doar numele și adresă locației, restul
elemen telor fiind salvate pentru a putea fi folosite în activitatea viitoare, eliminând astfel o
apelare în plus a server -ului.
Cu ajutorul uneltelor asigurate de Android SDK putem genera automat codul necesar
pentru afișarea unei liste, dar aceasta ne permite decât afișarea unei singure linii de text pentru
fiecare element al listei . Pentru a putea afișa și adresa locației este nevoie de implementarea
unui ViewHolder personalizat în care definim cele două câmpuri și un Adaptor personalizat,
dar care îl extinde pe cel inițial (BaseAdapter), pentru acest ViewHolder nou.
În codul de mai jos avem definirea celor două câmpuri de text, care vor fi afișate în
fiecare element al listei.
public CustomViewHolder(View v){
name = (TextView) v.findViewById(R. id.title_item);
address = (TextView) v.findViewById(R.id.address_item);
}
Cum a fost menționat anterior, pentru ca ViewHolder -ul personalizat să poată să fie
utilizat și afișat în aplicație trebuie implementat un Adaptor personalizat. O pa rte din codul
acestuia fiind mai jos:
public CustomListViewAdapter(Activity context, List<Items> listItems) {
mContext = context;
this.listItems = listItems;
this.filteredlistItems = listItems;
this.inflater = (LayoutInflater) context.getSystemService(
Context.LAYOUT_INFLATER_SERVICE);
}
Capitolul 5 IMPLEMENTAREA
39
De asemenea odată cu implementarea unui nou Adaptor, suntem nevoiți să
suprascriem și metoda onClick() a adaptorului inițial, pentru a se potrivi nevoilor noastre.
@Override
public void onClick(View arg0) {
Bundle bundle = new Bundle();
Intent intent = new Intent(mContext, LocationDetails.class);
bundle.putString("name", (listItems.get(position).getName()));
bundle.putString("description", (listItems.get(position).getDescription()));
bundle.putString("address", (listItems.get(position).getAddress()));
bundle. putString("rating", (listItems.get(position).getRating()));
bundle.putString("open_time", (listItems.get(position).getOpen_time()));
bundle.putString("close_time", (listItems.get(position).getClose_time()));
bundle.putDouble(" latitude", (listItems.get(position).getLatitude()));
bundle.putDouble("longitude", (listItems.get(position).getLongitude()));
intent.putExtras(bundle);
mContext.startActivity(intent);
}
Suprascrisă metoda onClick() , care are loc în momentul în care utilizatorul dă click pe
unul din elementele listei, grupează toate datele despre elementul selectat într -un pachet numit
Bundle. În acest mod putem transmite datele din fragmentul listei în acvititatea viitoare care
este deschisă la sfarșitul metodei prin startActivity() .
În adaptorul personalizat, a fost implementată de asemenea și o funcție de căutare
pentru a facilita găsirea unei locații specifice. Pentru aceasta a fost nevoie de implementarea
unei noi cla se, CustomFilter, care extinde filtrul inițial și a cărui cod îl avem mai jos:
class CustomFilter extends Filter{
@Override
protected FilterResults performFiltering(CharSequence constraint){
FilterResults results = new FilterResults();
if(constraint != null && constraint.length() > 0){
constraint = constraint.toString().toUpperCase();
List<Items> filters = new ArrayList<Items>();
for(int i=0;i<filteredlistItems.size( );i++){
if(filteredlistItems.get(i).getName().toUpperCase().contains(constraint)){
Items item = new Items(filteredlistItems.get(i)
.getName(),filteredlistItems.get(i).getAddress ());
filters.add(filteredlistItems.get(i));
}
}
results.count = filters.size();
results.values = filters;
Proiect de diplomă
40
}else{
results.count = fil teredlistItems.size();
results.values = filteredlistItems;
}
return results;
}
@Override
protected void publishResults(CharSequence constraint, FilterResults results) {
listItems = (List<Items>) results.values;
notifyDataSetChanged();
}
Metoda reverifică câmpul de căutare la fiecare caracter introdus/șters în acesta. Pentru
a asigura o căutare fără probleme, caracterele introduse sunt transformate în majuscule,
împreună cu toate numele locațiilor. În acest fel se creează uniformitate între formatul textului
introdus pentru căutare și formatul textului în care se execută căutarea. Toate elementele care
conțin textul introdus în câmpul de căutare sunt copiate în lista de elemente filtrate, după care
află numărul de elemente din listă. Acestea două sunt returnate, iar în metoda suprascrisă
publishResults() acestea sunt publicate în lista originală, care este reafișată în fragment.
Odată selectată o locație, metoda onClick() direcționează utilizatorul către urmatoarea
activitate, unde sunt afișate câteva informații despre locația selectată. Informațiile transmise
prin pachet cu ajutorul metodei onClick() sunt afișate pe ecran, iar latitudinea și longitudinea
sunt folosite pen tru a afișa o previzualizare a poziției pe harta a locației.
5.9 Fragment Listă 5.10 Căutare locație
Capitolul 5 IMPLEMENTAREA
41
În același timp cu afișarea i nterfeței activității, sistemul, folosind un fir de execuție în
fundal, accesează serviciul Directions, oferit de Google Maps API. Aceasta se face prin clasa:
private class ParserTask extends AsyncTask
<String, Integer, List <List <HashMap <String,
String>>>>
Cu ajutorul acestei clase, aplicația trimite o cerere către URL -ul de mai jos, unde
origin este numele străzii sau coordonatele geografice ale pozi ției utilizatorului, citite ant erior,
destination este numele străzii sau coordonatele geografice ale poziției locației selectate , iar
mode selectează metoda de parcurgere a distanței, cu mașina, pe jos sau transport în comun.
http://maps.googleapis.com/maps/api/directions/json?origin="+origin+"&destination="+desti
nation+"&sensor=false&mode=%22WALKING%22
Serviciul Directions, returnează un răspuns JSON, cu adresa de start și cea finală, iar
fiecare schimbare de direcție necesară este grupată într -un pachet, unde sunt înregistrate
coordonatele poziției de start de start ( start_location ), distanța care tre buie parcursă, timpul
mediu în care aceasta poate fi parcursă și sfărșitul locației ( end_location ). Dup ă sfarșitul
locației este afișat urmatorul pachet de coordonate în care este descrisă calea până la
urmatoarea schimbare de direcție. Deci, ruta este împ ărțită în mai multe pachete, fiecare
dintre acestea fiind specifice pentru o stradă. Pentru a întelege mai ușor răspunsul JSON oferit
de serviciul celor de la google, avem mai jos codul returnat pentru un pachet:
Response
{
"geocoder_stat us" : "OK",
"partial_match" : true,
"place_id" : "ChIJ8YWMWnz4wokRCOVf1CcJCbY" ,
"types" : [ "street_address" ]
}
],
"routes" : [
{
"bounds" : {
"northeast" : {
"lat" : 40.8171321 ,
"lng" : -73.99449150000001
},
"southwest" : {
"lat" : 40.7416627 ,
"lng" : -74.0728354
}
},
"copyrights" : "Map data ©2015 Google" ,
"legs " : [
{
"distance" : {
Proiect de diplomă
42
"text" : "9.7 mi" ,
"value" : 15653
},
"duration" : {
"text" : "25 mins" ,
"value" : 1480
},
"end_address" : "1 MetLife Stadium Dr, East Rutherford, NJ 07073, USA" ,
"end_location" : {
"lat" : 40.814505 ,
"lng" : -74.07272910000002
},
"start_address" : "75 Ninth Ave, New York, NY 10011, USA" ,
"start_location" : {
"lat" : 40.7428759 ,
"lng" : -74.00584719999999
},
"steps" : [
{
"distance" : {
"text" : "440 ft" ,
"value" : 134
},
"duration" : {
"text" : "1 min" ,
"value" : 34
},
"end_location" : {
"lat" : 40.7422925,
"lng" : -74.004457
},
"html_instructions" : "Turn \u003cb \u003eright \u003c/b \u003e at the 1st cross street onto
\u003cb \u003eN inth Ave \u003c/b \u003e" ,
"maneuver " : "turn -right" ,
"polyline" : {
"points" : "intwFz~tbMVN" },
"start_location" : {
"lat" : 40.7428759 ,
"lng" : -74.00584719999999
},
"travel_mode" : "DRIVING"
După cum se poate observa din răspunsul de mai sus , serviciul returnează și distanța
între poziția de start și pozitia finală a fiecărui pachet, dar și timpul necesar pentru ca acesta să
fie parcurs în modul de transport selectat.
Așadar pe lângă generarea unei rute către locația selectată de către utilizator, aplicația
îi ofer ă acestuia distanța pâna la ea și un timp aproximativ în care distanța poate fi parcursă
Capitolul 5 IMPLEMENTAR EA
43
Rezultatul returnat de către serviciu, este parcurs de către aplicație tot în interiorul
clasei ParserTask , cu ajutorul metodei suprascrise:
onPostExecute(List<L ist<HashMap<String, String>>> routes)
Metoda parcurge răspunsul JSON și stochează, latitudinea și longitudinea fiecărui
pachet intr -un HashMap<> , care la rândul lor sunt stocate într -o listă sub formă de puncte.
Odată cu terminarea parcurgerii răspunsului, metoda atribuie o grosime și o culoare mulțimii
de puncte, care acum formează o polilinie, prin comenzile:
polyLineOptions.addAll(points);
polyLineOptions.width(10);
polyLineOptions.color(Color.BLUE);
Așadar ruta este generată în fundal când activitatea afișare a detaliilor locației este
deschisă, dar doar în momentul în care utilizatorul apasă butonul “Generare Ruta”, aceasta
este afișata pe hartă. Harta, la rândul ei este mărită, pentru a facilita urm ărirea rutei.
Ultima opțiune din meniul aplicației redirecționează utilizatorul către pagina de setări.
Aici utilizatorul poate să modifice și actualizeze datele sau să se delogheze din aplicație.
Activitatea este formată dintr -un textView , prin care este afișată adresa de email a
utilizatorului și patru câmpuri de text, dedicate : numelui, parolei vechi, noii parole și pentru
ca aceasta trebuie sa fie confirmată, aceasta trebuie sa fie introdusă incă o dată la fel și in
Figura 5.11 Detalii Locație Figura 5.12 Harta după
generare rutei
Proiect de diplomă
44
câmpul de confirmar e parolă. La baza activității se află două butoane, “Salveaza
Modificarile”, care trimite cererea de modificare către server și butonul de “Log Out”, care
este utilizat în cazul în care utilizatorul nu mai vrea să fie autentificat în aplicație automat, în
cazul în care a bifat casuța “Ramai Autentificat” din activitatea de login.
Pentru ca, după apăsarea butonului “Salvaza Modificarile” cererea de actualizare a
bazei de date cu noile valori introduse să aiba loc, sunt făcute câteva verificări . În prima
verificare aplicația se asigură ca formatul pentru noua parolă introdusă este respectat (numărul
de caractere intoruduse este între 7 și 16). Dacă aceasta este îndeplinită, aplicația verifică dacă
noua parolă introdusă se potrivește cu parola in trodusă în câmpul de confirmare. Am adaugat
și acest câmp pentru a elimina posibilele erori umane, deoarece de nenumărate ori utilizatorii
introduc textul extrem de repede, iar din neatenție aceștia pot greșii unul sau mai multe
caractere. Dacă am avea doa r un câmp destinat actualizării parolei, aceștia introducând un
caracter greșit la actualizare, în momentul în care ar încerca să se logheze în aplicație, ei ar
introduce parola care ei cred că au actualizat -o, dar aceasta ar fi invalidă, deoarece la
actualizare au introdus un caracter gresit .
Dacă ambele cerințe sunt îndeplinite aplicația trimite o cerere cu noile date către
server, care urmează să interogheze baza de date. Compararea textului introdus în câmpul
destinat parolei vechi cu parola stocată în baza de date se face între server și ba za de date,
pentru a se elimina stocarea parolei curente în aplicație, aceasta fiind ușor de exploatat.
Server -ul așadar preia datele transmise de către aplicație și interoghează baza de date
pe baza adresei de email și a parolei vechi. Dacă parola vech e trasmisă se regăsește în baza de
date pentru a dresa de email trasmisă noua parolă îi va prelua locul, în caz contrar serverul va
răspunde cu un mesaj de eroare.
Figura 5.13 Setări Cont Figura 5. 14 Notificare
Modificări Salvate
Capitolul 5 IMPLEMENTAREA
45
Aplicația primește răspunsul de la server, îl intrepretează, iar în cazul în care operația
actualizare a avut succes, înstiințează utilizatorul că datele i -au fost actualizate, iar în caz
contrar afișează un mesaj de eroare.
În aplicațiile Android activitățile sunt formate din doua fișiere. Unul conține
funționalitățile, metodele și funcțiile a cestora. Acest ea sunt fisiere java .class grupate in
pachete, iar interfața activităților este implementată în fișiere .xml, grupate în șabloane (eng.
layouts).
Modificarea interfeței activităților in Android Studio se poate realiza în două moduri:
Text: Modificarea codului din fișierele xml
Design: Selectarea elementelor din lista de elemente cu dublu -click și
editarea detaliilor acestora din meniul “Properties”
Orice modificare facută în meniul de proprietați se transformă în cod generat automat
în fișierul xml. Aceasta se întamplă și invers în cazul în care se alege modificarea interfeței cu
ajutorul codului, nu cu ajutorul tab-ului “Design”
La începutul fișierului xml este necesară notarea versiunii de xml și stilul de codificare
folosit. După acestea se notează șablonul folosit, care poate sa fie unul din cele trei specificate
în capitolul 3, alaturi de namespace -ul și uneltele folosite, care sunt oferite de catre Android
SDK. Iar in final trebuie specificat contextul/activitatea pentru care este destinat fișierul xml.
<?xml version= "1.0" encoding= "utf-8"?>
<RelativeLayout
xmlns: android ="http://schemas.android.com/apk/res/android"
xmlns: tools ="http://schemas.android.com/tools"
android :layout_width= "match_parent"
android :layout_he ight= "match_parent"
tools :context= ".com.cpop.orasulmeu.RegisterActivity"
Mai jos avem secvența de cod necesară pentru a stiliza
câmpul de text destinat introducerii numelui în activitatea de
înregistare:
<EditText
android:layout_width= "wrap_content"
android:layout_height= "wrap_content"
android:id="@+id/etName"
android:layout_alignParentTop= "true"
android:layout_alignParentLeft= "true"
android:layout_alignParentStart= "true"
android:layout_marginTop= "44dp"
android:layout_alignParentRight= "true"
android:layout_alignParentEnd= "true"
android:hint="Nume"
android:textColor= "@color/white" />
Fiecare element din pagină este înc apsulat într -o
metodă, unde sunt scrise toate proprietățile de stilizare destinate acestuia, precum lungime,
lățime, id (care sunt obligatorii), însoțide de cele folosite la alinierea elementului. Figura 5.15 Activitatea de
Inregistrare, vazută din
editorul de Design al
Android Studio
Proiect de diplomă
46
5.4 Implementarea bazei de date
Pentru implementarea baz ei de date s -a folosit phpMyAdmin, un instrument gratuit și
open -source scris în PHP și destinat pentru administrarea bazelor de date MySQL cu ajutorul
unui navigator web. Crearea bazei de date este posibilă în doua moduri, utilizând interfața
programului myPHPAdmin, sau prin cod.
Am decis să folosesc interfața pentru a creea baza de date, deoarece, după părerea
mea, acesta este cel mai ușor mod de implementare, mai ales că aplicația nu necesită o bază
de date extrem de mare și complicată, ci doar trei s imple tabele în care sunt stocați utilizatorii,
locațiile și categoriile.
După creearea bazei de date și configurarea tabelui ca și în figura xyz, tabelul este
salvat, iar programul ne confirmă crearea tabelului și afișează codul folosit pentru crearea și
configurarea acestuia. Deci, interfața nu a făcut altceva decât sa ne ajute cu configurarea și să
genereze codul pentru creearea tabelului.
Figura 5. 16 Crea re tabel LOCATII
Codul afișat de program dupa crearea și configurarea tabelului:
CREATE TABLE `database `.`locatii ` (
`id_locatie` INT( 11 ) NOT NULL ,
`nume` VARCHAR ( 40 ) NOT NULL ,
`descriere` VARCHAR ( 40 ) NOT NULL ,
`adresa` VARCHAR ( 40 ) NOT NULL ,
`rating` TINYINT ( 4 ) NOT NULL ,
`open_time` TIME NOT NULL ,
`close_time` TIME NOT NULL ,
`latitudine` DOUBLE NOT NULL ,
`longitudine` DOUBLE NOT NULL ,
`id_categorie` TINYINT ( 5 ) NOT NULL ,
PRIMARY KEY ( `id_locatie` )
) ENGINE = MYISAM
Principul prin care a fost creat tabelul de mai sus, l -am aplicat și pentru restul tabelelor
din baza de date. După cum a fost menționat mai anterior, aplicația are în total doar trei tabele
în baza de date, dar fiecare având rolul său specific.
47
Utilizatori este un t abel care conține id_utilizator, nume, email și parola. El este cel
care se ocupa de stocarea utilizatorilor și adatelor acestora.
id_ultizator – index -ul pentru tabela utilizatorilor – Primary Key
nume – numele utilizatorului
email – adresa de email a utilizatorului
parola – parola utilizatorului
Locatii conține locațiile și informațiile despre acestea în următoarele coloane:
id_locatie – index -ul pentru ordonarea locațiilor – Primary Key
nume – numele locației
descriere – descrierea/numărul de telefon a locației
adresa – adresa locației
rating – rating -ul locației, stocat intr -un TinyINT
open_time – ora de deschidere a locației
close_time – ora de închidere a locației
latitudine – latitudinea poziției la care se află locația
longitudine – longitudinea poziției la care se află locația
id_categorie – folosită pentru a grupa locațiile pe categorii – Foreign
Key
Categorii, după cum îi sugerează numele, conține categoriile în care sunt grupate
locațiile din baza de date. Acesta conține doar două câmpuri:
id_categorie – index -ul pentru ordonarea categ oriilor – Primary Key
categorie – Restaurant / Bar / Hotel / Obiectiv Turistic / Transport
Proiect de diplomă
48
Capitolul 6 TESTARE ȘI VALIDARE
Ca urmare a finalizării programului descris în capitolul anterior, urmatorul pas este
testarea aplicației, pentru a ne asigura că aplicația se ridică la standardele impuse și nu exista
eventuale probleme de funcționalitate sau interfață, care să diminueze calitatea aplicației.
6.1 Acoperire Testare
În tes tarea aplicației s -au avut în vedere acoperirea următoarelor arii și caracteristici:
Login/Logout
Rămânere Autentificat
Creare cont
Validări câmpuri text
Interfață
Corectitudine text afișat
Integrare Google Map
Corectitudine afișare marcaje locații
Funcționalitate adaptor personalizat
Funcționalitate căutare locați i
Abilitate modificare credențiale
Corectitudine interacționare cu server -ul și cu baza de date
Performanță aplicație
Securitate
Compatibilitate
Pentru acoperirea tutoror ariilor și caracteristicilor aplicația a fost testată folosind
numeroase metode de testare descrise în detaliu mai jos.
6.2 Testare Unitară
Termenul de “testare unitară” se referă la testarea individuală a unor unități separate
dintr -o aplicație. În sistemele bazate pe POO, aceste unități sunt de cele mai multe ori clase
sau metode, sau în cazul aplicațiilor android pot fi și activități. Acest tip de testare se execută
de obicei pe parcursul implementării aplicației. În momentul în care este adaugată o noua
metodă, clasă, funcționalitate sau se modifică ceva în interfața aplicației, după implementarea
acesteia pe domeniul local, aceasta trebuie testată, pentru a ne asigura că funcționalitatea ei se
ridică la standardele impuse și nu inhibă funcționalitățile implementate anterior. Așadar de
fiecare dată când este adăugat ceva nou în ap licație, se rezervă o perioadă de timp destinată
testării acelei unități, de aici venind și numele de testare unitară. Doar după ce știm exact că
noua funcționalitate funcționeaza corect, se aplică modificările în aplicația generală.
Cu ajutorul testăr ii unitare prevenim un număr mare de probleme ce ar fi descoperite
după finalizarea proiectului, deoarece majoritatea acestora sunt găsite și remediate înca din
faza de implementare a fiecărui element.
Capitolul 6 TESTARE ȘI VALIDARE
49
Așadar după implementarea fiecărui element definitor iu pentru aplicație, mi -am
rezervat o perioadă fixă de timp în care am testat funcționalitatea și interfața acestuia, separat
de restul aplicației pentru a ma asigura că nu există probleme în modul în care a fost
implementat și doar dacă nu găseam probleme , elementul era unit cu restul aplicației. În cazul
în care se gaseau probleme, elementul era diagnosticat, modificat și testat până în momentul
în trecea testele și putea fi implementat în aplicație.
6.3 Testarea de regresie
Testarea de regresie const ă în retestarea părților neschimbate ale aplicației, dar care au
legatură cu o parte recent modificată a acesteia. Cazuri le de testare sunt re -executate, cu
scopul de a verifica dacă funcționalitatea anterioară a aplicației este aceeași și dacă
modificăril e noi nu au introdus probleme, odată ce acestea au fost implementate. Această
testare poate fi efectuată cand există o schimbare semnificativă în funcționalitatea aplicației
sau chiar și pentru o mica modificare.
Este verificat faptul că problemele, dacă există sunt fixate, iar caracteristicile recent
adăugate nu au creat probleme în versiunea anterioară a aplicației. Atunci când se execută
acest teste, se verifică faptul că funcționalitatea existentă este conform asteptărilor și că noile
modificări nu au introdus nici un defect de funcționalitate sau design, care funcționau
conform asteptărilor înainte de schimbare.
6.4 Testarea domeniu lui
Testarea domeniului este una dintre cele mai frecvent practicate tehnici de testare.
Esența testării domeniului este prelevarea filtarea stratificată a unui număr relativ mic de teste
dintr -un bazin foarte mare de teste potențiale [16].
În testarea domeniului, partiționăm domeniul (aplicația), în mai multe subdomenii
(clase de echivalența), iar apoi se execută te ste folosind valori din fiecare subdomeniu. O
clasă de echivalență poartă propria sa semnificație atunci când se efectuează teste de domeniu.
Diferitele feluri a unei clase de echivalența sunt:
Echivalență intuitivă
Echivalență specificată
Echivalență sub iectivă
Echivalență pe bază de risc
Pentru aplicația aflată în discuție această tehnică de testare a fost folosită predominant
pentru testarea modului în care se afișează informația recuperată din baza de date și modul de
trimitere a cererii către server , urmat de interogarea bazei de date.
Am folosit această tehnică deoarece în baza de date există un numar destul de mare de
înregistrări și ar dura extrem de mult pentru ca fiecare înregistrare să fie testată separat.
Așadar din toate înregistrările am a les atent un număr modic de înregistrări, care au fost
testate. Mai jos sunt câteva din înregistrările folosite, alături de scopul pentru care au fost
alese pentru a fi testate.
Proiect de diplomă
50
Tabel 6.1
ID Nume Adresă Telefon Rating Program Latitudine Longitudine Categorie
1 Nobori
Japanese
Restaurant Strada
Plopilor
numerele
57-62 0364
144 626 3 10:00
–
23:00 46.762619 23.556746 Restaurant
31 Hemmingway
Bar Strada
Sextil
Puscariu
numarul 9 +40754
565 828 5 16:00
–
03:00 46.771451 23.588587 Bar
51 Hampton by
Hilton B-dul 21
Decembri
numarul
67 0372
725 566 4 Non
Stop
46.776052
23.601035 Hotel
73 Salina Turda Aleea
Durgaului
numarul 7,
Turda 0364
260 987 3 09:00
–
16:00
46.589095 23.787938 Obiectiv
Turistic
91 Gara Cluj –
Napoca Piata Garii
numerele
2-3 0264
433 647
2 Non
Stop 46.784137 23.585074 Transport
65 Hotel Opal Strada
Constantin
Brancusi
numerele
148-152 0264
403 136 2 Non
Stop 46.760251 23.613331 Hotel
75 Muzeul
National de
Istorie a
Transilvaniei Strada
Constantin
Daicoviciu
numarul 2 0264
595 677 3 10:00
–
16:00 46.771532
23.58659
Obiectiv
Turistic
76 Parcul Central Parcul
Central 3 Non
Stop 46.76889 23.580347 Obiectiv
Turistic
Înainte de a menționa de ce a fost aleasă fiecare înregistrare vom explica ce reprezintă
fiecare coloană:
ID – Id-ul înregistrării din baza de date
Nume – Numele locației
Adresă – Adresa locației
Telefon – Numărul de telefon
Rating – Nota fiecărei locații, primită de la utilizatori
Program – Programul de funcționare al locației (În baza de date este stocat in
două coloane diferite open_time și close_time)
Latitudine – Latitudinea poziției la care se află locația respectivă
Longitudine – Longitudinea poziției la care se află locația respectivă
Categorie – categoria în care se află locația (în baza de date este stocată sub
formă de id și face legatura cu tabelul Categorii)
Capitolul 6 TESTARE ȘI VALIDARE
51
Înregistrările cu id -urile 1, 31, 51, 73 și 91 au fo st selectate pentru testare deoarece
acestea sunt primele înregistrări din fiecare categorie. Cu ajutorul acestora am testat
corectitudinea afișării marcajelor pe hartă, dar și funcționalitatea serverului pentru interogarea
bazei de date și extragerea datelor necesare pentru popularea listelor de locații grupate pe
categorii.
Înregistrarea cu id -ul 65 din baza de date a fost selectată pentru testare deoarece
numele străzii unde se află locație respectivă conține cele mai multe caractere și anume 43.
Așadar am folosit înregistrarea pentru a testa o parte din interfa ța aplicației și anume modul în
care este afișat numele străzii în lista cu locații și în activitatea în care sunt afișate informațiile
despre locație, în cel mai extrem caz.
Figura 6.1 Testare Culoare Marcaje
Proiect de diplomă
52
Figura 6.2 Testarea afișări
textului din câmpul destinat
numelui străzii în Lista Figura 6.3 Testarea afișări textului din
câmpul destinat numelui străzii în
activitatea de detalii
Figura 6.4 Testarea afișări textului din
câmpul destinat numelui locației în listă
Figura 6.5 Testarea afișări textului din
câmpul destinat numelui locației în
activitatea de detalii
Capitol ul 6 TESTARE ȘI VALIDARE
53
Înregistrarea cu id -ul 75 din baza de date a fost selectată pentru testare aproximativ din
același motiv ca și înregistrarea precedente, doar că de dat a aceasta variabila testată este
numele locației, acesta avand în total 42 de caractere. La fel ca și testul precendent, în acest
mod am testat modul de afișare a textului pentru nume în lista și în activitatea unde sunt
afișate detaliile locației, în cel mai extrem caz.
Înregistrarea cu id -ul 76 din baza de date a fost selectată pentru teste deoarece, ea este
una din puținele locații care nu conțin numar de telefon. În plus având în vedere ca este un
parc, nu trebuie afișat un program de funcționare pen tru acesta. În acest caz am testat dacă
există probleme cauzate de faptul că cele trei câmpuri (telefon, open_time și close_time) sunt
nule. Deoarece acestea sunt nule, nici etichetele pentru câmpurile respective nu trebuie
afișate.
6.5 Testare folosind scenarii de test
Această metodă este o activitatea de testare software care utilizează scenarii: povestiri
ipotetice care ajută persoana ce testează sa treacă de o problema complexă sau un sistem de
teste. Scenariul ideal de test este o poveste credibilă, complexă și convingatoare sau
motivațională al cărei rezultat este ușor de evaluat [17].
Figura 6.6 Testarea neafișări
numărului de telefon și a
programului
Proiect de diplomă
54
Cu ajutorul scenariilor de test s -au acoperit următoarele cazuri de test:
Creare cont – Verificare procesului de înregistrare a unui cont nou
Datele folosite sunt valide (adresa de email nu există în baza de date,
respectă formatul impus și parola, conține î ntre 7 și 16 caractere)
Câmpurile de text rămân necompletate
Adresa de email este deja înregistrată în baza de date
Adresa de email nu respectă formatul impus
Parola nu conține între 7 și 16 caractere
Logare utilizator – Verificarea procesului de logare a unui utilizator
Datele folosite sunt valide și utilizatorul are deja cont creat
Utilizatorul nu are cont creat
Este bifată cașuța “Rămâi Autentificat”
Adresa de email și/sau parola sunt invalide
Vizualizare hartă – Verificarea procesului de afișare a hărții si a marcajelor
locațiilor stocate în baza de date
Accesare listă locații – Verificarea procesului de afișare a listelor de locații în
funcție de categoria selectată
Selectarea unei locații
Folosirea bării de căutare
Actualizarea credențialelor contului – Verificarea procesului de de modificare
a credenț ialelor contului de către utilizator
Folosirea unor date valide
Câmpuri de text necompletate
Introducerea unei parole noi, ce nu respectă formatul corect
Introducerea unei parole vechi incorecte
Delogare utilizator – Verificarea procesului de delogare di n aplicație a unui
utilizator
6.6 Testarea exploratorie
Această tehnică de testare combină experința tester -ului cu o abordare stucturată
pentru testare. Testarea exploratorie este adesea efectuată asemenea unei tehnici de testare
numită “Cutie Neagră” (eng. Black -Box Testing), dar acest lucru nu este obligatoriu. Persoana
ce testează învață lucruri, care puse împreună cu experiența și creativitatea acestuia generează
noi teste.
Testarea Black -Box este o metodă de testare software prin care se examinează
funcționalitatea unei aplicații fară a avea cunoștință de structurile sale interne, precum codul
aplicației, metodele sau clasele folosite. Această metodă de testare poate fi aplicată practic
pentru fiecare nivel de testare software.
55
Beneficii le testării exploratori :
Pregătirea metodei durează mai puțin în comparație cu celelalte metode
Defecte critice pot fi găsite extrem de usor
Se pot utiliza abordări bazade pe raționamentul rezultatelor anterioare, pentru
ghidarea testelor viitoare
Neajunsurile testării exploratori:
Ținerea evidenței testelor realizate este dificilă
Testele nu pot fi revizuite
Puțin probabil sa fie efectuată în același mod și să repete detaliile specifice ale
testelor anterioare
Pentru această aplicație s -a ales o arie de interes și s -a verificat interfața și
funcționalitatea acesteia, fară avea un anumit set de pași de urmat. Prin acest lucru cred că s –
au testat lucruri ce altfel puteai fi omise, deoarece de multe ori, fără a avea un set de pași bine
stabilit, se pot descoperii numeroase probleme ce pot diminua calitatea aplicației.
Proiect de diplomă
56
Capitolul 7 CONCLUZII
Cum am menționat și anterior în lucare, trăim într -un secol al vitezei, unde cele mai
mari avantaje, pe lângă viteză sunt accesibilitatea și portabilitatea.
Datorită internetului oricine poate avea acces la orice fel de informație, iar majoritatea
activităților din viața de zi cu zi, precum plata facturilor, cumpăraturi, accesul la biblioteci
online, comunicarea on -line și chiar calătoriile ne sunt ușurate datorită acestuia. Toate acestea
sunt datorate calculatoarelor, telefoanelor care devin din ce în ce mai performante și
inglobează din ce în ce mai multe funcționalități, dar în special internetului.
În cele ce urmează vor fi prezentate cont ribuțiile personale aduse în dezvoltarea
acestei lucrari, precum și dezvoltări și îmbunătățiri folositoare în viitorul apropiat sau
îndepertat al acestei aplicații.
7.1 Contribuț ii personale
Pe parcursul acestui proiect a fost prezentat integral procesul de realizare a unei
aplicații Android, atât din perspectiva dezvoltării interfeței cu utilizatorul, cât și dezvoltarea
server -ului și a bazei de date, necesare pentru rularea aplicației.
Pentru realizarea proiectului au fost necesare cunoștințe de Prog ramare Orientată pe
Obiecte, Java, PHP și baze de date. Folosind aceste cunoștințe am reușit să dezvolt o aplicație
Android destinată informării persoanelor despre diferite localuri și obiective turistice din Cluj,
oferind informații despre acestea și abil itatea de geneare a unei rute de la poziția curentă pâna
la locația dorită. Obiectivele acestui proiect au fost atinse, dar există posibilitatea de extindere
a ariei de acțiune a aplicației, prin adaugarea mai multor locații în baza de date, dar și de
adau gare a mai multor elemente de filtrare pentru locațiile deja existente, pentru a facilita
găsirea unei locații perfecte și mai mult.
S-a reușit implementarea tuturor funcționalităților propuse inițial, dintre acestea, cele
mai importante fiind:
Crearea u nei interfețe intuitive care să faciliteze utilizarea aplicației pentru
utilizatori de toate vârstele.
Posibilitatea de vizualizare a locațiilor aflate în apropierea utilizatorului
Posibilitatea de filtrare a locațiilor după categoria acestora.
Posibilit atea de cautăre a locațiilor după numele acestora.
Abilitatea de generare a unei rute de la poziția utilizatorului către poziția
locației dorite.
Posibilitatea de a evaluare a locației de către utilizator.
Modul login pe baza unei adrese valide de email.
Abilitatea de editare a credențialelor utilizatorilor de către aceștia.
Criptarea datelor private ale utilizatorilor, pentru a fi asigurați că, în cazul în
care baza de date este compromisă, datele acestora nu pot fi accesate cu
usurință
Capitolul 7 CONCLUZII
57
7.2 Dezvoltări U lterioare
Întru -cât aplicația implementată este realizată cu tehnologii noi care sunt susținute de
o comunitate foarte mare, direcțiile și îmbunătățirile viitoare pot fi multiple, cele mai
semnificative fiind:
Adăugarea de noi locații pentru a extinde ari a de acțiune a aplicației
Remodelarea bazei de date astfel încat să existe categorii mai bine definite
Îmbunătățirea modului de creare a unui cont , în sensul că în momentul creării
unui cont nou, parola asociată acestuia să se genereze automat și să se tri mită
pe adresa de email asignat ă
Implementarea unei modalități de recuperare a parolei prin email
Implementarea abilității de logare folosind conturile de pe rețelele de
socializare
Implementarea abilității utilizatorilor de creare a recenziilor pentru loc ațiile
vizitate
Implementarea abilității de adaugare a locațiilor de către managerii de localuri
Imbunătățirea securității aplicației prin criptarea separată a parolelor, îmbunată
Proiect de diplomă
58
Bibliografie
[1] http://studytipsandtricks.blogspot.ro/2012/04/featur es-of-object -oriented –
programming.html
[2] https://en.wikipedia.org/wiki/Android_(operating_system)
[3] Mark Murphy , „Beginning Android 3 ”, APress, 2011
[4] https://developer.android.com/training/sharing/send.html
[5] http://ocw.cs.pub.ro/courses/eim/laboratoare/laborator05
[6] https://android.googlesource.com/platform/frameworks/volley
[7] https://developer.android.com/training/volley/index.html
[8] https://developer.android.com/guide/components/fundamentals.html
[9] http://www.makeuseof.com/tag/new -adb-make -process -simple -easy/
[10] https://en.wikipedia.org/wiki/Opaque_binary_blob
[11] https://ro.wikipedia.org/wiki/Android_(sistem_de_operare)
[12] https://console.developers.google.com/apis/library?project=zippy -genre -128610
[13] https://developer.android.com/reference/android/os/AsyncTask.html
[14] https://en.wikipedia.org/wiki/Client%E2%80%93server_model
[15] https://romannurik.github.io/AndroidAssetStudio
[16] http://testingeducation.org/BBST/domain/
[17] http://testi ngeducation.org/BBST/exploratory/
Acronime
59
Acronime
OOP – Oriented -Object Programming
POO – Programare Orientată pe obiect
UI – User Interface
AOSP – Android Open Source Project
HTTP – Hypertext Transfer Protocol
SD Card – Secure Digital Card
XML – Extensible M arkup Language
I/O – eng. Input/Ouput, Intrare/Ieșire
API – Application programming interface
SMS – Short Message Service
SDK – Software Development Kit
AVD – Android Virtual Device
IDE – Integrated Development Environment
ADB – Android Debug Bridge
USB – Universal Serial Bus
DDMS – Dalvik Debug Monitor System
APK – Android application package
PNG – Portable Network Graphics
ETC1 – Ericsson Texture Compression
OpenGL ES – Open Graphics Library for Embedded Systems
SHA -1 – Secure Hash Algorithm 1
PHP – Hype rtext Preprocessor
CRM – Curstomer relationship management
JSON – JavaScript Object Notification
CRUD – Create, Read, Update și Delete
URL – Uniform Resource Locator
DPI – Dots per inch
MHz – Mega Hertz
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: APLICAȚIE DE DISPOZITIVE MOBILE (ANDROID) ÎN [623062] (ID: 623062)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.