Xamarin

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 de zvoltarea 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 a plicației ................................ ............................................ ........................ ..................... .........

45

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

45

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

50

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

55

§ 4. Testarea și mentenanța aplicației (rezolvarea probleme, probleme, probleme deschise, perspective, etc.)...........................................................................

58

§ 5. Codurile-sursă ale aplicației

60

...................... .................................. ......................... ......................... .................. ......

Bibliografie ……………….......... ………………...................... ........................ ........................ ......................... ........................ .............. ...

62

Concluzii 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 a poi 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. “control” numit c. In Windows Runtime API, este un 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 difer ite 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 e xistă 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 MonoDevel op. 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-visualstudio/?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 Win dows 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 (ModelView-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 progr amator 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 pr ogram 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 oper are 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 public

(Label class

=

"Phone

Word",

MainActivity

MainLauncher :

=

true)] 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 ec ranul 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 ti mp 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 ar unca 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:

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 aces tea 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 asemene a 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 cart e 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 s erializam ș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 car e 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 cor espondenta dintre unele clase C# și unele obiecte xml:

Clase C#

Obiecte xml

Containere

LinearLayout

RelativeLayout

View

ScrollView

Text-containere

TextView

EditText

Container pentru imagini

ImageView

Container pentru butoane

Button

Xamarin

Recommend Documents