George Cristian Stoica AndroidSmartPresentationFeedback Document

UNIVERSITATEA POLITEHNICA BUCURETI
FACULTATEA DE AUTOMATIC I CALCULATOARE

DEPARTAMENTUL CALCULATOARE
LUCRARE DE LICEN
Smart Presentation Feedback
Comunicaia client-server
Coordonatori tiinifici:
Absolvent:
Prof. dr. ing.

ng. Adina Magda Florea
George-Cristian
Cristian Stoica
As. dr. ing. Andrei Olaru
BUCURETI
2012
Rezumat
O prezentare inut n faa unei audiene numeroase reprezint o activitate predominant
unilateral, n care cei prezeni n audien nu pot interveni n niciun fel pe parcursul prezentrii, astfel
nct strngerea unui feedback relevant din partea acestora este dificil. Acest lucru se ntmpl chiar i
n condiiile n care majoritatea persoanelor dein un dispozitiv smartphone sau chiar o tablet, deci un
suport electronic pe care ar putea urmri prezentarea i prin care s-ar putea devolta o interaciune ntre
acetia i speaker.
Aplicaia Smart Presentation ofer oportunitatea celor din audien s urmreasc prezentarea
fcut de speaker pe propriul dispozitiv Android, smartphone sau tableta, n mod sincronizat cu
prezentarea speakerului sau nu. n plus, aplicaia ofer posibilitatea acordrii de feedback direct pe
documentul prezentrii, n timp real, astfel nct speakerul s aduc lmuriri sau s rspund la ntrebri
chiar n timpul prezentrii, fr intervenia verbal a audientei. Speakerul are acces la forma agregat a
feedbackului, extrem de util n cazul unei audiente mari.
Pentru realizarea acestei aplicaii, am dezvoltat un sistem client-server, bazat pe cereri efectuate de
clieni, dispozitivele Android, ctre un server web, care pune la dispoziie resurse ce pot fi accesate prin
adresele lor URL. Resursele pot fi documentul prezentrii sau feedback agregat adresat de cei din
audien.
ii
CUPRINS
1. Introducere
1.1 Contextul proiectului
1.2 Ideea i Scopul proiectului
1.3 Structura proiectului
1.4 Structura lucrrii
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 funcionale ale sistemului
3.2 Arhitectura clientului Android
3.3 Arhitectura serverului web
4 Detalii implementare
4.1 Accesarea resurselor pe baza URL i a protocolului HTTP
4.1.1 Structura URL
4.1.2 Tipurile mesajelor HTTP
4.2 Implementarea protocolului de comunicaie
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 Persistena datelor n Sqlite i accesarea resurselor interne prin ContentProvider
4.3.3 Accesarea resurselor de pe web server prin mesaje asincrone
4.4 Implementarea serverului web
4.4.1 Iniializarea 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 ntrebrilor i sincronizarea cu acesta
4.5 Interfaa de utilizare a clienilor Android
4.5.1 Interfaarea cu prezentarea, selecia elementelor
4.5.2 Metodele handler ale butoanelor
5 Utilizarea aplicaiei
5.1 Descrierea aplicaiei
5.2 Scenarii utilizare - screenshots
6 Concluzii
7 Bibliografie
iii
George-Cristian Stoica
1. Introducere
1.1 Contextul proiectului
Prezentrile realizate n faa unei audiente de mrime medie sau mare pot fi uneori greu de urmrit
din diferite motive, cum ar fi incapacitatea persoanelor din audien de a nelege anumite concepte din
materialele prezentate, care duc la pierderea ateniei, sau imposibilitatea acestora de a reveni asupra
unor slide-uri anterioare.
Aceste prezentri ar putea deveni mai interactive, prin implicarea asculttorilor nc din timpul
audienei n procesul de apreciere pozitiv sau negativ a elementelor prezentate, precum i prin
posibilitatea urmririi prezentrii att n timp real ct i a revenirii asupra unor slideuri anterioare sau a
avansrii ctre slideuri urmtoare.
1.2 Ideea i scopul proiectului

Ideea proiectului Smart Presentation este de a realiza o interaciune strns ntre membrii audienei
unei prezentri i cel care ine prezentarea (asupra cruia m voi referi n continuare ca speaker). 1
Ca precondiii, se presupune c att speakerul, ct i cei din audien posed cte un dispozitiv
mobil, tableta sau telefon mobil, avnd instalat sistemul de operare Android. De asemenea este necesar
un server conectat la un router wireless, pentru a permite conectarea cu dispozitivele Android.
Funcionalitatea aplicaiei pornete de la posibilitatea membrilor audientei de a urmri pe propriul
dispozitiv Android prezentarea inut de speaker. Speakerul este cel care pornete prezentarea, care
schimb slide-urile i care termin prezentarea. Cei din audien au posibilitatea de a urmri
prezentarea n timp real i pe dispozitivul lor ntr-un mod live, sau pot naviga liber prin restul prezentrii.
n plus, acetia pot furniza feedback n timp real prezentrii astfel: pot selecta poriuni din prezentare,
asupra crora pot furniza feedback pozitiv, de apreciere, feedback de ambiguitate, prin care se remarc
necesitatea unor clarificri ale acelor elemente sau feedback de cerere a unor dovezi (proof). De
asemenea, cei din audien pot pune ntrebri legate de elementele selectate, sau pot alege s adere la
o ntrebare deja pus, acetia avnd posibilitatea de sincronizare a feedbackului cu cel acordat de toi
cei aflai n audien. n plus, acetia vor avea i posibilitatea retragerii propriului feedback, dac ulterior
nu l mai consider necesar. La finalul prezentrii, speakerul poate vedea o form agregat pentru toate
tipurile de feedback. n cazul ntrebrilor adresate speakerului referitor la o selecie fcut pe
prezentare, agregarea se face prin alegerea unor ntrebri reprezentative din punct de vedere semantic
i gruparea (eng. clustering) celorlalte ntrebri n jurul acestora.
Comunicarea ntre dispozitive i sincronizarea elementelor de feedback acordate prezentrii se face
prin intermediul unui server central care depoziteaz datele agregate primite din partea tuturor
clienilor cu care se comunic wireless. Serverul este i cel care conine prezentarea n format PDF,
aceasta fiind descrcat pe fiecare dispozitiv mobil care acceseaz aplicaia SmartPresentation.
1.3 Structura proiectului

Proiectul a fost structurat n patru module cu funcionaliti diferite, fiind cinci persoane implicate n
dezvoltarea aplicaiei. Cele patru arii sunt:
Pagina web cu ideea proiectului, 20.06.2012, <http://aimas.cs.pub.ro/androidEDU/>
modulul de manipulare a prezentrii PDF. Acesta presupune folosirea unei biblioteci open
source de manipulare a formatului PDF, pentru a permite navigarea prin prezentare, selectarea
unor elemente ale prezentrii prin folosirea ecranului touchscreen al dispozitivului Android i
evidenierea seleciei fcute prin diverse culori de highlighting.
interfaa clientului pe Android, care include toate elementele vizuale prin care clientul
interacioneaz cu aplicaia (ferestre, butoane, liste).
modulul de comunicaie client-sever, care asigur transmisia resurselor ntre dispozitive i server
i sincronizarea acestora.
modulul de clusterizare a ntrebrilor puse de audin pe baza similaritilor semantice.
Partea mea de proiect a constat n implementarea modulului de comunicaie ntre clienii Android i
server. Acest modul include partea de stocare a datelor att pe Android, ct i pe server, dezvoltarea
serverului web i a protocolului de comunicaie bazat pe HTTP i Google Protocol Buffers, obinerea
resurselor prin URLuri, tipul mesajelor i modalitatea de serializare a acestora, precum i interfaarea pe
server cu modulul de clusterizare a ntrebrilor i interfaarea pe sistemul de operare Android cu
modulul de manipulare a PDFurilor i cu interfaa de utilizare.
1.4 Structura lucrrii

n continuare, capitolele acestei lucrri sunt structurate astfel: aspecte teoretice ale proiectului,
urmate de tehnologiile folosite la implementarea proiectului, cu detalierea celor folosite la comunicaia
client-server i la crearea protocolului de comunicaie. Urmeaz arhitectura aplicaiei, n care sunt
prezentate diferitele module ale aplicaiei i interaciunea dintre ele, din nou cu detalierea celor de
backend direct implicate n schimbul de date ntre clieni i server. Capitolul detaliilor de implementare
prezint metodele de programare folosite, oferind spre exemplificare poriuni de cod explicate. n cadrul
acestui capitol este descris protocolul de comunicaie ntre server i clieni, tipurile de URLuri folosite
pentru accesul resurselor, tipurile mesajelor schimbate i diferitele tipuri de serializare. Mai apare i
detalierea interfarii dintre server i modulul de clusterizare a ntrebrilor de feedback.
n final, capitolul de utilizarea a aplicaiei prezint n detaliu aplicaia i modalitatea de utilizare
interfeei grafice, prin screenshoturi i nfiarea unor diverse scenarii de utilizare.
2. Tehnologii folosite
2.1 Sistemul de operare Android
Android este un sistem de operare pentru dispozitive mobile, telefoane sau tablete. Android a
devenit lider mondial n acest segment n 2010, n primul trimestru al anului 2012 raportnd o cot de
59% din piaa mondial a smartphoneurilor, cu un total aproximat la 331 milioane de dispozitive cu
acest sistem de operare instalat1.
Android a nceput de la o companie mic, achiziionat 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, Inel, LG, Motorola, Samsung Electronics, Nvidia, TMobile sau Texas Instruments.
Kernelul sistemului de operare Android se bazeaz pe kernelul de Linux. Acest kernel a suferit
modificri 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 aplicaiilor i bibliotecilor existente de Linux pe Android.
Principalele modificri pe care Google le-a adus ntr-o prima faza kernelului au fost legate de
eficientizarea consumului bateriei. Aceste modificri au fost respinse n prima faza de dezvoltatorii
kernelului Linux de baz, motivnd lipsa de ncredere n intenia Google de a se ocupa n continuare de
acest cod. n 2010 s-a fcut un pas major pentru integrarea modificrilor din Android n Linux, prin
adugarea unui patch care mbuntea frameworkul de wakeup events existent i care permitea
driverelor Android s fie uor integrate n Linux de baz. n August 2011 Linus Torvalds spunea c n
patru sau cinci ani Linux i Android se vor ntoarce la un kernel comun [1].
Arhitectura Android presupune existena a patru layere, cel de la baza fiind kernelul de Linux. Al
doilea layer, cel de middleware, conine biblioteci de C. Acesta este cod nativ, rulnd direct peste cel de
Kernel. Urmtorul layer este cel de application framework, care cuprinde biblioteci compatibile Java,
bazate pe versiunea de Java Apache Harmony.
Fig. 1 Arhitectura Android

1
Wikipedia, The Free Enciclopedia, 20.06.2012,

< http://en.wikipedia.org/wiki/Android_(operating_system)>
2
Kebomix blog, 20.06.2012, <http://kebomix.wordpress.com/2010/08/17/android-system-architecture/>
Maina virtual care face translaia din codul Java n byte-code se numete Dalvik virtual machine, i
se deosebete de maina virtual clasic JVM prin faptul c nu este o main bazat pe stiv, ci una
bazat pe regitri. Un tool numit dx este folosit pentru a converti o parte a fiierelor .class Java ntr-un
format .dex. Mai multe clase sunt incluse ntr-un singur fiier .dex. Stringurile duplicate i alte constante
folosite n mai multe fiiere class sunt incluse doar o dat n outputul .dex, pentru conservarea spaiului.
Java bytecode-ul este de asemenea convertit ntr-un set de instruciuni definit de Dalvik Virtual
Machine. Un fiier necomprimat .dex este sensibil mai mic dect o arhiv .jar, derivat din aceleai
fiiere .class. O alt diferen major fa de clasicele JVM este introducerea compilatorului JUST-INTIME, care reprezint o metod hibrid fa de cele dou metode clasice de runtime (intrepretat sau
static cod compilat). Astfel, acest compilator translateaz codul din bytecode n machine code la
runtime, nainte de a-l rula nativ.
Fiecare aplicaie Android ruleaz n propriul proces cu propria instan a mainii virtuale. Dalvik a
fost dezvoltat n aa fel nct un dispozitiv poate rula mai multe maini virtuale eficient. Maina virtual
Dalvik se bazeaz pe kernel-ul Linux pentru funcionalitile de baz, cum ar fi gestionarea thread-urilor
i meninerea nivelului de memoriei sczut.
Layerul de application framework cuprinde acele servicii scrise n Java care fac legtura ntre aplicaii
i sistemul de operare, fiind separate pe diverse funcionaliti: Activity Manager, Content Providers,
Resource Manager, Notification Manager, View System, Telephony Manager, Location Manager i altele.
Layerul de top este cel al aplicaiilor, unde dezvoltatorii pot aduga noi aplicaii utiliznd API-ul existent
sau pot modifica aplicaiile deja existente.
n prezent, Android are o vast comunitate de dezvoltatori care scriu aplicaii (apps) care extind
funcionalitatea dispozitivelor. Dezvoltatorii folosesc n principal codul versiunii custom de Java.
Applicaiile pot fi descrcate de pe magazine online ca Google Play (fostul Android Market), magazinul
condus de Google. n octombrie 2011 erau mai mult de 500 000 aplicaii disponibile pentru Android.
n cadrul proiectului Smart Presentation, o mare parte din devoltare s-a fcut pe sistemul de operare
Android, folosind versiunea 2.3 a sdk-ului Android. Dezvoltarea s-a fcut n Eclipse, acesta fiind mediul
standard i global folosit pentru crearea aplicaiilor Android, datorit pluginului Android i a
emulatorului care poate fi lansat direct din interfaa IDEului.
n cadrul dezvoltrii, am folosit att cod nativ C, ct i cod standard Java. Codul nativ face parte din
biblioteca mupdf, pe care am folosit-o la manipularea prezentrii n format PDF, pentru partea de
selecie. Codul nativ a fost compilat folosind toolul ndk, biblioteca rezultat putnd fi ncrcat direct n
codul de Java.
Pentru modulul client-server, am folosit design patternul Model-View-Controller, detaliat la capitolul
Arhitectura sistemului. Pentru implementarea acestui pattern am folosit clasele existente n API-ul
Android, care ncurajeaz separarea ariei funcionale, comunicarea pe retea sau persistena datelor, de
interfaa grafic a aplicaiei, pentru a se asigura un flow continuu al interfeei, fr ntreruperi care ar
duna calitii utilizrii. Principalele mecanisme folosite sunt cel de ContentProvider, care returneaz
activitii de frontend coninut pe baza unor interogri (echivalent conceptului de Model). n cadrul
ContentProviderului, persistena datelor este asigurat printr-o baz de date SQLlite, iar comunicarea cu
serverul wireless se face asincron, n cadrul unor threaduri separate. Pentru rularea acestor taskuri, APIul Android pune la dispoziie numeroase soluii, cea mai popular fiind cea de a extinde clasa AsyncTask,
aceasta oferind metode handler pentru execuie i pentru returnarea rezultatelor.
2.2 Tehnologiile specifice folosite pentru comunicarea client-server

Pentru crearea serverului central, responsabil cu centralizarea feedbackului de la clieni, distribuia
acestuia ctre clieni i persistena datelor, am avut de ales ntre multiple tehnologii disponibile, cum ar
fi realizarea unei comunicaii asincrone pe socketi sau implementarea unui mecanism de Remote
procedurce calling. Alegerea cea mai potrivit mi s-a prut n final implementarea unui web service,
datorit protocolului de nivel superior, Hypertext transfer 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, att de tip binar ct i plain text, prin completarea headerului de mime-type.
Un alt punct forte al alegerii unui sistem client-server bazat pe protocolul HTTP este portabilitatea,
fiecare limbaj de programare avnd biblioteci care faciliteaz crearea mesajelor HTTP i
transmiterea/recepionarea lor pe baza URLului. Datorit folosirii unui limbaj compatibil Java pe
Android, eu am ales tot Java pentru devoltarea serverului web. Tehnologia Java pentru crearea web
serverelor se bazeaz pe o arhitectur de tip servlet-container, care permite definirea unor scripturi Java
(servlets) i nregistrarea acestora, de obicei ntr-un fiier de configurare xml, pentru a fi ncrcate
dinamic ntr-un container web. Un container web este acea component a unui serviciu web care
interacioneaz cu servleturile i este responsabil cu managementul ciclului de via a acestora i cu
maparea lor la un URL. Un web container implementeaz contractul unei componente web Java EE,
specificnd un mediu de runtime care asigur securitatea, concurena, managementul ciclurilor de viata,
completarea tranzaciilor i alte servicii.
n cazul acestei aplicaii, pentru implementarea serverului web am ales s folosesc un web container
Glassfish, bazat pe popularul Tomcat. Pentru interaciunea cu acest container am folosit API-ul Grizzly,
care va fi detaliat ntr-un subcapitol urmtor. Pentru maparea resurselor http unor metode http i a
unor URLuri, am folosit frameworkul Java Jersey, o soluie care respect arhitectura RESTful, cea mai
folosit n momentul de fa pentru dezvoltarea serviciilor web.
Protocolul HTTP
Hypertext Transfer Protocol, pe scurt HTTP, este un protocol la nivelul aplicaie care st la fundaia
comunicaiei n World Wide Web. Hypertext reprezint un set de obiecte care construiesc conexiuni
ntre noduri prin legturi logice, hyperlinks. HTTP este protocolul care permite transferul unor astfel de
obiecte1.
HTTP este un protocol de tip cerere-rspuns n modelul arhitectural client-server. Un client, cel mai
des un web browser, trimite o cerere HTTP ctre un server web, care ntoarce un rspuns. Acest rspuns
conine o stare al completrii cererii i, n caz de succes, informaia cerut.
Resursele HTTP sunt identificate i localizate pe reea prin Uniform Resource Locators (URLs)
folosind schema http URI definit n RFC 3986 astfel:
<nume_schema> : <poriunea_ierarhic> [ ? <query> ] [ # <fragment> ]
n cazul HTTP numele schemei este http. Partea ierarhic ncepe cu un dublu forward slash "//",
urmat de un nume al autoritii, care poate fi un nume de domeniu sau un ip, urmat apoi de un port
opional, precedat de ":". Dup autoritate urmeaz un path construit ca o succesiune de segmente,
asemntor unei structuri de directoare, caracterul separator fiind "/". Poriunea de query este
opional, ncepe cu "?" i conine informaie adiional 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, < http://en.wikipedia.org/wiki/Http>
asemenea opional, ncepe cu "#" i conine o directiv ctre o resurs secundar, cel mai des un
atribut id al resursei principale, aa cum se ntmpl n cazul documentelor HTML.
HTTP definete nou metode care indic aciunea dorit asupra resursei accesate. Aceste nou
metode sunt: HEAD, GET, POST, PU, DELETE, TRACE, OPTIONS, CONNECT i PATCH. Cele mai utilizate
sunt cele de GET, prin care se citete resursa, i cele de POST, PUT i DELETE, prin care se modific
resursa. Metodele safe (sigure) sunt considerate cele prin care se intenioneaz doar citirea informaiei,
fr modificarea strii serverului. Acestea sunt HEAD, GET, OPTIONS i TRACE. Metodele idempotente
sunt cele asupra crora mai multe cereri identice ar trebui s aib acelai efect. Acestea sunt POST i
DELETE.
O cerere HTTP conine urmtoarele :
o linie de request, spre exemplu GET /diverse/car.jpg HTTP/1.1 care formuleaz o cerere pentru
resursa /diverse/car.jpg de la server.
Headere Http, cum ar fi Accept-Language: en-US, Accept-Charset: utf-8, etc.
O linie goal
Un corp al mesajului, opional
Un rspuns HTTP conine urmtoarele:
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, opional
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
tranzacii HTTP.
Datorit necesitii trasmiterii unor tipuri diferite de coninut prin mesajele HTTP, am folosit n
cadrul aplicaiei Smart Presentation setarea headerului Content-Type prin care se specific mime-typeul
coninutului. Un mime-type (Multipurpose Internet Mail Extension) este un standard Internet care a
pornit de la descrierea seturilor de caractere folosite la formatul email, ajungnd azi s fie utilizat ca
standard de descriere al coninutului unui mesaj web n general. Un astfel de antet descrie att
coninuturi de tip text, ct i coninut binar. n cazul clienilor i al serverului, interpretarea acestui cmp
este vital pentru alegerea modului n care resursa este citit, respectiv scris.
Pentru aplicaia Smart Presentation, am folosit urmtoarele tipuri mime:
text/plain definete un coninut n text clar, necodat.
application/pdf indic prezena unui fiier PDF n interiorul mesajului, n format binar
application/x-protobuf indic un coninut binar, serializat cu Google Protocol Buffers. Este

datoria clientului i a serverului de a serializa, respectiv deserializa acest format binar.
Grizzly Web Container

Grizzly este un framework web nscut din dorina de a ajuta dezvoltatorii s profite de avantajele
API-ului Java NIO (Java new I/O). Este devoltat de comunitatea GlassFish, sub conducerea Oracle1. Pn
la apariia acestui API, scrierea unor aplicaii server scalabile n Java era foarte dificil, problemele de
thread management fcnd imposibil scalarea unui server la mii de utilizatori. Scopul Grizzly este
dezvoltarea unor sisteme server robuste i scalabile, oferind componente extinse ale frameworkului
Java NIO ca:
- un framework HTTP Protocol pentru crearea unor aplicaii HTTP costumizate;
- un framework HTTP Server care ofer abstractizri la nivel nalt ale protocolului HTTP (similare
Servlets).
Grizzly folosete un sistem keep-alive bazat pe clasele Selector ale NIO, care suport monitorizarea
conexiunii i previn atacurile de tip Denial-of-Service. Sistemele Denial-of-Service adug suport pentru
validare IP, numrul tranzaciilor completate per IP, detecia conexiunilor inactive, cu scopul de a
preveni epuizarea sau atacurile "flooding". Toate aceste servicii sunt folosite n conjuncie cu sistemele
Keep-alive. Conectorul Grizzly va nainta cererile pentru resursele statice i dinamice ctre containerul
servleturilor, care proceseaz cererile pentru resurse statice ntr-un servlet dedicat
(org.apache.ctlina.servlets.DefaultServlet) [5].
Servicii Web RESTful i Jersey JAX-RS

Representational State Transfer (REST) reprezint un stil arhitectural bazat pe standardele web i pe
protocolul HTTP, pentru sisteme distribuite c World Wide Web. REST s-a evideniat n ultimii ani ca
modelul de design predominant al web-ului, datorit simplitii sale. REST a fost descris n 2000 de Roy
Fielding, n lucrarea sa de doctorat2.
ntr-o arhitectur bazat pe REST, totul este o resurs. O resurs este accesat printr-o interfa
comun bazat pe metodele standard HTTP. ntr-o arhitectur REST, exist tipic un server REST care
asigur accesul la resurse i clieni REST care acceseaz sau modific resursele. Fiecare resurs ar trebui
s suporte operaiile standard HTTP (GET, POST, PU, DELETE). 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/ctre un service
provider, ceea ce duce la reducerea bandwidth-ului consumat. REST are i o alt metodologie de
manipulare a erorilor: n timp ce SOAP poate avea mesaje definite de eroare, REST necesit folosirea
mecanismelor HTTP de error handling .
Stilul arhitectural REST impune anumite direcii de luat n considerare la realizarea designului,
implementarea componentelor individuale fiind la discreia dezvoltatorului:
Client-server o interfa uniform separ clienii de servere. Separarea preocuprilor nseamn c,
spre exemplu, clienii nu se ocup de stocarea datelor, aa cum serverul nu se ocup cu interfaa
utilizatorilor sau cu starea clienilor. Astfel, serverele i clienii pot fi dezvoltai independent, interfaa
rmnnd constant.
Grizzly website, 20.06.2012, < http://grizzly.java.net/>

Roy Fielding, "Architectural Styles and the Design of Network-based Software Architectures", 20.06.2012,
<http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>
2
Stateless acest principiu asigur c niciun context al clientului nu este memorat pe server ntre
cereri. Fiecare cerere efectuat conine toate informaiile necesare, i orice informaie de stare
a sesiunii este stocat pe client. Aceasta este o caracteristic de rezisten la erori a serverelor.
Cacheable clienii pot reine n cache rspunsurile. O memorie cache bine ntreinut poate
mbunti scalabilitatea i performana sistemului, prin reducerea numrul de cereri de la
clieni la server.
Layered un client nu-i poate da seama prin interfata comun dac este conectat direct la
server sau la un proxy intermediar. Servere intermediare pot mbunti scalabilitatea
sistemului prin load-balancing sau prin partajarea unei memorii cache.
Code on demand (opional) serverele pot s extind temporar funcionalitatea 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

definete tipic un URI de baza pentru resurse i tipurile MIME suportate (XML, Text, JSON, Protocol
Buffers, etc) i setul de operaii HTTP. Aceste metode standard sunt [6]:
GET definete un acces la citirea unei resurse, fr 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; operaia trebuie s fie idempotent, 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 producie a

standardului JAX-RS (JSR 311) pentru dezvoltarea web serviceurilor RESTful. Dar este mai mult dect
implementarea referinei, oferind i un api prin care programatorii pot extinde Jersey pentru nevoile
proprii [7]:
Standardul JAX-RS implementat de Jersey suport urmtoarele 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 aplicaie, n cazul folosirii unui
container c Grizzly
@POST
indic faptul c metoda va rspunde unei cereri POST
@GET
indic faptul c metoda va rspunde unei cereri GET
@PUT
indic faptul c metoda va rspunde unei cereri PUT
@DELETE
indic faptul c metoda va rspunde unei cereri DELETE
@Produces(mimetype [, more types])
definete ce mime-type va avea coninutul returnat l ao metoda adnotat cu

@GET. Mime-tipurile pot fi de tip "plain/text" sau binare, c "application/pdf"
sau
"application/x-protobuf".
Alte
exemple:
"application/xml",
"application/json"
@Consumes(mimetype [, more types])
Definete ce mime-type este consumat de aceast metod, PU sau POST
@PathParam
Folosita pentr a injecta valori din URL c parametru al metodei. Se folosete

spre exemplu la obinerea 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 definirea oricrui format de serializare a coninutului
propriu-zis al pachetului, att timp ct i emitorii i receptorii definesc programatic metode de citire i
scriere a acelor mesaje. Limbajul de facto folosit nc pentru schimbul de date este XML, datorit
simplitii sale i uurinei de citire. Totui, din dorina optimizrii utilizrii benzii de transfer , n dauna
lizibilitii, n cazul mesajelor mari sau a situailor n care exist necesitatea schimbului unui numr
foarte mare de mesaje, au ctigat teren i formatele de serializare binare [9].
Pentru serializarea mesajelor de mrime potenial mare, am folosit soluia Google Protocol Buffers,
un mecanism extensibil, neutru din punct de vedere al limbajului i al platformei pentru serializarea
binar a datelor, reprezentnd o variant mult mai eficient fa de XML i JSON. Acest mecanism a fost
dezvoltat de Google pentru uz intern, acetia crend compilatoare pentru C++, Java i Python disponibile
publicului larg printr-o licen open source.
Designul Protocol Buffers pune accentul pe simplitate i performan. A fost devoltat special pentru
a crea o alternativa mai compact i, deci, mai rapid dect XML. Metoda de creare a mesajelor Protocol
Buffers are la baz un limbaj de descriere a interfeei (IDL) care descrie structura datelor ntr-un format
foarte simplu. Aceste "mesaje" sunt definite ntr-un fiier de definire Proto (.proto) care este compilat cu
un executabil protoc. Compilarea genereaz cod care poate fi invocat de destinatarul sau receptorul
acestor structuri de date. Clasele generate pun la dispoziia programatorului metode Get i Set pentru
cmpurile mesajelor, asigurnd citirea i manipularea facil a acestora. De asemenea, se pot defini
mesaje ncapsulate n cadrul altor mesaje, care n mod programatic vor fi translatate n clase inner. O
alt facilitate a claselor generate dinamic este posibilitatea obinerii unei instane a mesajului direct din
streamul de octei.
n mod canonic, Protocol Buffers sunt serializate ntr-un format binar care este compact, forwardcompatible i backwards-compatible. Datorit simplitii 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;
}
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 concepte de programare orientat obiect, cum este
ncapsularea.
Astfel, eficiena acestui mecanism de serializare este dat att de dimensiunea extreme de redus a
pachetului care este transferat pe retea, ct i de de modul foarte succinct i compact de definire a
formatului mesajului. Aceste aspecte sunt net superioare limbajului XML, motiv pentru care foarte
multe aplicaii folosesc astzi acest mecanism de serializare. Dezavantajul Google Protocol Buffers fa
de XML este acela c nu e human-readable, fiind un limbaj binar prea puin important ns pentru
aplicaii care nu pun accentul pe urmrirea coninutului mesajului ntre procesele de serializare i
deserializare.
Fig. 2 Comparaie Xml Google Protocol Buffers
n cadrul proiectului Smart Presentation, am folosit Protocol Buffers la transmiterea ntre client i
server a feedbackului acordat de asculttori sub forma de ntrebri puse asupra unor elemente selectate
din prezentare. Serverul este cel responsabil de serializarea clusterului de ntrebri, mesajul proto fiind
prezentat n detaliu la capitolul detaliilor de implementare.
1
Alternative to XML Protocl Buffers. 20.06.2012, <http://afrozahmad.hubpages.com/hub/protocolbuffers>
10
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 aflat la baza formatului. Scopul su 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. Dei PostScript i PDF sunt nrudite, sunt formate
diferite. PDF folosete capacitatea limbajului PostScript de randare de stiluri complexe de text i grafic
i aduce aceast caracteristic att pe ecran, ct i la imprimare. Pentru PDF s-a ales o flexibilitate
redus n favoarea unei eficiene i unei predictibiliti mai bune. Spre deosebire de PostScript, PDF
poate conine o mulime de structuri de document, link-uri, precum i alte informaii conexe, dar nu
poate schimba rezoluia, sau s foloseasc orice alte caracteristici specifice hardware.
Sintaxa PDF poate fi mprit n patru pri [4]:
Obiecte. Un document PDF este o structur de date compus dintr-un set redus de tipuri de obiecte.
PDF include opt tipuri de baza de obiecte: valori boolene, numere ntregi i reale, iruri de caractere,
nume, vectori, dicionare, fluxuri de date i obiectul null.
Structura fiierului. Structura fiierului PDF determin cum sunt stocate n fiier obiectele, cum sunt
accesate i cum sunt modificate. Aceast structur este independent de sintaxa obiectelor.
Structura fiierului PDF este format din urmtoarele patru elemente:
o
Un antet format dintr-o singura linie specificnd versiunea PDF.
Un corp coninnd obiectele ce compun documentul.
Un tabel cross-reference coninnd informaii despre obiectele indirecte din fiier
Un trailer oferind locaia tabelului cross-reference.
Structura iniaial poate fi modificat ulterior, ceea ce adug elemente adiionale la finalul
fiierului.
Structura documentului. Structura documentelor PDF specific modul cum obiectele de baz sunt
folosite pentru reprezentarea componentelor unui document: pagini, fonturi, adnotri etc.
Catalogul documentului este un dicionar care conine referine la alte obiecte care definesc
coninutul, cuprinsul, threaduri de articole, nume de destinaii i formulare interactive
Paginile documentului sunt acesate printr-o structur cunoscut ca arborele de pagini (eng.
page tree), care definete ordonarea de pagini n document. Folosind aceast structur
arborescent aplicaiile de citit PDFuri care folosesc o cantitate limitat de memorie, pot deschide
imediat un document coninnd sute de pagini. Arborele conine noduri de dou feluri: noduri
interne reprezentate de arborii de pagini i frunze reprezentate de obiectele pagin.
Fluxuri de date. Un flux de date PDF conine o secven de instruciuni care descriu modul de
apariie al paginii sau alte entiti grafice. Aceste instruciuni, dei sunt reprezentate c obiecte, sunt
diferite din punct de vedere conceptual de obiectele folosite n descrierea structurii documentului.
11
Datele dintr-un flux de date de coninut sunt interpretate ca o secven de operatori i operanzii
acestora. Un flux de date de coninut poate descrie modul de prezentare a unei poze sau poate fi
tratat ca un element grafic n alte contexte.
Sistemul de coordonate definete spaiul n care randarea are loc. Determin poziia, orientarea i
dimensiunea textului, graficelor i imaginilor ce apar pe pagin (Figura 3).
Coninutul unei pagini apar n cele din urm pe un dispozitiv de ieire raster, cum ar fi un ecran sau o
imprimant. Asemenea dispozitve variaz n sistemul de coordinate folosit pentru a adresa pixeli.
Sistemul particular al unui dispozitiv se numete spaiul dispozitv (eng. device space). Originea sistemului
de coordinate al dispozitivelor poate fi n locuri diferite, de asemnea i axele pot avea orientri diferite.
Pentru a evita dependena de dispozitiv, PDF definete un sistem de coordonate independent de
dispozitiv. Acest sistem de coordonate se numete spaiul utilizator (eng. user space).
Fig. 3 Relaiile dintre sistemele de coordonate (imagine preluat din ISO 32000-1)
Pe lng aceste dou sisteme de coordonate PDF mai folosete i alte spaii de coordonate [4]:
Coordonatele pentru text va fi specificat n spaiul text. Transformarea din spaiu text n spaiu
utilizator va fi definit de o matrice n combiantie cu ali parametrii specifici textului respectiv.
Simbolul unui caracter dintr-un font este definit n spaiul simbol (eng. glyph space).
Transformarea din spaiul simbol n spaiul text va fi realizat de matricea de font.
Toate imaginile vor fi definite n spaiul imagine. Transformarea din spaiul imagine n spaiul
utilizator este predefinit i nu poate fi modificat.
Biblioteca MuPDF
MuPDF este o bibliotec software gratuit i open source dezvoltat n C care implementeaz un
motor de parsare i randare de PDF-uri i XPS-uri. Acesta este utilizat n principal pentru a face pagini n
bitmapuri, dar ofer de asemenea suport pentru alte operaiuni, cum ar fi cutarea, listarea cuprins i
hyperlinkuri. Motorul de randare n MuPDF este adaptat pentru grafic de nalt calitate. Aceasta
randeaz textul cu o precizie de fraciuni de pixel pentru o calitate ct 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
susine PDF 1.7, cu transparen, criptare, hyperlinkuri, adnotri, cutarea n text i mai multe. Suport,
de asemenea, i documente OpenXPS. Nu ofer suport pentru caracteristici interactive, cum ar fi
12
completare de formulare sau JavaScript. Un alt avantaj pentru care am ales MuPDF este acela c este
foarte bine modularizat, astfel nct alte caracteristici pot fi adugate dac se dorete acest lucru.
Exist un numr de aplicaii software gratuite care folosesc MuPDF pentru a randa documente PDF,
cel mai important fiind Sumatra PDF. MuPDF este, de asemenea, disponibil ca pachet pentru Debian,
Fedora, FreeBSD Ports i OpenBSD Ports.
MuPDF folosete o structur de date complex pentru reprezentarea intern a documentului PDF,
de care se folosete pentru a manipula fiierul pentru diferite funcionaliti, precum randare a
paginilor, extragere de text, de imagini, cutare n text etc. Practic realizeaz o copie n memorie a
fiierului PDF aflat pe hard. Folosirea acestei structuri care e completat cu date efective din fiierul PDF
faciliteaz realizarea de noi funcionaliti, cum a fost i cazul acestui proiect.
13
3. Arhitectura sistemului
3.1 Descrierea arhitecturii i modulele funcionale ale sistemului
Arhitectura sistemului aplicaiei Smart Presentation este de tip client-server, clienii fiind, din punct
de vedere logic, de dou tipuri: speakerul, cel care ine prezentarea i cei din audien. Clienii au n
general dou posibiliti: s trimit date ctre server, precum n cazul feedbackului, sau s interogheze
serverul pentru resurse, spre exemplu documentul PDF, slideul curent al prezentrii sau forma global,
agregat a feedbackului curent (Figura 4).
Serverul aplicaiei are rolul de a stoca resursele comune tuturor. Aceste resurse pot fi statice, cum
este cazul documentului PDF, sau pot fi dinamice, cum e cazul elementelor de feedback sau a slide-ului
curent al speakerului. n ambele cazuri, serverul are rolul de a centraliza datele i de a le pune la
dispoziia clienilor, prin adrese URL.
n cazul resurselor dinamince, serverul poate avea doar rolul de stocare, astfel nct orice client s
poat accesa resursa, sau poate avea i un rol de prelucrare, cum ar fi n cazul elementelor de feedback.
Aceste resurse sunt refcute la primirea oricrui feedback, astfel nct rspunsul la o cerere s conin o
form agregat a feedbackului.
Fig. 4 Arhitectura global a sistemului
14
3.2 Arhitectura clientului Android

Clientul Android implementeaz o arhitectur Model-View-Controller, care se caracterizeaz prin
separarea clar a funcionalitii celor trei module funcionale:
View interfaa grafic, alctuit din totalitatea butoanelor, ferestrelor i elementelor cu care
utilizatorul interacioneaz direct;
Controller totalitatea handlerelor care sunt declanate de utilizarea elementelor interfeei
grafice. n cadrul acestor handlere, sunt formulate interogri asincrone ctre model sau ctre
server pentru obinerea datelor.
Model modulul care are rolul de persistenta a datelor i care poate face cereri pe reea.
Interfaa este actualizat prin returnarea rspunsurilor de la server, asincron. Aceste rspunsuri pot
veni prin intermediul Modelului, dac cererea este fcut intermediar la Model, n cazul aplicaiei
Android acesta fiind implementat prin clasa ContentProvider. O alt variant a actualizrii vizuale este
prin ntoarcerea valorii direct prin execuia asincron a unei cereri ctre server, caz n care controllerul
este responsabil cu efectuarea cererilor ctre server.
O alt componenta de baz a modelului este baza de date, care este folosit pentru stocarea
informaiilor de feedback, sau a informaiilor proprii clientului, cum ar fi date legate de propriul
feedback. Aceste date se obin prin interogarea content providerului, care poate decide dac este
nevoie de o actualizare a datelor prin cereri ctre server.
Mai jos se afl o diagram UML care descrie principalele componente ale Modelului, clasa content
providerului i cele care deservesc bazei de date comunicrii cu serverul (Figura 5):
Fig. 5 Diagrama UML a arhitecturii MVC implementat prin ContentProvider
15
3.3 Arhitectura serverului web

Serverul central are dou componente, care ruleaz pe threaduri separate:
un server web, care rspunde la cereri HTTP pentru resurse;

un modul de grupare (eng. clustering) pe baza similaritilor semantice a ntrebrilor de
feedback. Acest modul comunic doar cu cealalt componenta a serverului.
n cazul serverului web, exist un thread principal cu un entry point din care se ruleaz serverul. n
acest thread se iniializeaz pachetele claselor resurs, care sunt ncrcate n background, comunicaia
facndu-se prin crearea de threaduri secundare. Responsabil cu crearea i managementul acestor
threaduri este containerul Grizzly.
Pentru stocarea datelor, am implementat o arhitectur de stocare ierarhic, format din containere
pentru diferitele tipuri de date (Figura 6).
Fig. 6 Diagrama UML a arhitecturii de stocare pe server
16
Resursele HTTP care sunt disponibile la interogarea serverului web sunt implementate n clase
specifice, care definesc metode programatice de interpretare a pachetelor HTTP i de alctuire a
rspunsurilor n cazul unor cereri (Figura 7).
n cazul resurselor dinamice, cum ar fi feedbackul de la utilizatori, serverul poate modifica resursa
prin executarea unor operaii interne, cum ar fi incrementarea numrului de feedbackuri pozitive asupra
unei selecii (mapate la un URL) sau reclusterizarea ntrebrilor pentru o selecie. n cazul al doilea,
serverul proceseaz clusterizarea semantic ntr-un thread 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 metodelor de prelucrare
17
4. Detalii de implementare
4.1 Accesarea resurselor pe baza URL i a protocolului HTTP
Aplicaia SmartPresentation se bazeaz pe o arhitectur client-server, avnd n centru un server cu
urmtoarele roluri:
stocheaz prezentarea pe care clienii cu dispozitive Android o descrc la deschiderea

aplicaiei;
menine evidena slideului curent al prezentrii la care se afl speakerul, oferind posibilitatea
clienilor de a-i sincroniza propria copie a prezentrii cu cea a speakerului, prin folosirea
modului "Go live!";
centralizeaz feedbackului primit de la clieni, stocnd toate tipurile de feedback;
rspunde la cereri de la clieni pentru feedbackul agregat;
ruleaz modulul de grupare pe baza semantic a ntrebrilor puse de cei din audien i
serializeaz structurile de date procesate de acest modul.
Pentru implementarea serverului am ales o soluie de web service, datorit existenei unor
soluii multiple de frameworkuri astfel de servicii i datorit simplitii accesrii resurselor, prin Uniform
Resource Locator.
4.1.1 Structura URLului

Containerul Grizzly folosit pentru stocarea resurselor http ofer posibilitatea setrii 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 staiei pe care ruleaz serverul, acest URL are forma
http://localhost:9998/, numele localhost fiind translatat local in ip-ul 127.0.0.1. n cazul clienilor,
acetia vor avea posibilitatea accesrii serverului prin ip-ul public al acestuia, care se seteaz indepenent
de server la rularea acestuia, n funcie de setrile ruterului wireless care asigur comunicaia.
API-ul Jersey permite crearea unor clase resurs http, pentru care se definete prin adnotarea @Path
poriunea de URL care se adug URL-ului de baza al serverului. O adnotare de tipul
@Path("/myresource") aplicat n cazul unei clase va face disponibil resursa http la adresa
http://localhost:9998/myresource, n cazul accesului de pe maina local care ruleaz serverul,
spre exemplu dintr-un browser rulat local.
Pentru aplicaia Smart Presentation, am definit mai mult tipuri de URL-uri, n funcie de resursele
accesate. Acestea sunt prezentate n continuare prin poriunea caracteristic resursei, care se adug
adresei de baz:
/presentation : aceast adresa este accesat la pornirea aplicaiei Smart Presentation pentru
/containers/slidecontainer/slide adresa la care este reinut slideul curent la care se afl
prezentatorul. Prin accesul la aceast resurs, utilizatorii pot sincroniza prezentarea cu cea a
speakerului. Speakerul actualizeaz aceast resursa automat la schimbarea slideului;
/containers/positivefeedback/[selection_id] aceasta este resursa la care se reine
numrul de feedbackuri pozitive care au fost acordate pe o selecie din prezentare, reprezentat
de un id, numr ntreg, al seleciei;
descrcarea prezentrii PDF stocate pe server;
18
/containers/ambiguousfeedback/[selection_id] aceasta este resursa la care se reine

numrul de feedbackuri de tip ambiguu care au fost acordate pe o selecie din prezentare;
/containers/prooffeedback/[selection_id] aceasta este resursa la care se reine
numrul de feedbackuri de tip proof/citation needed care au fost acordate pe o selecie din
prezentare;
/containers/questions/[selection_id] aceasta este resursa la care se gsete forma
agregat binar a ntrebrilor puse pe selecie, grupate n clustere (liste) de ntrebri similare din
punct de vede semantic;
Pe lng cele de mai sus, am mai definit patru resurse care sunt create i actualizate de server, la
primirea oricrui tip de feedback. Acestea sunt cele de feedback agregat pentru toat prezentarea,
necesare speakerului la finalul prezentrii, i au urmtoarele adrese URL:
/containers/positivefeedback/aggregate aceasta este resursa la care se reine o list de
mapari selecie feedback pozitiv;
/containers/ambiguousfeedback/aggregate aceasta este resursa la care se reine o list

de mapari selecie feedback de tip ambiguous;
/containers/prooffeedback/aggregate aceasta este resursa la care se reine o list de
mapari selecie feedback de tip proof needed;
/containers/questions/aggregate aceasta este resursa care stocheaz toate ntrebrile
puse pe documentul PDF, prin gruparea acestora n selecii, fiecare selecie fiind un binar de
tipul celei gsit la o resurs /containers/prooffeedback/[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. Urmtoarele tipuri au fost folosite pentru definirea coninutului:
text/plain: prin aceast setare am definit coninutul de tip clear text, n cazul mesajelor scurte,
care nu necesitau serializare pentru o optimizare a comunicrii. Astfel de mesaje sunt:
o schimbarea slideului de ctre speaker respectiv accesarea slideului curent de ctre client, n
ambele cazuri se transmite doar un numr al slideului;
o transmiterea unui ir fix de dou caractere, "+1" sau "-1", cu semnificaia adugrii su retragerii
unui feedback te ip fix, adic unul din tipurile positive feedback, ambiguous sau proof needed n
cazul unei selecii. Selecia este reprezentat n URL prin id-ul ei, un numr ntreg de tip long
care se obine ca hashCode al unui ir de caractere reprezentativ pentru elementele selectate;
o transmiterea ca rspuns de la server ctre client a unui ir de caractere reprezentnd numrul
total de feedbackuri din fiecare tip din cele trei descrise mai sus, pentru o anumit selecie.
Acest numr este reprezentativ pentru agregarea tipurilor fixe de feedback, frecvena indicnd
relevana acelui feedback;
application/pdf: aceast setare e folosit pentru codificarea binar a prezentrii pdf stocate pe
server. Prin interpretarea corect acestui mesaj http, clientul preia coninutul binar i l scrie ntr-un
fiier de tip pdf, stocat local pe dispozitivul Android.
application/x-protobuf: acesta este un mime-type definit local corespunztor mesajelor http
codificate binar folosind Google Protocol Buffers. Setarea coninutului binar al fiierului 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 octei, byte[]. n cazul serverului, sunt definite
clase care implementeaz interfeele MessageBodyWriter i MessageBodyReader din pachetul
19
jersey javax.ws.rs.ext, necesare pentru construirea unei clase Response pentru un mime type definit
de utilizator. Pentru deserializare am folosit i metoda parseFrom() aplicat unui obiect Google
Protocol Buffer, prin care se construiete instana din vectorul de octei al coninutului binar.
Setarea cmpului content-type i citirea acesuia se poate face foarte uor programatic, n funcie de
pachetele i clasele Java folosite pentru formarea i interpretarea mesajelor http. Astfel, pentru citirea
cmpului, pe server se poate inspecta cmpul 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("Content-Type") pe o instan de tip HttpResponse.
Pentru setarea acestui cmp, se poate instania o entitate care implementeaz interfaa HttpEntity cu
tipul coninutului corect sau se poate seta acel cmp din antet, printr-o metod setter.
4.2 Implementarea protocolului de comunicaie

Un protocol de comunicaie se definete ca un set de reguli cunoscute de ambele pri ale unei
comunicaii, prin care att receptorul, ct i emitorul pot interpreta corect mesajele transmise pentru
ndeplinirea anumitor cerine. Un protocol definete de asemenea i ordinea mesajelor schimbate,
anumite operaii necesitnd schimbul unui numr consecutiv de mesaje specifice, ntr-o ordine
particular. Un protocol bazat pe HTTP, aa cum este cazul la aplicaia Smart presentation, este format
din dou componente:
URL att clienii care acceseaz resursa ct i serverul pe care este stocat aceasta au aceeai
concepie asupra resursei aflate la acea adresa. Astfel, clientul tie ce adresa trebuie accesat
pentru obinerea resursei dorite i are certitudinea corectitudinii mesajului primit ca rspuns.
Aceast certitudine permite interpretarea corect a rspunsului. La fel, serverul asigur stocarea
resursei cerute la respectiva adres, avnd acelai set de mapri resurs-URL ca cel cunoscut de
client.
2. Coninutul mesajelor n cadrul unei resurse aflate la un URL, se ncapsuleaz un coninut propriuzis al mesajului care conine informaia dorit. Aceast informaie poate reprezenta date obinute
prin prelucrare pe server sau pur i simplu stocate pe acesta. n funcie de coninutul acestor
mesaje, un client poate decide transmiterea unor noi cereri sau declanarea unor evenimente
locale.
1.
4.2.1 Componenta mesajelor i logica protocolului

n cadrul aplicaiei Smart Presentation, protocolul de comunicaie este definit pe fiecare arie de
funcionalitate separat. Astfel, serverul primete anumite cereri la care este pregtit s rspund cu
mesajele necesare. n continuare, m voi referi la adresa serverului cu [adresa_server], datorit
caracterului variabil al acesteia, n funcie de adresa ip la care poate fi accesat. De asemenea, m voi
referi la un URL cu termenul "adresa".
Mesajele schimbate ntre client i server sunt urmtoarele:
La iniializarea aplicaiei, fiecare client trimite o cerere http de tip GET la adresa
[adresa_server]/presentation, cu coninut gol. Serverul trimite ca rspuns un mesaj http cu
headerul Content-type setat "application/pdf" i coninutul binar, n format pdf, reprezentnd
aplicaia stocat pe server.
La schimbarea slide-ului de ctre speaker, se trimite un mesaj de tip PUT ctre server, la adresa
[adresa_server]/containers/slidecontainer/slide, avnd un coninut cu Content-type "text/plain"
care este format dintr-un numr cu slide-ul curent. Clientul trimite cereri de tip GET la aceeai
20
adres, primind ca rspuns tot un mesaj http "text/plain" cu numrul slide-ului actual. Acest
mesaj este trimis la un interval mic de timp, ncontinuu, atunci cnd 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 coninutul "text/plain" reprezentat dintr-un ir de
caractere cu forma "+1" sau "-1", cu semnificaia adugrii sau retragerii acelui tip de feedback.
Adresele de acces a acestor tipuri de feedback pentru o selecie sunt:
o
[adresa_server]/containers/positivefeedback/[id_selecie]
pentru
pentru
accesarea feedbackului de tip positive feedback

o
o
[adresa_server]/containers/ambiguousfeedback/[id_selecie]
accesarea feedbackului de tip ambiguu
[adresa_server]/containers/prooffeedback/[id_selecie] - pentru accesarea
feedbackului de tip proof needed.

La formularea unei cereri PUT la o astfel de resurs, serverul returneaz acelai rspuns ca n
cazul unei cereri GET, un mesaj de tip "text/plain" reprezentnd numrul total al feedbackurilor
de acel tip primite la acea adresa, adic pe o anumit selecie. Id-ul selecie este un ir de cifre
care formeaz un numr ntreg reprezentativ doar pentru o selecie.
Pentru mesajele ce conin feedback de tip ntrebri pentru o anumit selecie, am folosit
codificarea n formatul binar Google Protocol Buffers, datorit simplitii i versatilitii sale n
definirea mesajelor, dar i datorit unei eficientizri evidente a utilizrii benzii de transfer. Ca i
n cazul celorlalte tipuri de feedback, adresa la care este inut feedbackul agregat pe un id al
unei selecii este de forma [adresa_server]/containers/questions/[id_selecie]. Diferena apare
la tipul coninutului unui mesaj i la logica rspunsului 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 cmpul contenttype setat pe "application/x-protobuf". Coninutul acestui mesaj este un mesaj de tip protocol
buffers, avnd la baza o ntrebare adresat pe o selecie. La recepia acestei cereri, serverul
reface resursa pe care o are reinut la acea adres, prin regrupare. Aceast resurs conine o
form agregat a feedbackului, reinut n format binar Google Protocol Buffers. Coninutul
acesui mesaj este format dintr-o list de clustere, un cluster fiind o list de ntrebri cu sens
asemntor din punct de vedere semantic. Acest mesaj este cel primit ca rspuns de un client
sau de ctre speaker la o cerere de tip GET pe adresa corespunztoare unei selecii.
De asemenea, am folosit Google Protocol Buffers pentru agregarea tuturor tipurilor de feedback
pentru ntregul document PDF, pentru ca acestea s poate fi accesate de speaker la final. Aceste
resurse sunt gsite la adresele detaliate la capitolul anterior, de tipul:
[adresa_server]/containers/[feedback_container]/aggregate
Coninutul unui mesaj de tip Google Protocol Buffers poate varia, n funcie de tipul mesajului.
Pentru a determina tipul mesajului nainte de deserializare, am folosit un mecanism de
ncapsulare care va fi descris n continuare.
21
4.2.2 Serializarea datelor folosind Google Protocol Buffers

Mesajele de codificare a ntrebrilor de feedback sunt serializate folosind mecanismul Google
protocol Buffers, detaliat la capitolul Tehnologii folosite. n acest scop, am definit mai multe tipuri de
mesaje ntr-o ordine ierarhic, n funcie de gradul de ncapsulare.
Astfel, pentru o simpl ntrebare, trimis n cadrul unui mesaj sub forma unei cereri PUT de la client
ctre server la o adres specific unei selecii, se folosete urmtorul format de mesaj:
message FeedbackQuestion
{
required int32 retract = 1;
required string selectionString = 2;
required string question = 3;
}
Pentru un cluster de ntrebri, reprezentat printr-o list de ntrebri apropiate semantic, din care se
poate alege oricare ca centroid (ntrebare reprezentativ), am definit urmtorul mesaj:
message QuestionCluster
{
repeated FeedbackQuestion questions = 2;
}
Pentru reprezentarea agregat pentru o selecie a tuturor clusterelor obinute n urma aplicrii
algoritmului de grupare pentru toate ntrebrile adresate, am definit urmtorul mesaj:
message SelectionClusters
{
required int64 selectionId = 1;
repeated QuestionCluster clusters = 3;
}
n plus fa de aceste mesaje, am implementat mesaje de ncapsulare pentru tipurile de feedback fix
sau ntrebri, pentru ncapsularea mesajelor de agregare transmise speakerului la finalizarea prezentrii.
message AggregateQuestionsFeedback
{
repeated SelectionClusters SelectionClusters = 1;
}
message FixedFeedback
{
required string feedbackType = 2;
required int32 numberOf = 3;
}
message AggregateFixedFeedback
{
repeated FixedFeedback feedbacks = 1;
}
n cazul transmiterii unui mesaj Google Protocol Buffers, ar trebui cunoscut tipul mesajului nainte
de deserializare, pentru folosirea claselor corecte generate de executabilul protoc. O tehnic potrivit
22
pentru acest scop este ncapsularea unui mesaj din cele trei tipuri de mai sus ntr-un mesaj container,
care s conin un cmp cu semnificaia unui flag care indic tipul mesajului ncapsulat, i un alt cmp cu
mesajul propriu-zis. Formatul mesajului container arta astfel:
message MessageContainer
{
enum Type
{
SINGLE = 1;
CLUSTER = 2;
SELECTION = 3;
AGGREGATE_QUESTIONS = 4;
AGGREGATE_FIXED = 5;
}
required Type type = 1;
optional
optional
optional
optional
optional
FeedbackQuestion feedbackQuestion = 2;
QuestionCluster questionCluster = 3;
SelectionClusters selectionClusters = 4;
AggregateQuestionsFeedback aggregateQuestions = 5;
AggregateFixedFeedback aggregateFixed = 6;
Astfel, cmpul type evideniaz care din cele trei mesaje opionale este cel coninut de mesajul
container, permind o deserializare corect.
Pentru definirea acestor mesaje, am folosit urmtoarele cuvinte cheie ale limbajului Google Protocol
Buffers, cu explicaiile:
Required indic necesitatea prezenei acelui cmp n mesaj;

Opional indic lipsa necesitii prezenei acelui cmp n mesaj;
Repeated indic un cmp de tip lista al tipului specificat.
De asemenea, se poate observa i un tag care este asociat fiecrui cmp. Acest tag este utilizat la
interpretarea mesajului la deserializare, indicnd ordinea n care se gsesc 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 obinerea mesajelor binare, este necesar obinerea unor clase Java din
formatele definite n fiierele .proto. Generarea acestor clase face printr-un executabil protoc.exe. n
cazul utilizrii mediului de dezvoltare Eclipse, exist un plugin care determin generarea automat a
claselor la crearea unui mesaj .proto n folderul resources al unui proiect.
Clasele generate pun la dispoziie mai multe subclase i metode pentru serializare i deserializare.
Pentru deserializare, cea mai facil tehnic este apelarea metodei parseFrom() care primete c
parametru un array de octei (byte[]), spre exemplu coninutul unui mesaj HTTP. Pentru serializare,
fiecare clasa conine o subclasa builder, care se obine astfel, pentru un exemplu din mesajele de mai
sus:
SelectionClusters.Builder clusterBuilder = SelectionClusters.newBuilder()
Aceast instan este folosit apoi pentru adugarea celorlalte cmpuri, prin metode de tip setter;
23
Exp: clusterBuilder.setSelectionId(id)
Pentru un cmp de tip repeated, se folosete metoda add().
Dup setarea tututor cmpurilor, mesajul se obine prin apelul metodei build asupra instanei builder.
Exp: SelectionClusters clusters = clusterBuilder.build()
SelectionClusters.Builder scBuilder = SelectionClusters.newBuilder();
scBuilder.setSelectionId(new Long(MemoryStore.currentItem));
for (Set<Question> cluster : clusterTree)
{
QuestionCluster.Builder qCluster = QuestionCluster.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 aplicaiei Smart Presentation include aplicaia de client, cea de Android i serverul
central. Implementarea clientului cuprinde cele trei module funcionale, interfaa, modulul de
manipulare a prezentrii PDF i partea de comunicare cu serverul.
Mediul de dezvoltare Android este diferit de cel desktop. O diferen de baza ntre aplicaiile pentru
telefoane mobile i aplicaiile desktop este reprezentat de modul n care trateaz persistena datelor.
Cel mai des, aplicaiile desktop folosesc o implementare a patternului MVC centrat pe documente
aplicaiile deschid un document, l citesc n memorie i l transpun n obiecte care persist n memorie.
Aceste programe definesc vizualizri n care pot fi manipulate acele obiecte ale modelului de date, prin
procesarea inputului de la controller. Spre deosebire de acestea, aplicaiile Android combin modelele
de date i interfaa utilizatorului ntr-un mod diferit. Aplicaiile ruleaz pe un dispozitiv mobil cu
memorie limitat, care poate rmne fr baterie ntr-un moment imprevizibil. ntregul concept de
document este absent n Android. Utilizatorul ntotdeauna ar trebui s aib datele la ndemn i s fie
ncreztor c acestea sunt n siguran. Pentru a stoca datele aplicaiei incremental, obiect cu obiect, i
ca acestea s fie ntotdeauna la dispoziie, Android ofer un suport centrat pe baze de date, prin clasele
cuprinse n pachetul android.database.sqlite [10].
O alt diferen ntre aplicaiile pentru telefoane mobile i aplicaiile desktop este accentul care
cade n cazul celor mobile n primul rnd pe o utilizare fluid a aplicaiei, astfel nct interfaa grafic s
nu fie blocat niciodat. Din acest motiv, sdk-ul Android ofer multiple pachete i clase care permit
24
rularea paralel a mai multor taskuri, cu scopul de a nu ncrca suplimentar threadul GUI. Spre exemplu,
ultimele versiuni de Android sdk interzic rularea de operaii de networking, cum sunt i cele http.
ncercarea de rulare a unei astfel de cereri n threadul aplicaiei arunc o excepie [2].
Cea mai des utilizat tehnica n devoltarea unor taskuri care ruleaz paralel este comunicarea
asincron cu threadul respectiv, astfel nct elementele vizuale, de interfa din threadul principal s fie
ntiinate de finalizarea taskului paralel. Pentru implementarea 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 finalizarea rulrii. Cealalt este cea de a realiza un
managedQuery() ctre ContentProviderul aplicaiei, un serviciu care are rolul Modelului din arhitectura
Model-View-Controller i care are acces direct la baz de date a aplicaiei. Ambele variante sunt
detaliate n continuare.
4.3.1 Implementarea design patternului MVC

Aa cum am descris i la capitolul de Arhitectur, devoltarea aplicaiei Android implic
implementarea unui pattern Model-View-Controller.
Astfel, se separ cele trei module funcionale, interfaa grafic, modelul i controllerul, astfel nct
fiecare component este dependent de celelalte. Interfaa grafic rspunde la comenzi din partea
utlizatorului, controllerul fiind responsabil cu tratarea evenimentelor i cu actualizarea datelor din
interfa. Modelul este cel care asigur persistena datelor din care att controllerul, ct i view-ul i
actualizeaz coninutul.
i n cadrul aplicaiei Smart Presentation, exist o separare clar a componentelor, astfel nct
acestea pot fi ncadrate ntr-una din cele trei categorii: view, model i controller. Astfel, view-ul este
constituit din totalitatea elementelor grafice ale aplicaiei i controllerul cuprinde totalitatea handlerelor
de actualizare a interfeei. Modelul este alctuit din taskurile asincrone care comunic direct cu serverul
web i dintr-o component special, Content provider, care asigur persistena datelor ntr-o baz de
date Sqlite i care poate fi interogat.
4.3.2 Persistena datelor n Sqlite i accesarea resurselor interne prin ContentProvider

Instanele Content providers reprezint o component a aplicaiei locale i sunt analoage
conceptului de serviciu web RESTful. API-ul content providerului permite aplicaiilor client s
interogheze sistemul de operare pentru date relevante utiliznd un URI, similar modului n care un
browser cere informaii pe internet. Adresa URI a content providerului ncepe ntotdeauna cu
content://, la care se adug c n cazul unui web service componenta specific resursei.
Dac o aplicaie implementeaz un provider propriu, este necesar ca acesta s fie nregistrat n
fiierul de configurare al aplicaiei, AndroidManifest.xml, astfel:
<provider android:name=".provider.SmartpContentProvider"
android:authorities="smartp.client.provider.SmartpContentProvider" />
Utilizarea clasic a unui content provider se face prin stocarea datelor ntr-o baz de date
SqLiteDatabase, asupra crora acioneaz metodele implementate 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
25
Query analoag metodei GET, returneaz nregistrri din baz de date pe baza unor cereri
SQL, ntr-o colecie specializat numit Cursor
Update analoag metodei update. nlocuiete cererile din baz de date cu unele mai noi
Delete analoag cererii de tip DELETE
Ca i n cazul unui server web, un content provider mapeaz dinamic adrese URL la resursele aflate
n baza de date. Aceast mapare este responsabilitatea programatorului, care la apelul metodei Query a
content providerului face match pe URIul folosit n query pentru a ti ce interogare se realizeaz pe baza
de date. Interogarea ntoarce o instan a clasei Cursor, care ofer pe lng informaia propriu-zis
mecanisme de declanare a evenimentelor atunci cnd datele aflate la adresa respectiv sufer
modificri. Pentru a activa aceste mecanisme, se apeleaz metoda [2]:
queryCursor.setNotificationUri(getContext().getContentResolver(),uri);
la crearea cursorului, adic n metoda Query a content providerului, i metoda :

getContext().getContentResolver().notifyChange(uri, null);
la modificarea coninutului, adic n interiorul unei metode insert, delete sau update.
n cazul ambelor metode, se folosete metoda getContext().getContentResolver(), care
ntoarce instana unui ContentResolver, clasa care realizeaz interfaa dintre aplicaia care ruleaz i
content providerul nregistrat n fiierul de configurare. Att Context, ct i ContentResolver, sunt clase
singleton, ale cror instane sunt create la iniializarea aplicaiei Android.
Clasa Content Provider a aplicaiei Smart Presentation are scopul de stocare n baz de date a unor
date care sunt preluate de pe server. Cele mai importante astfel de date sunt documentul PDF, care este
preluat asincron la deschiderea aplicaiei, dup care aceasta este notificat pentru a-i reface interfaa,
i ntrebrile de feedback sub forma agregat, care sunt reinute asemntor unui mecanism de
cacheing n baz de date, pentru a rri cererile la server. n ambele cazuri, din clasa activitate se
folosete un query de tip managedQuery, care primete ca parametru adresa de interogare a content
providerului i returneaz un cursor cu datele din baz de date.
Clasa managedQuery are posibilitatea de mapare a unei instane a clasei ContentObserver, care
implementeaz metoda onChange(), aceasta fiind metoda handler apelat atunci cnd un notify este
executat pe URLul cursorului n cadul content providerului, cel mai uzual n cazul unui insert, delete sau
update (Figura 8).
Fig 8. Componentele MVC de baz ale unei aplicaii Android

1
nd
Zigurd Mednieks, Laird Dornin & G. Blake Mieke: Programming in Android 2 Edition (O'Reilly, 2012), 80
26
Metoda query() a content providerului este responsabil cu returnarea rezultatelor din baz de
date. Acest matching se face folosind o clas ajuttoare UriMatcher.
n cazul ntrebrilor feedback reinute n baza de date, am decis s implementez o modalitate de
cacheing, astfel nct n urma unei extrageri a intrrii din baza de date corespunztoare feedbackului
unei selecii, s se verifice i timestampul ultimei actualizri, astfel nct o nou cerere ctre serverul
web s se fac doar atunci cnd resursele stocate sunt considerate prea vechi.
Extragerea cii de salvare a documentului PDF din baza de date se face doar o dat, la nceput, n
urma unei cereri efectuate la serverul web care declaneaz un notify la insertul n baza de date.
4.3.3 Accesarea resurselor de pe web server prin mesaje asincrone

Clasa AsyncTask
Accesarea resurselor de pe web server se face n dou situaii, 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 urmtoarele:
Params tipul parametrilor trimii taskului la execuie;

Progress tipul unitilor de progress publicate n timpul efecturii operaiilor n background;
Result tipul rezultatului obinut n urma rulrii operaiilor de background;
Aceste tipuri sunt setate atunci cnd se extinde clasa AsynTask, prin setarea celor trei parametri
generici ai clasei. n cazul n care unul din cele trei 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, String)
care se traduce astfel: metoda de execuie primete ca parametri instante ale clasei URL, unitile de
progress nu sunt folosite, iar rezultatul este ntors sub forma unui String.
Cnd un task asincron este executat acesta trece prin patru pai1:
1.
onPreExecute(), invocat de threadul UI imediat dup ce taskul este executat. Acest pas este utilizat
n mod normal pentru setarea taskului, spre exemplu pentru afiarea unui progress bar n interfaa
utilizatorului.
2. doInBackground(Params ...) invocat de threadul de background imediat ce onPreExecute()
termin de executat. Acest pas este folosit pentru efectuarea unor aciuni computaionale de
background care pot dura un timp mai ndelungat. Rezultatul operaiilor efectuate aici trebuie s fie
ntors n aceast metod i va fi pasat urmtorului pas. Acest pas poate declana i metoda
publishProgress(Progress...) pentru a publica una sau mai multe uniti de progres. 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 executrii este nedefinit. Aceast metod
este folosit pentru afiarea oricrei forme de progres n interfaa utilizatorului n timp ce operaiile
1
Documentatia Android, 20.06.2012, <developer.android.com/reference/android/os/AsyncTask.html>
27
de background sunt n execuie. Spre exemplu, poate fi folosit pentru animarea unui progress bar
sau pentru a afia mesaje de log.
4. onPostExecute(Result), invocat de UI thread dup ce operaiile de background se termin.
Parametrul Result este cel preluat de metoda doInBackground().
Fig. 9 Fluxul de date AsyncTask
O alt facilitate oferit de clasa AsynTask este posibilitatea opririi acesteia din threadul apelant, 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 executrii taskului se poate verifica periodic valoarea ntoars de onCancelled().
Din punct de vedere al concurenei threadurilor, AsyncTask asigur c toate apelurile callback sunt
sincronizate n aa fel nct urmtoarele operaii sunt sigure:
setarea
membrilor
constructor
sau
onPreExecute()
referirea
lor
referirea
lor
doInBackground(Params...)
setarea
cmpurilor
membri
n doInBackgroud(Params...)
onProgressUpdate(Progress...) i n onPostExecute(Result)
Aplicaia Smart Presentation folosete numeroase clase particulare care implementeaz aceast
clas abstract. n general, toate taskurile care presupun comunicare pe reea, n acest caz efectuarea
cererilor ctre serverul web i ntoarcerea asincron a rspunsurilor, sunt mapate la o astfel de clas.
Urmtoarele sunt principalele astfel de clase folosite n cadrul aplicaiei:
GetSlideAsyncTask este clasa responsabil cu sincronizarea slideului curent cu cel al
speakerului, a crei executare este lansat atunci cnd se intr n modul Go live!. Modul de
funcionare a acesteia este urmtorul: funcia doInBackgroud(String... params) intr ntrun ciclu n care, dac nu a s-a apelat nc metoda cancel n UI Thread, se verific ultima
actualizare a slideului. Dac timpul scurs de la ultima actualizare este mai mare de un anumit
threshold mic (2-3 secunde), se execut o cerere asincron ctre serverul web pentru
actualizarea numrului slideului.
Verificarea dac taskul continu s ruleze se face prin apelul metodei isCancelled, care ntoarce
true sau false. Dup fiecare cerere GET efectuat, rspunsul este folosit pentru actualizarea
1
nd
Zigurd Mednieks, Laird Dornin & G. Blake Mieke: Programming in Android 2 Edition (O'Reilly, 2012), 110
28
interfeei grafice, n cazul nostru schimbarea slideului. Aceeai metod de actualizare a slideului
este apelat i n final n metoda onPostExecute(String result).
Metoda doInBackground(String... params) primete parametru de tip String, reprezentat
de URLul la care se face cererea i returneaz un rspuns de tip String, numrul 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 aplicaie doar de speaker, i este apelat atunci cnd
acesta schimb slide-ul. n cadrul metodei de background, se seteaz coninutul de tip
"text/plain" al unei entiti StringEntity, reprezentnd slideul curent, i se execut o metod de
tip HttpPut.
Clasa PutFixedFeedback este folosit pentru trimiterea unuia din cele trei tipuri 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 semnificaia
adugrii acelui feedback sau retragerea unui feedback fcut anterior. Acest ir de dou
caractere este ncapsulat n coninutul unei StringEntity i trimis printr-un http put ctre
server, care returneaz ca rspuns numrul agregat al acelui tip de feedback pus pe selecia
respectiv. Afiarea rspunsului n aplicaie se face la execuia onPostExecute()
Clasa PutFeedbackQuestionTask realizeaz serializarea unei ntrebri de tip String i trimiterea

acesteia ctre 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, folosete coninut de tip binar:
29
ByteArrayEntity entity = new ByteArrayEntity(messsage.toByteArray());

entity.setContentType(smartp.client.AlternateMediaType.APPLICATION_XPROTOBUF);
Clasa UriRequestTask
Comunicarea cu serverul web se face nu doar din Activity, ci i prin intermediul Content Provider. n
acest scop, am dezvoltat o clas care implementeaz interfaa Runnable, rulnd ntr-un thread separat.
La fel c n cazul AsyncTask, n cadrul metodei run() se execut operaiile de background. Pentru
interpretarea mesajului, am implementat o clas handler, MessageHandler, care parseaza mesajul http
pentru a decide urmtorul pas. n general, datele cuprinse n rspunsul de la server sunt introduse n
baza de date SQLite, astfel nct la o modificare a datelor, cursorul pe care s-a fcut o interogare pe baz
de date s notifice elementele apelante din Activity.
Prima situaie n care se ntmpl acest scenariu este la pornirea aplicaiei, cnd se execut un
managedQuery la contentprovider pentru descrcarea prezentrii PDF de la server.
public void query()
{
Uri queryUri = SmartPresentationMessage.Pdf.CONTENT_UR;
Cursor myCursor = managedQuery(queryUri, null, null, null, null);
myCursor.registerContentObserver(new ContentObserver(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 ctre
ContentProvider, i are forma content://" + AUTHORITY + "/" + Pdf.PATH, unde AUTHORITY este calea
complet a clasei Content Provider i Pdf.PATH este o constanta care definete numele resursei.
Aceast interogare declaneaz cererea ctre web server. La descrcarea prezentrii PDF, aceasta este
scris n memoria intern a dispozitivului i adresa intern, cea specific sistemul de fiiere Android este
salvat n baza de date. n funcia care realizeaz insert n baz de date, se apeleaz metoda de
notificare notifyChange pe URLul descris mai sus, astfel nct cursorul creat de metoda managedQuery
30
s fie atenionat de terminarea cererii. n urma notificrii, se execut metoda onChange, n care se
ncarc prezentarea PDF n interfaa grafic.
Aceeai succesiune de aciuni ca i n cazul de mai sus se efectueaz n cazul interogrii
ContentProviderului pentru obinerea feedbackului agregat. Aceste date sunt cerute prin intermediul
instanei ContentProvider deoarece am dorit salvarea n baz de date a feedbackului, astfel nct s fie
implementat un mecansim de cacheing care s permit aplicaiei s obin feedbackul direct din baza de
date dac ultimul moment al actualizrii sale a fost foarte recent. Acest feedback agregat este reinut n
baz de date SqlLite n tabela QUESTIONS_TABLE, n cazul ntrebrilor, i n FIXED_FEEDBACK, pentru
celelalte tipuri de feedback. Interogarile pe tabele se fac dup ID reprezentnd selecia, i care conine
un blob cu binarul serializat Google Protocol Buffers i un timestamp al ultimei actualizri.
4.4 Implementarea serverului web

Serverul central al aplicaiei 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 implementarea claselor resursa i a metodelor specifice
HTTP. Pe lng componenta de resurse, serverul mai are i scopul de grupare a ntrebrilor feedback de
la clieni, pentru a permite utilizatorilor o vizualizare agregat, mai compact, a ntrebrilor, n funcie
de similaritatea semantic. Astfel, partea mea de implementare a cuprins doi pai:
1. dezvoltarea serverului web i a claselor resurs i maparea acestora la adrese URL
2. integrarea modulului de clusterizare i sincronizarea acestuia cu resursa HTTP corespunztoare
feedbackului format din ntrebri
4.4.1 Iniializarea serverului i a containerului Grizzly

Containerul Jersey ofer o interfa programatic de iniializare, spre deosebire de procedura
standard de nregistrare a resurselor web specifice serverelor web Tomcat sau Glassfish, adic prin
introducerea claselor ntr-un fiier de configurare web.xml.
Astfel, serverul poate fi pornit dintr-o metod Main, permind i operaii anexe, cum ar fi n cazul
aplicaiei Smart Presentation pornirea unui thread secundar al modului de clusterizare a ntrebrilor
feedback.
Iniializarea serverului web presupune urmtorii pai [5]:
Setarea unei adrese de baz a serverului web, spre exemplu http://localhost:9988/. Orice
resursa stocat pe server are adresa format din concatenarea acestei adrese unei poriuni
specifice resursei;
nregistrarea pachetelor unde se afl clasele resursa;
Crearea propriu-zis a serverului web, prin apelul metodei:
GrizzlyWebContainerFactory.create(BASE_URI, initParams).
31
4.4.2 Clasele resurs i metodele HTTP definite pe server

Serverul web pune la dispoziie toate resursele de care clientul are nevoie pentru ndeplinirea
funcionalitilor aplicaiei Smart Presentation. Aceste resurse pot fi acccesate i modificate prin cereri
HTTP de tip GET, PUT, POST sau DELETE. Clasele se mapeaz la adrese URL prin adnotri specfice
frameworkului Jersey, care definete de asemenea i adnotri ale metodelor clasei pentru metodele
HTTP la care acestea se mapeaza sau adnotri referitoare la tipul de content al corpului http.
Resursele expuse de serverul web sunt grupate n pachete care sunt nregistrate la iniializarea
containerului Grizzly, pentru ca ele s poate fi accesate de class loader. Resursele specifice aplicaiei
Smart Presentation sunt:
Class PDFPresentation este clasa care pune la dispoziie prezentarea PDF stocat pe server.
Aceasta este adnotat cu @Path("presentation"), indicnd adresa la care poate fi accesat.
Clasa implementeaz doar o metod GET, adnotat cu @Produces("application/pdf"), indicnd
tipul coninutului pachetului http. n interiorul metodei, este citit ntr-un obiect File fiierul PDF
aflat n directorul rdcina al serverului . Acest obiect este ncapsulat n rspunsul http prin
metoda Response.ok((Object) file).
Clasa ContainersResource adonatat cu @Path("containers"), este clasa care ncapsuleaz
totalitatea containerelor, ntorcnd un xml cu containerele 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
rspuns doar dac exist acel container.
Clasa ItemResource - nu are adnotare de Path, numele su este irul de caractere de dup
/containers/[container_name] i este instaniat din metoda geItemResource a clasei
ContainerResource. Are definite metode GET i PUT, pentru extragerea resursei, respectiv
pentru crearea/actualizarea acesteia.
Ultimele trei clase descrise fac parte dintr-o arhitectur exemplificat n aplicaia Storage Server
definit ca exemplu al utilizrii Jersey1. Acest design reprezint o alternativ foarte generic de stocat
resurse, ntruct ierarhia adresei permite separarea logic a acestora. De asemenea, resursele sunt
reinute n format binar, din care se poate obine orice alt tip de date, n funcie de resursa stocat.
Din punct de vedere programatic, arhitectura Storage Server permite stocarea unor date care pot fi
accesate n comun de resurse. Clasa care asigur stocarea se numete MemoryStore, i membrii clasei
au atributul static, pentru ca acetia s fie instantiati la ncrcarea clasei i nu la o instantiere a sa.
Excepie fac structurile de date de tip HashMap care realizeaz maparile containerelor i a numelor
resurselor item la containere:
private Map<String, Container> containerMap = new HashMap<String, Container>();
private Map<String, Map<String, byte[]>> dataMap = new HashMap<String,
Map<String, byte[]>>();
Acestea sunt membri ale instanei singleton MemoryStore, care conine 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 excepia documentului PDF i a clasei aferente, celelalte resurse sunt accesibile
prin acest format al URLului:
Exemple Jersey, Storage-Service, 20.06.2012,

<http://docs.oracle.com/cd/E19776-01/820-4867/ggrby/index.html>
32
[adresa_server/containers/[nume_container]/[nume_item]
Containerele sunt: slidecontainer, positivefeedback, ambiguousfeedback, prooffeedback i
questions, cu semnificaiile prezentate anterior. Dei pachetele http ntoarse ca rspuns pot avea
formate diferite (plain/text sau Google protocol buffers), toate resursele sunt reinute n forma byte[],
pentru a beneficia de genericitatea designului. Serializarea i deserializarea datelor din binar se face la
nivelul clasei ItemResource, n funcie de numele containerului.
4.4.3 Serializarea i deserializarea datelor

ntruct datele sunt reinute n binar sub forma unui vector de octei n sistemul de stocare a
serverului, este necesar deserializarea acestora atunci cnd se dorete interpretarea sau prelucrarea
datelor, respectiv serializarea lor atunci cnd se introduc sau reintroduc datele n structurile de date de
stocare.
n cazul resurselor de tip "text/plain", deserializarea se face uor datorit constructorului
String(byte[]). Serializarea este simetric, prin metoda toByteArray() a clasei String.
n cazul ntrebrilor de feedback i a celorlalte tipuri de feedback agregate, acestea sunt serializate i
deserializate folosind metodele clasei Google Protocol Buffers generate de executabilul protoc la
crearea mesajelor .proto. Deoarece la introducerea sau retragerea oricrei ntrebri este necesar o
regruparesemantic a ntrebrilor, la efectuarea unei cereri PUT sau DELETE sunt necesari pai att de
serializare, ct i deserializare, dei n mod normal continiutul binar transmis n mesajul HTTP ar putea fi
stocat direct. Acest lucru nu e posibil i din motivul c formatul mesajului primit de la client printr-o
metod PUT este diferit de cel reinut in binar pe server i transmis clientului la o cerere GET.
Serializarea mesajelor binare a fost detaliat la capitolul referitor la mesajele transmise ntre clieni
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 ntrebrilor i sincronizarea cu acesta

Pe lng funcionalitatea de serviciu web, care rspunde la cereri http, serverul aplicaiei are i rolul
de a rula gruparea ntrebrilor de feedback de fiecare dat cnd o nou ntrebare este pus de o
persoan de audien, deci o cerere PUT este efectuat pentru o ntrebare pe o anumit selecie. Fluxul
logic n acest caz este urmtorul:
1. utilizatorul formuleaz o ntrebare pe dispozitivul Android, care este ncapsulat ntr-un mesaj
FeedbackQuestion (mesaj Google Protocol Buffers) i trimisa ntr-o cerere PUT la adresa seleciei
pentru care este adresat ntrebarea
2. serverul web preia cererea, observ tipul cererii i este apelat o metod a modului de clusterizare
3. modulul de clusterizare preia ntrebarea ca input, citete binarul deja existent stocat n server (ntr-o
form deja agregat, n formatul SelectionsClusters), l deserializeaza pentru a obine ntrebrile
i realizeaz din nou clusterizarea, prelund i ntrebarea de de input.
4. modulul de cluster serializeaz napoi n formatul SelectionsClusters cu noile clustere de ntrebri,
apoi este refcut mesajul container i binarul obinut este salvat n MemoryStorage.
Modulul de clusterizare a fost devoltat separat, astfel nct eu l-am integrat ntr-un thread separat,
care este pornit odat cu serverul.
33
Problemele evidente apar la sincronizarea ntre threadurile create n background pentru cererile
web i threadul modulului de clustering. Pentru a rezolva aceast situaie, am folosit un obiect simplu ca
lock, acesta fiind vizibil tuturor claselor serverului ca membru al clasei MemoryStore. De asemenea,
toate datele modificate la execuia clusterizarii sunt membri ai clasei MemoryStore. Toate aceste resurse
accesate n comun sunt modificate ntr-o zon sincronizat dup MemoryStore.threadlLock [11].
Astfel,
threadul
de
clusterizare
se
blocheaz
ciclul
de
rulare
la
apelul
MemoryStore.threadlLock.wait(), urmnd ca acesa s fie atenionat cu notify din threadul serverului
web atunci cnd o nou ntrebare este adresat. n threadul cererii http, atunci cnd sosete o nou
ntrebare, se intr ntr-o zon sincronizat n care nti se construiete ntreg setul de ntrebri,
deserializndu-se binarul deja reinut la care se adug noua ntrebare, apoi se apeleaz notify pentru
a reporni threadul clusterer. Acesta preia setul de ntrebri din MemoryStore i reface clusterizarea, apoi
serializeaz noile clustere ntr-un nou mesaj SelectionClusters, care este suprascris peste binarul
stocat la URL-ul seleciei. La sfrit, acest thread iese din synchronized i repet operaia, blocndu-se n
wait.
public void run()
{
QuestionHierClusterer clusterer = new QuestionHierClusterer();
clusterer.init();
while (true)
{
clusterQuestions(clusterer);
}
}
public void clusterQuestions(, QuestionHierClusterer clusterer)
{
synchronized (MemoryStore.threadLock)
{
try {
MemoryStore.threadLock.wait();
Set<InputQuestion> input =
clusterer.setInputQuestionsFromArray(MemoryStore.feedbackQuestions);
Set<Set<Question>> tree = clusterer.cluster(input);
storeClusters(clusterer, tree);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
Exemplu cod de rulare al threadului de clustering
34
4.5 Interfaa de utilizare a clienilor Android

Interfaa aplicaiei ofer clientului posibilitatea utilizrii ntregii funcionaliti a modului de
comunicaie client-server al aplicaiei Smart Presentation. 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 ntrebri. De asemenea, clientul are posibilitatea sincronizrii prezentrii cu cea a
speakerului, prin apsarea butonului "Go live!". Odat intrat n acest mod, clientul poate iei prin
apsarea oricrui buton care oblig pstrarea slideului curent, cum ar fi intenia de selecie a unor
elemente din prezentare sau acordarea unui feedback.
Speakerul acceseaz serverul n mod indirect, prin schimbarea slideului, sau n mod direct, la sfrit,
cnd dorete vizualizarea ntregului feedback. Scenariile de utilizare sunt detaliate la capitolul urmtor.
4.5.1 Interfaarea cu prezentarea, selecia elementelor

Pentru acordarea feedbackului pe o selecie a documentului PDF, trebuie nti realizat selecia i
reprezentat ntr-un mod n memorie. Selecia se declaneaz la apsarea unui buton, pentru a nu se
ncerca o selecie eronat, sau pentru necesitatea resetrii seleciei fcute.
Selecia se face prin alegerea a doua puncte din slide, cel de capt stnga sus i cel de capt dreapta
jos. n momentul realizrii seleciei, este generat un ir de caractere reprezentativ pentru selecie. Acest
script cuprinde numrul slide-ului i id-uri ale elementelor din slide astfel nct s se poat reconstitui
selecia din irul de caractere, necesar la prezentarea feedbackului pentru speaker.
Id-ul seleciei folosit pentru accesarea i stocarea resurselor pe serverul web este numrul ntreg
obinut din aplicarea metodei hashCode() asupra stringului. Atunci cnd se realizeaz o selecie pe
documentul PDF, se reine aceast mapare ntre string i hash-codul sau, pentru a fi posibil operaia
invers de determinare a irului de caractere i, deci, a seleciei vizuale din id-ul seleciei.
4.5.2 Metodele handler ale butoanelor

Butoanele aplicaiei intr, la fel ca i ferestrele, la modulul de interfata Android. Legarea acestora de
modulul de comunicaie cu serverul presupune apelarea interogrilor atunci cnd un buton este apsat.
n clasa MuPDFActivity, clasa de startup a aplicaiei Smart Presentation, exist definit o clasa handler
comun pentru toate butoanele. Alegerea handlerului potrivit fiecrui buton se realizeaz n metoda
OnClick, prin verificarea callerului [13].
Handlerele butoanelor aplicaiei pot efectua dou tipuri de operaii, din punct de vedere al
comunicaiei i al accesrii datelor: pot instania o clas AsyncTask i s apeleze execute pe aceasta, sau
pot realiza o interogare managedQuery a Content Providerului, asupra cruia cade responsabilitatea
efecturii cererii asincrone ctre server, dac datele interogate 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 ctre server. La fel este i cazul butonului "Go live!", care declaneaz o aciune
repetitiv n cadrul unei clase AsyncTask, de sincronizare a slide-ului cu cel existent pe server, pn la
apsarea unui alt buton care provoac ieirea din modul Live.
35
5. Utilizarea aplicaiei
5.1 Descrierea aplicaiei
Aplicaia Smart Presentation permite utilizatorilor unor dispozitive Android care iau parte la o
prezentare s interacioneze n timp real cu aceasta, existnd dou moduri de utilizare: speaker i simplu
uer, persoana aflat n audien. Scopul principal al aplicaiei 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 ambiguitate, care indic necesitatea unor clarificri
suplimentare sau feedback de proof sau citation needed, pentru exprimarea necesitii citrii sursei. n
plus, utilizatorii pot formula ntrebri legate de selecia fcut adresate speakerului, sau pot vedea
ntrebrile deja reinute de la ali asculttori pentru a-i exprima acordul cu una din ele. ntrebrile sunt
grupate semantic pe un server central, astfel nct toi userii s poate vedea doar o forma compact a
ntrebrilor, fiind selectate doar cele reprezentative din punct de vedere semantic.
O alt facilitate a aplicaiei este posibilitatea de navigare liber prin prezentarea descrcat pe
propriul dispozitiv, sau folosirea modului live, care sincronizeaz permanent prezentarea cu cea a slideului speakerului pn cnd modul este dezactivat.
La sfritul prezentrii, speakerul poate vedea pe documente diversele feedbackuri primite din
audien pe timpul prezentrii astfel nct s poat rspunde mai eficient la ntrebri i s i
mbunteasc prezentarea pentru viitor.
5.2 Scenarii utilizare screenshots

Pentru exemplificarea scenariilor de utilizare, vom presupune existena urmtoarelor persoane, cu
urmtoarele roluri: Dan este prezentatorul, Alina, Andrei i Elena sunt simpli asculttori. Toi patru dein
un dispozitiv Android i documentul PDF este stocat pe un server aflat n apropiere care poate fi accesat
prin mediul wireless.
n momentul pornirii aplicaiei, este declanat o cerere ctre server de descrcare a documentului
PDF stocat pe acesta. La primirea rspunsului i scrierea documentului n memorie, cei patru utilizatori
sunt ntmpinai cu o fereastr care le permite s selecteze rolul pe care l vor avea: speaker sau simplu
uer. Dan alege s fie speaker, ceilali trei aleg s fie simpli ueri. Dup alegerea rolului, cei patru i aleg
numele cu care vor fi reinui n sistem (Figura 10).
Fig. 10 Ferestrele iniiale ale aplicaiei
n urmtoarele situaii sunt descrise activitile userilor din audien, adic Alina, Andrei i Elena.
Dup alegerea numelui, este ncrcat prezentarea de la nceput i acetia pot vedea interfaa aplicaiei
(Figura 11).
36
Fig. 11 Interfaa clientului n aplicaie
n continuare, Alina hotarete s parcurg aa cum dorete prezentarea, pentru ca este curioas de
coninutul acesteia. Andrei i Elena hotaresc s fie sincronizai cu prezentarea inut de Dan, pentru a fi
mai ateni la ceea ce spune acesta. Astfel, cei doi aps primul buton din stnga jos, cel de Go live!, care
le permite intrarea n modul sincronizat.
Pe parcursul prezentrii, Alina hotareste s fac o selecie pentru a trimite un feedback de
ambiguous. Pentru a face asta, ea apas pe al doilea buton, cel marcat cu T, i realizeaz selecia. Dac
nu este mulumit cu selecia fcut, ea poate reseta selecia prin apsarea aceluiai buton.
Fig. 12 Selecie fcut pe o poriune de text
n acest timp, Andrei i Elena se afl la alt slide, cel la care se afl i Dan, acetia fiind n modul Live.
Andrei se hotareste s pun o ntrebare legat de titlul slideului. Pentru aceasta, el selecteaz nti titlul
(Figura 13).
37
Fig. 13 Selecie fcut pe titlu
Apoi, acesta apsa pe al treilea buton de jos, care i arta ntrebrile semnificative deja
formulate pentru selecia fcut:
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 scrierea unei ntrebri noi.
38
Fig. 15 Adugarea unei noi ntrebri
Pe parcursul prezentrii, Elena a acordat mai multe feedbackuri de tip ambiguous (penultimul
buton) sau proof needed (ultimul buton), i a remarcat c, pentru unul din concepte, explicaia se afl
deja n prezentare, motiv pentru care se ntoarce la slide-ul respectiv i i retrage feedbackul pe aceeai
selecie.
Fig. 15 Adugarea unei noi ntrebri
n timpul prezentrii, Andrei, Elena i Alina acord mai multe feedbackuri de tip +1, pentru a-i
exprima o prere pozitiv legat de elementele selectate.
39
La sfritul prezentrii, Dan poate utiliza interfaa proprie, care i arat pentru fiecare tip de
feedback seleciile fcute pe document, pentru a asocia corect feedbackul cu elementele asupra crora
acesta a fost acordat.
40
6. Concluzii
Dezvoltarea aplicaiei Smart Presentation a necesitat utilizarea multor cunotine practice i
teoretice nvate n facultate, cum ar fi: protocoale de comunicaii, programare i design orientate
obiect, structuri de date, calcul paralel i sincronizare ntre threaduri, baze de date sau ingineria
programelor. n plus, au fost necesare acumularea unor cunotine teoretice noi, ct i nvarea
utilizrii unor tehnologii noi.
Dezvoltarea serverului mi-a permis s studiez arhitectura 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 resursele 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 pachetele http.
Implementarea modulului suplimentar de grupare a ridicat probleme de sincronizare, datorit
accesului comun la date din threaduri separate i a necesitii crerii unui mecanism de comunicare
ntre threaduri.
Din punct de vedere al clientului, am nvat concepte importante de programare pe sistemul de
operare Android. n primul rnd, ideea de entry point sau clasa main sunt inexistente pe Android, unde
serviciile i procesele lansate la execuia unei aplicaii sunt definite ntr-un fiier de configurare. n al
doilea rnd, din punct de vedere al gndirii arhitecturale, programarea pe Android foreaz utilizatorul
s separe funcionalitile aplicaiei 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 threadul principal. Stocarea datelor se face ntr-un mod
canonic ntr-o baz de date Sqlite care asigur persistena datelor. n cazul meu, am folosit o astfel de
baz de date pentru persistena unor informaii, similar cu pstrarea unor structuri de date, dar ntr-un
mod mai robust i care permite accesul simplu, prin adrese URI.
Pentru a realiza cererile HTTP de la client ctre server, am explorat versatilitatea clasei AsyncTask,
prin care dezvoltatorului i se ofer toate mecanismele necesare sincronizrii threadului apelant cu cel de
background i actualizarea datelor i a interfeei cu cele incluse n rspunsul primit de la server.
Comunicaia ntre client i server mi-a lsat la alegere conceperea diverselor tipuri de mesaje,
serializate n mod diferit i cu semnificaii diferite, care alctuiesc protocolul aplicaiei. Pentru mesajele
largi, de agregare a feedbackului de ntrebri, am ales s folosesc mecanismul de serializare binar
Google Protocol Buffers, o soluie optim i foarte uor de implementat, datorit generrii automate a
claselor Java dintr-un format de definire a mesajelor proprietar, user-friendly.
Rezultatul final al lucrrii s-a transpus ntr-o aplicaie care ndeplinete obiectivele formulate iniial:
posibilitatea sincronizrii prezentrii unui client Android din audien cu cea a speakerului;
acordarea de feedback de tip positive feedback, ambiguous, proof needed sau sub forma unei
ntrebri pe o selecie a unui slide sau pe ntregul slide curent al prezentrii;
vizualizarea feedbackului agregat n timp real i posibilitatea exprimrii acordului cu feedback
deja formulat de alte persoane;
retragerea feedbackului propriu efectuat;
interfee diferite de utilizare pentru speaker i audienta;
vizualizarea de ctre speaker a unei variante finale, agregate a tuturor tipurilor de feedback
acordate de audien.
41
n viitor, aplicaia poate fi dezvoltat, pentru a permite diverse faciliti noi. n primul rnd, este
necesar gruparea mai eficient a ntrebrilor, bazat pe un algoritm care s grupeze mai inteligent
ntrebrile pe baza similaritii semantice i care s aleag un centroid al clusterelor reprezentativ
pentru ntrebrile grupate. n prezent, gruparea se bazeaz n special pe cuvinte de baz i nu pe cuvinte
cheie care pot schimba sensul unei ntrebri.
Alte mbuntiri care pot fi aduse aplicaiei sunt: o interfata mai interactiv i informativ a
aplicaiei, care s permit o vizualizare mai intuitiv i mai cuprinztoare a feedbackului, devoltarea unui
sistem de autentificare pentru a acorda privilegii diferite uerilor, posibilitatea ncrcrii n realtime a
unui document nou de prezentare sau dezvoltarea unei interfee grafice a serverului, care s permit o
configurare a acestuia.
De asemenea, ar fi interesant/util de implementat o clasificare a userilor, n funcie de o reputaie a
acestora, care s le acorde o pondere mai mare propriilor feedbackuri n faa unor utilizatori noi.
42
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] Documentaia 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/acrobat/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/index-137171.html>
[7] Documentaia oficial Jersey, 20.06.2012, < http://jersey.java.net/nonav/documentation>
[8] RESTful Web Services Developer's Guide, 20.06.2012,
<http://docs.oracle.com/cd/E19776-01/820-4867/ggrby/index.html>
[9] Documentaia 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/article.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
43

George Cristian Stoica AndroidSmartPresentationFeedback Document

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

George Cristian Stoica AndroidSmartPresentationFeedback Document

Uploaded by

Copyright:

Available Formats

UNIVERSITATEA POLITEHNICA BUCURETI

FACULTATEA DE AUTOMATIC I CALCULATOARE

Prof. dr. ing.

As. dr. ing. Andrei Olaru

1.2 Ideea i scopul proiectului

1.3 Structura proiectului

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

modulul de clusterizare a ntrebrilor puse de audin pe baza similaritilor semantice.

1.4 Structura lucrrii

Fig. 1 Arhitectura Android

Wikipedia, The Free Enciclopedia, 20.06.2012,

2.2 Tehnologiile specifice folosite pentru comunicarea client-server

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

O cerere HTTP conine urmtoarele :

Headere Http, cum ar fi Accept-Language: en-US, Accept-Charset: utf-8, etc.

Un corp al mesajului, opional

Un rspuns HTTP conine urmtoarele:

Headere HTTP, cum ar fi Content-Type: text/html

Un corp al mesajului, opional

text/plain definete un coninut n text clar, necodat.

application/x-protobuf indic un coninut binar, serializat cu Google Protocol Buffers. Este

Grizzly Web Container

Servicii Web RESTful i Jersey JAX-RS

Grizzly website, 20.06.2012, < http://grizzly.java.net/>

Un WebService RESTful se bazeaz pe metodele HTTP i pe conceptele arhitecturii REST. Acesta

PUT creaz o nou resurs, trebuie s fie idempotent.

POST actulizeaz resursa existent sau creaz o nou resurs.

Jersey reprezint implementarea Java open source, de referin, la calitate de producie a

indic faptul c metoda va rspunde unei cereri POST

indic faptul c metoda va rspunde unei cereri GET

indic faptul c metoda va rspunde unei cereri PUT

indic faptul c metoda va rspunde unei cereri DELETE

@Produces(mimetype [, more types])

definete ce mime-type va avea coninutul returnat l ao metoda adnotat cu

@Consumes(mimetype [, more types])

Definete ce mime-type este consumat de aceast metod, PU sau POST

Folosita pentr a injecta valori din URL c parametru al metodei. Se folosete

Leag parametrul de o valoarea unui parameru de interogare HTTP

Leag parametrul de valoarea unui header HTTP

required Type type = 3;

Fig. 2 Comparaie Xml Google Protocol Buffers

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

2.3 Alte tehnologii folosite n cadrul proiectului

Un antet format dintr-o singura linie specificnd versiunea PDF.

Un corp coninnd obiectele ce compun documentul.

Un tabel cross-reference coninnd informaii despre obiectele indirecte din fiier

Un trailer oferind locaia tabelului cross-reference.

Fig. 4 Arhitectura global a sistemului

3.2 Arhitectura clientului Android

Fig. 5 Diagrama UML a arhitecturii MVC implementat prin ContentProvider

3.3 Arhitectura serverului web

un server web, care rspunde la cereri HTTP pentru resurse;

Fig. 6 Diagrama UML a arhitecturii de stocare pe server

Fig. 7 Diagrama UML a claselor resursa UML i a metodelor de prelucrare

stocheaz prezentarea pe care clienii cu dispozitive Android o descrc la deschiderea

centralizeaz feedbackului primit de la clieni, stocnd toate tipurile de feedback;

rspunde la cereri de la clieni pentru feedbackul agregat;

4.1.1 Structura URLului

/containers/slidecontainer/slide adresa la care este reinut slideul curent la care se afl

descrcarea prezentrii PDF stocate pe server;

/containers/ambiguousfeedback/[selection_id] aceasta este resursa la care se reine

/containers/positivefeedback/aggregate aceasta este resursa la care se reine o list de

mapari selecie feedback pozitiv;