Prof. dr. i ng. Adina Magda Florea As. dr. ing. Andrei Olaru i UNIVERSITATEA POLITEHNICA BUCUREȘTI FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE… [612801]

UNIVERSITATEA
FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE
DEPARTAMENTUL CALCULATOARE

LUCRARE DE LICENȚĂ

Smart Presentation Feedback
Comunicația

Coordonatori științifici:
Prof. dr. i ng. Adina Magda Florea
As. dr. ing. Andrei Olaru

i UNIVERSITATEA POLITEHNICA BUCUREȘTI
FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE
DEPARTAMENTUL CALCULATOARE
LUCRARE DE LICENȚĂ
Smart Presentation Feedback
Comunicația client-server

ng. Adina Magda Florea

George- Cristian Stoica

BUCUREȘTI
2012

FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE

Absolvent: [anonimizat], în care cei prezenți în audiență nu po t interveni în niciun fel pe parcursul prezentării, astfel
încât strângerea unui feedback relevant din partea acestora este dificilă. Acest lucru se întâmplă chi ar și
în condițiile în care majoritatea persoanelor dețin un dispozitiv smartphone sau chiar o tabletă, deci un
suport electronic pe care ar putea urmări prezentar ea și prin care s-ar putea devolta o interacțiune î ntre
aceștia și speaker.
Aplicația Smart Presentation oferă oportunitatea ce lor din audiență să urmărească prezentarea
făcută de speaker pe propriul dispozitiv Android, s martphone sau tableta, în mod sincronizat cu
prezentarea speakerului sau nu. În plus, aplicația oferă posibilitatea acordării de feedback direct pe
documentul prezentării, în timp real, astfel încât speakerul să aducă lămuriri sau să răspundă la într ebări
chiar în timpul prezentării, fără intervenția verba lă a audientei. Speakerul are acces la forma agrega tă a
feedbackului, extrem de util în cazul unei audiente mari.
Pentru realizarea acestei aplicații, am dezvoltat u n sistem client-server, bazat pe cereri efectuate d e
clienți, dispozitivele Android, către un server web , care pune la dispoziție resurse ce pot fi accesat e prin
adresele lor URL. Resursele pot fi documentul preze ntării sau feedback agregat adresat de cei din
audiență.

iii
CUPRINS

1. Introducere
1.1 Contextul proiectului
1.2 Ideea și Scopul proiectului
1.3 Structura proiectului
1.4 Structura lucrării
2 Tehnologii folosite
2.1 Sistemul de operare Android
2.2 Tehnologiile specifice folosite la comunicarea client-server
2.3 Alte tehnologii folosite în cadrul proiectului
3 Arhitectura sistemului
3.1 Descrierea arhitecturii și modulele funcționale ale sistemului
3.2 Arhitectura clientului Android
3.3 Arhitectura serverului web
4 Detalii implementare
4.1 Accesarea resurselor pe baza URL și a protocolu lui HTTP
4.1.1 Structura URL
4.1.2 Tipurile mesajelor HTTP
4.2 Implementarea protocolului de comunicație
4.2.1 Componenta mesajelor și logica acestora
4.2.2 Serializarea datelor folosind Google Protocol Buffers
4.3 Implementarea clientului Android
4.3.1 Implementarea design patternului MVC
4.3.2 Persistența datelor în Sqlite și accesarea re surselor interne prin ContentProvider
4.3.3 Accesarea resurselor de pe web server prin me saje asincrone
4.4 Implementarea serverului web
4.4.1 Inițializarea serverului și a containerului Grizzly
4.4.2 Clasele resursă și metodele HTTP definite pe server
4.4.3 Serializarea și deserializarea datelor
4.4.4 Modulul de clusterizare a întrebărilor și sin cronizarea cu acesta
4.5 Interfața de utilizare a clienților Android
4.5.1 Interfațarea cu prezentarea, selecția elemen telor
4.5.2 Metodele handler ale butoanelor
5 Utilizarea aplicației
5.1 Descrierea aplicației
5.2 Scenarii utilizare – screenshots
6 Concluzii
7 Bibliografie

George-Cristian Stoica

1
1. Introducere
1.1 Contextul proiectului
Prezentările realizate în fața unei audiente de mărime medie sau mare pot fi uneori greu de urmărit
din diferite motive, cum ar fi incapacitatea persoanel or din audiență de a înțelege anumite concepte din
materialele prezentate, care duc la pierderea atenției, sau imposibilitatea acestora de a reveni asupra
unor slide-uri anterioare.
Aceste prezentări ar putea deveni mai interactive, prin implicarea ascultătorilor încă din timpul
audienței în procesul de apreciere pozitivă sau negati vă a elementelor prezentate, precum și prin
posibilitatea urmăririi prezentării atât în timp real câ t și a revenirii asupra unor slideuri anterioare sau a
avansării către slideuri următoare.

1.2 Ideea și scopul proiectului
Ideea proiectului Smart Presentation este de a reali za o interacțiune strânsă între membrii audienței
unei prezentări și cel care ține prezentarea (asupra căr uia mă voi referi în continuare ca speaker ). 1
Ca precondiții, se presupune că atât speakerul, cât și cei din audiență posedă câte un dispozitiv
mobil, tableta sau telefon mobil, având instalat si stemul de operare Android. De asemenea este necesar
un server conectat la un router wireless, pentru a perm ite conectarea cu dispozitivele Android.
Funcționalitatea aplicației pornește de la posibilit atea membrilor audientei de a urmări pe propriul
dispozitiv Android prezentarea ținută de speaker. Spea kerul este cel care pornește prezentarea, care
schimbă slide-urile și care termină prezentarea. Cei d in audiență au posibilitatea de a urmări
prezentarea în timp real și pe dispozitivul lor într-un mod live , sau pot naviga liber prin restul prezentării.
În plus, aceștia pot furniza feedback în timp real pre zentării astfel: pot selecta porțiuni din prezentare,
asupra cărora pot furniza feedback pozitiv, de apreciere, feedback de ambiguitate, prin care se remarcă
necesitatea unor clarificări ale acelor elemente sau f eedback de cerere a unor dovezi (proof). De
asemenea, cei din audiență pot pune întrebări legate de elementele selectate, sau pot alege să adere la
o întrebare deja pusă, aceștia având posibilitatea d e sincronizare a feedbackului cu cel acordat de toți
cei aflați în audiență. În plus, aceștia vor avea și posibilitatea retragerii propriului feedback, dacă ulte rior
nu îl mai consideră necesar. La finalul prezentării, s peakerul poate vedea o formă agregată pentru toate
tipurile de feedback. În cazul întrebărilor adresate sp eakerului referitor la o selecție făcută pe
prezentare, agregarea se face prin alegerea unor întrebări reprezentative din punct de vedere semantic
și gruparea (eng. c lustering ) celorlalte întrebări în jurul acestora.
Comunicarea între dispozitive și sincronizarea elemente lor de feedback acordate prezentării se face
prin intermediul unui server central care depozitează da tele agregate primite din partea tuturor
clienților cu care se comunică wireless. Serverul est e și cel care conține prezentarea în format PDF,
aceasta fiind descărcată pe fiecare dispozitiv mobil care accesează aplicația SmartPresentation.

1.3 Structura proiectului
Proiectul a fost structurat în patru module cu funcțion alități diferite, fiind cinci persoane implicate în
dezvoltarea aplicației. Cele patru arii sunt:

1 Pagina web cu ideea proiectului, 20.06.2012, <http ://aimas.cs.pub.ro/androidEDU/>

George-Cristian Stoica

2
• modulul de manipulare a prezentării PDF. Acesta presupu ne folosirea unei biblioteci open
source de manipulare a formatului PDF, pentru a permit e navigarea prin prezentare, selectarea
unor elemente ale prezentării prin folosirea ecranului to uchscreen al dispozitivului Android și
evidențierea selecției făcute prin diverse culori de h ighlighting.
• interfața clientului pe Android, care include toate el ementele vizuale prin care clientul
interacționează cu aplicația (ferestre, butoane, liste ).
• modulul de comunicație client-sever, care asigură trans misia resurselor între dispozitive și server
și sincronizarea acestora.
• modulul de clusterizare a întrebărilor puse de audință pe baza similarităților semantice.
Partea mea de proiect a constat în implementarea modu lului de comunicație între clienții Android și
server. Acest modul include partea de stocare a datelo r atât pe Android, cât și pe server, dezvoltarea
serverului web și a protocolului de comunicație bazat pe HTTP și Google Protocol Buffers, obținerea
resurselor prin URLuri, tipul mesajelor și modalitatea de serializare a acestora, precum și interfațarea pe
server cu modulul de clusterizare a întrebărilor și interf ațarea pe sistemul de operare Android cu
modulul de manipulare a PDFurilor și cu interfața de u tilizare.

1.4 Structura lucrării
În continuare, capitolele acestei lucrări sunt structura te astfel: aspecte teoretice ale proiectului,
urmate de tehnologiile folosite la implementarea proie ctului, cu detalierea celor folosite la comunicația
client-server și la crearea protocolului de comunicați e. Urmează arhitectura aplicației, în care sunt
prezentate diferitele module ale aplicației și interac țiunea dintre ele, din nou cu detalierea celor de
backend direct implicate în schimbul de date între c lienți și server. Capitolul detaliilor de implementar e
prezintă metodele de programare folosite, oferind spre ex emplificare porțiuni de cod explicate. În cadrul
acestui capitol este descris protocolul de comunicați e între server și clienți, tipurile de URLuri folosite
pentru accesul resurselor, tipurile mesajelor schimbate ș i diferitele tipuri de serializare. Mai apare și
detalierea interfațării dintre server și modulul de cl usterizare a întrebărilor de feedback.
În final, capitolul de utilizarea a aplicației prezin tă în detaliu aplicația și modalitatea de utilizare
interfeței grafice, prin screenshoturi și înfățișarea un or diverse scenarii de utilizare.

George-Cristian Stoica

3
2. Tehnologii folosite
2.1 Sistemul de operare Android
Android este un sistem de operare pentru dispozitive m obile, telefoane sau tablete. Android a
devenit lider mondial în acest segment în 2010, în p rimul trimestru al anului 2012 raportând o cotă de
59% din piața mondială a smartphoneurilor, cu un tota l aproximat la 331 milioane de dispozitive cu
acest sistem de operare instalat 1.
Android a început de la o companie mică, achiziționa tă de Google în 2005. În prezent, dezvoltarea
sistemului de operare este supervizată de Open Handset Alliance, o comunitate condusă de Google din
care mai fac parte companii că ARM Holdings, HTC, In el, LG, Motorola, Samsung Electronics, Nvidia, T-
Mobile sau Texas Instruments.
Kernelul sistemului de operare Android se bazează pe ke rnelul de Linux. Acest kernel a suferit
modificări de arhitectura realizate de inginerii Google în afara procesului tipic de devoltare a kernelului
Linux. Android nu are un sistem nativ X Window și nu suportă întregul set de biblioteci standard GNU,
ceea ce face destul de dificilă portarea aplicațiilo r și bibliotecilor existente de Linux pe Android.
Principalele modificări pe care Google le-a adus într- o prima faza kernelului au fost legate de
eficientizarea consumului bateriei. Aceste modificări au fost respinse în prima faza de dezvoltatorii
kernelului Linux de bază, motivând lipsa de încredere în intenția Google de a se ocupa în continuare de
acest cod. În 2010 s-a făcut un pas major pentru inte grarea modificărilor din Android în Linux, prin
adăugarea unui patch care îmbunătățea frameworkul de w akeup events existent și care permitea
driverelor Android să fie ușor integrate în Linux de ba ză. În August 2011 Linus Torvalds spunea că în
patru sau cinci ani Linux și Android se vor întoarce l a un kernel comun [1].
Arhitectura Android presupune existența a patru layere, c el de la baza fiind kernelul de Linux. Al
doilea layer, cel de middleware, conține biblioteci d e C. Acesta este cod nativ, rulând direct peste cel d e
Kernel. Următorul layer este cel de application framewo rk, care cuprinde biblioteci compatibile Java,
bazate pe versiunea de Java Apache Harmony.

Fig. 1 Arhitectura Android 2

1 Wikipedia, The Free Enciclopedia, 20.06.2012,
< http://en.wikipedia.org/wiki/Android_(operating_s ystem)>
2 Kebomix blog, 20.06.2012, <http://kebomix.wordpres s.com/2010/08/17/android-system-architecture/>

George-Cristian Stoica

4
Mașina virtuală care face translația din codul Java î n byte-code se numește Dalvik virtual machine, și
se deosebește de mașina virtuală clasică JVM prin fap tul că nu este o mașină bazată pe stivă, ci una
bazată pe regiștri. Un tool numit dx este folosit pentru a converti o parte a fișierelor .c lass Java într-un
format .dex. Mai multe clase sunt incluse într-un si ngur fișier .dex. Stringurile duplicate și alte consta nte
folosite în mai multe fișiere class sunt incluse do ar o dată în outputul .dex, pentru conservarea spațiu lui.
Java bytecode-ul este de asemenea convertit într-un set de instrucțiuni definit de Dalvik Virtual
Machine. Un fișier necomprimat .dex este sensibil ma i mic decât o arhivă .jar, derivată din aceleași
fișiere .class. O altă diferență majoră față de clasi cele JVM este introducerea compilatorului JUST-IN-
TIME, care reprezintă o metodă hibridă față de cele do uă metode clasice de runtime (intrepretat sau
static – cod compilat). Astfel, acest compilator tran slatează codul din bytecode în machine code la
runtime, înainte de a-l rula nativ.
Fiecare aplicație Android rulează în propriul proces cu propria instanță a mașinii virtuale. Dalvik a
fost dezvoltat în așa fel încât un dispozitiv poate rula mai multe mașini virtuale eficient. Mașina virt uală
Dalvik se bazează pe kernel-ul Linux pentru funcționa litățile de bază, cum ar fi gestionarea thread-urilor
și menținerea nivelului de memoriei scăzut.
Layerul de application framework cuprinde acele servicii scrise în Java care fac legătura între aplicații
și sistemul de operare, fiind separate pe diverse funcț ionalități: Activity Manager, Content Providers,
Resource Manager, Notification Manager, View System , Telephony Manager, Location Manager și altele.
Layerul de top este cel al aplicațiilor, unde dezvol tatorii pot adăuga noi aplicații utilizând API-ul ex istent
sau pot modifica aplicațiile deja existente.
În prezent, Android are o vastă comunitate de dezvolta tori care scriu aplicații („apps”) care extind
funcționalitatea dispozitivelor. Dezvoltatorii folose sc în principal codul versiunii custom de Java.
Applicațiile pot fi descărcate de pe magazine online ca Google Play (fostul Android Market), magazinul
condus de Google. În octombrie 2011 erau mai mult de 500 000 aplicații disponibile pentru Android.
În cadrul proiectului Smart Presentation, o mare parte di n devoltare s-a făcut pe sistemul de operare
Android, folosind versiunea 2.3 a sdk-ului Android. D ezvoltarea s-a făcut în Eclipse, acesta fiind mediul
standard și global folosit pentru crearea aplicațiilor Android, datorită pluginului Android și a
emulatorului care poate fi lansat direct din interfața IDEului.
În cadrul dezvoltării, am folosit atât cod nativ C, c ât și cod standard Java. Codul nativ face parte din
biblioteca mupdf, pe care am folosit-o la manipularea prezentării în format PDF, pentru partea de
selecție. Codul nativ a fost compilat folosind tool ul ndk, biblioteca rezultată putând fi încărcată direc t în
codul de Java.
Pentru modulul client-server, am folosit design patte rnul Model-View-Controller, detaliat la capitolul
Arhitectura sistemului. Pentru implementarea acestui pa ttern am folosit clasele existente în API-ul
Android, care încurajează separarea ariei funcționale, co municarea pe retea sau persistența datelor, de
interfața grafică a aplicației, pentru a se asigura un flow continuu al interfeței, fără întreruperi care ar
dăuna calității utilizării. Principalele mecanisme f olosite sunt cel de ContentProvider, care returnează
activității de frontend conținut pe baza unor interogă ri (echivalent conceptului de Model). În cadrul
ContentProviderului, persistența datelor este asigurată printr-o bază de date SQLlite, iar comunicarea cu
serverul wireless se face asincron, în cadrul unor thread uri separate. Pentru rularea acestor taskuri, API-
ul Android pune la dispoziție numeroase soluții, cea mai populară fiind cea de a extinde clasa AsyncTask ,
aceasta oferind metode handler pentru execuție și pent ru returnarea rezultatelor.

George-Cristian Stoica

5
2.2 Tehnologiile specifice folosite pentru comunicarea client-server
Pentru crearea serverului central, responsabil cu central izarea feedbackului de la clienți, distribuția
acestuia către clienți și persistența datelor, am av ut de ales între multiple tehnologii disponibile, c um ar
fi realizarea unei comunicații asincrone pe socketi s au implementarea unui mecanism de Remote
procedurce calling. Alegerea cea mai potrivită mi s-a părut în final implementarea unui web service,
datorită protocolului de nivel superior, Hypertext trans fer protocol, care asigură o bază pentru
dezvoltarea unui mecanism facil de acces la date. De asemenea, acest protocol permite schimbul datelor
în mai multe formate, atât de tip binar cât și plain text, prin completarea headerului de mime-type.
Un alt punct forte al alegerii unui sistem client-se rver bazat pe protocolul HTTP este portabilitatea,
fiecare limbaj de programare având biblioteci care faci litează crearea mesajelor HTTP și
transmiterea/recepționarea lor pe baza URLului. Datorită folosirii unui limbaj compatibil Java pe
Android, eu am ales tot Java pentru devoltarea serverul ui web. Tehnologia Java pentru crearea web
serverelor se bazează pe o arhitectură de tip servlet-co ntainer, care permite definirea unor scripturi Java
(servlets) și înregistrarea acestora, de obicei într-un fișier de configurare xml, pentru a fi încărcate
dinamic într-un container web. Un container web est e acea componentă a unui serviciu web care
interacționează cu servleturile și este responsabilă c u managementul ciclului de viață a acestora și cu
maparea lor la un URL. Un web container implementează contractul unei componente web Java EE,
specificând un mediu de runtime care asigură securitate a, concurența, managementul ciclurilor de viata,
completarea tranzacțiilor și alte servicii.
În cazul acestei aplicații, pentru implementarea serve rului web am ales să folosesc un web container
Glassfish, bazat pe popularul Tomcat. Pentru interacți unea cu acest container am folosit API-ul Grizzly,
care va fi detaliat într-un subcapitol următor. Pent ru maparea resurselor http unor metode http și a
unor URLuri, am folosit frameworkul Java Jersey, o sol uție care respectă arhitectura RESTful, cea mai
folosită în momentul de față pentru dezvoltarea servic iilor web.
Protocolul HTTP
Hypertext Transfer Protocol, pe scurt HTTP, este un prot ocol la nivelul aplicație care stă la fundația
comunicației în World Wide Web. Hypertext reprezintă un set de obiecte care construiesc conexiuni
între noduri prin legături logice, hyperlinks. HTTP este protocolul care permite transferul unor astfel de
obiecte 1.
HTTP este un protocol de tip cerere-răspuns în modelu l arhitectural client-server. Un client, cel mai
des un web browser, trimite o cerere HTTP către un serv er web, care întoarce un răspuns. Acest răspuns
conține o stare al completării cererii și, în caz de su cces, informația cerută.
Resursele HTTP sunt identificate și localizate pe re țea prin Uniform Resource Locators (URLs)
folosind schema http URI definită în RFC 3986 astfe l:
<nume_schema> : <porțiunea_ierarhică> [ ? <query> ] [ # <fragment> ]
În cazul HTTP numele schemei este http. Partea ierarh ică începe cu un dublu forward slash "//",
urmat de un nume al autorității, care poate fi un nume de domeniu sau un ip, urmat apoi de un port
opțional, precedat de ":". După autoritate urmează un path construit ca o succesiune de segmente,
asemănător unei structuri de directoare, caracterul sep arator fiind "/". Porțiunea de query este
opțională, începe cu "?" și conține informație adiț ională care nu este ierarhică, ci organizată tipic prin
perechi de tip <cheie>=<valoare>, cu perechile separate prin ";" sau "&". Partea fragmentului este de

1 Wikipedia, The Free Enciclopedia, 20.06.2012, < ht tp://en.wikipedia.org/wiki/Http>

George-Cristian Stoica

6
asemenea opțională, începe cu "#" și conține o dire ctivă către o resursă secundară, cel mai des un
atribut id al resursei principale, așa cum se întâmplă în cazul documentelor HTML.
HTTP definește nouă metode care indică acțiunea dori tă asupra resursei accesate. Aceste nouă
metode sunt: HEAD, GET, POST, PUȚ, DELETE, TRACE, O PTIONS, CONNECT și PATCH. Cele mai utilizate
sunt cele de GET, prin care se citește resursa, și cel e de POST, PUT și DELETE, prin care se modifică
resursa. Metodele safe (sigure) sunt considerate cele p rin care se intenționează doar citirea informației,
fără modificarea stării serverului. Acestea sunt HEAD, GET, OPTIONS și TRACE. Metodele idempotente
sunt cele asupra cărora mai multe cereri identice ar tre bui să aibă același efect. Acestea sunt POST și
DELETE.

O cerere HTTP conține următoarele :
• o linie de request, spre exemplu GET /diverse/car.jpg H TTP/1.1 care formulează o cerere pentru
resursa /diverse/car.jpg de la server.
• Headere Http, cum ar fi Accept-Language: en-US, Acce pt-Charset: utf-8, etc.
• O linie goală
• Un corp al mesajului, opțional
Un răspuns HTTP conține următoarele:
• linie de Status (spre exemplu HTTP/1.1 200 OK, care indică finalizarea cu succes a cererii
clientului). Un status 3xx indică necesitatea unei redirectari, 4xx și 5xx sunt statusuri de eroare
(4xx – eroare la client, 5xx- eroare la server).
• Headere HTTP, cum ar fi Content-Type: text/html
• O linie goală
• Un corp al mesajului, opțional
Antetele HTTP sunt perechi "cheie: valoare", scrise în clear-text și separate prin succesiunea de
caractere carriage return (CR) și line feed (FD). Aceste headere definesc parametrii de operare a unei
tranzacții HTTP.
Datorită necesității trasmiterii unor tipuri diferite de conținut prin mesajele HTTP, am folosit în
cadrul aplicației Smart Presentation setarea headerului Content-Type prin care se specifică mime-typeul
conținutului. Un mime-type (Multipurpose Internet Mail Extension) este un stand ard Internet care a
pornit de la descrierea seturilor de caractere folosite l a formatul email, ajungând azi să fie utilizat ca
standard de descriere al conținutului unui mesaj web în general. Un astfel de antet descrie atât
conținuturi de tip text, cât și conținut binar. În ca zul clienților și al serverului, interpretarea acestui câmp
este vital pentru alegerea modului în care resursa este citită, respectiv scrisă.
Pentru aplicația Smart Presentation, am folosit următo arele tipuri mime:
• text/plain – definește un conținut în text clar, nec odat.
• application/pdf – indică prezența unui fișier PDF î n interiorul mesajului, în format binar
• application/x-protobuf – indică un conținut binar, se rializat cu Google Protocol Buffers. Este
datoria clientului și a serverului de a serializa, res pectiv deserializa acest format binar.

George-Cristian Stoica

7
Grizzly Web Container
Grizzly este un framework web născut din dorința de a a juta dezvoltatorii să profite de avantajele
API-ului Java NIO (Java new I/O). Este devoltat de comunitatea GlassFish, sub conducerea Oracle 1. Până
la apariția acestui API, scrierea unor aplicații serve r scalabile în Java era foarte dificilă, problemele de
thread management făcând imposibilă scalarea unui serv er la mii de utilizatori. Scopul Grizzly este
dezvoltarea unor sisteme server robuste și scalabile, of erind componente extinse ale frameworkului
Java NIO ca:
– un framework HTTP Protocol pentru crearea unor aplicaț ii HTTP costumizate;
– un framework HTTP Server care oferă abstractizări la ni vel înalt ale protocolului HTTP (similare
Servlets).
Grizzly folosește un sistem keep-alive bazat pe cla sele Selector ale NIO, care suportă monitorizarea
conexiunii și previn atacurile de tip Denial-of-Servi ce. Sistemele Denial-of-Service adăugă suport pentru
validare IP, numărul tranzacțiilor completate per IP, d etecția conexiunilor inactive, cu scopul de a
preveni epuizarea sau atacurile "flooding". Toate aces te servicii sunt folosite în conjuncție cu sistemele
Keep-alive. Conectorul Grizzly va înainta cererile pent ru resursele statice și dinamice către containerul
servleturilor, care procesează cererile pentru resurse sta tice într-un servlet dedicat
(org.apache.cătălina.servlets.DefaultServlet) [5].
Servicii Web RESTful și Jersey JAX-RS
Representational State Transfer (REST) reprezintă un sti l arhitectural bazat pe standardele web și pe
protocolul HTTP, pentru sisteme distribuite că World Wi de Web. REST s-a evidențiat în ultimii ani ca
modelul de design predominant al web-ului, datorită s implității sale. REST a fost descris în 2000 de Roy
Fielding, în lucrarea sa de doctorat 2.
Într-o arhitectură bazată pe REST, totul este o resur să. O resursă este accesată printr-o interfață
comună bazată pe metodele standard HTTP. Într-o arhit ectură REST, există tipic un server REST care
asigură accesul la resurse și clienți REST care accesea ză sau modifică resursele. Fiecare resursă ar trebui
să suporte operațiile standard HTTP (GET, POST, PUȚ, D ELETE). Resursele sunt identificate prin ID-uri
globale – URIuri.
"Limbajul" REST este bazat pe substantive și verbe ș i pune accentul pe lizibilitate. Spre deosebire de
SOAP, REST nu necesită parsare XML și nu necesită un header al mesajului de la/către un service
provider, ceea ce duce la reducerea bandwidth-ului cons umat. REST are și o altă metodologie de
manipulare a erorilor: în timp ce SOAP poate avea mesaj e definite de eroare, REST necesită folosirea
mecanismelor HTTP de error handling .
Stilul arhitectural REST impune anumite direcții de lu at în considerare la realizarea designului,
implementarea componentelor individuale fiind la dis creția dezvoltatorului:
Client-server – o interfață uniformă separă clienții de servere. Separarea preocupărilor înseamnă că,
spre exemplu, clienții nu se ocupă de stocarea datelo r, așa cum serverul nu se ocupă cu interfața
utilizatorilor sau cu starea clienților. Astfel, serv erele și clienții pot fi dezvoltați independent, in terfața
rămânând constantă.

1 Grizzly website, 20.06.2012, < http://grizzly.java .net/>
2 Roy Fielding, "Architectural Styles and the Design of Network-based Software Architectures", 20.06.201 2,
<http://www.ics.uci.edu/~fielding/pubs/dissertation /top.htm>

George-Cristian Stoica

8
• Stateless – acest principiu asigură că niciun contex t al clientului nu este memorat pe server între
cereri. Fiecare cerere efectuată conține toate informaț iile necesare, și orice informație de stare
a sesiunii este stocată pe client. Aceasta este o c aracteristică de rezistență la erori a serverelor.
• Cacheable – clienții pot reține în cache răspunsurile . O memorie cache bine întreținută poate
îmbunătăți scalabilitatea și performanța sistemului, prin reducerea numărul de cereri de la
clienți la server.
• Layered – un client nu-și poate da seama prin interf ata comună dacă este conectat direct la
server sau la un proxy intermediar. Servere intermediare pot îmbunătăți scalabilitatea
sistemului prin load-balancing sau prin partajarea unei memorii cache.
• Code on demand (opțional) – serverele pot să extindă temporar funcționalitatea clientului prin
transferul codului – exemple fiind Java applets sau limbajele client-side scripting ca JavaScript.
Un WebService RESTful se bazează pe metodele HTTP și pe conceptele arhitecturii REST. Acesta
definește tipic un URI de baza pentru resurse și tipuri le MIME suportate (XML, Text, JSON, Protocol
Buffers, etc) și setul de operații HTTP. Aceste metod e standard sunt [6]:
• GET – definește un acces la citirea unei resurse, fără efecte secundare. Resursa nu este niciodată
alterată în urma unei cereri GET.
• PUT – crează o nouă resursă, trebuie să fie idempotent ă.
• DELETE – șterge o resursă; operația trebuie să fie idemp otentă, o repetare a cererii nu trebuie să
producă efecte suplimentare primei cereri.
• POST – actulizează resursa existentă sau crează o nouă resursă.
Jersey reprezintă implementarea Java open source, de referință , la calitate de producție a
standardului JAX-RS (JSR 311) pentru dezvoltarea web s erviceurilor RESTful. Dar este mai mult decât
implementarea referinței, oferind și un api prin care pro gramatorii pot extinde Jersey pentru nevoile
proprii [7]:
Standardul JAX-RS implementat de Jersey suportă următoa rele anotatii (annotations) pentru crearea
resurselor web:
Adnotare Descriere
@PATH(my_path) setează patul la URL de baza + "/" + my_path. URL -ul de baza este cel definit ca
URL al containerului de bază, în web.xml sau în apli cație, în cazul folosirii unui
container că Grizzly
@POST indică faptul că metoda va răspunde unei cereri POST
@GET indică faptul că metoda va răspunde unei cereri GET
@PUT indică faptul că metoda va răspunde unei cereri PUT
@DELETE indică faptul că metoda va răspunde unei cereri DE LETE
@Produces(mime-
type [, more types]) definește ce mime -type va avea conținutul returnat l ao metoda adnotată cu
@GET. Mime-tipurile pot fi de tip "plain/text" sau b inare, că "application/pdf"
sau "application/x-protobuf". Alte exemple: "applica tion/xml",
"application/json"

George-Cristian Stoica

9
@Consumes(mime –
type [, more types]) Definește ce mime-type este consumată de această me todă, PUȚ sau POST
@PathParam Folosita pentr a injecta valori din URL că parametru al metodei. Se folosește
spre exemplu la obținerea ID-ului resursei din cadrul URLului, pentru
returnarea resursei corecte
@QueryParam Leagă parametrul de o valoarea unui parameru de interogare HTTP
@HeaderParam Leagă parametrul de valoarea unui header HTTP

Google protocol-buffers
Protocolul HTTP este un protocol care permite definire a oricărui format de serializare a conținutului
propriu-zis al pachetului, atât timp cât și emițătorii și receptorii definesc programatic metode de citire și
scriere a acelor mesaje. Limbajul de facto folosit încă pentru schimbul de date este XML, dato rită
simplității sale și ușurinței de citire. Totuși, din dorința optimizării utilizării benzii de transfer , în d auna
lizibilității, în cazul mesajelor mari sau a situațil or în care există necesitatea schimbului unui număr
foarte mare de mesaje, au câștigat teren și formatele d e serializare binare [9].
Pentru serializarea mesajelor de mărime potențială mare, am folosit soluția Google Protocol Buffers,
un mecanism extensibil, neutru din punct de vedere a l limbajului și al platformei pentru serializarea
binară a datelor, reprezentând o variantă mult mai efici entă față de XML și JSON. Acest mecanism a fost
dezvoltat de Google pentru uz intern, aceștia creând c ompilatoare pentru C++, Java și Python disponibile
publicului larg printr-o licență open source.
Designul Protocol Buffers pune accentul pe simplitat e și performanță. A fost devoltat special pentru
a crea o alternativa mai compactă și, deci, mai rapidă decât XML. Metoda de creare a mesajelor Protocol
Buffers are la bază un limbaj de descriere a interfeței (IDL) care descrie structura datelor într-un format
foarte simplu. Aceste "mesaje" sunt definite într-un fișier de definire Proto (.proto) care este compilat cu
un executabil protoc. Compilarea generează cod care po ate fi invocat de destinatarul sau receptorul
acestor structuri de date. Clasele generate pun la disp oziția programatorului metode Get și Set pentru
câmpurile mesajelor, asigurând citirea și manipularea f acilă a acestora. De asemenea, se pot defini
mesaje încapsulate în cadrul altor mesaje, care în mo d programatic vor fi translatate în clase inner. O
altă facilitate a claselor generate dinamic este posi bilitatea obținerii unei instanțe a mesajului direct din
streamul de octeți.
În mod canonic, Protocol Buffers sunt serializate înt r-un format binar care este compact, forward-
compatible și backwards-compatible. Datorită simplită ții și a vitezei sale, acest format și-a extins
popularitatea dincolo de comunicarea pe retea la cea între procese sau sisteme scrise în limbaje de
programare diferite, care suportă serializare/deserializare Google Protocol Buffers.

message MessageExample
{
required int32 id = 1;
requird string messageName = 2;
enum Type
{
TYPE1 = 1;
TYPE2 = 2;
}

George-Cristian Stoica

10
required Type type = 3;
message EmbeddedMessage
{
required int64 id = 1;
required string label = 2 [default = "SAMPLE"];
}
repeated EmbeddedMessage internalLabels = 4;
}

Exemplu Protocol Buffers
După cum se poate observa, formatul .proto este foarte intuitiv, foarte facil de scris și permite o
mapare la tipuri de date și structuri de date de bază î n toate limbajele de programare populare:
stringuri, tipuri numerice de date, liste, dar și concep te de programare orientată obiect, cum este
încapsularea.
Astfel, eficiența acestui mecanism de serializare est e dată atât de dimensiunea extreme de redusă a
pachetului care este transferat pe retea, cât și de de modul foarte succinct și compact de definire a
formatului mesajului. Aceste aspecte sunt net superio are limbajului XML, motiv pentru care foarte
multe aplicații folosesc astăzi acest mecanism de s erializare. Dezavantajul Google Protocol Buffers față
de XML este acela că nu e human-readable, fiind un l imbaj binar prea puțin important însă pentru
aplicații care nu pun accentul pe urmărirea conținutulu i mesajului între procesele de serializare și
deserializare.

Fig. 2 Comparație Xml – Google Protocol Buffers 1
În cadrul proiectului Smart Presentation, am folosit Pro tocol Buffers la transmiterea între client și
server a feedbackului acordat de ascultători sub forma de întrebări puse asupra unor elemente selectate
din prezentare. Serverul este cel responsabil de serializ area clusterului de întrebări, mesajul proto fiind
prezentat în detaliu la capitolul detaliilor de imple mentare.

1 Alternative to XML – Protocl Buffers. 20.06.2012, <http://afrozahmad.hubpages.com/hub/protocolbuffers >

George-Cristian Stoica

11
2.3 Alte tehnologii folosite în cadrul proiectului
Formatul PDF
Pentru reprezentarea documentelor am ales formatul PDF (Portable Document Format), motivul
principal fiind reprezentat de popularitatea acestui și de unele avantaje tehnologice clare.
PostScript care este limbajul de programare interpretat a flat la baza formatului. Scopul său principal
este de a descrie modul de randare a textului, formelor și imaginilor grafice. Acesta oferă, de asemenea,
un cadru pentru controlul dispozitivelor de imprimare. Deși PostScript și PDF sunt înrudite, sunt formate
diferite. PDF folosește capacitatea limbajului PostS cript de randare de stiluri complexe de text și grafică
și aduce această caracteristică atât pe ecran, cât și la imprimare. Pentru PDF s-a ales o flexibilitate
redusă în favoarea unei eficiențe și unei predictibil ități mai bune. Spre deosebire de PostScript, PDF
poate conține o mulțime de structuri de document, lin k-uri, precum și alte informații conexe, dar nu
poate schimba rezoluția, sau să folosească orice alte caracteristici specifice hardware.
Sintaxa PDF poate fi împărțită în patru părți [4]:
• Obiecte. Un document PDF este o structură de date com pusă dintr-un set redus de tipuri de obiecte.
PDF include opt tipuri de baza de obiecte: valori boo lene, numere întregi și reale, șiruri de caractere,
nume, vectori, dicționare, fluxuri de date și obiectul null.
• Structura fișierului. Structura fișierului PDF determină cum sunt stocate în fișier obiectele, cum sunt
accesate și cum sunt modificate. Această structură es te independentă de sintaxa obiectelor.
Structura fișierului PDF este formată din următoarele pa tru elemente:
o Un antet format dintr-o singura linie specificând ve rsiunea PDF.
o Un corp conținând obiectele ce compun documentul.
o Un tabel cross-reference conținând informații despre obiectele indirecte din fișier
o Un trailer oferind locația tabelului cross-reference.
Structura iniațială poate fi modificată ulterior, ceea ce adăugă elemente adiționale la finalul
fișierului.
• Structura documentului. Structura documentelor PDF spec ifică modul cum obiectele de bază sunt
folosite pentru reprezentarea componentelor unui docu ment: pagini, fonturi, adnotări etc.
Catalogul documentului este un dicționar care conțin e referințe la alte obiecte care definesc
conținutul, cuprinsul, threaduri de articole, nume de d estinații și formulare interactive
Paginile documentului sunt acesate printr-o structură cunoscută ca arborele de pagini (eng.
page tree), care definește ordonarea de pagini în docum ent. Folosind această structură
arborescentă aplicațiile de citit PDFuri care folosesc o cantitate limitată de memorie, pot deschide
imediat un document conținând sute de pagini. Arbore le conține noduri de două feluri: noduri
interne reprezentate de arborii de pagini și frunze repre zentate de obiectele pagină.
• Fluxuri de date. Un flux de date PDF conține o secve nță de instrucțiuni care descriu modul de
apariție al paginii sau alte entități grafice. Aceste instrucțiuni, deși sunt reprezentate că obiecte, sun t
diferite din punct de vedere conceptual de obiectele folosite în descrierea structurii documentului.

George-Cristian Stoica

12
Datele dintr-un flux de date de conținut sunt interp retate ca o secvență de operatori și operanzii
acestora. Un flux de date de conținut poate descrie m odul de prezentare a unei poze sau poate fi
tratat ca un element grafic în alte contexte.
Sistemul de coordonate definește spațiul în care randarea are loc. Determină p oziția, orientarea și
dimensiunea textului, graficelor și imaginilor ce apa r pe pagină (Figura 3).
Conținutul unei pagini apar în cele din urmă pe un di spozitiv de ieșire raster, cum ar fi un ecran sau o
imprimantă. Asemenea dispozitve variază în sistemul d e coordinate folosit pentru a adresa pixeli.
Sistemul particular al unui dispozitiv se numește sp ațiul dispozitv (eng. device space ). Originea sistemului
de coordinate al dispozitivelor poate fi în locuri dif erite, de asemnea și axele pot avea orientări diferite.
Pentru a evita dependența de dispozitiv, PDF defineș te un sistem de coordonate independent de
dispozitiv. Acest sistem de coordonate se numește sp ațiul utilizator (eng. user space ).

Fig. 3 Relațiile dintre sistemele de coordonate (im agine preluată din ISO 32000-1)
Pe lângă aceste două sisteme de coordonate PDF mai f olosește și alte spații de coordonate [4]:
• Coordonatele pentru text va fi specificat în spațiul text. Transformarea din spațiu text în spațiu
utilizator va fi definit de o matrice în combiantie c u alți parametrii specifici textului respectiv.
• Simbolul unui caracter dintr-un font este definit în spațiul simbol (eng. glyph space ).
Transformarea din spațiul simbol în spațiul text va f i realizată de matricea de font.
• Toate imaginile vor fi definite în spațiul imagine. Transformarea din spațiul imagine în spațiul
utilizator este predefinit și nu poate fi modificat.
Biblioteca MuPDF
MuPDF este o bibliotecă software gratuită și open sou rce dezvoltată în C care implementează un
motor de parsare și randare de PDF-uri și XPS-uri. Aces ta este utilizat în principal pentru a face pagini î n
bitmapuri, dar oferă de asemenea suport pentru alte ope rațiuni, cum ar fi căutarea, listarea cuprins și
hyperlinkuri. Motorul de randare în MuPDF este adaptat p entru grafică de înaltă calitate. Aceasta
randează textul cu o precizie de fracțiuni de pixel pentru o calitate cât mai bună în reproducerea
aspectului unei pagini imprimate pe ecran.
Motivul pentru care a fost ales pentru acest proiect muPDF îl reprezintă caracteristicele de baza ale
acestuia. MuPDF are o dimensiune redusă de cod, este rapid și, cu toate acestea , complet. Aceasta
susține PDF 1.7, cu transparență, criptare, hyperlinkuri , adnotări, căutarea în text și mai multe. Suportă,
de asemenea, și documente OpenXPS. Nu oferă suport pe ntru caracteristici interactive, cum ar fi

George-Cristian Stoica

13
completare de formulare sau JavaScript. Un alt avanta j pentru care am ales MuPDF este acela că este
foarte bine modularizat, astfel încât alte caracteristi ci pot fi adăugate dacă se dorește acest lucru.
Există un număr de aplicații software gratuite care folosesc MuPDF pentru a randa documente PDF,
cel mai important fiind Sumatra PDF. MuPDF este, de a semenea, disponibil ca pachet pentru Debian,
Fedora, FreeBSD Ports și OpenBSD Ports.
MuPDF folosește o structură de date complexă pentru re prezentarea internă a documentului PDF,
de care se folosește pentru a manipula fișierul pentru diferite funcționalități, precum randare a
paginilor, extragere de text, de imagini, căutare în text etc. Practic realizează o copie în memorie a
fișierului PDF aflat pe hard. Folosirea acestei structu ri care e completată cu date efective din fișierul PDF
facilitează realizarea de noi funcționalități, cum a fost și cazul acestui proiect.

George-Cristian Stoica

14
3. Arhitectura sistemului
3.1 Descrierea arhitecturii și modulele funcționale ale sistemului
Arhitectura sistemului aplicației Smart Presentation este de tip client-server, clienții fiind, din punct
de vedere logic, de două tipuri: speakerul, cel care ț ine prezentarea și cei din audiență. Clienții au în
general două posibilități: să trimită date către serve r, precum în cazul feedbackului, sau să interogheze
serverul pentru resurse, spre exemplu documentul PDF, sl ideul curent al prezentării sau forma globală,
agregată a feedbackului curent (Figura 4).
Serverul aplicației are rolul de a stoca resursele comun e tuturor. Aceste resurse pot fi statice, cum
este cazul documentului PDF, sau pot fi dinamice, c um e cazul elementelor de feedback sau a slide-ului
curent al speakerului. În ambele cazuri, serverul are ro lul de a centraliza datele și de a le pune la
dispoziția clienților, prin adrese URL.
În cazul resurselor dinamince, serverul poate avea doar ro lul de stocare, astfel încât orice client să
poată accesa resursa, sau poate avea și un rol de prelu crare, cum ar fi în cazul elementelor de feedback.
Aceste resurse sunt refăcute la primirea oricărui feedback , astfel încât răspunsul la o cerere să conțină o
formă agregată a feedbackului.

Fig. 4 Arhitectura globală a sistemului

George-Cristian Stoica

15
3.2 Arhitectura clientului Android
Clientul Android implementează o arhitectură Model-Vie w-Controller, care se caracterizează prin
separarea clară a funcționalității celor trei module fun cționale:
• View – interfața grafică, alcătuită din totalitatea b utoanelor, ferestrelor și elementelor cu care
utilizatorul interacționează direct;
• Controller – totalitatea handlerelor care sunt declanșa te de utilizarea elementelor interfeței
grafice. În cadrul acestor handlere, sunt formulate int erogări asincrone către model sau către
server pentru obținerea datelor.
• Model – modulul care are rolul de persistenta a datel or și care poate face cereri pe rețea.
Interfața este actualizată prin returnarea răspunsurilor de la server, asincron. Aceste răspunsuri pot
veni prin intermediul Modelului, dacă cererea este fă cută intermediar la Model, în cazul aplicației
Android acesta fiind implementat prin clasa ContentProvider . O altă variantă a actualizării vizuale este
prin întoarcerea valorii direct prin execuția asincronă a unei cereri către server, caz în care controllerul
este responsabil cu efectuarea cererilor către server.
O altă componenta de bază a modelului este baza de date, care este folosită pentru stocarea
informațiilor de feedback, sau a informațiilor proprii clientului, cum ar fi date legate de propriul
feedback. Aceste date se obțin prin interogarea conte nt providerului, care poate decide dacă este
nevoie de o actualizare a datelor prin cereri către serv er.
Mai jos se află o diagramă UML care descrie principalel e componente ale Modelului, clasa content
providerului și cele care deservesc bazei de date comu nicării cu serverul (Figura 5):

Fig. 5 Diagrama UML a arhitecturii MVC implementată prin ContentProvider

George-Cristian Stoica

16
3.3 Arhitectura serverului web
Serverul central are două componente, care rulează pe th readuri separate:
• un server web, care răspunde la cereri HTTP pentru resurs e;
• un modul de grupare (eng. clustering ) pe baza similarităților semantice a întrebărilor de
feedback. Acest modul comunică doar cu cealaltă comp onenta a serverului.
În cazul serverului web, există un thread principal cu un entry point din care se rulează serverul. În
acest thread se inițializează pachetele claselor resu rsă, care sunt încărcate în background, comunicația
facându-se prin crearea de threaduri secundare. Responsab il cu crearea și managementul acestor
threaduri este containerul Grizzly.
Pentru stocarea datelor, am implementat o arhitectură d e stocare ierarhică, formată din containere
pentru diferitele tipuri de date (Figura 6).

Fig. 6 Diagrama UML a arhitecturii de stocare pe se rver

George-Cristian Stoica

17
Resursele HTTP care sunt disponibile la interogarea se rverului web sunt implementate în clase
specifice, care definesc metode programatice de interpre tare a pachetelor HTTP și de alcătuire a
răspunsurilor în cazul unor cereri (Figura 7).
În cazul resurselor dinamice, cum ar fi feedbackul de l a utilizatori, serverul poate modifica resursa
prin executarea unor operații interne, cum ar fi increment area numărului de feedbackuri pozitive asupra
unei selecții (mapate la un URL) sau reclusterizarea întrebărilor pentru o selecție. În cazul al doilea,
serverul procesează clusterizarea semantică într-un threa d separat. Sincronizarea cu acesta se face
printr-un lock și prin resurse de memorie comune, aflate în MemoryStore.

Fig. 7 Diagrama UML a claselor resursa UML și a met odelor de prelucrare

George-Cristian Stoica

18
4. Detalii de implementare
4.1 Accesarea resurselor pe baza URL și a protocolu lui HTTP
Aplicația SmartPresentation se bazează pe o arhitectu ră client-server, având în centru un server cu
următoarele roluri:
• stochează prezentarea pe care clienții cu dispozitive Android o descărcă la deschiderea
aplicației;
• menține evidența slideului curent al prezentării la c are se află speakerul, oferind posibilitatea
clienților de a-și sincroniza propria copie a prezentă rii cu cea a speakerului, prin folosirea
modului "Go live!";
• centralizează feedbackului primit de la clienți, stoc ând toate tipurile de feedback;
• răspunde la cereri de la clienți pentru feedbackul agre gat;
• rulează modulul de grupare pe baza semantică a întrebări lor puse de cei din audiență și
serializează structurile de date procesate de acest mo dul.
Pentru implementarea serverului am ales o soluție de web service, datorită existenței unor
soluții multiple de frameworkuri astfel de servicii și datorită simplității accesării resurselor, prin Uniform
Resource Locator.

4.1.1 Structura URLului
Containerul Grizzly folosit pentru stocarea resurselor http oferă posibilitatea setării la rulare a unui
URL de bază, la care serverul web poate fi accesat. Î n cazul de fata, URL-ul de baza al serverului este
format dintr-un IP și un port. În cazul stației pe ca re rulează serverul, acest URL are forma
http://localhost:9998/, numele “localhost” fiind tra nslatat local in ip-ul 127.0.0.1. În cazul cliențil or,
aceștia vor avea posibilitatea accesării serverului pri n ip-ul public al acestuia, care se setează indepen ent
de server la rularea acestuia, în funcție de setările ru terului wireless care asigură comunicația.
API-ul Jersey permite crearea unor clase resursă http, pentru care se definește prin adnotarea @Path
porțiunea de URL care se adăugă URL-ului de baza al serverului. O adnotare de tipul
@Path("/myresource") aplicată în cazul unei clase va face disponibilă re sursa http la adresa
http://localhost:9998/myresource , în cazul accesului de pe mașina locală care rulează serverul,
spre exemplu dintr-un browser rulat local.
Pentru aplicația Smart Presentation, am definit mai mult tipuri de URL-uri, în funcție de resursele
accesate. Acestea sunt prezentate în continuare prin p orțiunea caracteristică resursei, care se adăugă
adresei de bază:
• /presentation : această adresa este accesată la pornirea aplicației Smart Presentation pentru
descărcarea prezentării PDF stocate pe server;
• /containers/slidecontainer/slide – adresa la care este reținut slideul curent la care se află
prezentatorul. Prin accesul la această resursă, utilizat orii pot sincroniza prezentarea cu cea a
speakerului. Speakerul actualizează această resursa aut omat la schimbarea slideului;
• /containers/positivefeedback/[selection_id] – aceasta este resursa la care se reține
numărul de feedbackuri pozitive care au fost acordate pe o selecție din prezentare, reprezentată
de un id, număr întreg, al selecției;

George-Cristian Stoica

19
• /containers/ambiguousfeedback/[selection_id] – aceasta este resursa la care se reține
numărul de feedbackuri de tip ambiguu care au fost ac ordate pe o selecție din prezentare;
• /containers/prooffeedback/[selection_id] – aceasta este resursa la care se reține
numărul de feedbackuri de tip proof/citation needed ca re au fost acordate pe o selecție din
prezentare;
• /containers/questions/[selection_id] – aceasta este resursa la care se găsește forma
agregată binar a întrebărilor puse pe selecție, grupate î n clustere (liste) de întrebări similare din
punct de vede semantic;
Pe lângă cele de mai sus, am mai definit patru resur se care sunt create și actualizate de server, la
primirea oricărui tip de feedback. Acestea sunt cele de feedback agregat pentru toată prezentarea,
necesare speakerului la finalul prezentării, și au urmă toarele adrese URL:
• /containers/positivefeedback/aggregate – aceasta este resursa la care se reține o listă de
mapari selecție – feedback pozitiv;
• /containers/ambiguousfeedback/aggregate – aceasta este resursa la care se reține o listă
de mapari selecție – feedback de tip ambiguous;
• /containers/prooffeedback/aggregate – aceasta este resursa la care se reține o listă de
mapari selecție – feedback de tip proof needed;
• /containers/questions/aggregate – aceasta este resursa care stochează toate întrebările
puse pe documentul PDF, prin gruparea acestora în sele cții, fiecare selecție fiind un binar de
tipul celei găsită la o resursă /containers/prooffeed back/[selection_id].

4.1.2 Tipurile mesajelor HTTP
Pentru transmiterea diferitelor mesaje HTTP între client și server, am folosit setarea antetului
Content-Type al mesajului http. Următoarele tipuri au fost folosite pentru definirea conținutului:
• text/plain : prin această setare am definit conținutul de tip cl ear text, în cazul mesajelor scurte,
care nu necesitau serializare pentru o optimizare a com unicării. Astfel de mesaje sunt:
o schimbarea slideului de către speaker respectiv accesa rea slideului curent de către client, în
ambele cazuri se transmite doar un număr al slideului;
o transmiterea unui șir fix de două caractere, "+1" sau " -1", cu semnificația adăugării său retragerii
unui feedback te țip fix, adică unul din tipurile po sitive feedback, ambiguous sau proof needed în
cazul unei selecții. Selecția este reprezentată în U RL prin id-ul ei, un număr întreg de tip long
care se obține ca hashCode al unui șir de caractere rep rezentativ pentru elementele selectate;
o transmiterea ca răspuns de la server către client a unui șir de caractere reprezentând numărul
total de feedbackuri din fiecare tip din cele trei des crise mai sus, pentru o anumită selecție.
Acest număr este reprezentativ pentru agregarea tipurilor fixe de feedback, frecvența indicând
relevanța acelui feedback;
• application/pdf : această setare e folosită pentru codificarea binară a prezentării pdf stocate pe
server. Prin interpretarea corectă acestui mesaj http, cl ientul preia conținutul binar și îl scrie într-un
fișier de tip pdf, stocat local pe dispozitivul And roid.
• application/x-protobuf : acesta este un mime-type definit local corespunzăt or mesajelor http
codificate binar folosind Google Protocol Buffers. Se tarea conținutului binar al fișierului se poate
face în mai multe moduri: în cazul clientului Android am folosit clasa ByteArrayEntity, care se
instantiaza cu un content-type dintr-un vector de oc teți, byte[]. În cazul serverului, sunt definite
clase care implementează interfețele MessageBodyWriter și MessageBodyReader din pachetul

George-Cristian Stoica

20
jersey javax.ws.rs.ext, necesare pentru construirea unei clase Response pentru un mime type definit
de utilizator. Pentru deserializare am folosit și metod a parseFrom() aplicată unui obiect Google
Protocol Buffer, prin care se construiește instanța din vectorul de octeți al conținutului binar.
Setarea câmpului content-type și citirea acesuia se poate face foarte ușor programatic, în funcție de
pachetele și clasele Java folosite pentru formarea și interpretarea mesajelor http. Astfel, pentru citirea
câmpului, pe server se poate inspecta câmpul headers de tip HttpHeaders accesibil într-o metodă de tip
Http a unei clase resursă, prin apelarea metodei header. getMediaType(). În cazul clientului, pentru
citirea antetului se apelează metoda getFirstHeader("C ontent-Type") pe o instanță de tip HttpResponse.
Pentru setarea acestui câmp, se poate instanția o ent itate care implementează interfața HttpEntity cu
tipul conținutului corect sau se poate seta acel câm p din antet, printr-o metodă setter.

4.2 Implementarea protocolului de comunicație
Un protocol de comunicație se definește ca un set de reguli cunoscute de ambele părți ale unei
comunicații, prin care atât receptorul , cât și emițătorul pot interpreta corect mesajele tran smise pentru
îndeplinirea anumitor cerințe. Un protocol definește de asemenea și ordinea mesajelor schimbate,
anumite operații necesitând schimbul unui număr cons ecutiv de mesaje specifice, într-o ordine
particulară. Un protocol bazat pe HTTP, așa cum este c azul la aplicația Smart presentation, este format
din două componente:
1. URL – atât clienții care accesează resursa cât și serv erul pe care este stocată aceasta au aceeași
concepție asupra resursei aflate la acea adresa. Astfe l, clientul știe ce adresa trebuie accesată
pentru obținerea resursei dorite și are certitudinea c orectitudinii mesajului primit ca răspuns.
Această certitudine permite interpretarea corectă a răs punsului. La fel, serverul asigură stocarea
resursei cerute la respectiva adresă, având același set de mapări resursă-URL ca cel cunoscut de
client.
2. Conținutul mesajelor – în cadrul unei resurse aflate la un URL, se încapsulează un conținut propriu-
zis al mesajului care conține informația dorită. Ace astă informație poate reprezenta date obținute
prin prelucrare pe server sau pur și simplu stocate pe ac esta. În funcție de conținutul acestor
mesaje, un client poate decide transmiterea unor noi cereri sau declanșarea unor evenimente
locale.
4.2.1 Componenta mesajelor și logica protocolului
În cadrul aplicației Smart Presentation, protocolul de comunicație este definit pe fiecare arie de
funcționalitate separată. Astfel, serverul primește anu mite cereri la care este pregătit să răspundă cu
mesajele necesare. În continuare, mă voi referi la ad resa serverului cu [adresa_server], datorită
caracterului variabil al acesteia, în funcție de adres a ip la care poate fi accesat. De asemenea, mă voi
referi la un URL cu termenul "adresa".
Mesajele schimbate între client și server sunt următo arele:
• La inițializarea aplicației, fiecare client trimite o cerere http de tip GET la adresa
[adresa_server]/presentation , cu conținut gol. Serverul trimite ca răspuns un mesaj http cu
headerul Content-type setat "application/pdf" și con ținutul binar, în format pdf, reprezentând
aplicația stocată pe server.
• La schimbarea slide-ului de către speaker, se trimite un mesaj de tip PUT către server, la adresa
[adresa_server]/containers/slidecontainer/slide, având un conținut cu Content-type "text/plain"
care este format dintr-un număr cu slide-ul curent. C lientul trimite cereri de tip GET la aceeași

George-Cristian Stoica

21
adresă, primind ca răspuns tot un mesaj http "text/pla in" cu numărul slide-ului actual. Acest
mesaj este trimis la un interval mic de timp, înconti nuu, atunci când clientul se află în modul "Go
live!".
• Pentru trimiterea unui feedback de tip fix, positive feedback, ambiguous sau proof needed,
clientul trimite un mesaj HTTP PUT cu conținutul "te xt/plain" reprezentat dintr-un șir de
caractere cu forma "+1" sau "-1", cu semnificația ad ăugării sau retragerii acelui tip de feedback.
Adresele de acces a acestor tipuri de feedback pentru o selecție sunt:
o [adresa_server]/containers/positivefeedback/[id_sel ecție] – pentru
accesarea feedbackului de tip positive feedback
o [adresa_server]/containers/ambiguousfeedback/[id_sel ecție] – pentru
accesarea feedbackului de tip ambiguu
o [adresa_server]/containers/prooffeedback/[id_selecț ie] – pentru accesarea
feedbackului de tip proof needed.
La formularea unei cereri PUT la o astfel de resursă, s erverul returnează același răspuns ca în
cazul unei cereri GET, un mesaj de tip "text/plain" r eprezentând numărul total al feedbackurilor
de acel tip primite la acea adresa, adică pe o anumit ă selecție. Id-ul selecție este un șir de cifre
care formează un număr întreg reprezentativ doar pentru o selecție.
• Pentru mesajele ce conțin feedback de tip întrebări p entru o anumită selecție, am folosit
codificarea în formatul binar Google Protocol Buffers, datorită simplității și versatilității sale în
definirea mesajelor, dar și datorită unei eficientizări evidente a utilizării benzii de transfer. Ca și
în cazul celorlalte tipuri de feedback, adresa la care este ținut feedbackul agregat pe un id al
unei selecții este de forma [adresa_server]/container s/questions/[id_selecție]. Diferența apare
la tipul conținutului unui mesaj și la logica răspun sului de la server în cazul transmiterii unei
forme agregate a feedbackului stocat.
Astfel, un client trimite un feedback sub forma unui mesaj de tip HTTP PUT, cu câmpul content-
type setat pe "application/x-protobuf". Conținutul a cestui mesaj este un mesaj de tip protocol
buffers, având la baza o întrebare adresată pe o selecț ie. La recepția acestei cereri, serverul
reface resursa pe care o are reținută la acea adresă, prin regrupare. Această resursă conține o
formă agregată a feedbackului, reținută în format binar Google Protocol Buffers. Conținutul
acesui mesaj este format dintr-o listă de clustere, u n cluster fiind o listă de întrebări cu sens
asemănător din punct de vedere semantic. Acest mesa j este cel primit ca răspuns de un client
sau de către speaker la o cerere de tip GET pe adresa corespunzătoare unei selecții.
De asemenea, am folosit Google Protocol Buffers pent ru agregarea tuturor tipurilor de feedback
pentru întregul document PDF, pentru ca acestea să poa te fi accesate de speaker la final. Aceste
resurse sunt găsite la adresele detaliate la capitolul anterior, de tipul:
[adresa_server]/containers/[feedback_container]/agg regate
Conținutul unui mesaj de tip Google Protocol Buffers poate varia, în funcție de tipul mesajului.
Pentru a determina tipul mesajului înainte de deserial izare, am folosit un mecanism de
încapsulare care va fi descris în continuare.

George-Cristian Stoica

22
4.2.2 Serializarea datelor folosind Google Protocol Buffers
Mesajele de codificare a întrebărilor de feedback sun t serializate folosind mecanismul Google
protocol Buffers, detaliat la capitolul Tehnologii fo losite. În acest scop, am definit mai multe tipuri d e
mesaje într-o ordine ierarhică, în funcție de gradul d e încapsulare.
Astfel, pentru o simplă întrebare, trimisă în cadrul un ui mesaj sub forma unei cereri PUT de la client
către server la o adresă specifică unei selecții, se fo losește următorul format de mesaj:
message FeedbackQuestion
{
required int32 retract = 1;
required string selectionString = 2;
required string question = 3;
}
Pentru un cluster de întrebări, reprezentat printr-o listă de întrebări apropiate semantic, din care se
poate alege oricare ca centroid (întrebare reprezentativ ă), am definit următorul mesaj:
message QuestionCluster
{
required string selectionString = 1;
repeated FeedbackQuestion questions = 2;
}
Pentru reprezentarea agregată pentru o selecție a tutu ror clusterelor obținute în urma aplicării
algoritmului de grupare pentru toate întrebările adresat e, am definit următorul mesaj:
message SelectionClusters
{
required int64 selectionId = 1;
required string selectionString = 2;
repeated QuestionCluster clusters = 3;
}
În plus față de aceste mesaje, am implementat mesaj e de încapsulare pentru tipurile de feedback fix
sau întrebări, pentru încapsularea mesajelor de agregare transmise speakerului la finalizarea prezentării.
message AggregateQuestionsFeedback
{
repeated SelectionClusters SelectionClusters = 1;
}

message FixedFeedback
{
required string selectionString = 1;
required string feedbackType = 2;
required int32 numberOf = 3;
}

message AggregateFixedFeedback
{
repeated FixedFeedback feedbacks = 1;
}
În cazul transmiterii unui mesaj Google Protocol Buff ers, ar trebui cunoscut tipul mesajului înainte
de deserializare, pentru folosirea claselor corecte genera te de executabilul protoc. O tehnică potrivită

George-Cristian Stoica

23
pentru acest scop este încapsularea unui mesaj din ce le trei tipuri de mai sus într-un mesaj container,
care să conțină un câmp cu semnificația unui flag ca re indică tipul mesajului încapsulat, și un alt câmp cu
mesajul propriu-zis. Formatul mesajului container arăt a astfel:
message MessageContainer
{
enum Type
{
SINGLE = 1;
CLUSTER = 2;
SELECTION = 3;
AGGREGATE_QUESTIONS = 4;
AGGREGATE_FIXED = 5;
}

required Type type = 1;

optional FeedbackQuestion feedbackQuestion = 2;
optional QuestionCluster questionCluster = 3;
optional SelectionClusters selectionClusters = 4;
optional AggregateQuestionsFeedback aggregateQuest ions = 5;
optional AggregateFixedFeedback aggregateFixed = 6 ;
}
Astfel, câmpul type evidențiază care din cele trei me saje opționale este cel conținut de mesajul
container, permițând o deserializare corectă.
Pentru definirea acestor mesaje, am folosit următoarel e cuvinte cheie ale limbajului Google Protocol
Buffers, cu explicațiile:
• Required – indică necesitatea prezenței acelui câmp î n mesaj;
• Opțional – indică lipsa necesității prezenței acelui câmp în mesaj;
• Repeated – indică un câmp de tip lista al tipului s pecificat.
De asemenea, se poate observa și un tag care este aso ciat fiecărui câmp. Acest tag este utilizat la
interpretarea mesajului la deserializare, indicând ordin ea în care se găsesc membrii mesajului în
formula binară a mesajului.
Generarea claselor, serializarea și deserializarea mesajelor
Google Protocol Buffers este un limbaj compatibil cu majoritatea limbajelor populare, oferind suport
inclusiv pentru Java. Pentru obținerea mesajelor binare , este necesară obținerea unor clase Java din
formatele definite în fișierele .proto. Generarea aces tor clase face printr-un executabil protoc.exe. În
cazul utilizării mediului de dezvoltare Eclipse, exi stă un plugin care determină generarea automată a
claselor la crearea unui mesaj .proto în folderul res ources al unui proiect.
Clasele generate pun la dispoziție mai multe subclas e și metode pentru serializare și deserializare.
Pentru deserializare, cea mai facilă tehnică este apel area metodei parseFrom() care primește că
parametru un array de octeți (byte[]), spre exemplu con ținutul unui mesaj HTTP. Pentru serializare,
fiecare clasa conține o subclasa builder, care se obți ne astfel, pentru un exemplu din mesajele de mai
sus:
SelectionClusters.Builder clusterBuilder = Selectio nClusters.newBuilder()
Această instanță este folosită apoi pentru adăugarea celorlalte câmpuri, prin metode de tip setter;

George-Cristian Stoica

24
Exp: clusterBuilder.setSelectionId(id)
Pentru un câmp de tip repeated, se folosește metoda add().
După setarea tututor câmpurilor, mesajul se obține pri n apelul metodei build asupra instanței builder.
Exp: SelectionClusters clusters = clusterBuilder.build()

SelectionClusters.Builder scBuilder = SelectionClus ters.newBuilder();
scBuilder.setSelectionId(new Long(MemoryStore.cur rentItem));

for (Set<Question> cluster : clusterTree)
{
QuestionCluster.Builder qCluster = QuestionClust er.newBuilder();
for (Question q : cluster)
{
FeedbackQuestion.Builder fqBuilder =
FeedbackQuestion.newBuilder();
fqBuilder.setRetract(0);
fqBuilder.setQuestion(q.originalText);
FeedbackQuestion fq = fqBuilder.build();
qCluster.addQuestions(fq);
}
QuestionCluster qc = qCluster.build();
scBuilder.addClusters(qc);
}

SelectionClusters sc = scBuilder.build();
Exemplu de cod din serializarea feedbackului

4.2 Implementarea clientului Android
Implementarea aplicației Smart Presentation include aplicația de client, cea de Android și serverul
central. Implementarea clientului cuprinde cele trei mo dule funcționale, interfața, modulul de
manipulare a prezentării PDF și partea de comunicare c u serverul.
Mediul de dezvoltare Android este diferit de cel deskt op. O diferență de baza între aplicațiile pentru
telefoane mobile și aplicațiile desktop este repreze ntată de modul în care tratează persistența datelor.
Cel mai des, aplicațiile desktop folosesc o impleme ntare a patternului MVC centrată pe documente –
aplicațiile deschid un document, îl citesc în memori e și îl transpun în obiecte care persistă în memorie.
Aceste programe definesc vizualizări în care pot fi man ipulate acele obiecte ale modelului de date, prin
procesarea inputului de la controller. Spre deosebire d e acestea, aplicațiile Android combină modelele
de date și interfața utilizatorului într-un mod diferi t. Aplicațiile rulează pe un dispozitiv mobil cu
memorie limitată, care poate rămâne fără baterie într-un moment imprevizibil. Întregul concept de
document este absent în Android. Utilizatorul întotde auna ar trebui să aibă datele la îndemână și să fie
încrezător că acestea sunt în siguranță. Pentru a stoc a datele aplicației incremental, obiect cu obiect, și
ca acestea să fie întotdeauna la dispoziție, Android oferă un suport centrat pe baze de date, prin clasele
cuprinse în pachetul android.database.sqlite [10].
O altă diferență între aplicațiile pentru telefoane mo bile și aplicațiile desktop este accentul care
cade în cazul celor mobile în primul rând pe o utiliza re fluidă a aplicației, astfel încât interfața grafic ă să
nu fie blocată niciodată. Din acest motiv, sdk-ul A ndroid oferă multiple pachete și clase care permit

George-Cristian Stoica

25
rularea paralelă a mai multor taskuri, cu scopul de a nu încărca suplimentar threadul GUI. Spre exemplu,
ultimele versiuni de Android sdk interzic rularea de ope rații de networking, cum sunt și cele http.
Încercarea de rulare a unei astfel de cereri în threadul aplicației aruncă o excepție [2].
Cea mai des utilizată tehnica în devoltarea unor task uri care rulează paralel este comunicarea
asincronă cu threadul respectiv, astfel încât elemente le vizuale, de interfață din threadul principal să fie
înștiințate de finalizarea taskului paralel. Pentru im plementarea acestei tehnici, am folosit două metode .
Prima și cea mai simplă este de a implementa o clasă care extinde clasa AsyncTask, aceasta oferind
metode pentru rularea în background și pentru finalizare a rulării. Cealaltă este cea de a realiza un
managedQuery() către ContentProviderul aplicației, un serviciu care are rolul Modelului din arhitectura
Model-View-Controller și care are acces direct la bază de date a aplicației. Ambele variante sunt
detaliate în continuare.

4.3.1 Implementarea design patternului MVC
Așa cum am descris și la capitolul de Arhitectură, dev oltarea aplicației Android implică
implementarea unui pattern Model-View-Controller.
Astfel, se separă cele trei module funcționale, int erfața grafică, modelul și controllerul, astfel încât
fiecare componentă este dependentă de celelalte. Int erfața grafică răspunde la comenzi din partea
utlizatorului, controllerul fiind responsabil cu tratare a evenimentelor și cu actualizarea datelor din
interfață. Modelul este cel care asigură persistența da telor din care atât controllerul, cât și view-ul își
actualizează conținutul.
Și în cadrul aplicației Smart Presentation, există o s eparare clară a componentelor, astfel încât
acestea pot fi încadrate într-una din cele trei categ orii: view, model și controller. Astfel, view-ul este
constituit din totalitatea elementelor grafice ale ap licației și controllerul cuprinde totalitatea handlerel or
de actualizare a interfeței. Modelul este alcătuit di n taskurile asincrone care comunică direct cu serverul
web și dintr-o componentă specială, Content provide r, care asigură persistența datelor într-o bază de
date Sqlite și care poate fi interogată.

4.3.2 Persistența datelor în Sqlite și accesarea re surselor interne prin ContentProvider
Instanțele Content providers reprezintă o componentă a aplicației locale și sunt analoage
conceptului de serviciu web RESTful. API-ul content providerului permite aplicațiilor client să
interogheze sistemul de operare pentru date relevante u tilizând un UR I, similar modului în care un
browser cere informații pe internet. Adresa URI a conten t providerului începe întotdeauna cu
content://, la care se adăugă că în cazul unui web service componenta specifică resursei.
Dacă o aplicație implementează un provider propriu, est e necesar ca acesta să fie înregistrat în
fișierul de configurare al aplicației, AndroidManifest .xml, astfel:
<provider android:name=".provider.SmartpContentProv ider"
android:authorities="smartp.client.provid er.SmartpContentProvider" />
Utilizarea clasică a unui content provider se face prin stocarea datelor într-o bază de date
SqLiteDatabase, asupra cărora acționează metodele imp lementate ale clasei abstracte ContentProvider:
• Insert – este analoagă metodei POST a unui server web și are rolul de a stoca noi date în bază
de date

George-Cristian Stoica

26
• Query – analoagă metodei GET, returnează înregistrări di n bază de date pe baza unor cereri
SQL, într-o colecție specializată numită Cursor
• Update – analoagă metodei update. Înlocuiește cereri le din bază de date cu unele mai noi
• Delete – analoagă cererii de tip DELETE
Ca și în cazul unui server web, un content provider map ează dinamic adrese URL la resursele aflate
în baza de date. Această mapare este responsabilitat ea programatorului, care la apelul metodei Query a
content providerului face match pe URIul folosit în q uery pentru a ști ce interogare se realizează pe baza
de date. Interogarea întoarce o instanță a clasei Curs or, care oferă pe lângă informația propriu-zisă
mecanisme de declanșare a evenimentelor atunci când d atele aflate la adresa respectivă suferă
modificări. Pentru a activa aceste mecanisme, se apel ează metoda [2]:
queryCursor.setNotificationUri(getContext().getCont entResolver(),uri);
la crearea cursorului, adică în metoda Query a content providerului, și metoda :
getContext().getContentResolver().notifyChange(uri, null);
la modificarea conținutului, adică în interiorul unei metode insert, delete sau update.
În cazul ambelor metode, se folosește metoda getContext().getContentResolver() , care
întoarce instanța unui ContentResolver , clasa care realizează interfața dintre aplicația care rulează și
content providerul înregistrat în fișierul de configurare . Atât Context, cât și ContentResolver, sunt clase
singleton, ale căror instanțe sunt create la iniția lizarea aplicației Android.
Clasa Content Provider a aplicației Smart Presentation are scopul de stocare în bază de date a unor
date care sunt preluate de pe server. Cele mai importan te astfel de date sunt documentul PDF, care este
preluat asincron la deschiderea aplicației, după care aceasta este notificată pentru a-și reface interfața,
și întrebările de feedback sub forma agregată, care sun t reținute asemănător unui mecanism de
cacheing în bază de date, pentru a rări cererile la serv er. În ambele cazuri, din clasa activitate se
folosește un query de tip managedQuery, care primește ca parametru adresa de interogare a content
providerului și returnează un cursor cu datele din bază d e date.
Clasa managedQuery are posibilitatea de mapare a unei instanțe a clasei ContentObserver , care
implementează metoda onChange() , aceasta fiind metoda handler apelată atunci când u n notify este
executat pe URLul cursorului în cadul content provideru lui, cel mai uzual în cazul unui insert, delete sau
update (Figura 8).

Fig 8. Componentele MVC de bază ale unei aplicații Android 1

1 Zigurd Mednieks, Laird Dornin & G. Blake Mieke: Programming in Android 2 nd Edition (O'Reilly, 2012), 80

George-Cristian Stoica

27
Metoda query() a content providerului este responsabilă cu returnarea rezultatelor din bază de
date. Acest matching se face folosind o clasă ajută toare UriMatcher.
În cazul întrebărilor feedback reținute în baza de dat e, am decis să implementez o modalitate de
cacheing, astfel încât în urma unei extrageri a intrării din baza de date corespunzătoare feedbackului
unei selecții, să se verifice și timestampul ultimei actualizări, astfel încât o nouă cerere către serverul
web să se facă doar atunci când resursele stocate sunt considerate prea vechi.
Extragerea căii de salvare a documentului PDF din ba za de date se face doar o dată, la început, în
urma unei cereri efectuate la serverul web care declanșe ază un notify la insertul în baza de date.

4.3.3 Accesarea resurselor de pe web server prin me saje asincrone
Clasa AsyncTask
Accesarea resurselor de pe web server se face în două situații, din clasa de baza Activity sau din
clasa ContentProvider, dar în ambele cazuri comunicarea cu serverul se face asincron. În cazul în care
apelul se face direct din threadul UI, acest mecanism se implementează printr-o clasă care extinde clasa
abstractă AsyncTask [2]. Această clasa oferă metode ș i parametri prin care comunică cu threadul
apelant.
Cele trei tipuri utilizate de un task asincron sunt următoarele:
• Params – tipul parametrilor trimiși taskului la execuție;
• Progress – tipul unităților de progress publicate în timpul e fectuării operațiilor în background;
• Result – tipul rezultatului obținut în urma rulării operațiilo r de background;
Aceste tipuri sunt setate atunci când se extinde cla sa AsynTask, prin setarea celor trei parametri
generici ai clasei. În cazul în care unul din cele tr ei tipuri nu este folosit, acesta poate fi marcat cu void.
Un exemplu de declarare a unei clase copil ar fi:
private class MyTask extends AsyncTask<URL, Void, S tring)
care se traduce astfel: metoda de execuție primește ca parametri instante ale clasei URL, unitățile de
progress nu sunt folosite, iar rezultatul este întors s ub forma unui String.
Când un task asincron este executat acesta trece prin patru pași 1:
1. onPreExecute() , invocat de threadul UI imediat după ce taskul este executat. Acest pas este utilizat
în mod normal pentru setarea taskului, spre exemplu pe ntru afișarea unui progress bar în interfața
utilizatorului.
2. doInBackground(Params …) invocat de threadul de background imediat ce onPreExecute()
termină de executat. Acest pas este folosit pentru ef ectuarea unor acțiuni computaționale de
background care pot dura un timp mai îndelungat. Rezul tatul operațiilor efectuate aici trebuie să fie
întors în această metodă și va fi pasat următorului pa s. Acest pas poate declanșa și metoda
publishProgress(Progress…) pentru a publica una sau mai multe unități de progre s. Aceste
valori sunt interpretate în UI thread, în pasul onProgressUpdate(Progres…)
3. onProgressUpdate(Progress…), invocat de UI thread după un apel al metodei
publishProgress(Progress…) . Momentul exact al executării este nedefinit. Aceas tă metodă
este folosită pentru afișarea oricărei forme de progres în interfața utilizatorului în timp ce operațiile

1 Documentatia Android, 20.06.2012, <developer.andro id.com/reference/android/os/AsyncTask.html>

George-Cristian Stoica

28
de background sunt în execuție. Spre exemplu, poate f i folosită pentru animarea unui progress bar
sau pentru a afișa mesaje de log.
4. onPostExecute(Result) , invocat de UI thread după ce operațiile de backgroun d se termină.
Parametrul Result este cel preluat de metoda doInBackground().

Fig. 9 Fluxul de date AsyncTask 1

O altă facilitate oferită de clasa AsynTask este posibilitatea opririi acesteia din threadul apel ant, prin
apelul metodei cancel(boolean) . Invocarea acestei metode activează returnarea valorii
onCancelled(Object) la terminarea metodei doInBackgroud() , în loc de onPostExecute . De
asemenea, în timpul executării taskului se poate veri fica periodic valoarea întoarsă de onCancelled().
Din punct de vedere al concurenței threadurilor, AsyncT ask asigură că toate apelurile callback sunt
sincronizate în așa fel încât următoarele operații sunt sigure:
• setarea membrilor în constructor sau în onPreExecute() și referirea lor în
doInBackground(Params…)
• setarea câmpurilor membri în doInBackgroud(Params…) și referirea lor în
onProgressUpdate(Progress…) și în onPostExecute(Result)
Aplicația Smart Presentation folosește numeroase cl ase particulare care implementează această
clasă abstractă. În general, toate taskurile care presu pun comunicare pe rețea, în acest caz efectuarea
cererilor către serverul web și întoarcerea asincronă a răs punsurilor, sunt mapate la o astfel de clasă.
Următoarele sunt principalele astfel de clase folosit e în cadrul aplicației:
• GetSlideAsyncTask – este clasa responsabilă cu sincronizarea slideului curent cu cel al
speakerului, a cărei executare este lansată atunci câ nd se intră în modul Go live!. Modul de
funcționare a acesteia este următorul: funcția doInBackgroud(String… params) intră într-
un ciclu în care, dacă nu a s-a apelat încă metoda c ancel în UI Thread, se verifică ultima
actualizare a slideului. Dacă timpul scurs de la ulti ma actualizare este mai mare de un anumit
threshold mic (2-3 secunde), se execută o cerere asin cronă către serverul web pentru
actualizarea numărului slideului.
Verificarea dacă taskul continuă să ruleze se face prin apelul metodei isCancelled, care întoarce
true sau false. După fiecare cerere GET efectuată, răsp unsul este folosit pentru actualizarea

1 Zigurd Mednieks, Laird Dornin & G. Blake Mieke: Programming in Android 2 nd Edition (O'Reilly, 2012), 110

George-Cristian Stoica

29
interfeței grafice, în cazul nostru schimbarea slideulu i. Aceeași metodă de actualizare a slideului
este apelată și în final în metoda onPostExecute(String result).
Metoda doInBackground(String… params) primește parametru de tip String, reprezentat
de URLul la care se face cererea și returnează un răspu ns de tip String, numărul slideului curent.

@Override
protected String doInBackground(String… params)
{
String response = "";
while (!isCancelled())
{
if (TimeUtils. getDiffTimeInSeconds (taskTimer) > 3)
{
taskTimer = TimeUtils. getCurrentTime ();
HttpClient client = new DefaultHttpClient();
HttpGet httpGet = new HttpGet(params[0]);
try
{
HttpResponse execute = client.execute(httpGet) ;
response = HttpUtils. getStringFromResponse (execute);

changeSlide(response);

} catch (Exception e)
{
e.printStackTrace();
}
}
}
return response;
}

Implementare a metodei doInBackground()
• Clasa PutCurrentSlide este folosită în aplicație doar de speaker, și este apelată atunci când
acesta schimbă slide-ul. În cadrul metodei de backgro und, se setează conținutul de tip
"text/plain" al unei entități StringEntity, reprezent ând slideul curent, și se execută o metodă de
tip HttpPut.
• Clasa PutFixedFeedback este folosită pentru trimiterea unuia din cele trei ti puri de feedback
fix, positive feedback, ambiguous sau proof needed. Această clasa setează în constructor un
membru String al clasei, numit PutOrRetract , cu valoarea "-1" sau "+1", cu semnificația
adăugării acelui feedback sau retragerea unui feedback făcut anterior. Acest șir de două
caractere este încapsulat în conținutul unei StringEntity și trimis printr-un http put către
server, care returnează ca răspuns numărul agregat al acel ui tip de feedback pus pe selecția
respectivă. Afișarea răspunsului în aplicație se face la execuția onPostExecute()
• Clasa PutFeedbackQuestionTask realizează serializarea unei întrebări de tip String și trimiterea
acesteia către server. Serializarea se face în formatul Google Protocol Buffers și scrierea
mesajului http se face folosind o entitate generică, ByteArrayEntity , care spre deosebire de
StringEntity , folosește conținut de tip binar:

George-Cristian Stoica

30
ByteArrayEntity entity = new ByteArrayEntity(messsa ge.toByteArray());

entity.setContentType(smartp.client.AlternateMedia Type.APPLICATION_XPROTOBUF);

Clasa UriRequestTask
Comunicarea cu serverul web se face nu doar din Activi ty, ci și prin intermediul Content Provider. În
acest scop, am dezvoltat o clasă care implementează interfața Runnable, rulând într-un thread separat.
La fel că în cazul AsyncTask , în cadrul metodei run() se execută operațiile de background. Pentru
interpretarea mesajului, am implementat o clasă handl er , MessageHandler , care parseaza mesajul http
pentru a decide următorul pas. În general, datele cupri nse în răspunsul de la server sunt introduse în
baza de date SQLite, astfel încât la o modificare a datelor, cursorul pe care s-a făcut o interogare pe bază
de date să notifice elementele apelante din Activit y.
Prima situație în care se întâmplă acest scenariu est e la pornirea aplicației, când se execută un
managedQuery la contentprovider pentru descărcarea preze ntării PDF de la server.

public void query()
{
Uri queryUri = SmartPresentationMessage.Pdf.CONTE NT_URÎ;
Cursor myCursor = managedQuery(queryUri, null, nu ll, null, null);
myCursor.registerContentObserver(new ContentObser ver(new Handler()) {

@Override
public void onChange(boolean selfChange)
{
Log.d(SmartpTAG.TAG, "On load finished");
super.onChange(selfChange);
onLoadPresentation();
initializeFrontend();
}

@Override
public boolean deliverSelfNotifications()
{
return true;
}
});
}

Metoda de interogare a content providerului

SmartPresentationMessage.Pdf.CONTENT_URI este adresa la care se face o interogare către
ContentProvider, și are forma content://" + AUTHORIT Y + "/" + Pdf.PATH, unde AUTHORITY este calea
completă a clasei Content Provider și Pdf.PATH este o constanta care definește numele resursei.
Această interogare declanșează cererea către web server. La descărcarea prezentării PDF, aceasta este
scrisă în memoria internă a dispozitivului și adresa in ternă, cea specifică sistemul de fișiere Android este
salvată în baza de date. În funcția care realizează i nsert în bază de date, se apelează metoda de
notificare notifyChange pe URLul descris mai sus, ast fel încât cursorul creat de metoda managedQuery

George-Cristian Stoica

31
să fie atenționat de terminarea cererii. În urma notif icării, se execută metoda onChange, în care se
încarcă prezentarea PDF în interfața grafică.
Aceeași succesiune de acțiuni ca și în cazul de mai sus se efectuează în cazul interogării
ContentProviderului pentru obținerea feedbackului agre gat. Aceste date sunt cerute prin intermediul
instanței ContentProvider deoarece am dorit salvarea în bază de date a feedbackului, astfel încât să fie
implementat un mecansim de cacheing care să permită aplicației să obțină feedbackul direct din baza de
date dacă ultimul moment al actualizării sale a fost foarte recent. Acest feedback agregat este reținut în
bază de date SqlLite în tabela QUESTIONS_TABLE, în cazul întrebărilor, și în FIXED_FEEDBACK, pentru
celelalte tipuri de feedback. Interogarile pe tabele se fac după ID reprezentând selecția, și care conține
un blob cu binarul serializat Google Protocol Buffers și un timestamp al ultimei actualizări.

4.4 Implementarea serverului web
Serverul central al aplicației Smart Presentation este un server web RESTful, care returnează resurse
pe baza unor cereri efectuate pentru anumite adrese URL . Tehnologiile utilizate la dezvoltarea acestuia
sunt Grizzly, pentru container, și Jersey, pentru implem entarea claselor resursa și a metodelor specifice
HTTP. Pe lângă componenta de resurse, serverul mai are și scopul de grupare a întrebărilor feedback de
la clienți, pentru a permite utilizatorilor o vizualiz are agregată, mai compactă, a întrebărilor, în funcție
de similaritatea semantică. Astfel, partea mea de im plementare a cuprins doi pași:
1. dezvoltarea serverului web și a claselor resursă și m aparea acestora la adrese URL
2. integrarea modulului de clusterizare și sincronizare a acestuia cu resursa HTTP corespunzătoare
feedbackului format din întrebări

4.4.1 Inițializarea serverului și a containerului G rizzly
Containerul Jersey oferă o interfață programatică de ini țializare, spre deosebire de procedura
standard de înregistrare a resurselor web specifice serve relor web Tomcat sau Glassfish, adică prin
introducerea claselor într-un fișier de configurare we b.xml.
Astfel, serverul poate fi pornit dintr-o metodă Main, permițând și operații anexe, cum ar fi în cazul
aplicației Smart Presentation pornirea unui thread sec undar al modului de clusterizare a întrebărilor
feedback.
Inițializarea serverului web presupune următorii pași [5 ]:
• Setarea unei adrese de bază a serverului web, spre exemp lu http://localhost:9988/. Orice
resursa stocată pe server are adresa formată din concat enarea acestei adrese unei porțiuni
specifice resursei;
• Înregistrarea pachetelor unde se află clasele resursa;
• Crearea propriu-zisă a serverului web, prin apelul metode i:
GrizzlyWebContainerFactory.create(BASE_URI, initPar ams) .

George-Cristian Stoica

32
4.4.2 Clasele resursă și metodele HTTP definite pe server
Serverul web pune la dispoziție toate resursele de care clientul are nevoie pentru îndeplinirea
funcționalităților aplicației Smart Presentation. Ace ste resurse pot fi acccesate și modificate prin cereri
HTTP de tip GET, PUT, POST sau DELETE. Clasele se m apează la adrese URL prin adnotări specfice
frameworkului Jersey, care definește de asemenea și a dnotări ale metodelor clasei pentru metodele
HTTP la care acestea se mapeaza sau adnotări referitoa re la tipul de content al corpului http.
Resursele expuse de serverul web sunt grupate în pachet e care sunt înregistrate la inițializarea
containerului Grizzly, pentru ca ele să poate fi acces ate de class loader. Resursele specifice aplicației
Smart Presentation sunt:
• Class PDFPresentation – este clasa care pune la dispoziție prezentarea PDF stocată pe server.
Aceasta este adnotată cu @Path("presentation"), indi când adresa la care poate fi accesată.
Clasa implementează doar o metodă GET, adnotată cu @Produces("application/pdf"), indicând
tipul conținutului pachetului http. În interiorul met odei, este citit într-un obiect File fișierul PDF
aflat în directorul rădăcina al serverului . Acest obiec t este încapsulat în răspunsul http prin
metoda Response.ok((Object) file).
• Clasa ContainersResource – adonatată cu @Path("containers") , este clasa care încapsulează
totalitatea containerelor, întorcând un xml cu contain erele definite.
• Clasa ContainerResource – nu are adnotare de Path, șirul de caractere de după / containers/
fiind considerat un parametru care se parseaza la apelul metodei http. Metoda GET returnează
răspuns doar dacă există acel container.
• Clasa ItemResource – nu are adnotare de Path, numele său este șirul de c aractere de după
/containers/[container_name] și este instanțiată din metoda geItemResource a clasei
ContainerResource. Are definite metode GET și PUT, pen tru extragerea resursei, respectiv
pentru crearea/actualizarea acesteia.
Ultimele trei clase descrise fac parte dintr-o arhitect ură exemplificată în aplicația Storage Server
definită ca exemplu al utilizării Jersey 1. Acest design reprezintă o alternativă foarte generică de stocat
resurse, întrucât ierarhia adresei permite separarea logică a acestora. De asemenea, resursele sunt
reținute în format binar, din care se poate obține oric e alt tip de date, în funcție de resursa stocată.
Din punct de vedere programatic, arhitectura Storage Se rver permite stocarea unor date care pot fi
accesate în comun de resurse. Clasa care asigură stoc area se numește MemoryStore, și membrii clasei
au atributul static, pentru ca aceștia să fie instantiati la încărcarea cla sei și nu la o instantiere a sa.
Excepție fac structurile de date de tip HashMap care realizează maparile containerelor și a numelor
resurselor item la containere:
private Map<String, Container> containerMap = n ew HashMap<String, Container>();
private Map<String, Map<String, byte[]>> dataMa p = new HashMap<String,
Map<String, byte[]>>();
Acestea sunt membri ale instanței singleton MemoryStore , care conține și metode accesor pentru
aceste structuri de date.
În primul subcapitol al detaliilor de implementare am detaliat URL-urile la care pot fi accesate
resursele serverului. Cu excepția documentului PDF și a clasei aferente, celelalte resurse sunt accesibile
prin acest format al URLului:

1 Exemple Jersey, Storage-Service, 20.06.2012,
<http://docs.oracle.com/cd/E19776-01/820-4867/ggrb y/index.html>

George-Cristian Stoica

33
[adresa_server/containers/[nume_container]/[nume_item]
Containerele sunt: slidecontainer, positivefeedback, ambiguousfeedback, prooffeedback și
questions, cu semnificațiile prezentate anterior. Deși pachetele http întoarse ca răspuns pot avea
formate diferite (plain/text sau Google protocol buffe rs), toate resursele sunt reținute în forma byte[],
pentru a beneficia de genericitatea designului. Serial izarea și deserializarea datelor din binar se face la
nivelul clasei ItemResource, în funcție de numele co ntainerului.

4.4.3 Serializarea și deserializarea datelor
Întrucât datele sunt reținute în binar sub forma unui v ector de octeți în sistemul de stocare a
serverului, este necesară deserializarea acestora atunci când se dorește interpretarea sau prelucrarea
datelor, respectiv serializarea lor atunci când se intr oduc sau reintroduc datele în structurile de date de
stocare.
În cazul resurselor de tip "text/plain", deserializarea se face ușor datorită constructorului
String(byte[]). Serializarea este simetrică, prin metoda toByteArray() a clasei String.
În cazul întrebărilor de feedback și a celorlalte tipu ri de feedback agregate, acestea sunt serializate și
deserializate folosind metodele clasei Google Protoc ol Buffers generate de executabilul protoc la
crearea mesajelor .proto. Deoarece la introducerea sau re tragerea oricărei întrebări este necesară o
regruparesemantică a întrebărilor, la efectuarea unei ce reri PUT sau DELETE sunt necesari pași atât de
serializare, cât și deserializare, deși în mod normal c ontiniutul binar transmis în mesajul HTTP ar putea fi
stocat direct. Acest lucru nu e posibil și din motivu l că formatul mesajului primit de la client printr-o
metodă PUT este diferit de cel reținut in binar pe ser ver și transmis clientului la o cerere GET.
Serializarea mesajelor binare a fost detaliată la capit olul referitor la mesajele transmise între clienți
și server. Acest proces se face prin clasa intermediară Builder a clasei respective mesajului Google
Protocol Buffers. Deserializarea acestor mesaje se face cu metoda parseFromData(byte[]) .

4.4.4 Modulul de grupare a întrebărilor și sincroni zarea cu acesta
Pe lângă funcționalitatea de serviciu web, care răspun de la cereri http, serverul aplicației are și rolul
de a rula gruparea întrebărilor de feedback de fiecare da tă când o nouă întrebare este pusă de o
persoană de audiență, deci o cerere PUT este efectuată pentru o întrebare pe o anumită selecție. Fluxul
logic în acest caz este următorul:
1. utilizatorul formulează o întrebare pe dispozitivul An droid, care este încapsulată într-un mesaj
FeedbackQuestion (mesaj Google Protocol Buffers) și trimisa într-o cerere PUT la adresa selecției
pentru care este adresată întrebarea
2. serverul web preia cererea, observă tipul cererii și est e apelată o metodă a modului de clusterizare
3. modulul de clusterizare preia întrebarea ca input, citeș te binarul deja existent stocat în server (într-o
formă deja agregată, în formatul SelectionsClusters ), îl deserializeaza pentru a obține întrebările
și realizează din nou clusterizarea, preluând și între barea de de input.
4. modulul de cluster serializează înapoi în formatul Se lectionsClusters cu noile clustere de întrebări,
apoi este refăcut mesajul container și binarul obțin ut este salvat în MemoryStorage .
Modulul de clusterizare a fost devoltat separat, astfe l încât eu l-am integrat într-un thread separat,
care este pornit odată cu serverul.

George-Cristian Stoica

34
Problemele evidente apar la sincronizarea între threadu rile create în background pentru cererile
web și threadul modulului de clustering. Pentru a rezol va această situație, am folosit un obiect simplu ca
lock, acesta fiind vizibil tuturor claselor serverului c a membru al clasei MemoryStore . De asemenea,
toate datele modificate la execuția clusterizarii sun t membri ai clasei MemoryStore . Toate aceste resurse
accesate în comun sunt modificate într-o zonă sincr onizată după MemoryStore.threadlLock [11] .
Astfel, threadul de clusterizare se blochează în ciclu l de rulare la apelul
MemoryStore.threadlLock.wait() , urmând ca acesa să fie atenționat cu notify din th readul serverului
web atunci când o nouă întrebare este adresată. În thre adul cererii http, atunci când sosește o nouă
întrebare, se intră într-o zonă sincronizată în care înt âi se construiește întreg setul de întrebări,
deserializându-se binarul deja reținut la care se adău gă noua întrebare, apoi se apelează notify pentru
a reporni threadul clusterer. Acesta preia setul de între bări din MemoryStore și reface clusterizarea, apoi
serializează noile clustere într-un nou mesaj SelectionClusters , care este suprascris peste binarul
stocat la URL-ul selecției. La sfârșit, acest thread iese din synchronized și repetă operația, blocându-se în
wait.

public void run()
{
QuestionHierClusterer clusterer = new QuestionHie rClusterer();
clusterer.init();

while (true)
{
clusterQuestions(clusterer);
}
}
public void clusterQuestions(, QuestionHierCluster er clusterer)
{
synchronized (MemoryStore. threadLock )
{
try {
MemoryStore. threadLock .wait();

Set<InputQuestion> input =
clusterer.setInputQuestionsFromArray(MemoryStore. feedbackQuestions );
Set<Set<Question>> tree = clusterer.cluster(inp ut);

storeClusters(clusterer, tree);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}

Exemplu cod de rulare al threadului de clustering

George-Cristian Stoica

35
4.5 Interfața de utilizare a clienților Android
Interfața aplicației oferă clientului posibilitatea u tilizării întregii funcționalități a modului de
comunicație client-server al aplicației Smart Presenta tion. Elementele vizuale permit utilizatorului să
acorde oricare tip de feedback dintre cele suportate de server, unul din cele trei tipuri fixe sau feedback
sub forma unei întrebări. De asemenea, clientul are po sibilitatea sincronizării prezentării cu cea a
speakerului, prin apăsarea butonului "Go live!". Odată intrat în acest mod, clientul poate ieși prin
apăsarea oricărui buton care obligă păstrarea slideului curent, cum ar fi intenția de selecție a unor
elemente din prezentare sau acordarea unui feedback.
Speakerul accesează serverul în mod indirect, prin sch imbarea slideului, sau în mod direct, la sfârșit,
când dorește vizualizarea întregului feedback. Scenarii le de utilizare sunt detaliate la capitolul următor.

4.5.1 Interfațarea cu prezentarea, selecția element elor
Pentru acordarea feedbackului pe o selecție a document ului PDF, trebuie întâi realizată selecția și
reprezentată într-un mod în memorie. Selecția se decla nșează la apăsarea unui buton, pentru a nu se
încerca o selecție eronată, sau pentru necesitatea re setării selecției făcute.
Selecția se face prin alegerea a doua puncte din slid e, cel de capăt stânga sus și cel de capăt dreapta
jos. În momentul realizării selecției, este generat un șir de caractere reprezentativ pentru selecție. Acest
script cuprinde numărul slide-ului și id-uri ale elemen telor din slide astfel încât să se poată reconstitui
selecția din șirul de caractere, necesară la prezentarea feedbackului pentru speaker.
Id-ul selecției folosit pentru accesarea și stocarea resurselor pe serverul web este numărul întreg
obținut din aplicarea metodei hashCode() asupra string ului. Atunci când se realizează o selecție pe
documentul PDF, se reține această mapare între string și hash-codul sau, pentru a fi posibilă operația
inversă de determinare a șirului de caractere și, deci, a selecției vizuale din id-ul selecției.

4.5.2 Metodele handler ale butoanelor
Butoanele aplicației intră, la fel ca și ferestrele, l a modulul de interfata Android. Legarea acestora de
modulul de comunicație cu serverul presupune apelarea interogărilor atunci când un buton este apăsat.
În clasa MuPDFActivity, clasa de startup a aplicați ei Smart Presentation, există definită o clasa handle r
comună pentru toate butoanele. Alegerea handlerului po trivit fiecărui buton se realizează în metoda
OnClick , prin verificarea callerului [13].
Handlerele butoanelor aplicației pot efectua două tip uri de operații, din punct de vedere al
comunicației și al accesării datelor: pot instanția o clasă AsyncTask și să apeleze execute pe aceasta, sau
pot realiza o interogare managedQuery a Content Provi derului, asupra căruia cade responsabilitatea
efectuării cererii asincrone către server, dacă datele i nterogate nu sunt în baza de date sau sunt expirate
(eng. ).
Butoanele care efectuează cereri directe care web server prin clase AsyncTask sunt cele care trimit
feedback de tip fix către server. La fel este și cazul butonului "Go live!", care declanșează o acțiune
repetitivă în cadrul unei clase AsyncTask, de sincroni zare a slide-ului cu cel existent pe server, până la
apăsarea unui alt buton care provoacă ieșirea din modu l Live.

George-Cristian Stoica

36
5. Utilizarea aplicației
5.1 Descrierea aplicației
Aplicația Smart Presentation permite utilizatorilor unor dispozitive Android care iau parte la o
prezentare să interacționeze în timp real cu aceasta, e xistând două moduri de utilizare: speaker și simplu
ușer, persoana aflată în audiență. Scopul principal a l aplicației este să permită celor din audiență să
poată selecta elemente din slide-ul curent pe care să acorde diverse tipuri de feedback, cum ar fi:
feedback pozitiv, în semn de apreciere, feedback de a mbiguitate, care indică necesitatea unor clarificări
suplimentare sau feedback de proof sau citation need ed, pentru exprimarea necesității citării sursei. În
plus, utilizatorii pot formula întrebări legate de sele cția făcută adresate speakerului, sau pot vedea
întrebările deja reținute de la alți ascultători pentru a-și exprima acordul cu una din ele. Întrebările sunt
grupate semantic pe un server central, astfel încât toț i userii să poate vedea doar o forma compactă a
întrebărilor, fiind selectate doar cele reprezentative din punct de vedere semantic.
O altă facilitate a aplicației este posibilitatea d e navigare liberă prin prezentarea descărcată pe
propriul dispozitiv, sau folosirea modului live, care s incronizează permanent prezentarea cu cea a slide-
ului speakerului până când modul este dezactivat.
La sfârșitul prezentării, speakerul poate vedea pe docu mente diversele feedbackuri primite din
audiență pe timpul prezentării astfel încât să poată răspunde mai eficient la întrebări și să își
îmbunătățească prezentarea pentru viitor.

5.2 Scenarii utilizare – screenshots
Pentru exemplificarea scenariilor de utilizare, vom pre supune existența următoarelor persoane, cu
următoarele roluri: Dan este prezentatorul, Alina, Andrei și Elena sunt simpli ascultători. Toți patru dețin
un dispozitiv Android și documentul PDF este stocat pe un server aflat în apropiere care poate fi accesa t
prin mediul wireless.
În momentul pornirii aplicației, este declanșată o ce rere către server de descărcare a documentului
PDF stocat pe acesta. La primirea răspunsului și scrie rea documentului în memorie, cei patru utilizatori
sunt întâmpinați cu o fereastră care le permite să s electeze rolul pe care îl vor avea: speaker sau simplu
ușer. Dan alege să fie speaker, ceilalți trei aleg să fie simpli ușeri. După alegerea rolului, cei patru își aleg
numele cu care vor fi reținuți în sistem (Figura 10).

Fig. 10 Ferestrele inițiale ale aplicației
În următoarele situații sunt descrise activitățile use rilor din audiență, adică Alina, Andrei și Elena.
După alegerea numelui, este încărcată prezentarea de la început și aceștia pot vedea interfața aplicației
(Figura 11).

George-Cristian Stoica

37

Fig. 11 Interfața clientului în aplicație
În continuare, Alina hotarește să parcurgă așa cum doreș te prezentarea, pentru ca este curioasă de
conținutul acesteia. Andrei și Elena hotaresc să fie sincronizați cu prezentarea ținută de Dan, pentru a fi
mai atenți la ceea ce spune acesta. Astfel, cei doi apăsă primul buton din stânga jos, cel de Go live!, care
le permite intrarea în modul sincronizat.
Pe parcursul prezentării, Alina hotareste să facă o sele cție pentru a trimite un feedback de
ambiguous. Pentru a face asta, ea apasă pe al doilea buton, cel marcat cu T, și realizează selecția. Dac ă
nu este mulțumită cu selecția făcută, ea poate reset a selecția prin apăsarea aceluiași buton.

Fig. 12 Selecție făcută pe o porțiune de text
În acest timp, Andrei și Elena se află la alt slide, cel la care se află și Dan, aceștia fiind în modul Live.
Andrei se hotareste să pună o întrebare legată de titl ul slideului. Pentru aceasta, el selectează întâi ti tlul
(Figura 13).

George-Cristian Stoica

38

Fig. 13 Selecție făcută pe titlu
Apoi, acesta apăsa pe al treilea buton de jos, care î i arăta întrebările semnificative deja
formulate pentru selecția făcută:

Fig. 14 Lista de intrebari
Andrei are posibilitatea de a alege o întrebare cu care să-si exprime acordul, sau de a alege
elementul Add question din listă, care-i permite sc rierea unei întrebări noi.

George-Cristian Stoica

39

Fig. 15 Adăugarea unei noi întrebări
Pe parcursul prezentării, Elena a acordat mai multe fee dbackuri de tip ambiguous (penultimul
buton) sau proof needed (ultimul buton), și a remarcat că, pentru unul din concepte, explicația se află
deja în prezentare, motiv pentru care se întoarce la sl ide-ul respectiv și își retrage feedbackul pe aceeași
selecție.

Fig. 15 Adăugarea unei noi întrebări
În timpul prezentării, Andrei, Elena și Alina acordă m ai multe feedbackuri de tip +1, pentru a-și
exprima o părere pozitivă legată de elementele selecta te.

George-Cristian Stoica

40
La sfârșitul prezentării, Dan poate utiliza interfața p roprie, care îi arată pentru fiecare tip de
feedback selecțiile făcute pe document, pentru a aso cia corect feedbackul cu elementele asupra cărora
acesta a fost acordat.

George-Cristian Stoica

41
6. Concluzii
Dezvoltarea aplicației Smart Presentation a necesita t utilizarea multor cunoștințe practice și
teoretice învățate în facultate, cum ar fi: protocoa le de comunicații, programare și design orientate
obiect, structuri de date, calcul paralel și sincroniz are între threaduri, baze de date sau ingineria
programelor. În plus, au fost necesare acumularea unor c unoștințe teoretice noi, cât și învățarea
utilizării unor tehnologii noi.
Dezvoltarea serverului mi-a permis să studiez arhitectu ra RESTful pentru servicii web și să învăț să
implementez un astfel de serviciu folosind framework- ul Jersey și utilizarea containerului Grizzly. Prin
studierea diverselor exemple am ales să implementez un design ierarhic al claselor resursa http, și o
clasă de stocare a datelor, accesibilă din toate resu rsele serverului. De asemenea, am folosit elemente
de detaliu ale protocolului http, cum ar fi metodele specifice protocolului și headerul de content-type,
care mi-a permis să trimit diferite tipuri de date în p achetele http.
Implementarea modulului suplimentar de grupare a ridica t probleme de sincronizare, datorită
accesului comun la date din threaduri separate și a ne cesității creării unui mecanism de comunicare
între threaduri.
Din punct de vedere al clientului, am învățat concep te importante de programare pe sistemul de
operare Android. În primul rând, ideea de entry point sa u clasa main sunt inexistente pe Android, unde
serviciile și procesele lansate la execuția unei apli cații sunt definite într-un fișier de configurare. În al
doilea rând, din punct de vedere al gândirii arhitectu rale, programarea pe Android forțează utilizatorul
să separe funcționalitățile aplicației după modelul arhitectural Model-View-Controller. Pentru
respectarea acestui pattern, am folosit numeroasele clase oferite de sdk-ul Android care facilitează
rularea paralelă a taskurilor și sincronizarea cu threadu l principal. Stocarea datelor se face într-un mod
canonic într-o bază de date Sqlite care asigură persis tența datelor. În cazul meu, am folosit o astfel de
bază de date pentru persistența unor informații, simil ar cu păstrarea unor structuri de date, dar într-un
mod mai robust și care permite accesul simplu, prin a drese URI.
Pentru a realiza cererile HTTP de la client către server, am explorat versatilitatea clasei AsyncTask,
prin care dezvoltatorului i se oferă toate mecanismele necesare sincronizării threadului apelant cu cel de
background și actualizarea datelor și a interfeței cu cele incluse în răspunsul primit de la server.
Comunicația între client și server mi-a lăsat la alege re conceperea diverselor tipuri de mesaje,
serializate în mod diferit și cu semnificații diferite , care alcătuiesc protocolul aplicației. Pentru mesaj ele
largi, de agregare a feedbackului de întrebări, am ales să folosesc mecanismul de serializare binară
Google Protocol Buffers, o soluție optimă și foarte u șor de implementat, datorită generării automate a
claselor Java dintr-un format de definire a mesajel or proprietar, user-friendly.
Rezultatul final al lucrării s-a transpus într-o apli cație care îndeplinește obiectivele formulate iniția l:
• posibilitatea sincronizării prezentării unui client An droid din audiență cu cea a speakerului;
• acordarea de feedback de tip positive feedback, ambig uous, proof needed sau sub forma unei
întrebări pe o selecție a unui slide sau pe întregul s lide curent al prezentării;
• vizualizarea feedbackului agregat în timp real și posi bilitatea exprimării acordului cu feedback
deja formulat de alte persoane;
• retragerea feedbackului propriu efectuat;
• interfețe diferite de utilizare pentru speaker și audie nta;
• vizualizarea de către speaker a unei variante finale, a gregate a tuturor tipurilor de feedback
acordate de audiență.

George-Cristian Stoica

42
În viitor, aplicația poate fi dezvoltată, pentru a pe rmite diverse facilități noi. În primul rând, este
necesară gruparea mai eficientă a întrebărilor, bazată p e un algoritm care să grupeze mai inteligent
întrebările pe baza similarității semantice și care să aleagă un centroid al clusterelor reprezentativ
pentru întrebările grupate. În prezent, gruparea se bazeaz ă în special pe cuvinte de bază și nu pe cuvinte
cheie care pot schimba sensul unei întrebări.
Alte îmbunătățiri care pot fi aduse aplicației sunt: o interfata mai interactivă și informativă a
aplicației, care să permită o vizualizare mai intuitiv ă și mai cuprinzătoare a feedbackului, devoltarea unu i
sistem de autentificare pentru a acorda privilegii dif erite ușerilor, posibilitatea încărcării în realtime a
unui document nou de prezentare sau dezvoltarea unei i nterfețe grafice a serverului, care să permită o
configurare a acestuia.
De asemenea, ar fi interesant/util de implementat o c lasificare a userilor, în funcție de o reputație a
acestora, care să le acorde o pondere mai mare propriilor feedbackuri în fața unor utilizatori noi.

George-Cristian Stoica

43
7. Bibliografie

[1] Wikipedia, Android Operating systems , 20.06.2012,
<http://en.wikipedia.org/wiki/Android_%28operating_ system%29>

[2] Zigurd Mednieks, Laird Dornin, G. Blake Meije, Programming Android, 2nd Edition, O'Reilly,
2011

[3] Documentația oficială Android , 20.06.2012, <http://developer.android.com>
[4] International Organization for Standardization, ISO 32000-1:2008 Document management –
Portable document format – Part 1: PDF 1.7 , 20.06.2012,
<http://www.adobe.com/content/dam/Adobe/en/devnet/a crobat/pdfs/PDF32000_2008.pdf>
[5 ] Website Grizzly , 20.06.2012, <http://grizzly.java.net>

[6] Sameer Tyagi, RESTful Web Services,
< http://www.oracle.com/technetwork/articles/javase/i ndex-137171.html>

[7] Documentația oficială Jersey, 20.06.2012, < http://jersey.java.net/nonav/document ation>

[8] RESTful Web Services Developer's Guide , 20.06.2012,
<http://docs.oracle.com/cd/E19776-01/820-4867/ggrby /index.html>

[9] Documentația oficială Google Protocol Buffers , 20.06.2012,
<https://developers.google.com/protocol-buffers/>

[10] Vogella tutorials , 20.06.2012,
<http://www.vogella.com/articles/AndroidSQLite/arti cle.html>

[11] Scott Oaks, Henry Wong , Java Threads, 3rd Edition, O'Reilly, 2004
[12] RESTful Web Services Developer's Guide, Chapter 5 – Jersey Sample Applications ,
20.06.2012 <http://docs.oracle.com/cd/E19776-01/820 -4867/ggrby/index.html>
[13] Marko Gargenta , Learning Android – Building Applications for the Android Market , O'Reilly,
2011