Lucrare de Licent a [628660]

Universitatea Transilvania din Bra sov
Facultatea de Matematic a  si Informatic a
Program de studiu Informatic a Aplicat a
Lucrare de Licent  a
-Simulator transport public-
Autor: Bivol Simina-Lavinia
Coordonator: Conf. univ.dr. Deaconu Adrian
Bra sov, 2017

Cuprins
1 Introducere 3
2 Tehnologii utilizate 4
2.1 Platforma Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Arhitectura platformei Android . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Programarea pe platforma Android . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Google maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Google maps pentru dezvoltatorii de Android . . . . . . . . . . . . . . . . . 11
2.3 Tehnologiile folosite pentru comunicat ia client-server . . . . . . . . . . . . . . . . . 14
2.3.1 Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2 RESTful Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.3 JAX-RS s ,i implementarea Jersey . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.1 Ce este un sistem de versionare? . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.2 Git-cel mai popular sistem de versionare . . . . . . . . . . . . . . . . . . . . 20
2.5 Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 GTFS s ,i GTFS Realtime 23
3.1 GTFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 GTFS Realtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Aplicat ,ie licent , a (Simulator transport public) 29
4.1 Descrierea arhitecturii  si a funct ,ionalit at ,ii aplicat ,iei . . . . . . . . . . . . . . . . . . 29
4.2 Modulele funct ionale ale sistemului . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Modulul Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.1 Procesarea datelor GTFS s ,i realizarea unui format propriu . . . . . . . . . . 32
4.3.2 Procesarea datelor GTFS Realtime . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.3 Utilizarea datelor de realtime la nivel de server . . . . . . . . . . . . . . . . . 36
4.3.4 Accesarea resurselor serverului pe baza URL  si a protocolului HTTP . . . . 38
4.4 Modulul Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.1 Modelele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.2 Controllere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.3 Task-uri asincrone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.4 Elementele grace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5 Mod de utilizare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5 Concluzii s ,i perspective 54
2

1 Introducere
^In ziua de ast azi transport ^ n comun a devenit indispensabil societ at ,ii.Rolul s au este de a
accelera procesul deplas arii. Utilizatorii care folosesc transportul public sunt ^ n cres ,tere, iar co-
munit at ,ile locale extind s ,i ele serviciile de tranzit public.
Mijloacele de transport ^ n comun sunt mai sigure dec^ at vehiculele individuale. C al atoriile cu
transportul public reduc cantitatea de autoturisme pe drum s ,i scad probabilitatea accidentelor.
Pentru persoanele cu handicap, c al atoriile sunt, de asemenea, mai sigure datorit a modalit at ,ilor de
accesibilitate disponibile cum ar  rampe, ascensoare, centuri de sigurant , a s ,i multe altele care fac
tranzitul public accesibil comunit at ,ilor ^ ntregi.
Am decis s a dezvolt o aplicat ,ie mobil a ^ n Android care s a ^ mbun at at ,easc a buna funct ,ionare a
unui sistem de transport public s ,i anume am reus ,it s a pun la dispozit ,ia utilizatorilor date statice
^ n leg atura cu programul autovehiculelor din stat ,ii .Cele mai valoroase informat ,ii sunt ^ ns a cele
dinamice s ,i anume date de realtime care apar s ,i ele ^ n aplicat ,ie.
Pe l^ ang a toate acestea ^ n interfat ,a utilizatorilor apare s ,i o hart a pe care sunt desenate traseele
mijloacelor de transport dar s ,i cum acestea se deplasez a.
Un avantaj al aplicat ,iei este faptul c a poate folosi date de la orice agent ,ie de transport
care are datele ^ n format GTFS.Astfel utilizatorului ^ i sunt puse la dispozit ,ie o multitudine de
locat ,ii.Aplicat ,ia cont ,ine date din foarte multe colt ,uri ale lumii,de la date din Europa,p^ ana la date
din America.
Pentru realizarea acestei aplicat ii, am dezvoltat un sistem client-server, bazat pe cereri efectuate
de dispozitivele Android c atre un server web, care pune la dispozit ie resurse ce pot  accesate prin
adresele lor URL.
3

2 Tehnologii utilizate
2.1 Platforma Android
Android este o platform a software c^ at s ,i un sistem de operare pentru telefoane mobile,tablete
sau alte dispozitive bazat a pe kernel-ul Linux. ^In prezent este cel mai popular sistem de operare
dedicate dispozitivelor portabile.
Un mare avantaj al acestei platforme este faptul c a este o platform a deschis a.Aceasta a fost
creat a de Google s ,i a rulat pentru prima dat a ^ n anul 2008 pe telefonul T Mobile G1.Dezvoltarea
platformei a fost continuat a de consort ,iul comercial Open Handset Alliance ce include Google,
HTC, Intel, Motorola, Qualcomm, T-Mobile, Sprint Nextel s ,i Nvidia.
2.1.1 Arhitectura platformei Android
Structura platformei android este alcatuit a din mai multe straturi care comunic a ^ ntre ele. Aceasta
cuprinde 5 straturi grupate pe patru niveluri principale:Kernel Linux, biblioteci, motorul Android,
cadrul pentru aplicat ,ii s ,i aplicat ,ii.
Fiecare strat depinde de serviciile aduse de stratul de sub el.
Pentru a ^ nt ,elege c^ at mai bine aceste structuri vom ^ ncepe analiza pornind de la baza gurii
Fig.1 .
1.Kernelul Linux (cu unele modic ari) cont ,ine driver-ele pentru diferitele componente hard-
ware (ecran, camer a foto, tastatur a, anten a WiFi, memorie
ash, dispozitive audio), ind respon-
sabil cu gestiunea proceselor, memoriei, perifericelor (audio/video, GPS, WiFi), dispozitivelor
de intrare/ies ,ire, ret ,elei s ,i a consumului de energie; de asemenea, au fost implementate s ,i unele
^ mbun at at ,iri:
Binder, sistemul de comunicat ,ie inter-proces, a fost adaptat, ^ ntruc^ at reprezint a mediul de
comunicat ,ie principal dintre aplicat ,ii s ,i sistemul de operare, inclusiv funct ,iile (serviciile)
dispozitivului mobil; expunerea sa este realizat a prin intermediul AIDL (Android Interface
Denition Language) prin care pot  manipulate obiecte transformate ^ n primitive utilizate
la comunicat ,ia propriu-zis a dintre aplicat ,ii s ,i sistemul de operare.
Logger, sistemul de jurnalizare, este esent ,ial ^ n cazul ^ n care trebuie realizat a depanarea
aplicat ,iilor, ^ n special pentru a detecta anumite situat ,ii particulare (informat ,ii cu privire la
ret ,ea, senzori); acesta este capabil s a agrege datele provenite at^ at de la aplicat ,ia propriu-
zis a c^ at s ,i de la sistemul de operare, datele ind disponibile prin intermediul unor utilitare
specializate.
4

sistemul prin intermediul c aruia se previne transferul sistemului de operare ^ ntr-o stare de
latent , a (wake locks), ^ n care consumul de energie este redus, ^ ntruc^ at se blocheaz a execut ,ia
oric arei aplicat ,ii; utilizarea unui astfel de mecanism trebuie realizat a cu precaut ,ie, ^ ntruc^ at
poate determina epuizarea bateriei.
sistemul de alarme ofer a posibilitatea ca anumite sarcini s a e planicate la anumite momente
de timp, put^ and  executate, chiar dac a sistemul de operare se g ases ,te ^ ntr-o stare de latent , a.
Viking Killer este un mecanism prin care sistemul de operare revendic a memoria utilizat a,
atunci c^ and nivelul acesteia atinge un anumit prag (aplicat ,iile Android care au fost rulate
anterior sunt de regul a stocate ^ n memorie pentru a se putea comuta rapid ^ ntre ele, de vreme
ce ^ nc arcarea ^ n memorie este o operat ,ie costisitoare).
YAFFS2 (Yet Another Flash File System) este un sistem de s ,iere adecvat pentru cipuri

ash bazate pe port ,i NAND; platforma Android este stocat a pe mai multe partit ,ii, ceea ce
^ i confer a
exibilitate la actualiz ari, ^ mpiedic^ and modicarea sa ^ n timpul rul arii (/boot –
cont ,ine secvent ,a de pornire, /system – stocheaz a s ,ierele de sistem s ,i aplicat ,iile ^ ncorporate,
/recovery – det ,ine o imagine din care se poate restaura sistemul de operare, /data – include
aplicat ,iile instalate s ,i datele aferente acestora, /cache – utilizat a pentru s ,iere temporare,
folosind memoria RAM, pentru acces rapid).
2.Bibliotecile (user-space) cont ,in codul care ofer a principalele funct ,ionalit at ,i a sistemului de
operare Android, f ac^ and leg atura ^ ntre kernel s ,i aplicat ,ii. Sunt incluse aici motorul open-source
pentru navigare WebKit, biblioteca FreeType pentru suportul seturilor de caractere, baza de date
SQLite utilizat a at^ at ca spat ,iu de stocare c^ at s ,i pentru partajarea datelor specice aplicat ,iilor,
biblioteca libc (Bionic), biblioteca de sistem C bazat a pe BSD s ,i optimizat a pentru dispozitive
mobile bazate pe Linux, biblioteci pentru redarea s ,i ^ nregistrarea de cont ,inut audio/video (bazate
pe OpenCORE de la PacketVideo), biblioteci SSL pentru asigurarea securit at ,ii pe Internet s ,i Sur-
face Manager, bibliotec a pentru controlul accesului la sistemul de as ,are care suport a 2D s ,i 3D.
Aceste biblioteci nu sunt expuse prin API, reprezent^ and detalii de implementare Android.
3.Motorul Android ruleaz a serviciile de platform a precum s ,i aplicat ,iile care le utilizeaz a, ind
reprezentat de:
ART (Android Runtime) este mas ,ina virtual a Java care a fost implementat a ^ ncep^ and cu
versiunea 5.0, folosind un tip de compilare AOH (Ahead of Time), ^ n care bytecode-ul este
transpus ^ n cod mas ,in a la momentul instal arii, astfel ^ nc^ at acesta este executat direct de
mediul dispozitivului mobil; compatibilitatea cu versiuni anterioare (care folosesc mas ,ina
virtual a Dalvik, ce se bazeaz a pe un compilator JIT – Just in Time) este asigurat a prin
transformarea pachetelor^ n format .dex (Dalvik Executable) la momentul compil arii, urm^ and
5

ca translatarea ^ n format .oat s a se realizeze la momentul instal arii; ecare aplicat ,ie Android
ruleaz a ^ n procesul propriu, ^ ntr-o instant , a a mas ,inii virtuale ART, izol^ and astfel codul
s,i datele sale prin intermediul unor permisiuni, care se aplic a inclusiv la comunicat ,ia prin
intermediul interfet ,elor de comunicare oferite de sistemul de operare Android.
Zygote este procesul care gestioneaz a toate aplicat ,iile, ind lansat ^ n execut ,ie odat a cu
sistemul de operare:
-init ,ial, creeaz a o instant , a a mas ,inii virtuale Java pentru sistemul de operare Android, ^ n con-
textul c areia plaseaz a serviciile de baz a: gestiunea energiei, telefonie, furnizori de cont ,inut,
gestiunea pachetelor, serviciul de localizare, serviciul de notic ari;
-atunci c^ and este necesar s a lanseze ^ n execut ,ie o anumit a aplicat ,ie, se cloneaz a, partaj^ and
astfel componentele sistemului de operare Android, astfel ^ nc^ at s a se asigure performant ,a
(timp de execut ,ie) s ,i ecient ,a (memorie folosit a), de vreme ce ecare aplicat ,ie trebuie rulat a
^ n propria sa instant , a a mas ,inii virtuale Java
4.Cadrul pentru Aplicat ,iiexpune diferitele funct ,ionalit at ,i ale sistemului de operare Android
c atre programatori, astfel ^ nc^ at aces ,tia s a le poat a utiliza ^ n aplicat ,iile lor.
5.La nivelul de aplicat ,iise reg asesc at^ at produsele ^ mpreun a cu care este livrat dispozitivul
mobil (Browser, Calculator, Camera, Contacts, Clock, FM Radio, Launcher, Music Player, Phone,
S Note, S Planner, Video Player, Voice Recorder), c^ at s ,i produsele instalate de pe Play Store sau
cele dezvoltate de programatori.[1]
6

Fig. 1: Arhitectura platformei Android [1]
7

2.1.2 Programarea pe platforma Android
Dezvoltarea aplicat ,iilor android oblig a dezvoltatorii s a separe funct ionalit at ile unui program
de interfat ,a grac a, pentru ca operat iile s a nu o blocheze. De aceea operat iile din spate trebuie s a
ruleze ^ n thread-uri separate.
Prin folosirea pattern-ului Model-View-Controller se separ a reprezentarea informat ,iilor de
interfat ,a cu utilizatorul.
Fig. 2:
Model-View-Controller1. Modelul ret ,inele datele s ,i gestioneaz a comportamentul
aplicat ,iei.Acesta trebuie realizat astfel^ nc^ at s a poat a  folosit
f ar a a  modicat pentru diferite interfet ,e.^In Android modelul
se identic a prin Content Providers ce este o clas a public a,
abstract a care gestioneaz a accesul la un anumit set de date
 si ofer a mecanisme pentru securitatea datelor.
2. Controlerul asigura comunicat ,ia^ ntre interfat , a s ,i model.Acesta
poate trimite comenzi interfet ,ei pentru a ^ s ,i modica felul ^ n
care as ,eaza modelul c^ at s ,i comenzi modelului pentru a ^ s ,i
modica starea. ^In Android controler-ele sunt reprezentate de
Servicii (Services).Serviciile sunt componente de baz a care se
comport a c a daemonii UNIX  si serviciile Windows.
3. In general vizualizarea este o mini aplicatie ce ajuta la
randarea unor informatii, avand la baza diverse template-
uri.Ea cuprinde elemente grace (texte, input-uri ale formu-
larelor,butoane).Pot exista mai multe vizualizari si control-
ere pentru un singur model, av^ and scopuri diferite. ^In Android view-urile sunt Activit at ile
(Activity).Activity este principala component a a interfet ,ei cu utilizatorul, este derivat a
din clasa public a Java Activity (android.app.Activity)  si este container pentru View (an-
droid.view.View). Activity interact ,ioneaz a cu utilizatorul  si creeaz a o fereastr a ^ n care se
poate plasa UI (User Interface).
Aplicat ,iile standard Android se implementeaz a in limbajul Java care mai apoi sunt compilate
^ n bytecode Dalvik. Acest pas implic a o vitez a medie de execut ,ie dar s ,i acces la cele mai multe
biblioteci ale sistemului.
Avem nevoie de Android SDK pentru dezvoltarea aplicat ,iilor. ^In urma compilarii rezult a pachete
.apk care pot  instalate de dispozitive mobile sau pot  rulate pe dispozitive virtuale (AVD).
8

Cerint ,e obligatorii pentru dezvoltarea unei aplicat ,ii Android:
kit-ul de dezvoltare pentru limbajul de programare Java
SDK-ul de Android ^ mpreun a cu denit ,iile corespunz atoare unuia sau mai multor niveluri
de API
un mediu integrat de dezvoltare (IDE)
-Elipse care cont ,ine plugin-ul ADT (Android Developer Tools)
-Android Studio
un dispozitiv pe care s a se ruleze aplicat ,iile
-un emulator(Android Virtual Device care se g ases ,te ^ n SDK-ul de Android,Genymotion)
-un telefon mobil cu sistemul de operare Android pentru care s-a dezvoltat aplicat ,ia
Componentele unei aplicat ii standard
Componentele sunt elementele de baz a ale unei aplicat ii. Ele reprezint a puncte de interact iune
cu aplicat ia, din partea utilizatorului sau a sistemului, a altor aplicat ii etc. Exist a patru tipuri de
componente:
Activit at i (Activity): ecare ecran al interfet ei utilizator este creat printr-o activitate. Spre
exemplu, un joc ar putea avea o activitate pentru meniul principal, o activitate pentru
fereastr a de opt iuni, una pentru ecranul de joc etc. Activit at ile sunt independente, ^ n sensul
c a o alt a aplicat ie poate apela oricare din activit at ile aplicat iei dezvoltate de noi, dac a dorim
acest lucru. O activitate este implementat a ca subclas a a clasei Activity
Servicii (Service): serviciile sunt componente care ruleaz a ^ n fundal, pentru interact iunea
cu alte procese sau pentru a desf a sura act iuni ^ ndelungate, f ar a interact iune cu utilizatorul.
Spre exemplu un serviciu poate derula muzic a pentru joculet ul nostru. Un serviciu este
implementat ^ n cod sub form a unei subclase a clasei abstracte Service.
Furnizori de cont inut (Content providers): un furnizor de cont inut este folosit pentru a
gestiona datele, publice sau private, folosite de aplicat ie. El scrie  si cite ste din sisteme de
 siere, baze de date SQLite, ^ n ret ea etc.  si poate  apelat de c atre alte aplicat ii pentru a
furniza date, dac a dorim acest lucru. Un furnizor de cont inut este implementat ca subclas a
a clasei abstracte ContentProvider.
Receptori de broadcast (Broadcast receivers): un receptor de broadcast este o component a
ce r aspunde la anunt urile de interes general din sistem (ex: anunt  c a ecranul a fost stins,
c a bateria este aproape desc arcat a etc.). Receptorii de broadcast nu au interfat  a cu utiliza-
torul, ^ ns a pot crea notic ari  si pot semnala alte componente ale aplicat iei. Un receptor de
broadcast este implementat c a subclasa a clasei abstracte BroadcastReceiver.
9

O plicat ie poate apela o component a a unei alte aplicat ii. La apelul unei componente, se
veric a dac a este pornit deja un proces pentru aplicat ia din care face parte  si se porne ste unul
dac a nu exist a deja. Prin urmare, aplicat iile Android nu au un singur punct de intrare (nu exist a
funct ia main). Apelul unei component a dintr-o alt a aplicat ie nu se face ^ ns a direct, din motive de
securitate, ci prin intermediul sistemului de operare, cu ajutorul unui intent.[2]
Resursele unei aplicat ,ii Android
Resursele sunt stocate ^ n directorul res din cadrul aplicat ,iei. Pentru a gestiona diferite tipuri
de resurse, directorul res al proiectului cont ine subdirectoare specice:
Director Descriere resursa
resanimator siere XML ce denesc proprietatile animatiilor
res/anim/ siere XML pentru animatii bazate pe transformari
res/color/ siere XML ce denesc culori
res/drawable/ Fisiere bitmap (.png, .jpg, .gif) sau siere XML ce denesc resurse
ce pot  desenate
res/layout/ siere XML ce denesc design-ul interfetei
res/menu/ siere XML ce denesc meniurile aplicatiei
res/raw/ siere diferite in format binar sau text
res/values/ siere XML care contin valori simple, cum ar  siruri de caractere,
numere intregi si culori. Este recomandat sa utilizati conventiile de
nume de siere pentru anumite tipuri de resurse: arrays.xml (typed
arrays), colors.xml , dimens.xml, strings.xml , styles.xml
res/xml/ siere XML care pot  citite Resources.getXML()
2.2 Google maps
Google Maps este o aplicat ie gratuit a dezvoltat a de Google s ,i este un serviciu de hart ,i ce ne
ofer a diferite informat ,ii geograce.
Utiliz^ and acest serviuciu putem benecia de anumite functii precum :
Cautare locuri  si indicat ii de la o locat ie la alt a.
Navigare stradal a cu ajutorul imaginilor panoramice 360din diferite ora se.
Obt inere de informat ii despre trac.
Folosire API cu ajutorul c aruia putem customiza h art ile  si putem obt ine informat ii.
Un avataj al acestei aplicat ii este faptul c a telefonul pe care este instalat a nu trebuie s a cont in a
neap arat cu un receptor GPS ca ^ n cazul dispozitivelor de navigat ie GPS. ^Ins a dezavantajul pentru
10

o buna perioada de timp era c a h art ile se ^ ncarcau direct de pe Internet a sa ^ nc^ at atunci c^ and
doreai s a folose sti aplicat ia trebuie s a i conectat la Internet,dar totusi recent cei la Google au
f acut posibil a folosirea aplicat ie  si f ar a internet prin salvarea h art ilor .
2.2.1 Google maps pentru dezvoltatorii de Android
Funct ,ionalit at ,ile oferite pentru dezvoltatori sunt:
furnizarea de servicii integrate pentru localizare, av^ and urm atoarele caracteristici: nivelul de
detaliu este determinat ^ n funct ,ie de specicat ,iile utilizatorului (precizie ^ nalt a sau consum
sc azut de energie), disponibilitate imediat a a celei mai recente locat ,ii disponibile, optimizarea
nivelului de utilizare al bateriei, lu^ andu-se ^ n considerare solicit arile existente raportat la
senzorii care pot  utilizat ,i,
exibilitatea ^ n gama de servicii oferite (utilizarea ^ n interfat ,a
grac a a aplicat ,iei, cu un nivel de detaliu ridicat sau folosirea de c atre servicii, cu un nivel
de detaliu sc azut);
oferirea unei liste cu punctele de interes din proximitate, raportat la un anumit domeniu
(locat ,ii turistice, tipuri de organizat ,ii), acestea put^ and  marcate cu ajutorul unor controale
grace dedicate; pentru ecare punct de interes pot  obt ,inute informat ,ii suplimentare (de-
scrieri, cont ,inut multimedia), acestea put^ and  furnizate s ,i de utilizator, ind stocate ulte-
rior ^ ntr-o baz a de date Google; se poate determina astfel s ,i locat ,ia curent a ^ mpreun a cu
alte repere din zon a; denumirile specice ale locurilor respective precum s ,i adresele core-
spunz atoare pot  completate facil prin indicarea unor sugestii ce cont ,in variantele disponi-
bile;
transmiterea de notic ari legate de restrict ,ia zonal a (eng. geofencing), prin indicarea unor
coordonate a
ate ^ n proximitate anumitor locat ,ii: pot  gestionate mai multe arealuri ge-
ograce de acet tip concomitent, f ar a a avea un impact semnicativ asupra consumului de
energie (actualiz arile cu privire la locat ,ia curent a sunt realizate ^ n funct ,ie de distant ,a fat , a
de zona marcat a precum s ,i de tipul de activitate – stat ,ionar sau ^ n mis ,care: mers, alergat,
^ n vehicul, cu bicicleta); sunt oferite informat ,ii at^ at cu privire la intrarea ^ n arealul geograc
c^ at s ,i cu privire la ies ,irea din acesta;
determinarea activit at ,ii pe care utilizatorul o desf as ,oar a ^ n mod curent (stat ,ionar sau ^ n
mis ,care: mers, alergat, ^ n vehicul, cu bicicleta), f ar a un consum de baterie important (folosind
senzori de putere mic a); o astfel de funct ,ionalitate este foarte util a ^ n contextul integr arii
cu aplicat ,iile care necesit a actualiz ari cu privire la locat ,ia curent a, frecvent ,a cu care sunt
solicitate acest set de date ind determinat a de tipul de activitate a
at ^ n desf as ,urare.[1]
Pas ,i folosire Google Maps API:
11

1. Pentru a avea acces la aceste servicii trebuie s a se activeaze API-ul Google Maps Android API
prin generarea unei chei Android pentru aplicat ia care ruleaz a pe dispozitivul mobil.Pentru
ecare proiect trebuie s a se precizeze urm atorii parametri:denumirea,identicatorul pentru
proiect (este generat^ n mod automat, ^ ns a poate  congurat suplimentar de c atre utilizator).
Fig. 3: Exemplu de cheie
2. Pe dispozitivul mobil (zic sau virtual) pe care se va rula aplicat ,ia care acceseaz a serviciul de
localizare, trebuie s a se g aseasc a cea mai recent a versiune de Google Play Services, asociindu-
se totodat a contul de utilizator Google pentru care s-a generat cheia public a.
3. Se instaleaz a SDK-ul Google Play Services, necesar acces arii serviciului de localizare prin
intermediul unei aplicat ,ii Android. Posibilitatea de instalare a acestor pachete exist a s ,i din
12

mediul integrat de dezvoltare Android Studio, prin accesarea opt ,iunii Tools!Android!
SDK Manager, sect ,iunea SDK Tools.
4.^In mediul integrat de dezvoltare Android Studio, se creeaz a un proiect corespunz ator unei
aplicat ,ii Android, av^ and urm atoarele propriet at ,i:
denumirea pachetului care identic a aplicat ,ia Android ^ n mod unic trebuie s a e aceeas ,i
cu cea precizat a ^ n momentul ^ n care a fost generat a cheia public a;
^ n s ,ierulbuild.gradle| s a se specice dependint ,a c atre biblioteca Google Play Ser-
vices (com.google.android.gms:play-services),^ n sect ,iunea dependencies: compile 'com.google.android.gms:play-
services:10.2.4'
^ n s ,ierul AndroidManifest.xml se indic a permisiunile necesare:
Fig. 4: Android.Manifest.xml
pentru redarea h art ,ilor, precum s ,i pentru operat ,iile de tip zoom, este necesar a folosirea
bibliotecii OpenGL
<uses-feature
android:glEsVersion="0x00020000"
android:required="true" / >
^ n sect ,iunea <application >. . .</application >se indic a: cheia public a utilizat a pentru
accesarea funct ,ionalit at ,ii legat a de serviciile de localizare
<metadata
android:name="com.google.android.maps.v2.API KEY"
android:value="AIzaSyARiJhQ Lj6HnzQwq7MqAvjWQtNkjVcprs" / >
13

versiunea folosit a pentru biblioteca Google Play Services (preluat a din cadrul proiectu-
lui referit)
<metadata
android:name="com.google.android.gms.version" android:value="@integer/google play services version"
/>
2.3 Tehnologiile folosite pentru comunicat ia client-server
2.3.1 Apache Tomcat
Apache Tomcat este un server web deschis, ind dezvoltat s ,i ment ,inut de Apache Software
Foundation. Acesta este o implementare software pentru tehnologiile Java  si ruleaz a pe Java
Servlets s ,i JSP-uri(pagini JavaServer).Acesta este disponibil pentru platformele Windows s ,i Linux.
Tomcat asigur a suportul pe Java Servlet s ,i JSP-uri pentru paginile dinamice servite,pe cand
Apache HTTP Server nu este compatibil cu acestea. De asemenea, Tomcat funct ,ioneaz a ca un
server de testare  si poate rula ^ n diferite moduri pentru a se garanta o bun a performant , a. El se
poate folosi ca un server web f ar a Apache HTTP Server.
Tomcat este cu sigurant  a cea mai bun a opt iune pentru a  pus a ^ n aplicare pentru utilizatorii
care au nevoie s a ruleze pagini JavaServer sau Java Servlets. Cu toate acestea, ^ n cazul ^ n care se
execut a simultan multe pagini statice sau este nevoie de alte tehnici dinamice, este mai potrivit s a
se opteze pentru Apache HTTP Server s ,i s a se ruleze Tomcat ^ n proces sau ^ n afara procesului.
Componente Tomcat:
Tomcat 4 a fost lansat cu urm atoarele componente:
Catalina este containerul de servlet al lui Tomcat. Catalina implementeaz a specicat iile
Sun Microsystems pentru servlet  si Pagini JavaServer (JSP). ^In Tomcat, un element Realm
reprezint a o "baza de date" cu nume de utilizator, parole  si roluri (similare grupurilor Unix)
atribuite acelor utilizatori. Implement arile diferite ale Realm permit Catalinei s a e integrat a
^ n medii ^ n care astfel de informat ii de autenticare sunt deja create  si ^ ntret inute  si apoi s a
utilizeze aceste informat ii pentru a implementa Container Managed Security a sa cum este
descris ^ n Specicat ia Servlet.
Coyote este o component a Connector pentru Tomcat care accept a protocolul HTTP 1.1
c a server web. Acest lucru permite Catalinei, care este ^ n mod obi snuit un servlet Java
sau un container JSP, s a act ioneze  si c a un server web simplu care serve ste  siere locale c a
documente HTTP.
14

Coyote ascult a conexiunile de intrare la server de pe un port TCP specic  si transmite
cererea c atre Tomcat Engine pentru a procesa cererea  si a trimite un r aspuns ^ napoi clientului
solicitant. Un alt Coyote Connector, Coyote JK, ascult a ^ n mod similar, dar ^ nainteaz a
cererile sale c atre un alt server web, cum ar  Apache, folosind protocolul JK.Acest lucru
ofer a de obicei o performant  a mai bun a.
Jasper este motorul JSP al lui Tomcat. Jasper analizeaz a  sierele JSP pentru a le compil a
^ n cod Java c a servlet-uri (care pot  gestionate de C at alina). ^In timpul execut iei, Jasper
detecteaz a modic arile aduse  sierelor JSP  si le recompila. ^Incep^ and cu versiunea 5, Tomcat
utilizeaz a Jasper 2, care este o implementare a specicat iei JSP 2.0 a Sun Microsystems.
Trei componente noi au fost ad augate cu lansarea Tomcat 7:
Cluester(grup) Aceast a component a a fost ad augat a pentru a gestiona aplicat ii mari. Se
utilizeaz a pentru echilibrarea ^ nc arc arii care poate  obt inut a prin multe tehnici. Suportul
pentru clustering necesit a ^ n prezent versiunea 1.5 sau JDK .
High availability(Valabilitate mare) A fost ad augat a o caracteristic a de disponibilitate
^ nalta pentru a facilita programarea actualiz arilor de sistem (de exemplu, lans ari noi, cereri
de modicare) f ar a a afecta mediul live. Acest lucru se face prin expedierea cererilor de trac
live c atre un server temporar pe un port diferit, ^ n timp ce serverul principal este modernizat
pe portul principal. Este foarte util ^ n gestionarea solicit arilor utilizatorilor pe aplicat ii web
de mare trac.
Aplicatie web De asemenea, a fost ad augat a o ^ mbun at at ,ire a aplicat ,iilor web bazate pe
utilizator s ,i pe sistem, pentru a ad auga suport pentru implementare ^ n ^ ntreaga gam a de
medii. De asemenea, ^ ncearc a s a gestioneze sesiunile, precum s ,i aplicat ,iile din ^ ntreaga ret ,ea.
2.3.2 RESTful Web Services
REST (Transfer de stare reprezentat ,ional) este un stil arhitectural s ,i o abordare a comunicat ,iilor
care este adesea folosit a ^ n dezvoltarea serviciilor Web. Utilizarea REST este adesea preferat a ^ n
comparat ,ie cu stilul SOAP (Simple Object Access Protocol) cu o greutate mai mare, deoarece
REST nu utilizeaz a o l at ,ime de band a la fel de mare, ceea ce o face mai bine pentru utilizare pe
Internet. Abordarea SOAP necesit a scrierea sau utilizarea unui program de server furnizat (pentru
a servi date) s ,i a unui program client (pentru a solicita date).
De ret ,inut despre REST ar  faptul c a este o arhitectur a client-server care, printre altele, uti-
lizeaz a capacitatea complet a a protocolului HTTP.
15

Fiecare adres a URL de pe server reprezint a o resurs a. Fie o resurs a de colect ,ii, e o resurs a
element.
O resurs a de tip colect ,ie ar putea  disponibil a la un URL ca http:localhost:8080/rest/items/
care ar reprezenta o list a de elemente.
O resurs a de tip element ar putea  disponibil a la un URL ca http:localhost:8080/rest/items/4
care ar reprezenta singur element, identicat prin pozit ,ia 4.
Resursele sunt manipulate folosind un set x de patru operat ,iuni de creare, citire, actualizare,
s,tergere: PUT, GET, POST s ,i DELETE. PUT creeaz a o nou a resurs a, care poate  ulterior s ,tears a
utiliz^ and DELETE. GET preia starea curent a a unei resurse ^ n unele reprezent ari. POST transfer a
o stare nou a pe o resurs a.
Avantajele serviciilor Web RESTful
Rapid: Serviciile Web RESTful sunt rapide deoarece nu exist a specicat ,ii stricte precum SOAP.
Ea consum a mai put ,in a l at ,ime de band a s ,i resurse.
Limba s ,i platforma independente: serviciile de web RESTful pot  scrise ^ n orice limbaj de
programare s ,i executate ^ n orice platform a.
Poate utiliza SOAP: cele mai restante servicii web pot utiliza serviciile web SOAP ca imple-
mentare.
Permite formatul diferit de date: serviciul Web REST permite formatul de date diferit, cum
ar  Text simplu, HTML, XML s ,i JSON.
2.3.3 JAX-RS s ,i implementarea Jersey
JAX-RS(Java API pentru servicii Web RESTful ) este un API pentru limbajul de programare
Java care ofer a suport ^ n crearea de servicii web conform modelului arhitectural de reprezentare a
transferului de stare (REST).
JAX-RS utilizeaz a adnot ari, introduse ^ n Java SE 5, pentru a simplica dezvoltarea s ,i imple-
mentarea client ,ilor serviciului web s ,i a obiectivelor nale.
16

Adnotare Descriere
@Path Calea relativ a a clasei / metodei de resurse.
@GET Obt ,inet ,i solicitarea, utilizat a pentru a prelua resursele.
@PUT Cerere utilizat a pentru a crea o resurs a.
@POST Cerere utilizat a pentru crearea / actualizarea resurselor.
@DELETE Cerere utilizat a pentru a s ,terge resursele.
@HEAD Cerere utilizat a pentru a obt ,ine statutul disponibilit at ,ii metodei.
@Produces Declar a r aspunsul HTTP generat de serviciul web. De exemplu,
aplicat ,ii / XML, TEXT / HTML, APPLICATION / JSON etc.
@Consumes Declar a tipul de solicitare HTTP. De exemplu pentru a accepta
datele formate ^ n corpul HTTP ^ n timpul solicit arii POST.
@PathParam Leaga parametrul transmis metodei la o valoare ^ n cale.
@QueryParam Leag a parametrul trecut la metoda unui parametru de interogare
din cale.
@MatrixParam Leag a parametrul transmis metodei la un parametru de matrice
HTTP ^ n cale.
@HeaderParam Leag a parametrul transmis metodei ^ ntr-un antet HTTP.
@CookieParam Leag a parametrul transmis metodei la un modul cookie.
@FormParam Leag a parametrul transmis metodei la o valoare de formular.
@DefaultValue Aloc a o valoare implicit a unui parametru transmis metodei.
@Context Contextul resursei. De exemplu, HTTPRequest ca context.
JAX-RS sprijin a crearea de XML s ,i JSON prin Java Architecture for XML Binding (JAXB).
Jersey este implementarea de referint , a pentru specicat ,ia JAX-RS.
Implementarea Jersey ofer a o bibliotec a pentru a implementa webservicele Restful ^ ntr-un con-
tainer de servlet Java.
Pe partea serverului, Jersey ofer a o implementare servlet care scaneaz a clase predenite pentru
a identica resursele RESTful. ^In s ,ierul de congurare web.xml, ^ nregistrat ,i acest servlet pentru
aplicat ,ia dvs. web.
Implementarea Jersey ofer a, de asemenea, o bibliotec a de client ,i pentru a comunica cu o web-
service RESTful.
Adresa URL de baz a a servletului este:
http: // domeniu: port / as ,are nume / url-model / calea catre clasa rest
Acest servlet analizeaz a cererea HTTP primit a s ,i selecteaz a clasa s ,i metoda corecte pentru a
r aspunde la aceast a solicitare. Aceast a select ,ie se bazeaz a pe adnot ari din clas a s ,i metode.
O aplicat ,ie web REST const a, prin urmare, din clase de date (resurse) s ,i servicii. Aceste dou a
17

tipuri sunt de obicei ment ,inute ^ n pachete diferite, deoarece servletul Jersey va  instruit prin
intermediul web.xml pentru a scana anumite pachete pentru clasele de date.
Pentru a folosi Jersey trebuie s a avem biblioteca com.sun.jersey s,i s a denim dispecerul de
servlet Jersey din s ,ierul web.xml al aplicat ,iei.
Fig. 5: Fis ,ierul web.xml
Un model de resurs a care accept a HTTP GET s ,i are drept r aspuns "Hello Jersey" este urm atoarea
clas a :
Fig. 6: Resurs a Jersey
Identicatorul de resurse va : http://localhost:8080/Jersey/rest/hello
18

2.4 Git
2.4.1 Ce este un sistem de versionare?
Controlul versiunilor este un sistem care ^ nregistreaz a modic arile aduse unui s ,ier sau unui
set de s ,iere ^ n timp, astfel ^ nc^ at s a putet ,i ret ,ine anumite versiuni mai t^ arziu.
Spre exemplu dac a suntet ,i un designer grac sau web s ,i dorit ,i s a p astrat ,i ecare versiune a
unei imagini sau a unui aspect (pe care at ,i dori cu sigurant , a), un sistem de control al versiunii
(version control system) este un lucru foarte ^ nt ,elept de folosit. V a permite s a readucet ,i s ,ierele la
o stare anterioar a, s a readucet ,i ^ ntregul proiect la o stare anterioar a, s a comparat ,i modic arile ^ n
timp, s a vedet ,i cine a modicat ultima oar a ceva care ar putea cauza o problem a, cine a introdus
o problem a s ,i c^ and. Utilizarea unui sistem de versionare ^ nseamn a, de asemenea, c a, dac a strici
lucrurile sau pierzi s ,ierele, le pot ,i recupera cu us ,urint , a.
Clasicarea sistemelor de control al versiunilor
^In prezent, sunt folosite trei tipuri de sisteme de control a versiunilor, ecare dintre acestea
ind adecvate unei anumite situat ,ii:
sisteme locale de control a versiunilor , ^ n cazul ^ n care se dores ,te monitorizarea vari-
antelor unui s ,ier exclusiv pe discul local; ^ n baza de date, versiunile sunt ret ,inute sub
forma diferent ,elor (rezultatul comenzii di) dintre versiuni succesive, astfel c a se poate reveni
oric^ and la o stare anterioar a (exemplu: rcs);
sisteme centralizate de control a versiunilor implic a stocarea diferent ,elor dintre ver-
siuni ^ ntr-o baz a de date rezident a pe un server dedicat, la care au acces tot ,i utilizatorii
implicat ,i, astfel ^ nc^ at ecare poate consulta versiunea curent a (exemple: CVS, Subversion,
Perforce);
-avantaje: posibilitatea de colaborare ^ ntre echipe care lucreaz a la acelas ,i proiect, stabilirea
de drepturi cu privire la s ,ierele ce pot  ^ nc arcate pe server de ecare utilizator ^ n parte;
-dezavantaje: ^ n cazul c^ and serverul dedicat pe care g ases ,te baza de date cu tot istoricul ver-
siunilor se defecteaz a, exist a riscul de a se pierde toate aceste informat ,ii (dac a nu exist a copii
de sigurant , a), p astr^ andu-se doar versiunile salvate pe mas ,inile utilizatorilor; mai mult, ^ ntr-o
astfel de situat ,ie utilizatorii se a
 a ^ n incapacitatea de a mai transmite propriile modic ari
s,i de a consulta modic arile celorlalt ,i;
sisteme distribuite de control a versiunilor ^ n care consultarea st arii actuale a unui
s,ier presupune s ,i desc arcarea, pe discul local, a ^ ntregului istoric de modic ari astfel ^ nc^ at
acesta s a poat a  reconstituit ^ n situat ,ii precum defectarea serverului; de asemenea, acestea
au capacitatea de a gestiona mai multe depozite a
ate la distant , a, chiar ^ n cazul ^ n care
19

acestea cont ,in acelas ,i proiect, permit ,^ and stabilirea unor anumite
uxuri de transmitere a
informat ,iei (exemple: Git, Mercurial, Bazaar, Darcs);[1]
2.4.2 Git-cel mai popular sistem de versionare
De departe, cel mai utilizat sistem de control al versiunii moderne din lume este Git. Git este un
proiect deschis, ^ ntret ,inut ^ n mod activ, init ,ial realizat ^ n 2005 de c atre Linus Torvalds, faimosul
creator al kernel-ului sistemului de operare Linux. Un num ar uluitor de proiecte software se bazeaz a
pe Git pentru controlul versiunii, inclusiv proiecte comerciale s ,i open source.
Comunitatea de utilizatori a lui Git a creat numeroase resurse pentru a instrui dezvoltatorii,
iar popularitatea lui Git us ,ureaz a obt ,inerea de ajutor atunci c^ and avet ,i nevoie. Aproape ecare
mediu de dezvoltare are suport Git s ,i instrumentele din linia de comand a Git ruleaz a pe ecare
sistem de operare major.
De ecare dat a c^ and salvezi proiectul tau, Git creeaz a o consemnare(commit).O consemnare
este un instantaneu al tuturor s ,ierelor la un moment dat. Dac a un s ,ier nu s-a schimbat de la o
consemnare la alta, Git utilizeaz a s ,ierul stocat anterior. Acest design difer a de alte sisteme care
stocheaz a o versiune init ,ial a a unui s ,ier s ,i p astreaz a o evident , a a schimbarilor ^ n timp.
Fig. 7: Leg aturi consemn ari[3]
Consemnarile creeaz a leg aturi c atre alte consemn ari, form^ and un grac al istoricului dezvolt arii.
Putet ,i s a revenit ,i la un cod al unei consemn ari anterioare, s a examinat ,i modul ^ n care s ,ierele s-au
schimbat de la o consemnare la alta s ,i s a examinat ,i informat ,iile, cum ar  locul s ,i momentul ^ n care
au fost efectuate modic arile. Consemn arile sunt identicate^ n Git printr-un hash criptograc unic
al cont ,inutului lor. Este imposibil s a se fac a schimb ari, s a se piard a informat ,ii sau s ,iere corupte
f ar a ca Git s a le detecteze.
Git furnizeaz a instrumente pentru izolarea schimb arilor s ,i apoi reunirea lor ^ mpreun a. Ra-
murile(branches) gestioneaz a aceast a separare. Odat a ce lucrarea creat a ^ ntr-o ramu a este termi-
nat a, o putem ^ mbina la ramura principal a (sau master) .
20

Fig. 8: Ramur a[3]
Fis ,ierele din Git se a
 a ^ ntr-una din cele trei st ari: modicate, ^ nscrise sau consemnate. C^ and
modic am pentru prima dat a un s ,ier, modic arile exist a numai ^ n directorul nostru de lucru.
Ele nu fac parte ^ nc a din consemnare sau din istoria dezvolt arii. Trebuie s a as ,ez am s ,ierele
modicate pe care dorim s a le includem ^ n consemnare (putem omite s ,ierele pe care dorim s a
le consemn am separat). Zona de as ,teptare cont ,ine toate modic arile pe care le vet ,i include ^ n
urm atoare consemnare. Odat a ce suntet ,i mult ,umit de s ,ierele alese, consemnat ,i-le cu un mesaj
care descrie ce s-a schimbat. Aceast a consemnare devine o parte din istoria dezvolt arii.
Fig. 9: St ari s ,ire din Git[3]
Un mare beneciu al Git-ului este dezvoltare simultan a. Toat a lumea are propria copie local a
de cod s ,i poate lucra simultan pe propriile ramuri. Git funct ,ioneaz a atunci c^ and suntem oine,
deoarece aproape ecare operat ,ie este local a.
Un al plus este reprezentat de integrarea ^ ncorporat a. Datorit a popularit at ,ii sale, Git este
integrat ^ n majoritatea instrumentelor s ,i produselor. Fiecare IDE major are suport Git ^ ncorporat
s,i multe instrumente care ne permit s a gestion am integrarea continu a, implementarea continu a,
testarea automat a, urm arirea elementelor de lucru, m asur atorile s ,i integrarea caracteristicilor de
raportare cu Git. Aceast a integrare ne simplic a
uxul de lucru zilnic.
21

2.5 Maven
Apache Maven este un instrument de automatizare pentru proiecte Java.
Maven este un proiect open source ^ n cadrul Apache ^ nc a din 2003. Av^ and ^ n vedere sprijinul
s au puternic s ,i popularitatea imens a, Maven este foarte stabil s ,i bogat ^ n funct ,ii, oferind numeroase
pluginuri care pot face orice, de la generarea versiunilor PDF ale documentat ,iei proiectului dvs.
p^ an a la generarea unei liste de modic ari recente de la CSM. Tot ceea ce este necesar pentru a
ad auga aceast a funct ,ie este o cantitate mic a de extra XML sau un parametru suplimentar de linie
de comand a.
Fiecare proiect cont ,ine un s ,ier numit POM (Project Object Model), care este doar un s ,ier
XML care cont ,ine detalii despre proiect. Unele dintre aceste detalii ar putea include numele
proiectului, versiunea, tipul pachetului, dependent ,ele, pluginurile Maven etc.
Un s ,ier pom.xml simplu ar putea ar ata astfel:
Fig. 10: pom.xml
Acestea sunt cele mai comune faze de ciclu de viat , a implicite executate:
validate valideaz a dac a proiectul este corect s ,i toate informat ,iile necesare sunt disponibile
compile compileaz a codul surs a al proiectului
22

test testeaz a codul surs a compilat utiliz^ and un cadru adecvat pentru testarea unit at ,ilor.
Aceste teste nu ar trebui s a impun a codului s a e ^ mpachetat sau implementat
package ia codul compilat s ,i ^ l ^ mpacheteaz a ^ n format care se poate distribui, cum ar
JAR.
integration-test proceseaz a s ,i implementeaz a pachetul, dac a este necesar, ^ ntr-un mediu ^ n
care se pot executa teste de integrare
verify execut a orice veric ari pentru a vedea dac a pachetul este valabil s ,i ^ ndeplines ,te cri-
teriile de calitate
install instaleaz a pachetul ^ n depozitul local, pentru a  folosit ca o dependent , a ^ n alte
proiecte la nivel local
deploy realizeaz a ^ ntr-un mediu de integrare sau de lansare, copiaz a pachetul nal ^ n depoz-
itul de la distant , a pentru a permite accesul altor dezvoltatori s ,i proiecte.
clean cur at , a artefactele create de build-urile anterioare
sitegenereaz a documentat ,ia site-ului pentru acest proiect
3 GTFS s ,i GTFS Realtime
3.1 GTFS
Specicat ,ia privind
uxul general de tranzit (General Transit Feed Specication[GTFS]), cunos-
cut a s ,i sub denumirea de tranzit static sau GTFS static , denes ,te un format comun pentru pro-
gramele de transport public s ,i informat ,iile geograce asociate.
Specicat ,ia init ,ial a pentru GTFS a fost dezvoltat a de TriMet s ,i Google ca ind "Specicat ,ia

uxului Google Transit" s ,i a fost lansat a la sf^ ars ,itul anului 2005. De atunci, datele GTFS au fost
create pentru sute de agent ,ii de tranzit din SUA s ,i peste o mie de agent ,ii din lume. Numele a fost
schimbat la Specicat ,ia
uxului general de tranzit atunci c^ and a devenit un standard deschis,el
ind ^ n continu a dezvoltare.
GTFS permite agent ,iilor de transport ^ n comun s a publice datele de tranzit, iar dezvoltatorii
scriu aplicat ,ii care consum a aceste date. Seturile de date GTFS sunt utilizate ^ ntr-o varietate de
tipuri de aplicat ,ii, inclusiv planicatori de excursii, cum ar  Google Maps, aplicat ,ii mobile, soft-
ware pentru generarea orarelor, instrumente pentru planicarea tranzitului s ,i analiza operat ,iunilor
23

s,i alte categorii de aplicat ,ii
GTFS nu este singurul format de date pentru informat ,iile de tranzit cu traseu x, dar este de
departe cel mai utilizat, pentru c a este relativ simplu s ,i are o comunitate activ a de dezvoltatori,
care ajut a noile agent ,ii s ,i dezvoltatori s a obt ,in a datele ^ n format GTFS.Spre deosebire de stan-
dardele europene de schimb a industriei de tranzit, cum ar  Transmodel sau VDV-45X, GTFS
include doar operat ,iunile programate care sunt destinate distribuirii c atre c al atori. De aseme-
nea, este limitat la informat ,ii programate s ,i nu include informat ,ii ^ n timp real. Cu toate acestea,
informat ,iile ^ n timp real pot  legate de programele GTFS ^ n conformitate cu specicat ,iile legate
de GTFS Realtime.
Seturile de date sunt reprezentate ^ ntr-o serie de s ,iere text care sunt comprimate ^ ntr-un s ,ier
ZIP s ,i includ informat ,ii cum ar  programe de rute xe, rute s ,i date de stat ,ie de autobuz.
Sunt disponibile instrumente gratuite cu surse deschise pentru a ajuta agent ,iile s a-s ,i evalueze
sistemele de tranzit precum proiectul Open Transit Indicators de la WorldBank sau GTFS Feed
Validator. GTFS este un instrument intern cu adev arat puternic pentru agent ,ii.
Un format GTFS este o colect ,ie de cel put ,in s ,ase s ,i p^ an a la 13 s ,iere CSV (cu extensia .txt)
cont ,inute ^ ntr-un s ,ier .zip. Codicarea caracterelor preferate este UTF-8.
C^ ampurile obligatorii ale unei structuri GTFS includ urm atoarele s ,iere:
agency.txt : Agent ,ia care furnizeaz a datele
calendar.txt : O list a a serviciului disponibil
routes.txt : rutele de tranzit disponibile pentru c al atori ^ n cadrul unui singur serviciu
stops.txt : Locat ,iile individuale ^ n care vehiculele opresc
stops times.txt : Timpii specici la care un vehicul ajunge s ,i pleac a de la o locat ,ie de
oprire
trips.txt : o secvent , a de dou a sau mai multe opriri care apare la un moment dat
24

Fig. 11: Reprezentarea s ,ierelor GTFS[4]
Exemple de site-uri web care servesc drept directoare globale primare ale datelor GTFS acce-
sibile publicului:
1. TransitFeeds.com
2. Registrul de furaje Transitland
3. TransitWiki.org
3.2 GTFS Realtime
GTFS-realtime este o standard pentru tranzit care permite agent ,iilor de transport public s a
furnizeze dezvoltatorilor de aplicat ,ii actualiz ari ^ n timp real despre vehicule. Este o extensie
25

la GTFS (General Transit Feed Specication), un format de date deschis pentru programele de
transport public s ,i informat ,iile geograce asociate.
Specicat ,ia a fost creat a printr-un parteneriat ^ ntre agent ,iile partenere init ,iate de Transit Live
Transit, un num ar de dezvoltatori de tranzit s ,i Google. Specicat ,ia este publicat a sub licent ,a
Apache 2.0.
Prezentare general a a tipurilor de s ,iere GTFS ^ n timp real
Specicat ,iile accept a ^ n prezent urm atoarele tipuri de informat ,ii:
Trip updates : ^ nt^ arzieri, anul ari, rute modicate
Service alerts : Evenimente neprev azute care afecteaz a o stat ,ie, o rut a sau ^ ntreaga ret ,ea
Vehicle positions : informat ,ii despre vehiculele de tranzit, inclusiv locat ,ia
Actualiz arile pentru ecare tip de informat ,ie sunt furnizate ^ ntr-un feed separat. Fluxurile sunt
difuzate prin HTTP s ,i actualizate frecvent. Fis ,ierul ^ n sine este un s ,ier binar obis ,nuit, deci orice
tip de server web poate g azdui s ,i deservi s ,ierul (pot  utilizate s ,i alte protocoale de transfer). Ca
alternativ a, s-ar putea folosi s ,i servere de aplicat ,ii web care, ca r aspuns la o solicitare valid a HTTP
GET, returneaz a feed-ul. Nu exist a constr^ angeri cu privire la c^ at de frecvent s ,i nici la metoda
exact a privind modul ^ n care feed-ul ar trebui actualizat sau preluat.
Deoarece GTFS ^ n timp real ne permite s a prezent am starea actual a a vehiculelor,
uxul tre-
buie actualizat ^ n mod regulat – de preferint , a, ori de c^ ate ori apar date noi de la sistemul automat
de localizare a vehiculelor.
Formatul datelor
Formatul de schimb de date GTFS Realtime se bazeaz a pe Protocol Buers .
Protocol Buers reprezint a un mecanism neutru al limbajului s ,i platformei pentru serializarea
datelor structurate (g^ andit ,i-v a la XML, dar mai mic, mai rapid s ,i mai simplu). Structura datelor
este denit a ^ ntr-un s ,ier gtfs-realtime.proto, care apoi este folosit pentru a genera cod surs a pen-
tru a citi s ,i scrie cu us ,urint , a datele structurate de la o varietate de
uxuri de date, folosind o
varietate de limbaje, cum ar  Java, C ++ , sau Python.
Cum funct ,ioneaz a Protocol Buers?
Trebuie s a specic am modul ^ n care dorim ca informat ,iile pe care le serializ am s a e structurate
prin denirea tipurilor de buer protocol ^ n s ,iere .proto . Fiecare buer este o ^ nregistrare logic a
mic a a informat ,iilor, care cont ,ine o serie de perechi de nume-valoare.
26

Iat a un exemplu foarte simplu al unui s ,ier .proto care denes ,te un mesaj care cont ,ine informat ,ii
despre o persoan a:
Fig. 12: Exemplu  sier .proto[5]
Odat a ce am denit mesajele, execut am compilatorul de buers protocol pentru limbajul
aplicat ,iei ^ n s ,ierul .proto pentru a genera clase de acces la date. Acestea ofer a metode sim-
ple pentru ecare c^ amp (cum ar  get name () s ,i set name ()), precum s ,i metode de serializare /
analiz a a ^ ntregii structuri.Exemplul de mai sus va genera o clas a numit a Person. Putem utiliza
aceast a clas a ^ n aplicat ,ia noastr a pentru a popula, serializa s ,i a prelua mesajele de tip persoane
protocol buer.
^In cazul struncturii GTFS Realtime ierarhia elementelor s ,i denit ,iile lor de tip sunt specicate
^ n s ,ierulgtfs-realtime.proto .
Acest s ,ier text este folosit pentru a genera bibliotecile necesare ^ n alegerea limbajului de
programare. Aceste biblioteci ofer a clasele s ,i funct ,iile necesare pentru generarea feedurilor GTFS
valabile ^ n timp real. Bibliotecile fac mai us ,oar a crearea structurii s ,i asigur a c a se produc numai
structuri valide.
27

Fig. 13: Exemplu  sier trip updates[5]
28

4 Aplicat ,ie licent , a (Simulator transport public)
4.1 Descrierea arhitecturii  si a funct ,ionalit at ,ii aplicat ,iei
Aplicat ,ia Simulator de transport public este o aplicat ,ie mobil a care are
ca scop reprezentarea datelor GTFS s ,i GTFS Realtime oferite de diferite
agent ,ii de transport ^ n comun. Utilizatorii au posibilitea de a vedea cum
se deplaseaz a vehiculele c^ at s ,i timpii din stat ,ii valabili ^ n urm atoarele
minute.
Arhitectura sistemului aplicat iei Simulator Transport Public este de tip
client-server ecare av^ and un rol bine denit.Client ,ii simulatorului pot
telefoanele,tabletele sau alte dispozitive pe care ruleaz a Android.
Modulul Client se ocup a atat de partea de interact iune cu utilizatorul(interfat a grac a) , c^ at
 si de partea de comunicare cu serverul: trimite diverse tipuri de cereri HTTP asincrone la server.
Client ,ii au posibilitatea de a face cereri c atre server atunci c^ and aleg o locat ,ie nou a spre vizualizare
sau atunci cand se modic a cont ,inul hart ,ii(s-a produs o mis ,care).
Modulul Server are rol de a stoca resursele statice sau dinamice .Resursele statice sunt reprezente
de GTFS-urile modicate ^ ntr-un format propriu ,iar cele dinamice sunt reprentate de GTFS-
realtime care sunt obt ,inute din cereri HTTP repetate la agent ,iile care ofer a informat ,ii ^ n timp
real. ^In ambele cazuri, serverul are rolul de a centraliza datele  si de a le pune la dispozit ia
client ilor, prin adrese URL.
29

Fig. 14: Arhitectura aplicat ,iei Simulator Transport Public
30

4.2 Modulele funct ionale ale sistemului
Modulul Client este alc atuit din:
Modulul View este compus din activit at ,i .Activitatea reprezint a principala component a
a interfet ,ei cu utilizatorul, derivat a din clasa public a Java Activity (android.app.Activity),
ind un container pentru View (android.view.View). Aceasta interact ,ioneaz a cu utilizatorul
 si creeaz a o fereastr a ^ n care se poate plasa UI (User Interface) folosind metoda setCon-
tentView(View).
Aplicat ,ia are trei astfel de activit at ,i s ,i anume :
1.MainActivity : utilizatorul are posibilitatea de a vedea locat ,iile disponibile s ,i de a
naviga spre oras ,ul ales
2.MapActivity : vizualizare cum se modic a ^ n timp pozit ,ia vehiculelor dar s ,i acces la
funct ,ionalit at ,i precum detalierea programelor stat ,iilor
3.StationAactivity : ajuns ,i ^ n acest view client ,ii pot vizualiza timpii dintr-o anumit a
stat ,ie care pot  marcat ,i ca s ,i timpi statici sau ^ n timp real
Modulul Controller cuprinde toate act iunile care au loc la activarea interfet ei s ,i este un fel
de \handler de evenimente". Acesta declans ,eaz a modic ari la nivelul interfet ,ei ,c^ at s ,i asupra
modelului, s ,i pornes ,te modulul de taskuri asincrone.
Modulul Model se ocup a cu stocarea datelor despre starea curent a a hart ,ii . Acesta extinde
clasa Observable .De ecare dat a c^ and cont ,inutul modelului se modic a acesta anunt , a view-
urile interesate de el s a ^ s ,i modice interft ,a.Acest modul este independent de interfat a cu
utilizatorul,lucru deosebit de important deoarece dac a se dore ste schimbarea implement arii
prin ad augarea de noi funct ionalit at i, nu este necesar a efectuarea de schimb ari ^ n modulul
view.
Modulul Taskuri asincrone este format din clase de tip AsyncTask care ruleaz a pe threaduri
separate  si sunt instant iate ^ n Controller sau ^ n Model ,iar la terminare acestea actualizeaz a
interfat a.Cele instant ,iate ^ n controller sunt utilizate pentru redesenarea pozit ,iilor vehiculelor
la un interval de o secunda.Cele instant ,iate ^ n Model execut a cererile HTTP c atre server
pentru actualizarea datelor .
Modulul Server este alc atuit din:
Modulul Resusrsa Web comunic a cu modulul datelor statice  si cu modulul datelor reale. ^In
acest modul se a
 a o clas a denumit a RestPublicTransport care cont ,ine metode HTTP GET
care sunt folosite ^ n cererile HTTP.La init ,ializarea serverului se ^ ncarc a toate datele statice
.Apoi pentru ecare dat a static a care are resurse de realtime se pornes ,te un r se execut ,ie
31

separat care actualizeaz a cont ,inutul lor cu datele primite ce cont ,in informat ,ii despre timpii
reali ai pozit ,iilor vehiculelor.
Modulul Datelor statice este o clas a cu membri  si metode statice de unde citesc date toate
modulele serverului. Datele sunt ^ nc arcate la init ,ializarea serverului din s ,iere serializate ce
cont ,in informat ,ii modicate ^ ntr-un format propriu din struncturi GTFS.
Modulul Datelor dinamice(^ n timp real) reprezint a de fapt o grupare de re de execut ,ie
care au ca scop aducerea s ,ierelor trip updates.proto,transformarea lor ^ ntr-o list a de obiecte
de tipul TripUpdates s ,i adaugarea lor la obiectul gtfs static de care apart ,in.
4.3 Modulul Server
4.3.1 Procesarea datelor GTFS s ,i realizarea unui format propriu
Primul pas este obt ,inerea datelor GTFS.Un exemplu de site web de pe care putem desc arca
arhive .zip GTFS este https://transitfeeds.com .
Am ales date din mai multe zone ale lumii ,de la oras ,e din Europa p^ an a la oras ,e din America pe
care le-am pus^ n directorul de resurse.Un criteriu de alegere a fost ca arhiva s a cont ,in a pe l^ ang a cele
s,ase s ,iere .txt obligatorii(agency.txt,calendar.txt,routes.txt,stops.txt,stops times.txt,trips.txt) s ,i
un s ,iershapes.txt . Acest s ,ier e foarte important pentru desenarea rutelor pe hart a deoarce
cont ,ine multe perechi de puncte(latitudine,logitudine) pentru ecare rut a ^ n parte.Cu c^ at sunt mai
multe puncte pentru o rut a cu at^ at proiect ,ia pe hart a este mai exact a.
Pentru ^ nc arcarea datelor dintr-o arhiv a GTFS am folosit clasa GtfsParser care cont ,ine dou a
metode generice statice publice.Pentru ^ nc arcarea datelor din s ,ierele CSV am folosit bib-
lioteca com.opencsv.CSVReader .Un GTFS este considerat valid de c atre aplicat ,ie dac a cont ,ine
toate c^ ampurile pentru ecare clas a model specicate ^ n diagrama UML din gura Fig.16.
32

Fig. 15: Structura clasei GTFS Parser s ,i a clasei care cont ,ine toate datele unui GTFS
Fig. 16: Schema UML a modelului unei arhive GTFS
33

Dup a ^ nc arcarea datelor ^ n obiecte de tipul modelelor prezen-
tate se modic a ^ n propriul format .Un obiect de tipul GtfsObject
devine NewGtfsObject.
Ce e diferit de vechiul format este faptul ca datele sunt mult mai
grupate s ,i g^ andite astfel ^ nc^ at s a e us ,or de manevrat de c atre
server atunci c^ and primes ,te cereri de la client ,i .Scopul era s a
reprezint datele ^ n as ,a fel s a e us ,or de reprezentat pe hart a s ,i
extrase de catre server ^ n funct ,ie de timp s ,i pozit ,ie gepgrac a.
Spre exemplu am construit dou a clase NewRoute s ,i NewTrip cu
ajutorul c arora putem gestiona mult mai us ,or as ,ezarea spat ,ial a s ,i
temporal a.
Fig. 17: Schema UML a claselor noi introduse pentru reprezentarea datelor statice
Pas ,ii pentru ^ nc arcarea datelor statice sunt urmatorii:
instant ,ierea unui obiect de tipul NewGtfsObject
apelarea metodei getChangedGtfs( Nume Oras ,)
-dac a oras ,ul nu a mai fost folosit s ,i exist a ^ n resursele aplicat ,iei acesta este ^ nc arcat din arhiva
.zip s ,i transformat ^ n noul format iar apoi este serializat
-dac a oras ,ul se a
 a deja printre s ,ierele serializate atunci este ^ nc arcat ^ n memorie prin
deserializarea lui
Datele cont ,inute de o arhiv a .zip GTFS pot  valabile s ,i un an de zile.La generarea datelor
,aplicat ,ia le pastreaz a doar pe cele valabile 7 zile de la data curent a.
34

4.3.2 Procesarea datelor GTFS Realtime
Unele agent ,ii ofer a date ^ n timp real. Pentru obt ,inerea datelor a trebuit s a fac cereri repetate
la anumite adrese URL. Datele sunt ^ n format binar s ,i au extensia .proto.
Adresele URL le-am ret ,inut ^ ntr-un s ,ier de propriet at ,i al aturi de alte congur ari.
Fig. 18: Fis ,ier cong.properties
Pentru prelucrarea datelor primite ^ n format binar am
folosit biblioteca onebusaway-gtfs-realtime-api care
deserializeaz a informat ,iile ^ n obiecte ale claselor precum
TripUpdate sau StopTimeUpdate ^ n funct ,ie de un s ,ier
protobu .
Putet ,i vizualiza un astfel de s ,ier la adresa
https://developers.google.com/transit/gtfs-realtime/gtfs-realtime.proto
Datele sunt ret ,inute^ n obiecte proprii care se reg asesc^ n pachetul realtime (TripUpdate,StopUpdate)
care mai apoi sunt folosite pentru actualizarea informat ,iilor statice.
Clasa care realizeaz a procesarea datelor cu timpi reali este RTData care cont ,ine o metod a
static a getRealTimeData(URL resurs a) .Aceasta returneaz a un Map <String,TripUpdate >.
35

Fig. 19: Clasa RTData care cont ,ine metoda static a de prelucrare a datelor
4.3.3 Utilizarea datelor de realtime la nivel de server
Modulul Resursa Web cont ,ine clasa RESTful RestPublicTransport care implementeaz a interfat ,a
ServletContextListener.Acest lucru implic a faptul c a este nevoit a s a cont ,in a dou a metode publice
void s ,i anume contextInitialized(ServletContextEvent arg0) s ,i contextDestroyed(ServletContextEvent
arg0).Prima se apeleaz a la pornirea serverului ,iar a doua la oprirea lui.
36

Fig. 20: Metoda contextInitialized(ServletContextEvent arg0)
La pornirea serverului am ^ nc arcat datele statice s ,i am pornit re de execut ,ie pentru serviciile
care au date de real time.Metoda startRealtime() a unui obiect NewGtfsObject pornes ,te un thread
care este de tipul RealtimeThread(gura de mai jos) doar dac a instant ,a are realtime.
37

Pentru ecare oras ,disponibil din datele statice se caut a ^ n s ,ierul de congur ari un link de
realtime .Dac a s-a g asit o adres a URL atunci se creeaz a un obiect de tipul RealtimeThread pentru
acel oras ,s,i ^ n interiorul rului de execut ,ie se apeleaz a metoda RTData.getRealtimeData(url)
.Datele aduse sunt folosite pentru actualizarea timpilor din stat ,ii a autovehiculelor.
Cererile de date reale dintr-un r de execut ,ie se repet a aproximativ din minut ^ n minut . Ele
sunt active at^ ata timp c^ at serverul este pornit. La oprirea serverului sunt dezactivate s ,i aceste
thred-uri prin apelarea metodei contextDestroyed(ServletContextEvent arg0).
4.3.4 Accesarea resurselor serverului pe baza URL  si a protocolului HTTP
Pentru implementarea serverului am ales o solut ie de web service de tipul JAX-RS care furnizeaz a
funct ,ionalitatea pentru serviciile Web de reprezentare a transferului de stare (RESTful).
Jersey este implementarea de referint , a a specicat ,iei JAX-RS. Jersey implementeaz a suportul
pentru adnot arile denite ^ n JAX-RS, us ,ur^ and munca dezvoltatorilor de a construi= servicii de
web REST cu Java.
API-ul Jersey permite crearea unor clase resurs a http, pentru care se dene ste prin adno-
tarea @Path port iunea de URL care se ad aug a URL-ului de baza al serverului. O adnotare de
tipul @Path("/resurs a") aplicat a ^ n cazul unei clase va face disponibil a resursa http la adresa
http://localhost:8080/resurs a, ^ n cazul accesului de pe mas ,ina local a care ruleaz a serverul,spre
exemplu dintr-un browser rulat local.
URL-ul de baza al serverului este format dintr-un IP  si un port.Numele \localhost" reprezint a
o translatare local a ip-ului 127.0.0.1.
^In cazul client ilor,ace stia au posibilitatea acces arii serverului prin ip-ul public al acestuia, care
se seteaz a indepenent de server la rularea acestuia, ^ n funct ie de set arile ruterului wireless care
asigur a comunicat ia.
Orice aplicat ,ia care este instalat a ^ ntr-un container de tip servlet are nevoie de un sier web.xml
de congurare. Aici se specic a servlet-ul de care Jersey are nevoie pentru a se init ,ializa s ,i totodat a
calea spre serviciile Restful oferite, se specic a pachetul Java ca valoare a parametrului .
38

Fig. 21: Fis ,ierul web.xml al aplicat ,iei web
Am denit mai mult tipuri de URL-uri pentru aplicat ia Simulator Transport Public, ^ n funct ie
de resursele accesate. Acestea sunt prezentate ^ n continuare prin port iunea caracteristic a resursei,
care se ad aug a adresei de baz a ( http://localhost:8080/PublicTransport/rest/ ):
/getAllAvailableCities : aceast a adres a este apelat a de aplicat ,ia Client pentru a prezenta
oras ,ele disponibile pentru vizualizare s ,i nu cont ,ine nici un parametru suplimentar
39

/getAllRoutesWhoMatch/[city]/[timeStamp]/[topLeft]/[bottomRight] : aceast a adres a
este apelat a de aplicat ,ia Client de ecare dat a c^ and harta s-a modicat s ,i cont ,ine drept
parametrii oras ,ul pentru care se face reprezentarea,timpul ^ n format timestamp(timp ^ n
milisecunde trecute de la 1 ianuarie 1970 p^ an a ^ n prezent),coordonatele punctului st anga
sus s ,i dreapta jos ^ n formatul longitudine#latitudine
Toate datele cerute sunt trimise sub format JSON. Pentru mapparea datelor sub aceast a struc-
tur a am folosit biblioteca com.fasterxml.jackson.databind . Se intant ,iaz a un obiect de exemplu
mapper de tipul ObjectMapper s ,i prin apelarea metodei writeValue(myObject). Pentru transfor-
marea datelor^ n obiecte de tipul clasei myObject vom apela mapper.readValue(json,myObject.class).
40

4.4 Modulul Client
4.4.1 Modelele
^In aplicat ,ia Android se reg asesc mai multe modele,ecare av^ and un scop propriu.Am construit
modele pentru :
preluarea datelor JSON din cereriele web .
Fig. 22: Model clase pentru formatul JSON
Astfel informat ,iile primite ^ n format JSON se mapeaz a ^ n obiecte.La fel ca s ,i ^ n partea de
server folosesc biblioteca com.fasterxml.jackson.databind pentru preluarea datelor,doar
c a de aceast a data este operat ,ia invers a s ,i anume readValue(json,Object.class).Un exemplu
de clas a folosit a la extracerea informat ,iilor este clasa RoutesParser care transporm a formatul
JSON ^ ntr-un obiect de tipul Routes.
41

Fig. 23: Clasa RoutesParser care mapeaz a formatul JSON ^ n obiecte de tipul clasei Routes
controlarea interfet ,ei grace
Cea mai import a clas a model este clasa MapModel ce extinde clasa Observable.
S ablonul Observer este utilizat atunci c^ and se dore ste ca unul sau mai multe obiecte s a
e noticate cu privire la schimbarea st arii unui alt obiect. S ablonul implementeaz a un
mecanism de ^ nregistrare a obiectelor interesate de schimbarea st arii obiectului t int a  si un
mecanism de schimbare a st arii obiectului t int a. ^In momentul schimb arii st arii obiectului se
poate transmite  si o informat ie suplimentar a c atre observatori prin intermediul unui obiect
event.
Java standard implementeaz a  sablonul Observer prin intermediul claselor Observer  si Ob-
servable localizate ^ n pachetul java.util.
42

^In cazul aplicat ,ier Simulator Transport Public clasa ce dores ,te s a primeasc a notic ari atunci
c^ and se modic a modelul este MapsActivity. Acest mecanism presupune ca de ecare dat a
c^ and utilizatorul mis ,c a harta controller-ul s a atent ,ioneze modelul sa-s ,i actualizeze datele(s a
fac a cereri la server) ,iar apoi dup a ce modelul s ,i-a modicat starea s a ^ ns ,tiint ,eze interfat ,a
pentru a se modica s ,i ea.
Metodele apelate pentru notocarea claselor interesate de model sunt:
setChanged();
notifyObservers();
Clasa MapsActivity implementeaz a Observer care implic a folosirea metodei public void up-
date(Observable o, Object arg) care se apeleaz a imediat dup a ce modelul notic a obiectul de
tip MapsActivity.
resurs a adaptor pentru ListView
^In Android, oric^ and dorim s a as , am o list a vertical a a elementelor scrollabile, vom folosi un
ListView care are date populate utiliz^ and un adaptor. Adaptorul cel mai simplu de utilizat
se numes ,te ArrayAdapter deoarece convertes ,te un ArrayList de obiecte ^ n elemente de view
^ nc arcate ^ n containerul ListView.
43

Clasa resurs a ^ n cazul aplicat ,iei mele este RouteStation iar adaptorul este clasa RouteStation-
Adapter.
4.4.2 Controllere
Act ,iuni posibile pe care le pot genera utilizatorii:
s a apese pe butonul de alegere a unei locat ,ii
44

s a mis ,te harta.^ n cazul h art ,ii am tratat doua posibile actiuni si anume atunci c^ and harta a
^ nceput s a se mis ,te s ,i atuci c^ and mis ,carea a fost ^ ncheiat a.
s a apese pe un vehicul
s a apese pe o stat ,ie
45

4.4.3 Task-uri asincrone
O activitate care momentan nu e vizibil a utilizatorului ar trebui s a se realizeze asincron,prin
intermediul unei clase AsyncTask.
Asynctask este o clas a abstract a Android care permite folosirea corect a  si u soar a a thread-ului
UI, rularea operat iilor ^ n fundal  si a sarea lor ^ n thread-ul UI.
O sarcin a asincron a este denit a printr-un calcul care ruleaz a pe un thread din fundal, ale c arui
rezultate sunt a sate pe thread-ul UI. Are trei tipuri generice: Params, Progress  si Result.
Task-urile asincrone le folosesc pentru doua ^ ntrebuint , ari:
46

1. Aducerea datelor de pe server
Acest task este apelat de modelul MapModel de ecare dat a c^ and harta s-a modicat s ,i
scopul lui este de a face cereri HTTP la server.Dupa ce primes ,te rezultatul ^ n format JSON
anunt , a modelul care le parseaz a.
2. Redesenarea pozit ,iilor vehiculelor pe hart a.
Aceast a operat ,ie se execut a din secund a ^ n secund a at^ ata timp c^ at nu s-a mis ,cat harta.
Atunci c^ and pozit ,ia h art ,ii s-a schimbat se opres ,te redesenarea s ,i pornes ,te abia atunci c^ and
mis ,carea hartei s-a terminat.
47

4.4.4 Elementele grace
^In aplicat ,ie exist a trei ferestre distincte s ,i anume MainActivity,MapActivity s ,i StationActivity.
Elementele grace ale ec arei ferestre:
1. MainActivity cont ,ine:
RelativeLayout.
Acest tip de organizare presupune pozit ionarea elementelor grace relativ la un alt
control grac sau chiar relativ la p arinte.
pl.droidsonroids.gif.GifTextView permite inserarea de GIF-uri .Am folosit un GIF pe
post de buton(i-am setat metoda onClick)
Spinner-ul ofer a o modalitate rapid a de a selecta o valoare dintr-un set. ^In starea
implicit a, un spinner as ,eaz a valoarea selectat a ^ n prezent. Ating^ and cursorul as ,eaz a
un meniu derulant cu toate celelalte valori disponibile, din care utilizatorul poate selecta
unul nou.
Pentru a deni un spinner cu un design mai pl acut la vedere am construit un stil pe care
l-am salvat^ n directorul drawable,iar atribuirea lui am realizat-o cu style="@style/spinner style".
48

2. MapActivity cont ,ine:
RelativeLayout
ProgressBar sunt utilizate pentru a ar ata progresul unei sarcini. De exemplu, atunci
c^ and ^ nc arcat ,i sau desc arcat ,i ceva de pe Internet, este mai bine s a ar atat ,i progresul
desc arc arii / ^ nc arc arii utilizatorului.
Bara de progres suport a dou a moduri pentru a reprezenta progresul: determinare s ,i
nedeterminat a.
Eu am folosit bara de progres atunci c^ and se ^ ncarc a datele pentru hart a.
fragment
Acest fragment este cel mai simplu mod de a plasa o hart a ^ ntr-o aplicat ,ie. Fiind un
fragment, aceast a component a poate  ad augat a la s ,ierul de aspect al unei activit at ,i,
pur s ,i simplu cu XML de mai jos.
3. StationActivity cont ,ine:
LinearLayout aranjeaz a alte elemente grace orizontal^ ntr-o singur a coloan a sau vertical
^ ntr-un singur r^ and.
ListView este un control de vizualizare care as ,eaz a o list a de elemente scrollabile.
Elementele din list a sunt inserate automat ^ n list a cu ajutorul unui adaptor care trage
cont ,inutul dintr-o surs a s ,i transform a ecare rezultat al elementului ^ ntr-o vizualizare
care este plasat a ^ n list a.
49

4.5 Mod de utilizare
Aplicat ,ia Simulator Transport Public este foarte us ,or de folosit ,utilizatorul av^ and la ^ ndem an a
o interfat , a simpl a s ,i spun eu destul de intuitiv a de folosit. Din moment ce aplicat ,ia se bazeaz a pe
o arhitectura client-server ,vom putea rula mai mult ,i client ,i ^ n acelas ,i timp care s a ceara informat ,ii
diferte.
^In cele ce urmeaz a voi prezenta funct ,iile aplicat ,iile.
^In momentul deschiderii aplicat ,iei este declans ,at a o cerere c atre server pentru as ,area datelor
cu locat ,iile disponibile.
Din aceast a ferestra utilizatorul poate selecta locat ,ia dorit a s ,i poate naviga sper aceasta ap as^ and
globul care se rotes ,te.
50

^In caz c a ultizatorul nu a ales o locat ,ie acesta va primi o atent ,ionare de la aplicat ,ie.
Dup a apas ararea butonului de navigare aplicat ,ie deschide o noua fereastr a care poate ar ata
diferit ^ n funct ,ie de datele reprezentate. Spre exemplu ^ n gura urm atoare ^ n st^ anga sunt reprezen-
tate date statice iar^ n dreapta date de realtime.La desenarea datelor statice la reprezentarea rutelor
se foloses ,te negru,pe c^ and la desenarea celor dinamice se folos ,te verde.La fel s ,i ^ n cazul autove-
hiculelor.Cele ros ,ii sunt provenite din date statice iar cele verzi din date cu timpi reali.
51

Din aceast a fereastr a utilizatorii pot ap asa pe autovehicule pentru a le vedea codul dar s ,i pe
stat ,ii.^In cazul stat ,iilor pot naviga mai departe spre program prin simpla ap asare pe descrierea de
deasupra stat ,iei.
52

^In fereastra destinat a unei stat ,ii utilizatorul primes ,te timpii de sosire disponibili ^ n urm atoarele
minute a autovehiculelor ce opresc acolo .Aceasta are ca scop doar vizualizarea.
Ce este foarte important de ment ,ionat este semnul de internet ce indic a faptul c a acei timpi
sunt provenit ,i din date reale .
Oric^ and clientul se poate ^ ntoarce la fereastra h art ,ii prin ap asarea butonului de back a dispoz-
itivului. La fel se poate face s ,i din fereastra hart ,ii c atre prima pagin a de unde pot selecta un alt
oras ,.
Ce este de ret ,inut este ca utilizator s a cunoasc a diferent ,a dintre reprezentarea datelor proven-
ite din GTFS-uri s ,i cele provenite din date de GTFS-Realtime. ^In principiu ROS ,U=STATIC s ,i
VERDE=DINAMIC.
53

5 Concluzii s ,i perspective
Aplicat ia dezvoltat a este destinat a tuturor persoanelor care folosesc transportul ^ n comun s ,i
doresc s a cunoasc a timpii din anumite stat ,ii.Cele mai folositoare sunt reprezent arile de realtime
deoarece utilizatorii sunt informat ,i cu date curente despre stadiul mersului autovehiculelor.
Dezvoltarea aplicat iei Simulator Transport public a necesitat utilizarea multor cuno stint e prac-
tice  si teoretice ^ nv at ate ^ n facultate.Spre exemplu protocoale de comunicat ii, programare  si design
orientat obiect, structuri de date, calcul paralel  si sincronizare ^ ntre threaduri,inginerie softului.
Pe l^ ang a toate acestea au fost necesare acumularea unor cuno stint e teoretice noi, c^ at  si ^ nv at area
utiliz arii unor tehnologii noi.
La realizarea datelor am avut ocazia s a studiez structura de tip GTFS s ,i GTFS Realtime ,din
care se pot extrage tot felul de informat ,ii legate de serviciile oferite de o agent ,ie de transport.Pentru
utilizara datelor de realtime a trebuit s a ma familiarizez cu mecanismul Google Protocol Buers
pentru citirea datelor binare.
Dezvoltarea serverului mi-a permis s a ^ nvat ,bazele arhitecturii RESTful pentru servicii web  si
s a implementez un astfel de serviciu folosind framework-ul Jersey.
Dezvoltarea clientului a presupus^ nsus ,irea unor concepte importante de programare pe sistemul
de operare Android. Spre exemplu ideea de clas a main e inexistent a^ n Android deooarece procesele
s,i serviciile lansate la execut ia unei aplicat ii sunt denite ^ ntr-un  sier de congurare. Sau faptul
c a programarea pe Android fort eaz a utilizatorul s a separe funct ionalit at ile aplicat iei dup a modelul
arhitectural Model-View-Controller.
Am preferat sistemul de operare Android pentru dezvoltarea aplicat iei deoarece este cea mai
r asp^ andit a tehnologie pe dispozitivele mobile actuale, este bine documentat  si intuitiv din punct
de vedere al modului de utilizare.
Pentru a realiza cererile HTTP de la client c atre server am folosit clasa AsyncTask prin care
dezvoltatorului i se ofer a toate mecanismele necesare sincroniz arii threadului apelant cu cel de
background  si actualizarea datelor  si a interfet ei cu cele incluse ^ n r aspunsul primit de la server.
^In viitor, aplicat ia poate  extins a, pentru a permite diverse facilit at i noi.O dezvoltare major a a
aplicat ,iei ar  integrarea unui algoritm de rutare care s a as ,eze solut ,ii optime^ ntre doua coordonate
alese de utilizator
Un plus al aplicat ,iei ar  dac a ar cont ,ine c^ at mai multe date de realtime.Acelas ,i lucru se poate
spune s ,i despre datele statice,cu c^ at mai multe cu at^ at aplicat ,ia poate  folosit a ^ n mai multe
locuri ale lumii.Alte ^ mbun at at iri care pot  aduse aplicat iei ar  interfata mai interactiv a care s a
permit a o vizualizare s ,i mai intuitiv a.
54

Bibliograe
[1] Cursuri s ,i laboaratoare de Android
https://ocw.cs.pub.ro/courses/eim.
[2] Model aplicat ,ie Android
http://cs.curs.pub.ro/wiki/si/lab/2012/lab10.
[3] Git
https://www.visualstudio.com/learn/what-is-git/.
[4] Google Transit API
https://developers.google.com/transit/gtfs/reference/.
[5] GTFS Realtime
https://developers.google.com/transit/gtfs-realtime/.
[6] Ian F. Darwin Jason Brittain. Tomcat The Denitive Guide, 2nd Edition . O'Reilly Media,
2007.
[7] Bruce Eckel. Thinking in Java (4th Edition) . Prentice Hall, 2006.
[8] Karim Yaghmour. Embedded Android . O'Reilly Media, 2013.
[9] Sam Ruby Leonard Richardson. RESTful Web Services . O'Reilly Media, 2007.
[10] Masoud Kalali Bhakti Mehta. Developing RESTful Services with JAX-RS 2.0, WebSock-
ets,and JSON . Packt Publishing, 2013.
[11] Apache Maven
https://maven.apache.org/guides/getting-started/maven-in-ve-minutes.html.
[12] Documentat ia ocial a Google Protocol Buers
https://developers.google.com/protocol-buers/.
55