Specializarea: Informatică [610778]

UNIVERSITATEA „LUCIAN BLAGA” DIN SIBIU
FACULTATEA DE ȘTIINȚE

Specializarea: Informatică

LUCRARE DE LICENȚĂ

Coordonator științific
Lector univ. dr. Ralf FABIAN Absolvent: [anonimizat]
2017

UNIVERSITATEA „LUCIAN BLAGA” DIN SIB IU
FACULTATEA DE ȘTIINȚE

Specializarea: Informatică

Sisteme mobile de notificare și
monitorizare a datelor pentru
facilitarea supervizării programelor de
medicamentație ș i nutriție

Coordonator științific
Lector univ. dr. Ralf FABIAN Absolvent: [anonimizat]
2017

Cuprins

INTRODUCERE ………………………….. ………………………….. ………………………….. ……………………. 1
CONTEXTUL LUC RĂRII ………………………….. ………………………….. ………………………….. …………… 1
MOTIVAȚIE ………………………….. ………………………….. ………………………….. …………………………. 1
OBIECTIVE ………………………….. ………………………….. ………………………….. …………………………. 2
DESCRIEREA TITLULUI ………………………….. ………………………….. ………………………….. ………….. 3
STRUCTURA LUCRĂRII ………………………….. ………………………….. ………………………….. ………….. 3
CAPITOLUL 1. UTILITA TEA SISTEMELOR MOBIL E ÎN SUPERVIZAREA
MEDICAMENTAȚIEI ȘI N UTRIȚIEI ………………………….. ………………………….. ……………………… 4
1.1 PROBLEME GENERALE ÎN CADRUL NUTRIȚI EI ………………………….. ………………………….. ……… 4
1.1.1 Program și limite ale nutriției ………………………….. ………………………….. ………………………….. …….. 4
1.1.2 Alimente procesate ………………………….. ………………………….. ………………………….. …………………. 4
1.1.3 Alimente de tip fast -food ………………………….. ………………………….. ………………………….. ………….. 5
1.1.4 Obezitatea ………………………….. ………………………….. ………………………….. ………………………….. ….5
1.1.5 Probleme digestive și cardiovasculare ………………………….. ………………………….. …………………… 6
1.1.6 Zaharuri și grăsimi ………………………….. ………………………….. ………………………….. ………………….. 6
1.1.7 Sodiul ………………………….. ………………………….. ………………………….. ………………………….. ……….. 6
1.1.8 Probleme respiratorii ………………………….. ………………………….. ………………………….. ……………….. 7
1.1.9 Probleme ale sistem ului nervos central ………………………….. ………………………….. ………………….. 7
1.1.10 Probleme ale sistemului osos și ale pielii ………………………….. ………………………….. ……………… 7
1.2 PROBLEME GENERALE ÎN CADRUL MEDICAMENTAȚI EI………………………….. ……………………….. 8
1.2.1 Efecte secundare ………………………….. ………………………….. ………………………….. ……………………. 8
1.2.2 Alergii ………………………….. ………………………….. ………………………….. ………………………….. ……….. 8
1.2.3 Interacțiuni între medicamente ………………………….. ………………………….. ………………………….. ….9
1.2.4 Interacțiuni cu alimente ………………………….. ………………………….. ………………………….. ……………. 9
1.2.5 Supradozarea ………………………….. ………………………….. ………………………….. ……………………… 10
1.3 ASEMĂNĂRILE ȘI CARACT ERUL INTER DISCIPLINAR ALE CELO R DOUA PROBLEMATICI ………….. 11
1.3.1 Caracterul interdisciplinar al lucrării prezente ………………………….. ………………………….. ……….. 11
1.3.2 Asemănările problematicilor prezentate ………………………….. ………………………….. ………………. 11
1.4 SOLUȚIA PROPUSĂ ÎN CA DRUL PROBLEMELOR PRE ZENTATE ………………………….. …………….. 12
1.4.1 Utilitatea și necesitatea sistemelor mobile ………………………….. ………………………….. ……………. 12
1.4.2 Arhitectura și caracteristicile platformei propuse ………………………….. ………………………….. …… 13
CAPITOLUL 2. TEHNOLO GII UTILIZATE ………………………….. ………………………….. …………… 15
2.1 LIMBAJUL DE PROGRAMAR E JAVA ………………………….. ………………………….. …………………. 15
2.1.1 Prezentare gene rală ………………………….. ………………………….. ………………………….. …………….. 15
2.1.2 Performanță ………………………….. ………………………….. ………………………….. ………………………… 15

2.1.3 Sintaxă ………………………….. ………………………….. ………………………….. ………………………….. …… 16
2.1.4 Servlet ………………………….. ………………………….. ………………………….. ………………………….. ……. 17
2.2 SISTEMUL DE OPERARE ANDROID ………………………….. ………………………….. …………………. 19
2.2.1 Prezentare generală ………………………….. ………………………….. ………………………….. …………….. 19
2.2.2 Arhitectura sistemului Android ………………………….. ………………………….. ………………………….. .. 20
2.2.3 Versiuni Android ………………………….. ………………………….. ………………………….. ………………….. 22
2.2.4 Cotă de piață ………………………….. ………………………….. ………………………….. ……………………….. 26
2.3 DEZVOLTARE DE APLICAȚ II ANDROID ………………………….. ………………………….. ……………… 27
2.3.1 Android Studio ………………………….. ………………………….. ………………………….. …………………….. 27
2.3.2 Android SDK ………………………….. ………………………….. ………………………….. ……………………….. 28
2.3.3 Android NDK ………………………….. ………………………….. ………………………….. ……………………….. 29
2.3.4 Gradle ………………………….. ………………………….. ………………………….. ………………………….. ……. 29
2.3.5 Limbajul XML ………………………….. ………………………….. ………………………….. ………………………. 30
2.4 REPRESENTATIONAL STAT E TRANSFER (REST) ………………………….. ………………………….. . 32
2.4.1 Prezentare generală ………………………….. ………………………….. ………………………….. …………….. 32
2.4.2 Proprietăți arhitectu rale ………………………….. ………………………….. ………………………….. …………. 32
2.4.3 Modelul client -server ………………………….. ………………………….. ………………………….. …………….. 33
2.4.4 Formatul JSON ………………………….. ………………………….. ………………………….. ……………………. 35
2.5 BAZE DE DATE MYSQL ………………………….. ………………………….. ………………………….. ….. 38
2.5.1 Prezentare generală ………………………….. ………………………….. ………………………….. …………….. 38
2.5.2 Limitări ………………………….. ………………………….. ………………………….. ………………………….. …… 39
2.5.3 Implementare ………………………….. ………………………….. ………………………….. ………………………. 39
2.5.4 MariaDB ………………………….. ………………………….. ………………………….. ………………………….. …. 40
2.5.5 PhpMyAdmin ………………………….. ………………………….. ………………………….. ……………………….. 41
CAPITOLUL 3. PREZENTA REA SOLUȚIEI ………………………….. ………………………….. ………… 42
3.1 DESCRIEREA ARHITECTUR II ȘI MODULELE FUNCȚ IONALE ALE SOLUȚIEI ………………………….. . 42
3.1 BAZA DE DATE ………………………….. ………………………….. ………………………….. ……………… 44
3.2 SERVE RUL WEB ………………………….. ………………………….. ………………………….. ……………. 52
3.3 APLICAȚIA ANDROID DEDICATĂ UTIL IZATORILOR ………………………….. ………………………….. .. 60
3.3 APLICAȚIA ANDROID DEDICATĂ MEDI CILOR ………………………….. ………………………….. ……… 82
CONCLUZII ………………………….. ………………………….. ………………………….. ………………………… 95
BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. …………………… 97

1
Introducere

Contextul lucrării

Dat fiind stilul de viată tot mai stresant ș i plin de activități cotidiene , în secolul tehnologiei
și al lucrurilor to t mai comp licate este din ce mai frecventă neglijarea condiției fizice ș i psihice.
Simptome tot mai severe sau chiar grave sunt din ce în ce mai mult ignorate, fie din cauza lipsei
de interes , sau a activităților complexe de zi cu zi care nu lasă suficient timp pentru îngrijora re.
Acest fapt este o problemă tot mai frecventă și are acțiuni nefaste asupra săn ătății, orice simptom
ignorat este o “bombă cu ceas ” care așteaptă să “explodeze” sub for ma unor complicații majore
sau chiar a unor boli grave.
Acest lucru poate fi evitat foarte ușor prin simpla vizită a unui medic , dar cum trăim in
secolul “viteze i” și timpul liber este din ce î n ce mai rar, chiar și această simplă vizită este lăsată
în așteptare sau ignorată complet.
Din aceste necesități firești s -a născut ș i dorința mea de a crea o modalitate de a facilita cât
mai rapid , în orice împrejurare posibilitatea de a stoca datele într -un loc sigur și de a le pune la
dispoziția medic ilor specialiști , iar soluția găsită poartă numele de “ICare”.

Motivație

Principalul aspect care a stat la baza motivației mele în cadrul proiectului I Care este
reprezentat de dorința de a îmbunătății calitatea vieții um ane, în special dator ită stilului dezordonat
de viață , organismul suferă modificări care perturbă buna s a funcționare, astfel apare fenomenul
de dezechilibru al organismului sau chiar îmbolnăvirea acestuia. Pentru a păstra o bună funcționare
a organismului este necesară intervenția medicilor specialiști , care prin expertiza lor, reușesc să
readucă starea de echilibru a organismului, dar pentru a permite medicilor să ofere ajutorul, aceștia
au ne voie de date concrete pe care să își bazeze diagnosticele precum ș i rețetele.
Astfel apare nevoia de o “instanță” mijlocitoare capabilă să stocheze și să pună la disp oziție
toate informațiile necesare pentru stabilirea cu exactitate a unui diagnostic de către medicii
specialiști , în mod normal această “instanță” sunt persoanele însăși atunci când vizitează medic ul
și își prezintă simptomele î n scopul obținerii unui d iagnostic, p recum ș i mijloacele prin care se pot
însănătoși. Dar nu întotdeauna ceea ce se transmite medicului este corect sau concret , astfel ș i
diagnosticul medicului poate să sufere erori considerabile. Din acest motiv se naște și dorința de a
înlătura imprecizia și incorectit udinea informațiilor prelevate către medicii specialiști .

2
O altă motivație este reprezentată de utilizarea sistemelor mobile deoarece “instanța”
necesară pentru managementul informațiilor utile în cadrul selecției unui diagn ostic favorabil de
către medici trebuie să ofere posibilitatea stocării cu ușurință a datelor , dar și vizualiz area acestora
într-o manieră câ t mai organizată . În acest context sistemele mobile sunt fezabile pentru atingere a
scopului propus, d eoarece sunt foar te versatile, relativ ieftine, disponibile oricui sub diferite forme
în funcție de buget sau de necesități și mai ales sunt la îndemâna unui număr impresionant de
utilizatori, în general su b forma unui smartphone sau a unei tablete.
Una dintre motivațiile personale este reprezentată de faptul că eu însumi întâmpin
dificultăți î n legătură cu prezentarea problemelor de sănătate în special datorită faptului că nu
reușesc să rețin tot ceea ce întâmpin, precum ș i faptul că apelez destul de rar la un medic și în
general în ultimă instanța atunci când starea mea devine destul de precară. Aici se adaugă și dorința
mea de a aprofunda cât mai multe cunoștințe î n domeniul sistemelor mobile, bazelor de date,
protocoalelor de comunicație , tehnici lor de programare, arhitecturii client -server, serviciilo r web,
industriei medicale, dar și dezvoltarea mea personală ș i profesională.

Obiective

Lucrarea prezentă impune o serie de obiective clare pentru atingerea scopului propus :
• rezolvarea problemelor de comunica re și e xpunerii simptomelor medicilor specialiști ;
• eliminarea distorsiunilor datelor prezentate, pentru o câ t mai bună acuratețe ;
• creșterea stării de bine și a condițiilor de viață ;
• dezvoltarea sistemului medical pentru a avea parte de cât mai mulți beneficiari ;
• stimularea activității medicilor prin punerea în contact cu cât mai mulți pacienți ;
• întâmpinarea ș i prevenirea problemelor medicale prin consultanță specializată ;
• formarea unor automatisme corespunzătoare pentru o stare de bine ;
• respectarea programelor de medicamentație și nutriție date de medicii specialiști ;
• utilizarea sistemelor mobile pentru inserarea și stocarea datelor prelevate de către
utilizatori, precum și punerea lor la dispoziția medicilor pentru stabilirea tratamentului ;
• posibilitatea vizualiză rii datelor cheie ale unor medicame nte, sub formă de prospect,
pentru a putea preveni utilizarea incore ctă a acestora ;
• înștiințarea cu privire la diferitele efecte secundare și a efectul ui nociv pe care îl pot avea
medicamentele în contact cu alte substanț e;
• urmarea unor diete stricte și bine s tabilite de căt re medicii în vederea însănătoșirii și a
menținerii greutății corporale normale ;
• propria dezvoltare personală și profesională ;
• posibilitatea studiului, acumulării cunoștințelor și experienței în cadrul domeniilor
precum: protocoale de comunicații, arhitectura client -server, sau sisteme mobile .

3
Descrierea titlului

Titlul lucrării , “Sisteme mobile de notificare și monitorizare a datelor pentru facilitarea
supervizării programelor de medicamentație ș i nutriție”, reprezintă modul î n care sistemele mobile
pot fi utilizate pentru a gestiona și monitoriza datel e necesare pentru a asigura o câ t mai bună
funcționare a organismului uman. În acest sens concentrarea și tema tica acestei lucrări de licență
pică pe definirea și explicarea principalelor aspecte care duc la periclitarea stării de bine, dar și pe
rezolvarea acestor intemperii propunând o soluție optimă și viabilă pentru o cât mai bună gestiune
a datel or necesare stabilirii unor diag nostice și rețete, v alorificând funcționalități le, fiabilitatea,
răspândirea largă și uș urința în utilizare a sistemelor mobile.

Structura lucrării

În această lucrare de licență voi prezenta detaliat demersul realizării unui framework
medical cu scopul de a facilita monito rizarea datelor pentru supervizarea programelor de
medicamentație ș i nutriție prin intermediul sistemelor mobile.
Această lucrare de licență este structurată în trei capitole: utilitatea sistemelor mobile în
supervizarea medicamentației și nutriției, tehnologii utilizate și prezentarea soluției .
În cadrul primului capitol, utilitatea sistemelor mobile în supervizarea medicamentației și
nutriției, sunt reliefate principalele aspecte care stau la baza necesității acestei abordări, prezentând
principalele probleme care perturbă echilibrul organismului și implicit sănătatea Tot în acest
capitol este reliefat și dualitatea conceptelor , în special asemănările și dependințele celor doua
problematici legate de programele respective , precum și soluția viabilă bazat ă pe utilitatea,
fiabilitatea, funcționalitatea și răspândirea sistemelor mobile.
În al doilea capitol sunt prezentate principalele tehnologii utilizate în realizarea soluției
pentru rezolvarea problemelor date. Aici sunt incluse limbaje le de programare utilizate,
framework -uri, medii de dezvoltare integrate, componente software, baze de date, servicii web,
precum ș i alte tehnologii care stau la baza realizării soluției propuse.
Ultimul capitol prezintă soluția implementată pentru rezolvare a problematic ilor enunțate
în primul capitol . În acest capitol se remarcă arhitectura soluției, modul de implementare, logica
și funcționalitatea din spatele codului. Soluția dezvoltată este împărțită în patru componente
principale: baza de date care conține informații le prelevate de către utilizatori și de către medici,
serverul web, implementat cu ajutorul servlet -urilor în cadrul unei aplicații web bazată pe limbajul
Java respectând arhitectura REST , care stă la baza comunicării aplicațiilor cu interfață grafică cu
baza de date, o aplicație Android dedicată utilizatorilor pentru a le permite introd ucerea și
gestionarea datelor , precum și o aplicație Android dedicată medicilor care le pune la dispoziție
vizualizarea datelor p relevate de către utilizatori în vederea sta bilirii tratamentelor necesare.

4
Capitol ul 1. Utilitatea sistemelor mobile î n supervizarea
medicamentației ș i nutriției

1.1 Probleme generale în cadrul nutriție i

1.1.1 Program și limite ale nutriției

În cadrul unei bune dezvoltări ale corpului omenesc , precum și pentru menținerea unei stări
cât mai bune de funcționare , nutriția ocupă un loc fruntaș. Pentru a putea supraviețui aproape orice
organism are nevoie de hrană în mod regulat, aceasta fiind combustibil pentru acel organism. Omul
are nevoie în gene ral de un program regulat al procesului de hrănire, acesta fiind reprezentat de 3
mese principale pe zi, la inte rvale de 4 -5 ore, la care se mai pot adăuga gustări în cazul în care este
necesar.
În principiu omul poate supraviețui mai mult de 3 săptămâni fără mâncare , Mahatma
Grandhi a supraviețuit 21 de zile fără nici o sursă de hrană, dar nu și fără apă. Cel puțin 60% din
corpul unui adult este făcut din apă, iar fiecare celulă din corp are nevoie de apă pentru a putea
funcționa. Apa funcționează ca un lubrifiant pentru articulații, în plus reglează temperatura
corpului prin transpirație și respirație și ajută la spălarea deșeurilor din organism. O persoană poate
supraviețui cel mult o săptămână fără apă în anumite circumstanțe, dar în general poate rezi sta în
jur de 3 -4 zile sau 100 de ore. [1]

1.1.2 Alimente procesate

Alimentele consumate au un impact foarte important asupra organismului, în special
alimentele procesate sau conservate care pot conține diferite substanțe n esănătoase sau chiar
toxice. În prezent majoritatea alimentelor de pe piață sunt procesate, prea puține însă sunt
disponibile în stare naturală de către producători ecologici, datorită faptului că alimentele
procesate sunt mult mai ușor de produs și mult m ai ieftin e în comparație cu cele ecologice, de aici
și diferențele relativ mari de prețuri în defavoarea alimentelor ecologice. Astfel tot mai multe
alimente nesănătoase ajung pe piață, care datorită prețului scăzut și gustului artificial și alterat au
o foarte mare cerere și cotă de piață, însă efectele negative sunt resimțite de către consumator. Un
astfel de exemplu de alimente nocive, dar care se bucură de o mare popularitate prin vânzări
susținute sunt cele prelevate de industria fast -food.

5
1.1.3 Alimente de tip fast -food

Alimentele de tip fast -food nu sunt neapărat nepotrivite pentru organism, dar în majoritatea
cazurilor sunt foarte procesate și conțin cantități mari de carbohidrați, zaharuri, grăsimi și sodiu. [2]
Deși aces te alimente au în general multe calorii, valoarea lor nutrițională este foarte mică.
În cazul persoanelor cu o dietă boga tă în alimente de tip fast -food, pot să apară probleme de
nutriție , de sănătate și de obezitate. Testele pe animalele de laborator au arătat probleme grave și
în cazul dietelor de durată scurtă bazate pe alimente de tip fast -food, chiar și acestea pot avea efecte
negative asupra sănătății. [2]
În cadrul persoanelor care suferă de obezitate riscurile sunt mult mai prezente cu o varietate
mult mai largă de probleme de sănătate cronice, incluzând boli de inimă, diabet și infarcturi. [2]
Potrivit fundației “Robert Wood Johnson”, majoritatea oamenilor subestimează numărul de calorii
pe care le consumă într -un restaurant fast -food. Un studiu publicat în 2013 în “JAMA Pediatrics ”
a arătat că copiii și adolescenții iau mai multe calorii în restaurantele de fast -food și alte restaurante
decât la domiciliu. Mâncarea la un restaurant a adăugat între 1 60 și 310 de calorii pe zi , fapt
îngrijorător care poate duce cu siguranță la probleme de sănătate și obezitate . [2]

1.1.4 Obezitatea

Potrivit “Centers for Disease Control and Prevention” (CDC) definiția obezității este
reprezent ată de diferențele indicelui de masă al corpului (BMI). [2]
BMI ( “body mass index” sau indicele de masă al corpului) este greutatea unei persoane în
kilograme (kg) împărțită la înălțimea sa în metri pătrați. Instit utul Național de Sănătate (NIH)
definește acum greutatea normală, excesul de greutate și obezitatea, conform BMI, mai bine decât
prin diagramele înălțime / greutate tradiționale. O persoană supraponderală are un BMI de 27,3
sau mai mult pentru femei și de 27,8 sau mai mult pentru bărbați. Obezitatea este un BMI de 30
sau mai mult pentru fiecare sex (aproximativ 30 de kilograme peste limită). O persoană foarte
musculoasă poate avea un BMI ridicat fără riscuri pentru sănătate. [3]
Există, de asemenea, o categorie numită “obezitate extremă”, care este definită de un indice
de masă BMI mai mare de 40. [2]
Coaliția de Acț iune pentru Obezitate (OAC) raport ează că numă rul de mag azine de fast –
food sa dublat față de 1970, este probabil că mulți factori să fi contribu it la epidemia de obezitate
în afară de corelația dintre disponibilitatea fast -food-ului ieftin și rata de îngrășare . Obezitatea
crește probabilitatea bolilor de inimă, tensiunii arteriale crescute, bolilor renale, diabet ului,
problemelor comune și multor altora . [2]

6
1.1.5 Probleme digestive și cardiovasculare

Multe alimente de tip fast -food și băuturi sunt încărcate cu carbohi drați și, prin urmare,
o mulțime de calorii. Sistemul digestiv sparge carbohidrații în zahăr (glucoză), pe care apoi îl
eliberează în sânge. Pancreasul răspunde prin eliberarea de insulină, care este necesară pentru a
transporta zahărul în celulele din înt regul corp. Pe măsură ce zahărul este absorbit, nivelul
glicemiei scade. Când zahărul din sânge scade, pancreasul eliberează un alt hormon numit
glucagon. Glucagonul îi spune ficatului să înceapă să utilizeze zaharurile stocate. [2]
Când totul funcționează în sincronizare, niveluri le de zahăr din sânge se mențin într-un
nivel normal. Când se introduc în cantități mari carbohidrați în organism, se provoacă o creștere a
glicemiei. Aceasta poate modifica răspunsul norm al la insulină. Frecvențele crescute ale zahărului
din sânge pot fi un factor care contribuie la rezistența la insulină și la apariția diabetul ui zaharat
de tip 2. [2]

1.1.6 Zaharuri și grăsimi

Zaharurile adăugate nu au valoare nutritivă, ci sunt bogate în calorii. Potrivit studiilor,
majoritatea persoanelor c onsumă de două ori mai mult zahă r decât se recomanda pentru o
sănătate optimă . Toate aceste calorii suplimentare sunt răspunzătoare pentru greutate a în plus,
care este un factor ce contribuie la obț inerea bolilor de inimă și a obezității. [2]
Multe dintre grăsimile procesate nu aduc valoare nutrițională spo rită și sunt considerate
foarte nesănătoase, unele sunt atât de periculoase încât au fost interzise în anumite țări.
Deseori găsite în alimentele de tip fast -food, se știe că grăsimile în exces cresc nivelurile de
colesterol LDL. Acesta este tipul nedorit de colesterol. Ele pot, de asemenea, să scadă colesterolul
HDL, care este așa -numitul colesterol bun. Grăsimile procesate pot crește riscul de apariție a
diabetului zaharat de tip 2. [2]

1.1.7 Sodiul

Sodiul în cantități ridicate duce la fenomenul numit retenție de apă, adică favorizează
reținerea apei în or ganism, dar poate duce și la alte probleme mai grave. Favorizează apariția
tensiunii arteriale și la lărgirea mușchiului inimii. În cazul în care sunt prezente în organism:
probleme cu inima, boli ale rinichilor, cancer la stomac , sodiul contribuie la creș terea periculoasă
a lichidului în zonele afectate și implicit la apariția complicațiilor. Excesul de sodiu poate să
crească riscul apariției pietrelor la rinichi, boli ale rinichilor și cancer la stomac. [2]

7
1.1.8 Probleme respira torii

Obezitatea este asociată cu creșterea problemelor respiratorii. Chiar și fără afecțiuni
medicale diagnosticate, obezitatea poate provoca episoade de respirație scurtă sau respirație
șuierătoare de la puțin efort. Obezitatea poate juca, de asemenea, un rol în dezvoltarea apneei în
cadrul somn ului, o condiție în care somnul este perturbat continuu prin respirație superficială și
astm . Un studiu recent publicat în revista “Thorax ” sugerează că persoanele tinere, în general copiii
care mănâncă alimente de tip fast-food de cel puțin trei ori pe săptămână prezintă un risc crescut
de astm și rinită, ceea ce implică un nas înfundat și secreții nazale . [2]

1.1.9 Probleme ale sistemului nervos central

Un studiu publi cat în jurnalul “Public Health Nutrition ” a arătat că consumul de produse
de panificație (gogoși, cornuri și chiar brioșe de tărâțe) și alimen te fast -food (pizza, hamburgeri )
poate duce la depresie. Studiul a stabilit că persoanele care măn âncă alimente fa st-food au cu 51%
mai multe șanse de a dezvolta depresie decât cei care mănâncă puțin sau deloc alimente fast -food.
De asemenea, în cadrul studiului a ieșit la iveală o problemă mai gravă, cu cât participanții la studiu
consumau mai multe alimente de tip f ast-food cu atât creșteau șansele să dezvolte depresie. [2]
O dietă alimentară bazată pe alimente nesănătoase, potrivit u nui studiu publicat în revista
“Nature”, poate de asemenea să afecteze sinapsele creierului ș i moleculele care stau la baza
memoriei și învățării . Testele pe animale au arătat același efect, șoarecii hrăniți constant cu o dietă
bazată pe mâncare nesănătoasă în care mai mult de jumătate dintre calorii erau provenite din
grăsimi, după doar câteva zi le au avut probleme în a rezolva labirintul pe care l -au învățat anterior ,
într-un studiu din 2009. [2]

1.1.10 Probleme ale sistemului osos și ale pielii

Ciocolata și alimentele bogate în grăsimi sunt adesea acuz ate de acnee, dar nu sunt
adevărații vinovați. Potrivit clinicii “Mayo ”, carbohidrații sunt de vină, deoarece alimentele bogate
în carbo hidrați cresc nivelurile de zahăr din sânge, ele pot declanșa ș i acneea. Studiul din “Thorax ”
a arătat un risc mai mare de eczeme (inflamații, plăci iritate ale pielii) printre copiii cu o dietă
bogată în fast -food. [2]
Când se consumă alimente bogate în carbohidrați și zahăr, bacteriile care locuiesc în gură
produc acizi. Acești ac izi pot distruge smalțul dinților, un factor care contribuie la cavit ățile
dentare. Atunci când smalț ul dintelui este pierdut, acesta nu poate fi înlocuit. Sănătatea orală slabă
a fost, de asemenea, legată de alte probleme de sănătate. Excesul de sodiu poa te crește riscul de
apariție a osteoporozei (oase subțiri, fragile). [2]

8
1.2 Probleme generale în cadrul medicamentației

1.2.1 Efecte secundare

Unele dintre principalele efecte în cadrul medicamentației foarte f recvent întâlnite sunt
efectele secundare. Un efect secundar este orice alt efect care nu corespunde celui dorit. Acestea
tind să fie în general ușoare, dar produc neplăceri. În unele cazuri reacțiile adverse pot fi grave,
pot produce degr adări ale organis mului, stări febrile, stări de vomă, complicații și pot duce chiar
la moarte. [4]
Majoritatea efectelor secundare se regăsesc pe prospectele medicamentelor, deși studiile
arată că tot mai puține persoane verifică prospectul înainte să folosească un medicament , ceea ce
poate duce la neplăceri majore și pericole nebănuite. Medicii și specialiștii susțin că este impetuos
necesară citirea cu atenție a prospectului înainte de a utiliza orice medicament pentru a putea
preveni orice e fect secundar nedorit și pentru a nu fi supus unor pericole mari.
Efectele secundare pot să apară la începutul, scăderea / creșterea dozei sau terminarea unui
regim de medicamentație . Reacțiile adverse se pot produce, de asemenea, la nerespectarea
tratamen tului prescris. Când efectele secundare ale unui medicament sau ale medicamentelor sunt
severe, doza poate fi ajustată sau poate fi prescris un al doilea medicament. Stilul de viață sau
modificările dietetice pot, de asemenea, ajuta la minimizarea efectelo r secundare. [5]

1.2.2 Alergii

Alergiile apar atunci când sistemul imunitar al organismului răspunde unei substanțe pe
care o consideră "invadator". Substanțele care provoacă sistemul imunitar într -un răspuns alergic
sunt cun oscute sub numele de alergeni. Nu există nici un fel de alergen universal. Ceea ce ar putea
declanșa un răspuns alergic care amenință viața unei persoane nu poate provoca absolut nici un
rău altei persoane. [6]
Mecanismul fizio logic al reacțiilor alergice este același, la persoanele din toată lumea.
Alergenii intră în corp prin înghițire, inhalare, contact ul cu pielea sau cu membranele mucoase.
Acest lucru face ca celulele albe să elibereze un anticorp care apoi se leagă de ceea ce este cunoscut
sub numele de celule mastocite. Se cauzează r uptura celulelor toracice și în proces eliberează
substanțe biochimice, inclusiv histamina. [6]
Simptomele alergice ușoare includ mâncărime, ochi apoși, un nas înfu ndat, gât iritat și o
erupție cutanată. Mai severe, simptomele alergiei care pun viața în pericol inc lud umflarea gâtului,
respirație șuierătoare și dificultatea respirației. [6]

9
1.2.3 Interacțiuni între medicamente

O interac țiune medicamentoasă este o situație în care o substanță (de obicei un alt
medicament) afectează activitatea unui medicament atunci când ambele sunt administrate
împreună. Această acțiune poate fi sinergică (când efectul medicamentului este crescut) sau
antagonistă (atunci când efectul medicamentului este scăzut) sau poate fi produs un nou efect care
nu este produs de medicamentele inițiale. [7]
În mod obișnuit, interacțiunile dintre medicamente sunt prezente pe prospectele
medi camentelor pentru a putea fi evitate . Cu toate acestea, pot exista și interacțiuni între
medicamente și alimente, precum și între medicamente și plante medicinale . Persoanele care iau
medicamente antidepresive, cum ar fi inhibitorii de monoaminooxidază, nu ar trebui să ia alimente
care conțin tiramină, deoarece poate apărea o criză hipertensivă. Aceste interacțiuni pot apărea d in
cauza utilizării accidentale sau din cauza lipsei de cunoștințe despre ingredientele active implicate
în substanțele relevante. [7]
Prin urmare, este ușor să vedem importanța acestor interacțiuni farmacologice în practica
medicinei. Dacă un pa cient ia două medicamente și unul dintre ele c rește efectul celuilalt , este
posibil să apară un supradozaj. Inte racțiunea dintre cele două medicamente poate, de asemenea, să
crească riscul apariției efectelor secundare. Pe de altă parte, în cazul în care acțiunea unui
medicament este redusă, acesta poate înceta să aibă o utilizare terapeutică datorită administrării
sub doză necesară . În ciuda celor de mai sus, ocazional aceste interacțiuni pot fi căutate pentru a
obține un efect terapeutic îmbunătățit. [7]
Exemple de acest lucru includ utilizarea de codeină cu paracetamol pentru a crește efectul
său analgezic. Sau c ombinația de acid clavulanic cu amoxicilină pentru a depăși rezistența
bacteriană la antibiotic. De asemenea, trebuie reamintit faptul că există interacțiuni care, din punct
de vedere teoretic, pot apărea, dar în practica clinică nu au repercusiuni importa nte. [7]

1.2.4 Interacțiuni cu alimente

O interacțiune între medicamente și alimente se întâmplă atunci când alimentele pe care o
persoană le consumă afectează ingredientele dintr -un medicament pe care l -a luat astfel încât
medicamentul să nu poată funcț iona așa cum ar trebui. [8]
Interacțiunile dintre medicamente și alimente se pot întâmpla atât cu medicamentele
eliberate pe bază de rețetă, cât și cu cele fără prescripție medicală, inclusiv antiac idele, vitaminele
și pilulele cu fier. [8]
Nu toate medicamentele sunt afectate de alimente, dar multe medicamente pot fi afectate
de alimentele consumate și de perioada în care au fost consumate . De exemplu, administrarea
unor medicamente în același timp în care se consumă anumite alimente poate interfera cu modul
în care stomacul și intestinele absorb medicamentul. Alimentele pot întârzia sau reduce absorbția

10
medicamentului. De aceea, unele medicamente trebuie luate pe stomacul gol (cu 1 oră înainte de
a mânca sau cu 2 ore după masă). Pe de altă parte, unele medic amente sunt mai ușor de tolerat
atunci când sunt consumate împreună cu alimente. [8]

1.2.5 Supradoz area

Supradozarea este un tratament medical inadecvat care apare atunci când un pacient ia
medicamente inutile sau excesive. Acest lucru se poate întâmpla deoarece medicul care prescrie
medicamentele nu este conștient de alte medicamente pe care pacientul le ia deja, din cauza
interacțiunilor medicamentoase cu alte sub stanțe chimice sau cu populația țintă, din cauza erorilor
umane, din cauza condițiilor medicale nediagnosticate sau din cauza conflictelor de intere se din
industria farmaceutică, promovarea (prin intermediul campaniilor publicitare, a vânzărilor în
practic a privată a medicilor sau a studiilor medicale părtinitoare sau modificate) care cauzează
utilizarea inutilă a unui anumit medic ament sau dozarea excesivă a unui medicament, datorită
motivelor de profit excesiv din industria farmaceutică. Acest lucru este uneori descris ca fiind
comercializarea medicamentelor. [9]
Supra dozarea poate apărea, de asemenea, atunci când consumatorii iau mai multe
medicamente decât este prescris sau etichetat pe prod usele fără prescripție medicală, fie în mod
intenționat sau neintenționat, sau atunci când consumatorii iau în necunoștință de cauză atât
medicamente pe bază de prescripție medicală, cât și medicamente fără prescripție medicală care
conțin aceleași ingrediente active. De exemplu, medicament ul cu prescripție, cum ar fi Vicodin,
care conține atât hidrocodonă, cât și acetaminofen, se poate administra împreună cu produsul
Tylenol fără prescripție medicală, care conține ca substanță activă acetaminofenul , un medicament
cu prescripție, sub formă d e supradozaj acut . Cu alte cuvinte, s upradozarea poate fi cauzată atât de
medicii care prescriu medicamentele , cât și de consumatori sau de îngrijitorii acestora. [9]
Un alt ex emplu important de supradozare apare atunci când co nsumatorii iau medicamente
prescrise de medici , împreună cu alte medicamente suplimentare care produc efecte terapeutice
similare sau identice . De exemplu, dacă un pacient ia un medicament , ibuprofen pe bază de
prescripție medicală și utilizează, de a semen ea, un produs cu naprosyn aceasta poate constitui o
suprad oză, care poate fi periculoasă și poate fi costisitoare pentru pacient în costurile generale de
îngrijire a sănătății . Deseori, consumatorii (pacienții ) se supun la supradoze prin luarea
medicamente lor la intervale mai scurte decât cele prescrise. Ca urmare, medicamentele se pot
acumula la nivele mai ridicate, provocând reacții adverse nedorite, uneori grave sau chiar fatale. [9]

11
1.3 Asemănările ș i caracterul interdisc iplinar al e celor doua problematici

1.3.1 Caracterul interdisciplinar al lucrării prezente

În cadrul aceste i lucrări de licență se remarcă, printre altele, și faptul că se regăsesc aspecte
teoretice din cadrul mai multor discipline și arii curriculare, de aici reiese și caracterul
interdisciplinar al lucrării de licență prezente.
Se remarcă integrarea cu succes a unor concepte teoretice și problematici ce țin de
domeniul medical, cu ajutorul cărora se conturează o nouă abordare în vederea rezolvării
impedimentelor pentru a putea prevenii și combate principalele riscuri și evenimente nedorite în
cadrul programelor de medicamentație.
Un alt aspect important este reprezentat de prezentarea și integrarea multiplelor noțiuni
teoretice ale probleme lor genera te în c adrul procesul de hrănire, aceste lucruri constituind obiectul
de studiu în cadrul domeniul nutriției , care își face cu ușurință simțită prezența în această lucrare
de licență.
Astfel lucrarea prezentă aduce în prin plan principalele aspecte negati ve regăsite în cadrul
programelo r de medicamentație și nutriție, prezintă și explică aceste probleme cu scopul de a
propune o so luție viabilă pentru a putea reduce sau chiar înlătura efectele nega tive ale problemelor
prezentate.

1.3.2 Asemănările problema ticilor prezentate

Există și câteva similarități în ceea ce privește problemele semnalate din cadrul
programelor de medica mentație ș i nutriție, în această ipostază se remarcă faptul că în ambele
situații , persoanele suspuse acestor programe tind să le ne glijeze sau să nu le respecte conform
indicațiilor medicilor speciali ști. În acest sens persoanele care nu își respectă programele de
medicamentație și nutriție, adeseori uită cu desăvârșire orele la care este necesar să își asimileze
medicamentele, sau la care trebuie să se hrănească, cel mai adesea din cauza lipsei de timp a rutinei
zilnice tot mai încărcate, sau a situați ilor stresante sau critice în care efectiv respectarea
programelor nu reprezintă o prioritate sau nu poate fi posibilă.
Astfel multe m edicamente sunt luate fie prea devreme, fie prea târziu, efectele lor fiind
accentuate sau diminuate, crescând riscul de interacțiune cu alte medicamente sau cu diverse
alimente, adesea fiind accentuate efecte adverse nedorite.
Acest fapt fiind valabil și în cazul procesului de hrănire, care tinde să nu fie respectat,
mesele principale ale zilei fiind luate la ore nepotrivite sau ignorate complet, fapt ce poate duce la
un dezechilibru masiv al organismului.

12
O altă asemănare este reprezentată de faptul că în cadrul ambelor programe, persoanele
vizate, tind să nu respecte cantitățile optime ale medicamentelor sau alimentelor necesare , astfel
apare o serie de efecte adverse neplăcute care pot dăuna sănătăț ii, fapt deosebit de periculos care
poate duce la com plicații, efecte adverse, interacțiuni nedorite între diferite medicamente sau între
medicamente și alimente.
Atât în cadrul programelor de medicamentație , cât și în cadrul celor de nutriție este
impetuos necesar existența unui program bine pus la punct , stabilit de medicii specialiști pentru a
asigura o cât mai bună performanță în cadrul acestora, minimalizând riscurile existente.

1.4 Soluția propusă în cadrul problemelor prezentate

1.4.1 Utilitatea și necesitatea sistemelor mobile

Soluția optimă pe ntru rezolvarea problemelor prezentate este susținută de utilitatea
sistemelor mobile. Pentru a putea preveni majoritatea problemelor care pot apărea în cadrul
programelor de medicamentație și nutriție este necesară expertiza medicilor specialiști, deoarec e
aceștia posedă cunoștințele și expertiza necesară pentru a soluționa problemele prezente.
În acest caz pentru ca informațiile legate de starea de sănătate a persoanelor în cauză să
poată fi disponibile, în timp real, medicilor specialiști este impetuo s necesar un sistem de gestiune
al informații lor capabi l să pună la dispoziție informațiile medicilor specialiști, dar care să confere
și posibilitatea introducerii datel or de că tre utilizatori.
Pentru realizarea unei platforme cât mai versatile, c u posi bilități cât mai mari de răspândire,
cu un suport pe măsură, cu o disponibilitate foarte mare și cu o ușurință cât mai mare de utilizare,
este nevoie de sisteme performante capabile să poată rula și susține platforma necesară, din acest
punct de vedere se remarcă utilitatea sistemele mobile.
Sistemele mobile se diferențiază în special prin faptul că dețin o cotă semnificativă de piață,
fapt ce contribuie la mărirea ariei de acoperire a aplicațiilor, care se bucură de un număr tot mai
mare de utilizatori î n fiecare zi, tot de aici se evidențiază și familiarizarea utilizatorilor cu aceste
sisteme, deoarece zilnic sunt expuși la acestea în activitățile de zi cu zi.
Un criteriu foarte important în favoarea sistemelor mobile este reprezentat de portabilitate a
acestora, la care se adaugă o putere relativ mare de calcul și costurile scăzute ale multor dispozitive
mobile au atras tot mai mulți adepți, astfel un dispozitiv mobil, de tipul unui smartphone sau al
unei tablete este la îndemâna oricui în fiecare moment al zilei, gata să ușureze viața utilizatoril or
prin multitudinea de funții ș i aplicații disponibile.

13
1.4.2 Arhitectura și caracteristicile platformei propuse

Platforma menită să confere sistemul de gestiune al informațiilor utilizatorilor, bazată pe
sistemele mobile, necesită o cât mai bună acoperire, astfel trebuie să fie disponibilă pe majoritatea
sistemelor mobile actuale în funcție de popularitatea lor, astfel sisteme mobile ca Android sau IOS
sunt principalele vizate datorită cotei de p iață în cont inuă creștere, dar ș i a popularității lor.
Aceeași platformă trebuie să pună la dispoziție o bază de date distribuită capabilă să
stocheze toate datele necesare și care să permită accesul tuturor utilizatorilor conectați în mod
mijlocit prin intermediul a ltor entități, pentru a nu pune în perico l securitatea și integritatea prin
accesul direct al unor utilizatori neavizați sau rău intenționați. Însă foarte importante sunt și
capacitatea de stocare, care să suporte u n număr considerabil de tabele ș i înregis trări, performanța
care să asigure o viteză cât mai mare de acces și de transport de date, disponibilitatea , deoarece
aceasta trebuie să fie gata să stocheze date în fiecare moment al zilei.
În cadrul accesului mijlocit la baza de date este recomandată ut ilizarea unui server web ,
care să fie capabil să transfere date de la utilizatori către baza de date și de la baza de date la
utilizatori, într -un mod cât mai sigur, pentru a evita apariția breșelor în securitate, coruperea sau
compromiterea datelor utiliz ate. Alt aspect important este performanța lor, fiind necesar să poată
opera la viteze cât mai mari pentru un timp de răspuns cât mai mic, un astfel de server web este
bazat pe arhitectura client -server, logica fiind bazată pe cereri din partea utilizator ilor, iar pe baza
acestor cereri serv erul trebuie să transmită răspunsuri valide în cel mai scurt timp. Astfel
necesitatea unui timp de răs puns cât mai mic este crucială și în acest sens trebuie luate mă suri
optime în cadrul a rhitecturii rețelelor utilizat e și a volumului de date vehiculat de serverul web,
fiind mult mai optimă trimiterea datelor strict necesare pentru utilizatori, astfel timpul de transfer
scade în raport cu volumul de date vehiculate.
În cadrul soluției propuse un rol important îl are po sibilitatea utilizatorului de a comunica
cu platforma, acest lucru realizându -se în cadrul unei aplicații cu interfață grafică destinată
sistemelor mobile pentru a putea facilita utilizatorului posibilitatea de a introduce, monitoriza și
gestiona datele sa le în scopul prezentării lor medicilor specialiști pentru o expertiză optimă.
Această aplicație este necesar să fie prietenoasă, atractivă și ușor de utilizat pentru a putea facilita
gestiunea datelor cât mai eficient . Este necesar să pună la dispoziție fu ncționalități avansate pentru
a permite utilizatorului să introducă, să modifice, să șteargă și să vizualizeze datele vitale pentru
rezolvarea problemelor de sănătate, medicamentație sau nutriție. Datele prelevate trebuie stocate
cu ajutorul serverului web în baza de date și tot prin intermediul serverului web să fie puse la
dispoziția medicilor specialiști. Pentru o cât mai ușoară gestiune a lor se impune utilizarea unor
opțiuni grupate pe categorii în meniuri pentru a putea naviga cu ușurință printre ele, atunci când
este nevoie.
Aceste categorii trebuie să acopere a varie tate de informații diferite , dar înrudite, cum ar fi
diferite simptome, măsurători, medicamente, diete și multe altele pentru a putea satisface nevoile
tuturor utilizatorilor.

14
Astfel d atele prelevate de către utilizatori ajung cu succes în baza de date, unde sunt stocate
în siguranță , însă aceste date pentru a putea fi valorificate se impune expunerea lor către medicii
specialiști , dar pentru ca acest lucru să poată fi posibil este nece sară o aplicație cu interfață grafică
care să beneficieze de avantajele sistemelor mobile, pentru a permite medicilor să vizualizeze
datele utilizatorilor și să le valorifice la adevărata lor valoare pentru a putea modifica în bine starea
de sănătatea a ut ilizatorilor. În acest sens gazdele ideale pentru această aplicație sunt tot sistemele
mobile.
Aplicația destinată medicilor necesită funcționalități asemănătoare cu cea a utilizatorilor,
însă trebuie să pună la dispoziție un sistem de gestiune al ut ilizatorilor care se întâmplă să fie
pacienți ai acestor medici. T rebuie să permită vizualizarea datelor pacienților , dar și adăugarea și
ștergerea lor. Însă este necesar să pună în valoare datele prelevate de către utilizatori prin
intermediul categoriilor di spuse în meniuri sugestive , asemenea aplicației destinate utilizatorilor,
pentru a putea facilitatea rapiditatea și simplitatea gestiunii datelor, precum și inserarea datelor
programelor de medicamentație și de nutriție de către medici, fiecărui pacient ca re, conform
datelor sale, necesită aceste intervenții.
Ideal este și punerea la dispoziție a unui sistem de gestiune a acordurilor dintre medici și
utilizatori, cu alte cuvinte utilizatorii trebuie să posede opțiuni specifice, în cadrul aplicației
destina te pentru ei, pentru a putea decide ce medic le poate vizualiza datele, ce date pot aceștia să
vizualizeze și posibilitatea de a selecta ce medici au dreptul să le transmită date, precum programe
de medicamentație și nutriție. Însă este necesar ca același sistem să fie disponibil și pentru medici
în cadrul aplicației destinate lor , aceștia trebuie să profite de posibilitatea de a selecta pacienții
doriți, sau posibilitatea de a seta care pacienți să posede posibilitatea de a le transmite date, ce fel
de dat e pot să transmită, sau în cadru căror intervale se poate face transmiterea și recepționarea
datelor în cauză .
Un alt aspect important ce trebuie integrat atât în cadrul aplicației destinate utilizatorilor,
cât și a medicilor , este existența unui sistem d e notificări care să semnaleze atât utilizatorilor cât
și medicilor apariția unor evenimente, precum inserarea , modificarea sau ștergerea anumitor date,
precum și posibilitatea de a seta ce fel de notificări și de la cine pot să fie recepționate, sau în
cadrul cărui interval orar, atât de către utilizatori cât și de către medici.
Mai concret, în cadrul aplicației destinate utilizatorilor să se primească notificări legate de
programe de medicamentație și nutriție , cum ar fi orele la care trebuie s atisfăcute aceste, dar și
adăugări, ș tergeri sau modificări de date de către medici. Iar în cazul aplicației destinate medicilor
este necesar să se primească notificări de la utilizatori pentru eventualele probleme, simptome,
măsurători și modificări ale stării lor de sănătate.
Indicat este și prezența unui sistem de gestiune al medicamentelor, cu posibilitatea
utilizatorilor de a verifica prospecte și indicații de utilizare ale medicamentelor, dar și posibilitatea
medicilor de a verifica tipul și cantitatea medicame ntelor disponibile ale fiecărui pacient cu scopul
de a le prescrie altele în prealabil în cazul în care acestea nu sunt suficiente.

15
Capitolul 2. Tehnologii utilizate

2.1 Limbajul de programare Java

2.1.1 Prezentare general ă

Java este un limbaj de progr amare cu scop general, concurent, bazat pe clase, orientat pe
obiecte și conceput special pentru a avea cât mai puține dependințe de implementare. Este destinat
să permită dezvoltatorilor de aplicații să "scrie o dată, să ruleze oriunde" (WORA), ceea ce
înseamnă că codul Java compilat poate rula pe toate platformele care suportă Java fără a fi nevoie
de recompilare. Aplicațiile Java sunt în mod obișnuit compilate la cod binar care poate rula pe
orice mașină virtuală Java (JVM) indiferent de arhitectura calc ulatorului. Începând cu anul 2016,
Java este una dintre cele mai populare limbi de programare utilizate, în special pentru aplicațiile
web client -server, cu un raportor de 9 milioane de dezvoltatori. Limbajul de programare Java a
fost inițial dezvoltat de James Gosling la Sun Microsystems (care a fost achiziționată de Oracle
Corporation) și lansat în 1995 ca o componentă de bază a platformei Java Sun Microsystems.
Limbajul derivă mult din sintaxa limbajelor C și C ++, dar are mai puține facilități de nivel scăzut
decât oricare dintre ele. [10][11][12]
Implementarea originală și implementarea de referință a compilatoarelor Java, a mașini
virtuale și a bibliotecilor de cl asă au fost inițial lansate de Sun sub licențe de proprietate. Începând
cu luna mai 2007, în conformitate cu specificațiile “Procesului Comunitar Java ”, Sun a re alizat
majoritatea tehnologiilor Java în cadrul “Licenței Publice Generale GNU ”. Alții au dezvo ltat, de
asemenea, implementări alternative ale acestor tehnologii Sun, cum ar fi compilatorul GNU pentru
Java (compilator bytecode), GNU Classpath (biblioteci standard) și IcedTea -Web (plugin pentru
browser în scopul creării applet -urilor). Ultima versiun e este Java 8, care este singura versiune
acceptată în prezent gratuit de Oracle, deși versiunile anterioare sunt acceptate atât de Oracle, cât
și de alte companii pe bază comercială. [13]

2.1.2 Performanță

Programele scrise în Java au reputația de a fi mai lente și necesită mai multă memorie
decât cele scrise în C ++. Cu toate acestea, viteza de execuție a programelor Java s -a îmbunătățit
semnificativ odată cu introducerea compilării “just -in-time” în 1997/1998 pentru Java 1 .1, plus
adăugarea unor element e de limbaj care să susțină o analiză mai bună a codului (cum ar fi clasele
interioare ) și optimizări în mașina virtuală Java, cum ar fi HotSpot devenind implicit pentru JVM –

16
ul Sun în 2000. Cu Java 1.5, performanța a fost îmb unătățită prin adăugarea pachetului
java.util.concurrent, incluzând implementările Free Lock ale ConcurrentMaps care au fost
îmbunătățite ulterior în Java 1.6. [13]
Unele platforme oferă suport hardware direct pentru Java. Există microcontrolere care
pot rula Java în hardware în loc de o mașină virtuală Java software și unele procesoare bazate pe
ARM ar putea avea suport hardware pentru executarea Java bytecode prin opțiunea lor Jazelle,
deși suportul a fost în mare parte aband onat în implementările curente ale ARM . [13]

2.1.3 Sintaxă

Sintaxa Jav a este în mare parte influențată de C ++ . Spre deosebire de C ++, care combină
sintaxa pentru programare structurată, generică și orientată pe obiecte, J ava a fost construit aproape
exclusiv ca un limbaj orientat pe obiecte. Tot codul este scris în interiorul clasei și fiecare element
este un obiect, cu excepția tipurilor de date primitive (adică numere întregi, numere cu virgulă
mobilă, valori booleene și caractere), care nu sunt obiecte din motive de performanță. Java
reutilizează câteva aspecte populare ale C ++ (cum ar fi metoda printf ()). [13]
Spre deosebire de C ++, Java nu suporta supraîncărcarea operatorilor sau moșten irea
multiplă pentru clase, deși moștenirea multiplă este suportată pentru interfețe. Acest lucru
simplifică limbajul și ajută la prevenirea potențialelor erori și a designului anti -pattern. [13]
Java utilizează comentarii sim ilare cu cele din C ++. Există trei stiluri diferite de
comentarii: un stil de linie marcat cu două slash -uri (//), un stil cu mai multe linii deschis cu / * și
închis cu * /, iar stilul de comentare Javadoc a fost deschis cu / ** și închis cu * / . Stilul de
comentare Javadoc permite utilizatorului să execute executabilul Javadoc pentru a crea
documentația pentru program și poate fi citită de unele medii de dezvoltare integrate (IDE, mediu
de dezvoltarea integrat), cum ar fi Eclipse, sau Intellij IDEA pent ru a permite dezvoltatorilor să
acceseze documentația din cadrul IDE. [13]

Clasicul “Hello World! ” în limbajul Java poate fi remarcat în Figura 1.1.

Figura 1.1. Aplicația “Hello World! ”. [13]

17
2.1.4 Servlet

Tehnologia Java Serv let furnizează dezvoltatorilor w eb un mecanism simplu și
consistent pentru extinderea funcționalității unui server Web și pentru accesarea sistemelor de
afaceri existente. Servlet -urile sunt componente Java EE care generează răspunsuri (de obicei
pagini HTML) de la server, la cereri (de obicei, solicitări HTTP) de la clienți. Un servlet poate fi
considerat aproape ca un applet care rulează pe partea de server. [13]
Un e xemplu de servlet care imită clasicul “Hello Word” poate fi văzut î n Figura 1.2.

Figura 1.2. Exemplu S ervlet “Hello Word” . [13]

Instrucțiunile de import direcționează compilatorul Java să includă toate clasele publice
și interfețele din p achetele java.io și javax.servlet în cadrul compilării. Pachetele fac limbajul Java
potrivit pentru aplicații la scară largă. [13]
Clasa Hello din exemplul dat în Figura 1.2 extinde clasa GenericServlet , care oferă
interfața p entru server pentru transmiterea cererilor către servlet și controlul ciclului de viață al
servlet -ului. Clasa Hello înlocuiește metoda serviciului (ServletRequest, ServletResponse) definită
de interfața Servlet pentru a furniza codul pentru dispozitivul d e preluare a cererii de servicii.
Metoda service () folosește un obiect ServletRequest care conține cererea de la client și un obiect
ServletResponse folosit pentru a crea răspunsul returnat clientului , tot metoda service() declară că
aruncă excepțiile Ser vletException și IOException dacă o problemă o împiedică să răspundă la
cerere. [13]
Metoda setContentType(String) în obiectul destinat răspunsului este chemată pentru a
seta tipul de conținut MIME al datelor returnate la "tex t / html". Metoda getWriter() din răspunsuri
returnează un obiect PrintWriter utilizat pentru a scrie datele trimise clientului. Metoda
println (String) este chemată să scrie " Hello Word !" la răspuns și apoi metoda close () este chemată
să închidă scriitorul de imprimare, ceea ce face ca datele care au fost scrise în flux să fie returnate
clientului. [13]

18
Pentru a implementa și rula un servlet, trebuie folosit un container web. Un container
web (cunoscut și ca un container de s ervlet) este, în esență, componenta unui server web care
interacționează cu servlet -urile. Containerul web este responsabil pentru gestionarea ciclului de
viață al servlet -urilor, maparea unei adrese URL la un anumit servlet și asigurarea faptului că
solic itantul adresei URL are drepturile de acces corecte. [13]
Servlet -urile pot fi generate automat din JavaServer Pages (JSP) de către compilatorul
de JavaServer Pages. Diferența dintre servlet -uri și JSP este că servlet -urile în corporează de obicei
cod HTML în interiorul codului Java, în timp ce JSP -urile încorporează codul Java în HTML. În
timp ce utilizarea directă a servlet -ului pentru a genera codul HTML a devenit rară, cadrul web
MVC de nivel superior din Java EE (JSF) utili zează în mod explicit tehnologia Servlet pentru
gestionarea solicitării / răspunsului la nivel scăzut prin FacesServlet . O utilizare oarecum mai
veche constă în folosirea servlet -urilor împreună cu JSP într -un model denumit "Model 2". [13]

Avantajele utilizării servlet -urilor sunt performanța lor rapidă și ușurința de utilizare,
combinate cu mai multă putere peste CGI -ul tradițional (Common Gateway Interface). Scripturile
tradiționale CGI scrise în Java au un număr de dezavan taje de performanță:
• Atunci când se face o solicitare HTTP, se creează un nou proces de fiecare dată când este
apelat scriptul CGI. Costurile asociate creării de procese pot domina volumul de lucru, mai
ales atunci când scenariul face operațiuni relativ r apide. Astfel, crearea de proceselor va
dura mai mult timp pentru executarea scriptului CGI. În schimb, pentru servlet, fiecare
cerere este gestionată de un thread Java separat în cadrul procesului de server web, evitând
astfel cheltuielile aferente proces elor de ”forking” în cadrul daemon -ului HTTP.
• Cererile CGI simultane vor încărca scriptul CGI care va fi copiat în memorie câte o dată
pentru fiecare cerere. Cu servlet, există o singură copie care persistă între solicitări și este
împărțită între fire.
• Doar o singură instanță răspunde concurent tuturor solicitărilor. Acest lucru reduce
utilizarea memoriei și facilitează gestionarea datelor persistente.
• Un servlet poate fi rulat de un container servlet într -un mediu restrictiv, numit sandbox.
Acesta este similar cu un applet care rulează în sandbox -ul browserului web. Acest lucru
permite utilizarea restricționată a servlet -urilor potențial dăunătoare . Programele CGI pot
fi, desigur, și sandbox -urile, deoarece sunt pur și simplu procese de operare. [13]

Tehnologii cum ar fi FastCGI și derivatele sale (inclusiv SCGI, AJP) nu prezintă
dezavantajele de performanță ale CGI, cauzate de procesul care se creează constant. Ele sunt, însă,
la fel de simple ca CGI. Prin urmare acestea sunt, de asemenea, în contrast cu servlet -urile care
sunt substanțial mai complexe. [13]

19
2.2 Sistemul de operare Android

2.2.1 Prezen tare general ă

Android este un sistem de operare bazat pe nucleul Linux, dezvoltat de comp ania Google
pentru dispozitivele mobile capabile de funcționalitate touchscreen cum ar fi smartphone -uri sau
tablete. Interfața grafică a sistemului de operare Android se bazează in principal pe manipularea
directă, folosind gesturi tactile care corespund în mod liber acțiunilor din lumea reală, c um ar fi
împingerea, atingerea ș i ciupirea pentru manipularea obiectelor sau a con ținutului de pe ecran ,
precum ș i o tastatură virtuala modificabilă pentru a facilita introducea de text. [14]
În prezent, pe lângă dispozitivele cu touchscreen, compania Google și -a extins sfera de
interes in ceea ce privește distribuția sistemului de operare Android, încerc ând implementarea
acestuia și pe alte dispozitive prin intermediul unor distribuții special create pentru a profita de
noile oportunități puse la dispoziție de: televizoare inteligente cu ajutorul sistemului de operare
Android TV, mașini cu ajutorul sistemului de operare Android Auto sau ceasuri inteligente cu
ajutorul sistemului de ope rare Android Wear. [14]
Acest sistem de operare a fost inițial dezvoltat de compania Android Inc., companie care a
fost ulterior cumpărată de Google. Sistemul de operare Android a fost prezentat in mod oficial
publicului in an ul 2007, tot atunci își făcea apariția ș i prima sa versiune finală, împreună cu “Open
Handset Alliance”, un consorțiu de companii hardware, software și de telecomunicații dedicate
avansării standardelor deschise pentru dispozitivele mobile. Începând cu pri ma reclamă pentru
dispozitivele cu Android î n septembrie 2008, sistemul de operare a trecut prin multiple versiuni
importante, versiunea curentă fiind 7.1 .2 “Nougat” lansată în 4 aprilie 2017. Aplicațiile Andoid
(“apps”) pot fi descărcate din magazinul Goo gle Play, în care se regăsesc p este 2.7 milioane de
aplicații î n februarie 2017. Android este cel mai bine vândut sistem de operare pentru tablete încă
din 2013 și rulează pe marea majoritate a smartphone -urilor. În mai 2017, sistemul de operare
Android ar e parte de două miliarde de utilizatori activi luna r, fiind cel mai utilizat sistem de
operare. [14]
Codul sursă al sistemului de operare Android este făcut public de Google sub licență de tip
open -source, deși cele mai multe dispozitive cu Android conțin o combinație de software open –
source și software patentat, incluzând software patentat necesar pentru a accesa servicii le Google.
Android este preferat de companiile de tehnologie care au nevoie de un sistem de operare gata
făcut, care are costuri scăzute și personalizabil pentru dispozitive performante. Datorită faptului
că este open -source a încurajat o mare comunitate de dezvoltatori și entuziaști să folosească codul
open -source ca o fundație pentru proiecte conduse de către comunitate, care creează actu alizări
pentru dispozitive mai vechi, care adaugă funcționalități noi pentru utilizatorii avansați, sau care
adaugă Android unor dispozitive care nu au fost lansate cu acest sistem de operare. Datorită
diversității componentei hardware care rulează sistemul Android apar întârzieri relativ mari când

20
vine vorba de actualizări de sistem pentru trecerea la versiuni mai noi ale sistemului de operare
sau în cadrul patch -urilor de securitate, fiind nevoie în mod normal de luni până sa ajungă la
utilizatori, iar câteodată nu își mai fac apariția. [14]

2.2.2 A rhitectura sistemului Android

Nucleul sistemului de operare Android este bazat pe cel al sistemului de opera re Linux.
Din aprilie 2014, dispozitivele cu Android folosesc versiunile 3.4, 3.10 sau 3.18 ale nucleului
Linux. Versiunea specifică a nucleului folosit depinde de actualul dispozitiv cu Android ș i de
platforma sa hardware. Android a folosit versiuni variate ale nucleului încă de la versiunea 2.6 .25
care a fost folosită în versiunea Android 1.0. [14]
Variația nucleului Linux în Android conține ș i modificări de arhitectură implementate de
Google în afara ciclului de dezvoltare tipic nucleului Linux, cum ar fi includere a unor componente
precum: Binder, ashmem, pmem, logger, wakelocks și manipularea în afara memoriei (OOM).
Anumite caracteristici pe care Google le -a contribuit nucleului Linux, în special o caracteristică
de gestionare a puterii numita “wakelocks” , au fos t respinse de dezvolt atorii nucleului principal ,
parțial pentru că au considerat că Google nu a intenționat să își mențină propriul cod. [14]
Spațiul de stocare flash pe dispozitivele Android este împărțit în mai multe partiți i, cum ar
fi “/system” pentru sistemul de operare în sine și “/data” pentru datele de utilizat or și instalările
aplicațiilor. În contrast cu distribuțiile Linux de tip desktop, proprietarii de dispozitive Android nu
primesc acces “root” la sistemul de oper are, iar părțile sensibile, cum ar fi “/system” , oferă doar
posibilitatea de citire. Cu toate acestea, accesul “root” poate fi obținut prin exploatarea defectelor
de securitate din Android, lucru des folosit de către comunitatea open -source pentru a spori
capacitățile dispozitivelor lor, dar și de către părțile rău intenționate pentru a i nstala viruși ș i
programe rău intenționate. [14]
Android este o distribuție Linux, în conformitate cu “Linux Fundațion”, șeful open -source
Chris DiBona și câțiva jurnaliști. Alții, cum ar fi inginerul Google, Patrick Brady, declară că
Android nu este Linux în sensul tradițional de Linux asemănător Unix. Android nu include
biblioteca GNU C (folosește Bionic ca o bibliotecă alternativă C) și câ teva alte componente găsite
de obicei în distribuțiile Linux. [14]
Arhitectura sistemului de operare Android poate fi remarcată în Figura 2.1.

21

Figura 2.1. Diagrama arhitecturii Android . [14]

Pe partea de sus a nucleului Linux există middleware , biblioteci, API-uri scrise in C și
software -ul aplicațiilor care rulează pe framework -ul aplicațiilor care include biblioteci
compatibile cu Java. Dezvoltarea nucleului Linux continuă independent de bazel e codului sursă
ale sistemului A ndroid. [14]
Până la versiunea 5.0, Android a folosit Dalvik ca și mașină virtuală de proces cu compilare
just-in-time( JIT) bazată pe urmăriri pentru a executa Dalvik “dex -code” (Executabil Dalvi k), care
de obicei este tradus in Java bytecode. Urmărind principiul JIT bazat pe urme, pe lângă
interpretarea majorității codului de aplicație, Dalvik efectuează compilația și execuția nativă a
segmentelor de cod executate selectate (“urme”) de fiecare da tă când este lansată o aplicație.
Android 4.4 a introdus Android Runtime (ART) ca un mediu de rulare nou, care utilizează
compilarea înainte de timp (AOT) pentru a compila în întregime bytecode -ul aplicației în cod
mașină la instalarea unei aplicații. În a ndroid 4.4, ART a fost o caracteristică experimentală și nu
a fost activată in mod implicit, dar a devenit singura opțiune de rulare în următoarea versiune
majoră de Android, 5.0. Pentru biblioteca sa Java, platforma Android utilizează un subset al

22
proiect ului Apache Harmony, proiect întrerupt în prezent. În decembrie 2015, Google a anunțat că
următoarea versiune de Android trece la o implementare Java baz ată pe OpenJDK. [14]
Biblioteca standard C a sistemului Android, Bionic, a fost dezvoltată de Google în mod
specific pentru Android, ca o derivare a codului librăriei standard C în cadrul BSD. Bionic în sine
a fost proiectat cu câteva caracteristici majore specifice nucleului Linux. Principalele avantaje ale
utilizării Bionic î n locul bibliotecii GNU C (glibc) sau uClibc sunt amprenta mai mică de rulare și
optimizarea procesoarelor cu frecvență joasă. În același timp, Bionic este licențiat sub licența BSD,
pe care Google o consideră mai potrivită pentru modelul sistemului Androi d. [14]
Urmărind un model de licențiere diferit, spre sfârșitul anului 2012, Google a schimbat stiva
Bluetooth în Android de la BlueZ cu licență GPL, la BlueDroid cu licență Apache. [14]
Android n u are în mod implicit un sistem nativ X Window și nici nu suportă setul complet
de biblioteci standard GNU. Acest lucru a făcut dificilă transferarea aplicațiilor sau bibliotecilor
existente de pe Linux către Android, până când versiunea r5 a chitului nati v de dezvoltare (NDK)
a adus suport pentru aplicațiile scrise complet în C sau C++. Bibliotecile scrise în C pot fi, de
asemenea, folosite în aplicații prin utilizarea JNI. [14]
De la apariția versiunii Marshmallow, “Toybox”, o colecție de utilitare la linia de comandă
(mai ales pentru utilizarea ei de către aplicații, deoarece Android nu oferă o interfață pentru linia
de comandă în mod implicit), a înlocuit colecția similară “Toolbox”. [14]
Androi d are un alt sistem de operare, Trusty OS, în cadrul acestuia, ca parte a
componentelor software “Trusty” care susțin un mediu de execuție de încredere (TEE) pe
dispozitivele mobile. Trusty și Trusty API pot fi modificate. Aplicațiile pentru sistemul de op erare
Trusty pot fi scrise în C/C++ (suportul pentru C++ este limitat) și au acces la o bibliotecă mică C.
Toate aplicațiile Trusty au un singur fir de execuție, execuția pe mai multe fire de execuție în
spațiul Trusty în prezent nu este suportată . Dezvolt area aplicațiilor de la terți nu este suportat în
versiunea curentă și software -ul care ruleaza pe sistemul de operare ș i pe procesor pentru acesta,
rulează și framework -ul DRM pentru conținut protejat. Există multe alte utilizări pentru un TEE
cum ar fi p lățile prin telefon, securizarea bancară, criptarea completă a disk -ului, autentificarea
multi -factor, protecția pentru resetarea dispozitivului, stocarea permanentă protejată prin repetare,
afișarea wireless a conținutului protejat, securizarea PIN -urilor și procesarea amprentelor digitale
și chiar detectarea software -ului rău intenționat. [14]

2.2.3 Versiuni Android

Istoricul versiunilor sistemului de operare Android a început cu lansarea Android A lpha în
5 noiembrie 2007. Prima versiune comercială Android 1.0 a fost lansată în septembrie 2008.
Android este dezvoltat continuu de Google ș i de Open Handset Alliance și a văzut o serie de
actualizări ale sistemului de operare de bază de la lansarea inițială. [14]

23

Versiunile 1.0 și 1.1 nu au fost lansate sub nume specifice de coduri. Numele de cod
Android sunt legate de produse de cofetărie și au fost în ordine alfabetică începând cu 2009,
Android 1.5 Cupcake, cea mai recentă versiune majoră fiind And roid 7.0 Nougat, lansată în august
2016. [14]
Versiunile majore ale sistemului de operare lansate in ordine cronologica sunt:
1) 1.0
• Lansată în 23 septembrie 2008
• Versiune 1.0
• Nivel API 1

2) 1.1
• Lansată în 9 februarie 2009
• Versiun e 1.1
• Nivel API 2

3) Cupcake
• Lansată în 27 aprilie 2009
• Versiune 1.5
• Nivel API 3
Figura 2.2. Interfața în Android 1.5 . [14]

4) Donut
• Lansată în 15 septembrie 2009
• Versiune 1.6
• Nivel API 4
Figura 2.3. Interfața în Andr oid 1.6 . [14]

5) Eclair
• Lansată în 26 octombrie 2009
• Versiuni 2.0 -2.1
• Nivele API 5 -7

Figura 2.4. Interfața în Android 2.0 . [14]

24

6) Froyo
• Lansată în 20 mai 2010
• Versiuni 2.2 -2.2.3
• Nivel API 8
Figura 2.5. Interfața în Android 2.2 . [14]

7) Gingerbread
• Lansată în 6 dece mbrie 2010
• Versiuni 2.3 -2.3.7
• Nivele API 9 -10

Figura 2.6. Interfața în Android 2.3 . [14]

8) Honeycomb
• Lansată în 22 februarie 2011
• Versiuni 3.0 -3.2.6
• Nivele API 11 -13
Figura 2.7. Interfața în Android 3.0 . [14]

9) Ice Cream Sandwich
• Lansată în 18 octombrie 2011
• Versiuni 4.0 -4.0.4
• Nivele API 14 -15
Figura 2.8. Interfața în Android 4 .0. [14]

10) Jelly Bean
• Lansată în 9 iulie 2012
• Versiuni 4.1 -4.3.1
• Nivele API 16 -18
Figura 2.9. Interfața în Android 4.1 . [14]

25

11) KitKat
• Lansată în 31 octombrie 2013
• Versiuni 4.4 -4.4.4
• Nivel API 19
Figura 2.10. Interfaț a în Android 4.4 . [14]

12) Lollipop
• Lansată în 12 noiembrie 2014
• Versiuni 5.0 -5.1.1
• Nivele API 21 -22

Figura 2.11. Interfața în Android 5.0 .[14]

13) Marshmallow
• Lansată în 5 octombrie 20 15
• Versiuni 6.0 -6.0.1
• Nivel API 23

Figura 2.12. Interfața în Android 6.0 . [14]

14) Nougat
• Lansată în 22 august 2016
• Versiuni 7.0 -7.1.2
• Nivele API 24 -25 [14]

Figura 2 .13. Interfața în Android 7.0 . [14]

26
2.2.4 Cotă de piață

Compania de cercetare Canalys a estimat în prima jumătate din 2009 că Android avea o
cotă de 2,8% din livrările de smartphone -uri la nivel mondial. Până la sfârșitul anu lui 2010, acesta
a crescut la 33% din piață devenind cea mai bine vândută platforma pentru smartphone -uri,
depășind Symbian. Până în a doua jumătate a anului 2011, Gartner a estimat că mai mult de
jumătate (52,5%) din vânzările de smartphone -uri au aparțin ut sistemului Android. Până în a doua
jumătate a anului 2012, Android a avut o cotă de 75% din piața smartphone globală, potrivit firmei
de cercetare IDC. [14]
În iulie 2011, Google a declarat că 550 000 de dis pozitive Android erau activate în fiecare
zi, de la 400 000 pe zi în mai, iar peste 100 de milioane de dispozitive au fost activate cu o creștere
de 4,4% pe săptămână. În septembrie 2012, 500 de milioane de dispozitive au fost activate cu 1,3
milioane de a ctivări pe zi. În mai 2013, la Google I / O, Sundar Pichai a anunțat că 900 de milioane
de dispozitive Android au fost activate. [14]
Cota de piață pentru Android variază în func ție de locație. În iulie 2012, abonații cu
vârsta de peste 13 ani din Statele Unite, folosind Android, au fost de până la 52% și au crescut la
90% în China. Începând cu luna mai 2013, au fost instalate 48 de miliarde de aplicații (" apps") din
magazinul Google Play și până în septembrie 2013 au fost activate un miliard de dispozitiv e
Android. În februarie 2017, magazinul Google Play a publicat peste 2,7 milioane de aplicații
Android, iar în mai 2016 aplicațiile au fost descărcate de peste 65 de miliarde de ori. [14]
Potrivit unei estimări , smartphone -urile Android au avut o bază instalată de 1,8 miliarde
de unități în 2015, ceea ce reprezintă 76% din numărul total estimat de sm artphone -uri din întreaga
lume. [14]
Android are cea mai mare bază in stalată a oricărui sistem de operare mobil și, începând
cu 2013, cel mai bine vândut sistem de operare global, cu vânzări în 2012, 2013 și 2014 aproape
de baza instalată a tuturor PC -urilor. În a doua jumătate a anului 2015, cota de piață globală de
smartp hone -uri cu Android a fost de 84,7%, cea mai mare valoare înregistrată vreodată. Începând
cu data de 28 septembrie 2016, cu o cotă de piață de 52,5%, Samsung rămâne liderul pentru livrarea
de smartphone -uri și tablete cu Android, urmat de LG, Huawei, Motor ola, Lenovo, Sony, HTC,
Asus, Alcatel și Xiaomi. [14]
Până în 2016, Android era pe majoritatea smartphone -urilor în aproape toate țările lumii,
cu excepția Statelor Unite și a Canadei (incluzând continentul Am ericii de Nord în totalitate),
Australia și Japonia. Câteva țări, cum ar fi Marea Britanie, pierd majoritatea Android dacă sunt
incluse tablete. [14]
În septembrie 2015, Google a anunțat că Android avea 1,4 mi liarde utilizatori activi
lunar. Acest lucru s -a schimbat la 2 miliarde utilizatori lunari activi în mai 2017. [14]

27
2.3 Dezvoltare de aplicații Android

2.3.1 Android Studio

Android Studio este mediul oficial de dezvoltare integrat (IDE) pentru platforma
Android. A fost anunțat la data de 16 mai 2013 la conferința Google I / O. [15]
Android Studio a fost în faza de acces timpuriu pornind de la versiunea 0.1 în mai 2013,
apoi a int rat în etapa beta pornind de la versiunea 0.8, care a fost lansată în iunie 2014. Prima
versiune stabilă a fost lansată în decembrie 2014, începând cu versiunea 1.0. Bazat pe software -ul
IntelliJ IDEA de la JetBrains, Android Studio este conceput special p entru dezvoltarea de aplicații
Android. Este disponibil pentru descărcare pe Windows, MacOS și Linux și a înlocuit Eclipse
Android Development Tools (ADT) ca IDE primar Google pentru dezvoltarea de aplicații native
Android. Interfața mediului integrat de d ezvoltare Android Studio se observă în Figura 2.14. [15]

Figura 2.14 . Interfața în Android Studio . [16]

Funcții noi vor fi lansate cu fiecare versiune de Android Studio. Următoarele funcții sunt
furnizate în versiunea stabilă actuală:
• suport de construcție bazat pe Grandle
• refactorizare ș i remedieri rapide specifice Android
• Instrumente Lint pentru a rezolv a probleme legate de performanță , grad de utilizare,
compatibilitatea versiunilor și alt e probleme

28
• Integrare ProGuard și capabilități de semnare a aplicațiilor
• Utilitare bazate pe șabloane pentru a crea desene și componente comune Android
• Un editor de layout bogat, care permite utilizatorilor drag -and-drop pe componentele UI,
opțiunea de a pr evizualiza layout -urile pe mai multe configurații de ecran
• Suport pentru crearea aplicațiilor Android Wear
• Suport încorporat pentru Google Cloud Platform, care permite integrarea cu Firebase
Cloud Messaging ("Google Cloud Messaging") și Google App Engine
• Dispozitiv virtual Android (Emulator) pentru a rula și depana aplicații [15]

2.3.2 Android SDK

Kitul de dezvoltare software Android (SDK) include un set cuprinzător de instrumente
de dezvoltare. Acestea includ un program de d epanare, bi blioteci, un emulator de dispozitive
mobile bazat pe QEMU, documentație, cod exemplu și tutoriale. Platformele de dezvoltare
acceptate în prezent includ computerele care rulează Linux (orice distribuție modernă pentru
Linux), Mac OS X 10.5.8 sau ulterior și Windows 7 sau o versiune ulterioară. Începând cu martie
2015, SDK nu este disponibil pe Android, însă dezvoltarea de software este posibilă prin utilizarea
de aplicații Android specializate. [17]
Până la sfârșitul anului 2014, mediul de dezvoltare integrat suportat oficial (IDE) a fost
Eclipse utilizând pluginul Android Development Tools (ADT), deși IntelliJ IDEA IDE (toate
edițiile) suportă pe deplin dezvoltarea Android, iar NetBeans IDE suportă, de asemenea,
Dezv oltare Android prin intermediul unui plugin. Începând cu 2015, Android Studio, produs de
Google și bazat pe IntelliJ, este IDE -ul oficial. Totuși, dezvoltatorii sunt liberi să utilizeze alte
medii de dezvoltare, însă Google a făcut clar faptul că ADT a fos t oficial anulat de la sfârșitul
anului 2015 pentru a se concentra pe Android Studio ca Android IDE oficial. În plus, dezvoltatorii
pot folosi orice editor de text pentru a edita fișiere Java și XML, apoi să utilizeze instrumentele
din linia de comandă (Ja va Development Kit și Apache Ant sunt necesare) pentr u a crea, a construi
și a depana aplicații Android, precum și pentru a controla dispozitive Android atașate. [17]
Îmbunătățirile pentru SDK -ul Android merg concomitent cu d ezvoltarea generală a
platformei Android. SDK acceptă, de asemenea, versiuni mai vechi ale platformei Android în cazul
în care dezvoltatorii doresc să vizeze aplicațiile lor la dispozitive mai vechi. Instrumentele de
dezvoltare sunt componente care pot fi descărcate, astfel încât, după descărcarea ultimei versiuni
și platformă, platformele și instrumentele mai vechi pot fi descărcate și pentru testarea
compatibilității. [17]
Aplicațiile Android sunt disponibile în format .apk ș i stocate în folderul /data/app în
sistemul de operare Android (folderul este accesibil numai utilizatorilor de tip administrator din
motive de securitate). Pachetul APK conține fișiere .dex (fișiere de coduri byte compilate
executabile Dalvik), fișiere d e resurse etc. [17]

29
2.3.3 Android NDK

Bibliotecile scrise în C, C ++ și alte limbaje pot fi compilate în codul nativ ARM, MIPS
sau x86 și sunt instalate utilizând kitul nativ de dezvoltare Android (NDK). Aceste biblioteci nat ive
pot fi folosite în cod Java care rulează sub Dalvik VM utilizând apelul System.loadLibrary, care
face parte din clasele standard Java din Android. [17]
Aplicații complete pot fi compilate și instalate utilizând instrumente le de dezvoltare
tradiționale. Cu toate acestea, conform documentației Android, NDK nu ar trebui să fie folosit
exclusiv pentru că dezvoltatorul preferă să programeze în C / C ++, deoarece utilizarea NDK crește
complexitatea, în timp ce majoritatea aplicaț iilor nu ar beneficia de utilizarea acestuia. [17]
Debugger -ul ADB oferă un root shell sub Emulator Android, care permite încărcarea și
executarea codului nativ ARM, MIPS sau x86. Codul nativ poate fi compilat folosind GCC sau
compilatorul Intel C ++ pe un PC standard. Rularea codului nativ este complicată de utilizarea de
către Android a unei biblioteci C non -standard (libc, cunoscută sub numele de Bionic). [17]
Debugger -ul ADB oferă suport pentru emulatorul Android, care permite încărcarea și
executarea codului nativ ARM, MIPS sau x86. Codul nativ poate fi compilat folosind GCC sau
compilatorul Intel C ++ pe un PC standard. Rularea codului nativ este complicată datorită utilizării
de către Android a unei biblioteci non -standard de C (libc, cunoscută sub numele de Bionic).
Biblioteca grafică utilizată de Android pentru a arbitra și a controla accesul la acest dispozitiv se
numește Skia Graphics Library (SGL) și a fost lansată sub licență open source . Skia are backend –
uri pentru Win32 și Unix, permițând dezvoltarea de aplicații multi -platformă și este motorul grafic
care stă la baza browserului web Google Chrome. [17]
Este posibilă utilizarea Android Studio cu Gradle pent ru a dezvolta proiecte bazate pe
NDK. Alte instrumente ale unor parți terțe permit integrarea NDK în Eclipse și Visual Studio. [17]

2.3.4 Gradle

Gradle este un sistem de construcție automatizat de tip open source care se baz ează pe
conceptele Apache Ant și Apache Maven și introduce un limbaj specific domeniului Groovy
(DSL) în locul formularului XML folosit de Apache Maven pentru declararea configurației
proiectului. Gradle utilizează un graf aciclic direcționat ("DAG") pentr u a determina ordinea în
care pot fi executate sarcini. [18]
Gradle a fost proiectat pentru construirea mai multor proiecte care pot crește la
dimensiuni destul de mari și sprijină construirea incrementală prin determinarea in teligentă a
părților din “build tree” până la data actuală, astfel încât orice sarcină care depinde de ace ste părți
nu va trebui să fie execută din nou . Plugin -urile inițiale sunt concentrate în primul rând în jurul
dezvoltării și implementării Java, Groo vy și Scala. [18]

30

2.3.5 Limbajul XML

Extensible Markup Language (XML) este un limbaj de tip markup care definește un set de
reguli pentru codificarea documentelor într -un format care poate fi citit de om și poate fi citit de
mașină. Un exemplu de document XML este vizibil în Figura 2.15. [19]

Figura 2.15 . Exemplu de document XML . [19]

Obiectivele de proiectare ale XML subliniază simplitatea, ge neralitate a și utilitatea pe
Internet. Este un format de date textual cu suport puternic prin intermedi ul Unicode pentru diferite
limbaje umane. Deși proiectarea XML se concentrează pe documente, limba jul este folosită pe
scară largă pentru reprezentarea s tructurilor de date arbitrare , cum ar fi cele utilizate în serviciile
web. Există mai multe sisteme schematice care ajută la definirea limbajelor bazate pe XML, în
timp ce programatorii au dezvoltat numeroase interfețe de programare a aplicațiilor (API) pe ntru
a ajuta la prelucrarea datelor XML. [19]

Terminologii și componente în cadrul limbajului XML :
• Caracter: Un document XML este un șir de caractere. Aproape fiecare caracter acceptat
de Unicode poate apărea într -un document XML.
• Procesor și aplicație : Procesorul analizează marcajul și transmite informații structurate
unei aplicații. Specificația plasează cerințe privind ceea ce un procesor XML trebuie să
facă și ceea ce nu trebuie să facă, dar aplicația este în afara domeniu lui său de aplicare.
Procesorul (așa cum îl numește specificația) este adesea referit în mod colocvial ca un
parser XML.

31
• Marcaj și conținut : Caracterele care compun un document XML sunt împărțite în marcaj
și conținut, care se pot distinge prin aplicarea regulilor simple sintactice. În general, șirurile
care constituie marcare fie încep cu caracterul < și se termină cu un caracter >, fie încep cu
caracterul & și se termină cu caracterul ;. Șirurile de caractere care nu sunt marcate sunt de
tip conținut . Cu toate acestea, într -o secțiune CDATA, delimitatorii <! [CDATA [ și ]]>
sunt clasificați ca marcaj, în timp ce textul dintre acestea este clasificat drept conținut. În
plus, spațiile libere înainte și după cel mai exterior ele ment sunt clasificate ca marca je.
• Etichetă (Tag) : O etichetă este o construcție de tip marcaj care începe cu caracterul < și
se termină cu caracterul >. Etichetele vin în trei forme: etichetă de început , cum ar fi
< section >, etichetă de sfârșit, cum ar fi < / section >, etichetă de tip element gol, cum ar
fi < line-break >,
• Element: Un element este o componentă a unui document logic care începe fie cu o
etichetă de început și se termină cu o etichetă de finală potrivită, fie constă doar dintr -o
etichetă cu element gol. Caracterele dintre eticheta de început și eticheta de final , dacă
există, sunt conținutul el ementului și pot conține marcaje , inclusiv alte elemente, numite
elemente c opil.
• Atribut : Un atribut este un construct or de marcaje constând dintr -o pereche de nume /
valoare care există într -o etichetă de început sau etichetă cu element gol. Un atribut XML
poate avea o singură valoare și fiecare atribut poate apărea cel mult o dată pe fiecare
element. În situația obișnuită în care este dorită o listă de valori multi ple, aceasta trebuie
făcută prin codificarea listei într -un atribut XML bine format cu un format dincolo de ceea
ce XML definește. De obicei, ac easta este o listă delimitată cu virgulă, cu punct și virgulă
sau, dacă se știe că valorile indivi duale nu conț in spații, poate fi utilizată o listă delimitate
cu spații .
• Declarația XML: Documentele XML pot începe cu o declarație XML care descrie unele
informații despre ele însele , de exemplu : <? Xml version = "1.0" encoding = "UTF -8"?>.
• Comentarii : Comentariile po t apărea oriunde într -un document în afara elementelor de
marcaj. Comentariile nu pot apărea înainte de declarația XML. Comentariile încep cu <! –
și se termină cu ->. Pentru compatibilitatea cu SGML, șirul " –" (dublu -cratimă) nu este
permis în interiorul comentariilor; aceasta înseamnă că comentariile nu pot fi imbricate.
Ampersandul nu deține semnificații speciale în cadrul comentariilor, astfel încât referințele
entității și caracterelor nu sunt recunoscute ca atare și nu există modalități de a reprezen ta
caracterele în afara setului de caractere al codificării documentului. [19]

32
2.4 Representational state transfer (REST)

2.4.1 Prezen tare generală

“Representational state transfer ” (REST) sau “RESTful Web Services” re prezintă o
modalitate de a asigura interoperabilitatea între sistemele informatice de pe Internet. Serviciile
web compatibile cu REST permit sistemelor solicitante să acceseze și să manipuleze reprezentările
textuale ale resurselor web folosind un set unif orm și predefinit de operații. Există și alte forme de
servicii web care își expun propriile seturi de operații, cum ar fi WSDL și SOAP. [20]
"Resursele web" au fost definite pentru prima dată pe World Wide Web ca documente
sau fișiere identificate prin adresele lor URL, dar astăzi au o definiție mult mai generică și abstractă
care cuprinde toate lucrurile sau entitățile care pot fi identificate, numite, adresate sau manipulate,
în orice caz, pe Web. Într -un serviciu web RESTfu l, solicitările făcute către un URI al unei resurse
vor genera un răspuns care ar putea fi în XML, HTML, JSON sau în alt format definit. Răspunsul
poate confirma că s -a făcut o modificare a resursei stocate și poate furniza legături hypertext la
alte resur se sau colecții de resurse conexe. Folosind HTTP, după cum este cel mai frecvent, tipul
de operațiuni disponibile include cele predefinite de verbele HTTP GET, POST, PUT, DELETE
și așa mai departe. [20]
Folosind un protocol fă ră statură și operațiuni standard, sistemele REST urmăresc
performanța, fiabilitatea și capacitatea de creștere rapidă prin reutilizarea componentelor care pot
fi gestionate și actualizate fără a afecta sistemul în ansamblul s ău, chiar și în timp ce ruleaz ă. [20]
Termenul transfer de stat reprezentativ a fost introdus și definit în anul 2000 de Roy
Fielding în disertația sa de doctorat. Fielding a folosit REST pentru a proiecta HTTP 1.1 și
identificatori de resurse uniforme (UR I). Termenul are ca scop evocarea unei imagini a modului
în care se comportă o aplicație web bine concepută: este o rețea de resurse web (o mașină virtuală
de stat) în care utilizatorul avansează prin aplicație, selectând linkuri, cum ar fi /user/tom, sau
operații cum ar fi GET sau DELETE (tranziții de stare), rezultând că resursa următoare
(reprezentând următoarea stare a aplicației) este transferată utilizatorului pentru utilizarea ei. [20]

2.4.2 Proprietăți arhitecturale

Proprietățile arhitecturale afectate de constrângerile stilului arhitectural REST sunt:
• Interacțiunile de tipul performanță -componente pot fi factorul dominant în performanța
percepută de utilizator și eficiența rețelei
• Scalabilitate pentru a suporta un n umăr mare de componente și interacțiuni între
componente. Roy Fielding, unul dintre principalii autori ai caietului de sarcini HTTP,
descrie efectul REST asupra scalabilității după cum urmează: separarea de preocupări în

33
cadrul arhitecturii client -server a serviciilor REST simplifică implementarea
componentelor, reduce complexitatea semanticii conectorilor, îmbunătățește eficac itatea
reglării performanței și mărește scalabilitatea componentelor serverului pur.
Constrângerile de sistem stratificate permit in termediarilor, de exemplu, proxy -urilor,
gateway -urilor și firewall -urilor să fie introduse în diferite puncte ale comunicării fără a
schimba interfețele dintre componente, permițându -le astfel să asiste în traducerea
comunicării sau să îmbunătățească perf ormanța prin cache -ul la scară largă.
REST permite procesarea intermediară prin constrângerea mesajelor să fie auto –
descriptivă: interacțiunea este lipsită de statură între solicitări, metodele standard și tipurile
de suporturi media sunt utilizate pentru a indica semantica și schimbul de informații.
• Simplitatea unei interfețe uniforme
• Modificabilitatea componentelor pentru a răspunde nevoilor în schimbare (chiar și în timp
ce aplicația rulează )
• Vizibilitatea comunicării între componente prin intermediul a genților de servicii
• Portabilitatea componentelor prin mutarea codului de program cu datele aferente
• Fiabilitatea este rezistența la defecțiuni la nivelul sistemului în prezența unor defecțiuni în
componente, conectori sau date [20]

2.4.3 Modelul c lient-server

Primele const rângeri adăugate acestui stil hibrid sunt cele ale stilului arhitectural client –
server. Separarea preocupărilor este principiul din spatele constrângerilor client -server. Prin
separarea preocupărilor legat e de interfața cu utilizatorul de problemele de stocare a datelor,
îmbunătățim portabilitatea interfeței cu utilizatorul pe mai multe platforme și se îmbunătățește
scalabilitatea prin simplificarea componentelor serverului. Poate că cel mai semnificativ pe ntru
web este totuși faptul că separarea permite componentelor să evolueze independent, sprijinind
astfel cerința pe scară largă pe internet a mai multor domenii organizaționale. [20]
Modelul client -server este o structură dis tribuită a aplicațiilor care împarte sarcini de
lucru între furnizorii unei resurse sau servicii, numite servere și solicitanți de servicii, numiți
clienți. Deseori, clienții și serverele comunică printr -o rețea de calculatoare pe hardware separat,
dar atâ t clientul, cât și serverul pot locui în același sistem. O gazdă de server rulează unul sau mai
multe programe server care împărtășesc resursele lor clienților. Un client nu împărtășește nici una
dintre resursele sale, ci solicită o funcție de conținut sau de serviciu a unui server. Prin urmare,
clienții inițiază sesiuni de comunicare cu servere care așteaptă cererile primite. Exemple de
aplicații informatice care utilizează modelul client -server sunt E -mail, imprimare în rețea și World
Wide Web. [21]

34
Caracteristica client -server descrie relația programelor care cooperează într -o aplicație.
Componenta server oferă o funcție sau un serviciu unui a sau mai multor clienți, care inițiază cereri
pentru astfel de servicii. [21]
Serverele sunt clasificate după serviciile pe care le furnizează. De exemplu, un server
web servește pagini web și un server de fișiere servește fișiere de calculator. O resursă partajată
poate fi orice software și componente electro nice ale computerului serverului, de la programe și
date la procesoare și dispozitive de stocare. Partajarea resurselor unui server constituie un serviciu.
Indiferent dacă un computer este un client, un server sau ambele, este determinat de natura
aplicaț iei care necesită funcțiile de serviciu. De exemplu, un singur computer poate rula serverul
și softul de fișiere al serverului pentru a pune la dispoziție diferite date clienților care
transmit diferite cereri la server. Software -ul clientului poate comun ica, de asemenea, cu software –
ul de tip server în cadrul aceluiași computer. Comunicarea între servere, cum ar fi sincronizarea
datelor, este uneori numită comunicare inter -server sau server -to-server. [21]
În general, un serv iciu este o abstractizare a resurselor de calcul și un client nu trebuie să
se preocupe cu modul în care serverul efectuează în timp ce îndeplinește cererea și transmite
răspunsul. Clientul trebuie doar să înțeleagă răspunsul bazat pe protocolul bine cunos cut al
aplicației, adică conținutul și formatarea datelor pentru serviciul solicitat. [21]
Clienții și serverele fac schimb de mesaje într -un model de mesagerie cerere -răspuns.
Clientul trimite o solicitare, iar serverul retur nează un răspuns. Acest schimb de mesaje este un
exemplu de comunicare între procese. Pentru a comunica, computerele treb uie să aibă un limbaj
comun și trebuie să respecte reguli, astfel încât atât clientul, cât și serverul să știe ce să aștepte.
Limbajul și regulile de comunicare sunt definite într -un protocol de comunicații. Toate
protocoalele client -server funcționează în stratul de aplicație. Protocolul stratului de aplicație
definește tiparele de bază ale dialogului. Pentru a formaliza și mai mult schi mbul de date, serverul
poate implementa o interfață de programare a aplicațiilor (API). API este un strat de abstractizare
pentru accesarea unui serviciu. Prin limitarea comunicării la un anumit format de conținut,
facilitează analiza. Prin abstractizarea accesului, facilitează schimbul de date între platforme. [21]
Un server poate primi solicitări de la mai mulți clienți distinși într -o perioadă scurtă de
timp. Un computer poate efectua numai un număr limitat de sarcini în ori ce moment și se bazează
pe un sistem de planificare pentru a acorda prioritate cererilor primite de la clienți pentru a le
acomoda. Pentru a preveni abuzurile și a maximiza disponibilitatea, software -ul serverului poate
limita disponibilitatea clienților. Atacuri le serviciilor sunt concepute pentru a exploata obligația
unui server de a procesa cererile prin supraîncărcarea acestuia cu rate excesive de solicitare. [21]

35

2.4.4 Formatul JSON

JSON (JavaScript Object Notation) este un format ușor de schimb de date. Este ușor pentru
oameni să citească și să scrie. Este ușor pentru mașini să parseze și să genereze. Se bazează pe un
subset al limb ajului de programare JavaScript . JSON este un format t ext complet independent de
limba j, dar utilizează convenții care sunt familiare p rogramatorilor familiei de limbaje C, inclu siv
C ++, C #, Java, JavaScript, Perl, Python și multe altele. Aceste proprietăți fac din JSON un limbaj
ideal de schimb de date. [22]

JSON este construit pe două structuri:
• O colecție de perechi de nume / valoare. În diverse limbaje, acest lucru este realizat ca un
obiect, record, struct, dicționar, tabelă hash, listă cu chei sau matrice asociativă.
• O listă ordonată de valori. În major itatea limbajelor , acest lucru este realizat ca o matrice,
vector, listă sau secvență. [22]
Acestea sunt structuri de date universale. Practic, toate limbajele de programare moderne
le susțin într -o formă sau alta. Are sens că un format de date care este interschimbabil cu limbajele
de programare să se bazează, de asemenea, pe aceste structuri. [22]

În JSON, acestea pot avea următoarele forme:
• Un obiect , care este un set neordonat de perechi de nu me / valoare. Un obiect începe cu
{ (acoladă deschisă la stânga ) și se termină cu } (acoladă închisă la dreapta ). Fiecare nume
este urmat de : (două puncte ) și perechile nume / valoare sunt separate prin , (virgulă). Un
exemplu este vizibil în Figura 2.16.

Figura 2.16 . Obiectul în format JSON . [22]

• Un vector, care este o colecție ordonată de valori. Un vector începe cu [ (paranteză pătrată
deschisă la stânga) și se termină cu ] (paranteză pătrată închisă la dreapta ). Valorile sunt
separate prin , (virgulă). Un exemplu este vizibil în Figura 2.17.

36

Figura 2.17 . Vectorul în format JSON . [22]

• O valoare poate fi un șir între ghilimele duble, un număr, adevărat sau fals, nul l, un obiect
sau un vector. Aceste structuri pot fi imbricate. Un exemplu este vizibil în Figura 2.18.

Figura 2.18 . O valoare în format JSON . [22]

• Un string, care este o secvență de caractere de zero sau ma i multe caractere Unicode,
înfășurate în ghilimele duble, utilizând escape -uri de tip backslash . Un caracter este
reprezentat ca string de dimensiune un caracter . Un string în JSON este foarte asemănător
unui string din C sau Java. Un exemplu este vizibil în Figura 2.19.

37

Figura 2.19 . String în format JSON . [22]

• Un număr , care este foarte asemănător unui număr din C sau Java, cu excepția faptului că
nu se utilizează formatele octale sau hexazecima le. Un exemplu este vizibil în Figura 2.20.
[22]

Figura 2.20 . Număr în format JSON . [22]

38
2.5 Baze de date MySQL

2.5.1 Prezentare generală

MySQL este un sistem de gestionare a b azelor de date relaționale open -source
(RDBMS). Numele este o combinație între "My", numele fiicei cofondatorului Michael Widenius
și "SQL", abrevierea pentru Language Structured Query. Proiectul de dezvoltare MySQL și -a făcut
disponibil codul sursă în ter menii Licenței Publice Generale GNU, precum și în baza a numeroase
acorduri de proprietate. MySQL a fost deținut și sponsorizat de o singură firmă cu scop lucrativ,
compania suedeză MySQL AB, deținută acum de Oracle Corporation. Pentru uz propriu, sunt
disponibile mai multe ediții plătite și oferă funcționalități suplimentare. [23]
MySQL este o componentă centrală a pachetului LAMP open -source pentru aplicații
web. LAMP este un acronim pentru "Linux, Apache, MySQL, Perl / PHP / Python". Aplicațiile
care utilizează baza de date MySQL includ: TYPO3, MODx, Joomla, WordPress, phpBB, MyBB
și Drupal. MySQL este, de asemenea, utilizat în numeroase site -uri de înaltă profil, inclusiv Google
(deși nu pentru căutări), Facebook, Twitter, F lickr și YouTube. [23]
MySQL este scris în C și C ++. Parserul său SQL este scris în yacc, dar utilizează un
analizor lexical de origine. MySQL funcționează pe multe platforme de sistem, inclusiv AIX,
BSDi, FreeBSD, HP -UX, eC omStation, i5 / OS, IRIX, Linux, MacOS, Microsoft Windows,
NetBSD, Novell NetWare, OpenBSD, OpenSolaris, OS / 2 Warp, QNX, Oracle Solaris, Symbian,
SunOS, SCO OpenServer, SCO UnixWare, Sanos și Tru64. Există, de asemenea, un port de
MySQL la OpenVMS. [23]
Software -ul de servere MySQL în sine și bibliotecile clienților utilizează distribuția cu
licență dublă. Acestea sunt oferite în versiunea 2 GPL, începând cu 28 iunie 2000 (care a fost
extinsă în 2009 cu o excepție de licență FLOSS) sau pentru a utiliza o licență de proprietate. [23]
Sprijin poate fi obținut din manualul oficial. Suportul gratuit este disponibil în diferite
canale și forumuri IRC. Oracle oferă suport plătit prin intermediul produs elor sale MySQL
Enterprise. Acestea diferă în ceea ce privește domeniul serviciilor și prețurile. În plus, există o
serie de organizații terțe care oferă asistență și servicii, inclusiv MariaDB și Percona. [23]
MySQL a primit recenzii pozitive, iar recenzenții au observat că aceasta "se comportă
extrem de bine în cazul mediu" și că "interfața pentru dezvoltatori este acolo, iar documentația (ca
să nu mai vorbim de feedback -ul în lumea reală prin intermediul site -urilor Web și a ltele asemenea)
este foarte bună ". De asemenea, a fost testat pentru a f i un "server de baze de date SQL rapid,
stabil, cu adev ărat multi -user și multi -threaded " . [23]

39
2.5.2 Limitări

Atunci când se utilizează unele moto are de stocare, altele decât cele implicite ale InnoDB,
MySQL nu respectă standardul complet SQL pentru unele dintre funcționalitățile implementate,
inclusiv referințe la chei străine și constrângeri de verificare. [23]
Până l a MySQL 5.7, declanșatoarele sunt limitate la câte unul pe acțiune / sincronizare,
ceea ce înseamnă că cel mult un declanșator poate fi definit ca executat după o operație INSERT
și una înainte de INSERT pe același tabel. Nu pot fi definiți declanșatori pe views. [23]
Funcțiile de bază ale bazei de date MySQL precum UNIX_TIMESTAMP() vor reveni la
0 după 03:14:07 UTC la 19 ianuarie 2038. [23]

2.5.3 Implementare

MySQL poate fi construit și instala t manual din codul sursă, dar este mai frecvent instalat
dintr -un pachet binar dacă nu sunt necesare personalizări speciale. În majoritatea distribuțiilor
Linux, sistemul de gestionare a pachetelor poate descărca și instala MySQL cu un efort minim,
deși es te necesară adesea o configurare suplimentară pentru a ajusta setările de securitate și
optimizare. [23]

Figura 2.21 . Componentele software LAMP . [23]

40

Deși MySQL a început ca o alternativă low-end la bazele de date mai puternice, a evoluat
treptat pentru a susține și nevoile la scară mai largă. Acesta este încă cel mai frecvent utilizat în
implementări single -server pe scară mică sau medie, fie ca o componentă într -o aplicație Web
bazată pe LAMP (ale cărui componente software pot fi remarcate î n Figura 2.21 ), fie ca server de
bază de date autonom. O mare parte din atractivitatea oferit de MySQL provine din simplitatea sa
relativă și ușurința de utilizare, care este permisă de un ecosistem de instrumente open source cum
ar fi phpMyAdmin. În gama medie, MySQL poate fi scalată prin implementarea pe un hardware
mai puternic, cum ar fi un server multiprocesor de capacitate mare. [23]
Există, totuși, limite în ce măsur ă performanța poate fi scalată pe un singur server
("scaling up"), astfel încât pe scalări mai mari, implementările MySQL ("scaling out") multi -server
sunt necesare pentru a oferi performanțe și fiabilitate îmbunătățite. O configurație tipică de tip
high-end poate include o bază de date puternică care gestionează operațiile de scriere a datelor și
este reprodusă mai multor serve re care manipulează toate operațiile de citire. Serverul principal
împinge în mod continuu even imente binlog la serverele conectate , astfel încât, în caz de eșec, un
server poate fi promo vat pentru a deveni noul server principal , minimizând timpul de
nefuncționare. Îmbunătățiri suplimentare în performanță pot fi obținute prin reținerea rezultatelor
din interogările bazei de date din m emorie sau descompunerea unei baze de date în bucăți mai mici
numite shards care pot fi răspândite pe mai multe clustere ale server elor distribuite. [23]

2.5.4 MariaDB

MariaDB este o ramificație dezvoltată în comunitate a si stemului de gestionare a bazelor
de date relaționale MySQL destinat să rămână liber sub GNU GPL. Fiind o ra mificație a unui
sistem software open source, este remarcabil că este condus de dezvoltatorii originali ai MySQL,
care l -au scos din cauza preocupări lor legate de achiziția sa de către Oracle. [23]
Colaboratorii trebuie să -și împărtășească drepturile de autor cu Fundația MariaDB.
MariaDB intenționează să mențină compatibilitate ridicată cu MySQL, asigurând o capacitate de
înlocuire "drop -in" cu echivalența binară a bibliotecii și potrivirea exactă cu API -urile și comenzile
MySQL. Există însă unele diferențe și incompatibilități documentate între versiunile MySQL și
MariaDB, iar unele instrumente pentru interacțiunea cu MySQ L, cum ar fi MySQL Workbench,
nu sunt pe deplin compatibile cu MariaDB. [23]
Acesta include motorul de stocare XtraDB pentru înlocuirea lui InnoDB, precum și un
nou motor de stocare, Aria, care intenționează să fie atât un mo tor tranzacțional, cât și un motor
non-tranzacțional, chiar inclus în viitoarele versiuni ale MySQL. [23]

41
2.5.5 PhpMyAdmin

În ingineria software, o ramificație a unui proiect se întâmplă atunci când dezvoltatorii
iau o cop ie a codului sursă dintr -un singur pachet software și încep să conceapă o dezvoltare
independentă, creând u n software distinct și separat, o versiune nouă (parte terță). Termenul
implică deseori nu doar crearea unei ramuri de dezvoltare, ci și o împărțire în comunitatea
dezvoltatorilor (o formă de schi sm). Un astfel de exemplu este ș i PhpMyAdmin a cărui interfața
poate fi remarcata în Figura 2. 22. [23]

Figura 2.22 . Interfața phpMyAdmin . [24]

PhpMyAdmin este un instrument gratuit și open source scris în PHP destinat să
gestioneze administrarea MySQL cu ajutorul unui browser web. Acesta poate efectua diverse
sarcini, cum ar fi crearea, modificarea sau ștergerea bazelor de date, tabele lor, câmp urilor sau
rânduri lor, executarea instrucțiunilor SQL, sau gestionarea utilizatorilor și a permisiunilor.
Software -ul, disponibil în 78 de limbi, este menținut de Proiectul phpMyAdmin. [23]
Acesta poate importa date din CSV și SQL și poate transforma datele stocate în orice
format utilizând un set de funcții predefinite, cum ar fi afișarea datelor BLOB ca imagini sau link –
uri de descărcare. [23]

42
Capitolul 3. Prezentarea soluției

3.1 Descrierea ar hitecturii și modulele funcționale ale soluției

Soluția prezentată sub numele de ICare funcționează pe baza unei arhitecturi de tipul client –
server , astfel se întâlnesc două entități funcționale c are stau la baza transferului și manipulării
datelor, serv erul și clientul. Aceste entit ăți se află într -o strânsă relație de colaborare, fiind
dependente una de cealaltă, clienții nu pot funcționa fără server, iar serverul nu are nici o
întrebuințare fără cl ienți.
Conform celor spuse mai sus , în Figura 3.1 se p oate remarca cu m funcționează un astfel
de sistem caracterizat de modelul client server, în cazul soluției ICare se remarcă faptul că prin
intermediul internetului se asigură o conexiune cu serverul web, clienții fiind de doua tipuri, de tip
utilizator, sau de tip medic, în ambele cazuri fiind posibil transferul de date către server prin
intermediul cererilor și transferul de date de la server prin intermediul răspunsurilor.

Figura 3.1 . Exemplu model client -server . [21]

43
În cadrul soluției proiectului ICare se remarcă existența a patru module sau componente de
bază care stau la baza funcționalității soluției propuse, acestea fiind :
• O bază de date de tip MySQL în care se regăsesc tabelele care conțin informațiil e
vehicula te de către server cl ienților
• O aplicație web, sub formă de server web, bazată pe servlet -uri care răspund la
cereri de tipul HTTP și transmit mai departe răspunsuri sub forma de JSON
• O aplicație Android, de tip client pentru utilizatorii normali, care ben eficiază de
serviciile medicale puse la dispoziție, capabilă să insereze și să gestioneze date
• O aplicație Android, de tip client pentru medicii specialiști, cei care prestează
serviciile medicale pentru utilizatori, având acces la datele lor medicale

Baza de date atașată serverului web este de tip MySQL și are drept scop stocarea datelor
medicale prelevate de către utilizatori pentru a le pune la dispoziția medicilor specialiști cu scopul
de a remedia și gestiona problemele și neplăcerile care pericliteaz ă sănătatea utilizatorilor.
Serverul are scopul de a vehicula informațiile cerute de către clienți pe baza unor cereri de
tip HTTP, acest server este de tip web și este bazat pe servlet -uri care respectă principiile de
funcționare ale arhitecturii REST. Astfel pentru fiecare tip de cerere primită de la clienți, serverul
are atașat un servlet dedicat, capabil să răspundă solicitării de tipul HTTP primită de la clienți și
să ofere în consecința informațiile cerute prin răspunsuri de tip JSON, respectând arhi tectura REST
(Reprezentațio nal state transfer sau RESTful Web S ervices).
Aplicația Android destinată utilizatorilor normali care beneficiază de serviciile medicale,
este în sine un client care se bazează pe comunicația cu serverul web pus la dispoziție pe ntru a
putea gestiona și manipula datele medicale necesare, astfel cu ajutorul cererilor de tip HTTP
trimise către server, poate primi de la acesta sub forma de JSON informațiile pentru a putea
gestiona datele utilizatorilor, precum și p entru citirea și sc rierea în baz a de date.
Aplicația Android destinată medicilor specialiști care prestează servi cii medicale pentru
utilizatori, este în sine tot cu client și este foarte asemănătoare cu aplicația Android destinată
utilizatorilor, deoarece folosește aceeași logică și principii de funcționare, adică se bazează tot pe
cereri de tip HTTP pentru a putea furniza și primi date din baza de date prin intermediul serverului
web dedicat, astfel răspunsurile primite care conțin datele medicale ale utilizatorilor sunt
structurate tot în format JSON.

44

3.1 Baza de date

Baza de date utilizată de către proiectul ICare este de tip MySQL, aceasta are drept scop
stocarea informațiilor provenite de la aplicațiile Android de tip client, prin intermediul serverului
web. Si ngura posibilitate de acces în cadrul bazei de date este prin intermediul serverulu i web
dedicat, pentru a preveni orice fel de probleme sau atacuri rău intenționate care ar putea să dăuneze
integrității acesteia, precum și împiedicarea furtului sau corupe rii datelor existente.
Astfel aplicațiile Android de tip client nu pot interacț iona în mod direct cu baza de date, ci
doar prin intermediul serverului web, care se asigură că datele primite și transmise sunt pentru
utilizatori autorizați, acest lucru nu l e permite utilizatorilor să comunice în mod direct cu baza de
date, din motive de securitate.
Structura completă a bazei de date utilizată în cadrul proiectului ICare este vizibilă în
Figura 3.2. În acea figură se pot observa toate t abele, inclusiv câmpu rile și tipul lor, dar mai ales
se remarcă legăturile dintre ele.

Figura 3.2 . Struc tura bazei de date .

45
Baza de date utilizată conține un număr considerabil de tabele utilizate pentru a stoca datele
prelevate de aplicațiile Android d e tip client , acestea conțin toate câmpurile necesare pentru o
stocare cât mai optimă și mai sigură . Aceste tabele precum și întreaga lor funcționalitate urmează
să fie explicate în paragrafele următoare.
Tabelul us ers este unu l dintre cele mai important e din cadrul bazei de date, întrucât el
conține datele personale, precum și datele necesare pentr u logare ale tuturor utilizatorilor aplicației
Android destinată lor. Datele sunt introduse ai ci prin utilizarea opțiunii de î nregistrare din cadrul
aplicației Android, acestea fiind transmise bazei de date prin intermediul serverului web dedicat.
Acest tabel stă la baza mai multor legături între tabele, prin intermediul câmpului id_users, pe care
se bazează multiple chei străine.
Acest tabel are următoarele câ mpuri :
• id_users este un câmp de tip int, precum și cheia primară a tabelului, în cadrul căruia se
regăsesc identificatorii unici (ID) ai tuturor utilizatorilor, aceștia sunt inserați automat în
ordine crescătoare prin intermediul opțiunii auto_increment, a tunci când un utilizator își
creează un cont nou
• first_name este un câmp de tip text ce conține prenumele utilizatorilor înregistrați
• last_name este un câmp de tip text ce conține numele de familie ale utilizatorilor înregistrați
• gender este un câmp de ti p varchar de dimensiune maxim 6 caractere ce conține genul
utilizatorilor, acesta este predefinit și poate fi ”male” pentru persoanele de sex masculin
și ”female” pentru persoanele de sex feminin
• date_of_birth este un câmp de tip date ce conține datele de naștere ale utilizatorilor
• phone_number este un câmp de tip varchar de maxim 10 caractere ce conține numerele de
telefon ale utilizatorilor
• email, este un câmp de tip text ce conține adresele de email ale utilizatorilor, acest câmp
este foarte important d eoarece pe baza valorii lui se poate face logarea utilizatorilor în
aplicația Android destinată lor , identificatorul contului fiind dat de adresa de email a
utilizatorilor
• password este un câmp de tip text ce conține parolele conturilor utilizatorilor , imp ortanța
acestui câmp este majoră, deoarece el trebuie verificat de fiecare dată când se încearcă o
autentificare de către utilizatori

Tabelul doctors este unul crucial pentru baza de date, deoarece acesta conține toate datele
personale ale medicilor spec ialiști ce prestează servicii medicale pentru utilizatorii sistemului, tot
aici se regăsesc și datele necesare pentru logarea în cadrul conturilor lor. Aceste date sunt introduse
în baza de date prin intermediul serverului web, care primește datele prin op țiunea de înregistrare
disponibilă în aplicația Android dedicată medicilor. Acest tabel stă la baza mai multor legături
între tabele prin intermediul câmpului id_doctor, pe care se bazează multiple chei străine.

46
Acest tabel are următoarele câmpuri :
• id_do ctor este un câmp de tip int, precum și cheia primară a tabelului, în cadrul căruia se
regăsesc identificatorii unici (ID) ai tutu ror medicilor , aceștia sunt inserați automat în
ordine crescătoare prin intermediul opțiunii auto_increment, atunci când un medic își
creează un cont nou
• first_name este un câmp de tip text ce conține prenumele medicilor înregistrați
• last_name, este un câmp de tip text ce conține numele de familie ale medicilor înregistrați
• gender este un câmp de tip varchar de dimensiune maxim 6 caractere ce conține genul
medicilor, aces ta este predefinit și poate fi ”male” pentru medicii de sex masculin
și ”female” pentru medicii de sex feminin
• date_of_birth este un câmp de tip date ce conține datele de naștere ale medicilor
• specializațion este un câmp de tip text care conține specializările medicale ale medicilor
• phone_number este un câmp de tip varchar de maxim 10 caractere ce conține numerele de
telefon ale medicilor
• email, este un câmp de tip text ce conține adresele de email ale medicilor, acest câmp este
foarte important deoarece pe baza valorii lui se poate face logarea medicilor în aplicația
Android destinată lor, identificatorul contului fiind dat de adresa de email a medicilor
• password este un câmp de tip text ce conține parolele contur ilor medicilor, importanța
acestui câmp este majoră, deoarece el trebuie verificat de fiecare dată când se încearcă o
autentificare de către medici

Tabelul drugs este unul dintre cele mai importante tabele din cadrul bazei de date, acesta
conține informa țiile legate de medicamente, aici se regăsesc în mod simplificat și bine organizat
conținutul prospectelor medicamentelor, precum și alte informații explicative pentru utilizatori
pentru a permite consumul în siguranță și limitarea posibilității de apariți e a efectelor secundare în
cadrul programelor de medicamentație. Acest tabel stă la baza unor legături cu alte tabele cu ajutor
câmpului id_drug pe care se bazează unele chei străine.
Acest tabel are următoarele câmpuri :
• id_drug este un câmp de tip int, p recum și cheia primară a tabelului, în cadrul căruia se
regăsesc identificatorii unici (ID) ai tuturor medicamentelor, aceștia sunt inserați automat
în ordine crescătoare prin intermediul opțiunii auto_increment, atunci când un medicament
este inserat în t abel
• name este un câmp de tip text, ce conține numele medicamentelor
• generic_name este un câmp de tip text, ce conține numele generice ale medicamentelor
• brand_name este un câmp de tip text, ce conține numele date de unele companii
farmaceutice aceluiași m edicament
• what_is este un câmp de tip text, ce conține informații legate de scopurile medicamentelor

47
• important_information este un câmp de tip text, ce conține informații importante despre
medicamente
• before_taking este un câmp de tip text, ce conține info rmații esențiale pentru utilizatori cu
privire la lucruri de care trebuie ținut cont înainte de a lua medicamentele respective
• how_to_take este un câmp de tip text, ce conține informații legate de modul de administrare
al medicamentelor
• dosing_information este un câmp de tip text, ce conține informații legate de numărul și
cantitatea dozelor ale medicamentelor ce se pot luat la un moment dat
• miss_a_dose este un câmp de tip text, ce conține informații legate de posibilele
inconveniente în cazul în care se sa r anumite doze ale medicamentelor
• overdose este un câmp de tip text, ce conține informații legate de posibilele probleme și
efecte secundare în cazul în care se administrează doze prea mari ale medicamentelor
• avoid_while_taking este un câmp de tip text, ce conține informații legate de substanțele ce
trebuie evitate în perioada în care se asimilează medicamentele
• side_effects este un câmp de tip text, ce conține informații legate de posibilele efecte
secundare care pot apărea în urma administrării medicament elor
• other_drugs este un câmp de tip text, ce conține informații legate de posibilele probleme și
efecte secundare în cazul în care se asimilează și alte medicamente în perioada în care se
asimilează un anumit medicament

Tabelul symptoms are o importanță deosebit în carul bazei de date, deoarece în cadrul
acestui tabel se introduc datele legate de simptomele utilizatorilor, aici apar problemele
întâmpinate de către utilizatori în cadrul programelor de medicamentație și nutriție, precum și
evenimente neplă cute sau efecte secundare apărute. Acest tabel este legat de tabelul users prin
intermediul cheii străine date de câmpul id_user al acestui tabel .
Acest tabel are următoarele câmpuri :
• id_symptom este un câmp de tip int, precum și cheia primară a tabelului , în cadrul căruia
se regăsesc identificatorii unici (ID) ai tuturor simptomelor întâmpinate de utilizatori,
aceștia sunt inserați automat în ordi ne crescătoare prin intermediul opțiunii
auto_increment, atunci când un simptom este inserat în tabel de către utilizatori, prin
intermediul serverului web, în cadrul aplicației A ndroid destinate lor
• id_user este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține
identificatorul unic al utilizatorului ce inserează simpt omele
• symptom_da te este un câmp de tip datetime ce conține data și ora la care simptomele s -au
făcut simțite de către utilizatori
• symptom este un câmp de tip text ce conține simptomele inserate de către utilizatori

48
Tabelul measurements își face ușor simțită importanța în cadrul bazei de date, prin faptul
că stochează date referitoare la diferitele măsurători efectuate de către utilizatori, aceste a fiind de
5 tipuri: temperatura corpului mă surată în grade Celsius (°C), înălțimea corpului măsurată în
centimetri (cm), greu tatea corpului măsurată în kilograme (kg), nivelul glicemiei din sânge
măsurat în miligrame per decilitru (mg/dL) și tensiunea arterială măsurată în milimetri coloană de
mercur (mmHg). Acest tabel este legat de tabelul users prin intermediul cheii străine date de
câmpul id_user al acestui tabel.
Acest tabel are următoarele câmpuri :
• id_measurement este un câmp de tip int, precum și cheia primară a tabelului, în cadrul
căruia se regăsesc identificatorii unici (ID) ai tuturor măsurătorilor efectuate de către
utilizatori, aceștia sunt inserați automat în ordine crescătoare prin intermediul opțiunii
auto_increment, atunci când o masurătoare este inserat ă în tabel de către utilizatori, prin
intermediul serverului web, în cadrul aplicației A ndroid destinată utiliz atorilor
• id_user este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține
identificatorul unic al utilizatorului ce inserează măsurătorile
• measurement_date este un câmp de tip datetime ce conține data și ora la care măsurătorile
au fost realizate de către utilizatori
• measuremet_value este un câmp de tip text ce conține măsurătorile, indiferent de tip,
împreună cu unitatea de măsură asociată fiecărui tip, obținute de către utilizatori
• type este un câmp de tip varchar de maxim 15 c aractere ce reține tipul măsurători lor
efectuate de către utilizatori

Tabelul schedule își face simțită utilitate a în cadrul bazei de date, prin faptul că stochează
informațiile legate de programul de nutriție, mai exact orele meselor principale ale zile i, pentru a
asigura echilibrul optim între mese, aceste informații fiind transmite de către utilizatori pri n
aplicația Android dedicată , facilitând funcționarea unui manager de notificări, care transmite
notificări utilizatorilor atun ci când este timpul să mănânce . Acest tabel este legat de tabelul users
prin intermediul cheii străine date de câmpul id_user al acestui tabel.
Acest tabel are următoarele câmpuri :
• id_schedule este un câmp de tip int, precum și cheia primară a tabelului, în cadrul căruia
se re găsesc identificatorii unici (ID) ai tuturor orelor la care sunt programate mesele
principale ale zilei, aceștia sunt inserați automat în ordine crescătoare prin intermediul
opțiunii auto_increment, atunci când o oră este inserată în tabel de către utiliza tori, prin
intermediul serverului web, în cadrul aplicației Android destinate lor
• id_user este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține
identificatorul unic al utilizatorului ce inserează orele meselor principale ale zilei
• clock este un câmp de tip time ce conține orele la care sunt programate mesele principale
ale zilei de către utilizatori

49
• type este un câmp de tip varchar de maxim 9 caractere ce reține tipul meselor principale
ale zilei , acestea având posibilitatea d e a fi : breakfast (mic dejun), lunch (prânz) și dinner
(cină)
• enabled este u n câmp de tip varchar de maxim 3 caractere, care poate avea valorile yes or
no, acestea fiind setate de către utilizatori în cadrul aplicației Android dedicată lor prin
activarea respectiv dezactivarea alertelor pentru mesele respective

Tabelul diets este printre cele mai importante tabele din cadrul bazei de date, acesta conține
alimentele recomandate și alimentele interzise pe care utilizatorii necesită să le consume sau nu,
datele fiind introduse de către medici pentru utilizatorii în cauză prin intermediul aplicației android
destinată medicilor și pot fi vizualizate de către utilizatori prin intermediul aplicației Android
destinată utilizatorilor. Acest tabel este legat de tab elul users prin intermediul cheii străine date de
câmpul id_user al acestui tabel, precum și de tabelul doctors prin intermediul cheii străine date de
câmpul id_doctor al acestui tabel.
Acest tabel are următoarele câmpuri :
• id_diet este un câmp de tip int, precum și cheia primară a tabelului, în cadrul căruia se
regăsesc identificatorii unici (ID) ai tuturor alimentelor din cadrul dietelor concepute de
către medici pentru utilizatori, aceștia sunt inserați automat în ordine crescătoare prin
intermediul opți unii auto_increment, atunci când un aliment, rețetă sau dietă se inserează
în tabel de către medici pentru utilizatori, prin intermediul serverului web, în cadrul
aplicației Android destinate lor
• id_doctor este un câmp de tip int, precum și cheie străină î n cadrul acestui tabel, ce conține
identificatorul unic al medicului ce inserează alimentele din cadrul dietelor concepute
pentru utilizatori
• id_user este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține
identificatorul unic al utilizatorului ce beneficiază de dietele propuse de către medici
• item este un câmp de tip text ce conține alimentele dietelor inserate de către medici
• type este un câmp de tip varchar de maxim 4 caractere ce reține tipul alimentelo r din cadrul
dietelor, valoarea acestuia este predefinită având posibilitatea de a fi good în cazul unui
aliment sau diete benefice și bad în cazul unui aliment sau diete nepotrivite

Tabelul agreements are un rol crucial de o importanță maximă in cadrul bazei de date,
acesta se ocupă de asigurarea accesului medicilor la datele utilizatorilor, astfel în acest tabel se
regăsesc acordurile dintre medici și utilizatori, un medic nu poate să vizualizeze absolut nici o
informație personala a utilizatorilor, fără ca aceștia să își de a acordul, acord ce poate fi anulat și
de către medici și de către utilizatori. Cu alte cuvinte medicii trimit cereri către utilizatori, iar dacă
aceștia le acceptă, adică își dau acordul, doar atunci medici au acces la datele utilizatorilor, în cazul
în care cererea este respinsă atunci medicii nu primesc acces la datele utilizatorilor.

50
Acest tabel este legat de tabelul users prin intermediul cheii străine date de câmpul id_user
al acestui tabel, precum și de tabelul doctors prin intermediul cheii străin e date de câmpul
id_doctor al acestui tabel.
Acest tabel are următoarele câmpuri :
• id_agreement este un câmp de tip int, precum și cheia primară a tabelului, în cadrul căruia
se regăsesc identificatorii unici (ID) ai acordurilor dintre medici și utilizato ri, aceștia sunt
inserați automat în ordine crescătoare prin intermediul opțiunii auto_increment, atunci
când apar noi cereri trimise de către medici
• id_user este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține
identificator ul unic al utilizatorului care a primit o cerere de la un medic
• id_doctor este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține
identificatorul unic al medicului ce trimite cererea către utilizator
• status este un câmp de tip varchar de maxim 8 caractere ce conține statusul cererii trimise
de către medic către utilizator, acesta este predefinit și poate avea valorile: pending în cazul
în care cerea a fost trimisă către utilizator, dar acesta încă nu a acceptat sau refuzat cerer ea,
accepted în cazul în care cererea a fost acceptată de către utilizator sau rejected în cazul în
care cerea a fost refuzată de către utilizator

Tabelul medication este deosebit de important în cadrul bazei de date, deoarece acesta
conține programele d e medicamentație trimise de către medici utilizatorilor cu scopul de a restaura
starea de bine a pacienților, aici se află medicamentele, dozele , orele la care se necesită
administrarea, date începerii și data termi nării programelor de med icamentație în ca uză. Acest
tabel este legat de tabelul users prin intermediul cheii străine date de câmpul id_user al acestui
tabel, de tabelul doctors prin intermediul cheii străine date de câmpul id_doctor al acestui tabel,
precum și de tabelul drugs prin intermediul ch eii străine date de câmpul id_drug al acestui tabel.
Acest tabel are următoarele câmpuri :
• id_medication este un câmp de tip int, precum și cheia primară a tabelului, în cadrul căruia
se regăsesc identificatorii unici (ID) ai programelor de medicamentație transmise de către
medici utilizatorilor , aceștia sunt inserați automat în ordine crescătoare prin intermediul
opțiunii auto_increment, atunci când apar programe de medicamentație noi transmise de
către medici
• id_user este un câmp de tip int, precum și che ie străină în cadrul acestui tabel, ce conține
identificatorul unic al utilizatorului căruia au fost transmise programele de medicamentație
de către medici
• id_doctor este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține
ident ificatorul unic al medicului ce transmise programele de medicamentație către
utilizatori

51
• id_drug este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține
identi ficatorul unic al medicamentelor din cadrul programelor de medicamen tație
transmise de către medici
• time este câmp de tip time ce conține orele la care trebuie luate medicamentele din cadrul
programelor de medicamentație
• start_date este câmp de tip date ce conține data la care este necesară începerea programulu i
de medica mentație
• end_date este câmp de tip date ce conține data la care se sfârș ește programul de
medicamentație
• medication_quantity este un câmp de tip int ce conține dozajul medicamentelor din cadrul
programelor de medicamentație
• active este câmp de tip varchar de maxim 3 caractere ce conține informații legate de
activarea sau dezactivarea programelor de medicamentație de către utilizatori, aceste valori
sunt predefinite și pot fi yes în cazul în care utilizatorul activează programul de
medicamentație sau no în c azul în care utilizatorul dezactivează programul de
medicamentație

Tabelul inventory își dovedește utilitatea în cadrul bazei de date prin stocarea informațiilor
utilizatorilor legate de tipul de medicamente pe care le dețin, precum cantitatea acestora, astfel se
realizează o gestiune eficientă a medicamentelor deținute de către utilizatori, oferind posibilitatea
de vizualizare a lor de către medici cu scopul prescrierii mai multor medicamente în caz că este
nevoie. Acest tabel este legat de tabelul users prin intermediul cheii străine date de câmpul id_user
al acestui tabel, precum și de tabelul drugs prin intermediul cheii străine date de câmpul id_drug
al acestui tabel.
Acest tabel are următoarele câmpuri :
• id_entry este un câmp de tip int, precum și cheia primară a tabelului, în cadrul căruia se
regăsesc identificatorii unici (ID) ai medicamentelor deținute de către utilizatori, aceștia
sunt inserați automat în ordine crescătoare prin intermediul opțiunii auto_increment, atunci
când utilizatorii achiz iționează medicamente noi
• id_user este un câmp de tip int, precum și cheie străină în cadrul acestui tabel, ce conține
identificatorul unic al utilizatorului care inserează medicamentele
• id_drug este un câmp de tip int, precum și cheie străină în cadrul ac estui tabel, ce conține
identificatorul unic al medicamentului introdus de către utilizator
• quantity este un câmp de tip int ce conține cantitatea medicamentelor introduse de către
utilizator

52
Tabelul quotes are drept scop stocarea zilnică de către admin istratori a unor citate
motivaționale care apar ca primă pagină atât în aplicația android destinată utilizatorilor cât și în
cea destinată medicilor cu scopul de a motiva și bine dispune atât utilizatorii cât și medicii pentru
o productivitate cât mai cres cută. Acest tabel nu are chei străine astfel nu se află în legătură cu alte
tabele, fiind singurul de acest tip în cadrul bazei de date, deoarece nu depinde de alte tabele.
Acest tabel are următoarele câmpuri :
• id este un câmp de tip int, precum și cheia p rimară a tabelului, în cadrul căruia se regăsesc
identificatorii unici (ID) ai citatelor introduse de către administratori, aceștia sunt inserați
automat în ordine crescătoare prin intermediul opțiunii auto_increment, atunci când
administratorii inserează un citat nou
• quote este un câmp de tip text care conține textul citatelor introduse
• author este un câmp de tip text care conține autorii citatelor introduse

3.2 Serverul web

Serverul web implementat în cadrul proiectului ICare cu scopul de a superviza accesul la
baza de date de către aplicațiile Android dedicate uti lizatorilor și medicilor, este u na dintre
componentele de bază deoarece pe baza lui se pot vehicula datele necesare gestiunii programelor
de medicamentație și nutriție.
Acesta stă la dispozi ția aplicațiilor Android de tip client care trimit cereri de tip HTTP către
server, așteptând ca serverul să le trimită răspunsuri sub format JSON cu informațiile cerute, astfel
apare în relief modelul client -server pe care este dispus proiectul ICare. Din acest punct de vedere
se remarcă o delimitare clară între partea de server, în cazul soluției propuse fiind utilizat un server
web și partea de client, clienții soluției prezente fiind reprezentați de aplicații Android dedicate
atât utilizatorilor cât și medicilor.
Serverul web este bazat pe principiile de funcționare ale arhitecturii REST, resursele
utilizate fiind informațiile stocate în baza de date, folosind protocolul HTTP pentru funcționare ,
acceptând de la clienți cereri de tip HTTP, returnând mesa je de tip JSON furnizând astfel datele și
resursele solicitate de către clienți. Servlet -urile, spre deosebire de serviciile web, se află cu un
nivel de abstractizare mai jos , se comportă similar și extind capabilitățile arhitecturii REST întrucât
dețin mecanisme de mapare asemănătoare , pot gestiona cu ușurință cereri de tip HTTP și pot folosi
JSON sau XML pentru răspunsuri (obligatoriu în cadrul arhitecturii REST ).
Componenta funcțională a serverului web este reprezentată de servlet. Serverul web pune
la dispoziție o serie de servle -uri dedicate pentru fiecare tip de cerere întâmpinată de la aplicațiile
Android de tip client. Aceste servlet -uri sunt de tip HTTP, clasa derivată pe care se bazează clasele
din cadrul serverului web este Http Servlet, care la rândul ei moștenește interfața Servlet.

53

Clasa HttpServlet face parte din librăria javax.servlet.http, aceasta funcționând pe baza
cererilor de tip HTTP transmise de către clienți pe care le primește prin intermediul unui obiect de
tip HttpServletReque st disponibil în cadrul aceleiaș i librării, transmiterea mesajelor către clienți
realizându -se pe baza unui obiect de tip HttpServletResponse, disponibil în cadrul aceleiași librării.
Serverul web este în sine o aplicație web bazată pe J ava, folosind Java EE (Java Enterprise
Edition), platformă ce oferă un mediu API și runtime pentru dezvoltarea și funcționarea aplicațiilor
de rețea la scară largă, multi -nivel, scalabile , fiabile și securizate. Acesta este pus în execuție cu
ajutorul lui Apache Tomcat, d eseori denumit Tomcat Server, care este un c ontainer Java Servlet
de tip open source dezvoltat de Apache Software Foundation (ASF). Tomcat implementează mai
multe specificații Java EE, inclusiv Java Servlet, Pagini JavaServer (JSP), Java EL și WebSocket
și ofer ă un mediu de server HTTP "pur Java" în care poate rula codul Java.
Pentru a putea accesa un servlet prin intermediul unei cereri de la clienți, acesta trebuie să
dețină o adresă la care să se poată referi cererea, această adresă este asignată servlet -ului prin
intermediul unui document XML, web.xml în care aplicația definește relațiile dintre clasele
efective ale servlet -urilor și adresele la care acestea pot fi găsite. În figura 3.3 se poate remarca
cum pentru clasele servlet -urilor se alege un nume pent ru ca mai apoi cu ajutorul acelui nume să
se poată face maparea clasei cu adresa la care poate fi accesată. Astfel pentru clasa de tip
HttpServlet Quote se primește numele servlet -ului ca fiind quoteServlet și prin intermediul acestui
nume se realizează ma parea către adresa /servlet/Quote, același procedeu se realizează și pentru
servletul Symptoms prezent în exemplu, precum și pentru toate celelalte servlet -uri din cadrul
serverului web.

Figura 3.3 . Exemplu mapare servlet .

54

Figu ra 3.4 . Cerere HTTP fără parametri . Figura 3.5 . Cerere HTTP cu parametri .

Servlet -urile utilizate primesc date de la clienți prin cereri sub forma de URL, exemplu în
Figura 3.4, unde se remarcă structura apelului, care conține protocolul http, urmat de adresa IP a
sistemului de calcul care găzduiește serverul (192.168.0.106 în acest caz), portul la care se face
conectarea (8080 în acest caz), urmat de adresa servlet -ului la care a fost asignat (/servlet/Quote).
Acea cerere de tip HTTP din figura 3.4 es te una fără parametri , care nu transmite date către
server, ci do ar așteap tă ca acesta să transmi tă date către client, dar există și posibilitatea de a
transmite date către server pentru a specifica ce date să vehiculeze, în ace st caz este nevoie de
parame tri care se pot specifica la sfârșitul URL -ului cu ajutorul caracterului ?, care delimitează
zona de unde încep parametri, lucru ușor vizibil în Figura 3.5 unde după caracterul ? transmite
parametru cu numele id_user de valoare 3 pentru a oferii informații suplimentare în legătură cu
datele solicitate. Î n cazul în care se transmit mai mulți parametri este nevoie de caracterul & pe
post de separator.
În urma cererilor primite serverul trebuie să proceseze datele cerute, în acest sens în clasa
servlet -ului e ste necesară utilizarea a două metode : doGet și doPost, acestea sunt foarte
asemănătoare cu metodele GET și POST din cadrul limbajului PHP, astfel și aici este mult mai
indicată utilizarea metodei doPost deoarece este cu mult mai sigură decât metoda doGet, datele
transmise în acest fel nefiind vizibile.

Figura 3.6 . Implementarea metodei doPost fără transfer de parametri .

55

Pentru implementarea logicii din spatele servletului se poate remarca în Figura 3.6
implementarea metodei doPost fără a necesita parametri suplimenta ri de la clienți, această metod ă
fiind cea care asigură transferul de informații de la server. În antetul funcției se remarcă cele două
obiecte necesare pentru buna funcționare, request de tip HttpServletRequest și respo nse de tip
HttpServletResponse , se mai semnalează faptul că această metodă poate să genereze excepții de
tip input sau output .
În continuare se setează tipul răspunsului ca fiind de tip text/html, adică conferă
posibilitatea mesajului să conțină text sau cod html, această opțiune fiind și cea mai indicată și cea
mai utilizată, evident în cadrul servlet -urilor utilizate de server, răspunsul este de tip text scris sub
format JSON. Apoi se creează și inițializează un obiect writer de tip PrintWriter care o să fie folosit
la transferul mesajului. Urmează implementarea logi cii în sine, se folosește JDBC pentru accesul
la baza de date, după care se face selecția informațiilor necesare din aceasta, în cazul nostru ultimul
citat, precum și autorul acestuia inserat în baza de date. După selecție se verifică daca au fost
extrase date, în funcție de care se generează raspunsul în format JSON, acest raspuns conține un
status, care poate fi false în cazul în care nu s -au găsit date în baza de date, sau au intervenit
even imente neplăcute, fapt ce generează scrierea unui obiect JSON qoute, în c are valoarea staus
este false, astfel ce semnalează aplicațiilor de tip client faptul că ceva nu a mers bine pentru a putea
oferii mesaje și acțiuni sugestive. Dar în cazul în care in formațiile sunt găsite, valoarea status, a
obiectului JSON quote, devine true, la care se adauză un apt obiect JSON numit description care
o să conțină informațiile cerute, citatul și autorul acestuia.

Figura 3.7. Obiectul JSON transmis în Fi gura 3.6 .

În urma executării metodei din Figura 3.6 mesajul care conține obiectul JSON este vizibil
în Figura 3.7, acolo se remarcă cu ușurință datele transmise, modul și formatul în care au fost
transmise. Obiectul cu numele quote, având valoarea statu s egală cu true, pentru a semnala faptul
că datele au fost găsite și transmise cu succes, precum și obiectul description în care se regăsesc
datele solicitate, citatul și autorul său.

56

Figura 3.8 . Implementarea metodei doPost cu transf er de parametri .

Totuși există ș i posibilitatea transmiterii cererilor împreună cu parametri, precum în Figura
3.8, pentru a putea oferii informații suplimentare în legătură cu ce informații se doresc, sau pentru
a insera, modifica sau șterge date din baza de date. În Figura 3.8 , modul de funcționare este similar
celui din Figura 3.6, însă se remarcă ca și deosebiri faptul că se extrage într -un string numit userId,
prin intermediul obiectului request, cu ajutorul proprietății getParameter(), care solici tă valoarea
parametrului cu numele id_user, trimis de către client. În continuare în mod asemănător se
vehiculează date din baza de date prin intermediul JDBC, doar că de data aceasta datele cerute
sunt dependente de valoarea parametrului transmis. În cadr ul formării obiectului JSON , în cazul
în care datele nu au fost găsite în baza de date obiectul transmis este similar, surpriza fiind însă în
cazul în care datele sunt găsite, deoarece datele sunt introduse într -un vector, din cadrul obiectului
JSON transm is, format în mod dinamic pe măsură ce se parcurg datele preluate din baza de date.
Obiectul JSON transmis conține simptomele, id -urile lor precum și data la care au apărut în funcție
de id -ul utilizatorului trimis ca parametru.
Astfel se transmit multip le înregistrări din baza de date utilizatorilor care solicită acele date
prin intermediul aplicațiilor Android de tip client, furnizând ca și parametru id -ul asignat contului
lor, pentru a putea vedea doar datele personale, nu și ale altor utilizatori, în afară de medicii care
au primit acordul utilizatorilor.

57

Figura 3.9. Obiectul JSON transmis în Figura 3.8 .

În urma execuției metodei din Figura 3.8 se poate remarca în Figura 3.9 obiectul JSON
conținut de răspunsul la ce rea trimisă cu parametru id_user de valoare 3, cu alte cuvinte se
transmite status ul ca fiind true , pentru a semnala că extragerea informațiilor din baza de date s -a
efectual cu succes. Dar se remarcă că în cadrul lui items sunt conținute informațiile ceru te sub
formă de vector , adică simptomele înregistrate de utilizatorul cu id -ul egal cu 3.
În cadrul componentelor serverului web, se remarcă o multitudine de servlet -uri de tip
HttpServlet, pe lângă cele prezentate anterior, care dețin propriile funcționa lități și care permit o
multitudine de operații în vederea răspunderii cererilor solicitate de către utilizatori sau medici,
prin intermediul aplicațiilor Android dedicate pentru nevoile lor.

58
Astfel serverul pune la dispoziție servlet -uri pentru :
• facilitarea logării atât utilizatorilor cât și medic ilor, primind de la aceștia ca ș i parametri
informațiile necesare pentru a se putea loga în cadrul aplicațiil or Android destinate lor,
acesta verificând veridicitatea și corectitudinea informațiilor transmise permițând accesul
în cazul în care sunt corecte , precum și furnizarea datelor pers onale atașate conturilor în
cadrul cărora se face logarea
• a permite înregistrarea de conturi noi, atât de către utilizatori, cât și de către medici, primind
de la aceștia da tele introduse în cadrul aplicațiilor Android ca și parametri, pentru a verifica
corectitudinea și unicitatea datelor necesare, astfel înregistrând în baza de date conturile
valide și unice
• transmiterea citatelor cerute de către aplicații atunci când se autentifică utilizatorii sau
medicii cu scopul de a bine dispune
• transmiterea simptomelor pentru a putea fi vizualizate de către utilizatori și de către medicii
care dețin acorduri cu utilizatorii menite să permită acest lucru , înregistrate d e către
utilizat ori, cu ajutorul para metrului ce conțin e id-ul utilizatorului
• inserarea în baza de date a unor simptome noi resimțite de către utilizatori cu ajutoru l unor
parametri ce conțin id -ul utilizatorului , simptomul întâlnit , data și ora la care și -a făcut
apariț ia
• modificarea unor simptome de către utilizatori, introduse în mod incorect , prin utilizarea ,
unor parametri ce conțin id-ul simptomul care trebuie modificat, precum și noul si mptom
ce urmează să îl înlocuiască pe cel eronat
• ștergerea din baza de date de către utilizatori a unor simptome introduse care sunt incorecte,
inexacte sau care nu mai sunt de actualitate, prin intermediul parametrului ce conțin e id-ul
simptomului ce necesită a fi șters
• transmiterea măsurătorilor pentru a putea fi vizualizate de că tre utilizatori și de către
medicii care dețin acorduri cu utilizatorii menite să permită acest lucru , înregistrate de către
utilizatori, cu ajutorul parametrilor ce conțin id-ul utilizato rului precum și tipul
măsurătorilor cerute (temperatura, înălțimea, greutatea, glicemia sau tensiunea)
• inserarea în baza de date a unor măsurători noi de către utilizatori cu ajutorul unor
parametri ce conțin id -ul utilizatorului, valoarea măsurătorii împreuna cu unitatea de
măsură, data și ora la care s -a efectuat măsur ătoarea, precum și tipul măsurătorii
• modificarea unor măsurători de către utilizatori , care au fost introduse în mod incorect , prin
utilizarea unor parametri ce conțin id -ul măsurătorii ce trebuie modificată , precum și noua
măsurătoare ce urmează să o înl ocuiască pe cea eronată
• ștergerea din baza de date de către utilizatori a unor măsurători introduse care sunt
incorecte , inexacte sau nu mai sunt de actualitate , prin intermediul parametrului ce conțin e
id-ul măsurătorii ce necesită a fi ște arsă

59
• transmiter ea unei liste cu medicamentele aflate în sistem, atât utilizatorilor cât și medicilor
fără a necesita parametri
• transmiterea datelor ce constituie prospectul unui medicament, atât utilizatorilor cât și
medicilor, prin intermediul parametrului ce conține id -ul medicamentului
• transmiterea medicamentelor și cantitatea acestora deținute de către utilizatori, atât
utilizatorilor cât și medicilor care dețin acorduri cu utilizatorii menite să permită acest
lucru, prin intermediul parametrului ce conține id -ul util izatorului
• inserarea de noi medicamente deținute de către utilizatori, precum și cantitatea acestora,
prin intermediul parametrilor ce conțin id -ul utilizatorului, id -ul medicamentului și
cantitatea deținută
• modificarea cantității medicamentelor deținute de către utilizatori, prin intermediul
parametrilor ce conțin id -ul înregistrării din tabel ce urmează să fie modificată și noua
cantitate ce trebuie inserată
• ștergerea medicamentelor deținute de către utilizatori, prin intermediul parametrului ce
conține id-ul înregistrării din tabel ce urmează a fi ștearsă
• transmiterea datelor personale ale utilizatorilor, atât utilizatorilor cât și medicilor care dețin
acorduri cu utilizatorii menite să permită acest lucru
• transmiterea datelor personale ale medicilor, at ât medicilor cât și utilizatorilor care dețin
acorduri cu medicii menite să permită acest lucru
• modificarea datelor personale atât utilizatorilor cât și medicilor, prin intermediul
parametrilor ce conțin datele ce necesită modificări
• transmiterea unui list e cu medicii care dețin acordur i cu utilizatorul care transmite cererea ,
prin intermediul parametrului ce conține id -ul utilizatorului
• transmiterea unui liste cu utilizatorii care dețin acorduri cu medicul care transmite cererea ,
prin intermediul parametr ului ce conține id -ul medicului
• posibilitatea de a transmite de către medici, cereri de acorduri noi între utilizatori și medici
anumitor utilizatori
• posibilitatea de a accepta sau refuza de către utilizator cererile de acorduri noi transmise
de către medi ci acelui utilizator
• inserarea de noi alimente de către medici în cadrul programelor de medicamentație propuse
utilizatorilor, precum și vizualizarea acestora atât de către medicii care le -au transmis, cât
și de către utilizatorii care le -au primit
• inserar ea și modificarea de către utilizatori a unor planuri noi ce privesc orele la care se
transmit notificări în scopul de a respecta mesele principale ale zilei
• inserarea, modificarea și ștergerea de către medici a programelor de medicamentație
conceput e de a ceștia pentru utilizatori , precum și posibi litatea de activare sau dezacti vare
de către utilizatori ale notificărilor generate de aceste programe cu scopul de a respecta
orele la care trebuie luate medicamentele în cauză

60

3.3 Aplicația Android dedicată utilizatorilor

Aplicația Android dedicată utilizatorilor este realizată în Android Studio, mediul de
dezvoltare integrat oficial pentru acest sistem, cu ajutorul limbajului Java prin intermediul căruia
a fost creată întreaga logică și toate funcționalitățile , dar și prin intermediul limbajului XML care
stă la baza creării elementelor vizuale ce țin de design și de interfața cu utilizatorul.
La pornirea aplicației ICare instalată pe un dispozitiv mobil de tip smartphone sau tabletă
pe care rulează sistemul de operare Android, primul lucru afișat este interfața destinată logării,
vizibilă în Figura 3.10, care necesită adresa de email pe baza căreia a fost creată contul, precum și
parola contului, ca în Figura 3.11 . Această interfață grafică poartă numele de Activity, fiind
similară cu ferestrele din alte sisteme. Câmpul în care se introduce adresa de email, permite
inserarea unui string care are ca și format modelul unui adrese de email, adică un set de caractere,
urmate de caracterul @, urmat de alt set de cara ctere care se termină cu caracterul . și în final un
alt set de caractere , în caz contrar câmpul afișează mesaje de avertizare .
Câmpul care reține parola permite inserarea acesteia fără a face vizibile caractere. Există
și posibilitatea vizualizării lor prin utilizarea controlul sub formă de pictogramă din partea dreaptă
al câmpului password. Parola introdusă este validată și necesită un format prestabilit pentru a fi
acceptată, minim 8 caractere, o literă mică, o literă mare, o cifră și cel puțin un cara cter special , în
caz contrar câmpul afișează mesaje de avertizare.

Figura 3.10 . Interfața pentru logare . Figura 3.11 . Datele necesare pentru logare .

61

În cazul în care ambele câmpuri au fost completate corespunzător, se poate începe procesul
de logare prin apăsarea butonului Log In care apelează la un task asincron pentru a transmite o
cerere de autentificare către server cu datele introduse de către utilizator. În cazul în care datele
sunt veridice atunci autentificarea are loc, în c az con trat se afișează un mesaj cores punzător care
specifi că că datele introduse nu sunt c orecte.
Interfața mai pune la dispoziție și posibilitatea de înregistrare a unui utilizator nou prin
apăsarea pe textul “Create a new account ”, care aduce în prin p lan interfață grafică destin ată
înregistrării, vizibilă în F igura 3.12.

Figura 3.12. Interfața pentru înregistrare . Figura 3.13. Mesaje de avertizare .

În cadrul acestei interfețe se pun la dispoziție diferite câmpuri care permit ins erarea datelo r
personale ale utilizatorului cu ajutorul câmpurilor dedicate , prenumele în cadrul câmpului First
Name și numele de familie în cadrul câmpului Last Name , care pot să conțină doar text, acest lucru
fiind verificat. Genul se stabilește prin sel ectarea butonului radio potrivit, Male pentru un utilizator
de genul masculin și Female pentru un utilizator de genul feminin , acestea funcționând după
principiul de excludere mutuală. Data nașterii se stabilește prin alegerea valorii zilei, lunii și anulu i,
din cadrul celor trei obiecte spinner puse la dispoziție. Numărul de telefon poate să conțină doar
cifre, în total 10 caractere, orice altă dimensiune este respinsă cu un mesaj de avertizare, adresa de
email și parola sunt validate în același mod ca și cele din interfața din F igura 3.10.
La apăsarea butonului Register, dacă toate câmpurile sunt introduse și validate cu succes,
se folosește un task asincron care trimite o cerere la server cu datele introduse de c ătre utilizator
ca și parametri. D acă dat ele destinate autentificării sunt veridice și unice atunci contul este creat,

62

dacă nu , se transmite un mesaj de avertizare corespunzător utilizatorului. Dacă nu au fost introduse
toate datele, sau dacă unele date nu sunt validate cu succes atunci se transm it mesaje de avertizare
specifice ca în Figura 3.13.
Dacă în urma cererii de autentificare trimise către server în cazul apăsării butonului Log In
din cadrul interfeței grafice destinate logării din figura 3.10, autentificarea se realizează cu succes,
atunci se primesc datele personale ale utilizatorului printr -un răspuns de tip JSON și se trece la o
altă interfață grafică, cea de bază a aplicației , vizibilă în Figura 3.14 .

Figura 3.14. Interfața principală .

În momentul cre ării interfeței din Figura 3.14 se utilizează un task asincron care face o
cerere către server și primește de la acesta în format JSON citatul zilei, precum și autorul acestuia.
În partea din dreapta sus se remarcă o iconiță sub formă de trei puncte supra puse care demască un
meniu contextual cu o singură opțiune numită Log Out , vizibilă în Figura 3.15 , care are drept scop
delogarea utilizatorului din cadrul aplicației, care o să revină la interfața grafică din Figura 3.10.
Dacă această opțiune este select ată, o să apară o casetă de dialog de confirmare, ca în Figura
3.16, de tipul AlertDialog care pune la dispoziție opțiunea yes, în cazul în care se dorește delogarea
din aplicație, sau opțiune a no care anulează procesul fără a face modificări .

63

Figura 3.15. Opțiunea de Log Out . Figura 3.16 . Confirmare Log Out .

Interfața principală din Figura 3.14 mai pune la dispoziție un alt meniu mult mai complex,
de tip NavigaionDrawler, vizibil în Figura 3.17 și Figura 3.18 , care se face vizib il prin swipe din
partea stângă. Î n cadrul acestuia aflându -se principalele opțiuni și funcționalități pus e la dispoziție
de aplicația ICa re.

Figura 3.17 . Prima parte a meniului . Figura 3.18 . A doua parte a meni ului.

64

Opțiunile prezentate în cadrul meniului sunt create sub formă de fragmente cu ajutorul unui
manager de fragmente. Fragmentele sunt echivalentul conținutului unui fere stre sau interfețe
grafice, un A ctivity este ca un container pentru elementele graf ice pe care le deține, prin fragmente
se poat e schimba doar conținutul unui A ctivity, fără a schimba sau pierde și alte elemente atribuite
lui, cum ar fi bara de sus, sau meniul în sine. Astfel se asigură disponibilitatea meniului indiferent
de conținut in terfeței curente.
În continuare urmează prezentarea fiecărei opțiuni di sponibile din meniu, precum și
întreaga lor funcționalitat e.
Personal Info are drept scop aducerea în prin plan a datelor personale ale utilizatorului care
folosește aplicația , acest ea fiind aduse prin intermediul serverului în momentul în care
autentificarea s -a efectuat cu succes, lucru vizibil în Figura 3.19.

Figura 3.19. Datele personale . Figura 3.20 . Editarea datelor personale .

Butonul Edit are drept scop p ermiterea modificării datelor personale de către utilizatori,
prin apăsarea lui se aduce în prin plan o fereastră , vizibilă în Figura 3.20 , care pune la dispoziț ie
posibilitatea modificării datelor . Dacă se apasă pe opțiunea cancel atunci nu se întâmpla ni ci o
modificare, însă dacă se apasă pe opțiunea ok, se verifică corectitudinea datelor și dacă totul este
corect definit, se utilizează un task asincron care trimite o cerere la server împreună cu datele
modificate pentru a face update în baza de date. Dac ă datele introduse nu sunt corecte atunci se
primesc mesaje corespunzătoare .
Opțiunea Home are drept scop aducerea în prin plan a interfeței grafice din Figura 3. 14
indiferent de locația curentă în cadrul aplicației.

65

Symptoms are drept scop aducerea simp tomelor înregistrate de către utilizator din cadrul
bazei de date, prin intermediul unui task asincron care realizează o cerere către server , primind un
răspuns de tip JSON care conține un vector cu toate simptomele înregistrate de către acesta,
permițând astfel stocarea și gestiunea datelor inserate. Acest l ucru este vizibil în Figura 3.21 , în
care interfața grafică conține un element grafic de tip listă, care găzduiește informațiile aduse.

Figura 3.21 . Lista simptomelor . Figura 3.22 . Inserarea simptomelor .

Figura 3.23. Editare simptomelor . Figura 3.24. Ștergerea simptomelor .

66

Aplicația pune la dispoziție posibilitatea inserării simptomelor prin apăsarea butonului
rotund din stânga jos, cu o iconiță în formă de plus, vizibil în interfața din F igura 3.21, care
deschide o fereastră ca în Figura 3.22, în care se permite inserarea simptomului, ora și data fiind
inserată automat în funcție de ceasul dispozitivului. Se mai pune la dispoziție și editarea datelor
inserate prin apăsarea pe simptomul dorit din listă, care aduce în prin pla n o fereastră de editare ca
în Figura 3.23. În care opțiunile puse la dispoziție sunt : edit care modifică simptomul selectat cu
altul nou introdus în câmpul dedicat, cancel care închide ferea stra fără a face modificări și delete
care are drept scop ște rgerea simptomului inserat. La selectarea lui delete se aduce în prin plan o
altă fereastra, de confirmare a ștergerii ca în Figura 3.24, care prin opțiunea yes realizează ștergerea
simptomului s electat, iar prin opțiunea no închide fereastra fără a face modificări.
Doctors este o altă opțiune din meniul principal, care pune la dispoziție lista cu medi cii
utilizatorului, cărora le -au fost acordat e drepturi de acces la datele utilizatoru lui, de că tre
utilizatorul însăș i, ca în Figura 3.25.

Figura 3.25 . Lista medicilor . Figur a 3.26 . Cerere nouă de la medic .

În cazul unor cereri transmise de medici cu scopul creării unui nou acord cu utilizator ul
care apar în aplicația utilizat orului sub forma unei ferestre care conține datele personale ale
medicului care a transmis cererea, ca în Figura 3.26. Utilizatorul având posibilitatea de a amâna
răspunsul cererii prin opțiunea skip, de a refuza cererea prin opțiunea cancel și de a accept a cererea
prin opțiunea ok. Dacă acesta a acceptat cererea medicului, atunci medicul apare în lista
utilizatorului și acesta primește dreptul de a vedea datele inserate de către utilizator, cu scopul de
a presta servicii medicale.

67

Figu ra 3.27 . Datele medicului . Figur a 3.28 . Apel către medic .

Figur a 3.29 . Ștergerea medicului .

68

La selectarea unui medic din lista disponibilă în interfața grafică din Figura 3.25, se
deschide o fereastra ce conține datele personale ale medicului, ca în Figura 3.27. În această
fereastră sunt disponibile opțiunile : call care aduce în prin plan posibilitatea de a efectua un apel
telefonic către me dicul selectat , ca în Figura 3.28 , cancel care închide fereastra fără a face
modificări și delete care șterge medicul din listă și îi anulează acestuia dreptul de a putea vizualiza
datele introduse de către utilizator. La selectarea opțiunii delete se deschide o fereastă de
confirmare ca în F igura 3.29 cu două opțiuni : no care închide fereastra fără a efectua modificări și
yes care realizează logica din spatele ștergerii medicului din listă .
În cadrul categoriei Measurements din meniului principal, vizibil în Figura 3.17 și Figura
3.18, se remarcă opțiunile : Temperature, Weight, Height, Blood P ressure, Blood Glucose care sunt
realizate pe acel ași principi u ca în cazul opțiunii Symptoms, astfel afișarea, inserarea, modificarea
și ștergerea a temperaturilor, greutăților, înălțimilor, tensiunilor respectiv glicemiilor se realizează
identic ca în ca zul simptomelor , acestea fiind prezentate în continuare .
Opțiunea Temperature aduce în prin plan o listă cu temperaturile corpului înregistrare de
către utilizator, ca în Figura 3.30 . Operațiile de inserare, modificare ș i ștergere a le temperaturilor
se realizează în mod identic ca în cazul simptomelor. Exemplu pentru inserare este disponibil în
Figura 3.31, pentru modificare este disponibil în Figura 3.32 și pentru ștergere este disponibil în
Figura 3.33.

Figura 3.30. Lista temperaturil or. Figura 3.31. Inserarea temperaturii .

69

Figura 3 .32. Modificarea temperaturii . Figur a 3.33 . Ștergerea temperaturii .

Opțiunea Weight aduce în prin plan o listă cu greutățile corpului înregistrare de către
utilizator, ca în Figura 3.34. Operațiile de inserare, modificare și ștergere a le greutăților se
realizează în mod identic ca în cazul simptomelor. Exemplu pentru inserare este disponibil în
Figura 3.35, pentru modificare este disponibil în Figura 3.36 și pentru ștergere este dis ponibil în
Figura 3.37.

Figura 3.34. Lista greutăților . Figura 3.35. Inserarea gre utății.

70

Figura 3 .36. Modificarea greutății . Figur a 3.37 . Ștergerea greutății .

Opțiunea Height aduce în prin plan o listă cu înălți mile corpului înregistrare de către
utilizator, ca în Figura 3.38. Operațiile de inserare, modificare și ștergere a le înălțimilor se
realizează în mod identic ca în cazul simptomelor. Exemplu pentru inserare este disponibil în
Figura 3.39, pentru modificar e este disponibil în Figura 3.40 și pentru ștergere este disponibil în
Figura 3.41.

Figura 3.38. Lista înălțimilor . Figura 3.39. Inserarea înălțimii .

71

Figura 3 .40. Modificarea înălțimii . Figur a 3.41 . Ștergerea înălți mii.

Opțiunea Blood Pressure aduce în prin plan o listă cu tensiunile arteriale înregistrare de
către utilizator, ca în Figura 3.42. Operațiile de inserare, modificare și ștergere a le tensiunilor se
realizează în mod identic ca în cazul simptomelor. Exem plu pentru inserare este disponibil în
Figura 3.43, pentru modificare este disponibil în Figura 3.44 și pentru ștergere este disponibil în
Figura 3.45.

Figura 3.42. Lista tensiunilor . Figura 3.43. Inserarea tensiunii .

72

Figura 3.44. Modificarea tensiunii . Figura 3.45. Ștergerea tensiunii .

Opțiunea Blood Glucose aduce în prin plan o listă cu glicemiile înregistrare de către
utilizator, ca în Figura 3.46. Operațiile de inserare, modificare și ștergere ale glicemiilor se
realizează în mod identic ca în cazul simptomelor. Exemplu pentru inserare este disponibil în
Figura 3.47, pentru modificare este disponibil în Figura 3.48 și pentru ștergere este disponibil în
Figura 3.49.

Figura 3 .46. Lista glicemii lor. Figur a 3.47 . Inserarea glicemiei .

73

Figura 3.48. Modificarea glicemiei . Figura 3.49. Ștergerea glicemiei .

În cadrul grupului Medication al meniului principal, se găsesc opțiuni specifice
programelor de medicamentație. Aici se află funcționalitățile care reușesc să ajute utilizatorii în
legătură cu gestiunea orelor la trebuie luate medicamente, cu evidența tipului și cant ității
medicamentelor deținute ș i cu informații despre fiecare medicament.
Opțiunea P rogram aduce din baza d e date prin intermediul unui task asincron datele
programelor de medicamentație create de medici pentru utilizator, cu ajutorul unui cereri către
server, care transmite datele sub format JSON pentru a fi afișate sub forma unui liste care conține
numele medicamentelor și orele la care necesită să fie luate , ca în Figura 3.50.
Dacă este selectat din listă un program de medicamentație, atunci apare o fereastră cu
informațiile acelui program, acestea fiind : numele medicament ului, cantitate a, ora la care trebui e
luat, medicul care a adăugat programul, data de început și data de sfârșit a programului, precum și
posibilitatea de a activa, ca în Figura 3.51, sau de a dezactiva, ca în Figura 3.52, prin intermediul
unui slider dedicat, notificări menite să atenționez e utilizatorul atunci când este timpul să ia un
medicament.

74

Figura 3.50. Programe de medicamentație . Figura 3.51. Activarea alertelor .

Figura 3.52. Dezactivarea alertelor . Figura 3. 53. Notificare pentru medicamente .

75

În cazul în care programul d e medicamentație este activat, la ora la care acesta este setat se
transmite o notificare utilizatorului, ca în Figura 3.53, care atenționează în legătură cu faptul ca
este timpul ca utilizatorul să ia medicamentul . În momentul în care se accesează notificarea apare
o interfață ce conține planul de medicamentație, ca în Figura 3.54, în care apar datele programului
precum și cantitatea medicamentului pe care o deține utilizatorul.
Sunt puse la dispoziție două opțiuni, prima fiind Take it! care o să notifice faptul că
utilizatorul a luat medicamentul și modifică automat cantitatea deținută de utilizator prin scăd erea
cantității ce trebuie luată , iar a doua fiind Don’t take it! care semnalează faptul c ă utilizatorul nu
poate lua medicamentul în acel moment. În cazul în care utilizatorul nu deține o cantitate necesară
din cadrul medicamentului ce trebuie luat, atunci la accesare a notificării o să apară interfața din
Figura 3.55 care are doar opț iunea Don’t take it!, pre cum și un mesaj de alertă în legătură cu
insuficiența cantității medicamentului.

Figura 3.54 . Planul de medicamentație . Figura 3.55. Lipsa medicamentelor necesare .

O altă opțiune din cadrul meniului principal este Inventory, aceasta are drept scop stocarea
și gestiunea datelor referitoare la cantitățile medicamentelor deținute de către utilizator. Aceasta
aduce în prin plan o listă cu cantitățile medicamentelor deț inute de căt re utilizator, ca în Figura
3.56. Operațiile de modificare și ștergere ale cantităților medicamentelor deținute se realizează în
mod identic ca în cazul simptomelor , diferența fiind că la adăugarea unei noi cantități trebuie
specificat medicamentul a cărui cantitate se introduce . Exemplu pentru inserar e este disponibil în
Figura 3.57 , pentru modificar e este disponibil în Figura 3.58 și pentru șterger e este disponibil în
Figura 3.59 .

76

Figura 3.56. Lista cantităților deținute . Figura 3.57. Inserarea unei noi cantități .

Figura 3.58. Modificarea cantității . Figura 3.59. Ștergerea cantității .

77

O opțiune importantă în cadrul meniului principal este Drugs, aceasta conține o listă cu
medicamentele disponibile în sistem , ca în Figura 3.60. Importanța de osebită iese la iveală atunci
când este selectat un medicament din lista respectivă, deoarece apare o interfață grafică , ca în
Figura 3.61, care conține toate informațiile referitoare la prospectul medicamentului , aici
incluzând : moduri de administrare, do zele recomandate , efectele secundare, interacțiuni cu alte
medicamente și cu alimente, precum și alte informații importante.

Figura 3.60. Lista medicamentelor . Figura 3.61. Prospectul medicamentului .

Ultimul grup din cadrul meniul ui principal este Diets, acesta având o importanță deosebită
deoarece aici se găsesc indicațiile medicilor în cadrul programelor de nutriție, precum și
planificarea meselor principale ale zilei, pentru a putea primi notificări atunci când utilizatorul
trebuie să respecte orele impuse.
Opțiunea Schedule pune la dispoziție o interfață grafică în care utilizatorul își poate
introduce orele la care dorește să fie notif icat în legătură cu respectarea meselor principale ale
zilei: mic dejun , prânz și cină. Dacă acestea nu au mai fost configurate de către utilizator , câmpurile
care afișează orele meselor o să conțină valoarea “Insert data! ” ca în Figura 3.62 .
Configurarea orelor se face prin selectarea câmpurilor dedicate pentru fiecare masă
principală a zilei, f apt ce determină apariția unei ferestre ce permite introducerea orei dorite, pentru
micul dejun ca în Figura 3.63, pentru prânz ca în Figura 3.64 și pentru cină ca în Figura 3.65.

78

Figura 3.62 . Notificări neconfigurate . Figura 3.63 . Setarea notificării pentru mic dejun .

Figura 3.64 . Setarea notificări i pentru prânz . Figura 3.65 . Setarea notificării pentru cină .

79

Figura 3.66. Activarea notificărilor . Figura 3.67. Dezactivarea notificărilor .

După ce au fost introduse orele la care se doresc setate notificările, acestea pot fi act ivate
prin intermediul slider -ului dedicat pentru fiecare masă principală în parte, ca în Figura 3.66, sau
pot fi dezactivate ca în Figura 3.67.

Figura 3 .68. Notificare pentru mic dejun . Figura 3.69. Informații despre mic dejun .

80

Figura 3.70. Notificare pentru prânz . Figura 3.71. Informații despre prânz .

În cazul în care notificările au fost activate pentru mesele principale ale zilei , atunci pentru
micul dejun se generează notificarea din Figura 3.68, pentru prânz se generează notificarea din
Figura 3.70 și pentru cină se generează notificarea din Figura 3.72.

Figura 3.72. Notificare pentru cină . Figura 3.73. Informații despre cină .

81

Dacă notificările sunt selectate de către utilizator atunci se accesează o interfață cu date
utile despre acea masă principală, pentru micul dejun ca în Figura 3.69, pentru prânz ca în Figura
3.71 și pentru cină ca în Figura 3.73.
În cadrul opțiunii Recom mendations din cadrul meniului principal se pune la dispoziție o
listă cu alimentele recomandate pentru utilizatorul aplicației împreună cu numele medicilor
propunători, ca în Figura 3.74, acestea fiind inserate de către medi cii speci aliști care dețin acorduri
cu utilizatorul în cadrul programelor de nutriție create cu scopul de a asigura o alimentație cât mai
optimă pentru utilizatorul în cauză.

Figura 3.74. Lista cu alimente recomandate . Figura 3.75. Lista cu alime nte interzise .

Ultima opțiune din cadrul meniului principal, numită Bans, pune la dispoziție o listă cu
alimentele interzise pentru utilizator ul aplicației împreună cu numele medicilor propunători, ca în
Figura 3.75, acestea fiind inserate de către medi cii specialiști care dețin acorduri cu utilizatorul în
cadrul programelor de nutriție create cu scopul ca utilizatorul să evite alimentele periculoase sau
nesănătoase care pot dăuna sănătății lui.
După cum se poate observa , după numărul impresionant de opț iuni și funcționalități
implementate în cadrul aplicației Android, de tip client, dedicată utilizatorilor beneficiari de
servicii le medicale ale medicilor specialiști. A plicația încearcă să formeze un ecosistem complex
și prielnic gestionării datelor legat e de programele de medicamentație și nutriție transmise de către
medici, cu ajutorul datelor legate de starea de sănătate transmise de către utilizatori , astfel se
realizează un echilibru între datele furnizate medicilor și datele primite de la medici care
favorizează îmbunătățirea sănătății și a calității vieții utilizatorilor.

82
3.3 Aplicația Android dedicată medicilor

Aplicația Android dedicată medicilor a fost creat ă în Android Studio, mediul oficial de
dezvoltare integrat destinat creării aplicațiilor pentru sistemul de operare Android, cu ajutorul
limbajul Java, care stă la baza logicii ș i a funcționalităților existente, dar și cu ajutorul limbajului
XML, care stă la baza tuturor elementelor de interfață grafică.
Această aplicație are drept scop permi terii medicilor specialiști să folosească expertiza lor
medicală în folosul utilizatorilor, utilizând datele medicale introduse de către aceștia pentru a putea
asigura u n grad cât mai optim și exact al servicii lor medicale prestate .
În cadrul acestei apli cații se pot înregistra doar medici, această aplicației creând un mediu
prielnic și singur în care utilizatorii își pot expune datele cu caracter medical unor specialiști
dornici să își ofere serviciile medicale. Astfel acest serviciu medical are avantaje de ambele părți,
utilizatorii găsesc medici competenți gata să rezolve probleme medicale întâmpinate de aceștia, în
vreme ce medicii câștigă reputație precum și un număr impresionant de pacienți noi care pot aduce
profituri substanțiale în cazul în care un ii medici își oferă serviciile medicale contra cost. Din acest
punct de vedere proiectul ICare poate deveni o afacere sustenabilă pe viitor.
Aplicația destinată medicilor poartă numele sugestiv de ICare Doctors, din care reiese
faptul ca este vorba de apl icația ICare, a utilizatorilor, reinterpretată cu scopul de a maximiza
performanțele medicilor, precum și ușurința în utilizare . Astfel medicii au un mediu dedicat în care
să poată profesa fără existența barierelor legate de timpul liber tot mai scăzut al utilizatorilor , sau
de distanțele mari dintre aceștia și pacienții lor.
Această aplicația este veriga lipsă din cadrul proiectului ICare, fără de care nu poate exista,
întrucât ea reprezintă ”scena, pe care actorii principali (medicii) creează spectacolul de neuitat
(serviciile medicale) pentru publicul (utilizatorii) tot mai numeros și în nevoie”.
Deoarece aceasta se bazează pe aplicația ICare prezentată în subcapito lul anterior, împarte
cu aceasta mai multe elemente de logică cât și de design, astfel ex istă unele elemente identice sau
repetitive, dar pe baza cărora s -au implementat și al tele funcționalități unice disponibile doar în
această aplicație conform necesităților medicilor care o utilizează pentru prestarea serviciilor
medicale de care aceștia s unt capabili.
În continuare este prezentată aplicația în mod complet, accentul picând pe elementele unice
și inedite care creează unicitatea și funcționalitatea aceste aplicații, elementele comune cu aplicația
destinată utilizatorilor fiind doar amintite.
La pornirea aplicației ICare Doctors, prima interfață grafică întâmpinată este cea de logare,
ca în Figura 3.76 care obligă medicul să se autentifice înainte de a putea utiliza aplicația. Pentru
autentificare este necesară introducerea adresei de email ș i a parolei, ca în Figura 3.77, procedeul
de autentificare fiind același ca în aplicația anterioară pornind de la butonul Log In , dacă ambele
câmpuri au fost introduse și validate cu succes .

83

Figura 3.76 . Interfața pentru logare . Figura 3.77. Datele necesare pentru logare .

La accesarea opțiunii “Create a new account ” se aduce în prin plan o interfață grafică ca în
Figura 3.78 c are permite înregistrarea unui cont nou în mod similar cu aplicația precedentă, doar
că aici este necesară int roducerea specializării medicului într -un câmp nou numit specialization .
Procesul de înregistrare pornind în momen tul apăsării butonului Register, dacă toate câmpurile au
fost introduse și validate cu succes .

Figura 3.78 . Interfața pentru înregistrare . Figura 3.79 . Mesaje de avertizare .

84

În cazul în care nu sunt introduse toate datele sau datele introduse sunt incorecte se primesc
mesaje de avertizare ca în Figura 3.79. Dacă autentificarea a fost realizată cu succes atunci se
aduce în pr in plan interfața grafică principală , de tip A ctivity, ca în Figura 3.80, care în momentul
creării cu ajutorul unui task asincron cere de la server citatul de întâmpinare.

Figura 3.80. Interfața grafică principală . Figura 3.81 . Meniul interfeței principale .

Figura 3.82 . Opțiunea de Log Out . Figura 3.83 . Confirmare Log Out .

85

Interfața principală conține, similar ca în aplicația precedentă, un meniu contextual în
partea dreaptă sus cu o opțiune numită Log Out, c a în Figura 3.82, care permite medicilor să se
delogheze după ce acceptă mesaj ul de confirmare din Figura 3.83 .
Meniul interfeței principale din cadrul aplicației pentru medici este tip NavigationDrawler,
fiind vizibil în Figura 3.81 . Acesta pune la disp oziție o serie restrânsă de opțiuni care vizează
atenția medicilor, informațiile pacienților aflându -se în opțiunea Pacients. În cadrul acestui meniu
se vor prezenta pe rând fiecare opțiune disponibilă în rândurile ce urme ază, opțiunile fiind de tip
Fragme nt utilizate cu ajutorul unui FragmentManager.
Opțiunea Personal Info aduce în prin plan o interfață grafică ce pune la dispoziție
vizualizarea datelor personale ale medicului, ca în Figura 3.84 . Permite și modificarea acestor date
prin intermediului buto nului Edit care creează o fereastră ce face posibilă modificare datelor
personale ale medicului , lucru vizibil în Figura 3.85, prin câmpurile dedicate pentru tipurile de
informații , dacă se apasă pe opțiunea ok din cadrul ferestrei .

Figura 3.84. Datele personale . Figura 3.85. Editarea datelor personale .

Opțiunea Home are drept scop aducerea în prin plan a interfeței grafice din Figura 3.80
indiferent de locația curentă în cadrul aplicației.
O opțiune importantă este Drugs, aceasta co nține o listă cu medicamentele disponibile în
sistem ca în Figura 3.86. Această opțiune este disponibilă și în aplicația pentru utilizator fiind
importată și aici. Atunci când este selectat un medicament din lista respectivă apare o interfață
grafică, ca î n Figura 3.87, care conține toate informațiile referitoare la prospectul medicamentului,

86

aici incluzând : moduri de administrare, dozele recomandate , efectele secundare, interacțiuni cu
alte medicamente și cu alimente, precum și alte informații importante.

Figura 3.86 . Lista medicamentelor . Figura 3.87 . Prospectul medicamentului .

Opțiunea Patients este cea mai importantă din cadrul întregii aplicații, deoarece conține
lista pacienților medicului, precum și toate datele inserate de căt re aceștia, date cruciale pentru
stabilirea programelor de medicamentație și nutriție. Aceasta pune la dispoziție o interfață grafică
ce conține lista pacienților care au acceptat cereri de la medicul respectiv, lucru vizibil în Figura
3.88. Se pune la dis poziție un buton în partea dreaptă jos cu o iconiță în formă de plus care are
drept scop inserarea pacienților noi.
În momen tul în care butonul este apăsat se creează o fereastră ca în Figura 3.89, care pune
la dispoziție un câmp pentru a insera un pacie nt în funcție de adresa sa de email . Dacă se apasă pe
opțiunea ok, atunci se trimite o cerere către utilizatorul în cauză, dacă și numai dacă acesta acceptă
cererea de la medic abia atunci este introdus în lista medicului pentru a putea vizualiza datele
acestuia cu scopul prestării servicii lor medicale.
Dacă se selectează un pacient din listă atunci apare o altă interfață grafică de tip A ctivity
care conține datele pacientului selectat, exact ca în Figura 3.90. În această interfață se pun la
dispoziție dou a opțiuni. Prima opțiune este numită Call care facilitează crearea unui apel către
pacientul selectat, ca în Figura 3.91, iar a doua se numește Delete și are drept scop ștergerea
pacientului selectat din listă.
Dacă se selectează opțiunea Delete se trans mite o fereastră de confirmare ca în Figura 3.92,
care e fectuează ștergerea pacientului doar la apăsarea opțiunii yes.

87

Figura 3.88. Lista pacienților . Figura 3.89. Adăugarea unui pacient .

Figura 3. 90. Datele pacient ului. Figura 3.91 . Apelarea unui pacient .

88

Figura 3.92. Ștergerea unui pacient .

Figura 3.93. Prima parte a meniului . Figura 3.94. A doua parte a meniului .

89

Interfață grafi că din Figura 3.90 este de tip A ctivity și implementează un alt meniu de tip
NavigationDrawler, vizibil în Figura 3.93 și Figura 3.94. Acest meniu este foarte similar cu cel
din aplicația destinată utilizatorilor, în el regăsindu -se informațiile stocate de către pacientul
selectat, astfel me dicul având acces asupra acestor date cu scopul de a transmite programe de
medicamentație și nutriție. În cadrul acestui meniu, opțiunile fiind de tip Fragment utilizate cu
ajutorul unui FragmentManager.
În continuare urmează prezentarea fiecărei opțiuni disponibile, accentul picând pe
funcționalitățile noi disponibile doar medicului prin această aplicație.
Opțiunea Patient Info are drept scop aducerea în prin plan a interfeței grafice din Figura
3.90 indiferent de locația curentă în cadrul aplicației.
Opțiunea Home are drept scop aducerea în prin plan a interfeței grafice din Figura 3.80
indiferent de locația curentă în cadrul aplicației.
În cadrul opțiunii Symptoms se creează o interfață grafică ce conține o listă cu toate
simptomele în serate de către pacientul selectat, ca în F igura 3.95.
La selectarea opțiunii Temperature apare o interfață grafică ce conține o listă cu toate
temperaturile corpului înserate de c ătre pacientul selectat, ca în F igura 3.96.
Prin utilizarea opțiunii Weight apare o interf ață grafică ce conține o listă cu toate greutățile
corpului înserate de c ătre pacientul selectat, ca în F igura 3.97.
La apăsarea pe opțiunea Height se creează o interfață grafică ce conține o listă cu toate
înălțimile corpului înserate de c ătre pacientul selectat, ca în F igura 3.98.

Figura 3.95 . Lista simptomelor . Figura 3.96 . Lista temperaturilor .

90

Figura 3.97. Lista greutăților . Figura 3.98. Lista înălțimilor .

La selectarea opțiunii Blood Pressure apare o inte rfață grafică ce conține o listă cu toate
tensiunile arteriale înserate de c ătre pacientul selectat, ca în F igura 3.99.
La apăsarea pe opțiunea Blood Glucose se creează o interfață grafică ce conține o listă cu
toate valorile glicemiilor înserate de c ătre pacientul selectat, ca în F igura 3.100.

Figura 3.99 . Lista tensiunilor . Figura 3.100 . Lista glicemiilor .

91

Opțiunea Program are o importanță deosebită în cadrul stabilirii programelor de
medicamentație de către medic pentru pacienții săi. În momentul accesării se pune la dispoziție o
interfață grafică care conține o listă cu programele de medicamentație prescrise de către medicul
în cauză, ca în Figura 3.101, nu și programele prescrise de către alți medici.
Inserarea unui program de m edicamentație pentru pacientul selectat se realizează prin
utilizarea butonului rotund din dreapta jos. La apăsarea acestuia se deschide o fereastră ca în Figura
3.102, în care sunt disponibile câmpuri dedicate pentru introducerea datelor necesare :
medicam entul în cauză, dozajului, ora la care trebuie luat medicamentul, data la care începe
programul și data la care se sfârșește programul. A cest lucru se poa te face doar da că pacientul
deține o cantitate suficientă din cadrul medicamentului prescris.
La sele ctarea unui program de medicamentație din listă, apare fereastră care conține datele
curente în câmpuri dedicate ca în Figura 3.103, lăsând posibilitatea m odificării programului
selectat prin schimbarea oricărui parametru. Modificarea se face la selectarea opțiunii edit, în caz
că se alege opțiunea delete, atunci se afișează o fereastra de confirmare ca în Figura 3.104, dacă în
acea fereastră se alege opțiunea yes atunci programul de medicamentație o să fie șters.
În cadrul meniului principal, dacă se aleg e opțiunea Inventory, atunci se afișează o interfață
grafică care pune la dispoziție o listă cu medicamentele și cantitățile acestora deținute de către
pacientul selectat, ca în Figura 3.105.

Figura 3.101. Lista programelor . Figura 3. 102. Adăugarea unui program .

92

Figura 3.103 . Modificarea unui program . Figura 3.104 . Ștergerea unui program .

Figura 3.105. Lista medicamentelor deținute .

93

Figura 3.106. Lista alimentelor recomanda te. Figura 3.107. Inserarea unui aliment .

Opțiunea Recommendations aduce în prin plan o listă cu alimentele recomandate
înregistrare de către medic pentru utilizator ul selectat , ca în Figura 3.30 6, dar nu și cele înregistrate
de alți medici . Operațiile de inserare, modificare, ștergere ale alimentelor se realizează în mod
identic ca în aplicația precedentă . Exemplu pentru inserar e este disponibil în Figura 3.107 , pentru
modificar e este disponibil în Figura 3.108 și pentru ștergere este disponib il în Figura 3.109 .

Figura 3.108 . Modificarea unui aliment . Figura 3.109 . Ștergerea unui aliment .

94

Figura 3.110. Lista alimentelor interzise . Figura 3.111. Inserarea unui aliment .

Opțiunea Bans ad uce în prin plan o listă cu alimentele interzise înregistrare de către medic
pentru utilizatorul selecta t, ca în Figura 3.310, dar nu și cele înregistrate de alți medici. Operațiile
de inserare, modificare și ștergere ale alimentelor se realizează în mod i dentic ca în cazul aplicației
precedente. Exemplu pentru inserare este disponibil în Figura 3.111, pentru modificare este
disponibil în Figura 3.112 și pentru ștergere este disponibil în Figura 3.113.

Figura 3.112 . Modificarea unui alime nt. Figura 3.113 . Ștergerea unui aliment .

95
Concluzii

Scopul principal al lucrării prezente, monitorizare a datelor pentru facilitarea supervizării
programelor de medicamentație ș i nutriție , a fost atins cu succes în cadrul soluției propuse prin
intermediul sistemelor mobile, mai exact prin cadrul aplicațiilor ce respectă modelul client -server
care fac posibil acest lucru, acestea fiind serverul web și cele două aplicații Android dedicate
utilizatorilor respectiv medicilor.
Obiectivele enunțate în deschiderea lucrării de licență au fost îndeplinite prin
funcționalitățile puse la dispoziție de către soluția propusă, în care se oferă suport pentru toate
datele medicale introduse de către utilizatori, permițând intervenția medicilor prin programe d e
medicamentație și nutriție pentru soluționarea problemelor medicale descrise.
Se poate remarca scopul nobil și umanitar al ideii care stă la baza temei lucrării de licență,
tratarea persoanele aflate în suferință , din punct de vedere medical, dar și sus ținerea valorificării
medicilor prin expunerea lor la un mediu plin de potențiali pacienți. Un factor important în acest
sens fiind utilitatea soluției, care își propune să remedieze cât mai multe cazuri medicale.
Dezvoltarea proiectului ICare a necesita t utilizarea multor cunoștințe dob ândite în cei trei
ani de studiu , dintre care se a mintesc : principii de programare, algoritmi, programe orientată pe
obiect, tehnici avansate de programare, protocoale de comunicații, modelul client -server, structuri
de d ate, baze de date, limbaje de programare, sisteme de operare mobile, tehnologii web ,
programare paralelă și concurentă, precum și multe altele. Acest proiect a permis și dobândirea
multor cunoștințe teoretice noi, precum și utilizarea unor tehnologii noi.
Dezvoltarea bazei de date a pus probleme substanțiale în cadrul grupării și gestionării
datelor primite de la aplicațiile Android, datorită faptului că eficientizarea gestionării acestora a
fost o prioritat e pentru asigurarea unei bune funcționalități în cadrul proiectului, totuși a permis
fixarea noțiunilor teoretice legate de limbajul MySQL și familiarizarea cu PhpMyAdmin în cadrul
gestionării acesteia.
Serverul, prin dezvoltarea sa, a ridicat probleme în ceea ce privește transferul de date și
arhitectu ra pe care o respectă, deoarece a necesitat un timp îndelungat și multe experiențe pentru
a putea înțelege arhitectura REST și protocolul de comunicație utilizat. Dar a permis asimilării de
cunoștințe noi în cadrul arhitecturii REST, aplicațiilo r web, mode lului client -server ș i
protocoalelor de comunicației.
În cadrul dezvoltării aplicațiilor Android dedicate utilizatorilor respectiv medicilor
problemele au apărut în cadrul creării interfețelor grafice și a funcționalităților atașate lor, acestea
fiind o n outate, a mai ridicat probleme și în cazul gestionării resurselor utilizate, în cadrul
transmiterii de informații către server, dar mai ales în cadrul securității și a protecției datelor
utilizate. În schimb a facilitat învățarea tehnicilor de programare n ecesare dezvoltării aplicațiilor
Android , precum și familiarizarea cu gestiunea sistemelor complexe bazate pe componente.

96
Acest proiect poate să devină motivul unei afaceri sustenabile, întrucât elimină barierele
dintre utilizatori și medici, sporind prod uctivitatea celor implicați, dar și pentru faptul că poate
crea noi oportunități și locuri de muncă prin atragerea medicilor în cadrul acestui sistem, în cazul
transformării lui într -un serviciu plătit.
Ca și tendințe de viitor dezvoltarea proiectului po ate fi continuată astfel încât să intre în
producție, generând un sistem medica l complex plin de beneficii atât pentru utilizatori cât și pentru
medici. Se pot dezvolta în primul rând un sistem de securitate mult mai performant și eficient
pentru a securiz a datele vehiculate în cadrul platformei , la care se poate adăuga un sistem mai
inteligent de notificări capabil să semnaleze și să acționeze în consecință atunci când apar
modificări în baza de date . Se pot stratifica și grupa date în cadrul unor categori i mai eficiente și
mai ușor de utilizat, interfețele grafice pot fi dezvoltate mai amănunțit pentru a fi mai ușor de
utilizat și mult mai atractive , precum și opțiuni suplimentare care să permită personalizarea
conținutului și interfețelor conform necesită ților utilizatorilor și medicilor .
Pot fi implementate și funcționalități diferite de cele existente pe ntru a sporii gradul de
utilizar e al platformei, astfel mărind productivitate a prin opțiuni care permit o mult mai bună
gestiune a datelor vehiculate î n cadrul platformei pentru o supervizare a programelor de
medicamentație și nutriție cât mai optimă.
Un aspect foarte important în cadrul dezvoltării viitoare este și punerea la dispoziție a
platformei realizate unei populații cât mai vaste de utilizator i, acest lucru fiind posibil prin
implementarea soluției și pe alte sisteme, prin integrarea acestora pe alte sisteme mobile, cum ar
fi IOS sau Windows Phone, dar mai ales pe W eb, pentru a putea permite utilizarea și pe platforme
de tip desktop, astfel cu o componentă centrală, serverul web la care se adaugă un număr cât mai
mare de tipuri de aplicații client pe multiple platforme suportate se elimină limitările soluției și se
permite o utilizare cât mai variată a funcționalităților oferite .
Ca o concluzi e generală declar că î n urma realizării acestei lucrări de licență am asimilat
multe cunoștințe teoretice și practice, am descoperit și utilizat tehnologii noi, dar mai ales am
învățat să îmi gestionez timpul și resursele, astfel timpul dedicat realizării lucrării de licență a fost
bine utilizat și foarte productiv. Cunoștințele acumulate sunt vaste și din domenii diferite, acestea
fiind : informatică, nutriție și medicină . După această experiență consider că sunt cu mult mai
informat în ceea ce privește un stil de viață să nătos și ce presupune acesta, reușind să corectez
anumite deprinderi greșite în ceea ce privește programele de medic amentație și nutriție.

97
Bibliografie

[1] Dina Spector. ”Here's how many days a person can survive without water ”,
http://www.businessinsider.com/how -many -days-can-you-survive -without -water -2014 -5
(Accesat la 2017.05 .08)
[2] Ann Pietrangelo, Elea Carey, Kimberly Holland . ”The Effec ts of Fast Food on the Body ”
http://www.healthline.com/health/fast -food-effects -on-body (Accesa t la 2017.05 .08)
[3] ”Medical Definition of Body mass index ”
http://www.medicinenet.com/script/main/art.asp?articlekey=16125
(Accesat la 2017.05.12 )
[4] ”Medicine Probl ems”
http://www.webmd.com/a -to-z-guides/tc/prescription -medications -medication -problems
(Accesat la 2017.05.13 )
[5] ”Drug Side Effects ”,
https://www.drugs.com/sfx/ (Accesat la 2017.05.15 )
[6] Jim Morelli, MS, RPh . ”Allergy Drugs: Prescription and OTC Medication s”
http://www.rxlist.com/allergy_medications/drugs -condition.htm (Accesat la 2017.05.18 )
[7] ” Drug interaction ”.
https://en.wikipedia.org/wiki/Drug_interaction (Accesat la 2017.05.1 8)
[8] ”Drug -Food Interactions ”,
https://familydoctor.org/drug -food-interactions / (Accesat la 2017.05.1 8)
[9] Fincke, Benjamin Graeme, Miller, Donald R., Spiro, Avron ( Martie 1998). " The
interaction of patient perception of overmedication with drug compliance and side
effects ". Jurnal de medicină internă generală .
[10] Gosling, James, Joy, Bil l, Steele, Guy, Bracha, Gilad, Buckley, Alex (2014). ”The
Java® Language Specification ”
[11] ”Write once, run anywhere? ”
http://www.computerweekly.com/feature/Write -once -run-anywhere
(Accesat la 2017.05.25 )
[12] ”The Java Language Environment ”
http://www.oracle.co m/technetwork/java/intro -141325.html (Accesat la 2017.05.25 )
[13] “Java (programming language) ”
https://en.wikipedia.org/wiki/Java_(programming_language) (Accesat la 2017.05.25 )
[14] “Android (operating system) ”
https://en.wikipedia.org/wiki/Android_(operating_syste m) (Accesat la 2017.05.2 8)
[15] “Android Studio ”
https://en.wikipedia.org/wiki/Android_Studio (Accesat la 2017.05.2 8)

98
[16] “Create a Project ”
https://developer.android.com/studio/projects/create -project.html (Accesat la 2017.06.02 )
[17] “Android software development ”
https://en.wikipedia.org/wiki/Android_software_development (Accesat la 2017.06.02 )
[18] “Gradle ”
https://en.wikipedia.org/wiki/Gradle (Accesat la 2017.06.02 )
[19] “XML ”
https://en.wikipedia.org/wiki/XML (Accesat la 2017.06.03)
[20] “Representational state transfer ”
https:/ /en.wikipedia.org/wiki/Representational_state_transfer (Accesat la 2017.06.04 )
[21] “Client –server model ”
https://en.wikipedia.org/wiki/Client%E2%80%93server_model (Accesat la 2017.06.04 )
[22] “Introducing JSON ”
http://www.json.org/ (Accesat la 2017.06.05 )
[23] “MySQL ”
https://en.wikipedia.org/wiki/MySQL (Accesat la 2017.06.05 )
[24] “Backing Up Your Database ”
https://codex.wordpress.org/Backing_Up_Your_Database (Accesat la 2017.06.05 )