Universitatea POLITEHNICA Bucuret i

Facultatea Automatic i Calculatoare

Departamentul Automatic i Informatic Industrial

LUCRARE DE LICEN

Aplicatie mobile interactiva de ghidare a

vizitatorilor in Bucuresti

Coordonator Absolvent
Conf.dr.ing. Andreea Udrea Cogean Stelian

2017
Cuprins (orientativ)

1. Introducere (de ex.: justificarea alegerii temei, descrierea succint a coninutului

fiecrui capitol)................................................................................................................ 3
2. Prezentarea domeniului din care face parte lucrarea........................................................ 5
3. Descrierea problemei abordate i a metodei de rezolvare propuse................................. 14
4. Documentaie tehnic - prezentarea aplicaiei, echipamentelor, algoritmilor,
experimen-telor etc. i a rezultatelor obinute
.................................................................................. 25
4.1. Echipamente utilizate.............................................................................................. 30
4.2. Tehnologii software.................................................................................................40
4.3 Rezultate obinute....................................................................................................50
5. Concluzii i dezvoltri ulterioare (contribuii originale, domenii de utilizare posibile,
comparaii cu realizri similare - cu sublinierea avantajelor, performanelor etc.-, alte
aspecte relevante) ........................................................................................................... 59
7. Bibliografie..................................................................................................................... 64
8. Anexe (cu fragmente de cod software sau/i diagrame sau alte elemente, dac este cazul)

2
Abstract

3
1.Introducere
In ziua de azi tehnologia este atat de avansata incat telefoanele mobile si
dispozitivile periferice ale acestora au ajuns sa faca parte din viata noastra cotidiana si din
activitatile desfasurate de noi in mod regulat, inclusiv activitatile de relaxare precum
calatoritul. Chiar mai mult, s-a creat o dependenta foarte puternica de aceste tehnologii
intrucat din ce in ce mai multi oameni prefera sa isi petreaca timpul in lumea virtuala
decat sa socializeze cu persoanele aflate in jurul lor.

Scopul acestei lucrari este acela de a dezvolta o aplicatie mobile care sa ajute
vizitatorii orasului Bucuresti sa descopere si sa viziteze orasul in functiile de preferintele
acestora intr-o maniera interactiva si placuta. Aplicatia va fi intitulata BucharestGO.

Un alt obiectiv este reprezentat de incercarea de a limita interactiunea

persoanelor cu telefoanele mobile cu ajutorul introducerii unei tente de gamification.
Aplicatia genereaza trasee al caror obiectiv trebuie gasit in intervalul de timp pus la
dispozitie utilizatorului. Astfel, prin intermediul aplicatiei dezvoltate vizitarea orasului
Bucuresti este transformata intr-o vanatoare de comori. Indiciile transmise utilizatorului
pe durata traseului vor fi de tip cald-rece, informand vizitatorul daca se apropie de
obiectiv sau se departeaza.

Necesitatea dezvoltarii unei astfel de aplicatii este cauzata de inexistenta unor

aplicatii care sa permita utilizatorului sa primeasca informatii in timp real legate de locatii
ce ar putea reprezenta un punct de interes pentru acesta si provocarea acestuia de a gasi
aceste puncte de interes fara ajutorul tehnologiei.

Desi exista o serie de aplicatii pentru calatorit asemanatoare, majoritatea sunt

dezvoltate cu un obiectiv concentrat pe planificarea calatoriei si vizualizarea de locatii si
stabilirea traseelor catre acestea.

O prima aplicatie de acest gen este Cool Cousin [1]. Aceasta aplicatie genereaza o
retea sociala in care oameni pot sugera activitati si localuri in orasele lor natale. Totodata
acestia pot primi informatii legate de orasele pe care doresc sa le descopere in viitorul
apropiat. Desi aceasta aplicatie incurajarea comunicarea intre oameni aflati in diferite
parti ale lumii si descoperirea de locuri noi si interesante, nu garanteaza oferirea unor
activitati pe care turisti doresc sa le faca in orasul respectiv. Un alt efect negativ al acestei
aplicatii este faptul ca se incurajeaza utlizarea tehnologiei si implicit a dependentei
oamenilor de telefoanele lor mobile.(url:https://www.coolcousin.com)

Sidekix este o aplicatie pentru calatorit care sugereaza localuri cu rating ridicat
aflate in apropiere pe masura ce un turist strabate orasul. O alta functionalitate a acestei
aplicatii este setarea de trasee. Aceste functionalitati sunt prezente si in BucharestGO dar
aceasta contine si functionalitatile pentru treasure hunt. (url:
http://www.getsidekix.com/)

Walc este o aplicatie de generare a traseelor si oferire a indicatiilor intr-o maniera

mai usor de urmarit, intrucat nu foloseste punctele cardinale pentru afisarea directiilor ci
locuri de pe harta. Exemplu: indicatia: go north for the next 100 meters then turn right
este inlocuita cu: walk towards KFC, turn right at SubWay. Aplicatia BucharestGO are
4
incorporata functionalitatea de a genera trasee, acestea fiind afisate pentru o perioada
limitata de timp inainte de inceperea calatoriei. Restul aplicatiilor prezente in aplicatia
dezvoltata de mine reprezinta avantaje asupra aplicatiei Walc. (url:http://www.walc.me/)

Aplicatia Google Trips permite planificarea activitatilor desfasurate in timpul

explorarii unui oras. Sunt prezente si functionalitati de efectuarea de rezervari la hoteluri,
restaurante sau chiar bilete de avion. In comparatie cu BucharestGO, Google trips este
orientata mai mult pe partea de planificare a calatoriei si nu asupra descoperirii de locatii
noi.(url:https://get.google.com/trips/)

Localeur este o aplicatie pentru calatorit foarte asemanatoare cu aplicatia Cool

Cousin. Prezinta aceleasi functionalitati ca aceasta dar are in plus posibilitatea de a stabili
intalniri cu localnici care se ofera sa joace rolul de ghid turistic. BucharestGO ofera
posibilitatea de a descoperi locatii noi si favorizeaza socializarea dintre turisti si localnici
pentru obtinerea de indicatii catre obiectivul traseului. (url: https://www.localeur.com/)

In cadrul acestei lucrari se vor discuta urmatoarele aspecte:

Se va efectua o descriere a aplicatiei dezvoltate din punct de vedere

structural si se vor prezenta ecranele aplicatiei cu functionalitatile acestora
Se va explica modul de dezvoltare a aplicatiei specificand modul de
functionare al componentelor aplicatiei
Se vor prezenta tehnologiile folosite si se va motiva alegerea acestora
pentru dezvoltarea aplicatiei BucharestGO
Se vor specifica rezultatele obtinute si posibile dezvoltari ulterioare ce pot
imbunatatii aplicatia

5
2. Descrierea aplicatiei BucharestGO

In cadrul acestui capitol vor fi prezentate rolurile aplicatiei, structura acesteia si

functionalitatile dezvoltate in cadrul aplicatiei BucharestGO impreuna cu detalii de
implementare ale acestora.

Rolurile acestei aplicatii mobile sunt:

- de a oferi utilizatorului posibilitatea de a-si alege activitatile dorite pe parcursul
vizitei
- de a propune unele obiective care sa satisfaca aceste alegeri
- oferirea de detalii precum review-uri oferite de alti utilizatori. Aceste detalii pot
contribui la alegerea destinatiei cea mai potrivita pentru fiecare utilizator;
- incurajarea turistului de a petrece cat mai putin timp inetractionand cu telefonul
Utilizatorul interactioneaza mai mult cu mediul inconjurator datorita faptului ca indicatiile
oferite de aplicatie pentru atingerea obiectivului sunt afisate doar o anumita perioada de
timp. Astfel, utilizatorul nu trebuie sa-si concentreze toata atentia asupra telefonului, ci
poate observa imprejurimile si socializa cu locuitorii orasului, crescand in acest fel si
sansele ca acesta sa fie placut impresionat de experienta avuta in timpul descoperirii
orasului. Astfel se contureaza o proprietate a aplicatiei, aceea de a minimiza interactiunea
utilizatorului cu telefonul. Aplicatia devine o metoda de ghidaj care ofera informatii
suficiente pentru ca utilizatorul sa stie unde se indreapta, dar in acelasi timp il ajuta sa
cunoasca orasul mai bine fara a fi dependent de telefonul mobil.

2.1 Structura aplicatiei

Aplicatia BucharestGO este structurata astfel:
Baza de date. Are rolul de stoca informatiile transmise din cadrul aplicatiei;
Un modul principal(Starter). Acesta este incarcat primul in momentul rularii
aplicatiei. La acest modul principal sunt adaugate submodulele si serviciile. In
cadrul acestuia mai sunt realizate: conexiunea la baza de date si maparea paginilor
HTML , a controller-elor catre o stare. Astfel, unei stari ii corespunde o pagina
HTML si controller-ul asignat acestei pagini. Acest mecanism mai poarta numele

6
 de rutare;
Template general. Acesta este o pagina HTML ce are rolul de cadru. In acest cadru
sunt incarcate ecranele aplicatiei. Practic, este singura pagina HTML a aplicatiei
5 template-uri HTML. Fiecare template reprezinta un ecran al aplicatiei.
Acestea sunt:
LoginPage;
CreateAccountPage;
QuestionsPage;
ObjectivesPage;
JourneyPage;
5 controllere. Fiecare template HTML are nevoie de un controller separat in care
sunt stocate variabile si functii accesbile doar in pagina respectiva. Corespondenta
dintre template-urile HTML si controllere este urmatoarea:
LoginPage -> LoginCtrl;
CreateAccountPage -> CreateAccountController;
QuestionsPage -> QuestionsController;
ObjectivesPage -> ObjectivesController;
JourneyPage -> JourneyController;

Submodule. Acestea se anexeaza la modulul principal si au functionalitati diferite.

Submodulele implementate in aplicatie sunt:
geolocation. Acest submodul are rolul de a detecta pozitia curenta a
telefonului si de a stoca aceasta pozitie;
storeObjectivesBucket. Aici sunt stocate obiectivele si sunt
implementate diferite functii de prelucrare a acestora;
underscoreless. Acest submodul are functionalitate de filtru. Este
folosit pentru a inlocui caracterul underscore (_) cu un spatiu in
interiorul string-urilor.
hoursAndMins. Si acest submodul are functionalitate de filtru, rolul
sau fiind acela de a converti numarul de secunde ramase din cadrul
unui cronometru in format hh:mm

In momentul deschiderii aplicatiei sunt incarcate template-ul general si modulul principal

al aplicatiei. Modulul principal, spre deosebire de cele secundare, ruleaza pe toata perioada
sesiunii de utilizare a aplicatiei. Dupa incarcarea acestor componente cheie vor fi generate

7
toate dependintele definite in cadrul modului starter. Astfel, modulele secundare vor
putea fi accesate in cadrul utilizarii aplicatiei. In continuare, vor fi generate legaturile
dintre template-urile HTML si controllerele asignate acestora conform maparii realizate in
cadrul modului principal. In final, se genereaza conexiunea la baza de date si se face
autentificarea in cadrul API-urilor Google pe baza APIKey-ului obtinut in momentul
inregistrarii. Dupa efectuarea cu succes a acestor operatii este incarcat primul
template(LoginPage) iar aplicatia poate fi utilizata.

In Fig. x. este prezentata structura...

fig. x

2.2 Login

8
 Primul pas pentru utilizarea aplicatiei este acela de autentificare a utilizatorului.
Aceasta activitate se efectueaza in primul ecran al aplicatiei. Acesta contine doua campuri
ce trebuiesc completate cu adresa de email si parola aferente contului cu care utilizatorul
doreste sa se autentifice. Ecranul mai contine butonul de Login, care are rolul de a
efectua apelul de autentificare catre baza de date si un buton de tip link pentru redirectarea
catre pagina de creare a unui cont nou.
In momentul apelarii functiei de Login se face o validare a campurilor, intrucat
acestea trebuiesc completate inainte de efectuarea apelului catre baza de date. Astfel, se
restrictioneaza numarul de apeluri redundante catre baza de date. Dupa validare,
informatiile sunt trimise ca parametri ai apelului catre baza de date fie individual, fie dupa
convertirea acestora intr-un obiect de tip JSON (JavaScript Object Notation).
Apelul efectuat este de tip asincron, acest lucru inseamna ca dupa efectuarea
verificarii credentialelor in baza de date se va returna un promise cu rezultatul operatiei.
In functie de raspunsul primit prin promise utilizatorul este fie redirectat catre
urmatoarea pagina a aplicatiei, in cazul in care credentialele introduse sunt corecte, fie este
rugat sa reintroduca datele sau sa isi creeze un cont nou, in cazul in care credentialele nu
corespund cu utilizatorii existenti in baza de date.

9
 Fiura 1:Ecran Login

2.3 Create Account

In cazul in care utilizatorul se afla la prima utilizare a aplicatiei, acesta isi poate
crea un cont nou navigand catre pagina de Create Account, unde acesta trebuie sa
completeze campurile cu o adresa de email, o parola la alegere si un camp suplimentar de
verificare a parolei.
Completarea campului de verificare a parolei previne pericolul de salvare a unei
parole tastate gresit de catre utilizator. Inregistrarea contului nou cu o parola tastata gresit
reprezinta o problema ce poate conduce la pierderea si imposibilitatea de utilizare a
contului nou creat, lucru ce necesita resetarea parolei sau crearea unui cont nou. Aceste
activitati reprezinta o utilizare ineficienta a timpului si pot genera sentimente de

10
nemultumire utilizatorului.
Dupa completarea campurilor poate fi accesata functia de salvare a contului prin
apasarea butonului de Create Account, la apasarea acestui buton informatiile completate
de utilizator vor fi trimise catre baza de date unde informatiile introduse vor fi verificate
pentru corectitudine: adresa de email trebuie sa aiba un format valid, iar parola introdusa
trece prin doua operatii de verificare.
O prima verificare este reprezentata de compararea sirurilor de caractere completate
pentru a verifica daca acestea sunt identice. In cazul in care cele doua parole nu coincid
este returnat un mesaj de eroare menit sa informeze utilizatorul de greseala de tastare
efectuata, iar utilizatorul va trebui sa completeze din nou cele doua campuri si sa retrimita
cererea de creare a contului catre baza de date. In cazul in care sirurile de caractere coincid
se trece la urmatoarea operatie de verificare: analiza complexitatii parolei.
Din motive de securitate, parola trebuie sa respecte anumite reguli pentru a putea
preveni accesarea contului de catre alte persoane prin intermediul atacurilor cibernetice.
Aceste reguli se bazeaza pe lungimea parolei (aceasta trebuie sa fie compusa din cel putin
6 caractere), existenta majusculelor in cadrul parolei (cel putin o litera cu majuscule) si
existenta unui numar (parola trebuie sa contina cel putin un numar). Daca parola nu
indeplineste toate conditiile este returnat un mesaj de eroare specific, utilizatorul urmand
sa reintroduca parola, iar aceasta va fi verificata din nou. Daca atat adresa de email, cat si
parola respecta regulile contul este creat. Un avantaj al bazei de date folosite in
implementarea aplicatiei este reprezentat de stocarea tuturor user-ilor intr-o alta baza de
date, independenta de cea a aplicatiei oferind astfel un nivel mai mare de securitate.
Informatiile legate de useri pot fi accesate prin cereri efectuate catre baza de date a
aplicatiei, urmand ca aceasta sa efectueze la randul ei cereri care nu sunt vizibile
programatorului, catre baza de date generala dedicata stocarii si gestiunii utilizatorilor.
Informatiile returnate in baza de date a aplicatiei sunt criptate, astfel incat datele raman
confidentiale. Aceasta functionalitate poate fi folosita pentru a permite stocarea de
informatii suplimentare ale utilizatorului( exemple: varsta, nume, prenume).
Dupa crearea si stocarea noului user in baza de date, aplicatia afiseaza o alerta de
tip pop-up care are rolul de a informa utilizatorul cu privire la rezultatul pozitiv al operatiei
de creare si stocare a contului si cu privire la redirectionarea catre pagina de autentificare

11
unde poate utiliza acest cont.
Redirectionarea se efectueaza dupa 3 secunde, oferind in acest fel utilizatorului timpul
necesar pentru a citi informatiile afisate.

Figura 2: Ecran Create Account

Dupa efectuarea operatiei de autentificare, utilizatorul poate incepe procesul de selectare a

traseului prin a raspunde la intrebari legate de timpul pe care acesta il are la dispozitie si ce
activitati doreste sa desfasoare in intervalul de timp selectat. Aceste intrebari sunt afisate
pe primul ecran succesiv celui de Login.

12
2.4 Questions Page

Figura 3: Ecran Query

Pentru a raspunde la ntrebri, user-ul poate alege dintr-o list prestabilit de
opiuni. Aceasta metoda este favorit luand in considerare experienta utilizatorului si
interactiunea acestuia cu aplicatia. De asemenea, aceasta metoda ajuta la reducerea
timpului necesar utilizatorului pentru a-si exprima preferintele, generandu-se senzatia de
smooth flow a folosirii aplicatiei.
La imbunatatirea intercatiunii utilizator-aplicatie contribuie si meniul de navigare,
plasat in partea superioara a ecranului pentru varianta Android a aplicatiei si in partea
inferioara a variantei iOS, permitand navigarea intre paginile aplicatiei printr-o singura

13
apasare a iconitei aferente paginilor.

Figura 4: Navigation Bar

Aceasta metoda este preferata in detrimentul celor care prezinta un meniu lateral, deschis
prin apasarea butonului de Hamburger Menu, urmata de selectarea butonului dorit. In
acest mod, aplicatia devine mai intuitiva si mai user friendly.
In momentul finalizarii chestionarului de inceput, locatia telefonului este preluata
prin intermediul serviciului de Geolocation din cadrul API-ului de Google Maps. Acest
serviciu este accesat prin intermediul unei apel de tip POST, al carui raspuns este un obiect
de tip JSON ce contine pozitia, in coordinate de tip latitudine - longitudine, din momentul
efectuarii apelului.
Aceste coordonate, impreuna cu raspunsurile selectate sunt stocate atat in baza de
date pentru pastrarea preferintelor utilizatorului si a locatiei sale initiala (fiind accesibile si
in sesiunile viitoare ale utilizatorului respectiv) cat si in interiorul aplicatiei, int cadrul
submodulului geolocation. Acesta ruleaza in background si poate fi accesat din orice
activitate a aplicatiei. Existenta acestor submodule in cadrul aplicatiei permite reutilizarea
informatiilor pe durata intregii sesiuni de utilizare si ajuta la micsorarea numarului de
apeluri catre baza de date, determinand astfel pastrarea unui trafic de date de tip
aplicaticatie-server mai redus.
Aceste informatii servesc rolul de parametri pentru cautarea locatiilor din preajma
coordonatelor utlizatorului:
Activitatea dorita determina tipul de locatii cautate, astfel sunt excluse
obiectivele ce nu prezinta interes pentru utilizator;(Exemple)
Timpul selectat determina dimensiunea ariei in care este efectuata cautarea
de obiective. In maparea timpului catre aria de cautare a fost luat in calcul
un timp de vizitare a obiectivelor de pe parcurs care ar putea trezi interesul
urilizatorului, desi tipul acestora nu a fost selectat in faza initiala;

14
 Locatia curenta reprezinta centrul ariei de cautare ;

Cautarea obiectivelor se face prin intermediului API-ului Places API Web

Service din cadrul setului de servicii oferit de Google. Efectuarea apelului se face prin
intermediul metodelor specifice oferite de framework-ul AngularJS. In acest fel se
apeleaza o metoda simpla careia ii este transmis ca parametru un obiect ale carui campuri
sunt tipul obiectivelor, raza ariei de cautare si punctul central al cautarii. Raspunsul acestei
metode este un vector de obiecte de tip JSON, fiecare dintre aceste obiecte reprezentand o
locatie. Obiectele contin informatii legate de obiectiv, precum numele localului, adresa
acestuia, un id unic, locatia reprezentata in coordonte de tip Latitudine Longitudine,
programul de lucru si daca acest obiectiv se afla in intervalul de ore de deschidere.
Dupa parsarea obiectelor pentru o prelucrare mai rapida si mai optima, acestea sunt
filtrate in functie de programul de lucru, in cazul in care acesta este si va fii deschis in
timpul estimat pentru completarea traseului. Vectorul final este salvat in modulul intern de
memorare al aplicatiei pentru a putea fi accesat din alte activitati ale aplicatiei.
La finalul efectuarii acestor operatii, utilizatorul este redirectionat catre urmatoarea
pagina.

2.5 ObjectivesPage
In cadrul acestui ecran al aplicatiei obiectivele selectate la pasul anterior sunt afisate sub
forma unei liste de cards. In interiorul fiecarei carte sunt afisate numele locatiei, nota
generala oferita de utilizatori, tipul obiectivului si doua butoane: Show Details si Select
Location.

15
 Butonul de Show Details are rolul de a oferi utilizatorului informatii suplimentare
legate de locatia respectiv. La apasarea acestui buton se preiau date suplimentare despre
obiectiv. Acest lucru este realizat cu ajutorul API-ului de Google Maps, apeland serviciul
de Place Details din cadrul acestuia. Utilizarea acestui serviciu necesita transmiterea unuia
dintre urmatorii parametrii: un vector de lungimea fixa de 2 elemente, fiecare dintre
acestea reprezentand coordonatele locatiei, adresa acesteia sau id-ul unic. Toate aceste
informatii sunt incadrate in detaliile locatiei oferite de API-ul Places API Web Service,
utilizat pentru gasirea posibilelor puncte de interes ale utilizatorului. Parametrul mai usor si
mai sigur de folosit din punct de vedere al corectitudinii rezultatului este id-ul unic,
intrucat nu necesita construirea unui vector pentru a putea fi transmis, iar rezultatul
utilizarii acestuia este mai sigur decat utilizarea adresei.
Rezultatul obtinut este reprezentat sub forma de obiect JSON. Acesta contine

16
informatii aditionale, precum pareri si opiniile altor utilizatori. Rolul acestora in alegerea
unei locatii este foarte important deoarece pot scoate la iveala aspecte mai putin placute
cu privire la locatii sau dimpotriva, pot confirma aspecte pozitive.
Utilizatorul poate vizualiza aceste informatii in cadrul unei ferestre informative in
care sunt afisate review-urile, autorii acestora si notele oferite. Aceasta fereastra mai
contine doua butoane care ofera posibilitatea de a inchide modalul si de a selecta locatia
respectiva ca si obiectiv al traseului. Functionalitatea acestui buton de selectare este
similara cu cea a butonului prezent in afisarea de tip cards.

17
 In momentul selectarii unui obiectiv, acesta este stocat in interiorul submodulului
storeObjectivesBucket, iar utilizatorul este redirectionat catre pagina JourneyPage.
2.6 JourneyPage
In momentul initializarii acestui ecran, sunt preluate informatii despre locatia
curenta si destinatia din submodulele interne, iar continutul paginii este mascat de o
fereastra informativa al carei continut este reprezentat de o harta in care este ilustrat traseul
catre obiectiv.

Din momentul afisarii acestei ferestre, utilizatorul are la dispozitie 5 minute pentru
a stabili repere si a memora traseul. Dupa scurgerea acestui timp fereastra se va inchide

18
automat, iar cronometrul este pornit. Utilizatorul, acum devenit jucator, are la dispozitie
timpul selectat la primul pas pentru a termina traseul. Initializarea hartii si conturarea
traseului este realizata prin utilizarea directive Ng-Map.
Dupa pornirea traseului, progresul jucatorului este verificat la fiecare 5 minute.
Aceasta verificare este facuta printr-o bucla repetitiva. La primul pas, prin compararea
distantei initiale dintre punctul de plecare si destinatie cu distanta in timp real intre pozitia
curenta si destinatie. Dupa prima verificare, noua distanta este salvata ca distanta veche
urmand sa fie comparata cu distanta determinata dupa urmatoarele 5 minute. Jucatorul este
informat cu privire la timpul ramas prin intermediul unui timer si cu privire la progresul
sau printr-un indicator de tip hot and cold, care isi schimba culoarea treptat, in functie de
distanta ramasa de parcurs pana la destinatie. Culoarea initiala a indicatorului este albastru
inchis, urmand ca acesta sa treaca treptat, odata cu apropierea de obiectiv a jucatorului
catre rosu.

19
 In momentul intrarii jucatorului intr-o arie destul de restransa in jurul obiectivului
stabilit, este activat butonul Finish Quest care opreste cronometrul si felicita jucatorul
pentru terminarea traseului.
2.7 Chestionar pentru profil
Pentru a putea selecta atat intrebarile cat si raspunsurile concludente pentru
aplicatia in discutie, am realizat un chestionar pe care l-am impartit unui numar de
persoane din grupul int. In functie de rezultatele chestionarului au fost selectate
intrebarile si rapunsurile din aplicatie pe care utilizatorul trebuie sa le completeze.
Chestionarul reprezinta o metoda optima de colectare a informatiilor necesare
legate de posibile functionalitati ale aplicatiilor. Cu ajutorul chestionarului se descopera ce
beneficii doresc utilizatorii sa obtina din utilizarea aplicatiei, astfel influentand arhitectura

20
si functionalitatile prezente in varianta finala a aplicatiei.
Aceasta colectare de informatii trebuie efectuata inainte de inceperea dezvoltarii
aplicatiei, mai exact in etapa de planificare. In cadrul acestei etape sunt stabilite
functionalitatile ce urmeaza a fi implementate in cadrul aplicatiei. Pentru aplicatia curenta
chestionarul este format din urmatoarele intrebari:
Prima intrebare este legata de varsta persoanei ce completeaza chestionarul.
Prin intermediul acestei intrebari se poate stabili o dependenta intre grupele
de varste si raspunsurile oferite. In urma colectarii raspunsurilor acestui
chestionar principalele varste au fost:

Ti-ar placea sa folosesti o aplicatie de ghidare atunci cand vrei sa descoperi

un oras nou?
Aceasta intrebare are rolul de a detecta probabilitatea ca turistii sa
foloseasca aplicatia proiectata. Aceasta probabilitate poate fi luata in calcul
pentru aproximarea numarului de utilizari al aplicatiei si implicit, al
numarului de apeluri catre baza de date si catre API-urile folosite in
dezvoltarea aplicatiei, odata ce aceasta a fost publicata in magazinele online
de aplicatii. Raspunsul predominant al acestei intrebari a fost DA
Care dintre urmatoarele intrebari iti vine prima in minte cand vizitezi un
oras nou? Posibilele raspunsuri la aceasta intrebare sunt:Ce activitati ai
de obicei?, Ce activitati ai vrea sa faci azi?, Ce ai vrea sa vezi azi?.
Rolul acestei intrebari este acela de a determina criteriile pe care turistii le
au in alegerea activitatilor in momentul vizitarii unui oras nou.

21
 Rezultatele acestei intrebari sunt:

In urma acestui rezultat a fost selectata intrebarea legata de activitatile dorite, afisata in
cadrul aplicatiei.
Atunci cand vizitezi un oras nou, ce activitati ai de obicei?. Prin
intermediul acestei intrebari au fost selectate raspunsurile oferite la
dispozitie utilizatorului la intrebarea legata de activitati. Au fost selectate
primele 5 cele mai populare raspunsuri.

Ce este cel mai important pentru tine atunci cand esti intr-un oras nou?.
Cu aceasta ultima intrebare s-a stabilit filtrul final din cadrul aplicatiei.
Aceasta reprezinta un criteriu de cutare al locatiilor aflate in zona
apropiata utilizatorului.Situaia oferit de rspunsuri este urmtoarea:

22
In urma acestor rezultate a fost aleasa o intrebare legata de timpul pe care utilizatorul il are
la dispozitie pentru a putea realiza traseul sugerat de aplicatie.

3. Modul de implementare
In acest capitol se va prezenta modul in care aplicatia a fost implementata.
Modurile de implementare prezentate vor fi detaliate pe baza structurii aplicatiei. Se va
incepe cu partea de backend, ce contine baza de date si se va continua cu partea de
frontend si design.
3.1 Baza de date FireBase
Baza de date este structurata in obiecte generale ale caror campuri reprezinta de
fapt alte obiecte. Aceasta reprezentare a datelor este necesara datorita faptului ca in
FireBase nu se pot stoca vectori de obiecte si nu exista tabele.
Un exemplu al stocarii de date in cazul aplicatiei BucharestGO este reprezentat de
stocarea detaliilor legate de utilizatori. Astfel, a fost creat un obiect parinte numit
userInfo. In cadrul acestuia sunt stocate obiecte ce contin informatiile primite din cadrul
aplicatiei. Aceste obiecte contin:
codul utilizatorului logat in aplicatie. Acesta reprezinta id-ul unic al userului salvat
in baza de date dedicata utilizatorilor;
activitatea selectata in cadrul sesiunii curente de utilizare a aplicatiei. Aceasta
informatie reprezinta raspunsul utilizatorului la intrebarea :What would you like to
do today?;
varsta utilizatorului;
timpul selectat de utilizator in cadrul ecranului QuestionsPage. Reprezinta timpul
pe care acesta il are la dispozitie pentru efectuarea traseului;
adresa de email a utilizatorului;

23
 Pentru a putea gestiona informatiile din baza de date in cadrul aplicatiei au fost
realizate urmatoarele etape:
realizarea conexiunii la baza de date;
efectuarea operatiilor de salvare si de preluare a datelor.
Conexiunea la baza de date se realizeaza prin apelarea metodei initializeApp din
cadrul librariei Firebase. Aceasta metoda primeste ca parametru un obiect care trebuie sa
contina informatiile necesare crearii conexiunii. Aceste informatii pot fi preluate din cadrul
consolei web a bazei de date.
Operatiile de salvare a informatiilor sunt realizate prin specificarea obiectului
parinte din cadrul bazei de date in care trebuiesc stocate informatiile, urmate de apelarea
metodei push. Trebuie transmis obiectul JavaScript in care sunt stocate informatiile ce se
doresc a fi salvate.
Operatiile de accesare a informatiilor in baza de date sunt realizate intr-o maniera
simpla. Intai se specfica obiectul parinte din baza de date, apoi se realizeaza stocarea
informatiilor in interiorul aplicatiei prin atribuirea obiectului JavaScript.
3.2 Controllere
3.2.1 LoginCtrl
Acest controller este asignat paginii de autentificare prin intermediul maparii
definita in modulul principal al aplicatiei. Acest controller contine urmatoarele functii:
login si goToCreateAccount. Functia de login are rolul de a prelua informatiile
introduse de utilizator in cele doua campuri existente in pagina si de a efectua apelul de
autentificare catre baza de date.
Apelul catre baza de date se realizeaza cu ajutorul metodei
signInWithEmailAndPassword din cadrul librairei FireBase. Aceasta metoda primeste ca
parametrii 2 string-uri: adresa de email si parola. In cazul in care operatia de autentificare
se realizeaza cu succes, se navigheaza catre pagina QuestionsPage, prin intermediul
metodei state.go(). Daca operatia de autentificare esueaza, mesajul de eroare captat prin
intermediul metodei catch este afisat pe pagina.
Functia goToCreateAccount are rolul de a redirectiona aplicatia spre pagina
CreateAccountPage. Aceasta operatie este realizata prin apelarea metodei state.go().
Aceasta metoda primeste ca parametru numele starii catre care se doreste navigarea, in

24
cazul de fata acesta fiind createAccount.
3.2.2 CreateAccountController
In acest controller sunt implementate functionalitatile prezente in ecranul
CreateAccountPage. Functiile implementate in cadrul acestui controller sunt:
createAccount;
returnToLogin;
showPopUp;
Functia createAccount este mai importanta decat celelalte functii ale controller-ului
intrucat are rolul de a efectua operatia de creare de conturi, dupa cum sugereaza si numele
functiei. Aceasta functie realizeaza apelul pentru generarea si stocarea unui nou user catre
baza de date prin apelarea metodei createUserWithEmailAndPassword. Metoda returneaza
rezultatul operatiei de creare a user-ului in cadrul bazei de date. Astfel, daca rezultatul este
unul pozitiv, este apelata functia showPopPup, iar in caz contrar este afisat mesajul de
eroare returnat.
Functia returnToLogin are rolul de a efectua redirectarea aplicatiei inapoi catre
ecranul de login.
Ultima functie din cadrul acestui controller afiseaza o fereastra informativa cu
mesajul de succes al operatiei de creare a contului si executa redirectionarea catre pagina
de login prin apelarea functiei returnToLogin. Aceasta redirectare se executa dupa 3
secunde, oferind astfel timp suficient utilizatorului sa citeasca continutul ferestrei
informative.
3.2.3 QuestionsController
O prima functionalitate a acestui controller este aceea de a trimite catre baza de
date detaliile despre utilizator impreuna cu raspunsurile acestuia la intrebarile afisate pe
ecranul QuestionsPage. Aceasta functionalitate a fost implementata in cadrul functiei
finishQuizz. Dupa stocarea acestor informatii, raspunsurile utilizatorului sunt analizate si
se stabilesc parametrii de cautare a obiectivelor in functie de acestea.
In cadrul acestui controller mai este realizata si determinarea pozitiei curente a
telefonului prin apelarea serviciilor din cadrul submodulului geolocation. Pozitia
determinata este stocata in interioul aceluiasi submodul.
In acest moment au fost determinati toti parametri necesari pentru cautarea

25
obiectivelor din apropierea telefonului. Cautarea se realizeaza prin intermediul apelarii
functiilor din cadrul submodulului storeObjectivesBucket. In continuare sunt efectuate o
serie de verificari asupra rezultatelor obtinute in urma cautarii de obiective.
O prima verificare este realizata asupra numarul de rezultate. Daca nu a fos gasit
nici un rezultat, raza de cautare se mareste si este executata din nou cautarea. In caz
contrar, sunt eliminate din vectorul de rezultate acele obiective care sunt inchise. Vectorul
final de rezultate este salvata in interioul aceluiasi submodul utilizat pentru cautarea de
obiective prin intermediul unei functii de tip set.
Dupa efectuarea tuturor acestor operatiii aplicatia navigheaza catre urmatorul ecran.

3.2.4 ObjectivesController
Acest controller este asignat paginii ObjectivesPage si are un rol intermediar, intrucat
acesta apeleaza diferite submodule in care au fost implementate majoritatea
functionalitatilor prenzente in acest ecran. Comuicarea la nivel pagina HTML - submodul
nu este posibila. Asadar este necesara stocarea informatiilor in cadrul controller-ului pentru
a permite afisarea acestora.
Astfel, la initializarea acestui controller sunt preluate obiectivele obtinute in ecranul
anterior din cadrul aceluiasi submodul folosit pentru detectarea acestora. Aceasta operatie
este realizata prin apelarea unei functii de tip get. Aceste obiective sunt afisate in
interfata grafica.
Functionalitatea de cautare a detaliilor legate de un anumit obiectiv se realizeaza
prin apelarea functiei getLocationDetails, implementata in cadrul submodului
storeObjectivesBucket. Dupa executia acestei functii, rezultatele obtinute sunt preluate
in interiorul controller-ului si afisate in cadrul unei ferestre informative.
Selectarea unui obiectiv ca destinatie a traseului a necesitat implementarea a doua
functii diferite intrucat obiectele locatiilor au structuri diferite. Desi au functionalitati
similare de a stoca destinatia aleasa in interioul submodulului storeObjectivesBucket si
de a efectua redirecatarea catre ultimul ecran al aplicatiei, acestea transmit obiecte cu
structuri diferite.

26
 3.2.5 JourneyController
In cadrul acestui controller au fost implementate functionalitatile existente in ultimul ecran
al aplicatiei BucharestGO.
In momentul initializarii sunt preluate din submodule destinatia si punctul de
plecare al traseului. Locatia curenta este considerata punctul de start al traseului.
Aceste doua pozitii sunt transmise directivei NgMap ca parametrii pentru a se putea genera
traseul. Parametrii sunt transmisi dinamic catre directiva prin specificarea in codul HTML
a variabilelor din cadrul controller-ului unde sunt stocate originea si destinatia.
Harta si traseul sunt afisate in interiorul unei ferestre informative, care dispare automat
dupa 5 minute. Pentru a inchide fereastra automat am implementat un comportament de tip
cronometru, acesta asteapta scurgerea celor 5 minute dupa care inchide fereastra.
In continuare este determinata distanta initiala dintre cele doua obiective. Acest
lucru a fost implementat cu ajutorul API-ul Google Maps Distance Matrix. Realizarea unui
apel catre acest API se realizeaza prin metoda getDistanceMatrix din cadrul librariei
Google. Aceasta metoda primeste ca parametri coordonatele celor doua pozitii, urmand sa
returneze distanta calculata pe baza traseului dintre aceste doua locatii.
Pentru realizarea functionalitatii de verificare a distantei la interval de 5 minute am
implementat un comportament repetitiv. Astfel, functia de tip timer apeleaza la sfarsitul
celor 5 minute functionalitatea de calculare a distantei si se apeleaza singura pentru a
repeta ciclul. Determinarea pozitiei curente a dispozitivului este necesara pentru a putea
calcula noua distanta.
In cadrul comportamentului repetitiv se efectueaza o comparatie intre distanta nou
calculata si cea veche. Daca distanta s-a micsorat, utilizatorul este anuntat ca se apropie de
obiectiv, iar in caz contrar, utilizatorul este informat ca acesta se indeparteaza de obiectiv.
Informararea utilizatorului cu privire la progresul acestuia in cadrul traseului este
realizata prin doua metode. Prima metoda este aceea de a afisa mesajul You are getting :
urmat de o variabila din cadrul controllerului. Aceasta variabila este modificata la 5
minute, odata cu verificarea distantei. Daca distanta s-a micsorat, variabila devine closer,
iar in cazul in care distanta s-a marit variabila este modificata in farther.
Cea de-a doua metoda este realizata prin existenta unui indicator de tip Hot and
Cold. In controller, culoarea acestui indicator este modificata automat in functie de

27
distanta ramasa de parcurs. A fost creata o lista de obiecte care cuprinde o distanta si
culoarea ce trebuie aplicata indicatorului pentru distanta respectiva. Dupa determinarea
distantei in comportamentul repetitiv este apelata functia care incadreaza distanta
respectiva intre 2 elemente ale listei de corespondenta intre distanta si culori si este setata
culoarea indicatorului. In cazul in care distanta dintre pozitia curenta a telefonului si
obiectiv este mai mica decat 100 de metri, utilizatorul poate apela functionalitatea de
finishQuest. La completarea traseului, cronometrul si comportamentul repetitiv de
determinare a distantei sunt intrerupte.
O alta functionalitate implementata in acest controller este aceea de a cronometra
timpul ramas pentru indeplinirea traseului. Aceasta functie preia din cadrul submodulelor
numarul de ore selectat de utilizator. Acest cronometru ruleaza independent de celelalte
functionalitati si este oprit doar la indeplinirea obiectivului. Astfel, in cazul in care
utilizatorul navigheaza pe alta pagina a aplicatiei, cronometrul inca functioneaza.
3.3 Modul Principal si submodule
3.3.1 Modulul Principal
Acesta reprezinta modulul de baza al aplicatiei si este incarcat primul in momentul
rularii aplicatiei. Spre deosebire de controllere si submodule care pot fi implementate in
acelasi document JavaScript, acest modul necesita de regula un document separat.
In cadrul acestui modul am implementat maparea intre template-uri si controllere.
Acest lucru permite navigarea in cadrul aplicatiei. Implementarea acestui sistem de rutare a
fost realizata cu ajutorul modulului AngularJS predefinit $stateProvider.
O alta functionalitate a acestui modul este realizarea conexiunii la baza de date.
Aceasta este realizata in momentul in care aplicatia a fost incarcata.
3.3.2 Submodule
Submodulele underscoreless si hoursAndMinutes au rol de filtrare. Mai exact,
underscoreless inlocuieste toate caracterele _ cu spatiu. Functionalitatea acestui
submodul este apelata direct in codul HTML prin folosirea caracterului | in cadrul
expresiilor de interpolare. exemplu: {{selectedTime | underscoreless}}.
Submodulul hoursAndMinutes are rolul de a converti numarul de secunde in format
HH:MM. Pentru implementarea acestei functionalitati, am folosit instructiunile de tip
Math din limbajul JavaScript.

28
 In cadrul submodulul geolocation a fost implementata functionalitatea de
preluare a locatiei curente a telefonului. Pentru aceasta, am folosit API-ul Google Maps
Geolocation API. Rezultatul apelului catre acest API este stocat de asemenea in interiorul
acestui submodul. Pentru a transmite informatiile catre controllere am implementat o
functie de tip get.
Submodulul storeObjectivesBucket contine implementarile functionalitatilor de
cautare de obiective, preluare de informatii aditionale despre un anumit obiectiv.
Rezultatele acestor operatii sunt stocate in interiorul submodulului, iar accesul la aceste
rezultate este realizat prin intermediul operatiilor de tip set si get.
Pentru a cauta obiective in zona apropiata utilizatorului am folosit API-ul Google
Places API Web Service. Pentru a putea executa apelul catre acest API, este necesara
transmiterea urmatorilor parametri:
Locatia curenta. Aceasta va servi rolul de centru al razei de cautare;
Tipul obiectivelor cautate. Acest parametru este determinat prin analiza
raspunsului oferit de utilizator la intrebarea legata de activitatile dorite;
Raza ariei de cautare. Acest parametru este stabilit in functie de raspunsul
utilizatorului la intrebarea legata de timpul pe care acesta il are la dispozitie
pentru a indeplini traseul;
O functie de callback care are rolul de a se executa in urma apelului catre
API. In cadrul acestei functii sunt realizate operatiile de verificare executate
asupra rezultatelor primite in urma apelului.
Acesti parametrii sunt transmisi din cadrul controller-ului in care se doreste
apelarea aceastei functii.
Rezultatul apelului catre acest API este un vector de obiecte JSON, unde fiecare
obiect reprezinta o locatie gasita conform criteriilor de cautare transmise ca parametrii.
Vectorul final de obiective rezultat in urma operatiilor de verificare executate in
controller este stocat in interiorul acestui submodul prin intermediul unei functii de tip
set.
Functionalitatea de cautare de informatii aditionale despre un anume obiectiv a fost
implementata cu ajutorul serviciului Places Details din cadrul API-ului: Google Places
API Web Service. Apelarea acestui seviciu necesita transmiterea ca parametru a unui

29
indificator unic al obiectivului. Acest parametru poate fi: id-ul unic, adresa sau
coordonatele obiectivului. Rezultatul obtinut in urma apelarii acestui serviciu este un
obiect JSON.
Toate aceste obiecte sunt stocate in interiorul submodulului prin intermediul unei
functii de tip set. In cadrul acestui submodul mai sunt stocate locatiile alese de utilizator
ca obiective ale traseelor efectuate.
3.4 Template-uri HTML
Structura de baza a template-urilor a fost realizata in limbajul HTML, iar pentru
stilizarea elementelor din pagini au fost folosite atat clase si elemente din Ionic Framework
cat si clase create de mine in CSS.
Iconitele prezente in bara de nevigatie au fost preluate din libraria framework-ului
ionic. In momentul navigarii pe o pagina, iconita corespunzatoare acestei pagini isi
modifica culoarea automat pentru a fi evidentiata pagina curenta afisata in cadrul aplicatiei.
Pentru conectarea elementelor unei pagini cu variabilele din controller-ul asignat
acesteia au fost folosite directive AngularJS precum ng-model. Directivele din aceasta
familie permit salvarea modificarilor realizate in frontend in variabilele din cadrul
controller-ului. Pentru afisarea informatiilor din controller este necesara doar folosirea
mecanismului de interpolare. Continutul variabilelor putand afisat prin intemediul {{
$scope.numeVariabila}}.
Afisarile listei de obiective din pagina ObjectivesPage este realizata cu ajutorul
directivei ng-repeat. Aceasta directiva permite parcurgerea vectorului de obiective si
generarea elementelor HTML de tip cards. Structura HTML si stilul acestor elemente
sunt identice, difera doar informatiile afisate.
De asemenea, au fost implementate template-urile afisate in cadrul ferestrelor
informative. Acestea au fost asignate ferestrelor in mod direct prin transmiterea codului
HTML ca string in cazul ferestrelor cu cantitate mica de informatii. Iar pentru ferestrele cu
continut mai bogat de informatii, template-urile au fost asignate cu ajutorul proprietatii
templateUrl. Aceasta propietate primeste ca parametru calea din structura de fisiere a
aplicatiei unde se gaseste fisierul HTML in care a fost implementat template-ul.
Pentru crearea indicatorului de tip Hot and Cold de pe ultima pagina a aplicatiei
am folosit un svg in cadrul caruia am desenat un cerc.

30
4. Tehnologii folosite
4.1 Aplicatii Hibride
(https://www.mobiloud.com/blog/native-web-or-hybrid-apps/);
(https://ymedialabs.com/hybrid-vs-native-mobile-apps-the-answer-is-clear/)

La inceputul anilor 2000, dezvoltarea aplicatiilor destinate telefoanelor mobile

presupunea cunoasterea limbajelor specifice fiecarui sistem de operare existent. Odata cu
evolutia tehnologiei si imbunatatirea exponentiala a performantelor smartphone-urilor, a
crescut si nevoia de dezvoltare accelerata a aplicatiilor.
Acest lucru a determinat aparitia necesitatii unei solutii care sa permita micsorarea
timpului necesar dezvoltarii aplicatiilor mobile. Aceasta solutie a fost gasita in cadrul
tehnologiilor web, de asemenea aflata in deplina expansiune. Cum toate telefoanele dispun
de un browser nativ care sa permita navigarea mai rapida pe site-urile din ce in ce mai
complexe, indiferent de sistemul de operare al dispozitivului, cu un continut mai bogat de
informatii si functionalitati, s-a decis utlizarea acestuia pentru interpretarea aplicatiilor,
eliminand astfel nevoia utilizarii limbajelor de programare specifice.

Noul tip de aplicatii permite dezvoltarea acestora utilizand tehnologiile folosite in

programarea web (HTML, JavaScript si framework-uri ale acestui limbaj, CSS) si rularea
rezultatului pe browserul nativ al telefonului. Se genereaza in acest mod senzatia utilizarii
unei aplicatii native. Aceasta senzatie este semnificativ imbunatatita prin existenta unor
conectori al caror scop este acela de a permite aplicatiilor hibride sa acceseze si sa utilizeze
functiile interne ale telefonului din cadrul browser-ului nativ , oferind posibilitatea de a
construi aplicatii care sa foloseasca camera foto a telefonului, sa acceseze fisierele stocate

31
in memorie sau sa deschida galeria pentru preluarea si gestionarea continutului acesteia.
Aplicatiile hibride prezinta numeroase avantaje, dar si dezavantaje fata de aplicatiile
native.

Principalele avantaje sunt:

Un timp de dezvoltare mult mai redus, intrucat nu mai este necesara programarea
unui numar de variante ale aplicatiilor egal cu numarul de sisteme de operare pe
care se doreste posibilitatea de a fi rulate. Astfel nu mai exista necesitatea
existentei impartirii echipei de dezvoltare in subechipe specializate pe un anumit
sistem de operare;
Un cost mult mai redus. Acest lucru este determinat de numarul mai mic de
programatori necesar pentru dezvoltarea aplicatiilor deoarece acestia nu sunt
nevoiti sa cunoasca limbajele de programare specifice sistemelor de operare. Astfel
se poate mari profitul obtinut de catre companie.
Operatiile de suport ale aplicatiei sunt mai usor de realizat si necesita un timp mai
redus, ceea ce inseamna o rezolvare mai prompta a posibilelor probleme aparute in
aplicatie;
Se pot include functionalitati programate in limbajul nativ specific sistemului de
operare in cazul necesitatii acestui lucru;

Principalele dezavantaje sunt:

In cazul existentei unei cerinte de putere de calcul ridicata, aplicatiile native sunt
mai performante intrucat acestea nu sunt rulate in browserul intern al
dispozitivului, ci direct in sistemul de operare.Acest lucru permite o utilizare mult
mai optima a resurselor hardware ale telefonui, generand rezultate mai bune decat
aplicatiile hibride;
Existenta unor diferente in cadrul browser-elor native poate cauza aparitia unor
comportamente diferite ale aplicatiilor hibride rulate pe diferite sisteme, fiind
necesare tratari diferite ale acestor comportamente. Aceste diferente pot fi subtile,
de aceea este necesar un timp mai indelungat dedicat operatiilor de testare ale
aplicatiei.

32
 Datorita existentei unor tehnologii de tratare automata a diferentelor existente intre
browser-ele sistemelor, a posibilitatii de accesarea a functionalitatilor interne ale
telefonului si nevoia unei cantitati relativ reduse de date utilizate (iar un procent ridicat din
acestea va fi preluat de la API-uri) si a unei puteri de procesare destul de mare, accesibila
din cadrul browserului, am decis sa dezvolt o aplicatie hibrida care sa ajute la ghidarea
turistilor in Bucuresti.

De aici am luat informatiile despre arhitectura( e o carte)

https://www.safaribooksonline.com/library/view/building-hybrid-android/9781449361907/
ch05.html
Arhitectura generala a unei aplicatii hibride cuprinde:
Browser intern. Avand in vedere faptul ca o aplicatie hibrida este la baza o
aplicatie web cu capacitati de accesare a functiilor native ale telefonului prin
diferiti conectori, aceasta are nevoie de utilizarea unui browser intern pentru
afisarea continutului si incorporarea codului aferent logicii de functionare;
Model-view-controller (MVC) avand in vedere ca aplicatia este programata in
JavaScript si framework-uri ale acestui limbaj, este necesara implementarea unui
sistem de tipul MVC. Acest sistem reprezinta o modalitate de a separa partea de
prezentare de partea logica a aplicatiei. Modelul reprezinta structura logica a
aplicatiei, codul prin care sunt realizate functionalitatile aplicatiile, aceasta fiind
independenta de ceea ce este prezentat utilizatorului. View reprezinta partea
vizibila utilizatorului, partea cu care acesta interactioneaza in timpul folosirii
aplicatiei. Aceasta parte este scrisa cu ajutorul limbajului de tip MarkUp,
HTML.Cea de a doua componenta a acestui model este reprezentata de Controller.
Scopul acestuia este de a realiza legatura intre partea de prezentare si cea de
logica. Prin intermediul controller-ului este posibila interactiunea celorlalte
componente.Modul de functionare al modelului MVC este urmatorul: in
momentul interactiunii utilizatorului cu partea de prezentare, acesta efectueaza

33
 actiuni ce necesita apelarea unei functionalitati din cadrul modelului, partea de
prezentare trimite aceste actiuni catre controller care, la randul lui va accesa
functionalitatile necesare din partea de model, urmand sa preia rezultatul efectuarii
acestora de catre partea logica si sa il transmita partii de prezentare. In urma
executiei acestui ciclu utilizatorul efectueaza o operatie si vede rezultatul acesteia.
(MVC de aici:
http://whatis.techtarget.com/definition/model-view-controller-MVC)

Link imagine: https://developer.chrome.com/static/images/mvc.png

Conectori catre componentele native ale aplicatiei. Au rolul de a facilita

comunicarea intre partea incarcata in browser-ul nativ si componentele native ale
telefonului.
Componentele native. Dintre acestea fac parte: senzorii (un exemplu de utilizare a
acestora poate fi detectarea miscarilor efectuate asupra telefonului si activarea
anumitor comportamente in functie de acestea) sistemul de fisiere si camera
telefonului pentru capturarea de imagini in cadrul aplicatiei;

Datele pastrate in aplicatie. Acestea reprezinta informatii adunate in timpul rularii

aplicatiei si pot fi stocate intr-un modul de stocare intern, permitand astfel rularea
aplicatiei fara existenta unei conexiuni la internet si micsorarea numarului de
apeluri catre baza de date;
Resursele aplicatiei. Aici sunt pastrate librariile si fisiere externe folosite in cadrul
dezvoltarii. Acestea pot fi folosite pentru a stoca librariile framework-urilor folosite

34
 (ex: AngularJS, Ionic Framework) sau documente aditionale pentru introducerea
unor functionalitati aditionale celor oferite de librariile standard ale
framework-urilor. Este posibila incarcarea acestor resurse prin intermediul
conexiunii la internet in momentul initializarii aplicatiei, dar aceasta metoda nu este
recomandata deoarece anuleaza posibilitatea rularii aplicatiei in regim offline si in
unele cazuri resursele nu pot fi accesate datorita unor erori provenite de la server,
cauzand oprirea aplicatiei si imposibilitatea utilizarii acesteia;

url poza:
https://www.codeproject.com/KB/mobile/661720/PhoneGap-application-architecture.j
pg

Arhitectura aplicatiei dezvoltate o respecta pe cea generala, componentele sugerate

in cadrul acesteia regasindu-se si in aplicatia dezvoltata in lucrarea prezenta. Exceptie fac
componentele native ale tefelonului. Datorita functionalitatilor implementate in cadrul
aplicatiei a fost exclusa nevoia accesarii si utilizarii acestora. In plus, a fost creata si
utilizata o baza de date pentru stocarea informatiilor transmise din aplicatie.

Aplicatia este compusa din 3 mari parti componente:

Backend, format din baza de date si serverul aplicatiei;

35
 Frontend, care cuprinde functionalitatea aplicatiei;
Design, etapa in care partea vizuala a aplicatiei este construita intr-o maniera cat
mai simplista, pentru usurinta utilizatorului de a folosi functionalitatile aplicatiei,
dar totusi atractiva pentru utilizatori;

4.2.Backend
Acesta este alcatuit din baza de date si server. Serverul are rolul de a crea si
mentine o conexiune stabila intre aplicatie si baza de date pentru a facilita transferul de
date si evitarea posibililelor erori de transmitere a informatiilor. Rolul bazei de date este
acela de a stoca informatii transmise din cadrul aplicatiei. Aceste informatii reprezinta
detalii ale utilizatorilor si detalii despre traseele parcurse de acestia.
Un inconvenient in ceea ce priveste setarea si programarea acestor servicii este
timpul necesar si complexitatea efectuarii acestor operatii, intrucat majoritatea bazelor de
date si a serverelor ruleaza local in acest stadiu de dezvoltare al existentei aplicatiei,
urmand ca acestea sa sufere modificari ulterioare pentru a face posibila lansarea pe piata a
aplicatiei. Setarea pe masina locala a serverului si a bazei de date permite generarea
conexiunii intre aplicatie si acestea, insa fie doar prin intermediul unui emulator de
dispozitive telefonice, fie direct pe tefelon. Acest lucru este posibil cu conditia ca atat
calculatorul pe care au fost setate serverul si baza de date cat si telefonul sa fie conectate la
aceeasi retea wireless.
Pentru a evita aceste inconveniente, am optat pentru utilizarea unei baze de date
oferite de Google si anume Firebase. Aceasta este o baza de date in timp real, ce ofera
avantajul de a nu fi nevoit sa iti creezi un server pentru a putea fi accesata, intrucat este
situata pe cloud. Eliminarea necesitatii de creare a unui server este posibila datorita
API-urilor oferite de Google pentru conectare, autentificare si manipularea datelor din
interiorul bazei de date. Documentatia vasta pusa la dispozitie faciliteaza dezvoltarea
functionalitatilor din partea de backend.
Pentru a putea utiliza aceasta baza de date este necesara inregistrarea cu un cont
Google. Un alt avantaj al acestei tehnologii este reprezentat de faptul ca in momentul
inregistrarii iti este alocat un anumit spatiu de stocare pe care il poti folosi pentru crearea a
mai multor baze de date ce pot fi utilizate in cadrul mai multor proiecte. Vizualizarea si

36
gestiunea bazelor de date se face intr-un mod rapid si eficient prin intermediul interfetei
grafice pusa la dispozitia utilizatorului.

In cadrul acestei console se pot accesa toate proiectele create, se pot crea proiecte
noi pentru noi aplicatii sau se pot importa proiecte deja existente. Astfel, multe operatii ce
in cadrul altor baze de date necesita o perioada indelungata pentru realizare pot fi reduse la
doar cateva click-uri.
In afara bazei de date, se pot utiliza mai multe servicii pentru a analiza, testa si
genera rapoarte asupra aplicatiilor existente. In acest mod se pot colecta informatii legate
de gradul de utilizare al aplicatiei de catre utilizatori prin intermediul serviciului de
analytics. Astefel se pot detecta posibile defecte in cadrul aplicatiei folosind optiunea de
testare automata a aplicatiei.
Partea de analiza a utilizarii unei aplicatii este importanta intrucat poate determina
ce functionalitati ale aplicatiei sunt folosite mai des de catre utilizatori si ce functionalitati
sunt folosite mai putin, detectand astfel posibile imbunatiri ce pot fi aduse aplicatiei pentru
a genera un interes mai ridicat din partea utilizatorilor. Aceste operatii de analiza pot
determina numarul de descarcari al aplicatiei, varsta medie a utilizatorilor si zonele
geografice unde aplicatia este mai des folosita. Informatiile acestea pot ajuta la selectarea
unui grup tinta de utilizatori mai potrivit crescand astfel profiturile obtinute.
In cadrul aplicatiei dezvoltate, aceasta baza de date este folosita pentru gestiunea
utilizatorilor si pentru stocarea de informatii aditionale atat despre acestia, cat si despre
obiectivele selectate si rating-ul oferit acestora din partea utilizatorilor.
Conexiunea aplicatiei la baza de date este realizata in momentul incarcarii

37
aplicatiei, aceasta se face prin trimiterea unui parametru de tip obiect ce poate contine id-ul
unic al proiectului din baza de date, API Key-ul necesar autentificarii contului de Google si
domeniul aplicatiei. Toate aceste informatii sunt generate in momentul crearii proiectului
in consola.
O problema intampinata in folosirea acestei baze de date este modul de
reprezentare al datelor din cadrul ei. Informatiile nu sunt stocate sub forma de tabele, cum
este cazul in celelalte baze de date, ci sunt salvate sub forma de obiecte. De asemenea, nu
exista posibilitatea de a salva vectori. Aceste metode de structurare a datelor au determinat
o metoda de abordare diferita de cea clasica. Nu mai sunt utilizate query-uri pentru
interogarea bazei de de date ci sunt folosite metode predefinite in cadrul Firebase.

4.3 Frontend

In cadrul aplicatiilor hibride, aceasta parte este realizata cu ajutorul limbajului

JavaScript sau a framework-urilor sale. Pentru dezvoltarea functionalitatilor acestei
aplicatii am optat pentru folosirea framework-ului AngularJS.
4.3.1 AngularJS
AngularJS este un framework dezvoltat de catre compania Google cu rolul de a
permite realizarea de aplicatii ce pot fi accesate din cadrul mai multor platforme. In acest
mod se pot crea aplicatii care pot fi atat site-uri web cat si aplicatii mobile independente
care permit accesarea acelorasi informatii si functionalitati prezente in varianta web.
Permite limitarea operatiilor de manipulare a DOM-ului prin existenta unor directive
predefinite in cadrul frameworku-ului,determinand astfel o crestere a performantelor
aplicatiei.
DOM este prescurtarea de la Document Object Model si reprezinta un API aplicat
documentelor de tip HTML si XML. Cu ajutorul acestuia este definta structura logica a
documentelor si modalitatile de accesare si manipulare ale acestora. Prin intermediul
acestui API, se pot genera documente noi, se poate naviga prin structura acestora si se pot
efectua operatii de adaugare, stergere sau modificare ale continutului documentelor.
(url de unde am luat definitia DOM-ului:
https://www.w3.org/TR/DOM-Level-2-Core/introduction.html)
Dezvoltatorii de aplicatii hibride prefera utilizarea AngularJS datorita avantajelor

38
prezentate de catre acest framework. Printre acestea se numara:
url avantaje: https://www.sitepoint.com/10-reasons-use-angularjs/
Respecta modelul MVC, acesta este implementat intr-o maniera corecta ce
permite programatorului sa foloseasca capacitatile acestui model la potential
maxim. Spre deosebire de alte framework-uri, care necesita atat
programarea separata a partilor componente cat si programarea procesului
de comunicare dintre acestea, AngularJS necesita doar programarea
individuala a partii vizuale de cea a functionalitatilor urmand ca acesta sa
genereze automat comunicarea intre cele 2 parti.
Utilizarea unei interfete grafice declarative. AngularJS necesita utilizarea
limbajului HTML pentru crearea interfetei grafice. Aceasta necesitate este
generata de faptul ca AngularJS cuprinde o lista foarte bogata de etichete si
atribute ale acestora, care au rolul de conecta interfata grafica de logica de
functionare, dezvoltate special pentru limbajul HTML;
Modelul de date este POJO (Plain Old JavaScript Object). Prin folosirea
acestor obiecte care sunt de natura simplista, nu mai este necesara
implementarea unor metode suplimentarea pentru accesarea si modificarea
lor. Astfel, obiectele se pot accesa rapid printr-o cantitate redusa de cod,
oferind un aspect curat si bine organizat codului. Toate aceste obiecte sunt
conectate la interfata grafica, iar modificarea acestora se reflecata in mod
automat si in partea vizuala.
AngularJS introduce noi functionalitati prin intermediul directivelor.
Acestea reprezinta o modalitate noua de creare a unor functionalititati noi ce
pot fi reutilizate in cadrul a mai multor aplicatii. In acest fel, se incurajeaza
o modularizare mai buna a codului, lucru care ajuta la o mai buna intelegere
a codului de catre alti programatori din cadrul echipei de dezvoltare.
Existenta filtrelor si a modului usor de utilizare a acestora in cadrul
aplicatiilor dezvoltate cu framework-ul AngularJS permite executia
operatiilor de sortare, transformare, ordonare si filtrare a informatiilor
existente in aplicatie. Acestea sunt similare directivelor dar au ca scop
principal modelarea informatiilor afisate in interfata grafica. Pentru

39
 folosirea acestora, programatorul nu este nevoit sa scrie cod JavaScript
aditional ci doar trebuie sa apeleze aceste filtre prin intermediul caracterului
| .
Conceptul de modularizare a aplicatiei este imbogatit si prin existenta
serviciilor in AngularJS. Acestea au scopul de a realiza partea de conexiune
catre baza de date, efectuarea operatiilor de comunicare a aplicatiei cu
aceasta si stocarea informatiilor local, in aplicatie pe durata sesiunii
utilizarii aplicatiei. Odata ce informatiile au fost salvate intern, aplicatia
poate rula in regim offline. In acest mod, conceptul de aplicatie hibrida este
separat in totalitate de site web intrucat accesarea functionalitatilor si
navigarea intre paginile aplicatiei nu necesita o conexiune la internet, cum
este nevoie in cadrul unui site web. Serviciile/ submodulele AngularJS sunt
delcarate separat de controllere. Accesarea informatiilor stocate in interiorul
serviciilor se face intr-o maniera simplista, fiind necesara doar includerea
serviciului in dependintele controller-ului urmata de apelarea directa a
acestora sau prin apelarea unor metode de tip get si set implementate in
cadrul submodului;
Toate aceste avantaje transforma AngularJS intr-unul dintre cele mai puternice
framework-uri existente.
4.3.2 Google API
Pentru functionalitatile aplicatiei de preluare a pozitiei curente, de gasire a
posibilelor obiective si a detaliilor acestora, de includere a hartii si a generarii unui traseu
am folosit setul de API-uri oferit de Google. Acestea permit interogarea a uneia dintre cele
mai mari baze de date existente la momentul actual si utilizarea informatiilor obtinute
pentru a putea oferi utilizatorului o experienta placuta.
Api-urile Google pot fi folosite atat pentru aplicatii hibride cat si pentru aplicatii native
Android si iOS.
Pentru a prelua locatia curenta a telefonului am folosit Google Maps Geolocation
API. Acest serviciu ofera pozitia curenta a dispozitivului de unde a fost executat apelul si
acuratetea acesteia. Determinarea pozitiei se bazeaza pe detectarea nodurilor wifi si
surselor de semnal din apropiere de catre dispozitiv si transmiterea acestor informatii catre

40
server urmand ca acesta sa proceseze informatiile si sa calculeze locatia telefonului.
Informatiile transmise catre server nu trebuiesc neaparat colectate de catre programator,
acestea putand fii colectate in mod automat. In acest fel, programatorul este nevoit doar sa
execute apelul catre server. Acest apel este de tip POST catre un url gasit in documentatia
oferita de Google.
Pentru a putea folosi acest API, este necesara crearea unui cont standard sau
premium. In urma inregistrarii unui cont pentru utilizarea serviciul, acestuia ii este atribuit
o cheie unica care trebuie inclusa in apelurile executate pentru a se realiza autentificarea
contului si utilizarea propriuzisa a serviciului. Raspunsul returnat de serviciu este utilizat
pentru detectarea de obiective din apropierea dispozitivului.
Pentru a putea gasi locatii in apropierea telefonului si implicit in apropierea
utilizatorului aplicatiei, am folosit un alt serviciu oferit de catre Google, si anume: Google
Places API Web Service. Acest serviciu returneaza o lista de obiecte de tip JSON, unde
fiecare dintre acestea reprezinta o locatie aflata in aria device-ului. Aceste obiecte contin
informatii precum: numele localului, adresa acestuia, coordonatele, programul de lucru si
un camp de tip boolean care precizeaza daca localul este deschis sau nu in momentul
efectuarii apelului catre API.
Aria de cautare reprezinta un cerc al carui centru si raza trebuie specificat ca
parametru. Pe langa acestea doua mai este necesara transmiterea tipului de locatie
cautat(exemple: museum, park, shopping_mall). In cadrul aplicatiei acesti parametri sunt
transmisi dinamic, locatia curenta reprezentand centrul ariei de cautare, raza ariei este
setata in functie de raspunsul utilizatorului la intrebarea How much time can you spare to
complete our challenge? aflata pe ecranul cel de-al doilea ecran al aplicatiei.
Ca si in cazul API-ului de preluare a pozitiei curente a dispozitivului, este necesara
o cheie unica de autentificare. Aceasta poate fi obtinuta usor prin inregistrarea contului. O
cerinta secundara a utilizarii acestui API in cadrul aplicatiei este aceea de a include libraria
Google Places JavaScript Library in aplicatie. Utilizarea acestei librarii nu reprezinta un
dezavantaj, ci modul de includere a acesteia in aplicatie intrucat accesarea sa se realizeaza
prin intermediul unei conexiunii la internet si nu prin pastrarea acesteia in resursele
aplicatiei. Acest lucru poate cauza un trafic aditional de date al telefonului.
In ceea ce priveste operatiile de preluare a detaliilor legate de un anumit obiectiv,

41
am folosit serviciul Place Details din cadrul Google Places API Web Service. Pentru
utilizarea acestei functionalitati sunt necesare aceasi cheie si aceasi librarie ca si in cazul
serviciului serviciului de cautare a locatiilor din apropiere. Pentru a putea prelua detalii
despre un anumit obiectiv este necesara transmitearea unui identificator unic al acestuia.
Acest identificator poate fi: un vector de lungimea fixa de 2 elemente, fiecare dintre
acestea reprezentand coordonatele obiectivului, adresa obiectivului sau id-ul unic al
obiectivului. Aceste informatii pot fi preluate din obiectul locatiei returnat ca raspuns de
catre serviciul de cautare al obiectivelor. Din motive de corectitudine al raspunsului primit
din partea API-ului si de usurinta de transmitere a parametrului, am decis sa folosesc id-ul
unic al locatiei, stocat in campul place_id din cadrul obiectului corespunzator obiectivului.
Raspunsul primit este un obiect de tip JSON ce contine informatiile dorite. Este
recomandata convertirea acestui JSON in obiect de tip JavaScript pentru usurarea
efectuarii operatiilor necesare asupra acestuia.
In ceea ce priveste afisarea hartii si desenarea traseului intre locatia curenta, care
serveste rolul punctului de plecare a traseului, si destinatia aleasa de catre utilizator m-am
folosit de API-ul de Google Maps. Pentru a putea folosi acest API sunt necesare o cheie de
acces si utilizarea librariei Google Places JavaScript Library, insa aceste cerinte au fost
deja indeplinite in dezvoltarea functionalitatilor de cautare a locurilor din proximitatea
telfonului si obtinerea detaliilor despre unul dintre aceste locuri. Principiul de functionare
al hartii este format din urmatoarele etape: Crearea unui recipient pentru aceasta in
interfata grafica, asignarea acestuia metodei de generare a hartii specificand punctul in
jurul careia trebuie centrata harta, afisarea hartii in recipientul creat, setarea celor doua
puncte de interes (originea si destinatia), desenarea marker-erelor pe harta la coordonatele
punctelor stabilite, desenarea traseului intre cele doua puncte.
Problema majora pe care am intampinat-o in afisarea hartii si a traseului a fost
imposibilitatea de a utiliza doar functionalitatile din cadrul librariei oferite de Google,
intrucat functionalitatea hartii nu este compatibila cu Ionic Framework, utilizat pentru
stilizarea aplicatiei, si cu serverul local in care a fost dezvoltata aplicatia, Ionic Lab. Astfel,
a fost necesara includerea unei directive speciale in AngularJS, si anume : NgMap. Cu
ajutorul acesteia am putut suprascrie stilizarea generata de clasele din cadrul
framework-ului Ionic. Rolul acestei directive a fost de includere a functionalitatilor

42
librariei Google pentru harti in cadrul codului AngularJS, compatibil cu Ionic Framework.
Altfel spus, prin intermediul directive a fost creata o punte de legatura intre cele doua
librarii externe folosite in aplicatie: Google Places JavaScript Library si Ionic Framework.
Modul de functionare al directivei utilizate este similar cu cel al librariei Google, doar ca
initializarea hartii este realizata in codul HTML, fiind urmata de setarea destinatiei si a
punctului de plecare prin intermediul subdirectivei directions din cadrul NgMap.
Transmiterea celor doua puncte stocate intern in codul AngularJS catre codul HTML este
realizata automat de framework prin intermediul conectorilor. Acesta este un exemplu de
functionare al modelului Model-View-Controller.
Calcularea distantei existente intre cele doua ale traseul este realizate cu ajutorul
Google Maps Matrix Distance API. Acest serviciu are rolul de a calcula distanta intre
coordonatele a doua puncte transmise ca parametri. Un al treilea parametru necesar
apelarii acestui API este sistemul de masura al distantei calculate, in cadrul aplicatiei am
ales sistemul metric. Inainte de executia apelului, acesti parametri trebuiesc convertiti
intr-un singur obiect ce va servi rolul de parametru al apelului.
Rezultatul transmis de acest serviciu reprezinta distanta exprimata in unitatea de
masura transmisa ca parametru. Aceasta distanta nu este calculata ca un segment de
dreapta intre cele doua locatii, ea este determinata in functie de traseul dintre cele doua
locatii, oferind astfel un rezultat cat mai corect. Aceasta distanta urmeaza a fi comparata cu
distantele calculate anterior pentru a putea determina progresul jucatorului, daca acesta se
apropie de obiectiv sau se indeparteaza de acesta.

4.3.3 Limitari ale API-urilor Google

Un aspect important ce nu poate fi ignorat in dezvoltarea functionalitatilor folosind
setul de API-uri oferit de Google este limitarea numarului de apeluri permise in fiecare zi
in functie de tipul de cont utilizat, Standard sau Premium. Contul Standard este gratis iar
cel Premium necesita o plata lunara, suma fiind decisa in urma specificarii numarului de
apeluri necesare pentru a satisface numarul de apeluri provenite din aplicatie.
Numarul de apeluri al conturilor standard, desi este limitat, este suficient de mare pentru a
permite utilizarea serviciilor in etapa de dezvoltare a aplicatiilor. Numarul de utilizari

43
permise zilnic pentru fiecare dintre API-urile folosite in dezvoltarea acestei aplicatii este
ilustrat in tabelul de mai jos:
Nr. Crt. Denumire API Numar de utilizari permis
1. Google Maps Geolocation API 2500
2. Google Places API Web Service 1000
3. Google Maps API 25000
4. Google Maps Distance Matrix 2500

Conform datelor din tabel, numarul de apeluri permise zilnic nu este suficient in cazul unei
aplicatii lansate in productie. In acest caz pot exista numere foarte mari de utilizatori ai
aplicatiei generand astfel un numar mult mai mare de apeluri decat cel permis cauzand
astfel blocarea aplicatiei si imposibilitatea de utilizare a acesteia. In cazul aplicatiei create
de mine, care reprezinta un prim prototip, numerele acestea de apeluri au fost mai mult
decat suficiente pentru dezovoltarea si testarea aplicatiei. Numarul curent de apeluri poate
fi supravegheat in cadrul consolei oferite de Google.

Pe langa numarul de apeluri efectuate, se pot observa si numarul de dati in care apelurile
nu au putut fi executate cu succes datorita aparitiei unor erori. Astfel se pot urmari
performantele API-urilor. Aceste date pot fi utilizate pentru a aproxima un numar de
utilizari efectuate dupa lansarea aplicatiei in productie.

4.4 Design
Partea de design reprezinta modul in care sunt prezentate informatiile utilizatorului.
4.4.1 Ionic Framework
url pt Ionic
(https://www.joshmorony.com/8-reasons-why-im-glad-i-switched-to-the-ionic-framework/

44
)
http://ionicframework.com/docs/v1/overview/
Pentru partea de design a aplicatiei am optat pentru utilizarea unui framework
dedicat interfetei vizuale si anume Ionic Framework. Acesta este un framework de tip
open source dedicat HTML5, creat special pentru dezvoltarea aplicatiilor mobile hibride.
Spre deosebire de alte framework-uri specializate pentru interfata grafica, Ionic prezinta o
serie de componente al carui scop este de a da userului impresia utilizarii unei aplicatii
native.
O constrangere a aplicatiilor hibride este de a dezvolta stilizarile necesare pentru
toate dimensiunile ecranelor dispozitivelor pe care se doreste rularea aplicatiei, fie acestea
telefoane sau tablete. Propietatea aplicatiei de a-si modifica stilul prezentarii in functie de
dimensiunile ecranului poarta numele de responsive.
Aceasta activitate poate fi considerata ineficienta din punct de vedere al timpului
investit intrucat exista o gama foarte variata atat de telefoane, cat si de tablete,
dimensiunile ecranelor acestora putand sa difere foarte mult. Ionic Framework ofera
posibilitatea de a reduce acest timp prin oferirea de componente responsive. In acest fel,
elementele incluse in interfata grafica sunt capabile sa se modifice automat in functie de
dimensiunea ecranului. Un alt motiv pentru alegerea acestuia este reprezentat de faptul ca
Ionic framework a fost dezvoltat special pentru AngularJS. Se poate spune ca Ionic
Framework reprezinta o extensie a framework-ului AngularJS, utlizarea acestor doua
librarii impreuna fiind realizata intr-un mod foarte usor de inteles.
Existenta unei comunitati foarte mare de dezvoltatori reprezinta un alt avantaj,
intrucat acestia pot raspunde la nelamuririle programatorilor si ii pot ajuta pe acestia sa
rezolve problemele intampinate pe parcursul dezvoltarii aplicatiilor.
Un alt punct forte al acestui framework este constituit de posibilitatea setarii unui
server local care permite rularea proiectului intr-un emulator de sistem Android si unul de
iOS in browser si detectareaa schimbarilor efectuate in codul aplicatiei si repornirea
aplicatiei in browser. Exemplu: se doreste adaugarea unei noi functii intr-un controller,
dupa implementarea acesteia se executa operatia de salvare a codului modificat. In acest
moment este detectata schimbarea, codul este interpretat din nou pentru detectia posibilelor
erori iar aplicatia in browser este repornita.

45
 Un obstacol intalnit in folosirea framework-ului Ionic a fost afisarea hartii oferite
de catre API-ul Google Maps si de catre libraria oferita de acestia. Acest obstacol a fost
cauzat de faptul ca stilul aplicat elementelor de catre acest framework nu oferea librariei
permisiunea de a modifica elementele pentru a afisa harta.
4.4.2 CSS (Cascading Style Sheets)
In completarea acestui framework, pentru stilizari mai specifice ale aplicatiei am
folosit CSS. Acesta este un limbaj de stilizare a paginilor web, are rolul de a crea un mod
de prezentare placut al acestora. Modul de functionare al acestui limbaj se bazeaza pe
selectori si setarea stilului preferat al elementelor dorite. Cei mai des utilizati selectori sunt:
Numele tag-urilor: se aplica acelasi stil tuturor elementelor din cadrul
interfetei ce sunt create cu ajutorul tag-ului respectiv. Aceasta metoda se
poate dovedi ineficienta intrucat majoritatea paginilor web necesita stiluri
diferite pentru elementele generate prin intermediul aceleiasi etichete;
Clase: pot fi asignate clase tuturor elementelor ce se doresc a fi stilizate
urmand ca in documentul CSS sa fie definita clasa respectiva si setarea
atributelor dorite.
Id-uri: pentru modificarea unui singur element se recomanda utilizarea
id-urilor. Aceasta metoda este similara cu cea a claselor dar este de obicei
aplicata unui singur element din cadrul interfetei grafice.
Stilul paginilor poate fi definit prin mai multe metode, fie direct pe elementul dorit
prin intermediul atributului style al elementului HTML, fie prin utilizarea etichetei
<style></style> in HTML, iar in interior se poate scrie codul CSS. Acest lucru se poate
face prin crearea unui document nou CSS, implementarea stilulilor dorite in acesta fiind
urmata de includerea fisierului in proiect si crearea referintei catre acesta in codul HTML.
Decizia asupra utilizarii acestor metoda este realizata pe baza complexitatii stilizarii
necesare.
Pentru proiecte complexe, ce necesita o stilizare puternica, se recomanda utilizarea
unui preprocesor de compilare a CSS. Acesta are rolul de a permite dezvoltatorului sa
genereze si sa gestioneze stilizarile unei pagini intr-o maniera mai usoara. Cateva exemple
de preprocesoare ale CSS sunt SASS, LESS si Stylus, cel mai utilizat dintre acestea fiind
SASS. In cadrul aplicatiei dezvoltate in cazul de fata nu a fost necesara utilizarea unei

46
astfel de tehnologii intrucat optiunile oferite de Ionic Framework nu au avut nevoie de
imbunatatiri substantiale.

5.Concluzii si dezvoltari ulterioare

5.1 Concluzii
Scopurile lucrarii au fost indeplinite intrucat a fost dezvoltata o aplicatie mobile hibrida
care sa ajute ajute turistii sa descopere orasul Bucuresti intr-un mod inedit ce combina
utilizarea tehnologiei cu socializarea. Utilizatorii aplicatiei BucharestGO beneficiaza de o
serie de functionalitati care le permite acestora sa viziteze locuri ce reprezinta interes
pentru ei si sa se bucure de experienta unui mic joc de tip Treasure Hunt.
5.2 Dezvoltari ulterioare
O aplicatie se impune pe piata doar prin intermediul unei imbunatatiri continue a
functionalitatilor si adaugarea de unele functionalitati noi.
In cazul aplicatiei BucharestGO se pot introduce functionalitati suplimentare precum:
Introducerea conditiilor meteo ca parametri pentru selectarea obiectivelor. Aceasta
functionalitate poate fi de folos turistilor in situatii precum: un utilizator doreste sa
efectueze un traseu prin bucuresti in ciuda conditiilor atmosferice neprietenoase. In
aceste conditii aplicatia ar trebui sa exclude automat obiective precum parcuri;
Crearea unei comunitati online in care utilizatorii pot socializa si schimba pareri
legate de traseele parcurse;
Implementarea unui sistem de adaugare de poze pe parcursul traseului si la finalul
acestuia. O astfel de functionalitate ar fi o metoda in plus de schimbare de impresii
intre utilizatorii aplicatiei;
Extinderea ariei de functionalitate de la Bucuresti pe tot teritoriul tarii. Aceasta
imbunatatire a aplicatiei ar putea creste substantial numarul de utilizatori ai
aplicatiei. In acest fel, crescand profiturile si popularitatea aplicatiei in cadrul
turistilor;
O posibilitatea mai usoara de conectare in cadrul aplicatiei prin servicii de
autentificare cu retelele sociale;
Includerea in lista de obiecte a targurilor si festivalelor sezoniere. Astfel, se pot
selecta de exemplu targuri de craciun pe perioada iernii;

47
 O alta functionalitate ar putea fi reprezentata de posibilitatea cumpararii de bilete la
concertele ce au loc in perioada urmatoare;

48