Sisteme și Tehnologii Informatice Avansate [617283]

UNIVERSITATEA „LUCIAN BLAGA” DIN SIBIU

FACULTATEA DE
Ș
TIIN
Ț
E

Specializarea:

Sisteme și Tehnologii Informatice Avansate

LUCRARE DE DISERTAȚIE

Coordonator
ș
tiin
ț
ific

Prof.univ.dr. Dana Simian

Absolvent: [anonimizat]

2018

UNIVERSITATEA „LUCIAN BLAGA” DIN SIBIU

FACULTATEA DE
Ș
TIIN
Ț
E

Specializarea:

Sisteme și Tehnologii Informatice Avansate

Food Ordering Applications

System

Coordonator
ș
tiin
ț
ific

Prof.univ.dr. Dana Simian

Absolvent: [anonimizat]

2018

Abstract

1. Introducere

1.1 Contextul proiectului

1.1.1 Coduri de bare

1.1.2 Importan
ț
a informa
ț
iei

1.2 Ideea si scopul proiectului

1.3 Solutii existente in domeniul proiectului (state of the art)

2. Arhitectura aplica
ț
iei

2.1 Arhitectura serverului

2.2 Arhitectura clientului Android

3. Tehnologii folosite

3.1 Java

3.1.1 Limbajul de programare Java

3.1.2 Platforme de lucru Java

3.1.3 JDBC

3.2 Sistemul de operare Android

3.3 MySQL

3.4 Hibernate framework

3.5 Spring Framework

3.6 Maven

3.7 Servicii REST

4. Detalii de implementare

4.1 Aplica
ț
ia server

4.2 Aplica
ț
ia Android

5. Utilizarea Aplica
ț
iei

5.1 Descrierea Aplica
ț
iei

5.2 Scenarii de utilizare

6. Concluzii

7. Bibliografie

Abstract

Lucrarea
are
ca
scop
prezentarea
detaliilor
de
design
ș
i
implementare
a
proiectului

Food Ordering System.

Proiectul
Food
Ordering
System
este
destinat
comercian
ț
ilor
din
domeniul

restaurantelor
(în
special
de
tip
Fast-Food),
dar
ș
i
cumpărătorilor,
pentru
a
optimiza
procesul

de
preluare
a
comenzilor
de
către
comerciant
dar
ș
i
procesul
de
predare
a
comenzilor
de
către

cumpărător,
utilizând
cea
mai
uzuală
metodă
de
a
transfera
informa
ț
ii,
folosind

smartphone-uri.
Lucrarea
este
structurată
pe
capitole,
încercând
prin
aceasta
să
acopere

informa
ț
iile de bază privi nd ideea, arhitectura, tehnologiile, utilizarea, etc.

Primul
capitol
cuprinde
introducerea
în
sfera
proiectului,
oferind
informa
ț
ii
generale,

structurate
pe
subcapitole.
Primul
subcapitol
se
referă
la
încadrarea
proiectului
în
contextul

actual,
iar
prin
asta
se
explică
tiparul
de
consumatori
din
societate
pe
care
se
axează
sau

căreia
i
se
adresează.
Următorul
subcapitol
încadrează
ideea
de
la
care
a
plecat
proiectul
ș
i

care
este
motivul
sau
scopul
dezvoltării
acestuia.
Ultimul
subcapitol,
numit
“State
of
the
art”,

cuprinde
un
rezumat
al
cercetării
asupra
aplica
ț
iilor
existente
în
domeniul
în
care
se

încadrează
ș
i aplica
ț
ia Food Ordering System.

Al
doilea
capitol
con
ț
ine
prezentarea
arhitecturii
aplica
ț
iei.
Având
în
vedere
că

proiectul
Food
Ordering
System
este
compus
din
server,
aplica
ț
ie
Web
(destinată

comerciantului)
ș
i
aplica
ț
ie
Android
(destinată
comunită
ț
ii
de
cumpărători),
sunt
prezentate

fiecare
într-un
subcapitol
aferent.
Arhitectura
serverului
este
complexă
ș
i
dezvoltată
având

cuno
ș
tin
ț
e
despre
modul
în
care
se
creează
o
arhitectură
la
nivel
“enterprise”.
Pentru
aceasta

există
ș
i
diagrame
aferen te
pe
baza
cărora
a
fost
construit
sistemul
de
aplica
ț
ii.
Atât
pentru

aplica
ț
ia
Android,
cât
ș
i
pentru
aplica
ț
ia
Web,
s-a
ț
inut
cont
de
standardele
existente
în

domeniu.

Al
treilea
capitol
este
constituit
din
tehnologiile
studiate
ș
i
folosite
pentru
dezvoltarea

aplica
ț
iei,
descrise
succin t,
pentru
a
ajuta
cititorul
să
în
ț
eleagă
rolul
folosirii
lor
ș
i
pentru
a

crea
o
imagine
în
legătura
cu
modul
de
utilizare
a
lor.
Tehnologiile
folosite
sunt
gratuite
ș
i
se

încadrează
în
cele
mai
folosite
tehnologii
pentru
astfel
de
proiecte,
o
mare
parte
din
ele
fiind

sus
ț
inute de către comuni tatea programatorilor.

Al
patrulea
capitol
cuprinde
detaliile
de
implementare,
rela
ț
ia
dintre
cele
trei
aplica
ț
ii,

modul
în
care
ele
comunica
ș
i
modul
de
folosire
a
tehnologiilor
în
aplica
ț
ia
server
cât
ș
i
în

cele
două
aplica
ț
ii
clien t.
În
acest
capitol,
se
pot
găsi
ș
i
por
ț
iuni
de
cod
care
exemplifică

modul
de
folosire
a
tehnologiilor
în
dezvoltarea
aplica
ț
iilor
în
concordan
ț
ă
cu
standardele
de

dezvoltare actuale.

Al
cincilea
capitol
este
conceput
pentru
a
prezenta
aplica
ț
iile,
fiecare
având
un
mod

de
utilizare
specific,
fiind
interconectate
utilizând
aplica
ț
ia
server.
În
primul
subcapitol
se

descriu
aplica
ț
iile
utilizân d
pa
ș
ii
de
folosire,
iar
în
cel
de
al
doilea
capitol
se
explică
detaliat,

utilizând capturi de ecran din cadrul aplica
ț
iei.

Al
ș
aselea
capito l
este
dedicat
concluziilor
ș
i
elaborării
unor
dezvoltări
viitoare

precum
ș
i impactul realiz ării proiectului în dezvoltarea mea personală.

O
primă
formă
a
proiectului
Food
Ordering
System
a
fost
prezentată
la
Conferin
ț
a

interna
ț
ională
ICDD
–
“Imagination,
Creativity,
Design,
Development”
2018.
Prezentarea
a

primit multe răspunsuri pozitive, ceea ce contribuie la motiva
ț
ia dezvoltării în continuare [6].

Lucrarea
este
realizată
în
colaborare
cu
GSD
IT,
cu
ajutorul
căreia
o
să
devină
o

aplica
ț
ie
disponibilă
pe
“Google
Play”
iar
un
lan
ț
de
restaurante
de
tip
Fast-Food
urmează
să

o folosească în produc
ț
ie pentru a prelua
ș
i procesa comenzi.

1. Introducere

1.1 Contextul proiectului

Contextul
actual
este
reprezentat
de
nevoia
de
procesare
a
informa
ț
ilor
într-un
timp

cât
mai
scurt
posibil,
iar
aici
tehnologia
joacă
un
rol
esen
ț
ial.
Tehnologia
modernă
sprijină

această
nevoie,
iar
dispozitivele
mobile
reprezintă
probabil
exponentul
cel
mai
de
seamă
al

acestei
tehnologii.
Noile
telefoane,
dotate
cu
sisteme
de
operare
din
ce
în
ce
mai
avansate,

tind
să
con
ț
ină
o
parte
din
personalitatea
noastră:
agenda
telefonicã,
știri
de
ultimă
oră,

alarme,
contacte
cu
prietenii,
jocuri,
întâlniri
de
afaceri,
dieta,
orarul
tratamentului

medicamentos, etc.

Un
studiu
realizat
de
Huawei
împreună
cu
Ipsos,
conclude
că
79%
dintre
români

folosesc
smartphone-ul
înainte
de
culcare
pentru
a
citi
email-uri,
pentru
a-
ș
i
verifica
conturile

de
Social
Media
ș
i
mesa jele
primite,
în
timp
ce
64%
fac
acest
lucru
când
se
trezesc.
Acesta

este
unul
dintre
motivele
pentru
care
60%
din
români
î
ș
i
iau
telefoanele
când
se
pun
în
pat
ș
i

1 din 10 sau aproximativ 11% din ace
ș
tia, admit că dorm cu telefonul lângă ei [1].

Acela
ș
i
studiu
a
identificat
că
87%
dintre
români
au
nevoie
de
smartphone
pentru

trimiterea
mesajelor
text,
că
72%
folosesc
telefonul
pentru
surprinderea
fotografiilor
ș
i,

bineîn
ț
eles,
că
79%
utilizează
telefonul
pentru
verificarea
re
ț
elelor
Social
Media.
De

asemenea,
cercetarea
a
constatat
că
56%
dintre
responden
ț
i
recunosc
că
au
smartphone-urile

cu
ei
mai
mult
de
13
ore
pe
zi,
în
timp
ce
27%
folosesc
smartphone-ul
în
mod
activ
3-4

ore/zi.

Angajații
lucrează
zilnic,
în
cursul
săptămânii,
în
medie,
7:44
ore,
bărbații
cu
38
de

minute
mai
mult
decât
femeile,
iar
populația
are,
de
luni
până
vineri,
mai
puțin
timpul
liber

zilnic
cu
2:11
ore
față
de
zilele
de
odihnă,
potrivit
unui
studiu
realizat
de
Institutul
Național

de Statistică (INS) [2].

Având
aceste
studii
în
vedere,
observăm
ca
societatea
este
formată
din
foarte
multi

oameni
cu
profesii
tot
mai
solicitante,
pentru
care
timpul
este
un
element
important,
motiv

pentru
care,
aceasta
este
o
resursă
folosită
cu
în
ț
elepciune.
De
asemenea,
alimenta
ț
ia
are
o

relevan
ț
ă
mărită
în
activi tatea
de
zi
cu
zi
a
oamenilor.
Potrivit
cercetărilor,
un
număr
mare
de

oameni
fac
comenzi
telefonice
aproape
zilnic
pentru
a-
ș
i
asigura
alimenta
ț
ia.
În
general,

comenzile
telefonice
necesită
o
perioada
de
timp
relativ
mare,
în
special
dacă
comanda
este

complexă.
Pe
de
altă
parte,
intervalele
de
masă
fiind
în
general
comune
(prânz
sau
cină),

liniile
telefonice
pot
forma
o
coadă
de
apelan
ț
i,
lucru
care
este
deranjant
pentru
o
mare
parte
a

oamenilor, pentru care timpul este important.

În
consecin
ț
ă,
bazându-ne
pe
informa
ț
iile
de
mai
sus,
am
decis
să
înbunătă
ț
im
acest

sistem
de
predare
ș
i
gestionare
a
comenzilor
creând
o
aplica
ț
ie
mobilă
pentru
clien
ț
i
ș
i
o

aplica
ț
ie web pentru furn izori/restaurante.

Proiectul
prin
aplica
ț
ia
mobilă
(Android)
se
focusează
pe
o
varietate
de
consumatori.

Prive
ș
te
în
primul
rând
utilizatorii
din
mediul
urban,
având
în
vedere
că
mul
ț
i
lucrează
la

birou,
sunt
în
tranzit
sau
timpul
nu
permite
prepararea
alimenta
ț
iei,
această
aplica
ț
ie
oferind

posibilitatea
de
a
comanda
produse
de
la
un
anumit
lan
ț
de
restaurante
într-un
timp
optim
fără

nevoia de a sta la coadă sau a contacta telefonic restaurantul.

De
asemenea,
proiectul
(prin
aplica
ț
ia
web)
se
focusează
pe
proprietarii
de

restaurante,
optimizând
gestionarea
comenzilor,
creând
statistici
bazate
pe
comenzile

anterioare,
automatizând
oferte
pentru
clien
ț
ii
fideli
ș
i
pentru
a
putea
anticipa
numărul
de

comenzi în anumite intervale de timp.

1.2 Ideea si scopul proiectului

Ideea
proiectului
a
pornit
de
la
necesitatea
de
a
comanda
mâncare
de
tip
fast-food

pentru
un
număr
relativ
mare
de
oameni,
fiecare
dorindu-
ș
i
un
meniu
personalizat.
După

primele
comenzi,
s-a
constatat
o
pierdere
de
timp
relativ
mare
pentru
fiecare
comandă,
fapt
ce

a condus la ideea creerii unei aplica
ț
ii care sa u
ș
ureze predarea de comenzi.

Aplica
ț
ii
care
privesc
optimizarea
comenzilor
există
în
acest
moment
pe
pia
ț
ă
însă
se

adresează
unei
mase
mari
de
restaurante,
lucru
care
nu
permite
personalizarea
comenzilor

mari
sau
unele
restaurante
nu
existau
în
lista
oferită.
Scopul
acestui
proiect
este
e
a
crea
o

aplica
ț
ie de baza care, ult erior, să se personalizeze pentru câte un lan
ț
de restaurante.

De
asemenea,
scopul
prevede
o
gestionare
a
comenzilor
mult
mai
u
ș
oara
de
către

furnizor,
eliminând
apelurile
telefonice
ș
i
în
ț
elegerea
gre
ș
ită
a
comenzilor.
Având
un
sistem

de
fidelizare,
încrederea
în
gestionarea
comenzilor
mari
cre
ș
te
iar
periodic
se
pot
genera

rapoarte, promo
ț
ii pentru clien
ț
ii fideli
ș
i alte oferte.

Un
alt
scop
este
de
a
ajuta
consumatorii
să
vizualizeze
ș
i
în
acela
ș
i
timp
să
creeze

comanda,
ulterior
de
a
vedea
statusul
comenzii
în
timp
real,
toate
acestea
fiind
securizate.

Utilizatorul
are
acces
la
un
sistem
de
comunicare
scris
pe
fiecare
comandă,
pentru
a
avea

siguran
ț
a implementării, aceasta fiind favorizată printr-un modul de notificări.

Un
avantaj
al
acestei
aplica
ț
ii
este
posibilitatea
de
a
vedea
părerea
altor
utilizatori

despre
anumite
produse
sau
de
a
lăsa
comentarii
la
produse.
Acesta
constituie
un
mare

avantaj
având
în
vedere
că
părerea
altor
consumatori
poate
fi
ș
i
de
cele
mai
multe
ori
este
un

criteriu consistent în alegerea produselor.

1.3
​

​
Solutii existente in domeniul proiectului (state of the art)

Solu
ț
iile
existente
în
domeniu
se
pot
contura
sau
defini
printr-un
studiu
de
pia
ț
ă
care

ajută
crearea
unui
proiect
diferit,
original
sau
potrivit
standardelor
actuale
de
pe
pia
ț
ă.
Rolul

cercetării
este
de
a
cunoa
ș
te
dinamica
actuală
a
pie
ț
ei,
comportamentul
actorilor

(producătorilor/distribuitorilor) cât
ș
i tendin
ț
ele pe termen scurt, mediu
ș
i lung .

Studiul
pie
ț
ei
reprezintă
colectarea
informa
ț
iilor
de
pe
piată,
în
func
ț
ie
de
ce

informa
ț
ii
sunt
necesare ,
dezvoltatorul
abordează
cercetarea
privind
cererea,
oferta
sau

mediul
înconjurator
de
pe
pia
ț
a
respectivă
[13].
În
ceea
ce
prive
ș
te
oferta,
cercetarea
ar
trebui

să
ia
în
considerare
care
sunt
poten
ț
ialii
concuren
ț
i
de
pe
pia
ț
ă,
care
sunt
ofertele
lor
sau
care

este
politica
lor
comercială.
Pe
de
altă
parte,
este
importantă
cererea,
ea
poate
veni
din
partea

unor
firme
sau
din
partea
consumatorilor
(comunită
ț
ii).
Cunoa
ș
terea
cererii
înseamnă
să
se

ș
tie
care
este
publicul
la
care
dezvoltatorul
dore
ș
te
să
facă
referin
ț
ă
(vârsta,
sex,
segment,
stil

de
via
ț
ă,
venituri),
care
sunt
motiva
ț
iile
achizi
ț
ionării
unui
produs.
Al
treilea
factor
este,
în

unele
cazuri,
cel
mai
important
deoarece
cunoa
ș
terea
mediului
extern
este
un
factor
pentru
a

în
ț
elege
oportunită
ț
ile
ș
i
ocolirea
posibilelor
amenin
ț
ări.
Acesta
reprezintă
asigurarea
că

reglementăriile
(legi,
norme,etc.)
sunt
aplicate
corect,
influen
ț
a
situa
ț
iilor
economice,

influen
ț
a
factorilor
socia li
(presiuni
ecologice,
sindicale,
etc.)
sau
existen
ț
a
noilor
tehnologii

pentru produsul/produsele în cauză [11].

Studiul
de
pia
ț
ă
se
formează
prin
strângerea
ș
i
analizarea
informa
ț
iilor
referitoare
la

clien
ț
i,
competitori
ș
i
pia
ț
ă.
Un
studiu
de
pia
ț
ă
construit
în
manieră
profesională
constituie

funda
ț
ia
unui
plan
de
afaceri,
lansarea
unui
produs
sau
a
unui
serviciu,
etc.
Studiul
este

constituit
din
mai
multe
etape
[12]:
Prima
reprezintă
stabilirea
contextului
în
care
se

încadrează
proiectul
iar
aceasta
cere
în
mod
frecvent
o
reflec
ț
ie
în
prealabil,
înainte
de
a

elabora
proiectul
studiului.
În
cazul
proiectului
Food
Ordering
System,
contexul
se
rezumă
la

multitudinea
de
aplica
ț
ii
mobile
care
oferă
posibilitatea
de
a
comanda
anumite
produse
din

categoria restaurantelor
ș
i gestionarea comenzilor.

A
doua
etapă
se
referă
la
colectarea
informa
ț
iilor
disponibile
pe
site-urile
web,

aplica
ț
ii
mobile,
căr
ț
i,
etc.
Colectarea
informa
ț
iilor
presupune
o
aten
ț
ie
extinsă
având
în

vedere
pia
ț
a
vastă.
Avân d
în
vedere
contextul
proiectului,
s-au
abordat
diferite
surse,
precum

magazinul
de
aplica
ț
ii
disponibil
pe
sistemul
de
operare
Android
(Play
Store),
diferite
colec
ț
ii

sau
top-uri
(clasamente)
pentru
a
găsi
cele
mai
relevante
aplica
ț
ii
care
se
încadrează
în

context, iar rezultatul a fost unul favorabil, s-a găsit un număr relevant de aplica
ț
ii.

Următoarea
etapă
a
studiului
este
de
a
analiza
informa
ț
iile
găsite
în
amănunt,
de
a
crea

statistici,
chestionare
(dacă
este
cazul),
etc..
Analiza
se
construie
ș
te
din
perspectiva
de

producător
sau
creator
dar
ș
i
din
perspectiva
de
client,
ea
este
foarte
importantă
deoarece
este

important
să
i
se
ofere
clientului
ceea
ce
i
ș
i
dore
ș
te.
Analiza
aplica
ț
iilor
găsite
este
structurată

pe
două
ramuri:
Prima
ramură
este
construită
din
caracteristicile
aplica
ț
ilor,
func
ț
ionalită
ț
i

(avantaje)
existente
în
aplica
ț
ii
care
pot
deveni
noi
func
ț
ionalită
ț
i
în
aplica
ț
ia
Food
Ordering

System.
S-au
găsit
func
ț
ionalită
ț
i
precum
setarea
restaurantului
favorit
pentru
a
evita
anumi
ț
i

pa
ș
i,
op
ț
iunea
de
a
primi
notificări,
sau
posibilitatea
de
a
avea
un
sistem
de
mesagerie
pe

comandă
(petru
a
putea
avea
posibilitatea
de
a
schimba
anumite
detalii
pe
comanda.

Posibilitatea
de
a
da
un
rating
sau
de
a
face
un
review
(comentariu)
la
un
produs.
Unele

aplica
ț
ii
oferă
posibilitat ea
de
a
plăti
în
avans
folosind
un
card
bancar.
Analizând
aplica
ț
iile

selectate,
s-a
descoperit
unele
dezavantaje
la
unele
dintre
ele,
însa
unul
major
este
lipsa

informa
ț
iilor
despre
produse.
În
general
căutarea
s-a
efectuat
folosind
coduri
de
bare
de

produse
alimentare.
Un
alt
dezavantaj
îl
prezintă
accesibilitatea
îngreunată
de
reclame,
un

design
slab
sau
aveau
de
oferit
o
experien
ț
ă
utilizatorului
care
nu
este
predictivă,
fiind
greu

de folosit.

A
patra
etapă,
ultima,
constă
în
raportul
studiului
care
reflectă
analiza,
cu
avantaje
ș
i

dezavantaje.
În
general
aceste
rezultate
se
pot
prezenta
ș
i
oral,
având
rol
de
a
crea
o
discu
ț
ie

pe
baza
acestei
cercetări.
Luând
în
considerare
cele
prezentate
mai
sus,
pe
pia
ț
a
aplica
ț
iilor

mobile
ce
oferă
posibilitatea
comenzilor
produselor
de
tip
Fast-Food
ș
i
administrarea
lor,

exista
pu
ț
ine
(aplica
ț
ii)
care
satisfac
suficient
de
bine
consumat orii,
iar
acestea
se
adresează

unui număr mare de restaurante, personalizarea fiecărui restaurant fiind mai dificilă [13].

2. Arhitectura aplica
ț
iei

Food Ordering System este un sistem de aplica
ț
ii, împăr
ț
it trei aplica
ț
ii, una dintre ele

fiind
o
aplica
ț
ie
Android
destinată
comandării
de
produse,
în
cazul
de
fa
ț
ă,
comandarea
de

mâncare.
Următoarea
aplica
ț
ie
este
aplica
ț
ia
Web,
destinată
comerciantului,
care
utilizează

aplica
ț
ia
pentru
a
administra
comenzile
primite,
pentru
a
modifica
meniul,
sau
pentru
a

genera
oferte
în
func
ț
ie
de
numărul
comenzilor.
Pentru
a
crea
legătura
între
aceste
aplica
ț
ii,

a
fost
nevoie
de
crearea
unui
server,
unde
toată
informa
ț
ia
este
păstrată
într-o
bază
de
date

(Figura 2.1).

Aplica
ț
ia
Android
s-a
construit
pe
conceptul
arhitectural
personalizat
MVC

“Model-View-Controller”
care
a
fost
conceput
pentru
a
separa
interfa
ț
a,
logica
ș
i
informa
ț
iile.

De
asemenea,
aplica
ț
ie
Web
a
fost
creată
pe
conceptul
de
MVC,
urmând
ca
aplica
ț
ia
server

sa
fie
construită
pe
un
concept
de
“Layers”
prin
care
se
separă
serviciile
expuse
de
logică
ș
i

de persisten
ț
ă.

Figura 2.1
​
Interac
ț
iunea aplica
ț
iilor într-un întreg sistem

2.1 Arhitectura clientului Android

“Model
View
Controller”
sau
MVC
a
ș
a
cum
este
numit
popular,
este
un
model
de

design
software
pentru
dezvoltarea
de
aplica
ț
ii
web.
Un
MVC
este
alcătuit
din
următoarele

trei păr
ț
i:

1.
Modelul
reprezintă
partea
de
hard-programming,
partea
logică
a
aplica
ț
iei.
El

are
în
responsabilitate
ac
ț
iunile
ș
i
opera
ț
iile
asupra
datelor,
autentificarea

utilizatorilor,
integrarea
diverselor
clase
ce
permit
procesarea
informa
ț
iilor
din

diverse baze de date.

2.
View-ul
se
ocupă
de
afi
ș
area
datelor,
practic
această
parte
a
programului
va

avea
grijă
de
cum
vede
end-userul
informa
ț
ia
procesată
de
controller.
O
dată

ce
func
ț
iile
sunt
executate
de
model,
viewului
îi
sunt
oferite
rezultatele,
iar

acesta
le
va
trimite
către
browser.
În
general
viewul
este
o
mini-aplica
ț
ie
ce

ajută la randarea unor informa
ț
ii, având la baza diverse template-uri.

3.
Controller-ul
reprezintă
creierul
aplica
ț
iei.
Aceasta
face
legătura
între
model
ș
i

view,
între
ac
ț
iunile
userului
ș
i
partea
deciziona la
a
aplica
ț
iei.
În
func
ț
ie
de

nevoile
utilizatorului,
controllerul
apelează
diverse
func
ț
ii
definite
special

pentru
sec
ț
iunea
de
site
în
care
se
află
userul.
Func
ț
ia
se
va
folosi
de
model

pentru
a
prelucra
(extrage,
actualiza)
datele,
după
care
informa
ț
iile
noi
vor
fi

trimise către view, ce le va afi
ș
a apoi prin template-uri.

MVC
este
popular
deoarece
izolarea
logicii
aplica
ț
iei
de
pe
stratul
de
interfa
ț
ă

utilizator
ș
i
sus
ț
ine
separarea
preocupărilor.
Aici,
controlorul
prime
ș
te
toate
cererile
pentru

aplica
ț
ie
ș
i
apoi
lucrează
cu
modelul
pentru
a
pregăti
orice
date
necesare
vizualizării.

Vizualizarea
utilizează
apoi
datele
pregătite
de
controlor
pentru
a
genera
un
răspuns
final

prezentabil. Abstrac
ț
ia MVC este reprezentată grafic în Figura 2.1.1.

​
Figura 2.1.1
​
arhitectura de tip MVC

În
aplica
ț
ia
Andr oid,
interfe
ț
ele
sunt
reprezentate
prin
“Activities”
ș
i
“Fragments”,

moduri
prin
care
Java
reu
ș
e
ș
te
să
controleze
interfa
ț
a.
La
nivelul
“Controller”
se
folosesc

clase
care
cuprind
logica,
pentru
a
pregăti
datele
pentru
interfa
ț
ă.
De
la
nivelul
logicii
se

apelează serviciile care fac legătura într-e aplica
ț
ia Android
ș
i server.

În
stadiul
de
dezvoltare,
în
această
aplica
ț
ie
s-au
folosit
obiecte
con
ț
inând
date
de
test

“Mock
data”.
Din
punct
de
vedere
arhitectural,
s-au
folosit
“Interfaces”
(interfe
ț
e)
pentru
a

crea
un
contract
între
clasele
care
controlează
ceea
ce
se
afi
ș
ează
ș
i
clasele
ce
se
ocupă

livrarea
informa
ț
iilor,
în
asa
fel
încât
să
se
poată
schimba
implementarea
când
serverul
este

implementat.
Pe
baza
contractului,
ini
ț
ial
s-a
lucrat
cu
date
false,
obiecte
de
tip
“Mock”,

urmând ca acestea să fie schimbate odată cu dezvoltarea serviciilor de pe server.

Sistemul
de
operare
Android
oferă
posibilitatea
arhitecturală
de
a
crea
mai
multe

foldere
în
directorul
de
resurse
pentru
a
crea
anumite
configura
ț
ii,
în
func
ț
ie
de
regiunea
pe

care
e
setat
smartphone-ul.
În
acest
fel
s-a
permis
implementarea
unui
sistem
de

interna
ț
ionalizare
a
aplic a
ț
iei,
în
care
avem
un
fi
ș
ier
numit
“Strings.xml”
pentru
fiecare

limbă,
adaugat
în
directorul
specific,
numele
fiind
definit
de
Android,
de
exemplu
pentru
a

crea
un
director
pentru
România
avem
nevoie
ca
numele
directorului
să
fie
“values-ro”,

pentru
Germania
ar
trebui
să
se
numească
“values-de”.
Sistemul
a
fost
implementat
în
Food

Ordering System pentru trei limbi: Romană, engleză
ș
i germană.

Android
este
folosit
pe
mai
multe
tipuri
de
dispozitive,
de
la
smartphone,
la
tablete
ș
i

uneori
pe
TV.
Pentru
ca
aplica
ț
ia
să
se
adapteze
la
aceste
dispozitive,
Android
oferă

posibilitatea
de
a
folosi
fragmente,
care
reprezintă
bucă
ț
i
de
func
ț
ionalitate
din
interfa
ț
ă,
care

pot
fi
refolosite,
sau
aranjate
în
interfa
ț
ă
în
func
ț
ie
de
mărimea
ecranului.
În
aceea
ș
i
categorie

se
încadrează
ș
i
imaginil e
folosite
în
aplica
ț
ie,
care
se
pot
încărc a
foarte
greu
pe
dispozitive

cu
ecran
mic
ș
i
hardware
slab
în
cazul
în
care
imaginile
au
o
rezolu
ț
ie
prea
mare.
În
func
ț
ie

de
categoria
de
ecrane,
rezolu
ț
ia
imaginii
se
schimbă
ș
i
se
pune
în
directorul
corespunzător

ecranului.

2.2 Arhitectura clientului Web

Arhitectura clientului web este una de tip MVC deoarece reprezintă recomandarea

comunită
ț
ii programatori lor ce dezvoltă aplica
ț
ii utilizând Angular.

​
Figura 2.2.1
​
arhitectura de tip MVC [17]

2.3 Arhitectura serverului

Arhitectura serverului necesită adaptabilitate, scalabilitate, posibilitatea de a putea fi

refolosită în alte contexte, pentru a-i permite aplica
ț
iei să răspundă foarte repede la cereri. De

aceea, folosind servicii web, care creează legătura dintre aplica
ț
ia Web
ș
i aplica
ț
ia Android,

s-a creat un server pentru acumularea și gestionarea informațiilor. Serverul con
ț
ine un

serviciu web, care prin apeluri HTTP returnează un fișier cu informațiile aferente într-un

anume format, cele mai des utilizate sunt JSON și XML.

Serverul
este
creat
pe
baza
unei
arhitecturi
care
respectă
standardele
de
tip
enterprise,

aceasta
presupune
împărțirea
funcționalităților
fără
a
depinde
direct
una
de
cealaltă,
pentru

aceasta folosindu-se interfe
ț
e, în caz contrar ar exista erori de compilare.

Arhitectura
aplica
ț
iei
este
structurată
în
patru
straturi
diferita,
după
cum
vedem
în

Figura
2.1:
stratul
de
servicii,
stratul
de
func
ț
ionalitate,
stratul
de
persisten
ț
ă
ș
i
stratul

elementelor comune.

Pachetul
de
servicii
presupune
expunerea
unor
servicii
care
sunt
apelate
de
clien
ț
i

pentru
a
salva
informa
ț
ii
sau
pentru
a
prelua
informa
ț
ii
din
baza
de
date.
Acest
pachet
include

interfe
ț
e
pentru
comunica re.
Aici
se
implementează
securitatea
serverului,
ea
fiind
constinuită

din
autentificare
ș
i
autor izare.
Autentificarea
se
folose
ș
te
atunci
când
un
client
accesează

pentru
prima
data
serverul
prin
servicii
web,
încercând
să
creeze
o
sesiune.
Autorizarea
în

schimb,
se
execută
la
fiecare
cerere
a
unui
client
ș
i
verifică
dacă
clientul
are
acces
la
acea

cerere
(request).
În
pachetul
de
servicii
există
o
parte
de
validare
care
verifică
parametrii
de

intrare a serviciilor.

Al
doilea
strat
al
arhitecturii
este
locul
în
care
se
implementează
logica,
locul
de

decizie,
în
care
se
decide
unde
se
livrează
informa
ț
ia
sau
de
unde
se
preia.
Acest
strat
este

locul
unde
se
fac
validări,
apeluri
succesive
către
stratul
de
persisten
ț
ă
sau
alte
servicii

externe, totul pentru a crea un răspunsul cerut prin servicii.

Al
treilea
strat
al
arhitecturii
este
reprezentat
de
partea
de
date
sau
informații
(mai

fiind
numit
ș
i
stratul
de
persisten
ț
ă).
Prima
componentă
al
acestu i
strat
este
definită
de
entități

care
au
rolul
de
a
memora
pentru
o
perioadă
scurtă
de
timp
informații.
Aceste
entități
sunt

defapt
niște
obiecte
cărora
le
sunt
însușite
proprietăți,
în
general
private,
care
se
pot
accesa

prin
metode
specifice
(setter/getter).
Fiecare
entitate
reprezintă
o
tabelă
din
baza
de
date,

aceasta
reprezentând
conceptul
de
“ORM
–
Object
Relational
Mapping”.
Entitățile
sunt

folosite
de
următoarea
componentă
a
acestei
părți,
de
componentele
de
accesare
a
datelor

(Data
Access
Object).
Într-o
bază
de
date,
informațiile
din
entități
se
salvează
prin
crearea

unei
cereri
(query)
care
conține
fiecare
coloană
și
proprietățiile
entităților.
Folosind

Hibernate,
se
specifică
doar
entitatea
care
trebuie
salvată
sau
referința
pentru
entitatea
care
se

caută
iar
Hibernate
face
totul
în
locul
dezvoltatorului.
Pe
lângă
entități
și
obiectele
de

accesare a datelor mai avem și “Data Helpers” care ne ajută la convertirea obiectelor.

Figura 2.3.1
​
Arhitectura serverului

Toate
cele
trei
straturi
sunt
din
punct
de
vedere
arhitectural
independente,
însă
au
ș
i

elemente
comune,
elemente
care
se
folosesc
în
fiecare
fără
a
crea
dependen
ț
ă
între
celalalte

ramuri, aceasta este cunoscută
ș
i sub denumirea de “Cross Cutting” într-un mod personalizat.

Unul
din
elementele
“Cross-Cutting”
este
sistemul
de
excep
ț
ii,
care
este
folosit
pentru
a

genera
ș
i
transporta
mesa je
de
eroare
de
la
cel
mai
jos
strat,
cel
de
persisten
ț
ă,
pânâ
la
cel
mai

înalt
strat,
cel
de
servicii,
urmând
să
fie
interpretat
ș
i
transmis
către
client.
Acest
sistem
de

excep
ț
ii,
poate
fi
folosit
într-un
mod
care
ajută
la
interna
ț
ionalizarea
mesajelor
de
eroare.

Pentru
a
folosi
un
sistem
de
interna
ț
ionalizare
a
mesajelor
de
eroare
folosind
excep
ț
iile,
este

nevoie
de
un
fi
ș
ier
de
tip
proprietă
ț
i
în
care
să
ț
inem
sub
forma
cheie-valoare,
numele
clasei

excep
ț
iei
ș
i
un
cod
de
eroare,
urmând
să
se
creeze
fi
ș
iere
de
mesaje,
care
con
ț
in
tot
sub
forma

cheie-valoare
codul
de
eroare
ș
i
mesajul
în
func
ț
ie
de
limba
fi
ș
ierului.
Folosind
aceste
două

fi
ș
iere
de
proprietă
ț
i,
se
poate
crea
un
obiect
care
să
interpretez e
fi
ș
ierele,
iar
dacă
clasa
de

excep
ț
ie
este
gasită
în
primul
fi
ș
ier,
atunci
se
ia
codul
de
eroare
urmând
să
fie
căutat
în

fi
ș
ierul corespunzător reg iunii cererii (requestului).

​
Figura 2.3.2
​
Obiect de transfer date (DTO)

Modelul
de
date
este
complex,
însă
în
cazul
nostru
se
folosește
pentru
a
crea
obiecte

care
înșusesc
proprietăți
ale
entităților
pe
care
le
folosim
pentru
transferul
de
date,
aceste

obiecte
mai
poartă
sufixul
de
DTO
(Data
Transfer
Object).
Obiectele
de
transfer
sunt
create

pentru
a
încapsula
date
care
ulterior
sunt
trimise
altor
module/sub-sisteme
ale
aplicației.

Atunci
când
se
lucrează
cu
o
interfa
ț
ă
de
la
distan
ț
ă
pentru
a
accesa
date,
fiecare
apel
este

costisitor.
Ca
și
rezultat
trebuie
scăzut
numărul
de
apeluri.
După
cum
putem
vedea
în
Figura

2.3.1,
un
mod
de
a
scădea
numărul
de
apeluri,
este
de
a
trimite
obiecte
compuse.
În
partea

dreaptă
avem
două
obiecte
în
relație.
Pentru
a
scădea
numărul
de
obiecte,
doar
pentru

transfer,
s-a
creat
un
obiect
care
conține
proprietățile
amândurora.
Diferența
dintre
obiectele

de
transfer
(DTO)
și
obiectele
de
acces
(DAO)
sau
obiectele
care
administrează
aplicația

constă
în
compoziția
lor,
obiectele
de
transfer
conțin
doar
proprietăți
cu
accesori,
fără
metode

care
necesită
testare,
pe
când
celelalte
tipuri
de
obiecte
cum
ar
fi
cele
de
acces
trebuie
să
fie

testate.

Logarea
este
comună
tuturor
straturilor
arhitecturii,
fiind
utilizată
pentru
stocarea

erorilor
și
a
informațiilor
importante
într-o
ordine
cronologică.
Sistemul
de
logare
a
erorilor

este
important
pentru
dezvoltarea
continuă
a
aplicației.
În
cazul
aplicațiilor
care
implică
mai

multe fire de execuție, logarea ajută la identificarea problemelor.

Ultima
parte
a
elementelor
comune,
numit
“utilities”,
după
cum
putem
vedea
în

Figura
2.3.1,
cuprinde
și
alte
eventuale
nevoi
care
se
folosesc
în
cel
puțin
două
părți
din

arhitectura
serverului.
Un
exemplu
de
clasă
utilitară
ar
putea
fi
o
clasa
statică
de
constante

care
se
definesc
ca
și
câmpuri
publice,
statice
ș
i
finale,
pe
care
le
folosim
fără
a
crea
un

obiect.
Un
alt
exemplu
de
utilitate
ar
putea
fi
conversia
de
date,
de
exemplu
dintr-o
dată

într-un șir de caractere.

3. Tehnologii folosite

3.1 Limbajul de programare Java

Java
este
un
limbaj
de
programare
ș
i
o
platformă
de
calcul
lansată
ini
ț
ial
de
Sun

Microsystems
în
1995.
Există
o
mul
ț
ime
de
aplica
ț
ii
ș
i
site-uri
web
care
nu
vor
func
ț
iona

decât
dacă
ave
ț
i
instalat
Java
ș
i
din
ce
în
ce
mai
multe
sunt
create
în
fiecare
zi.
Java
este
un

limbaj
rapid,
sigur
ș
i
fiabil.
De
la
laptopuri
la
centre
de
date,
console
de
jocuri
la

supercomputere
ș
tiin
ț
ifice, telefoane mobile la Internet [5].

Este
dificil
să
relatăm
un
singur
motiv
pentru
care
limbajul
de
programare
Java
a

devenit
omniprezent.
Cu
toate
acestea,
caracteristicile
majore
ale
limbajului
au
jucat
toate
un

rol în succesul său, incluzând următoarele componente:

Programele
create
în
Java
oferă
o
portabilitate
într-o
re
ț
ea.
Codul
sursă
este
compilat

în
ceea
ce
Java
nume
ș
te
bytecode,
care
poate
fi
rulat
oriunde
într-o
re
ț
ea
dintr-un
server
sau

client
care
are
o
ma
ș
ină
virtuală
Java
(JVM).
JVM
interpretează
codul
bytecode
în
cod
care

va
rula
pe
hardware-ul
computerului.
În
schimb,
majoritatea
limbajelor
de
programare,
cum

ar
fi
COBOL,
C
++,
Visual
Basic
sau
Smalltalk,
compilează
codul
într-un
fi
ș
ier
binar.

Fi
ș
ierele
binare
sunt
specifice
platformei,
astfel
încât
un
program
scris
pentru
o
ma
ș
ină

Windows
bazată
pe
Windows
nu
poate
rula
un
Mac,
o
ma
ș
ină
bazată
pe
Linux
sau
o

mainframe
IBM.
JVM
include
un
compilator
op
ț
ional
la
jumătatea
perioadei
(JIT)
care

compilează
dinamic
codul
bytecode
în
cod
executabil
ca
alternativă
la
interpretarea
câte
unei

instruc
ț
iuni
bytecode
la
un
moment
dat.
În
multe
cazuri,
compila
ț
ia
dinamică
JIT
este
mai

rapidă decât interpretarea ma
ș
inii virtuale [4].

Codul
este
robust.
Spre
deosebire
de
programele
scrise
în
C
++
ș
i
în
alte
limbi,

obiectele
Java
nu
con
ț
in
referin
ț
e
la
date
externe
pentru
ele
sau
alte
obiecte
cunoscute.
Acest

lucru
asigură
faptul
că
o
instruc
ț
iune
nu
poate
con
ț
ine
adresa
de
stocare
a
datelor
într-o
altă

aplica
ț
ie
sau
în
sistemul
de
operare
în
sine,
oricare
ar
determina
încetarea
sau
prăbu
ș
irea

programului
ș
i,
eventual,
a
sistemului
de
operare.
JVM
face
o
serie
de
verificări
pe
fiecare

obiect pentru a asigura integritatea [13].

Java
este
orientat
pe
obiecte.
Un
obiect
poate
profita
de
faptul
că
face
parte
dintr-o

clasă
de
obiecte
ș
i
de
a
mo
ș
teni
un
cod
comun
pentru
clasă.
Obiectele
sunt
considerate
ca

"substantive"
pe
care
un
utilizator
le-ar
putea
referi
mai
degrabă
decât
"verbele"
tradi
ț
ionale

procedurale.
O
metodă
poate
fi
considerată
ca
fiind
una
dintre
capabilită
ț
ile
sau

comportamentele
obiectului.
Orientarea
spre
obiect
este
relativ
obi
ș
nuită
în
peisajul
de

programare
de
astăzi,
dar
încă
din
1996,
doar
o
mână
de
limbi
implementează
în
mod
eficient

concepte
orientate
pe
obiecte
ș
i
modele
de
design.
Abilitatea
de
a
se
dezvolta
ca
un
limbaj

creat
de
la
început
orientat
obiect,
a
făcut
ca
Java
să
devină
o
platformă
interesantă
pe
care
să

se programeze.

Un
applet
oferă
flexibilitate.
Pe
lângă
faptul
că
este
executat
pe
client
mai
degrabă

decât pe server, un applet Java are alte caracteristici proiectate pentru a face să ruleze rapid.

Dezvoltatorii
pot
învă
ț
a
Java
rapid.
Cu
sintaxa
similară
cu
C
++,
Java
este
relativ
u
ș
or

de învă
ț
at, mai ales pentr u cei cu fundal în C.

O
concep
ț
ie
gre
ș
ită
este
că
există
o
asociere
între
Java
ș
i
JavaScript.
Cele
două
limbi

împărtă
ș
esc asemănări în sintaxă, dar, altfel, sunt două construc
ț
ii foarte diferite.

Există trei platforme-cheie pe care programatorii dezvoltă aplica
ț
ii Java:

●
Java
SE.
Aplica
ț
iile
simple,
independente,
sunt
dezvoltate
folosind
Java

Standard
Edition.
Fost
cunoscut
sub
numele
de
J2SE,
Java
SE
oferă
toate

API-urile necesare dezvoltării aplica
ț
iilor desktop tradi
ț
ionale.

●
Java
EE.
Java
Enterprise
Edition,
cunoscut
anterior
ca
J2EE,
oferă

posibilitatea
de
a
crea
componente
pe
partea
de
server
care
pot
răspunde
la
o

cerere
pe
bază
de
solicitare
web.
Acest
aranjament
permite
crearea
de

programe
Java
care
pot
interac
ț
iona
cu
clien
ț
i
baza
ț
i
pe
internet,
inclusiv

browsere
web,
clien
ț
i
baza
ț
i
pe
CORBA
ș
i
chiar
servicii
web
bazate
pe
REST

ș
i SOAP.

●
Java
ME.
Java
oferă,
de
asemenea,
o
platformă
u
ș
oară
pentru
dezvoltarea

mobilă
cunoscută
sub
numele
de
Java
Micro
Edition,
cunoscută
anterior
ca

J2ME.
Java
ME
sa
dovedit
a
fi
o
platformă
foarte
populară
pentru
dezvoltarea

dispozitivelor
încorporate,
dar
sa
străduit
să
ob
ț
ină
trac
ț
iune
în
arena
de

dezvoltare
a
smartphone-urilor.
În
ceea
ce
prive
ș
te
dezvoltarea

smartphone-urilor, Android a devenit platforma de dezvoltare mobilă.

Folosind
diferitele
componente
furnizate
de
Java
EE,
este
u
ș
or
pentru
dezvoltatori
să

scrie
programe
care
folosesc
modele
de
design
populare
de
software
ș
i
convenite
în
mod

universal asupra celor mai bune practici.

De
exemplu,
framework-urile
Struts,
Spring
ș
i
JavaServer
Faces
utilizează
un
servlet

Java
pentru
a
implementa
modelul
de
design
al
controlerului
frontal
pentru
centralizarea

cererilor.

Între
timp,
o
mare
parte
a
ecosistemului
Java
este
o
mare
varietate
de
proiecte
open

source,
platforme
software
ș
i
API
pe
care
comunitatea
le-a
construit
folosind
limba.
De

exemplu,
Funda
ț
ia
Apac he
găzduie
ș
te
o
varietate
de
proiecte
scrise
folosind
Java,
printre

care:

●
Cadre simple de înregistrare pentru Java (SLF4J).

●
Cadre mari de procesare a datelor, cum ar fi Fire
ș
i Hadoop.

●
Platforme
de
integrare
precum
Apache
Camel,
Axa
Apache
ș
i
CXF
pentru

dezvoltarea de servicii web RESTful.

●
Platforme de dezvoltare de micro-servicii.

Mai
multe
întreprinderi
vor
încerca
să
transforme
mediile
Java
EE
în
cloud.
Pe

măsură
ce
dezvoltatorii
Java
creează
servicii
de
cloud
Java,
abilitatea
de
a
scala
rapid
aceste

servicii este o preocupare majoră, precum capacitatea de a colabora în cloud.

3.2 Sistemul de operare Android

Android
este
un
sistem
de
operare
mobil
dezvoltat
de
Google,
bazat
pe
o
versiune

modificată
a
kernel-ului
Linux
ș
i
a
altor
produse
software
open
source
ș
i
conceput
în
primul

rând
pentru
dispozitive
mobile
dotate
cu
“touchscreen”,
cum
ar
fi
smartphone-uri
ș
i
tablete.

În
plus,
Google
a
dezvoltat
în
continuare
Android
TV
pentru
televizoare,
Android
Auto

pentru
ma
ș
ini
ș
i
Wear
OS
pentru
ceasuri
de
mână,
fiecare
cu
o
interfa
ț
ă
de
utilizator

specializată.
Variantele
de
Android
sunt
de
asemenea
folosite
pe
console
de
jocuri,
camere

digitale, PC-uri
ș
i alte pro duse electronice [18].

Ini
ț
ial
dezvoltat
de
Android
Inc.,
pe
care
Google
la
cumpărat
în
2005,
Android
a
fost

lansat
în
2007,
cu
primul
dispozitiv
comercial
Android
lansat
în
septembrie
2008.
Sistemul

de
operare
a
trecut
de
atunci
prin
mai
multe
versiuni
importante,
versiunea
curentă
fiind
de

8.1
"Oreo"
,
lansat
în
decembrie
2017.
Codul
sursă
de
bază
Android
este
cunoscut
sub

numele
de
Android
Open
Source
Project
(AOSP)
ș
i
este
licen
ț
iat
în
principal
sub
licen
ț
a

Apache.

Android
este,
de
asemenea,
asociat
cu
o
multitudine
de
produse
software
dezvoltate

de
Google,
inclusiv
aplica
ț
ii
de
bază
pentru
servicii
precum
Gmail
ș
i
“Google
Search“,

precum
ș
i
magazinul
de
aplica
ț
ii
ș
i
platforma
de
distribu
ț
ie
digitală
Google
Play
ș
i
platforma

de
dezvoltare
asociată.
Aceste
aplica
ț
ii
sunt
licen
ț
iate
de
producătorii
de
dispozitive
Android

certificate
conform
standardelor
impuse
de
Google,
dar
AOSP
a
fost
folosit
ca
bază
pentru

ecosistemele
Android
concurente,
cum
ar
fi
Fire
OS
Amazon.com,
care
utilizează
propriile

lor echivalente cu Google Mobile Services.

Android
a
fost
cel
mai
bine
vândut
sistem
de
operare
din
întreaga
lume
pe

smartphone-uri
începând
din
2011
ș
i
pe
tablete
începând
cu
2013.
În
mai
2017,
are
peste

două
miliarde
utilizatori
activi
lunar,
cea
mai
mare
bază
instalată
a
oricărui
sistem
de
operare,

iar începând din 2017, Google Play magazin caracteristici peste 3,5 milioane de aplica
ț
ii.

Prima
versiune
comercială
de
Android,
1.5,
a
intrat
pe
pia
ț
ă
în
Aprilie
2009
sub

numele
Cupcake.
Toate
versiunile
de
Android,
de
altfel,
au
nume
de
cod
inspirate
după

diverse
deserturi
sau
dulciuri.
A
urmat
o
accelerare
a
dezvoltării,
fiind
lansată
următoarea

versiune
majoră,
2.1
Éclair,
înainte
de
finalul
aceluia
ș
i
an.
Primele
versiuni
cu
adevărat

mature
ș
i
cu
impact
semn ificativ
în
cadrul
comunită
ț
ii
de
dezvoltatori
au
fost
lansate
în
2010,

în mai (2.2 Froyo), respectiv decembrie (2.3 Gingerbread).

În
2011,
odată
cu
confirmarea
tabletelor
ca
pia
ț
ă
importantă
ș
i
cu
potential
pentru

tehnologia
mobile,
Google
a
lansat
versiunea
3.1
Honeycomb
a
sistemului
de
operare,

orientată
însă
exclusiv
spre
acestea.
Odată
cu
această
lansare
a
avut
loc
ș
i
o
puternică

consolidare
ș
i
unificare
a
serviciilor
din
zona
de
consumer
caracterizată
în
principal
prin

accentul
pus
pe
user
experience
cât
ș
i
pe
puternica
integrare
a
serviciilor
(GMail,
Search,

Calendar, etc.).

Honeycomb
a
fost
mai
mult
o
versiune
de
sacrificiu,
fiind
adoptată
doar
pe
un
număr

mic
de
tablete
care
au
pionierat
intrarea
Android
pe
acea
pia
ț
ă.
Cota
nu
a
depă
ș
it
2%.

Răspunsul
la
noua
versiune
a
fost
însă
foarte
pozitiv,
iar,
în
decembrie
2011,
Google

introduce
versiunea
4.0
Ice
Cream
Sandwich.
Această
versiune
aduce
împreună
versiunile

pentru
telefoane
ș
i
pentru
tablete,
unificând
în
acela
ș
i
timp
interfa
ț
a
grafică,
conferindu-i
un

stil aparte
ș
i o identitate p roprie.

În
topul
pe
luna
ianuarie
2018,
Android
Marshmallow
(versiunea
6.0)
rămâne
pe

primul
loc
fiind
instalat
pe
28,6%
din
dispozitivele
active.
Locul
doi
este
ocupat
de
Nougat

(versiunea
7.0),
versiunea
precedentă,
cu
26,3%
din
piață,
o
veste
bună,
având
în
vedere
că
și

adopția
sa
a
fost
destul
de
înceată
anul
trecut.
Locul
trei
este
însă
ocupat
de
Lollipop

(versiunea
5.0)
cu
25,1
%
din
total.
Având
în
vedere
că
aceste
trei
variante
sunt
și
cele
mai

recente
înainte
de
Oreo,
iar
fiecare
are
cam
un
sfert
din
total,
Am
ajuns
într-un
punct
în
care

platforma
Android
chiar
se
poate
lăuda
că
este
destul
de
modernă
în
comparație
cu
anii

precedenți, când Android KitKat era la putere [23].

Odată
cu
versiunea
5,
Android
a
adus
no
ț
iunea
de
aspect
material
“Material
design”,

care a schimbat masiv aspectul aplica
ț
iilor.

Platforma
acaparează
tot
mai
mult
din
pia
ț
a
de
terminale
mobile,
în
special
datorită

politicii
mult
mai
permisive
decât
cea
a
lui
Apple.
Android
este
prezent
în
peste
30%
din

terminalele
mobile
de
pe
pia
ț
a
globală
fiind
cel
mai
răspândit
sistem
de
operare
mobil.
Faptul

că
Android
are
până
în
prezent
8
versiuni
majore,
a
dus
la
fragmentarea
cotei
de
pia
ț
ă.
Totu
ș
i

doar
două
versiuni
ocupă
o
cota
semnificativă,
restul
fiind
destul
de
neglijabile
ca
pondere.

Astfel, cele mai răspândite versiuni sunt 6 cu 28.6%
ș
i 7 cu 26.3%.

Ca
orice
altă
platformă
de
dezvoltare,
Android
este
alcătuit
din
mai
multe
straturi,

fiecare reprezentând o func
ț
ie specifică
ș
i având responsabilită
ț
i clare. Acestea sunt:

Aplica
ț
iile
reprez entate
în
Figura
3.2.1,
sunt
reprezentate
prin
aplica
ț
iile
care
se
pot

găsi pe magazinul de aplica
ț
ii de pe sistemul Android.

Cadrul
de
aplica
ț
ii
reprezintă
o
parte
puternic
integrată
a
platformei
ș
i
a
SDK-ului
ș
i

oferă o serie de API-uri pentru interac
ț
iunea high-level cu sistemul de operare.

Librăriile
necesare,
așa
cum
sugerează
ș
i
numele,
aceasta
este
o
colec
ț
ie
de

componente
care
fac
legătura
dintre
sistemul
de
operare
ș
i
aplica
ț
ii.
Aici
sunt
con
ț
inute

func
ț
ii, cum ar fi stocarea de date, engine-ul grafic
ș
i altele.

Baza
este
reprezentată
de
sistemul
de
operare
care
este
bazat
pe
Linux
ș
i
se
comportă

exact ca
ș
i omologul de p e desktop.

Figura 3.2.1
​
Interac
ț
iunea dintre aplica
ț
ii
ș
i sistemul de operare Android

În
cadrul
aplica
ț
iei
noastre,
s-a
folosit
acest
sistem
de
operare
pentru
aplica
ț
ia
client

deoarece
este
cel
mai
răspândit,
este
gratuit,
permisiv
din
punct
de
vedere
al
dezvoltării,
în

compara
ț
ie
cu
dezvoltare a
de
aplica
ț
ii
pentru
Apple,
următorul
pe
lista
utilizării
telefoanelor

inteligente.
Pentru
aplica
ț
ia
Android
s-a
pornit
de
la
versiunea
5
ca
versiune
minimă,
cu

posibilitatea
de
a
o
adapta
ș
i
pentru
versiunea
4.
S-a
ales
versiunea
5
deoarece
a
fost
cea
care

a
adus
un
plus
considerabil
în
design,
iar
în
momentul
demarării
proiectului,
a
fost
versiunea

ce mai folosită de către utilizatori.

3.3 MySQL

MySQL
este
un
sistem
de
gestiune
a
bazelor
de
date
rela
ț
ionale,
produs
de
compania

suedeză
MySQL
AB
ș
i
distribuit
sub
Licen
ț
a
Publică
Generală
GNU.
Este
cel
mai
popular

sistem
de
gestiune
a
bazelor
de
date,
cu
sursele
disponibile
pe
internet
la
ora
actuală,
fiind
o

componentă cheie a stivei LAMP (Linux, Apache, MySQL, PHP) [8].

O
bază
de
date
este
o
colec
ț
ie
structurată
de
date.
Poate
să
fie
de
la
o
listă
simplă
de

cumpărături
până
la
o
galerie
de
imagini
sau
cantitatea
mare
de
informa
ț
ii
dintr-o
re
ț
ea

corporativă.
Pentru
a
adăuga,
a
accesa
ș
i
a
procesa
date
stocate
într-o
bază
de
date

computerizată,
ave
ț
i
nevoie
de
un
sistem
de
gestionare
a
bazelor
de
date,
cum
ar
fi
serverul

MySQL.
Deoarece
calculatoarele
sunt
foarte
bune
la
manipularea
unor
cantită
ț
i
mari
de
date,

sistemele
de
gestionare
a
bazelor
de
date
joacă
un
rol
central
în
calcul,
ca
utilită
ț
i
de
sine

stătătoare sau ca păr
ț
i ale altor aplica
ț
ii [24].

O
bază
de
date
rela
ț
ională
stochează
datele
în
tabele
separate,
în
loc
să
pună
toate

datele
într-un
depozit
mare.
Structurile
bazei
de
date
sunt
organizate
în
fi
ș
iere
fizice

optimizate
pentru
viteză.
Modelul
logic,
cu
obiecte
precum
baze
de
date,
tabele,
vizualizări,

rânduri
ș
i
coloane,
oferă
un
mediu
de
programare
flexibil.
Se
pot
stabili
reguli
care

reglementează
rela
ț
iile
dintre
diferitele
câmpuri
de
date,
cum
ar
fi
unu-la-unu,
unul-la-multe,

unic,
necesar
sau
op
ț
ional
ș
i
"
indicii
"
între
diferite
tabele.
Baza
de
date
aplică
aceste
reguli,

astfel
încât,
cu
o
bază
de
date
bine
concepută,
aplica
ț
ia
dvs.
nu
vede
niciodată
date

inconsistente, duplicate, singure, depă
ș
ite sau lipsite de date.

Partea
SQL
a
"MySQL"
înseamnă
"Language
Structured
Query".
SQL
este
cea
mai

comună
limbă
standardizată
folosită
pentru
a
accesa
bazele
de
date.
În
func
ț
ie
de
mediul
dvs.

de
programare,
este
posibil
să
introduce
ț
i
direct
SQL
(de
exemplu,
pentru
a
genera
rapoarte),

să
încorpora
ț
i
instruc
ț
iunile
SQL
în
cod
scrise
într-o
altă
limbă
sau
să
utiliza
ț
i
un
API
specific

limbajului
care
ascunde
sintaxa
SQL,
în
cazul
aplica
ț
iei
noastre,
un
exemplu
bun
este

utilizarea
Hibernate
care
permite
scrierea
cererilor
către
baza
de
date
într-un
limbaj
generic

care permite schimbarea bazei de date fără a fi necesară adaptarea cererilor (queries).

SQL
este
definit
de
standardul
ANSI
/
ISO
SQL.
Standardul
SQL
a
evoluat
din
1986

ș
i
există
mai
multe
versiu ni.
În
acest
manual,
"SQL-92"
se
referă
la
standardul
lansat
în
1992,

"SQL:
1999"
se
referă
la
standardul
lansat
în
1999,
iar
"SQL:
2003"
se
referă
la
versiunea

curentă
a
standardului.
Folosim
expresia
"standardul
SQL"
pentru
a
însemna
oricând

versiunea curentă a standardului SQL.

“Open
Source”
înseamnă
că
este
posibil
ca
oricine
să
utilizeze
ș
i
să
modifice
codul

sursă.
Oricine
poate
descărca
codul
MySQL
de
pe
Internet
ș
i
îl
poate
folosi
fără
să
plătească

nimic.
Dacă
dori
ț
i,
pute
ț
i
să
studia
ț
i
codul
sursă
ș
i
să
îl
modifica
ț
i
în
func
ț
ie
de
nevoile
dvs.

Aplica
ț
ia
MySQL
folose
ș
te
GPL
(GNU
General
Public
License) ,
pentru
a
defini
ceea
ce
este

posibil
ș
i nu se poate face cu software-ul în situa
ț
ii diferite

Serverul
MySQL
a
fost
dezvoltat
ini
ț
ial
pentru
a
gestiona
bazele
de
date
mari
mult

mai
repede
decât
solu
ț
iile
existente
ș
i
a
fost
utilizat
cu
succes
în
medii
de
produc
ț
ie
extrem
de

exigente
timp
de
mai
mul
ț
i
ani.
De
ș
i
în
curs
de
dezvoltare,
MySQ L
Server
oferă
astăzi
un
set

bogat
ș
i
util
de
func
ț
ii.
Conectivitatea,
viteza
ș
i
securitatea
fac
MySQL
Server
foarte
potrivit

pentru accesarea bazelor de date pe Internet.

3.4 Hibernate framework

Lucrul cu software orientat obiect
ș
i baze de date rela
ț
ionale poate fi time-consuming

ș
i poate cauza diverse ero ri datorită diferen
ț
elor dintre reprezentarea datelor în baza de date
ș
i

modelarea lor în obiecte.

Hibernate este o biblioteca ORM()Object-Relational Mapping) pentru limbajul Java, utilă

pentru maparea modelului orientat pe obiecte pe bazele de date rela
ț
ionale. Principalul atu al

acestei librării este faptul că oferă o solu
ț
ie rapidă, de înaltă performan
ț
ă, independentă de

tipul bazei de date folosite pentru modelarea obiectelor unei baze rela
ț
ionale.

Aceasta tehnologie este free si open source, distribuita sub licenta GNU Lesser

General Public License.

Principala caracteristică a Hibernate este maparea între clasele Java
ș
i tabelele bazelor de date

precum
ș
i între tipurile de date Java
ș
i SQL. Hibernate pune la dis pozitie posibilitatea

redactării de query-uri si data-retrieval.

Hibernate este o solu
ț
ie pentru Object-Relational-Mapping pentru Java. Este o

tehnologie gratis creată de Gavin King în 2001. Este un puternic, foarte performant,

Object-Relational Persistence serviciu pentru orice aplica
ț
ie Java.

Hibernate mapează clasele Java pe tabelele bazei de date, astfel se pot folosi direct

obiecte Java pentru a transforma informa
ț
iile din baza de date.

Maparea claselor Java pe tabele dintr-o bază rela
ț
ională se realizează prin

configurarea unui fi
ș
ier X ML sau prin folosirea de adnotări Java. Atunci când se alege prima

variantă, Hibernate poate genera un schelet de cod pentru clasele persistente. Dacă se folosesc

adnotările Java acest lucru nu mai este necesar. Hibernate poate folosi oricare dintre cele

două variante pentru a men
ț
ine schema bazei de date.

Hibernate
oferă
posibilitatea
de
a
realiza
rela
ț
ii
one-to-one
sau
many-to-many
între

clase.
De
asemenea
se
pot
realiza
asocieri
reflexive
între
un
obiect
ș
i
mai
multe
instan
ț
e
din

acela
ș
i timp, rela
ț
ie de tip one-to-many.

Configurările
necesare
pentru
lucrul
cu
Hibernate
se
realizează
în
fi
ș
erul
​
hibernate.cfg.xml
​
.

Acest fi
ș
ier con
ț
ine informatii pentru realizarea conexiunii JDBC precum:

ș
propietăti –
​
property

ș
connection.driver_class

ș
connection.url

ș
connection.username

ș
connection.password

ș
connection.pool_size
​
– folosit pentru configurarea pool-ului

ș
dialect
​
– specifica dialectul pe care Hibernate o va converti

ș
hbm2ddl.auto
​
– activează generarea schemei bazei de date direct

în baza de date;

ș
mapări persistente pentru clasele POJO –
​
mapping

ș
class
​
– numele clasei mapate referitor la pachetul în care se află

ș
resource
​
– localizează clasa folosind java.lang.ClassLoader

3.5 Spring Framework

Spring Framework este o platformă Java care oferă suport complet pentru

infrastructură pentru dezvoltarea aplica
ț
iilor Java. Spring se ocupă de infrastructură, astfel

încât putem să ne concentrăm asupra aplica
ț
iei.

Spring permite construirea de aplica
ț
ii din "Plain Old Java Object" (POJOs)
ș
i

aplicarea de servicii asupra POJOs. Această posibilitate se aplică complet modelului de

programare Java SE
ș
i par
ț
ial modelului Java EE.

Spring facilitează crearea de aplica
ț
ii pentru întreprinderi Java. Acesta oferă tot ce

ave
ț
i nevoie pentru a îmb ră
ț
i
ș
a limbajul Java într-un mediu de afaceri, cu suport pentru

Groovy
ș
i Kotlin ca limbi alternative pe JVM
ș
i cu flexibilitatea de a crea multe tipuri de

arhitecturi în func
ț
ie de n evoile unei aplica
ț
ii. Începând cu Spring Framework 5.0, Spring

necesită JDK 8+ (Java SE 8+)
ș
i oferă deja suport pentru JDK 9.

Spring suportă o gamă largă de scenarii de aplicare. Într-o întreprindere mare,

aplica
ț
iile există adesea p entru o lungă perioadă de timp
ș
i trebuie să ruleze pe un server JDK

ș
i aplica
ț
ie al cărui ciclu de upgrade este dincolo de controlul dez voltatorilor. Al
ț
ii pot rula ca

un singur “Jar” cu serverul incorporat, eventual într-un mediu de tip cloud. Cu toate acestea,

altele pot fi aplica
ț
ii indep endente (cum ar fi loturi sau volume de integrare) care nu au

nevoie de un server.

Primavara este open source. Are o comunitate vastă
ș
i activă, care oferă feedback

continu bazat pe o gamă largă de cazuri de utilizare în lumea reală. Acest lucru a ajutat

Spring să evolueze cu succes într-un timp foarte îndelungat.

Termenul "Spring" înseamnă lucruri diferite în diferite contexte. Acesta poate fi

folosit pentru a face referire la proiectul Spring Framework însu
ș
i, de unde a început totul.

Cel mai adesea, atunci când oamenii spun "Spring", ei în
ț
eleg întreaga familie de proiecte.

Spring Framework este împăr
ț
it în module. Aplica
ț
iile pot alege modulele de care au

nevoie. În centru modulelor este containerul de bază, incluzând un modul de configurare
ș
i un

mecanism de injec
ț
ie a de pendin
ț
elor. Dincolo de aceasta, framew ork-ul Spring oferă suport

fundamental pentru diferite arhitecturi de aplica
ț
ii, inclusiv mesagerie, date tranzac
ț
ionale
ș
i

persisten
ț
ă
ș
i web. Acesta include, de asemenea, site-ul de web M ervent MVC bazat pe

Servlet
ș
i, în paralel, cadr ul web reactiv Spring Web.

O idee importantă este: librăriile Spring permit implementarea pe calea versiunii Java,

JDK 9 ("Jigsaw"). Pentru utilizarea în aplica
ț
iile Jigsaw, librăriile Spring Framework 5 vin cu

denumiri automatizate a modulelor "Automatic-Module-Name" care definesc nume de

module stabilite la nivel de limbă ("spring.core", "spring.context" etc).

Spring este folosit în sistemul Food Ordering System pentru server, unde

administrează ciclul de via
ț
ă a obiectelor, de
ț
ine configurările pentru Hibernate
ș
i conexiunea

cu baza de date
ș
i expune servicii web cu ajutorul librăriei Jersey.

3.6 Maven

Maven
este
un
sistem
de
construire
ș
i
management
al
proiectelor,
scris
în
Java.
Face

parte
din
proiectele
găzduite
de
Apache
Software
Foundation.
Este
un
tool
open
source

(instrument
cu
codul
sursă
deschisă)
care
este
pe
larg
utilizat
atât
de
majoritatea
proiectelor

Java
OpenSource,
cât
ș
i
de
altele.Ce
este
Maven?
Cea
mai
mare
parte
a
utilizatorilor
Maven

vor
spune
că
Maven
este
uninstrument
pentru
build,
în
timp
ce
defini
ț
ia
de
pe
pagina
oficială

a
proiectului
ApacheMaven
spune
că
Maven
este
un
instrument
pentru
management
al

proiectelor.
Un
instrument
pentru
build
se
axează
în
principal
pe
preprocesare,

compilare,ambalare
(packaging),
testare
ș
i
distribuie.
Un
instrument
pentru
management,

cum
ar
fi
Maven,
în
plus
fa
ț
ă
de
capacită
ț
ile
de
build
pe
care
le
are,
ș
i
care
sunt
cu
mult
mai

simple
ș
i
u
ș
oare
în
folosire,
mai
prevede
de
asemenea
ș
i
un
ciclu
de
via
ț
ă
al
proiectului,
un

sistem
de
management
al
dependin
ț
elor,
poate
rula
rapoarte,
genera
o
pagină
web
a

proiectului,
facilitează
comunicarea
între
membrii
echipei
de
lucru
prin
oferirea
unei
interfe
ț
e

comune,
ș
i multe alte fac ilită
ț
i [9].

O
caracteristică
centrală
în
Maven
este
managementul
dependen
ț
ei.
Mecanismul
de

gestionare
a
dependin
ț
elor
Maven
este
organizat
în
jurul
unui
sistem
de
coordonate
care

identifică
artefacte
individuale,
cum
ar
fi
librăriile
sau
modulele.
Un
exemplu
foarte
folosit
de

proiectele
Maven
este
Junit
care
este
în
general
o
dependen
ț
ă
directă
a
proiectului.
Un
proiect

care
are
nevoie,
să
zicem,
de
biblioteca
Hibernate
trebuie
doar
să
declare
coordonatele
din

proiectului
Hibernate
în
POM.
Maven
va
descărca
automat
dependin
ț
a
ș
i
dependin
ț
ele
pe
care

le
are
Hibernate
(numite
dependin
ț
e
tranzitive)
ș
i
le
va
stoca
în
local.
Maven
2
Central

Repository
este
utilizat
în
mod
implicit
pentru
a
căuta
librării,
însă
se
pot
configura
depozite

de librarii care vor fi utilizate (de exemplu, un repository privat al companiei) în cadrul POM.

Există
motoare
de
căutare,
cum
ar
fi
motorul
de
căutare
Maven
central,
care
poate
fi

folosit
pentru
a
găsi
coordonate
pentru
diferite
biblioteci
ș
i
librării
care
au
implementarea

oferită gratis pentru comunitate.

Proiectele
dezvoltate
pe
o
singură
ma
ș
ină
pot
depinde
una
de
cealaltă
prin
depozitul

local.
Depozitul
local
este
o
structură
de
directoare
care
ac
ț
ionează
atât
ca
o
memorie
cache

pentru
dependen
ț
ele
descărcate,
cât
ș
i
ca
un
loc
de
stocare
centralizat
pentru
artefacte

construite
local.
Comanda
Maven
”mvn
install”
construie
ș
te
un
proiect
ș
i
plasează
fi
ș
ierele

binare
în
repozitoriul
local.
Apoi,
alte
proiecte
pot
utiliza
acest
proiect
prin
specificarea

coordonatelor în POM-urile lor.

3.7 Servicii REST

Mai
mult
de
un
deceniu
după
introducerea
sa,
REST
a
devenit
una
dintre
cele
mai

importante
tehnologii
pentru
aplica
ț
iile
Web.
Importan
ț
a
sa
este
probabil
să
continue
să

crească
rapid,
pe
măsură
ce
toate
tehnologiile
se
îndreaptă
către
o
orientare
API.
Fiecare

limbaj
de
dezvoltare
majoră
include
acum
cadre
pentru
construirea
serviciilor
Web
RESTful.

Ca
atare,
este
important
ca
dezvoltatorii
web
ș
i
arhitec
ț
ii
să
aibă
o
în
ț
elegere
clară
a

serviciilor
REST
ș
i
RESTful.
Acest
tutorial
explică
REST
arhitectural,
apoi
scufundă
în

detaliile de utilizare a acestuia pentru activită
ț
i comune bazate pe API.

În
timp
ce
REST
reprezintă
“Representational
State
Transfer”,
care
este
un
stil

arhitectural
pentru
aplica
ț
iile
hypermedia
în
re
ț
ea,
este
folosit
în
principal
pentru
a
construi

servicii
Web
care
sunt
u
ș
or
de
între
ț
inut
ș
i
scalabile.
Un
serviciu
bazat
pe
REST
este
numit

serviciu
RESTful.
REST
nu
depinde
de
niciun
protocol,
dar
aproape
fiecare
serviciu
RESTful

folose
ș
te HTTP ca protoc ol de bază [12].

Fiecare
sistem
utilizează
resurse.
Aceste
resurse
pot
fi
imagini,
fi
ș
iere
video,
pagini

web,
informa
ț
ii
de
aface ri
sau
orice
altceva
care
poate
fi
reprezentat
într-un
sistem
bazat
pe

computer.
Scopul
unui
serviciu
este
de
a
oferi
o
interfa
ț
ă
clien
ț
ilor
săi,
astfel
încât
ace
ș
tia
să

aibă
acces
la
aceste
resurse.
Arhitec
ț
ii
ș
i
dezvoltatorii
de
servici i
doresc
ca
acest
serviciu
să

fie
u
ș
or
de
implementat,
u
ș
or
de
între
ț
inut,
extensibil
ș
i
scalabil.
Un
design
RESTful
promite

acest lucru
ș
i mai mult.

Obiectivul
unui
serviciu
RESTful
se
referă
la
resurse
ș
i
la
modul
de
a
oferi
acces
la

aceste
resurse.
O
resursă
poate
fi
u
ș
or
de
gândit
ca
un
obiect
ca
ș
i
în
cazul
OOP.
O
resursă

poate
consta
din
alte
resurse.
În
timp
ce
proiectează
un
sistem,
primul
lucru
de
făcut
este

identificarea
resurselor
ș
i
determinarea
rela
ț
iei
dintre
ele.
Aceasta
este
similară
cu
prima

etapă a proiectării unei baze de date: Identificarea entită
ț
ilor
ș
i a rela
ț
iilor.

Odată
ce
ne-am
identificat
resursele,
următorul
lucru
de
care
avem
nevoie
este
să

găsim
o
modalitate
de
a
reprezenta
aceste
resurse
în
sistemul
nostru.
Pute
ț
i
utiliza
orice

format
pentru
reprezentarea
resurselor,
deoarece
REST
nu
pune
o
restric
ț
ie
asupra
formatului

unei reprezentări.

Cele mai folosite tipuri de servicii RESTful sunt[16]:

●
POST:
upload-ul
unei
noi
resurse
(creare
sau
modificare).
Execu
ț
ii
repetate
pot
avea

efecte distincte.

●
PUT:
crearea
unei
noi
resurse.
Execu
ț
ii
repetate
vor
avea
acela
ș
i
efect
ca
ș
i
o
singură

execu
ț
ie IDEMPO TENT.

●
GET:
cititrea
unei
resurse
fără
a
modifica
resursa.
Opera
ț
ia
nu
trebuie
să
fie
folosită
la

creare de resurse.

●
DELETE:
stergerea
unei
resurse.
Execu
ț
ii
repetate
vor
avea
acela
ș
i
efect
ca
ș
i
o

singură execu
ț
ie IDEMPOTENT.

Conceptul
de
REST
a
fost
folosit
ini
ț
ial
în
anii
2000,
de
Roy
Fielding.
Câteva
aspecte
legate

de serviciile REST:

1.
Este
un
stil
architectural
simplu
bazat
pe
standarde
Web
ș
i
HTTP
(câ
ș
tigând
teren
în

fa
ț
a unor model e ca
ș
i SOAP)

2.
Este
o
arhitectură
client-server
bazată
pe
folosirea
resurselor.
Exemplu
de
resurse:

carte, produs, ma
ș
ină, etc.

3.
Comparativ
cu
SOAP,
REST
nu
este
foarte
strict
cu
tipurile
de
date,
este
mai
u
ș
or
de

citit folosind substantive
ș
i verbe
ș
i este mai pu
ț
in "verbose"

4.
Tratarea erorilor se face conform tratării erorilor în protocolului HTTP.

5.
Este
o
arhitectură
scalabilă
datorită
separării
de
responsabilită
ț
i
între
client
ș
i
server.

De
exemplu,
responsabilitatea
unui
client
este
să
men
ț
ină
starea
unui
utilizator,
în

timp
ce
serverul
nu
men
ț
ine
nici
o
stare,
dar
este
resposabil
de
managementul
datelor.

De
asemenea
între
request-uri
serverul
nu
trebuie
să
se
men
ț
ină
starea
clientului

(stateless).

6.
Clien
ț
ii
pot
folosi
tehnici
de
caching
pentru
cre
ș
trea
performan
ț
ei
ș
i
scalabilită
ț
ii
unei

solu
ț
iei.

7.
Partea
de
server
poate
să
con
ț
ină
mai
multe
nivele,
fără
ca
modificări
ale
acestora
să

afecteze
în
vreun
fel
clien
ț
ii.
Aceasta
abordare
ar
putea
duce
la
o
separare
de

responsibilită
ț
i
a
diferitelor
nivele,
ca
de
exemplu:
load
balancing,
securitate,
stocarea

datelor, caching de resurse.

8.
Resursele
pot
avea
diferite
reprezentări
(JSON,
XML,
definit
de
user,
etc),
folosirea

lor
determinându-se
conform
protocolului
HTTP
(de
exemplu
folosind
HTTP

Headers).

În
aplica
ț
iile
proiectului
Food
Ordering
System,
serviciile
RESTful
sunt
folosite
pe

partea
de
server,
care
expune
servicii
pentru
ca
aplica
ț
iile
client
să
poată
avea
baza
de
date

comună
ș
i
pentru
a
intero ga
informa
ț
ii
de
care
ambele
au
nevoie .
Serviciile
REST
mai
pot
fi

numite
ș
i conectorii aplic a
ț
iilor.

4. Detalii de implementare

În acest capitol se prezintă detaliile de implementare atât pentru aplica
ț
ia Android, cât

ș
i pentru aplica
ț
ia server. Aplica
ț
ia web este în stadiul de design.

4.1 Aplica
ț
ia server

Aplica
ț
ia
server
este
dezvoltată
utilizând
limbajul
Java,
fiind
un
proiect
Maven,

împăr
ț
it
pe
module
(Figura
4.1.1).
Această
aplica
ț
ie
este
împăr
ț
ită
pe
module
(proiecte

Maven
ce
sunt
tratate
ca
dependin
ț
e
pentru
alte
proiecte),
pentru
a
asigura
posibilitatea
de

reutilizare a modulelor, sau pentru a avea “Low-Coupling” (dependin
ț
ă u
ș
oară între ele).

●
Primul
proiect
Maven
(forsys),
este
folosit
ca
proiect
agregator,
care
are
rolul

de
a
ț
ine
toate
modulele
într-un
proiect
mai
mare,
ajutând
astfel
la
build.

Pentru
a
face
un
build
modulelor,
este
necesar
ca
modulele
să
fie
inserate
în

pom
într-o
ordine
specificată
de
dependin
ț
a
dintr-e
ele.
Un
modul
utilizat
ca

dependin
ț
ă
trebuie
să
fie
prioritar
în
ordinea
de
build,
în
compara
ț
ie
cu
cel
care

îl are ca
ș
i dependin
ț
ă.

●
Al
doilea
proiect
Maven,
fiind
primul
ca
ordine
de
build,
este
“forsys-parent”

care
are
rolul
de
a
administra
dependin
ț
ele
externe.
În
fi
ș
ierul
“pom.xml”
al

acestui
proiect,
se
află
definită
fiecare
dependin
ț
ă
externă
a
tuturor
modulelor,

cu
versiune,
urmând
ca
în
modulele
care
au
nevoie
de
dependin
ț
ă,
să
se

definească
numai
artefactul
ș
i
id-ul
grupului
dependin
ț
ei.
În
cazul
în
care
se

dore
ș
te
schimbarea
versiunii
unei
dependin
ț
e,
atunci
se
schimbă
din
fi
ș
ierul

“pom.xml”
a
proiectului
“parent”
iar
toate
proiectele
care
folosesc
acea

dependin
ț
ă,
o
să
primească
noua
dependin
ț
ă.
În
acest
proiect
se
mai
pot
defini

proprietă
ț
i
specifice
întregului
proiect
ș
i
care
să
fie
utilizare
în
celelalte

module Maven.

●
Al
treilea
proiect
Maven,
“commons”
este
al
doilea
în
ordinea
de
build.
Acest

proiect
reprezintă
foarte
bine
stratul
arhitectural
“Cross-Cutting”
care
cuprinde

toate
elemente
ce
se
folosesc
în
toate
modulele.
El
este
dependin
ț
ă
pentru

modulele:
Persistence,
Business
ș
i
Web-Service.
Modulul
cuprinde
elemente

comune
precum
obiectele
de
transfer
“Data
Transfer
Object”,
folosite
pentru
a

evita
utilizarea
entită
ț
ilor
(obiectele
reprezentative
ale
tabelelor
din
baza
de

date)
prin
celelalte
module.
Un
alt
element
comun
ce
se
găse
ș
te
în
acest
modul

este
sistemul
de
excep
ț
ii
ș
i
logarea
mesajelor
de
eroare
în
fi
ș
iere.
De
asemenea

aici
se
pot
adăuga
orice
fel
de
clase
utilitare
care
se
pot
folosi
în
cel
pu
ț
in
două

module din proiect.

●
Cel
de
al
patrulea
proiect
Maven,
“persistence”
este
al
treilea
în
ordinea
de

build
deoarece
depinde
direct
de
modulul
“commons”.
Acest
modul
se

folose
ș
te
pentru
a
administra
baza
de
date.
Aici
se
mapează
entită
ț
i
la
tabele

din
baza
de
date,
urmând
ca
printr-o
sesiune
cu
baza
de
date,
să
se
acceseze

datele
prin
clase
specializate
“Data
Acces
Object”.
În
acest
modul,
se
definesc

interfe
ț
e
care
care
definesc
contractul
care
trebuie
implementat
ulterior,
în
a
ș
a

fel
încât
doi
programatori
pot
lucra
în
acela
ș
i
timp
la
două
implementări

diferite ce servesc acela
ș
i set de ac
ț
iuni dar cu o im plementare diferită.

●
Cel
de
al
cincilea
modul
Maven,
“business”
este
al
patrulea
în
ordinea
de

build,
deoarece
el
depinde
de
modulele
“commons”
ș
i
“persistence”.
În
acest

modul
se
implementează
logica,
el
are
rolul
unui
“Controller”,
de
a
prelucra

informa
ț
ia
ș
i
a
o
pregăti
pentru
salvare
sau
predarea
ei
mai
departe,
către

modulul
de
servicii
sau
un
alt
modul
având
în
vedere
că
din
acest
modul

rezultă
un
“Jar”.
În
acest
modul
se
injectează
“Data
Access
Objects”
pentru
a

comunica
cu
baza
de
date.
De
asemenea,
de
la
modulul
“persistence”
se

primesc
obiecte
de
transfer
(Transfer
Objects)
pentru
a
transmite
informa
ț
ia

mai departe.

●
Cel
de
al
ș
aselea
modul
este
“service”,
care
este
al
cincilea
în
ordinea
de
build.

Acest
modul
are
ca
dependin
ț
ă
directă
modulul
“business”
care
aduce
la

rândul
lui
librăria
“persistence“,
care
aduce
mai
departe
librăria
“commons”.

În
acest
modul
se
expun
servicii
RESTful
cu
ajutorul
librăriei
Jersey.
Acest

modul se împachetează la build ca jar.

●
Cel
de
al
ș
aptelea
modul
este
“war”,
care
este
ultimul
în
ordinea
de
build

deoarece
acesta
are
ca
dependin
ț
ă
directă
librăria
“service”
care
aduce
mai

departe
toate
librăriile
rezultate
mai
sus
în
ordinea
de
build.
Acest
modul
are

rolul
împachetării
ș
i
pregătirii
proiectului
pentru
a
putea
fi
pus
în
func
ț
iune
pe

un
container
de
aplica
ț
ii.
Împachetarea
este
de
tipul
“WAR
–
Web
Archive”

deoarece este nevoie ca aceasta sa poată fi interpretată ca o aplica
ț
ie web.

●
Ultimul
modul
este
“project-config”
ș
i
este
folosit
pentru
a
cuprinde
toate

configurările
pentru
ca
proiectul
să
poată
fi
mutat
pe
orice
ma
ș
ina
care
are
un

JVM instalat.

În
Figura
4.1.2
este
prezentat
fi
ș
ierul
“web.xml”
care
este
primul
fi
ș
ier
executat
de

containerul
de
aplica
ț
ii
atunci
când
se
instalează
aplica
ț
ia.
Acest
fi
ș
ier
mai
are
denumirea
de

descriptor.
În
prima
parte
a
fi
ș
ierului,
se
define
ș
te
calea
către
fi
ș
ierul
de
configurare
pentru

Spring,
care
urmează
să
se
execute
imediat.
După
executarea
fi
ș
ierului
“spring-config”,
se

ini
ț
ializează contextul Jer sey pentru expunerea serviciilor web din modulul de servicii.

În
Figura
4.1.4
este
prezentat
fi
ș
ierul
de
configurare
“spring-config.xml”
din
modulul

“war”
care
este
folosit
pentru
a
defini
configurările
pentru
Spring.
Spring
este
un
tool
foarte

puternic
care
oferă
posibilitatea
de
a
crea
o
sesiune
cu
baza
de
date,
administrează
ciclul
de

via
ț
ă
al
obiectelor,
creează
instan
ț
e
de
obiecte
pe
baza
adno tărilor
pe
care
le
injectează

ulterior
oriunde
este
necesar.
În
Figura
4.1.4
se
define
ș
te
un
bean
numit
“dataSource”
care

creează
la
runtime
o
sesiune
cu
baza
de
date.
Următorul
bean
se
nume
ș
te
“sessionFactory”
ș
i

este
definit
pentru
ca
ulterior
să
fie
injectat
în
obiectele
de
tip
“DAO
–
Data
Access
Object”

din
modulul
“persistence”
pentru
a
avea
acces
la
sesiunea
creată
către
baza
de
date.
De

asemenea,
avem
“transactionManager”
care
ne
ajută
să
să
creăm
tranzac
ț
ii
cu
baza
de
date.

Spring
administrează
ciclul
de
via
ț
ă
a
obiectelor,
ceea
ce
înseamnă
că
e
nevoie
să
ș
tie
ce

obiecte
administrează,
iar
pentru
asta
există
definit
tag-ul
“context:component-scan”
care

cuprinde
toate
pachetele
în
care
Spring
ar
trebui
să
caute
pentru
clase
care
trebuie
să
fie

administrate.

Figura 4.1.1
​
Structura proiectului Maven

În
Figura
4.1.5
este
prezentă
maparea
unei
entită
ț
i
pe
baza
de
date
utilizând

“Hibernate”
ș
i
“JPA
–
Java
Persistence
Api”
ca
ș
i
tehnologii
pentru
baza
de
date.
Clasa

“User”
este
adnotată
cu
“@Entity”
pentru
ca
“Hibernate”
să
ș
tie
ca
aceasta
reprezintă
o

entitate.
Mai
departe,
urmează
adnotarea
“@Table”
care
are
numele
tabelei
pe
care
este

mapată
această
entitate.
Cu
ajutorul
acestor
tehnologii,
putem
defini
coloanele
prin
adăugarea

unei
adnotări
în
sens,
a
defini
id-ul
unic
al
tabelei
sau
a
adăuga
diferite
constrângeri
pentru

fiecare coloană din baza de date.

În
Figura
4.1.3
este
prezentat
un
exemplu
de
“@Repository”
care
este
interpretat
de

Spring
ca
o
clasă
care
are
rolul
de
a
administra
opera
ț
iile
pe
baza
de
date
pentru
utilizatori.
În

toate
clasele
care
administrează
opera
ț
ii
pe
baza
de
date,
se
injectează
sesiunea
către
baza
de

date
(definită
în
spring-config.xml).
Aceasta
clasă
implementează
interfa
ț
a
“IUserDao”,
care

extinde
o
interfa
ț
ă
gener ică
numită
“IDao”
care
are
rolul
de
a
defini
metodele
în
func
ț
ie
de

genericitatea
functionalită
ț
ii:
Un
exemplu
bun
este
metoda
“findAll()”
ce
se
găse
ș
te
în
Figura

4.1.3
ș
i
este
definită
în
“IDao”
deoarece
se
poate
aplica
pe
orice
tabelă
din
baza
de
date
care

are
cel
pu
ț
in
două
înregis trări.
Acestă
metodă
returnează
o
listă
de
obiecte
de
transfer
de
tipul

“UserTO”
deoarece
sunt
momente
în
care
în
obiectele
de
transfer
se
adaugă
proprietă
ț
i

speciale
care
nu
sunt
reprezentate
în
baza
de
date,
caz
în
care
entită
ț
ile
nu
ar
mai
reprezenta
o

tabelă
din
baza
de
date.
Pentru
a
transmite
obiecte
de
transfer
avem
clase
utilitare
care

convertesc obiectele de transfer în entită
ț
i sau invers.

Figura 4.1.2
​
Structura proiectului Maven

​
Figura 4.1.3
​
Clasa pentru administrarea opera
ț
iilor pe baza de date

Figura 4.1.4
​
Fi
ș
ierul de configurare pentru Spring

Figura 4.1.5
​
Maparea unei entită
ț
i utilizând Hibernate

4.2 Aplica
ț
ia Android

Sistemul
de
aplica
ț
ii
începe
cu
aplica
ț
ia
Android
este
construită
folosind
limbajul
Java

ș
i
un
număr
de
librării
utilitare.
Conceptul
aplicat
pentru
implementarea
aplica
ț
iei
este
MVC.

Interfe
ț
ele
sunt
impleme ntate
utilizând
activită
ț
i
ș
i
fragmente,
un
exemplu
de
interfa
ț
ă
este

prezentat în Figura 4.2.1.

Defini
ț
ie
1[
​
11
​
]
Un
fragment
reprezintă
un
comportament
sau
o
por
ț
iune
a
interfe
ț
ei
de

utilizator
într-o
activitate.
Se
pot
combina
mai
multe
fragmente
într-o
singură
activitate

pentru
a
crea
un
interfa
ț
ă
UI
multiplă
ș
i
se
poate
reutiliza
un
fragment
în
mai
multe

activită
ț
i.
Conceptual,
un
fragment
se
poate
gândi
ca
o
sec
ț
iune
modulară
a
unei
activită
ț
i,

care
are
propriul
ciclu
de
via
ț
ă,
prime
ș
te
propriile
evenimente
de
intrare
ș
i
pe
care
le
pute
ț
i

adăuga
sau
elimina
în
timp
ce
activitatea
se
desfă
ș
oară
(un
fel
de
"subactivitate"
care
se

poate reutilizarea în diferite activită
ț
i).

Defini
ț
ie
2[
​
10
​
]
O
activ itate
reprezintă
un
singur
screen
cu
propriul
ciclu
de
via
ț
ă.
O

activitate este o subclasă a ContextThemeWrapper.class.

Figura 4.2.1
​
Utilizarea unui fragment în fi
ș
ierul interfe
ț
ei

Mai
departe,
se
exemplifică
comunicarea
dintre
aplica
ț
ia
server,
web
ș
i
aplica
ț
ia

Android
folosind
bucă
ț
i
de
cod,
se
explică
pa
ș
i
care
includ
folosirea
unor
tehnologii
sau
a

unor librării.

În
aplica
ț
ia
client ,
după
ce
un
client
adaugă
în
co
ș
ul
de
cumpărături
produsele
dorite,

pentru
a
putea
plasa
comanda,
el
are
nevoie
de
un
cont
de
utilizator.
Pentru
a
crea
un
cont,
s-a

implementat
un
modul
de
înregistrare.
Înregistrarea
unui
utilizator
se
face
pe
server,
prin

urmare
este
nevoie
de
conexiune
la
internet
ș
i
un
pachet
de
clase
pentru
servicii.
În
Figura

4.2.2
se
prezintă
o
clasă
care
are
rolul
de
a
autentifica
un
utilizator
folosind
servicii
web.

Servicile
web
sunt
implementate
folosind
librăria
Volley
[7]
care
oferă
numeroase
avantaje

precum:

●
Programarea automată a request-urilor.

●
Conexiuni concurente către serviciile web.

●
Crearea unui cache al răspunsurilor care fac mult mai rapidă accesarea datelor.

●
Suport pentru prioritizarea cererilor.

●
Posibilitatea
de
oprire
a
requesturilor.
Se
poate
anula
un
singur
request,
sau
se

pot seta scopuri pentru anularea cererilor.

●
Posibilitatea unei customizări u
ș
oare;

●
Cererile pot fi asincrone, ceea ce permite actualizarea datelor din interfa
ț
ă.

●
Utilitare pentru “Debug”
ș
i “Tracking”.

Pentru
a
apela
serviciul
pentru
autentificare,
este
necesar
să
facem
o
cerere
de
tip

“GET”,
în
care
numele
utilizatorului
este
encodat
in
Base64,
urmând
ulterior
să
fie
criptat.

Răspunsul
cererii
poate
fi
unul
fără
eroare,
caz
în
care
este
prins
pe
“onResponse”,
unde
este

interpretat
iar
în
func
ț
ie
de
con
ț
inut
se
decide
dacă
utilizatorul
se
autentifică
sau
nu,
sau
poate

fi
prins
pe
“onErrorResponse”
caz
în
care
se
poate
interpreta
con
ț
inutul
de
tip
JSON
ș
i
afi
ș
a

în interfa
ț
ă mesajul de ero are.

Figura 4.2.2
​
Utilizarea serviciilor pentru a autentificare

5. Utilizarea Aplica
ț
iei

5.1 Descrierea Aplica
ț
iei Android

Aplica
ț
ia
dezvolta tă
exclusiv
pe
sistemul
de
operare
Android,
este
destinată
masei
de

clien
ț
i
care
doresc
să
predea
comenzi
complexe,
fără
a
a
ș
tepta
rândul
la
telefon,
astfel

asigurându-se
un
loc
monitorizat
în
ordinea
comenzilor.
S-a
precizat
monitorizat
deoarece

orice
comandă
trimisă
folosind
aplica
ț
ia
mobilă,
are
pe
langă
ora
de
trimitere,
un
status
curent

care ajută clien
ț
ii în a esti ma mai bine timpul de ridicare/livrare.

Aplica
ț
ia
Android
are
ca
ș
i
scop,
predarea
comenzilor
către
orice
restaurant
din
listă,

vizualizarea
statusului
comenzii
într-un
timp
real
ș
i
schimbul
de
mesaje
pe
comandă
în
cazul

în care apar complica
ț
ii, un exemplu este lipsa stocului unui anumit produs.

Pe
prima
pagina
a
aplica
ț
iei
apare
logo-ul
restaurantului,
acesta
având
rolul
de
a

a
ș
tepta până datele ini
ț
iale ale aplica
ț
iei sunt încărcate, Figura 5.1.1.

După
pregătirea
datelor,
se
afi
ș
ează
automat
prima
pagină
unde
utilizatorul
are
control

complet.
După
cum
se
vede
în
Figura
5.1.2
ș
i
Figura
5.1.3,
utilizatorul
are
posibilitatea
de
a

căuta
restaurantul
dorit
în
moduri,
prima
fiind
într-o
listă,
unde
fiecare
restaurant
are
o

imagine,
un
afi
ș
aj
refer itor
programul
restaurantului,
în
cazul
în
care
e
deschis,
în
afi
ș
aj

utilizatorul
vede
câte
ore
mai
este
deschis,
altfel
v-a
vedea
doar
faptul
că
este
închis.
De

asemenea,
dacă
utilizatorul
are
loca
ț
ia
pornită,
se
va
afi
ș
a
ș
i
distan
ț
a
până
fiecare
restaurant

raportat
la
loca
ț
ia
curen tă.
Utilizatorul
mai
poate
căuta
restaurantul
dorit
ș
i
în
func
ț
ie
de

pozi
ț
ia
lui
pe
hartă,
acesta
oferindu-i
de
asemenea
posibilitatea
de
a
viziona
informa
ț
ii
sumare

precum disponibilitatea restaurantului cât
ș
i distan
ț
a până la acesta.

​
Figura 5.1.1
​
Pagina temporară pentru încărcarea ini
ț
ială a datelor

Figura 5.1.2
​
Pagina restaurantelor sub formă de listă

În
general,
un
lan
ț
de
restaurante
poate
ajunge
ș
i
la
zeci
de
puncte
de
vânzare,
având

aceasta
în
vedere,
s-a
creat
ș
i
un
mod
de
filtrare,
în
cazul
acestui
lan
ț
,
filtrul
este
în
func
ț
ie
de

numele
ora
ș
ului.
Acest
filtru
este
de
tip
introducere
text,
aceasta
însemnând
că
utilizatorul

poate
introduce
ș
i
nu
selecta
ora
ș
ul
pe
care
îl
caută,
urmând
ca
doar
restaurantele
din
acel

ora
ș
să fie afi
ș
ate.

Bazat
pe
cele
spuse
anterior,
utilizatorul
poate
accesa
din
această
pagină
orice

restaurant,
cât
ș
i
un
meniu
contextual
care
îi
da
posibilitatea
de
a
crea
un
cont
sau
a
se

autentifica,
de
a
vedea
notificările,
de
a
accesa
istoricul
comenzilor
sau
de
a
accesa
pagina
de

setări a aplica
ț
iei.

Figura 5.1.3
​
Pagina restaurantelor organizate pe hartă

După
ce
utilizatorul
a
accesat
un
restaurant
din
listă
sau
de
pe
hartă,
i
se
afi
ș
ează
o

nouă
pagină,
pagina
restaurantului.
Acestă
pagina
include
trei
sec
ț
iuni,
doar
una
fiind
vizibilă

ș
i
putând
fi
schimbate
cu
ajutorul
tab-urilor.
Pe
lângă
sec
ț
iuni,
această
pagină
include
în

partea
de
sus,
informa
ț
ii
generice
despre
restaurant,
de
exemplu
pagina
de
Facebook,

Twitter/Google+,
logo
sau
un
ajutor
de
navigare
spre
restaurantul
curent.
Partea
de
sus

include
ca
ș
i
fotografie
de
fundal
o
imagine
din
restaurant,
altfel,
aceasta
fiind
înlocuită
cu

sigla companiei/lan
ț
ului d e restaurante.

Pe
pagina
restaurantului,
dacă
utilizatorul
are
un
cont,
atunci
este
pregătit
pentru

prima comandă, după cum se poate vedea în Figura 5.1.4.

Ini
ț
ial,
utilizatoru l
întâlne
ș
te
sec
ț
iunea
meniului,
unde
poate
consulta
meniul,
adăuga

în
co
ș
produsele
dorite
sau
poate
accesa
un
anumit
produs.
Utilizatorul
poate
vedea
ș
i
părerea

altor utilizatori referitoare la un anumit produs urmărind nota acordată.

Figura 5.1.4
​
Pagina restaurantului, sec
ț
iunea meniului

Cea
de
a
doua
sec
ț
iune,
sec
ț
iunea
pre-comenzii,
este
reprezentată
în
Figura
5.1.5
ș
i

este
folosită
pentru
a
avea
imagine
asupra
produselor
adăugate
în
co
ș
.
Această
pagină
oferă

atât
posibilitatea
de
a
vedea
detaliat
fiecare
produs
cu
ingrediente
extra
sau
specifica
ț
ii

speciale
pe
produs,
de
a
ș
terge
un
anumit
produs
din
co
ș
ul
de
cumpărături,
sau
de
a
modifica

detaliile
pentru
un
anumit
produs.
Produsele
din
cos
pot
fi
complexe,
caz
in
care,
exista
un

dialog
creat
special
pentru
aceasta
în
care
se
pot
vedea
detaliile
pentru
fiecare
produs,
se

poate
vedea
în
Figura
5.1.6.
Dialogul
pentru
detaliile
co
ș
ului
ajută
în
cazul
comenzilor

complexe, astfel u
ș
urând vizualizarea acestora.

Următorul
tab
este
cel
destinat
exclusiv
pentru
fidelizarea
clien
ț
ilor.
Comerciantul

poate
crea
oferte
pentru
fiecare
restaurant,
încât
să
atragă
clien
ț
ii,
aceste
informa
ț
ii
find

adăugate
din
aplica
ț
ia
destinată
comercian
ț
ilor.
De
asemenea,
o
dezvoltare
la
care
se
lucrează

este
un
sistem
de
data-mining
prin
care
să
generăm
cupoane
de
reducere
pentru
clien
ț
ii
fideli.

Pentru
a
face
asta
este
nevoie
de
foarte
multe
interogări
a
bazei
de
date,
pentru
a
extrage

informa
ț
ii
despre
capacit atea
de
cumpărare
a
unui
anumit
restaurant,
încât,
pe
baza
capacită
ț
ii

de
cumpărare,
să
extragem
clien
ț
ii
fideli,
iar
dacă
se
încadrează
în
anumite
tipare,
se
pot

genera
cupoane
de
reducere,
sau
în
func
ț
ie
de
for
ț
a
de
cumpărare
de
la
un
anumit
restaurant,

se pot oferi meniuri gratis.

Figura 5.1.5
​
Pagina restaurantului, sec
ț
iunea pre-comenzii

Figura 5.1.6
​
Detaliile unui produs adaugat in cos

În
pagina
destinată
fidelizării
utilizatorilor,
avem
un
fragment
în
care
fiecare

restaurant
poate
adăuga
ș
tiri
informative
referitor
la
un
nou
produs,
sau
bucătari
invita
ț
i

speciali,
etc..
Acest
modul
de
ș
tiri
poate
fi
dus
la
nivelul
următor,
încât
să
afi
ș
eze
informa
ț
iile

de
pe
pagina
web
a
restaurantului,
ș
i
adăugarea
unui
sistem
de
comentarii
unde
utilizatorii
pot

spune păreri despre
ș
tire.

Figura 5.1.7
​
Cupoane pentru clien
ț
ii fideli

În
sec
ț
iunea
a
treia,
numită
“Despre”,
vezi
Figura
5.1.7,
restaurantul
poate
adăuga

oferte
astfel
utilizatorii
sunt
tenta
ț
i
să
comande
conform
acesteia.
De
asemenea,
un
client
care

este
fidel
aplica
ț
iei
ș
i
comandă
des,
el
poate
primi
vouchere
pe
care
le
poate
folosi
ca

reducere
la
următoarele
comenzi.
Acest
modul,
cel
de
a
crea
vouchere,
are
scopul
de
a
crea

fidelitate,
de
a
avea
consumatori
constan
ț
i,
mul
ț
umi
ț
i
de
produ sele
oferite.
Cupoanele
sunt

generate
pe
client
în
timp
de
ofertele
sunt
generate
pe
restaurant,
oricine
poate
accesa
o
ofertă

însă
nu
oricine
poate
avea
un
cupon,
decât
dacă
numărul
comenzilor
este
mare
sau
comenzile

au
fost
într-un
procent
foarte
mare
livrate/ridicate
cu
succes.
Componenta
de
ș
tiri
este
folosită

pentru
a
ț
ine
un
curs
al
evenimentelor
petrecute
în
fiecare
restaurant,
astfel
asigurându-se
un

istoric
ș
i reclamă restaura ntului.

Figura 5.1.8
​
Personalizarea unui produs

Atât
din
pagina
meniului
cât
ș
i
din
pagina
co
ș
ului
de
produse
(pre-comandă),

produsele
se
pot
personaliza
sau
edita
în
func
ț
ie
de
dorin
ț
ele
clientului.
În
Figura
5.1.8
se

observă
că
se
pot
alege
ingrediente
în
plus
pe
fiecare
produs,
sau
se
pot
adăuga
cerin
ț
e

speciale
ș
i
observa
ț
ii,
cât
ș
i
posibilitatea
de
alege
o
cantitate
din
acel
produs.
Pagina
din

Figura
5.1.8
are
două
roluri,
una
de
a
edita
produsul,
iar
a
doua
de
a
vedea
con
ț
inutul

produsului, ingredientele din care e compus, vezi Figura 5.1.9.

5.2 Descrierea Aplica
ț
iei Web

Sistemul
de
aplica
ț
ii
oferă
pe
lângă
aplica
ț
ia
pentru
clien t,
care
este
folosită
pentru
a

comanda
produse,
o
aplica
ț
ie
pentru
comercian
ț
i,
pentru
lan
ț
urile
de
restaurante
pentru
a

administra
comenzile,
meniul
ș
i
a
lansa
oferte
sau
promo
ț
ii.
Serverul,
a
treia
aplica
ț
ie,
este

locul
unde
se
ț
in
toate
informa
ț
iile
pentru
a
putea
fi
u
ș
or
accesate
atât
de
către
aplica
ț
ia

destinată utilizatorilor cât
ș
i de către aplica
ț
ia destinată administrării comenzilor.

Aplica
ț
ia
pentru
comercian
ț
i
are
trei
mari
func
ț
ionalită
ț
i,
însă
ș
i
idei
ce
urmează
să
fie

transformate în func
ț
ionalită
ț
i.

S-a
creat
aplica
ț
ia
web
pentru
a
se
putea
rula
pe
orice
tip
de
device
ce
suportă
un

browser.
Prima
pagină
a
aplica
ț
iei
este
pagina
de
autentificare
(Figura
5.2.1)
deoarece

aplica
ț
ia
fiind
destinată
unui
lan
ț
de
restaurante,
atunci
fiecare
restaurant
sau
fiecare
angajat

ar trebui să se autentifice separat pentru a putea urmării cine a preluat comenzile.

Figura 5.2.1
​
Pagina de autentificare

După
ce
un
angajat
s-a
autentificat,
ajunge
pe
pagina
principală
(Figura
5.2.2)
de
unde

poate
începe
administrarea
comenzilor.
În
partea
de
sus
a
paginii
se
găse
ș
te
un
meniu

contextual
pentru
a
naviga
între
pagini.
În
partea
stânga
a
paginii
se
află
comenzile
în
ordine

cronologică
cu
detalii
despre
utilizator,
ora
comenzii
ș
i
loca
ț
ia
de
livrare.
Comenzile
pot
fi

filtrate
în
func
ț
ie
de
cele
care
au
fost
procesate
sau
care
urmează
să
fie
procesate.
În
partea

dreaptă
apar
detaliile
comenzii
selectate.
În
partea
dreaptă,
jos,
există
butonul
de
status
care

ajută
comerciantul
să
transmită
în
timp
real
un
status
al
comenzii.
Ini
ț
ial,
când
angajatul
preia

comanda,
apasă
butonul
“start
work
on
it”
care
este
folosit
pentru
a
transmite
aplica
ț
iei
client

un
status
în
timp
real.
Dupa
ce
a
lucrat
la
comandă,
angajatul
apasă
butonul
“Ready
for

delivery”
care
pe
lângă
faptul
ca
informează
utilizatorul
cu
privire
la
comandă,
poate
muta

comanda
într-o
pagină
a
unui
alt
angajat
care
se
ocupă
doar
de
livrări
pentru
a
administra

comenzile pregătite de livrare.

Figura 5.2.2
​
Pagina de administrare a comenzilor

Figura 5.2.3
​
Pagina de editare a unui produs

Figura 5.2.4
​
Pagina de administare a meniurilor

O
a
doua
func
ț
ionalitate
foarte
importantă
este
cea
de
administrare
a
meniului,
care

poate
fi
făcută
din
aplica
ț
ia
comerciantului,
urmând
să
se
modifice
ulterior
ș
i
în
aplica
ț
ia

clien
ț
ilor,
în
momentul
în
care
acesta
are
conexiune
la
internet.
Meniul
se
poate
modifica
în

func
ț
ie
de
categorii.
În
Figura
5.2.4
este
creat
design-ul
pentru
editarea
meniului,
loc
în
care

produsele sunt împăr
ț
ite pe categorii, permi
ț
ând astfel o administrare mai u
ș
oară a meniului.

În
pagina
meniului
se
pot
adăuga,
ș
terge
ș
i
edita
produsele
pentru
toate
restaurantele,

urmând ca în viitor să permitem personalizarea meniului pentru fiecare restaurant.

Următorul
modul
al
aplica
ț
iei
este
cel
de
rapoarte,
un
modul
orientat
spre
comerciant,

unul
de
care
s-a
observat
nevoia
în
momentul
în
care
s-a
discutat
despre
punerea
în
produc
ț
ie

a
acestei
aplica
ț
ii.
În
pagina
de
rapoarte,
dorim
să
oferim
comerciantului
posibilitatea
de
a

vedea
rapoarte
pe
fiecare
restaurant,
cât
ș
i
la
nivel
de
concern.
Rapoartele
pot
fi
în
func
ț
ie
de

cerin
ț
e,
însă
cele
mai
importante
sunt
cele
care
exprimă
cantitatea
de
produse
vândută
pe

perioade determinate, sau intervalul orar în care se primesc cele mai multe comenzi.

6. Concluzii

Proiectul Food Ordering System este dezvoltat pentru a permite comercian
ț
ilor din

domeniul restaurantelor de tip fast-food
ș
i nu numai, să gestioneze un număr mare de

comenzi utilizând două aplica
ț
ii, una mobila pentru predarea comenzilor,
ș
i una web pentru

gestionarea comenzilor, administrarea meniului
ș
i generarea de rapoarte.

Dezvoltarea acestui sistem de aplica
ț
ii a necesitat o cercetare în ceea ce prive
ș
te

abordarea actuală a comercian
ț
ilor în ceea ce prive
ș
te administrarea comenzilor, punerea în

discu
ț
ie a mai multor solu
ț
ii pentru îmbunătă
ț
irea abordării actuale, însă
ș
i ascultarea nevoilor

din partea comercian
ț
ilor pentru a crea un sistem complex, care să scutească utilizatorii de

apeluri telefonice, să le creeze un sistem de fidelizare, însă prin care sa rezolve nevoile

comercian
ț
ilor.

De asemenea, pentru dezvoltarea acestui sistem, a fost necesar să învă
ț
tehnologii noi,

pentru ca aplica
ț
iile să se poată adapta la noi dezvoltări
ș
i a avea o viteza de procesare a

informa
ț
iilor foarte rapidă . Una din noile tehnologii este Angular pentru aplica
ț
ia Web

destinată comercian
ț
ilor c are rulează în mare parte local, încât doar schimbul de informa
ț
ii

făcându-se folosind internetul. Un framework care se poate găsi atât în server cât
ș
i în

aplica
ț
ia client, este Sprin g care se folose
ș
te pentru inversarea controlului asupra obiectelor

din aplica
ț
ie, mai exact, o biectele pe care le-am creat până acum cu ajutorul operatorului

“new”, acum sunt create automat de către Spring, atunci când sunt folosite.

În
continuare,
ne-am
propus
să
dezvoltăm
acest
proiect
din
mai
multe
aspecte.
Un

aspect
necesar
ș
i
care
a
fost
cerut
de
posibili
clien
ț
i
a
fost
posibilitatea
de
a
plăti
comenzile

prin
intermediul
aplica
ț
iei,
ceea
ce
implică
un
studiu
avansat
pe
securizarea
informa
ț
ilor

sensibile.

Încă
o
dezvoltare
la
care
se
lucrează
încă
de
acum,
însă
care
este
complexă
ș
i
necesită

un
“business
logic”
complex
este
să
utilizăm
data-mining
prin
care
să
generăm
cupoane
de

reducere
pentru
clien
ț
ii
fideli.
Pentru
a
face
asta
este
nevoie
de
foarte
multe
interogări
a
bazei

de
date,
pentru
a
extrage
informa
ț
ii
despre
capacitatea
de
cumpărare
a
unui
anumit
restaurant,

încât,
pe
baza
capacită
ț
ii
de
cumpărare,
să
extragem
clien
ț
ii
fideli,
iar
dacă
se
încadrează
în

anumite
tipare,
se
pot
genera
cupoane
de
reducere,
sau
în
func
ț
ie
de
for
ț
a
de
cumpărare
de
la

un anumit restaurant, se pot oferi meniuri gratis.

Pentru
viitor,
ne-am
propus
să
creăm
un
modul
pentru
contorizarea
stocului
de

produse
al
unui
restaurant.
Acest
modul
de
viitor
ar
putea
ajuta
restaurantele
de
dimensiuni

medii
ș
i
mari
să
ț
ină
o
eviden
ț
ă
a
stocului
mai
rapidă,
portabilă
având
în
vedere
că
atunci

când merge pentru aprovizionare are aplica
ț
ia aproape și u
ș
or de utilizat.

Aplica
ț
ia
a
fost
propusă
unor
lan
ț
uri
de
restaurante,
iar
în
momentul
de
fa
ț
ă
se

negociază implementarea ei în produc
ț
ie.

7. Bibliografie

[1] Statistici privind utilizarea telefonului mobil,

https://start-up.ro/romanii-si-telefonul-mobil-cum-ne-folosim-smartphone-urile/
​
/
​
, (data

accesării: 04.02.2018).

[2] Statistici privind raportul muncă respectiv timp liber,

http://www.mediafax.ro/social/cercetare-privind-utilizarea-timpului-cat-lucreaza-si-cat-timp-l
iber-au-zilnic-angajatii-romani-11799813, (data accesării: 10.02.2018).

[3] Statistici privind utilizarea telefoanelor mobile,

https://start-up.ro/romanii-si-telefonul-mobil-cum-ne-folosim-smartphone-urile/
​
/
​
, (data

accesării: 04.05.2018).

[4] Despre Java, https://en.wikipedia.org/wiki/Java_(programming_language), (data

accesării: 02.01.2018).

[5] Despre MySQL, https://dev.mysql.com/doc/refman/5.7/en/what-is-mysql.html (data

accesării: 21.04.2018)

[6] Utilizarea sistemului de operare Android,

http://www.go4it.ro/software/platforma-android-la-inceput-de-2018-android-oreo-creste-incet
-versiunile-vechi-incep-sa-dispara-16921350/ (data accesării: 21.04.2018)

[7] Avantajele librăriei Volley, https://developer.android.com/training/volley/
​

​
(data accesării:

03 May 2018)

[8] Despre MySQL,
​
https://ro.wikipedia.org/wiki/MySQL
​
, (data accesării: 21.04.2018)

[9] Despre Maven,
​
https://en.wikipedia.org/wiki/Apache_Maven
​
(data accesării: 05.05.2018)

[10] Despre activită
ț
i,
​
https://www.tutorialspoint.com/android/android_acitivities.htm
​
(data

accesării: 03 May 2018)

[11] Despre fragmente, https://developer.android.com/guide/components/fragments. (data

accesării: 05 May 2018)

[12] Request Servicii REST,
​
https://www.slideshare.net/busaco/servicii-web-prin-rest
​
(data

accesării: 03.03.2018)

[13] Limbajul de programare Java,

https://ro.wikipedia.org/wiki/Java_(limbaj_de_programare)
​
, (data accesării: 06/14/2016)

[14] Despre limbajul de programare Java, https://java.com/en/download/faq/whatis_java.xml,

(data accesării: 21.02.2018).

[15] Despre Hibernate, https://www.tutorialspoint.com/hibernate/hibernate_overview.htm,

(data accesării: 23.02.2018).

[16] Servicii REST, https://www.tutorialspoint.com/restful/index.html, (data accesării:

21.02.2018)

[17] Arhitectura MVC,

https://inkoniq.com/blog/googles-baby-angularjs-is-now-the-big-daddy-of-javascript-framew
orks/, (data accesării: 19.02.2018)

[18] Despre Android,
​
https://en.wikipedia.org/wiki/Android_(operating_system)
​
, (data

accesării: 18.02.2018)