Programarea In Java
INTRODUCERE
Aplicațiainformatică cu citire de coduri QR pentru bibliotecă este o aplicație pentru Android cu scopul de a mări viteza procesului de împrumutare și returnare. Până în momentul de față, bibliotecile mici sau tradiționale folosesc calculatorul doar ca mediu de stocare a titlurilor și eventual a cititorilor. Procesul de împrumut și returnare se face pe baza unui permis, doar pe suport de hârtie, cititorul fiind nevoit să semneze când împrumută. Adesea la returnare, găsirea fișei cititorului necesită timp, și pe lângă acești timpi morți se mai adaugă și zecile de secunde când bibliotecarul este nevoit să transcrie personal anumite date despre cărțile împrumutate. Așadar, tot acest proces este consumator de timp, mai ales când este aglomerație, provocând nemulțumiri și stres în ambele tabere – cititorul și bibliotecarul.
Această aplicație am creat-o cu scopul de a facilita aceste activități în bibliotecă, și pentru a oferi bibliotecarului o mai mare eficiență. Bibliotecarul poate folosi aplicația atât pe tabletă cât și pe smartphone, dar și pe desktop, pentru persoanele mai tradiționale. Soluția dezvoltată are două mari componente: o interfață cititoare de coduri QR – aplicație Android, ce necesită doar un permis al cititorului cu un cod QR unic și o carte cu un cod QR unic, respectiv o aplicație web de gestiune a cărților din bibliotecă. Prin aplicația Android, se scanează permisul, cartea și printr-un click, bibliotecarul decide ce operație se desfășoară: Borrow (Împrumut) sau Return (Returnare). Și astfel, tot procesul se încheie în câteva zeci de secunde. Aplicația web de gestiune prezintă însă un control mai mare de gestiune. Aici bibliotecarul are posibilitatea să adauge cărți, cititori, edituri, autori, să desfășoare activități de împrumut și returnare, să vadă titlurile împrumutate în prezent, să afle cititorii care au depășit data limită de returnare, să vadă câte cărți și ce fel de cărți a împrumutat un anumit cititor.
CAPITOLUL 1
Programarea în Java
1.1 Istoric și caracteristici
Java este un limbaj de programare orientat obiect, ce poate fi pus alături de C++, C#, Perl, Ruby, Delphi, Python, PHP. Conform TIOBE Index, limbajul Java este considerat cel mai popular limbaj de programare anul acesta.
O echipă formată în 1991 în principal din James Gosling, Mike Sheridan și Patrick Naughton, aceștia din urmă alăturându-se mai târziu, au dezvoltat un nou limbaj de programare numit Java după boabele de cafea din insula indoneziană Java. După patru ani de lucru, limabjul Java este finalizat și făcut public, urmând ca Sun Microsystems, compania sub egida căreia s-a dezvoltat limbajul, să vândă licența firmelor IBM, Microsoft, Silicon Graphics, Adobe și Netsacpe. În 2010 Oracle a cumpărat Sun Microsystem.
Limbajul de programare Java a devenit renumit și foarte folosit în special datorită caracteristicilor și particularităților sale:
Limbaj interpretat și compilat. Programele Java sunt compilate în niște fișiere asemănătoare codului de asambalare și apoi interpretate de mediul de execuție Java în instrucțiuni mașină asociate platformei sistem țintă.
Limbaj independent de platformă. Fișierele pot fi executate pe orice platformă indiferent de Sistemul de Operare (Windows, UNIX, Solaris etc). Când se instalează limbajul Java se creează o mașină virtuală Java ce traduce instrucțiunile unui byte code Java în instrucțiuni mașină pentru platforma curentă.
Limbaj orientat obiect. Java scoate în evidență toate elementele programării orientate obiect: obiecte, trimitere de parametri, încapsulare, clase, biblioteci, moștenire, modificatori de acces.
Limbaj concurent. Java are capacitatea de a executa mai multe sarcini simultan. Termenul în engleză ce-l definește este “multithreading”.
Limbaj simplu. Deși a fost creat preluând diverse elemente din C/C++, limbajul Java este mult mai simplu. Nu are pointeri, alocarea și dealocarea memoriei se fac automat de către ”Garbage Collector”, nu există moștenire multiplă, iar șirurile sunt încapsulate într-o structură clasă.
Limbaj distribuit. Permite utilizarea obiectelor locale și de la distanță, oferind posibilitatea dezvoltării aplicațiilor pentru Internet. Java respectă standardul IEEE (eng. Institute of Electrical and Electronics Engineers), de aceea se pot utiliza numerele în virgulă flotantă, întregii și șirurile de caractere. Java poate fi utilizat și în aplicații de rețea pentru că respectă protocoalele de rețea ca FTTP, HTTP, etc.
Limbaj performant, dinamic și robust. Java este capabil să lucreze cu fire de execuție multiple, să întârzie alocarea obiectelor și legarea dinamică a claselor pentru momentul execuției tocmai cu scopul de a evita erorile de alocare.
Limbaj sigur. Deoarece nu folosește pointeri și alocă memorie doar la execuție, programele Java nu pot accesa memoria heap, stack sau alte secțiuni protejate de memorie.
1.2 Instalare și tipuri de aplicații Java
Fiind un limbaj open-source (cu sursă deschisă), se poate descărca gratuit de pe https://java.com/en/download/. Pentru execuția unui program Java, interpretorul Java decodifică byte-code-ul Java și îl execută instrucțiune cu instrucțiune. În procesul de traducere a codului sursă în instrucțiunile mașinii fizice apare mașina virtuală Java, ceea ce aduce cu sine o scădere a vitezei de execuție comparativ cu un program construit cu instrucțiunile unei mașini native.
Există mai multe tipuri de aplicații Java: aplicații de sine stătătoare (eng. stand-alone), aplicații care se execută pe partea de client (eng. applet), respectiv aplicații care se execută pe partea de server (eng. servlet).
O aplicație de sine stătătoare Java este un program care se execută în afara contextului unui browser Web. Caracteristica sa principală este încapsularea în cadrul clasei principale a unei funcții main():
public static void main (String [] args) {
…
}
Această metodă publică este o cerință obligatorie. Metoda main() este punctul normal de intrare pentru o aplicație Java. Trebuie declarată obligatoriu static pentru a putea fi executată fără a construi o instanță a clasei corespunzătoare. Șirul args [] conține argumentele pe care utilizatorul poate să le introducă în momentul apelării din linia de comandă.
Clasificarea aplicațiilor Java de sine stătătoare se poate face în felul următor: aplicații de tip consolă, respectiv aplicații fereastră care folosesc interfața grafică cu utilizatorul (eng. Graphical User Interface – GUI).
O aplicație care se execută pe partea de client este încărcată de pe un server, de cele mai multe ori aflat la distanță și executată de programe speciale, cum sunt navigatoarele Web. Un applet este un program Java care respectă o mulțime de convenții care îi permit să ruleze în cadrul unui navigator Web. Fișierul cu extensia .class al unui applet este stocat pe un server Web și poate fi accesat de către un client prin intermediul unei pagini care conține acel applet. La încărcarea paginii, codul appletului este transferat pe mașina client și va fi executat cu ajutorul mașinii virtuale incluse în navigator.
O aplicație care se execută pe partea de server este o aplicație care este rulată de către un server ca urmare a unei cereri primite de acesta, iar rezultatul este trimis clientului solicitant. Un servlet este o componentă Web scrisă în Java care poate fi încărcată dinamic și rulată de un server Web, și care poate interacționa cu diferiți clienți folosind o implementare a paradigmei cerere/răspuns bazată pe protocolul HTTP. Spre deosebire de appleturi, servleturile nu afișează o interfață grafică, ci doar rezultatul procesării, în general sub forma unui fișier HTML.
1.3 Fișiere sursă
Orice fișier sursă Java trebuie să aibă extensia .java și să conțină cel mult o definiție a unei clase de bază publice. Clasa publică trebuie să aibă același nume cu al fișierului, desigur fără extensie și poate conține un număr nedefinit de clase nepublice.
Într-un fișier pot apărea trei elemente importante, care odată folosite trebuie să respecte o ordine: declarații de pachete, instrucțiuni de includere de clase (eng. import), definiții de clase.
Un pachet reprezintă o mulțime de programe Java păstrate în același director. Există mai multe pachete de bază, ca de exemplu: java.lang, java.applet, java.io etc. Pachetul java.lang fiind importat implicit. Pachetele sunt utile pentru separarea claselor în vederea reutilizării lor, căci rar se întâmplă să mai sufere modificări. Pentru o mai bună înțelegere, dăm un exemplu: un programator a creat o serie de clase pentru lucrul cu numerele fracționare; acestea pot fi stocate în același director și reutilizate în alte aplicații prin includerea pachetului creat.
CAPITOLUL 2
Android Studio
2.1 Istoric și caracteristici
Android Studio este un mediu de dezvoltare integrat (IDE) special creat pentru programarea pe Android. A fost făcut cunoscut în 2013 la o conferință Google și este distribuit gratuit sub licență Apache.
Android este un sistem de operare (OS) bazat pe nucleul Linux și dezvoltat, după cum am mai spus de către Google. Cu o interfață pentru utilizator bazată pe manipularea directă, Android este destinat în primul rând dispozitivelor mobile cu ecran tactil (smartphone), cu interfețe specializate pentru televizor (Android TV), autoturisme (Android Auto), ceasuri (Android Wear). Sistemul de operare folosește gesturi care corespund acțiunilor reale de zi cu zi (swiping, tapping, pinching, and reverse pinching) pentru a manipula obiectele de pe ecran și o tastatură virtuală.
Android Studio oferă: sistem flexibil bazat pe Gradle; posibilitatea de a construi fișiere apk variate și multiple; șabloane de cod pentru a construi aplicații comune; editor cu suport ‘drag and drop’; instrumente lint pentru ușurința în utilizare, compatibilitate de versiuni; capabilitate de app-signing și ProGuard; suport pentru platforma Google Cloud.
2.2 Android Studio versus Eclipse
În Eclipse există conceptul de ‘Workspace’ – mediul de lucru – unde diversele componente ale unui proiect cu librăriile sale sunt stocate în fișiere numite .jar, incluse mai târziu în aplicația finală. În Android în schimb proiectele sunt înlocuite de conceptul de modul și bibliotecă modul.
Modulele sunt unități discrete de funcționalitate care pot fi testate, rulate și depanate independent, oarecum similar cu Eclipse, exceptând câteva puncte cheie. Fiecare modul trebuie să aibă un fișier Gradle, creat automat sau creat manual la importarea unui proiect din Eclipse. Aceste fișiere Gradle conțin detalii importante ca versiunea de Android suportată și alte meta date despre proiectul în curs Android. Unele module pot fi ‘Library Modules’ ce se aseamană cu ‘Library Projects’ din Eclipse.
Interfața din stadiul de design este mult îmbunătățită în așa fel încât să se poată vedea interfața în lucru și componentele sale pot fi folosite cu ‘drag and drop’. Eclipse are și el o perspectivă de design asemănătoare.
Ca și în Eclipse, va trebui să se apeleze la fișiere Jar, adăugându-le în fișierul Gradle. Aceste fișiere .jar vor fi puse într-un folder ‘libs’ la rădăcina modulului director.
Precum în Eclipse un modul depinde de un alt modul. Creându-se o legătură între două module, Android Studio va genera automat fișierele Gradle necesare.
O schimbare majoră în Android Studio este că mai multe setări comune care erau odată în Android Manifest acum fie sunt adăugate automat (ex. în situația "debuggable=true", un steguleț apare însemnând că aplicația a fost deja ‘debugged’), fie au fost mutate în build.gradle (ex. API specificații). Cu toate acestea anumite permisiuni și carcateristici trebuie notate în Android Manifest (ex. permission:camera).
În timpul unei tranziții de la Eclipse către Android, cea mai dificilă parte este adăugarea fișierului Gradle. Un proiect Android Studio va avea un settings.gradle valabil pentru întreg proiectul. Fișierul settings.gradle include referințe către toate modulele incluse în proiect și este updated automat când se importă sau se creează un nou modul. Fiecare modul Android Studio va avea un fișier build.gradle.
CAPITOLUL 3
Programarea web cu Laravel PHP
3.1 Laravel PHP
Definit ca un framework Open Source, bazat pe limbajul de programare PHP, Laravel a câștigat aprecierea unui număr mare de programatori prin simplitatea și facilitatea interfeței. Considerat nu doar simplu de instalat și folosit, Laravel poate fi alegerea perfectă a programatorului web care își dorește să creeze site-uri web cu aspect plăcut, fără cunoștințe avansate de web design. Practic vorbim de o revoluționare a tot ceea ce înseamnă, de ani buni, PHP și WordPress.
Laravel adresează una dintre cele mai întâlnite probleme ale dezvoltatorilor: livrarea rapidă a unui produs validat și bine cotat la nivelul pieței. Foarte importantă este și dezvoltarea unui produs care să exprime profesionalism, încredere sau care să convingă consumatorii să treacă la următoarea etapă, aceea a achiziției.
Ușurința în folosirea framework-ului Laravel este consolidată și de manualul de utilizare, complet și extrem de bine documentat. Framework-ul beneficiază și de aportul mai multor autori care au scris cărți tehnice prin care se acoperă toate specificațiile framework-ului Laravel.
De asemenea, în jurul Laravel s-a construit o comunitate puternică de dezvoltatori și testeri, pregătită prin experiența proprie să contribuie cu soluții reale problemelor pe care le punctează dezvoltatorii.
În momentul lansării, Laravel a creat rumoare prin asumarea promisiunilor referitoare la minimalizarea efortului și a transformării procesului de programare în ceea ce programatorii numesc fun mood. De asemenea, Laravel scoate la iveală un alt set de algoritmi, departe de a fi plictisitori, lăsând o mai mare libertate programatorului în vederea concentrării asupra arhitecturii unei aplicații, nu scrierea propriu-zisă a liniilor de cod. Modificarea ulterioară pe care un programator Laravel o face pe un segment de cod sau într-o funcție nu afectează alte module ale aplicației, fapt ce oferă un plus de siguranță și de relaxare.
Laravel a introdus proceduri logice și intuitive, ce vizează denumirea dată fișierelor salvate, claselor sau bazelor de date apelate. Prin alegerea funcționalității Smart Defaults, Laravel permite focusarea programatorului asupra bunei funcționări a aplicației, precum și pe dezvoltarea rapidă și corectă (fără erori) a structurii de cod. Laravel promovează DRY (Don’t-Repeat-Yourself), un principiu prin care o funcționalitate este scrisă pentru o singură dată și fără eventuale erori. De asemenea, Laravel oferă un mediu prielnic împărtășirii facile a liniilor de cod între modulele unui program.
Toate aceste avantaje ale folosirii Laravel sunt susținute de unul dintre cele mai recente trenduri din domeniul IT, ce recunosc viitorul industriei online prin tot ceea ce înseamnă FIA (Future Internet Architecture program).
Creat de Taylor Otweel, cu o sintaxă ușor de memorat, o documentație oficială disponibilă la http://www.laravel.com extrem de bine făcută și cuprinzătoare – Laravel reprezintă cea mai comună alegere în privința framework-urilor PHP în ultima vreme. Instalarea Laravel este foarte ușoară, aceasta putând fi făcută cu ajutorul utilitarului composer – disponibil la adresa web https://getcomposer.org/ .
Laravel are numeroase funcționalități care-l transformă într-un framework extrem de puternic:
Are Fațade (eng. Facades) (clase ale căror metode pot fi apelate ca și metode statice, ex: Route::get(), Input::get(), Input::all() și multe altele).
Are Eloquent ORM (eng. Object-relational mapping) pentru comunicarea cu bazele de date. Un ORM oferă numeroase funcționalități ce-ți conferă un control imens asupra aplicației.
Design Patterns – Folosind Laravel se învață numeroase design patterns, un subiect frecvent dezbătut printre programatorii PHP avansați.
3.2 Programarea web pentru client și server
Programarea Web se realizează prin intermediul unor limbaje de programare, atât pe client cât și pe server. Aceste limbaje interpretate, sau altfel spus instrucțiunile prezente în programele incluse sunt traduse într-un format intern și executate una câte una. Limbajele de programare Web pentru client și server sunt asemănătoare în sensul că secvențele de cod sursă scrise în aceste limbaje pot fi integrate în codul XHTML, dar diferite din punct de vedere al modalităților de execuție a programelor. Browserul Web interpretează un script scris într-un limbaj de programare pentru client după ce pagina care îl conține a fost descărcată pe calculatorul utilizatorului. Un script scris într-un limbaj de programare pentru server este procesat în întregime pe serverul Web, ca rezultat fiind generate diverse tipuri de conținuturi (XHTML, XML, conținut grafic), trimise apoi aplicației client (browserului Web).
Utilizarea limbajelor de programare Web pentru server are diverse avantaje precum:
Asigurarea accesului la resurse stocate pe server (fișiere, baze de date);
Faptul că pot fi folosite în variate scopuri (calcule și procesări complexe, utilizarea poștei electronice).
3.3 Limbajul PHP – istoric și caracteristici
PHP este cel mai popular limbaj de programare Web pentru server. Succesul său este datorat caracteristicilor sale: simplitate, familiaritate (sintaxe prelucrate de la Pearl și C), eficiență (folosește mecanisme de alocare a resurselor specifice mediilor multiutilizator precum Web-ul), securitate sporită (oferă un set eficient de măsuri de siguranță), flexibilitate (poate fi integrat cu numeroase servere web ca Apache, Zeus), gratuitate căci este dezvoltat sub licența open source. Datorită acestor caracteristici PHP este un limbaj folosit adesea pentru crearea unor aplicații Web complexe în diferite domenii ca e-business, e-banking, e-marketing, e-gambling, e-learning, e-government, e-commerce.
În anul 1994 Rasmus Lerdorf a creat utilitarul PHP, acronim pentru Personal Home Page, prin intermediul căruia colecta informații despre vizitatorii site-ului său. Mai târziu, a adăugat la PHP elemente de interfață între utilizatori și bazele de date. În anul 1997, Zeev Surasky și Andi Gutmans au inițiat dezvoltarea unui limbaj de programare Web bazat pe ideile lui Rasmus Lerdorf numit acum PHP de la Hypertext Preprocessor. În anul 1998 este oferită utilizatorilor versiunea 3.0 a limbajului care permite folosirea unor elemente de programare orientată pe obiecte. Avantajele pe care le aduce utilizatorilor folosirea serverului de aplicații PHP sunt datorate în special numărului mare de API-uri (Application Programming Interface) de care dispune, precum și portabilității acestuia. Astfel, serverul de aplicații PHP dispune de interfețe pentru o mare parte a sistemelor de gestiune a bazelor de date utilizate în Internet (Oracle, MySql, Sybase etc.). PHP poate accesa un număr mare de sisteme de gestiune a bazelor de date relaționale, prin intermediul unor interfețe de acces direct sau indirect. MySQL este cel mai utilizat sistem de gestiune a bazelor de date relaționale folosit în Web împreună cu PHP.
3.4 Lucrul cu baze de date
Sistemele de gestiune a bazelor de date (SGBD) sunt aplicații folosite într-un număr mare de domenii de activitate, în scopul organizării, stocării și regăsirii informațiilor. Pentru organizarea și stocarea datelor, SGBD-urile utilizează o serie de modele conceptuale, cele mai folosite fiind cele numite ierarhic, rețea, relațional, obiectual, obiectual-relațional.
Cel mai des utilizat model conceptual este cel relațional, dezvoltat în anii 1970 de către Edgar Frank Codd, în timp ce lucra la firma IBM. Sistemul software care implementează modelul relațional se numeste SGBDR, sistem de gestiune a bazelor de date relaționale. Un SGBDR utilizează arhitectura client-server, în care datele sunt centralizate pe un calculator server, fiind gestionate de către un program server, iar utilizatorii le pot accesa prin intermediul unei rețele, folosind un program client. O bază de date relațională este alcătuită din tabele, între care se pot stabili relații. Un tabel conține înregistrări numite și rânduri. O înregistrare este alcătuită din câmpuri numite și coloane sau atribute. O înregistrare este identificată prin valorile corespunzătoare ale coloanelor. În teoria relațională, înregistrările conținute într-un tabel nu se pot repeta, ceea ce înseamnă că nu pot exista două rânduri identice. Coloana/coloanele care au valori unice sunt folosite pentru identificarea înregistrărilor. O coloana/combinație de coloane utilizată în scopul menționat se numește cheie candidată. Aceasta trebuie să respecte următoarele condiții: unicitate (o cheie identifică în mod unic o înregistrare), valori nenule (coloanele care compun cheia trebuie să aibă valori nenule) și compoziție minimală (nicio coloană nu poate fi eliminată – în cazul unei chei compuse – fără a distruge unicitatea înregistrării).
Pentru un tabel dat pot exista mai multe chei candidate. Dintre acestea se alege o cheie primară, folosind criterii stabilite de cel care proiectează structura tabelului/bazei de date. O cheie se numește externă dacă este și cheia primară a unui alt tabel. În modelul relațional, implementarea unei baze de date implică parcurgerea obligatorie a trei etape acestea fiind enumerate mai jos:
Proiectarea bazei de date;
Normalizarea bazei de date;
Specificarea tipului de date pentru fiecare coloană.
3.5 Limbajul SQL
SQL (Standard Query Language) este un limbaj neprocedural utilizat pentru gestionarea datelor în SGBD-uri, bazat pe algebra relațională. Limbajul SQL include instrucțiuni care permit efectuarea unor operațiuni diverse:
Crearea bazelor de date, a tabelelor și a structurii acestora;
Indexarea și stabilirea relațiilor între tabele;
Efectuarea de operații de actualizare a datelor;
Regăsirea datelor având ca rezultat transformarea acestora în informații;
Modificarea structurii tabelelor;
Controlul drepturilor de acces pentru utilizatori, asupra bazelor de date, tabelelor și coloanelor acestora.
O instrucțiune SQL este compusă din cuvinte rezervate și cuvinte definite de utilizator. Cuvintele definite de utilizator reprezintă denumirile bazelor de date, tabelelor, câmpurilor etc. La rândul lor, cuvintele rezervate sunt cuvintele cheie și clauze. Rezultă că o instrucțiune SQL are trei părți: un cuvânt cheie, parametri și clauze. Atunci când se face referire la o instrucțiune, se precizează componenta cuvânt – cheie (ex. instrucțiunea SELECT). Cuvintele rezervate sunt case-insensitive. În schimb, unele dintre cuvintele definite de utilizator sunt case-sensitive (numele coloanelor unui tabel), altele fiind case-insensitive (numele bazelor de date și ale tabelelor). Limbajul SQL are două componente:
Un limbaj de definire a datelor, utilizat pentru definirea structurii bazei de date;
Un limbaj de manipulare a datelor, denumit și Limbaj de Interogare, utilizat pentru regăsirea, introducerea, modificarea/actualizarea și ștergerea datelor.
Caracteristicile limbajului SQL sunt:
Simplitatea. Spre deosebire de un limbaj de programare ce necesită învățarea unor sintaxe stricte și usor de confundat, SQL are o sintaxă foarte apropiată de limbajul uman natural, ușor de înțeles și ușor de utilizat. Complexitatea sistemului care implementează algoritmii necesari lucrului efectiv cu datele, metodele de stocare, căutare etc, precum și optimizările sunt perfect transparente pentru utilizator. Acest limbaj nu este considerat un limbaj de programare deoarece a fost conceput pentru a spune calculatorului ce date sunt necesare și nu cum trebuie obținute. Sunt necesare cunoștinte minime de calculator pentru utilizarea SQL; acesta este de fapt și idealul urmărit de marile firme producătoare de motoare de baze de date: comercializarea unui sistem complex care să permită implementarea oricărei baze de date care ulterior poate fi manipulată doar cu ajutorul utilitarelor anexate sistemului, fără a mai fi nevoie de scrierea de aplicații specifice.
Avantajul simplității în utilizare constă în faptul că în realitate nu există nicio aplicație care să ofere o interfață utilizatorului neprofesionist. Mai mult decât, așa-zisa similaritate cu limbajul natural uman nu se concretizează decât într-un număr restrâns de cuvinte cheie gândite inițial ca fiind suficiente pentru realizarea oricărei operații. Realitatea a dovedit că pentru prelucrarea datelor sunt necesare multe alte funcții – care au fost implementate ulterior – însă restul limbajului conține denumiri și sintaxe la fel de criptice ca în orice alt limbaj de programare.
Generalitatea. Standardizarea a fost întotdeauna o sursă de progres; stabilirea unui limbaj comun a permis producătorilor din întreaga lume să își cumuleze eforturile și să își bazeze munca pe rezultatele anterioare. În realitate SQL constituie un standard doar în forma teoretică, descrisă cu mulți ani în urmă. Odată cu avansul tehnologic setul de facilități oferite de SQL a devenit rapid insuficient. Metodele în care datele pot fi prelucrate sunt de o varietate infinită și nu au putut fi grupate într-un set de funcții comune, fiecare aplicație având cerințe specifice. Rezolvarea acestor cerințe prin funcții noi inventate pentru a satisface cele mai variate necesități (de la simple conversii între tipuri de date până la medii geometrice, radicali, logaritmi sau căutari de șiruri) nu au mai reprezentat un standard. Au început prin a fi extensii venite să îmbogățească limbajul de bază și să ușureze munca utilizatorului, dar au devenit curând absolut indinspensabile și au fost implementate de toate sistemele. Astfel, toate companiile ce dezvoltă motoare de baze de date implementeaza aceleași funcții, dar sub denumiri și cu sintaxe diferite.
Portabilitatea. O aplicație accesează o bază de date prin intermediul frazelor SQL care nu sunt altceva decât simplu text. Orice motor de baze de date acceptă astfel de fraze text, făcând posibilă migrarea unei aplicații de pe un motor pe altul mai performant fără nicio modificare. Faptul că SQL este un standard unanim recunoscut oferă un mare avantaj aplicațiilor care își pot alege oricând pe ce sistem să ruleze.
CAPITOLUL 4
Descrierea aplicației
4.1 Mediul de dezvoltare
4.1.1 Analiza dependințelor tehnice
Soluția propusă pentru a dezvolta acest ecosistem de aplicații nu este una simplă din perspectiva tehnologiilor ce urmează a fi folosite. Prin urmare, vom interacționa cu următoarele tehnologii:
HTML – pentru realizarea paginilor web (limbaj de marcare);
JavaScript – pentru a adăuga comportament dinamic paginilor web;
CSS – pentru a stiliza paginile web;
PHP – pentru procesarea pe server a cererilor de la client;
SQL – pentru stocarea și gestiunea datelor ;
Java – pentru realizarea aplicației Android.
De asemenea, pentru a pregăti mediul de lucru trebuie să instalăm serverele, uneltele și framework-urile necesare necesare:
Serverul Apache (pentru procesarea cererilor web);
Serverul MySQL (pentru găzduirea bazei de date);
Interpretorul PHP;
Composer;
Laravel;
Bootstrap Framework (HTML + CSS + JavaScript Framework);
WebStorm (mediu integrat de dezvoltare web – IDE JavaScript);
Java JDK;
Biblioteca ZXing (pentru scanarea codurilor QR);
Android Studio (mediu integrat de dezvoltare – IDE Android).
Pentru a avea o mai bună perspectivă asupra tuturor serverelor, uneltelor și framework-urilor folosite, respectiv relațiile dintre acestea, putem să aruncăm o privire pe graficul alăturat.
Figura 1. Arhitectura aplicației. Servere, unelte și framework-uri folosite.
4.1.2 Instalare Apache
XAMPP un pachet de aplicații ce conține o distribuție Apache ușor de instalat, serverul MySQL, și limbajele de scripting PHP și Pearl. Prin urmare, primul pas în pregătirea mediului de dezvoltare a proiectului a fost să descarc fișierul executabil XAMPP versiunea pentru Windows de la adresa https://www.apachefriends.org/download.html.
De îndată ce fișierul executabil s-a descărcat cu ajutorul Wizard am dat startul instalării. Am acceptat toate setările inițiale. După instalare, XAMPP se deschide cu o fereastră de Control Panel în care se regăsesc diverse acțiuni precum cea de pornire/oprire a modulelor, accesarea panoului de configurare, verificarea proceslor ce rulează în background și altele.
Pentru a verifica dacă mediul a fost instalat corect, dupa ce am pornit câteva module Apache, am tastat în browser http://localhost/.
Pentru a proteja datele personale contra unui atac exterior, am accesat tabul de Security setând vizibilitatea acestuia doar pentru localhost. După configurarea parolei pentru userul root MySQL, am efectuat o verificare accesând PhpMyAdmin (o unealtă dezvoltată în PHP pentru administrarea serverului MySQL).
Din acest moment, XAMPP este configurat și putem sa trecem la pasul în care vom dezvolta aplicația web. Deoarece XAMPP se instalează în mod normal în directorul xampp de pe partiția sistem (C:\xampp), directorul în care vom pune fișierele pentru a servi site-ul estehtdocs (C:\xampp\htdocs).
4.1.3 Instalare Laravel
Pentru a pregăti mediul de lucru bazat pe framework-ul Laravel, avem două opțiuni:
Descărcarea ultimei versiuni a framework-lui Laravel de pe site-ul official;
Folosirea unui manager de pachete pentru PHP – Composer .
Pentru mediul curent, am ales opțiunea de a folosi Composer deoarece este o unealtă care poate rezolva diverse dependințe într-un mod mai elegant.
Composer este o aplicație de management pentru limbajul de programare PHP. A fost dezvoltat de Nils Andermann și Jordi Boggiano. Composer rulează în promterul de comandă și instalează librării pentru aplicații. Mediul de lucru care folosește Composer este Laravel. Așadar se instalează mai întâi Composer și ulterior Laravel.
Am descărcat și rulat Composer-Setup.exe de pe https://getcomposer.org/download/. Se intalează automat ultima versiune de fiecare dată când este executat. Dupa ce Composer a fost instalat, se pregătește mediul de lucru pentru a descărca framework-ul Laravel drept dependință pentru aplicația web de administrare a bibliotecii.
composer create-project laravel/laravel –prefer-dist
Această comandă va crea o instanță Laravel în directorul de unde s-a lansat comanda. De exemplu, va crea un director numit laravel ce va conține framework-ul Laravel cu toate librăriile și dependințele necesare.
Figura5. Fereastră Command-Prompt în care se poate vedea procesul de creare a unui proiect Laravel folosind Composer
Odată ce procesul de creare a proiectului bazat pe Laravel este terminat, putem să testăm rezultatul accesând proiectul nou-creat în browser.
Figura6. Așa arată ecranul de start al site-ului web generat cu framework-ul Laravel
De menționat că Laravel vine preinstalat cu un framework de UI (eng. User Interface) ce are la bază Twitter Bootstrap (UI Framework) ce conține componente predefinite de markup HTML și stil. Folosit împreună cu Laravel, website-ul capătă un aspect plăcut și totodată ne ajută să câștigăm timp util nefiind nevoie să ne concentrăm asupra aspectului visual.
Bootstrap este cel mai popular framework UI pentru dezvoltarea proiectelor responsive și mobile. Se poate folosi ca o platformă independentă, dar în cazul nostru îl folosim împreună cu Laravel.
Putem să vedem de exemplu ce înseamnă un formular de autentificare stilizat cu Bootstrap în mod responsiv (eng. Responsive Design) în captura grafică alăturată.
4.1.4 Instalare Android Studio și Java JDK
În această etapă scopul este să pregătim mediul de dezvoltare pentru a putea dezvolta aplicații Android.
Primul pas este să instalăm Java JDK (eng. Java Development Kit), parte dependință a Android Studio. Conform site-ului java.com (http://www.java.com/en/download/faq/develop.xml), Java JDK se descarcă de la adresa http://www.oracle.com/technetwork/java/javase/downloads/index.html.
Figura8. Captură de pe site-ul Oracle pentru descărcarea Java JDK
După ce descărcăm și instalăm Java JDK, putem trece la pasul următor ce constă în descărcarea și instalareaAndroid Studio, disponibil pe site-ul official Android la adresa https://d.android.com/sdk/index.html.
4.2 Aplicația Web
4.2.1 Configurarea inițială
Mediul de dezvoltare fiind pregătit, putem să trecem la etapa următoare, etapa în care ne vom ocupa de configurarea inițială. În acest proces vom acoperi câteva aspecte:
Crearea bazei de date destinată utilizării de către aplicația web;
Configurarea adaptorului SQL a proiectului Laravel.
Aplicația web va avea nevoie de o bază de date pentru stocarea cărților, autorilor, editurilor, bibliotecarilor, respectiv a tranzacțiilor privind procesul împrumut-returnare. Așadar, avem 2 opțiuni pentru crearea bazei de date: prin linie de comandă folosind clientul MySQL sau prin interfață grafică folosind utilitarul web PhpMyAdmin. Vom merge pe a doua variantă fiind mai simplă și totodată oferindu-ne acces rapid la mai multe funcții și operații și vom crea baza de date numită adminlibrary. De asemenea putem să creăm un utilizator dedicat care să aibă permisiuni asupra bazei de datenou-create sau putem să folosim utilizatorul root, cu privilegii de administrare. Recomandat este să avem utilizator dedicat cu permisiuni clare pentru fiecare bază de date, din motive de securitate.
Odată create baza de date cât și utilizatorul care săaibă permisiunile necesare asupra bazei de date, putem să adăugăm informațiile de conectare în fișierele de configurare ale proiectului Laravel:
Fișierul .env din rădăcina proiectului;
Fișierul database.php din directorul config.
În oricare din cele două fișiere vom specifica adaptorul sql (în cazul nostru acesta fiind mysql), adresa serverului mysql (localhost), numele bazei de date (adminlibrary) respectiv datele de acces, utilizatorul și parola pentru baza de date.
Din acest punct, suntem gata să trecem la următorul pas.
4.2.2 Definirea entităților
În contextul nostru, ca bibliotecar, vom desfășura diverse operațiuni. De la adăugarea de cărți în sistem până la a realiza procesul de împrumut – returnare, iată care ar fi operațiile de bază:
Gestionarea cărților (adăugare, actualizare, ștergere);
Gestionarea autorilor (adăugare, actualizare, ștergere);
Gestionarea editurilor (adăugare, actualizare, ștergere);
Gestionarea cititorilor (adăugare, actualizare, ștergere);
Gestionarea tranzacțiilor (împrumut, returnare).
Privind cu atenție aceste acțiuni specifice operațiilor dintr-o bibliotecă comună, putem să extragem entitățile cu care vom opera în baza de date. După cum se poate vedea anterior, entitățile se reflectă singure:
Autor;
Editură;
Carte;
Cititor;
Tranzacție.
Laravel, este un framework care include un ORM foarte util, ORM care ne oblige să definim modelele (entitățile) înainte de a ne apuca de treabă. Eloquent ORM va fi folosit ulterior pentru a lucra cu obiecte, obiecte care vor reflecta starea datelor din baza de date. Procesul va fi foarte simplificat și ne va permite să câștigăm timp.
4.2.3 Crearea modelelor
Trebuie menționat faptul că Laravel vine cu sine nu doar cu Eloquent ORM ci și cu o unealtă extraordinară numită artisan. Artisan se folosește în linie de comandă și poate fi folosit la crearea de controllere, modele respectiv view-uri (șabloane), dar și în procesul de migrare și seeding.
Este adevărat că odată cu artisan am introdus câteva concepte noi. (controller, model, view, migrare, seeding). Acesta este o dovadă practică a ceea ce se spune despre acest framework, Laravel: ca dezvoltator ești constrâns să lucrezi cu design patterns.Un design pattern pe care îl regăsim aici este cel de MVC (eng. Model-View-Controller), design pattern care implică separarea componentelor în aplicație după cum urmează:
Model: componenta care reflectă starea și valoarea datelor;
View: componenta prin care se afișează datele (html, json, șabloane);
Controller: componenta care conține partea logicăa aplicației (operează asupra datelor).
Folosirea unui ORM aduce cu sine alți termeni în vocabular: migration respectiv seeding (migrare și însămânțare). Dat fiind faptul că la scară largă se folosesc termenii din limba engleză, vom folosi pe mai departe termenii de seeding, respectiv migration pentru a descrie operațiile asociate.
Migrarea în Laravel reprezintă o procedură prin care se efectuează o operație la nivel de bază de date ce implică crearea, alterarea sau inserarea de date. De altfel, procesul de seeding este deseori asociat cu cel de migration. Migration-ul și modelul sunt mână în mână, însă sistemul de migration ne ajută să versionăm schema bazei de date. Practic deși vom folosi un model de-a lungul procesului de dezvoltare, prin migration noi putem să actualizăm constant schema din baza de date fără a crea impedimente în dezvoltare între colaboratori.
Inițial vom crea câte un fișier migration pentru fiecare entitate, respectiv autor, editură, carte, cititor, tranzacție. De menționat că dacă o carte poate avea o singură editură, aceasta poate avea mai mulți autori.Având mai mulți autori, vom fi nevoiți să folosim o relație unul-la-mulți (eng. one-to-many) a cărții în raport cu autorul. De aceea vom avea nevoie de o altă migrare pentru relații carte-autor.
Crearea migrărilor cu artisan este simplă. Vom folosi comanda make:migration împreună cu utilitarul artisan ca în exemplul următor: php artisan make:migration create_users_table. Prin această comandă, în directorul Database/migrations vom găsi fișierul migrare asociat. Editând fișierul generat putem să construim schema tabelului folosind Schema Builder ca în exemplul alăturat.
Pentru a crea un model în Laravel, lucrurile se simplifică foarte mult. Vom folosi utilitarul artisan alături de comanda make:model ca în exemplul următor:php artisan make:model User.
Iată mai jos cum ar arăta modelul pentru Carte (eng. Book) cu relațiile aferente.
Figura10. Cartea aparține unei edituri (belongsTo) și totodată mai multor autori (belongsToMany)
Practic crearea modelelor se realizează foarte simplu și ușor după ce au fost definite structurile din baza de date (migrations).
4.2.4 Crearea controller-lor
Controller-ul, așa cum am văzut la migrations și modele, se creează tot cu artisan: php artisan create:controller BookController. Gândit pentru a ușura munca dezvoltatorilor, Laravel generează fișierul destinat a avea rol de controller cu metode REST predefinite pentru acțiuni uzuale:
anyIndex (acțiunea de bază);
anyEdit (acțiunea de editare);
anyUpdate (acțiunea de actualizare);
anyCreate (acțiunea de creare);
anyStore (acțiunea de stocare);
anyShow (acțiunea de afișare);
anyDestroy (acțiunea de ștergere).
Prefixul anyeste folosit pentru a specifica framework-ului că acțiunea respectivă trebuie să răspundă atât cererilor GET cât și cererilor POST. De altfel, prefixul any poate fi înlocuit cu unul din prefixele get sau post pentru a specifica exact tipul de cerere web acceptat.
Așa cum am menționat anterior, controller-ul este componenta MVC în care se definește logica aplicației. În controller extragem date și operăm asupra lor folosind modele, pe care le vom afișa ulterior folosind view-urile.Controller-ul poate avea mai multe forme de răspuns:
Redirecționare;
plain/text (JSON);
View (HTML).
În exemplul alăturatvedem cum arată acțiunea Store a controller-ului Book ce va fi folosită pentru a salva în baza de date o carte nouă.
Să analizăm rândurile anterioare. După cum vedem, se instanțiază un obiect de tipul Book – ceea ce constituie modelul nostru. Având obiectul model, putem să asociem valori tuturor prioprietăților. Astfel, se citesc informațiile primite prin obiectul $request, informații primite de la client și le asociem valorile proprietăților corespunzătoare și vom apela metoda save, acțiuni ce va salva proprie-zis cartea în baza de date. În cazul nostru particular, având relația carte-autor one-to-many, citim informațiile privind lista de autori și folosim modelul BookAuthor pentru a insera relații de asociere carte-autor. Răspunsul controller-ului în exemplul dat este un răspuns de redirecționare la pagina de listare a cărților.
Controller-ul este foarte flexibil. Am spus mai devreme că avem multiple răspunsuri. Răspunsul de mai devreme a fost un răspuns de tip redirecționare. Să aruncăm o privire pe un exemplu care include un răspuns de tip View. Răspunsul de tip plain/text îl vom aprofunda în capitolul dedicat serviciilor, răspunsce va fi folosit pentru comunicarea cu aplicația Android.
Figura12. Acțiunea index a controller-ului Book. Se poate vedea răspunsul de tip View.
Iată că am văzut și o acțiune ce întoarce un răspuns de tip view. Mai exact, trebuie să menționăm faptul că Laravel vine cu un motor de șabloane numit Blade. Cu ajutorul lui Blade putem să scriem șabloane reutilizabile, arhitecturi complexe de aspect și structură. În exemplul curent, răspunsul de tip view îi spune lui Blade să folosească șablonul index din directorul books (punctul are rolul de a separa și delimita directoarele de fișiere) împreună cu setul de date books. Faptul că putem să specificăm unui view un set de date ne va permite în șablon să folosim datele respective pentru afișare. Tot în exemplul curent putem să vedem puterea Eloquent ORM care ne permite să scriem cod orientat-obiect pentru interogarea și procesarea datelor din baza de date. Pentru afișarea cărților ordonate alfabetic și paginare nu a fost nevoie decât de o linie de cod:
$books = Book::with('publisher')->with('authors')
->orderBy('name')->paginate(10);
4.2.5 Crearea route-lor
Am vorbit despre modele, controller, iată că am ajuns la un nou termen: route. Sau tradus, rută.În urmă cu câțiva ani schimbările din motoarele de căutare dictau noi trenduri în ce privește dezvoltarea web: link-urile prietenoase. Link-urile prietenoase presupuneau ca site-ul să folosească o structură de link-uri sub formă de directoare pentru paginile interne pentru a putea fi ușor memorate de utilizator. Ex: http://site-ulmeu.ro/index.php?cat=home&page=profile vs http://site-ulmeu.ro/home/profile. Cu timpul, în procesul de dezvoltare a apărut un nou design pattern și anume cel prin care cererile web sunt interpretate într-un punct de intrare numit RouteController și ulterior se decide care este controller-ul care trebuie să răspundă cererii respective.
Figura13. Grafic care arată cum este o procesată cererea web de la motorul de routing până la pagina generată în navigatorul web
Gestionarea rutelor în Laravel este se face în fișierul routes.php din directorul app/Http. După instalare, Laravel vine configurat cu o singură rută, aceea care răspunde de cererile web venite în rădăcina site-ului web. Iată mai jos cum arată fișierul routes.php.
Figura1. Fișierul routes.php după instalarea proiectului Laravel.
După cum se vede în imaginea de mai sus, pentru a scrie o nouă rută, dezvoltatorul web se folosește de formatul URL pentru a desemna rutele ce vor fi asociate cu o acțiune sau un controller. În cazul de față, pentru adresa /este asociată o acțiune care întoarce ca rezultat o pagină numită welcome ce va fi încărcată de motorul de view și ulterior trimisă înapoi la utilizator în format HTML.
Motorul de rute din Laravel este destul de flexibil și oferă dezvoltatorului mai multe facilități, printre care: asocierea dintre o rută și o acțiune descrisă pe loc, sau o acțiune a unui Controller, asocierea dintre o rută și un Controller, specificarea filtrelor (ex. Filtrul strat pentru Autentificare), sau chiar filtre pentru grupuri de Controllere.
Figura2. Rute exemplu din aplicația web. Se pot vedea diferite moduri de a asocia acțiuni, controllere și filtre rutelor definite.
În principiu în lucrul cu rutele specificăm tipul de acces, calea ce trebuie procesată și acțiunea care gestionază și întoarce răspunsul către client:
get este metoda prin care se face cererea. Așa cum serverul web interpretează tipuri de cerere http precum ‘GET’, ‘HEAD’, ‘POST’, ‘PUT’, tot așa și Laravel are definite metode prin care poate interpreta cererile. Cele mai populare cereri http sunt folosite de Laravel sunt:
get – pentru afișarea unei pagini
post – pentru trimiterea de date prin formular
put – pentru salvare
patch – pentru modificare de informații
delete – pentru ștergere de informații
any – cerere care va fi procesată pentru orice tip de request (get, post etc.)
“/” reprezintă linkul care va fi adresat în cadrul rutei. În acest caz este vorba de accesarea rădăcinii aplicației (homepage-ul).
function() – reprezintă o funcție anonimă, rutei returnându-i-se direct ceea ce s-a definit în cadrul funcției anonime.
4.2.6 Crearea view-urilor
Laravel are propriul sistem de șabloane numit Blade. Este un instrument foarte puternic.Cu ajutorul lui Blade putem să construim șabloane reutilizabile și componente ce pot fi îmbinate pentru a realiza site-uri cu design complex. Blade este construit să suporte moșteniri de șabloane, și secțiuni. Fișierele blade trebuie să aibă extensia .blade.php pentru a fi identificate automat de către motorul Blade.
Pe partea de aspect, blade oferă următoarele instrucțiuni:
@section – @show/@stop – cu ajutorul acestor instrucțiuni putem defini secțiuni etichetate care pot fi ulterior încorporate în alte șabloane;
@yeld – cu ajutorul yeld putem să desemnăm o zonă de șablon în care se va atașa o anumită secțiune de către Blade;
@extends – instrucțiunea extends este folosită pentru a specifica faptul că un șablon moștenește un șablon părinte/master.
Vom arăta în continuare cum putem să desemnăm un șablon pentru a fi utilizat drept șablon master alături de șabloanele care vor moșteni arhitectura șablonului master.
Figura3. Șablonul master. Se pot observa instrucțiunile @yeld respectiv @section/@show
În următoarea captură vom observa cum un șablon poate extinde șablonul master.
Figura4. Șablonul moștenitor. Șablonul master este extins iar secțiunile dinamice sunt definite
Pe lângă aceste instrucțiuni, Blade oferă și structuri de control. Aceste structuri de control sunt necesare pentru lucrul cu datele ce urmează afișate. Astfel avem următoarele instrucțiuni disponibile:
Instrucțiuni pentru afișare: {{ $name }}
Instrucțiuni condiționale: @if … @elseif … @else … @endif sau @unless – @endunless
Instrucțiuni iteratoare: @foreach… @endforeach, @for … @endfor, @while … @endwhile
Instrucțiuni comentarii: {{– Acesta este un comentariu și nu va fi afișat în HTML –}}
4.2.7 Filtre de securitate. Autentificare
Filtrele sunt un alt punct forte ale framework-ului Laravel. Folosirea filtrelor ne permite sălucrăm cu procese pre-procesare respectiv post-procesare a requesturilor web. Astfel, procesul de autentificare poate fi foarte ușor implementat folosind filtrele pre-procesare.
Laravel face ca implementarea autentificării să fie foarte simplă. De fapt, aproape totul este configurat să funcționeze de la prima instalare. Fișierul de configurare se găsește în config/auth.php, și conține câteva opțiuni bine documentate pentru a optimiza comportamentul serviciilor de autentificare.
La instalarea standard, Laravel includeun model App\User în directorulapp. Acest model poate fi folosit cu driverul de autentificare Eloquent.Conține două controllere care se ocupă de partea de autentificare. Controller-ul AuthController este folosit pentru înregistrarea utilizatorilor noi și autentificarea acestora, pe când controller-ul PasswordController conține logicapentru a ajuta utilizatorii existenți să își reseteze parola uitată.
Pentru cele mai multe aplicații uzuale, nu va fi nevoie să modificăm aceste controllere sub nicio formă.Șabloanele de tip view pe care aceste controllerele folosesc pentru afișare se găsesc în proiect în directorul resources/views/auth. Se poate personaliza șablonul după bunul plac fără nicio problemă.
În cazul nostru, am ales să controlăm manual procesul de autentificare și am specificat în fiecare controller dacă este solicitat sistemul de autentificare sau nu. Iată un exemplu în care controller-ul Book solicită ca serviciul de autentificare să fie rulat înaintea procesării cererilor web.
Figura5. Apelarea serviciului de autentificare prin constructor pentru controller-ul Book
4.2.8 Structura logică a aplicației
Pentru ca aplicația să poată fi folosită într-un mediu real, trebuie să ne asigurăm că aplicația va fi capabilă să efectueze operații uzuale dintr-o bibliotecă. Să enumerăm operațiile obișnuite într-o astfel de bibliotecă:
Să adauge cărți noi în sistemul de gestiune și să actualizeze informațiile privind cărțile existente
Să adauge cititori noi în sistem și să actualizeze informațiile aferente
Să efectueze căutări privind disponibilitatea unor cărți
Să efectueze operații de împrumut-returnare.
Putem să privim cu atenție la următoarea diagramă pentru a înțelege mai bine workflow-ul propus care să răspundă acestor operațiuni efectuate în bibliotecă.
Figura6. Workflow-ul propus având la bază cele două aplicații folosite împreună
Din diagrama de mai sus se poate evidenția clar diferența dintre cele două aplicații și care este scopul folosirii acestora. Deși operațiile împrumut-returnare se pot realiza prin ambele aplicații, aplicația web este destinată folosirii exclusive pentru administrarea întregii biblioteci, scopul aplicației Android fiind acela de a facilita doar procesul de împrumut-returnare prin scanarea de coduri QR, proces care este mai puțin costisitor din perspectiva timpului comparativ cu folosirea aplicației web pentru aceeași operațiune.
În secțiunea dedicată modelelor, am vorbit mai mult despre modul în care framework-ul Laravel ne pune la dispoziție instrumente ce facilitează lucrul cu modelele. Nu am prezentat însă structura propusă pentru baza de date și am lăsat acest aspect să fie abordat în secțiunea despre structura logică a aplicației, considerând că este mai relevant să prezentăm workflow-ul și procesul logic având ca fundament structura bazei de date.
Așadar, iată forma propusă pentru baza de date ce va susține aplicația web și cea Android pentru a realiza operațiunile din bibliotecă.
Figura 20. Diagrama care afișează entitățile, proprietățile acestora și relația dintre ele în contextul workflow-ului propus.
Având entitățile bine definite, procesul de creare al modelelor este unul ușor de urmat folosind artisan pentru a crea fișierele de migrare și Schema Builder pentru a defini proprietățile modelelor. Acest mod de lucru se potrivește perfect cu motorul de rute (eng. routing engine) din Laravel și ne permite să pregătim structura paginilor web. Astfel, pentru fiecare model, vom asocia o rută respectiv un controller iar secțiunile aplicației web vor arăta în felul următor:
/ – pagina de start. Dacă utilizatorul nu este autentificat va fi trimis la pagina de autentificare
/books – secțiunea în care se listează, caută, adaugă și actualizează cărți
/publishers – secțiunea în care se vor lista, căuta, adăuga și actualiza editurile
/authors – secțiunea dedicată administrării autorilor
/readers – secțiunea în care se listează, caută, adaugă și actualizează cititori
/reports – secțiunea în care se listează istoricul tranzacțiilor și se vor efectua filtrări pentru a vedea cărțile împrumutate nereturnate, cele pentru care termenul de returnare a fost depășit și cele pentru care procesul a fost finalizat cu succes, cartea fiind returnată.
În urma unei analize atente a nevoilor și a modului de utilizare al unor aplicații de gestiune bibliotecă similare, s-a observat că se pot optimiza anumite procese.
Optimizarea în procesul de returnare.
În procesul de returnare, deseori bibliotecarul este nevoit să caute atât cartea cât și cititorul în sistem pentru a putea efectua operațiunea de împrumut. Pentru a facilita acest proces am desemnat următorul mod de lucru: se caută cartea, se continuă cu acțiunea de împrumut (atunci când cartea este disponibilă), după care se selectează cititorul și acțiunea de împrumut este gata. Un alt timp câștigat a fost prin adăugarea unei facilități sistemului de căutare ce permite căutarea nu doar după titlul cărților ci și după codul cărții, astfel: bibliotecarul introduce codul cărții în caseta de căutare iar aplicația îl va redirecționa automat la pagina cărții dacă aceasta a fost găsită în sistem, proces care îl va ajuta să câștige secunde prețioase în condiții de stres.
Optimizarea în procesul de returnare.
Pentru returnarea unei cărți, avem la dispoziție mai multe moduri de a face acest lucru.
Din secțiunea Reports (Istoric). Aici putem să vedem împrumuturile active, iar în contextul în care nu sunt multe împrumuturi active este foarte ușor să găsim cartea, să o selectăm și ulterior să apăsăm butonul return pentru a o returna.
Căutând efectiv cartea. Odată ce găsim cartea, putem să încheiem procesul de returnare folosind butonul return afișat imediat după detaliile cărții.
Căutând cititorul. Un alt mod de a returna o carte este prin a merge în secțiunea dedicată cititorilor. Aici vom căuta cititorul și imediat după secțiunea detalii avem acces la două secțiuni: una în care vom regăsi împrumuturile active, și a doua în care vom regăsi istoricul de lectură al cititorului. Astfel, se poate selecta cartea împrumutată și ulterior încheia procesul de returnare prin butonul return.
Un alt aspect destul de important ce merită a fi menționat este acela că aplicația având design-ul realizat cu ajutorul framework-ului Twitter Bootstrap, are avantajul că poate fi folosită cu ușurință pe orice platformă: desktop, tabletă, smartphone. Aplicația fiind accesibilă de pe orice dispozitiv aduce un mare plus în ce privește utilizarea și disponibilitatea. Să ne imaginăm ce s-ar întâmpla în situația în care calculatorul folosit de către bibliotecar ar deveni indisponibil temporar: întreg procesul de administrare ar fi inaccesibil. Soluția web propusă răspunde și acestor situații neplăcute și poate asigura o utilizare în astfel de condiții, fiind accesibilă de pe orice dispozitiv.
Să urmărim câteva capturi de ecran care ilustrează diferite secțiuni din aplicație.
Figura 21. Secțiunea Books. Listare de cărți
Figura 22. Secțiune Reader. Împrumuturi active și istoric de lectură
Figura 23. Secțiune Book. Detalii despre carte și împrumutul activ împreună cu butonul return
Figura 24. Secțiune Book. Detalii carte și butonul Borrow ce permite inițierea procesului de împrumut
Figura 25. Secțiune Book. Selectarea cititorului, pasul final în procesul de împrumut.
Figura 26. Secțiune Reports. Filtrarea istoricului de tranzacții pentru vizualizarea cărților nereturnate la timp
4.2.9Crearea serviciilor
Pentru implementarea serviciilor în proiectul curent, am folosit practic un singur Controller care să proceseze diferite cereri/acțiuni la adresa /service/ . În primă etapă am creat un controller nou cu ajutorul artisan numit ServiceController. După crearea controller-ului, am actualizat fișierul routes.php cu o nouă regulă de routing și anume, ca orice acțiune pe adresa /servicesă fie procesată de controllerul ServiceController.
Ținând cont de scopul și modul de utilizare al aplicației client (aplicația Android), am considerat că vor rezulta următoarele tipuri de cerere ce vor fi rezolvate de către serviciu:
Solicitare de verificare dacă serviciul este accesibil și autentificarea este OK
Solicitare de verificare a codului unei cărți
Solicitare de verificare a codului unui cititor
Solicitare de realizare a împrumutului unei cărți de către un cititor în baza codurilor acestora
Solicitare de realizare a returnării unei cărți de către un cititor în baza codurilor acestora
Date fiind tipurile de solicitări, am convenit să avem următoarele tipuri de răspuns:
OK:AUTH pentru solicitarea de verificare a serviciului și autentificare atunci când autentificarea este reușită
OK pentru solicitarea de verificare a serviciului dar fără autentificare
NOAUTH pentru solicitările în care procesul de autentificare a eșuat
ERR atunci când un serviciu a eșuat în procesarea logică a solicitării
JSON (plain/text) pentru serviciile care întorc seturi de date atunci când solicitarea a fost procesată cu succes
În ce privește logica de procesare a solicitărilor web, iată cum vor arăta serviciile finale:
/service/ – verificare, respectiv autentificare. Folosit de aplicația Android pentru a se asigura că aplicația poate fi utilizată pentru operațiunile de împrumut-returnare.
/service/book-details/ – serviciu prin care aplicația Android interoghează sistemul solicitând detalii despre carte, rezultatul fiind folosit cu dublu scop:
Validarea cărții
Afișarea informațiilor despre carte în aplicație pentru a oferi feedback vizual utilizatorului
/service/reader-details/ – serviciu prin care aplicația Android interoghează sistemul solicitând detalii despre cititor, rezultatul având dublu rol, ca serviciul anterior.
/service/borrow-book/ – serviciu prin care aplicația Android solicită sistemului să efectueze împrumutul propriu-zis.
/service/return-book/ – serviciu prin care aplicația Android solicită sistemului să efectueze un proces de returnare.
4.2.10 Setul de date
În ce privește setul de date, trebuie menționat faptul că ne-a fost pus la dispoziție un set de către Biserica Penticostală EFRAIM Târgoviște ce conține o listă de aproximativ 900 de cărți în format CSV. Importul acestora l-am făcut să fie integrat cu sistemul de seeding al Laravel. Astfel, că se poate integra perfect cu sistemul de migrări, rollback și seeding.
4.3 Aplicația Android
4.3.1 Pregătirea proiectului Android folosind biblioteca ZXing
În urma unei cercetări efectuate pe internet am găsit mai multe biblioteci cu sursă deschisă (eng. Open Source). Ceea ce a fost mai potrivit pentru proiectul nostru s-a regăsit în biblioteca ZXing – proiect care este susținut de o comunitate puternică de dezvoltatori, dar și companii precum Google.
Actualmente ZXing este disponibil pe GitHub la adresa https://github.com/zxing/zxing. Conform documentației oficiale, acesta suportă multiple tipuri de coduri de bare respectând diverse standarde, printre care și codurile QR.
După cum am spus, ZXing este o bibliotecă foarte apreciată și larg răspândită printre dezvoltatori. Acest lucru face ca numeroși dezvoltatori să ofere public propriile implementări ale bibliotecii. Am ales o implementare dezvoltată sub licență cu sursă deschisă disponibilă pe GitHub la adresa https://github.com/journeyapps/zxing-android-embedded.
Unul din avantajele acestei implementări este acela că are suport și pentru versiunile mai vechi de Android, ceea ce îl face alegerea optimă.
Pentru dezvoltarea aplicației Android am ales să folosim Android Studio în detrimentul Eclipse, deoarece acesta permite personalizarea aspectului grafic al aplicației printr-un utilitar cu interfață grafică, ceea ce ne va scuti de timp și ne va ajuta să dăm aplicației un aspect plăcut.
Odată ce am descărcat de pe GitHub proiectul ZXing (ZXing Embedded), primul pas cu Android Studio este acela de a importa proiectul pentru a putea continua cu etapele următoare.
Figura 27. Ecranul de start din Android Studio. Proiectul a fost importat cu succes.
4.3.2 Design-ul aplicației
Design-ul inițial venit cu proiectul ZXing Embedded este unul foarte simplu, care scoate în evidență acțiunile posibile și câteva din punctele forte ale implementării.
Ținând cont de contextul în care aplicația va fi folosită, am considerat că cel mai potrivit ar fi ca aplicația să fie intuitivă, iar prin intermediul design-ului aplicației să constrângem utilizatorul să folosească aplicația în mod corect, pentru a evita apariția greșelilor în mod accidental.
Prin urmare, aplicația va avea două zone bine definite alocate pentru a afișa informațiile rezultate în urma procesului de scanare pentru ca utilizatorul să aibă un feedback vizual în raport cu operațiunea efectuată. Totodată se pot preveni erorile prin care în urma procesului de scanare, codul este partial sau eronat iar prin feedback-ul vizual utilizatorul poate observa că informațiile privind cartea sau cititorul nu sunt corecte.
Astfel, design-ul final al aplicației arată ca în figura alăturată. Se pot identifica cele două zone alocate informațiilor despre cartea sau cititorul identificat în urma procesului de scanare. Butonul prin care se inițiază un proces de scanare este așezat în centrul aplicației lăsând loc unei singure utilizări. Astfel, odată cu fiecare scanare, în urma răspunsului primit de la server aplicația știe să afișeze informațiile și să țină minte faptul că o carte sau un cititor a fost scanat.
Butoanele de acțiune, cele prin care se efectuează împrumutul sau returnarea sunt dezactivate în mod implicit și ulterior activate atunci când în aplicație sunt scanate cele două entități: cartea, respectiv cititorul.
De asemenea, pentru a reseta aplicația pentru a efectua o nouă tranzacție folosim butonul reset.
Pentru a notifica utilizatorul în ce privește rezultatul anumitor acțiuni, am folosit sistemul de notificări Toast oferit de Android SDK. O altă mențiune este aceea că aplicația conține și un ecran de configurări prin care se pot configura adresa serviciului web, respectiv informațiile de autentificare.
4.3.3 Comunicarea cu serviciile. Implementarea logică
Procesul de comunicare cu serviciul web, parte din aplicația web este unul destul de simplu și concis. În principiu, aplicația trebuie să știe care este adresa web a serviciului, restul fiind foarte clar care sunt tipurile de cereri ce pot fi efectuate.
Pentru a adresa această problemă, am folosit instrumentul ghidat din Android Studio pentru a adăuga suport pentru un ecran de configurări. Odată ce am creat secțiunea de setări, am putut să construiesc în mod dinamic adresele web necesare comunicării cu serviciul web.
Un alt aspect ce trebuie menționat este faptul ca operațiunile ce implică comunicarea cu o parte terță, cum este în cazul nostru un server web aflat la distanță, blochează în mod normal procesul curent în care aplicația rulează. Astfel, am folosit o implementare cu sursă deschisă pentru ca cererile web efectuate din interiorul aplicației Android să fie executate în mod asincron într-un proces paralel, pentru a evita ca interfața grafică a aplicației să se blocheze.
La nivel de implementare logică, aplicația pornește într-o anumită stare în care valorile privind cartea scanată sau cititorul scanat sunt neinițializate și totodată butoanele de acțiune sunt inactive. Butonul de scanare citește un cod QR pe care îl interpretează și tratează în felul următor:
Dacă textul citit este de forma CARTE:12345, aplicația tratează codul QR ca aparținând unei cărți cu identificatorul 12345. Pe ecran se afișează un mesaj Toast cu textul Book pentru a oferi un feedback vizual utilizatorului că a fost identificată o carte, după care execută o cerere către serviciul web pentru a obține informații privind cartea la adresa corespunzătoare acțiunii – /service/book-details/12345. Odată ce răspunsul a venit de la server este afișat un mesaj de eroare dacă răspunsul primit este codul ERR sau populează zona destinată informațiilor despre cartea scanată cu detaliile primite de la server.
Dacă textul citit este de forma CITITOR:12345, aplicația tratează codul QR ca aparținând unui cititor cu identificatorul 12345. Similar procesului de scanare carte, aplicația notifică utilizatorul despre rezultatul scanării și ulterior solicită serverului informații privind cititorul la adresa /service/reader-details/12345. Funcție de răspunsul primit, se populează zona destinată informațiilor despre cititor sau este alertat utilizatorul despre eroarea apărută.
După fiecare scanare, aplicația verifică dacă atât cartea cât și cititorul au fost identificate, iar dacă această condiție este îndeplinită, se activează butoanele Borrow, respectiv Return.
Butonl reset este activ în permanență, iar scopul lui este acela de a șterge din memorie informațiile privind cartea, respectiv cititorul dacă acestea au fost scanate și identificate, ceea ce permite ca o nouă acțiune să fie executată (împrumut sau returnare).
CONCLUZII
Lucrarea de diplomă ”Aplicație informatică cu citire de coduri QR pentru biblioteca tehnică” reprezintă o implementare a utilitățiitehnologieiactuale într-un mediu special în care timpul este prețios și se execută operațiuni care pot fi costisitoare din acest punct de vedere. Realitatea din jurul nostru ne obligăsăcăutăm soluții prin care să răspundem prompt unor astfel de situații.
Benficiileaduse de lucrareaprezentă au un impact major în ce privește timpul de execuție al operațiunilor împrumut-restituire și totodată propune un mod de lucru prin care procesul de returnare să fie executat aproape instantaneu. De asemenea, bibliotecarul poate săobțină informații despre istoricul unui cititor în mod aproape instantaneu. Soluția având la bază două componente celucrează împreună pentru îndeplinireaacelorași sarcini, este una foarte flexibilă, putând fi folosită chiar și atunci când sistemele de calcul din bibliotecă pot ceda temporar.
Un punct slab al acestei soluții este acela în care conectivitatea la serviciile web nu se poate realiza sau când din punct de vedere energetic, serverul care găzduiește aplicația web este stins sau nu există vreun dispozitiv la îndemână prin care să se poată realiza conexiunea la serviciile web. Pe scurt, lipsaconectivității cu serviciul web face ca întreaga soluție să nu poată fi folosită, iar în acest caz biblioteca este nevoită să apeleze la mijloaceleclasice de înregistrare, pe suport de hârtie.
În acest moment soluția propusă poate fi folosită cu succes în scopul pentru care a fost dezvoltată inițial. Este în continuare loc pentru dezvoltare, aplicația putând fi extinsă cu ușurință și pentru alte utilizări decât cea pentru care a fost proiectată. Se poate adăuga suport pentru etichete, categorii, ceea ce ar permite o mai bună filtrare a cărților, sau de ce nu, în formaactuală, se poate modifica aplicația pentru a putea fi expusă public astfel încât cititorii să se poată autentifica cu rol de cititor și să răsfoiască online disponibilitatea cărților căutate. De asemenea, o altă facilitate ar fi înscrierea pe o listă de așteptare pentru cărțile foarte solicitate, sau chiar și într-o listă de dorințe (eng. wishlist) pentru ca o carte să fie achiziționată și pusă la dispoziție cititorilor în bibliotecă.
BIBLIOGRAFIE
[1] Tanasă Ș., Olaru C., Andrei Ș.: Java de la 0 la expert, Editura Polirom, București, 2003
[2] Horga M., Radu V., Coman M., Radu V., BarbuVăcărășteanu N.: Limbajul SQL în Oracle și Visual FoxPro, Editura Bibliotheca, Târgoviște, 2007
[3] Anghel T.: Manualul tău de PHP, Editura Albastră, Cluj-Napoca, 2012
[4] Forta B.: SQL în lecții de 10 minute, Editura Teora, București, 2008
[5] Documentation, http://laravel.com/
[6] Android Studio Overview, http://developer.android.com/,
[7] Rex St. John, Android Studio vs Eclipse, https://www.airpair.com,
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Programarea In Java (ID: 150171)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.
