Șef lucr. Dr. Ing. Ionela Halcu Curelea Andrei -Costin [611777]

UNIVERSITATEA TEHNICĂ DE CONSTRUCȚII BUCUREȘTI
FACULTATEA DE HIDROTEHNICĂ
DOMENIU: INGINERIA SISTEMELOR
SPECIALIZARE: AUTOMATICĂ SI INFORMATICĂ APLICATĂ

PROIECT DE LICENȚĂ

CORDONATOR ȘTINȚIFIC : ABSOLVENT: [anonimizat]
2019

UNIVERSITATEA TEHNICĂ DE CONSTRUCȚII BUCUREȘTI
FACULTATEA DE HIDROTEHNICĂ
DOMENIU: INGINERIA SISTEMELOR
SPECIALIZARE: AUTOMATICĂ SI INFORMATICĂ APLICATĂ

Helpifi
Sistem complementar
pentru situa ții de urgent ă

CORDONATOR ȘTINȚIFIC : ABSOLVENT: [anonimizat]
2019

CUPRINS

1. Introducere
1.1. Contextul general
1.2. Contextul aplicatiei
1.3. Rezumat
2. Studiu de caz
2.1. Sistemul de urgenta actual
2.2. Protocolul AML (de completat cu noile norme europene)
2.3. Solutii
3. Concepte si Tehnologii folosite
3.1. Limbajul Java
3.2. Limbajul Kotlin
3.3. Limbajul JavaScript
3.4. Limbajul HTLM
3.5. Limbajul CSS
3.6. Polymer
3.7. Firebase
3.7.1. Baza de date in timp real (poti scrie si de JSON)
3.7.2. Firebase Firestore
3.7.3. Securitatea bazei de date Firebase
3.7.4. Capacit ăti offline
3.7.5. Crashlytics
3.8. API – Application Programing Interface
3.8.1. Google Maps API (de completat)
3.9. Sistemul de operare Android
3.9.1. Scurt istoric
3.9.2. Date generale (versiunile de android + graficul de impartire al versiunilor
+ tipuri de hardware )
3.9.3. Arhitectura Sistemului Android
3.9.3.1. Kernel Linux
3.9.3.2. Librari

3.9.3.3. Android runtime
3.9.3.4. Application Framework
3.9.3.5. Applications
3.10. Elemente utilizate in dezvoltarea Android
3.10.1. Clasele de baza
3.10.2. Ciclul de viata
3.10.3. Fisierul Manifest (permisiuni,activity,service, etc)
3.10.4. Resurse (drawable/layout(XML) /Strings(localizare)/Dimensiuni(px –
dp)/colors/etc )
3.11. Android studio
3.11.1. Emulator
3.11.2. Gradle
3.12. WebStorm

4. Proiectarea aplicatiei (Aici intra scheme cu cazuri and stuff)
4.1. Caracteristici (Functionalitati)
4.2. Schemele UML
4.3. SMS Gateway – Telerivet
4.4. Principiul Arhitecturi MVP

5. Implementarea sistemului
5.1. Arhitectura aplicatiei Android
5.1.1. View
5.1.2. ViewModel
5.1.3. Repository
5.1.4. Room
5.2. Structura bazei de date
5.3. Implementarea concretă Android
5.4. Implementarea concreta Web (DE COMPLETAT)
6. Concluzi i
7. Anexa

Table of Contents
Capitolul 1 ………………………….. ………………………….. ………………………….. …………………… 6
Capitolul 2 Capitolul 1 – Introducere ………………………….. ………………………….. ……………… 6
1.1 Contextul general ………………………….. ………………………….. ………………………….. ………. 6
1.2 Contextul aplicatiei ………………………….. ………………………….. ………………………….. …….. 6
1.3 Rezuma t ………………………….. ………………………….. ………………………….. …………………… 6

6 Capitolul 1 – Introducere
1.1 Contextul general
Eficienta unui serviciu de urgentă este critica in cazul unui accident sau al unei
calamitati . De exemplu p entru persoanele ce suferă un atac de cord, fereastra de timp in care
trebuie sa i se realizeze maneverele de resuscitare cardio -respiratorie si sa fie transportat la
spital este direct proportionala cu sans a de supravietuire . Timpul in care s e face sesizarea
catre serviciul corect de urgenta poate face diferenta . Daca un trecator nu cunoaste locatia cu
exactitate (este in vacanta in orasul respectiv, etc.) acest interval poate creste extrem de mult
atat durata apelului cat si gasirea efectiva a locului de catre echipajul de interventie . Iar in
cazul unei calamitati nu exista un instrument ce ne poate da un numar estimativ de victime
intr-o zona afectata . Instrumentele actuale ale serviciilor de urgenta au o marja ridicata de
eroare.
1.1 Contextul aplicatiei
In cazul unei situatii de urgența fiecare secundă contează. Astfel transmiterea a căt mai
multor informații intr -un timp cat mai scurt este esentiala. Odata cu evoluția tehnologiei,
dispozitivele mobile au devenit un ajutor de nelipsit din viata omul modern. Cresterea de la an
la an a performantei privind puterea de calcul, capacitatea bateriei,capacitatea memoriei, a
preciziei senzorilor, incurajeaza folosirea acestor „mini -calculatoare” in fiecare activitate. I
Intr-o situatie de urgenta toate simturile omului sunt ascutite, dar cateodata nu sunt
indeajuns, iar prin intermediul unor aplicatii dedicate putem face ca si „simturile”
dispozitivului sa poata fi folosite.
1.2 Rezumat
Lucrarea de fata prezinta un sistem informatic complementar de transmi tere, in
momentul apelari, a unor date vitale catre un serviciu de urgenta si posibilitatea serviciului de
urgenta ce detine acest sistem sa activeze transmiterea de date de pe dispozitivele vizate in
caz de calamitate . Sistemul este format dintr -o aplicat ie (pentru utilizatori) ce ruleaza pe
dispozitivele mobile cu sistemul de operare Android versiunea 5.0 sau ulterioară si o
platforma WEB (pentru serviciul de urgenta ) . In capitolul 2 va fi prezentat un studiu de caz
despre actualul sistem de urgenta si despre viitorul acestuia in Uniunea Europeana , in
capitolul 3 vor fi prezentate pe rand conceptele si tehnologiile utilizate, in capitolul 4 sunt
prezentati pasi proiectari sistemului impreuna cu cazurile de utilizare, capito lul 5 prezinta
ghidul de in stalare , iar in ultimul capitol sunt prezentate concluzii le si cateva directi de
dezvoltare viitoara

7 Capitolul 2 – Studiu de caz
2.1 Sistemul actual de urgență
In Uniunea Europeana apelurile la numarul unic de urgenta „112” a crescut cu 5% in
ultimul an atingand un numar de 141.141.731 .
Intr-o eră a digitalizari numarul apelurilor efectuate de pe un telefon mobil este in
continua crestere , si variaza de la tara la tara . In anul 2017 ,in Uniunea Europeana, media
apelurilor efectuate de pe un telefon mobil in statele membre este de 73% , ultimul loc fiind
ocupat de Croatia cu 53% .Primele locuri sunt ocupate de Finlanda cu 96% si Danemarca cu
97 %

Fig. 2.1 Tabelul distributiei apelurilor de urgenta in functie de dispozitivul utilizat

Timpul de raspuns
Oamenii aflați intr-o situatie de criza au nevoie de un raspuns cat mai prompt din
partea serviciului de urgenta. Dupa analizarea timpilor in mai multe state membre ale Uniunii
Europene s-a constatat un timp de raspuns sub 10 secunde (Vezi figura 2.2)

Fig. 2.2 Timpul de raspuns al catorva state membre ale Uniunii Europene

Localizarea
In cazul in care apelul este efectuat de pe un telefon fix, numarul are atasat adresa,
problema apare in momentul in care apelul se efectueaza folosind un telefon mobil.
Localizarea acestora se realizeaza pe baza celulelor GSM. Aceasta metoda a fost adoptata c u
rapiditate datorita faptului ca nu necesita aplicarea de modificari pe dispozitivele terminale,
folosindu -se doar de infrastructura operatorilor de telecomunicati. Un telefon mobil este in
permanenta conectat la astfel de celule (de obicei cea mai apropi ata),masurand puterea
semnalelor si folosind metoda triangulatiei , se poate estima locatia. Precizia acestei
determinati este strans corelata cu numarul celulelor din vecinatate, astfel variaza intre 500 de
metri, intr -o zona urbana si 40000 de metri (40 km) intr -o zona rurala.
Metoda triangulatiei functioneaza astfel : telefonul receptioneaza semnalul de la cea
mai apropiata celula de transmisie, a carei locatie este cunoscuta, masurandu -se semnalul
putem deduce ca dispozitivul se afla in aria de acoper ire a acelei celule, cercul cu centrul
reprezentat de turn si raza de puterea de transmisie a acestuia. In acelasi timp dispozitivul ar
trebui sa comunice si cu alte turnuri, repetand procedeul si intersectand rezultate putem
deduce locatia aproximativa (F ig. 2.2)

Fig. 2.3 Determinarea locatiei unui telefon mobil utlizand triangularea GSM

8

Timpul de interventie

In Romania timpul mediu de interventie al unui echipaj medial este de 11 -12 minute,
timp la care se mai adauga si perioada de desfasurare a apelului. Aceasta fereastra poate face
diferenta dintre viata si moarte, astfel trebuie redusa la minim.

2.2 Protocolul AML (Advanced Mobile Location)

Odata cu evolutia tehnologiei , cu popularitat ea telefonelor „inteligente” si
maturizarea sistemelor GNSS posibilitatea obtineri unei locati precise direct de catre
dispozitivul apelantului a crescut exponential. Desi aceste informati existau si puteau fi
preluate da catre sistemul de urgenta, pana d e curand nu erau folosite. In anul 2016 operatorii
PSAP din Marea Britanie impreuna cu trei mari companii de telecomunicatii au decis sa
creeze un standard pentru transmiterea acestor informatii. Acest proiect a ajuns sa fie
cunoscut ca proiectul AML ce a dat nastere unui nou protocol de comunicatii ce poarta acelasi
nume. Protocolul utilizeaza tehnologiile existente de pe dispozitivele utilizatorilor impreuna
cu un serviciu SMS de transport disponibil pe piata pentru a face conexiunea cu operatorii
PSAP si pentru a corela informatiile cu apelul vocal bazandu -se pe detaliile CLI (Calling Line
Identity).
Conform unui decret al Comisiei Europene toate statele membre trebuie sa
implementeze protocul AML pana in anul 2020.
Aspecte cheie ce trebuie luate in considerare :
Capabilitatile dispozitivului
Pentru a putea folosi avantajele descrise mai sus terminalul trebuie sa suporte simultan
un apel standard de urgenta GSM, o localizare GNSS sau/si WI -FI si transmiterea unui SMS
catre PSAP, toate acestea in timpul apelului
Automatizarea
Într-o situatie de urgenta, apelantul traieste un moment plin de panica si stres,
functionalitatea AML trebuie sa se activeze automat, fara vreo interventie din partea
utilizatorului si sa fi e invizibil pentru a nu induce in eroare.
Nivelul bateriei
Exista posibilitatea unui apel de pe un telefon al carui nivel de baterie este extrem de
scazut, in acest caz energia trebuie conservata cu orice pret pentru a putea mentine
conexiunea apelului vocal . Se recomanda evitarea folosiri unor operatii ce necesita un nivel
ridicat de energie (folosirea receptorului GNSS, a receptorului Wi -Fi , ș.a.m.d.). Limita
specificata mai sus difera de la un producator la altul si este o informatie ce trebuie stiut a.
Daca nivelul bateriei este un impediment, in protocol trebuie specificat acest lucru
fiind recomandata localizarea GSM (date ce sunt disponibile operatorilor in mod implicit).

9 Pozitionar ea
Datele obtinute prin serviciul GNSS au un grad de precizie ridi cat ce vine cu un cost,
timpul de obtinere al acestora este mai mare, fata de metod a de localizare bazat a pe turnurile
GSM . Pentru a optimiza timpul operatori cer orice informatie este disponibila in acel moment.
Urmand aceasta regula s -a introdus un time-out. Orice aplicatie ce respecta acest protocol
trebuie sa implementeze un astfel de time -out ce poate fi modificat oricand cu usurinta.
Time -out- ul reprezinta timpul maxim de la initializarea apelului pana la trimiterea
SMS -ului cu datele necesare. In prezent valoarea este de 20 de secunde. In momentul in care
se initializează apelul de urgentă conform protocolului trebuie incepute operatiile de obținere
ale locației in paralel pentru a ne incadra in fereastra de timp. Daca nivelul bateriei este peste
limita impusa de producator se pornesc receptoarele GNSS si de WI-FI. Odata inceput
procesul trebuie verificate rezultatele pentru a putea diferentia datele salvate anterior in
memoria cache . Orice date viabile obtinute mai devreme se vor trimite inainte c a fereastra de
timp sa se inchida. Odata ajunsi la finalul ferestrei se verifica daca au putut fi obtinute datele
GNSS, in caz contrar se vor folosi datele de localizare bazate pe WI -FI folosind adresele
SSID si MAC ale AP(Access Points) din vecinatate , daca si aceasta metoda da gres, ca
ultima varianta se vor folosi datele de la celulele GSM.
In cel mai rau caz nici o varianta din cele prezentate mai sus nu a returant un rezultat
viabil, se va trimite SMS -ul cu specificatia ca nu s -a putut obtine locatia , impunănd
operatorlui PSAP sa ceara locatia via voce.

Interfata protocolului AML

Un apel de urgenta se poate intampla in orice mediu,iar sansele sa se intample intr -o
zona fara internet sunt destul de ridicate. Pentru a depasi acest obstacol datele prel uate vor fi
trimise printr -un SMS . SMS -urile vor fi trimise pe un canal special, ce are o prioritate
ridicata fata de cele conventionale . SMS are o limita de 164 de caractere, fapt ce a restrans
cantitatea si formatul informatiilor.
Coordonatele vor fi codificate in formatul WGS84 cu o precizie de 5 zecimale,
echivalentul in realitate este de 1,1 metri . Gradul de precizie variaza in functie de tehnologia
folosita, relief, interferente ș.a.m.d. Precizia reprezinta raza cercului in care dizpozitivul s -ar
putea afla la momentul apelului,
Timpul la care datele au fost preluate (TOP/ Time of Positioning/ Timpul de
pozitionare) trebuie trimis deasemenea pentru a putea filtra rezultatele mai vechi asigurand o
locatie reala. TOP trebuie sa fol oseasca UTC si NTP (Network Time Protocol) adica
timestamp -ul (timpul in secunde incepand cu 1 ianuarie 1970 pana in momentul de fata)
preluat de pe server. Se foloseste acest NTP pentru o precizie extrem de ridicata, daca NTP -ul
este indisponibil se preia timpul obtinut din rezultatele GNSS, ca ultima varianta, in cazul in
care cele doua metode specificate inainte dau greș se va prelua timpul dispozitivului . Trebuie
totusi tinut cont ca acest TOP poate fi extrem de imprecis.
Interfata protocolului AML este formata dintr -un header „ A”ML=1” pentru a putea fi
identificat ca un mesaj AM L si din perechi de forma cheie -valoare unite prin operatorul „=”
fara spatii si separate prin operatorul „;” din nou, fara spatii, avand neaparat la final numarul
de caractere d in mesaj.

10

Exemplu de mesaj AML :

A”ML – Headerul ce specifica faptul ca acesta este un mesaj A ML
lt – Latitudinea in format WGS84
lg – Latitudinea in format WGS84
rd – Raza de precizie (reprezinta raza cercului in care utilizatorul se poate afla)
top – Timpul la care a fost preluata locatia in formatul timestamp (Time of
Positioning)
lc – Nivelul d e incredere (Level of Confidence)
pm – Metoda de pozitionare (Positioning Method)
si – IMSI (International Mobile Subscriber Identity)
ei – IMEI (International Mobile Equipment Identity)
mcc – MCC (Mobile Country Code)
mnc – MNC (Mobile Network Code)
ml – Lungimea mesajului in caractere (Message Length)

In exemplul de m ai sus se poate observa ca datele intr -un mesaj AML sunt pozitionate
dupa ordin ea importantei lor, latitudinea, longitudinea, raza de precizie si timpul sunt la
inceput urmate apoi de cele lalte informatii
.
Datele complete necesare pentru a respecta protocolul AML se gasesc in Tabelul 2.1
in anexa ….

Canalul special prin care acest tip de mesaj se trimite suporta doua tipuri de SMS.
SMS -ul normal si Data SMS
Data SMS este varianta recoma ndata deoarece sistemul nu salveaza in mod automat
mesajul trimis in sistem, evitand astfel ulterioarele confuzii. Acest tip de SMS desi este folosit
destul de des de catre companiile de telecomunicatii, nu este la fel de cunoscut utilizatorilor.
Un exempl u de intrebuintare al acestui tip de SMS este configurarea casutei vocale sau a
cartelei sim.
Diferentele dintre DATA SMS si SMS si sunt urmatoarele :
– Data sms -urile nu sunt trimise direct catre un port cunoscut
– Indicatorul Antetul este pus in spatiul PDU
– Antetul specifica portul de conexiune la care se trimite mesajul

2.3 Solutii

11
In lucrarea prezenta se propune implementarea unui canal complementar de
comunicare automata intre apelant si PASP . Acest sistem este compus dintr -o aplicatie WEB
ce poate fi integrata in sistemul actual de urge nta si o aplica ție ce va rula pe orice telefon
mobil cu sistemul Android avand o versiune minima 5.0. Aplicatia WEB in momentul
efectuari unui apel de urgenta de catre o persoana ce are instalata aplicatia, primeste instant
date precum locatia in timp rea l, date adiacente precum nume, varsta, istoric medical,
persoane de contact sau orice tip de date introdus in prealabil de utilizator. Operatorului
ramand atributia sa constate gravitatea situatiei si confirm area datelor trimise. Toate acestea
respectand protocolul descris in capitolul 2.2.

Capitolul 3. Concepte si tehnologii folosite

In subcapitolele ce urmeaza vor fi specificate si detaliate tehnologiile folosite pentru
realizarea proiectului. Helpifi utilizeaza tehnologi de ultima ora ce au devenit un standard pe
piata IT.
Folosirea acestor tehnologii si a librari ilor open source prezinta urmatoarele avantaje:
– Reducerea timpului de dezvoltare care implicit reduce si costurile aferente
– Prezența unei comunitati vaste de dezvoltatori ce sustin astfel de librarii

Sistemul Helpifi este constituit dintr -o platforma web si o aplicatie pentru telefoanele
mobile ce ruleaza sistemul Android.
Aplicatia Helpifi a fost realizata in mediul de dezvoltare Android Studio, mediu de
dezvoltare creat de firma JetBrains si sustinut oficial de catre Google, utlizand limbajele Java
si Kotlin. Pentru anumite functionalitati au fost folosite librarii open source din considerentele
specificate mai sus
Platforma Helpifi a fos t realizata in mediul de dezvoltare WebStorm creat tot de catre
firma JetBrains utilizand libraria Polymer , creata de catre Google, folosind limbajele
JavaScript, HTML, CSS.
La momentul redactari acestui document platforma se afla in mod demonstrativ la
adresa web : www.helpifi.com iar aplicatia poate fi instalata de la adresa web : ………..

3.1 Limbajul Java

Limbajul Java este un limbaj de programare orientat pe obiecte , dezvoltat de catre
Sunt Microsystems si detinut de catre Oracle sub licenta GNU . El este gandit si conceput in
asa fel incat dezvoltatorii pot scrie un program o singura data si sa ruleze pe mai multe
dispozitive, insemnand ca orice cod Java compilat poate rula pe toate platformele ce suporta
Java fara a mai fi nevoie de o recompilare a acestuia. Compilarea este procesul prin care
compilatorul transforma codul initial in codul tinta. De obicei compilatorul executa
transformarea dintr -un limbaj de nivel inal t intr -un limbaj de nivel mai scazut sau direct in
cod masina. Deoarece java a fost conceput pentru a putea rula pe mai multe dispozitive , in

12 momentul compilari limbajul java este tranformat in bytecode , acest este un set de instructiuni
ce este preluat de JVM (Java Virtual Machine) specific arhitecturi dispozitivului.
Lansarea acestui limbaj a fost dezvoltat de catre James Gosling la Sunt Microsystems
si lansat in anul 1995 find achizitionat ulterior de compania Oracle

Pentru a putea intelege urmatoarele principii trebuie specificate si explicate
urmatoarele concepte :
– Clasa : Intr -un limbaj orientat pe obiecte clasa reprezinta schita unei enitati.
Aceasta schita poate contine proprietati si metode. De exemplu : Avem clasa
Casa ce are ca propri etate i adresa,culoarea peretilor exterior si coordonatele
geografice, ca metode avem alarma de incendiu si deschide usa garajului. In
acest moment noi avem doar o idee, un plan al unei case fara valori specifice.
– Obiect : Obiectul reprezinta o instanta a unei clase. Obiectul este entitatea
creat a conform clasei sale. Daca urmam exemplul de mai sus, dat pentru clasa
unei case, un obiect ar reprezenta o casa construita ce se afla pe strada X, cu
culoarea peretilor Y, la coordonatele Z.
Principiile de baza ale programari orientate pe obiecte :

– Abstractizarea : Este posibilitatea ca un program să separe unele aspecte ale
informației pe care o manipulează. Fiecare obiect în program are rolul unui “actor”,
care poate executa acțiuni, își poate modifica starea și poate comunica cu alte obiecte
din program fără a dezvălui cum au fost implementate acele notiuni .
– Polimorfismul : Posibilitatea de a procesa obiectele in mod diferit in functie de tipul
lor. Dupa cum sugereaza si numele poli – mai multe, morfism – forma, aspect, acelasi
nume , mai multe forme . Acest principiu este util atunci cand se vrea redefinirea unei
metode pentru clasele derivate. De exemplu: avem clasa corp ce are metoda volum,
daca clasele cub, piramida,sfera ș,a.m.d. extind clasa corp pentru fiecare in parte se
poate modifica metoda volum pentru a returna un raspuns correct;
– Incapsularea : Asigura faptul ca starea interna a proprietatilor unei clase nu pot fi
schimbate direct din exterior ci doar prin intermediul unor interfete ce asigu ra modul
corect de modificare ;
– Moștenirea : Usureaza folosirea incapsularii si a polimorfismului oferind
posibilitatea creari unor clase noi plecand de la alte clase deja definite. Noile clase
obtinute pot pastra comportamentul celor de baza, il pot modifica sau aduce proprietati
si functionalitati noi.Acest principiu a plecat de la ideea ca unele entitati seamana pana
la un anumit nivel. Exemplu : clasa cerc mosteneste/extinde clasa figura. Clasa cert
are acum acces la toate proprietatile si metodele clasei figura adaugand proprietatile
specifice, de exemplu raza.
Limbajul Java a fost limbajul oficial de dezvoltare pentru aplicatiile Android pana in
anul 201 9 cand Google a anuntat suportul oficial pentru limbajul Kotlin.

3.2 Limbajul Kotlin

13 Kotlin, dezvoltat de firma JetBrains, este un limbaj de programare pe mai multe
platforme ( cross -platform ), cu verificare statica si cu inferenta de tip, conceput cu scop
general, interoperabil cu limbajul Java si cu JVM -urile acestuia. Kotlin se compilea za atat
utilizand JVM cat si in JavaScript si Swift. Kotlin este puternic sustinut de Google, astfel se
bucura de o rata de adoptie extrem de mare. Conform statisticilor oferite de Google peste 80%
din dezvoltatori Android folosesc deja limbajul Kotlin. In cepand cu anul 2019 acesta a
devenit limbajul principal pentru dezvoltarea aplicatiilor Android. Interoperabilitatea cu Java
ofera companiilor o trecere graduala si o posibilia implementare mixta.
Cateva a specte ale limbajului :
– Spre deosebire de java “ ;” sunt optionale
– Permite semnalarea posibilitati variabilelor de a avea valoarea null prin operatorul “?”
si ofera o modalitate de a accesa in mod sigur proprietatile si metodele acestora.
– Tipul variabilelor este dupa declararea numelui acestora
– Variabi lele pot fi constante prin operatorul val sau variabile prin operatorul var
– Clasele sunt finale in mod implicit, iar pentru a putea fi extinse trebuie folosit
operatorul open
– Metodele si constructori claselor suporta parametrii impliciti
– Ofera functionalitatea metodelor extensi, oricarei clasei I se pot adauga metode
publice fara sa se creeze o noua clasa ce mostenesta clasa baza. Aceste metode apar la
fel ca metodele initiale.

–
– Existanta functiei de delegare lazy() ce primeste o functi e lambda si returneaza o
instanta a obiectului ce a delegat functia lazy(). Folosind aceasta functie , variabilele pot fi
initializate in momentul accesari lor si nu la instantierea obiectului, reducand memoria si
puterea de procesare necesara .

Interoperabilitatea Kotlin -Java este un aspect important pentru dezvoltatorii Android,
oferind acestora o tranzitie lina catre el permitandu -le in acelasi timp sa foloseasca librariile deja
scrise in Java intr-un mod natural. Pentru a face acest lucru se generează automat in fundal
metodele get si set.

3.3 Limbajul JavaScript

JavaScript este un limbaj de nivel inalt, interpretat, orientat pe obiecte si este unul din
tehnologiile de baza pentru World Wide Web .

3.4 Limbajul HTML

Hypertext Markup Language pe scurt HTML este un limbaj ce permite crearea de
documente de tip hypertext, ce vor fi utilizate pentru paginile Web.
HTML nu este de fapt un limbaj de programare. Specificattile lui definesc un set de
“tag” -uri(comenzi) si reg uli de scriere ale ascestora. Intr -un cuvint, cu ajutor ul limbajului
HTML formatam un document pentru a putea fi accesat prin Internet.

14 Folosind HTML putem realiza urmatoarele:
– documente independente de platforma (sistemul de operare)
-legaturi la alte documente de pe Internet
-introducerea de imagini, sunet si video
-interactivitate intre cititorul documentului si document .
Documentele WWW s unt de fapt texte ASCII care contin diferite elemente ale acestui
limbaj de formatare (HTML). De regula document ele HTML au extensia.html , dar si .htm
in cazul serverelor WWW ce ruleaza pe MS -Windows. Documentele HTML pot fi create
manual folosind un editor de texte ASCII (de exemplu “Notepad” din Windows) . Pot fi
convertit e din alte formate folosind diverse editoa re HTML sau pot fi create dinamic de un
server WWW. Un document HTML lucreaza extrem de simplu. El “spune” programului de
navigare prin Internet pe care -l folosim (browser), prin intermediul “tag” -urilor, ce sa faca cu
textul, imaginile, sunetul sau celela lte elemente cuprinse in document.
HTML nu tine cont de forma originala a textului. Nu conteaza cum arata textul c ând este
scris, ci cum va arata pe ecran in fata unui privitor. Nu conteaza tab -urile, spatiile multiple, nu
se tine cont de sf ârsitul de lini e, etc. Tag-urile (comenzi) s unt scrise intre paranteze
unghiulare:
<nume -tag> Aceste tag -uri sunt de doua feluri: de inceput <nume -tag> si de sf ârșit
</nume -tag> si au efect asupra obiectului descris intre ele (paragraf de text, imagine, etc).
Dupa numel e tag -ului de inceput mai pot fi scrise si o serie de atribute, astfel:

Întreaga dezvoltare a limbajului HTML s -a facut in ideea cresterii calitatii fara
sacrificarea simplitatii. Fiecare document HTML este structurat in doua parti: antetul –
“head” si continutul – “body”. Structura unui document HTML arata astfel:

<html>
<head>
<title>Titlul Documentului</title>
</head>
<body>Continutul documentului</body>
</html>

3.5 Limbajul CSS

Cascading Style Sheets sau CSS este un standard pentru formatarea elementelor unui
document HTML Stilurile se pot atașa elementelor HTML prin intermediul unor fișiere
externe sau în cadrul documentului, prin elementul <style> și/sau atributul style . CSS se poate
utiliza și pentru formatarea elementelor XHTML , XML și SVGL . CSS3 reprezintă o
actualizare ce aduce câteva atribute noi și ajută la dezvoltarea noilor concepte in web design.
Structura unui fisier CSS :
div {
border: 2px solid #333333;
padding: 1 6px 16px;

15 background: # ffffff ;
width: 400px;
border -radius:2 5px;
}

3.6 Polymer
Polymer este o librarie si un set de instrumente dezvoltate de Google in efortul de a
introduce conceptul de componente web ca un standard WW3C. Aceasta librarie a trecut prin
mai multe iterati, prima versiune fiind lansata ca un proiect in beta, aproape incompatibil pe
browserele existente ce isi propunea a demonstra concepul de dezvoltare a unor componente
web incapsulate si reutilizabile ce pot fi usor distribuite fi ind dezvoltate pe o arhitectura
predefinita.
Etapa de mijloc in perioada de dezvoltare a librariei Poly mer a fost vazuta ca o librarie
stabila si compatibila cu aproape 100% din browserele de pe piata.
In final tranzitia la versiunea a treia a librariei a fost marcata de transformarea
conceptelor promovate de Google intr -un standard web, adoptate de major itatea
frameworkurilor si librariilor de dezvoltare web. In acest context rolul echipei care a dezvoltat
Polymer in cadrul Google a ramas de a asculta nevoile dezvoltatorilor si a inova domeniul in
care a fost si pionier, iar ceea ce ofera catre dezvoltato ri s-a transformat intr -un set de unelte
in diferite grade de stabilitate (Alpha/Beta/Stable)

3.7 Firebase

Firebase este o platforma de dezvoltare pentru aplicatii web si aplicatii mobile ,
indiferent de sistemul de operare. Nu a fost construita cu scopul de a inlocui mijloacele de
dezvoltare existente ci mai degraba sa ajute dezvoltatori oferindu -le serviciile necesare
precum o baza de date, un serviciu de autentificare securizat si multe a ltele pentru a construi ,
a creste si a mentine proiectul dorit.
Firebase este impartit in trei categori: Dezvoltare, Crestere si Castig.

Modularitatea este un alt aspect important, dezvoltatorul poate alege ce function alitate
doreste sa foloseasca, nefind obligat sa le foloseasca pe toate. Majoritatea modulelor sunt
gratuite, analiza datelor, autentificarea, notificarile via cloud , raportarea erorilor fatale, linkuri
dinamice, inivitatii, configurare aplicatiilor de la distanta. Pentru celelalte module exista o
limita de gratuitate, de exemplu, pentru baza de date in timp real limita este 1 Gb de date si
100 de conexiuni simultane, iar pentru rularea functiiolor de pe server ( Cloud Functions) se
poate ajunge pana la 125,000 de apeluri pe luna.
In continuare vor fi detaliate functiile folosite pentru a dezvolta proiectul prezentat :

Consola Firebase

16 Consola ( Fig. …..) este loc ul de administrare a tuturor modulelor ce urmeaza a fi
prezentate, iar in ecranul principal se pot gasi informatii generale despre utilizarea serviciilor,
modul de plata,utilizatorii activi intr -un interval de timp ales si setarile generale ale
proiectului (persoanele autorizate ce pot accesa si edita proiectul, aplicatiile conectate
ș.a.m.d), practic acesta este „centrul de comanda”.

Fig. …..

Autentificarea Firebase

In momentul in care un utilizator isi instaleaza aplicatia, pentru al putea ident ifica si
prezenta continutul adecvat avem nevoie de o inregistrare securizata . Dezvoltarea acestui
modul deseori este costisitor si greu de intretinut. Pe cat de greu este de dezvoltat, atat de
neapreciat poate fi de utilizator. Studii efectuate in domeniu l experientei utilizatorului in
interactiunea cu o aplicatie mobila releva faptul ca multi utilizatori renunta la folosirea
produsului software in momentul in care ii este cerut sa se autentifice. O posibila rezolvare
este de a se autentifica cu credentiale deja salvate, de exemplu logarea cu : Facebook, Google,
Twitter, ș.a.m.d. Firebase vine in ajutorul dezvoltatorilor cu un API de autentificare simplu de
utilizat, securizat ce se imbina perfect cu celelalte module .

Acest API ofera o variatate larga de moduri de autentificare (Fig. …… ):
 Email si parola
 Facebook, Google,Twitter , ș.a.m.d.
 Numarul de telefon
 Logare anonima (fara ca userul sa asocieze alte date)

Fig……..
Pentru a completa si acoperi toate posibilitatile dintr -un proces de autentificare intr -un
mod cat mai prietenos pentru utilizator a fost creata o librărie open source pe nume
FirebaseAuthU I. Aici se pot gasi toate unelete pentru ai oferi utilizatorului o tranzitie lina prin
modulul de logare. Aceleasi principii sunt utilizate in produse de avengura precum Google
search, Youtube, ș.a.m.d. Folosind aceste metod e s-a constatat o crestere semni ficativa a
conversiei de log in . Adica a utilizatorilor ce trec cu succes de o operatie de logare continuand
sa foloseasca aplicatia.
SDK -ul de autentificare firebase este construit avand securitatea pe prim plan, folosind
standarde precum OAuth 2.0 si OpenID Connect . In continuare va fi explicat unul din cele
mai raspandite fram eworkuri de autentificare:

17 Oauth 2.0

Oauth permite aplicatilor sa obtina acces limitat la un cont al utilizatorului utlizand un
serviciu HTTPS. Functioneaza delegand atributiile de autentificare catre serviciul ce detine
informatiile legate de contul folosit.
Acest protocol are urmatoarele co mponente :
 Proprietarul resurselor : proprietarul resurselor este utilizatorul ce a permis unei
aplicatii sa foloseasca datele contului. De mentionat faptul ca accesul aplicatiei este
restrictionat, putand citi doar datele necesare in procesul de identifi care.
 Serverul de autentificare : Acest rol il are serverul ce detine informatiile despre
contul accesat si serverul ce indeplineste verificarea indentitatii returnand token -ul
rezultat in urma acestui process .
 Clientul : reprezinta aplicatia ce vrea sa accese contul utilizatorului
Etapele autentificari :

1. Aplicatia cere permisiunea sa acceseze serverul cu resurse
2. Odata permis accesul aplicatia primeste o autorizatie pentru a accesa resursele
3. Autorizatia de la pasul 2 este trimisa catre serverul de au tentificare. Serverul verifica acest
permis si daca este valid emite un token de autentificare inapoi catre aplicatie
4. Aplicatia cere datele serverului prezentand tokenul obtinut la pasul 3, iar daca aceste este
validat, datele sunt trimise inapoi catre aplicatie.

Fig…….

Principiul de functionare:

Pentru a putea autentifica utilizatorul acesta trebuie sa introduca credentialele de
autentificare. Acestea pot fi email/parola sau un token O auth in cazul logari cu o parte terța
(Facebook,Google,Twitter). Dupa obtinerea credentialelor acestea trebuie introduse in SDK –
ul firebase de autentifica re ce verifica autenticitatea lor si a dispozitivul de pe care s -a realizat
logarea.
Fiecare utilizator este identificat in sistem folosind un id unic generat in momentul
inregistrari. Acest id unic poate fi folosit pentru personalizarea datelor afisate si pentru a crea
o interfata intre toate celelalte API -uri firebase.

Baza de date in timp real
Aceasta este o baza de date non-sql. Ea ofera o sincronizare a datelor pentru toate
dispozitivele conectate , functionand chiar si fara o conexiune activa la internet printr -un cache
local. Este o baza de date bazata pe evenimente ce functioneaza diferit fata de bazele de date
traditionale SQL. De fiecare data cand datele se schimba in baza de date sunt declansate
evenimente in codul client ce sunt folosite pe ntru a gestiona si actualiza noile informatii .
Scopul acestei baze de date este de a oferi utilizatorului o experienta fluida si scalabila in timp
real.

18 Datele sunt structurate sub forma unui fisier JSON (Java Script Object Notation) .
Acesta este un forma t standard open source ce poate fi inteles usor de om. Este compus din
perechi nume -valoare separate prin „ , ”. Formatul nu impune nici o restrictie asupra tipului
sau a complexitatii datelor.

Formatului unui fisier JSON:

Exemplu de fisier JSON:

{
„prenume ”: „Ion”,
„nume”: „Popescu ”,
„este”: true,
„varsta”: 22
„adresa”: {
„strada”: „Strada Targu neamt ”,
„oras”: „Bucuresti ”,
„tara”: „RO”,
„cod_postal ”: „ 062058”
},
„agenda”: [
{
„nume”: „Acasa”,
„numar”: „0712345678 ”
},
{
„nume”: „Alex”,
„numar”: „0787654321 ”
},
{
„nume”: „Marius”,
„numar”: „0712348765 ”
}
],
„copii”: []
}
Firebase Storage – serviciu de stocare pentru fisiere

19
Pe langa date, majoritatea aplicatiilor au nevoie sa stocheze poze sau videoclipuri. O
astfel de infrastructa este complicat de dezvoltat, in special pentru a sustine un volum mare de
date precum cel al videoclipurilor. Firebase Storage foloseste tehnologi a spatiului de stocare
Google Cloud si pune la dispozitie un API ce gestioneaza automat procesul de descarcare ,i
ncarcare si eventuale erori. Este recomandata utilizarea acestui modul impreuna cu cel de
autentificare pentru a crea o legatura intre fisiere si datele din baza de date in timp real.
Desi putem observa exista o asemanare cu un sistem de gestiune al fisierelor, structura
este defapt liniara, fara directoare ce contin fisierele. Cel mai inalt nivel de acces se numeste
„bucket”, el contine toate fisierele. Navigarea,structurarea si cautarea obiectelor stocate se
face folosind un mecanism asemanator unei structuri de directoare (utilizatori/poze/poza1.jpg)
chiar daca nu exista nici unul.

Baza de date Firestore
La fel ca baza de date in timp re al, putem folosi firestore pentru a stoca datele
necesare aplicatiei . Intr -un proiect este recomandat sa le folosim pe amandoua deoarece
fiecare este optimizata pentru un lucru anume. Baza de date in timp real este optimizata
pentru scrieri multipe, rapide , concomitente, pe cand firestore este optimizat pentru un volum
mai mare de date pe care se pot face interogari complexe. Firestore este structurat in obiecte
numite documente ce contin perechi cheie -valoare. Aceste documente la randul lor sunt
structurat e in colectii

Fig ……..

Intr-un proiect se vor gasi colectii ce contin subcolectii sau documente conform figurii
de mai jos :

Fig.

Un avantaj este modul in care se realizeaza interogarile. Structura noua permite
interogarea dupa mai multe criterii si citirea datelor dintr -un document fara a le citi si pe cele
din subcolectiile aferente, permitand structurarea logica a datelor fara grija descarcari datelor
nefolositoare . Un exe mplu este r edat in urmatoarea figura ( Fig. …… ), putem citi documentul
marcat fara a citi si datele din subcolectia sa.

Fata de baza de date in timp real, cei de la Google au adus imbunatari asupra
capacitati de scalare. In timp ce cealalta suporta in jur de 100 000 de conexiuni simultane,
Firestore suporta 1 000 000.

Fig. ….

20

Regurile de securitatea ale bazelor de date Firebase

Deoarece bazele de date sunt accesibile de orice client conectat, trebuie specificate
cateva reguli de securitate pentru a evita un eventual atac cibernetic. Aceste reguli sunt
compuse din permisiuni de citire sau scriere pentru utilizatori. Cel mai intalnit caz este
restrictia utilizatorilor de a putea citi sau scrie in baza de data daca nu sunt autrentificati.
Aceste reguli de securitate sunt sub forma unui singur fisier JSON ce poate fi
modificat din consola de la modulul „Database” , sectiunea „Rules” ( Fig …….. ).

Fig. …..

Nodul parinte principal trebuie denumit „root” iar accesul pentru a scrie si de a citi
este permis pe nodurile „.read”/”.write” urmat de valoarea corespunzatoare.
Aceste reguli au o metodologie cascada, adica odata acordata permisiunea unui nod
parinte, toate nodurile ce sun t dependente de acel parinte au aceasi permisiune.

In figura ….. se pot gasi cele mai comune reguli de securitate, in acest caz doar clientii
conectati si autentificati pot citi si scrie. Aceste reguli verifica daca clientul are id unic.

Fig. …..

Crashlytics

Acest modul Firebase face parte din categoria modulelor ce sunt folosite dupa lansarea
aplicatiei. Probleme le intr-o aplicatie software nu sunt un lucru strain, chiar si dupa lansarea
oficiala a acesteia. Pentru a oferi un serviciu de calitate fara intrerupere, dezvoltatori trebuie
sa se depisteze probleme ce apar. Reproducerea,administrarea si gruparea erorilor dupa
prioritate poate fi un proces costisitor fara instrumente si informatii ajutatoare . Din dorinta de
a sustine un produs in continua crestere , a luat nastere modulul prezentat. Crashlytics este un
serviciu de raportare automata a problemelor ce duc la e rori ce inchid aplicatia si opresc firul
de executie. Datale trimise includ un raport detaliat ce contine eroarea intalnita, date despre
telefon precum nivelul bateriei, orientarea ecranului, conexiunea la internet ș.a.m.d. In functie
de gravitatea erorii, de nivelul aparitiei si numarul de utilizatori impactati acestea sunt
structurare si grupate.

21 In sectiunea crashlytics ( Fig …. ) putem vedea o imagine de ansamblu, putem filtra
datele dupa o anumita versiune a aplicatiei, dupa dispozitivele pe care s -au intamplat erorile si
dupa multe alte detalii.
Odata sortate erorile, le putem accesa pe fiecare in parte si putem vedea istoricul
actiunilor ce au condus la eroare , inclusiv numarul liniei de cod ce a generat eroare.

Fig …..

3.9 Sistemul de o perare Android

Android este un sistem de operare bazat pe kernelul Linux, care are ca scop principal
functionarea in conditii optime a aplicatiilor si a functiilor de pe telefonul mobil. Tot ceea ce
este vizibil pe un telefon mobil, de la functia de volu m, la aplicatiile din Play Store face parte
din intregul sistem de operare.

3.9.1 Scurt istoric

Compania Android Inc. infiintata de 4 tineri vizionari si anume Rich Miner, Nick
Sears, Chris White si Andy Rubin , a aparut pe piata in luna Octombrie anul 2003, in sudul
Californiei, intr -un orasel pe nume Palo Alto. Aceasta companie a luat nastere cu mult timp
inainte ca termenul bine -cunoscut „smartphone” sa fie folosit de majoritatea oamenilor cum
este in ziua de astazi si cu cativa ani inainte de lansarea primei versiuni de iPhone si a primei
versiuni de iOS.
Conform prezentarii oferite de Andy Rubin in anul 2013 la o conferinta de ni șa din
Tokyo, sistemul de operare Android a fost initial creat pentru a imbuna tatii sistemele de
operare pentru camerele digitale. Desi produsul acestor 4 vizionari era de o inginiozitate ne
mai intalnita, piata camerelor digitale era in scadere, cateva luni mai tarziu dupa prezentarea
produsului catre investitiori, acestia luand de cizia de a pivota cu produsul in zona de sisteme
de operare pentru telefoanele mobile.
Un nou capitol important in viata fondatorilor si in viata companiei a aparut in anul
2005 cand compania Android Inc a fost achizitionata de giganul Google pentru pretul
estimativ de 50 de milioane de dolari americani. Cu toate ca cei 4 fondatori au renuntat la
actiunile lor si la drepturile acestora de decizie din cadrul companiei, ei au continuat sa
lucreze inca o buna parte de timp, Rubin fiind Directorul diviziei de A ndroid din cadrul
Google pana in anul 2013. La finanul anului 2014, acesta a demisionat din cadrul companiei
Google, infiintandu -si propriul incubator de start -up-uri.
In timp ce Apple lucra la propria versiune de smartphone si la prima versiune de iOS,
Google se straduia din rasputeri sa lanseze intr -un timp cat mai scurt prima versiune de
Android, ambele companii dezvoltand in secret 2 solutii diferite. In final, Apple a dezvaluit si
a iesit primul pe piata cu prima versiune de iPhone si de iOS, in anul 2 007 intr -o conferinta

22 din cadrul companiei. Google, datorita acestui fapt, a inceput sa dezvaluie si ei la randul lor
din planurile pe care le aveau cu sistemul de operare Android, incercand sa creeze o distanta
psihologica mai mica intre cele 2 lansari , in noiembrie 2007 lansand prima versiune Beta
pentru Android.
In septembrie 2008, prima versiune oficiala de Android avea sa fie lansata pe piata,
companiile Google si Apple intrand intr -o competitie directa ce are sa tina mult timp de acum
in colo.

3.9.2 Date generale

Dupa cum se poate observa, Android a ales ca diferentierea intre versiunile sistemelor
de operare sa fie facuta prin oferirea unor nume de cod care au ca si origini si sunt tangentiale
cu dulciurile/deserturile/bomboanele.
Prima ve rsiune de Android (1.0) conform unui reportaj oferit de catre inginerul Jean –
Baptiste Queru catre Android Police, nu a avut nici un nume de cod, versiunea de Android 1.1
fiind denumita numai intern ca „Petite four”; nume care face referire la un desert bin e-
cunoscut din Franta.
In prezent, cea mai noua si ultima versiune de Android lansata pe piata este Android
Q. Aceasta versiune a fost lansata in beta urmand ca in toamna anului 2019 sa fie lansata
versiunea finala a acestuia. Android Q va avea ca functio nalitate noua principala, posibilitatea
de a distribui mult mai rapid diverse tipuri de continut cum ar fi pozele.
Reprezentarea grafica a versiunilor de Android si a utilizarii acestora pe plan global
conform datelor publicate de Statista.com . Dupa cum se poate observa in fig. …… de mai jos
cea mai raspindita versiune este Oreo 8.0. Aceste date sunt foarte importante pentru
dezvoltatori deoarece fiecare iteratie de dezvoltare a venit cu cate o functionalitate noua sau
cu rezolvarea unor p robleme vechi. Deobicei atunci cand se hotaraste versiunea minima pe
care poate rula aplicatie ce doreste sa fie dezvoltata se ia in considerare: functionalitatile ce
sunt compatibile cu versiunea minima si procentul de adunat de dispozitive pe care il tin tim.

3.9.3 A rhitectura sistemului Android

Arhitectura unui sistem este un model conceptu al ce defineste
comportamentul,interactiunea si structura componentelor. In alcatuira sa se pot gasi
componente sau subsisteme ce indeplinesc un rol bine stabilit. Folosind acest mod de
vizualizare conceptuala a elementelor, putem obtine informatii precum b eneficiile aduse de

23 sistem vand o perspectiva general a. Conceptul de arhitectura de sistem se poate aplica in mai
multe domenii, lucru ce a dus la nasterea urmatoarelor tipuri :
 Arhitectura Hardware definește designul de hardware necesar cum ar fi CPU, spa țiu
de stocare, spațiu de memorie, mediu de transfer de date (Wan, Lan), echipamente
conexe (ex.: imprimanta sau echipament de scanare), medii de back -up, medii de
funcționare (in house, hosted, cloud) ;
 Arhitectura Software cu scop de definire a designulu i de aplicație,
componente/elemente și relație între componente/elemente ;
 Arhitectura de Întreprindere este compusă din arhitecturile de mai jos, dar are un
status mai special prin interferența sa cu mediul de afaceri și cu implicațiile sale
asupra mai m ultor sub entități sau firme ;
 Arhitectura Organizationala definește relațiile de afaceri , procese de afaceri ,
structură organizațională (ierarhizare), roluri și responsabilități, competentele
organizaționale (departamentele) și relația lor ;
 Arhitectura Informationala definește structura entităților de date, sursa și
organizarea acestora, de fapt structura datelor și accesibilitatea eficientă a acestora
în diferite baze de date.
Arhitectura software are scopul de a ajuta luarea deciziilor structurale, ce au un cost
ridicat de schimbare odata implementate .
Din punct de vedere al arhitecturi software sistemul Android se imparte in cele 6
subsisteme prezentate in figura de mai jos (Fig. 3.1)

Fig. 3.1

Kernelul Linux

Kernelul este un program software ce sta la baza oricarui sistem de operare, avand
controlul complet asupra fiecarei componente. El se ocupa de intrarile si iesirile cerute , este
primul program ce se incarca atunci c and se deschide dispozitivul si se ocupa de
transformarea comenzilor primite de la alte programe in instructiuni pentru CPU (Unitatea
Centrala de Procesare), de administrarea memoriei si a tuturor perifericelor
(tastatura,mouse,imprimanta, ș.a.m.d), rularea proceselor, ș.a.m.d. Avand aceasta
responsabilitate mare, kernelul trebuie protejat . Solutia a fost separarea acestuia din zona de
momerie accesibila pentru programele de sistem, intr -o zona dedicata doar lui , numita spatiul
kernel .
Folosind un ke rnelul Linux sistemul Android beneficiaza de securitatea ridicata pe
care acesta o are datorita popularitati .

Stratul de abstractizare hardware ( Hardware Abstraction Layer/ HAL )
Acest strat are rolul de a face legatura intre componentele hardware ( camer a,
bluetooth,pedometru, ș.a.m.d. ) si celelalte nivele superioare (de ex. Frameworkul Java). HAL

24 este compus din mai multe librarii fiecare fiind raspunzatoare de functionalitatea unei singure
componente hardware.

Android Runtime
Odata cu Android 5.0 fie care aplicatie foloseste propriul proces cu propriul Android
Runtime ( ART ). ART este folosit pentru a rula mai multe masini virtuale pe dispozitive ce nu
au foarte multa memorie folosind fisiere DEX , un format ce a fost conceput special pentru
Android si optimizat pentru a nu afecta memori a foarte mult.
ART are cateva functionalitati foarte importante :
 Compilarea AOT(Ahead -of-time) si JIT(just -in-time)
In Android 2.2 a fost introdusa compilarea JIT folosind arhitectura Dalvik.
Aceasta metoda compileaza codul aplicatiei in timpul folosiri, de aici si numele “just –
in-time/exac – la-timp”. In cele mai multe cazuri consta in traducerea in cod masina a
codului sursa. Un sistem ce implementeaza acest tip de compilarea analizeaza in
permanenta codul ce se execu ta si cauta secvente le de cod ce s -au modificat luand
decizia daca sa recompileze tot codul sau doar acele secvente. JIT este o forma de
compilare dinamica ce combina viteza codului compilat si flexibilitatea unui
interpretor.
Cateva avantaje ale folosiri compilari JIT:
1. Procesul de compilare poate fi optimizat pentru procesorul/sistemul
de operare folosit ;
2. Sistemul poate colecta date despre modul in care codul ruleaza si
poate optimiza compilarea dinamica a acestuia ;
3. O utilizarea a memoriei cache mai buna .
Toate aceste avantaje vin cu un cost, un timp crescut la lansarea initiala a aplicatiei din
cauza timpului necesar incarcari si compilari codului. Acest timp este cunoscut ca „timpul de
incalzire”.
Compilarea AOT reprezinta compilarea unui limbaj de nivel inalt intr -un cod
masina nativ inca de la instalarea aplicatiei, astfel incat fisierul rezultat sa se poata executa
nativ. Fata de compilarea JIT timpul de pornire initial al aplicatiei este redus cu costul unor
posibile optimizari .
 Optimizarea memor iei
 Incepand cu Android 9 s -a introdus un nou format ce suporta o comprimare mai
buna a codului in defavoarea vechiului format DEX (Dalvik Executable)

Librari native C/C++

Majoritatea serviciilor si a componentelor Android (ART sau HAL) sunt construit e
folosind cod nativ ce necesita aceste librari scrise in C/C++. Pentru a le accesa cateva API -uri
Java au fost expuse.

Java API

25 Functionalitatea componentelor este expusa dezvoltatorilor folosind aceste API Java.
Toate componentele unei aplicatii And roid sunt deja implementate , tot ce ramane de facut
este unirea acestora si construirea functionalitatilor specifice comportamentului dorit. Cateva
dintre componentele principale expuse sunt :
 Un manager de resurse ce per mite accesul catre fisierele ce co ntin imagini, siruri de
caractere localizate, ș.a.m.d.
 Un manager al ciclului de viata al activitatilor/fragmentelor
 Un sistem de vizualuri
Aplicatiile de sistem

Sunt acele aplicatii de baza, precum aplicatia de email, SMS, calendar, contacte,
ș.a.m.d. Au acelasi nivel de acces precum orice alta aplicatie instalata de utilizator, overind
posibilitatea de a seta functionalitatea uneia dintre ele ca find implicita (de ex. : deschiderea
unui fisier pdf cu o anumita aplicatie). Aceste componente functioneaza atat ca aplicatii
pentru utilizatori cat si ca baza pentru dezvoltari ulterioare (de ex. : daca se doreste
dezvoltarea unei aplicatii de trimitere SMS, programatorul nu trebuie sa implementeze de la
zero trimiterea efectiva , el se poate folosi de modulul existent )

3.9.SDK – Software Development Kit
Kitul de dezvaltare software (SDK) este compus dintr -o colectie de produse software
utilizate pentru a dezovolta aplicatii pentru un anumit tip de dispozitiv sau sistem de operare
(ex: Android SDK, IOS SKD, ș.a.m.d.). De cele mai multe ori aceste SDK se folosesc
impreuna cu un mediu de dezvoltare compatibil. Pentru SDK -ul de Android se poate folosi
mediul de dezvoltare Android Studio, descris in capitolul …….. Aceste medii de dezvoltare au
deobicei o fere astra in care se poate scrie codul, un debugger pentru a vedea erorile si un
editor vizual pentru a putea construi interfata grafica.
Companiile incurajeaza dezvoltatorii sa creeze aplicatii pentru platformele lor prin
oferirea in mare parte a acestor SDK-uri gratuite. Complexitatea lor poate deveni un
impedinent in procesul de intelege si asimilare, lucru ce a necesitat dezvoltarea unei
documentatii bine pusa la punct.

3.9…… API – Application Programing Interface

Un API este o colectie de unelte, metode si componente utilizate in dezvoltarea
software. In general reprezinta un set de metode de comunicare intre mai multe componente
bine definite si cu un scop de utilizare clar. Pentru dezvoltator, un API preia toata logica din
spatele acelei operati si expune doar metodele pe care le poate folosi. Un exemplu poate fi
obtinerea locatiei utilizatorului. Folosind API de locatie de la Google programatorul apeleaza
o singura metoda ce returneaza locatia. Toata logica din spatele acestui rezultat este
incap sulata in API si poate fi necunoscuta.

Google Maps SDK

26 Utilizand Google Maps SDK, se pot adauga harti direct in aplicatii folosind date le
colectate de Google . Accesul catre servere , descarcarea datelor necesare si afisarea hartii sunt
administrare automat de catre API. API -ul se poate folosi si pentru a adauga indicatoare ,
sectiuni si pentru a schimba perspectiva asupra harti.. Pentru a putea folosi aceste servicii, o
cheie API trebuie generata si asociata cu proiect ul in cauza . Cheia reprezinta un sir unic de
caractere ce leaga aplicatia de serviciul in sine . Ne putem gandi la cheia ca la CNP -ul
aplicatiei in contextul folosiri API -ului. Fiecare API poate avea cate o cheie diferita. Acest
SDK este taxat in functie de numarul de ap eluri realizate. Dupa limita gratuita destinata
testari, se va taxa lunar folosind datele de facturare oferite si legate cu acea cheie API.
Google Maps SDK contine mai multe interfete de programare precum:
 Routes API – ofera posibilitatea obtineri unor r ute de navigare optimizate putand
alege mijlocul de deplasare, punctul de plecare si destinatia. Rezultatul obtiunut in
urma apelului consta intr -un fisier JSON ce contine date necesare afisari unei linii
peste harta, timpul de deplasare, rute alternative, etc. Datele sunt influenta te in timp
real de trafic, deoarece foloseste aceasi infrastructura informatica a produsul Google
Maps
 Places API – ofera posibilitatea obtineri locatiei diferitor restaurante, firme, locuri ce
au asociata o adresa. Totodata se pot obtine si informatiile a diacente precum rating,
pareri si informatii de contact.

Elemente utilizate in dezvoltarea Android

In procesul de dezvoltare al aplicatiilor Android se intalnesc cateva componente si
concepte principale:

Activitatea

Clasa Activity este o componenta esentiala intr -o aplicatie Android, iar modul in care
aceste activitati sunt pornite reprezinta un aspect fundamental al platformei. Spre deosebire
de celelalte platforme in care aplicatiile sunt lansate folosind metoda principala main(),
sistem ul Android initializeaza codul intr -o instanta de tip Activity, apeland cateva metode
specifice de tip callback care corespund cu diferitele etape din ciclul de viata ( Cap ……) .
O aplicație poate avea în structura ei una sau mai multe componente de tip Activity . O
activitate trebuie marcată ca principala , aceasta fiind primul obiect de tip Activity ce va fi
lansat în execuție după pornirea aplicației.
Fiecare obiect de tip Activity are un ciclu de viața comp us din mai multe stări. Datele
privind stările diferitelor componente sunt reținute într -o structură denumită stivă de activități
(back -stack) ce este gestionată de sistem. Această structură este o structura de tip
LIFO(Ultimul intrat, primul i esit). I n capul stivei se afla Activitatea A activa la momentul
respectiv, iar resursele sistemului ii sunt alocate ei , atunci cand o noua activitate B este
initializata, activitatea A trece in fundal ajungand pe un nivel inferior in stiva de memorie.
Atun ci cand navigam inapoi actvitatea B este distrusa, fiind scoasa din stiva, devenind activa
activitatea A .
Un obiect de tip Activity se poate afla în una din cele 3 stări

27  starea acti a. Componenta de tip cti it se află în prim plan (se situeaza în capul stivei de
acti ită i) , utilizatorul interacționand direct cu aceasta.
 stare de așteptare. Componentele aflate in aceasta stare nu interactioneaza cu utilizatorul
insa sunt izibile acestuia, fiind în continuare atașată manager -ului de ferestr e. oate datele
legate de starea acestor obiecte sunt păstrate în memorie. nsă în cazul în care sistemul are
nevoie de resurse acestea vor fi distruse.
 oprită. Componentele aflate în această stare nu interacționeaza cu utilizatorul și nici nu s unt
izibile acestuia. oate datele legate de starea acti ității sunt păstrate în memorie. nsă în
cazul în care sistemul are ne oie de mai multe resurse acti itățile din această stare pot fi
distruse .

Incepand cu anul 2018, la Android Dev Sum mit, a fost introdus si sustinut oficial
conceptul de „Single Activity App”, aplicatie cu o singura activitate. Se prefera folosirea unei
activitati principale ce contine diferite fragmente ( Cap ……) . Acest concept isi propune
fluentizarea experientei utilizatorilor si ofera posibilitatea construiri unei interfete grafice
mult mai complexe. Folosirea unei singure activitati si a mai multor fragmente ce sunt atasate
de acestea vine si cu cateva imbunatatiri ce nu sunt atat de evidente ca cele prezentate m ai
sus :
 un control mult mai bun la schimbarea continutului , nu ne mai bazam pe
frameworkul android
 o amprenta de memorie mult mai mica (Activitatile aflate in memorie consuma mult
mai mult decat fragmentele)
 meniu lateral in toate interfetele ce au nevoi e (acest meniu find legat de activitatea
principala, nu de fragmenul cu continut)

Fragmentul

Fragmentul reprezinta o portiune din interfata utilizatorului. Ne putem referi la un
fragment ca la o sectiune dintr -o activitate ce are propriul ciclu de viata, primeste propriile
inputuri si care poate fi adaugat a si sco sa in timp ce activitatea ruleaza. Incapsularea
comportamentului acestuia il face reutilizabil in diferite contexte si activitati.
Fragmentul este intotdeauna legat de o activitate, iar ci clul de viata al acestuia este
strans corelat cu cel al activitatii parinte

Serviciul

Un serviciu este o componenta fara interfata grafica ce ruleaza in fundal pe o perioada
mai lunga de timp , ciclul de viata find unul simplificat si independent de al altor componente .
Este controlat in mare parte de programator si nu de catre sistem. Aceasta componenta trebuie
pornita prin intermediul altor entitati si ruleaza pe firul de executie principal al aplicatiei pana
la distrugere. Pentru a putea folosi un serviciu, trebuie adaugat in fisierul Manifest ( Cap …..)
folosind urmatoarea sintaxa :

28
Furnizorul de continut (Content Provider )
O component de tip Content Provider este un obiect din cadrul unei aplicații Android
care face ca anumite date, din cadrul aplicației, să fie disponibile altor aplicații. Datele
partajate pot fi fișiere audio, video,imagini, alte tipuri de fișiere precum și date stocate într -o
baza de date SQLite. Un exemplu utilizat frecvent in aplicatii este cel de preluare al
contactelor sau a datelor din calendar.
Receptori de anunțuri Broadcast Receivers
Un obiect de tip Broadcast Receiver este o componentă ce răspunde la mesaje de tip
broadcast. Mesajele de tip broadcast pot fi transmise de către sistem, pentru a notifica
aplicațiile despre anumite modificari ale parametrilor sistemului (precum nivelul memoriei,
bateria disponibilă), sau de către aplicații pentru a notifica alte aplicații despre a numite
evenimente precum terminarea descărcării unui fișier.
Intentia (Intent )
O “intenție”, sau un obiect de tip Intent, conține informații despre operațiile pe care ar
trebui să le facă o anumită componentă destinație pe un anumit set de d ate. Cu ajutorul
obiectelor de tip Intent este posibilă comunicarea, în timpul rulării, cu diverse componente
atat din interiorul aplicatiei cat si din exterior . Printre componentele ce pot fi activate prin
intermediul obiectelor de tip Intent se numară obiecte de tip Activity, Service și
BroadcastReceiver.
Există 2 tipuri principale de intenții intenții implicite și intenții explicite.
In cadrul intențiilor explicite este specificat obiectul distinație care să realizeze
prelucrările cerute (fie ca e de tip Activity, Service sau BroadcastReceiver).
In cazul intențiilor implicite, rămane pe seama sistemului sarcina de a selecta
aplicația corespunzatoare care să raspundă la solicitatea din cadrul Intent -ului.Elementele din
Intent care su nt analizate sunt cele din categoriile action, data, și category. In acest caz
sistemul ține cont de filtrele de intenție declarate în fișierul manifest a fiecarei aplicații. Un
filtru de intenții (intent filter)specifica tipul de intenții pe care le poate prelucra o anumita
aplicație. De exemplu aplicatia poate cere deschiderea unei aplicatii ce gestioneaza trimiterea
de email -uri.
Fisierul manifest Android
Fiecare proiect Android include un fi ier xml (Extended Markup Language) denumit
AndroidManifest.xml, stocat în fisierul rădăcină al proiectului. In acest fi ier sunt descrise
componentele folosite în aplica ie i alte informa ii referitoare la permisiuni le necesare pentru
aplica i e.. Structura acestui fi ier impune prezen a unui tag rădacină manifest urmat de tag –
ul application în interiorul căruia vor fi descrise componentele ce alcătuiesc aplica ia.
Procese si fire de executie in Android

29 Atunci când e necesară pornirea unei aplicații, sau a unei anumite componente dintr -o
aplicație Android pornește automat un nou proces Linux cu un singur fir de execuție pentru
componenta respectivă. Acest proces este cunoscut și sub numele procesul principal (procesul
main) al aplicației. n cazul în care a fost pornit un proces pentru o componentă aparținând
unei aplicații anume, atunci orice cerere ulterioară de a rula alte componente apartinând
aceleași aplicații vor fi executate în același process nefiind creat unul nou.
Ciclul de viata
Activitatile sunt en titati ce sunt adiminstrate in stiva, atunci cand o noua activitate este
pornita, ea apare deasupra celei vechi. O activitate se poate afla in una din cele 4 stari
posibile :
 In prim plan – in aceasta stare activitatea se afla in pozitia cea mai inalta in s tiva. In
mod obisnuit aceasta este momentul in care utilizatorul interactioneaza cu ea .
 In plan secund – atunci cand utilizatorul nu mai interactioneaza cu ea, dar inca este
prezenta pe ecranul dispozitivului. Aceasta stare se poate intampla daca o noua
activitate ce nu acopera tot ecranul sau este transparenta apare pe ecran.
 Oprita sau ascunsa – atunci cand o noua activitate acopera vechea activitate. Ea isi
pastreaza in continuare datele si starea interfetei , dar daca nu reapare in scurt timp
este de ce le mai multe ori oprita de sistem pentru a elibera memoria .
 Sistemul poate decida sa distruga activitatea in orice moment pentru a elibera
memoria. In acest caz activitatea trebuie recreata cu totul.
Ciclul de viata este controlat de 6 metode: onCreate(), onStart(), onResume(),
onPause(), onStop(), onDestroy() . Fiecare apelandu -se intr -un moment anume. In figura …. de
mai jos se poate observa detaliat ciclul de viata al unei activitati.

Exista 3 intervale de timp ce sunt cel mai des observate :

 Intregul ciclu de viata – acesta sa intampla de la primul apel al functiei onResume()
pana la apelul functiei onDestraoy()
 Ciclul de viata al vizibilitati activitati – acesta se intampla intre apelul metodei
onStart() si onStop(). In timpul acesta utilizatorul poate vedea si interactiona cu
activitatea
 Ciclul de viata al utilizari activitati – acesta se intampla intre apelul metodei
onResume() si onPause(). In acest timp activitatea este vizibila si se poate interactiona

30 cu ea, dar poate oscila intre starea de pauza si cea normala (de exemuplu se poate
inchide ecranul).

Ciclul de viata al fragment elor

Ciclul de viata al fragmentelor este destul de asemanator ca cel al activitatilor. La fel
ca o activitatea, un fragment se poate afla in 3 stari : Activ (Resumed) , Inactiv (Paused) si
Oprit (Stopped). O activitate poate salva aceste stari in cazu l distrugeri procesului. Marea
diferenta dintre ciclul de viata al unei fragment si al unui activitati este faptul ca o activitatea
este stocata intr -o stiva ce este administrata de sistem, iar fragmentul este stocat intr -o alta
stiva optionala, doar daca este apelata metoda addToBackStack() atunci cand acesta este
afisat pe ecran. De retinut ca acest ciclu poate fi influentat de ciclul de viata al activitatii
parinte.
In fig …. de mai jos este prezentat ciclul de viata complet al unui fragment

Resursele

In dezvoltarea Android aproape toate lucrurile sunt o resursa, stabilirea clara a
entitatilor ce pot fi folosite si accesata in aplicatie este o parte foarte importanta. Resursele
pot fi orice, de la culori, imagini,layout, meniuri pana la siruri de caract ere. Utilitatea acestei
abordare este ca ni ci o valoare nu este scrisa in cod (hardcodat) . Cea mai simpla si utilizata
intrebuintare a folosiri acestor resurse este in procesul de localizare al aplicatiei, adica atunci
cand folosim resurse de tipul siruril or de caractere pentru a stoca textele in mai multe limbi si
pentru a le afisa in functie de preferintele utilizatorului.

Resursele intalnite in dezvoltarea android sunt:

Nume Fisier Descriere
Property
Animations animator Un fisier XML ce contine animatii pentru
proprietati
Drawables drawable Fisiere Bitmap sau XML ce sunt folosite
pentru grafica
Layout layout Fisier XML ce defineste interfata grafica a
utilizatorului

31 Nume Fisier Descriere
Menu menu Fisier XML ce defineste meniul
Values values Fisier XML ce defineste valori ca sirurile
de caractere, numele, culori, etc.

Fisierele de tip Layout:

Un fisier de tip layout contine structura unei interfetei grafice. Organizarea
elementelor se face ca cea a unui arbore . Componentele din aceasta ierarhizare sunt de tipul
View si ViewGroup ( Fig. …. ). View -ul reprezinta o componenta specifica cu care utlizatorul
poate interactiona, iar ViewGroup reprezinta o componenta recipient pentru mai multe
obiecte View.

Fig …..
Un View este reprezentat de catre un widget, elementul cu care utilizatorul
interacti oneaza in diverse modu ri. Acestea pot fi elemente in care este afisat textul, butoane,
campuri de scris, etc.
Un ViewGroup este reprezentat de catre un layout. Adica un recipient pentru
widgeturi. Tipul recipientului influenteaza modul de aranjare dinaun tru lui.
Aceste componente sunt structurate in fisiere XML (Extended Markup Language).
Orice element intr -un astfel de fisier trebuie sa inceapa cu un tag de deschidere si sa se
termine cu unul de inchidere (similar limbajului HTML) . Orice este cuprins i n tagul de
deschidere este considerat un atribut al acelui element. Orice este cuprins intre tagul de
deschidere si cel de inchidere este considerat un element copil, care la randul lui poate avea
atribute si alte elemente. In Exemplul ….. avem ca atribu te pentru LinearLayout
latimea,inaltimea si orientarea unui, continand elementele TextView, pentru afisarea textului
si un Buton cu care utlilizatorul poate interactiona

32
Exemplul …..

Cel mai utilizat tip de layout este ConstraintLayout, acest tip de recipient permite
structarea elementelor din interior s ău folosind reguli de constrangere. O regula de
constrangere este precum o legatura intre doua elemente cu anumite proprietati. De exemplu
putem spune ca butonul este legat de marginea din stanga a ecranului la o distan ta de 16 dp.

In continuare fisierul Values este impartit in urmatoarele fisiere:

Nume Fisier Descriere
Colors res/values/colors.xml Pentru a defini culorile. Aceste
sunt valori hex
Dimensions res/values/dimens.xml Sunt stocate dimensiuni
folosite in layout( Padding,
Margins, etc. )
Strings res/values/strings.xml Sunt stocate valorile sirurilor
de caractere
Styles res/values/styles.xml Pentru stilurile aplicatiei, aici
se seteaza culoarea bari de
status si a bari de actiuni

Exemplu de fisier Strings :

<?xml version="1.0" encoding="utf -8"?>
<resources>
<string name="log_in" >Logheaza -te</string>
<string name="reseteaza_parola" >Reseteaza parola</string>
</resources>

Odata definite aceste resurse, ele pot fi folosite de oriunde din cod. De exemplu putem
seta textul din variabila resursa log_in pe butonul aferent. Avand astfel salvat textul putem
face localizarea foarte usor, creand un nou fisier pentru resurse string, precizam codul pentru
limba in care se vrea traduce rea sirurile de caractere, iar apoi folosind aceleasi nume doar se
traduce textul. Avand referintele in aplicatie catre resurse, sistemul stie automat sa preaia
limba principala a dispozitvului si ne va afisa sirul dorit. Aceste resurse pot fi accesate din
layout din xml sau dinamic din cod.

33

<Button
android:layout_width ="match_parent"
android:layout_height= "wrap_content"
android:text= "@string/log_in " />

Exemplu de fisier Colors:

<?xml version="1.0" encoding="utf -8"?>
<resources>
<color name="white">#FFFFFF</color>
<color name="black">#000000</color>
</resources>

Exemplu de fisier Dimen:

<resources>
<dimen name="button_height" >25dp</dimen>
<dimen name="button_width" >25dp</dimen>
<dimen name="font_size" >16sp</dimen>
</resources>

Pentru marimi este indicat sa se foloseasca marimea dp (density -pixel). Marime a
asigură o oarecare uniformizare pe o gama mai larga de dispozitive cu rezolutii diferite. De
exemplu daca luam un patrat de 4X4 pixeli pe doua dispozitive cu o densitate a pix elilor
diferita putem observa urmatorul lucru:

Pe un dispozitiv cu o rezolutie mai mica (exemplul din stanga) patratul va aparea mai
mare decat pe dispozitivul din dreapta cu o rezolutie mai mare. Introducand conceptul de
density pixel putem calcula o marime uniforma.

Ca o varianta de rezerva putem afisa diferite resurse in functie de dispozitivul pe c are
ruleaza aplicatia. Acest caz se intalneste cel mai des la setarea iconitei de pornire, in functie
de rezolutia ecranului.

Android studi o

34
Android studio este mediul de dezvoltare integrat (IDE) oficial pentru sistemul de
operare Android, construit d e compania JetBrains special pentru cei de la Google . Lansarea
oficiala a avut loc la conferinta Google I/O din anul 2013.
In anul 2019, foloseste ca limbaj principal Kotlin, continuand sa ofere suport pentru
Java.
Functionalitatile ce au adus renumele acestui mediu de dezvoltare sunt :
 Suport Gradle
 Integrare ProGuard si capacitatea de semnare a aplicatiilor
 Refactorizari optimizat e pentru dezvoltarea android
 Unelte pentru a urmari date despre impactul aplicatiei asupra sistemului
 Editor grafic pentru a putea asambla interfete grafice folosind componentele deja create sau
posibilitatea de a creea componente noi
 Dispozitive Virtuale Android pentru a putea rula aplicatia create fara a avea nevoie de un
dispozitiv fizic
 Suport pentru produsele Google, precum platforma Google Cloud si Firebase

Fig …..

In partea stanga a Fig…. se poate observa fereastra de navigare intr -un proiect
Android, in partea stanga editorul de cod, iar dedesubt consola pentru log -urile aplicației .

Emulatorul Android (AVD – Android Virtual Device)

Fiind un sistem open -source, exista o gama larga de dispozitive ce îl folosesc, iar
testarea pe dispozitivele reale este imposibila. Pentru a depasi acest impediment a fost creat
acest AVD. Emulatorul Android este un program so ftware ce simuleaza caracteristicile unui
dispozitiv cu Android ca sistem de operare.
 Emulatorul este compus din trei componente principale: profilul hardware, profilul
software si zona de stocare
 Profilul hardware defineste componentele dispozitivului ca si cum ar fi real. Cuprinde
componente precum senzorii, bateria, camera, etc.
 Profilul software cuprinde versiunea sistemului instalat
 Zona de stocare reprezinta memoria alocata de catre terminal emulatorului. Aceasta
contine datele utilizatorului, ap licatiile instalate, etc.

Gradle

Gradle este un sistem ce defineste modului în care urmează să fie compilat un proiect,
ce dependențe trebuie îndeplinite și care ar trebui să fie ultimul rezultat (sau rezultate) in
procesului de compilare .

35 Flexibilitatea pe care o ofera este un aspect important, ce il face o solutie preferata
pentru dezvoltatori find un mediu autonom, bazat pe linia de comanda si care poate fi integrat
usor in alte medii de dezvoltare printr -un simplu plug -in.
Dependente

Folosind acest princpiu se poate configura un arboere de dependente astfel incat
fiecare librarie poate defini la randul ei dependetele de care are nevoie pentru a functiona.
Ceea ce inseamna ca in momentul in care o librarie este inclusa intr -un proiect, toate
dependentele necesare acesteia sunt si ele adaugate. Aceste dependente pot fi locale, adica
sunt reprezentate de un fisier de pe dispozitiv sau pe server .
In Android dependentele de pe server sunt administrate de un alt serviciu numit
Maven. Daca o astfel de dependenta este declarata in Gradle folosind sintaxa Maven, atunci
acea librarie va fi downloadata si inclusa in proiect in mod automat. O astfel de dependenta,
pentru componentele de design material se noteaza:

'com.google.android.material:material:1.0.0'

Versiunile aplicatiei

Acest suport permite dezvoltatorilor sa creeze diverite variatii ale proiectului de baza.
De exemplu putem folosi acesta functionalitate pentru a lega la acelasi proiect de Android
Studio doua proiecte de Firebase (Testare si Productie).

Semnarea APK -ului

Poate administra datele de semnare ale proiectului astfel incat APK -ul se poate creea
automat din linie -comanda fara a mai le introduce inca o data.

Suportul ProGuard

Aceasta functionalitate optimizeaza bytecodul Java /Kotlin astfel incat logica acestuia
sa nu poata fi dedusa prin analiza.

Web Storm

Web Storm este un mediu de dezvoltare integrat creat special pentru a lucra cu
JavaScript, HTML, CSS si o varietate la rga de tehnologi moderne. Acest IDE este poreclit
„cel mai destept IDE pentru JavaScript” . Companii mari precum Booking.com si
SoundCloud il folosesc zi de zi in dezvoltarea produselor lor. El vine la pachet cu
autocompletare, functionalitati de refactoriz are, prevenirea erorilor in timp real, documentatie
in timp real si multe altele.

36

Capitolul 4. Proiectarea aplicatiei

Definirea cerintelor sistemului
In urma studiul de caz detaliat in capitolul 2, aplicatia dezvoltata trebuie sa respecte un
set de reguli, sa asigura un grad de incredere ridicat si sa ofere o serie de functionalitati ce
impreuna ating scopul propus, acela de a realiza un canal de comuni care suplimentar,
automat.
Sistemul este compus din doua componente : aplicatia utilizatorului final si platforma
destinata serviciului de urgenta, fiecare cu cerintele ei, detaliate in continuare:
In cazul aplicatiei utlizatorului final, ea trebuie: ca utilizatorul sa fie autentificat cu o
metoda sigura si relevanta contextului( C.A. – 1), sa permita adaugarea si stocarea datele
introduse de utilizator despre persoana ce foloseste dispozitivul, cum ar fi numele, prenumele,
varsta, un istoric medical, poza, etc. ( C.A. – 2), numerele de urgenta (minim 1) ce activeaza
trimiterea de date ( C.A. – 3) si persoanele apropiate ce vor fi notificate in cazul unei urgente
printr -un SMS cu un text predefinit ce contine si locatia din momentul apelari serviciului
(C.A. – 4). Odata ce aplicatia detine aceste date, canalul de comunicare poate fi activat.
Deoarece intr -o situatie de urgenta, nivelul de agitatie este extrem de mare si fiecare secunda
conteaza, aplicatia nu trebuie sa fie un impediement in procesul de aler tare sau sa impuna
apelantului sa faca orice pas in plus. Aplicatia trebuie sa se activeze automat in momentul in
care s -a realizat apelul ( C.A. – 5), iar datele trebuie trimise conform protocolului AML ( C.A. –
6). Implementarea acestui canal de comunicare trebuie sa fie bidirectional, in caz de
calamitate se doreste obtinerea unei imagini de ansamblu asupra victimelor dintr -o anumita
zona. Acest lucru se poate obtine prin declansarea aplicatiei de la distanta fara a fi nevoie de
apelarea serviciului de urg enta( C.A. – 7). Internetul ofera un mijloc de comunicare rapid, dar
vine cu un dezavantaj, zona de acoperire este restransa, iar pentru un astfel de context este
inadecvat. Aplicatia trebuie sa trimita datele fara sa se bazeze pe internet ( C.A. – 8)
In cazul platformei aceasta trebuie sa ofere locatia si marja de eroare a apelantului
(C.P. – 1), datele ce leaga acea locatie de apel (C.P. – 2) si datele adiacente ( C.P. – 3). Timpul
dintre primirea datelor si afisarea acestora trebuie sa fie minim, de pre ferat aceasta operatie sa
fie in timp real ( C.P. – 4), iar in caz de calamitate trebuie sa ofere posibilitatea autoritatilor sa
declanseze toate dispozitivele ce au aplicatia dedicata sistemului instalata ( C.P. – 5)
Toate cerintele de mai sus pot fi gasite in tabelele de mai jos:

Identificator Descriere
C.A. – 1 Autentificare securizata si adecvata contextului
C.A. – 2 Adaugarea si stocarea datelor adiacente
C.A. – 3 Adaugarea si stocarea persoanelor
C.A. – 4 Adaugarea si stocarea numerelor de urgenta
C.A. – 5 Declansarea automata a aplicatiei
C.A. – 6 Construirea mesajului conform protocolului AML
C.A. – 7 Declansarea aplicatiei de la distanta

37 C.A. – 8 Trimiterea datelor fara internet
Tabelul …. Cerintele Aplicatiei

Identificator Descriere
C.P. – 1 Afisarea locatiei apelantului
C.P. – 2 Legarea datelor cu apelul
C.P. – 3 Afisarea datelor adiacente
C.P. – 4 Afisarea cerintelor 1,2,3 in timp real in platforma
C.P. – 5 Posibilitatea declansarii modului de calamitate
Tabelul …. Cerintele Platformei

Constrangerile sistemului

Helpifi doreste a fi un sistem destinat folosiri de catre publicul larg. Aplicatia trebuie
sa fie usor de utilizat si configurat , sa ruleze p e toate tipurile de telefoane inteligente si sa
ofere rezultate viabile. Punand in balanta nivelul de incredere al senzorilor de pe dispozitive,
versiunile Android ale acestora , distributia pe piata conform Fig …. din capitolul ….
functionalitatilor ne cesare dezvoltari s-a luat decizia ca versiunea minima pe care sa
functioneze aplicatia sa fie Android 5.0. O iteratie majora in istoria sistemului ce la momentul
actual acopera 89,3% din piata de telefonale Android.
Platforma trebuie sa fie simpla si datele aparute usor de interpretat de catre cineva cu o
minima pregatire . Pentru a putea afisa datele trebuie sa existe o conexiune stabila si rapida la
internet.
Intregul sistem trebuie conceput in asa fel incat eroarea umana sa fie cat mai mica.

Proiectarea de ansamblu

Diagrama cazurilor de utilizare a aplicati ei Android Helpifi

Pe diagrame sunt prezentate ac iun ile dintre variantele p osibile de utilizare . Diagrama
reflectă cerin ele către sistem din punct de vedere al utilizatorului. Aceasta schema a fost
realizata folosind standardul UML
UML (Unified Modeling Language) este un limbaj realizat pentru
conceperea,vizualizarea si documentarea unui produs software.
In urma descrierilor facute in studiul cerintelor se contureaza urmatoare le cazuri de
utilizare:
 Autentificarea utilizatorului
 Adaugarea , vizualizarea si modificarea datelor despre utilizator introduse in aplicatie
 Adaugarea , vizualizarea si modificarea numerelor de urgenta declansatoare
 Adaugarea , vizualizarea si modificarea persoanelor de contact ce vor fi anuntate in
caz de urgenta
 Declansarea aplicatiei in cazul apelari unui numar declansator salvat
 Declansarea aplicatiei in caz de calamitate folosind platforma Helpifi

38
Actorii care interactioneaza cu sistemul sunt urmatorii:
 utilizatorul – acesta decide in orice moment al desfasurarii aplicatiei unde si ce anume
doreste sa faca
 sistemul (aplicatia) – preia controlul cand este apelat un numar de urgenta sau este
necesara o incarcare in memorie a elementelor, i nstantiere a claselor si formare de noi
obiecte

Diagrama generala a cazurilor de utilizare este prezentata in Fig. …… ,iar cu ajutorul ei se
poate delimita aria de cuprindere a sistemului .

Fig. ….. Diagrama generala a cazurilor de utilizare

Detalierea cazurilor de utilizare
Caz 1 – Ecranul de autentificare : primul contact al utilizatorului cu aplicatia se indeplineste
aici, parcursul utilizatorului in aplicatie trebuie sa fie cat mai intuitiv si mai rapid, astfel am
ales posibilitatea logari cu numarul de telefon in defavoarea metodei clasice cu email si
parola .
Actor : Utilizatorul final
Preconditi : pentru a ajunge in acest caz, utilizatorul trebuie sa aibe aplicatia instalata si sa o
deschida.
Pasi: Odata deschisa aplicatia, actorul, va vedea campul de autentificare in care trebuie
introdus numarul de telefon. In cazul in care este introdus un numar invalid de telefon, o
eroare va aparea, aducand la cunostinta acest lucru. Verificarea numarului de telefon se
realizeaza prin apasarea buton ul dedicat, operatie ce initializeaza verificarea pe serverele
Firebase si trimiterea unui SMS cu codul de autentificare catre numarul in cauza. Utilizatorul
trebuie sa introduca acel cod in noul camp indicat. In cazul in care codul nu corespunde se va
aduce la cunostinta acest lucru. De mentionat este faptul ca acest proces se intampla o singura
data, la prima intrare in aplicatie dupa instalare. Odata trecut cu succes si acest pas utilizatorul
inainteaza catre Cazul 2 de utilizare.

Caz 2 – Meniul Princip al: ofera posibilitatea utilizatorului de a naviga catre ecranul de:
1) numere de urgenta
2) persoane de contact

39 3) fisa medicala

Actor : Utilizatorul final
Preconditii: pentru a ajunge in acest caz, utilizatorul trebuie sa fie autentificat (Cazul 1) si sa
aibe date despre toate cele trei sectiuni.
Pasi : In acest moment utilizatorul este autentificat . Daca este prima data cand ajunge in acest
caz el este ghidat sa treaca prin toate cele trei optiuni din meniul principal. Daca nu este prima
data el poate vizualiza datele personale introduse anterior, iar pe celelalte le poate accesa
pentru actualizare. Fiecare meniu reprezinta un caz de utilizare separat.
Caz 2.1 – Meniul Fisei Medicale : ofera posibilitatea vizualizari si actualizarii datelor
personale, nume, prenume, adresa de domiciliu, poza si despre fisa medicala , in aceasta
sectiune trebuie sa se regaseasca date precum istoricul medical, boli cronice, alergii, daca
utilizatorul urmeaza vreun tratament, etc

Fig……
Actor : Utilizatorul final
Preconditii : pentru a ajunge in acest moment utilizatorul trebuie sa fie autentificat, sa nu
aibe date completate despre fisa medicala sau sa aleaga modificarea acestora.
Pasi : Utilizatorul trebuie sa adauge datele conform indicatiilor din campurile prezente .
Fiecare camp are o validare interna, de exemplu : este verificat formatul e -mailului. In cazul
in care datele lipsesc sau nu sunt introduse corect o eroare va fi afisata. La finalizarea
introduceri datelor trebuie apasat buton de salvare, ce va salva datele si va intoarce utilizatorul
in meniul principal.

Caz 2.2 – Meniul numere de urgenta : utilizatorul poate adauga, vizualiza sau sterge
numerele de urgenta ce declanseaza a plicatia din fundal

Fig……
Actor : Utilizatorul final

40 Preconditii : pentru a ajunge in acest moment utilizatorul trebuie sa fie autentificat , sa aibe
date despre fisa medicala si sa nu aibe date numere de urgenta setate sau sa aleaga
modificarea acestora
Pasi : Utilizatorul poate vizualiza numerele de urgenta adaugate. A cesta are optiunea de a
adauga numere noi de urgenta prin apasarea butonului “ + ”, odata apasat va aparea o
fereastra ce il va ghida pe utilizator sa introduca noul numar sau optiunea de stergere directa a
acestuia prin apasarea butonului “X”.

Caz 2.3 – Meniul persoane de contact: utilizatorul poate adauga, vizualiza sau sterge
numerele persoanelor de contact in caz de urgenta .

Fig. …….
Actor : Utilizatorul final
Preconditii : pentru a ajunge in acest moment utilizatorul trebuie sa fie autentificat , sa aibe
date despre fisa medicala, date despre numerele de urgenta si sa aleaga sa vizualizeze
persoanele de contact in caz de urgenta
Pasi : Utilizatorul poate vizualiza persoanel e de contact, poate adauga noi persoane prin
apasarea butonului “Adauga persoana de contact” , completarea manuala numelui complet si a
numarului de telefon sau preluarea acestor date direct din agenda si apasarea butonului
salveaza, poate edita sau sterge.

41

Caz 3 – Ecran Apel (declansarea aplicatiei) : odata ce utilizatorul apeleaza unul din
numerele de urgenta salvate, aplicatie se deschide automat, in fundal , trimitand catre serviciul
de urgenta datele salvate.

Fig. …….
Actor : Aplicatia
Preconditii : pentru a ajunge in acest moment utilizatorul trebuie sa fie autentificat, sa aibe
date despre fisa medicala, date despre numerele de urgenta si sa aibe aplicatia functionala
(trebuie sa fie prezenta notificarea aplicatiei in bara)
Pasi : In acest caz ut ilizatorul nu trebuie sa faca nimic, in momentul initializari unui apel ,
aplicatia verifica numarul si il compara cu cele de urgenta salvate. Daca raspunsul primit este
unul pozitiv, aplicatia incepe sa preia datele de la senzori si sa le trimita catre ser ver.

Caz 4 – Declansarea inversa a aplicatiei : in caz de calamitate aplicatia poate fi activata de
la distanta de catre un serviciu de urgenta autorizat. Activarea presupune trimiterea automata
de date catre server, practic inlocuieste initializarea apelului de urgenta
Fig. …….

Actor : Aplicatia
Preconditii : pentru a ajunge in acest moment utilizatorul trebuie sa fie autentificat, sa aibe
date despre fisa medicala, date despre numerele de urgenta si sa aibe aplicatia functionala
(trebuie sa fie prezenta notificarea aplicatiei in bara) , sa se produca o calamit ate si sa fie
activat protocolul de declansare inversa din platforma Helpifi de catre serviciul de urgenta
autorizat.
Pasi : In acest caz utilizatorul nu trebuie sa faca nimic, in momentul initializari procedurii de
urgenta aplicatia verifica expeditorul c ereri, verificand autenticitatea acestuia . Daca raspunsul
primit este unul pozitiv, aplicatia incepe sa preia datele de la senzori si sa le trimita catre
server.

42

Diagrama cazurilor de utilizarea a platformei Helpifi
In urma descrierilor facute in studiul cerintelor se contureaza urmatoarele cazuri de utilizare:

Caz 1 – Ecranul de autentificare : primul contact al utilizatorului cu aplicatia se indeplineste
aici, parcursul utilizatorului in aplicatie trebuie sa fie cat mai intuitiv si mai rapid, astfel am
ales posibilitatea logari cu numarul de telefon in defavoarea metodei clasice cu email si
parola.
Fig. …….
Actor : Operatorul autorizat al serviciului de urgenta inscris in platforma
Preconditi : pentru a ajunge in acest caz, actorul trebuie sa fie inscris si autorizat in platforma
si sa aibe o conexiune stabila si rapida la internet.
Pasi : In acest caz utilizatorul trebuie sa se autentifice cu un mail autorizat de catre un admin
si o parola aferenta.

Caz 2 – Harta : In aceast ecran sunt afisate indicatoarele de locati e ale apelurile efectuate
catre serviciul inscris, se pot vizualiza datele apelantilor si se poate activa protocolul cazului
de calamitate.
Fig. …….
Actor : Operatorul autorizat al serviciului de urgenta inscris in platforma
Preconditi : pentru a ajunge in ace st caz, actorul trebuie sa fie inscris si autorizat in
platforma, sa aibe o conexiune stabila si rapida la internet si sa fie autentificat
Pasi : In momentul unui apel efectuat catre serviciul in cauza, operatorul va prelua
conversatia telefonica, iar in maxim 20 de secunde pe harta va aparea un indicator al locatie
impreuna cu un cerc in jurul lui ce reprezinta precizia. Pentru a putea vizualiza datele trimise
operatorul trebuie sa dea click pe indicator, trebuie sa confirme veridicitatea datelor cu
apela ntul si sa trimita echipajul de interventie adecvat. In cazul unei calamitati personalul
autorizat trebuie sa foloseasca butonul de “Reverse trigger” pentru a activa protocolui si sa
astepte primirea datelor de la toate dispozitvile ce au instalata aplicat ia Helpifi.

43

Diagrama claselor aplicatiei Android Helpifi
Locul principal în programarea orientată pe obiecte îi revine dezvoltării modelului
logic a sistemului în diagrama claselor , al carei scop este de a structura natura statica a
claselor .
Nota ia claselor în limbajul UML este simplă i intuitiv percepută de to i.
Nota ia în UML ne pune la dispozi ie o largă gamă de posibilită i pentru reflectarea
informa iei(clase abstracte, stereotip, interfe e detaliate etc.).
Diagrama claselor serve te pentru reprezentarea statică a modelului în terminologia
claselor programării orientate pe obiecte. Diagrama claselor poate reflecta diferite rela ii între
diferite esen e ale domeniului respectiv, a a ca obiecte, subsisteme, totodată determinând
structura internă i tipurile de rela ii.
Diagrama claselor reprezintă un graf, vârfurile căruia sunt ni te elemente de tip
„clasificator”, care sunt într -o rela ie cu diferite tipuri structuri. De men ionat că diagrama
claselor deasemenea poate să con ină interfe e, pachete, rela ii, i chiar exemplare aparte, a a
ca obiecte i legături. Pe această diagramă sunt reprezentate structurile legăturilor modelului
logic al sistemei, care la rândul sau este static, i nu depinde de timp.
Relațiile între clase

Înafară de structura internă a claselor pe diagramă se mai indică i diferite rela ii între
clase. Dar totodată entitatea tipurilor a astfel de rela ii este fixată în limbajul UML i este
predefinită de semantica acestor tipuri. Rela iile de bază sunt
1. Rela ia de dependen ă
2. Rela ia de asociere
3. Rela ia de generalizare
4. Rela ia de realizare
Fiecare din aceste rela ii are reprezentarea sa grafică.

Fig…. Diagrama claselor pentru aplicatia Android Helpifi

In figura de mai sus este reprezentata dia grama claselor ce schiteaza in linii mari
clasele cele mai importante ale aplicatiei . De exemplu toate ecranele(meniurile) au la baza o
clasa abstracta pe care o exting cu scopu l de a implementa corpul functiei asa cum este
specific fiecarui meniu. Astfel in linii mari, toate meniurile trebuiesc initilizate, afisate,
ascunse, redimensionate si randate, numai ca fiecare astfel de metoda este specifica fiecarui
meniu.
Diagrama starilor aplicatiei Android Helpifi

44 Diagrama claselor reprezintă din sine modelul logic a reprezentării statice a sistemului
modelat. Dar pentru majo ritatea sistemelor fizice înafară de reprezentarea statică este nevoie
de o reprezentare dinamic ă. Anume diagrama st ărilor este o reprezentare dinamică a
sistemului proiectat.
Diagrama de stare are 3 feluri de stări
1. început – este reprezentat în formă de cerc umplut de culoare neagră i corespunde
stării obiectului în momentul creării.
2. desfășurare – reprezintă în formă de dreptunghi
3. sfârșitul – se reprezintă unul în altul

Diagrama de stare poate avea numai un început, dar sfâr ituri câte avem nevoie. Când
obiectul se află într -o stare co ncretă asupra lui se poate îndepli ni orice proces. In Fig …. este
prezentata diagrama starilor pentur ecranul de Apel.

Fig …

Diagram a de activitate a aplicatiei android Helpifi

Se folosesc pentru modelarea aspectelor dinamice ale unui sistem, la diferite nivele:
incepand de la nivelul „business process”, pana la nivel de operatie a unei clase. Din acest
motiv, in diagramele de activita te se folosesc un numar mare de simboluri.
O diagrama de activitate poate reda pasii unui proces de calcul, fluxul controlului intr –
o operatie, executia secventiala sau paralela a unor actiuni.
O actiune reprezinta un singur pas intr -o activitate: un calcul, gasirea unor date, verificarea
unor date, etc. O actiune se reprezinta printr -un dreptunghi rotunjit in care este inscris text
(numele actiunii) in format liber.
Actiunile redate intr -o dia grama de activitate pot fi executate de diferite obiecte, care
sunt active in acelasi timp. Astfel, o diagrama de activitate poate reda, la un nivel de
detaliu mai ridicat, interactiunea dintre obiecte reprezentata printr -o diagrama de
secventa.
Tipuri de noduri intr -o diagrama de activitate:
 Noduri executabile noduri actiune si noduri „tratare exceptie”
 Noduri de control:noduri de decizie, nod final (final activitate, final flux), nod Fork,
nod Join, nod initial, nod unificare (merge)
 Noduri obiect
Căi i ntr-o diagrama de activitate:
 Flux control

45  Flux obiect

Fig …..

In Fig. … este prezentata diagrama de activitate a aplicatiei android Helpifi

Fig …..

SMS Gateway

Deoarece este exclusa folosirea internetului in cazul aplicatiei, a trebuit gasita o
solutie de comunicare intre ea si platforma, cea din urma f iind conectata in permanenta la
internet. Astfel cea mai buna solutie este folosirea unui gateway de SMS. Un gateway SMS
reprezinta un server conectat la internet cu un modul GSM . Acest mo dul poate gestiona
intrarile si iesirile dintr -o retea de telecomunicatii, in acest caz SMS -urile. Pentru acest proiect
a fost folosit serviciu tert de gateway SMS de la compania Telerivet. Folosind acest serviciu,
am redus costul de implementare si de intretinere al unui server , avand acces la unul
administrat de ei ce realizeaza procesul descris pe larg mai jos.
Pasi procesului :
 Aplicatie trimite datele folosind protocolul AML printr -un SMS catre acest gateway
 Pe server este apelata o functie din Google Cloud, ce primeste SMS -ul
 Functia interpreteaza datele primite si le scrie in baza de date sub formatul utilizat de catre
platforma

Proiectarea de detaliu si implementarea concreta

Principiul arhitecturii JetPack

Arhitectura este un model conceptual de structurare a elementelor esentiale si a logicii
unei aplicati. Structurarea se realizeaza decupland informatiile interne ale aplicatiei de
infromatile accesibile utilizatorului. Datorita acestei separari codul devine modular,
reutilizabil in diferite locuri facilitand dezvoltarea in paralel. Fiecare tip de arhitectur a are
principiile ei dar cateva dintre acestea se intersecteaza.

Principiul separari

46 Intr-o aplicatie android, cea mai intalnita problema este scrierea intregului cod in
activitate sau fragment. Aceste instante trebuie sa contina doar logica legata de view,
deoarece sunt detinute de sistem, el putand sa le distruga in orice moment. Separan d codul ce
nu are legatura cu datele finale prezentate utilizatorului se evita multe erori cauze de ciclul de
viata al activitati/fragmentului.

Reactiunea interfetei grafice la date

Este recomandat ca intr -o aplicatie interfata grafica sa reactionez e la date si nu invers,
datele sa se schimbe in functie de interfata. Este recomandata f olosirea pentru administrarea
datelor , a nivelului numit „Model”, o entitate independenta de nivelul interfetei grafice numit
„View” si implicit nu este afectata de sch imbarile ciclului de viata. Datele vor fi intr -un loc
sigur, separat, iar in cazul in care sistemul opreste aplicatia din diverse motive acestea nu se
vor pierde sau nu vor trebui citite din nou de pe server.
Cele doua concepte intalnite in majoritatea ar hitecturilor confera produselor software
un grad ridicat de testabilitate si stabilitate.

Ahitectura MVP (Model -View -Presenter)

Arhitectura Model -View -Presenter reprezinta structurarea elementelor pe trei straturi :
 Model – reprezinta nivelul ce detine datele aplicatiei, el este independent de ciclul de viata
al aplicatiei.
 View – reprezinta nivelul interfetei grafice, este nivelul cu care utilizatorul interactioneaza.
Este controlat de sistem si trebuie sa contina doar logica legata de interfata grafica.
 Presenter – reprezinta nivelul ce face legatura dintre cele doua straturi. El poate decide
asupra datelor afisate in View, le poate procesa si notifica View -ul de schimbarile datelor,
actualiz ând interfata grafica. Aici se afla logica aplicatiei.
Un dezavantaj al acestei arhitecturi il reprezinta administrarea intregi aplicatii de
catre o singura entitate.

Ahitectura JetPack

Arhitectura JetPack este special conceputa pentru dezvoltarea aplicatiilor in sistemul
Android. Ea seamana cu cea MVP aducand in plus nivelul „Repository” ce administreaza
datele din diferitele surse .

Fig ….

Facand o analogie cu arhitectura MVP, nivelul View este reprezentat de o activi tatea
sau fragment si de „ViewModel”, nivelul Presenterului este preluat de Repository iar Modelul
ramane neschimbat. In schimb exista si diferente majore. Urmand Fig… putem observa ca
fiecare componenta de pe un nivel superior depinde de cea de pe nivelul inferior, comunicarea

47 facandu -se intr -un singur sens, respectand principiul reactiuni interfetei la date. Adica datele
de pe un nivel inferior nu sunt trimise catre nivelul superior ci sunt ascultate schimbarile.
Respectand principiul separari eliminarea unei componente de pe un nivel superior nu le
afecteaza pe celelalte. Un exemplu este eliminarea interfetei grafice, ce este reprezentate in
cazul nostru de catre act ivitate/fragment, aplicatia este inca functionala si poate fi controlata
din consola.
Arhitectura aceasta se bazeaza pe folosirea unor componente realizate special de catre
echipa Google. Cateva dintre aceste componente folosite sunt :
 LiveData – aceasta este o structa observabila ce incapsuleaza orice tip de variabila. Odata ce
acea variabila se schimba, structura emite catre toate celelalte componente ce observa , un
apel de notificare. Avantajul folosiri acestei structuri este capacitatea sa de a inregi stra
observatori tinand cont de ciclul lor de viata. Adica in momentul in care sistemul opreste un
fragment ce asculta schimbarile unei componente de tip LiveData, componenta stie sa nu
mai trimita notificari acelui fragment. De mentionat este faptul ca pr ocesarea acestora se
realizeaza prin operatia de mapare si ascultarea lor este permisa doar in componente de tip
View

 ViewModel – este o componenta ce este persistenta pe toata durata sesiuni aplicatiei.
Aceasta administreaza structurile de tip LiveData c e sunt expuse pentru a fi observate din
activitate/fragment. Este recomandat ca pentru fiecare activitate/fragment sa existe cate un
ViewModel propriu.

 Navigation – este o componenta create pentru a lamuri paradigma navigari in aplicatie
folosind arhite ctura descrisa mai sus. Incapsuleaza toate metodele necesare schimbari
eficiente, din punct de vedere al memoriei, a fragmentelor si a activitatilor. Pe langa
functionalitati aceasta componenta vine si cu editor grafic in care se poate trasa parcursul
utilizatorului in aplicati e folosind legaturi intre fragmente. Tot aici se pot configura si
animatiile de tranzitie.

Descrierea componentelor din arhitectura JetPack :

 View : reprezentat de a ctivitati si fragmente . Find dependente de sistem, este recoman dat
ca aceste entitati sa contina doar datele finale pregatite pentru afisare si logica acestui
proces .
 ViewModel : Responsabilitatea pregatiri datelor finale revine componentei ViewModel ce
persista pe toata durata aplicatiei. In aceasta componenta se afl a logica de pregatire a
datelor ce sunt stocate si procesate la randul lor de Repository si logica interactiuni
utilizatorului cu componentele din View.
 Repository : Contine logica aplicatiei, ace sst nivel face legatura dintre mai multe
componente “Model” si le expune pentru a fi ascultate prin procesul de mapare in
ViewModel
 Model : Reprezinta o structura predefinita a datelor
 Room : Componenta ce face posibila comunicarea cu surse de date si servic ii externe

48 Structura bazei de date

Luand in considerare cerintele sistemului, pentru proiect s -a folosit baza de date
Firebase . Deoarece avem doua componente, alert ele si datele utilizatorilor, s -a ajuns la decizia
de a se folosi pentru alerte baza de date in timp real Firebase si cea Firestore pen tru datele
utilizatorilor. Avantaje si detaliile despre acestea se pot gasi la capitolul …..
Inainte de a incepe implementarea in cod, a fost facuta o analiza pentru a determina ce
date vor fi transmise. In urma acestei operatii am ajuns la urmatoare a concluzie :
 Pentru utilizator : datele vor fi stocate in firestore deoarece aceasta baza poate tine un
volum mai mare , iar citirea acestora nu este necesara in timp real. Urmatoarea
structura ( Fig. ….) a fost conceputa: Toate datele despre profilele utilizatorilor sunt
tinute intr -o colectie cu numele “users_profile”. Pe urmatorul nivel avem in
subcolectii document e mixte, ce au atat date cat si alte subcolectii. In subcolectiile
“emergency_numbers” si “contacts” sunt structurate numerele de urgenta si
perso anele de contact . Datele din document sunt urmatoarele pe cheia “address”
avem valoarea adresei, pe cheia “details” avem toate detaliile fisei medicale, pe cheia
“email” adresa casutei email, iar p e cheia “phoneNumber” numarul de telefon cu care
s-a autentificat

Fig. …

In subcolectia „emergency_numbers” Fig…. . avem alte subcolectii reprezentate prin UID ce
au pe nivelul inferior un document ce are pe cheie „emergencyPhoneNumber” numarul de
telefon al persoanei apropiate la care se va trimite SMS -ul cu locatia si care ii atentioneaza ca
s-a efectuat un apel de urgenta de la cineva drag.

Fig…..

In subcolectia „contacts” Fig…. . avem alte subcolectii reprezentate printr -un id unic
generat automat in momentul incarcari datelor. Subcolectiile au pe nivelul inferior un
document ce are pe cheie „imageUrl” url -ul pe care il obtinem dupa ce am incarcat cu succes
o poza pentru persoana de contact in Firebase Storage . Pe cheia „name” se va pune numele iar
pe cheia „phoneNumber” numarul de telefon al acestuia.

Fig ….

49  Pentru alerte: datele sunt stocate in baza de date in timp real Firebase, deoarece dorim
un raspund cat mai rapid de la server, in momentul producer i unui incident si o
gestionare sigura si de precizia a unui calup extrem de mare de astfel de evenimente.
Pentru alerte a fost conceputa urmatoarea structura Fig. …. Pe cheia “alerts” se vor
afla toate alertele inregistrare , identificate prin UID la care se adauga num arul de
telefon despartite prin caracterul “ ”. Pe nivelul urmator avem pe cheia UID valoarea
id-ului unic al utilizatorului, pe cheia “caller” avem datele despre apelant, pe cheia
“adr” avem adresa, pe cheia “name” numele complet, pe cheia “obs” avem deta liile
despre fisa medicala, iar pe cheia “phone” numarul de telefon de pe care s -a efectuat
apelul. Ultimul nod este cel mai importat lucru, pe cheia “location” avem datele
despre locatia apelantului, latitudinea,longitudinea si raza de precizie.

Fig… .

De mentionat faptul ca aceste date sunt procesate de server . Ele reprezinta rezultatul obtinut
prin combinarea datelor primite prin protocolul AML si cele din baza de date Firestor e.
Corelarea lor find facuta cu ajutorul id -ului unic al utilizatoruluil (UID).

Firebase Storage (Fig….) este structurat in doua directoare, „users” in care se afla pozele
utilizatorilor cu numele format din UID si unul „users_contacts” in care se afla pozele
persoanelor de contact, diferentiate printr -un id unic. In ca zul acestora id -ul nu este relevant,
deoarece se va folosi doar link -ul de download obtinut la incarcare si scris imediat dupa in
Firestore.

Fig …..

Aplicatia Android

Structura proiectului

In cadrul aplicatiei Android Helpifi este urmata arhitectura recomandata JetPack.
Datele sunt structurate pe nivelurile prezentate in cap … .
Structura fisierelor in proiect este realizata dupa componentele arhitecturii. Dupa cum
se poate observa in Fig…. fisierele principale sunt :
 “data” nivelul de date ce contine modele informatiilor folosite in aplicatie
 „repositories” ce contine toate componentele de acest tip.

50  “ser ices” ce contine clasele de tip Service
 “ui” ce se imparte in activitati si fragmente. In aceste fisiere se afla structurare pe ecrane
fisierul fragmentului/activitati si viewModelul aferent ( Fig….)
 “utils” in acest fisier se gasesc toate clasele ajutatoare folosite in cadrul proiectului.

Utilizand versiunea cea mai noua a mediului de dezvoltare Android putem folosi in același
proiect atat fisiere Java cat si fisiere Kotlin. Acestea find interoperabile, adica pot apela o
metoda scrisa in Java dintr -un fisier Kotlin sau invers.

Fig….

Fig….

Componentele de tip Manager

Inainte de a incepe dezvoltarea functionalitatilor , pentru a respecta arhitectura trebuie
create doua clase ce ajuta la administrarea componentelor „repository” si „view model” ,
specificarea dependentelor in fisierul gradle , a permisiunilor necesare in fisierul manifest si a
graficului de navigare conform diagramei cazurilor de utilizare.

RepositoryManager

RepositoryManager este defapt o clasa de tip Singletone ce are ca proprietati
componentele „repository”. Un singletone este o clasa ce poate avea o singura instanta la un
moment dat, pastrand aceasta instanta pe tot parcursul executiei programului. Acest a a fost
ales tocmai pentru functionalitatea sa , componentele ce tin date trebuie sa persiste pe toata
durata aplicatiei.
Limbajul kotlin fata de java vine in ajutor cu operatorul „object” ce incapsuleaza
comportament ul Singletone . Initializarea componentelor „repository” este delegata functiilor
lazy, deoarece managerul este creat la deschiderea aplicatiei , iar unele date nu sunt necesare
inca de la inceput . Datele vor fi create sau preluat e din baza de date doar in momentul in care
aplicatia chiar are nevoie de ele.

Fig …

ViewModelFactory

51 ViewModelProvider este clasa ce leaga activitatea sau fragmentul de view modelul ei,
returnand o instanta corespunzatoare in functie de fragmentul sau activitata trimisa ca
parametru. Deoarece arhitectura permite comunicarea doar intr -o singura directie din view
model in repository, a fost aleasa solutia injectari compo nentei necesare in view model.
Pentru a realiza acest lucru a fost extinsa clasa ViewModelProvi der si denumita
ViewModelFactory conform Fig … .
Acesta clasa a fost scrisa in Java utilizand acelasi principiu de Singletone. Spre
deosebire de limbajul Kotlin, comportamentul a trebuit implementat manual folosind metoda
getInstance().
Suprascri ind metoda create() , putem trimite ca parametru la instantiere componentele
necesare.

Fig … .

Confor m cerintelor aplicatiei si a functionalitatilor ajutatoare, in fisierul
manifest trebuie specificate permisiuni precum : posibilitatea interceptari si procesari
apelurilor efectuate, capacitatea de a accesa contactele din agenda, capacitatea de a trimite, a
primi si a citi SMS -uri, capacitatea de a citi starea telefonului, posibilitatea de a rula un
serviciu si cel mai important posibilitatea de a accesa si a folosi locatia.
In fig … se pot regasi toate aceste permisiuni . In functie de ti p, sistemul dec ide
daca trebuie cerut acordul utilizatorului sau nu.
Permisiunea de locatie este impartita in doua tipuri „coarse location” pentru o
localizare cu o precizie mai slaba, folosindu -se doar de datele obtinute din retea si „fine
location” ce este folosita p entru o localizare cu o precizie ridicata, folosindu -se atat de datele
GPS cat si de datele obtinute din retea.

Fig … .

Dependentele de alte librari trebuie trecute in fisierul gradle utilizand prefixul
„implementation”. In acest proiect au fost folosite librari cu licenta „open source”, adica
libere pentru utilizare. Aceste dependente au fost grupate in noua categori:
 Design : aceste librarii contin elementele de design material utilizate in interfetele grafice
 Kotlin : libraria kotlin ce permite utilizarea functionalitatilor acestui limbaj in Android Studio
 Lifecyle : librariile ce contine componentele dependente de cicl ul de viata. Din aceasta
categorie fac parte: view modelul, live data, etc.
 Firebase : toate componentele ce fac posibila comunicare a cu baza de date firebase
 Firestore : toate componentele ce fac posibila comunicare a cu baza de date firestore
 Epoxy : este o librarie open source dezvoltata de cei de la compania AirBnb pentru a schimba
modul in care adaptoarele pentru liste sunt folosite, eliminand codul standard generat.

52 Aceasta librarie ofera posibilitatea costruiri unei interfete grafice compl exe in interioriul unei
liste de tipul “Rec clerView”, printr -o abordare declarativa.
 Navigation : toate componentele jetpack ce permit utilizarea frameworkului de navigare
Android
 Picasso : este o librarie de descarcare a pozelor in mod asincron, salvarea /obtinerea lor din
memoria cache si incarcarea in elementele grafice din interfata
 AirLocation : este o librarie ce incapsuleaza procedeele de obtinere si procesare a
informatiilor primite atat de la retea cat si de la receptori GPS

Fig. …
Navigarea
Aplicatia este conceputa folosind conceptul „Single Activity App”. Activitatea
principala v -a contine si v -a prezenta toate celelalte fragmente, ea este pe post de recipient ,
influentand ciclul de viata al fragmentelor .
Pentru a putea folosi acest princip iu, layout -ul activitatii trebuie sa contina un element
de tipul <fragment> al carui scop este de a specifica locul in care se vor incarca interfetele
grafice ale fragmentelor si de a face legatura intre acestea si graficul de navigare. Aceasta
legatura se face utilizand atribut ul „ app navGraph = „@navigation/nume_grafic” „

Graficul de navigare

Navigarea manuala intre fragmente a dat multe batai de cap dezvoltatorilor putand
deveni o operatie complexa si incurcata, putand pierde foarte usor sirul cazurilor in care un
utilizator se poate afla. Acest framework a aparut din dorinta de a simplifica si a incuraja
utilizarea lor, incapsuland toata logica in componente intuitive si usor de folosit.
Folosind frameworkul de navigare JetPack, putem construi un grafic (Fig ….) ce leaga
toate fragmentele dintr -o aplicatie. Creand astfel un tip de diagrama a locurilor posibile pe
care un utilizator le poate accesa. Legaturile se realizeaza utilizand elemente de tipul <action>
ce cuprind punctul de plecare, de stinatia, animatia tranzitiei intre cele doua puncte si optional,
date. Aceasta harta va fi ulterior apelata din cod conform logicii aplicatiei, iar navigarea se va
produce automat. In cazul in care apar erori in cod, de exemplu navigam intr -un fragment ce
nu este legat de punctul de plecare in care se afla utilizatorul, o eroare va aparea, atentionand
dezvoltatorul.

Fig ….

Pentru a porni cu activitatea principala, in fisierul manifest trebuie specificat acest
lucru adaugand filtrul corespunzator in interiorul tagului activitati.

53

Odata p ornita activitata, avand elementul <fragment> descris mai sus , frameworkul de
navigare incarca primul fragment. Prin incarcare ne referim la instantierea clasei respective,
adaugarea acesteia in stiva d e navigare si in memoria dispozitivului.

Componentele vor fi prezentate in oridinea nivelurilor arhitecturii incepand de la
nivelul de baza:

Nivelul Model

Acest nivel contine toate clasele responsabile de comunicarea cu baza de date si
obiectele ce mapeaza structura entitatilor stocate explicate in cap … . In kotlin aceste clase se
numesc data class. In acest tip de clasa metoda equals() deriva din parametrii din constructor ,
functionalitate utila deoarece scuteste dezvoltatorul de a verifica manual egalitatea fiecarui
parametru in parte. Un exemplu poate fi observat in Fig…
Clasa ContactModel are in costructor parametrii name, phoneNumber si imageUrl
care sunt marcati ca optionali prin operatorul „?” si implementeaza clasa „Ser ializable”.In
kotlin variabilele pot avea valoarea null doar daca sunt marcate ca optionale. Acest principiu
ajuta la evitarea erorilor NullPointerException. Atribuind intre paranteze parametrii optionali
care au valoarea implicita null kotlin genereaza u n constructor gol si un constructor ce
necesita toti parametrii. Toate modelele de date ce sunt folosite pentru a mapa datele din
Firebase forteaza dezvoltatorul sa faca acest lucru, deoarece acest proces are nevoie de un
constructor gol.
Implementarea interfetei Serializable ajuta la stocarea obiectelor in memoria Cache.
Restul claselor model sunt similare si se pot gasi in anexa….

Fig.

Componentele de tip Room sunt acele componente ce fac legatura directa dintre baza
de date si aplicatie.
Deoarece se doreste ca toate datele ce trebuie sa ajunga in fragmente sa poata fi
observate, am creat o clasa noua ce combina functionalitatea unui recipient LiveData cu cel al
componentei ce realiza citirea. In proiectul Helpifi exista cinci astfel de cla se :
 FirestoreQueryLiveData
 FirestoreCollectionMutableLiveData
 FirestoreCollectionQueryLiveData

54  FirestoreDocumentMutableLiveData
 FirebaseAuthLiveData

FirebaseAuthLiveData

FirebaseAuthLiveData este o clasa ce extinde functionalitatea unui live data si
incapsuleaza date despre starea de autentificare a utilizatorului
In mod normal stare a autentificari se putea obtine printr -un callback ce era apelat in
momentul schimbari. Din dorinta de a separa si incapsula comportament ul, adaugand
capabilitatea de a respecta ciclul de viata a fost extinsa clasa LiveData.
In interiorul clasei noi s-a obtinut o referinta catre obiectul FirebaseAuth, el face
legatura dintre aplicatie si modului de autentificare firebase. In momentul in care starea se
schimba preluam obiectul FirebaseUser si il setam in recipient (Fig. …) . Astfel putem atasa un
observator ce v -a primi aceste valori setate automat. Deoarece aceasta conexiune este
permanenta trebuie modelata dupa ciclul de viata al fragmentului sau activitati in care e ste
instantiata. Extinzand clasa LiveData avem acces pe langa metoda setValue() si la callback –
urile ciclului de viata. Se suprascriu cele doua metode specifice, onActive() atunci cand
incepe ciclul de viata si onInactive() atunci cand se sfarseste ( Fig .. ..).
Un aspect foarte important este acela ca onInactive() si onActive() se apeleaza si in
momentul in care rotim telefonul din modul portret in cel orizontal, deoarece interfata gra fica
este distrusa, iar fragmentul este pus pe pauza pana cand aceasta e ste recreata cu orientarea
noua, perioada in care orice live data observat se opreste din a emite valori. Inlaturarea si
adaugarea callback -ului intr-un astfel de caz este ineficient a, avand in vedere ca folosim o
baza de date din cloud. Pentru a evita ace st lucru de fiecare data cand un live data devine
inactiv amanam inlaturarea cu doua secunde, timp arhisuficient pentru orice fragment sa fie
reinitializat. Daca in aceasta fereastra de timp devine din nou activ verificam variabila
listenerRemvoePending, c e ne indica daca trebuie sa anulam actiunea initiata mai devreme
sau daca este prima data cand live data -ul devine activ si trebuie pur si simplu adaugat
callback -ul.

Fig. …

Fig ….
Fig ….

Firebase CollectionLiveData

Aceasta clasa este responsabila de obtinerea si maparea tuturor documentelor dint -o
colectie stocata in Firestore. Dependenta de ciclul de viata este asemanatoare cu cea a clasei
FirebaseAuthLiveData descrisa mai sus. Aceasta clasa primeste ca parametrii: ruta /calea de pe
care se gasecc datele si daca se doreste pastrarea unei legaturi in timp real sau obtinerea lor o
singura data. In fig. …. avem callback -ul ce se ataseaza de referinta pentru o conexiune in

55 timp real. Datele primite sunt verificare si fiecare document es te mapat pe modelul aferent .
Datele sunt organizate intr -un vector ce la final este emis catre toti observatori. Pentru a
adauga acest listener, el trebuie instantiat si trimis ca parametru folosind metoda
addSnapshotListener(listener) ce se apeleaza pe obiectul de referinta (un obiect de tipul
CollectionReference) primit din exterior Fig … . Pentru a prealua dat ele o singura data se
foloseste metoda get() pe aceasi referinta.

fig. ….

Fig … .

Restul componentelor au un comportament similar si se pot gasi in anexa….

Nivelul Repository

Aceste componente sunt separate in functie de categoria de date pe care le
incapsuleaza. Pentru a fi cat se poate de modulare, aceste clase implementeaza o in terfata cu
metodele necesare.
In Fig …. este prezentata interfata componentei repository folosita pentru a obtine
datele de profil. In cazul in care decidem sa schimbat baza de date, trebuie reimplementat
doar modul de obtinere al acesto ra, nivele su perioare utilizand aceleasi metode.

Fig ….

In Fig. … este prezentat modul in care sunt obtinute datele de contact . Pentru a procesa datele
se folosesc transformari. Metode ce primesc un LiveData, expun valoarea acestuia si opereaza
pe ea . Aceste operatii se repeta la fiecare schimbare a valorii emise de live data -ul trimis ca
parametru. Intreaga componenta se poate gasi in anexa…

Fig ….

Componenta repository responsabila de autentificare si datele aferente acesteia
foloseste aceleasi principi ca cele descrise mai sus si se poate gasi in anexa …

Nivelul ViewModel

In Fig… este prezentat view model -ul fragmentului pentru numerele de urgenta. Acesta preia
datele din componenta repository apeland medota getEmergencyNumbers() return and un live
data ce contine un HasMap<String,EmergencyNumberModel>. In cazul in care acesta exista

56 si nu este gol , se mapeaza intr -o lista ce este stocata la randul ei intr -un livedata. Restul
componentelor view model functioneaza pe acelasi principiu si p ot fi gasi in anexa …

Fig…

Tot in acest nivel se incadreaza si clasele ce administreaza listele afisate utilizand
libraria Epoxy. O librarie ce ajuta la definirea declarativ a a elementel or dintr -o lista de tipul
RecyclerView. Acest controler primeste lista de elemente iar in momentul in care este setat a,
se apeleaza automat metoda buildModels() (FIG….) . In interiorul acesteia se parcurge lista si
se decide ce tip de layout se afiseaza, pastrandu -se ordinea . In cazul de fata avem un singur
tip de layout.
Aceasta librarie genereaza automat modele de date mapate pentru layout -ul specificat
Fig… In acest caz se vor genera modele pentru fisierele de layout al caror nume incepe cu
prefixul „i tem”. Modelele sunt generate tinand cont de variabilele definite in layout. De
exemplu Fig…. avem modelul generat – contactNumber aferent layout -ului pentru persoanele
de conatct. In acest layout avem definite variabila contact,editClickListener si
remov eClickListener. Variabile le sunt setate la randul lor in layout utilizand proprietatile
widgeturilor respective .

Fig…

Nivelul Activitatilor/Fragmentelor
Acest nivel va fi descris in detaliu deoarece reprezinta interfata dintre utilizatorul final
si sistemul descris in aceasta lucrare.

Fragmentul Home

Primul fragment incarcat contrat asteptarilor nu este cel de autentificare ci cel
principal, cel in care uti lizatorul isi poate vedea datele. La afisare acesta trece prin metodele
ce ne indica ciclul de viata.
In metoda onCreateView() se face legatura dintre layout si fisierul cu cod, iar in
metoda onViewCreated() sunt puse actiunile dorite de catre dezvoltator. In cazul de fata se
preia instanta view model -ului aferent acestui fragment, se cer permisiunile in cazul in care
utilizatorul este logat, se porneste seviciul ce asculta apelul de urgenta si se apeleaza
urmatoarele metode :

57  setThemeStyle() – aceasta seteaza culoarea bari de status (bara de deasupra ce contine
nivelul bateriei, notificarile, puterea semnalului GSM receptionat, etc.) si bari de navigare de
jos (in cazul in care exista)
 setupConditionalNavigation() – aceasta este metoda ce inreg istreaza ascultarea
componentelor live data ce contin informatii despre starea autentificari utilizatorului si
despre existenta informatiilor adiacente. Atunci cand utilizatorul nu este autentificat, se va
naviga catre ecranul de autentificare. Se doreste ca atunci cand utilizatorul intra pentru
prima data in aplicatie sa I se indice si sa parcurga ecranele in care trebuie sa adauge
numarul de urgenta declansator si persoanele de contact.
 setupListeners() – aceasta este metoda ce inregistreaza interactiunea utilizatorilor cu
butoanele, prezente in interfata grafica. Metoda atasata de butoane setOnClickListener()
primeste ca parametru o functie lambda ce se va executa la fiecare interactiune a
utilizatorului cu elemental respective.
 setupObservers() –aceasta este metoda ce inregistreaza ascultarea datelor incapsulate in
componente live data. Componente ce sunt tinute in view model si expuse printr -un geter
catre fragment. Odata obtiune pentru a inregistra observarea datelor din acestea se
foloseste metoda obse rve() ce primeste ca parametrii ciclul de viata al fragmentului si un
Observer ce la randul lui primeste o functie lambda ce ne expune valoarea efectiva a
variabilei. De fiecare data cand valoarea din live data se schimba si fragmentul este pe ecran
se va apela aceasta functie . In cazul de fata datele sunt setate in widgeturile din layout.

Metodele descrise mai sus sunt doar un mod standard de organizare a apelurilor
celorlalte componente. Nu sunt obligatori. Aceasta metodologie se va gasi in tot proiectu l
android Helpifi. Codul descris mai sus se poate gasi in anexa …

Interfat a grafica a fragmentului home

Interfata acestui fragment ( Fig…) este formata dintr -un antet cu o poza si un card
material in care sunt asezate widgeturi cu informatiile uti lizatorului. Pe langa acestea mai
exista inca trei butoane ce pot fi folosite pentru navigarea catre celelalte fragmente. Codul
XML poate fi gasit in anexa

Fig…

Fragmentul LogIn

Acest fragment se ocupa de procesul de autentificare al utilizatoru lui. El apare dupa
fragmentul Home atunci cand utilizatorul nu este logat, adica valoarea statusului de
autentificare este „LOGGED_OUT”. Aceasta valoare este o transformare a valori obtinute din
FirebaseAuthLiveData ce returneaza obiectul cu datele utiliza torului in cazul in care este logat
si null in cazul in care nu este. Deoarece avem doar 2 valori posibile, nu putem face diferenta
intre valoarea null a inexistentei utilizatorului sau valoarea null cand nu a fost efectuata inca
citirea. Pentru a trece pe ste acest impediment s -a creat un nou live data Fig…. ce reprezinta o

58 o transformare cu valoarea initiala „UNKNOWN”. Un MediatorLiveData este o clasa ce
extinde clasa de baza LiveData si ofera posibilitat ile de a seta valoarea acestuia din exteriorul
clasei si de a adauga ca sursa o alta variabila live data. Adaugarea unei surse ce are o functie
lamda face ca atunci cand se modifica valoarea din interioriul sursei sa se apeleze functia
lambda in care putem face prelucrari ale valori si le setam mai departe in MediatorLiveData.
Avantajul acestei componente este ca putem seta mai multe surse si astfel combinam mai
multe valori intr -una singura. In Fig … se poate observa cum setam valoarea implicita, dupa
care adaugam sursa si in functie de existenta valori setam statusul potrivit. De mentionat,
acest Status este prelucrat in View Model si este ascultat in fragmentul LogIn.

Fig….

La fel ca in fragmentul Home si acesta trece prin metodele ce indica ciclul de viata. In metoda
onViewCr eated() se urmeaza standardul descris si in fragmentul precedent : metodele
standard implementate pe langa cele specifice acestui fragment sunt: setupListeners(),
setupObservers() si setupConditionalNavigation().
 setupListeners() – in cazul de fata este vorba doar de interactiunea utilizatorului cu
butonul de autentificare. In momentul in care este apasat, se face o verificare a
campului in care trebuie introdus numarul de telefon . Se afiseaza o eroare, indicand
problema sau in caz contrar procesul contin ua apeland metoda register() din
ViewModel. Metoda ce prelucreaza datele si le inainteaza catre repository. In acesta se
produce comunicarea cu modulul de autentificare Firebase, mai specific pe
componenta PhoneAuthProvier se apeleaza metoda verifyPhoneNu mber() ce primeste
ca parametrii numarul de telefon, timpul maxim de raspuns al serverului, firul de
executie pe care se produce si un obiect in care sunt incapsulate comportamentele
dorite in functie de raspunsul serverului. Aceste raspunsuri difera deoar ece in acest tip
de autentificare cu numarul de telefon , exista trei raspunsuri posibile . Autentificarea
esueaza, este reusita si ne sunt returnate credentialele necesare pentru a autentifica
utilizatorul sau este necesara o verificare a autenticitatii, moment in care se trimite
prin SMS un cod ce trebuie introdus de utilizator. Acest caz are efecte asupra
fragmentului LogIn deoarece trebuie oferita posibilitatea utilizatorului sa introduca
codul primit. Pentru a face acest lucru se foloseste metoda syncViews() detaliata mai
jos.
 syncViews( needsVerification:Bol ean).- metoda ce sincronizeaza el ementele din layout
in functie de date. In cazul de fata este vorba de functionalitatile campului in care
utilizatorul poate introduce date si de butonul de verificare
 setupObservers() – metoda ce inregistreaza observarea datelor din view model, date ce
influenteaza afisarea elementelor pe ecran si functionalitatea lor (vezi de exemplu
metoda syncViews()) si cel mai important observarea statusului de autentificare ce
opreste acest fragment in momentul in care inregistrarea este cu succes.
Codul aferent desc rierilor de mai sus se gaseste in anexa …..

59

Interfat a grafica a fragmentului LogIn

Interfata este compusa dintr -un ConstraintLayout ce organizeaza in interiorul lui :
 un ImageView ce acopera intreaga latime si inaltime a ecranului cu fundalul blurat.
 un ImageView ce afiseaza logo -ul aplicatiei
 un TextInputEditText ce permite utilizatorului sa introduca numarul de telefon
 un Button de autentificare
 un TetxView ce la interactiune deschide pagina WEB cu politica de confidentialitat e
Codul XML al interfetei grafice si relatile de constrangere utilizate pentru aceste elemente se
gaseste in anexa …..

Fragmentul Profile

Acest fragment se ocupa de adaugarea sau editarea datelor despre utilizator. Exista
doua posibilitati in care acest fragment poate aparea. Atunci cand utilizatorul s -a autentificat
pentru prima data si nu are un profil setat sau atunci cand apasa pe butonul aferent din
fragmentul Ho me.
La fel ca orice fragment si acesta trece prin metodele ce indica ciclul de viata. In
metoda onViewCreated() se urmeaza standardul descris si in fragmentul Home : metodele
standard implementate pe langa cele specifice acestui fragment sunt: setupListe ners() si
setupObservers()
 setupListeners() – in aceasta metoda este atasata de butonul de salveaza metoda ce
verifica cele cinci campuri: nume,numar de telefon, email,adresa domiciliului, si
detaliile medicale. Patru dintre acestea sunt modificabile, numarul de telefon find
nemodificabil din motive de securitate ;
 setupObservers() – in aceasta metoda este initializata ascultarea datelor din View
Model -ul aferent acestui fragment. In momentul in care datele despre profil se
schimba, me toda atasata ascultari este apelata, actualizand datele;
 toggleInputAvailability( isAvailable : Bolean ) – aceasta este o metoda specifica
fragment ului descris , primeste ca parametru o variabila de tipul Boolean si in functie
de valoarea acestuia, adevarat sau fals se seteaza daca utilizatorul poate interactiona cu
campurile prezente . Metoda este apela in interiorul unui Observer ce returneaza daca
utilizatorul a initializat editarea sau nu.

Interfata grafica a fragmentului Profile

60 Interfata este compus a dintr -un ConstraintLayout ce organizeaza in interiorul lui:
 un ImageView cu o poza reprezentativa ce acopera un anumit procent din ecran
 un Card material ce la randul lui are in interior un ConstraintLayout ce organizeaza
cele cinci TextInputEditText
 un buton ce initializeaza inceputul editarii si salvarea datelor in baza de date

Codul XML al interfetei grafice si relatile de constrangere utilizate pentru aceste elemente se
gaseste in anexa …..

Fragmentul EmergencyNumbers

Acest fragment se ocupa de adaugarea si stergerea numerelor de urgenta ce
declanseaza aplicatia. Exista doua posibilitati in care acest fragment poate aparea. Atunci
cand utilizatorul s -a autentificat pentru prima data si nu are un numar de telefon setat s au
atunci cand apasa pe butonul de editare aferent din fragmentul home. La fel ca orice fragment
si acesta trece prin metodele ce indica ciclul de viata. In metoda onViewCreated() se urmeaza
standardul descris si in fragmentul Home. Metodele folosite :
 setupListeners() – in interior sunt atasate de butonul “Done” metoda ce ne intoarce in
fragmentul Home daca avem cel putin un numar de urgenta salvat si de butonul “Adauga
numar” metoda ce ne afiseaza interfata de a adauga numarul ;
 setupObservers() – in ac easta metoda se porneste ascultarea listei cu numerele de urgenta.
Atunci cand datele se schimba acestea se salveaza in memeoria cache si sunt trimise catre
lista pentru a le afisa ;
 initEmergencyList() – in aceasta metoda se ataseaza de RecyclerView contr olerul Epoxy. Fara
controler chiar daca avem date, acestea nu vor fi afisate ;
 showAddNumberDialog() – aceasta metoda afiseaza interfata de adaugare a numarului ;
 closeAddNumberDialog() – aceasta metoda inchide interfata de adaugare a numarului .

61
Interfata grafica a fragmentului EmergencyNumbers

Interfata este compusa dintr -un ConstraintLayout ce organizeaza in interiorul lui:
 un ImageView cu o poza reprezentativa ce acopera un anumit procent din ecran
 un Button stilizat printr -un Drawable pentru a adauga numerele de urgenta
 un Button stilizat printr -un Drawable pentru a termina intentia de a adauga numere
 un EpoxyRecyclerView ce afiseaza datele sub forma de lista folosindu -se de layoutul
modular, conceput special pentru acest lucru . Este compus dintr -un ConstraintLayout
ce organizeaza un TextView pentru numarul de urgenta si un ImageButton pentru a -l
folosi in cazul in care utilizatorul doreste sa stearga datele
 interfata de adaugare a numarului de urgenta este afisata dinamic, din cod. Adica nu
este in codul XML al interfetei inca de la inceput.

Codu Codul XML al interfetei grafice , al elementului utilizat in lista si al interfetei de
adaugare numar se pot ga si in anexa ….

Fragmentul EmergencyContacts

Acest fragment este asemanator cu cel pentru adaugarea numerelor de urgenta , singura
diferenta find la interfata si la tipul de date adaugat. S e ocupa de adaugarea si stergerea
numerelor persoanelor de urgenta. Numerele si nume persoanelor se pot adauga manual din
interfata dedicata sau pot fi preluate din agenda utilizatorului. Exista doua posibilitati in care
acest fragment poate aparea. Atunci cand utilizatorul s -a autentificat pentru prima data si nu
are adaugata nici un numar pentru persoanele de contact sau atunci cand apasa pe butonul de
editare aferent din fragmentul home. La fel ca orice fragment si acesta trece prin metodele ce
indica ciclul de viata. In metoda onViewCreated() se urmeaza standar dul descris si in
fragmentul Home.

Interfata grafica a fragmentului EmergencyContacts

Interfata este compusa dintr -un ConstraintLayout ce organizeaza in interiorul lui:
 un Button stilizat printr -un Drawable pentru a afisa interfata de adaugare.
 un Epox yRecyclerView ce afiseaza datele sub forma de lista folosindu -se de layoutul
conceput special pentru acest lucru. Acest layout este compus dintr -un Card material
ce organizeaza un ConstraintLayout ce contine un TextView pentru numarul de

62 urgenta, un TextVi ew pentru numele persoanei, un ImageButton pentru a -l folosi in
cazul in care utilizatorul doreste sa stearga datele si inca un ImageButton pentru
editarea datelor
 interfata de adaugare a numarului de urgenta este afisata dinamic, din cod. Adica nu
este in codul XML al interfetei inca de la inceput. Aceasta interfata de adaugare este
conceputa dintr -un Card material ce are un ConstraintLayout ce organizeaza un
TextView cu un text informativ, doua TextInputEditText, un ImageButton ce
initializeaza preluar ea datelor din agenda, un Button ce inchide aceasta interfata si
unul pentru salvarea datelor.

Codu Codul XML al interfetei grafice, al elementului utilizat in lista si al interfetei de
adaugare numar se pot gasi in anexa ….

Fragmentul PermisionDenied
Din cazul faptului ca functionarea acestei aplicatii depinde de acordarea tuturor
permisiunilor, a fost creat acest fragment ce apare in momentul in care utiliatorul refuza cel
putin una din cele cerute. Acest fragment este mai degraba unui informativ, av and o singura
functionalitate plasata pe singurul buton existent ce duce utilizatorul in ecranul de setari al
telefonului la sectiunea de permisiuni.

Interfata fragmentului PermissionDenied

Interfata este compusa dintr -un ConstraintLayout ce organizeaza in interiorul lui:
 un ImageView ce acopera intregul ecran si afiseaza imaginea de fundal
 un ImageView ce afiseaza logo -ul proiectului
 un ConstraintLayout ce are setat ca fundal o nuanta de alb transparenta si care are in
interiorul lui un TextView cu un t ext informativ si un Button ce duce utilizatorul in ecranul de
permisiuni din setarile telefonului

Serviciul Apelului (CallService)

Deoarece se doreste functionarea aplicatiei in fundal, este necesar un serviciu. Acest
are un comportament asemanator unui fragment, dar este folosit doar pentru operati, neavand
interfata grafica. In momentul in care acesta este creat, dupa inregistrarea tututor datelor
necesare, se creaza un canal de notificari , notificarea propriu -ziua ce ne indica faptul ca
aceasta f unctioneaza si componenta ce asculta apelurile initializate . Am folosit metoda
setOnGoing(true), ce face ca aceasta notificare sa fie permanenta, pentru a evita cazurile in
care utilizatorul sterge toate notificarile .

63
Receptorul apelului (CallReceiver )

Aceasta este o componenta ce extinde functionalitatile clasei BroadcastReceiver .
BoardcastReceiver este folosit pentru a primi diferite actiuni ce se intampla in cadrul
sistemului de operare. In cazul de fata se foloseste pentru a primi detalii despre apelurile
initializate si despre SMS -urile primite. Metoda in care primim actiunile se numeste
onReceive()
In Fig. …. sunt prezentate metodele ce inregistreaza ascultarea apelurilor si a SMS –
urilor si cele ce o opresc.

Fig. ….

In Fig. … este pr ezentat modul de verificare al SMS -urilor. In momentul in care
primim o notificare ca a fost receptionat un SMS, preluam numerele de urgenta din memoria
cache, verificam daca numarul care a trimis SMS -ul se afla printre cele salvate si daca
continutul text ului este cel corespunzator protocolului in caz de calamitate. Daca aceste doua
conditi sunt indeplinite activitatea ce trimite datele este pornita pasandu -i date precum
numarul serviciului ce a declansat activitatea si metoda declansatoare.

Fig. …

In Fig … este prezentat modul in care este procesat a initializarea unui apel. In
momentul in care primim notificarea ca un apel a fost initializat preluam numerele de urgenta
salvate in memoria cache, le parcurgem si verificam daca numarul apelat se afl a printre ele.
Daca conditia este indeplinita activitatea ce trimite datele este pornita, pasandu -i date precum
numarul serviciului ce a declansat activitatea si metoda declansatoare.

Fig. …

Activitatea Call

Aceasta este o activitate normala ce este deschisa de serviciul descris mai sus. In
aceasta activitate atentionam utilizatorul ca aplicatia a fost declansata si incepe preluarea
datelor. Pentru inceput sunt afisate datele trimise din serviciu, numarul de telefon si un text ce
depinde de metoda declansatoare.
In acelasi timp se preia locatia utilizand libraria AirLocation. Odata obtinuta se
construieste SMS -ul folosind componenta AdvanceMobileLocation si este trimis catre
numarul serverului gateway ( Fig. …) (Ace asta este o clasa ce preia informatiile brute si le
codifica in formatul specificat in protocolul AML). Dupa trimiterea SMS -ului catre server, se

64 citesc persoanele de contact din memoria cache si se trimite un mesaj fiecaruia cu locatia si un
text predefin it.

Fig. …

Interfata activitatii Apel

Fig. …
Interfata este compusa dintr -un ConstraintLayout ce organizeaza in interiorul lui:
 un ImageView ce acopera intregul ecran si afiseaza imaginea de fundal
 un ImageView ce afiseaza logo -ul proiectului
 un ConstraintLayout ce are setat ca fundal o nuanta de alb transparenta si care are in
interiorul lui un TextView cu numarul de urgenta, un TextView cu ce indica metoda
declansatoare si un Button ce inchide activitatea si apelul

Platforma Web Helpifi

Platforma web Helpifi este destinata operatorilor serviciilor de urgenta. Ea are rolul
de a permite vizualizarea datelor trimise prin intermediul aplicatiei Helpifi (Fig. …) . In
momentul preluari unui apel, pe harta va aparea in termen de 20 de secunde un indicator al
locatiei apelantului impreuna cu raza de precizie. Pentru a vizualiza datele complementare,
operatorul trebuie sa apese pe indicatorul de locatie deschizandu -se fereastra dorita (Fig. …) .
Din aceasta pot fi preluate date precum : numele, prenumele, numarul de telefon, poza
individului, istoric medical si alte observatii. In caz de calamitate, operatorul autorizat poate
declansa trimiterea de date de la dispozitivele ce au instalata aplicatia. Acest apel se face
utilizand butonul „Reverse Trigger” din partea dreapta.
Platforma a fost construita utilizand mediul de dezvoltare WebStorm impreuna cu
limbajele de programare: JavaScript, HTLM si CSS utilizand libraria Polymer.

<div class="card">
<google -map min -zoom="3" styles="{{styledMapType}}"
additionalMapOptions="{{additionalMapOptions}}" latitude="44.4268"

65 longitude="26.1025" api -key="AIzaSyCqTPAIFAJGJGyecPAqFs9Pd_C5zexAvKU" on –
google -map-ready="mapReady" map="{{map}}">
<template is="dom -repeat" items="{{d ata}}" as="call" >
<my-google -map-marker icon="{{icon}}" accuracy="{{call.location.radius}}"
circle -fill-opacity="0.1" circle -stroke -opacity="0.3" circle -stroke -color="#ff0000" circle -fill-
color="#ff0000" title="{{call.caller.phone}}" latitude=" {{call.location.lat}}"
longitude="{{call.location.long}}" draggable="false">
<div class="card">
<h3>{{call.caller.phone}}</h3>
<h4><b>Nume:</b> {{call.caller.name}}</h4>
<h4><b>Adresa:</b>{{call.cal ler.adr}}</h4>
<h4><b>Observatii:</b>{{call.caller.obs}}</h4>
</div>
</my -google -map-marker>
</template>

</google -map>
</div>

Acesta reprezinta template -ul componentei web dezvoltata pentru a afisa harta cu
locatiile apelurilor de urgenta. In prima partea, aplicatia web se conecteaza la firebase
folosind comp onenta firebase -app dupa care, interogheaza ruta apelurilor de urgenta "/alerts"
din baza de date folosind componenta firebase -query. Ace asta componenta va pune rezultatul
interogarii (un vector) in variabila data. In urmataorea parte a t emplate -ului se afiseaza harta
folosind componenta google -map cu setarile necesare si se parcurge vectorul "data" folosind
echivalentul unui for in template (dom -repeat) pentur a afisa toate markerele si cardurile cu
informatii (ce devin vizibile la click pe indicator )

In portiunea de script a componentei (Fig. ….) se initializeaza o componenta Polymer
standard in care se definesc proprietatile necesare, precum st ilizarea hartii si icoana f olosita de
indicator.

66

Fig. ….

Codul complet poate fi gasit in anexa….

Interfata grafica a platformei Helpifi

Fig …

Fig ….

67

Capitolul 5 Concluzi si contributii

Datorita evolutiei tehnologie , raspandiri telefoanelor mobile „ inteligente ” si a
necesitatea unei noi metode de localizare in caz de urgenta, Uniunea Europeana a promulgat o
directiva ce face obligatorie implementarea in statele membre a unui astfel de sistem pana in
anul 2020. Salvarea vietilor se poate face intr -un mod mai eficient , folosind metodele
existente, senzori din telefonul apelantului si un canal de comunicare complementar . Toate
acestea au fost implementat e in proiectul Helpifi. Inovatia acestui proiect o reprezinta canalul
de comunicare inversa dinspre serviciul de urgeta catre utilizatorul final, in caz de calamitate,
atacuri, etc.
Aplicatia poate fi folosita in orice momen t, dar aduce un plus in momentul in care
persoana in cauza nu cunoaste locul in care se afla, de exemplu este in vacanta intr-un loc
necunoscut.
Sistemul este gandit ca un sistem open -source, adica este deschis pentru integrarea cu
terti, poate functiona foarte bine impreuna cu aplicatii de fitness, calatorii si cu dispozitive
„inteligente ” precum ceasuri, bratari, benzi, etc.

Pasi urmatori in dezvoltarea acestui sistem pot fi :
 crearea si implementarea unei experiente mai bune in aplicatie, o imbunatat ire a interfetei
grafice astfel incat orice utilizator va intelege si va reusi sa indeplineasca scopul pentru care a
fost dezvoltata aplicatia ;
 un parteneriat cu un serviciu de gateway SMS ;
 dezvoltarea unui API pe care terti il pot folosi pentru a integr a functionalitea sistemului
direct in aplicatia sau dispozitivul lor.
Pe parcursul acestui proiect am dobandit cunostiinte despre metodologia serviciilor de
urgenta, eforturile lor zilnice si importanta stabilitati unui sistem informatic . Mi-am
consolidat cunostintele despre functionarea sistemului Android si despre concepte le utilizate
in dezvoltarea produselor software . Am folosit cunostinte dobinde pe parcursul facultatii si
din cei trei ani de munca pe postul de dezvoltator de aplicatii andro id.

Contribuțiile personale se regăsesc în
 Analiza dezvoltării sistem ului software;
 Alegerea tehnologiilor folosite;
 Proiectarea și realizarea bazei de date Firebase si Firestore ;
 Dezvoltarea aplicatiei Androi d;

68  Implementarea protocolului AML in sistemu l Helpifi;
 Testarea aplicați ei;

Bibliografie

I. Surse internet

[1]. https://www.digitalocean.com/community/tutorials/an -introduction -to-oauth -2
[2]. https://eena.org/wp -content/uploads/2018/11/Advanced -Mobile -Location -AML –
Specifications –
requirements.pdf?fbclid=IwAR3NEBzwWYYq5wmrjoBi5g_S1HG4LzU0vkbGMDnCRh2w
K3xIC6hZ -_Lsijs
[3]. https://developer.android.com/guide/platform
[4]. https://firebase.googleblog .com/2017/10/cloud -firestore -for-rtdb-developers.html
[5]. https://developer.android.com/guide/components/fragments.html
[6]. https://en.wikipedia.org/wiki/Java_(programming_language)
[7]. https://developer.android.com/kotlin/overview
[8]. https://en.wikipedia.org/wiki/HTML
[9]. https://developers.google.com/maps/documentation/android -sdk/intro
[10]. https://hackernoon.com/introduction -to-firebase -218a23186cd 7
[11]. https://en.wikipedia.org/wiki/Android_(operating_system)
[12]. https://developer.android.com/guide/components/activities/activity -lifecycle
[13]. https://developer.android.com/guide/topics/ui/declaring -layout
II. Lucrare de specialitate.
[14]. Auto r Prof. univ. dr. Mariana Marinescu , Sisteme informationale si informatice , suport
de curs, UTCB.

69

http://staff.cs.upt.ro/~dan/curs/fis/Cap3_Cerinte.pdf
Capitolul 9. Anexa

Tabelul 2.1 Specificatiile proprietatilor interfetei protocolului AML

Proprietate Numele
Proprietatii
codificat Marimea Proprietatii in
caractere
Descrierea Proprietatii

70 Nume Valoare
Maxima Numar
total de
caractere
(include
operatorul
„=”)
Antent A”ML 4

3 8 Acest antet trebuie sa apara
obligatoriu la inceputul
fiecarui mesaj AML, trebuie
sa aibe litere mari si
caracterul ” pe pozitia 2.
Valoarea acestei proprietati
arata versiunea protocolului
folosita
Latitudine lt 2 10 13 Coordonatele in sistemul
WGS84 cu o precizie de 5
zecimale, echivalentul a 1,1
metri in realitate. Formatul
acestor date este :
<semn><valoare>

<semn> Semnul poate fi +/ –
in functie de emisfera

<valoare> Este o valoare
numerica ce variaza de la -90
la +90 pentru latitudine si de
la -180 la +180 pen tru
longitudine urmat de cifrele
zecimale separate prin „.”

Daca nu s -au putut obtine
date aceste proprietati trebuie
in continuare trimise sub
forma + 00.00000 pentru
latitudine si +000.0000 pentru
longitudine
Longitudine lg 2 10 13

Raza de
precizie rd 2 5 8 Reprezinta raza de precizie a
unui cerc in care se poate afla
utilizatorul, este strans legata
de locatie, astfel daca locatia
nu a putut fi obtinuna aceasta
va avea valoarea „N”

71 Timpul de
pozitionare top 3 14 18
Nivelul de
Incredere
(LoC) lc 2 2 5
Metoda de
pozitionare pm 2 1 4
Identitatea
abonatului
mobil si 2 15 18
Identitatea
echipamentului
mobil ei 2 16 19
Codul tarii mcc 3 3 7
Codul retelei mnc 3 2 6
Lungimea
mesajului ml 2 3 6

Dictionar termeni Protocol AML

Meaning
AML Advanced Mobile Location
CLI Calling Line Identifier
DCS Data Coding Scheme
GNSS Global Navigation Satellite System
A-GNSS Assisted Global Navigation Satellite System
GSM Global System for Mobile Communications
IMSI International Mobile Subscriber Identity
IMEI International Mobile Equipment Identity
LOC Level of Confidence
MNOs Mobile Network Operators (referred to as Carriers in some jurisdictions)
MCC Mobile Country Code
MNC Mobile Network Code
OS Operating System
PSAP Public Safety Answering Point

SMS Short Message Service
SMSC Short Message Service Center
TOP Time of Positioning
UTC Universal Coordinated Time (known as Greenwich Mean Time also)

72

Caracteristici AML

Item Requirement
SMS transport format PSAPs/Public Authority should be able to receive and decode both
“regular SMSs” and “Data SMSs” as defined in Section 3.4 of this
document
AML message content The content attributes described in section 3 of this document should
be used
Recipient of the SMS has to make sure that the attributes can be read
regardless of the order
SMS invisibility Sending of the SMS should be invisible to the user on the handset and
should not be stored on the handset
Shortcode AML message should be sent to a unique shortcode per country e.g.
112, 999, 101… etc. (but can be triggered by dialling any national
shortcode emergency numbers)
International Roaming Until a recommended solution is agreed, the AML functionality should
not be activate d when roaming.
Consistency of AML
location and network
Cell-ID location Up to the public authority to provide guidance to PSAP call takers about
how to manage cases where the location provided with the AML message
and the location provided by Cell ID differ appreciably
Frequency of AML SMSs As a minimum and in order to receive the best possible location that is
available at that time, one SMS should be sent no later than 20 seconds
after the emergency call is initiated as described in section 2.6
Battery life Up to the handset manufacturers/OS provider to decide when the AML
functionality should not be triggered because of the battery level to allow
for a short (5 minute) voice call to be placed
User consent Not needed when making an emergency call.