Ministerul Educaţiei al Republicii Moldova

Universitatea de Stat din Tiraspol

Catedra Informatică și Tehnologii Informaționale

Domeniul general de studii:

Ştiinte ale educaţiei

Specialitatea:
Informatică

Teză de master
Dezvoltarea aplicațiilor
mobile Android cu Xamarin

A efectuat:
st. gr. C2I2 Ion Cojucovschi

Conducător ştiinţific:
dr. conf. Andrei Braicov

Chişinău, 2018
Cuprins
Introducere ………………………………………………………………… 3

Capitolul I. Despre aplicații mobile și mediul de dezvoltare Xamarin

§ 1. Aplicații mobile: cerințe, tipuri, instrumente, tehnologii .................... 5

§ 2. Xamarin: descriere generală ............................................................... 9

§ 3. Sistemul de operare Android ............................................................. 18

§ 4. Xamarin pentru dezvoltarea aplicațiilor Android ............................... 22

Capitolul II. Crearea aplicației mobile Librărie digitală

§ 1. Descrierea aplicației ………………………………………………..... 39

§ 2. Structura aplicației …………............................................................... 41

§ 3. Etapele elaborării aplicației ................................................................. 45

3.1. Crearea fisierelor front-end………………………………. 45

3.2. Interacțiunea cu bazele de date (resursele de carti)............. 50

55
3.3. Asigurarea vizualizării resurselor .pdf……………………

§ 4. Testarea și mentenanța aplicației (rezolvarea probleme, probleme

deschise, perspective, etc.)........................................................................... 58

§ 5. Codurile-sursă ale aplicației 60

.................................................................
Bibliografie ………………......................................................................... 62

Concluzii ..................................................................................................... 63

Cuvinte-cheie .............................................................................................. 64

Rezumate (română, engleză) …………………………………………….. 65

 Introducere

Există multe bucurii în programare. Există bucurie în analiza unei probleme,

divizarea acesteia în bucăți, formularea unei soluții, abordarea acesteia din diferite
direcții și realizarea codului. Exista multa bucurie în a vedea pentru prima data
codul,și apoi mai multa bucurie în optimizarea acestuia pentru ca sa lucreze mai bine
și mai repede. Există bucurie de asemenea, de multe ori în vânătoarea de bug-uri
pentru a ne asigura că programul rulează fără probleme și previzibil.
Exista bucurie în a realiza că abordarea originală pe care ați luat-o nu este este
chiar cea mai bună. Mulți dezvoltatori descoperă că au învățat multe în timp ce scriu
un program, inclusiv că există o modalitate mai bună de a crea structura codului.
Procesul este ca și cum ai învăța să mergi din nou și există multă bucurie în atingerea
acestei perspective și cunoștințe.
Timp de peste o jumătate de secol, dezvoltatorii râvneau la abilitatea de a scrie
un singur program pe mai multe platforme. Acesta este unul dintre motivele pentru
care limbajele de nivel înalt au fost inventate în primul rând, și de aceea conceptul de
”dezvoltare inter-platformă” continuă să exercite o atragere atât de puternică pentru
programatori.
Industria calculatoarelor personale a cunoscut o schimbare masivă în ultimii
ani, calculatoarele desktop fiind fiind principala sursă de informare, dar o mare parte
din computerele personale apar acum pe mai mici dispozitive, în special pentru
informații rapide, consum media și rețele sociale.
 Capitolul I. Despre aplicatii
mobile si mediul de
dezvoltare Xamarin
§ 1. Aplicații mobile: cerințe, tipuri, instrumente,
tehnologii
Tablete și smartphone-urile au o paradigmă fundamental diferită de
interacțiune a utilizatorilor bazată în primul rând pe atingere, cu o tastatură care apare
numai atunci când este necesar.
În prezent cunoaștem trei mari platforme pe care rulează telefoanele și tabletele
acestea sunt:
1. iOS, sistemul de operare ce rulează pe familia de dispozitive Apple.
2. Android, sistem de operare care este dezvoltat de Google pe baza
kernelului Linux , care rulează pe o varietate de telefoane și tablete.
3. Microsoft Windows Phone și Windows 10 Mobile, o a treia platformă de
dezvoltare mobilă, care nu este la fel de populară ca iOS și Android, dar implică o
companie cu o istorie puternică în industria calculatoarelor personale.
Pentru dezvoltatorii de software, strategia optimă este de a viza mai mult decât
una dintre aceste platforme.Dar nu este ușor. Există patru mari obstacole:
1. Diferite paradigme de interfață utilizator.
2. Diferite medii de dezvoltare.
a. Pentru dezvoltarea iOS în Xcode pe Mac.
b. Pentru dezvoltarea Android în Android Studio într-o varietate de
platforme.
c. Pentru dezvoltarea Windows în Visual Studio pentru PC.
3. Diferite interfețe de programare.
a. Pe iPhone sau iPad, este un “view” numit UISwitch.
 b. Pe Android dispozitive, este un “widget” numit Switch.
c. In Windows Runtime API, este un “control” numit
ToggleSwitch
4. Diferite limbaje de programare.
a. Objective-C pentru iPhone și iPad
b. Java pentru Android dispozitive.
c. C# pentru Windows

Daca sa categorizam tipurile de aplicatii atunci putem spune ca ele se impart in

trei categorii:

1. Aplicatii native:
● IOS in Objective-c sau Swift
● Android in Java
● Windows Phone in C# .Net

2. Aplicatii hibride pentru toate platformele cu Xamarin, React Native,

Ionic, Angular Mobile Sencha Touch, etc.

3. Aplicatii Web ca versiuni responsive ale site-urilor pentru a functiona pe

orice dispozitiv mobil.

In continuare vom descrie fiecare dintre aceste tipuri de aplicatii pentru a vedea
care este totusi difrerenta dintre ele, care sunt mai eficiente, si care dintre ele pe viitor
ar putea pedomina in lumea aplicatiilor mobile.
Aplicatiile native
Aceste aplicații sunt dezvoltate exclusiv pentru un singur sistem de operare
mobil, deci sunt "native" pentru o anumită platformă sau dispozitiv. Aplicația
construită pentru sisteme precum iOS, Android, Windows Phone, Symbian,
Blackberry nu poate fi utilizată pe o altă platformă decât cea proprie. Cu alte cuvinte,
nu veți putea utiliza aplicația Android pe iPhone sau invers.
Principalul avantaj al aplicațiilor native este performanța ridicată și asigurarea
unei experiențe bune pentru utilizatori, pe măsură ce dezvoltatorii folosesc interfața UI
a dispozitivelor. În plus, accesul la o gamă largă de API-uri care nu limitează
utilizarea aplicațiilor. Aplicațiile native sunt accesibile în mod distinct din magazinele
de aplicații de acest gen și au tendința clară de a ajunge la clienții vizați.
Cu toate acestea, acest tip de aplicație este costisitor de dezvoltat deoarece este
legat de un tip de sistem de operare, forțând compania care creează aplicația să facă
versiuni duplicate care funcționează pe alte platforme. Unele aplicații native au costuri
mai mari comparativ cu alte tipuri de aplicații - datorită necesității de a crea duplicate
de aplicații pentru alte platforme, de suport și întreținere separat pentru diferite tipuri
de aplicații, rezultând un preț mai mare pentru produse.

Aplicații hibride
Acestea sunt construite folosind tehnologii web multi-platforme (de exemplu,
HTML5, CSS și Javascript). Așa-numitele aplicații hibride sunt în principal aplicații
de pe site-uri deghizate într-un ambalaj nativ. Aplicațiile posedă argumente pro și
contra obișnuite atât ale aplicațiilor mobile native, cât și ale aplicațiilor web mobile.
Aplicațiile hibride pe mai multe platforme sunt rapide și relativ ușor de
dezvoltat - un avantaj clar. Baza unică de coduri pentru toate platformele asigură o
întreținere la preț redus și actualizări ușoare. Utilizați API pe scară largă, cum ar fi
giroscop, accelerometru, geolocație.
Pe de altă parte, aplicațiile hibride nu au performanță, viteză și optimizare
globală în comparație cu aplicațiile native, de exemplu. De asemenea, există anumite
probleme de proiectare din cauza incapacității aplicației de a arăta în același mod pe
două sau mai multe platforme.
Principalul avantaj al aplicațiilor hybrid este reutilizarea codului pe diferite
platforme, spre exemplu dacă utilizam platforma care creează aplicații pe baza
tehnologiilor web, atunci codul HTML(design) si JavaScript poate fi reutilizat si pe
alta platforma (OS), iar dacă utilizam spre exemplu Xamarin atunci cross-codul poate
atinge 70-80% din tot codul aplicației, spre exemplu aici design codul nu poate fi
reutilizat, cu toate ca se poate de fîcut share la design-cod, doar ca acesta reduce
considerabili performanta aplicației.

Aplicațiile Web
Acestea sunt aplicații software care se comportă într-un mod similar cu
aplicațiile native. Aplicațiile Web utilizează un browser pentru a fi difuzate și sunt de
obicei scrise în HTML5, JavaScript. Aceste aplicații redirecționează un utilizator la
adresa URL și oferă opțiunea de "instalare" creând pur și simplu un marcaj în pagina
lor.
Aplicațiile web necesită, de regulă, minimum de memorie a dispozitivului. Pe
măsură ce toate bazele de date personale sunt salvate pe un server, utilizatorii pot
accesa de pe orice dispozitiv ori de câte ori există conexiune la internet. Acesta este
motivul pentru care utilizarea de aplicații web cu conexiune slabă ar avea ca rezultat o
experiență nefavorabilă a utilizatorului. Dezavantajul este accesul a puținelor API-uri
pentru dezvoltatori, cu excepția localizării și a altelor.
Aplicațiile Web au devenit foarte populare când HTML5 și-a făcut apariția și
oamenii și-au dat seama că pot obține funcționalități asemănătoare nativului în
browser. Astăzi, deoarece tot mai multe site-uri folosesc HTML5, distincția dintre
aplicațiile web și paginile web obișnuite a devenit neclară.

§ 2. Xamarin: descriere generală

Xamarin este o companie de software din San Francisco, înființată în 2011 de
către inginerii care au creat Mono, Mono pentru Android si MonoTouch ce reprezinta
implementările CLI (Common Language Specifications) și CLS(Common language
specification, adesea numit și Microsoft .Net)
Un singur limbaj pentru aceste trei platforme este o idee destul de convenabilă,
dar care limbaj ar trebui sa fie?
 Mulți dezvoltatori vor da o mulțime de răspunsuri la întrebarea pusă, dar un
bun argument va fi în favoarea limbajului C#.
Bazat pe limbajul de programare C#, dezvoltatorii pot folosi instrumentele
Xamarin pentru a scrie aplicații native Android,IOS si Windows cu interfețe utilizator
și partajare pe mai multe platforme, inclusiv Windows si MacOS. Potrivit companiei,
peste 1,5 milioane de dezvoltatori folosesc produsele Xamarin, în 120 de țari din
întreaga lume.
C # pare să fie un limbaj orientat pe obiect, destul de clar, tipizat, imperativ, cu
siguranță influențat de C ++ (și Java, de asemenea), dar cu o sintaxă mult mai curată
decât C ++ și cu niciun bagaj istoric. în martie 2016, Microsoft a achiziționat Xamarin
cu s copul de a aduce dezvoltarea mobilă pe mai multe platforme la o comunitate mai
largă de dezvoltatori Microsoft. Acum Xamarin este disponibil gratuit tuturor
utilizatorilor Visual Studio.
În primii trei ani de existență, Xamarin sa concentrat în principiu pe tehnologiile
compilatoare și trei seturi de bază de biblioteci .NET:
a. Xamarin.Mac, care a evoluat de la proiectul MonoMac.
b. Xamarin.iOS, care a evoluat de la MonoTouch.
c. Xamarin.Android, care a evoluat de la Mono pentru Android sau (mai
informal) MonoDroid,
în mod colectiv, aceste biblioteci sunt cunoscute sub numele de platforma Xamarin.
Aceste biblioteci constau din versiuni .NET din Mac, iOS și Android API nativ.
Programatorii care folosesc aceste biblioteci pot scrie aplicații C# pentru a viza API-
urile native ale acestor trei platforme, dar și (ca bonus) cu acces la bibliotecile .NET
Framework.

Xamarin pentru Visual Studio

Xamarin susține că este singurul IDE care permite dezvoltarea aplicațiilor
native Android, iOS și Windows în Microsoft Visual Studio. Xamarin furnizează
programe adiționale pentru Microsoft Visual Studio, care permite dezvoltatorilor să
construiască aplicații Android, iOS și Windows în cadrul IDE utilizând terminarea
codului și IntelliSense. Xamarin pentru Visual Studio are, de asemenea, extensii în
Microsoft Visual Studio care oferă suport pentru construirea, implementarea și
depanarea aplicațiilor pe un simulator sau pe un dispozitiv. La sfârșitul anului 2013,
Xamarin și Microsoft au anunțat un parteneriat care a inclus programe de integrare
tehnică și de clienți pentru a le permite construirii bazelor comune de dezvoltatori
pentru toate platformele mobile. În plus, Xamarin include acum suport pentru
Microsoft Portable Class Libraries și cele mai multe caracteristici C # 5.0 cum ar fi
async / await. CEO și co-fondator al Xamarin, Nat Friedman, a anunțat alianța la
lansarea Visual Studio 2013 în New York.
Pe 31 martie 2016, Microsoft a anunțat că a îmbinat toate programele Xamarin
cu fiecare versiune de Microsoft Visual Studio, inclusiv Visual Studio Community, iar
acest lucru a adăugat diferite caracteristici Xamarin care vin preinstalate în Visual
Studio, cum ar fi un emulator iOS.

Xamarin Studio
În momentul lansării sale în februarie 2013, Xamarin Studio a fost un IDE
independent pentru dezvoltarea aplicațiilor mobile pe Windows și MacOS, ca parte a
Xamarin 2.0, bazat pe proiectul open source MonoDevelop. Pe lângă un program de
depanare, Xamarin Studio include completarea codului în C #, un constructor UI
Android pentru crearea de interfețe utilizator fără XML și integrarea cu Xcode
Interface Builder pentru proiectarea aplicațiilor iOS.
Pe Windows Xamarin Studio este acum depreciat și a fost înlocuit cu Xamarin
pentru Visual Studio. Pe macOS Xamarin Studio este încă în dezvoltare, dar a fost
rebrand 2016 ca Visual Studio for Mac.
Xamarin.Mac a fost creat ca un instrument pentru dezvoltarea aplicațiilor
tehnologiei Apple utilizând limbajul de programare C #. Xamarin.Mac, ca și în cazul
Xamarin.iOS și Xamarin.Android, oferă dezvoltatorilor până la 90% din reutilizarea
codurilor pe Android, iOS și Windows. Xamarin.Mac oferă dezvoltatorilor C #
posibilitatea de a construi aplicații de Cocoa complet native pentru Mac OS X și
permite aplicații native care pot fi puse în Mac App Store.

RoboVM
În octombrie 2015, Xamarin a anunțat că a achiziționat RoboVM-ul suedez
pentru platforma de dezvoltatori Java asemănător ofertelor sale, motivul declarat de
Xamarin pentru achiziție a fost că dacă ar dezvolta o platformă bazată pe Java de la
bază până la finalul produsului final asemanatoare cu RoboVM, astfel incat au
dobândit compania, în consecința RoboVM operează independent de echipa Xamarin.
RoboVM permite dezvoltatorilor să construiască aplicații Java pentru iOS și Android
cu UI-uri native, performanțe native și toate aplicațiile Java au acces complet la API-
urile fiecărei platforme de dezvoltatori.

Instalarea, utilizarea mediului de programare Xamarin

Ca să lucrăm cu mediul Xamarin avem două metode să instalăm Visual Studio
sau să Instalăm Xamarin Studio, ambele au aceleași posibilități doar că Xamarin
Studio este orientată pur pe dezvoltarea aplicațiilor multiplatforma și ocupă mai puține
resurse pe calculator. Ambele resurse dispun de versiunile gratis cu funcționalități mai
reduse dar destule pentru a crea aplicații destul de avansate.

Cum instalăm Visual Studio 2017 cu extensiile Xamarin?

1. Accesăm https://www.visualstudio.com/downloads/
2. Descarcam Visual Studio Comunity sau de pe linkul de mai jos:
https://www.visualstudio.com/thank-you-downloading-visual-
studio/?sku=Community&rel=15
3. Apoi urmați următorii pași:
visual_studio_instaler.exe => Continue => Visual Studio Comunity 2017/Install
=>
Mobile & Gaming/Mobile developement with .NET
Bifați propunerile conform screenshot-ului de mai jos:

apoi faceți click pe Install. Acestea pezintă resursele minime pentru a lucra cu Mediul
Visual Studio Xamarin.
De asemeni puteți găsi mai explicit pașii de instalare a Xamarin pe Visual
Studio pe următorul link: https://developer.xamarin.com/guides/cross-
platform/getting_started/installation/windows/
sau Xamarin Studio pe linkul:
https://developer.xamarin.com/guides/android/getting_started/installation/windows/
Dezvoltatorii pot folosi Visual Studio, pentru a construi aplicații Xamarin, care
vizează și iOS și Android ca toate platformele Windows diferite. Cu toate acestea,
dezvoltarea iPhone și iPad necesită, de asemenea, un Mac conectat la PC printr-o rețea
locală. Acest Mac trebuie să aibă instalat Xcode, precum și Xamarin Studio, un mediu
de dezvoltare integrat bazat pe OS X care vă permite să dezvoltați iPhone, iPad, Mac
OS X și aplicații Android pe Mac. Xamarin Studio nu vă permite să dirijați
platformele Windows.
 Avantajul dirijării mai multor platforme cu un singur limbaj de programare
provine din capacitatea de a partaja codul între aplicații, asta economisește timpul,
reduce efortul de creare a aplicației și reduce din utilizarea mai multor resurse.
Înainte ca codul să poată fi partajat, o aplicație trebuie bine structurată în acest
scop. În special din moment ce a accelerat utilizarea pe scară largă a interfețelor
grafice ale utilizatorilor, programatorii au înțeles importanța separării codului
aplicației în straturi funcționale. Poate că diviziunea cea mai utilă este între interfața
utilizator-cod și modelele și algoritmii de date. Aplicația populară MVC (Model-
View-Controller) arhitectura formalizează această separare a codului într - un model
(datele de bază), vizualizarea (reprezentarea vizuală a datelor) și Controlorul (care
gestionează datele de la utilizator).
MVC își are originile din anii 1980. Cea mai recenta arhitectura care are
pornirile de la MVC este MVVM care efectiv a modernizat arhitectura MVC bazata pe
GUI-uri (Graphical User Interface) moderne. MVVM separa codul în Model(datele
model), View(interfața utilizatorului, incluzând input-urile vizuale) și
ViewModel(acesta este managerul care formează relațiile dintre Model și View).
Când un programator dezvoltă o aplicație care țintește mai multe platforme,
arhitectura MVVM ghidează dezvoltatorul în separarea codului specific fiecărei
platforme (adică ajuta la crearea legăturii între View-codul care interacționează cu
API-urile platformei, acestea fiind specifice fiecărei platforme și codului independent
adică cel scris pentru Model și ViewModel).
Adesea acest cod independent de platformă trebuie să acceseze fișiere sau rețea
sau să utilizeze colecții sau threading. În mod normal acest lucru ar putea fi considerat
ca poate fi îndeplinit de API-urile sistemului de operare dar acestea pot fi executate și
de biblioteca .NET Framework iar dacă .NET este disponibil pe fiecare platformă
atunci acest cod este efectiv independent de platformă.
Partea aplicației care este independentă de platformă poate fi izolată și pusă în
contextul unui proiect nou de tip Proiect de Asset Shared (SAP)-care constă pur și
simplu din cod și alte fișiere și materiale accesibile din alte proiecte sau poate fi
izolată intr-un proiect de tip Portable Class Library (PCL), care cuprinde tot codul
comun într-o bibliotecă namic-link (DLL) care poate apoi să fie menționate de alte
proiecte.
Următoarea diagramă ilustrează interconexiunile dintre Visual Studio sau
Xamarin Studio și librăriile Xamarin și API-urile platformei. În a treia coloana este
prezentat pentru oricare proiect bazat .NET Windows Platform:
 INTRODUCERE ÎN XAMARIN
Pe data de 28 mai 2014 Xamarin introduce Xamarin.Forms, care vă permite să
scrieți codul de interfață utilizator care pot fi compilate pentru dispozitivele IOS,
Android și Windows. Din motive ca deja exista o legătura strânsa intre noul proiect
Xamarin bazat pe limbajul C# si tehnologiile .NET, proiectul Xamarin a avut un
startup destul de reușit, pentru ca deja putea utiliza nenumăratele biblioteci disponibile
aplicațiilor .NET, iar pasul de intrare în aceasta platforma de creare a aplicațiilor era
destul de mic pentru cunoscătorii tehnologiilor .NET.

Opțiunile oferite de Xamarin:

Xamarin suportă cinci platforme diferite pentru crearea aplicațiilor:

a) IOS pentru aplicațiile care ruilează pe IPhone,IPad și IPod Touch.

b) Android pentru aplicațiile ce rulează pe smartphone-urile Android.
c) Universal Windows Platform (UWP) aplicațiile ce rulează pe Windows 10 sau
Windows 10 Mobile.
d) Windows Runtime pentru Windows 8.1.
e) Windows Runtime pentru Windows Phone 8.1.

În general, o aplicație Xamarin în Visual Studio constă din cinci proiecte

separate pentru fiecare dintre aceste cinci platforme, cu un al șaselea proiect care
conține cod comun. De obicei proiectele dependente de platforma pe care rulează sunt
destul de mici avînd doar partea de cod de pornire redus. PCL sau SAP conține cea
mai mare parte a aplicației, inclusiv interfața utilizatorului cod. Următoarea diagramă
arată doar platformele iOS, Android și Universal Windows. Celelalte două platforme
Windows sunt similare cu UWP:

Să prezentăm un simplu exemplu ce ne va arata cum rulează unu și același

program pe platformele IOS, Android și Windows 10 Mobile. Spre exemplu vom avea
un View ce va conține un TextView (cu conținutul ”Hello, Xamarin Forms !”) un
Buton (numit ”click me!”), un Swich și un Slider. Acestea vor fi afișate diferit pe
fiecare din aceste device-uri deoarece fiecare platformă afișează conținutul printr-un
obiect specific, să observăm figura de mai jos:
 De asemeni ar trebui de menținut că aceste screenshot-uri sunt făcute pentru
următoarele simulatoare ce rulează pe următoarele platforme cu versiunile:
IPhone 6 - rulează pe IOS 9.2,
LG Nexus 5 - rulează pe Android versiunea 6.0,
Nokia Lumia 935 - ce rulează pe Windows 10.
Ne dăm seama ca aceste obiecte ar fi afișate diferit pe diferite versiuni ale
platformelor, dar aceasta va fi un subiect discutat aparte.
Diferitele implementări ale barei de instrumente arată că, într-un sens
Xamarin.Forms este un API care virtualizează nu numai elementele interfeței
utilizator pe fiecare platformă ci și paradigmele interfeței utilizator.

XAMAL support

De asemenea Xamarin.Forms suportă XAML (se pronunță ”zammel”), este

bazat pe limbajul XML- Extensible Application Markup Language dezvoltat de
Microsoft ca limbaj de marckup general pentru instanțierea și inițializarea obiectelor.
XAML nu se limitează la definirea layout-urilor inițiale ale interfeței utilizatorului,
dar din punct de vedere așa a fost folosit cel mai mult, și de aceea este folosit în
Xamarin.Forms.

Mai jos voi prezenta fișierul XAML pentru screenshot-urile de mai sus:
 Într-un program real fiecărui obiect i se poate atașa un eveniment aceasta
realizându-se prin intermediul codului C#. Aici acestea nu au atașat nimic, cu scopul
prezentării cât mai simple a noțiunilor de bază.

În continuare ne vom axa doar pe crearea aplicațiilor pentru platforma Android

aceasta având caracteristicile sale specifice.

§ 3. Sistemul de operare Android

 Android este o platformă software și un sistem de operare pentru dispozitive și
telefoane mobile bazată pe nucleul Linux, dezvoltată inițial de compania Google, iar
mai târziu de consorțiul comercial Open Handset Alliance. Android permite
dezvoltatorilor să scrie cod gestionat în limbajul Java, controlând dispozitivul prin
intermediul bibliotecilor Java dezvoltate de Google. Aplicațiile scrise în C și în alte
limbaje pot fi compilate în cod mașină ARM și executate, dar acest model de
dezvoltare nu este sprijinit oficial de către Google.

Lansarea platformei Android la 5 noiembrie 2007 a fost anunțată prin fondarea

Open Handset Alliance, un consorțiu de 48 de companii de hardware, software și de
telecomunicații, consacrat dezvoltării de standarde deschise pentru dispozitive mobile.
Google a lansat cea mai mare parte a codului Android sub licența Apache, o licență de
tip free-software și open source.

În iulie 2005 Google a achiziționat Android, Inc, o mică companie de tip

startup cu sediul în Palo Alto, California, SUA. Cofondatorii companiei Android, care
au continuat să muncească la Google, au fost Andy Rubin (cofondator al Danger),
Rich Miner (cofondator al Wildfire Communications, Inc), Nick Sears (fost
vicepreședinte al T-Mobile) și Chris White (unul dintre primii ingineri ai WebTv). La
acea dată se cunoștea foarte puțin despre Android, Inc., doar că făceau software pentru
telefoane mobile. Aceasta a cauzat zvonuri că Google ar plănui să intre pe piața
telefoniei mobile, deși era neclar ce funcție ar putea îndeplini în această piață.

Începând cu 21 octombrie 2008, Android a fost disponibil ca Open Source.

Google a deschis întregul cod sursă (inclusiv suportul pentru rețea și telefonie), care
anterior era indisponibil, sub licența Apache. Sub licența Apache producătorii sunt
liberi să adauge extensii proprietare, fără a le face disponibile comunității open source.
În timp ce contribuțiile Google la această platformă se așteaptă să rămână open
source, numărul versiunilor derivate ar putea exploda, folosind o varietate de licențe.

Android a fost criticat că nu este software open source în totalitate, în ciuda a

ceea ce a fost anunțat de către Google. Părți ale SDK-ului sunt proprietare și sursă
închisă și unii cred că acest lucru este pentru ca Google să poată controla platforma.

Unele Specificații ale SO Android:

 - Platforma este adaptabilă la configurații mai mari, VGA, biblioteci
grafice 2D, biblioteci grafice 3D bazate pe specificația OpenGL ES 1.0
și configurații tradiționale smartphone.
- Software-ul de baze de date SQLite este utilizat în scopul stocării
datelor.
- Android suportă tehnologii de conectivitate incluzând GSM/EDGE,
CDMA, EV-DO, UMTS, Bluetooth și Wi-Fi.
- SMS și MMS sunt formele de mesagerie instant disponibile, inclusiv
conversații de mesaje text.
- Navigatorul de web disponibil în Android este bazat pe platforma de
aplicații open source WebKit.
- Software-ul scris în Java poate fi compilat în cod mașină Dalvik și
executat de mașina virtuală Dalvik, care este o implementare
specializată de mașină virtuală concepută pentru utilizarea în
dispozitivele mobile, deși teoretic nu este o Mașină Virtuală Java
standard.
- Android acceptă următoarele formate media audio/video/imagine:
MPEG-4, H.264, MP3, AAC, OGG, AMR, JPEG, PNG, GIF.
- Android poate utiliza camere video/foto, touchscreen, GPS,
accelerometru, și grafică accelerată 3D.
- Include un emulator de dispozitive, unelte de depanare, profilare de
memorie și de performanță, un plug-in pentru mediul de dezvoltare
Eclipse.

Primele aprecieri cu privire la dezvoltarea aplicațiilor pentru platforma Android

au fost amestecate. Problemele citate includeau bug-uri, lipsa de documentație,
infrastructura de testare inadecvată, și lipsa unui sistem de gestionare a problemelor
public. (Google a anunțat un sistem de gestionare a problemelor la data de 18 ianuarie
2008.) În decembrie 2007, fondatorul startup-ului mobil MergeLab Adam MacBeth a
declarat: "Funcționalitatea lipsește, este prost documentată sau pur și simplu nu
funcționează... Este clar că nu este gata pentru prime time." În ciuda acestui fapt,
aplicațiile pentru Android au început să apară deja în săptămâna următoare celei în
care a fost anunțată platforma.Prima aplicație publică a fost jocul Snake.Telefonul
Android Dev este un dispozitiv cu SIM și hardware neblocate care este destinat
dezvoltatorilor avansați. Cu toate că dezvoltatorii pot utiliza un dispozitiv de consum
achiziționat de pe piață pentru a-și testa și a utiliza aplicațiile, unii dezvoltatori pot
alege să nu utilizeze un dispozitiv de pe piață, preferând un aparat neblocat sau fără
contract.
 SDK-ul Android include un set complet de instrumente de dezvoltare. Acestea
includ un program de depanare, biblioteci, un emulator de dispozitiv(bazat pe
QEMU), documentație, mostre de cod și tutoriale. Platformele de dezvoltare sprijinite
în prezent includ calculatoare bazate pe x86 care rulează Linux (orice distribuție
Linux desktop modernă), Mac OS X 10.4.8 sau mai recent, Windows XP sau Vista.
Cerințele includ, de asemenea, Java Development Kit, Apache Ant, și Python 2.2 sau
o versiune ulterioară. Mediul de dezvoltare (IDE) suportat oficial este Eclipse (3.2 sau
mai recent), utilizând plug-in-ul Android Development Tools (ADT), deși
dezvoltatorii pot folosi orice editor de text pentru a edita fișiere XML și Java și apoi să
utilizeze unelte din linia de comandă pentru a crea, să construi și depana aplicații
Android.
O versiune pentru examinare a Android Software Development Kit (SDK) a
fost lansată la data de 12 noiembrie 2007.La 15 iulie 2008, echipa Android Developer
Challenge a trimis accidental un e-mail la toți participanții Android Developer
Challenge anunțând că o nouă versiune de SDK era disponibilă într-o zonă de
descărcare "privată". Mesajul a fost destinat pentru câștigătorii primului tur al Android
Developer Challenge. Revelația că Google va furniza noi versiuni SDK unor
dezvoltatori și nu altora (și păstra acest regim secret) a condus la frustrare raportată pe
scară largă în comunitatea dezvoltatorilor Android.
La 18 august 2008, a fost lansat Android SDK 0.9 beta. Această versiune oferă
un API actualizată și extinsă, instrumente de dezvoltare îmbunătățite și un design
actualizat pentru ecranul de bază. Instrucțiuni detaliate pentru actualizare sunt
disponibile pentru cei care lucrează deja cu o versiune anterioară. La 23 septembrie
2008 a fost lansat SDK-ul Android 1.0 (Release 1). Conform documentației de
lansare, includea "în principal remedii pentru probleme, deși au fost adăugate unele
capabilități mai puțin semnificative". Includea, de asemenea, câteva modificări ale
API-ului față de versiunea 0.9.
Pe 9 martie 2009, Google a lansat versiunea 1.1 pentru telefonul Android Dev.
Deși există câteva actualizări estetice, câteva actualizări cruciale includ suport pentru
"căutare prin voce, aplicații contra cost, remedii pentru ceasul cu alarmă, remediu
pentru blocarea la trimiterea gmail, notificări de poștă electronică și intervale de
împrospătare, iar acum hărțile afișează evaluări de firme". Un alt update important
este că telefoanele Dev pot acum accesa aplicații plătite și dezvoltatorii le pot vedea
acum pe Play Store.
Uneltele din SDK-ul Android, compilează codul sursă împreună cu fişierele
în care se află memorate resursele, în arhive ce au extensia *.apk. Tot codul aflat
într-o arhivă *.apk este tratat ca o aplicaţie unitară ce este instalată ulterior pe
dispozitivele ce rulează Android.
 Faptul că Android este un sistem de operare cu sursă deschisă şi licenţă
gratuită, permite programatorilor să dezvolte rapid și cu uşurinţă aplicaţii care să
aducă inovația în utilizarea dispozitivelor mobile.

§ 4. Xamarin pentru dezvoltarea aplicațiilor

Android
Aplicațiile Android nu au un singur punct de intrare, adică nu există o singură
linie de cod în aplicația solicitată de sistemul de operare pentru a porni aplicația. În
schimb, o aplicație pornește atunci când Android reprezintă o instanță a uneia dintre
clasele sale, timp în care Android încarcă întregul proces al aplicației în memorie.
Această caracteristică unică a aplicației Android poate fi extrem de utilă atunci
când proiectează aplicații complicate sau interacționează cu sistemul de operare
Android. Cu toate acestea, aceste opțiuni fac, de asemenea, complex Android atunci
când se ocupă de un scenariu de bază, cum ar fi aplicația Phoneword. Din acest motiv,
explorarea arhitecturii Android este împărțită în două. În Hello, Android Multiscreen,
complexitatea completă a arhitecturii Android este explorată, fiind abordate diferite
modalități de a lansa o aplicație.
Scenariul Phoneword - startează cu un Activity
Când deschizi aplicația Phoneword pentru prima dată într-un emulator sau
device, sistemul de operare crează prima activitate numită Activity. O activitate este o
clasă specială pentru Android ce corespunde unui singur ecran de aplicație și este
responsabilă pentru desenarea și alimentarea interfeței cu anumite date. Când Android
creează prima activitate a aplicației, ea încarcă întreaga aplicație conform prezentării
de mai jos:

Deoarece nu există progresie liniară printr-o aplicație Android (puteți lansa

aplicația din mai multe puncte), Android are o modalitate unică de a urmări ce clase și
fișiere alcătuiesc o aplicație. În exemplul Phoneword, toate părțile care alcătuiesc
aplicația sunt înregistrate cu un fișier XML special numit Android Manifest. Rolul
fișierului Android Manifest este de a urmări conținutul, proprietățile și permisiunile
unei aplicații și de a le dezvălui în sistemul de operare Android. Vă puteți gândi la
aplicația Phoneword ca pe o singură Activitate (ecran) și o colecție de fișiere de
resurse și de ajutor asociate împreună cu fișierul Android Manifest, ilustrat în
diagrama de mai jos:
 Interfața Utilizatorului
Main.axml este fișierul unde se realizează aspectul interfeței
utilizatorului pentru primul ecran din aplicație. .axml ne indică faptul că acesta
estre un fișier de tip designer Android (AXML înseamnă Android XML).
Numele principal este arbitrar din punctul de vedere al Android SO - fișierul
layout (adică schema xml a ecranului) ar fi putut denumită altfel. Când
deschideți fișierul Main.axml în IDE, acesta aduce editorul vizual pentru
fișierele ce țin de design numit Android Designer, acesta este prezentat în
figura de mai jos:
 În aplicația Phoneword, id-ul butonului TranslateButton este setat astfel:
@+id/TranslateButton, puteți observa în figura de mai jos:

Când setați proprietatea de identitate a TranslateButton, Designerul Android

desenează controlul TranslateButtonla clasa Resource și îi atribuie un ID de
resursă a TranslateButton. Această mapare a controlului vizual în clasă face
posibilă localizarea și utilizarea funcțiilor TranslateButton și a altor controale
în codul aplicației.
 Source View- Vizualizarea sursei
Tot ce este definit în suprafața de proiectare (AXML layout) este tradus
în XML pentru Xamarin.Android pentru utilizare. Android Designer oferă o
vizualizare a sursei XML generate de designerul vizual. Puteți vizualiza acest
XML prin trecerea la panoul sursă din stânga jos a vizualizării proiectului, așa
cum este ilustrat în imaginea de mai jos:

Acum că am descoperit ce se află în spatele părții vizuale a interfeței cu

utilizatorul să trecem la partea de cod ce are influență asupra acestei interfețe.

Activitățile(Activities) și ciclul de viață al Activității (Activity

Lifecycle)
Clasa Activitate conține codul care împarte interfața cu utilizatorul.
Activitatea este responsabilă pentru reacția la interacțiunea cu utilizatorul și
pentru crearea unei experiențe dinamice a utilizatorului.
Aplicația Phoneword are un singur ecran (Activitate). Clasa care
activează ecranul se numește MainActivity și se afla în fișierul
MainActivity.cs. Numele MainActivity nu are nici o semnificație specială în
Android - deși convenția este de a numi prima activitate într-o aplicație
MainActivity, SO Android nu-i pasă dacă este denumită altfel.
Când deschideți MainActivity.cs, puteți vedea că clasa MainActivity
este o sub-clasă a clasei Activity și că activitatea este ”împodobită” cu atributul
Activity:
[Activity (Label = "Phone Word", MainLauncher = true)]
public class MainActivity : Activity
{
...
}

Atributul de activitate înregistrează activitatea în Android Manifest,

acest lucru permite Android-ului să știe că această clasă face parte din aplicația
Phoneword gestionată de acest manifest. Proprietatea Label stabilește textul
care va fi afișat în partea superioară a ecranului.Proprietatea MainLauncher îi
spune Android-ului să afișeze această Activitate când pornește aplicația sau nu.
Această proprietate devine importantă pe măsură ce adăugați mai multe
activități (ecrane) la aplicație.
În continuare vom prezenta durata ciclului de viață al unei activității.

Ciclul de viață al unei Activițăți:

În Android, activitățile trec prin diferite etape ale ciclului de viață, în
funcție de interacțiunile cu utilizatorul. Activitățile pot fi create, pornite și
întrerupte, reluate și distruse și așa mai departe. Clasa Activitate conține
metode pe care sistemul le solicită la anumite puncte ale ciclului de viață al
ecranului. Următoarea diagramă ilustrează o viață tipică a unei activități,
precum și unele dintre metodele corespunzătoare ciclului de viață:
 Să prezentăm în continuare sub formă de diagramă toate metodele
standard disponibile unei activități apoi o să încercăm să descriem succint
menirea acestor metode în viața unei aplicații:

Datorită faptului că putem face ”override” la metodele ciclului de viată a

unei Activități, noi putem controla modul în care se încarcă Activitatea, modul
în carea reacționează cu utilizatorul și chiar ceea ce se întâmplă după ce dispare
de pe ecranul dispozitivului. De exemplu, puteți face ”override” la metodele
ciclului de viață din diagrama de mai sus pentru a efectua câteva sarcini
importante:

- OnCreate - Creează vizualizări, inițializează variabile și

efectuează alte activități pregătitoare care trebuie efectuate
înainte ca utilizatorul să vadă Activitatea. Această metodă se
inițializează o singură dată atunci când activitatea se încarcă în
memorie.
- OnStart - este apelată mereu de sistem după terminarea
executării metodei OnCreate. Activitățile pot înlocui această
metodă dacă trebuie să îndeplinească anumite sarcini specifice
înainte ca o activitate să devină vizibilă, cum ar fi actualizarea
 valorilor curente ale vizualizărilor în cadrul activității. Android
va apela OnResume imediat după acestă metodă.
- OnResume - Efectuează toate sarcinile care trebuie să se
întâmple de fiecare dată când activitatea revine pe ecranul
dispozitivului. Unele activități de exemplu ar putea fi ca:
ramparea ratelor cadrelor(o sarcină comună în construirea
jocurilor),inițierea animațiilor, urmărirea actualizărilor GPS,
afișarea tuturor dialogurilor relevante, conectarea agenților de
urmărire a evenimentelor, etc.
- OnPause - Efectuează orice sarcină care trebuie să se întâmple
de fiecare dată când Activitatea părăsește ecranul
dispozitivului.Unele activități de exemplu ar putea fi ca: salvarea
modificărilor datelor persistente, ștergerea sau distrugerea unor
obiecte ce consumă resurse, reducerea ratelor cadrelor și a
animațiile de pauză, s.a.
- OnStop - este apelată atunci când activitatea nu mai este vizibilă
pentru utilizator. Acest lucru se întâmplă când apare una dintre
următoarele acțiuni (?????se referă în anumite condiții când este
necesară una din următoarele rezultate): să se lanseze o nouă
activitate care acoperă activitatea curentă, o activitate existentă
este pusă în prim-plan, activitatea curentă trebuie să fie distrusă.
- OnDestroy - este metoda finală care este apelată pe o instanță a
activității înainte de a fi distrusă și complet îndepărtată din
memorie. În situații extreme, sistemul Android poate ucide
procesul de solicitare care găzduiește activitatea, ceea ce va duce
la invocarea serviciului OnDestroy. Majoritatea activităților nu
vor implementa această metodă deoarece majoritatea acțiunilor
de curățare și închidere au fost efectuate în metodele OnPause și
OnStop.
- OnRestart - este chemat după ce activitatea dvs. a fost oprită,
înainte de a începe din nou. Un bun exemplu de acest lucru ar fi
atunci când utilizatorul apasă butonul acasă în timp ce se află
într-o activitate din aplicație. Când se întâmplă acest lucru, se
apelează metode OnPause și apoi OnStop și activitatea este
mutată în fundal, dar nu este distrusă. Dacă utilizatorul urma să
restaureze aplicația utilizând managerul de activități sau o
aplicație similară, Android va apela metoda OnRestart a
activității. Nu există orientări generale pentru ce fel de logică ar
trebui implementată în OnRestart. Acest lucru se datorează
faptului că OnStart este invocat întotdeauna indiferent dacă
 activitatea este creată sau reluată, astfel încât toate resursele
necesare activității ar trebui inițializate în OnStart, nu pe
OnRestart.

Ca concluzie putem menționa că ciclul de viață al activității Android oferă

imaginar un tablou puternic pentru gestionarea activităților în cadrul unei aplicații, dar
poate fi dificil de înțeles și implementat. În acest paragraf s-a prezentat diferitele stări
pe care o activitate le poate trece pe parcursul vieții sale, precum și metodele ciclului
de viață asociate cu aceste stări. Apoi, s-au oferit îndrumări cu privire la ce fel de
logică ar trebui să fie efectuată în fiecare dintre aceste metode.

Crearea serviciilor android

Aici vom discuta despre serviciile Xamarin.Android, care sunt
componentele Android care permit lucrul fără a avea o interfață de utilizator
activă. Serviciile sunt foarte frecvent utilizate în fundal cum ar fi calcule ce
consumă timp, descărcarea de fișiere, redarea de muzică și așa mai departe.
Aceasta explică diferitele scenarii pentru care serviciile sunt potrivite și arată
cum să le implementăm atât pentru efectuarea sarcinilor de fundal pe termen
lung, cât și pentru furnizarea unei interfețe pentru apeluri procedurale.
Generic
Aplicațiile mobile nu sunt ca aplicațiile desktop. Computerele desktop
au o cantitate mare de resurse, cum ar fi dimensiunea ecranului, memoria,
spațiul de stocare și o sursă de alimentare conectată, dispozitivele mobile nu.
Aceste constrângeri obligă aplicațiile mobile să se comporte diferit. De
exemplu, ecranul mic de pe un dispozitiv mobil înseamnă de obicei că este
vizibilă o singură aplicație (adică Activitate). Celelalte activități sunt mutate în
fundal și împinse într-o stare suspendată, unde nu pot efectua nicio lucrare. Cu
toate acestea, doar pentru că o aplicație Android se află în fundal nu înseamnă
că este imposibil ca aplicația să continue să funcționeze.
Aplicațiile Android sunt alcătuite din cel puțin una din următoarele patru
componente principale: Activități (Activities), Receptoare de difuzare
(Broadcast Receivers), Furnizori de conținut (Content Providers) și Servicii
(Service). Activitățile reprezintă piatra de temelie a numeroaselor aplicații
Android, deoarece furnizează interfața utilizator care permite unui utilizator să
interacționeze cu aplicația. Cu toate acestea, atunci când este vorba de
efectuarea unor lucrări concurentă sau de fond, activitățile nu sunt întotdeauna
cea mai bună alegere.
 Mecanismul principal pentru lucrul de fundal în Android este serviciul.
Un serviciu Android este o componentă care este proiectată să funcționeze fără
o interfață cu utilizatorul. Un serviciu poate descărca un fișier, reda muzică sau
aplica un filtru unei imagini. Serviciile pot fi, de asemenea, utilizate pentru
comunicarea inter-proceselor (IPC) între aplicațiile Android. De exemplu, o
aplicație Android ar putea să utilizeze serviciul de redare muzicală dintr-o altă
aplicație sau o aplicație ar putea expune date (cum ar fi informațiile de contact
ale unei persoane) altor aplicații prin intermediul unui serviciu.
Serviciile, precum și capacitatea lor de a efectua lucrări de fundal, sunt
esențiale pentru asigurarea unei interfețe ușoare și flexibile a utilizatorului.
Toate aplicațiile Android au un fir principal (cunoscut și sub denumirea de
thread UI) pe care se execută Activitățile. Pentru a menține dispozitivul
receptiv, Android trebuie să poată actualiza interfața cu o viteză de 60 de cadre
pe secundă. Dacă o aplicație Android se comportă mult pe thread-ul principal,
atunci Android va rupe cadre, ceea ce, la rândul său, face ca interfața de
utilizator să apară jerky (uneori denumită și janky). Aceasta înseamnă că orice
lucrare realizată pe thread-ului UI ar trebui să se finalizeze în intervalul de timp
dintre două cadre, aproximativ 16 milisecunde (1 secundă la fiecare 60 de
cadre).

Pentru a rezolva această problemă, un dezvoltator poate folosi thread-uri

în cadrul unei activități pentru a efectua o activitate care ar bloca interfața
utilizator. Cu toate acestea, acest lucru ar putea cauza probleme. Este foarte
posibil ca Android să distrugă și să recreeze multiplele instanțe ale Activității.
Cu toate acestea, Android nu va distruge automat thread-urile, ceea ce ar putea
duce la scurgeri de memorie. Un prim exemplu este atunci când dispozitivul
este rotit - Android va încerca să distrugă instanța Activității și apoi să recreeze
una nouă:
 Aceasta este o pierdere de memorie potențială - thread-ul creat de prima
instanță a Activității va fi în continuare rulat. Dacă thread-ul are o referință la
prima instanță a Activității, aceasta va împiedica Android să șteargă obiectul
dat (sau să fie colectat de garbage collector). Cu toate acestea, a doua instanță a
activității este încă creată (care, la rândul ei, ar putea crea un thread nou).
Rotirea dispozitivului de mai multe ori în succesiune rapidă poate epuiza toată
memoria RAM și poate forța Android să întrerupă întreaga aplicație pentru
recuperarea memoriei.
De regulă, dacă lucrul care trebuie efectuat ar trebui să supraviețuiască
într-o activitate, atunci ar trebui creat un serviciu pentru a efectua această
activitate. Cu toate acestea, dacă lucrarea este aplicabilă numai în contextul
unei activități, atunci crearea unui thread pentru a efectua lucrarea ar putea fi
mai potrivită. De exemplu, crearea unei miniature pentru o fotografie care
tocmai a fost adăugată la o aplicație din galeria foto ar trebui să apară probabil
într-un serviciu. Cu toate acestea, un thread ar putea fi mai potrivit pentru a
reda o anumită muzică care ar trebui să fie auzită doar în timp ce o Activitate se
află în prim-plan.

Calculele de fundal pot fi împărțite în două categorii largi:

Activitate de lungă durată - este o activitate care este în curs de

desfășurare până când se oprește în mod explicit. Un exemplu de activitate pe
termen lung este o aplicație care difuzează muzică sau care trebuie să
monitorizeze datele colectate de la un senzor. Aceste activități trebuie să
funcționeze chiar dacă aplicația nu are o interfață de utilizator vizibilă.
Sarcini periodice - (uneori se face referință la calcule sau lucru) O
sarcină periodică este una cu o durată relativ scurtă (câteva secunde) și se
desfășoară într-un program (o dată pe zi timp de o săptămână sau poate o
singură dată în următoarele 60 de secunde ). Un exemplu este descărcarea unui
fișier de pe internet sau generarea unei miniaturi pentru o imagine.

Există patru tipuri diferite de servicii Android:

Bound Service( serviciu legat ) - Un serviciu legat este un serviciu care
are o altă componentă (de obicei o activitate) legată de acesta. Un serviciu legat
oferă o interfață care permite componentei legate și serviciului să
interacționeze între ele. Odată ce nu mai sunt clienți legați de acest serviciu,
Android va închide serviciul.
IntentService - Un IntentService este o sub-clasă specializată a clasei
Service care simplifică crearea și utilizarea serviciilor. Un IntentService este
destinat să gestioneze apelurile individuale. Spre deosebire de un serviciu care
poate gestiona simultan mai multe apeluri, un IntentService este mai mult ca un
procesor de coadă de lucru - lucrul este așteptat în așteptare și un IntentService
procesează fiecare lucrare unul câte unul pe un singur thread de lucru. În mod
obișnuit, un IntentService nu este legat de o activitate sau un fragment.
Started Service(Serviciu inițiat) - un serviciu început este un serviciu
care a fost pornit de o altă componentă Android (cum ar fi o activitate) și se
execută în mod continuu în fundal, până când ceva indică în mod explicit
serviciului să se oprească. Spre deosebire de un serviciu legat, un serviciu
început nu are niciun client direct legat de acesta. Din acest motiv, este
important să se proiecteze servicii începute astfel încât acestea să poată fi
reîncepute dacă este necesar.
Hybrid Service(Serviciul hibrid) - un serviciu hibrid este un serviciu
care are caracteristicile unui serviciu început(started service) și unui serviciu
legat(bound service). Un serviciu hibrid poate fi pornit de când un element se
leagă de acesta sau poate fi pornit de un eveniment. O componentă a clientului
poate sau nu poate fi legată de serviciul hibrid. Un serviciu hibrid va continua
să fie difuzat până când i se va spune în mod explicit să se oprească sau până
când nu mai sunt clienți legați de acesta.

Permisiuni în Xamarin.Android
Aplicațiile android se executa în propriul spațiu de stocare și din motive
de securitate nu au acces la anumite resurse de sistem sau hardware pe
dispozitiv. Utilizatorul trebuie să acorde în mod explicit permisiunea aplicației
înainte de a putea utiliza aceste resurse. De exemplu, o aplicație nu poate
accesa GPS-ul pe un dispozitiv fără permisiunea explicită a utilizatorului.
Android va arunca o Java.Lang.SecurityException dacă o aplicație încearcă să
acceseze o resursă protejată fără permisiune.
Permisiunile sunt declarate în AndroidManifest.xml de către
programator atunci când este dezvoltată aplicația. Android are două fluxuri de
lucru diferite pentru a obține consimțământul utilizatorului pentru acele
permisiuni:
1. Pentru aplicațiile care vizează Android 5.1 (nivel 22 API) sau mai
mic, cererea de permisiune a apărut la instalarea aplicației. Dacă
utilizatorul nu a acordat permisiunile, aplicația nu va fi instalată.
Odată ce aplicația este instalată, nu există nicio modalitate de
revocare a permisiunilor decât prin dezinstalarea aplicației.
2. Începând cu Android 6.0 (nivel 23 API), utilizatorii au primit mai
mult control asupra permisiunilor; aceștia pot acorda sau revoca
permisiuni atât timp cât aplicația este instalată pe dispozitiv.
 Această captură de ecran afișează setările de permisiune pentru
aplicația Google Contacts. Acesta afișează diferitele permisiuni și
permite utilizatorului să activeze sau să dezactiveze permisiunile:

Aplicațiile Android trebuie să verifice în timpul execuției dacă au

permisiunea de a accesa o resursă protejată sau nu. Dacă aplicația nu are
permisiune, atunci trebuie să facă cereri utilizând noile API-uri furnizate de
kitul SDK Android pentru ca utilizatorul să acorde permisiunile. Permisiunile
sunt împărțite în două categorii:
Permisiuni normale - Acestea sunt permisiuni care prezintă un
risc mic de securitate pentru securitatea sau confidențialitatea
utilizatorului. Android 6.0 va acorda în mod automat permisiuni
normale în momentul instalării.
Permisiuni periculoase - În contrast cu permisiunile normale,
permisiunile periculoase sunt cele care protejează securitatea sau
confidențialitatea utilizatorului. Acestea trebuie să fie explicite
acordate de utilizator. Trimiterea sau primirea unui mesaj SMS
este un exemplu de acțiune care necesită o permisiune
periculoasă.

Permisele periculoase sunt subdivizate în continuare în grupuri de permisiune.

Un grup de permisiuni va deține permisiuni logice. Când utilizatorul acordă
permisiunea unui membru al unui grup de permisiuni, Android acordă automat
permisiunea tuturor membrilor acelui grup. De exemplu, grupul de permisiuni
STORAGE deține atât permisiunile WRITE_EXTERNAL_STORAGE, cât și
READ_EXTERNAL_STORAGE. Dacă utilizatorul acordă permisiunea de
READ_EXTERNAL_STORAGE, atunci permisiunea
WRITE_EXTERNAL_STORAGE este acordată în mod automat în același timp.

În continuare o sa prezentam grafic cum trebuie sa fie proiectata o aplicație

pentru a cere permisiuni de la utilizator în Run-Time sau nu:
Avem două modalități de a adăuga permisiunile în AndroidManifest.xml
 1. Programatic, acestea se adaugă în fișierul AndroidManifest.xml în
următorul mod:

<uses-permission
android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
/>

2. Grafic, accesând opțiunea Properties din Solution Explorer, apoi selectam opțiunea Android
Manifest, după cum este prezentat în screen-ul următor:

Ca să facem o generalizare despre permisiunile android, putem spunea că acestea

permite utilizatorilor să cunoască intuitiv ce se va întâmpla la nivel de cod dacă acesta va
permite o anumită permisiune nativ, în multe cazuri, permisiunile pentru utilizarea anumitor
resurse din SO android sunt violate, de aceia nu se recomanda instalarea aplicațiilor android
din resurse necunoscute, pentru ca aceasta poate obține acces la resursele utilizatorului fără ca
acesta să-și dea consimțământul. Odată cu modernizarea sistemului de operare android, de la
api 23, în play store au fost implementați noi algoritmi care verifică siguranța datelor
utilizatorului și tot o dată permisiunile aplicației, drept consecință practic 25% din aplicațiile
stocate pe serverele google au fost blocate.
 Capitolul II. Crearea
aplicației mobile Librărie
digitală
§ 1.Descrierea aplicației
În continuare o sa discutăm despre posibilitățile ecosistemului Xamarin și
posibilitățile sale în crearea aplicațiilor mobile în special android. Aplicațiile create de mediul
de programare Xamarin sunt percepute de ANDROID ca aplicații native deoarece acestea
sunt convertite în Java cod, diferența fiind practic minimă. Astfel posibilitățile mediului
Xamarin sunt practic la egal cu posibilitățile mediului Android Studio.
Luând în considerație ca astăzi sunt foarte populare store-urile și diferite aplicații ce
permit stocarea informației în Drive-Cloud, mi-am propus ideea dezvoltării unui asemenea
store sau mai bine zis o librărie digitală, orientată spre utilizatorii ce adoră cititul prin
intermediul cărților electronice, aceasta trebuie să conțină funcționalitățile unei biblioteci plus
un acces la cărțile deja stocate te utilizator într-o resursă, acesta poate fi ore tip de Cloud-
Drive, drept exemplu în tandem cu această aplicație va funcționa și un site, acesta având
posibilitatea de a stoca cărți, accesa și citi, toate acestea opțiuni fiind posibile doar în cazul
când utilizatorul este înregistrat în baza de date. Principalele tehnologii pe care ne vom axa în
această aplicație sunt:
- design modern;
- utilizarea api-urilor;
- utilizarea bazelor de date (sql-lite);
- utilizarea librăriilor native Java, pentru citirea fișierelor pdf;

Dacă privim aplicația ca pe un produs atunci va trebui sa specificam pentru ce grup de

utilizatori este orientata aceasta, care sunt părțile tari, de ce utilizatorii ar alege o asemenea
aplicație. Deci haideți sa detalizăm scopul și premisele acestei aplicații. Pentru început
aplicația a fost creata pentru utilizatorii care sunt pasionați de citit și din considerente
financiare sau fizice aceștia nu-și pot permite sa poarte mereu o carte cu ei sau sa cumpere de
fiecare data una noua, astfel aplicația prezintă o bună alternativa din motiv ca acum practic
toți poarta cu ei un smartphone, astfel instalând aplicația pe device utilizatorul va putea sa
aibă acces la resurse de cărți din librăria digitală. Dacă sa specificam resursele disponibile
pentru utilizator atunci trebuie de menționat ca aceștia vor dispune de resurse locale și
resursele cloud, din motivul ca nu mereu vom fi conectați la internet, aplicația are
posibilitatea de a salva cărțile în format electronic pe device, adică în resursele locale, care
vor fi accesate ușor, dacă va lipsi conecsiunea internet pentru ca aceasta nu are nevoie de
internet. Utilizatorii au acces nelimitat la resursele de cărți cloud, cu atât mai mult aceștia pot
sa-și adaoge propriile cărți, adică dacă utilizatorul nu găsește cartea data în resursele siteului
atunci el o poate adaugă, și apoi o găsește și o adaogă în cos sau sa o descarce deja pe device
nemijlocit din aplicație. Trebuie de menționat ca aplicația are posibilitatea de a salva pagina
rămasă, accesa orice fișier de tip pdf de pe device, descarca noi cărți din resursa menționata,
regimul citire rapida(pentru a vedea conținutul cărții înainte de descărcare).
Nu putem spune ca aceasta aplicație folosește ceva nou, toate aceste lucruri sunt
cunoscute demult și aplicate cu succes în diferite aplicații cu diferit grad de complexitate,
acesta aplicație poate surveni doar ca un exemplu al utilizării mai multor tehonologii
combinate în una, vom utiliza POO cu una din cele mai moderne arhitecturi MVVM, vom
construi un design nu prea sofisticat și bucșit cu animații, vom utiliza api-urile create deja cu
ajutorul PHP pentru siteul și resursa noastră(după un anumit standard), vom utiliza obiecte
JSON, o sa le serializam și deserializăm respectiv pentru transmiterea și primirea datelor,
vom utiliza librăriile native java datorita faptului MONO ANDROID.
Ca sa concluzionam aceasta a fost o scurta prezentare a aplicației, în continuare va
urma harta aplicației, prezentarea funcționalului aplicației și respectiv a siteului sursa
(readabook.16mb.com).

§ 2. Structura aplicației
 Readabook este o aplicație user-app adică fiecare utilizator trebuie sa fie
înregistrat pentru a avea acces la aplicație. Pentru mai multe detalii despre structura
aplicație cititorii pot descarca aplicația de pe următorul link
https://mega.nz/#!JgtGhb7T!kcDl0wO4xZ9JHyrEJI49GobB1_GVRyt7KB3oUrtUY
4U . Accesarea acestui link se va face de pe un device ANDROID care va cere
permisiunea de a descarca un fișier în format .apk, după descărcare utilizatorul
trebuie sa activeze opțiunea de instalare a aplicațiilor android din resurse
necunoscute, care se afla în setări. După instalarea aplicației utilizatorul trebuie sa-și
creeze un cont readabook pe următorul link http://readabook.16mb.com/register ,
trebuie de menționat ca utilizatorul nu poate utiliza aplicația dacă contul sau nu este
activat.

În desenul de mai jos sunt afișate opțiunile principale a aplicației la care orice
utilizator are acces.

După cum am menționat anterior aplicația data folosește api-urile site-ului

readabook.16mb.com și cred ca ar fi bine dacă as face o mica prezentare a acestui
site pentru a clarifica mai bine care este relația dintre site și aplicație. Dacă ar fi sa
vorbesc despre “creierul” acestei aplicații atunci acesta ar fi site-ul, de ce? Pentru ca
aplicația readabook este doar un mod de afișare a informației, ea nu păstrează nimic
în sine, pentru ca aceasta ar folosi multe resurse care de obicei deviceurile nu prea
dispun, și logic ar fi ca acestea sa fie “remote” și aplicația sa aibă acces la ele doar
când dispune de internet. Nu pot spune ca proiectul readabook nu procesează date,
procesează dar acestea sunt doar de transmitere și primire, dar ca sa facem aluzie la
site atunci acesta primește datele, le procesează, le transforma în obiecte pe care
readabook.apk le “cunoaște”(JSON) apoi le transmite.

In imaginea de mai jos este afișata pagina principala a site-ului:

Numărul de pagini disponibile pentru utilizatori este afișat în următoarea

imagine:
 Putem observa ca una din pagini poarta numele de api.php, aceasta este
pagina destinata doar pentru aplicație, dar este disponibila și pentru alte proiecte ce
necesita resursele date, acestea doar trebuie sa adapteze proiectul lor în formatul fix
pe care îl transmite siteul. Nu exista nici o limitare intre api și funcționalitatea
siteului, acestea toate pot fi implementate prin intermediul api-urilor. Deci dacă sa
trecem iar la o concluzie despre site atunci pot spune ca acesta prezintă o un web-site
tipic, care cu ușurință poate fi extins la noi funcționalități legat de tema data a
proiectului.

Acest tip de cooperare dintr-un web-proiect și o aplicație destinata

smartphone-urilor este destul de des întâlnită și destul de întrebată de companiile în
creștere ce au nevoie de realizarea produselor lor, și ușurarea acestui proces prin
intermediul acestor aplicații. Cu siguranță ca deja ne dam seama de avantajele
soluționării problemelor de acest tip printr-o astfel de abordare.
§ 3. Etapele elaborării aplicației
3.1. Crearea fișierelor front-end
 După cum am mai menționat sunt două metode de creare a designului,
programatic și cu ajutorul fișierelor xml. Pentru primul caz nu este necesar sa
menționam vreo legătura cu vreun eventual fișier xml, pentru cazul doi va fi necesar
de format legăturile dintre variabilele activității și obiectele(tag-urile) din xml care
vor implementa datele setate din activitate. Pentru aplicația dată eu am folosit aceste
metode combinat, dar în mare parte m-am folosit de metoda a doua(adică cu ajutorul
fișierelor xml) acesta fiind mai utila în crearea unui design mai acceptabil.

Pentru început trebuie de menționat ca un rol important în dirijarea conexiunii

dintre elementele din fișierul xml și pagina (Activitate) îl are fișierul
Resource.designer.cs care este o clasa statica ce salvează toate id-urile la obiectele
din fișier care are atributul de următoarea formă
android:id=``@+id/numele_obiectului`` astfel ca noi îl putem găsi în
Resource.designer.cs în următoarea forma public const int numele_obiectului=(un
numar generat compilator in Run-Time). Toate fișierele xml create pentru design
sunt afișate în imaginea următoare:
 În continuare drept exemplu vom afișa doar un fișier de tip xml, pentru
claritatea cititorilor, iar cei interesați de toate fișierele xml și în genere de aplicație o
pot găsi pe GIT, link-ul către acesta este atașat în anexa.

Cum facem conectarea dintre xml și activitățile aplicației?

Cu aceasta problema se ocupa doua librarii una care face legătura intre
obiectele xml și cele din activitate iar alta care face legătura dinte obiectele din
activitate și cele din ViewModel, deci în continuare voi prezenta doar modul în care
se creează aceasta legătura intre obiecte:

[CrossView(nameof(NameOfViewModel.ObjectName))]
[InjectView(Resource.Id.object_id_in_xml)]

public ObjectType ObjectName { get; set; }

Sa precizam ce acțiuni îndeplinesc fiecare din librăriile menționate în

exemplu de mai sus. Librăria ce are grija de crearea legăturii dintre fișierele xml și
activitate este Cheeseknife aceasta cauta în fișierul xml obiectele cu id-ul
menționat în Resource.Id.object_id_in_xml și îl leagă cu obiectul de tipul
ObjectType cu numele ObjectName. Deci ca sa concretizam pentru crearea legăturii
dintre xml și activitate se îndeplinește doar cu următorul cod:

[InjectView(Resource.Id.object_id_in_xml)]

public ObjectType ObjectName { get; set; }

Foarte des putem obține crash-uri din motiv ca obiectul din xml nu-i
corespunde obiectului din clasa activitate cu alte cuvinte pentru fiecare obiect xml
exista o clasa C# care ii corespunde lui. Mai jos o sa afișam corespondenta dintre
unele clase C# și unele obiecte xml:

Clase C# Obiecte xml

 Containere

LinearLayout <LinearLayout/>

RelativeLayout <RelativeLayout/>

View <View/>

ScrollView <ScrollView/>

Text-containere

TextView <TextView/>

EditText <EditText/>

Container pentru imagini

ImageView <ImageView/>

Container pentru butoane

Button <Button/>

Container pentru progress-bar-uri

ProgressBar <ProgressBar/>

A doua librărie are un rol mai specific aceasta implementează obiectele care
sunt valabile pentru arhitectura android în proiectul “cross” (proiectul comun pentru
toate celelalte proiecte destinate unui anumit SO), deci sa afișam codul care ne
permite crearea legăturii intre obiectele din cross și cele din proiectul nostru android:

[CrossView(nameof(NameOfViewModel.ObjectName))]

public ObjectType ObjectName { get; set; }

Trebuie sa menționam ca datorita faptului ca clasa activity admite parametri

generici, noi putem crea interfețe care fiind definite în ViewModel acestea se vor
implementa diferit pentru fiecare platforma, spre exemplu avem interfața ITex care
este implementată și TextView, EditText.

În ModelView se setează conținutul obiectelor conținute în design, de

asemeni tot aici se descarca datele, se implementează metodele pe care le conțin
interfețele date.

2. Interacțiunea cu baza de date

După părerea mea aceasta este partea cea mai interesanta a aplicației, datorita
faptului ca proiectul de la început a fost plănuit ca cross-patform, designul și
manipularea obiectelor este asemănător, unica deosebire fiind lipsa altor proiecte ce
ar implementa codul “comun”. De aceia pentru a lucra cu obiectele JSON primite din
resursa noi a trebuit sa implementam diferit transmiterea și primirea datelor, decât în
cazul în care as fi făcut doar un proiect strict orientat numai pentru sistemul de
operare ANDROID.

În continuare o sa analizam metodele ce ne permit transmiterea datelor si

primirea acestor date deja în obiecte C#, pentru aceasta avem creata o clasa ce are
metode cu parametri generici, asta facilitează mult procesul de transformare a
obiectelor din JSON în obiecte C#, reducându-se doar la chemarea acestei metode
din clasa statica, iar obiectul ce îl returnează aceasta metoda este tot de tip generic și
este egal cu tipul introdus. Deci haideți sa vizualizam metodele date:

public IRestCallbackClient GetBooksFromCategory(ICategoryContent

model)

var
somedata=Request(RestConstants.GetBooksForCategory+"/"+model.category,
Method.GET,

RestConstants.MediaTypeJson, requestTo: RequestTo.Key);

return somedata;

Metoda de mai sus are menirea de a crea request-ul la server și de a primi

datele în format JSON, după contextul returnat de aceasta metoda este deserializat în
obiecte C# de metoda care urmează:

public void GetBooksFromCategory(Action<IList<Booklist>> success,

Action<string> error)

ICategoryContent somevalue =
BooksManager.Instance._curentCategory;
 var response =
RequestFactory.ExecuteRequest<MResponse<IList<Booklist>>>(RestCalls.Instance
.GetBooksFromCategory(somevalue));

response.OnResponse(() => { success?.Invoke(response.Data); },

exception => error?.Invoke(exception.Message));

, trebuie sa menționăm ca aceste doua metode se refera doar la transmiterea și

primirea datelor în formatul specificat de obiectul generic pe care trebuie sa-l
returneze acestea, în cazul nostru pentru aceste metode obiectul generic este
IList<Booklist> cu alte cuvinte o lista de cărti.

Sa vedem ce format JSON primim noi atunci când se executa prima metoda,
cea care primește datele prin intermediul api-urilor:

{"data":[{"id":"15","title":"Fericirea mea esti tu ","author":"Jamie

McGuire","category":"Dragoste","date":"2018-03-09","publication_date":"2018-03-
09","description":"Travis Maddox a \u00eenv\u0103\u0163at dou\u0103 lucruri de
la mama sa \u00eenainte ca aceasta s\u0103 moar\u0103: Iube\u015fte mult.
Lupt\u0103 \u015fi mai mult pentru iubirea ta.\r\n\u00cen Fericirea mea e\u015fti tu,
via\u0163a lui Travis e plin\u0103 de femei care vin \u015fi pleac\u0103, de jocuri
de noroc ilicite \u015fi de violen\u0163\u0103. \u00cens\u0103 tocmai c\u00e2nd
Travis se consider\u0103 invincibil, Abby Abernathy \u00eel pune la
p\u0103m\u00e2nt.\r\nFiecare poveste are dou\u0103 versiuni. \u00cen Fericirea
\u00eencepe azi, Abby vorbe\u015fte \u00een numele ei. Acum e timpul s\u0103
citim povestea prin ochii lui Travis.\r\n\r\n\u201eTravis e un tip impulsiv.
\u00cencerc\u00e2nd s\u0103 scriu din punctul lui de vedere, am \u015ftiut c\u0103
nu puteam s\u0103 spun povestea din nou, pur \u015fi simplu. Mi-am \u00eendreptat
aten\u0163ia asupra perioadei c\u00e2nd Abby \u015fi Travis nu erau
\u00eempreun\u0103, pentru ca romanul s\u0103 aduc\u0103 lucruri noi \u015fi am
sentimentul c\u0103 am reu\u015fit s\u0103 fac ce mi am propus.\" -- Jamie
Mcguire\r\n\r\n\u201eFericirea mea e\u015fti tu are avantajul c\u0103 vine
dup\u0103 o poveste emo\u0163ionant\u0103, pe care o completeaz\u0103, \u015fi
c\u0103 are un epilog ingenios, ce surprinde un instantaneu din via\u0163a lui Travis
\u015fi a lui Abby \u00een viitor.\" -- Reading, Eating &
Dreaming","rating":"14","user_id":"20","downloands_number":"8","download_linq"
:"Resources\/books\/Dragoste\/Jamie_McGuire_-
_Fericirea_mea_esti_tu.pdf","image_linq":"Resources\/images\/Dragoste\/fericirea_
mea_esti_tu.jpg"},{"id":"34","title":"Marele Gatsby","author":"Scott
Fitzgerald","category":"Dragoste","date":"2018-04-18","publication_date":"2018-
04-18","description":"Jay Gatsby, un simbol al pove\u015ftii americane de succes,
vrea s\u0103 recupereze trecutul \u015fi paradisul pe care le asociaz\u0103 cu prima
lui iubire, Daisy Buchanan. Este am\u0103git de un vis care se dovede\u015fte
nedemn de el, iar Fitzgerald \u00eenal\u0163\u0103 c\u0103derea lui Gatsby la
nivelul unui mit american esen\u0163ial. Romanul se \u00eencheie cu unul dintre
cele mai sugestive pasaje lirice din literatur\u0103: \u00abGatsby crezuse
p\u00e2n\u0103 la urm\u0103 \u00een lumini\u0163a aceea verzuie, \u00eentr-un
viitor frem\u0103t\u0103tor, care se \u00eendep\u0103rteaz\u0103 \u00eens\u0103
cu fiece an \u00een fa\u0163a noastr\u0103. Ne-a sc\u0103pat o dat\u0103, dar ce
importan\u0163\u0103 are... m\u00e2ine o s\u0103 fugim mai repede, ne vom
\u00eentinde bra\u0163ele mai departe... \u015ei tot a\u015fa, p\u00e2n\u0103
\u00eentr-o diminea\u0163\u0103... \u015ei tot a\u015fa, trecem de la o zi la alta,
barci \u00eempinse de curent, \u00eempinse fara \u00eencetare, tot mai \u00eenapoi,
\u00een trecut\u00bb. \u00cen Marele Gatsby, Fitzgerald realizeaz\u0103 ceea ce nu
va mai face \u00een toat\u0103 cariera sa ulterioar\u0103: o satir\u0103 a
moravurilor contemporane care con\u0163ine adev\u0103rurile \u2013 personale
\u015fi sociale \u2013 cele mai profunde. Dac\u0103 subiectul predilect al lui
Hemingway este r\u0103zboiul, al lui Fitzgerald este Visul american \u015fi
tr\u0103darea acestuia, subiect care face conexiunea \u00eentre via\u0163a
privat\u0103 a scriitorului, cariera lui \u015fi c\u0103r\u0163ile sale \u00eentr-un
\u00eentreg tematic. Fitzgerald r\u0103m\u00e2ne principalul cronicar al puterii
seduc\u0103toare a bog\u0103\u0163iei \u015fi faimei. Nici un alt scriitor american
nu s-a pozi\u0163ionat asemenea lui \u2013 chiar \u00een ad\u00e2ncul sufletului
american.\u201c (Daniel S. Burt)\r\n\r\n\u201eCred c\u0103 romanul este o
minune.\u201c
(","rating":"0","user_id":"20","downloands_number":"0","download_linq":"Resourc
es\/books\/Dragoste\/fitzgerald-scott-marele-
gatsby.pdf","image_linq":"Resources\/images\/Dragoste\/marelegatsby.jpg"}]}

În continuare o sa afișam conținutul obiectului Booklist care prezintă

conținutul obiectului referitor la detaliile cărții electronice:

public class Booklist

public int id { get; set; }

public string title { get; set; }

public string author { get; set; }

public string category { get; set; }

public string date { get; set; }

public string publication_date { get; set; }

public string description { get; set; }

public string rating { get; set; }

public string user_id { get; set; }

public string downloands_number { get; set; }

public string download_linq { get; set; }

public string image_linq { get; set; }

De obicei este primit ca de prelucrarea datelor sa se ocupe o clasa speciala în

cazul nostru aceasta este BookManager care are responsabilitatea de a ne oferi
conținutul din baza de date, și anume pentru diferite activități aceasta ne va oferi
datele corespunzătoare.

Ca sa concluzionam la acest subiect atunci putem spune ca e o experiența

buna ca manipularea datelor, descărcarea acestora, conexiunea la baza de date, sa se
afle în proiectul cross iar tot ce este legat de design și implementări caracteristice
sistemului de operare sa fie executate în proiectul ANDROID (în cazul nostru).

3.3. Asigurarea vizualizării resurselor .pdf

Afișarea fișierelor de tip pdf este problematica pentru versiunile de android ce
depășesc versiunea android 4.2 din motiv ca pana atunci afișarea acestui tip de fișiere
era asigurata în mod implicit de către sistemul de operare ANDROID. Ar fi fost ușor
dacă aplicația se plănuia numai pan la versiunea 4.2, dar nu este asa, din motiv ca
noile versiuni android nu pot afișa acest tip de fișiere, trebuie sa implementam
metode și librarii care ne vor permite sa vizualizam acest tip de fișiere. Sunt multe
librarii care ne permit sa citim fișiere de acest tip dar acestea toate sunt cu plata,
astfel ca a trebuit sa înconjuram soluțiile care ne impun la cheltuieli, de aceia am
ajuns la ideea ca trebuie de cautat mijloace mai acceptabile adică acelea care nu
implica cheltuieli. Asa dar am găsit doua metode datorita faptului ca android poate
afișa și conținutul web cu ajutorul obiectului WebView noi putem afișa conținutul
pdf, dar nu și fără a utiliza librăriile JavaScript, pentru ca WebView-ul în adndroid
de la versiunea 5 nu mai afișează pdf-ul, și a doua metoda care vizează utilizarea
librăriilor native adică cele scrise în limbajul JAVA, datorita faptului ca tot codul
scris de noi în C# mai apoi de către tehnologia Mono Android este interpretat în Java
cod, ajungem la ideea ca noi putem folosi librăriile native în momentul Run-Time, și
deci rămâne doar de adăugat acestea în proiect, și apoi de implementat librăria
Xamarin.PdfView.Android.

Eu am ales metoda a doua, astfel am fost nevoit sa adaug în mapa lib

următoarele foldere ce conțin librăriile native după cum observați în imaginea de mai
jos:

Fisierul libvudroid.so este librărie care este adaptata pentru toate tipurile de
procesoare întâlnite pentru care SO Android se poate instala. De aceia în folderul lib
denumirile celorlalte foldere indica SO pentru ce tip de procesor este librăria data,
astfel ca android va alege librăria destinata tipului sau de procesor.

Cum are loc interpretarea fișierelor .pdf cu ajutorul acestei librarii?

Librăria data are funcția de a converti fișierele pdf în imagini, de aceia faptul
ca aceasta interpretează fiecare pagina ca imagine, face posibila afișarea textului mai
clar, iar zoom-ul devine o funcție ușor de implementat din motiv ca odată ce lucram
cu imagini acestea au metode speciale care permit acest lucru. Saltul de la o pagina
la alta este posibil doar încărcând cartea din nou în containerul ce o afișează, de aceia
ca folosirea metodelor asincronice ce fac acest lucru, încarcă memoria, și asta face ca
aplicația sa-și oprească activitatea.
 Un alt subiect ce tine de asigurarea vizualizării fișierelor pdf este, cum găsesc
toate fișierele cu extensia .pdf din device, pentru ca ANDROID nu are nici o metoda
care ar putea face asta, este necesar sa o cream noi. Mai jos este afișat exemplu cum
putem extrage adresele fișierelor cu o anumita extensie:
public List<LocalBook> GetAllBooksListFromDevidce(File
parentDir, string PathToParentDir)

{ string[] fileNames = parentDir.List();

foreach (string fileName in fileNames)

if (fileName.ToLower().EndsWith(".pdf"))

inFiles.Add(new LocalBook

{ Id=BookCounter,

Name = fileName,

FileContent = new File(parentDir.Path

+ "/" + fileName),

PathFile = parentDir.Path + "/" +

fileName,

});

BookCounter++;

}else{

File file = new File(parentDir.Path + "/"

+ fileName);

if (file.IsDirectory)

{ inFiles.Union(
GetAllBooksListFromDevidce(file, PathToParentDir + "/" +
fileName));

return inFiles;
 }

Aceasta metoda creează o lista de fișiere, folderele făcând parte tot din aceasta
categorie, după fiecare listă se verifica dacă elementele ei se termine cu stringul
“.pdf” și dacă da atunci acest element este adăugat într-o noua lista în cazul nostru se
numește inFile. După cum va dați seama cu aceasta aplicație putem ușor sa extragem
orice tip de fișier care se afla în device, muzica, poze, fișiere txt, careva date
personale.

§ 4. Testarea și mentenanța aplicației

Una din problemele principale, care persista mereu la orice proiect este
testarea și mentenanța, acestea iau în mare parte cel mai mult timp și cele mai
multe resurse. În momentul creării proiectului nu poți prevede orice situație de aceia
aplicațiile înainte de a fi publicate în masa trebuiesc testate, aceste teste de regula se
îndeplinesc de programiști competenți în domeniul dat numiți “testeri”, iar toate
greșelile, și spargerile aplicației sunt înregistrate și retransmite progremiștilor pentru
a le rezolva. Sunt și tehnologii care permit testarea automata a aplicațiilor numita
UNI-Test, dar aceasta nu poate prevede toate circumstanțele în care poate apărea un
BUG.

Unele aplicații care folosesc servicii și tehnologii externe cum ar fi

implementarea serviciilor google, etc, pe mentenanța este pus un accent mai
pronunțat, din motiv ca odată ce acestea își modifică formatul atunci aplicațiile ce le
folosesc nu mai funcționează corect, și necesita o adaptare după noile modificări.

Drept rezultat al mentenanței și al testării, aplicațiile obțin noi update-uri sub

forma de versiuni, cu fiecare versiune mai noua acestea devin mai stabile și mai
simplu de utilizat, de asemeni cu noile versiuni, apar și funcționalități noi, aceasta
tine de procesul de mentenanță, pentru ca fiecare fixare de erori și extindere de
funcțional este însoțită de o noua versiune a aplicației.

Perspectivele aplicațiilor scrise în mediul de programare Xamarin sunt destul

de mari, acestea pot fi mereu extinse la noi funcționalități, cu condiția ca arhitectura
acestei aplicații sa fie corect scrisa și sa fie păstrate principiile SOLID. De aceia este
foarte util ca în procesul creării aplicației sa utilizam diferite patern-uri precum:
SINGLETON, PROXY, FACADE, OBSERVER, … .

Aplicarea patern-urilor simplifica considerabil logica arhitecturii, din motiv ca

aceasta devine una fixa, pe care în dependenta de caz sunt metode de a le extinde.

Aplicația prezentata în teza data de asemeni poate fi extinsa la noi

funcționalități, i se poate de implementat versiunea IOS a aplicației, i se poate de
adăugat comentarii la cărți (pentru ca utilizatorii sa vadă părerile celor care au citit
cartea), se poate de creat paginările( pentru simplitatea navigării prin cărți), etc.
§ 5.Codurile sursa ale aplicației
Marea majoritate a programiștilor sunt deprinși în momentul dezvoltării unei
aplicații sa folosească tehnologia controlului versiunilor, precum Git sau alte
derivate a acestui OpenSource. Avantajele utilizării unei astfel de tehnologii nea
ajuta însemnat de mult în momentul când apar probleme cu arhitectura aplicației, sau
trebuie de derivat de la acest proiect un alt proiect nou, astfel controlul versiunilor
este extrem de util, din doar câteva comenzi poți obține o nouă versiune a aplicației.
Controlul versiunilor se folosește nu numai pentru a salva o anumita versiune a
aplicației, ci și pentru a vizualiza schimbările făcute de un anumit dewelopper o data
cu crearea unui nou “commit”.

La proiecte și aplicații la care participa mai multi programiști, controlul

versiunilor este un mare avantaj, deoarece concomitent la acest proiect pot lucra mai
multi programiști, astfel proiectul poate fi realizat în timp record.

Eu la fel am folosit controlul versiunilor pentru ambele proiecte, atât pentru

readabook.apk cat și pentru site.php. Mai jos voi afișa imaginea proiectului situat pe
GitHub și linkul pentru ca cei interesați să poată studia proiectul mai detaliat.

Codul sursa pentru proiectul readabook îl găsiți pe următorul link:

https://github.com/IonCojucovschi/Thesis
 Codul sursa pentru site-ul ReadAbook.16mb.com îl găsiți pe următorul link:

https://github.com/IonCojucovschi/sitephp

Bibliografie
 1. C# in a Nutshell. Joseph Albahary, Ben Albahary;
2. C# in Depth. John Skeet;
3. Creating Mobile Apps with Xamarin.Forms. Charles Petzold;
4. Enterprize Application Patterns using Xamarin.Forms. David Britch;
5. Head first Design Patterns. Eric Freeman, Elizabeth Freeman;
6. https://docs.microsoft.com/en-us/xamarin/#pivot=platforms&panel=Android ;
7. https://docs.microsoft.com/en-us/xamarin/android/app-fundamentals/index ;
8. https://docs.microsoft.com/en-us/xamarin/cross-
platform/troubleshooting/component-nuget?tabs=vswin ;

Cuvinte-cheie
 Cross-platforma, aplicație, pattern, moștenire, design, implementare, Run-
Time, Mono Android, activitate, servicii, api, JSON, librărie, customizare,
mentenanță, sistem de operare, permisiuni, … .