Programul de Licență: Informatică [605298]

Facultatea de Automatică și Calculatoare
Programul de Licență: Informatică

BOOKSHARE -APLICAȚIE MOBILĂ PENTRU
ÎMPRUMUTAREA CĂRȚILOR

Lucrare de licență

Timișoara, 2019
Coordonatori Absolvent: [anonimizat].dr.ing. Adriana ALBU
As.univ. Cristian ZIMBRU Ana VULPEȘ

2
Cuprins
Lista figurilor utilizate ………………………….. ………………………….. ………………………….. …………… 3
Lista acronimelor ………………………….. ………………………….. ………………………….. ………………….. 4
Capitolul 1. Introducere ………………………….. ………………………….. ………………………….. ……. 5
1.1. Contextul ………………………….. ………………………….. ………………………….. ………………… 5
1.2. Motivația ………………………….. ………………………….. ………………………….. ………………… 5
Capitolul 2. Tehnologii folosite ………………………….. ………………………….. ……………………… 6
2.1. Sistemul de operare Android ………………………….. ………………………….. ………………….. 6
2.2. Componentele unei aplicații Android ………………………….. ………………………….. ……… 8
2.3. Android Studio ………………………….. ………………………….. ………………………….. ………. 15
2.4. Limbajul de programare Java ………………………….. ………………………….. ……………….. 17
2.5. Baza de date Google Firebase ………………………….. ………………………….. ………………. 18
Capitolul 3. Aplicații asemănătoare ………………………….. ………………………….. ………………. 20
3.1. Booxup ………………………….. ………………………….. ………………………….. …………………. 20
3.2. Bookup ………………………….. ………………………….. ………………………….. …………………. 21
Capitolul 4. Specificațiile aplicației ………………………….. ………………………….. ………………. 22
4.1. Analiza cerințelor ………………………….. ………………………….. ………………………….. …… 22
4.2. Proiectarea soluției ………………………….. ………………………….. ………………………….. …. 22
4.3. Schema de utilizare a aplicației ………………………….. ………………………….. …………….. 23
4.4. Funcțiile sistemului ………………………….. ………………………….. ………………………….. … 23
4.5. Structura bazei de date ………………………….. ………………………….. ………………………… 29
4.6. Utilizarea aplicației ………………………….. ………………………….. ………………………….. … 34
4.7. Testarea aplicației pe alte dispozitive ………………………….. ………………………….. …….. 39
Capitolul 5. Concluzii ………………………….. ………………………….. ………………………….. …….. 40
Bibliograf ie ………………………….. ………………………….. ………………………….. ………………………… 41

3
Lista figurilor utilizate
Fig. 2.1 Arhitectura platformei Android ………………………….. ………………………….. ……………….. 7
Fig. 2.2 Stivă de activități ………………………….. ………………………….. ………………………….. ………. 9
Fig. 2.3 Ciclul de viață al unei activități ………………………….. ………………………….. ……………… 12
Fig. 2.4 Fragmentarea unei activități ………………………….. ……. Error! Bookmark not defined.
Fig. 2.5 Ierarhia obiectelor de tip View ………………………….. ………………………….. ………………. 13
Fig. 2.6 Exemplu de fișier Android Manifest ………………………….. ………………………….. ……… 14
Fig. 2.7 Structura unui proiect în Android Studio ………………………….. ………………………….. … 16
Fig. 3.1 Aplicație mobilă Bo oxup ………………………….. ………………………….. ………………………. 20
Fig. 3.2 Aplicație mobilă Bookup ………………………….. ………………………….. ………………………. 21
Fig. 4.1 Schema de utilizare a aplicației ………………………….. ………………………….. ……………… 23
Fig. 4.2 Diagramă Autentificare User ………………………….. ………………………….. …………………. 24
Fig. 4.3 Diagramă activitate Înregistrare User ………………………….. ………………………….. ……… 25
Fig. 4.4 Diagramă activitate Editare P rofil ………………………….. ………………………….. ………….. 26
Fig. 4.5 Diagramă activitate Adaugă Carte ………………………….. ………………………….. ………….. 27
Fig. 4.6 Diagramă Șterge/Împrumură/Returnează cartea ………………………….. ………………….. 29
Fig. 4.7 Consola Firebase Authentication ………………………….. ………………………….. ……………. 30
Fig. 4.8 Structura nodului „users” ………………………….. ………………………….. ………………………. 31
Fig. 4.9 Structura nodului „books” ………………………….. ………………………….. …………………….. 31
Fig. 4.10 Structura nodului „connections” ………………………….. ………………………….. …………… 32
Fig. 4.11 Structura nodurilor „loans” și „requests” ………………………….. ………………………….. . 32
Fig. 4.12 Structura nodului „messages” ………………………….. ………………………….. ………………. 33
Fig. 4.13 Fereastra Autentificare ………………………….. ………………………….. ……………………….. 34
Fig. 4.14 Fereastra Înregistrare ………………………….. ………………………….. ………………………….. 34
Fig. 4.15 Fereastra Editare Profil ………………………….. ………………………….. ……………………….. 35
Fig. 4.16 Fereastră Profil utilizator logat ………………………….. ………………………….. …………….. 35
Fig. 4.17 Fereastră Adaugă carte ………………………….. ………………………….. ……………………….. 36
Fig. 4.18 Fereastră carte personală ………………………….. ………………………….. …………………….. 36
Fig. 4.19 Fereastra Vizualizare cărți ………………………….. ………………………….. …………………… 37
Fig. 4.20 Fereastră profil carte (1) ………………………….. ………………………….. ……………………… 37
Fig. 4.21 Fereastră profil carte(2) ………………………….. ………………………….. ………………………. 37
Fig. 4.22 Fereastra Mesaje + layout mesaj ………………………….. ………………………….. ………….. 38

4
Lista acronimelor
API – Application Programming Interface
IDE – Integrated development environment
OHA – Open Handset Alliance
SDK – Software development kit
XML – Extensible Markup Languag e
JSON – JavaScript Object Notation
NDK – Native Development Kit
UI-User Interface
ISBN – International Standard Book Number

5

Capitolul 1. Introducere
1.1. Contextul
Cumperi o carte, o citești și apoi o pui pe raftul bibliotecii tale ca să adune praf. Știți
cum se spune „Prea multe cărți de citit, prea puțin timp”, așadar unele cărți puse înapoi pe raft
după lectură nu vor mai fi deschise. E o soartă destul de tristă , însă nu îl putem învinui pe
cititor .
Nu e tocmai ieftin să ai ca hobby cititul, prețul cărților variază în funcție de calitatea
lor, de raritatea lor și de mulți alți factori . În timp cu fiecare carte cumpărată banii investiți în
biblioteca personală se adună. Nu putem să nu ne întrebăm dacă nu e puțin cam prea mult
pentru o carte care o să fie citită d oar o singură dată. Din acest motiv fo arte mulți cititori ajung
să își facă abonament la bibliotecă sau să își cumpere un e -reader deoarece prețul cărților în
format virtual este mai redus.
Orice cititor a ajuns probabil să dea în împrumut o carte din colecția personală unui
prieten, unei rude sau a cerut vreodată în împrumut o carte. Poate pentru unele persoane cărțile
în format fizic par de domeniul trecutului, însă acest lucru ține de gusturile personale ale
fiecăruia. Există cititori pasionați care nu vor înlocui niciodată senzația de a ține o carte în
mână și a -o răsfoi cu un ecran tactil, indiferent de cât de rentabil ar fi.
1.2. Motivația
O aplicație mobilă ar putea fi gazda unei comunități de c ititori care să își împrumute
cărți între ei. Toată lumea ar avea de câștigat, iar o singură carte circulând astfel de la o persoană
la alta ar avea o soartă mult mai „veselă” decât raftul plin de praf .
Mai mult decât atât, o aplicație cu acest scop ar pu tea deveni un mediu virtual prin care
oamenii ar putea să își facă prieteni cu aceleași interese și gusturi în materie de literatură

6

Capitolul 2. Tehnologii folosite
2.1. Sistemul de operare Androi d
Android Incorporation a fost fondată în octombrie 2003 de către Andy Rubin în Palo
Alto California, Statele Unite ale Americii. Andy Rubin dorea să dezvolte sisteme de operare
pentru camere foto, însă deoarece piața nu era atât de dezvoltată a schimbat direcția înspre
telefoanele mobile . Ulterior în anul 2005, Google a cumpărat compania, Android devine astfel
o filială a sa. Astfel Google intră pe piața telefoanelor mobile, însă nu cu produse hardware.
[1]
În 2007, 5 noiembrie, se formează Open Handset Alliance, un consorțiu de companii în
domeiul Tech, pe lângă Google au fost incluși mai mulți producători de dispozitive: HTC,
Motorola, Samsung , Spint, T -Mobile, Qualcomm și Texas Instruments. Scopul alianței era
acela de a dezvolta standarde deschise pentru dispozitive mobile, oferind utilizatorilor o
experință mult ma i bună decât ce era disponibil la vremea respectivă. La 9 decembrie 2008, au
aderat la acest proiect ambițios încă 14 noi membri: Sony Ericsson, Vodafone Group Plc, ARM
Holdings Plc, Asustek Computer Inc, Toshiba Corp și Garmin Ltd.
Din 21 octombrie 2008, platforma Android bazată pe nucleu Linux (versiunea 2.6)
devine disponibilă ca Open Source, Google punând la dispoziție întregul cod sursă sub licență
Apache. Mai mult decât atât OHA lansează un kit software de instrumente pentru cei interesați
de crearea de aplicații inovative și atractive pentru platformă. Primul telefon scos pe piață cu
sistem de operare Android a fost HTC Dreams (T -Mobile G1), pe data de 22 octombrie
2008. [2]
Arhitectura Android
Arhitectura sistemului Android este alcătuită din 5 niv eluri (după cum se poate observa
în figura 2.1) ce comunică între ele:
➢ Nucleu Linux (Linux Kernel)
➢ Librării de bază
➢ Android Runtime
➢ Aplicații Framework
➢ Aplicații

7

Nucleul Linux constituie primul nivel al arhitecturii sistemului Android, aflându -se la
baza arhitecturii acesta ofer ă un nivel de abstractizare între componentele hardware ale
dispozitivului și nivelele superioare ale arhitecturii. Bazat pe versiunea Linux 2.6, nucleul
asigură funcții low -level : gestiunea energiei, a ecranului, a conexiunii wireless, a driverelor
audio, pentru camera, pentru memoria Flash. [3]
Nivelul de ab stractizare Hardware (Hardware Absttraction Layer) este constituit din
mai multe librării, fiecare dintre ele implementează interfața pentru o anumită componentă
hardware precum senzorii, bluetooth, cameră. De fiecare dată când un framework API face un
apel pentru accesarea unei anumite componete hardware, sistemul Android încarcă librăria
necesară. [3]
ART – Android Runtime furnizează mediul de rulare pentru aplicațiile Android. Pentru
dispozitivele care rulează versiunea de Android 5.0 (API level 21) sau versiuni mai noi, fiecare
aplicație își rulează propriul proces și cu propria instanță de Android Runtime .ART asigură
transformarea fișierelor în format .dex (Dalvik Executable) la momentul compilării, ulterior la
momentul instalării se realizează translat area în format .oat . Fiecare aplicație Android rulează
în process propriu, într -o instanță a mașinii virtuale ART, codul și datele fiind separate prin
intermediul unor permisiuni. Dalvik a fost inițial mediul de rulare Android până să fie înlocuit

Fig. 2.1 Arhitectura platformei Android

8
de ART. Aplicațiile care rulează prin intermediul ART, pot rula fără probleme pe mașina
virtuală Dalvik, însă acest lucru nu e valabil în sens invers. [3]
Multe componete și servicii de bază din sistemul Android,precum ART și HAL, sunt
compuse din cod nativ ce n ecesită librării native scrise în C și C++. Deși majoritatea aplicațiilor
Android sunt scrise în Java, există anumite scenarii în care este necesară utilizarea limbajelor
C/C++ iar acest lucru este posibil prin intermediul tool -ului Android NDK.
Nivelul d e Java API Frameworks pune la dispoziție dezvolatorilor de aplicații Android
funcționalitățile și resursele sistemului de operare. Dezvoltatorii au acces integral la aceleași
framework -uri pe care aplicațiile de sistem le folosesc. [3]
Cele mai importante componente sunt :
➢ Activity Manager – gestiunea ciclului de viață al aplicațiilor și stiva de navigare a
utilizatorului
➢ View System – componentă necesară pentru definirea interfeței aplicației ( liste,
butoane, căsuțe de text)
➢ Resource Manager -asigură ac cesul la fișierele adiționale cu conținut static folosite în
cod, imagini, layout -uri, animații
➢ Notification Manager -componentă necesară pentru gestionarea notificărilor (mesaje
care sunt afișate în afara aplicației precum reminder)
➢ Content Providers – componentă prin intermediul căreia se pot accesa date din alte
aplicații ale sistemului de opeare (locația GPS, Galeria Foto, Contactele)

Dispozitivele Android vin la pachet cu un set de aplicații de bază pentru email,
mesagerie SMS, Calendar, Browser, Cont acte și multe altele. Aplicațiile care vin împreună cu
platforma nu au un status special față de cele pe care utilizatorul alege să le instaleze.

2.2. Componentele unei aplicații Android
O aplicație Android are la bază mai multe componente, fiecare componentă reprezintă
o cale de acces prin care fie sistemul, fie utilizatorul poate resursele aplicației. Unele
componente depind de altele. În această secțiune sunt prezentate componentele de bază ce
alcătuiesc structura unei aplicații Android și legăturile ce se formează între ele.

9
Există 4 tipuri diferite de componente într -o aplicație Android: activities, services,
broadcast recei vers și content providers. Fiecare tip servește un scop anume și are un ciclu de
viață distinct .
1. Activities (Activități)
Activitatea reprezintă un set de task -uri ce îndeplinesc o sarcină unitar,relativ independentă
de restul task -urilor, aceasta este asociată unei ferestre grafice. O activitate este formată dintr –
o clasă Java și un fișier de tip XML, layout -ul ce definește design -ul interfeței. O aplicație
Android este formată din una sau mai multe activități. Prin intermediul activității se realizează
comunicarea cu user -ul. Există o activitate de bază „MainActivity”, toate celelalte activități
fiind subordonate celei pri ncipale. Pentru navigarea de la o activitate la alta există o stivă „back
stack” , procesul este ilustrat în fig. 2.2. De fiecare dată când e deschisă o nouă fereastră
(implicit activitate) , activitatea precedentă este împinsă în spatele stivei până când t erminăm
cu cea „nouă”. Când apăsăm butonul de „Înapoi” din bara de navigare a telefonului , activitatea
precedentă este extrasă din stivă iar cea nouă este distrusă. [ 4]
2. Services (Servicii)
O componenta de tip Service asigură rularea aplicației în fundal, acest lucru putând fi
necesar din diferite motive (de exemplu pentru task -uri de durată lungă de timp). Acest tip de
componentă nu asigură interfață pentru utilizator, dar nici nu blochează accesul acestuia la alte
aplicații ale sistemului. Poate avea dou ă stări:
➢ Started – Din moment ce e pornit, serviciul respectiv își execută în cadrul firului
de execuție principal sarciniile pe care le are de făcut chiar dacă componenta
care l -a declanșat inițial este distrusă. În acest caz nu este returnat nici un
rezul tat
user-ului.
Fig. 2.2 Stivă de activități

10
➢ Bound – în acest caz o altă componentă este „legată” de un serviciu pentru ca o
anumită sarcină să fie îndeplinită. În acest fel este asigurată o interfață de tip
client -service ; pot fi trimise cereri, pot fi primite cereri și se pot returna rezultate
utilizatorului. Atunci când componenta care declanșează serviciul este distrusă
serviciul încetează să mai ruleze. [ 5]

3. Content Providers (Furnizorii de conținut)
Această componentă este folosită pentru gestionarea bazelor de date ale ap licației dar și
pentru schimbul de date cu alte aplicații. Prin intermediul acetui tip de componentă, alte
aplicații pot accesa și modifica date ale aplicației dacă obiectul content provider permite acest
lucru. Android include o baza de date SQLite în car e se pot stoca datele care pot fi accesate
prin intermediul componentelor Content Provider. Se pot partaja date de diferite tipuri: imagini,
fișiere text, audio sau video.
4. Brodcast Receivers (Receptori de anunțuri)
Clasa Broadcast Receiver implementează altă variantă a mecanismului Android de
comunicare între procese cu ajutorul obiectelor de tip Intent. Obiectele de tip Intent reprezintă
mediul de comunicare, pot fi folosite pentru a adresa interogări altor componente, pentru a
instanția no i activități sau pentru a prelua rezultate de la o alta.
Un obiect de tip receiver preia mesaje de tip broadcast. Aceste mesaje pot fi expediate fie
de sistem pentru a notifica modificarea parametrilor sistemului (memorie,semnal, conexiune
Internet etc.) , fie de alte aplicații pentru a anunța începerea sau finalizarea unei operații.
Componeta de tip BroadcastReceiver are un ciclu de viață mult mai simplu decât celelalte tipuri
de componente, asem ănându -se cu o activitate însă nu include interfață pentru u tilizator.
Există două categorii de mesaje ce pot fi recepționate:
➢ Mesaje normale: acestea sunt asincrone prin natura lor, pot fi trimise mai multe în
același timp fără a se ține cont de ordine
➢ Mesaje comandate:acestea sunt sincrone prin natura lor; un m esaj primit de un receptor
este expediat unui alt receptor, în mod secvențial

11
Ciclul de viață al unei activități
Activitatea este componenta cea mai complexă din punct de vedere al ciclului de viață.
Ciclul de viață al unei activității este definit de s tarea în care o activitate poate fi la un moment
dat, aceste stări sunt declanșate de anumite metode , după cum se poate observa și în fig. 2.3 :
➢ Metoda OnCreate() este apelată după ce instanța activității a fost creată. În acest segment
al codului are loc deobicei inițializarea activității: setarea layout -ului prin
setContentView(int) , crearea de obiecte de tip View ,referințe către componentele interfeței
grafice . Dacă activitatea nu va fi distrusă și nici procesul oprit această metodă nu va mai fi
apelată încă o dată.
➢ Metoda OnRestart() este apelată doar dacă o activitate a fost oprită. Prin starea „Stopped”
a unei activități înțelegem că activitatea nu interacționează cu user -ul la un anumit moment.
➢ Metoda OnStart() este apelată atunci când activitate a și obiectele de tip View incluse în ea
devin vizibile pentru utilizator
➢ Metoda OnResume() este apelată înainte de reluarea execuției activității
➢ Metoda OnPause() este apelată atunci când o activitate diferită este lansată iar cea curentă
nu mai interacți onează cu utilizatorul.
➢ Metoda OnStop() este apelată atunci când activitatea nu mai e nici vizibilă și nici nu mai
interacționează cu utilizatorul
➢ Metoda OnDestroy() este apelată atunci când instanța unui obiect de tip Activity va fi
distrus. Înaite ca ace astă activitate să fie apelată, activitatea va fi încetat să fie vizibilă și să
interacționeze cu utilizatorul.

12

Fig. 2.3 Ciclul de viață al unei activități

➢ Fragments
Un fragment este o clasă reutilizabilă ce implementează o parte din activitate, putem
spune că este o sub -activitate. Un obiect de tip fragment definește deobicei o parte din
interfață, nu poate fi folosit de sine stătător ci doar în compoziția unei activități , după cum se
poate o bserva în figura 2.4 . [6]

Fig. 2.4 Fragmentarea unei activități

13

➢ Layout -uri
Un layout descrie structura interfeței utilizator, fiind asociat cu o anumită activitate. Toate
elemetele din layout sunt organizate în ierarhia obiectelor de tip View și ViewGroup conform
figurei 2.5 . Un View este un element pe care utilizatorul în poate vedea și cu care poate
interacționa pe parcursul utilizării aplicației. Un View Group este un container invizibil care
are rolul de a grupare. Obiectele de tip View sunt denumite și widget -uri: TextView, Loading
Bar, Buttons ,Recycler View, etc. [7]
Fig. 2.5 Ierarhia obiectelor de tip View

➢ Fișierul Android Manifest XML
Fișierul Manifest este considerat ca fiind rădăcina unei aplicației Android. Aici se găsesc
informații esențiale despre aplicație fără de care nu se poate rula codul sursă. Structura
fișierului Manifest este prezentată în fig. 2.6. Printre multe altele, f ișierul Manifest se ocupă
de următoarele:
✓ Dă numele pachetului Java, identificatorul unic al aplicației.
✓ Descrie componentele aplicației : activități, servicii, receptori de anunțuri. Aceste
declarații lasă sistemul să știe când să lanseze anumite compon ente
✓ Determină ce procese vor găzdui componentele aplicației
✓ Declară permisiuni pentru accesul în alte aplicații și resurse de sistem ale dispozitivului
✓ Declară nivelul minim Android API de care aplicația are nevoie pentru a rula.
✓ Conține lista librării lor pe care aplicația le folosește
✓ Pemite specificarea de meta dată cu privire la aplicație (teme folosite, iconițe) [8]

14

Fig. 2.6 Exemplu de fișier Android Manifest

➢ Resurse Android
Resursele sunt stocate în directorul /res din cadrul proiectului Android. O aplicație Android
necesită fișiere cu resurse, acestea fiind izolate de codul sursă pentru o mai bună lizibilitate a
codului. Aici regăsim colecția de fișiere audio,video,bitmap,animații și text. Separarea
resurselor permite dezvoltatorului să creeze interfețe utilizator adaptate la diferite configurații
de dispozitive.
➢ Adapters
Componentele de tip Adapter asigură legătura între componentele UI și sursa de date cu care
acestea vor fi populate. Un obiect de tip Adapter View, este după cum sugerează și numele un
obiect de tip View însă spre deosebire de al doilea, primul nu poate afișa date de unul singur.
Adaptorul asigură legătura între un obiect AdapterView și u n set de date (vectori, liste de
obiecte, obiecte de tip Cursor).

15

2.3. Android Studio
Android Studio este mediul de dezvoltare (IDE) oficial pentru sistemul de operare
Android, având ca fundație IntelliJ IDEA de la JetBrains, creat special pentru dezvoltarea de
aplicații Android. Este disponibil pentru sistemele de operate bazate pe Windows, macOS și
Linux. Înainte de Android Studio, Eclipse Android Development Tools (ADT) era mediul de
dezvoltare nativ pentru crearea de aplicații Android. Prima versiune stab ilă 1.0 a fost lansată
în decembrie 2014. Android Studio este gratuit sub licența Apache 2.0. [9]
Următoarele caracteristici sunt disponibile în vesiunea actuală (3.4.1) :
➢ Suport C/C++ și NDK
➢ Suport încorporat pentru Google Cloud Platform, permițând integr area tool -urilor de la
Google Firebase
➢ Android Virtual Device, un simulator ce permite testarea și depanarea codului sursă pe
mai multe dispozitive
➢ Sistem flexibil bazat pe Gradle
➢ Instrumente pentru măsurarea performanței, compatibilitatea versiunii
➢ Instrumente extinse pentru și cadre de lucru
➢ Template -uri pentru crearea instantanee de design -uri comune
➢ Suport pentru dezvoltarea de aplicații pentru Android Wear
➢ Template -uri cu cod sursă, integrare GitHub pentru importarea de cod sursă [9]
Structura unui proiect Android
Android Studio afișează fișierele proiectului în fereastra Android, fișierele nu sunt
organizate conform ierahiei de pe disk, ci sunt grupate în mai multe module pentru o navigare
mult mai facilă. Aceste module sunt vizibile în figura 2.7. În fiecare aplicație Android fișierele
sunt grupate astfel:
➢ manifests -conține fișierul AndroidManifest.xml
➢ java-conține f ișierele cu cod sursă Java, inclusid codul de testare JUnit
➢ res- conține toate celelalte fișiere care nu includ cod, layout -uri XML, imagini
bitmap, valori de tip string [10]

16
Fig. 2.7 Structura unui proiect î n Android Studio

17
2.4. Limbajul de programare Java
Java este un limbaj de programare dezvoltat de James Gosling de la Sun Microsystems
(acum filială Oracle), lansat în anul 1995 . Oracle oferă 4 platforme Java: Java Card, Java ME;
Java SE și Java EE. Platforma este alcătuită dintr -o mașină virtuală și un mediu de execuție.
Mașina virtuală este un procesor software ce vine cu un set de instrucțiuni, Java Virtual
Machine (JVM). Mediul de execuție constă în librării necesare pentru rularea programelor și
interacțiunea cu sistemul de operare, denumit și platforma nativă.
Compilatorul Java transformă codul sursă în cod obiect, acesta fiind alcătuit din
instrucțiuni este executat de mași na virtuală. Compilatorul stochează bytecode -ul programului
și informațiile în fișiere cu extensia .class. O componentă a mașinii virtuale , classloader,
încarcă fișierul clasă în memorie, se verifică validitatea bytecode -ului și securitatea . Ulterior
acest cod este interpretat instrucțiune cu instrucțiune, fiind executate instrucțiuni echivalente
native (instrucțiuni „înțelese” de procesorul fizic al platformei). [11]
Limbajul Java stă la baza aplicațiilor Android, în ciuda faptului că platforma Android
a fost dezvoltată pe nucleu Linux, în limbaj C. Android SDK folosește propria mașină virtuală
(fie DVM sau ART în funcție de versiune ) pentru executarea bytecode -ului.
Java a fost o alegere evidentă pentru platforma Android, fiind un limbaj puternic tip izat,
orientat -obiect, gratis și open -source. Limbajul Java permite dezvoltarea de aplicații care pot
rula fără probleme pe o varietate de dispozitive fără a folosi cod specific platformei. [ 12]
Putem da multe motive pentru care Android folosește limbajul de programare Java, pe
lângă popularitatea limbajului s-a luat în calcul numărul mare de telefoane mobile ce foloseau
deja Java Me (Java MicroEdition). Prin rularea tuturor aplicațiilor în mașină virtuală este
asigurată securitatea sistemului, nici o apli cație nu poate exploata nucleul sistemului de
operare. Având în vedere că Android rulează pe o gamă largă de platforme hardware, faptul că
nu este nevoie ca o aplicație să fie rulată și optimizată la nivel de cod nativ pentru fiecare nouă
configurație de d ispozitiv reprezintă un real avantaj. Nu în ultimul rând, limbajul Java pune la
dispoziție un suport imens open -source, cu multe librării și tool -uri disponibile facilitând astfel
munca dezvoltatorilor.

18
2.5. Baza de date Google Firebase
Firebase este o platfor mă ce oferă suport back -end pentru aplicații mobile și web, creată
de Firebase Inc. în 2011 , asimilată ulterior de Google în 2014. În octombrie 2018, platforma
Firebase era utilizată de 1.5 milioane de aplicații, punând la dispoziție 18 servicii. Există două
categorii de servicii „Grow” și „Develop” ilustrate în figura 2.8. [13]

Firebase Realtime Database este o bază de date NoSQL cloud -hosted care permite
stocarea de date și sincronizarea datelor în timp real. Baza de date Realtime Database se rezumă
la un obiect de tip J SON pe care dezvoltatorul îl poate manipula în funcție de nevoie.
Sincronizarea în timp real asigură facilitate în accesarea datelor, fie de pe mobil sau web. În
lipsa conexiunii la Internet, SDK -ul Realtime Database se folosește de memoria cache locală
pentru a stoca temporar noile modificări aduse bazei de date. [14]
Firebase Authentication asigură servicii backend, SDK -uri ușor de folosit și librării UI
pentru autentificarea utilizatorilor în aplicație. Autentificare se poate face prin mai multe
metode: email & parolă, număr de telefon, cont de Google/Facebook/Twitter. Utilizarea
serviciului Firebase Authentication face întreg procesul de autentificare ușor de realizat și
sigur.
Firebase Cloud Messaging (FCM) pune la dispoziție o conexiune stabilă între s erver și
dispozitiv ce permite expedierea și primirea de mesaje și notificări pe Android, iOS și web. Pot
Fig. 2.8 Produse și servicii Firebase

19
fi trimise mesaje de notificare de maxim 2KB. FCM poate livra mesaje instant sau la un anumit
moment în viitor în funcție de ora locală a utilizatorul ui.
Firebase Storage asigură încărcarea și descărcarea de fișere necesare aplicației în
condiții de securitate, indiferent de calitatea conexiunii la Internet. Dezvoltatorul poate folosi
acest serviciu pentru stocarea de imagini, materiale audio/video sau alt conținut generat de
utilizator. Firebase Storage are ca backup Google Cloud Storage.
Firebase Hosting este un serviciu de hosting web static și dinamic ce asigură stocarea
de fișere CSS, HTML, JavaScript. Transferul fișerelor se realizează prin protoc ol de securitate
HTTP Secure și criptare SSL (Secure Sockets Layer) .
Firebase Analytics este o unealtă gratuită pentru monitorizarea interacțiunii
utilizatorilor , punând la dispoziție înregistrarea nelimitată a până la 500 de evenimente diferite.
O astfel de unealtă este vitală în dezvoltarea unei aplicații, o bună înțelegere a utilizatorului
ajută dezvoltatorul să ia decizii corecte pentru optimizarea aplicației .
ML Kit este un sistem de învățare automată „Machine Learning” pus la dispoziție
dezvolt atorilor Android și iOS , ce include text recognition, detectarea facială, scanarea
barcode -urilor. API -ul poate folosit fie pe dispozitiv , fie în cloud.
Crash Reporting creează rapoarte detaliate a erorilor din aplicație. Pe lângă rapoartele
automate, d eveloper -ul poate urmări anumite evenimente pentru a descoperi pas cu pas sursa
erorii. Firebase Test Lab pentru Android și iOS oferă infrastructură cloud -based pentru testarea
aplicațiilor. Dezvoltatorii pot iniția testare pe aplicațiile lor pe o gama lar gă de dispozitive și
configurații .[14]
Acestea fiind spuse Firebase este o platformă de dezvoltare ce pune la dispoziție o
multitudine de unelte și servicii pentru realizarea de aplicații de calitate înaltă și creșterea
numărului de utilizatori .

20
Capitolul 3. Aplica ții asemănătoare
3.1. Booxup

Booxup este o aplicație mobilă lansată în martie 2015 la Târgul de carte de la Paris,
creată de David Mennesson, Robin Sappe și Cheng Huang. Aplicația necesită versiune iOS 9.3
sau mai recentă și este compatibilă cu iPhone, iPad și iPod touch. Interfața aplicației este
vizibilă în figura 3.1. [15]
Aplicație este de fapt un magazin online pentru oamenii pasionați de citit ce vor să
cumpere cărți la prețuri rezonabile d irect de la proprietar. Cărțile se găsesc aici la prețuri sub
prețul pieței, iar unele dintre ele sunt chiar gratuite. Evident poți la rândul tău să îți pui cărțile
la vânzare. Pe Booxup poți găsi toate genurile de cărți de la Thrill er la Horror, ghiduri de
călătorie, cărți pentru copii și cărți de specialitate.
Te poți loga cu contul de Email, Facebook sau Twitter, scanezi codul de bare al cărții,
stabilești prețul și aștepți clientul interesat. Booxup este o aplicație bogată în func ționalități,
punând la dispoziție chat, filtre pentru cărți, posibilitatea de asociere cu alți utilizatori în grupuri
și multe altele.

Fig. 3.1 Aplicație mobilă Booxup

21

3.2. Bookup

Fig. 3.2 Aplicație mobilă Bookup
Bookup este o aplicație gratui tă lansată în 2018, disponibilă pentru versiuni mai noi de
8.0 iOS, compatibilă cu iPhone, iPad și iPod touch, în limba engleză, franceză și portugheză.
Intefața aplicației este vizibilă în figura 3.2. [16]
Se prezintă ca o aplicație pentru cititorii ce v or să fac schimb de cărți printate în arealul
lor, fără costuri și de ce nu să își facă un nou prieten cu aceleași interese literare. Dacă nu mai
ai loc în bibliotecă sau vrei să scapi de o anume carte poți să îi cauți un nou proprietar prin
intermediul ac estei aplicații. La rândul tău vei primi o carte în schimb și astfel toată lumea are
de câștigat.
Oferă funcționalita te de localizare locală . După ce îți faci cont poți adăuga cărți în
biblioteca personală și poți începe căutarea de cărți din bibliotecile puse la dispoziție de ceilalți
utilizatori în arealul tău.
Funcția de chat în timp real asigură comunicarea între utilizatori necesară pentru
stabilirea locului de întâlnire pentru schimbul de cărți. O altă caracteristică a aplicației este
prezența notif icărilor de tip push, care anunță disponibilitatea cărții de care ești interesat. []

22
Capitolul 4. Specificațiile aplicației
4.1. Analiza cerințelor
Scopul acestei lucrări este dezvoltarea unei aplicații Android prin intermediul căreia
pasionați de literatură să își poată împrumuta cărți în format fizic. Este nevoie de o aplicație
ușor de utilizat, plăcută din punct de vedere al design -ului interfeței și intuitivă.
În cadrul aplicației, utilizatorul, odată logat va putea :
➢ Să își creeze un profil cu date personale
➢ Să adauge cărți în biblioteca personală
➢ Să șteargă o carte din biblioteca personală
➢ Să acceseze cărțile înregistrate de alți utilizatori
➢ Să ceară o carte în împrumut
➢ Să gestioneze cereri de împrumut primite (accept/delete)
➢ Să poată vizualiza pr ofilul altor utilizatori

4.2. Proiectarea soluției
Am optat pentru o aplicație mobilă deoarece în zilele noastre telefonul mobil e ste
indispensabil, oamenii preferă să își folosească smartphone -ul pentru o sarcină simplă în loc să
deschidă un laptop. Astfel aplicația poate fi accesată oricând oriunde atâta timp cât sistemul de
operare și versiunea de Android o permite și există o conexiune la Internet. Android este de
departe cel mai popular sistem de operare pentru telefoane mobile , conform statisticilor de la
statCounter Global Stats.
Arhitectura aplicației se bazează pe mai multe obiecte de tip Activity, se lansează una
din alta prin obiecte de tip Intent . Deschiderea unei noi activități este declanșată de o anumită
acțiune a utilizatorului, fie click pe i magine, pe butoane sau text în funcție de context. De
asemenea în implementare au fost utilizate clase de tip Adapter, în afișarea cărților și a cererilor
de împrumut. Pentru stocarea datelor despre utilizatori, despre cărți și stocarea imaginilor
încărcat e de aceștia am optat pentru tool -ul pus la dispoziție de Google, Firebase. Această
platformă fiind una ușor de folosit și bogată în funcționalități.

23
4.3. Schema de utilizare a aplicației

4.4. Funcțiile sistemului
Autentificare
Orice aplicație are o activitate principală, în cazul de față clasa LoginActivity
îndeplinește acest rol fiind prima activitate care apare pe ecran atunci când aplicația este lansată
în execuție. Pentru o activitate se poate specifica și un filtru de intenții ( acest lucru se face în
fișierul Manifest), acesta indică modul în care componentele aplicației o pot accesa. Așadar
Fig. 4.1 Schema de utilizare a aplicației

24
pentru clasa LoginActivity acțiun ea are valoarea android.intent.action.MAIN deoarece
reprezintă punctul de intrare în aplicație, iar categoria are valoarea
android.intent.category.LAUNCHER deoarece activitatea trebuie inclusă în meniul
dispozitivului mobil pentru a putea fi lansată în ex ecuție.
În cadrul acestei activități se verifică dacă email -ul și parola corespund unui utilizator
înregistrat în baza de date asociată proiectului. Acest procedeu se realizează cu ajutorul
bibliotecii FirebaseAuth . Procesul de autentificare este ilustr at în figura 4.2 . Bineînțeles, acest
lucru se întâmplă după verificarea căsuțelor de text (obiecte EditTextView) pentru a ne asigura
că atât email -ul cât și parola au fost introduse. Utilizatorul va fi notificat prin mesaje de tip
toast cu privire la evolu ția procesului de autentificare ( de exemplu „Please enter email…” ,
„Login failed. Please try later” , „Login succesful”). Dacă autentificare are loc cu succes este
lansată activitatea ProfileActivity printr -un obiect de tip Intent declanșat la apăsare a butonului
„Autentificare”.
În cazul în care utilizatorul nu are cont încă pe aplicație acesta va fi condus la activitatea
de înregistrare prin simpla apăsare pe obiectul TextView din partea de jos a layout -ului („Nu
ai cont? Înregitrare”).

Înregistrare
Fig. 4.2 Diagramă Autentificare User

Clasa RegisterActivity.class poate fi accesată doar din cadrul activității de logare.
Layout -ul acestei activității constă din mai multe obiecte de tip EditTextView ( cu următoarele
hint-uri „Nume”, „E -mail”, „ Parolă ”, „Confirmă parola”), pe care utilizatorul este nevoit să le
completeze pentru înregistrarea în baza de date a utilizatorilor. Din nou acesta va fi notificat în
cazul în care unul dintre câmpuri nu este completat sau cele două parole tastate nu corespund).

25
Userul poate de asemenea să își seteze fotografia de profil prin click pe un obiect ImageView
prezent în partea superioară a layout -ului.
În metoda onCreate() a clasei RegisterActivity se setează layout -ul activității prin
instrucțiunea setContentView(R.layout.activity_register), se face legătură între obiectele de tip
View locale și cele prezente în layout. Atunci când avatarul general din interfață este apăsat se
cere permisiunea pent ru a accesa galeria foto a dispozitivului. După ce utilizatorul acordă
permisiunea aplicației și selectează o imagine din galerie, aceasta apare în locul avatarului
inițial.
După apăsarea butonului „Înregistrare” se creează contul user -ului și este lansa tă în
execuție activitatea EditProfileActivity.class. Crearea unui cont nou se realizeză cu metode din
librăriile FirebaseAuth și FirebaseUser. Fiecărui user nou înregistrat îi este asignat un cod unic
UID. Imaginea de profil este stocată în FirebaseStorag e în nodul „users_photos/”. Ca și în
cadrul activității de logare există un hyperlink care îl conduce pe utilizator înapoi la activitatea
de logare în cazul în care acesta are cont deja.
Fig. 4.3 Diagramă activitate Înregistrare User

Editare profil
În acest punct al aplicației, EditProfileActivity.class, se ajunge după ce utilizatorul s -a
înregistrat cu succes în aplicație. Layout -ul conține trei obiecte de tip Edi tText View, pentru
adăugarea de informații de suplimentare despre utilizator (nume, oraș și o scurtă descriere).
În metoda onCreate() a activității se va seta layout -ul activității, se vor inițializa
obiectele de tip View. Butonul „Salvează” implementeaz ă o metodă setOnClickListener prin
care se apelează o funcție numită SaveData(), în cadrul acesteia se creează un obiect de tip
User.class cu datele preluate de la utilizator. Se face referință la baza de date Firebase Database
asociată proiectului Android și se salvează instanța obiectului User. Aici ne vom folosi de UID –
ul asignat la înregistrare. Diagrama activității este ilustrată în figura 4.4.

26

Fig. 4.4 Diagramă activitate Editare Profil

Profil ul utilizatorului logat
Activitatea ProfileActivity.class poate fi considerată pagina de „acasă” al aplicației, de
aici utilizatorul poate să adauge cărțile prin apăsarea butonului „Adaugă carte” ce lansează
activitatea AddBookActivity.class printr -un obiec t de tip Intent sau poate să facă update la
informațiile despre el însuși prin apăsarea butonului „Editează profil”.
Sunt afișate informațiile despre userul logat: nume, oraș, adresă de email, fotografia de
profil și descrierea. Cu ajutorul unei instanțe FirebaseAuth aflăm UID -ul utilizatorului logat,
iar pe baza acetuia facem o referință la baza de date pentru a extrage instanța obiectului User
asociată cu acest id. Acest lucru este posibil cu ajutorul unui DataSnapshot, o captură a bazei
de date. Pentru recuperarea datelor este nevoie de crearea unei instanțe de tip User, care este
„încărcată” cu informațiile corespunzătoare prin metoda .getvalue().
Este utilizat un obiect de tip RecyclerView cu un layout vertical pentru afișarea cărților
puse la dispoz iție pentru împrumuturi. Acest RecyclerView este gestionat de clasa
RecyclerViewAdapter. Pentru a recupera informațiile despre cărțile utilizatorului logat vom
face din nou o referință la baza de date, de această dată vom accesa nodul books/uid/….. . Vor
fi memorate doar titlurile și link -ul de unde pot fi descărcate imaginile cărților în două obiecte
de tip ArrayList(), mNames și mImageUrls. Acești doi vectori sunt necesari pentru apelarea
constructorului de tip Adapter.
Pentru navigarea în cadrul aplic ației se poate folosi bara de navigare din partea de jos a
ecranului , cât și butonul de „Înapoi” din bara de navigare a dispozitivului .

Adaugă carte
Această activitate poate fi lansată doar din profilul utilizatorul prin apăsarea butonului
corespunzător. Layout -ul conține mai multe căsuțe de text EditTextView , un obiect de tip
Image View și două butoane, „Renunță” și „Salvează”. În cadrul metodei onCr eate() se

27
inițializează obiectele de tip View cu datele completate de utilizator prin intermediul interfeței.
Butonul „Renunță” redirecționează utilizatorul la activitatea Profile printr -un obiect de tip
Intent, datele completate nu sunt se salvează. La c lick pe ImageView -ul prezent se va cere din
nou accesul pentru galeria foto a dispozitivului. Imaginea aleasă de utilizator este salvată în
referința la FirebaseStorage . Link -ul de unde se poate descărca imaginea este salvat pentru a fi
memorat în baza de date.
Se vor face două referințe la baza de date. Prin prima vom accesa nodul „books” unde
vom stoca instanța obiectului Book.class, cărțile fiind memorate în nodul dat de UID -ul
userului curent. De asemenea vom memora titlul în nodul „connections”, prin asocierea titlului
unei cărți cu UID -ul userului facilităm accesul la baza de date în utilizările viitoare. Aceste
acțiuni vor avea loc după apăsarea butonului „Salvează”.

Fig. 4.5 Diagramă activitate Adaugă Carte

Vizualizarea listei de cărți
Această secțiune a aplicației poate fi accesată din bara de navigare. SearchActivity.class
se ocupă de afișarea tuturor cărților înregistrate în baza de date cu ajutorul unui obiect de tip
Adapter. Se face o referință la nodul „books” Firebase Database și se memorează într -un vector
de obiecte informațiile despre fiecare carte înregistrată în aplicație. Acest vector este ulterior
transmis ca parametru în constructorul obiectului de tip SearchAdapter. Cărțile v or fi afișate
sub forma unei liste de CardView -uri, acestea conțin titlul,autorul,imaginea cu cartea și un
hyperlink ce conduce utilizatorului la prezentarea integrală a cărții.
Gestionarea cererilor
MessagesActivity.class poate fi lansată doar din bara d e navigare. Layout -ul este
structurat pe baza unui obiect de tip RecyclerView, ce conține obiecte de tip CardView. Fiecare
CardView va conține textul mesajul și două butoane ( „Acceptă”, „Șterge”) prin intermediul
cărora utilizatorului gestionează cererea. Cererile trimise în cadrul aplicației sunt texte

28
prestabilite („ X dorește să împrumute cartea Y”). Se face referință la nodul „messages/UID
utilizator curent” pentru a descărca mesajele în obiecte de tip String care sunt ulterior salvate
într-un vector c e este folosit ca parametru în constructorul obiectului de tip Adapter.
Clasa MessagesAdapter populează obiectul RecyclerView din interfața activității, mai
mult decât atât declară metode pentru widget -uri. Butonul „Acceptă” implementează metodă
setOnCl ickListener(), în cadrul acesteia se face referință la baza de date pentru a înregistra
împrumutul în nodul „loans” și pentru a ștege cererea. În metoda setOnClickListener() pentru
butonul „Șterge” se elimină cererea din nodul „requests” al bazei de date.
Profilul cărții
Prin intermediul clasei BookActivity.class se poate vizualiza profilul unei cărți. Această
activitate este lansată fie din SearchActivity.class fie din profilurile utilizatorilor prin click -ul
asupra imaginii unei cărți, în ambele cazuri este trimis titlul cărții de la o activitate la alta prin
metoda putExtra().
Odată recuperat stringul cu ajutorul metodei getExtra() facem o referință la nodul
„connections” din baza de date pentru a căuta UID -ul proprietarului, această operație este
necesară pentru facilitarea parcurgerii nodului „books” ( mult mai bogat în nivelu ri,
books/uid/title/Book object) . Ulterior accesăm baza de date încă o date pentru a recupera
instanța obiectului Book care conține toate informațiile necesare (titlu, autor,url -ul
imaginii ,anul publicării, descrierea). Vom afișa datele prin intermediul o biectelor View din
layout -ul activității, imaginea este încărcată cu ajutorul librăriei Glide.
În funcție de statutul user -ului acesta poate vedea și interacționa cu anumite widget -uri.
Avem trei scenarii :
➢ Dacă titlul afișat este deținut de utilizatorul logat va fi vizibil doar butonul de ștergere
al cărții. La acționarea acestuia în cadrul metodei setOnClickListener () se va face
referință la baza de date și se va înlătura instanța cărții respective
ref.child( "books" ).child( book_owner ).child (titlu).removeValue();
➢ Dacă titlul afișat nu este deținut de utilizatorul logat va fi afișată disponibilitatea cărții ,
fie mesajul „Cartea este indisponibilă” fie butonul prin care cartea poate fi cerută pentru
împrumut. Baza de date va fi accesată pentru a se verifica disponibilitatea cărții. Butonul
implementează o metodă setOnClickListener prin care se „trimite” un mesaj la
proprietarul cărții. Mesajul nu este trimis în mod direct, ci salvat în nodul „messages”

29
din ba za de date sub ID -ul proprietarului , ca mai apoi să îi fie lui/ei afișat în activitatea
MessagesActivity. De asemenea va fi salvată în baza de date în nodul „Reguests” sub
forma titlu -uid
➢ Dacă titlul afișat este momentan împrumutat de utilizatorul logat a cestuia îi este vizibil
butonul „Predă cartea”, odată apăsat se execută o referință la baza de date și se modifică
statusul de disponibilitate al cărții respective.
Statusul este stabilit prin verificarea id -ului, se verifică dacă UID -ul utilizatorului logat este
identic cu cel al proprietarului cărții prin referință la nodul „connections” sau dacă este identic
cu cel din nodul „loans” (unde se ține evidența împrumutu rilor). Cele trei scenarii sunt ilustrate
în figura 4. 6.
Fig. 4.6 Diagramă Șterge/Împrumură/Returnează cartea

4.5. Structura bazei de date

În cadrul proiect au fost utilizare servicii oferite de platforma Google Firebase, mai
exact FirebaseAuth, Firebase Database și Firebase Storage.
Firebase Authentication oferă servicii de backend, SDK -uri ușor de folosi și librării
integrate de UI pentru autentificarea utilizatorilor în aplicație. Utilizatori înregistrați prin
Firebase au un set de proprietății: un id unic, o adresă de e -mail primară și adresa unde se află
fotografia de profil. Toate aceste informații sunt stocate în baza de date a utiliza torilor asociată
cu aplicația. Utilizatori autentificați în aplicație pot fi vizualizați (conform figurei 4.2) în
consola Firebase pe care a fost configurat proiectul.

30
Firebase Realtime Database este o baza de date stocată în cloud. Datele sunt salvate în
format JSON și sincronizate în timp real pentru fiecare client conectat. Folosind Firebase,
datele aplicației rămân stocate la nivel local în lipsa conexiunii la Internet. Când conexiunea
este reluată, clientul primește orice modificare adusă bază de da te și se sincronizează cu
serverul.
Fig. 4.7 Consola Firebase Authentication

Baza de date asociată proiectului are mai multe noduri principale create pentru a accesa
cu ușurință informațiile în funcție de cont ext. Acestea sunt următoarele:
➢ Nodul „users” are forma tul users/id user/obiect de tip User, cu câmpurile ce conțin numele,
orașul, adresa de e -mail,descrierea și URL -ul fotografiei de profil. Se face referință la acest
nod în cadrul activităților care afișează profilul unui utilizator (fie cel al utilizatorului logat,
fie al unui alt utilizator înregistrat în aplicație). Structura se poate observa în figura 4. 8.

➢ Nodul „books” este structurat sub forma books/id_owner/titlu/obiect de tip Book, cu
câmpurile: autor, disponibilitate, descriere, URL -ul cu imaginea cărții, id -ul proprietarului,
anul publi cării și titlul. În cadrul codului sursă se face referință la acest nod de fiecar e dată
când se afișează informații despre o carte, când se adaugă/șterge o carte sau când se
modifică disponibilitatea unei cărți. Structura se poate observa în figura 4. 9.

31

Fig. 4.8 Structura nodului „users”

Fig. 4.9 Structura nodului „books”
➢ Nodul „connections ” (extins în figura 4.10) a fost creat din motive practice, deseori în
cadrul aplicației e nevoie de legătura dintre proprietar și carte. Nodurile „users” și „books”
sunt mult mai bogate în structură, implicit mai greu de parcurs/ de iterat , din acest motiv
am utilizat acest nod pentru a accesa cu ușurință relația titlu -id_proprietar.

32

Fig. 4.10 Structura nodului „connections”

➢ Nodurile „loans” (împrumuturi) și „requests”( cereri ) gestionează procesul de împrumut al
unei cărți. Atunci când un utilizator cere o carte în împrumut, în nodul de cereri se va
înregistra a cest lucru sub forma titlu: id -ul utilizatorului. Dacă proprietarul cărții acceptă
cererea, se va înregistra acest lucru în nodul de împrumuturi, iar cererea este eliminată din
baza de date. Dacă proprietarul cărții nu acceptă, înregistrarea cu cererea est e eliminată.
Structura nodurilor este ilustrată în figura 4.11.
Fig. 4.11 Structura nodurilor „loans” și „requests”

33

Fig. 4.12 Structura nodului „messages”

➢ În nodul „messages” (mesaje) se vor înregistra cererile de împrumut pe care le vor primi
proprietari de cărți, acestea sunt string -uri de forma „ X dorește să împrumute cartea Y”.
Se face referință la acest nod pentru afișarea cererilor în activitatea Messages Activity.
Structura nodului este messages/id propritar carte/ mesaj: timpul la care a fost trimis
mesajul, după cum se poate observa în figura 4. 12.

34
4.6. Utilizarea aplicației
Autentificare și înregistrare

În mod firesc, utilizatorul este întâmpinat cu fereastra de Autentificare , ilustrată în
figura 4. 13. Procesul de autentificare se realizează prin email și parolă , fiind una dintre cele
mai tipice metode. În cazul în care utilizatorul nu are cont acesta po ate face click pe hyperlinkul
din partea de jos a ecranului, urmând să fie direcționat spre fereastra de înregistrare.
În ferestra de înregistrare (vizibilă în figura 4. 14) utilizatorul trebui să completeze toate
câmpurile pentru a se înregistra în baza de date. Prin apăsarea iconiței din partea superioară a
ferestrei acesta poate adăuga o fotografie de profil, însă abia după ce permite aplicației să
acceseze galeria foto a dispozitivului.
Vor fi afișate notificări de tip Toast prin care utilizatorul primește anunțuri cu privire la
evoluția procesului de autentificare/înregistrare ( „Login successful!”, „Login failed! Try
again”) dar și în cazul în care nu sunt completate toate câmpurile sau parolele nu corespund.
După ce procesul de înregistrare este finalizat cu success utilizatorul este direcționat
spre o fereastră de editare a profilului (ilustrată în g oferind informații suplimentare precum
Fig. 4.13 Fereastra
Autentificare Fig. 4.14 Fereastra
Înregistrare

35
numele, orașul și o scurtă descriere. Atât du pă autentificare cât și după salvarea datelor din
cadrul ferestrei „Editare profil” , vizibilă în figura 4.15, user-ul este condus spre pagina lui de
profil.
Profilul utilizatorului
Din acest punct al aplicație utilizatorul este liber să navigheze în celelalte secțiuni din
structura aplicației cu ajutorul barei de navigare (aceasta se poate observa în figura 4. 16).
Utilizatorul poate adăuga acum cărți în biblioteca personală (click pe butonul „Adaugă carte”
din profil”) , poate să își actua lizeze informațiile din profil (click pe butonul „Editează profil”) .
De asemenea are acces direct la cărțile din biblioteca personală, la click pe imaginea unei cărții
se va deschide profilul cărții și utilizatorul o poate șterge din baza de date .
Din bar a de navigare userul poate să ajungă la fereastra care prezintă toate cărțile
înregistrate în sistem, la secțiunea mesaje sau se poate deconecta (se ajunge din nou la fereastra
de autentificare) . User -ul știe în orice moment în ce secțiunii a aplicației s e află, după cum se
poate observa în figura 4. 16 , iconița Profil din bara de navigare este pusă în evidență.

Fig. 4.15 Fereastra Editare
Profil
Fig. 4.16 Fereastră Profil utilizator
logat

36
Adăugarea cărților și ștergerea cărților
Pentru a adăuga o carte tot ce trebuie să facă utilizatorul este să dea click pe butonul
corespunzător din pagina sa de profil care va deschide fereastra ce îndeplinește acest rol.
Ulterior trebuie completate toate căsuțele de text din cadrul ferestrei „Adaugă carte” cu
informațiile despe carte (titlu, autor,anul publicării, descriere) și selectată o imagine cu coperta
cărții din galeria foto (conform figurii 4. 18). Odată acționat butonul „Salvare” datele sunt
înregistrate în baza de date iar procesul este finalizat. Butonul „Renunță” îl duce pe utilizator
înapoi la profil, datele completate nu se salvează nicăieri. Cartea adăugat ă va apărea în scurt
timp în lista de titluri din profil.
Pentru a șterge o carte din colecția personală utilizatorul trebuie să acceseze profilul
cărții respective ( de exemplu fereastra din fig. 4.17) , acest lucru se poate face fie din profilul
personal fie din ferestra ce afișează lista integrală a cărților din sistem. Odată ajuns în fereastra
cu profilul cărții tot ce trebuie să facă user -ul este să acționeze butonul „Șterge carte” iar
informațiile despre cartea respectivă vor fi înlăturate din baza de date.

Fig. 4.17 Fereastră Adaugă
carte Fig. 4.18 Fereastră carte
personală

37
Vizualizarea cărților înregistrate în aplicație
Această secțiune poate fi accesată de utilizator din bara de navigare. Utilizatorul poate
vedea aici întreaga listă de cărți (interfața este ilustrată în figura 4. 19), la click pe hyperlink -ul
„Vezi mai multe detalii” acesta va fi redirecționat spre profilul cărții. Un profil de ca rte arată
în principal comform figurii , butoanele afișate variază în funcție de disponibilitatea cărții și de
statutul user -ului ( proprietarul cărții/utilizatorul care a împrumutat cartea).
Pentru împrumutarea cărții se va click pe butonul „Împrumută ca rtea” (acesta se poate
vedea în figura 4. 21), butonul nu va fi vizibil în cazul în care aceasta este indisponibilă. Atunci
când un utilizator dorește să predea o carte, trebuie apăsat butonul „ Returnează cartea ”(vizibil
în figura 4. 20) din profilul cărții respectiv.
Din profilul unei cărții se poate ajunge la profilul proprietarului prin click pe hypelink –
ul „Vezi profil proprietar”. Profilul proprietarului e o fereastră pur informativă, design -ul
interfeței este aproape identic cu cel al propri ului profil, lipsind doar butoanele pentru
adăugarea de cărți și editarea profilului.

Fig. 4.19 Fereastra Vizualizare
cărți Fig. 4.20 Fereastră profil carte
(1) Fig. 4.21 Fere astră profil
carte(2)

38
Gestionarea cererilor
Utilizatorul poate să accese „căsuța de mesaje” din bara de navigare . Aici va primi
cereri de la alți utizatori, pentru fiecare cerere vor fi două butoane (conform figurii 4. 22). La
click pe butonul „Acceptă” cartea va apărea ca indisponibilă în sistem, din moment ce cineva
a împrumutat -o. La click pe butonul „Șterge” va fi șters doar mesajul/cererea.
În cazul în c are utilizatorul nu a primit nici o cerere, lista va apărea goală și va fi afișată
o notificare de tip Toast „Nu există mesaje”.

Fig. 4.22 Fereastra Mesaje + layout mesaj

39
4.7. Testarea aplicației pe alte dispozitive
Pe parcusul procesului de dezvoltare al aplicației aceasta a fost rulată în repetate rânduri
pe telefonul mobil Huawei Mate 20 Lite, versiune Android 8.1 Oreo , rezoluție 2340×1080 .
Ulterior aplicația a mai fost testată prin intermediul unui emulator de dispozitive online pe
tableta Google Nexus 7 (versiune Android 7.1, rezoluție 1280×800) și telefonul mobil
LiquidZ530 (versiune An droid 5.1.0, rezoluție 720×1280). În ambele cazuri , ilustrate în figura
4.23 și figura 4.24, nu s-au sesizat probleme în ceea ce privește funcționalitatea aplicației, însă
putem sesiza schimbări la nivelul interfeței .

Fig. 4.24 Testare aplicație – Nexus 7

Fig. 4.23 Testare aplicație -Acer
LiquidZ530

40
Capitolul 5. Concluzii
Aplicația prezentată în cadrul acestei lucrări poate fi considerată o fundație pe care se
poate construi mult mai mult. Am reușit să implementez cu succes funcții de bază precum
autentificare a/logarea utilizatorului, adăugarea/modificarea/ștergerea informațiilor din baza de
date și crearea unei interfețe utilizator plăcute și ușor de folosit. Interfața aplicației este
consistentă, proiectată estetic și minimalist , oferind flexibil itate și eficință în utilizare.
Scopul meu a fost acela de a crea o aplicație mobilă prin care oamenii să își poată
împrumuta cărți reciproc. Consider că mi -am îndeplinit scopul, întrucât am reușit să
implementez funcțiile vitale ale aplicației: crearea c ontului de utilizator, crearea unui profil cu
informații, adăugarea cărților în sistem și gestionarea cererilor de împrumut.
După cum am spus deja, aplicația poate fi considerată doar o bază pentru o astfel de
platformă de „socializare”. Se pot adăuga mul te alte funcționalități dintre care țin să vorbesc
despre următoarele. Aplicația are nevoie de o messagerie de tip chat print intermediul căreia
utilizatorii pot stabili timpul și locul întâlnirii pentru ca împrumutul să aibă loc sau pot discuta
orice altc eva între ei fără a fi nevoiți să apeleze la mijloace de comunicare externe aplicației
(e-mail, Facebook, apel telefonic).
Să ne gândim la scenariul în care un utilizator dorește să adauge în colecția personală
din profilul creat în aplicație 20 -30 de cărți, sarcina ar putea mult mai ușor de îndeplinit prin
simpla scanare a codului ISBN de pe cărți în loc de inserarea manuală a tuturor informațiilor,
fotografierea fiecărei cărți în parte. ISBN (Număr Internațional Standartizat pentru Carte) este
un identificator numeric pentru identificarea comercială a cărților.
Pentru a crește ușurința de utilizare a aplicației ar trebui implementate filtre pentru cărți,
acestea putând fi sortate pe autori, pe genuri literare, pe perioade. Dacă aplicația ar fi pu să în
utilizare s -ar aduna un număr colosal de cărți, din acest motiv navigarea trebuie să fie facilă.

41
Bibliografie

[1] https://www.javatpoint.com/android -history -and-versions
[2] https://en.wikipedia.org/wiki/Open_Handset_Alliance
[3] https://developer.android.com/guide/platform
[4] https://www.wideskills.com/android/overview -android/principal -ingredients -android
[5] https://www.tutorialspoint.com/android/android_services.htm
[6] https://guides.codepath. com/android/creating -and-using -fragments
[7] https://developer.android.com/guide/topics/ui/declaring -layout
[8]https://stuff.mit.edu/afs/sipb/project/android/docs/guide/topics/manifest/manifest –
intro.html
[9] https://en.wikipedia.org/wiki/Android_Studio
[10] https://developer.android.com/studio/projects
[11] Jeff Friesen (2010) Learn Java for Android Development , Apress
[12]Paul Deitel, Harvey Deitel, Abbey Deitel (2013) Android: How to program, Deitel
[13] https://en.wikipedia.org/wiki/Firebase
[14] https://hackernoon.com/introduction -to-firebase -218a23186cd7
[15] http://www.booxup.com
[16]https://apps.apple.com/us/app/bookup -hookups -for-books/id1104416604#?platform=ipad