george cristian stoica androidsmartpresentationfeedback document (1)

UNIVERSITATEA

FACULTATEA DE AUTOMATIC I CALCULATOAREDEPARTAMENTUL CALCULATOARE

LUCRARE DE LICEN

Smart Presentation FeedbackComunicaia

Coordonatori tiinifici:

Prof. dr. ing. Adina Magda Florea

As. dr. ing. Andrei Olaru

i

UNIVERSITATEA POLITEHNICA BUCURETI FACULTATEA DE AUTOMATIC I CALCULATOARE

DEPARTAMENTUL CALCULATOARE

LUCRARE DE LICEN

Smart Presentation Feedback Comunicaia client-server

ng. Adina Magda Florea

George-Cristian Stoica

BUCURETI

2012

FACULTATEA DE AUTOMATIC I CALCULATOARE

Absolvent:

Cristian Stoica

ii

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.

iii

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


1

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:

1 Pagina web cu ideea proiectului, 20.06.2012,


2

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.


3

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, T-Mobile 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 2

1 Wikipedia, The Free Enciclopedia, 20.06.2012,

< http://en.wikipedia.org/wiki/Android_(operating_system)> 2 Kebomix blog, 20.06.2012,


4

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-IN-TIME, 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, API-ul 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.


5

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:

: [ ? ] [ # ]

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 =, cu perechile separate prin ";" sau "&". Partea fragmentului este de

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


6

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.


7

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.

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

2 Roy Fielding, "Architectural Styles and the Design of Network-based Software Architectures", 20.06.2012,


8

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(mime-type [, 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"


9

@Consumes(mime-type [, 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, forward-compatible 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;

}


10

required Type type = 3; message EmbeddedMessage {

required int64 id = 1; required string label = 2 [default = "SAMPLE"]; } repeated EmbeddedMessage internalLabels = 4; }

Exemplu Protocol Buffers

Dup cum se poate observa, formatul .proto este foarte intuitiv, foarte facil de scris i permite o mapare la tipuri de date i structuri de date de baz n toate limbajele de programare populare: stringuri, tipuri numerice de date, liste, dar i 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 Buffers1

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,


11

2.3 Alte tehnologii folosite n cadrul proiectului

Formatul PDF

Pentru reprezentarea documentelor am ales formatul PDF (Portable Document Format), motivul principal fiind reprezentat de popularitatea acestui i de unele avantaje tehnologice clare.

PostScript care este limbajul de programare interpretat 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.

o Un corp coninnd obiectele ce compun documentul.

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

o 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.


12

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


13

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.


14

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


15

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


16

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


17

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


18

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 descrcarea prezentrii PDF stocate pe server;

/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;


19

/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


20

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:

1. 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 propriu-zis 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.

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


21

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 accesarea feedbackului de tip positive feedback

o [adresa_server]/containers/ambiguousfeedback/[id_selecie] - pentru accesarea feedbackului de tip ambiguu

o [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 content-type 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.


22

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 {

required string selectionString = 1; 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; required string selectionString = 2; 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 selectionString = 1; 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


23

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 FeedbackQuestion feedbackQuestion = 2; optional QuestionCluster questionCluster = 3; optional SelectionClusters selectionClusters = 4; optional AggregateQuestionsFeedback aggregateQuestions = 5; optional 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;


24

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 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


25

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:

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


26

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 Android1

1 Zigurd Mednieks, Laird Dornin & G. Blake Mieke: Programming in Android 2

nd Edition (O'Reilly, 2012), 80


27

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


28

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 AsyncTask1

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 n constructor sau n onPreExecute() i referirea lor n doInBackground(Params...)

setarea cmpurilor membri n doInBackgroud(Params...) i referirea lor n 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 ntr-un 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 Zigurd Mednieks, Laird Dornin & G. Blake Mieke: Programming in Android 2

nd Edition (O'Reilly, 2012), 110


29

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:


30

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


31

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).


32

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 containerMap = new HashMap(); private Map dataMap = new HashMap();

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:

1 Exemple Jersey, Storage-Service, 20.06.2012,


33

[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[]).

george cristian stoica androidsmartpresentationfeedback document (1)

Documents