As. dr. i ng. Andrei Olaru [604584]

UNIVERSITATEA POLITEHNICĂ BUCUREȘTI
FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE
DEPARTAMENTUL CALCULATOARE

PROIECT DE DIPLOM Ă
Smart Presen tation Feedback
Interfa ța cu utilizatorul

Coordonator i științifici : Absolvent: [anonimizat]. dr. i ng. Adina Magda Florea Anca -Virginia Pîrvan
As. dr. i ng. Andrei Olaru

BUCUREȘ TI
2012

ANCA – VIRGINA P ÎRVAN

2
Cuprins

1. Introducere ………………………….. ………………………….. ………………………….. ………………………….. … 4
1.1 Contextul proiectului ………………………….. ………………………….. ………………………….. ……………………… 4
1.2 Ideea și scopul proiectului ………………………….. ………………………….. ………………………….. ………………. 4
1.3 Structura proiectului ………………………….. ………………………….. ………………………….. ………………………. 5
1.4 Structura documentului ………………………….. ………………………….. ………………………….. ………………….. 5
2. Aspecte teoretice ………………………….. ………………………….. ………………………….. ……………………. 6
3. Tehnologi i folosite ………………………….. ………………………….. ………………………….. …………………. 10
3.1 Sistemul de operare Android. Tehnologiile Android folosite ………………………….. …………………….. 10
3.2 Tehnologiile folosite pentru comunicația client -server. Alte tehnologii ………………………….. …….. 16
4. Arhitectura sistemului ………………………….. ………………………….. ………………………….. …………… 21
4.1 De scrierea arhitecturii și a func ționalit ății proiectului ………………………….. ………………………….. …. 21
4.2. Modulele funcționale ale sistemului ………………………….. ………………………….. …………………………. 22
4.3. Arhitectura clientului Android ………………………….. ………………………….. ………………………….. ………. 23
5. Detalii de implementare ………………………….. ………………………….. ………………………….. ………… 25
5.1 Im plementarea interfețelor de utilizare ale clientului Android ………………………….. …………………. 25
5.1.1 Interfața clientului participant la prezentare ………………………….. ………………………….. ……….. 25
5.1.2 Interfața clientului prezentator ………………………….. ………………………….. ………………………….. . 35
5.1.3 Folosirea MuPDF pentru vizualizarea PDF -urilor ………………………….. ………………………….. …… 35
6. Utilizarea aplicației ………………………….. ………………………….. ………………………….. ………………… 37
7. Concluzii și dezvoltări ulterioare ………………………….. ………………………….. …………………………. 41
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. …… 42
Anexe ………………………….. ………………………….. ………………………….. ………………………….. ………….. 44

Smart Presentation Feedback –Interfața cu utilizatorul

3
Rezumat

Proiectul Smart Presentation Feedback constă în implementarea unei
aplicații inteligente pentru trimiterea feedback -ului de la auditoriu la
vorbitor , în timpul unei prezentări . Persoanele din sală pot trimite
feedback prezentator ului sub formă de întrebări, aprecieri pozitive sau
negative , folosind opțiunile disponibile . La finalul prezentării, vorbitorul
are posibilitatea de a vedea feedback -ul primit într-o formă agregată ;
selecțiile făcute de auditoriu au culori diferite în funcție de tipul de
feedback ales. Observațiile primite au rolul de a -l ajuta pe vorbitor să își
îmbunătățească prezentările viitoare. În această lucrare este descrisă o
aplicație al cărei scop principal este eficientizarea comunicării între sală
și prezentator, d ar și între persoanele din sală. Aceasta se adresează în
primul rând persoanelor care participă la o prezentare des pre un anumit
subiect și doresc să urmărească cu ușurință opiniile fiecărui participant.
Contribu ția mea principal ă la acest proiect a fost implementarea
interfe ței, urm ărind o interac țiune cât mai bun ă cu utilizatorul.

ANCA – VIRGINA P ÎRVAN

4
1. Introducere
1.1 Contextul proiectului
Dispozitivele mobile cu Android au cunoscut o foa rte mare dezv oltare î n ultimii ani, atingând
o cotă de piață majoritar ă în anul 2012 (Figura 1) . O dată cu evolu ția telefoanelor mobile , s-au extin s
și aplica țiile dezvoltate folosind sistemul de operare Android.
Ca urmare a acestei evolu ții a sistemului de operare And roid ș i a aplica țiilor pe dispoz itive
mobile, proiectul meu se încadrează în aceea și zon ă de interes ș i constă î n implementarea unei
aplica ții inteligente pentru trimiterea feedback -ului sub formă de întrebări , aprecieri pozitive sau
negative , unui vorbitor care susține o prezentare, curs, lucrare sau prezintă un pr odus care trebuie
lansat pe piață internă sau interna țional ă. La finalul prezentării , vorbitorul a re posibilitatea de a
vizualiza într-o formă agregat ă feedback -ul primi t de la auditoriu și de a răspunde la întrebările și
observațiile primite pe parcurs .
Proiectul Smart Presentation Feedback este parte a proiectului Google Android
EDU și a fost implementat în colaborare cu Stoica G eorge -Cristian și Dincă Dragoș, sub
îndru marea și supravegherea As . dr. ing. Andrei Olaru și I ng. Tudor Berariu.

1.2 Ideea ș i scopul proiectului
Pe parcursul unei prezentări care conține slide -uri cu informații complexe (ex: formule
matematice, algoritmi, demonstrații ale unor teoreme) ce solicită concentrarea persoanelor din
auditoriu un timp îndelungat , poate interveni plictiseala și lipsa de atenție a publicului din diverse
motive. Câteva din aceste motive ar putea fi: vorbitorul prezintă într -un ritm alert informa țiile, iar
persoana di n auditoriu nu are suficient timp pentru a înțelege ideea transmisă ; până la finalul
prezentării, când poate adresa o în trebare, este posibil ca persoana din sală să își piardă ideea.
Aplicația dezvoltată de noi are ca scop principal evitarea acestor prob leme care pot apărea pe
parcursul unei prezentări , sporirea atenției publicului și eficientizarea comunicării dintre sală și
prezentator . Este dezvoltată pe dispoz itive mobile cu Android , adresându -se în primul rând
utilizatorilor, dar și dezvoltatorilor de aplica ții Android .
Folosind această aplica ție, utilizatorii ș i speakerul vor avea o mai bună comunicare.
Persoanele din sală vor putea urmări prezentarea î n propr iul lor ritm, nefiind nevoite să țină pasul cu
vorbitorul ș i putând aloca timpul dorit fiecărui slide, vor putea face adnotări pe parcurs, evitând
astfel posibilitatea pierderii ideilor până la finalul prezentării /lecției.
Speakerul va putea răspunde , la finalul prezentării, la întrebările pe care le prime ște în
feedback -ul agr egat, în ordinea importanței și a numărului de întrebări de acela și tip.

Smart Presentation Feedback –Interfața cu utilizatorul

5 Scenariu l de func ționare al proiectului : Anca susține o prezentare în fața colegilor săi de la
cursul de IA. În timp ce ea parcurge prezentarea, colegii din audiență pot să navigheze independent
prin slide -uri, să facă adnotări, să scrie întrebări, să dea feedback pozitiv unui text /imagini folosind
butonul +1. Cristi nu înțelege cum a aplicat A nca o formulă pe un anumit slide și vrea să noteze o
întrebare în legătură cu aces t lucru, dar observă că un a lt coleg a pus deja aceeași întrebar e. Cristi
poate doar să apese butonul +1 pentru a susține că are aceea și întrebare . În cazul în care Cristi vrea
să primească o explicație detaliată legată de aplicarea unei formule sau a unui algoritm, el poate
folosi unul din butoanele ambigous sau citation or proof needed . La finalul prezentării ,
Anca poate vedea feedback -ul agregat pe care l -a primit de la colegi și poate răspunde la întrebări și
observații . Analizând feedback -ul primit, Anca își poate îmbun ătăți prezentările viitoare. [1]
1.3 Structura proiectului
Proiectul este împăr țit în patru module principale, fiecare din cei implica ți în dezvoltare se ocupă
de unul din aceste ele:
 Interfa ța cu utilizatorul
 Selec ția din PDF
 Modulul client – server
 Clusterizarea întrebărilor
Eu m -am ocupat d e partea de interfa ță cu utilizatorul care este împăr țită în interfa ța audienței și
interfa ța vorbitorului. Aceste interfe țe au câteva func ționalit ăți comune. Acest modul constă , în
principal, în implementarea funcționalităților și design -ului butoanelor care compun cele două
interfețe.
1.4 Structura documentului
Documentul este împăr țit în 8 capitole, fiecare capitol fiind structurat pe mai multe
subcapitole . În cele ce urmează va fi prezentată modalitatea de realizare a aplica ției, subliniind
problemele întâlnite și modalităț ile de rezolvare a acestora.
În capitolul 2 voi prezent a câteva aspecte teoretice legate de interfața cu utilizatorul, ergonomie și
principiile ergonomice.
Capitolul 3 este o scurtă prezentare a sistemului de operare Android, la modul general, dar și o
prezentare a tehnologiilor Android , a tehnologiilor client – server și a altor tehnologii pe care le -am
utilizat pentru implementarea proiectului.
Capitolul 4 descrie arhitectura și funcționalitățile proiectului, modulele sistemului și relațiile dintre
acestea .
Capitolul 5 este o prezentare a modului de implementare a intefețelor clientului Android, cuprinzând
detalii tehnice și fragmente din codul propriu.
Capitolul 6 prezintă în detaliu aplicația dezvoltată și cuprinde imagini sugestive ale funcționalităților
existente .

ANCA – VIRGINA P ÎRVAN

6
2. Aspecte teoretice

Interac țiunea dintre utilizatori și calculatoare apare la nivelul interfe ței cu utilizatorul, c are
include aspecte ergonomice, software și hardware. La calculatoarele moderne există următoarele
puncte centrale ale interfe ței om-calculator : interfa ța grafică ( pe un monitor sau ecran de calculator),
interfa ța grafică mijlocită prin atingerea monitorul ui (touch screen) , interfa ța grafică prin comenzi
verbale ( recunoa șterea vocii).
Interfa ța este acea parte a aplica ției software prin intermediul căreia utilizatorul
interac ționeaz ă cu calculatorul, având posibilitatea de a -și exprima inten țiile de opera re și de a
interpre ta rezultatele efectuate de mașină. Interfa ța nu este concepută doar ca parte vizuală a
software -ului, pentru majoritatea utilizatorilor reprezintă întregul sistem de calcul. Orice interfa ță
poate fi utilă, utilizabilă ș i utilizată .
Brazier considera că interfața defineș te modul în care utilizatorul trebuie să interacționeze cu
sistemul pentru a delega sistemului sarcinile unitate specifice. Utilizatorul traduce sarcinile unitate în
sarcini de bază , ce sunt implementate în interfa ța utilizator. [2]

Un aspect deosebit de important în definirea interfe ței utilizator este faptul că interfaț a
reprezintă din sistemul complex utilizatorului , doar aspectele relevante pentru interacțiunea sa cu
sistemul. Celelalte aspecte care există în siste m dar nu sunt accesibile utilizatorului, nu îi influen țează
acestuia interac țiunea cu sistemul . Van der Veer a numit interfața și mașina virtuală a
utilizatorului. [2]

O interfa ță – utilizator este bine scrisă atunci când programul se comportă exact așa cum se
așteapt ă utilizatorul.
Proiectarea interfe țelor cu utilizatorul este rezultatul activită ților de: înțelegere a nevoilor
utilizatorilor, proiectare (design) , evaluare/ testare, implementare finală, men ținere .

Ergonomia este disciplina științifică ce studiază interac țiunea dintre oa meni ș i alte elemente
ale unui sistem , precum ș i profesia care aplică teorii, principii, informa ții și meto de de design pentru
optimizarea activită ții omului ș i performanțele sistemului din care acesta face par te [defini ție
adoptată în august 2000 de către consiliul director al Asocia ției Interna ționale de Ergonom ie].
Denumirea de ergonomie derivă din cuvintele grece ști ergon (=muncă ) și nomos (=reguli) pentru a
exprima știința muncii și se aplică tuturor domeni ilor de activitate. Ergonomia promovează o
abordare care ia în considerare aspectele fizice, cognitive, sociale, organiza ționale , de mediu ș i alți
factori importan ți. Pentru aceasta, ergonomia integrează cuno ștințe dintr -o varietate de discipline
care includ: anatomia, fiziologia, științe tehnice, psihologie, sociologia, economie etc.

Smart Presentation Feedback –Interfața cu utilizatorul

7 Ramurile principale ale ergonomiei sunt: ergonomia fizică , ergonomia cognitivă și ergonomia
organiza țional ă.
Ergonomia fizică se refe ră la modul de raportare la activitatea fizică a caracteristicilor
anatomice, fiziologice și biomecanice ale omului. Domenii de studiu: posturi de lucr u, manipularea
obiectelor, mi șcări repetitive, designul locului de muncă .
Ergonomia cognitivă se referă la modul în care procesele mentale, cum ar fi percep țiile,
memoria, logica, răspunsurile motorii, influen țează interac țiunile dintre oameni și alte elemente ale
unui sistem. Domenii de studiu: interac țiunea om-calculator, suprasolicitarea neuropsihică , luarea
deciziilor, obținerea performanței , stresul la locul de muncă , pregătirea .
Ergonomia organiza țional ă este ramura ergonomiei care se preocupă de optimizarea
sistemelor sociotehnice, incluzând structurile organiza ționale , politicile și procesele. Domeni i de
studiu: comunicarea, managementul resurselor, stabilirea orarului de muncă , mun ca în echipă ,
ergonomia comunită ților, noi paradigme în muncă , organiza ții virtuale, teleactivitatea.
Ergonomia este definită și ca știință și tehnologie interdisciplinară având ca obiect adaptarea
reciprocă între oameni, mașini și mediu în cadrul interacțiunii lor ca sisteme [3 ]. Ergonomia apare
deci ca un demers sistematic de achiziție și organizare a cunoștințelor despre om în scop ul utilizării
lor în conceperea instrumentelor de lucru, în ameliorarea condițiilor activității pentru reducerea
efortului și creșterea confortului, securității și eficacității. Continuând tradiția ergonomiei sist emelor
om-mașină, ergonomia cognitivă se co ncentrează în mod particular asupra interacțiunii dintre om și
mediul activității sale cognitive, concentrându -se pe procesele de înțelegere, raționament și utilizare
a cunoștințelor.
Suportul fizic al interacțiunii om -calculator este reprezentat de interfață , adică totalitatea
elementelor fizice reale sau virtuale și a programelor de calculator implicate în acest proces. Alăt uri
de interfața propriu -zisă și caracteristici specifice mașinii, interacțiunea om -calculator implică și un
context de utilizare (social, organizațional), precum și trăsături specifice omului (cunoștințe,
deprinderi, atitudini, aspect e afective și motivaționale etc ).
Unul dintre scopurile ergonomiei cognitive este tocmai obținerea unei tehnologii
comprehensibile și utilizabile. Interfața om -calculator este utilizabilă dacă consideră următoarele
condiții: utilizarea ei este ușor de învățat și reamintit, este eficientă, adică se pot efectua rap id
acțiuni comple xe, este consistentă, unitară, flexibilă, confortabilă. Proiectarea interfețelor utilizabile,
prietenoase și personalizate impune considerarea mai multor principii de ergonomie cognitivă:
principiul coerenței , caracterul unitar al constituenților interfețe i, principiul conciziunii (reducerea
efortului cognitiv) , asigurarea unei economii cognitive, principiul conexiunii inverse ( asigurarea
feedback -ului), asigurarea unei reacții la orice interacțiune pentru a furniza informații utilizatorului

ANCA – VIRGINA P ÎRVAN

8
asupra funcțion ării sistemului în scopul înțelegerii cât mai ușoare a stării curente și detectarea
situațiilor nedorite [4 ].
Criteriile ergonomice constituie un mijloc de încorporare a utilizabilită ții în proiectul unei
interfe țe, ajută la structurarea și completarea un ui set de indicatori și măsuri pentru evaluare și la
elaborarea unor reguli de proiectare a interfe țelor . Unui criteriu ergonomic îi corespund una sau mai
multe reguli de proiectare. Mai jos voi analiza câteva dintre criteriile ergonomice:
 Ghidarea utilizatorului se referă la mijloacele de orientare, informare și ghidare a
utilizatorului pe parcursul interacțiunii om -calculator. Mijloacele de ghidare sunt diverse:
etichete, mesaje, alarme etc.
Ghidarea facilitează ușurința în învățare și utilizarea sistemului, având ca efect reciproc
performanțe mai bune în execuție și reducerea numărului de erori.
 Efortul utilizatorului se referă la toate elementele interfeței care au un rol în reducerea
încărcării perceptuale sau cognitive a utilizatorului și în c reșterea eficienței dialogului. Cu
cât utilizatorul este mai încărcat, cu atât mai mare este proba bilitatea de a comite erori.
Nu este recomandabilă distragerea utilizatorului prin afișarea unei informații care nu este
necesară, întrucât aceasta constituie o piedică în îndeplinirea cu eficiență a sarcinii.
 Controlul explicit se referă atât la procesarea de către sistem a acțiunilor explicite ale
utilizatorului cât și la controlul pe care utilizatorul îl are asupra procesării acțiunilor sale
de către sistem. Atunci când utilizatorul definește în mod explicit intrările și când intrările
se află sub controlul său, erorile și ambiguitățile sunt limitate.
 Adaptabilitatea se referă la capacitatea unui sistem de a se comporta contextual și în
concordanță cu nevoile și preferințele utilizatorului.
 Tratarea erorilor se referă la mijloacele disponibile pentru a preveni și/sau reduce erorile
și de a permite recuperarea în ca z de eroare. E rorile se referă la intrări de date invalide,
erori de sintaxă etc. Întreruperea pr ocesării ca urmare a erorilor utilizatorilor are efecte
negative asupra activității utilizatorilor. Prin limitarea numărului de erori, numărul de
întreruperi este de asemenea limitat.
 Consistența se referă la modul în care opțiunile de proiectare ale inter feței (coduri,
denumiri, formate, proceduri etc.) sunt menținute în contexte similare și sunt diferite
atunci când sunt aplicate unor contexte diferite. Consistența este un criteriu elementar.
 Semnificația codurilor califică relația dintre un termen și/sau un semn (simbol) și
referința acestuia. Codurile și denumirile sunt semnificative pentru utilizator atunci când
există o relație semantică puternică între aceste coduri și articolele sau acțiunile la care
se referă. Semnificația codurilor este un criteriu elementar.
 Compatibilitatea se referă la potrivirea dintre caracteristicile utilizatorului (memorie,
percepție, obiceiuri, vârstă, așteptări) și ale sarcinii, pe de o parte, și organizarea
intrărilor, ieșirilor și dialogului pentru o aplicație dată, pe de altă parte. De asemenea,
compatibilitatea se referă la coerența dintre medii și dintre aplicații. [5]

Smart Presentation Feedback –Interfața cu utilizatorul

9 Știința factorilor umani poate fi numită uneori ergonomie și se referă la arta de a asigura
aplicarea cu succes a ingineriei factorilor umani într-un program. În general , un factor uman este o
proprietate fizică sau cognitivă a unui individ sau comportament social, care este specifică influenței
omului asupra func ționării sistemelor tehnologice și echilibrului dintre om și mediu. Ia în calcul factori
lega ți de: vizibilitate, feedback, consistență ( nu induce riscul unor confuzii cauzate de contradic ții
apărute între diferite aspecte interpretate), restric ții și indica ții. Exemple: indica ții pentru a clarifica
modalitatea de folosire, restric ții în aplicarea anumitor soluții, inconsistenta (tastatura numerică la
calculator vs. telefon mobil).
În cadrul interac țiunii om-calculator, ramura care se ocupă cu aspectele psihologice cognitive
ale interac țiunii om-calculator este ergonomia cognitivă . Menir ea ergonomiei cognitive este de a
adapta instrumentele cognitive, precum și utilizarea lor în așa fel încât să îmbunătă țeasc ă procesarea
informa ției umane în termenii îmbunătă țirii eficienței interac țiunii , scăderii ratei de erori și accidente
și crearea u nui sentiment de confort.
Interfa ța trebuie să asigure o comunicare cât mai facilă . O interfa ță este utilizabilă dacă și
numai dacă folosirea ei este ușor de învă țat și reamintit, e eficientă (se execută rapid acțiuni
complexe), e flexibilă , confortabilă , consistentă și unitară .
Ergonomia interfe țelor căută modalită țile cele mai bune de a realiza interfe țe prietenoase,
personalizabile și utilizabile.
Ergonomia cognitivă se ocupă de aspectele mentale și psihice ale ergonomiei interfe țelor , nu
de elementele fizice cum este în cazul ergonomiei clasice. Modelul mental indus de o interfa ță poate
diferi de la utilizator la utilizator pentru aceea și interfa ță.
Ergonomia cognitivă e strâns legată de modelul utilizatorului ( modelul procesorului uman ),
profilele cognitive și starea de flux.

Modelul utilizatorului – interfa ța trebuie să preia opțiunile /scopurile/ convingerile
utilizatorului și să le reprezinte prin acest model pentru a fi adaptabilă . În acest scop trebuie studiată
psihologia umană și semiotica ( știința semnelor).
Interfa ța utilizator poate fi descrisă prin utilizarea unor modele conceptuale . Pentru a realiza
un model conceptual al sistemului se utilizează diferite metode de modelare. Modelul conceptual
poate fi abordat d in trei persp ective: lingvistică , psihologică și a proiectării .
Modelele cognitive (perspectiva psihologică ) sau arhitecturile cognitive sunt modele ale
utilizatorilor dezvoltate în special de psihologii cognitivi ști pentru a descrie procesele pe care le
folosesc oame nii pentru a rezolva anumite sarcini, cum sunt rezolvarea de probleme sau utilizarea
unui sistem complex.

ANCA – VIRGINA P ÎRVAN

10
3. Tehnologii folosite
3.1 Sistemul de operare Android. Tehnologiile Android folosite
Pentru dezvoltarea aplicației am ales sistemul de operare An droid, în defavoarea celorlalte
tehnologii de pe piață ca Windows Mobile sau iPhone, mai ales datorită faptului că este cea mai
răspândită tehnologie pe dispozitivele mobile act uale, fiind totodată o platformă open -source.
Android este în prezent cel mai popular sistem de operare dintre cele dedicate dispozitivelor
portabile. A fost construit în jurul unui nucleu Linux, la fel ca și Chrome OS sau MAC OS, de către o
companie anonimă Android Inc. Și achizi ționat de Google în anul 2005. În anul 2007, s-a înfiin țat
consor țiul comercial Open Handset Alliance pentru a stimula evolu ția în dome niul dispozitivelor
portabile; în acela și an a fost anun țat sistemul de operare Android. La sfârșitul anului 2008, a apărut
pe piață primul terminal cu Android 1.0, HTC Dream , care oferea printre facilită ți : Wi-Fi, integrarea
serviciilor Google, Android Market (foarte diferit de varianta actuală ). O dată cu apari ția versiunii
Android 1.1 a fost rezolvat un număr foarte mare de probleme descoperite la versiune a anter ioară ,
piața Android fiind în continuă expansiune de atunci. În prezent , Android a ajuns la versiunea 4.0. –
cea mai modernă versiune, apărută pe piață o dată cu telefoanele Galaxy Nexu s. Ultima versiune de
Android aduce cea mai mare varietate de schimbări în cadrul platformei. Printre schimbările majore
se numără : butoanele virt uale, suport pentru widget -uri îmbună tățit, un font nou pentru
reprezentarea caracterelor, și nu în ultimul rând recunoa șterea facială .[6]

Figura 1: Evolu ția pe piață a sistemului de operare Android ( grafic realizat folosind date de la [6])

Smart Presentation Feedback –Interfața cu utilizatorul

11 Linux oferă abstractizare a hardware -ului pentru Android, permi țând să fie portat pe o mare
varietate de platforme. Pe plan intern, Android folose ște Linux pentru gestionarea memoriei,
managementul proceselor, servicii de rețea și alte servicii ale sistemului de operare.
Următorul nivel din arhitectura Android, conține bibliotecile native. Aceste biblioteci
partajate sunt scrise în C și C++, compilate pentru arhitectura hardware folosi tă de telefoane și
preinstalate pe telefon. Câteva dintre cele mai importante biblioteci Android sunt: Surface Manager,
Grafica 2D și 3D, baza de date SQL, Browser -ul.
Diagrama din Figura 2 prezintă componentele majore al e arhitecturii sistemului de operare
Android:

Figura 2 : Arhitectura sistemului de operare Android [7]

O parte semnificativă a kernel -ului o reprezintă Android Runtime, care include mașina
virtuală Dalvik și bibliotecile de bază Java. Android Runtime trebuie să aibă următoarele facilități :
viteza limitată a procesorului, memorie RAM limitată , baterie puternică , să nu aibă spațiu de swap și
să dețină un set divers de dispozitive. Având în vedere toate aceste cerin țe, o mașină virtuală a părut
a fi o alegere potrivită .

ANCA – VIRGINA P ÎRVAN

12

Dalvik este mașina virtuală (VM) din sistemul de operare Android. Este software -ul care
rulează aplica țiile pe dispozitive Android. Dalvik este parte integrantă a Android, care este de obicei
folosit pe dispozitive mobile cum ar fi telefoanele mobile și tablete le. Programele sunt de obicei
scrise în Java și compilate într-o mașină de instruc țiuni independente numite bytecode s. Acestea sunt
apoi convertite din fișiere .class sau .jar compatibile Java Virtual Machine în fișiere .dex (Dalvik
Executable) compatibile Dalvik , înainte de a fi instalate pe dispoz itive. Fișierele .class sunt citite de
JVM la runtime. Fișierele .dex sunt mai compacte și mai eficiente decât fișierele .class , un aspect
important pentru limitarea de memorie și baterie a dispozitivelor mobile. Un fișier .class conține o
singură clasă , pe când un fișier .dex poate conține mai multe clase. Formatul Dalvik Executabil este
special conceput pentru sisteme care sunt limitate în termeni de memorie și viteză a procesorului. [8]

Diagrama din Figura 3 prezintă asemănările și deosebirile între fișierele .class și fișierele
.dex care sunt executate de mașina virtuală Dalvik.

Figura 3 : Comparație intre fișierele . class și fișierele . dex [8]

Smart Presentation Feedback –Interfața cu utilizatorul

13
O altă diferen ță dintre Dalvik și mașinile tradi ționale de Java sunt bibliotecile de bază Java
care vin cu Android. Acestea sunt diferite de bibliotecile Java Standard Edition și Java Mobile Edition.

Dalvik este un software open -source. Este în esen ță o mașina virtuală Java optimizată pentru
consum redus de memorie. Permite rularea mai multor instan țe ale aceleia și mașini la un moment
dat și are avantajul de securitate al sistemului de operare Linux. Spre deosebire de mașinile virtuale
Java care sunt mașini stivă , Dalvik es te o arhitectură bazată pe regiș tri. Pentru a converti anumite
clase Java în format .dex este folosit un instrument numit DX. Java bytecode este de asemenea
convertit în seturi alternative de instruc țiuni utilizate de Dalvik VM.

Un fișier necompr imat .dex este de obicei mai mic decât un fișier comprimat . jar (Java
Archive) derivate din aceea și clasă . Fișierele executabile Dalvik pot fi modificate după ce au fost
instalate pe dispozitivele mobile.

Standardul Java byteco de execută instrucțiuni de stivă pe 8 biți. Variabilele locale trebuie să
fie copiate în sau din stivă de instrucțiuni separate. Dalvik folosește în schimb propriul set de
instrucțiuni pe 16 -biți, care acționeaz ă în mod direct asupra vari abilelor locale. Acest lucru reduce
numărul d e instruc țiuni și măre ște viteza .

Fiecare aplicație Android rulează propriul proces cu propria instan ța a unei mașini virtuale
Dalv ik. Dalvik a fost scris, astfel că un dispozitiv poate rula mai multe instan țe ale unei mașini virtuale
eficient . VM Dalvik se bazează pe kernel -ul Linux pentru funcționalitatea de bază, cum ar fi
gestionarea memoriei la nivel scăzut.

Android permite programatorilor să dezvolte aplica ții scrise în limbajul de programare Java,
folosind bibliotecile puse la dispozi ție de SDK (Software Development Kit) . SDK-ul Android cuprinde
un set de instrumente de dezvoltare p rintre care și un emulator de dispozitiv, biblioteci,
documenta ție, program de depanare, etc.
Mediul de dezvoltare (IDE) suportat oficial este Eclipse, utilizând plug-in-ul Android
Development Tools (ADT) . Plug -in-ul ADT este proiectat pentru a oferi dezvoltatorilor Android un
mediu puternic, integrat în care să creeze aplica ții mai ușor. ADT extinde facilită țile Eclipse și permite
configurarea rapidă a proiectelor no i în Android, crearea mai ușoar ă a aplica țiilor UI, editarea facilă a
fișierelor XML, depanarea aplica țiilor într-un mediu grafic.
O aplicație Android poate avea în componenta să oricâte surse . java și fișiere .xml . Câteva
dintre ele, însă, sunt predefinite. Orice aplicație Android are în componența sa fișierul Android
Manifest . Acesta este un fișier de tip .xml , care conține informa ții despre proiect: iconi ța proiectului,
numele autorului ; tot aici se pot specifica versiunea și numele pachetului. Simbolul @ din fața
anumitor atribute arătă că șirul care urmează este o referin ță la o resursă . Resursele se află în
folderu l res al proiectului. Folderul values (subfolder al folderului res) poate stoca diferite

ANCA – VIRGINA P ÎRVAN

14
tipuri de resurse printre care numere, culori, string -uri. Fișierul strings.xml este creat automat în
acest folder și conține mesajul și numele aplicației care apar atunci când este rulat proiectul.

Programarea pe Android forțează dezvoltatorii să separe funcționalitățile unui proiect de
partea de interfață, pentru ca operațiile să nu blocheze interfața. De aceea operațiile de background
trebuie să ruleze în thread -uri separate. Cea mai bun ă metodă de a face această separare în cadrul
unui proiect Android este pattern -ul Model View Controller.
Model – View – Controller este o metodă de proiec tare pentru software care separă
reprez entarea informa țiilor de interfa ța cu utilizatorul . Modelul cuprinde datele ( informa țiile) și
regulile d e afaceri, controller -ul asigură comunica ția între model și view. View -ul conține elemente
din interfa ța cu utilizatorul ( texte, input -uri ale formularelor) sau date de ieșire ( diagrame). MVC
define ște foarte bine intera cțiunea dintre cele trei componente ale sale astfel : [9]
 Controller -ul prime ște date le introduse de utilizator și inițiază un răspuns prin efectuarea
apelurilor pe diferite obiecte model. Controller -ul poate trimite comenzi view -ului care îi este
asociat pentru a schimba modul în care este reprezentat modelul de către view) și comenzi
către model pentru a -și actualiza starea.

 Modelul anun ță view -urile (perspectivele) și controller -ele care îi sunt asociate în momentul
în care apar schimbări în starea sa pentru ca acestea să poată reac ționa . Modelul este cel
care gestionează comportamentul și datele aplica ției, răspunde la cereri de informa ții despre
starea acesteia și răspunde la instruc țiuni pentru a schimba starea. Mode lul trebuie
implementat astfel î ncât să poată fi folosit fă ră a fi modificat pentru diferite interfe țe.
 View -ul folose ște informa țiile primite de la model pentru a genera o reprezentare a ieșirii, de
obicei o interfa ță pentru utilizator. Pot exista mai multe view -uri și contro llere pentru un
singur model, având scopuri diferite.
View -ul și modelul interac ționeaz ă numai cu controller -ul, niciodată nu interac ționeaz ă între
ele.

Smart Presentation Feedback –Interfața cu utilizatorul

15
Figura 4 : Model – View – Controller (inspirată de la [ 10])
În arhitectura Android , pattern -ul MVC este reprezentat astfel:
 Modelele ide ntificate prin Content Providers .
Content Providers este o clasă publică , abstractă din Android care gestionează accesul la un
anumit set de date și oferă mecani sme pentru securitatea datelor. Este interfața standard
care conectează datele dintr-un proces care rulează cu datele din cadru l altui proce s. Content
Providers sunt un fel “manageri de date” și este recomandat să fie folosiți în schimbul de
date între aplicații . Sunt folosiți decât dacă este nevoie de schimb de date între mai multe
aplicații .

 View -urile sunt Activitățile (Activity)
Activity este principala componentă a interfe ței cu utilizatorul , este derivată din clasa publică
Java Activity (android.app.Activity ) și este container pentru View
(android.view.View ). Activity interac ționeaz ă cu utilizatorul și creează o fereastră în
care se poate plasa UI (User Interface) folosind metoda setContentView(View) . În
timp ce activitățile de multe ori sunt prezentate utilizat orului ca ferestre full -screen, ele pot fi
folosite și în alte moduri: ca ferestre plutitoare ( într-o temă cu un windowIsFloating
setat) sau î ncorporate în interiorul unei alte activități (folosind ActivityGroup).

ANCA – VIRGINA P ÎRVAN

16
 Controler -ele sunt reprezentate de Servicii (Services)
Servici ile sunt componente de bază care se comportă că daemoni i UNIX și serviciile Windows.
Ele rulează în fundal și efectuează prelucrarea pe parcursul aplica ției.
Un serviciu este o componentă care reprezintă o cerere a aplica ției de a efectua o operațiune
de mai lungă durată în timp ce nu interac ționeaz ă cu utilizatorul sau de a furniza
func ționalit ăți pentru alte aplica ții. Fiecare clasă de servicii trebuie să aibă o declarație
corespunzătoare <service> în fișierul AndroidManifest.xml din pachetul său. Serviciile
pot fi pornite cu Context.startSe rvice() și Context.bindService (). [9]

3.2 Tehnologiile folosite pentru comunicația client -server. Alte tehnologii

Pentru serializarea/deserializarea diferitelor tipuri de mesaje de pe server ( cel mai simplu tip
de mesaj cuprinde o întrebare sub forma unui string și o selecție, tot sub forma string) este
folosită în cadrul proiectului tehn ologia Google Protocol Buffers. Un alt motiv pentru care am ales
această tehnologie es te consumul foarte mic de bandă.
Google Protocol Buffers este un Framework independent de platformă , un limbaj neutru,
pentru serializare a/deserializarea datelor binare pentru a fi utilizate în protocoale de comunicație, de
stocare a datelor, etc.
Protocol Buffers sunt flexibile, eficiente, mecanisme automate pentru s erializarea datelor
structurate, ca un XML, dar mai rapide și mai simple. Cu ajutorul lor, se poate defini modul în care vor
fi structurate datele o singură dată , apoi codul sursă gener at special poate fi folosit pentru a scrie și
citi datele de la o varietate de fluxuri și folosind o varietate de limbaje . [11]
Structurile de date ( numite mesaje) și serviciile sunt definite în fișierele Proto Definition
(.proto ) care sunt compilate cu protoc . Fiecare mesaj este o înregistrare logică de informa ții,
conținând o serie de perechi nume -valoare. [11]
În secvența de cod 1 este un exemplu de astfel de mesaj (fișier .proto) :

message Persoana {
required string nu me = 1;
required int32 id = 2;
optional string email = 3;
enum Telefon {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message NumarTelefon {

Smart Presentation Feedback –Interfața cu utilizatorul

17 required string numar = 1;
optional PhoneType tip = 2 [default = HOME] ;
}
Repeated NumarTelefon telefon = 4;
}

Secvența de cod 1: Exemplu de mesaj Protocol Buffers

Comp ilatorul Protocol Buffers creează o clasă care implementează codificarea automată și
parsarea datelor într-un format binar. Clasa generată oferă metode Getter și Setter pentru câmpurile
din interiorul unui Protocol buffer. Formatul Protocol Buffers suportă extinderea în timp, dar codul va
fi compatibil și cu formatele anterioare.
Pentru a folosi Protocol Buffers în primul rând trebuie dezvoltat un serviciu Web care
converte ște datele CSV în format Protocol Buffers, apoi trebuie construită o aplica ție Android care ia
date de la serviciul Web în acest format (Protocol Buffers) și le analizează pentru a fi afișate
utilizatorului.
Serverul folosit și implementat în acest proiect este un serve r Java care folosește un serviciu
web RESTful. Am ales tehnologia REST pentru că este standardizată (operațiile HTTP sunt bine
înțelese și funcționează în mod consecvent), este ușor de testat, este lizibilă, nu este nevoie de f ișiere
.xml
Representationa l state transfer (REST ) este o arhitectură software pentru sisteme
distrib uite, un exemplu de propor ții fiind World Wide Web. A fost dezvoltat în paralel cu HTTP/ 1.1,
fiind bazat pe desi gn-ul deja existent al HTTP/1.0 și exemplifică modul în care interac ționeaz ă cele
patru componente ale Web -ului : Proxy -uri, servere, gateway și clien ți fără a impune limitări asupra
participan ților individuali. În ultimii ani, REST a devenit un model de design/proiectare predominant
în lumea serviciilor Web , înloc uind modele ca SOAP și WSDL, datorită stilului să u simplu. [12]
REST este o abordare pentru a obține informa ții de pe un site web, folosind fișiere XML
pentru a include conținutul dorit. Datorită simplită ții sale, REST a devenit o modalitate populară
printre dezvoltatori de a accesa serviciile.
În arhitectura REST, informa ția de pe server este considerată o resursă pe care dezvoltatorii o
pot accesa folosind HTTP (Hypertext Transfer Protocol) și URI (Uniform Resource Identifiers).
Deoarece REST utilizează HTTP ca protocol de comunica ție este constrâns să fie o arhitectură de tip
client -server. Clien ții inițiază cereri către servere, serverele procesează cererile și dau răspunsuri
adecvate. Cererile și răspunsurile sunt construite pe baza reprezentărilor resurselor. O resursă poate
fi orice concept care poate fi abordat. Reprezentarea unei resurse este de obicei un document care
surprinde starea actuală sau dorită a unei resurse. Clientul începe trimiterea de cereri când este
pregătit pentr u a face tranzi ția la o nouă stare. REST facilitează tranzacția dintre servere de web,

ANCA – VIRGINA P ÎRVAN

18
permițând cuplarea între diferite servicii. Limbajul REST se bazează pe utilizarea de substantive și
verbe și pune accent pe lizibilitate. [12]
Serviciile web RESTful (serviciile web care sunt create și accesate prin utilizarea principiilor
REST) folosesc protocolul HTTP pentru opera țiile pe care le efectuează .
JAX-RS oferă un API pentru crearea serviciilor web RESTful în Java. API -ul JAX -RS folose ște
adnotări pentru a simplifica dezvoltarea serviciilor web RESTful. Adnotările , împreună cu clasele și
interfe țele oferite de API -ul JAX -RS permit reprezentarea resurselor web ca POJO ( Plain Old Java
Object ). [13]
Ca în orice altă aplica ție web Java , aplica țiile JAX-RS sunt grupate ca un fișier WAR și
implementate apoi pe cu un container care suportă Servlets. (exemplu server Tomcat , server
Glassfish). Servlets -urile oferite de container pot fi utilizate pentru a ruta cererile către cea mai
apropiată resursă web . Un obiectiv al JAX -RS este acela de a permite portabilitatea pentru a
implementa resurse web în diferite tipuri de containere.
Sun oferă o implementare de referință pent ru JAX -RS numită Jersey .

Am ales să folosim o implementare a JAX -RS (Jersey) pentru că este extensibil, permite
adăugarea de noi funcționalități ușor și folosește protocolul Google Procol Buffers. Ambele sunt
proiectate pentru sisteme de înaltă performanță și pentru a reduce CPU utilizat în timpul serializăr ii și
deserializării datelor.
Jersey folosește un s erver de web HTTP numit Grizzly și servlet -ul Grizzly . Servlet -ul
gestionează cererile către Grizzly. Pot fi dezvoltate aplica ții JAX-RS folosind Jersey care
implementează toate API -urile și oferă adnotările necesare pentru crearea serviciilor web RESTful.
Prin intermediul API -urilor proprii, Jersey oferă func ții suplimentare, cum ar fi AP-ul pentru clientul
Jersey. [14]

Clasele și interfe țele care pot fi folosite pentru a crea servicii web RESTful cu JAX -RS se
găsesc în următoarele pachete: javax.ws.rs, javax.ws.core, javax.ws.rs.ext. JAX-RS define ște o resursă
ca pe orice clasa Java (POJO) care folose ște adnotări JAX-RS pentru a implementa resursa web.
Nota ția @Path identifică o clasă Java ca pe o clasă de resurse. Exemplu l din Secvența de cod 2 este o
clasă Java :

import javax.ws.rs.Path;
@Path(“/stockquote”)
public class StockResource {
…
public String getStockInfo() {
return “This îs Stock Information”;
}
}

Secvența de cod 2: Clasa Java care folosește Jersey

Smart Presentation Feedback –Interfața cu utilizatorul

19
Pentru fiecare cerere făcută la o resursă va fi creată o nouă instan ță a clase i de resurse. După
crearea obiectului, este invocat constructorul, iar când este primit răspunsul obiectul d evine
disponibil pentru garbage collection. Metodele resursei sunt metode publice ale clasei de resurse
care pot fi recunoscute printr -un identificator al metodei. Identificatorii metodelor sunt adnotări
folosite pentru a recunoa ște metodele HTTP și JAX-RS. JAX-RS define ște adnotări pentru metode
HTTP ca GET, PUT, POST, DELETE și HEAD și permite definirea de identificatori personaliza ți în func ție
de metoda.
JAX-RS oferă o mapare clară între protocolul HTTP și URI, având interfe țe și clase bine
definite.
În serviciile web RESTful, metodele HTTP sunt mapate cu opera țiile CRUD pe care le
efectuează . În func ție de tipul cererii HTTP efectuate sunt apela ți identificatorii metodei. Ex: pentru e
cerere HTTP GET, serviciul va apela o metodă @GET și va aștepta răspu ns. O metodă a resursei poate
întoarce o valoare void, un obiect sau un alt tip Java.

Pentru a construi URL -ul la care se găse ște un PDF pe server și pentru a face cache la
întrebările de pe server folosim SQLite .

SQLite este un sistem open -source de gestiune de baze de date relaționale , conținut într-o
bibliotecă de C. Este portabil, ușor de utilizat, compact și eficient. Este o bază de date incorporata în
aplica ția pe care o serve ște, se comportă ca o parte a programului pe care îl găzduie ște. Avant ajul de
a avea un server de baze de date în interiorul programului este acela că nu mai este necesară nicio
configurare de rețea. Clientul și serverul rulează acela și proces . [15]

SQLite are o arhitectură modula rizata, modulele de bază fiind interfa ța, compilatorul și
mașina virtuală . Interfa ța este API -ul C SQLi te, este modalitatea prin care programele și limbajele de
scripting interac ționeaz ă cu SQLLite.

Procesul de compilare începe cu Tokenizerul și parserul care lucrează împreună pentru a
valida sin taxa și pentru a o converti într-o structură cu care se poate lucra mai ușor. Parserul este
generat de generatorul de parsere al SQLite numit Lemon.

Mașina virtuală , numită și motorul de bază de date virtual (VDBE) func ționeaz ă pe cod octet ,
ca o mașina virtuală Java. Este concepută pentru prelucrarea datelor , fiecare instruc țiune realizând o
opera ție specifică . Orice declara ție scrisă în SQLite este mai întâi compilată în această mașina virtuală .

SQLite este disponib il pe orice dispozitiv Android, fără să aibă nevoie de configurare sau
administrare. Este gestionat automat de platforma Android. Pentru accesul la baza de date SQLite se
accesează sistemul de fișiere . Este recomandat ca opera țiile pe bază de date să se efectueze asincron,
prin intermediul u nei clase AsyncTask .
Asynctask este o clasă abstractă Android care permite folosirea corectă și ușoară a thread -ului UI,
rularea operațiilor în fundal și afișarea lor în thread -ul UI.

ANCA – VIRGINA P ÎRVAN

20
O sarcină asincronă este definită printr -un calcul care rulează pe un thread din fundal, ale cărui
rezultate sunt afișate pe thread -ul UI. Are trei tipuri generice: Params, Progress și Result.

O bază de date SQLite este privată pentru aplicațiile pe care le creează . Pentru a partaja date
cu alte aplica ții se poate f olosi un ContentProvider .
ContentProvider poate fi folosit intern pentru a accesa date. Accesul la ContentProvider se face
printr -un URI. URI este definit la declara ția ContentProvider, în fișierul AndroidManifest. xml folosind
atributul android: authorities. De obicei, clasele care implementează ContentProviders oferă
constant e publice pentru URI. ContentProvider poate fi definit în AndroidManifest.xml sau folosind o
clasă care extinde android.content.ContentProvide r.

Pentru vizualizarea fișierelor PDF pe dispozitivele mobile am folosit software -ul open -source
MuPDF. Acestui proiect i -am adăugat noi funcționalități pentru a îndeplini cerințele aplicației noastre.

MuPDF este un software gratuit, scris în C, care implementează parsarea și randarea
fișierelor PDF și XPS. Randarea paginilor se face cu o precizie de fracțiuni de pixel pentru a reproduce
perfect aspectul unei pagini pe ecran. [16]
Este folosit în primul rând pentru a converti paginile unui doc ument în bitmap -uri, dar oferă
suport și pentru alte opera ții cum ar fi căutarea în document și listarea conținutului , criptarea,
transparența , adnotări și hyperlink -uri.
Este o aplica ție care permite vizualizare a fișierelor de tip PDF , XPS sau OpenXPS . Dezvoltatorii
au pus accentul, în dezvoltarea aplica ției, pe viteza, cod de dimensiuni reduse și randare de înaltă
calitat e. Nu suportă func ții interactive , JavaScript și tranzi ții. Este scris modu lar, astfel încât
programatorii care îl folosesc să poată adăuga noi func ționalit ăți.
Librăria vine cu un set de instrumente în linia de comandă : pentru randarea unui pdf
(pdfdraw), pentru examinarea structurii fișierului (pdfshow) și pentru rescrierea fișierelor (pdfclean).
MuPDF este disponibil ca pachet gratuit și pentru Debian, Fedora, porturi FreeBSD. A fost
portat pe multe platform e printre care Android, Amazon Kindle.
Proiectul pentru portarea MuPDF în sistemul de operare Android include librăria mudpdf, o
interfa ța mup df jni pentru Android și aplica ția Android pdfViewer (.apk).

Smart Presentation Feedback –Interfața cu utilizatorul

21 4. Arhitectura sistemului
4.1 Descrierea arhitecturii și a func ționalit ății proiectului

Figura 5 : Arhitectura proiectului

Pentru a implementa aplicația prezentată conceptual este necesară implementarea a două
componente majore : modulul Client și modulul Server.
Modulul Client se ocupă atat de partea de interacțiune cu utilizatorul: interfața
prezentatorului ș i interfața audienței , cât ș i de partea de comunicare cu serverul: trimit e diverse
tipuri de cereri HTTP asincrone la server ( pentru a primi date legate de utilizatorii din baza de date –

ANCA – VIRGINA P ÎRVAN

22
SQLite, pentru a primi lista întrebărilor de pe un anumit slide/ din toată prezentarea, pentru a
primi numărul de +1, ambiguous sau citation o r proof needed de pe un anumit slide ).
Modulul Server se ocupă de partea de clusterizare a întrebărilor primite de la auditoriu,
gruparea lor în funcție de asemănăr ile semantice, trimite rea întrebărilor că tre client, contorizarea
feed back -ul de fiecare tip , primirea cereri lor de la client .
Fiecare din aceste două module este împărțit la rândul sau în module mai mici, pe care le voi
descrie în continuare.
4.2. Modulele funcționale ale sistemulu i

Modulul Client este format din:
 Modulul View este reprezentat în aplicație de activitățile implementate (Activity). Acest
modul este principala componentă a interfeței cu utilizatorul. În cadrul lui sunt implementate
funcționalități ca: selecția din PDF, funcționalitățile butoanelor interfețelor, sliding-ul
paginilor.
 Modulul Controller comunică cu modulele View, Model și cu modulul de taskuri asincrone și
cereri HTTP. Acest modul primește cererile de la utilizator și le trimite modulul ui de cereri
HTTP pentru a fi procesate și trimise la server. Pe de altă parte, trimite cereri la
ContentProvider, care la rândul lui trimite cererea la server. Acest modul cuprinde toate
acțiunile care au loc la activarea interfeței, este un fel de “handler de evenimente" .
 Modulul Model este reprezentat de Content Provider și de baza de date SQLite. Se ocupă cu
stocarea și securitatea datelor , conține reprezentările datelor de intrare , ale datelor
intermediare și ale datelor de ieșire . Poate primi cereri de la controller pentru a interoga baza
de date, returnează la cerere date din baza de date. Dacă este nevoie, actualizează baza de
date cu cereri de la serverul web. Acest modul este independent de interfața cu utilizatorul,
lucru deosebit de important deoarece dacă se dorește schimbarea imple mentării prin
adăugarea de noi funcționalități , nu este necesară efectuarea de schimbări în modulul view.
 Modulul de t askuri asincrone și cereri HTTP primește cereri asincrone de la Controller și
Model pe care le trimite prin HTTP serverului Web . Acest mod ul este format din clase de tip
AsyncTask care rulează pe threaduri separate și sunt instanțiate in Controller atunci când sunt
apăsate butoanele . După ce se execută cererile HTTP, clasele modului actualizează interfața .

Smart Presentation Feedback –Interfața cu utilizatorul

23 Modulul Server este format din:
 Modulul Resursa Web comunică cu modulul de clustering și cu modulul Memory Store. În
acest modul sunt clase care definesc metode HTTP ( GET, POST, PUT, DELETE) care sunt
folosite in cererile HTTP.
 Modulul de clustering comunică cu modulul de resurse web și cu cel de memorie. În acest
modul are loc clusterizarea întrebărilor în funcție de asemănările semantice dintre acestea și
realizarea unui arbore cu acestea. Acest arbore este trimis apoi modulu lui Resursa Web prin
metodele PUT, POST.
 Modulul Memory Store este o clasă cu membri și metode statice unde scriu /citesc date toate
modulele serverului. Primește date de la modulul Resursa Web și de la mo dulul de clustering
și cuprinde toate structurile de date.

4.3. Arhitectura clientului Android

Figura 6: Structura clasei MuPDFActivity

ANCA – VIRGINA P ÎRVAN

24
Clientul Android are o clasă – MuPDFActivity care este strâns legată de implementarea
interfeței . Această clasă este împărțită în două module care comunică între ele.
Modulul principal – MuPDFActivity cuprinde numele și valorile variabilelor, implementările metodelor
pentru vizualizarea butoanelor și a listelor agregate cu întrebări .
În modulul MyButtonHandler sunt declarate toate butoanele celor două interfețe și implementate
metodele pentru click pe buton. Metodele a cestui modul apelează metode din modulul
MuPDFActivity.

Figura 7 : Structura clasei Multiline Adapter
Pentru a implementa facilitatea de a vizualiza întrebările de dimensiuni mari pe mai multe
rânduri am creat o nouă clasă MultilineAdapter c are extinde clasa ArrayAdapter. Schema acestei
clase este descrisă în Figura 7. Clasa Multiline Adapter are două module care comunică între ele. In
modulul principal al acestei clase est e suprascrisă metoda getView() a clasei ArrayAdapter . Această
metodă întoarce un obiect de tip View care este trimis modului MultilineView.

Smart Presentation Feedback –Interfața cu utilizatorul

25 5. Detalii de implementare
5.1 Implementarea interfețelor de utilizare ale clientului Android
5.1.1 Interfața clientului participant la prezentare
La deschiderea aplica ției, clientul participant la prezentare trebuie să se autentifice folosind
un nume. După autentificare, slide -urile se vor descărca automat de pe server pe telefonul său și se
vor sincroniza cu prezentatorul. Clientul intră astfel în view -ul principal al aplica ției pe care îl descriu
în continuare. Acest view are o suprafață mare dedicată prezentării, dar și o zonă dedicată
butoanelor cu ajutorul cărora participantul va putea face adnotări pe parcurs.

Butonul Go live sincronizează prezentarea de pe telefonul p articipantului cu prezentare a
de pe telefonul speaker -ului atunci când participantul apăsă pe el. În spatele acestei acțiuni , se
trimite o cerere la server web prin metodele GET sau POST .

Butonul de selec ție activează sau dezactivează posibilitatea utilizatorului de a selecta text din
PDF. După ce a făcut o selec ție, utilizatorul poate da feedback pe acea selec ție. Ca modalită ți prin
care se poate exprima feedback -ul sunt:
 Butonu l +1 folosit pentru feedback pozitiv sau pentru a susține o întrebare pe care a adresat –
o un coleg mai devreme
 Butonul ambiguous/unclear folosit atunci când utilizatorul nu înțelege o anumită
formulare și ar vrea să primească o explicație mai concisă
 Butonul citation or proof needed folosit atunci când utilizatorul are nevoie de o
demonstra ție concretă a celor scrise pe slide

Butonul Feedback este o listă agregată cu întrebările care au fost puse pe fiecare slide ( lista
de tip Alert dialog din Android) pe care utilizatorul o poate vedea. În cazul în care 2 utilizatori
vor să pună aceea și întrebare , pot folosi butonul +1 pentru a nu scrie de două ori textul întrebării . Tot
în lista de feedback este și butonul prin care utilizatorul poate adăuga o întrebare nouă – Add new
question.

Întrebările sunt grupate după similaritate semantică , întrebările de acela și tip fiind într-o altă
listă. Între lista principală de feedback și listele cu întrebări similare se poate naviga. Toate butoanele
din interfață au asociate imagini sugestive.

În aplica țiile Android, interfa ța este construită folosind obiecte de tip View și ViewGroup .
Există mai multe tipuri de View și ViewGroup , fiecare dintre ele fiind un descendent al clasei
View .
Obiectele de tip View sunt unită țile de bază ale interfe ței cu utilizatorul pe platforma
Android. Clasa View este considerată baza pentru subclase care oferă obiecte UI implementate, cum

ANCA – VIRGINA P ÎRVAN

26
ar fi butoane și câmpuri de text. Clasa ViewGroup este clasa de bază pentru subclasele layouts
care oferă diferite tipuri de structură cum ar fi liniară , tabel, relativă .

Un obiect de tip View este o structură de date ale cărui proprietă ți stochează parametrii
layout -ului și conținutul pentru o anumită zonă , în general dreptunghiulară , a ecranului. Obiectul
View este de asemenea un punct de interac țiune între utilizator și receptor.

Pe platforma Android, pentru a defini interfa ța pentru o activitate (Activity) se folose ște o
ierarhie de View -uri și ViewGroup , de forma celei din Figura 8 :

Figura 8 : Ierarhie View [17]

Layout : cel mai întâlnit mod de a defini un layout și de a exprima ierarhia de View -uri este
folosind un fișier .XML . Fiecare element din .XML este un View sau un obiect ViewGroup. Layout -ul
este arhitectura pentru interfa ța cu utilizatorul dintr -o activitate (Activity).

Un layout poate fi declarat în 2 moduri:
 Declarând elemente UI într-un fișier .XML . Avantajul folosirii fișierelor XML este că ajută la o
mai bună separare a parții de prezentare a aplica ției, de partea de cod. Fiecare fișier XML
trebuie să aibă un singur element rădăcină , care trebuie să fie un obiect de tip View sau
View Group . După ce se define ște elementul rădăcină se pot adăuga elementele copil în
ierarhie pentru a defini layout -ul.
 Instanț iind elementele layout -ului la runtime. Aplica ția poate crea obiecte de tip View sau
ViewObject programatic.

Programatorul poate fi folosi oricare din aceste două metode sau pe amândouă în acela și timp
pentru a con strui interfa ța aplica ției sale.

Smart Presentation Feedback –Interfața cu utilizatorul

27
Layout -urile sunt de 4 tipuri: [18]
 FrameLayout este cel mai simplu tip de obiect layout. Este practic un spațiu gol pe ecran pe
care îl poți umple mai târziu cu un singur obiect – de exemplu , o poză . Toate elementele
copil ale Frame Layout sunt fixate în colțul stânga sus al ecranului și nu pot fi mutate.
Poate fi folosit pentru a afișa mai multe butoane/controale în acela și ecran.

 Linea rLayout are toate elementele copil aliniate într-o singură direc ție – vertical sau
orizontal, în func ție de cum a fost definit atributul orientare (proprietatea orientation ).
Toate elementele apar în listă unul după altul, astfel că o listă verticală va avea un singur
element pe rând , indiferent de cât de mare este și o listă orizontală va avea un rând . Se
respectă marginile între elemente.
Cele mai importante proprietă ți ale layout -ului linear sunt: orientation, fill
model, gravity, padding .
Orientation : această proprietate stabilește cum vor fi afișate elementele,
fie orizontal , stil rând sau vertical , gen coloană.
Fill model : widget -urile din interiorul unui LinearLayout au înălțime și lățime.
Aceste proprietăți pot avea trei valori:
 o valoare numerică în pixeli, dpi sau inchi . Valoarea default pentru fiecare din ele este
0.
 wrap_conten t – widget -ul ocupă un spațiu egal cu aria sa.
 fill_parent – widget -ul ocupă tot spațiul existent.
Gravity : inițial toate controalele sunt poziționate în part ea stângă -sus. Acest lucru
însă se poate modifica utilizând proprietatea layout_gravity .
Proprietatea padding determină spațiul între widget -uri padding_left ,
padding_top , padding_right , padding_buttom , padding .

 TableLayout : elementele sunt așezate pe linii și coloane. Nu se afișeaz ă linii de frontieră
pentru rânduri , coloane sau celule. Un TableLayout este alcătuit din mai multe
componente TableRow , iar la rândul său un TableRow poate conține una sau mai multe
celule. Fiecare celulă poate conține doar un singur View . Celulele unui rând pot fi formate
dintr -o varietate de obiecte View , cum ar fi ImageView sau TextView . Coloanele care
alcătuiesc structura tabelului sunt recunoscute de Android
Tabelul va avea la fel de multe coloane ca rândul cu cele mai multe celule. Un tabel poate
avea celule goale, dar celulele nu se pot întinde pe coloane, cum se întâmplă în HTML.

 RelativeLayout : acest tip de organizare presup une poziționarea elementelor grafice relativ
la un alt control sau chiar relativ la părinte (ținând cont de structura ierarhică a ecranului ).
Acest tip de așezare implică faptul că un copil de tip control, ce poate fi reprezentat
printr -un Button, TextView , EditText sau oricare alt tip de control, poate fi plasat
relativ la o altă componentă a interfeței grafice fie deasupra, dedesubt , în dreapta sau în
partea stângă a acesteia.
Copilul de tip control poate fi poziționat și față de contain er-ul părinte : sus, jos, la
dreapta sau la stânga. Această poziționare trebuie să respecte niște reguli stricte .

ANCA – VIRGINA P ÎRVAN

28

RelativeLayout asigură o organizare mai eficientă a componentelor interfeței grafice fără a fi
necesară utilizarea dimensiunii screen -ului sau a elementelor existente.

Butoanele sunt componentele de bază ale interfe ței utilizatorului, cu ajutorul lor acesta
poate efectua acțiunile precizate mai sus .

În SDK-ul de Android sunt două clase care pot fi folosite pentru a controla butoanele:
Button(android.widget.Button ) și ImageButton (android.widget.ImageButton ).
Diferen ța dintre cele două clase este mai mult vizuală , butoanele din clasa Button sunt, de obicei,
butoane cu text (ex: buto nul Save) , iar butoanele din clasa ImageButton sunt asociate cu imagini
(ex: butoane muzicale – play, s top).

Un buton este format din text și/sau imagine care comunică ce acțiune se va produce atunci
când utilizatorul îl atinge. Android suportă două tipuri dife rite de butoane: butoane de bază și
butoane fără margini. Ambele tipuri de butoane pot conține text și/sau imagini.

Butoanele de baz ă sunt butoane cu margini și fundal. Pot fi de două tipuri: mari și mici.
Butoanele implicite au dimensiunea fontului mai mare și sunt optimizate pentru afișare în afara
conținutului formularului. Butoanele mici sunt concepute pentru afișare alături de alte tipuri de
conținut , au un font mai mic.

Butoanele fără margini seamănă cu butoanele de bază , cu excep ția faptului că nu
au margini sau fundal. Pot fi folosite cu imagini și text, se integrează mai frumos cu alte tipuri de
conținut .
În proiect am folosit butoanele de baza.
Butoanele pot fi create în fișiere .XML , în interiorul unui layout sau în clasa activity a
proiectului ( activity .java ).
În func ție de tipul de buton pe care vreau să îl creez folosesc una din m etodele:
a) În cazul în care creez butoanele în fișiere .xml:

 Pentru butoane cu text , folosesc clasa Button:
<Button
android:id = “ @+id/buton”
android:layout_width = “wrap_content”
android: layout_height =”wrap_content”
android:text =”@string/text_buton”
.. />
 Pentru butoane cu imagine, folosesc clasa ImageButton:
<ImageButton
android:id = “ @+id/buton”
android: layout_width = “wrap_content”
android: layout_height = “wrap_content”
android: src = “@drawable/ buton_imagine ”
.. />

Smart Presentation Feedback –Interfața cu utilizatorul

29  Pentru butoane cu text și imagine, folosesc clasa Button cu atributul android:drawableLeft:
<Button
android:id = “ @+id/buton”
android:layout_width = “wrap_content”
android:layout_height =”wrap_content”
android_text = “@string/text_buton”
android:dr awableLeft = “@drawable/ buton_imagine ”
../>

În codul Java, referirea la un buton se face folosind findViewById(R.id.id_buton ).
Ex: myBtn = (Button) findViewById(R.id.buton);
Fișierul R se găse ște în interiorul folderului gen și nu poate fi modificat.

b) În cazul în care creez butoanele în fișierul Java :
Button butonSelectie = new Button(this);
butonSelectie.setText(“Select);

 Pentru a adă uga imagine pe un buton folosesc metoda:
setCompoundDrawablesWithIntrinsicBounds(int,int,int,int);
Exemplu utilizare:
butonSelectie.setCompoundDrawablesWithIntrinsicBounds(R.drawabl
e.nume_imagine, 0, 0, 0);

Func ționalit ățile butoanelor se realizează adău gând eveniment e pentru fiecare din ele si se
pot adăuga în fișierele .XML sau în codul Java .

1. Folosind fișierul .XML
– pentru a defini evenimentul click pe un buton, în fișierul .XML , se adăugă atributul
android:onClick elementului de tip <Button >. Valoarea pentru acest atribut trebuie să fie
numele unei metode apelate ca răspuns la evenimentul click. Metoda trebuie să fie implementată în
activity -ul corespunzător butonului.

<?xml version="1.0" encoding="utf -8"?>
<Button xmlns:android="http://schemas.android.com/apk/res/android"
android:id="@+id/butonSelectie"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@string/butonSelectie"
android:onClick="SelecteazaText" />

În Activity se implementează metoda SelecteazaText:
public void SelecteazaText(View view) {
// răspunsul la click
butonSelectie.setText("Acum poți selecta text");
}

ANCA – VIRGINA P ÎRVAN

30
2. Folosind fișierul activity Java care este în folderul src.

butonSelectie.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
butonSelectie.setText("Acum poți selectă text"); }
});

Butonul Feedback al interfe ței, este diferit de celelalte , el conține o listă agregată a
întrebărilor participan ților la prezentare. Pentru a realiza acest buton folosesc o succesiune de liste
de tip alert dialog și array adapter .

Un dialog este o fereastră care apare peste activitatea curentă . Activita tea de bază își
pierde proprietă țile și fereastra dialog acceptă toate interac țiunile cu utilizatorul. Dialogurile sunt
utilizate, de obicei, pentru notificările care ar t rebui să întrerupă utilizatorul pentru a efectua sarcini
scurte care se refera direct la aplica ția în curs (bara de progre s , solicitare de conectare) .

Clasa Dialog este clasa de bază pentru crearea de dialoguri. Un dialog nu p oate fi instanț iat
direct, trebuie folosită una din subclasele clasei Dialog : AlertDialog, ProgressDialog,
DatePickerDialog, TimePickerDialog.

Un dialog este creat și afișat ca parte a unei activităț i. Trebuie creat folosind metoda de
callback onCreateDialog(int) .Când este folosită această metodă , sistemul Android
gestionează starea fiecărui dialog și îl instanțiază . Dialogul moștenește anumite proprietăț i de la
activitate. Pentru a afișa un dialog, se apelează metoda showDialog(int) , prime ște ca
parametru o valoare întreagă care identifică în mod unic dialogul pe care vreau să îl afișez. Pentru a
închide un dialog se apelează func ția dismiss () pe obiectul de tip Dialog. Se poate apela și metoda
dismissDialog(int) din activitate, metoda care aplează la rândul ei metoda dismiss ().

Alert dialog sau fereastra de notificare poate fi creată în cadrul oricărei activități (Activity) și
asigură o mai bună comunicare între ușer și aplica ție. Aceasta poate gestiona zero, unu , două sau mai
multe butoane și/sau o listă de elemente selectabile care pot include casete cu text și radio buttons ,
mesaje text , titluri. Este o extensie a clasei Dialog.

Pentru a crea un alert dialog se folose ște subclasa AlertDialog.Builder . Se creează un
constructor folosind AlertDialog.Builder(Context ) și apoi se utilizează metodele publice
ale clasei pentru a defini toate proprietă țile Alert Dialog -ului. După ce au fos t scrise acțiunile
corespunzătoare Builder -ului, dialogul se creează folosind builder.create().

În exemplul din secventa de cod 3 , creez un dialog cu ajutorul căruia utilizatorul poate alege
dacă este speaker sau participant la prezentare. Alert Dialog -ul este format dintr -un mesaj și două
butoane .

Primul pas este adăugarea unui mesaj pentru Dialog folosind metoda
setMessage( CharSequence ), apoi se stabile ște dacă dialogul se poate închide cu butonul de

Smart Presentation Feedback –Interfața cu utilizatorul

31 back al te lefonului sau nu, folosind setCancelable (Boolean). Pentru fiecare buton se folose ște
una din metodele set (cum ar fi setPositiveButton()), care acceptă numele pentru bu ton și un
eveniment care defineș te ac țiunea care va avea loc pe buton
(DialogInterface.OnClickListener ). Într-un dialog, se poate adăuga un singur buton de
un anumit tip. Nu pot avea decât un buton positive button .

AlertDialog.Builder builder = new AlertDialog.Builder( this);
builder.setMessage("What are you?");
builder.setC ancelable( true);
builder.setPositiveButton("Speaker", new
DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int id) {
addSpeakerButtonsBar();
dialog.cancel();
}
});
builder.setNeutralButton("Ușer", new
DialogInterface.OnCl ickListener() {
public void onClick(DialogInterface dialog, int id) {
loginDialog();
}
});
AlertDialog alert = builder.create();
alert.show();

Secvența de cod 3: Alert Dialog

Figura 9 : Alert dialog

În aplica ție, folosesc AlertDialog și pentru a crea o listă cu întrebări , din care utilizatorul poate
selecta (secvenț a de cod 4).

Primul pas în creare a unui alert dialog de tip listă este adăugarea titlului folosind metoda
setTitle(CharSequence ). Apoi se adăugă lista de elemente selectabil e folosind metoda
setItems () care acceptă șiruri de elemente pentru a fi afișate și în final un listen er(
DialogInterface.OnClickListener) care define ște acțiunile care au loc atunci când utilizatorul
selectează un anumit element din listă .

ANCA – VIRGINA P ÎRVAN

32

final CharSequence[] items_list = {"Question1", "Question2",
"Question3","Question4"};
AlertDialog.Builder builder = new AlertDialog.Builder( this);
builder.setTitle("Questions");
builder.setItems(items_list, new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int item) {
Toast.makeText (MuPDFActivity. this, "item "+item+"
clicked", Toast. LENGTH_SHORT ).show();
}
});
Secvența de cod 4: Lista cu întrebări

Metoda exemplificată în secvența de cod 4 poat e fi folosită în cazul întrebărilor de dimensiuni
mici. În cazul în care utilizatorul adresează întrebări foarte lungi, metoda nu mai este utilă deoarece
întrebările vor fi afișate incomplet ( se va afișa doar prima parte a întrebării , urmată de puncte de
suspensie). De aceea, solu ția găsită de min e a fost extinderea func ționalit ății clasei Array Adapter.

Figura 10: Lista cu întrebări

Smart Presentation Feedback –Interfața cu utilizatorul

33 În Android, listele sunt im plementate folosind modelul MVC ( Model View Controller).
Modelul este reprezentat de datele ce trebuie afișate , View -ul este reprezentat de lista propriu -zisă,
Controller -ul este programul care controlează modul de afișare .
Un View de tip ListView poate fi implementat în orice tip de activitate (Activity). Android
pune la dispozi ție un tip special de activitate, n umit ListActivity . [19]

Lista de tip ListView prime ște datele prin intermediul unui adaptor. Deci p entru a
impl ementa o listă, trebuie scrisă componenta Adapto r a ei. Adaptorul define ște cum va arăta fiecare
rând din listă. Din punct de vedere al programării , acest lucru presupune crearea unui obiect care să
implementeze interfa ța ListAdapter . Una din modalită țile prin care se poate implementa ListAdapter
este ArrayAdapter.

Array Adapter (figura 11) este o clasă publică Android care poate fi folosită pentru a
implementa liste simple, ce conțin elemente cu o singură linie de text. Poate primi la intrare obiecte
Java de orice tip pe care le asociază unui View din layout. Acesta clasă presupune că toate elementele
sunt stocate într-un șir (ex: Ob ject[] ) sau o listă (orice obiect ce implementează interfa ța List<type>).
Pentru a folosi ArrayAdapter trebuie implementată metoda getView (), din clasa BaseAdapter .
Această metodă ajută la determinarea aspectului rândului și a felului cum sunt mapate datel e pe
View -uri în layout –ul curent . ArrayAdapter extinde clasa BaseAdapter. [19]

public View getView (int position, View convertView, ViewGroup list )
{
// func ția trebuie să întoarcă view -ul de pe poziția position din lista
// convertView este un element din lista ce nu mai este vizibil și poate fi convertit
}

Figura 11 : List adapter [19]

ANCA – VIRGINA P ÎRVAN

34

În exemplul din secvența de cod 5 este implementată metoda getView a clasei
MultilineAdapter care extinde Array Adapter , pentru a putea obține o listă cu întrebări pe mai multe
rânduri .

public class MultilineAdapter extends ArrayAdapter {
//variabile …
public MultilineAdapter (Activity activity, List objects) {…}
@Override
public View getView(int position, View convertView , ViewGroup
parent) {
View rowView = convertView;
MultilineView mView = null;
if(rowView == null){
LayoutInflater inflater = activity.getLayoutInflater();
rowView = inflater.inflate(R.layout.multiline_item,
null);
mView = new MultilineView();
mView.mq = (TextView) rowView.findViewById(R.id.mq);
rowView.setTag(mView);
} else { mView = (MultilineView) rowView.getTag(); }
Question question = (Question) questions.get(position);
mView.mq.setText(question.q);
return rowView; }}

Secventa de cod 5 : Implementarea metodei GetView

O implementare eficientă a ArrayAdapter presupune folosirea parametrului convertView ,
așa cum se întâmplă și în cazul meu. Acesta este fie null, caz în care trebuie ignorat, fie un obiect
întors anterior de către getView (), însă obiect care nu mai este vizibil. Ideea este că, în loc de a crea
un nou View de fiecare dată , să se refolosească View -urile create anterior și care nu mai sunt vizibile.
În exemplul din secvența de cod 5 , se folose ște și Layout Inflater pentru a parsa fișierul .xml.

Folosind Array Adapter și BaseAdapter se pot construi și liste mai complexe, care pot conține
și alte elemente ( ex: imagini).

În realizarea interfe ței clientului participant la prezentare, am folosit și obiecte de tip
EditText pentru câmpurile unde utilizatorul se autentifică și pentru câmpul unde adăugă o întrebare .

EditText este o clasă publică Android care extinde clasa TextView, afișeaz ă textul introdus de
utilizato r și permite editarea acestuia. Metodele setWidht(int pixels ), setHeight(int
pixels), setHint(CharSequence hint) sunt folosite pentru a seta dimensiunile ferestrei
de text.

Smart Presentation Feedback –Interfața cu utilizatorul

35 5.1.2 Interfața clientului prezentator
Prezentatorul , ca și utilizatorul, prime ște slide-urile de pe server atunci când deschide
aplicația . Acesta are un alt set de facilita ți, având o interfa ța mai simplă decâ t a clientului participant .

La final, speakerul prime ște feedback -ul agregat al prezentării . Acesta are două butoane de
feedback, unul din ele este o listă (de tip alert dialog cum este și în cazul participantului ) ce
contine feedback -ul pe toată prezentarea, iar celălalt buton este o lista cu feedback -ul pe fiecare
slide.

Atunci când participantul face o selec ție pe o porțiune de text , secțiunea selectată va avea o
anumită culoare , stabilită din aplicație . Speakerul va vedea în fereastra de feedback întrebările
colorate în func ție de zonă pe care a fost făcută selec ția. Exemplu: trei participanți au selectat trei
zone diferite dintr -un slide, selec țiile lor vor avea culori diferite și întrebările care vor apărea în lista
cu feedback a prezentatorului vor avea acelea și culori cu selec țiile făcute .

Și în cazul butoanelor +1, ambiguous/unclear și citation o r proof needed ,
culorile selec țiilor făcute de participant corespund cu cele ale butoanelor. Butoanele +1,
ambiguous/unclear și citation or proof needed nu mai au acelea și func ționalit ăți ca
în cazul participantului; în acest caz sunt folosite doar pentru a vedea spe akerul numărul de +1,
ambiguous/unclear și citation or proof needed care au fost marcate pe fiecare slide.

Din punct de vedere al implementării , având elemente de interfa ță asemănătoare cu
participantul la prezentare, am folosit, în general , acelea și clase și metode precizate și exemplificate
în subcapitolul precedent.

5.1.3 Folosirea MuPDF pentru vizualizarea PDF -urilor

MuPDF este un software open source care implementează randarea și parsarea fișierelor
PDF. În implementarea proiectului, am pornit de la varianta portată pentru Android a acestui
software care include librăria mudpdf, o interfa ță mupdf jni pentru Android și aplica ția Android
pdfViewer (.apk). Clasele proiectului Android la care am adăugat noi func ționalități sunt:
MuPDFActivity.java, MuPDFCore.java și PixmapView.java . Randarea efectivă a
pdf -ului, reprezentat print r-o imagine se face în cod nativ C.
Clasa MuPDFCore.java apelează funcții native Java pentru deschiderea unui fișier , obținerea
dimensiunilor unei pagini, desenarea efectivă a unei pagini. Fiecare pagină a unui document .pdf
este tratată ca o imagine (de tip bitmap ).
Clasa PixmapView.java extinde clasa Android SurfaceView și se ocupă de evenimentele și
acțiunile care au loc pe suprafața pdf -ului. Printre aces te evenimente sunt și cele care au loc atunci

ANCA – VIRGINA P ÎRVAN

36
când este atins ecranul. În această clasă , au fost adăugate , în cadrul proiectului, funcționalități pentru
a realiza selecția de text din document și pentru a simula trecerea pe o altă pagină în pdf .
Clasa MuPDFActivity.java este clasa în care am adăugat butoanele din interfața utilizatorului
și funcționalitățile lor
Comunicația dintre codul Android ce rulează în mașina virtuală de Android și aplicațiile native
(programe specifi ce de la o platformă hardware și sistemul de operare) sau biblioteca de C se fac prin
intermediul framework -ului Java Native Interface (JNI).
JNI permite scrierea unor metode native pentru a gestiona situațiile în care o aplicație nu
poate fi scrisă în totalitate în Java. Poate fi de asemenea folosit pentru a modifica o aplicație existentă
scrisă într-un alt program, pentru a fi accesibilă pentru aplicațiile Java. Folosind JNI, o metodă nativă
poate folosi obiecte Java în același mod în care le folosește și codul Java. Altfel spus, o metodă nativă
poate crea obiecte Java și le poate folosi pentru a îndeplini propriile sarcini. Poate, de asemenea,
folosi obiecte create în cod Java.

Figura 12: Rolul JNI [ 20]

Smart Presentation Feedback –Interfața cu utilizatorul

37 6. Utilizarea aplicației

Scenariul complet al aplicației : Anca se pregătește să susțină o prezentare în fața colegilor săi
de la cursul de IA. Înainte de a începe prezentarea pornește aplicația SmartPresentation de pe
telefonul mobil. Același lucru îl fac și colegii săi. Prezentar ea Ancăi este descărcată automat de pe
server pe dispozitivele mobile ale tuturor participanților . Pentru a vedea conținutul prezentării
utilizatorii trebuie să spună cine sunt (speaker sau utilizator din auditoriu) și să se autentifice folosind
un nume (f igura 13 ).

Figura 13 : Autentificare utilizator
După autentificare, utilizatorii pot vedea slide -urile prezentării și butoanele cu funcționalități
corespunzătoare tipului de utilizator ales. În figura 14 se pot vedea butoanele din cadrul celor două
tipuri de interfață , speaker și persoana din auditoriu.

Figura 14 : Butoane interfața speaker vs. Butoane interfața utilizator din sală

Andrei poate urmări prezentarea în propriul său ritm, alocând timpul pe care îl consideră
necesar fiecărui slide. Dacă vrea să vadă la ce slide a ajuns Anca poate apăsă butonul Go live.
Acest buton îl va poziționa pe slide -ul la care este în acel moment prezentatorul .

ANCA – VIRGINA P ÎRVAN

38
Bogdan are o întrebare în legătură cu un subiect ab ordat de Anca. Pentru a scrie întrebarea
trebuie să activeze întâi selecția , folosind butonul de selecție , apoi să adauge întrebarea în lista de
întrebări . Poate selecta o zonă de text sau o poză de pe slide. După ce urmează acești pași, observă că
Dragoș a pus deja o întrebare pe același slide, așa că folosește butonul +1 pentru a susține întrebarea
colegului său. În figura 15 este prezentat scenariul de selecție a unei imagini din pdf și adăugarea unei
întrebări noi:

Figura 15 : Scenariu selecție din document și adăugare întrebare
Butonul +1 poate fi folosit și individual de întrebări , pentru a da feedback pozitiv unei porțiuni
de text sau unei imagini.
Bogdan nu înțelege cum a fost aplicată o anumită formulă și vrea să îi ceară Ancăi o
demonstrație detaliată . Pentru aceasta poate f olosi butoanele ambigous și proof needed din
interfață .
Fiecare utilizator vede feedback -ul sub forma unei succesiuni de mai multe liste cu întrebări .
Lista principală conține întrebările cele mai generale adresate de auditoriu, întrebările rădăcină ale
arborelui de întrebări . Presupun că Bogdan a adresat întrebarea “Ce înseamnă E?”. În cazul în care
mai există și alte întrebări asemănătoare ca semantica cu întrebarea lui Bogdan, le va putea vedea

Smart Presentation Feedback –Interfața cu utilizatorul

39 prin simpla apăsare pe întrebarea sa din lista de fee dback. Astfel se va deschide o nouă listă care
poate cuprinde întrebările : “Ce înseamnă E în formula ta?”, “Care este rolul lui E în formula ta?”.
Același lucru este exemplificat în figura 1 6.

Figura 1 6: Liste de feedback
Orice utilizator poate șterge o întrebare proprie din listă și poate da +1 unei întrebări puse de
altcineva .
În cazul în care utilizatorul a selectat o zonă de text pe care a dat feedback ambigous sau
proof needed, a doua oară când apăsă butonul, aplicația consideră că este posibil să dorească să își
retragă feedback -ul. De aceea apare o fereastră în care este întrebat dacă vrea să renunțe la
feedback -ul ales anterior.
La finalul prezentării , Anca poate vedea feedback -ul agregat primit de la toate persoanele din
sală. Pentru a vizualiza întrebările adăugate pe parcursul prezentării , Anca are 2 butoane. Unul dintre
ele îi arată feedback -ul pentru toată prezentarea, iar celălalt feedback -ul pentru un singur slide.
Butoanele din interfața ei au grafica diferită de butoanele audienței , unele din ele fiind colorate. În
funcție de culoarea butonului din interfață , Anca vede feedback -ul primit. Astfel, pentru că butonul
+1 este galben, atunci când apăsă pe el va putea vedea toate selecțiile pe care s -a dat ca feedback +1

ANCA – VIRGINA P ÎRVAN

40
în culoa rea galben. La fel și în cazul butoanelor ambiguous și proof needed care sunt colorate. În
cazul întrebărilor , fiecare zonă selectată pe care au fost adăugate întrebări va avea o anumită culoare.
Atunci când apăsă butonul de F eeback, Anca vede textul întrebărilor în aceeași culoare cu zona
selectată de utilizator din text. În figura 17 este exemplificat feedback -ul din perspectiva
prezentatorului pentru butoanele +1, ambiguous și proof needed.

Figura 17 : Feedback din perspectiva prezentatorului

Smart Presentation Feedback –Interfața cu utilizatorul

41 7. Concluzii și dezvoltări ulterioare

Aplicația dezvoltată este destinată grupurilor de persoane care doresc să participe la o
prezentare în care să se poată implica și să poată interacționa cu prezentatorul, exprimându -și
acordul sau dezacordul cu privire la anumite părți ale lucrării /prezentării .
Scopul principal al proiectului este îmbunătățirea relației dintre prezentator și auditoriu, dar
și dintre persoanele din sal ă pe parcursul unei prezentări . Pentru a atinge acest obiectiv am ales să
dezvoltăm o aplicație pe dispozitve mobile cu Android care să permită utilizatorilo r urmărirea
prezentării atât în timp real, cât și în propriul ritm și adăuga rea, pe parcur s, de feedback pozitiv sau
negativ pe o anumită zonă selectată de text/ imagine . La finalul prezentării , prezentatorul va putea
analiza și răspunde la întrebările și adnotările primite.
Folosirea aplicației are numeroase avantaje atât pentru utilizatori, cât ș i pentru prezentator.
Avantajul principal al utilizatorilor este interacțiunea , atât cu cei din sală pentru că pot vedea
întrebările notate de fiecare și pot interacționa cu persoanele care au interese comune cu ei, dar și cu
prezentatorul căruia îi pot ad resa întrebări și cere explicații . Avantajul prezentatorului este în primul
rând faptul că poate obține feedback relevant de la un număr destul de mare de persoane, poate
răspunde feeback -ului primit și își poate îmbunătăți pe viitor prezentările luând în considerare
observațiile primite.
Am preferat sistemul de operare Android pentru dezvoltarea aplicației , în defavoarea
celorlalte, mai ales datorită faptului că este cea mai răspândită tehnolo gie pe dispozitivele mobile
actuale, este bine documentat și intuitiv din punct de vedere al modului de utilizare . Pentru a
implementa partea de server am folosit tehnologii ca SQLite, Google Protocol Buffers, Jersey și
Grizzly .
Principalul obiectiv viitor al aplicației este îmbunătățirea părții de feeback din per spectiva
prezentatorului: în lista de feebback vor fi afișate primele 10 întrebări în ordinea relevanței și a
numărului de apariții , în dreptul fiecărei întrebări din interfața prezentatorului va apărea un timp
estimat pentru a răspunde la acea întrebare , raportat la timpul rămas . Astfel, prezentatorul își va
putea gestiona mai bine timpul alocat răspunsurilor și explicațiilor . Atât utilizatorii,cât și
prezentatorul vor avea afișat,în aplicație, timpul rămas până la finalul prezentării,
Un alt obiectiv viitor al aplicației este adăugarea de scenarii noi, care ar putea dovedi
necesitatea acesteia pe scară largă (ex: prezentări și conferințe pe I nternet). Pent ru realizarea
acestui obiectiv, o idee ar fi ca aplicația să dețină o funcționalitate ce persona lizează o prezentare pe
baza unor profiluri, asociate unui tip de scenariu, în măsură să codifice anumite caracteristici pentru o
experiență de utilizare mai bună . Un exemplu de acest tip este implementarea streaming -ului audio și
video pentru prezentări pe Internet.

ANCA – VIRGINA P ÎRVAN

42
Bibliogra fie

[1] Google AI -MAS Group . Preluat de pe http://aimas.cs.pub.ro/androidEDU
[2] Interactiunea om – calculator. Preluat de pe
http://www.scribd.com/doc/92389473/Interactiunea -Om-Calculator
[3] Iosif, G. Activitatea cognitivă a operatorului uman. Bucuresti: Editura Academiei.
[4] Trăușan -Matu, Ș. (2000). Interfațarea evoluată om -calculator. Bucuresti: Editura MatrixRom.
[5] Proie ctarea intefețelor utilizator in conducerea avansata – Criterii ergonomice. Preluat de pe
http://www.aie.ugal.ro/sica/curs/Curs5.pdf
[6] Gargenta, M. (2011). Learning Android.
[7] Burnette, E. (2010). Pragmatic Hello Android, Third Edition.
[8] Ehringer, D . (2010). The Dalvik virtual machine architecture.
[9] Design Patterns – Model View Controller (MVC) Pattern . Preluat, de pe
http://www.bogotobogo.com/DesignPatterns/mvc_model_view_controller_pattern.php
[10] Model View Controller Pattern . Preluat de pe h ttp://best -practice -software –
engineering.ifs.tuwien.ac.at/patterns/mvc.html
[11] Google Protocol Buffers Java documentation . Preluat de pe http://code.google.com/intl/ro –
RO/apis/protocolbuffers/docs/javatutorial.html
[12] REST . Preluat de pe http://searchsoa.techtarget.com/definition/REST
[13 ] JAX-RS: Developing RESTful Web Services in Java . Preluat de pe

JAX-RS: Developing RESTful Web Services in Java

[14] Jersey Documentation . Preluat de pe http://jersey.java.net/nonav/documentation/latest/user –
guide.html#d4e1972
[15] Owens, M. The Definitive Guide to SQLite . Preluat de pe
http://www.campusne wsjbp.com/campus_news/placement_papers/Sqlite.pdf
[16] MuPDF . Preluat de pe http://www.mupdf.com/
[17] Building an Android application . Preluat de pe

Smart Presentation Feedback –Interfața cu utilizatorul

43 http://www.skill -guru.com/blog/2011/01/10/building -an-android -application/
[18] Badita, M. Tutoriale And roid. Preluat de pe
http://magdabadita.wordpress.com/tag/android -tutorials/
[19] Liste in Android . Preluat de pe http://pdm.ipworkshop.ro/mediawiki/index.php/Lab3
[20] Liang, S. The Java Native Interface, Programmer’s Guide and Specification. Preluat de pe
http://java.sun.com/docs/books/jni/download/jni.pdf
[21] Tufiș, D. C. (2008). DIAC+: A Professional Diacritics Recovering System. Preluat de pe
http://www.racai.ro/~tufis/papers/Tufis -Ceausu -LREC2008.pdf

ANCA – VIRGINA P ÎRVAN

44
Anexe
Clasa MuPDFActivity. java
package com.artifex.mupdf;
import android.app.Activity;
import android.app.AlertDialog;
import android.content.DialogInterface;
import android.content.DialogInterface.OnCancelListener;
import android.os.Bundle;
import android.os.Environment;
import an droid.view.*;
import android.view.View.OnClickListener;
import android.widget.*;
import java.io.File;
import java.util.ArrayList;
import com.artifex.mupdf.PixmapView;

public class MuPDFActivity extends Activity
{
/* The core rendering instance */
private MuPDFCore core;
private static int MOD_SPEAKER = 1;
private static int MOD_USER = 2;
private int mod;
private int contorAmbiguu = 0;
private int contorProof = 0;

private MuPDFCore openFile()
{
String storageState = Environment.getExternal StorageState();
File path, file;
MuPDFCore core;
if (Environment.MEDIA_MOUNTED.equals(storageState))
{
System.out.println("Media mounted read/write");
}
else if (Environment.MEDIA_MOUNTED_READ_ONLY.equals(storageState))
{
System.out.pri ntln("Media mounted read only");
}
else
{
System.out.println("No media at all! Bale! \n");
return null;
}
path = Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOWNLOADS);
file = new File(path, "test.pdf");
System.out.println("Trying to open "+file.toString());
try
{
core = new MuPDFCore(file.toString());
}
catch (Exception e)
{

Smart Presentation Feedback –Interfața cu utilizatorul

45 System.out.println(e);
return null;
}
return core;
}
/** Called when the activity is first created. */
@Ov erride
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);

chooseUser();
}
public void init(int mod) {
PixmapView pixmapView;
if (core == null) {
core = (MuPDFCore)getLastNonConfigurationInstance();
}
if (core == null) {
core = openFile();
}
if (core == null)
{
/* FIXME: Error handling here! */
return;
}
pixmapView = new PixmapView(this, core);
/* Now create the UI */
RelativeLayout layout;
LinearLayout bar;
MyButtonHandler b h = new MyButtonHandler(pixmapView);
bar = new LinearLayout(this);
bar.setOrientation(LinearLayout.HORIZONTAL);
LinearLayout.LayoutParams butMargin = new
LinearLayout.LayoutParams(LinearLayout.LayoutParams.WRAP_CONTENT, LinearLayout.LayoutParams.WRAP _CONTENT);
butMargin.setMargins(5, 0, 5, 0);
bh.goLive = new Button(this);
bh.goLive.setOnClickListener(bh);
bh.goLive.setCompoundDrawablesWithIntrinsicBounds(R.drawable.live, 0,0,0);
if (mod == MOD_USER) bar.addView(bh.goLive);
bh.selectButton = new Button(this);
bh.selectButton.setOnClickListener(bh);
bh.selectButton.setCompoundDrawablesWithIntrinsicBounds(R.drawable.select, 0,0,0);
if (mod == MOD_USER) bar.addView(bh.selectButton);
bh.feedbackButton = new Button(this);
bh.feedbackBu tton.setOnClickListener(bh);
bh.feedbackButton.setCompoundDrawablesWithIntrinsicBounds(R.drawable.feedback, 0,0,0);
bar.addView(bh.feedbackButton);
bh.feedbackSlide = new Button(this);
bh.feedbackSlide.setOnClickListener(bh);
bh.feedbackSlide.setCompoundDrawablesWithIntrinsicBounds(R.drawable.feedback_slide, 0,0,0);
if(mod == MOD_SPEAKER)
bar.addView(bh.feedbackSlide);
bh.plus1Button = new Button(this);
bh.plus1Button.setOnClickListener(bh);

ANCA – VIRGINA P ÎRVAN

46
bh.plus1Button.setCompoun dDrawablesWithIntrinsicBounds(R.drawable.plus, 0,0,0);
if (mod == MOD_SPEAKER) {
bh.plus1Button.setBackgroundResource(R.layout.blue_button);
bh.plus1Button.setLayoutParams(butMargin);
}
bar.addView(bh.plus1Button);
bh.ambiguuButton = new Butt on(this);
bh.ambiguuButton.setOnClickListener(bh);
bh.ambiguuButton.setCompoundDrawablesWithIntrinsicBounds(R.drawable.ambiguu, 0,0,0);
if (mod == MOD_SPEAKER) {
bh.ambiguuButton.setBackgroundResource(R.layout.purple_button);
bh.ambiguuButton.s etLayoutParams(butMargin);
}
bar.addView(bh.ambiguuButton);
bh.proofButton = new Button(this);
bh.proofButton.setOnClickListener(bh);
bh.proofButton.setCompoundDrawablesWithIntrinsicBounds(R.drawable.proof, 0,0,0);
if (mod == MOD_SPEAKER){
bh.proofButton.setBackgroundResource(R.layout.yellow_button);
bh.proofButton.setLayoutParams(butMargin);
}
bar.addView(bh.proofButton);

layout = new RelativeLayout(this);
layout.setLayoutParams(new RelativeLayout.LayoutParams(
RelativeLayout.LayoutParams.FILL_PARENT,
RelativeLayout.LayoutParams.FILL_PARENT));
layout.setGravity(Gravity.FILL);

RelativeLayout.LayoutParams barParams =
new RelativeLayout.LayoutParams(
RelativeLayout.LayoutParams.WRAP_CONTENT,
RelativeLayout.LayoutParams.WRAP_CONTENT);
barParams.addRule(RelativeLayout.ALIGN_PARENT_BOTTOM);
barParams.addRule(RelativeLayout.CENTER_HORIZONTAL);
bar.setId(100);
layout.addView(bar, barParams);
RelativeLayout.LayoutParams pixmapParams =
new RelativeLayout.LayoutParams(
RelativeLayout.LayoutParams.FILL_PARENT,
RelativeLayout.LayoutParams.FILL_PARENT);
pixmapParams.addRule(RelativeLayout.ABOVE,100);
layout.addView(pixmapView, pixmapParams);
setContentView(layout);
}
public void addSpeakerButtonsBar(){
Toast.makeText(MuPDFActivity.this, "speaker", Toast.LENGTH_SHORT).show();
init(MOD_SPEAKER);
mod = MOD_SPEAKER;
}
public void addUserButtonsBar(){
Toast.makeText(MuPDFActivity.this, "user", Toast.LENGTH_SHORT).show();
init(MOD_USER);
mod = MOD_USER;
}

Smart Presentation Feedback –Interfața cu utilizatorul

47 public void chooseUser(){
AlertDialog.Builder builder = new AlertDialog.Builder(this);
builder.setMessage("What are you?");
builder.setCancelable(true);
builder.setPositiveButton(" Speaker", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int id) {
addSpeakerButtonsBar();
dialog.cancel();
}
});
builder.setNeutralButton("User", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int id) {
loginDialog();
}
});
AlertDialog alert = builder.create();

alert.show();
}
protected void loginDialog(){
AlertDialog.Builder builder = new AlertDialog.Builder(this);
builder.setMessage("Login to continue");
LinearLayout ll = new LinearLayout(this);
ll.setOrientation(LinearLayout.VERTICAL);
EditText username = new EditText(this);
username.setHint("Username");
username.setWidth(400);
ll.addView(username);
builder.setView(ll);

builder.setPositiveButton("Ok", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int id) {
addUserButtonsBar();
dialog.cancel();
}
});
AlertDialog alert = builder.create();
alert.show();
}
public void finalFeedback(){
final AlertDialog alert;
AlertDialog.Builder builder = new AlertDialog.Builder(this );
builder.setCancelable(true);
LinearLayout ll = new LinearLayout(this);
ll.setOrientation(LinearLayout.HORIZONTAL);
Button plus1 = new Button(this);
Button delete = new Button(this);
plus1.setCompoundDrawablesWithIntrinsicBounds(R.drawable.pl us, 0,0,0);
delete.setCompoundDrawablesWithIntrinsicBounds(R.drawable.delete, 0,0,0);
ll.addView(plus1);
ll.addView(delete);
builder.setView(ll);
alert = builder.create();
delete.setOnClickListener(new OnClickListener() {
public void onClick(View v) {

ANCA – VIRGINA P ÎRVAN

48
Toast.makeText(MuPDFActivity.this, "delete my question!", Toast.LENGTH_SHORT).show();
alert.dismiss();
}
});
plus1.setOnClickListener(new OnClickListener() {
public void onClick(View v) {
Toast.makeText(MuPDFActivity.this, "+1!", Toast.LENGTH_SHORT).show();
alert.dismiss();
}});
alert.setOnCancelListener(new OnCancelListener() {
public void onCancel(DialogInterface dialog) {
createList2(mod);
}});
alert.show();
}
publ ic void addQuestion(){
final AlertDialog alert;
AlertDialog.Builder builder = new AlertDialog.Builder(this);
builder.setTitle("Add question");
LinearLayout ll = new LinearLayout(this);
ll.setOrientation(LinearLayout.VERTICAL);

EditText et = new EditText(this);
et.setHint("Add new question");
et.setWidth(400);
ll.addView(et);
builder.setView(ll);
builder.setPositiveButton("Ok", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int id) {
dialog.cancel();
} });
alert = builder.create();
alert.show();
}
public void createList2(final int mod){

final CharSequence[] items_list2 = {"Question1 Question Qu estion11 Question1 Question1 "};
AlertDialog.Builder build er = new AlertDialog.Builder(this);
builder.setTitle("Questions");
builder.setItems(items_list2, new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int item) {
Toast.makeText(MuPDFActivity.this, "item "+item+" clicked", Toast.LENGTH_SHORT).show();
if(mod == MOD_USER){
finalFeedback();
}}});
builder.setOnCancelListener(new OnCancelListener() {
public void onCancel(DialogInterface dialog) {
createList(mod);
}
});
AlertDialog alert = bu ilder.create();
alert.show();
}
public void createList(final int mod) {
final ArrayList<Question> items = new ArrayList<Question>();

Smart Presentation Feedback –Interfața cu utilizatorul

49 for (int i = 1; i<6; i++)
items.add(new Question("Question"+i+" This is a very long question!!."));
if (mod == MOD_USER)
items.add(new Question("Add question"));
AlertDialog.Builder builder = new AlertDialog.Builder(this);
builder.setTitle("Feedback");
builder.setCancelable(true);
builder.setAdapter(new MultilineAdapter(this, items), new DialogInterfa ce.OnClickListener() {
public void onClick(DialogInterface dialog, int item) {
Toast.makeText(MuPDFActivity.this, "question "+item+" clicked", Toast.LENGTH_SHORT).show();
if (item == (items.size() – 1) && mod == MOD_USER) {
addQuestion( );
} else {
createList2(mod);
}
}
});
AlertDialog alert = builder.create();
alert.show();
}
public Object onRetainNonConfigurationInstance()
{
MuPDFCore mycore = core;
core = null;
return mycore;
}
public v oid onDestroy()
{
if (core != null)
core.onDestroy();
core = null;
super.onDestroy();
}
private class MyButtonHandler implements OnClickListener
{
Button goLive;
Button selectButton;
Button feedbackButton;
Button feedbackSlide;
Button plus1Button;
Button ambiguuButton;
Button proofButton;
PixmapView pixmapView;
public MyButtonHandler(PixmapView pixmapView)
{
this.pixmapView = pixmapView;
}
public void onClick(View v)
{
if (this.pixmapView.selectActiv == tr ue && v != selectButton)
{
pixmapView.getThread().resetSelect();
if (this.pixmapView.doneSelection == false)
{

ANCA – VIRGINA P ÎRVAN

50
Toast.makeText(MuPDFActivity.this, "First make a selection",
Toast.LENGTH_SHORT).show();
}
else
{
if (pixm apView.selectionString.charAt(pixmapView.selectionString.length() – 1) == '.')
{
this.pixmapView.doneSelection = false;
Toast.makeText(MuPDFActivity.this, "Nothing was selected",
Toast.LENGTH_SHORT).show();
}
else
{
Toast.makeText(MuPDFActivity.this, "Selection: " +
this.pixmapView.selectionString, Toast.LENGTH_SHORT).show();
}}}
if(v == goLive)
Toast.makeText(MuPDFActivity.this, "Go live!", Toast.LENGTH_SHORT).show();
else if(v == selectButton)
{
if (this.pixmapView.selectActiv == false)
{
this.pixmapView.selectActiv = true;
Toast.makeText(MuPDFActivity.this, "Make selection!",
Toast.LENGTH_SHORT).show();
}
else
{
this.pixmapView.selectActiv = false;
this.pixma pView.doneSelection = false;
pixmapView.getThread().resetSelect();
this.pixmapView.getThread().forceRedraw();
Toast.makeText(MuPDFActivity.this, "Stopped selection!",
Toast.LENGTH_SHORT).show();
}
}
else if(v == feedbackButton)
createList(mod);
else if(v == feedbackSlide)
createList(mod);
else if(v == plus1Button && mod == MOD_USER)
Toast.makeText(MuPDFActivity.this, "+1!", Toast.LENGTH_SHORT).show();
else if(v == ambiguuButton && mod == MOD_USER){
contorAmbiguu++;
if(this.pixmapView.selectActiv == true && contorAmbiguu == 1){
Toast.makeText(MuPDFActivity.this, "Ambiguu",
Toast.LENGTH_SHORT).show();
}
else if(this.pixmapView.selectActiv == true && contorAmbiguu == 2) {

AlertDialog.Builder builder = new AlertDialog.Builder(MuPDFActivity.this);
builder.setMessage("Do you want to delete ambiguu selection?");
builder.setPositiveButton("Yes", new DialogInterface.OnClickListener() {
public void onClick(Dia logInterface dialog, int id) {
pixmapView.selectActiv = false;

Smart Presentation Feedback –Interfața cu utilizatorul

51 pixmapView.doneSelection = false;
pixmapView.getThread().resetSelect();
pixmapView.getThread().forceRedraw();
dialog.cancel();
}
});
builder.setNegativeButton("No", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int id) {
dialog.cancel();
}
});
AlertDialog alert = builder.create();
alert.show();
}
else {
contorAmbiguu = 0;
this.pixmapView.selectActiv = false;
this.pixmapView.doneSelection = false;
pixmapView.getThread().resetSelect();
this.pixmapView.getThread().forceRedraw();
Toast.makeText(MuPDFActivity.this, "Make selection!",
Toast.LENGTH_SHORT).show();
}
}
else if(v == proofButton && mod == MOD_USER){
contorProof++;
if(this.pixmapView.selectActiv == true && contorProof == 1){
Toast.makeText(MuPDFActivity.this, "Proof",
Toast.LENGTH_SHORT).show();
}
else if(this.pixmapView.selectActiv == true && contorProof == 2) {

AlertDialog.Builder builder = new AlertDialog.Builder(MuPDFActivity.this );
builder.setMessage("Do you want to delete PROOF selection?");
builder.setPositiveButton("Yes", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int id) {
pixmapView.selectActiv = false;
pixmapView.doneSelection = false;
pixmapView.getThread().resetSelect();
pixmapView.getThread().forceRedraw();
dialog.cancel();
} });
builder.setNegativeButton("No", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int id) {
dialog.cancel();
}});
AlertDialog alert = builder.create();
alert.show();}
else {
contorProof = 0;
this.pixmapView.selectActiv = false;
this.pixmapView.doneSelection = false;
pixmapView.getThread().resetSelect();
this.pixmapView.getThread().forceRedraw();
Toast.makeText(MuPDFActivity.this, "Make selection!", Toast.LENGTH_SHORT ).show();}}}}}