Universitatea POLITEHNICA București

Facultatea Automatică și Calculatoare

Departamentul Automatică și Informatică Industrială

LUCRARE DE LICENŢĂ

Aplicație mobile pentru rezervări

Coordonator: Absolvent:
Ș.l. Dr. Ing. Călin Munteanu Drăghici Andrei-Cristian

2016
Cuprins
1. Introducere ........................................................................................................................ 6
1.1 Contextul proiectului ................................................................................................... 6
1.2 Descrierea domeniului din care face parte tema de licența ......................................... 6
2. Descrierea problemei abordate .......................................................................................... 7
2.1 Descrierea problemei abordate .................................................................................... 7
2.2 Studiu asupra realizărilor similare din domeniu .......................................................... 7
2.3 Stabilirea funcționalităților aplicației raportat la aplicațiile similare .......................... 8
3. Tehnologii utilizate ............................................................................................................ 9
3.1 Sistemul de operare Android ....................................................................................... 9
3.2 Tehnologii de comunicare client-server .................................................................... 12
3.2.1 Standardul TCP/IP .............................................................................................. 12
3.2.2 Network socketing .............................................................................................. 13
3.3 .NET Windows Forms ............................................................................................... 15
3.4 Microsoft SQL Server................................................................................................ 15
3.5 [Link] .................................................................................................................. 15
3.5 Limbajul de programare C# ....................................................................................... 16
3.6 Limbajul de programare Java .................................................................................... 16
4. Arhitectura sistemului ...................................................................................................... 17
4.1 Structura bazei de date ............................................................................................... 17
4.2 Aplicația de tip server ................................................................................................ 19
4.3 Aplicația Windows de tip client din incinta localului ............................................... 23
4.4 Aplicația Android pentru tabletă ............................................................................... 26
4.5 Aplicația Android pentru smartphone ....................................................................... 31
5. Utilizarea aplicațiilor ....................................................................................................... 34
5.1 Utilizarea aplicației Windows ................................................................................... 35
5.2 Utilizarea aplicației Android pentru tabletă............................................................... 37
5.3 Utilizarea aplicației Android pentru smartphone....................................................... 39
5.4 Scenariu de utilizare .................................................................................................. 44
6. Concluzii.......................................................................................................................... 45
7. Bibliografie ...................................................................................................................... 46
Listă de figuri
Fig. 2.1 Arhitectura Android .............................................................................................. 10
Fig. 2.2 Distribuție versiuni Android ................................................................................. 11
Fig. 2.3 Fluxul traficului utilizând standardul TCP/IP ....................................................... 12
Fig. 2.4 Conexiune client-server......................................................................................... 15
Fig. 4.1 Arhitectura sistemului ........................................................................................... 17
Fig. 4.2 Structura bazei de date .......................................................................................... 19
Fig. 4.3 Diagramă de clase aplicație server ........................................................................ 20
Fig. 4.4 Diagramă de clase aplicație Windows de tip client .............................................. 23
Fig. 4.5 Diagramă de clase aplicație Android pentru tabletă ............................................. 27
Fig. 4.6 Diagramă de clase aplicație Android pentru smartphone ..................................... 31
Fig. 5.1 Diagrama cazurilor de utilizare ............................................................................. 35
Fig. 5.2 Fereastra principală a aplicației Windows ............................................................ 36
Fig. 5.3 Fereastră pentru vizualizarea comenzii făcute la o masă ...................................... 36
Fig. 5.4 Fereastră pentru masă rezervată ............................................................................ 37
Fig. 5.5 Meniu principal aplicație Android pentru tabletă ................................................. 37
Fig. 5.6 Meniu mâncare aplicație Android pentru tabletă .................................................. 38
Fig. 5.7 Meniu băutură aplicație Android pentru tabletă .................................................... 38
Fig. 5.8 Meniu vizualizare notă de plată ............................................................................ 39
Fig. 5.9 Confirmarea cererii notei de plată ......................................................................... 39
Fig. 5.10 Meniu principal aplicație Android pentru telefon ............................................... 40
Fig. 5.11 Meniu mâncare aplicație Android pentru telefon ................................................ 40
Fig. 5.12 Meniu băutură aplicație Android pentru telefon ................................................. 41
Fig. 5.13 Vizualizare disponibilități mese .......................................................................... 41
Fig. 5.14 Confirmare rezervare masă ................................................................................. 42
Fig. 5.15 Eroare rezervare masă ce a fost ocupată între timp ............................................. 42
Fig. 5.16 Eroare rezervare masă deja ocupată .................................................................... 43
Fig. 5.17 Notificare cu codul rezervării .............................................................................. 43
Listă de secvențe de cod

Secvență de cod 4.1 Inițializare server ................................................................................ 21

Secvență de cod 4.2 Metoda AcceptCallback ..................................................................... 21
Secvență de cod 4.3 Recepționare query de la client .......................................................... 21
Secvență de cod 4.4 Trimitere răspuns querry de tip Select ................................................ 22
Secvență de cod 4.5 Exemplu cerere și răspuns de la server în C# ..................................... 24
Secvență de cod 4.6 Exemplu conectare la server și creare Intent ...................................... 28
Secvență de cod 4.7 Exemplu creare Toast ......................................................................... 29
Secvență de cod 4.8 Exemplu creare AlertDialog ............................................................... 30
Secvență de cod 4.9 Exemplu creare notificare ................................................................... 33
Notații și abrevieri

API – Application Programming Interface

IDE – Integrated Development Enviroment
XML– Extensible Markup Language
TCP – Transmission Control Protocol
IP – Internet Protocol
DNS – Domanin Name System
HTTP – Hypertext Transfer Protocol
CLI – Common Language Infrastructure
SMC – Simple Managed Code
CLR – Common Language Runtime
ASP – Active Server Pages
1. Introducere
1.1 Contextul proiectului

Socializarea este una dintre nevoile principale ale omului alături de realizarea
personală, stima de sine, siguranță și nevoile fiziologice. Maslow a ordonat în anul 1954
aceste nevoi și le-a structurat sub forma unei piramide cu cinci niveluri, socializarea
situându-se pe cea de-a treia treapta. Acesta considera că nevoile situate pe nivelurile
superioare pot fi satisfăcute doar dacă cele aflate la baza piramidei sunt deja satisfăcute.
Zilnic, omul simte nevoia de a interacționa cu alte persoane, fie că sunt cunoscute sau nu.

În ziua de azi, oamenii preferă sa interacționeze într-un mediu plăcut, dar care să-i
ofere si senzația de securitate. Restaurantele și pub-urile sunt locațiile în care milioane de
oameni din toată lumea se întâlnesc zilnic pentru a socializa.

1.2 Descrierea domeniului din care face parte tema de licența

Piața aplicațiilor mobile a devenit din ce în ce mai puternica începând cu anul 2007
când compania Apple Inc. a lansat pe piață primul telefon iPhone ce rula pe sistemul de
operare iPhone OS1. In ultimii trei ani au fost vândute, anual, peste un miliard de telefoane
smartphone. Fără să-și dea seama, oamenii au devenit în ziua de astăzi dependenți de
smartphone-uri și de aplicațiile mobile. Statistic, o persoană îți petrece aproximativ 23 de
zile dintr-un an folosind aplicațiile de pe telefonul mobil, iar dezvoltatorii profită din plin
de acest lucru. In momentul de față, există în total aproximativ 4 milioane de aplicații
mobile disponibile pe cele patru sisteme de operare ce domină piața: Android, Apple,
Blackberry si Windows. Din totalul de aplicații disponibile, 1.6 milioane sunt destinate
sistemului de operare Android, deținut în prezent de către gigantul Google Inc., generând
in anul 2015 nu mai puțin de 6 miliarde de dolari. De asemenea, platforma Android
domină piața și punctul de vedere al numărului de telefoane vândute anual.

6
2. Descrierea problemei abordate
2.1 Descrierea problemei abordate

Fiecare persoană are cu certitudine restaurante sau pub-uri pe care preferă să le

frecventeze. Motivele pentru care oamenii au localuri preferate sunt diverse: le poate
plăcea modul în care sunt serviți la masă, design-ul localului, muzica ce cânta in interior,
locația sau orice alt motiv. Cu siguranță, a existat cel puțin un moment în care un grup de
persoane a dorit sa meargă într-un astfel de local, dar odată ajunși acolo membrii grupului
au observat că nu există nicio masă liberă la care să se poată așeza și au fost nevoiți să
plece către un alt local sau să aștepte eliberarea unei mese. Acest lucru poate deveni ușor
deranjant după câteva încercări nereușite consecutive, mai ales în zilele de weekend când
majoritatea oamenilor nu merg la serviciu si preferă să se întâlnească cu prietenii pentru a
socializa.

Scopul proiectului este de a realiza o aplicație mobile ce permite vizualizarea în

timp real a disponibilităților meselor din diferite localuri si eventuala rezervare a unei
mese. Acesta este destinată celor ce dețin telefoane mobile de tip smartphone ce rulează pe
sistemul de operare Android.

2.2 Studiu asupra realizărilor similare din domeniu

Încă de la apariția telefoanelor inteligente dezvoltatorii de aplicații mobile realizat

diferite aplicații menite să-i ajute pe oameni cu alegerea unui local în care să-și petreacă
timpul liber. Astfel au apărut primele aplicații ce permiteau utilizatorilor să vadă o listă de
restaurante din apropierea lor și în care puteau opta să meargă. O astfel de aplicație este
“Foursquare” lansată în anul 2007. Cu timpul, aplicațiile au evoluat permițând utilizatorilor
să vadă meniul din diferite restaurante, dar și să caute restaurante in funcție de ceea ce
doreau să mănânce sau să bea. Astăzi există aplicații cu baze de date de dimensiuni
impresionante, având peste 30.000 de restaurante însoțite de meniurile lor si recenzii
realizate de persoane ce au fost deja în acele localuri – aplicații precum: “Yelp”, “Eat24”,
“LocalEats”, “Restaurant Finder”.

O altă categorie de aplicații este reprezentată cele ce le permit utilizatorilor să

rezerve din timp o masă dintr-un restaurant pentru o anumită dată și oră, economisind
timpul pierdut pentru a merge personal la restaurant si a rezerva masa. De aici putem
considera că a apărut ideea de a realiza aplicații ce permit utilizatorilor să efectueze o
comandă “la pachet”. Principiul este invers față de cel al aplicațiilor prezentate anterior, în
sensul că utilizatorul anunță că vrea să vină să cumpere anumite produse dintr-un

7
restaurant la o anumită dată și oră, dar fără a ocupa masa. În această categorie sunt incluse
aplicații precum: “OpenTable”, “Zagat”, “Urbanspoon”.1

2.3 Stabilirea funcționalităților aplicației raportat la aplicațiile similare

Asemenea aplicațiilor descrise anterior, doresc să ofer utilizatorilor posibilitatea de

a vizualiza lista de produse si prețuri din diferite localuri. Aplicația se va adresa inițial
celor ce cunosc localurile din orașul București și au o așa zisă listă de restaurante preferate
pe care le place să le frecventeze. Spre deosebire de aplicațiile prezentate anterior,
utilizatorii nu vor putea face o rezervare pentru o anumită dată și oră. Aplicația va permite
utilizatorilor să vadă în timp real disponibilitatea meselor în localurile “partenere” și pot
opta să rezerve o masă pentru 15 minute, iar aceștia vor primi un cod generat automat.
Masa va fi păstrată pentru aceștia, timp în care tableta aflată pe masa ce corespunde
rezervării nu va putea fi folosită de alți clienți. Odată ajunși în local, cei ce au rezervat
masa vor introduce în tabletă codul primit în momentul în care au efectuat rezervarea și o
vor putea folosi pentru a comanda. În cazul în care utilizatorul nu ajunge la timp în localul
respectiv, rezervarea se va anula permițând altor potențiali clienți să ocupe masa respectivă
și să plaseze o comandă.

Cu ajutorul tabletei de la masă clienții vor putea comanda, consulta nota de plată și
înștiința ospătarul de intenția de a pleca. Astfel, se va reduce timpul de așteptare necesar
pentru a putea comanda și pentru a cere nota de plată. De asemenea, clienții vor
interacționa cu ospătarul doar prin intermediul tabletei, exceptând momentul plecării când
vor trebui să-i dea personal banii.

1
Paste Magazine, 09.06.2016,
<[Link]

8
3. Tehnologii utilizate
3.1 Sistemul de operare Android

Android este un sistem de operare destinat în principal telefoanelor mobile de tip

smartphone, tabletelor și mai nou televizoarelor de tip smart TV, dar și ceasurilor
inteligente. Interfața cu utilizatorul este bazată în principal pe manipularea directă folosind
gesturi tactile precum apăsarea ecranului sau glisarea degetelor pe acesta. Simplitatea cu
care se utilizează telefoanele ce folosesc Android a făcut ca începând cu anul 2013 acesta
să devină cel mai popular sistem de operare destinat gadget-urilor inteligente. În anul 2015
au fost vândute 271 de milioane de smartphone-uri sau tablete ce au instalat sistemul de
operare Android.

Android fost dezvoltat inițial de către o companie mică de tip startup, Android Inc.,
ce a fost cumpărată în anul 2005 de Google. În prezent, dezvoltarea sistemului de operare
este supervizată de Open Hanset Alliance, un consorțiu alcătuit din companii hardware,
software și de telecomunicații condus de către Google și din care fac parte: Samsung, LG,
Sony, HTC, T-Mobile, Intel si Nvidia.

Primul kernel Android a avut la bază versiunea 2.6.25 a kernelului Linux, iar în
prezent majoritatea dispozitivelor Android folosesc versiunea 3.4 sau 3.10 a kernelului
Linux. Toate versiunile de kernel Linux au suferit modificări de arhitectură pentru a putea
include componente precum: Binder (responsabil de comunicarea între procesele active),
ashmem (subsistem responsabil de alocarea memoriei virtuale), pmem (subsistem
responsabil de alocarea memoriei fizice), logger (subsistem folosit pentru afișarea erorilor
și avertismentelor), wakelock (subsistem responsabil de gestionarea consumului de
energie) si diferite soluții de tratare a situațiilor în care sistemul de operare rămâne fără
memorie disponibilă.

Arhitectura sistemului de operare Android pe se bazează pe existența unei stive cu

patru niveluri ce conțin cinci layere:

 Primul nivel este reprezentat de kernelul Linux și conține drivere pentru afișare pe
display, cameră foto, Bluetooth, memorie flash, USB, tastatură, Wi-Fi, dar și
componentele adăugate ulterior de către inginerii Google enumerate anterior.
Dezvoltatorii de aplicații Android nu vor programa în mod direct la acest nivel;

 Al doilea nivel conține bibliotecile native Android, toate fiind scrise intern în limbajul
C/C++. Aceste biblioteci conțin seturi instrucțiuni folosite de sistemul de operare

9
 pentru tratarea diferitor tipuri de date. Bibliotecile se mai numesc și interfețe Java. Pe
același nivel se află și layerul Android Runtime ce este alcătuit din Dalvik Virtual
Machine și bibliotecile Android de bază. Aplicațiile Android sunt scrise în limbajul de
programare Java. Mașina virtuală are rolul de a face translația din codul Java in byte-
code cu ajutorul lui tool numit “dx”. Tool-ul convertește în momentul compilării
fișierele .class din Java în fișiere .dex deoarece acestea sunt mai compacte decât
fișierele Java pentru clase, factor important atunci când există limitări de memorie și
baterie așa cum se întâlnește la dispozitivele mobile ce utilizează Android.

 Pe cel de-al treilea nivel se află Application Framework Layer. Majoritatea tool-urilor
sunt oferite de către Google și restul sunt extensii sau servicii pe care dezvoltatorii de
aplicații Android le scriu pentru programele lor. Cele mai importante tool-uri sunt:
Activity Manager (administrează ciclul de viață al aplicațiilor), Content Providers
(administrează datele de sunt transmise de la o aplicație la alta), Telephony Mnager
(administează toate apelurile vocale, inclusiv căsuța poștală), Location Manager
(responsabil de localizarea dispozitivului folosind GPS-ul sau stațiile de bază emisie
recepție) și Resource Manager (responsabil de administrarea resurselor folosite de
aplicații).

 Ultimul nivel conține Application Layer și este cel cu care majoritatea utilizatorilor de
dispozitive Android interacționează. Acesta conține aplicațiile standard pentru apeluri,
mesagerie, navigare internet, administrare contacte, dar și cele pe care utilizatorii le vor
instala ulterior pe dispozitivul lor.

Fig. 2.1 Arhitectura Android2

2
edureka! Education Solutions, 08.06.2016,
<[Link]

10
 Fig. 2.1

Una dintre calitățile unice și puternice pe care Android le are este faptul că orice
aplicație standard a unui telefon poate fi înlocuită cu ușurință. Aplicațiile scrise de
producătorii de telefoane trec prin același API public la care are acces orice dezvoltator sau
utilizator Android. Această calitate a dus la diversitatea de aplicații și un număr
impresionant de 1.6 milioane de aplicații ce pot fi descărcate de pe magazinul online
Google Play condus în prezent de Google.

Pentru dezvoltarea celor două aplicații Android din cadrul proiectului a fost folosită
versiunea 4.4.2 (KitKat) a sdk-ului Android corespunzătoare nivelului API 19 aceasta fiind
cea mai răspândită versiune Android, aproximativ 31.6% din dispozitivele produse până în
prezent. IDE-ul utilizat pentru dezvoltarea aplicațiilor este Android Studio 2.0, fiind
mediul de dezvoltare oficial folosit pentru realizarea de aplicații Android începând din
decembrie 2014. Android Studio permite testarea aplicațiilor in timpul dezvoltării lor atât
pe emulatorul integrat în interfața IDE-ului, cât și pe un telefon conectat la calculator
printr-un cablu USB.

Fig. 2.2 Distribuție versiuni Android3

Codul folosit pentru dezvoltarea celor două aplicații Android este cod standard Java
ce folosește pachete și clase standard Java împreună cu pachete și clase dezvoltate special

3
Android Developer, 08.06.2016, < [Link]

11
pentru sistemul de operare Android. Interfața grafică cu utilizatorul este realizată folosind
fișiere XML specifice dezvoltării aplicațiilor Android.

3.2 Tehnologii de comunicare client-server

Pentru a putea îndeplini obiectivul propus, afișarea în timp real a disponibilităților

meselor în restaurante și pub-uri, au fost dezvoltate patru aplicații: o aplicație server și trei
aplicații client. Cele trei aplicații client comunică asincron cu serverul central prin sockete
a căror funcționalitate se bazează pe standardul TCP/IP.

3.2.1 Standardul TCP/IP

Standardul TCP/IP, format din protocoalele TCP și IP, primele protocoale de rețea
dezvoltate, este un model de conectare în rețea al calculatoarelor și conține un set de
protocoale de comunicație între calculatoare conectate la Internet. TCP/IP a fost creat de
Ministerul Apărării Naționale al Statelor Unite din necesitatea realizării unei rețele de
comunicații ce ar putea rezista în orice condiții și să permită transmiterea vorbirii în timp
real. Acest standard asigura comunicații de date capăt la capăt specificând felul în care
datele trebuie împachetate, adresate, transmise, dirijate și recepționate. Funcționalitatea
este organizată în patru niveluri de abstractizare cu funcționalități diferite și bine definite:
Network Acces, Internet, Transport, Application.

Fig. 2.3 Fluxul traficului utilizând standardul TCP/IP4

4
Oracle, System Administration, 08.06.2016,
< [Link]

12
 Nivelul Network Acces este cea mai de jos componentă a standardului și este
folosit pentru a realiza comunicația dintre doi clienți conectați în rețea. Aici, pachetelor de
date li se asignează câte un header înainte de a fi transmise mai departe pe calea fizică
către un alt echipament conectat la rețea. Printre funcțiile nivelului Network Acees se află:
adresarea fizică a fiecărui echipament prin adresele MAC, identificarea erorilor apărute
(fără a le corecta) și controlarea accesului la mediul de transmisie.

Al doilea nivel, Internet, are responsabilitatea de a trimite pachete de date către

multiple alte rețele. Aici se găsește si protocolul IP ce are două funcționalități de bază:
identificarea și adresarea gazdei, folosind un sistem ierarhic de adresare IP, și dirijarea
pachetelor de date, adică dirijarea lor către cel mai apropiat router de destinația finală.
Protocolul IP este cel ce face posibilă interconectarea mai multor rețele, realizând astfel
Internetul.

Cel de-al treilea nivel, Transport, conține protocolul TCP. TCP este un protocol
complex ce garantează ajungerea datelor la destinație. Înainte de a începe transferul datelor
are loc un schimb de mesaje între sursă și destinație cu scopul de verificare a
disponibilității și pentru a sincroniza numerele de secvență în baza cărora se va confirma
primirea datelor. Aici se creează canale de comunicație ce permit aplicațiilor din nivelul
superior să comunice, iar fiecare canal are asignat un număr către care se face referirea în
timpul comunicației. Acest lucru îl face să fie considerat un protocol orientat pe conectare.
Acest nivel al standardului TCP/IP asigură și faptul că: datele ajung de la sursă la
destinație în ordinea dorită, datele transmise au erori minimale la primire, duplicatele
primite sunt eliminate, pachetele pierdute pe traseu sunt retransmise și includ metode de
decongestionare a traficului în rețea.

Ultimul nivel, Application, conține protocoalele folosite de majoritatea aplicațiilor

ce oferă diferite servicii clienților sau fac schimb de date cu alte echipamente conectate la
rețea. Printre protocoalele ce se găsesc la acest nivel se află: HTTP, FTP, SMTP, DHCP.
Nivelul Application este de asemenea asociat cu aplicațiile client-server, așa cum sunt și
cele ce sunt realizate în cadrul acestui proiect.

3.2.2 Network socketing

Un socket de rețea este un punct de conectare în cadrul unei rețele de calculatoare.

Astăzi, majoritatea comunicațiilor dintre calculatoare se bazează pe Internet Protocol,
astfel majoritatea socketelor de rețea sunt sockete de Internet. Mai exact, un socket este un
handler pe care un program îl poate transmite API-ului de rețea pentru a putea realiza o
conexiune cu un alt socket.

Un socket API este o interfață de programare a aplicațiilor oferit, de obicei, de către

sistemele de operare ce permit aplicațiilor să controleze și să folosească socketele de rețea.
Socketele sunt bazate pe standardul Berkeley conform căruia socketele sunt o formă de
handlere de fișiere (teoria UNIX, sistem pentru care a fost creat inițial acest standard,

13
considera că orice este un fișier în cadrul unui sistem de operare). De aici și analogia dintre
fișiere și sockete: acestea permit citirea, scrierea, deschiderea si închiderea amândurora. În
mod normal, fiecare punct de conectare are propriul socket, dar acestea diferă în funcție de
API-ul utilizat fiind abstractizate de protocolul de rețea pe care îl utilizează.

Un socket de adresă reprezintă o combinație dintre o adresă IP și un port. Fiecare

astfel de socket este caracterizat și de un protocol de transport. Socketele sunt în general un
concept utilizat în nivelul Transport și nivelul Internet al protocoalelor de transport
permițând atât recepționarea datelor, cât si transmiterea lor.

În cadrul acestui proiect, clienții comunică cu serverul prin intermediul unor

sockete caracterizate de standardul TCP/IP. Am ales această modalitate de comunicație
deoarece este sigură și permite serverului tratarea mai multor clienți în același timp. Acest
lucru asigură faptul că dacă serverul primește cereri simultan de la mai mulți clienți, iar
acestea vor putea fi tratate simultan evitând astfel apariția unor eventuale erori atunci când
se va transmite un răspuns către clienți.

O altă caracteristică importantă a socketelor o reprezintă comunicarea asincronă.

Aceasta este critică pentru funcționarea corespunzătoare a aplicațiilor de tip client. În cazul
în care s-ar fi comunicat sincron, în momentul în care un client face o cererea către server,
acesta s-ar bloca până în momentul în care se va primi un răspuns de la server. Folosind o
comunicare asincronă se asigură o funcționare fluentă a aplicațiilor, aceasta făcându-se fără
întreruperi.

Principiul de funcționare al aplicațiilor client-server ce folosesc sockete este relativ

simplu. În mod normal, o aplicație server rulează pe un calculator și are asignat un socket
căruia îi corespunde un port. Serverul așteaptă să fie înștiințat de faptul că un client
încearcă să se conecteze. Din punctul de vedere al clientului, IP-ul pe care rulează serverul
si portul către care trebuie să se conecteze sunt cunoscute. Pentru a face o cerere de
conexiune, clientul trebuie să se identifice serverului pentru a-i fi asignat un port local pe
care îl va utiliza în timpul conexiunii (acesta este asignat în mod uzual de către sistemul de
operare). Dacă identificarea este reușită, serverul acceptă conexiunea și primește un nou
socket căruia îi este asignat portul la care este conectat clientul. Noul socket este creat
pentru a-i permite serverului să urmărească socketul folosit inițial si pentru a trata cererea
primită de la clientul ce s-a conectat. În acest moment, serverul și clientul sunt conectați si
comunica între ei. Conexiunea se va închide odată cu socketele.

14
 Fig. 2.4 Conexiune client-server5

3.3 .NET Windows Forms

.NET Windows Forms este una dintre tehnologiile majore ale platformei .NET.
Acesta este un API ce oferă dezvoltatorilor posibilitatea să creeze interfețe grafice cu
utilizatorii. Limbajul de programare folosit pentru dezvoltarea programelor ce folosesc
această tehnologie este C#. Am ales să folosesc această tehnologie datorită avantajelor pe
care le oferă față de alte tehnologii folosite cu același scop: simplitate (facilitează accesul
la resursele sistemului de operare și reduce numărul de erori din cod), portabilitate (același
program poate fi rulat pe mai multe calculatoare ce pot avea la rândul lor diferite versiuni
ale sistemului de operare Windows), eficiență (este scris mai puțin cod pentru a facilita
aceleași funcționalități ce se pot obține și cu alte tehnologii folosite pentru realizarea
interfețelor grafice cu utilizatorul), management (permite organizarea și depanarea mult
mai ușoară a programelor).

3.4 Microsoft SQL Server

Microsoft SQL Server este un sistem ce permite manipularea bazelor de date

relaționale și este dezvoltat de Microsoft începând din anul 1988. Acesta folosește o
variantă a SQL numită T-SQL. Stocarea datelor se face pe modelul relațional sub forma
unor colecții de tabele cu rânduri și coloane. SQL server suportă tipurile primare de date
(integer, decimal, char, date), dar și tipuri complexe precum: texte, date binare, date
geometrice, XML etc. Am ales să folosesc acest sistem datorită interfeței grafice cu
utilizatorul pe care o oferă si simplității cu care bazele de date create de acesta pot fi
accesate utilizând [Link].

3.5 [Link]

[Link] este un set de clase ce oferă diferite servicii de acces la date

programatorilor ce folosesc framework-ul .NET. [Link] oferă o gamă variată de

5
Oracle – The Java Tutorials, 09.06.2016,
<[Link]

15
componente utilizate de către dezvoltatorii ce realizează proiecte alcătuite din mai multe
aplicații ce necesita intercomunicații. Acesta poate fi folosit pentru aplicații ce utilizează
baze de date sau fișiere XML. Am ales să utilizez această tehnologie datorită simplității cu
care un program poate comunica cu o bază de date.

3.5 Limbajul de programare C#

C# este un limbaj de programare bazat pe multiple paradigme incluzând:

programarea imperativă, funcțională, generică, orientată pe obiecte și orientată pe
componente. A fost dezvoltat de Microsoft odată cu inițiativa .NET și mai târziu aprobat
drept standard de ISO și Ecma. Este unul dintre limbajele de programare creat pentru CLI.

De-a lungul dezvoltării .NET Framework, librăriile de clase au fost scrise inițial
într-un compilator numit SMC. În 1999, Anders Hejlsberg a format o echipă pentru a crea
un nou limbaj numit ”Cool”. Deși a fost considerată această denumire finală, nu a fost
folosită din motive ce au ținut de marcă înregistrată. Între timp, proiectul .NET a fost făcut
public în iulie 2000 la Professional Developers Conference, limbajul a fost redenumit C# și
toate bibliotecile de clase și ASP .NET au fost portate în C#.

Principalul designer și arhitect al limbajului este Anders Hejlsberg, care fusese

implicat anterior în dezvoltarea Turbo Pascal, CodeGear Delphi (formal denumit Borland
Delphi) și Visual J++. În interviuri și lucrări tehnice, el a afirmat că toate deficiențele din
majoritatea limbajelor de programare au condus la fundamentele CLR, implicit la designul
limbajului C# însuși.

3.6 Limbajul de programare Java

Java este un limbaj de programare orientat pe obiecte și puternic tipizat, dezvoltat

pentru a avea cât mai puține dependențe de implementare. A fost conceput de către James
Gosling la Sun Microsystems (filială a Oracle) la începutul anilor ’90 și lansat în 1995.
Sintaxa limbajului derivă mult din cea a limbajelor C și C++, dar nu are facilitățile de nivel
jos a niciunuia. A fost conceput pentru a le permite dezvoltatorilor de aplicații să scrie
codul o singură dată și să-l ruleze pe orice dispozitiv, adică codul compilat Java poate să
ruleze pe orice platformă ce suporta Java fără a fi nevoie de o recompilare. Majoritatea
aplicațiilor distribuite sunt scrise în Java deoarece noile tehnologii permit utilizarea
acestora și pe dispozitive mobile. Începând cu anul 2016, Java este unul dintre cele mai
populare limbaje de programare mai ales pentru aplicațiile web de tip client-server.

16
4. Arhitectura sistemului

Pentru a îndeplini obiectivul propus a fost necesară crearea unei baze de date
centrală și a 4 aplicații ce comunică între ele: un server, o aplicație Windows și două
aplicații Android.

Fig. 4.1 Arhitectura sistemului

4.1 Structura bazei de date

Baza de date conține următoarele cinci tabele (Fig. 4.2):

 Pubs este tabela în care se rețin informații referitoare la localurile ce se vor regăsi
în lista cu localuri din aplicația pentru Android. Informațiile reținute aici sunt:

 ID_pub – integer PK
 Nume – nvarchar(40)
 Oras – nvarchar(40)

17
 Bonuri este tabela în care se rețin informații despre bonurile deschise în localuri.
Informațiile reținute aici sunt:

 ID_bon – integer PK
 ID_pub – integer FK
 total – integer
 status – integer

 Meniu este tabela în care se rețin informații despre produse ce se pot cumpăra în
fiecare local. Informațiile reținute aici sunt:

 ID_produs – integer PK
 ID_pub – integer FK
 uume – nvarchar(70)
 uret – integer
 unitate_masura – nvarchar(30)

 Mese este tabela în care se rețin informații despre mesele din localuri. Informațiile
reținute aici sunt:

 ID_masa – integer PK
 ID_pub – integer FK
 status – nvarchar(30)
 bon_curent – integer
 cod_rezervare – nvarchar(7)

 Comenzi este o tabelă de legătură în care se rețin informații despre comenzile

efectuate în localuri. Informațiile reținute aici sunt:

 ID_bon – integer
 ID_produs – integer
 nr_bucati – integer
 ID_masa -integer

18
 Fig. 4.2 Structura bazei de date

4.2 Aplicația de tip server

Pentru a permite celorlalte trei aplicații, la care mă voi referi ulterior cu termenul de
“client”, să acceseze baza de date și să preia informațiile de care au nevoie, a fost necesară
dezvoltarea unei aplicații de tip server. Această aplicație are rolul de a prelua cererile
clienților și să se returneze răspunsurile adecvate. Ea va face legătura dintre clienți și baza
de date centrală, în care se afla toate informațiile enumerate mai sus, stocată pe același
calculator pe care se află și serverul.

Serverul va comunica cu clienții prin intermediul socketelor. În momentul în care

aplicația este lansată în execuție, serverul se va conecta la baza de date si va menține
conexiunea deschisă pe toată durata de rulare a acestuia. În același timp, serverului i se va
aloca un socket principal și va fi creată o listă de sockete a cărei scop va fi descris mai jos.

În limbajul de programare C#, utilizarea socketelor este mult mai ușoară decât în
cazul limbajelor precum C sau C++. În cadrul C# există o clasă predefinită numită
“Socket” inclusă în namespace-ul “[Link]”. Această clasă are rolul de a ajuta
programatorii în dezvoltarea aplicațiilor oferindu-le un set de metode deja definite ce
acoperă toate funcționalitățile pe care trebuie să le aibă un socket.

19
 Odată creat socketul principal, acestuia i se atribuie tipul de adresă IP folosită (se
va folosi un IPv4), tipul de socket și protocolul Internet utilizat de către acesta. Serverul
dezvoltat de mine folosește un socket de tipul “Stream” ce permite o comunicare în două
sensuri, adică serverul va primi și va trimite informații către clienți. Protocolul de
comunicare folosit este TCP deoarece permite conectarea mai multor clienți simultan,
micșorând timpul necesar pentru a-i răspunde clientului, și permite o comunicare asincronă
cu clienții. Avantajul oferit de acest tip de comunicare va fi explicat când vor fi prezentate
aplicațiile de tip client.

Structura aplicației server:

Fig. 4.3 Diagramă de clase aplicație server

Odată ce socketul principal a fost creat și ales tipul și protocolul Internet folosit,
acestuia i se va asigna o adresă IP, adresa IP este de obicei cea a calculatorului pe care
rulează serverul, și un port după care socketul va fi pus în starea de ascultare în care
așteaptă ca un client să trimită o cerere de conectare și se va preciza numărul maxim de
cereri de conexiune ce se pot afla la coadă. În acest moment socketul pornește o operație
asincronă de acceptare a cererilor de conectare ce vor fi redirecționate către metoda
“AcceptCallback”.

20
 Secvență de cod 4.1 Inițializare server

În momentul în care o cerere a fost primită, se va lansa în execuție metoda

“AcceptCallback”. Aici se va crea un nou obiect de tip Socket care va primi datele
clientului ce încearcă să se conecteze la server. În cadrul acestei metode este necesară
crearea unui nou socket pentru a elibera socketul principal și a-i permite să reînceapă
operația asincronă de acceptare a cererilor de conectare. Socketul nou creat va fi adăugat în
lista de clienți. În această listă vor fi păstrate informațiile despre clienții ce au deschisă o
conexiune cu serverul și pentru a ști cărui client ce cerere îi corespunde. Socketul nou creat
va realiza o conexiune cu clientul si va începe un proces asincron de primire a informațiilor
venite de la client folosind metoda “BeginReceive”. Parametrii folosiți în cadrul acestei
metode predefinite specifică vectorul de tip byte în care se vor stoca informațiile primite, la
care mă voi referi în continuare cu termenul de “buffer”, împreună cu poziția de start și
lungimea, în byte, a informației primite, flag-urile specifice soketelor folosite, metoda ce
urmează să se apeleze asincron pentru a trata cererea clientului și soketul ce conține
informațiile venite de la client.

Secvență de cod 4.2 Metoda AcceptCallback

Metoda ReceiveCallback este metoda care tratează cererile clienților. Datele

primite de la metoda descrisă anterior sunt copiate într-un nou obiect de tip socket, iar în
momentul în care toate datele transmise de către client sunt recepționate se calculează
lungimea acestora în bytes. Astfel, se va crea un nou vector de tip byte, cu lungimea
calculată anterior, în care se vor copia informațiile din buffer. Conținutul noului vector se
va copia într-un obiect de tip string după ce conținutul vectorului va fi codificat și apoi
recodificat folosind codul ASCII.

Secvență de cod 4.3 Recepționare query de la client

21
 În acest moment se poate considera că serverul cunoaște intențiile clientului.
Singurele nevoi pe care le pot avea clienții sunt de a utiliza baza de date centrală și pot fi
cereri de interogare, modificare sau adăugare de conținut. Cererile clienților li se va
răspunde folosind [Link] pentru a accesa și manipula baza de date. Namespace-ul
inclus în proiect pentru a utiliza această tehnologie este “[Link]” și includ
o serie de clase și metode predefinite ce ajută la manipularea bazei de date. Query-urile de
tipul insert sau update se vor trata rapid: se creează o nouă comandă utilizând clasa
“SqlCommand” specificând asupra cărei conexiuni cu o bază de date se aplică si query-ul
dorit. Deoarece modificările au loc direct asupra bazei de date, serverul nu va primi înapoi
un răspuns de la aceasta.

Query-urile de tipul Select se vor executa relativ similar. Comanda ce se dorește a

fi executată asupra bazei de date se va crea identic ca și în cazul celorlalte două tipuri de
query. Deoarece în urma interogărilor de tip Select se primește și un răspuns de la baza de
date, va fi necesară folosirea unui obiect de tip “SqlDataReader”. Răspunsurile la astfel de
interogări se vor primi tabelat ca și cum ar fi efectuate utilizând programul SQL Server.
Obiectul de SqlDataReader este un vector de obiecte, fiecare obiect fiind o înregistrare
găsită în baza de date ce corespunde condițiilor impuse în interogare. Odată primit
răspunsul, se va calcula lungimea obiectului SqlDataReader pentru a ști câte înregistrări au
fost primite și fiecare înregistrare găsită va fi copiată într-un obiect de tip string. Finalul
unei înregistrări va fi marcat, manual, de către caracterul special “\n”. Răspunsul primit de
la baza de date va fi codificat în bytes și copiat într-un vector de tip byte. Socketul creat la
intrarea în metoda ReceiveCallback va utiliza metoda predefinită “BeginSend” pentru a
transmite răspunsul către client. În interiorul acestei metode se va specifica vectorul de tip
byte ce conține răspunsul, poziția de start în cadrul acestuia și lungimea răspunsului,
precum și numele metodei, “SendCallback” în cazul de față, ce transmite răspunsul în mod
asincron.

Secvență de cod 4.4 Trimitere răspuns querry de tip Select

Metoda SendCallback va trimite clientului faptul că query-ul de tip Insert sau

Update a fost efectuat sau răspunsul în cazul unei interogări de tip Select după care va opri
conexiune cu acesta și va fi eliminat din lista cu clienți conectați.

22
4.3 Aplicația Windows de tip client din incinta localului

Aceasta este aplicația client ce este instalată pe un calculator în incinta localului și

va permite personalului să vadă starea meselor: libere, ocupate, rezervate, dar și să vadă
daca a fost efectuată o comandă la una dintre mese sau dacă unii clienți doresc să achite
nota de plată pentru a pleca. Acest program va necesita o conexiune permanentă la
Internet.

Aplicația a fost dezvoltată în limbajul de programare C# și folosește tehnologia

Windows Forms pentru a realiza interfața grafică cu utilizatorul. Aplicați are două tipuri de
ferestre: o fereastră principală în cadrul căreia ospătarii vor putea observa în timp real
situația meselor și mai multe ferestre, câte una pentru fiecare masă, în care ospătarii vor
putea vedea ce conține o comandă efectuată la masă sau ce produse mai trebuie duse la
masă. Ferestrele și utilitatea lor va fi descrisă în următorul capitol.

Structura parțială a aplicației Windows de tip client poate fi observată în figura de

mai jos (Fig. 4.4). În cadrul clasei se regăsesc încă 14 obiecte identice cu: produseDeDus1,
produseDuse1, newOrder1, timer1, button1, iar în cadrul proiectului încă 14 clase identice
cu Masa1, fiecare clasa pentru câte o masă.

Fig. 4.4 Diagramă de clase aplicație Windows de tip client

Odată pornit programul, se va deschide fereastra principală si va fi lansat în

execuție un thread principal ce o va ține “în viață” până când utilizatorul va apăsa butonul
de închidere al acesteia. În același constructor în care este creată fereastră fereastra
principală se va crea și un task cu aceeași lungime de viață ca și thread-ul principal al
aplicației. Taskul va reapela metoda checkTables la 10 secunde după ce aceasta a fost
rulată în întregime.

23
 În cadrul limbajului de programare C# task-urile pot fi utilizate folosind
namespace-ul “[Link]” ce conține clasa predefinită Task si toate
metodele necesare utilizării ei. Task-urile sunt utilizate în general pentru a executa o
singură operație în urma căreia nu se returnează nicio valoare și se execută în mod
asincron. În cazul aplicației de față, task-ul va rula metoda checkTables ce este
responsabilă cu obținerea status-urilor meselor, status ce va fi reținut în baza de date
deoarece acesta va fi accesat și de celelalte două aplicații Android. A fost necesară
utilizarea unui task datorită proprietății acestuia de a rula asincron. Rularea asincronă a fost
necesară în această situație pentru a nu bloca aplicație din momentul în care se va face
cererea către server și până când aplicația va primi un răspuns.

Metoda checkTables este cea care se ocupă de aflarea status-urilor meselor și de

modificarea interfeței grafice cu utilizatorul. În momentul în care începe execuția acestei
metode, se creează un socket ce poate comunica în ambele sensuri, trimite și primește
informații, și folosește o adresă IPv4 și un protocol Internet după care îi este asociată
adresa IP a serverului și portul la care trebuie să se conecteze. Adresa IP și portul vor fi
cunoscute de la început, știindu-se din timpul proiectării aplicației de tip server. După ce a
fost creat socket-ul, interogarea SQL de tip Select va fi salvată într-un string și codificată
în bytes, rezultatul fiind copiat într-un vector de tip bye apelând mai apoi metoda
,predefinită, Send a socket-ului și se așteaptă răspunsul de la server. Răspunsul venit de la
server va fi tot de tipul byte, necesitând decodarea acestuia și salvarea lui într-un string.
După ce răspunsul a fost primit și salvat în întregime, clientul se va deconecta de la server,
închizând conexiunea. Forma în care este trimis înapoi răspunsul serverului a permis ca
status-urile meselor sa fie identificate si izolate cu ușurință, primindu-se câte un cuvânt
pentru fiecare masă urmat de caracterul special “\n” ce marchează convențional sfârșitul
unei înregistrări. Status-urile meselor vor fi salvate într-o listă de string-uri (ce este
reinițializată la fiecare reapelare a metodei), ce va fi folosită pentru modificarea interfeței
grafice cu utilizatorul. Status-ul unei mese poate fi unul dintre următoarele: liber, ocupat,
rezervat, comandă sau plată, fiecare modificând într-un mod unic interfața grafică a
ferestrei principale.

Secvență de cod 4.5 Exemplu cerere și răspuns de la server în C#

24
 După separarea status-urilor meselor începe verificarea pe rând a acestora. Fiecare
element al listei cu status-uri va fi comparat cu unul dintre cele cinci posibile. Fiecare
dintre acestea va modifica interfața grafică și le va oferi ospătarilor informații despre ce se
întâmplă la mese. Prezența status-ului “rezervat” nu va avea doar rolul de a modifica
interfața grafică, ci se va ocupa și de tratarea rezervărilor. Fiecare masă are asociat câte un
timer, iar în momentul în care se observă că în baza de date există un status de tipul
“rezervat” se va verifica dacă timer-ul rulează, fiind pornit în cazul în care acesta era
oprit. Imediat după verificarea statusului fiecărei mese, se verifică durata de timp
înregistrată de timer-ul asociat fiecărei mese, pentru a putea determina dacă au trecut cele
15 minute, echivalentul a 900000 milisecunde contorizate de timer, în care este valabilă o
rezervare. Timer-ul va fi oprit și resetat în cazul în care cele 15 minute au trecut sau
status-ul mesei a fast modificat luând valoarea “ocupat”, indicând faptul că masa a fost
ocupată de cei ce au făcut rezervarea. În cazul în care timer-ul se oprește din cauza
depășirii perioade de 15 minute, aplicația se va conecta la server și va modifica status-ul
mesei respective marcând faptul că aceasta a devenit “liberă” și nu mai este „rezervată”.

Odată ce status-urile meselor au fost verificate si interfața grafică a ferestrei

principale a fost modificată adecvat, metoda va fi reapelată de către task după 10 secunde.
Aceste două lucruri au loc din motive adecvate. Întreruperea de 10 secunde este efectuată
pentru a nu solicita serverul prea mult.

Fiecare buton, ce reprezintă câte o masă, poate fi apăsat în cazul în care status-ul
mesei căreia îi corespunde este “comandă” sau ”plată”, fiecare fiind corespunzător
semnalat.

În cazul apăsării butonului atunci când există o comandă la masă aplicația se va

conecta la server și va obține lista de produse ce au fost comandate până acum la masa
respectivă pe bonul curent, (modul în care se atribuie un bon curent va fi explicat în cadrul
aplicației Android pentru tabletă). Se va realiza o interogare a bazei de date, căutând în
tabela “Comenzi” numele și numărul de produse ce au fost comandate pe bonul trecut ca
fiind curent în dreptul mesei respective în tabela “Mese” și răspunsul serverului va fi salvat
într-o variabilă de tip string. După aceasta se va deschide o noua fereastră în care vor putea
fi vizualizate produsele ce trebuie duse la masa respectivă, fie că sunt produse dintr-o
comandă nouă, sau dintr-o comandă anterioară, mai mare, a cărei produse nu au fost duse
în întregime. Clasa responsabilă de crearea noii ferestre va folosi 3 variabile, asociate
mesei sale, ce aparțin clasei ce implementează fereastra principală. String-ul cu răspunsul
serverului va fi împărțit într-un număr de string-uri egal cu numărul de caractere speciale
”\n” găsite. Fiecare șir este compus din numele unui produs și numărul de astfel de produse
comandate și va fi adăugat într-o lisă de string-uri ce conține produsele ce ar trebui duse la
masă. După determinarea produselor ce ar trebui duse la masă se verifică dacă acestea
există deja într-o listă de string-uri (modul în care aceasta este populată va fi explicat mai
jos) ce conține produsele ce au fost duse deja la masă, iar fiecare produs marcat ca fiind
duse deja la masă va fi eliminat din lista celor ce ar trebui duse la masă. Astfel se obține o
listă în care rămân doar produse ce trebuie duse la masă și care va fi afișată ospătarului cu

25
ajutorul unui obiect de tipul CheckedListBox. Acum, ospătarul poate bifa produsele pe
care le va duce sau tocmai au fost duse la masă, iar după apăsarea butonului “Ok!” listele
vor fi modificate adecvat. Produsele bifate vor fi adăugate în lista cu produse duse și șterse
din lista cu produse ce trebuie duse. În cazul în care lista cu produse ce trebuie duse este
goală, aplicația se va conecta la server și va marca masa ca fiind ocupată, modificând
adecvat interfața ferestrei principale.

În cazul apăsării butonului atunci când clienții anunță ca vor să achite nota pentru a
pleca se va afișa un mesaj ce anunță ospătarul că bonul se va printa, iar aplicația se va
conecta la server si va marca masa ca fiind liberă. În același timp, lista cu produsele ce au
fost duse la masă se va goli pentru a putea deservi următoarei comenzi.

4.4 Aplicația Android pentru tabletă

Aplicația Android pentru tabletă este cea care le permite clienților să realizeze
comenzi, să vadă suma pe care trebuie să o plătească, dar și să anunțe ospătarul că doresc
să achite nota de plată pentru a pleca. Aceasta este alcătuită din cinci activități, iar structura
ei poate fi văzută în figura Fig. 4.5. Pentru a putea funcționa, aplicația necesită o conexiune
la Internet.

O activitate reprezintă o singură acțiune pe care utilizatorului îi este permis să o

facă. Toate activitățile sunt create pentru a-i permite unui utilizator să interacționeze cu
aplicația.. O activitate este o clasă ce extinde clasa Activity. Fiecare activitate trebuie să
suprascrie și să apeleze metodele onCreate, onStart, onPause, onStop, on Destroy,
onRestart și onBackPressed ale clasei părinte, Activity.

Toate activitățile, împreună cu proprietățile lor, folosite în cadrul aplicației sunt

declarate într-un fișier XML numit “[Link]” De asemenea, aici sunt
specificate toate permisiunile de care o aplicație are nevoie pentru a funcționa. De
exemplu, aplicațiile Android dezvoltate în cadrul proiectului au nevoie de permisiuni
pentru a utiliza datele mobile sau Wi-Fi-ul. În același fișier se poate specifica orientarea
fiecărei activități, portret sau panoramă, precum și ce iconiță va avea aplicația.
Pictogramele utilizate ca iconiță sunt salvate de obicei în folder-ul
/res/mipmap/ic_launcher din cadrul proiectului.

26
 Fig. 4.5 Diagramă de clase aplicație Android pentru tabletă

Fiecare activitate a unei aplicații poate avea un layout unic. Layout-ul definește structura
vizuală a interfeței cu utilizatorul. Elementele componente interfeței grafice a unei
activități se declară in fișierul XML asociat acesteia. Un avantaj al declarării interfeței
grafice într-un fișier XML este separarea modului în care interfața arată de codul ce
controlează comportamentul acesteia. De exemplu se pot realiza layout-uri diferite pentru
limbi diferite în care o aplicație poate fi folosită, layout-ul schimbându-se în momentul în
care utilizatorul selectează o limba diferită. Fiecare astfel de fișier XML trebuie să aibă un
singur element rădăcină, acesta conținând la rândul lui toate celelalte elemente ce
alcătuiesc interfața grafică. Fișierul XML asociat unei activități trebuie încărcat în cadrul
metodei onCreate ce se apelează atunci când o activitate este creată. Acesta se încarcă
precum în exemplul următor: setContentView([Link].activity_menu) unde ”R”
reprezintă folder-ul de resurse al aplicației, ”layout” este folder-ul în care sunt salvate
fișierele XML utilizate pentru interfața grafică și ”activity_menu” este numele fișierului
XML ce trebuie încărcat.

Orice aplicație Android are o activitate principală ce este afișată prima oară atunci
când este deschisă, cu condiția ca aceasta să nu ruleze deja în background. Activitatea

27
principală a acestei aplicații este “MainActivity” și din cadrul acesteia utilizatorul va fi
redirecționat către celelalte activități din cadrul aplicației.

Odată lansată activitatea principală, aplicația se va conecta la server, prin

intermediul unui socket, și va afla status-ul mesei existând astfel trei situații posibile. În
cazul în care masa este liberă status-ul va fi modificat în ”ocupat” , astfel cei ce folosesc
aplicația destinată smartphone-urilor vor putea să vadă că este cineva la masă și că are
intenția de a comanda, chiar dacă până acum nu a fost deschis un bon pe masa respectivă.
În cazul în care aplicația este închisă și nu a fost efectuată nicio comandă, se va realiza o
conexiune la server pentru a seta status-ul mesei în “liber”. În cazul în care masa
configurează ca fiind rezervată, se va crea un Intent ce va porni activitatea
“RezervationActivity”. În cazul în care starea mesei este una dintre celelalte posibile, nu va
apărea nicio modificare. Intent-urile sunt folosite pentru a naviga dintr-o activitate în alta.

Spre deosebire de limbajul de programare C#, în Java realizarea unei conexiuni cu

serverul necesită crearea unui nou thread separat de thread-ul principal ce este folosit
pentru rularea activității. Fiecare metodă a acestei aplicații ce necesită manipularea bazei
de date are în cadrul ei un thread ce execută toate operațiile necesare și este întrerupt odată
ce acestea au fost terminate. Crearea unui thread separat este necesară pentru a nu bloca
aplicația si pentru a-i permite utilizatorului să interacționeze cu aceasta cât timp există o
conexiune deschisă cu serverul.

Secvență de cod 4.6 Exemplu conectare la server și creare Intent

28
 Activitatea “RezervationActivity” este cea care se ocupă de rezervările efectuate de
utilizatorii aplicației pentru smartphone. În interfața grafică a acestei activități se află un
container de text, TextView, ce îl înștiințează pe client că trebuie să introducă codul
rezervării, un câmp de tip input, EditText, și un buton ce trebuie apăsat pentru a verifica
codul introdus. În momentul în care butonul este apăsat se realizează o conexiune la server
și se extrage codul rezervării asociat mesei. Textul introdus în cadrul câmpului EditText
este copiat într-un string și se compară cu codul extras din baza de date. În cazul în care
cele doua coduri sunt identice se va crea o conexiune la baza de date pentru a specifica
faptul că masa este acum ocupată și un Intent ce va porni activitatea ”MainActivity” pentru
a le permite clienților să comande, iar în caz contrat se va crea și afișa un Toast ce conține
un mesaj corespunzător.

Un toast este un container de text ce permite afișarea unei mesaj sub formă de
popup. Acesta ocupă, în general, puțin loc pe ecran, suficient cât să cuprindă tot mesajul
dorit și dispare după o scurtă perioadă de timp. Pentru afișarea unui mesaj sub această
formă este necesară crearea unui thread de tip Looper, responsabil de menținerea pe ecran
a mesajului.

Secvență de cod 4.7 Exemplu creare Toast

Din cadrul activității principale, utilizatorul poate naviga manual într-una din
celelalte trei activități, în funcție de preferințe, prin apăsarea unuia dintre cele trei butoane.
La apăsarea unui buton se va crea un Intent ce-l va redirecționa pe utilizator în activitatea
corespunzătoare.

Activitățile “FoodMenuActivity” și “DrinksMenuActivity” sunt identice din punct

de vedere al sarcinilor pe care le îndeplinesc, diferind doar conținutul lor. Ambele conțin
un buton și un container de tipul ScrollView. Fiecare ScrollView conține un tabel ce are pe
fiecare rând un container de tip TextView și un câmp input de tip EditText. Într-un
container TextView se găsesc informații despre un produs precum numele acestuia, și
ingredientele (dacă este cazul), iar în câmpul EditText aflat în dreptul fiecărui nume de
produs se poate introduce numărul de astfel de produse ce se doresc comandate. În
activitatea ”FoodMenuActivity” se va găsi mâncarea, iar în a ”DrinksMenuActivity ”se vor
găsi băuturile. Când butonul prezent în ambele este apăsat se va crea o conexiune la server
și se va extrage din tabela “Mese” bonul curent asociat mesei, existând două situații. În
cazul în care bonul curent este 0 se consideră că la masă nu exista încă nicio comandă.
Astfel, se va accesa tabela “Bonuri” pentru a crea un bon nou și se va modifica câmpul ce

29
conține bonul curent al mesei din tabela “Mese” după care se plasează comanda. În cazul
în care există un bon deschis se va trece direct la plasarea comenzii. Pentru a plasa
comanda se va crea un obiect de tipul Produs, corespunzător fiecărui produs, în care se va
vor salva ID-ul produsului, dacă s-a introdus text în câmpul EditText și ce text. Apoi
fiecare obiect de tip Produs va fi verificat pentru a vedea dacă câmpul EditText asociat era
gol sau nu, iar în cazul în care acesta nu este gol, obiectul va fi introdus într-o listă de astfel
de obiecte. La final lista va fi accesată, se vor extrage ID-urile produselor și cantitatea
dorită, se va realiza o conexiune la server și se va face un query multiplu de tip Insert ce va
introduce în tabela ”Comenzi” pentru fiecare produs ID-ul lui, numărul de astfel de
produse comandate, numărul bonului pe care va fi adăugat produsul și masa la care a fost
comandat.

Activitatea “ToPayActivity” permite utilizatorului să vadă cât trebuie să plătească

pentru produsele comandate și să anunțe ospătarul că dorește plătească pentru a putea
pleca. În momentul în care activitatea este pornită se va crea o conexiune la server pentru a
obține lista de produse comandate. Utilizatorul va putea vedea mai apoi o lista ce conține
pe fiecare rând numele unui produs, numărul de astfel de produse comandate și valoarea
unui astfel de produs, cât valorează toate produsele de acest tip, dar și totalul notei. La
apăsarea butonului ”Plateste” se va crea o crea o fereastră de tipul AlertDialog. Butonul are
asociat un OnClickListener ce creează o astfel de fereastră în momentul în care este apăsat.
Acesta este o fereastră folosită pentru a confirma intenția clientului de a plăti, în cazul în
care acesta a apăsat butonul din greșeală. Fereastra îi arată, din nou, utilizatorului totalul de
plată și-i oferă două opțiuni: de a confirma cererea făcută sau de a renunța. În cazul în care
utilizatorul confirma intenția de a pleca, se va realiza o conexiune la baza de date, bonul
curent va fi închis în tabela “Bonuri”, status-ul mesei va deveni ”plata” și bonul curent
pentru masă va fi setat cu valoarea 0.

Secvență de cod 4.8 Exemplu creare AlertDialog

30
 Fiecărui TextView, EditText si Button îi asociat câte un ID, la creare, pentru a
putea realiza identificare lor și a ști cu exactitate care dintre acestea este folosit la un
moment dat. Butoanele sunt caracterizate și de o atributul onClick în care se specifică ce
metodă va fi executată in momentul apăsării lui.

4.5 Aplicația Android pentru smartphone

Această aplicație permite utilizatorilor să vizualizeze în timp real selectând un local

dintr-o listă prestabilită. Pentru a putea utiliza această funcție telefonul trebuie să fie
conectat la Internet. De asemenea, prin intermediul acestei aplicații utilizatorii vor putea
vedea și lista de produse disponibile în fiecare local. Spre deosebire de funcția precizată
anterior, meniurile localurilor vor putea fi vizualizate și fără o conexiune la Internet.
Aplicația, în stadiul curent, are 3 activități și are următoarea structură:

Fig. 4.6 Diagramă de clase aplicație Android pentru smartphone

31
 Activitatea principală a aplicației este “MainActivity” și conține lista de localuri
disponibile. Lista este salvată într-un container de tip ScrollView ce conține un tabel. Pe
fiecare rând al tabelului se află numele unui local și doua butoane, unul pentru vedea
meniul și unul pentru a vedea harta localului și disponibilitățile meselor. Tranziția de la
activitatea principală la celelalte activități se face prin intermediul Intent-urilor.

Activitatea “MenuPavone” conține informații despre produsele disponibile în

localul Pavone. Utilizatorii pot vedea atât numele produselor cât și prețul acestora. Când
această activitate se va accesa pentru prima dată, utilizatorul va vedea inițial lista de
mâncăruri, putând sa vizualizeze băuturile apăsând butonul ”Bautura” și invers în cazul în
care se afla în fereastra pentru băuturi și dorește să ajungă în cea pentru mâncare.

Activitatea “RezervaPavone” este cea în care utilizatorii vor putea vedea în timp
real disponibilitatea meselor din localul Pavone. Când activitatea este creată, la apelarea
metodei onCreate, fiecărui buton i se va asocia un obiect de tip Button pentru a putea fi
identificat cu ajutorul ID-urilor atribuite și va fi creat un handler. Handler-ul este folosit
pentru a rula repetat, la un interval de timp prestabilit, anumite comenzi. Fiecare buton din
această activitate corespunde unei mese din local.

În cadrul metodei onStart, ce este rulată de fiecare dată când activitatea este
deschisă, o variabilă de tip boolean va primi valoarea de adevăr true. Handler-ul creat
anterior va fi pornit și va rula metoda checkTables din cinci în cinci secunde cât timp
variabila de tip boolean are valoarea de adevăr true.

Metoda checkTables este cea în care aplicația se conectează la baza de date pentru
a prelua status-ul meselor din localul respectiv. Răspunsul primit este sub forma unui string
de cuvinte formate din status-urile meselor și despărțite între ele prin caracterul special
”\n”. După ce acestea sunt separate și adăugate într-o listă ce conține string-uri, fiecare
element al acesteia va fi verificat dacă coincide cu “liber” pentru a modifica corespunzător
aspectul fiecărui buton asociat meselor.

Fiecărui buton îi este asociat câte un onClickListener. În momentul în care un buton

este apăsat se verifică starea mesei corespunzătoare în lista de status-uri. Dacă masa este
ocupată va fi creat un Toast ce-l înștiințează pe utilizator că masa este ocupată. În cazul în
care masa este liberă, se va crea și afișa un AlertDialog în care i se comunică utilizatorului
că rezervarea va fi valabilă 15 minute de la realizarea ei. În acest AlertDialog utilizatorul
are doua opțiuni: să renunțe sau să confirme intenția de a face o rezervare, lansând astfel în
execuție metoda de rezervare corespunzătoare fiecărei mese.

În momentul în care fost confirmată intenția de rezervare a unei mese se va genera

automat un cod de 7 caractere, iar aplicația se va conecta la baza de date pentru a introduce
acest cod în câmpul “cod_rezervare” al tabelei Mese și pentru a seta noul status al mesei.
În acest moment, timer-ul, din aplicația Windows, corespunzător mesei rezerva va porni și

32
va cronometra cele 15 minute. De asemenea, utilizatorul va primi o notificare pe telefon cu
codul generat ce va trebui introdus în tableta de la masă pentru a putea comanda.

Secvență de cod 4.9 Exemplu creare notificare

33
5. Utilizarea aplicațiilor

Fiecare aplicație este destinată unui tip diferit de utilizator ce poate efectua diferite
acțiuni.

 Ospătarii din localuri vor putea să:

 Vizualizeze status-urile meselor

 Închidă bonurile
 Vadă produsele comandate

 Utilizatorii aplicației de pe tabletă vor putea să:

 Citească meniurile
 Comande produse
 Vadă produsele comandate și valoarea lor

 Utilizatorii aplicației de pe telefonul smartphone vor putea să:

 Vadă lista localurilor

 Citească meniuri
 Facă rezervări
 Comande produse
 Vadă produsele comandate și valoarea lor

34
 Fig. 5.1 Diagrama cazurilor de utilizare

5.1 Utilizarea aplicației Windows

Această aplicație va fi utilizată doar de personalul localului și le va permite

ospătarilor să observe status-ul meselor și eventualele comenzi efectuate la o masă.

În fereastra principală, fiecare masă este reprezentată de câte un buton a cărui

culoare se va schimba în funcție de starea mesei. Colorile asociate fiecărei stări sunt:
verde – masa este liberă, roșu – masa este ocupată, albastru – comandă existentă, galben -
masa este rezervată, portocaliu – a fost solicitată nota de plată.

35
 Fig. 5.2 Fereastra principală a aplicației Windows

În momentul în care ospătarul apasă pe o masă ce are o comandă nouă sau la care
mai sunt produse din comanda anterioară ce trebuie duse, se va deschide o nouă fereastră .
În fereastra nou deschisă va fi afișată lista cu produse ce trebuie duse. Ospătarul va putea
să bifeze produsele pe care urmează să le ducă imediat sau pe care tocmai le-a dus. După
ce produsele au fost selectate, se va apăsa butonul “Ok!” pentru a salva modificările făcute
și pentru a închide fereastra. Dacă lista se va goli, culoarea mesei va deveni roșie și această
fereastră nu va mai putea fi deschisă până când nu se va mai face o nouă comandă, iar în
caz contrar butonul va rămâne albstru.

Fig. 5.3 Fereastră pentru vizualizarea comenzii făcute la o masă

36
5.2 Utilizarea aplicației Android pentru tabletă

Această aplicație va fi utilizată de clienții localului pentru a comanda.

În cazul în care masa este rezervată și un potențial client încearcă să folosească

tableta pentru a comanda, acesta va fi redirecționat spre o fereastră ce îi cere acestuia să
introducă codul rezervării. În cazul în care codul introdus este corect acesta va fi
redirecționat către meniul principal al aplicației, iar în caz contrat va fi afișat un mesaj
corespunzător.

Fig. 5.4 Fereastră pentru masă rezervată

Meniul principal conține trei butoane.

Fig. 5.5 Meniu principal aplicație Android pentru tabletă

37
 Apăsând butoanele Mancare sau Bautura, clientul va fi redirecționat către partea
corespunzătoare a meniului. În ambele ferestre ce ar putea fi deschise acesta va vedea
produsele disponibile, grupate pe categorii. Pentru a putea comanda un produs, clientul va
apăsa pe câmpul din dreapta asociat fiecărui produs și i se va deschide o tastatură ce
permite introducerea de cifre pentru a introduce numărul de astfel de produse pe care
dorește să le comande. Odată alese produsele, se va apăsa butonul Comandă pentru a plasa
comanda.

Fig. 5.6 Meniu mâncare aplicație Android pentru tabletă

Fig. 5.7 Meniu băutură aplicație Android pentru tabletă

Apăsând pe butonul Vezi nota, clientul va fi redirecționat către o fereastră în care

va putea vedea cât trebuie să plătească. Aici el poate să apese butonul Inapoi pentru a
revenit la fereastra principală a aplicației sau Plateste pentru a solicita nota de plată și se va
deschide o fereastră de dialog. În această fereastră este afișat din nou clientului totalul de
plată și i se va cere o confirmare a intenției de a plăti deoarece butonul ar putea fi apăsat
din greșeală.

38
 Fig. 5.8 Meniu vizualizare notă de plată

Odată confirmată cererea notei de plată, clientul este informat că ospătarul va veni
imediat pentru a lua banii.

Fig. 5.9 Confirmarea cererii notei de plată

5.3 Utilizarea aplicației Android pentru smartphone

Utilizatorii acestei aplicații vor putea vizualiza meniurile și să vadă în timp real
disponibilitățile meselor localurilor.

În fereastra principală va fi disponibilă lista cu localuri în care a fost implementat

sistemul ce permite vizualizarea meselor.

39
 Fig. 5.10 Meniu principal aplicație Android pentru telefon

Apăsând pe butonul Meniu din dreptul unui local aceștia vor fi redirecționați către
o activitate în care poate fi consultat meniul de mâncăruri.

Fig. 5.11 Meniu mâncare aplicație Android pentru telefon

Apăsând butonul Bautura din cadrul acestei activități utilizatorii vor putea vedea
meniul de băuturi și se vor putea întoarce în fereastra anterioară apăsând butonul Mancare.

40
 Fig. 5.12 Meniu băutură aplicație Android pentru telefon

Disponibilitățile meselor dintr-un local vor putea fi văzute apăsând butonul Rezerva
din dreptul localului respectiv. Odată ajunși în noua fereastră utilizatorii vor vedea harta
localului și mesele acestora. Fiecărei mese îi este asociat un buton ce poate avea două
culori: verde – simbolizează că masa este liberă și roșu – simbolizează că masa este
ocupată. În cazul în care este apăsat un buton verde se va deschide o fereastră de dialog
ce-i va comunica utilizatorului că este pe cale să rezerve o masă și i se va cere o
confirmare.

Fig. 5.13 Vizualizare disponibilități mese

41
 Fig. 5.14 Confirmare rezervare masă

În cazul în care masa a fost rezervată înainte ca utilizatorul să-și confirme intenția
se va afișa un mesaj corespunzător.

Fig. 5.15 Eroare rezervare masă ce a fost ocupată între timp

În cazul în care utilizatorul apasă un buton roșu acesta va fi informat că masa

respectivă este deja rezervată.

42
 Fig. 5.16 Eroare rezervare masă deja ocupată

Odată ce masa a fost rezervată, utilizatorul va primi imediat o notificare pe telefon

ce conține codul rezervării. Acest cod va trebui introdus în tableta aflată pe masa din local
pentru a o debloca și comanda. Codul este valabil 15 minute din momentul rezervării.

Fig. 5.17 Notificare cu codul rezervării

43
5.4 Scenariu de utilizare

Un utilizator al aplicației pentru smartphone împreună cu cinci prieteni doresc să-și

petreacă seara într-un restaurant. Aflați deja în apropierea a două restaurante, aceștia decid
să încerce să ocupe o masă în unul din acestea, dar constată ca toate mesele sunt ocupate.
Acesta decide să utilizeze aplicația pentru a căuta o masă și constată că în primul restaurant
din lista de localuri este disponibilă o masă de șase locuri și face o rezervare în urma căreia
primește un cod generat aleatoriu și masa devine ocupată. Grupul de prieteni pleacă spre
locația restaurantului.

În același timp, un alt grup de persoane, printre care nu se află niciun utilizator al
aplicației, ajunge în restaurantul în care utilizatorul menționat a rezervat masa. Aceștia văd
ca este o singură masă disponibilă și se așază la aceasta, dar constată că pentru a comanda
folosind tableta disponibilă la masă este nevoie de un cod asociat unei rezervări pe care
aceștia nu îl au și se văd nevoiți să se ridice de la masă și să se îndrepte către alt local.

Utilizatorul și grupul său ajung la restaurant înainte ca rezervarea să expire. Aceștia

se așază la masă și introduc codul rezervării, putând astfel să comande. După plasarea
comenzii, ospătarul este înștiințat că trebuie să ducă anumite produse la masa respectivă.

Dorind să plece, grupul consultă nota de plată utilizând tableta și-l înștiințează pe
ospătar că doresc să dorește să plece. Ospătarul va fi notificat pe calculator de intenția
clienților, printează bonul și merge la masă pentru a lua banii.

44
6. Concluzii

Dezvoltarea celor patru aplicații a necesitat utilizarea cunoștințelor teoretice și

practice dobândite în timpul facultății, dar și acumularea unor cunoștințe teoretice noi, cât
și învățarea modului de utilizare a unor tehnologii noi.

Partea de dezvoltare a server-ului mi-a permis să studiez modul în care aplicațiile

ce necesită o conexiune la Internet funcționează și modul prin care acestea comunică între
ele cu ajutorul socketelor.

În timpul dezvoltării aplicațiilor client, dar m-ai ales pentru cele Android, am fost
nevoit să gândesc aplicațiile din punctul de vedere al unui utilizator. Acestea trebuiau să
asigure toate utilitățile pe care mi le-am propus, dar și să arate într-un mod cât mai plăcut.
De asemenea, o altă problemă pe care a trebuit să o am în vedere a fost timpul necesar unei
aplicații pentru a modifica interfața grafică în funcție de informațiile din baza de date,
Inițial, timpul acesta era mare rezultând astfel durate de așteptare destul de lungi, dar după
multiple optimizări am obținut un timp de așteptare acceptabil.

Deși aplicația realizează toate funcțiile pe care mi-am dorit să le implementez, mai
pot fi aduse anumite îmbunătățiri precum:

- Sistem de feedback pentru localuri

- Localizarea localurilor utilizând Google Maps
- Implementarea unui program de contabilitate

45
7. Bibliografie

1. Bruce Eckel, Thinking in Java, 4th Edition, 2006

2. Svetlin Nakov, Veselin Kolev , Fundamentals of Computer Programming with C#,
2013
3. Marko Gargenta, Learning Android, 2nd Editiob, 2014
4. John Sharp, Microsoft Visual C# 2013 Step by Step, 2013
5. Documentație oficială .NET. Accesat: 2016.
<[Link]
6. Documentație oficială Android. Accesat: 2016
<[Link]
7. Documentație oficială Java. Accesat: 2016
<[Link]

46