Criste V Alin Ionut Proiect De Diploma [627235]

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI TEHNOLOGIA
INFORMAȚIEI
PROGRAMUL DE STUDIU CALCULATOARE
FORMA DE ÎNVĂȚĂMÂNT ZI

PROIECT DE DIPLOMĂ

COORDONATOR ȘTIINȚIFIC
PROF. UNIV. DR. ING. GYORODI ROBERT

ABSOLVENT: [anonimizat]
2020

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI TEHNOLOGIA
INFORMAȚIEI
PROGRAMUL DE STUDIU CALCULATOARE
FORMA DE ÎNVĂȚĂMÂNT ZI

IMPLEMETAREA UNEI
APLICAȚII MOBILE PENTRU O
COFETĂRIE/PATISERI E

COORDONATOR ȘTIINȚIFIC
PROF. UNIV. DR. ING. GYORODI ROBERT

ABSOLVENT: [anonimizat]
2020

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI TEHNOLOGIA INFORMAȚIEI
DEPARTAMENTUL CALCULATOARE

TEMA
IMPLEMENTAREA UNEI APLICAȚII MOBILE PENTRU O COFETĂRIE/PATISERIE

Lucrare de Finalizare a studiilor a student: [anonimizat]
1). Tema lucrării de finalizare a studiilor:
IMPLEMENTAREA UNEI APLICAȚII MOBILE PENTRU O COFETĂARIE/PATISERIE
2). Termenul pentru predarea lucrării: 05.09.2020
3). Elemente ini țiale pentru elaborarea lucrării de finalizare a studiilor:
CURS PROGRAMARE ORIENTATĂ PE OBIECTE, BAZE DE DATE
4). Conținutul lucrării de finalizare a studiilor: INTRODUCERE , OBIECTIVELE
LUCRĂRII , STUDIUL BIBLIOGRAFIC , ANALIZĂ ȘI FUNDAMENTARE TEORETIĂ ,
PROIECTAREA DE DETALIU ȘI IMPLEMENTARE , CONCLUZII
5). Material grafic: Prezentare Power Point, Capturi de ecran
6). Locul de documentare pentru elaborarea lucrării: Internet
7). Data emiterii temei: 07/10/2019

COORDONATOR ȘTIINȚIFIC
PROF. UNIV. DR. ING. GYORODI ROBERT

Cuprins

1. INTRODUCERE ………………………….. ………………………….. ………………………….. ……………. 1
1.1. Context ………………………….. ………………………….. ………………………….. …………………… 1
1.2. Motivația ………………………….. ………………………….. ………………………….. ………………… 2
2. OBIECTIVELE PROIECTULUI ………………………….. ………………………….. …………………… 3
2.1. Specificarea problemei ………………………….. ………………………….. ………………………….. .3
2.2. Obiectivele principale ………………………….. ………………………….. ………………………….. ..3
2.3. O biectivele secundare ………………………….. ………………………….. ………………………….. ..4
3. STUDIU BIBLIOGRAFIC ………………………….. ………………………….. ………………………….. .5
3.1 Tipuri de aplicații mobile ………………………….. ………………………….. ………………………… 5
3.1.1 Aplicații Web Hibride ………………………….. ………………………….. ………………………. 6
3.1.2 Aplicații Native Hibride ………………………….. ………………………….. ……………………. 7
3.1.3 Aplicații complet Native ………………………….. ………………………….. …………………… 8
3.2. Tehnologii de stocare și baze de date ………………………….. ………………………….. ……….. 9
3.2.1. Cloud computing ………………………….. ………………………….. ………………………….. …9
3.2.1.1. Caracteristici esențiale ………………………….. ………………………….. ……………… 10
3.2.1.2. Modele de deployment cloud ………………………….. ………………………….. …….. 10
3.2.1.3. Model de servicii cloud ………………………….. ………………………….. ……………. 11
3.3. Baze de date locale ………………………….. ………………………….. ………………………….. …. 13
3.4. Platforma Android ………………………….. ………………………….. ………………………….. ….. 14
3.4.1. Descrierea platformei ………………………….. ………………………….. …………………….. 14
3.4.2. Arhitectura platformei Android ………………………….. ………………………….. ……….. 15
3.4.3. Componentele unei aplicații Android ………………………….. ………………………….. .. 17
3.5. Aplicații similare ………………………….. ………………………….. ………………………….. ……. 21
4. ANALIZĂ ȘI FUNDAMENTARE TEORETI CĂ ………………………….. ………………………. 24

4.1. Cerințele sistemului ………………………….. ………………………….. ………………………….. … 24
4.1.1 . Cerințe funcționale ………………………….. ………………………….. ………………………… 24
4.1.2. Cerințe non -funcționale ………………………….. ………………………….. ………………….. 25
4.2. Tehnologii și Baze de Date utilizate ………………………….. ………………………….. ……….. 27
4.2.1. Firebase ………………………….. ………………………….. ………………………….. …………… 27
4.2.2. Android Studio ………………………….. ………………………….. ………………………….. …. 29
4.2.2.1. Debug ………………………….. ………………………….. ………………………….. ……….. 30
4.2.2.2. Structura proiectelor Android Studio ………………………….. ………………………. 30
4.2.3 SQLite ………………………….. ………………………….. ………………………….. …………….. 30
5. PROIECTAREA DE DETALIU ȘI IMPLEMENTARE ………………………….. ………………. 32
5.1. Structura bazelor de date ………………………….. ………………………….. ………………………. 32
5.1.1. Structura bazei de date Firebase Cloud ………………………….. ………………………….. 32
5.1.1.1. Stocarea datelor ………………………….. ………………………….. ………………………. 32
5.1.1.2. Baza de date în Firebase Cloud ………………………….. ………………………….. ….. 33
5.1.2. Structura bazei de date locale ………………………….. ………………………….. ………….. 35
5.2. Prezentarea generala a interfeței ………………………….. ………………………….. …………….. 36
5.3. Implementarea Aplicației Client și Aplicației de Gestiune ………………………….. ………. 37
5.3.1. Părți comune ………………………….. ………………………….. ………………………….. ……. 37
5.3.2. Implementarea sistemului de înregistrare ………………………….. ……………………….. 39
5.3.3. Implementarea listei de sugestii a produselor ………………………….. ………………….. 42
6. CONCLUZII ………………………….. ………………………….. ………………………….. ……………….. 43
6.1. Concluzii ………………………….. ………………………….. ………………………….. ………………. 43
6.2. Posibilități de dezvoltare ………………………….. ………………………….. ………………………. 43
BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. ……………… 45

1
1. INTRODUCERE

În acest capitol se va prezenta contextul în care este dezvoltat proiectul și
motivația pentru care s -a decis abordarea problemei descrise, de asemenea soluția propusă
pentru a rezolva această problemă.

1.1. Context
Trăim într -o lume în care comunicarea este din ce în ce mai important ă în vie țile noastre,
iar nevoia de a fi în con tact cu ceilal ți se manifest ă în toate activit ățile curente. Tehnologia
modern ă sprijin ă această nevoie, iar dispozitivele mobile reprezint ă probabil exponentul cel
mai de sea mă al acestei tehnologii. Telefoanele inteligente (smartphones) dotate cu sisteme de
operare din ce în ce mai avansate tind s ă înglobeze în ele un mic univers al fiec ăruia dintre noi .
În ziua de astăzi utilizarea dispozitivelor mobile inteligente din categoria tabletelor și
telefoanelor este într -o creștere permanentă. Din aceas tă cauză producătorii de dispozitive
mobile sunt forțați să își îmbunătățească produsele hardware și să vină cu tehnologii tot mai
performante. Suntem din ce în ce mai dependen ți de aceste tehnologii, de comunicare, de
conexiune, de transfer, de informa ție. Toate acestea sunt posibile datorit ă aplica țiilor mobile
care ruleaz ă pe aceste dispozitive . Aplicațiile mobile sunt relativ mai ușor de creat decât
aplicațiile pentru computere iar prețul dezvoltării lor este considerabil mai scăzut. Aceste două
avantaj e, împreună cu dezvoltarea tehnologică din ultimii ani și creșterea ratei de penetrare a
dispozitivelor mobile, au condus la creșterea cererii pentru aplicații mobile.
Știind toate aceste aspecte doresc s ă evidențiez importanța proiect ului ales, care consta
în dezvoltarea unei aplicații cu potențial ridicat, capabila de a susține o afacere pe piața din ziua
de azi.
Acest proiect urmează să trateze problemele care apar în afacerile de genul cofetărie/
patise rie, iar în urma unei analize putem evidenția câteva dintre acestea :
➢ În primul rând p entru a putea plasa o comanda clientul trebuie să viziteze
magazinul fizic să se informeze în legătură cu produsele dorite, pe urma s ă
comande și s ă plătească, toate acest ea necesită timp și răbdare.
➢ In al doilea rând plasarea comenzilor telefonic aduce cu si ne probleme ca lipsa
copiei fizice a meniului respectiv confirmarea vizuală a faptului că, comanda a
fost plasată corect.

2
➢ În ultimul rând fiecare afacere de acest gen are nevoie de anumiți angajați pentru
a prelua comanda prin telefon sau în persoană, pentru a oferi clientului o
experiență cât mai plăcută. Pe piața de astăzi, cererea forței de muncă crește zi
de zi, acest luc ru fiind o problem ă mare pentru angajatori în găsirea personalului
potrivit .

1.2. Motivația
Motivația pentru proiectarea acestei aplicații se datorează familiei mele, aceasta urmând
să intre într -o afacere de genul cofetărie/patiserie , ca urmare acest pr oiect va avea un impact
sper eu major în promovarea produselor care vor fi comercializate și totodată să ajute clientul
în pla sarea unei comenzi cu posibilitatea de a fi livrată acasă, salvând timpul de deplasare și
așteptarea , timp care este atât de preți os în zilele de astăzi . Crearea unei aplicații mobile se
potrivește majorității afacerilor deoarece aduce valoare investiției inițiale și atrage un număr
mare de clienți.
Un alt motiv ar fi faptul că aplicațiile orientate spre acest gen de afacere sunt foa rte
puține în Romania și inexistente în anumite zone ale țării, acesta fiind un avantaj în lansarea
unei noi afaceri pe piață
Lucrarea este structurată în șase capitole. Cel de -al doilea capitol face o trecere în revistă
a obiectivelor care urmează să fie atinse. Al treilea capitol face un studiu al tipurilor de aplicații
care s -ar putea dezvolta în cazul nostru, al modului de stocare a informațiilor, de asemenea va
studia și câteva aplicații asemănătoare pentru a putea a duce o noutate. Capitolul patru prezintă
cerințele sistemului, tehnologiile de stocare si de dezvoltare care urmează să fie implementate
și utilizate . Cel de -al cincilea capitol explica în detaliu modul de stocare și utilizare a
informațiilor, modul de imp lementare a funcțiilor și prezintă câteva dintre elementele de
interfață utilizate. În ultimul capitol se vorbește atât despre beneficiile care le -a adus dezvoltarea
acestui proiect , cât și despre alte posibilități de dezvoltare.

3
2. OBIECTIVELE PROIECTULUI

În acest capitol se vor enunța problema pe care proiectul vrea să o rezolve, obiectivele
principale, și obiectivele secundare ale proiectului.

2.1. Specificarea problemei
În viața modernă de oraș, cumpărăturile sunt o activitate esențială pentru fiecare
dintre noi. Când zicem cumpărături specific faptul că mă refer doar la partea de produse
alimentare, această parte fiind cea care ne interesează pentru acest proiect.
Mâncarea și produsele alimentare sunt indispensabile în viața fiecărui om, indiferent de
țară, culoare sau gen. Datorită acestui fapt serviciile din acest domeniu au venit cu tot felul de
cereri care să le ușureze activitatea și totodată să ajute dezvoltarea lor.
Pentru a înțelege mai bine problemele pentr u care este necesară dezvoltarea acestui
proiect, sunt necesare evidențiate câteva dintre acestea.
Atunci când vizităm o locație cu scopul de satisface nevoile culinare și trupești, trebuie
luați în calcul mai mulți factori. Timpul este unul dintre aceșt ia și probabil cel mai important
deoarece vom pierde ore întregi cumulate atunci când ne deplasăm la locația respectivă , apoi
până se decide ce produs va fi comandat , pe urmă timpul de așteptare după comandă și desigur
deplasare înapoi spre casă.
O altă problemă ar fi calitatea serviciilor oferite de către cofetărie/patiserie . Acestea la
rândul lor pot fi de două feluri:
➢ Calitatea produsului
➢ Calitatea personalului

2.2. Obiectivele principale
Obiectivul principal al acestui proiect este de a dezvolta o aplicație ușor de utilizat și
intuitivă pentru telefoanele mobile . Aplicația va oferi clientului posibilitatea de a plasa o
comanda direct de pe propriul telefon, iar comanda va fi livrată la adresa completată de către
acesta întreg procesul fiind automatizat, iar angajatorului posibilitatea reducerii costurilor
implicite. Aplicația este de stinată tuturor utilizatorilor, fiind gestionată de către personalul
afacerii , comenzile fiind primite într -un mod cât mai eficient.

4
2.3. Obiectivele secundare
Aplicația va ajuta utilizatorii prin recenziile care au fost făcute deja de către alți
utilizatori, să se orienteze către produsele preferate de aceștia.
De asemenea clienții vor avea tot timpul copia fizică a meniului respectiv confirmarea vizuală
a faptului că, comanda a fost plasată corec t.

5
3. STUDIU BIBLIOGRAFIC

3.1 Tipuri de aplicații mobile
Un prim pas în dezvoltarea unei aplicații mobile îl reprezintă alegerea tehnologiilor în
care urmează să fie implementată . Criteriile de selecție a tehnologiei este influențat ă în cea mai
mare parte de platforma respectiv platformele pe care va rula aplicația .
În funcție de aplicabilitatea lor, aplicații le se împar t în mai multe categorii, iar aici am
ales cele mai utilizate 3 tipuri :
➢ Aplicații Web Hibride
➢ Aplicații Native Hibride
➢ Aplicații complet Native
În continuare voi face o scurta descrie a ceea ce înseamnă aplicați i native respectiv aplicații
hibride pentru a înțelege mai bine conceptele care se ascund în spatele acestora .
Un utilizator de dispozitive mobile poate face diferența foarte ușor între aplicațiile mobile
native sau cele hibrid e.
Datorită timpului de răspuns superior și faptului că acesta are acces la diferite
componente hardware ale dispozitivului (bluetooth, camera foto sau cea frontală, altele),
aplicațiile native pot fi destul de atractive pentru oricine. O aplicație nativă care respectă
regulile de dezvoltare specifice platformei pentr u care este destinată, nu va folosi niciodată
aceleași resurse grafice (ex. butoane, icoane, fundaluri pentru liste, etc. ) pentru mai mult de o
platformă. Aceasta din cauză că aplicațiile native trebuie să păstreze din comportamentul și
designul sistemului de operare pe care rulează. Acestea trebuie să se integreze în platforma
aleasă de utilizatorul final.
Aplicațiile hibrid de regulă sunt formate dintr -o componentă nativă de tip webbrowser
care poate accesa diferite funcționalități ale platformei pe care rulează (ex. camera video, lista
de contacte, etc.). De regulă aplicațiile hibrid au același design grafic pe toate platformele pe
care au fost publicate fără să țină cont de ghidul de implementare a interfeței cu utilizatorul a
fiecărei platforme pe care rulează aplicația. Este de ajuns să scr ii codul de bază pentru o
aplicație, pentru ca ulterior, ca prin magie aplicația să funcționeze pe mai multe platforme. Din
această cauză dezvoltatorii de aplicații hibrid au mai mult timp pentru idei noi sau dezvolt area
unei noi aplicații.

6
Pe scurt aplica țiile native sunt aplica ții specifice platformei pentru care sunt dezvoltate, a șadar
o aplica ție creata pentru Android va func ționa doar pe dispozitive care utilizeaz ă acest sistem
de operare , iar a plica țiile hibride sunt dezvoltate folosind tehnologii web, precum JavaScript,
CSS sau HTML. Acestea sunt create pentru a func ționa pe mai multe tipuri de dispozitive.
Pentru a ajunge la o concluzie în vederea alegerii modelului de aplicație este necesar să
cunoaștem detal iile tehnice din spatele fiecărui mecanism, iar ca s ă facem asta vom evidenția
părțile pozitive și negative pentru fiecare aplicație în funcție de anumite criterii.
Platformele de dezvoltare care le -am considerat cele mai importante sunt cei doi giganți care
conduc piața în prezent și anume Android respectiv iOS .

3.1.1 Aplicații Web Hibride
Rapiditate și performanță :
➢ Rulează în webview -uri (sistem care procesează conținut web), consumând mai mult
procesor și mai multă memorie .
Cod și scalabili tate a aplicației pe alte sisteme :
➢ Cea mai mare parte a codului poate funcționa și pe altă platformă (Android/iOS), dar
deseori sunt necesare componente personaliza te.
Potrivite pentru un MVP (Produs Minim Viabil) :
➢ Ideal pentru a testa o idee, spre a oferi utilizatorilor o versiune simplă a aplicației .
Framework -uri și Tehnologii folosite :
➢ Ionic Framework – React, Angular, Vue; JavaScript .
Debugging (depanare și depi stare a problemelor) :
➢ Mai greu de găsit probleme specifice platformei (Android/iOS). Cea mai mare parte a
depanării se întâmplă cu uneltele disponibile în browser .
Ecosistemul :
➢ O comunitate bună și în creștere, în principal comunitatea open source. Unele module
scrise de la zero pot fi utile .
Ușurința accesării diverselor funcții ale telefonului :
➢ Mai lent și nu foarte eficient datorită mai multor straturi între codul scris și har dware .
Convenții de stilizare (UI) și experiență (UX) specifice platformei Android sau iOS :
➢ Pentru a se potrivi cu interfața platformei utilizatorului, trebuie să se folosească de la
zero o bibliotecă sau componente specifice platformelor scrise de la 0. I nterfață mai
lentă .

7
Timp și cost :
➢ Cod reutilizabil în principiu pentru toate platformele. Costuri mai mici datorită
tehnologiilor web, dar pot crește din cauza nevoii de a genera senzația unei aplicatii
native .

3.1.2 Aplica ții Native Hibride
Rapiditate ș i performanță:
➢ Performanțe asemănătoare cu cele native . Execuția nativă a codului .
Cod și scalabilitate a aplicației pe alte sisteme:
➢ Cea mai mare parte a codului poate funcționa și pe altă platformă (Android/iOS), dar
deseori sunt necesare componente pers onalizate .
Potrivite pentru un MVP (Produs Minim Viabil):
➢ Util dacă doriți să construiți un MVP mai șlefuit, pe care să construiești pe el pe termen
lung.
Framework -uri și Tehnologii folosite:
➢ Flutter, React Native, Xamarin .
Debugging (depanare și depistare a problemelor):
➢ Instrumente și mecanisme excelente pentru a găsi probleme. În unele cazuri, depanarea
cu unelte native ar putea fi necesară .
Ecosistemul:
➢ Documentație foarte bună de la proprietarii fremework -urilor . Comunitate este mare.
Poate fi nevoie de analiza documentației native pentru probleme complexe .
Ușurința accesării diverselor funcții ale telefonului:
➢ Toate API -urile de hardware disponibile, dar în dependență cu autorul framework -ului.
Convenții de stilizare (UI) și expe riență (UX) specifice platformei Android sau iOS:
➢ Aspect și experiență aproape native. Componentele stilistice standard sunt furnizate de
obicei de către autorul framework -ului.
Timp și cost:
➢ Mare parte din cod este reutilizabil. Puțin mai costisitor dator ită programatorilor care
trebuie să cunoască și particularitățile specifice ale sistemelor de operare .

8
3.1.3 Aplicații complet Native
Rapiditate și performanță:
➢ Cea mai bună performanță datorită executării native a codului .
Cod și scalabilitate a aplicației pe alte sisteme:
➢ Necesită echipe separate pentru ambele platforme Android și iOS .
Potrivite pentru un MVP (Produs Minim Viabil):
➢ Nu este cea mai bună opțiune pentru un MVP, fiind o alegere complexă și mai
costisitoare pentru aces t stagiu .
Framework -uri și Tehnologii folosite:
➢ Java, Kotlin, Objective -C, Swift/SwiftUI .

Debugging (depanare și depistare a problemelor):
➢ Profilarea și optimizarea proceselor se face ușor ..
Ecosistemul:
Comunitate mare, suport mare din partea proprietarilor de platforme – Google și Apple .
Cea mai bună documentație .
Ușurința accesării diverselor funcții ale telefonului:
➢ Acces direct la tot hardware -ul dispozitivului , fără legături intermediare
Convenții de stilizare (UI) și experiență (UX) speci fice platformei Android sau iOS:
➢ Fără compromisuri. Utilizatorii vor simți aplicația foarte familiară. Aspectul corespunde
unu la unu cu sistemul de operare .
Timp și cost:
➢ Mai scump. Echipe de dezvoltare separate pentru platformele iOS și Android .[1]
Informațiile oferite mai sus despre tipurile de aplicații care pot fi dezvoltate și instalate pe
sistemul de operare al telefoanele inteligente consider că sunt suficiente pentru a lua o decizie
legată de tipul aplicației și desigur platforma pe care va ru la.
Având în vedere atât experiența în programare cât și cantitatea de informație care îmi
stă la dispoziție consider că aplicația complet nativă este cea mai buna alegere aceasta
dezvoltându -se pe un singur tip de platforma în prima faza. În urma unui sc urt studiu legat de
procentajul cotei de piață a celor două platforme , Android și iOS , cu o cota de peste 74%
Android este liderul detașat și alegerea mea ca platforma de dezvoltare. [2]
Concret în prima fază am ales ce tip de aplicație voi crea și pe ce platforma va rula, urmând ca
în cea de a doua faza să aleg care tehnologie voi folosi pentru partea de back -end ( Framework –
uri și Tehnologii ).

9
În ceea ce mă privește, ca și tehnologie nativ ă pentru dezvoltarea acestui proiect am să
aleg Java deoarece pe de -o parte consider că este o tehnologie stabilă, bine „înfiptă ” și pe de
altă parte informațiile se găsesc mult mai ușor .

3.2. Tehnologii de stocare și baze de date
Aplicațiile respectiv afacerile de acest gen sunt bazat e pe clienți, aceștia când doresc să
se înregistreze sau să plaseze o comandă, vor avea nevoie de anumite date personale(număr de
telefon, nume, adresă, etc.), toate aceste informații trebuie salvate și stocate într-o bază de date.
Pentru proiectul curent avem posibilitatea de a utiliza tehnologiile cloud computing pentru
stocarea datel or permanente și baze de date locale pentru acele date care sunt utilizate doar o
perioadă scurtă.

3.2.1. Cloud computing
Confo rm cărții lui George Reese [ 3] cloud este mai mult decât internet, cloud este locul
în care găsești tehnologia de care ai nevoie când ai nevoie și pentru cât timp ai nevoie. Unul din
avantajele serviciilor de tip cloud este faptul că plătești doar ce și câ t folosești. Cloud poate
oferii atât software cât și infrastructura, poate fi o aplicație accesată prin internet sau un server.
Conform NIST [ 4] (National Institute of Standards and Tehnology) cloud computing
reprezintă un model care permite acces omnipre zent, convenabil și la cerere la o rețea comună
de resurse configurabile (de exemplu: servere, depozitare de date, aplicații, servicii) care pot fi
oferite rapid cu un management minim și cu interacțiunea provider -ului de servicii.

Figură 3.1 . Diagrama conceptuală a Clou d computing

10
3.2.1 .1. Caracteristici esențiale
➢ Aplicațiile sau serviciile software sunt stocate la distanță
➢ Utilizatorul are acces la diverse servicii sau aplicații software prin intermediul
internetului
➢ În majoritatea cazurilor utilizatorul nu trebuie să instaleze nimic pe mașina gazdă, totul
se face din browser
➢ Acces și administrare, bazat pe rețea, la software
➢ Costuri reduse pentru implementare și întreținere
➢ Mobilitate crescută pentru forța de lucru la nivel global
➢ Infrastruc turi flexibile și scalabile
➢ Permite focusare asupra inovării în loc de întreținere și implementare
➢ Disponibilitate crescută pentru aplicații de calcul de performanță înaltă pentru afaceri
medii și mici

3.2.1.2. Modele de deployment cloud
➢ Cloud computing are câteva modele de deployment, fiecare cu caracteristici
specifice pentru cei care doresc să treacă la servicii de tip cloud.
➢ Cloud public: folosit de organizații care oferă servicii către publicul sau către un
grup mare de industrii
➢ Cloud priv at: folosi t de o singură organizație.
➢ Cloud hibrid: reprezintă o îmbinare a două sau mai multe cloud -uri care rămân
entități unice dar care comunică prin tehnologi standardizate.

11
Figură 3.2 . Tipurile de Cloud coputing

3.2.1.3. Model de servicii cloud
Principalele modele de servicii cloud declarate de NIST sunt SaaS, PaaS, IaaS.

Figură 3.3 . Structura ierarhică a serviciilor oferite de cloud

➢ Software as a Service (SaaS)
• Mai este cunoscut și ca Application -as-a-sevice(AaaS)
• Aplicația este livrată peste o platformă a Web -ului la utilizatorul final, în mod
tipic prezentând aplicația printr -un navigator

12

• Model în care o aplicație e găzduită ca serviciu pentru clienții care
o accesează prin intermediul internetului
• Aplicațiile sunt livrate printr -un navigator la mii de clienți utilizând o arhitectură
multi -utilizator
• Exemple de utilizare a modelului SaaS:
o Administrarea resurselor clienților
o Conferințe video
o Administrarea de servicii IT
o Administrarea de conținut Web
• Caracteristici cheie :
o Aplicațiile sau serviciile sunt stocate la distanță
o Un utilizator poate accesa aceste servicii sau aplicații software prin
intermediul internetului
o În majoritatea cazurilor, un utilizator nu trebuie să instaleze nimic pe
mașina gazdă
o Acces și administrare la software bazat pe rețea
➢ Platform as a Service (PaaS)
• Platforme le de dezvoltare sunt ofer ite ca servicii
• Spre deosebire de platformele de dezvoltare tradiționale PaaS:
o Suportă mai mulți dezvoltatori în același timp
o Asigură load balancing și fail recovery
o Oferă management integrat al resurselor
o Se plătește doar ce și cât se utilizează
• Serviciile PaaS include :
o Proiectarea aplicațiilor
o Dezvoltare
o Testare
o Lansare
o Găzduire
o Colaborare între echipe
o Integrarea serviciilor Web
o Integrare de baze de date

13
o Securitate
o Scalabilitate
o Stocare
o Administrarea stărilor
➢ Infrastructure as a Service (IaaS)
• Spre deosebire de SaaS și PaaS nu oferă aplicații , ci hardware
• Resurse oferite:
o Spațiu server
o Echipament de rețea
o Memorie
o Cicluri CPU
o Spațiu de stocare

3.3. Baze de date locale
Multe aplicații necesită un simplu tabel de date pentru a efectua o serie de sarcini
esențiale. O modalitate de a adăuga aceste date este printr -o foaie de calcul online, dar o
modalitate mai rapidă și mai simpl ă de a face acest lucru este printr -o bază de date locală .
În zilele noastre, aplicațiile păstrează baza de date local sau fac o copie a ace steia peste
cloud pe dispozitivul local și se sincronizează cu acesta o dată pe zi sau ori de câte ori există o
conectivitate de rețea. Acest lucru va ajuta aplicații le să fie mai rapide și receptive, având
posibilitatea de a funcționa chiar și fără internet.
Bazele de date pentru telefoane mobile trebuie să îndeplinească anumite criterii :
➢ Capacitate mică, deoarece sto carea este limitată pe dispozitivele mobile.
➢ Nu este nevoie de server.
➢ Într-o formă de bibliotecă fără dependență sau foarte limitată (încorporată), astfel încât
să poată fi utilizată atunci când este nevoie .
➢ Rapid și sigur.
➢ Ușor de manevrat prin cod și op țiune de a -l face privat sau partajat cu alte aplicații.
➢ Consum redus de memorie și energie.
Există o mulțime de baze de date mobile pe piață, dar nu toate îndeplinesc cerințele
menționate. [5]

14
3.4. Platforma Android
3.4.1. Descrierea platformei
Android este o platforma software și un sistem de operare pentru dispozitive mobile
bazat pe nucleul Linux, dezvoltat de compania Google, iar apoi de Open Handset Alliance.
Câteva dintre avantajele pe care platforma Android le de ține comparativ cu celelal te
platforme mobile sunt:
➢ Are la baza o arhitectură bazată pe componente
Părți dintr -o aplica ție pot fi concepute și refolosite cu u șurință și în alte aplica ții. Se por
înlocui si construi componentele existente cu versiuni proprii îmbunătă țite. Aceasta va oferi
dezvoltatorului posibil itatea exploatării creativită ții în spa țiul mobil.
➢ Constituie o platformă open -source
Produc ătorii de telefoane mobile pot folosi și customiza platforma fără a plăti bani
suplimentari pentru licen țe. Dezvoltatorii a u avantajul ca platforma este independentă și nu este
blocată în nici un furnizor care poate ajunge să fie achizi ționat de către alte companii.
➢ Încorporeaz ă o multitudine de servicii predefinite
Serviciul de localizare bazat pe GPS permite u tilizatorului să afle tot timpul informa ții
despre locul în care se găse ște la un moment dat. Pentru stocarea datelor Android pune la
dispozi ția dezvoltatorului un sistem de gestiun e de baze de date bazat pe SQLite. Pentru
navigarea pe Web, Android are încorporat un bro wser.
➢ Permite o gestionare automată a ciclului de via ță a aplica ției
Programele sunt izolate unele de altele prin mai multe straturi de securitate, care vor
oferi un nivel de stabilitate superior oricăror platforme mobile existente. Utilizatorul nu va
trebui să -si mai facă griji despre programele ce rulează în sistem la un moment dat și nici nu va
trebui să închidă anumite aplica ții pentru a putea face loc altora. Platforma Android este
optimizată pentru consumul redus de energie și de memorie.
➢ Oferă o gra fică și sunet de înaltă calitate
Pentru a reda con ținutul 3D dezvoltatorul are la dispozi ția sa librăria Open GL. De
asemenea anima țiile pot fi redate cu ajutorul flash player -ului încorporat. Pentru sunete, susține
portabilitatea rulării pe o gamă largă de hardware curente și viitoare
Toate programele sunt scrise în Java și executate pe ma șina virtuală Dalvik, exist ând
posibilitatea po stării codului pe ARM, x86 și alte arhitecturi.
De asemenea, platforma Androi d pune la dispoziția de zvoltatorilor o serie de unelte
utile pentru dezvoltarea aplicațiilor precum un emulator, unelte pentru debugging, pentru
măsurarea performanțelor aplicațiilor, și posibilitatea de integrare cu Eclipse IDE. Android este

15
dezvoltat con tinuu, fiecare versiune lansată aducând îmbunătățiri la diverse componente deja
existente precum și elemente și func ționalități noi care sa utilizeze cât mai bine resursele fizice
ale dispozitivelor.

3.4.2. Arhitectura platformei Android
Arhitectura dup ă care este structurata platforma Android este ilustrata în figura 3.4.
Nivelele ierarhice indica faptul ca fiecare nivel este dependent de func ționalit ățile oferite de
nivelul inferior acestuia

Figur ă 3.4. Arhitectura sistemului de operare Android

In continuare, vor fi prezentate componentele acestei arhitecturi:
➢ Kernel -ul Linux
Android este construit pe o funda ție solidă: kernel -ul Linux. Creat de Linus Torvalds în
1991, în timp ce era student la Univers itatea din Helsinki, Linux poate fi găsit astăzi pe o
multitudine de dispozitive, de la ceasuri de mână până la supercalculatoare. Linux oferă nivelul

16
de abstractizare hardware pentru Android care să permită portarea acestuia pe diferite
arhitecturi. Pe pl an intern, Android folose ște Linux pentru gestionarea memoriei,
managementul de procese, crearea de re țele, precum și alte servicii predefinite. Utilizatorul nu
are habar de existen ța acestui nivel, dezvoltatorul de aplica ții nu va face apeluri directe căt re el,
dar va trebui sa ia în considerare existen ța lui la baza arhitecturii.
➢ Librăriile native
Următorul strat deasupra kernel -ului îl reprezintă librăriile predefin ite. Aceste librării
sunt scrise în totalitate în C sau C++, compilate pentru arhitectura hardware specială folosită de
telefon și preinstalate de către vânzătorul telefonului. Unele dintre cele mai importante librării
implementate sunt:
• Gestiune Suprafețe – Android utilizează un sistem de manager de ferestre similar cu cel
prezent în Vista sau Compiz, dar mult simplificat. În loc să fie desenate direct pe ecran,
bitmap -urile sunt administrate local și combinate pentru a reda utilizatorului interfa ța
finală . Acest sistem permite crearea unei game largi de efecte vizuale interesante, cum
ar fi ferestrele transparente sau tranzi ția animată între ferestre .
• Grafică 2D și 3D – Elementele 2D și 3D pot fi combinate într -o singura interfa ță în
Android. Librăria va f olosi accelera ția hardware dacă aceasta este prezentă pe dispozitiv
sau un render software în caz contrar .
• Baza de date SQL – Android include o versiune u șoară de sistem de gestiune a bazelor
de date.
Dezvoltatorul poate folosi acest sistem pentru stocare a persistentă a datelor .
Aceste librării nu sunt aplica ții de sine stătătoare, ele există doar pentru a oferi suport pentru
nivelele superioare.
➢ Motorul Android
Android include un set de librării care sus țin o mare parte din func ționalitatea pusă la
dispo ziție de limbajul de programare Java. Prin implementarea lor a rezultat crearea ma șinii
virtuale Java intitulată Dalvik, care a fost special creată pentru Android de către Dan Bornstein
și echipa sa de la Google. Fiecare aplica ție Android rulează într -un p roces propriu și are o
instan ță separată de ma șină virtuală Dalvik. Dalvik a fost astfel scrisă înc ât să permită rularea
mai multor instan țe de ma șină virtuală pe acela și dispozitiv hardware.
Diferen țele dintre Dalvik și mașina virtuală Java standard:

17
• Dalvik VM rulează pe fi șiere .dex care sunt ob ținute prin co nvertirea fi șierelor .class
și.jar în mome ntul compilării. Fi șierele .dex sunt mai compacte și mai eficiente dec ât
fișierele .class pentru a optimiza consumul de m emorie și de energie.
• Bibliotecile de bază Java care vin cu Android sunt diferite atât fa ță de bibliotecile din
Java Standard Edition (Java SE) și de cele din Java Mobile Edition (Java ME). Exist ă
totuși un subset comun de API -uri.
➢ Cadrul pentru Aplicații
Acest nivel se g ăsește peste nivelul librăriilor native și a motorului android . Punând la
dispoziție o platforma de dezvoltare deschisă, Android oferă dezvoltatorilor posibilitatea de a
crea aplicații extrem de variate și inovative și acces la hardware -ul telefonului, la i nformații de
localizare, posibilitatea rulării de aplica ții în fundal, setarea de alarme, notificări și multe altele.
Dezvoltatorii au acces complet la același API care este folosit și de aplicațiile native Android.
Arhitectura este astfel concepută încât să ușureze reutilizarea componentelor: orice aplicație
poate sa -și publice capabilitățile și orice aplicație poate apoi sa folosească aceste capabilități,
sub anumite constrângeri făcute de framework.
Sub toate aplicațiile se g ăsește un set de servicii și sisteme, incluzând:
• un set bogat de componente UI ce pot fi folosite de utilizator pentru a crea o
aplica ție. Acest set include grid -uri , listview -uri , textbox -uri.
• Gestiune Activități – controlează ciclul de via ță al aplica țiilor și modul de comunicare
dintre acestea
• Gestiune Resurse – controlează accesul la resursele non -cod, cum ar fi: string -uri,
layout -uri, imagini
• Furnizori de conținut – aceste obiecte încapsuleaz ă datele și informa țiile care trebuie
împărțite între aplica ții
• Gestiune Notificări – permite notificarea utilizatorului sub diferite forme. [6]

3.4.3. Componentele unei aplica ții Android
Componentele sunt blocuri esențiale ale aplicației Android. Fiecare componentă
reprezintă un punct distinct prin care sistemul poate a ccesa aplicația, și joacă un rol specific
ajutând astfel la definirea comportamentului aplicației. Există șase tipuri diferite de
componente. Fiecare tip are un scop specific și un ciclu de viață care definește cum este creată
și distrusă respectiva compon entă.

18
Activități
Activită țile reprezintă partea de prezentare într -o aplica ție. Fiecare ecran din aplica ție
va fi o extensie a clasei Activit y. O aplica ție poate fi alcătuită dintr -o singură activitate sau
poate să con țină mai multe în func ție de design -ul conceput de dezvoltator. De obicei, una dintre
activi tăți este marcată ca fiind prima activitate care să fie prezentată utilizatorului.
Trecerea de la o activitate la alta se realizează prin apelul explicit în cadrul primei
activită ți a rutinei care o porne ște pe cea de a doua. Cele mai multe activită ți sunt proiectate
pentru a ocupa întregul ecran, dar se pot crea activită ți care sunt semitransparente, plutitoare,
sau dialog -uri. Fiecare act ivitate este alcătuită dintr -o structură de vederi.
Vederile reprezintă elementele de interfa ță de bază în Android. De exemplu, o vedere
poate prezenta o imagine și să reac ționeze c ând utilizatorul apasă pe ea. Pentru a crea o
activitate, dezvoltatorul trebuie să extindă clasa de bază Activity și să const ruiască în interiorul
ei interfa ța și comportamentul dorit. Componentele unei aplica ții au un ciclu de via ță, un început
când Android le instan țiază pentru a ră spunde la anumite inten ții și un sf ârșit atunci când
instan țele sunt distruse.
Starea fiecărei activită ți este determinată de pozi ția sa cu privire la stiva de activită ți, o
colec ție FIFO (first in first out) ce con ține toate activită țile care rulează la un moment dat în
sistem. Când o nouă activitate este începută, aceasta este mutată în c apul stivei. În cazul în care
utilizatorul navighează înapoi folosind butonul dedicat sau c ând activitatea este închisă,
activitatea imediat următoare este împinsă pe stivă și devine activă. Această stivă este folosită
și de manager -ul de memorie pentru de terminarea priorită ții aplica ției și eliberarea resurselor
de memorie.
O activitate are, în esen ță, trei stări:
➢ Este activă sau se execută atunci când este în prim planul ecranului (se situeaz ă în capul
stivei de activită ți). Aceasta este activitatea cu ca re interac ționează utilizatorul la un
moment dat.
➢ Este întreruptă în cazul în care și-a pierdut focus -ul, dar este încă vizibilă pentru
utilizator. O altă activitate se află peste activitatea întreruptă dar o parte a activită ții
întrerupte este încă accesi bilă utilizatorului. O activitate întreruptă este men ținută în
viață (își men ține starea în întregime, informa țiile despre membrii și rămâne ata șat la
managerul de ferestre), dar poate fi oprită de sistem în situa ții de utilizare excesivă a
memoriei.

19
➢ Este oprită în cazul în care este complet acoperită de o altă activitate. Informa țiile despre
stare sunt men ținute, dar activitatea respectivă nu mai este vizibilă pentru utilizator și
va fi distrusă c ând va fi nevoie să se elibereze memoria.

Figur ă 3.5. Ciclul de via ța al unei activit ăți

Intenții (Intent)
Intent -urile reprezintă un mecanism de mesaje ce permi te declararea inten ției ca o
acțiune de efectuat, de obicei, cu un anumit set de date. Inten țiile suportă interac țiunea dintre

20
două componente diverse aflate în aceia și aplica ție sau în aplica ții diferite. Ele sunt responsabile
cu transformarea unei colec ții de componente independente într -un singur sistem interconectat.
Una dintre cele mai comune utilizări ale inten țiilor îl reprezintă pornirea unei activită ți, fie în
mod explicit (prin specificarea clasei activită ții care se dore ște a fi încărcată), fie implicit (prin
cererea ca o ac țiune să fie efectuată pe un set de date). O aplica ție poate înregistra un broadcast
receiver care să asculte și să reac ționeze la aceste Intent -uri. Android folose ște intent -uri
broadcast pentru a anun ța evenimente de sistem, cum ar fi schimbarea stării conexiunii de
internet sau nivelul bateriei telefonului.
Aplica țiile native Android, cum ar fi SMS manager -ul sau manager -ul de telefonie ,
înregistrează componente care ascultă aceste intent -uri broadca st și reac ționează corespunzător
prin alertarea utilizatorului cu privire la schimbările din sistem. Pentru a începe în mod explicit
o activitate trebuie creat un nou intent specificând contextul curent al aplica ției, precum și clasa
de activitate ce trebu ie lansată. Această inten ție trebuie trimisă ca parametru metodei
startActivity, a șa cum se arată în următorul fragment de cod:
Intent intent = new Intent(MyActivity.this, MyOtherActivity.class);
startActivity(intent);
Servicii
Un serviciu este o componentă care rulează în background pentru efectuarea de operații
de durată sau pentru a permite accesul la distanță al proceselor. Un serviciu nu dispune de o
interfață utilizator. De exemplu, un serviciu poate efectua un proces în background, în timp ce
utilizatorul se află în cadrul altei aplicații. O altă componentă, precum o activitate, poate începe
serviciul, îl poate lăsa să ruleze sau îl poate îngloba pentru a interacționa cu acesta. Un serviciu
este implementat ca o subclasă a clasei Service.
Receptorii de broadcast
Un receptor de broadcast este o componenta care r ăspunde anun țurilor de broadcast ale
sistemului. Multe broadcasturi își au originea în cadrul sistemului, de exemplu, un anun ț
broadcast legat de închiderea ecranului , terminarea bateriei, sau efectuarea unei fotografii.
Aplica țiile pot ini ția și ele broadcast -uri, precum anun țarea altei aplica ții de faptul c ă anumite
date au fost desc ărcate și se afl ă pe dispozitiv disponibile spre utilizare. Cu toate c ă receptorii
de broadcast nu afi șează o interfa ță utilizator, pot crea o bar ă de notificare a status -ului pentru
a înștiința utilizatorul de momentul apari ției unui eveniment de broadcast. Un receptor de
broadcast este implementat ca și subclasa a clasei BroadcastReceive r și fiecare broadcast este
livrat ca un obiect Intent.

21
Fișierul manifest Android
Fiecare proiect Android include un fi șier manifest, AndroidManifest.xml, stocat în
directorul rădăcină al proiectului. În acest fi șier sunt descrise componentele folosite în aplica ție
și alte informa ții referitoare la permisiuni sau librării ce trebuie legate de aplica ția curentă. Se
poate def ini versiunea de Android folosită de aplica ție, precum și o temă preferată pentru
afișarea interfe ței.
Structura acestui fi șier impune prezen ța unui tag răd ăcină <manifest> urmat de tag -ul
<application> în interiorul căruia vor fi descrise componentele ca re alcătuiesc aplica ția. Pentru
definirea de permisiuni se va folosi tag -ul <uses -permission>, urmat de numirea permisiunii
dorite.
Deoarece sistemul rulează fiecare aplicație într -un proces separat cu fișiere de
permisiuni care restricționează accesul la alte aplicații, aplicația nu poate acționa direct o
componentă din cadrul altei aplicații. Sistemul Android, în schimb, poate. Astfel, pentru a activa
o componentă a altei aplicații trebuie trimis un mesaj sistemului care să specifice in tenția
(Intent) de a începe o anumită componentă. Sistemul activează apoi componenta respectivă.

3.5. Aplicații similare
În prezent, strict pe acest gen de afacere nu am găsit aplicație dezvoltată pe platforma
Android. Am găsit în schimb aplicații apropiate ca gen de activitate și am ales 2 dintre acestea,
iar mai jos am făcut o scurtă comparație între sistemele principale dezvoltate în cadrul acestora.
Due Fratelli Rom ânia1
Este o aplicație dezvoltată pentru un restaurant care oferă utilizatorilor posibilitatea de
a comanda produse le puse la dispoziție de către acesta .
Utilizatorul are posibilitatea de vizualiza meniul restaurantului fără ca acesta să trebuiască să
creeze un cont de autentificare. Dar atunci când dorește să plaseze o comandă aplicaț ia solicită
utilizatorului că este nevoie de un cont pentru a putea comanda. Acest lucru eu îl vad un
dezavantaj, deoarece clientul va trebui s ă facă mulți pași în plus pentru a putea comanda, a cesta
fiind un lucru enervant și pierdere de timp.
De asemene a utilizatorului îi lipsește recenziile altor clienți, iar în zilele noaste chiar și
asta poate fi un factor decisiv în atragerea de noi utilizatori și luarea unei decizii de comandare
a unui anumit produs.

1 https://play.google.com/store/apps/details?id=com.inmobito.duefratelliapp

22

Figur ă 3.6. Due Fratelli Romania

Pizza San Marco2
Este o aplicație dezvoltată pentru un restaurant care oferă utilizatorilor posibilitatea de
a comanda produsele puse la dispoziție de către acesta.
Utilizatorul are posibilitatea de vizualiza meniul restaurantului fără ca acesta să trebu iască să
creeze un cont de autentificare. Dar atunci când dorește să plaseze o comandă aplicația solicită
utilizatorului că este nevoie de un cont pentru a putea comanda. Acest lucru eu îl vad un
dezavantaj, deoarece clientul va trebui să facă mulți pași î n plus pentru a putea comanda, acesta
fiind un lucru enervant și pierdere de timp.
De asemenea utilizatorului îi lipsește recenziile altor clienți, iar în zilele noaste chiar și
asta poate fi un factor decisiv în atragerea de noi utilizatori și luarea une i decizii de comandare
a unui anumit produs.

2 https://pl ay.google.com/store/apps/details?id=tm.pizzasanmarco.at

23

Figur ă 3.7. Pizza San Marco

Funcții principale Propria aplicație Due Frattelli Pizza San Marco
Autentificare ✓ ✓ ✓
Recenzii Utilizatori ✓ x x
Geo Locație x ✓ x
Notificare ✓ ✓ ✓
Distribuire poze ✓ x x
Plata cu cardul x x x
Tabel 3.1. Avantaje și dezavantaje între aplicații

24
4. ANALIZĂ ȘI FUNDAMENTARE TEORETICĂ

4.1. Cerințele sistemului
Cerințele unui sistem pot fi clasificate în cerințe funcționale și cerințe non-funcționale.
Cerințele funcționale prezintă acele funcționalități concrete pe care sistemul trebuie sa le ofere
astfel încât să răspundă cerințelor de business. Cerințele non -funcționale sunt acele cerințe care
nu implică realizarea unei funcționalităț i, dar care sunt necesare ca funcționalitățile să poată fi
utilizate.

4.1.1. Cerințe funcționale
Acestea descriu funcțiile pe care trebuie să le realizeze sistemul și modul în care un
utilizator poate interac ționa cu aplicația. Ele pot fi calcule, proces ări de date sau alte
funcționalități specifice care definesc ce ar trebui să facă un sistem .
Proiectul principal a fost împărțit în doua aplicații, prima fiind destinată utilizării de
către clienți, iar cea de -a doua va fi utilizată strict de personalul cofetăriei/patiseriei . Am ales
această variantă deoarece pentru mine este mult mai simplu să gestionez dezvoltarea aplicației
nefiind așa mule componente (clase, layout -uri, pachete, etc.) și totodată erau necesare ascunse
anumite elemente de UI(User Inter face) atunci când utilizatorul avea dreptul se administrator
sau era un simplu utilizator.
Pe de altă parte apar mult mai puține probleme de intersectare a căilor, iar pentru
utilizatorii finali o interfață simplă în care informațiile se găsesc ușor este mult mai atractivă
decât una complexă care pentru unii necesită manual de utilizare.
Funcționalitățile primei aplicații(Aplicația Client) cât și celei de a doua
aplicație(Aplicația de Gestiune) se bazează foarte mult pe principiile de funcționate ale un ei
afaceri de acest gen , doar c ă aplicațiile oferă mai mult sau mai puțin în funcție din ce punct de
vedere privim lucrurile.
Funcționalitățile Aplicației Client:
➢ Sistem de înregistrare a noilor clienți
➢ Sistem de verificare a numărului d e telefon
➢ Sistem de autentificare
➢ Sistem de plasare comenzi
➢ Sistem de feedback(comentarii și rating)

25
➢ Posibilitatea de a distribui poze pe rețelele de socializare cu produsele preferate(ajută la
promovarea afacerii și a aplicației)
➢ Sistem de schimbare a par olei
➢ Sistem de recuperare a parolei
➢ Aplicația are posibilitatea de a ține mine utilizatorul, adică nu mai trebuie introduse
informațiile de autentificare de fiecare dată când dorim să comandam ceva.
➢ Sistem de apelare a numărului de telefon direct din aplicație
Multe dinte aceste funcționalități sunt comune utilizatorilor deoarece ele se găsesc în
majoritatea aplicațiilor mobile.
Funcționalitățile Aplicației de Gestiune :
➢ Sistem de autentificare
➢ Sistem de notificări(atu nci când este înregistrată o noua comandă automat se va primi o
notificare)
➢ Sistem de creare de categorii și sub categorii
➢ Sistem de afișare a comenzilor
➢ Aplicația are posibilitatea de a ține mine utilizatorul, adică nu mai trebuie introduse
informațiile d e autentificare de fiecare dată.
De asemenea mai putem considera ca funcționalitate pentru ambele aplicații, afișarea
categoriilor si subcategoriilor de produse. Pentru început consider ca toate aceste funcții ale
celor două aplicații sunt suficiente în ad ministrarea și de ce nu promovarea produselor oferite
de producător .

4.1.2. Cerințe non -funcționale
În ingineria sistemelor, o cerin ță non-funcțională este o cerință care specifică criteriile
care pot fi utilizate pentru a descrie modul în care func ționează sistemul, în timp ce cerințele
funcționale descriu ce ar trebui să facă sistemul.
Cerințele non -funcționale sunt vitale pentru succesul sistemelor software. În cazul în care
acestea nu sunt abordate în mod corespunzător. Cerințele non -funcționale p entru sistemul
realizat sunt urm ătoarele:
➢ Utilizabilitatea
Interfa ța aplicației trebuie să fie cât mai simplă, astfel înc ât un utilizator nou să poată
folosi aplicația fără s ă consulte un manual de utilizare. Designul interfeței grafice, dar și
plasarea elementelor în locații specifice, familiar utilizatorului, reprezintă elemente esențiale
pentru a atrage câți mai mulți utilizatori .

26
O aplicație cu o interfață prietenoasă, ușor de învățat, de navigat și care face ca
obiectivul să fie atins rapid, este dorită de utilizator în defavoarea unei aplicații cu multe
funcționalități, dar care nu beneficiază de o interfață corespunz ătoare.
Interfa ța are un rol decisive în aprobarea succesului aplica ției.
➢ Extensibilitatea
Această proprietate non -funcțională a sistemului m ăsoară cât de ușor se pot adăuga noi
funcționalități aplica ției. Implementarea sistemului a fost realizată astfel înc ât dezvoltările
viitoare s ă poate fi f ăcute cu ușurință și să nu degradeze modul de funcționare existent.
Adăugarea de noi funcționalități se realizează ușor în cadrul proiectelor bine structurate.
➢ Performanța
Ca și indicator de calitate reprezintă o măsură care definește volumul de procesări pe
care o aplicație trebuie să le poată realiza pe o unitate de timp sau termenul car e trebuie respectat
pentru finalizarea corectă a unei aplicații. Sistemul realizat prezintă un timp de r ăspuns scurt
pentru procesarea datelor, o rată de utilizare ridicată și o utilizare scăzută a resurselor
sistemului.
Performanța este necesară pentru a putea asigura utilizarea și funcționarea în condiții
optime a sistemului. S -a pus ac cent pe implementarea unui sistem care comunică în timp real
cu clientul.
➢ Scalabilitate
Această proprietate arată capacitatea unui sistem de a suporta corect un volum mai mare
de date sau de a permite mărirea sau extinderea acestuia . Un sistem de pr elucrare a datelor este
scalabil dacă atunci c ând volumul de date pe care le pr elucrează devine mai mare, iar sistemul
se comportă similar, f ără defecțiuni. De asemenea , un sistem este scalabil și dacă acesta oferă
rezultate îmbunătățite în condițiile în care sunt adăugate resurse suplimentare .
➢ Securitate
Cea mai importantă cerință non -funcțională este securitatea, presupune protecția
împotriva atacurilor. Utilizatorii înregistra ți vor un user și o parola ,iar fiecare utilizator se
loghează pentru a avea acces la sistem, în cazul în care un utilizator nu este înregistrat, acesta
nu poate accesa sistemul. În funcție de rolul utilizatorului se restricționează accesul acestu ia
➢ Accesibilitatea
Accesibilitatea este reprezentată de modul simplu în care se poate accesa aplicația.
Datorită faptului ca sistemul realizat este o aplica ție mobilă , se poate accesa foarte ușor prin
descărcarea acesteia din magazinul de aplicații Android, acesta venind instalat pe toate
telefoanele care au sistem de operare Android și desigur avem nevoie și de conexiune la internet

27
➢ Disponibilitatea
Această cerin ță non -funcționala este reprezentată de momentele în care sistemul poate
fi utilizat. Aplicația va avea un grad ridicat de disponibilitate datorită folosirii serviciilor
Firebase.

4.2. Tehnologii și Baze de Date utilizate
4.2.1. Firebase
Datorită celei mai bune capacități în timp real din cl asa sa, a API -urilor instinctive,
consolei ușor de utilizat și a sistemului de analiză pe care le oferă, am ales Firebase ca și
tehnologie cloud computing .
Firebase3 reprezintă un serviciu cloud creat pentru a furniza date pentru aplicații
colaborative, în timp real. Este o platformă foarte utilizată pentru dezvoltarea aplicațiilor mobile
și web deoarece oferă multe servicii care ne scutesc de implementarea unui server auxiliar.
Firebase devine s erverul nostru , API -ul nostru și locul de stocare a datelor. Scopul Firebase,
descris în cartea lui L. Moroney [7], este de a oferi uneltele și infrastructura de care ai nevoie
pentru a crea cele mai bune aplicații, de a dezvolta o afacere de succes. Fireb ase nu reprezintă
un înlocuitor al API -urilor existente pentru crearea aplicațiilor iOS, Android sau web. El este
mai degrabă o îmbunătățire care îți oferă serviciile comune de care ai putea avea nevoie – bază
de date back -end, autentificare sigură, mesage rie și multe altele. Asta este un beneficiu pentru
că nu mai este necesară crearea lor astfel este posibil focus pe elementele care diferențiază
aplicația de toate celelalte.

Figură 4. 1. Servicii Firebase

3 https://firebase.google.com/

28
Firebase este un Baas (Back -end as a service) ca re oferă numeroase beneficii, printre care:
➢ Ușurința de implementare .
➢ Firebase este deținut și creat în infrastructura Google, lucru care oferă o oarecare
asigurare a performanței și calității serviciului oferit.
➢ Având numeroși utilizatori, este foarte ușor să primești ajutor.
➢ Firebase oferă atât de multe caracteristici care te ajută să salvezi timp și să te focusezi
pe experiența utilizatorului.
Urmează o descriere în detaliu a trei servicii principale utilizate în dezvoltarea acestei
lucrări.

Firebase Authentication
Atunci când un anumit set de informații trebuie oferit unui anumit utilizator, acel
utilizator trebuie să se identifice. Cea mai utilizată formă de identificare este autentificarea, care
este oferită de Firebase Authentication într -un mod ușor de integrat în aplicație și permite
autentificarea cu conturi deja existente cum sun cele de Google sau Facebook.
Majoritatea aplicațiilor au nevoie să cunoască identitatea utilizatorului. Cunoașterea
identității utilizatorului permite aplica ției să salveze datele acestuia în mod sigur în cloud și să
ofere aceeași experiență personalizată pe toate dispozitivele utilizatorului. Firebase
Authentication oferă servicii back -end, SDK ușor de utilizat și librării UI gata create pentru a
autentifica utilizatorii aplicației. Oferă posibilitatea autentificării folosind parole, numere de
telefon sau platformelor Google, Facebook, Twitter.
Pentru înregistrarea conturilor utilizatorilor, vom folosi serviciile de autentificare prin
număr de telefon, aceast ă metodă ne v -a ajuta doar să verificăm dacă numărul de telefon a
utilizatorului este real.

Firebase RealTime Database
Una din cele mai cunoscute facilități pe care Firebase le are este baza de date RealTime
care sincronizează în timp real informația stocată ca JSON pentru fiecare client, urmând
modelul din figura 4.5.
Aceasta este o bază de date NoSQL stocată în cloud. Aceasta oferă sincronizare între
dispozitivele conectate și este utilizabilă chiar și atu nci când nu există conectivitate între rețele
printr -un cache local. Este o bază de date bazată pe evenimente care funcționează foarte diferit
de baza de date SQL tradițională. De câte ori informațiile sunt schimbate în baza de date,
evenimente sunt trimis e către codul client și mai apoi se pot face modificări la interfața

29
utilizatorului ca răspuns la aceste evenimente. Conține un limbaj bazat pe reguli de expresie,
numit Firebase RealTime Database Security Rules, care definesc cum este structurată
informaț ia și ce utilizatori au acces la informații.

Figură 4. 2. Firebase RealTime Database
Firebase Cloud Storage
În plus față de stocarea datelor, stocarea fișierelor de tip foto sau video poate fi utilă, iar
tehnologia care realizează acest lucru este Fireba se Cloud Storage. Firebase Cloud Storage este
un sistem de stocare simplu și eficient din punct de vedere al costurilor, creat pentru Google.
SDK Firebase pentru Cloud Storrage adaugă securitatea Google la fișierele încărcate și
descărcate pentru aplicațiile Firebase, fără a ține cont de calitatea rețelei. SDK se poate folosi
pentru a stoca imagini, fișiere audio, video și alte tipuri de conținut generate către utilizator.

4.2.2. Android Studio
Android Studi o este un mediu de dezvoltare pentru aplicații Android bazat pe IntelliJ.
Acesta oferă o serie de caracteristici care îmbunătățesc productivitatea la crearea aplicațiilor
Android cum ar fi:
➢ Un emulator rapid și eficient
➢ Un sistem flexibil bazat pe Gradle pentru build
➢ Un mediu în care se pot dezvolta aplicații pentru toate tipurile de sisteme cu Android
➢ Modalitate de a adăuga modificările făcute aplicației fără a crea o noua aplicație de tip
apk
➢ Template -uri care ușurează crearea de aplicații
➢ Unelte și framework -uri de testare

30
➢ Suport pentru platforma Google Cloud pentru a face integrarea aplicațiilor în c loud mai
ușoară

4.2.2.1. Debug
Android Studio oferă modalități performante de debug printre care se numără și „inline
debugging” care face parcurgerea codului în etapa de debug mai ușor de urmărit oferind
informații despre variabilele din fiecare linie d e cod pe linia respectiva. Aceste informații permit
dezvoltatorului să vadă detalii ca :
➢ Valoarea variabilei
➢ Obiecte referite
➢ Valoarea returnată de metode
➢ Expresii Lambda și expresii operator

4.2.2.2. Structura proiectelor Android Studio
Proiectele Android conțin unul sau mai multe module cu fișiere de tip cod sursă sau
resurse. Fiecare modul al unei aplicații conține următoarele directoare care se pot observa în
figura 4. 4.:
➢ manifest: conține fișierul AndroidManifest.xml
➢ java: conține fiș iere cu surse de cod și codul pentru testele Junit
➢ rez: conține resursele care nu conțin cod cum ar fi:
o layout -uri xml
o imagini
Pentru adăugarea surselor locale (de exemplu bazele de date locale, în cazul nostru
SQLite) pe dispozitiv este necesară crearea u nui director cu denumirea ”assets” care să conțină
resursele dorite și care sa fie creat în directorul ”app” al aplicației .[8]

4.2.3 SQLite
Pe baza criteriilor enumerate la subcapitolul 3.3. am ales ca și bază de date locală
SQLite, aceasta îndeplinind toate cerințele.
SQLite4 este o bază de date relațional ă, o versiune mai ușoară a SQL conceput ă pentru
aplicații mobil e. Este o bibliotecă în proces care implementează o configurație autonomă care
nu necesită un server pentru a rula , nu necesită configurare, este simplu de folosit de către

4 https://www.sqlite.org/about.html

31
dezvoltatori . Este un motor de baze de SQL încorporat fără vreun proces de server separat, spre
deosebire de orice altă bază de date SQL. Este cea mai răspândită bază de date pentru aplicații
mobile din lume.
SQLite acceptă toate funcțiile bazelor de date relaționale și este o bibliotecă compactă
fiind open -source , care este implicit prezentă în sisteme le principale de operare mobilă . SQLite
poate fi stocat atât pe dis k, cât și în memorie și fiecare fișier de bază de date este un fișier de
unic și poate fi folosit pe mai multe platforme. Este foarte rapid și are nevoie de foarte puțină
memorie pentru a opera.
SQLite este o bibliotecă compactă. Cu toate caracteristicile activate, dimensiunea
bibliotecii poate fi mai mică de 600 KB, în funcție de platforma țintă și setările de optimizare a
compilatorului. [9]

32
5. PROIECTAREA DE DETALIU ȘI IMPLEMENTARE

5.1. Structura bazelor de date
5.1.1. Struc tura bazei de date Firebase Cloud
5.1.1.1. Stocarea datelor
Cloud Firestore este o bază de date NoSQL ce este cloud -hosted. Această bază de date
poate fi accesată de mai mulți clienți rulând sistem e de operare diferite. Accesul la facilitățile
oferite de această bază de date se face folosind SDK -urile native fiecărei platforme. Conform
modelului de date NoSQL, datele sunt stocate în documente ce conțin câmpuri mapate la valori.
Aceste documente sunt stocate în colecții, care sunt containere pentru documentele aplicației,
și folosind aceste containere se pot organiza datele și construi interogări.
Documentele pot stoca diferite tipuri de date, de la tipuri simple la obiecte complexe .
Se pot crea și subcolecții în documente pentru a construi structuri de date ierarhice. Datele
stocate în această bază de date sunt protejate cu Firebase Authentication, permițând accesul
doar la persoanele autorizate, și prin regulile de securitate Cloud Firestore Security Rules pentru
a determina permisiunile de citire și scriere ale aplicației.
Cloud Firestore a fost folosit pentru a stoca informațiile despre produsele ce au fost
adăugate în aplicație de către utilizatori, cu excepția pozei produsului. În schimb, aceste date
au fost stocate în Cloud Storage, iar link -ul spre poza produsului a fost salvată în câmpul ce
stochează informația despre imagine. A fost necesară stocarea pozelor în Cloud Storage
deoarece Cloud Firestore are o limită de 1MB pentr u fiecare document, limită atinsă ușor de
către o poză.
Cloud Storage este un serviciu de stocare ce permite stocarea eficientă a obiectelor.
Acest serviciu prezintă securitate Google pentru fișierele încărcate și descărcate, indiferent de
calitat e. Toate datele din Firebase RealTime Database sunt stocate ca obiecte de tip JSON. Baza
de date rezultată e asemănătoare unui arbore JSON cloud -hosted. Spre deosebire de bazele de
date SQL nu exista tabele, când adăugam date în arborele JSON acestea devin un nod în
structura JSON existentă cu o cheie asociată. Poți introduce chei personalizate sau acestea pot
fi generate automat folosind push().[ 10]
Cheile introduse trebuie să respecte următoarele constrângeri:
➢ Trebuie să fie codificate folosind UTF -8
➢ Trebuie să nu depășească 768 biți

33
➢ Nu pot conține ”.” ,” $”, ”#”, ”[”,” ]”,” /”
➢ Nu pot conține caractere de control ASCII 0 -31 sau 127
În documentul oficial se menționeaz ă faptul că deoarece Firebase RealTime Database
permite date implicate până la 32 nivele , există impresia că așa ar trebui să fie structura
standard. Totuși când preluăm date de la o locație din baza de date primim și nodurile copil. Pe
lângă asta de câte ori permitem acces de scriere sau citire la un nod din baza de date permitem
accesul și la tot ce se afla în acel nod. Din acest motiv e ste indicat să structurăm datele cât mai
simplu .

Figură 5.1. Stocarea imaginilor în Firebase Storage

5.1.1.2. Baza de date în Firebase Cloud
Baza de date creată în cloud este comună pentru cele două aplicații, însă fiecare aplicație
în parte o gestionează diferit, datorită scopului diferit de utilizare a ace stora.
Considerând modul de stocare a datelor am creat structura bazei de date astfel încât să se potrivească
cât mai bine necesități aplicațiilor și am obținut 5 noduri principale: User, Category, Foods, Rating,
Banner .
➢ User
Acest nod conține informații despre utilizatorii deja înregistrați. Fiecare utilizator are o
cheie, această cheie este numărul de telefon validat. Aici se găsesc conturile pentru ambele
tipuri de utilizatori(utilizatorii Aplicației Client respectiv a Aplicației de Gestionar e). Fiecare
cheie conține 4 câmpuri :
• name – aici este salvat numele utilizatorului

34
• Password – aici este salvată parola utilizatorului
• isStaff – acest câmp este folosit pentru a se identifica utilizatorii care se autentifică în
cadrul Aplicatiei de Gestiune
• secureCode – aici este salvat codul pentru recuperarea parolei

➢ Category
Acest nod conține informații despre categoriile de produse care sunt puse la dispoziție
în cadrul ambelor aplicații. Fiecare categorie care există sau care se va crea reprezintă un nod
copil al nodul ui Category. Acest nod copil conține 2 câmpuri :
• name – aici este salvat numele categor iei
• image – aici este salvat link-ul de desc ărcare a imaginii categoriei din Firebase Storage

➢ Foods
Acest nod conține informații despre produsele din fiecare categorie care sunt puse la
dispoziție în cadrul ambelor aplicații. Fiecare produs care există sau care se va crea reprezintă
un nod copil al nodului Foods. Acest nod copil conține 6 câmpuri :
• name – aici este salvat numele produsului
• menuId – aici este salvată cheia categoriei din care face parte produsul
• price – aici este salvat pretul produsului
• image – aici este salvat link-ul de descărcare a imaginii produsului din Firebase Storage
• description – aici este salvată descrierea produsului
• discount – pentru promoții(neutilizat)

➢ Rating
Acest nod conține informații despre recenziile făcute de către utilizatori, pentru fiecare
produs în parte . Fiecare recenzie care există sau care se va crea reprezintă un nod copil al
nodului Rating. Acest nod copil conține 4 câmpuri :
• userPhone – aici este salvat numarul de telefon al utilizatorului cate a facut recenzia
• foodId – aici este salvată cheia prosusului pentru care s -a facut recenzia
• rateValues – aici este salvată valoarea rating -ului facut de către utilizator
• comment – aici este salvat comentariul facut de către utilizator

35
5.1.2. Struc tura bazei de date locale
Este utilizată doar în cadrul Aplicației Client aceasta având două tabele. Rolul pe care
îl îndeplinește baza de date locală în aplicație este acela de a salva câteva date despre produsele
care urmează a fi comandate, până în momentul în care comanda a fost plasată, respectiv rolul
de a susține produsul preferat pentru fiecare u tilizator în parte.
Cele două tabele sunt denumite : Favorites și OrderDetail
➢ Favorites
Această tabelă conține două câmpuri ambele fiind setate ca și Primary Key:
• FoodId – aici se memorează cheia produsului
• UserPhone – aici se memorează numărul de telefon al utilizatorului
Având aceste două câmpuri fiecare utilizator are posibilitatea de a trece un produs în aceast
tabel, chiar dacă o aplicație este utilizată de mai mulți clienți , acest lucru nu va influența
acțiunea altui utilizator.
➢ OrderDetail
Această t abelă conține 6 câmpuri, iar primul câmp adică ID este setat ca Primary Key,
Autoincrement, Unique
• ID – aici valoarea se incrementează automat
• ProducId – aici este memorată cheia produsului
• ProductName – aici este memorat numele produsului
• Quantity – aici este memorată cantitatea produsului
• Price – aici se memorează prețul produsului
• Discount – pentru reducere(neutilizat)
Rolul acest ui tabel este acela de a salva produsele adăugate în coș de către utilizator până în
momentul în care comanda v -a fi plasată, pe urma datele se vor șterge din tabel.
Pentru a se înțelege mai bine structura bazei de date local e(SQLite) voi adăuga Figura 5.1.

Figură 5.1. Structura bazei de date locale

36
5.2. Prezentarea generala a interfeței
Interfața utilizator este alc ătuită dintr -un set de fișiere de tip XML (Extensible Markup
Language ) asociate activităților.
Avantajul definirii elementelor unei interfețe prin metoda XML este separarea interfeței
de codul care controlează elementele definite. Asta înseamnă că implementarea aplica ției este
mult mai logică și mai u șor de urmat, ori de câte ori va fi nevoie să modificăm un element din
interfa ță nu va trebui decât să îi ajustăm proprietă țile din fi șierul XML. Un lucru foarte la
îndemână în platforma Android este sintaxa XML pentru definirea elementelor UI. Acestea
respectă acelea și reguli de definire ca și clasele sau metodele din cod, unde numele clas ei
corespunde cu numele obiectului iar numele metodei corespunde cu atributele pe care le acceptă
obiectul.
În cadrul platformei Android pentru a defini interfața utilizator pentru o activitate
trebuie să folosim o structură care să con țină noduri de tip ViewGroup sau simple View -uri.
Aceasta poate fi cât de complexă sau simplă dorim și o putem crea folosi nd widget -uri și layout –
uri predefinite sau putem crea noi înșine view -uri particularizate.
Pentru a atribui un asemenea layout unei activități trebuie să inserăm următoarea linie
de cod în metoda onCreate():
• setContentView(R.layout.<em>main</em>);
În sistemul Android aceste fi șiere XML sunt percepute ca fiind resurse ale aplicației,
așadar le vom găsi în directorul res/layout în cadrul proiectului nostru. Fiecare fi șier de acest
gen con ține o structură ierarhică de widget -uri și containere care descriu modul în care va arăta
un anumit ecran din aplica ția noastră. XML se aseamănă destul de mult cu HTML deoarece
structura sa este ușor de u rmărit și înțeles.
Elementele de UI(User Interface) utilizate în cadrul celor două aplicații sunt cele mai
comune utilizate în aplicațiile Android. Pentru unele componente am folosit biblioteci pentru a
le da un design mai frumos și desigur pentru a utili za funcțiile suplimentare oferite de către
acestea . De exemplu pentru butonul care adaugă produsele în coș sau pentru butonul care
deschide fereastra pentru recenzii am utilizat biblioteca :
• com.cepheuen.elegant -number -button:lib:1.0.2
În acest proiect am u tilizat mai multe tipuri de elemente de UI, precum :
➢ RecyclerView
➢ Button
➢ ImageView
➢ TextView

37
➢ EditText
➢ CardView
Widgetul RecyclerView5 este o versiune mai avansată și flexibilă a ListView.
RecyclerView este utilizat în cadrul ambelor aplicații pentru afișarea listelor de categorii și
produse, dar și pentru afișarea produselor din coș și de asemenea comenzile care au fost deja
plaste. În modelul RecyclerView, mai multe componente diferite colaborează pen tru a afișa
date. Containerul general pentru interfața utilizator este un obiect RecyclerView pe care îl
adăug ăm layout -ului. RecyclerView se completează cu view -uri oferite de layout manager pe
care noi le furnizăm .
ImageView a fișează resurse de imagine , de exemplu resurse bitmap sau drawable.
ImageView este, de asemenea, utilizat în mod obișnuit pentru a aplica nuanțe pe o imagine și
pentru a gestiona scalarea imaginii. ImageView în cadrul proiectului, este utilizat în toate
situa țiile în care este nece sară descărcarea unei imagini din Firebase Storage sau când este setat
să afișăm o imagine salvată în fișierul drawable .
Button este u n element pe care utilizatorul îl poate atinge sau face clic pentru a efectua
o acțiune. Butoanele în acest proiect sunt utilizate pentru a deschide o altă activitate sau pentru
a adăuga produse în coș sau pentru a deschide o fereastră de dialog.
Aplicațiile deseori trebuie să afișeze date în containere cu stil similar. Aceste containere
sunt adesea f olosite în liste pentru a reține informațiile fiecărui articol. CardView6 oferă o
modalitate ușoară de afișare a informațiilor sub forma unui card care au un aspect constant și
plăcut. Aceste carduri au o altitudine implicită deasupra view group -urilor de conținut, astfel
încât sistemul atrage umbre sub acestea . Cardurile oferă un mod ușor de a conține view group ,
oferind în același timp un stil consecvent pentru container.
CardView -ul în acest proiect este utilizat în cadrul recyclreview pentru afișarea listelor
de categorii și produse.
EditText este element pentru introducerea și modificarea textului.

5.3. Implementarea Aplicați ei Client și Aplicați ei de Gestiune
5.3.1. Părți comune
În cadrul ambelor aplicații am folosit același concept de creare a listelor de categori i și
listelor de produse utilizând recyclerview. De exemplu să luăm cazul listei de categor ii din
Aplicația de gestiune. Prima dată am creat elementele de UI, lista recy clerview și cardview -ul

5 https://developer.android.com/guide/topics/ui/layout/recyclerview
6 https://developer.android.com/guide/topics/ui/layout/cardview

38
ca și componentă de bază a listei , apoi am creat clasa „Category,class” în cadrul căreia am
inițializat constructorii respectiv funcțiile get și set. Apoi în clasa „Home”, am creat un Adapter.
Adap ter-ul este piesa care va conecta d atele noastre la RecyclerView și va determina
ViewHolder -ul care va trebui să fie utilizat pentru a afișa aceste date . Pentru a crea un adapter
trebuie inițializată clasa abstractă „ FirebaseRecyclerAdapter<Category, MenuViewHolder> ”,
pentru asta avem nevoie d e doi parametri după cum se poate vedea. Primul parametru este deja
creat acesta fiind clasa Caregory. Cel de al doilea după cum se poate vedea este un ViewHolder .
ViewHolder este mai mult decât un simplu obiect care conține un view . Este chiar
obiectul care reprezintă fiecare item din lista noastră și va fi folosit pentru afișarea acestuia.
ViewHolder este o clasă abstracta pe care o va extinde clasa „ MenuViewHolder ”. Deci
„MenuViewHolder ” va susține view -ul pentru fiecare item în r ecyclerview fiind responsabilă
de generarea obiectelor view. În această clas ă trebuie inițializate elementele UI din layout mai
exact elementele din cardview pentru a le putea accesa în cadrul adapter -ului. Mai departe se
poate crea obiectul FirebaseRecycl erAdapter , acesta are nevoie să fie configurat. Configurația
se va face cu ajutorul clasei FirebaseRecyclerOptions care controlează modul în care
FirebaseUI populează RecyclerView -ul cu date din baza de date în timp real.
database = FirebaseDatabase.getI nstance();
reference = database.getReference("Category");
FirebaseRecyclerOptions<Category> options =
new FirebaseRecyclerOptions.Builder<Category>()
.setQuery(reference, Category.class)
.build();
După cum se poate vedea acest obiect are nevoie de o referință la baza de date, iar în
cadrul nostru acesta este nodul „Category” și de un model adică „Category.class” . În cadrul
adapter -ului se implementează 2 metode, onBindViewHolder și onCreateViewHolder .
În onCreateViewHolder vom crea o nouă instanță a ViewHolder și vom folosi un layout
personalizat pentru fiecare element , iar în onBindViewHolder vom lega obiectul Category la
MenuViewHolder . Metoda onBindViewHolder folosește biblioteca Picasso pentru a descărca
imaginile din Firebase Storage. În final ini țializăm recyclerview UI, setăm modul în care se vor
afișa elementele în acesta cu LayoutManager și setăm adapter -ul pentru recyclerview , după care
chemăm adapret -ul.

39
5.3.2. Implementarea sistemului de înregistrare
Sistemul de înregistrare este implementat doar în cadrul Aplicației Client . Acesta are
rolul de a înregistra noii utilizatori în urma verificării numărului de telefon. Deci acest sistem
are două etape importante. Prima reprezintă validarea numărului, acest lucru îl vom realiza cu
ajutorul metodelor furnizate de către FirebaseUI, aceasta fiind o bibliotecă, pentru legarea la
baza de date, autentificare și stocare de date în timp real. Metoda care este utilizată pentru
validarea numărului de telefon se numește „PhoneAuthProvider.verifyPhoneNumber ”. Aici
avem nevoie de 5 parametri. Primul este numărul de telefon, al doilea este timpul maxim pentru
executarea acestei metode, al treilea parametru reprezintă unitatea de timp , cel de -al patrulea
parametru este executorul. Când chemăm această metodă, trebuie furnizată o instanță a clasei
abstracte „OnVerificationStateChangedCallbacks ” , care conține implementări ale funcțiilor
callback, acestea gestionând rezultatele solicitării. Această instanță va implementa 3 metode :
onCodeSent, onVerificationCompleted, onVerificationFailed .
onCodeSent este chemată după ce codul de verificare a fost trimis prin sms la numarul
de telefon . Este folosit pentru a verifica codul introdus de utilizator.
onVerificationCompleted această metodă poate fi chemată în două situații :
➢ În unele cazuri număru l de telefon poate fi verificat instant fără a mai fi nevoie să trimită
un cod de verificare
➢ Pe unele dispozitive, serviciile Google Play pot detecta automat sms -urile de verificare
primite și efectua verificări fără acțiunea utilizatorului.
În ambele situ ații numărul de telefon a fost verificat cu succes . Tot în această metodă am creat
detectarea automată a codului.
onVerificationFailed această metodă este apelată ca răspuns la o solicitare de verificare
nevalidată, cum ar fi o solicitare care specifică u n număr de telefon sau un cod de verificare
nevalide. Pentru a verifica codul trimis am creat metoda „verifyCode” care are ca parametru
codul trimis prin sms , acesta fiind preluat automat când este trimis . În această metodă este creat
un obiect al clasei „ PhoneAuthCredential ” în cadrul căruia vom folosi codul de verificare și id –
ul de verificare care a fost trimis către apelul metodei „ onCodeSent ”. Tot aici am apelat metoda
„signInWithCredential ”, aceasta permite utilizatorului să se logheze în Fire base. Metoda are
nevoie de un parametru, acesta fiind obiectul creat mai sus. După ce am creat un obiect al clasei
„FirebaseAuth” și l -am inițializat, am apelat metoda „ signInWithCredential ”, care are nevoie
de parametru transmis din metoda „verifyCode”. Pe urmă am atașat un task și am verificat dacă
acesta a reușit sau nu, iar în funcție de rezultat, utilizatorul va primi un mesaj de eroare sau va

40
fi trimis către o altă activitate. Pentru a înțelege mai bine cele explicate pân ă acuma am atașat
codul mai jo s.

private void sendVerificationCode(String number) {
PhoneAuthProvider.getInstance().verifyPhoneNumber(
number,
60,
TimeUnit.SECONDS,
TaskExecutors.MAIN_THREAD,
mCall Back
);
}
private PhoneAuthProvider.OnVerificationStateChangedCallbacks
mCallBack = new PhoneAuthProvider.OnVerificationStateChangedCallbacks() {
@Override
public void onCodeSent(String s, PhoneAuthProvider.Force ResendingToken
forceResendingToken) {
super.onCodeSent(s, forceResendingToken);
verificationid = s;
}
@Override
public void onVerificationCompleted(PhoneAuthCredential phoneAuthCredential) {
String code = phoneAuthCredential.getSmsCode();
if (code != null) {
progressBar.setVisibility(View.VISIBLE);
verifyCode(code);
}
}
@Override
public void onVerificationFailed(FirebaseException e) {
Toast.makeText(OtpActivity.this, e.getMessage(), Toast.LENGTH_LONG).show();
}
private void verifyCode(String code) {

41
PhoneAuthCredential credential = PhoneAuthProvider.getCredential( verificationid,
code);
signInWithCredential(credential);
}
private void signInWithCredential(PhoneAuthCredential credential) {
mAuth.signInWithCredential(credential)
.addOnCompleteListener(new OnCompleteListener<Auth Result>() {
@Override
public void onComplete(@NonNull Task<AuthResult> task) {
if (task.isSuccessful()) {
String phonetest = getIntent().getStringExtra("phone");
Intent intent = new Intent(OtpActivity.this, SingUp.class);
intent.putExtra("phonetest", phonetest);
startActivity(intent);
finish();
} else {
Toast.makeText(OtpActivity.this,task.getException().getMessage(),
Toast.LENGTH_LONG).show();
}
}
}); }

Dacă taskul a reușit prima etapă este completă și mai rămâne ultima etapă . Aici
utilizatorul trebuie să completeze niște câmpuri cu date, aceste urmând a fi salvare în Firebase
Cloud. Pentru a face asta trebuie să creăm o referință către nodul „User” din baza de date, aici
fiind locul unde se salvează conturile utilizatorilor. Apoi vom inițializa constructorul clasei
„User” și îi setăm datele introduse de către utilizator. Pe urmă vom folosi funcția child () pe
referința creată. Cu ajutorul acestei funcții vom crea un nod copil în cadrul nodului părinte
„User” care va seta ca și cheie numărul de telefon al utilizatorului, iar apoi utilizând funcția
setValue care primește ca parametru obiectul care conține d atele introduse de utilizator, vom
salva valorile în cadrul acestui nou nod creat.

42
5.3.3. Implementarea listei de sugestii a produselor
Lista de sugestii a produselor din cadrul sistemului de căutare necesită accesare datel or
stocate în Firebase RealTi me Database , pentru asta trebuie să creăm o referință către ramura
arborelui din baza de date pe care se afla datele dorite apoi putem sa parcurgem acea ramur ă
cât de adânc dorim prin folosirea funcției ”child()” care returnează o listă cu toate subnoduril e
nodului curent.
De exemplu daca am dori s ă extragem lista de produse dintr -o oarecare categorie de
produse prima data trebuie să creăm o referință către „Foods” , adică nodul în care sunt salvate
toate produsele, apoi pe baza acelei referințe ordonăm dat ele rezultate după câmpul „menuId ”
acesta fiind cheia categoriei din care face parte produsul și le comparăm cheia categorie pentru
a afișa strict acele produse din categoria selectată . Datele returnate de Firebase sunt de tip
DataSnapsot aceste date se po t mula pe clasele aplicației folosind funcția getValue() și
specificând ca parametru pentru aceast ă funcție , clasa pe care trebuie să se muleze datele , în
cazul nostru „Foods .class” apoi adăugam fiecare produs găsit în lista „ suggestList ” și pe urmă
o afișăm în bara de căutare „ materialSearchBar.setLastSuggestions(suggestList) ”. Pentru a
înțelege mai bine ce am dorit sa explic, am copiat mai jos funcția respectivă. Această funcție
este utilizată doar în Aplicația Client.

reference = database.getReferen ce("Foods");
categoryId = getIntent().getStringExtra("CategoryId");
private void loadSuggest() {
reference.orderByChild("menuId").equalTo(categoryId).addValueEventListener(new
ValueEventListener() {
@Override
public void onD ataChange(@NonNull DataSnapshot dataSnapshot) {
for (DataSnapshot postSnapshot : dataSnapshot.getChildren()) {
Foods item = postSnapshot.getValue(Foods.class);
suggestList.add(item.getName());
}
materialSearchBar.setLastSuggestions(suggestList);
}
@Override
public void onCancelled(@NonNull DatabaseError databaseError) {
} }); }

43
6. CONCLUZII

6.1. Concluzii
Acest capitol va prezenta rezultatele obținute în urma dezvoltării acestui sistem , îmbunătățirile
ce pot fi aduse aplicați ilor sau funcționalități viitoare , cât și lucrurile noi învățate.
Ajungând și la această etapă, pot spune că am reușit prin dezvoltarea ace stui proiect să
rezolv multe dintre problemele care pe care le -am enumerat în primul capitol, în concluzie să
fac viața mai celor două tipuri de utilizatori.
Problemele care s -au ivit în momentele în care am lucrat la implementarea celor doua aplicații,
m-au ajutat să evoluez și sa înțeleg mai bine modul de funcționare atât a tehnologiei Java cât și
a programului de dezvoltare Android Studio și a elementelor de UI(User Interface).
Având în vede că, înainte de a începe să lucrez la acest proiect aveam doar cunoștințe de bază
în Java, acuma pot spune că am ajuns să cunosc principiile dezvoltării unei aplicații mobile .
Pentru a face o scurta evaluare a lucrurilor noi învățate am să enumăr câteva dinte acestea :
➢ Concepte de spre tipurile de aplica ții mobile care se pot implementa
➢ Familiarizarea cu tehnologiile cloud și bazele de date pentru aplicații mobile
➢ Utilizarea bibliotecilor
➢ Utilizarea JSON în crearea bazelor de date
➢ Utilizarea activităților
➢ Utilizarea componentelor UI
Aplicațiile pot fi instalate pe t elefoanele pe care rulează sistemul de operare Android (versiunile
de la 4.4 în sus API 19).
Deoarece aplicația folosește Firebase, aceasta este fiabilă și disponibilă. Datele stocate în
Firebase sunt securizate, deci acestea nu pot fi modificate sau pierd ute.

6.2. Posibilit ăți de dezvoltare
Având în vedere rolul pe care îl joaca aplicația, aș putea spune ca posibilitățile de
dezvoltare sunt destul de numeroase, iar în continuare voi enumera și descrie câteva dintre
acestea.
Momentan clientul are posibili tatea de a plăti doar atunci când comanda a ajuns la acesta și doar
cu bani cash. Majoritatea afacerilor de acest gen pentru ai oferi un confort ridicat clientului au
posibilitatea ca plata sa se facă prin transfer bancar sau prin transfer din depozite. Pe viitor
doresc să implementez un astfel de sistem aplicației.

44
O alta îmbunătățire care s -ar putea aduce aplicației a r fi implementarea unui sistem GPS,
acesta având posibilitatea de a prelua adresa clientului și adresa celui care utilizează sistemul și
pe urmă sa o transforme în coordonate globale , iar apoi se va putea stabili o rută între cele două
puncte. Toate aceste a fiind posibile direct în aplicație, iar acest lucru ar ajuta mult etapa de
livrare.
De asemenea implementarea unui sistem de notificări pe partea de aplicația client ar fi
destul de util atunci când se doreșt e inform area clienți lor că a apărut un produs nou în meniu
sau când apar reduceri la anumite produse.
Crearea unui sistem de acordare de reduceri pentru primi 5/10 clienți care au făcut cele mai
multe comenzi ar fi o alta posibilitate de dezvoltare.

45
BIBLIOGRAFIE

[1] Daniel Knott , Hands -On Mobile App Testing: A Guide for Mobile Testers and Anyone
Involved in the Mobile App , 2015
[2] https://gs.statcounter.com/os -market -share/mobile/worldwide Iunie -Iulie 2020
[3] G. Reese, “Cloud Computing Architectures”, O'Reilly Media, 2009
[4] P. Mell , T. Grance, “The NIST Definition of Cloud Computing”, 2011
[5] Mark L. Murphy, The Busy Coder’s Guide To Android Development (Final Version), 2008 –
2019
[6] Nikolay Elenkov , Android Security Internals: An In -Depth Guide to Android's Security
Architecture , Publisher: William Pollock , 2015
[7] Laurence Moroney, The Definitive Guide to Firebase: Build Android Apps on Google's
Mobile Platform, 2017
[8] J. F. DiMarzio, Beginning Android® Programming with Android Studio, Published by John
Wiley & Sons , Inc. 10475 Crosspoint Boulevard Indianapolis, 2017
[9] Felix Alvaro , SQL: Easy SQL Programming & Database Management For Beginners, Your
Step-By-Step Guide , 2016
[10] „Database Structure” https://firebase.google.com/docs/database/android/structure -data