1 Sinteza lucrării în limba Engleză ………………………….. ………………………….. ………………………. 3 2 Planificarea… [612594]

Cuprins
1 Sinteza lucrării în limba Engleză ………………………….. ………………………….. ………………………. 3
2 Planificarea activității ………………………….. ………………………….. ………………………….. ………….. 4
3 Stadiul actual ………………………….. ………………………….. ………………………….. ……………………… 5
3.1.1 Moduri de implementare a realității augmentate ………………………….. ………………….. 5
3.1.2 Probleme nerezolvate ale realității augmentate ………………………….. ……………………. 7
4 Fundamentare teoretică ………………………….. ………………………….. ………………………….. ……… 10
4.1 Realitate augmentată ………………………….. ………………………….. ………………………….. ……. 10
4.1.1 Introducere în Realitatea augmentată ………………………….. ………………………….. …… 10
4.1.2 Utilizări actuale ale realității augmentate ………………………….. ………………………….. 11
4.2 Android ………………………….. ………………………….. ………………………….. ……………………… 14
4.2.1 Scurt isto ric al dispozitivelor mobile ………………………….. ………………………….. …… 14
4.2.2 Sistemul de operare Android ………………………….. ………………………….. ………………. 14
4.2.3 Arhitectura sistemului de operare Android ………………………….. ……………………….. 16
4.2.4 Dezvoltarea aplicațiilor ………………………….. ………………………….. ……………………… 18
4.2.5 Activități ………………………….. ………………………….. ………………………….. ……………… 19
4.2.6 Fragmente ………………………….. ………………………….. ………………………….. ……………. 21
4.2.7 Interfața grafică ………………………….. ………………………….. ………………………….. ……. 22
4.2.8 Intent ………………………….. ………………………….. ………………………….. …………………… 22
4.3 Recunoșterea optic ă a caracterelor ………………………….. ………………………….. …………….. 23
4.4 Trecerea de la text la vorbire ………………………….. ………………………….. …………………….. 24
4.5 Google API ………………………….. ………………………….. ………………………….. ………………… 24
5 Implementare a soluției adoptate ………………………….. ………………………….. ………………………. 26
5.1 Platforma si mediu de dezvoltare ………………………….. ………………………….. ………………. 26
5.2 Creearea proiectului Android ………………………….. ………………………….. ……………………. 26
5.3 Fișiere de configurare ………………………….. ………………………….. ………………………….. ….. 27
5.4 Implementarea proiectului ………………………….. ………………………….. ………………………… 28
5.4.1 CameraSource ………………………….. ………………………….. ………………………….. ……… 28
5.4.2 TextOverlay ………………………….. ………………………….. ………………………….. …………. 29
5.4.3 Activități si Fragmente ………………………….. ………………………….. ………………………. 30
5.5 Recunoașterea caracterelor ………………………….. ………………………….. ……………………….. 33
5.6 Probleme si dezavantaje ale abordarii alese ………………………….. ………………………….. … 34
5.7 Dezvoltări ulterioare ………………………….. ………………………….. ………………………….. ……. 35
6 Rezultate experimentale ………………………….. ………………………….. ………………………….. …….. 37
7 Concluzii ………………………….. ………………………….. ………………………….. …………………………. 39
8 Bibliografie ………………………….. ………………………….. ………………………….. ………………………. 40
9 Anexe ………………………….. ………………………….. ………………………….. ………………………….. …. 41

1 Sinteza lucrării în limba Engleză

2 Planificarea activității

3 Stadiul actual
Termenul „Realitate Augmentată” a fost introdus în 1990 de către Thomas Caudell, pe atunci
angajat al companiei Boeing [ 8]. Realitatea augmentată (AR) este o variație a realității virtuale –
un spațiu virtual în care timpul, fizica și materialele din lumea reală pot fi depășite. AR permite
utilizatorilor să vadă lumea reală cu modele virtuale integrate în realitate. De aceea, aceasta
completează realitatea, nu o înlocuiește. În mod ideal, totul pare că obiectele virtuale și cele reale
coexista în același spațiu. Mai jos este prezentată cele bra ilustrație a continuumului Real -Virtual.

Figura 1 Continuumul Real -Virtual
Figura de mai sus arată Continuumul Real -Virtual propus de autorii cărții „Augmented
reality: A class of displays on the reality -virtuality continuum”[ 9]. Pe una dintre extreme se află
mediul real și pe cealată mediul virtual. Tot ce se află la mijloc, între cele două extreme aparține
realității mixte, cum ar fi AR. Se face distincția dintre realitate augmentată (AR) și virtualitate
augmentată (AV). Prima se bazează pe un mediu real amestecat cu obiecte din mediul virtual, pe
când cealaltă este total invers. Un exemplu bun de AV este o cameră virtuală în care se află
persoane reale. Astfel, realitatea augmentată este o tehnologie ce suprapune o lume virtuală
generată de către computer peste lumea reală, înregistrată de către sensor -ul video al
dispozitivului. Lumea virtuală poate fi formată din obiecte bi – sau tri -dimensionale de orice tip.
Printr -o definiție scurtă, realitatea augmentată reprez intă un set de tehnici, care permit obiectelor
virtuale să se plaseze în lumea reală. Aceste elemente virtuale pot folosi cele cinci simțuri
umane, cele mai comune aplicații utilizând imagini și uneori sunete.
Un sistem AR trebuie să cuprindă următoarele c aracteristici [ 10]:
• Combină realul cu virtualul
• Interacționeză în timp real
• Înregistrează obiecte 3D
Prima caracteristică se referă la faptul că rezultatul trebuie să conțină atât părți din lumea
virtuală, cât și din realitate. Cea de -a doua se poate exe mplifica prin filmul Avatar, care deși
conține obiecte virtuale amestcate în scene reale, nu poate fi considerat un model AR deoarece
acestea nu sunt interactive. În plus, după cum se menționează în al treilea punct, proiecția
cromatică (chrome keying), ca re este adesea folosit în rapoartele meteo de la televizor, nu este
AR, pentru că îmbină hărți și nu obiecte 3D.
3.1.1 Moduri de implementare a realității augmentate
Toate aplicațiile de tip AR au o problemă comună ce necesită a fi rezolvată. Aceasta este
reprez entată de poziția camerei care să respecte buna vizualizare a obiectelor virtuale trebuie să

fie corect determinată. Există mai multe metode de determinare, fiecare având avantaje și
dezavantaje din punct de vedere al calculelor și acurateții rezultatelor, aceste fiind prezentate în
detaliu în cele ce urmează. [5]
a. Folosind informații de poziție
• În acest caz, aplicațiile îmbină informațiile referitoare la poziția utilizatorului sau la
direcția spre care acesta privește.
• Suprapune informația pe care o poate p relua de pe ecran relativă la poziția utilizatorului
• Un exemplu de acest tip de aplicație poate fi aceea care permite căutarea web având aceste
informații de coordonate.

Figura 2 Wikitude – căutare locații
• Utilizând această metodă, este foarte dificil ca elementele virtuale să fie identice cu
realitatea deoarece aplicația nu reușește să aproximeze unde se află obiectul (clădirea) pe
eranul dispozitivului
• Altfel spus, nu e ușor să fie detectată cu exactitate locația utilizator ului, spre exemplu cu
un sistem GPS, acuratețea preciziei locației este de 15m. (uneori distanță fiind suficientă)
• Ca un mare avantaj, soluția oferită de aceasta abordare a realității augmentate respectă
constrângerea timpului, ce determină ca aplicațiile să fie considerate în timp real.
b. Folosind markeri (patterns/codes)
• Markerii de reper sunt forme simple, puternic contrastante. De cele mai multe ori, ele sunt
reprezentate de o figură simplă alb -negru. Pătratele sunt cele mai comune, însă nu în
exclusivita te.

Figura 3 Exemple de markeri
• Aceste figuri, folosite ca reper sunt usor și rapid recunoscute de un calculator sau de o
camera. În acest caz, aplicațiile pot localiza cu exactitate obiectele urmărite și apoi
integrează informaț iile în timp real.
• Singurul dezavantaj îl reprezintă faptul că nu pot fi plasate astfel de markeri pe fiecare
clădire sau obiect ce urmează a fi analizat. Spre exemplu, pentru ca vizitatorii unui muzeu

să folosească o aplicație AR trebuie ca fiecare expon at să fie astfel marcat, proces ce ar
dura mult timp și ar avea un risc de deterioarare.
• Totodată, aceasta este metoda folosită în dezvoltarea prezentei lucrări practice deoarece
folosind puncte de reper, este mai ușor de implementat un model 3D poziționat
corespunzător, care să fi suprapus cu lumea reală.
• altă modalitate, care să rezolve problema scalarității obiectelor este folosirea lumii reale ca
markeri, lucru posibil doar în anumite situații. Un astfel de exemplu este aplicația oferită
de marca Tisso t, care pe baza unei benzi (marker) în jurul încheieturii permite vizualizarea
ceasului dorit.
c. Folosind recunoașterea de imagini
• Diferența dintre marker și recunoașterea imaginilor rămâne neclară. Pentru majoritatea
aplicațiilor de detecție a fețelor umane , se folosesc ochii ca și puncte de reper. Este destul de
ușor să detectezi ochii pe fața unei persone datorită pupilelor (puncte negre).
• În schimb, recunoașterea imaginilor folosesc o cameră și un calculator pentru a extrage
principalele caracteristici a le fotografiei comparându -le cu alte informațiile anterior
descoperite și stocate în sistem. În acest fel, putem știi precis unde se află obiectul respectiv
fără a fi fost marcat.
• O problema ce apare este timpul necesar calculatorului să recunoască un anu mit obiect. Mai
mult decât atât, detecția poate fi dificilă și din cauza poziționării camerei și a condițiilor de
lumină.
În concluzie, cea mai simplă și cu calcule mai puțin complicate este metoda care folosește
markeri plasate în locații specifice, așa c um se poate observa din figura alăturată. Dar în unele
situații, acești markeri pot deranja sau nu pot fi poziționați in locurile dorite, de aceea celelalte
metode care folosesc caracteristici naturale în procesul de determinare a obiectelor 3D, deși de o
complexitate mai mare (prin urmare mai greu de a fi implementate), sunt utilizate cu succes.
3.1.2 Probleme nerezolvate ale realității augmentate
După cum am dezvoltat anterior domneniul AR este destul de bine cunoscut și are destul de
multe aplicații care să îl scoată în evidență. Dar exista utilitati pentru care tehnologia nu poate fi
implementată deocamdată din cauza limitărilor hardware și algoritmice.
Experiențe Virtuale
Tehnologia AR ar putea fi folosită în viitor pentru a crea experiente virtuale. Ai putea avea un
sistem montat pe cap care transforma locatia curenta în ceva cu totul diferit. Ca exemplu, ai
putea să traiesti prin filme purtand un sistem ca acesta și să ve zi filmul ruland în jurul tau. Ai
putea să convertesti propria casa intr -un castel medieval sau o statie spatiala internationala.
Cuplata cu un aparat auditiv și o tehnologie care emite miros ar crea o experienta complet reala.
în plus de asta, avand un co stum pe tot corpul care emuleaza simtul tactil ar face experienta
indubitabil de reala. Aceasta ar fi destul de greu de implementat pe Android, pentru ca Android
nu are senzorii și metodele de intrare pentru a implementa asa ceva. Caracteristicile vizuale ar
putea fi implementate intr -o oarecare masura, dar sunetele și simturile tactile vor fi inaccesibile
decat dacă cineva creaza un costum pe corp cu un montaj pe cap cu sunet și portat pe Android.
Simulari Imposibile
Deocamdata tehnologia AR ar putea să faca ceea ce hardware -ul real nu poate. Ai putea avea un
ecran pe care ai un obiect obijnuit, ca un cub. Ulterior vei putea aplica diferite scenarii și forte pe
cub și să vezi cum se modifica. Nu poti face acest lucru cu hardware real pentru ca de obicei e l

nu isi poate schimba forma fara a fi distrus. Teoriile ar putea fi testate prin experimente care
altfel ar fi foarte scumpe sau complet imposibile.
Aceasta ar fi posibil de implementat pe Android până cand sunt dezvoltate alte modele reale
pentru ca sin gurele cerințe pentru simularile high -end sunt datele și o putere mare de procesare.
Telefoanele mobile ar putea să ajunga destul de rapide pentru a rula aplicații ca aceasta la pasul
în care creste puterea de procesare.
Holograme
AR permite utilizatorul ui să aibe o transmisiune în direct directă sau indirectă a lumii, permitand
utilizatorilor să proiecteze holograme în fața lor. Aceste holograme ar putea fi interactive sau
doar descriptive. Ar putea arăta orice. Aceasta se poate face și în ziua de azi fo losind o versiune
foarte modificata a aplicatiei care foloseste markere pentru a afisa modele. în loc de modele
statice, aplicatia ar putea să fie facuta pentru a afisa animatii, o inregistrare sau o transmisiune în
direct. Cu toate aceastea, nu ar furniza o experienta holografica autentica deoarece va fi doar pe
ecranul dispozitivului.

Conferințe Video
AR ar putea permite mai multor persoane să apară în aceeasi camera de conferință dacă o sursă
video a unei camere de conferințe transmisa lor. Oamenii ar putea folosi o camera web pentru a
"apărea" în scaunele din camera împreuna cu ceilalți. Aceasta ar putea crea un mediu colaborativ
chiar dacă colaboratorii sunt la distanțe mari.
Aceasta aplicația ar putea fi implementată cu ceva algoritmi avansați de p lasament și o
conexiune foarte rapidă la Internet. Este nevoie de algoritmi pentru că este destul de improbabil
ca oamenii să ramana în același loc în timpul conferinței. Ei trebuie repozitionați de fiecare data
pentru a nu se suprapune cu alții.
Filme
AR ar putea fi folosit pentru a reda filme întregi. Cinematograful ar putea fi inlocuit cu fundalul
filmului sau doar cu actorii. în primul caz, actorii ar putea fi augmentați pe fundal și în al doilea
caz ar fundalul ar putea fi augmentat în spatele actori lor. Acestea ar putea asigura o experiență
mai realistică și distractivă, iar în acelasi timp costurile filmărilor pot fi reduse.
Aplicații ca aceasta există deja în producție, dar nu la calitatea, popularitatea și sofisticarea
pentru a nu exista implemen tări viitoare. Chiar dacă ele nu sunt chiar ușor de dezvoltat, nu sunt
nici atât de greu.
Turism
Problema majoră în primul rând pentru industria turismului la complet adoptă aplicații AR este
că în prezent cele mai multe dintre aplicații sunt bazate pe lo calizare, bazându -se doar pe pozitii
GPS. În cazul în care hărțile sau bazele de date sunt nu au fost actualizate la cele mai recente
puncte de interes sau sunt inexacte, aplicațiile nu pot funcționa corect sau nu vor avea
capacitatea de a suprapune grafic a corect. În acest moment acuratețea GPS -ului integrat in
dispozitivele mobile de tip smartphone este în jur de 10 de metri, în funcție de diverse factori
cum sunt diponibilitatea satelișilor GPS în zonă, numărul de clădiri care pot bloca transmisia
locali zării GPS. Aceasta poate fi insuficientă pentru anumite site -uri istorice, cum sunt ruinele,
unde există o verietate de obiecte și locuri de interes. [1]

Deși problema pierderii semnalului GPS, se poate compensa prin transmisia datelor referitoare la
local izare prin internet, această metodă poate deveni destul de scumpă pentru utilizatori.De
asemenea, folosirea atât a semnalului GPS cât si a intenetului pentru o perioadă îndelungată, au
un impact mare asupra utilizării bateriei telefonului, ceea ce poate fi deranjant pentru utilizator.
Controlul prin Gesturi
AR ar putea fi folosită pentru a implementa mai multe forme de control prin gesturi, cum ar fi
formarea unui numar de telefon prin mișcările ochiilor. Camera ar urmări mișcările de ochi ale
utilizatorul ui pentru a selecta tasta cu numarul. Dupa ce tasta a fost selectată, el ar clipi pentru a
alege numarul și continua să selecteze tasta urmatoare. Aceasta ar putea fi implementată
asemănător pentru a controla o aplicație de redare de muzică, aplicații mobi le, calculatoare și alte
feluri de tehnologii. [4]
Acest fel de aplicații ar necesită cateva lucruri:
camera frontală cu rezoluție rezonabilă
Algoritmi scriși foarte bine pentru a detecta mișcările fine de ochi și să le diferentieze de alte
miscări, cum ar fi verificarea oglinzii retrovizoare
AR s -a dezvoltat destul de mult de cand a fost început și mai are mult de mers. Cerinșele de bază
pentru o cameră, GPS, accelerometru și compass sunt îndeplinite de aproape toate dispozitivele
Android de pe piață. C hiar dacă aplicațiile care folosesc AR există pentru platforma Android,
sunt mult mai puține decat alte tipuri de aplicații. Timpul pentru a intra pe platforma Android
prin a crea aplicații AR este propice deoarece competiția este destul de bună pentru a s târni
interesul utilizatorilor, dar destul de liniștită pentru a nu pierde investiția. Considerând că sunt
destul de putine aplicații AR pe piata, există și o șansă prin care dezvoltând o aplicație AR destul
de bună, nu o să fie mai mult de 3 -5 aplicații î n competitie, garantand un avantaj mare.[4]
Medical
Desi există și aplicații medicale în ceea ce privește tehnologia AR. Mașinile AR pot fi folosite să
urmărească un număr larg de pacienți, pentru a se asigura că semnele lor vitale sunt sub
observație tot timpul, dar acest tip de tehnologii AR nu a fost niciodată implementat pe o
platformă AR, din motive diverse:
Ar fi nevoie de un volum de informație gigantică pe un dispozitiv, fiindcă conexiunile la Internet
nu sunt atât de sigure, iar viața unui pacient ar putea fi riscată pe acest motiv.
Puterea de procesare necesară pentru aceste task -uri medicale nu există încă pe unele dintre
dispozitive.
Nu există o piață foarte mare pentru dispozitive Android pentru operații sau într -ajutorarea task –
urilor medicale.
Ultima, dar nu cea din urmă, este mult prea scump și dificil pentru a proiecta și construi o
asemenea aplicație. Algoritmii inteligenței artificiale necesari pentru a permite tehnologiei AR să
proceseze în timp real în domeniul medical, trebuie să fie cre ați. Înafară de asta, ar fi nevoie de o
echipă de developeri foarte buni, o echipă de doctori foarte pricepută și experimentată și o sumă
mare de bani.[5]

4 Fundamentare teoretică
Pentru a putea întelege conceptele folosite în dezvoltarea aplicației este nevoie de
prezentarea unor considerente toretice privind tehnologiile alese, fie că este vorba despre
alegerea sistemului de operare și a mediului de dezvoltare sau despre librării și API -uri utilizate
pentru a ușura munca dezvoltatorului de aplicații.
4.1 Realitate augmentată
4.1.1 Introducere în Realitatea augmentată
Realitatea augmentată este o variație a realității virtuale. Tehnologiile de realitate virtuală
introduc utilizatorii într -un mediu sintetic, creat complet digital, în care utilizatorul nu poate
vedea mediul din jurul sau. În contrast, realitatea augmentată ia informațiile generate de un
calculator, fie că sunt imagini, sunete sau filme pe care le suprapune peste mediul înconjurător.
Realitatea augmentată poate fi folosită, pentru a spori senzațiile, a supra tuturor celor 5 simțuri
dar în prezent este folosită preponderent pentru a oferii o experiență vizuală îmbunătățită. [3]
Spre deosebire de realitatea virtuală, realitatea augmentată, permite utilizatorului să observe
mediul înconjurător, peste care sunt suprapuse elemente generate de calculator, făcând ca aceasta
să fie considerată o cale de mijloc între un mediu complet sin tetic, generat de calculator, și un
mediu complet real.
Unul dintre cele mai simple exemple de utilizare al realității augmentate în acest moment
este pe căștile piloților de avioane militare, cărora le sunt afișate pe viziera căștii diverse
informații cu m ar fi linia orizontului, viteza avionului, altitudinea și alte informații cruciale
pentru pilot, lucru care îi permite să ia decizii mult mai repede.
O caracteristică foarte importantă a realității augmentate este faptul că trebuie să fie
interactivă, s ă prezinte utilizatorului orice modificare în timp real.
Conform autorilor cărții „Augmented Reality: An emerging technologies guide to AR”
pentru a avea un sistem funcțional de realitate augmentată este nevoie de următoare componente:
Hardware:
– Un ca lculator, fie un PC fie un dispozitiv mobil
– Un display
– O cameră de filmat
– Senzori de mișcare și orientare
– Conexiune la internet
– Markere: obiecte fizice care realizează legătură între mediul real și cel virtual se suprapun
Software:
– O apl icație sau un program care rulează local
– Servicii web
– Un server pentru informații

Realitatea augmentată are rolul de a combina și suprapune conținut grafic (imagini, video,
sunete), asupra realității înconjurătoare. Acest domeniu este, de fapt, o combinație de mai multe
tehnologii cum sunt, procesarea de imagini si computer vision. Figu ra 1 reprezintă o schemă a
tehnologiilor incluse în crearea realității augmentate.[1]

Principalul domeniu în care este folosită realitatea augmentată în prezent este domeniul
reclamelor, tot mai multe firme profitând de omniprezentă dispozitivelor mobile i nteligente
pentru a -și integra în campaniile de marketing diverse modele de realitate augmentată. Companii
precum Nissan, Toyota, BMW și Mini folosesc reclamele din revistele de profil pentru a oferi,
prin intermediul diverselor aplicații de realitate augm entată, un model 3D al mașinilor lor pentru
a putea fi vizionate de către cititorii revistelor în cât mai mare detaliu.

Figura 1 – Tehnologii folosite în realitatea augmentată
4.1.2 Utilizări actuale ale realității augmentate
Deși primul dispozitiv capabil s ă redea elemente de realitate virtuală avea dimensiuni mari și
nu avea o utilitate reală pentru uilizatorul de rând, dezvoltarea continuă în acest domeniu a făcut
posibilă integrarea sa în domenii diverse, de la aplicații specifice pentru anumite domenii, până
la utilizarea sa în viața de zi cu zi. Figura 2 reprezintă “The Sword of Damocles”, ceea ce se
consideră primul sistem de display montat pe cap, pentru a reda realitate virtuală și realitate
augmentată.[2]

Figura 2 – The Sword of Damocles
Poate că cea mai simplă formă de realitate augmentată pe care oamenii o folosesc mulți ani
este cel disponibil în camerele foto. Mulți îl folosesc, dar foarte puțini realizeză natura
conceptului aplicat. Partea camerei numită "vizor" este, de fapt, o realitate augm entată într -o
formă foarte simplă. Ceea ce face în mod fundamental este să te uiți la lumea din jurul ei prin
lentila și apoi se adaugă un strat de imprimat pe sticlă pentru a evidenția centrul lentilei și
granițele imaginii care urmează să fie capturată.

Pentru dispozitivele mobile, au fost realizate lucrări privind realitatea augmentată pe aceleași
principii, chiar dacă metoda este ușor diferită. Camera surprinde un flux în direct a lumii din
jurul ei și afișează realitatea augmentată fără ca aceasta să d ifere de mediul încojurător. Procesul
de calcul al poziției relative a utilizatorului la realitatea înconjurătoare, pentru a putea spori în
mod corect conținutul pentru utilizator, este numit de urmărire. Pe de altă parte, aplicațiile de
navigație sunt alt e aplicații pentru dipozitive mobile utile și folosite zi de zi de o mulțime de
utilizatori.
Televiziunea este un alt domeniu în care realitatea virtuală a luat amploare. Emisiuni TV,
meciuri sportive în direct sau prognoza meteo, toate sunt situatii în ca re televiziunea folosește
realitatea augmentată în mod repetat. De asemenea, în această categorie intră și partea de filme.
Tehnologia AR este utilizată pentru a îmbunătăți filmele și piesele ănregistrate. Conceptul aplicat
în acest caz este folosirea unui panou static și un ecran cu suprapuneri pe ea pentru a produce
imagini și peisaje care altfel ar necesita seturi scumpe și foarte detaliate. Aceasta este o opțiune
cu adevărat fezabilă.
Folosirea realității virtuale în domeniul traducerilor poate fi util tuturor celor care călăltoresc
mult. Aplicații deja existente în acest domeniu scanează cu ajutorul camerei video textul pe care
vrem să îl traducem și afiseaza în locul sau textul deja tradus. Aceasta parte s -a dezvoltat atât de
mult, încât , dacă descarca m un pachet în prealabil, aplicatia se va putea folosi și fara a depinde
de conexiunea la internet. Figura 3 prezintă un exemplu de utilizare a aplicației Google
Translate, care folosește realitatea augmentată pentru a traduce texte în timp real. În acest
moment, aplicația conține un pachet de 20 de limbi din care se poate realiza traducerea.
Figura 3 – Utilizarea AR pentru traduceri.
În ultima perioadă, vehiculele au început să implementeze tehnologia AR. Parbrizele au
fost înlocuite cu display -uri largi și high -definition. De multe ori, într -un vehicol sunt mai multe
ecrane, fiecare arătând o direcție. Dacă există doar un ecran și mai multe camere, vehicolul fie va
schimba automat ce filmează o cameră, ori va avea o opțiune manuală. Exteriorul unui vehicul
deține mai multe camere, pentru dircții multiple. Imaginile de pe ecran prezintă date utile,
precum o hartă mică, busolă, săgeți de direcție, rute alternate, vremea și mult mai multe. Acest
tip de tehnologie este în moment, cel mai preznt în avioan e și trenuri. Mașinile inteligente,
încorporate cu acest tip de tehnologie sunt încă în testare, pentru piațe. Submarinele și vapoarele
folosesc acest tip de tehnologie. Recentele discontinued Space Shuttles (intuiesc că nave, idk) au
tehnologie AR.
Aceste aplicații pot fi implementate într -o formă hibridă pe Android. Din cauza faptului
că majoritatea platformelor de Android par a fi lipsite de anumite caracteristici, pe care alte
vehicule normale le au, aceste tipuri de caracteristici nu sunt obținut e. Pe de altă parte, pot fi
scrise aplicații care să ajute la navigare, folosind GPS -ul pentru a ajunge la destinația dorită, prin

intermediul APIs direction, și prin folosirea unui accelorometer pentru a afla viteza vehiculului.
Android -ul oferă informați i AR, iar ei bine, vehicolul, partea vehicolului.
Domeniul medical este un alt domeniu în care s -a dezvoltat utilizarea realitatii
augmentate. Operațiile prin intermediul AR, devin din ce în ce mai comune în ziua de azi.
Operațiile realizate în acest fel a u o marjă de eroare mult mai mică, fiindcă computer -ul oferă
detalii prețioase despre operație. Motivul este că AR -ul folosește detaliile pentru a controla
roboții când operează, fie complet sau doar parțial. Computer -ul poate folosi alternative și
instruc țiuni asupra ce se poate face, pentru a îmbunătăți operația în timp real. AR -ul, redă în flux
real(stream), iar pe lângă asta, informația legată de pacienți, poate fi trimis și medicilor aflați la
distanță, pentru a putea vedea în timp real informația, de parcă s -ar afla în fața lor.[5]
Turismul este un alt domeniu în care s -a investit pentru integrarea realității virtuale. În
mai multe locuri faimoase în lume există excursii organizate în care se folosesc sisteme de
realitate augmentată montate pe cap, car e afișează informații despre locul curent și clădirile sale,
în timp real. Folosind sistemele de realitate augmentată se pot reconstrui pentru turiști clădiri,
orașe, peisaje și terenuri pentru a putea fi vizualizate în modul în care au existat în trecut. În
momentul de față există mai multe platforme care fac posibilă crearea de aplicații turistice, care
integrează realitatea augmentată. Una dintre aceste platfome este Wikitude. Aceasta este o
platformă care oferă suport pentru toate sistemele de operare d e dispozitive mobile. O altă
platfomă este Layar, care se bazează pe locația utilizatorului și raza de vedere a acestuia pentru a
adăuga straturi asupra camerei foto. Respectivele straturi (“layers”) vor fi încărcate cu ajutorul
unor servicii web și pot re cunoaște obiecte din viața reală sau pot crea obiect interactive de tip
3D. Figura 4 prezintă o viziune de ansamblu al structurii platformei Layar.

Figura 4 – Structura platformei Layar
Venind ca o extindere a implementarii realității augmentate în do meniul turismului, s -a
dezvoltat și o ramură de introducere a vizualizării 4D a mediului înconjurător. Conceptul de
vizualizare 4D cuprinde mai multe nivele de detalii care permit să explorați date orientate în timp
într-o vizualizare folosind realitatea a ugmentat. Cel mai inalt Nivelul de abstractizare furnizează
suficiente informații pentru a oferi o imagine de ansamblu a datelor în raport cu obiectele din
mediul realității virtuale. Al doilea nivel de abstractizare prezintă vizualizări tradiționale
orien tate spre timp înregistrate în AR, pentru a permite o analiză eficientă a datelor orientate în
timp. înregistrarea acesteia în realitatea augmentată oferă în plus informații despre relația sa cu
structura din lumea reală. Al treilea nivel oferă detalii str ucturale ale obiect de interes pentru un
punct selectat în timp și spațiu 3D. [7]

4.2 Android
4.2.1 Scurt istoric al dispozitivelor mobile
Făcând o scurt rezumat a dezvoltării dispozitivelor mobile de la apariția lor, aflăm că prima
punere în practică a conceptului de telefonie mobilă s -a concretizat în anul 1910, când
inventatorul suedez Lars Magnus Ericsson și -a instalat un dispozitiv în ma șina personală, cu care
se putea conecta la rețeaua națională, în timpul deplasărilor sale prin țară. Totuși, din acel
moment până la un dispozitiv asemănător a ceea ce reprezintă azi telefonul mobil, a fost nevoie
de rezolvarea mai multor probleme care fă ceau ca utilizarea dispozitivului mobil să nu fie una
ușoară sau eficientă, fie că însemnă rezolvarea problemei greutății dispozitivului (începănd de la
40 de kilograme, în anul 1956), fie rezolvarea piedicilor în ceea ce privește aria de acoperire a
semna lului dispozitivului.
Un pas important în dezvoltarea telefoniei moderne se face în anul 1973, când compania
Motorola, prin angajatul său Dr. Martin Cooper, realizează o convorbire cu un telefon mobil
bazat pe undele radio, Motorola DynaTAC, în New York. Din acest moment mai este nevoie de
doar șase ani până la prima lansare în scop comercial al telefoanelor mobile, eveniment ce a avut
loc în Tokio în 1979. Această primă generație realiza transmisiile în sistem analog, din cauza
căreia apăreau interferențe legate de electricitate și de zgomot.
Rezolvarea problemelor de interferențe s -a făcut în anul 1991, o dată cu lansarea celei de a
doua generații. Aceasta era bazată pe sisteme GSM (Global System for Mobile Communication)
și transmisia se realiza în sist em digital. Pe lângă rezolvarea problemelor anterioare, acestă 7
generație a venit și cu noi servicii cum sunt mesajele de tip SMS (Short Message Service),
accesul la fișiere multimedia (descărcarea tonurilor de apel), afișarea unor reclame promoționale.
După zece ani, în anul 2001 apare și a treia genarație numită ”3G”, care vine cu o viteză de
transmisie mai mare și o calitate mai bună a serviciilor.
Cea mai nouă generație de telefonie mobilă este cea de -a patra generație, care este
caracterizată prin c reșterea considerabilă a calității transmisiilor multimedia, aceste fiind
realizate prin "streaming media". Dintre aplicațiile compatibile cu această generație fac parte și
televiziunea mobilă high -definition și televizunea 3D, iar dezvoltatorii celor mai importante
sisteme de operare pentru dispozitivele mobile Android, iOS, Windows Phone au făcut posibilă
compatibilitatea acestora cu dispozitivele 4G.
4.2.2 Sistemul de operare Android
Una dintre primele decizii care trebuiesc luate în dezvoltara unei aplicații mobile, este
alegerea sistemului de operare cu care vrem ca aplicația noastră să fie compatibilă. Principalele
sisteme de operare și cele care ocupă cea mai mare parte a pieței dispozitivelor mobile în
momentul de față, sunt Android și iOS. Alegerea dintre cele două trebuie făcută luând în
considerare avantajele și dezavantajele fiecăruia și analizând care este cel mai potrivit în funcție
de populația țintă și scopul aplicației noastre.
IOS (inițial numit iPhone OS) este un sistem de operare creat si dezvo latat de care compania
Apple, fiind distribui exclusiv alături de hardware Apple. Cele mai importante cerințe pentru
dezvoltarea aplicațiilor pentru acest sistem de operare sunt: un computer cu sistemul de operare
OS X 10.8 (Mountain Lion) sau mai nou, car e conține mediul de dezvoltare Xcode care, cu
ajutorul software development kit -ului (SDK) pentru iOS, permite dezvoltarea de aplicații, iar o

alta cerință este necesitatea de a știi Objective C, limbaj de programare folosit de în compania
Apple.
Sistemul de Operare Android este cuprins în noul val de sisteme de opeare pentru mobile și
se află într -o continuă creștere de popularitate. Spre deosebire de alte sisteme de operare, 8
Windows Mobile,Apple iPhone și Palm Pre care sunt contruite pe sisteme de oper are care
prioritizează dezvoltare aplicațiilor native, Android oferă noi posibilități pentru aplicațiile
mobile, deoarece oferă un mediu de dezvoltare open -source. Accesul la hardware -ul
dispozitivelor mobile se face prin intermediul unor librării (API), i ar ineracțiunea dintre aplicații,
deși este controlată, este suportată în întregime.
Sistemul de operare a fost pentru prima dată prezentat în anul 2007 împreună cu formarea
Open Handset Alliance, un consorțiu de companii de hardware, software și telecomu nicații,
HTC, Sony, Samsung, T -Mobile și Qualcomm, devotate dezvoltării de standarde universal
accesibile pentru dispozitivele mobile. A durat însă încă un an de zile până la apariția telefonului
HTC Dream, lansat în 22 octombrie 2008, primul dispozitiv di sponibil comercial cu sistemul de
operare Android. Din anul 2008 până în prezent au apărut numeroase versiuni noi menite să
îmbunătățească experiența utilizatorilor. Fiecare nouă versiune majoră lansată a fost numită în
ordine alfabetică după un nume de pr ăjitură, spre exemplu: versiunea 1.5 „Cupcake” urmată de
versiunea 1.6 „Donut”, ajungând u-se până la versiunea Android 7 .0 „Nougat ”.
Pachetul de servicii Google Mobile Services, împreună cu trademark -ul Android pot fi
licențiate de producătorii de hardwar e pentru dispozitive care îndeplinesc standardele impuse de
Google. Astfel dispozitive care au modificări majore ale sistemului de operare, cum ar fi Fire OS
a companiei Amazon, nu includ pachetul de servicii oferit de Google și deci nu sunt compatibile
cu aplicațiile care au nevoie de acestea.
În afara faptului că poate rula direct pe o arhitectură x86 Android poate fi rulat pe o
asemenea arhitectură și folosing un emulator care face parte din Software Development Kit
pentru Android, sau folosind diverse alte aplicații.
Dispozitivele pot avea și alte componente hardware opționale cum ar fi camere video, GPS,
senzori de orientare, accelerometru, magnetometru, gyroscop, barometru, senzori de presiune,
senzori de proximitate, termometru. Unele componente nu sunt obligatorii însă au devenit
componente standard pentru anumite clase de dispozitive, în timp ce unele au fost obligatorii la
un moment dat însă nu mai sunt în prezent. Spre exemplu: inițial sistemul Android a fost
dezvoltat ca sistem de operare pentru telefon și avea nevoie obligatoriu de un microfon, însă cu
timpul funcționalitatea de telefon a fost trecută că opțională.
Aplicațiile pe Android sunt prezente într -un număr foarte mare. Principala sursă de aplicații
o reprezintă magazinul oficial Google Play, însă acestea pot fi luate și din alte surse sau chiar
instalate direct pe dispozitiv dacă utilizatorul are fișierul APK al aplicației dorite. La nivelul lunii
Martie 2017 pe Google Play se află mai mult de 2800000 de aplicații (Conform The Statistic s
Portal ) fiind în fruntea clasamentului în ceea ce privește numărul de aplicații disponibile pentru
fiecare sistem de operare pentru dispozitive mobile. În momentul de față , Androidul se află tot pe
primul lor și în ceea ce privește extinderea sa din pun ct de vedere al cotei sale de piață, ocupând
64% din totalul dispozitivelor mobile (conform www.netmarketshare.com ).

Google Play, inițial Android Market, este o platformă de distribuție digitală operat de
Google. Servește ca App Store oficial pentru sis temul de operare Android, care permite
utilizatorilor să navigheze și să descărce aplicații dezvoltate cu SDK -ul Android și publicate prin
intermediul Google. Google Play de asemenea, servește ca un magazin digital media, oferind
muzică, reviste, cărți, fi lme și programe de televiziune. Acesta a oferit anterior dispozitive
hardware Google pentru cumpărare până la introducerea unui retailer separat hardware on -line,
Google Store, la 11 martie 2015. Google utilizează un sistem de antivirus in -house automate,
numit Google Bouncer, pentru a elimina aplicații malware încărcate pe piață. Acest lucru este
menit să prevină repetarea dezvoltatori -infractor, precum și de verificare a unor anomalii în
aplicații încărcate. Bouncer este creditat la reducerea malware cu 4 0% dintre primul și al doilea
trimestru din 2011. Înainte de a instala o aplicație, Google Play afișează toate permisiunile care o
aplicație necesită. Un joc poate fi necesar să activați vibrații, de exemplu, dar nu ar trebui să
citească mesaje sau accesa datele din agenda de contacte a utilizatorului. După trecerea în revistă
acestor permisiuni, utilizatorul poate decide dacă pentru a instala aplicația. Permisiunile
aplicației posibile includ funcționalități cum ar fi: cccesul la Internet, efectuarea de ap eluri
telefonice, trimiterea de mesaje SMS, citirea și scrierea de la pe cardul de memorie instalată,
accesarea datelor din agenda unui utilizator.
Analizând atât avantajele și dezavantajele ale celor două sisteme de operare și de asemenea
experiența mea în ceea ce privește dezvolatrea aplicațiilor mobile, am ajuns la concluzia că cel
mai potrivit sistem de operare pentru dezvoltarea lucrării de dizertație este Androidul.
4.2.3 Arhitectura sistemului de operare Android
Android este proiectat sub forma unei stive software împărțite în cinci secțiuni, care la rândul lor,
pot fi structurate pe patru nivele, care cuprinde aplicații, un sistem de operare, de mediu run –
time, middleware, servicii și biblioteci. Aceasta arhitectura poate, probabil, cel mai bine să fie
reprezentate vizual așa cum se arată în figura următoare . Fiecare strat al stivei, iar elementele
corespunzătoare din fiecare strat, sunt strâns integrate și reglate cu grijă pentru a oferi
dezvoltarea aplicare optimă și mediul de execuție pentru dispozitive mobile. Android , 64.43iOS, 31.99Windows Phone ,
1.34Java ME , 0.98Symbian , 0.39 BlackBerry , 0.82 Altele , 0.03Cota de piață a sistemele de operare pentru
dispozitive mobile ( Iunie 201 7)
Android
iOS
Windows Phone
Java ME
Symbian
BlackBerry
Altele

Figura 1 – Reprezentarea grafică a nivelelor Sistemelui de operare Android
Kernelul Linux este cel mai de jos nivel al Androidului, iar versiunea sa curentă este Linux
Kernel 3.6 . Acesta oferă un nivel al abstractizării între hardware -ul dispozitivului și conține
driver -ele pentru diferitele componente hardware (ecran, cameră foto, tastatură, antenă WiFi,
memorie flash, dispozitive audio), fiind responsabil cu gestiunea proceselor, memoriei,
perifericelor (audio/video, G PS, WiFi), dispozitivelor de intrare/ieșire, rețelei și a consumului de
energie.
Biblitecile Androidului sunt liantul dintre kernel și aplicații. Printre aceste biblioteci se află
motorul de căutare open -source WebKit, librăria libc (Bionic), baza de date SQLite utilizată atât
ca spațiu de stocare cât și pentru partajarea datelor specifice aplicațiilor, biblioteci utilizate
pentru redarea și înregistrarea de fișiere audio și video, Librării SSL responsabile pentru
securitatea pe internet și multe altele.
Al doile nivel a arhitecturii sistemului, pe lângă bibliotecile specifice, se mai află Android
Runtime. Acest segment este alcătuit dintr -un set de biblioteci ale procesorului, care permit
dezvoltatorilor de aplicații Android să folosească limbajul standard de programare Java. Pe lângă
aceste biblioteci se mai află și mașina virtuală dezvoltată și optimizată pentru Android, numită
Dalvik. Acestă mașină virtuală utilizează regiștri, fiind echipată cu un compilator JIT (just -in-
time), executabilul obținut putâ nd fi modificat când este instalat pe dispozitivul mobil. Întrucât
este utilizată o bibliotecă proprie ce pornește de la un subset al implementării Java realizată de
Apache Harmony, nu sunt conținute pachetele pentru AWT / Swing, imprimare sau alte
compone nte speciale. De asemenea, se permite ca fiecare aplicație Android să ruleze în procesul
propriu, într -o instanță a mașinii virtuale Dalvik.
Framework -ul pentru Aplicații este al treiea nivel al arhitecturii. Aceste oferă servcii de nivel
înalt sub formă de clase Java, astefl încât programatorii le pot folosi în dezvoltarea aplicațiilor
lor. Aceasta este prima parte în care programatoru are contact direct cu sistemul de operare.
Aplicațiile reprezintă cel mai înalt nivel al sistemului de operare. Prin ace st nivel se face legătura
cu utilizatorul, aici fiind instalate toate aplicațiile și widget -urile care îi sunt destinate. Ca
dezvoltatori, avem posibilitatea de a înlocui orice aplicație deja existentă a sistemului. Acest
lucru ne dă libertatea de a folosi orice resurse, atâta timp câ utilizatorul acceptă permisiunile
cerute.

4.2.4 Dezvoltarea aplicațiilor
Aplicațiile pentru sistemul de operare Android sunt scrise în limbajul de programare Java.
Uneltele din SDK compilează codul, împreună cu toate fișierele de da teși resurse, și creează un
fișier APK (Android package) care este o arhivă. Acest fișier APK conține toate componentele
aplicației și este fisierul folosit de dispozitive pentru a instala aplicația.
Componentele unei aplicații Android sunt cărămizile din care se construiește o aplicație. Fiecare
componentă este un punct prin care sistemul poate accesa aplicația. Nu toate componentele sunt
puncte de intrare pentru user, iar unele depind unele de altele, însă fiecare există ca o entitate
separată și joacă u n rol specific care ajută să definească comportamentul final al aplicației.
Exista patru tipuri de componente, fiecare cu un scop diferit și fiecare cu ciclul ei de viață care
defineste cum este creeată și distrusă componenta.
Cele patru tipuri de compone nte sunt:
– Activitățile
– Serviciile
– Content provider
– Broadcast receiver
Activitățile reprezintă un ecran cu o interfata utilizator, putand exista in aplicație oricât de multe
activități. Chiar dacă împreună creează o experiență coezivă fiecare act ivitate este independentă
de celelalte și dacă aplicația o permite, alte aplicații pot porni oricare dintre activitățiile aplicației
noastre. Activitățile sunt implementate ca subclase ale clasei Activity și au fiecare ciclul lor de
viață.
Serviciile sunt componente care rulează în spate pentru a realiza operații mari consumatoare de
timp sau realizează calcule pentru alte procese. Un serviciu nu are o interfață cu utilizatorul. Spre
exemplu într -un serviciu se poate realiza operația de cautare de date pe i nternet fără a deranja
utilizatorul cu o activitate nouă. Serviciile pot fi pornite de alte componente, cum ar fi o
activitate, acesta putând fi lăsat să ruleze sau se poate lega de acesta pentru a putea interacționa
cu el. Serviciile sunt implementate ca subclase ale clasei Service.
Un content provider administrează un set de date ale aplicației. Datele pot fi stocate in sistemul
de fisiere, într -o bază de date SQLite, pe internet sau pe orice sistem de salvare de date pe care
aplicația îl poate accesa. Pr in furnizorul de conținut alte aplicații pot interoga sau chiar modifica
datele, dacă aceasta este permisa. Un content provider este implementat ca subclasa a clasei
ContentProvider și trebuie să implementeze un set de API -uri care permit altor aplicații s ă facă
tranzacții asupra datelor.
Broadcast receiver este o component care răspunde la anunțuri transmise la nivelul întregului
sistem. Multe dintre aceste anunțuri pornesc de la sistemul de operare, cum ar fi anuntul ca
ecranul s -a stins, sau ca nivelul b ateriei este scazut. Aplicațiile pot initia și ele mesaje de
broadcast spre exemplu pentru a anunța că un fisier s -a terminat de descarcăt și e pregătit pentru
a fi utilizat. Acestea nu pot afișa o interfață cu utilizatorul însă pot crea notificari in stat us bar,
pentru a notifica utilizatorul cand un eveniment a avut loc. un broadcast receiver este
implementat ca o subclasa a clasei BroadcastReceiver si fiecare broadcase este livrat ca un obiect
Intent.
Un aspect unic al designului sistemului Android este ca orice aplicație poate porni orice
componenta a altei aplicații. Cand sistemul porneste o componenta, el porneste procesul pentru
acea aplicație, dacă nu ruleaza deja, si instantiaza clasele necesare componentei. Deoarece
sistemul ruleaza fiecare aplicaț ie in procese separate cu permisiuni care restrictioneaza accesul la

alte aplicatii, aplicatia curenta nu poate activa direct componente ale altei aplicatii, însă sistemul
Android poate. Pentru a activa o componenta a altei aplicatii trebuie transmis un me saj
sistemului care specifica un intent de a porni o componenta, iar sistemul se ocupa de activarea
componentei.
Trei din cele patru componente, activități, servicii și broadcast receiver, pot fi activate printr -un
mesaj asincron numit intent. Intenturile leagă componente individuale una de cealalta la runtime,
indiferent carei aplicatii ii corespunde componentele.
Înainte ca sistemul să poată porni o componenta a unei aplicatii, trebuie mai întai să știe că
componenta există. Aceasta se realizeaza prin ci tirea fișierului AndroidManifest.xml în care
fiecare aplicație își declară componentele.
Acest fișier face mai multe lucruri decât să declare doar componentele unei aplicatii, cum ar fi:
– Identifică orice permisiune care e necesară bunei funcționări a ap licației (acces la internet,
acces la Calendar etc.)
– Declară nivelul minim de API pe care poate rula aplicația, bazat pe ce API -uri folosește
aplicația
– Declară caracteristici hardware și software folosite sau necesare de aplicație (camera, bluetooth
etc.)
4.2.5 Activități
Din punct de vedere al utilizatorului, cea mai impotantă componentă a sistemlui de operare
Android, sunt activitățile. Acestea sunt liantul dintre utilizator și aplicație, oferind ferestre cu
care 19 utilizatorul va interacționa. Diferind față ce alte sist eme de operare, în Android,în general
într-un moment de timp, se va afișa o singură fereastră pe ecranul dispozitivul, dar există și
situații în care ferestrele vor pluti deasupra altor ferestre. De asemenea, legătura dintre ferestrele
aplicației este acee a că o fereastră va da naștere mai multor ferestre, iar prima, cea care apare în
momentul lansării aplicației, este considerată fereastra principală. De fiecare dată când o
activitate nouă este pornită, activitatea din care s -a plecat se va opri, însă ea e ste păstrată într -o
stivă folosită pentru naviga înapoi folosind butonul back.
Din punct de vedere al programatorului, activitățile sunt clase care se extind din clasa
Activity, iar interacțiunea cu această clasă se va face prin evenimente. La generarea fiecărei clase
de tip Activitate, acesteia i se va atribui un fisier de tip XML. Acest fișier conține design -ul
interfeței grafice, care include elementele ferestrei, care la rândul lor au anumite caracteristici:
poziționarea, dimensiunile, culoarea, textul de pe ele. Pentru setarea fiecărei proprietăți se va
scrie un parametru de tip proprietate = „valoare”.
Pentru a face legătura dintre elementele fișierului XML si fișierul JAVA, este nevoie să mai
adăugăm o proprietate elementului numită ID, în fișierul XML, iar în fișierul JAVA vom
indentifica elementul dorit prin funcția „findView ById(R.id.ID)”.
Fiecare activitate a unei aplicții are propria stare, iar datele acesteia pot fi salvate sau
restaurate.Fiecare activitate are propriul său ciclu de viață, independent de ciclul de viață al
procesului asociat aplicației. Acesta arată stare a în care se află o activitate la un moment dat.
O activitate va conține câteva metode de callback, cu ajutorul cărora se va modifica starea
curentă a aplicației. Aceste metode sunt:

• onCreate(Bundle) – În această metodă se fac setările globale, spre exemp lu stabilirea
layoutului. Când activitatea este creată folosind argumentul metodei de tip Bundle
există posibilitatea a restabiliti starea activității, salvate într -o sesiune anterioară. O
dată cu această metodă începe și viața activității.
• onStart() – Apelată în mometul în care activitatea urmează să fie afișată. Începând cu
acestă metodă, activitatea este vizibilă și în prim -plan.
• onPause() – Metoda prin care activitea este întreruptă, pierde prim -planul și este
mutată în fundal.
• onResume() – Se va ape la în momentul în care activitatea redevine vizibilă
• onStop() –Apelata în cazul în care activitatea nu mai este utilizată și nu mai este
vizibilă
• onDestroy() – Metoda este apelată în cazul în care activitatea este distrusă , iar
memoria sa eliberată. În acest moment se termină și viața activității.
Durata în care activitatea are focus -ul (este principala activitate cu care utilizatorul
interacționează și nu este obscurată de nici o altă activitate) se află între apelurile metodelor
onStart() și onPause( ). O activitate poate oscila frecvent între a avea focusul și a nu -l avea, spre
exemplu onPause() este apelată cand dispozitivul intră în starea de sleep sau când este afișat un
mesaj pe ecran. Deoarece aceste tranzitii sunt frecvente, codul din aceste met ode ar trebui sa fie
nu foarte intensiv din punct de vedere computațional pentru ca tranzitiile dintre stări sa fie foarte
rapide.În funcție de metoda apelată într -un anumit moment, de -a lungul duratei de viață a
activității, aceasta se poate afla în trei stări:
o Activă – Activitatea a fost creată/pornită și este afis ată pe ecranul dispozitivului
o În stare de pauză – Activitatea pierde focus -ul
o Oprită – activitatea nu mai este în uz
o Distrusă – activitatea este distrusă și memoria este eliberată

Figure 1 – Ciclul de viață al unei activități

4.2.6 Fragmente
O componentă importantă în realizarea designului unei activități o reprezintă fragmentele.
Un fragment reprezintă un comportament sau o porțiune de interfață cu utilizatorul într -o
activitate. Puteți combina mai multe fragmente într -o singură activitate pentru a construi o
interfață multipanou și reutiliza un fragment în mai multe activități. Vă puteți gândi la un
fragment ca o secțiune modulară de activitate, care are propriul său cicl u de viață, primește
propriile evenimente de intrare, și pe care le puteți adăuga sau elimina în timp ce activitatea se
execută (ca un fel de " subactivitate" pe care le poti reutiliza în diferite activități).
Un fragment trebuie să fie întotdeauna încorpo rat într -o activitate, iar ciclul său de viață este
direct afectat de ciclul de viață al activității gazdă. De exemplu, atunci când activitatea este
întreruptă, la fel sunt toate fragmentele din acesta, iar când activitatea este distrusă, la fel sunt
toate fragmentele. Cu toate acestea, în timp ce o activitate se execută (ciclul de viață al acesteia
este în starea de reluat), puteți manipula fiecare fragment independent, cum ar fi adăugați sau să
le eliminați. Când efectuați o astfel de tranzacție de fragme nt, puteți, de asemenea adăuga o stivă
care este gestionat de activitate (fiecare intrare în stivă este o înregistrare a tranzacției fragment
care a avut loc). Stiva permite utilizatorului de a inversa o tranzacție fragment (mergeți înapoi),
apăsând butonu l Back.
Când adăugați un fragment ca parte a layout -ului unei activități, acesta trăiește într -un
ViewGroup. Puteți insera un fragment în aspectul activitații declarând fragmentul în dosarul
activității, ca un element , sau de la codul aplicație prin adăugarea unui ViewGroup existent. Cu
toate acestea, un fragment nu trebuie să fie o parte din structura activitații; puteți utiliza, de
asemenea, un fragment fără propriul UI ca un lucrător invizibil pentru activitate.
O mare facilitate utilizării fragmen telor într -o activitate este posibilitatea de a adăuga,
elimina, înlocuiși de a efectua alte acțiuni cu ele, ca răspuns la interacțiunea cu utilizatorul.
Fiecare set de modificări pe care le angajează cu activitatea se numește tranzacție și se pot
efectua una care utilizează API -uri în FragmentTransaction. De asemenea, putem salva fiecare
tranzacție ca o stivă gestionată de activitate, permițând utilizatorului pentru a naviga înapoi prin
modificările fragmentului (similar cu navigarea înapoi prin activități ).
Pentru a creea un fragment trebuie sa creem o clasă care să extindă clasa Fragment, care are
un cod similar cu cel al unei activități având foarte multe metode pentru ciclul de viață similare
cu cele ale unei activități: onCreate(), onStart(), onPause() și onStop().
În general, pentru un fragment trebuie implementate urmatoarele metode:
– onCreate() în care se inițializează componente importante ale fragmentului
– onCreateView(), metoda specifică fragmenteleor, care este apelată în momentul în care
fragm entul este pregătit pentru a fi desenat pe interfața pentru prima dată. Pentru a desena
interfața fragmentului aceasta metoda trebuie să returneze un obiect de tip View care va fi baza
interfeței acestui fragment. Dacă metoda returnează null atunci fragmen tul va fi unul invizibil
fără interfață cu utilizatorul.
– onPause(), metoda care e apelată de sistem la prima indicație ca utilizatorul părăsește
fragmentul. În această metodă ar trebui salvate orice modificare ce a avut loc în fragment și
trebuie să fie persistentă.
Majoritatea aplicațiilor ar trebui să implementeze măcar aceste trei metode pentru fiecare
fragment, însă și celelalte metode callback sunt utile în diverse situații.

– DialogFragment care afișează un fragment plutitor deasupra activității, o alternativă la
metodele din activitate care pot creea ceva similar, având însă avantajul că acesta poate fi
adăugat în stiva back
– ListFragment care, așa cum îi spune și numele, afișează o listă de elemente administrată de un
adaptor, similar obiectelor ListActivity
– PreferenceFragment care afișează o listă de obiecte Preference, similar obiectelor de tip
PreferenceActivity, utilă în creearea ecranelor de setări ale unei aplicații
Utilizarea fragmentelor în lucrarea de față s -a făcut utilă în momentul creării meniului din stânga
ecranului, care conține toate modulele prin care utilizatorul poate naviga.
4.2.7 Interfața grafică
Modelele definesc structura vizuală a interfeței utilizator, cum ar fi interfața grafică a unei
activități sau a unui fragment. Eleme ntele de aspect pot fi declarate la început în fișierele XML
sau pot fi instanțiate la timpul de execuție. Deci, programatorul le poate manipula programat.
Fiecare fișier XML trebuie să conțină doar un singur element rădăcină. Odată ce elementul
rădăcină e ste definit, putem adăuga obiecte suplimentare de aspect sau widget -uri ca elemente
copil ale rădăcinii, care se numește părinte. Interfețele grafice pot fi construite astfel încât să
obținem o ierarhie de vizualizare care definește designul nostru. Un obi ect de vizualizare poate
avea asociat un ID de tip întreg, care este un identificator unic al elementului. Atunci când este
atribuit de către programator, ID -ul este atribuit ca un șir, dar la compilare, ID -ul este referit de
către OS ca un întreg. LinearL ayout este unul dintre cele mai frecvent utilizate tipuri de elemente
rădăcină. Este definit ca un aspect care aranjează copiii din interiorul acestuia într -un singur rând
sau coloană. Direcția rândului poate fi aleasă prin setarea orientării (orizontală s au verticală).
Alinierea elementelor copilului este stabilită prin schimbarea gravității fiecărui element.
Aspectul relativ afișează vederile care sunt copilul său în poziții relative. Pentru fiecare
vizualizare putem specifica poziția care trebuie să fie relativă la celelalte elemente sau la părinte.
4.2.8 Intent
O intenție în sistemul de operare Android este un mecanism software care permite
utilizatorilor de a coordona funcțiile diferitelor activități pentru a realiza o sarcină. Un Intent este
un obiect de me sagerie, care prevede o facilitate pentru efectuarea cu întârziere de execuție între
22 codul între diverse aplicații în mediul de dezvoltare Android. Utilizarea sa cea mai importantă
este lansarea de activități, în cazul în care acesta poate fi gândit ca un liant între activități.
Intențiile oferă un sistem de mesagerie inter -aplicație care încurajează colaborarea și reutilizarea.
O intenție este de fapt o structură de date pasivă care deține o descriere abstractă a unei
acțiuni care urmează să fie efectua te.
Conceptul a fost creat ca o modalitate de a permite dezvoltatorilor adaptarea cu ușurință
diferitelor aplicații și permite fiecărui tip de sarcini (denumit activitate) să fie manipulate prin
aplicarea cea mai potrivită pentru el, chiar dacă sunt furniz ate de către o terță parte. Deși
conceptul nu era nou, arhitectura Android nu are nevoie de privilegii ridicate pentru a accesa
componentele, caracteristică care o face o platformă deschis.
Activitățile în Android sunt definite ca clase care controleaza ci clul de viață al unei sarcini în
interfața cu utilizatorul. Activitățile susținute de o cerere sunt declarate într -un manifest, astfel

încât alte aplicații să poată citi ce activități sunt acceptate. Intențiile într -o aplicație pot începe
activitățile spec ifice într -o altă aplicație.
O analiză în 2011 de cercetari de la Universitatea din California, la Berkeley au descoperit ca
Intenții poate presupune un risc de securitate, permițând atacatorilor să citească conținutul în
mesaje și pentru a introduce mesaj e malware între aplicații.
4.3 Recunoșterea optic ă a caracterelor
Recunoașterea optică a caracterelor (OCR) este conversia mecanică sau electronică a
imaginilor care conțin text, scrise de mână sau de tipar, fie dintr -un document scanat, dintr -o
fotografie di ntr-un document sau direct dintr -un fișier video, in care recunoșterea se vafe e
fiecare cadru in parte. Acest algoritm este este utilizat pe scară largă ca formă de introducere a
informațiilor din înregistrările de hârtie tipărite, documente de pașaport, facturi, extrase bancare,
chitanțe computerizate, cărți de vizită, corespondență, imprimate de date statice sau orice
documentație adecvată. Este o metodă obișnuită de digitizare a textelor tipărite, astfel încât
acestea să poată fi editate, căutate, stoca te mai compact, afișate on -line și folosite în procesele de
mașină, cum ar fi computerele cognitive, traducerea automată, textul în vorbire, date cheie și
data mining de text. OCR este un domeniu de cercetare în recunoașterea modelului, inteligența
artific ială și viziunea pe calculator.
Există două tipuri de bază ale algoritmului OCR, care pot produce o listă clasată de
caractere.
Matricea de potrivire presupune compararea unei imagini cu un glif stocat pe o bază pixel –
cu-pixel; Este, de asemenea, cunoscut ca "potrivire model", "recunoașterea model", sau
"corelarea imaginii". Aceasta se bazează pe faptul că glisorul de intrare este corect izolat de
restul imaginii, iar gliful stocat este într -un font similar și la aceeași scară. Această tehnică
funcționează cel mai bine cu textul scris de mașină și nu funcționează bine atunci când se
întâlnesc noi fonturi. Aceasta este tehnica aplicată, mai degrabă în mod direct, OCR pe bază de
fotocelule timpurie.
Extragerea caracteristicilor descompune glifurile în "caract eristici", cum ar fi linii, bucle
închise, direcții de linie și intersecții de linii. Caracteristicile de extracție reduc dimensionalitatea
reprezentării și fac din procesul de recunoaștere un computațional eficient. Aceste caracteristici
sunt comparate cu o reprezentare abstractizată de vector a unui personaj, care ar putea reduce la
unul sau mai multe prototipuri de glif. Tehnicile generale de detectare a caracteristicilor în
viziunea pe calculator sunt aplicabile acestui tip de OCR, care este văzut de ob icei în
recunoașterea "inteligentă" a scrisului de mână și, într -adevăr, cea mai modernă aplicație OCR.
[23] Cel mai apropiat clasificator de vecini, cum ar fi algoritmul k -cel mai apropiat vecin, este
utilizat pentru a compara caracteristicile imaginilor cu caracteristicile memorate ale glifului și
pentru a alege cel mai apropiat meci [24].
Software -ul cum ar fi Cuneiform și Tesseract folosesc o abordare dual -pass pentru
recunoașterea caracterelor. Cea de -a doua trecere este cunoscută sub numele de "recuno aștere
adaptivă" și folosește formele litere recunoscute cu mare încredere în prima trecere pentru a
recunoaște mai bine literele rămase de pe a doua trecere. Acest lucru este avantajos pentru
fonturi neobișnuite sau scanări de calitate scăzută în cazul în care fontul este distorsionat (de ex.
Estompată sau estompată). [21]
Rezultatul OCR poate fi stocat în formatul standard ALTO, o schemă dedicată XML
menținută de Biblioteca Congresului Statelor Unite ale Americii.

4.4 Trecerea de la text la vorbire
Sinteza s intezei este producția artificială a discursului uman. Un sistem informatic utilizat în
acest scop este numit un computer de vorbire sau un sintetizator de vorbire și poate fi
implementat în produse software sau hardware. Sistemul text -to-speech (TTS) conv ertește textul
limbajului obișnuit în vorbire; Alte sisteme fac reprezentări lingvistice simbolice precum
transcripțiile fonetice în vorbire. [1]
Discursul sintetizat poate fi creat prin concatenarea pieselor de vorbire înregistrate care sunt
stocate într -o bază de date. Sistemele diferă în funcție de mărimea unităților de vorbire stocate;
Un sistem care stochează telefoane sau difoneze oferă cel mai mare interval de ieșire, dar poate fi
lipsit de claritate. Pentru domeniile specifice de utilizare, stocarea cuvintelor întregi sau a
propozițiilor permite obținerea unei producții de înaltă calitate. Alternativ, un sintetizator poate
încorpora un model al tractului vocal și al altor caracteristici ale vocii umane pentru a crea o
ieșire vocală complet "sintetică ". [2]
Calitatea unui sintetizator de vorbire este judecată prin similitudinea sa cu vocea umană și
prin capacitatea sa de a fi înțeles clar. Un program inteligibil text -to-speech permite persoanelor
cu deficiențe de vedere sau cu dizabilități de citire să asculte cuvinte scrise pe un computer de
acasă. Multe sisteme de operare computerizate au inclus sintetizatoare de voce de la începutul
anilor 1990.
Text de vorbireText to speech, prescurtat TTS, este o formă de sinteză de vorbire care
convertește textul în voce. Sistemele text -to-speech au fost mai întâi dezvoltate pentru a ajuta
persoanele cu deficiențe de vedere, oferind o voce generată de computer, care ar "citi" textul
pentru utilizator.
TTS nu ar trebui să fie confundat cu sistemele de răspuns vocal. Sistemele de răspuns de
voce sintetiza vorbire concaternând exemple dintr -o bază de date de cuvinte preînregistrate și
sunt utilizate pentru alte scopuri decât sistemele TTS, care formează propoziții și / sau fraze
bazate pe grafeme și foneme unei limbi l ui străine. Sistemele de răspuns vocale sunt limitate la
sintetizarea frazelor care conțin numai cuvinte care au fost predeterminate de către sistem.
Sistemele TTS, în contrast, teoretic sunt capabile de "citire" a orcărui șir de caractere de text
pentru a forma fraze originale.
4.5 Google API
API (Application Programming Interface) este un set de definiții de subrutine, protocoale sau
instrumente pentru construirea de aplicații software. În termeni generali, este un set de metode
clar definite de comunicare în tre diferite componente software.
API-urile Google reprezintă un set de interfețe de programare a aplicațiilor (API) dezvoltate
de Google care permit comunicarea cu serviciile Google și integrarea acestora în alte aplicații
software . Exemplele acestora i nclud Search , Gmail, Traducere sau Hărți Google. Aplicațiile
software pot utiliza aceste API -uri pentru a profita sau a extinde funcționalitatea serviciilor
existente. API-urile furnizează funcționalități precum analiza, învățarea automată ca serviciu
(API -ul de predicție) sau accesul la datele utilizatorului (când este dată permisiunea de a citi
datele).
Sistemul de operare Android permite să converți textul în voce. Nu numai că puteți converti,
dar, de asemenea, vă permite setarea într -o varietate de lim bi diferite.

Android oferă clasa TextToSpeech pentru acest scop. Pentru a putea utiliza această clasă,
trebuie să instanția un obiect al acestei clase și specifica, de asemenea, initListeners.
În acest listener, trebuie să specificați proprietățile pentru obiectul TTS, cum ar fi limba,
rapiditatea etc. Limba poate fi setat prin apelarea metodei setLanguage(). În prezent, limbile
acceptate includ Bengaleză , Cantoneză (Hong Kong), Chineză (China) , Olandeză, Engleză
(India), Engleza (Marea Britanie), Engleza (Statele Unite), franceză, germană, hindi,
indoneziană, italiană , japoneză, coreeană, poloneză, portugheză (Brazilia), rusă, spaniolă și
Turca. Text-to-Speech poate fi utilizat de aplicații, c um ar fi Google Play Books pentru citirea
cărților cu voce tare, de Google Translate pentru citirea cu voce tare traduceri care furnizează
informații utile despre pronunțarea de cuvinte, de către Google TalkBack și alte aplicații bazate
pe accesibilitate p entru feedback vocal, precum și de aplicații third -party.
Google Auto un mini Sistem de operare utilizat în domeniul automobilelor, care
facilitează interacțiunea utilizatorului cu dispozitivul mobil pentru a nu -l distrage pe acesta de la
condus. Atăt ceri nțele utilizatorului cât și feedback -ul dispozitivului mobil se poate realiza
exclusiv folosind vocea.
Google Now este un produs nou Google, în care interacțiunea utilizatorului cu telefonul
mobil se face prin voce, iar răspunsul dispozitivul vine de aseme nea printr -un semnal vocal.
Pornirea acestui serviciu se face prin rostirea “Ok Google” urmată de întrebarea pe care vrem sa
o punem. Acest produs este unu complex, care are la bază și principii de Inteligență Artificială.
De exemplu o întrebare de tipul “ Who is the president of USA?”, poate fi urmată de întrebarea
“How old is he?” fără a mai fi nevoie să specificăm persoane despre care s -a vorbit.

5 Implementarea soluției adoptate
În momentul actual dispozitivele mobile inteligente sunt omniprezente în viața noastră de zi
cu zi, iar conexiunea la internet este ca și o necesitate pentru acestea. Această disponibilitate a
puterii de calcul și a conectivității în mâna utilizatorului fi nal face posibilă crearea de aplicații
din ce în ce mai inventive și mai utile, care să ușureze viața utilizatorului.
Proiectul pe care doresc să îl elaborez conține o aplicație destinată sistemului de operare
Android, care combină camera telefoanelor mob ile, cu principiile realității argumentate si
folosește câteva API -uri realizate de Google pentru a recunoaște și citi texte, atât din imagini, cât
si direct folosin camera telefonului.
Din punct de vedere al dezvoltării aplicației, aceasta trebuie să fie modular și usor
extensibilă pentru a înlesni o dezvoltare continuă a experienței pe care o oferă.
5.1 Platforma si mediu de dezvoltare
Printre cele mai importante decizii la începerea dezvoltarii unui proiect îl reprezintă alegerea
platformelor cărora o să le fie dedicate, urmat de alegerea mediului de dezvoltare ce va fi folosit.
O dată ce am ales sistemul de operare, urmatorul pas este de alegere a mediului de dezvoltare în
care se va lucra. Din punctul meu de vedere alegrea este de făcut între doua medii: E clipse și
Android Studio.
Android Studio este IDE -ul oficial pentru dezvoltarea de aplicații Android, bazat pe IntelliJ
IDEA. Prima versiune oficială a acestui IDE, Android Studio 1.0, a fost lansată în Decembrie
2014, iar în momentul de față, cea mai rec entă versiune este Android Studio 2.3.3 , care a fost
lansată în 8 Iunie 2017. În lu area deciziei de a folosi acest IDE, în defavoarea mediului de
dezvoltare Eclipse, au contribuit câteva caracteristici prin care Android Studio a devenit superior
Eclipse -ului, pentru dezvoltarea aplicațiilor mobile dedicat Android -ului. Câteva dintre aceste
caracteristici sunt:
• Este un sistem flexibil, bazat pe Grandle
• Șabloane de cod care ajută la creare unor caracteristici comune pentru aplicații
• Editor cu aspect bogat c are are suport pentru drag and drop
• instrumente ”lint” pentru a vizualiza performanța, usurința în utilizare,
compatibilitatea versiunilor și alte probleme
Pentru utilizarea acestui IDE este nevoie de minim 3 GB de RAM, dar recomandat sunt 4
GB, iar în ce ea ce privește spațiul pe disc, este nevoie de cel puțin 1 GB în care vor fi incluse
Android SDK și emulatorul.
5.2 Creearea proiectului Android
Primul lucru care trebuie făcut pentru implementarea aplicației Virtual Bookstore pentru
dispozitive Android este d e a crea un proiect Android în Android Studio. Acest lucru se face
selectând File – New Project. Următorul pas este să configurați noua aplicație:
• Numele aplicatiei: Read My Book
• Numele pachetului: com.daniela.project

• factorii de formă pe care se va distri bui aplicația: aici putem selecta (Telefon,
Tablet, Wear, TV, Android Auto, Glass) – în cazul aplicației am ales ca aceasta sa
fie disponiilă doar pentru telefoane și tablete, deoarece acestea au suportul
necesar pentru cea mai importantă parte de hardware din aplicație, camera
• SDK minim: aceasta reprezintă versiunea minimă Android necesară pentru
instalarea aplicației. În acest caz, minimul este de 15, ceea ce face ca aplicația să
fi compatibilă cu 98% din telefoanele cu Android
Noul nostru Proiect Android este acum creat și putem începe să lucrăm și să implementăm
funcțiile pe care le dorim.
5.3 Fișiere de configurare
Până la apariția IDE -ului Android Studio, într -un proiect Android exista un singur fișier
pentru configurarea proiectului, numit AndroidManifest .xml. Acest lucru s -a schimbat, Android
Studio fiind construit pe un sistem bazat pe Gradle.
Fișierul AndroidManifest.xml este un fișier esential aplicațiilor Android care trebuie să fie
prezent în orice aplicație. Acest fișier manifest prezintă informații le esențiale despre aplicație
către sistemul Android, informații pe care sistemul trebuie sa le aibă înainte de a rula codul
oricărei aplicații.
Gradle este un nou sistem puternic de management de dependențe pentru Java. Acesta oferă
posibilitatea de a con strui o logica mai personalizată decât predecesorii, cum ar fi Maven sau
Ant.
Android Studio foloseste un plugin Android Gradle care se ocupa de cele mai multe
integrării cu Gradle. Acest plugin vă permite să construiți versiuni diferite ale aplicației (de
exemplu, plătit și neplătit, personalizate pentru diverse dispozitive Android) în timp ce menține
aceeași bază de cod. De asemenea, permite semnarea APK.
Cele două fișiere prezintă anumite caracteristici, iar câteva dintre acestea le voi exemplifica
folos ind codul propriei aplicații. Caracteristicile sunt:
– pachetul Java al aplicației, care servește ca identificator unic pentru aplicație
<?xml version= "1.0" encoding= "utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package= "com.daniela.project" >

– Descrie componentele aplicației: activitățiile, serviciile, broadcast receiver -ele și content
providere -le din care aplicația este formată.
<activity
android:name=".ui.activities.SplashActivity"
android:theme="@style/AppTheme.NoActionBar" >
<intent-filter>
<action android:name="android.intent.action.MAIN" />

<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity >
– Declară permisiunile necesare aplicației pentru a putea accesa părți restrictionate ale
APIului și să interactioneze cu alte aplicații
<uses-feature android:name="android.hardware.camera" />
<uses-permission android:name="android.permission.CAMERA" /> (utilizată pentru a
cere acces la informatiile oferite de camera)

<uses-permission android:name="android.per mission.WRITE_EXTERNAL_STORAGE" />
(necesară pentru scrierea fișierelor în telefon)

<uses-permission android:name="android.pe rmission.READ_EXTERNAL_STORAGE" />
(necesară pentru citirea fișierelor din telefon)

<uses-permission android:name="android.permission.INTERNET" /> (necesară
pentru conectarea la internet)
– Declară nivelul minim al Android API (versiunea minimă de Android) necesare pentru
ca aplicația să poată rula
android {
compileSdkVersion 25
buildToolsVersion "25.0.2"
defaultConfig {
applicationId "com.daniela.project"
minSdkVersion 15
targetSdkVersion 25
versionCode 1
versionName "1.0"
testInstrumentationRunner
"android.support.test.runner.AndroidJUnitRunner"
multiDexEnabled true
}
}
– Precizează librăriile de care are nevoie aplicația
– dependencies {
compile fileTree( dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat -v7:25.2.0'
compile 'com.android.support.constraint:constraint -layout:1.0.0 -beta4'
compile 'com.google.android.gms:play -services -vision:10.2.0'
compile 'com.android.support:design:25.2.0'
compile 'com.android.support:support -v4:25.2.0'
compile ('com.google.apis:google -api-services -translate:v2 -rev47-
1.22.0')
compile ( 'com.google.cloud:google -cloud-translate:0.5.0' )
testCompile 'junit:junit:4.12'
}
5.4 Implementarea proiectului
5.4.1 CameraSource
Această clasă g estionează camera telefonului . Aceasta primește cadre de previzualizare de la
cameră la o rată specificată, trimițând acele cadre către detector cât de repede poate procesa acele
cadre.
Această sursă de cameră face un efort pentru a gestiona prelucrarea pe cadrele de
previzualizare cât mai repede posibil, în același timp minimizând întârzierea. Ca atare, cadrele
pot fi scăpate dacă detectorul nu poate ține pasul cu rata de cadre generată de aparatul de
fotografiat. Pentru a specifica o rată a cadrelor care funcționează bine cu capabilită țile hardware –
ului camer ei și opțiunile detectorului selectat e, ar treb ui să utilizați setRequestedFps (float). Dacă
utilizarea CPU este mai mare decât este nevoie , atunci se recomandă reducerea FPS. Dacă
previzualizarea camerei sau rezultatele detectorului nu sunt concludente, atunci poate doriți să
luați în considerare creșterea FPS.
În interiorul clasei există mai multe metode care au rolul de a seta proprietățiile camerei
astfel încăt aceasta să funcționeze cât mai eficient și să creeze o experianță plăc ută pentru user.

Utilizând aceste metode, putem porni sau opri camera sau putem seta rotația, zoom -ul, camera
folosită (față sau spate).
Din punct de vedere al performanței aplicației, cea mai importantă parte a clasei, este o
subclasă numită “ FrameProcess ingRunnable ”. Acest modul de control permite accesul la
receptorul principal, apelându -l la procesarea cadrelor atunci când este disponibil de la cameră.
Aceasta este concepută pentru a rula detectarea pe cadre cât mai repede posibil (adică fără
comutarea contextului inutil sau așteptare în cadrul următor).
În timp ce detecția funcționează pe un cadru, pot fi recepționate cadre noi de la cameră. Pe
măsură ce aceste cadre intră, cel mai recent cadru este păstrat în așteptare. De îndată ce
detectarea și pro cesarea asociată acesteia sunt efectuate pentru cadrul anterior, detectarea pe cel
mai recent primit cadru va începe imediat pe același fir.
void setNextFrame( byte[] data, Camera camera) {
synchronized (mLock) {
if (mPendingFrameData != null) {
camera.addCallbackBuffer( mPendingFrameData .array());
mPendingFrameData = null;
}

if (!mBytesToByteBuffer .containsKey(data)) {
return;
}
mPendingTimeMillis = SystemClock. elapsedRealtime () – mStartTimeMillis ;
mPendingFrameId ++;
mPendingFrameData = mBytesToByteBuffer .get(data);

mLock.notifyAll();
}
}
5.4.2 TextOverlay
Clasa are rolul de a creea un strat grafic deasupra imaginilor primite de la cameră. În acest
fel, se creează o legătură între realitate, imiaginile primate de la camera, și virtual, blocuri
generate folosind metode software. Acesta este punctul de pornire al realit ății virtuale în proiect .
Această clasă extinde clasa View. Ideea de funcționare este că elementele de detecție sunt
exprimate în termeni de dimensiune de previzualizare, dar trebuie să fie redimensionate până la
dimensiunea de vizualizare completă și, de asemenea, în cazul camerei orientate spre față acestea
trebuie oglindite oglindite.
Una dintre cele mai importante metode din această clasă este :
public T getGraphicAtLocation( float rawX, float rawY) {
synchronized (mLock) {
// Get the position of this View so the raw location can be offset
relative to the view.
int[] location = new int[2];
this.getLocationOnScreen(location);
for (T graphic : mGraphics ) {
if (graphic.contains(rawX – location[ 0], rawY – location[ 1])) {
return graphic;
}
}
return null ;
}
}

Metoda returnează primul bloc grafic care conține punctul de la coordonatele rawX si rawY sau
null dacă nu este detectat niciun text. Aceasta este folosită apoi în fragmentele aplicației, pentru a
citi textul selectat sau pentru a traduce respectivul text.
5.4.3 Activități si Fragmente
Aplicația este structurată în 3 activități si 6 fragmente.
Primul ecran cu care utiizatorul intră în contac t, se numește SplashScreen. Acesta este o
activitate destul de comun ă în cadrul aplicațiilor Android, iar în cazul aplicațiilor dezvoltate
pentru sistemul de operare iOS este un ecran a cărui prezență este obligatory în cazul în care
dezvoltatorul dorește ca aplicația sa să fie distrubuită în AppStore. Rolul acestuia este ca
utilizatorul să fie familiarizat cu culorile și logo -ul. În general acesta are o durată de afișare
scurtă (2 -3 secunde), dar există posibilitatea ca în timpul afisării acestuia să facem anumite
request -uri la server, spre exemplu pentru a sincroniza aplicația cu ultimele modi ficări aduse
unei baze de date. Astfel, aplicația va fi gata de folosit în momentul în care ecranul dispare, fără
a mai fi nevoie să asignăm un timp extra, în care u tilizatorul nu poate avea interacțiune cu
aplicația.
Un alt ecran, pe care utilizatorul îl întălnește în primele interacțiuni, este TutorialActivity.
După cum îi spune și numele , acesta are rolul de a îndruma utilizatorul în utilizarea aplicați ei.
Acesta a pare o singură dată, atunci când utilizatorul deschide prima dată aplicația. Deși nu are un
rol decisiv în elaborarea lucrării, această activitate este una destul de complexă și folosește multe
funcționalități din Android. În implemetarea activității am fo losit un ViewPager, o schemă care
permite utilizatorului să răsfoiască la stânga și la dreapta prin paginile de date. Pentru a putea
folosi un ViewPager, este nevoie să furnizăm o implementare a unui PagerAdapter pentru a
genera paginile afișate. Ca și în cazul nostru, un ViewPager se folosește pentru a face scroll
printre mai multe fragmente, iar un PagerAdapter are rolul de a face legătura între frgmentele pe
care dorim să le afișăm și suportul lor. Tot în aceste ecran, aplicația e folosește de
SharedPreferences, o modalitate de a salva local, în fișierul ascuns al aplicației, informații sub
formă de cheie și valoare. Folosind SharedPrefereces, ținem cont dacă utilizatorul a intrat pentru
prima dată în aplicație sau nu. Pentru a inițializa și a utiliza SharedPreference am folosit
următorul cod:
private static final String PREF_NAME = "project" ;
private static final String IS_FIRST_TIME_LAUNCH = "IsFirstTimeLaunch" ;

public PrefManager(Context context) {
this._context = context;
pref = _context .getSharedPreferences( PREF_NAME , PRIVATE_MODE );
editor = pref.edit();
}

public void setFirstTimeLaunch( boolean isFirstTime) {
editor.putBoolean( IS_FIRST_TIME_LAUNCH , isFirstTime);
editor.commit();
}

public boolean isFirstTimeLaunch() {
return pref.getBoolean( IS_FIRST_TIME_LAUNCH , true);
}

Activitatea care este cel mai mult timp vizibilă pentru utilizator este DrawerActivity.
Aceasta are rol de suport entru fragmentele aplicației. Meniul principal al aplicației, care este
inclus în această activitate, este format dintr -un Navigation Drawer. Acesta este un panou care
afișează principalele opțiuni de navigare ale aplicației pe marginea din stânga a ecranului. Acesta

este ascuns cele mai mult e ori, dar este descoperit atunci când utilizatorul face swipe cu un deget
de la marginea din stânga a ecranului sau utilizatorul atinge pictograma aplicației în bara de
acțiune. O dată cu afișarea meniului restul ecranului este întunecat. Prin intermediul acestui
meniu putem naviga în interiorul aplicației. La selectarea oricărei opțiuni, se realizează imediat
schimbarea dorită, meniul ascunzându -se automat.
Deși activitățile au un rol important în dezvoltarea aplicației, dar caracteristicie importante
am ales sa le dezvolt prin fragmente . Acestea sunt: HomeFragment, ImageOcrFragment,
TranslateFragment, SearchFragment, CameraFragment și FilesFragment.
HomeFragment și FilesFragment au ca părinte direct DrawerActivity. HomeFragment are rol
de afișa posibilită țile pe care utilizatorul le are în aplicație.Aceasta conține 4 butoane care, prin
apăsarea fiecăruia, se apelează metoda prin care încarcă fragmentul specific.
private void startFragment(String backStackString) {
Fragment fragment = null;
Class fragmentClass = null;
switch (backStackString) {
case "TranslateFragment" :
fragmentClass = TranslateFragment. class;
break;
case "CameraFragment" :
fragmentClass = CameraFragment. class;
break;
case "ImageOcrFragment" :
fragmentClass = ImageOcrFragment. class;
break;
case "SearchFragment" :
fragmentClass = SearchFragment. class;
break;
}
fragment = (Fragment) fragmen tClass.newInstance();
FragmentManager fragmentManager = getActivity().getSupportFragmentManager();
fragmentManager.beginTransaction().replace(R.id. flContent ,
fragment).addToBackStack(backStackString).commit();
}

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!! FILESFRAGMENT
ImageOcrFragment este fragmentul prin care utlizaorul poate extrage textul afișat făcând o
poză textului dorit. Această funcționalitate este utilă în momentul în care utilizatorul dorește să
salveze textul sub format text sau audio. Pentru această funcționalitate, începem prin a porni
camera telefonului:
private void takePicture() {
Intent intent = new Intent(MediaStore. ACTION_IMAGE_CAPTURE );
File photo = new File(Environment. getExternalStorageDirectory (),
"picture.jpg" );
imageUri = Uri.fromFile (photo);
intent.putExtra(MediaStore. EXTRA_OUTPUT , imageUri );
startActivityForResult(intent, PHOTO_REQUEST );
}
Apelarea metodei startActivityForResult() pornește o activitate nouă, care în cazul
nostru este una dezvoltată direct de sistemul de operare Android, și așteaptă un rezultat de la
activitatea apelată . În mometul în care primim rezultatul așteptat, bitmap -u primit se transformă
în Frame, pe care îl putem trimite mai departe detectorul de text implemetat în GoogleOC R.
După aplicarea algoritmului, primim textul într -un obiect de tip TextBlock. Aceste Textblock îl
despărțim m ai departe îl linii și cuvinte, pe care le afișăm pe ecran la categoria de care aparțin.

Toate procesările făcute după ce imaginea este primită d e la cameră foto, pot fi regăsite în
acestă metodă:
@Override
public void onActivityResult( int requestCode, int resultCode, Intent data) {
if (requestCode == PHOTO_REQUEST && resultCode == RESULT_OK ) {
launchMediaScanIntent();
try {
Bitmap bitmap = decodeBitmapUri(getActivity(), imageUri );
if (detector .isOperational() && bitmap != null) {
Frame frame = new Frame.Builder().setBitmap(bitmap).build();
SparseArray<TextBlock> textBlocks = detector .detect(frame);
String blocks = "";
String lines = "";
String words = "";
for (int index = 0; index < textBlocks.size(); index++) {
TextBlock tBlock = textBlocks.valueAt(index);
blocks = blocks + tBlock.getValue() + "\n" + "\n";
for (Text line : tBlock.getComponents()) {
lines = lines + line.getValue() + "\n";
for (Text element : line.getComponents()) {
words = words + element.getValue() + ", ";
}
}
}
if (textBlocks.size() == 0) {
scanResults .setText("Scan Failed: Found nothing to scan" );
} else {
scanResults .setText( scanResults .getText() + blocks);
scanResults .setText( scanResults .getText() + lines + "\n");
scanResults .setText( scanResults .getText() + words + "\n");
}
} else {
scanResults .setText( "Could not set up the detector!" );
}
} catch (Exception e) {
Toast.makeText (getActivity(), "Failed to load Ima ge",
Toast.LENGTH_SHORT ).show();
}
}
}
!!!!!!!!!!!! SALVAREA DE FISIERE
CameraFragment este un alt fragment al aplicației. Acesta are o funcționalitate asemănătoare
cu primul fragment prezentat, dar implementarea s -a este diferită. În acesta am ales să
implementez utilizarea camerei dezvoltate în clasa CameraSource, fără a folosi clasele oferite de
Android pentru utilizarea camerei. În metoda de creare a fragmentului,
onCreateView(LayoutInflater inflater, ViewGroup container, Bundle
savedInstanceState) verificăm dacă utilizatorul a oferit utilizatorului posibi litatea de a folosi
camera, dacă nu avem permisiune aceasta se cere prin ActivityCompat. requestPermissions (), iar dacă
se obține permisiunea putem inițializa CameraSource . Frame -urile interceptate de la cameră, sunt
trimise către detectorul de text pentru a putea aplica algoritmul de detecție a textului. O dată ce
primim textul, vom apela GraphicOverlay pentru a afișa textul pe ecran. În continuare, pentru
fiecare bloc de text afi șat pe ecran are posibilitatea de a fi citit. Pentru citire textelor am folosit
TextToSpeech APi. Sistemul de operare Android permite să converți textul în voce. Nu numai că
putem converti textul în vorbire, de asemenea, vă permite setarea într -o varietat e de limbi
diferite.
Android oferă clasa TextToSpeech pentru acest scop. Pentru a putea utiliza această clasă,
trebuie să instanția un obiect al acestei clase și specifica, de asemenea, initListeners. Sintaxa sa
este prezentată mai jos:

TextToSpeech ttobj = new TextToSpeech(getApplicationContext(), new
TextToSpeech.OnInitListener() {
@Override
public void onInit(int status) {
}
}
);
În acest listener, trebuie să specificați proprietățile pentru obiectul TTS, cum ar fi limba,
rapiditatea vorbirii etc. Sintaxa de setare a limbii este prezentată mai jos:
ttobj.setLanguage(Locale.UK);
Odată ce a m setat limba, pute m apela metoda clasei speak() de a vorbi cu mesajul , dat ca
parametru.
ttobj.speak(message, TextToSpeech .QUEUE_FLUSH );
Message – mesajul de vorbit
TextToSpeech .QUEUE_FLUSH -mesajul va întrerupe textul vorbit anterior si va
începe imediat. Dacă acesta este schimbat cu TextToSpeech .QUEUE_ADD, atunci textul se
va adăuga într -o stivă de mesaje care vor fi redate în ordinea ad ăugării lor în
stivă.

5.5 Recunoașterea caracterelor
Pentru recunoșterea caracterelor în cadrul aplicației am folosit GoogleOCR API, care face
parte dintr -un proiect mai amplu GoogleVision, care are mai mult funționalități de recunoaștere,
printre care și recunoașterea ochilor sau a fețe i. Primul pas făcut de algoritm este o analiză a
componentelor din imagini , în care sunt stocate contururile componentelor. Aceasta este o
decizie de design computațional costisitoare la momentul respectiv, dar are un avantaj
semnificativ: prin inspectarea grupurilor de contur și a numărului de contururi ale copiilor și
nepoțilo r celui mai mare bloc de text , este simplu să se dete cteze textul și să se recunoa scă la fel
de ușor ca și negrul, textul alb. În acest stadiu, contururile sunt adunate, pur și simplu prin
grupuri , în Blobs. Bloburile sunt organizate în linii de text, iar liniile și regiunile sunt analizate
pentru text fix sau proporțional. Liniile de text sunt împărțite în cuvinte în mod uri diferit, în
funcție de tipul spațiilor de caractere. Recunoașterea continuă apoi ca proces de două treceri. În
prima trecere, se face o încercare de a recunoaște fiecare cuvânt la rândul său. Fiecare cuvânt
care este satisfăcător este transmis unui clasificator adaptiv ca date de antrenament.
Clasificatorul adaptiv are apoi șansa de a recunoaște cu mai multă precizie textul de jos în jos al
paginii. Deoarece clasificatorul adaptabil poate să fi învățat ceva util mai târziu, pentru a face o
contribuție în partea de sus a paginii, este necesară o a doua trecere peste pagină, în care
cuvinte le care nu au fost recunoscute suficient de bine su nt recunoscute din nou.
Prin folosirea librăriei puse la dispoziție de Google, toată procesarea se face în spate, iar în
aplicație este necesar ca noi să procesăm ceea ce rezultă după rularea algoritmului pe fiecare
cadru, în cazul fișierelor video sau di rect pe o imagine. În aplicația curentă, procesarea blocurilor

primite se face în două clase distincte, OcrDetectorProcessor si WordsFinder , ambele
implementând interfața Detector.Processor<TextBlock> care aparține librăriei.
În prima clasă, după ce primim detecțiile, acestea sunt adăugate în GraphicOverlau, pentru a
putea fi afișate pe ecran.
@Override
public void receiveDetections(Detector.Detections<TextBlock> detections) {
mTextOverlay .clear();
final SparseArray<TextBlock> items = detections.ge tDetectedItems();
for (int i = 0; i < items.size(); ++i) {
TextBlock item = items.valueAt(i);
OcrGraphic graphic = new OcrGraphic( mTextOverlay , item);
mTextOverlay .add(graphic);
}
}
A doua clasă, WordsFinder , funcționează pe același principiu, dar este puțin mai complexă.
Aceasta caută în detecțiile primite, cuvinte cheie stabilite de către utilizator, iar atunci când
acestea sunt găsite, utilizatorul primește un feedback audio care îi trasmite că cuvântul a fost
găsit.
@Override
public void receiveDetections(Detector.Detections<TextBlock> detections) {
mTextOverlay .clear();
final SparseArray<TextBlock> items = detections.getDetectedItems();
for (int i = 0; i < items.size(); ++i) {
TextBlock item = items.valueAt(i);
if (word != null) {
String value = item.getValue().toLowerCase();
word = word.toLowerCase();
if (value.contains( word)) {
OcrGraphic graphic = new OcrGraphic(mTextOverlay , item);
mTextOverlay .add(graphic);
if (Build.VERSION. SDK_INT >= Build.VERSION_CODES. LOLLIPOP ) {
tts.speak("Stop here. We found your word" ,
TextToSpeech. QUEUE_ADD , null, "DEFAULT" );
}
}
}

}
}
5.6 Probleme si dezavantaje ale abordarii alese
În acest capitol vom discuta problemele pe care le aduce după sine această abordare a
realității augmentate, fie ca este vorba de limitările serviciilor folosite , fie ca este vorba despre
limiăarile dispozitivelor, fie este vorba de limitări hardware care trebuie depășite.
Pentru început să abor dam problemele părții software. În mare parte aplica ția se bazeaza pe
informatiile venite de la serverele Google Cloud, p rincipala sursa de informatii. De aici se culeg
informatii despre OCR (Optical Character Recognition), traducere și citire a informațiilor.
Trecând la partea hardware, o mare problemă o constituie inacuratețea senzorilor, pentru
obtinerea orientarii dispoz itivului și necessitate unei camere destul de performante, pentru a
realiza imagini cat mai clare, care pt fi citite cu ușurință. Acestea creeaza o problema majora in
momentul afisarii blocurilor de cuvinte peste imaginile de la camera. Acestea trebuie sa fie
pozitionate exact, lucru aproape imposibil cu variația mare a datelor citite de dispozitiv.

Pentru rezolvarea pro blemei solu ții pot fi gasite atâ t în hardware c ât și în software. În cazul
harwareului soluția este construirea unor procesoare mai puterni ce, mai eficiente, care sa
genereze mai pu țină căldură și astfel s ă apară mai greu problema disip ării termice, astfel
ajungâ ndu-se mai greu la situa ția în care procesoarele s ă fie nevoite s ă își limiteze artificial
performan țele.
Una din cele mai mari prob leme, atat hardware c ât și software, o reprezint ă intensitatea
computa țional ă a aplica ției. Aceasta aplicaț ie este una intensive din punct de vedere
computa țional pe toat ă durata vie ții sale, în special în ecranul in care sunt prezentate informatiile
peste imaginile venite de la camera. În aceasta situatie, pentru ca aplicaț ia să fie perceput ă ca una
care raspunde instant la modificarile de orientare ale dispozitivului trebuie sa calculeze constant
pozitii le cuvintelor pe ecran. Calculul acestor pozi ții este unul intensiv, iar problema creș te cu
cât sunt mai multe cuvinte vizibile la un moment dat. Aceasta nu este o problema major ă cand
aplica ția este proasp ăt pornit ă. Deoarece i în aceste momente procesorul este înca rece și poate
funcționa la capacitate maxim ă. Însă cu trecerea timpului disipa ția termic ă devine o problem ă.
Pentru a se proteja de la supraincalzire procesorul i și limiteaz ă artificial frecven ța la care
lucrează. Dacă aplicatia este folosita o perioada îndelungat ă, peste 2 -3 minute, aceast ă limitare se
aprofundeaza tot mai mult p ână se ajunge la un prag sustenabil de procesor. În să de multe ori
acest prag nu este unul care s ă ofere performa țele necesare unei rul ări satisfacatoare ale
aplica ției. Aceste rezultate sunt obtinute prin rularea aplicatiei pe un telefon mediu ca și
performanță , la nivelul anului curent, 2017 . Aceasta problema este mai mare in cazul
dispozitivelor cu specificatii modeste.
Soluția software a problemei o constitu ie opt imizarea algoritmilor din cadrul aplicatiei, astfel
încât sa nu mai fie la fel de intensivi din punct de vedere computational.
Conform m ăsuratorilor din capitolul de analiza a impactului aplicatiei asupra performatelor
dispozitivelor mobile putem observa ca algoritmul foloseste intens primele doua core -uri ale
dispozitivelor. În cazul în care exista mai multe core -uri disponibile acestea r ămân în mare parte
neutilizate. Prin cre șterea gradului de paralelism al aplicatiei s -ar putea obtine o mai buna
distributie a taskurilor c ătre fiecare core al dispozitivului, fapt ce ar putea reduce semnificativ
disipatia termic ă.
Consider c ă aceste probl eme nu sunt niste obstacole de nedep ășit, put ând fi rezolvate într-un
timp relativ scurt, dacă nu și partea hardware, însă cu siguran ță partea software poate fi
optimizat ă suficient încât aplicatia sa fie viabila pe un numar cat mai mare de dispozitive mob ile.
5.7 Dezvoltări ulterioare
Deși am muncit foare mult în dezvoltarea acestei aplicații, totuși mai sunt câteva probleme
pe care ori nu le -am avut în planul inițial de dezvoltare a aplicației, ori am descoperit probleme
pe parcursul devoltării care ar putea fi evitate cu câteva schimbări.
În momentul actual, principala problemă a aplicației este dependența permanentă de internet.
Acest lucru poate fi de cele mai multe ori dezavantajos, dacă ne gandim la faptul că dipozitivul
mobil trebui să descarce de fiecar e dată datele. Luând în calcul o utilizare zilnică a aplicației
putem concluziona că utilizarea acesteia devine costisitoare dar și consumatoare de timp. Soluția
acestei probleme este introducerea unui mod de lucru offline. Aceasta se poate realiza prin
crearea unei baze de date locale, salvate pe cardul microSD, unde să fi salvate datele f olosite cel
mai des de către utilizatori. Prin introducerea unei baze de date locale se pot rezolva mai multe
probleme ale aplicației. Se înlatură dependența critică a co nexiunii la internet și totodată poate
rezolva problema majora de scalabilitate a aplicației, iar rezolvarea și acestei probleme face mai
ușoară folosirea aplicației și pe dispozitive mobile cu resurse mai limitate. Această abordare

poate funcționa bazându -ne pe faptul că de cele mai multe ori utilizatorii folosesc aplicații pentru
a face în general aceleași acțiu ni. Astfel se pot salva informații de la o rulare la alta a aplicației.
Aceasta nu este o varianta utilă în fiecare situație de folosire a aplicaț iei, dar va rezolva una
dintre cele mai mare probleme.
O altă problemă pe care aș vrea să mă axez în viitorul apropiat în ceea ce privește această
aplicație este schimbarea interfeței. Până în momentul de față, m -am axat în mare parte pe
funcționalitatea a plicației și consider că am neglijat partea de front -end. Experința pe o are
utilizatorul atunci când folosește o aplicație este la fel de importantă ca și funcționalitatea
acesteia.
Cea mai importanta dezvoltare ce trebuie adusa aplicatiei este combinarea abordăii
tradiționale a realității augmentate cu abordarea aleasă pentru această aplicație. Consider că se
pot obține performanțe optime prin strângerea de informații atât din imaginile venite de la
camera cât și din surse externe. Prin aceasta s -ar putea rezolva o multitudine de probleme.
Ultima idee pentru dezvoltarea ulterioară a aplicației, dar probabil cea pe care voi pune în
practică prima dintre cele prezentate, este găsirea unei soluții fezabile pentru ca aplicația să
funcționeze corect în cât mai multe limbi, inclusiv limba română.
Fiind un domeniu care se află într -o conti nuă dezvoltare, intenționez ca aceste idei și altele
care mi se vor părea potrivite pe parcurs, dar și mentenanța aplicației, să le implementez după
perioada studiilor de master .

6 Rezultate experimentale

7 Concluzii
Platformele open source au câștigat atenția utilizatorilor terminali datorită licențelor lor
gratuite și sursei modificabile, a devenit o provocare să concureze cu celelalte platforme care au
caștigat deja popularitate pe piață și care au caștigat încreder ea producătorilor, dezvoltatorilor și
utilizatorilor terminali. Android este prima platforma Open Source gratis și personalizabilă.
Oferă o stivă întreagă ce include un sistem de operare, middle ware, aplicații mobile cheie. De
asemenea conține o mulțime b ogată de API -uri care permit dezvoltatorilor terțiari să dezvolte
aplicații utile.
În lucrarea de față am prezentat sistemul de operare Android în detaliu, cu structura sa dar și
caracteristici mai detaliate. De asemenea, am prezentat mașina virtuală a si stemului și diferența
dintre acesta și Java Virtual Machine pentru a ajune la concluzia că Dalvik este o mașină mult
mai potrivită pentru dezvoltarea aplicațiilor mobile, datorită performanței crescute în condiții de
resurse limitate. Din comparația între fișierele dex și cele Java comprimate și necomprimate
putem observa cât de puțin spatiu al memoriei consumă. Execuția unui cod pe biti clar îl va face
mai rapid decât înainte.
Prin prezentarea argumentelor pro și contra pentru ideea de a dezvolta aplicați a folosind
Android sau iOS, în prezent am decis că cel mai potrivit este Androidul. Totuși, o dată cu
dezvoltarea aplicație la un nivel mai înalt și perfecționarea acesteia, un următor pas este
dezvoltarea pentru platforma iOS. Acest fapt ar duce la o creș tere mai mare a utilității sale,
cuprinzând o marjă mai mare de utilizatori.
Deși nu am tratat subietul performanțelor în elaborarea acestei lucrări de diplomă, acestea,
dar și experiența oferită de aceasta aplicație pot fi îmbunătățite dramatic prin diver sificarea
surselor de informații. Totodată consider că pentru îmbunătățirea acurateții aplicației cât și a
abordărilor ulterioare asupra acesteia, cel mai indicat este să se creeze o simbioză între
dezvoltarea tot mai mare a tehnologiei mobile și nevoile u tilizatorilor. Prin aceasta s -ar putea
complementa neajunsurile fiecărei abordări și se poate oferi utilizatorului final o experiență de
utilizare a aplicației cît mai satisfacatoare și mai informativă.
Un obiectiv major pe care și -l propune aplicația este să fie ușor de folosit de către oricine și
să ofere utilizatorului informațiile pe care și le dorește fără a depunde efort. Acest lucru l -am
tratat printr -o interfață simplă și intuitivă.
În concluzie, prin aplicația dezvoltată am încercat să îmbin plăce rea de a programa cu
dorința de a aduce ceva folositor societății. Momentu actual reprezintă doar începutul carierei
mele și îmi doresc ca pe măsură ce aprofundez acest domeniu să pot dezvolta cât mai multe
aplicații, și de ce nu să aduc ceva nou

8 Bibliog rafie

9 Anexe