Dezvoltarea Unei Aplicatii Native Cross Platform Pentru Administrarea Evenimentelor

Cuprins

1.Capitolul 1. Introducere și noțiuni teoretice 4

1.1.Introducere 4

1.2.Motivație 5

1.3. Sumar 5

1.4. Noțiuni teoretice 6

1.4.1. Ce este o platformă mobilă 6

1.4.2. Android 7

1.4.3. iOS 7

1.4.4. Windows Phone 8

1.4.5. Aplicații native 8

1.4.6. Aplicații cross-platform 9

2. Capitolul 2.Tehnologii folosite 11

2.1. C# și .NET 11

2.2. XAML 11

2.3. Xamarin 12

2.4. Xamarin.Forms 14

2.5. Universal Apps 15

2.6. MVVM 15

2.7. Portable Class Library vs. Shared Asset Project 17

2.8. Xamarin Studio 21

2.9. Visual Studio 21

3.Implementarea aplicației 22

3.1. Structura aplicației 22

3.1.1. Structura soluției Universal App 22

3.1.2. Structura soluției Xamarin.Forms 24

3.1.3.Structura proiectului KT_CommonMobile 25

3.2. Funcționalități comune pentru fiecare pagină 26

3.3. Funcționalitățile aplicației 29

3.4. Pagina ScannerPage 30

3.4.1. Folosirea camerei în soluția Universal App 32

3.4.2. Folosirea camerei în soluția Xamarin.Forms 36

3.5. TransitionPage 40

3.6. DashboardPage 43

4. Capitolul 4. Concluzii 45

Bibliografie 46

Capitolul 1. Introducere. Noțiuni Teoretice

Introducere

În ultimii opt ani, cu apariția primului model de telefon de la Apple, denumit iPhone, lumea telefoanelor mobile s-a schimbat în multe privințe. Înainte, oamenii își achiziționau telefoane din motive clar definite, cum ar fi: convorbiri telefonice, mesagerie de tip sms sau fotografii. Aplicațiile mobile pe vremea respectivă nu erau foarte răspândite, utilizatorii puteau descărca câteva jocuri, majoritatea lor scrise în Java, însă acestea nu erau ușor de folosit, și aveau funcționalități limitate. Odată cu trecerea timpului pe piață au apărut așa numitele telefoane inteligente, cunoscute pe piață sub denumirea de smartphone-uri, care erau mult mai performante decât telefoanele obișnuite și aveau aplicații mult mai dezvoltate. Acestea aveau și multe limitări, sistemul de operare era lent, dimensiunile lor erau de cele mai multe ori prea mari, ecranele nu erau tactile, iar pentru operare se foloseau butoanele.

Anul 2007 a fost anul în care compania Apple a lansat primul lor telefon, un dispozitiv care a fost conceput total diferit față de telefoanele de pe vremea respectivă. Primul iPhone a avut un ecran mare, tactil, ușor de folosit prin gesturi, a avut performanțe foarte bune, iar sistemul de operare iOS a fost foarte intuitiv. Astfel, utilizatorii au început să întelegă conceptul de aplicație diferit. În scurt timp a apărut cererea din partea acestora pentru aplicații, care nu erau furnizate cu sistemul de operare. În anul 2008 Apple a lansat magazinul online pentru aplicații iOS, denumit App Store, care aproape imediat a stimulat dezvoltatorii de aplicații să-și creeze programe pentru iPhone. Deoarece piața dispozitivelor mobile se dezvolta într-un ritm alert, în scurt timp, au apărut concurenți pentru Apple și magazinul lor online, și anume: platforma Android de la Google, cu magazinul online Google Play, respectiv sistemul de operare Windows Phone cu magazinul online Store, dezvoltat de Microsoft.

Cu cele trei platforme existente, un dezvoltator de aplicații mobile trebuie să decidă de la început care este platforma pentru care dorește sa dezvolte. Firecare platformă în parte presupune cunoștințe specifice. Astfel, pentru dezvolatrea aplicațiilor Android se va folosi limbajul java, Objective-C pentru IOS, iar pentru Windows Phone limbajul C#.

Problema mare este constituită de alegerea finală. Pentru a fi capabil să dezvolte aplicații pe toate platformele actuale, un programator trebuie să conoască atât limajul de programare aferent, cât și SDK-ul utilizat.

Pentru problemele menționate dezvoltatorii au început să caute soluții. A apărut ideea aplicațiilor cross platformă, care au scopul de a simplifica acest proces, astfel încât codul sursă să fie partajat de toate platformele. Codul va fi scris o singură dată, iar compilarea va fi per toate platformele.

Motivație

Această lucrare își propune să prezinte o modalitate de a dezvolta aplicații cross-platform pentru dispozitive mobile. Pentru prezentarea procesului de dezvoltare a aplicațiilor cross- platform, am creat o aplicație numită KT MyAdmin. Programul rulează pe platformele Android, și Windows Phone, și facilitează controlul accesului pentru evenimentele online. Înainte de a prezenta detaliile de implementare a aplicației, și modul de a folosi aceasta, doresc să prezint principali termeni pentru dezvoltarea cross-platform, și anume platformele principale de telefoane mobile, diferențele dintre acestea, conceptul aplicațiilor native față de cele cross-platform.

Sumar

În acest capitol intenția mea este să prezint conceptele necesare pentru dezvoltarea aplicațiilor pentru dispozitive mobile, respectiv pentru dezvoltarea aplicațiilor cross-platform.

Capitolul al doilea, “Tehnologii folosite” va prezenta tehnologiile folosite în implementarea aplicației KT_MyAdmin.

În al treilea capitol, “Implementarea aplicației” vor fi descrise funcționalitățile aplicației, respectiv modul în care aceste funcționalități au fost implementate

În capitolul final vor fi prezentate concluziile la care am ajuns în urma dezvoltării aplicației KT_MyAdmin.

Noțiuni teoretice

Ce este o platformă mobilă

Pentru a înțelege mai bine conceptul platformelor mobile trebuie să recapitulăm cunoștințele despre sistemele de operare tradiționale. Sistemul de operare reprezintă ansamblul de programe care asigură utilizarea optimă a resurselor fizice și logice ale unui sistem de calcul. El are rolul de a gestiona funcționarea componentelor hardware ale sistemului de calcul, de a coordona și controla execuția programelor și de a permite comunicarea utilizatorului cu sistemul de calcul [1] . Facilitățile unui sistem de operare sunt următoarele: abstractizarea hardwarelui prin ajutorul API-urilor sistem, arhitecturi de securitate, administrarea proceselor și a memoriei operative cu scopul de a facilita utilizarea mai optimă a resurselor hardware.

O platformă mobilă este echivalentul unui sistem de operare tradițională, dar care este conceput în mod exclusiv pentru dispozitivele mobile, cum ar fi smartphoneurile, personal digital assistent(PDA) sau tablete [2]. Sistemele de operare mobile sunt similare cu cele tradiționale dar sunt simplifacate față de acestea, și gestionează în mod principal rețelele locale și wireless, task-uri multimedia și diversele metode de input. Platformele mobile au la dispoziție resurse limitate, cum ar fi memorii operaționale cu mărimi reduse, procesoare mai lente, medii de stocare mai mici [2], și durată de autonomie limitată din cauza bateriilor. În momentul de față există numeroase sisteme de operare pentru telefoane mobile, cum ar fi: FlymeOS de la Meizu, Tizen de la Samsung si Intel, Ubuntu Touch de la Canonical, iOS de la Apple, BlackBerry OS de la Research In Motion(RIM), Windows Phone de la Microsoft, si Firefox OS.[2] Diferitele platforme presupun aplicații scrise în limbaje diferite, apeluri de API diferite, respectiv necesită bune cunoștințe a diferitelor medii de dezvoltare și a ciclurilor de viață diferite a aplicațiilor specifice platformei ținte.

Aplicația KT MyAdmin țintește platformele cele mai populare, și anume iOS , Android și Windows Phone.

Figura nr. 1. Platformele ținte pentru KT MyAdmin [3]

1.4.2 Android

Android este o platformă mobile cu un kernel Linux modificat. A fost introdusă în noiembrie 2007 de alianța Open Handset Alliance, care include companiile Google, HTC, Motorola, Texas Instruments, etc. Majoritatea aplicațiilor dezvoltate pentru platforma Android sunt implementate în limbajul de programare Java. Acest fapt nu înseamnă, că pentru rularea aplicațiilor este nevoie de mașină virtuală Java (Java Virtual Machine). Clasele Java sunt compilate în fișiere executabile Dalvik, iar ele rulează pe sistemul virtual Dalvik[4].

Android este un sistem de operare deschisă. Termenul deschis nu înseamnă, că oricine poate contribui la dezvoltarea platformei, ci reprezintă faptul, că Google dă acces la codul de sursă a platformei. În acest sens, dezvoltatorii interesați pot descărca codul sursă pentru varianta cea mai nouă, și pot crea propriile variante pentru sistemul de operare.

Pentru a crea aplicații pentru platforma, dezvoltatorul trebuie să descarce Android SDK, care include instrumentele de dezvoltare și API-urile specifice.

1.4.3 iOS

iOS este un sistem de operare mobilă dezvoltat în mod exclusiv pentru dispozitivele Apple. Platforma a fost lansată în 2007 cu apariția primului model iPhone, și a fost extinsă să suporte și pe celelalte dispozitive mobile din gama Apple, cum ar fi iPad, iPod Touch și Apple TV[5].

Platforma este o variantă a sistemului de operare Mac OS X și este un sistem de operare de tip Unix. Există patru nivele de abstractizare conform iOS:

-nivelul Core OS: oferă facilități pentru securitate și interacțiuni cu hardware extern

-nivelul Core Services Layer: oferă servicii necesare pentru nivelele mai superioare

-nivelul Media: ofera tehnologiile necesare pentru grafica, audio si video

-nivelul Cocoa Touch Layer: pe acest nivel se găsesc frameworkurile folosite la crearea aplicatiilor

Dezvoltatorii pot folosi SDK-ul iOS pentru crearea aplicațiilor Apple. SDK-ul include instrumente și interfețe pentru dezvoltarea și testarea aplicaților. Aplicațiile native pot fi scrise folosind de frameworkurile iOS și limbajul de programare Objective-C [6].

1.4.4 Windows Phone

Windows Phone reprezintă familia sistemelor de operare dezvoltate de Microsoft pentru dispozitivele mobile, cu scopul de a înlocui platforma Windows Mobile. Platforma a fost lansată în 15 Februarie 2010, prima versiune fiind denumită Windows Phone 7. Ultima versiune este denumită Windows Phone 8.1, și a fost prezentată tă în 14 Aprilie 2014 [7].

Dezvoltarea aplicațiilor Windows Phone se face cu ajturorul frameworkului Windows Runtime, care facilitează crearea aplicațiilor destinate platformelor Windows si Windows Phone. Frameworkul Windows RT reprezintă un nivel nativ, însă aplicațiile care fac apeluri la el pot rula și pe procesoarele Intel și ARM. Programele scrise cu API-urile WinRT se pot rula cu puține modificări atât pe telefoane mobile cât și pe calculatoare[8].

Cu aceste trei platforme existente, un dezvoltator trebuie să facă o decizie înainte să se apuce la implementarea unei aplicații: crează o aplicație nativă, care este destinată pentru o singură platformă, sau dezvoltă o aplicație cross-platform.

1.4.5 Aplicații native

O aplicație nativă este un program care a fost dezvoltat cu scopul de a fi folosit pe o singură platformă. Aplicațiile native sunt implementate pentru o singură platformă specifică, de aceea pot profita de caracteristicile sistemului de operare, respectiv pot interacționa în mod direct cu acesta. O aplicație nativă poate să folosească de toate posibilitățile hardware și software specifice pentru dispozitiv, inclusiv de tehnologiile cele mai noi disponibile, fapt ce înseamnă un avantaj față de aplicațiile web sau cloud [9].

Deoarece aplicațiile native sunt concepute pentru o singură platformă, trebuie ținut cont în fiecare etapă a dezvoltării de componentele hardware a dispozitiveleor cum ar fi unitatea procesare centrală și setul ei de instrucțiuni. Aplicațiile native sunt fișiere binare executabile care vor fi instalate pe dispozitivul mobil fără să fie necesară un nivel de abstractizare a sistemului de operare. Folosind sdk-ul specific platformei destinate, ele au capacitatea de a apela la funcționalitățile dispozitivului, cum ar fi contactele sau serviciile de email. În ciuda faptului că dezvoltarea aplicațiilor native necesită îndemânarea platformei, strategia aceasta ajută la implementarea unei experiențe de utilizator mai bună decât celelalte metode de dezvoltare software.

Pentru prezentarea dezavantajului major al aplicațiilor native putem să considerăm exemplul următor: să presupunem că avem o aplicație iOS, pe care am lucrat 6 luni, am petrecut mult timp citind tutoriale, cărți, căutând răspunsuri pentru întrebări. Aplicația a devenit un mare succes pe App Store cu multe păreri pozitive, și pe urmă apare un interes pentru aplicația și din partea utilizatorilor Windows Phone și Android. Pentru a satisface acest interes avem trei posibilități: prima posibilitate este de a rescrie aplicația, petrecând încă un an cu învățarea celorlalte platform-uri. În acest caz, vom avea trei aplicații separate, care înseamnă că modificările ulterioare trebuie aplicate pe toate trei aplicații. A doua posibilate este angajarea dezvoltatorilor care sunt pricepuți în celelalte platforme, dar decizia aceasta ar însemna costuri suplimentare. A treia posibilitate este dezvoltarea unei aplicații cross-platforme care să destineze pe toate cele trei platforme majore.

Aplicații cross-platform

O aplicație este considerată cross platform, dacă este capabilă să funcționeze pe mai multe arhitecturi de calculatoare, respectiv pe mai multe sisteme de operare. Dezvoltarea unei astfel de aplicație poate deveni un proces lung, din cauza interfețelor de programare diferite pentru fiecare platformă, respectiv de limbajurile de programare diferite[10].

Un factor comun între platformele existente este suportul pentru HTML și JavaScript, iar cu ajutorul acestor două tehnologii dezvoltatorul poate să creeze o aplicație Web, care este capabilă să ruleze prin browserele de web instalate. Această modalitate reprezintă o primă variantă pentru aplicații cross-platform, care sunt dezvoltate doar o dată, și poate să apeleze anumite API-uri ai telefonului prin JavaScript. Dezavantajul acestei abordări este că aplicația este dependentă de browserul platformei, nu poate să ruleze singur și multe facilități al sistemului de operare nu pot fi accesate prin intermediul lui JavaScript.

A doua posibilate pentru dezvoltarea aplicațiilor cross platform este de a folosi un framework care facilitează dezvoltarea aplicațiilor hibride folosind HTML și JavaScript. Un astfel de framework este PhoneGap, care permite crearea aplicațiilor mobile folosind JavaScript, HTML, și CSS3 [11]. Termenul hibrid înseamnă că aplicațiile nu sunt cu adevărat native, dar nu sunt nici aplicații web-based. Diferența față de o aplicație nativă este reprezentată de faptul că interfața utilizator nu este realizată prin frameworkul UI nativ, ci este construită prin utilizarea Web View-urilor, scrise în cod HTML și CSS. Diferența față de o aplicație web este că aplicația hibridă poate apela API-urile native a platformelor, fiind ambalată ca o aplicație mobilă nativă, cu posibilitatea de a o încărca în magazinele online de aplicații. Aplicațiile hibride reprezintă o alternativă bună pentru aplicațiile native, însă aceste aplicații nu pot să ofere senzația UI a aplicațiilor native, respectiv API-urile native sunt accesibile prin interfețe abstractizate care uneori lipsesc anumite facilități importante a celor native.

Capitolul 2. Tehnologii folosite

2.1 C# si .NET

Aplicația KT MyAdmin este implementată în cod C#. Limbajul C#, prezentat de Microsoft in anul 2000, este un limbaj de programare relativ nou în comparație cu limbajele Objective-C și Java. Este un limbaj de programare strongly typed(*), imperativ, orientat pe obiecte, influențat de limbajele C++ și Java, dar cu o sintaxă mult mai clară decât C++.

Limbajul C# stă într-o legătură strânsă cu mediul său de rulare, cu arhitectura .NET. Pe de o parte, C# a fost dezvoltat pentru crearea codului pentru arhitectura .NET, iar pe de altă parte bibliotecile utilizate de C# sunt cele ale arhitecturii .NET. Arhitectura .NET definește un mediu de programare care permite dezvoltarea și execuția aplicațiilor indiferent de platformă. Aceasta permite programarea în limbaj mixt și oferă facilități de securitate și portabilitate a programelor [12]. La nivelul cel mai scăzut .NET oferă infrastructura pentru tipurile de baza a lui C#. Pe lângă acestea, librăria .NET oferă suport pentru diversele cerințe întâlnite în programare, cum ar fi Math, Reflection, Collections, Globalization, Networking și multe altele.

Facilitățile menționate fac din limbajul C# si librăria .NET o soluție tentativă pentru dezvoltarea aplicațiilor cross platform. La scurt timp după ce Microsoft a anunțat .NET în anul 2000, compania Ximian a lansat un proiect open-source, numit Mono pentru a crea o implementare alternativă pentru compilatorul C# si frameworkul .NET.

În 2011, fondatorii Ximianului, au fondat pe Xamarin care foloseste pe Mono ca baza soluțiilor cross-platform[13].

2.2 XAML

XAML –Extensible Markup Language – este un limbaj de programare declarativ, dezvoltat de Microsoft ca un limbaj general pentru instanțierea și inițializarea obiectelor. XAML nu este conceput doar pentru crearea interfețelor utilizator.XAML este limbajul markup folosit atât în proiectele universal app cât și în proiectele Xamarin.Forms.

Figura 2. 1 pagină simplă realizată în XAML

2.3 Xamarin

Platforma Xamarin se constituie din versiunile native ale librăriilor Mac, iOS și Android. Cele trei setui de librării .NET sunt:

– Xamarin.Mac, care a evoluat din proiectul MonoMac

– Xamarin.iOS, care a evoluat din MonoTouch

– Xamarin.Android, care a evoluat din Mono pentru Android

Utilizând aceste librării, programatorii scriu aplicațiile in cod C# și au acces la API-urile native a celor trei platforme [13]. Avantajul dezvoltării aplicațiilor cross platform cu un singur limbaj de programare este abilitatea de a partaja cod între mai multe aplicații. Pentru ca codul să poate fi partajat, aplicația trebuie să aibă o structură adecvată. Metoda cea mai bună pentru structurarea aplicației este folosirea arhitecturii MVVM, care ajută la separarea codului într-un Model, View și ViewModel. Viewurile sunt clase platform specifice, de aceea ele sunt puse în proiecte separate, specifice fiecărui platform. Modelul și ViewModelul sunt de obicei clase independente de platformă, de aceea ele pot fi puse într-un proiect separat. Proiectul comun poate fi de tip Shared Asset Project sau de tip Portable Class Library.

În amândouă cazuri, codul comun are acces la biblioteca .NET, deci poate efectua procese I/O pe fișiere, să trateze globalizarea, să facă requesturi către internet, să descompune fișiere XML, etc.

Folosind de tehnicile menționate pentru partajarea codului, putem crea o singură soluție C# care să conține patru proiecte care țintesc cele trei platforme mobile majore, cu acces la un proiect comun de tip SAP sau PCL.

Următoarea figură [2. ] ilustrează relațiile între proiectele C#, librariile Xamarin, si API-urile native:

Figura 2.2 [13]

Căsuțele din rândul doi reprezintă aplicațiile platform specifice. Aceste aplicații fac apel la proiectul comun și la librăriile Xamarin care implementează API-urile native. Diagrama nu este completă, deoarece nu sunt afișate apelurile între proiectele comune. Proiectele comune pot fi de tip PCL – Portable Class Libray sau de tip Shared Asset Project – SAP [14]. Proiectul PCL are acces la versiunea proprie de .NET, în timp ce proiectul SAP folosește versiunea de .NET încorporată în fiecare platforma.

Figura [2. 2] arată librăriile Xamarin.iOS si Xamarin.Android ca niște elemente complexe, însă ele reprezintă doar legăturile între limbajele diferite și nu adaugă nimic în plus la apelurile de API.

În cazul aplicației iPhone, când se face build la proiect, compilatorul Xamarin generează un limbaj intermediar – IL, intermediate language. Pentru generarea codului nativ iPhone, Xamarin trebuie să apeleze compilatorul Apple, care este disponibil doar pe sistemele Mac. În final, apelurile de aplicatie la API-urile Apple sunt exact la fel ca și în cazul unei aplicații scrise in Objective-C.

Pentru proiectul Android compilatorul Xamarin generează limbajul intermediar – IL – care rulează pe o versiune de Mono pe dispozitiv alături de motorul Java. Apelurile de API sunt la fel ca și într-o aplicație dezvoltată în Java.

2.4 Xamarin Forms

Xamarin.Forms a fost anunțată in 28 Mai, 2014 alături de alte îmbunătățiri care sunt incluse în a treia versiune de Xamarin. Xamarin.Forms permite utilizatorului să scrie cod pentru interfața utilizator care poate fi compilat atât pentru iPhone, cât și pentru Android si Windows Phone [13].

Figura 2. 3

În mod normal, soluția Xamarin.Forms se constituie din trei proiecte separate pentru cele trei platforme mobile, și dintr-un proiect care contine codul comun, similar cu diagrama anterioară (Figura 2. 3). În acest caz, cele trei proiecte platform-specifice conțin doar cod tip boilerplate. Proiectul SAP sau proiectul PCL conține nucleul aplicaîiei împreună cu codul pentru interfața utilizator. Librăriile Xamarin.Forms.Core si Xamarin.Forms.Xaml implementează API-ul Xamarin.Forms. În functie de platformă, Xamarin.Forms.Core va folosi una dintre librăriile Xamarin.Forms.Platform. Aceste librării sunt în mod predominant colecții de clase, numite renderers, care transformă obiectele de interfață Xamarin.Forms în elemente UI platform-specifice.

2.5 Universal Apps

Universal App este definiția aplicațiilor dezvoltate pentru Windows Store, care sunt capabile să ruleze atât pe sistemul de operare Windows 8.1 cât și pe platforma mobilă Windows Phone 8.1. Versiunea 2013 al instrumentului de dezvoltare Visual Studio conține șablonul Universal Windows App care permite crearea unei aplicații pentru Windows Store și Windows Phone Store App în aceeași soluție [15].

Pentru dezvoltarea unei aplicații Universal App putem alege dintre mai multe limbaje de programare: JavaScript, C#, Visual Basic, sau C++. Există și posibilitatea de a folosi componente scrise într-un alt limbaj decât cel folosit la dezvoltarea aplicației. Aplicațiile Universal App pot folosi de Windows Runtime, care este un API nativ inclus în sistemul de operare. Acesta este implementat în C++ și suportă limbajele JavaScript, C#, Visual Basic și C++.

2.6 MVVM

Arhitectura MVVM permite separea aplicațiilor în trei nivele:



Model: furnizează datele care stau la baza aplicației

ViewModel: leagă modelul și interfața utilizator.

View: reprezintă interfața utilizator, respectiv nivelul de prezentare, implementată de regulă în XAML

Modelul nu știe nimic despre ViewModel, respectiv nu știe nimic despre proprietățile publice și metodele din ViewModel. În mod asemănător, ViewModelul ignoră interfața utilizator. Dacă presupunem că toată comunicația între cele trei nivele se întâmplă prin apelarea metodelor și accesarea proprietăților, putem constata că toate apelurile de metode și accesarea proprietăților se întâmplă într-o singură direcție (Figura 2.4) :

Figura 2. 4 [13]

Datele fiind dinamice, figura prezentată mai înainte nu poate să fie valabilă în aplicațiile reale. Modelul poate să obține date noi, care trebuie transmise către ViewModel și pe urmă la interfața utilizator. Din acest motiv, interfața utilizator ar putea urmări evenimentele declanșate de la ViewModel, iar ViewModelul ar putea urmări evenimentele declanșate de Modelul. În aces t sens am putea avea o comunicare în ambele direcții [Figura 2. ] :

Figura 2. 6 [13]

Arhitectura MVVM a fost concepută să profite din avantajul lui XAML de a face data-binding între elementele UI și proprietăți din ViewModel:

Figura 2. 7 [13]

Atât în cazul aplicației universal App, cât și în cazul aplicației Xamarin.Forms interfețele sunt dezvoltate în XAML. Ele fac binding la proprietățile din ViewModelele definite în proiectul KTMobile portabil. În acest sens se profită de arhitectura MVVM, realizând separarea codului UI și al claselor modele și viewmodele.

2.7 Portable Class Library vs. Shared Asset Project

Scopul adevărat la dezvoltarea aplicațiilor cross-platform cu un singur limbaj de programare este partajarea codului între aplicațiile. Codul independent de platformă trebuie să fie capabilă să acceseze fișierele, rețeaua, diferite colecții de date și să ofere un mecanism pentru tratarea firurilor de execuție. În mod tradițional aceste sarcini sunt platform-specifice, însă ele pot fi rezolvate cu ajutorul frameworkului .NET, disponibil pentru toate cele trei platforme majore [14].

Codul independent poate să fie izolat, sau pus într-un proiect separat cu ajutorul instrumentelor de dezvoltare integrate Visual Studio sau Xamarin Studio. Proiectul care conține codul partajat poate să fie un Shared Asset Project – SAP – sau un Portable Class Library –PCL.

Librăriile Portable Class Library sunt versiuni mai specializate a librăriilor Class Library, și sunt concepute pentru a partaja cod între mai multe platforme țintind vesiuni diferite a frameworkului .NET [14]. Termenul Portabil înseamnă că codul conținut în librăria portabilă va deveni o librărie dinamic linkuită – dinamic link library(DLL) – care va putea fi referențiată din orice proiect .NET. [11]

Librăriile portabile pot fi create atât în Xamarin Studio cât și în Visual Studio(Figura 2. ):

Figura 2. 9 Crearea unei librării portabile în Visual Studio

După apăsarea butonului OK, utilizatorul va avea posibilitatea de a alege platformele compatibile cu librăria portabilă (Figura 3):

Figura 2. 10 Casetă de dialog pentru alegerea platformelor ținte

La prima vedere se pare o idee bună alegerea tuturor versiuni de .NET Framework, dar trebuie ținut în minte faptul că suportul către mai multe versiuni de frameworkuri .NET oferă funcționalități mai puține [13]. De exemplu, clasa HttpClient, care facilitează realizarea apelurilor web într-un mod asincron, nu este acceptată de toate versiunile de Windows Silverlight. Dacă bifăm și opțiunea pentru platforma Silverlight, clasa HttpClient nu va mai fi accesabil din proiectul PCL.

Avantajele folosirii librariilor portabile:

Pot accesa alte librarii portabile care țintesc platforme similare

Permite crearea paginilor XAML

Unit testing ușor de scris

Generează un dll care poate fi folosit și în alte proiecte

Dezavantajele pentru PCL:

Nu poate conține cod platform specific

Nu poate conține referințe către librării cu cod platform non-specific

Are acces doar la o parte a frameworkului .NET

Aplicația KT MyAdmin profită de avantajele librăriilor portabile, având două proiecte de tip PCL. Primul proiect PCL este folosit pentru aplicația Xamarin, și conține paginile XAML și logica comună pentru aplicațiile iOS și Android. Cealaltă librărie portabilă este folosită pentru codul comun proiectelor Xamarin și Windows Phone.

Pe lângă librăriile portabile, aplicația KT MyAdmin profită și din conceptul librăriilor tip shared, și anume în proiectul Windows, care conține logica și paginile Xaml destinate aplicațiilor Windows Phone și Windows.

Șablonul Shared Project a fost inrodus cu Visual Studio 2013 Update 2, iar Xamarin a adăugat suport pentru aceste proiecte în Xamarin Studio 5. Acest tip de proiect a fost creat de Microsoft pentru a sprijini conceptul aplicațiilor universale, care permit crearea unui singur cod care pe urmă să ruleze atât pe Windows 8.1 cât și pe Windows Phone 8.1. Șablonul Shared Project permite utilizatorilor să scrie cod care pe urmă va fi referențiat de proiecte diferite de .NET. Codul va fi compilat înpreună cu proiectele care fac referință către acesta și poate să include directive de compilator [13].

Crearea unui Shared Asset Project în Visual Studio se întâmplă conform Figura 2. :

Figura 2. 12 Crearea unui de tip SAP

Un astfel de proiect nu conține foldere pentru resurse sau componente. Nu are nici clasele Properties și nici alte fișiere (Figra 2. 13):

Figura 2. 13

Un proiect partajat nu se compilează singur, ci se compilează ca o parte a proiectului care face referință la el. Proiectele partajate permit compilarea condiționată al codului prin directive de compilare (Figura 2. 14):

Figura 2. 14 Compilare condiționată în proiectul shared de la aplicația Windows

Orice cod care are asociat în față un semn de # este considerat directiv de preprocesare. Aceste directive sunt folosite de compilator pentru a determina liniile care trebuie incluse în procesul de compilare. Ca și în codul de mai sus, directivele de preprocesare sunt însoțite de simboluri, cum ar fi WINDOWS_PHONE_APP. Simbolurile de precompilare folosite în Xamarin.Forms sunt următoarele:

__MOBILE__: definit în proiectele Xamarin.iOS și Xamarin.Android

__IOS__: definit în proiectul Xamarin.iOS

__ANDROID__: definit în proiectul Xamarin.Android.

WINDOWS_PHONE_APP : definit în proiectul universal

Avantajele proiectului shared:

Au acces la toate funcționalitățile în proiectele care fac referință la ele

Poate conține cod specific platformei

Permite compilare condițională

Dezvantajele proiectului shared:

Nu se crează fișier DLL, alte aplicații nu poate să le folosească

Nu permite crearea paginilor XAML

Realizarea Unit-Testingului e mult mai complicat

2.8 Xamarin Studio

Xamarin Studio este un instrument integrat de dezvoltare, creat de către compania Xamarin. Instrumentul permite dezvoltarea aplicațiilor mobile cross-platform pentru sistemele de operare Android și iOS. În cazul în care aplicația are ca țintă amândouă platforme, instrumentul de dezvoltare trebuie să fie instalată pe o stație Mac. Pentru dezvoltarea aplicațiilor Android nu este necesară instalarea lui Xamarin Studio pe o stație Mac, instrumentul având și o versiune Windows, dar care nu permite dezvoltarea aplicațiilor iOS.

2.9 Visual Studio

Visual Studio este un instrument integrat de dezvoltare lansat de către Microsoft. Este folosit pentru dezvoltarea aplicațiilor Windows, pagini web, aplicații web și servicii web.

Începând cu Update-ul 2 RC pentru Visual Studio 2013, dezvoltatorii au posibilitatea de a crea aplicații cross platform, în sensul că aplicația rulează atât pe dispozitivile Windows Phone cât și pe dispozitivele cu sistemul de operare Windows 8.1 .

Capitolul 3: Implementarea aplicației

3.1 Structura aplicației

Aplicația KT MyAdmin se constituie din două aplicații: dintr-o aplicație Universal App pentru dispozitivele Windows Phone 8.1 și Windows 8.1, respectiv dintr-o aplicație Xamarin.Forms. Aplicația Universal rulează momentan doar pe dispozitivele cu sistem de operare Windows Phone 8.1, iar aplicația Xamarin.Forms pe dispozitivele Android.

3.1.1 Structura soluției Universal App

Aplicația Universal App este implementată în Visual Studio 2013, și constă din soluția KT_ACMobileWindows, care are patru proiecte(Figura 3. 1):

Figura 3. 1

Proiectul KT_ACMobileWindows.Windows conține paginile XAML specifice ppentru dispozitivele desktop, respectiv tablete care rulează sistemul de operare Windows 8.1. În proiectul KT_ACMobileWindows sunt incluse paginile destinate telefoanelor Windows Phone. Existența celor două proiecte este motivată cu modurile diferite în care sunt concepute interfețele utilizator. De exemplu, o aplicație destinată tabletelor are la dispoziție mai mult spațiu pentru afișarea informațiilor, în comparație cu un telefon mobil, care are un ecran mai mic. Cele două proiecte au logică comună pentru paginile XAML, care se află în proiectul KT_ACMobileWindows.Shared.

Proiectul KT_ACMobileWindows.Shared este un proiect de tip Shared Asset Project: în acesta este implementată logica aplicației, și anume clasele cod-behind pentru paginile XAML, clasele acestea fiind comune în amândouă proiecte. Folosirea claselor cod behind comune este posibilă din motivul că amândouă proiecte folosesc de librăria Windows Runtime, majoritatea api-urilor apelate fiind același în amândouă proiecte. În cazul în care implementarea unei clasă necesită abordări diferite pentru cele două platforme, proiectul shared asset project oferă folosirea directivelor de precompilare:

Figura 3.

Figura 3. 2 arată un exemplu pentru utilizarea directivelor de precompilare: se verifică dacă proiectul curent este de tip Windows Phone. În cazul în care proiectul este de tip Windows Phone, se înregistrează evenimentele de suspendare respectiv și de resuming, altfel se execută logica din ramura else, care reprezintă cazul în care proiectul curent este de tip Windows. După cum se vede și în figura …, codul curent se diferențiază prin culoare. Alegerea proiectului curent, respectiv care va fi rulat se face conform figurii 3. 3:

Figura 3.

Directivele de precompilare nu sunt disponibile în proiectele de tip Portable Class Library.

3.1.2 Structura soluției Xamarin.Forms

Structura aplicației Xamarin.Forms este prezentată în figura 3. 4:

Figura 3.

Aplicația Xamarin.Forms se constituie din soluția KT_ACMobileXamarin, care include cinci proiecte, din care trei sunt platform specifice. Proiectele iOS și Windows Phone țintesc dispozitivele iOS, respectiv Windows Phone, și conțin cod platform specific pentru acestea, însă aceste două proiecte nu sunt terminate până momentul acesta. Aceste două tipuri de proiecte nu sunt accesibile din Xamarin Studio. Proiectele care vizează platforma iOS au nevoie de un sistem Mac, cu Xamarin Studio instalat, la care instanța Xamarin Studio instalată pe windows se poate conecta prin rețeaua locală. Proiectele care vizează Windows Phone se pot dezvolta doar cu folosirea lui Visual Studio, cu extensia Xamarin instalată.

Proiectul KT_ACMobileXamarin.Droid conține codul platform specific pentru dispozitive Android, respectiv logica care permite folosirea elementelor Xamarin.Forms. Această logică este inclusă în clasa MainActivity, și conține metoda OnCreate, apelată la crearea aplicației:

Figura 3.

După cum se observă și în figura 3. 5, această metodă se ocupă de inițializarea handlerurilor de excepții, respectiv de inițializarea elementelor Xamarin.Forms.

Proiectul KT_ACMobileXamarin este de tip portable class library, și este similar cu proiectul shared de la soluția KT_ACMobileWindows, în sensul că proiectul acesta conține codul comun pentru cele trei platforme. Diferența stă în faptul, că acest proiect conține și paginile XAML, scrise cu ajutorul lui Xamarin.Forms care face posibil ca interfața utilizator să fie creată într-un singur loc, fiind capabilă să ruleze pe toate cele trei platforme.

3.1.3 Structura proiectului KT_CommonMobile

Având în vedere existența a două soluții diferite, am dorit să profit de facilitățile lui .NET, și am implementat un proiect, care conține codul comun pentru soluțiile KT_ACMobileWindows și KT_ACMobileXamarin. Tipul proiectului este Portable Class lIbrary, și este denumit KT_CommonMobile:

Figura 3.

Figura 3. 6 prezintă structura proiectului KT_CommonMobile. Astfel, am implementat clasele viewmodel în proiectul comun, implementarea lor fiind platform independent. Similar cu clasele viewmodel, și comenzile UI sunt implementate în proiectul PCL, însă pentru a permite navigarea între pagini prin comenzi, am fost obligat să creez interfețe. Crearea interfețelor este obligatoriu din momentul ce anumite facilități, cum ar fi navigarea între pagini este implementată în moduri diferite în platformele Windows și Android. În aceste interfețe sunt definite metodele care vor fi implementate în clasele din proiectele platform specifice.

Proiectul conține clase scrise în .NET, folosind de librăriile standarde, de aceea poate să fie utilizată în amândouă aplicații: cel Universal App și cel Xamarin.Forms.

3.2 Funcționalități comune pentru fiecare pagină

Înainte să prezint funcționalitățile aplicației, respectiv paginile XAML cu codul C# în spate, intenția mea este de a prezenta părților comune, care sunt prezente în fiecare pagină, și care au rol important pentru funcționarea aplicației. Paginile XAML, menționate mai înainte, sunt similare cu paginile web, în sensul că ele au rolul de a furniza nivelul de prezentare a datelor, și pentru a furniza o interfață grafică prietenoasă pentru utilizator. Fiecare pagină XAML are în spate o clasă cod behind, care conțin logica pentru funcționarea paginilor.

Navigarea între aceste pagini XAML se întâmplă în mod diferit în cele două soluții al aplicației KT MyAdmin. Un proiect Windows Phone, în mod normal permite navigarea între pagini folosind de metoda Frame.Navigate, însă API-urile Win RT nu dispun de o soluție pentru tratarea în mod elegant al evenimentelor care se întâmplă când ajungem la o pagină, când plecăm de la o pagină, sau când folosim butonul Back al dispozitivului. Soluția pentru aceste probleme este impementată de Microsoft, și anume proiectele Universal furnizează clasele NavigationHelper, respectiv SuspensionHelper. Cu ajutorul acestor două clase putem trata atât evenimentele de suspendare, cât și evenimentele de resume, respectiv tratează evenimentul pentru apăsarea butonului back. Acest lucru este foarte important, deoarece fără aceste clase, la apăsarea butonului back de pe dispozitiv, aplicația se suspendează, iar cu ajutorul acestor clase la apăsarea butonului back aplicația nu se suspendă, ci navighează la pagina precedentă.

Figura 3.

Figura 3. 7 prezintă inițializarea clasei ScannerPage, dar codul care conține apare în constructorul fiecărei clasă. Astfel, InitializeComponent se ocupă de instanțiarea elementelor definite în pagina XAML, în timp ce instanța NavigationHelper va înregistra evenimente metode pentru evenimentele LoadState și SaveState. Aceste metode se apelază la intrare pe pagină, respectiv la plecarea de la pagina curentă, și ele se ocupă de salvarea contextului curent al paginii, respectiv cu refacerea contextului când utilizatorul revine la pagină.

Metoda configureNetworkStatusListener() este folosită cu intenția de a asculta, respectiv de a reacționa de schimbările de conexiuni internet. Fără o conexiune activă de internet, majoritatea funcțiilor aplicației nu mai pot funcționa, aplicația fiind nevoită să comunică cu Web API-ul aplicației. În figura … se prezintă conținutul metodei:

Figura 3. 8

Conform figurii 3.8 se înregistrează metoda callback pentru evenimentul NetworkStatusChanged, care va fi apelată la fiecare schimbare de conexiune rețea.

Figura 3. 9

Figura 3. 9 prezintă implementarea metodei callback, metoda OnNetworkStatusChanged. Pentru fiecare eveniment de schimbare al conexiunii, se interoghează starea curentă al conexiunii, și se tratează atât cazurile când s-a pierdut conexiunea inernet, cât și cazul în care a revenit conexiunea.

Metodele comune care mai vor fi apelate în fiecare pagină sunt OnNavigatedTo și OnNavigatedFrom. Metoda OnNavigatedTo este apelată când utilizatorul ajunge la pagină, iar OnNavigatedFrom când pleacă de aici. Pentru a ține evidență de anumite stări, respectiv pentru salvarea setărilor, se folosește de dicționarul ApplicationData.Current.LocalSettings, care se utilizează conform figurii 3. 10:

Figura 3.

Navigare între paginile aplicației se realizează folosind de metoda Navigate, care este definită pe clasa Frame. Clasa Frame reprezintă suprafața care este afișată utilizatorului aplicației, dispune de o zonă în care paginile sunt randate, respectiv permite navigarea între paginile de care dispune. Clasa Frame conține toate paginile la care utilizatorul a navigat, și permite ștergerea istoricului de navigare conform figurii 3. :

Figura 3.

În soluția KT_ACMobileXamarin navigarea între paginile se face în mod diferit. Butonul back este tratat de la început, și nu avem nevoie de măsuri ulterioare. Majoritatea paginilor au constructor, gol iar inițializare componentelor XAML se întâmplă în metodele OnAppearing:

Figura 3.

După cum se vede și din figura 3.13, se folosește de clasa statică MessagingCenter, care este inclusă în Xamarin.Forms. MessagingCenter include o mesagerie simplă care facilitează comunicarea între diferitele părți ale aplicației. De exemplu, în clasa App.cs avem cele două metode pentru suspendarea, și reinițializarea aplicației: (figura 3.14)

Figura 3.

În cazul în care se declanșează evenimentul OnSleep, și aplicația intră în stare suspendată, mesageria MessagingCenter trimite un mesaj, iar dacă avem o instanță care a abonat la acest mesaj, instanța o să fie notificată, și va apela metoda specificată pentru acest eveniment:

Figura 3.

Figura 3.15 arată metoda din clasa ScannerPage care se apelează când se trimite un mesaj de la MessagingCenter. Similar cu soluția Windows, Xamarin.Forms dă posibilitatea pentru salvarea stărilor, cu ajutorul dicționarului Properties:

Figura 3.

3.3 Funcționalitățile aplicației

Aplicația KT MyAdmin permite controlul accesului pentru evenimente online folosind dispozitivele mobile, indiferent de platforma dispozitivului, furnizând o interfață similară, respectiv funcționalități identice pentru toate platformele.

Aplicația poate fi folosită la evenimente pentru care vânzarea biletelor se întâmplă online. Folosind aplicația, operatorii telefonului pot controla accesul la evenimente prin scanarea codului qr de pe biletul clientului.

Apicația permite autentificare operatorului pentru un eveniment prin scanarea codului QR al evenimentului. Dacă codul respectă un anumit pattern, codul va fi trimis către web API , care decide dacă codul QR este valid. În cazul în care codul este valid, se trimit înapoi datele evenimentului, iar operatorul va ajunge pe pagina dashboard care reprezintă meniul aplicației. În acest meniu sunt afișate opțiunile aplicației, respectiv lista cu participanțile evenimentului. Opțiunile disponibile sunt: autentificarea utilizatorului prin scanarea biletului, autentificarea utilizatorului prin introducerea numelui utilizatorului, respectiv delogare din eveniment.

În anexa 2 se va găsi schema bloc a aplicației în care este prezentată logica și cum utilizatorul poate naviga în interiorul ei.

3.4 Pagina ScannerPage

Funcționalitatea de scanare cod QR va fi folosită în două cazuri în aplicația KT_MyAdmin: odată la început, la autentificarea operatorului prin codul QR al evenimentului, respectiv la validarea biletelor clienților. Atât în soluția KT_ACMobileWindows, cât și în soluția KT_ACMobileXamarin, pagina de scanare va fi implementată doar odată, și va fi folosită în amândouă cazuri menționate.

În cazul în care operatorul nu s-a autentificat pentru nici un eveniment, pagina ScannerPage va fi prima pagină care se afișează, altfel se afișează pagina Dashboard:

Figura 3.

Figura 3.

Figurile 3. 17 și 3. 18 arată logica pentru setarea paginii inițiale în proiectele Universal App, respectiv Xamarin.Forms. În ambele cazuri se veifică dacă dicționarul conține valoare pentru id-ul evenimentului, adică dacă operatorul deja s-a autentificat pentru un eveniment. Dacă da, pagina inițială va fi DashBoardPage, în caz contrar ScannerPage.

Pentru scanarea unui cod QR vom utiliza camera dispozitivelor mobile, iar pentru procesarea codurilor vom folosi o librărie specială, scrisă pentru acest scop. Pe lângă faptul, că dorim să scanăm codul QR, intenționăm să afișăm pe ecranul dispozitivului imaginea de la camera, respectiv vom adăuga la imaginile de previzualizare un efect special, care să ajute operatorul aplicației cu poziționarea camerei.

Aplicațiile care folosesc camera dispozitivului sunt obligați să aibă permisiunea de a profita din camera telefonului. Din acest motiv, este necesar să modificăm fișierele care specific permisiunile aplicațiiilor: în proiectul KT_ACMobileWindows.WindowsPhone fișierul Packag.appmanifest trebuie modificat, iar în proiectul proiectul KT_ACMobileXamarin.Droid fișierul AndroidManifest.xml trebuie schimbat. În amândouă fișiere vom adăuga permisiunea pentru ca aplicația să fie capabilă de a folosi camera dispozitivului.

Procesarea codului QR se întâmplă cu ajutorul librăriei gratuit ZXing [16]. Librăria a fost inițial dezvoltată în Java, dar ulterior s-a crea un port în .Net. Librăria permite decodarea și generarea codurilor de bare prin imagini, și este disponibil prin pachete Nuget atât pentru proiectul KT_ACMobileXamarin și KT_ACMobileWindows:

Figura 3.

Figura 3. 19 arată metoda apelată din proiectul KT_ACMobileXamarin pentru procesarea codului QR. Metoda ScanImage acceptă un șir de octeți, care reprezintă imaginea primită de la camera dispozitivului. Width și Height reprezintă lățimea, și înălțimea pozei trimisă către funcția decode al instanței de BarcodeReader. Rezultatul procesării este un string, care este de fapt codul QR.

Metoda ScanImage trebuie apelată pentru fiecare cadru de previzualizare primită de la camera dispozitivului mobil. Pentru a realiza acest lucru, trebuie să avem acces la cadrele de previzualizare a camerei, și să transmitem fiecare cadru pentru procesare. Utilizarea camerei, furnizarea imaginilor de previzualizare pentru o suprafață de previzualizare,și obținerea accesului la cadrurile de previzualizare se întâmplă în mod diferit în soluțiile KT_ACMobileWindows și KT_ACMobileXamarin. Motivul pentru acest fapt este diferența dintre platformele Windows și Android.

3.4.1 Folosirea camerei în soluția Universal App

Pagina pentru scanarea codurilor QR se numește ScannerPage.xaml, și este definită în proiectul KT_ACMobileWindows.Windows, iar clasa cod behind este implementată în proiectul shared asset project.

Afișarea previzualizării camerei se întâmplă în felul următor: în pagina xaml pentru previzualizarea imaginii de la camera trebuie să avem un element numit VideoCapture (Figura 3.20):

Figura 3.

VideoCapture este o instanță a clasei CaptureElement, și este utilizată pentru randararea unui stream de la camera dispozitivului. Elementul reprezintă o suprafață pentru afișarea cadrelor de previzualizare, și are o proprietate numită RenderTransform, folosită ulterior din fișierul cod behind pentru rotirea imaginii de previzualizare.

Pentru a vedea imaginilor de previzualizare, elementul VideoCapture trebuie să primească imaginile acestea de la camera telefonului. Astfel, în fișierul cod behind inițializăm camera folosind un element denumit capture, care este o instanță a clasei MediaCapture:

Figura 3.

Elementul capture se va conecta la camera telefonului, și va furniza imaginile de previzualizare. Următoarea figură prezintă modul în care elementul capture este inițializată:

Figura 3.

Colecția cameras reprezintă camerele disponibile pentru dispozitivul curent, telefoanele moderne având o cameră principală respectiv o cameră secundară pentru apelurile video. Obiectul settings este folosit pentru inițializarea setărilor de cameră, astfel, specificăm că folosim camera principală, iar streamul primit de la aceasta este de tipul video. În final, apelăm metoda de initializare al elemenului capture.

Având o cameră inițializată, putem să asociem camera cu suprafața de previzualizare:

Figura 3.

În momentul acesta am putea să apelăm metoda StartPreviewAsync() pe instanța de capture, iar streamul camerei ar apărea pe ecran. În acest fel, am avea o aplicație care știe să afișeze streamul camerei, dar cadrele de previzualizare n-ar fi prelucrate.

Pentru a procesa toate cadrele de previzualizare, trebuie să folosim de o clasă denumită LumiaAnalyzerDefinition, care provine din librăria VideoEffects. Această clasă permite analiza imaginilor difuzate în timp real, trimitând fiecare cadru video pentru aplicație, fără întârzieri de cadre în fluxul de previzualizare. În cazul în care timpul de procesare a imaginii este prea lung, instanța de LumiaAnalyzerDefinition va trimite mai puține cadre, iar previzualizarea fluxului de cameră se va întâmpla fără întârzieri [17]. Utilizarea clasei LumiaAnalyzerDefintion este prezentată în figura … :

Figura 3.

ScanBitmapAsync reprezintă metoda care va fi apelată pentru fiecare cadru de previzualizare, iar implementarea ei este prezentată în următoarea figură:

Figura 3.

Metoda ScanBitmapAsync primește ca parametru o imagine ca un bitmap. Imaginea este procesată de către scanner-ul QR, care returnează un string în urma procesării imaginii. Acest string va fi asociat unei dependency property, denumit QRScanResult (figura 3. 26) :

Figura 3.

În setterul proprietății se verifică dacă valoarea este diferită față de cea actuală. Dacă da, se declanșează evenimentul PropertyChanged pentru proprietatea QRScanResult, și se veifică dacă valoarea encodată în codul QR respectă patternul acceptat pentru codurile QR al aplicației.

Dacă codul respectă șablonul impus, aplicația navighează la pagina următoare (Figura 3. 27):

Figura 3.

Pagina ScannerPage din soluția KT_ACMobileWindows arată conform figurii 3. 28:

Figura 3.

3.4.2 Folosirea camerei în soluția Xamarin.Forms

Xamarin.Forms este o tehnologie relativ nouă, care faciliteză dezvoltarea aplicațiilor native cross platform prin implementerea unei serii de controale de interfață [19]. Fiecare control are un aspect implicit, și toate controalele dispun de proprietăți prin care se poate personaliza aspectul lui[18]. În cazul în care dezvoltatorul are nevoie de un element UI, care nu este încă disponibilă, sau are nevoie de un element UI existent, cu funcționalități extinse, Xamarin.Forms oferă posibilitatea de a crea controlul dorit [16].

În Proiectul KT_ACMobileXamarin problema este, că Xamarin.Forms nu dispune de un element UI care să permite randarea fluxului camerei. Din acest motiv, suntem obligați de a crea controlul UI dorit:

Figura 3.

În figura 3.29 este prezentată o parte din contrulul CameraView, pe care am creat în proiectul KT_ACMobileXamarin pentru afișarea fluxului video de la camera dispozitivului. Clasa derivă din clasa Xamarin.Forms.View [13], și conține bindable properties. O astfel de proprietate permite implementarea bidirecțională a data-bindingului, fiecare proprietate având o proprietate de tipul BindableProperty, care este capabilă să comunice fiecare schimbare prin implementarea notificării property changed.

Clasa CameraView are următoarele proprietăți:

Camera: reprezintă id-ul camerei folosite

ScanResult: conține valoarea obținută prin urma scanării codului QR.

Un control creat în Xamarin.Forms nu funcționează de la sine însuși. Controlul creat are nevoie de clase renderer, specifice pentru fiecare platformă țintă, care are rolul de a afișa controlul și să asculte după evenimente de modificare de proprietăți. Un renderer este o clasă specială, care transformă obiectele de interfață Xamarin.Forms în obiecte platform specifice.

Pentru controlul CameraView am implementat un renderer platform specific în proiectul KTAcMobileXamarin.Droid:

Figura 3.

Figura 3.30 arată o parte din clasa CameraViewRenderer. Clasa derivă din ViewRenderer, fapt ce înseamnă că calcularea mărimilor, respectiv proprietățile normale ale unui view standard Android sunt disponibile[18]. Crearea controlului, respectiv afișarea lui se face în metoda OnElementChanged, unde avem acces la două proprietăți importante:

Element – el fiind controlul CameraView creat în proiectul KT_ACMobileXamarin

Control – în acest element va fi setat camera cu ajutorul librăriei Xamarin.Droid, apelând metoda SetNativeControl(figura 3.31)

Figura 3.

Figura 3.31 prezintă setarea elementului de control cu o nouă instanță a clasei CameraPreview. Definiția clasei este ilustrată în figura [3.32] :

Figura 3.

Clasa CameraPreview conține implementarea pentru folosirea fluxului video de la camera dispozitivului. Codul scris din acest motiv este foarte asemănător cu codul scris din același motiv într-o aplicație nativă Android, deoarece în aplicația KT_AcMobileXamarin.Droid avem acces la toate API-urile native prin librăria Xamarin.Droid. Diferența majoră dintre o aplicație xamarin și o aplicație nativă este limbajul folosit pentru implementare.

Figura 3.

Figura 3.33 ilustrează suprafața folosită în aplicațiile Android pentru randararea fluxului video, clasele SurfaceView și SurfaceHolder având rolul asemănător cu clasa CaptureElement din Windows RT. Odată având o cameră inițializată, și o suprafață pregătită, putem să setăm metoda callback pentru analiza fiecărui cadru de previzualizare, respectiv să pornim previzualizarea(figura 3.34) :

Figura 3.

Metoda callback este reprezentată în următoarea figură:

Figura 3.

După obținerea codului QR, metoda setează pe proprietatea ScanResult cu valoare codului QR.

Legarea rendererului cu controlul din proiectul PCL se întâmplă cu atributul special care se pune în fața namespaceului din fișierul CameraViewRenderer. Cu setarea ExportRendererului Xamarin.Forms va știe că proiectul Android a implementat controlul CameraView(figura 3.36):

Figura 3.

Trebuie menținut, că în cazul în care avem o soluție cu proiecte care țintesc cele trei platfoarme, atunci suntem obligați să creăm un renderer personalizat pentru toate cele trei platfoarme, folosind API-urile specifice fiecărui platform.

Următorul cod XAML arată utilizarea controlului CameraView în pagina scannerpage.xaml:

Figura 3.

Astfel, prin implementarea unui renderer personalizat am reușit să afisăm fluxul de la camera. Pentru ca codul scanat să fie folosit de către pagina Xaml, avem o logică similară ca în proiectul windows. Se verifică dacă codul obținut respectă patternul pentru codurile de bare, și în caz afirmativ se navighează la pagina următoare. Pagina ScannerPage implementată în Xamarin.Forms este prezentată în figura 3.38 :

Figura 3.

TransitionPage

Această pagină se afișează în cazul în care codul QR a fost scanat cu succes, și este valid. Rolul acestei pagini este de a arăta un efect animat până ce se efectuază apelul la Web API.

Figura…

În ambele soluții apelurile către Web API se întâmplă cu clasa ApiHelper, care face parte din proiectul KT_CommonMobile. Un Web API reprezintă o interfață de programare pentru un server web, în care este definit un sistem de mesaje prin cereri și răspunsuri [21]. WebApi-ul de la ASP.NET permite crearea servicilor HTTP, fiind ideal pentru implementarea soluțiilor REST. Api-ul folosit de aplicația mea de tip ASP.NET[22].

Web API-ul folosit de mine respectă conceptul REST, adică lucrează cu patru tipuri de metode, și anume : GET, POST, PUT, DELETE. De aceea, clasa ApiHelper vor conține patru metode care vor trata fiecare din cazurile menționate, și vor fi apelațe din părți diferite ale aplicației. Din acest motiv, nu putem să folosim tipuri în implementarea metodelor, că astfel aș limita metodele, în sensul că n-ar putea fi apelate de oriunde, și oricine. Cele patru metode din clasa ApiHelper vor fi metode generice, astfel tipul obiectului returnat va fi transmis la apelarea metodei.

Figura 3.

Figura 3.39 prezintă metoda folosită pentru efectuarea apelurilor get. La începutul metodei se specifică tipul obiectului care va fi returnat, respectiv sunt definite parametrii care trebuie trimise: numele metodei apelat din Api, și parametrile acceptate de metoda de la web API. Toate apelurile către web API vor fi făcute cu ajutorul clasei HttpClient, care face parte din frameworkul .NET, și este accesabil în proiectele de tip Portable Class Library. URL-ul resursei din Web API va fi aflat cu ajutorul metodei RequestUri, care va concatena numele funcției de apelat cu adresa de bază a Web Api-ului. Adresa de bază este setată la crearea aplicației atât în soluția Windows cât și în soluția Xamarin.Forms. Răspunsurile returnate de la Web API sunt de formatul JSON, de aceea ele trebuie deserializate în tipul transmis la apelarea metodei.

Un exemplu pentru apel Web API este prezentat în următoarea figură:

Figura 3.

Figura prezintă o parte din metoda ScanQrCodeResultAsync, care este implementată în clasa EventContext, în proiectul KT_CommonMobile. Metoda apelată în web API este event/ByQrCode. Event reprezintă controllerul, iar ByQrCode metoda din acest conroller. Această metodă va apela baza de date, și va returna informațiile evenimentului. Diagrama bazei de date cu tabelele folosite de aceasta aplicație este prezentată în anexa 1.

DashboardPage

Pagina DashBoard este prezentată în figura 3.41 :

Figura 3.

Pagina DashBoard reprezintă meniul aplicației și este de tip panorama, adică are două view-uri una lângă alta. View-ul prezentat în figura … arată view-ul cu opțiunile aplicației, iar celălalt view va furniza lista participanților deja autentificate.

Paginile DashBoard vor utiliza tehnologia MVVM, elementele afișate fiind furnizate de un observable collection. Icoanele prezentate în figura 3.42 provin din lista prezentată în figura …:

Figura 3.

Fiecare element conținut de lista ObservableCollection va fi de tipul DashBoardItemData, și va avea proprietățile ClickCommand, ImagePath, Title. Această clasă este implementată în proiectul Portable Class Library, și de aceea va fi folosită atât în soluțiile Universa cât și în soluția Xamarin. În dezvoltarea acestei clase problema majoră a fost implementarea comenzilor UI în manieră cross platform, ele fiind responsabile de sarcinile de navigarea, respectiv de comunicare cu utilizator prin mesaje platform specifice. Sarcinile menționate sunt tratate diferit de Xamarin.Forms și de Universal App, de aceea am fost nevoit să creez interfețe care vor fi implementate în mod diferit în cele două soluții. Interfețele create sunt următoarele:

IAppSettingsHelper – conține metode pentru tratare dicționarelor de setări

IKTNavigationHelper – conține metode pentru navigare dintre pagini

IUIHelper – conține metode pentru a afișa mesaje pe interfața utilizator

Figura 3.

Figura 3.

În figurile 3.43 și 3.44 sunt prezentate implementările diferite pentru interfața IKNavigationHelper. Diferența majoră dintre cele doău clase este abordarea diferită pentru implementarea navigării dintre pagini. Astfel, clasa din figura 3.44, clasa din soluția Universal App necesită specificarea tipului paginii la care dorim să ajungem [20]. Metoda Navigate din figura 3.43 din clasa implementată în soluția Xamarin.Forms necesită o instanță a paginii următoare, de aceea trebuie să inițializăm un obiect, care se face folosind de Reflection din .Net.

Capitolul 4. Concluzii

În dezvoltarea acestei aplicații am ajuns la concluzia că factorul cel mai important în dezvoltarea aplicațiilor cross platform este de a avea cât mai mult cod comun între aplicații. La început, am crezut și eu în conceptul write-once, build on all platforms, dar pe parcurs am realizat că acest concept este imposibil de realizat. În schimb, dacă avem două aplicații, una destinată dispozitivelor Windows Phone, cealalta dispoztivelor Android, aplicația respectivă trebuie dezvoltată de două ori, iar la final vom avea două proiecte, cu implementări total diferite. Prima variantă nu numai că a luat mult timp să fie dezvoltată, dar presupunea probleme în viitor în ceea ce privește mentenanța proiectelor. În cazul aplicației KT_MyAdmin, folosind un singur limbaj de programare, și profitând de tehnologiile cross platform care permit scrierea librăriilor comune, am reușit ca majoritatea implementării să fie inclusă într-un singur proiect, reducând mult timpul de dezvoltare al aplicațiilor și facilitând mult mentenanța ulterioară a acestora.

O posibilă dezvoltare viitoare este implementarea bazei de date SQLite, astfel încât participanții unui eveniment să fie salvați în aceasta, și astfel ar putea fi posibilă utilizarea aplicației fără conexiune Internet. O altă îmbunătățire ar fi implementarea unei pagini care să informeze operatorul despre numărul participanților care au intrat, respectiv numărul total al participanților.

O altă îmbunătățire posibilă pentru aplicația KT_MyAdmin este implementarea aplicației și pentru platforma iOS, astfel ar deveni posibilă acoperirea tuturor platformelor majore cu o singura aplicație.

Bibliografie

[1]. http://www.competentedigitale.ro/it/it6.html – Consultat la 04.07.2015

[2]. http://www.techopedia.com/definition/3391/mobile-operating-system-mobile-os – Consultat la 01.07.2015

[3] http://topmobiletrends.com/better-cross-platform-mobile-app/]

[4]. http://www.techopedia.com/definition/4219/android-platform – Consultat la 05.05.2015

[5]. https://en.wikipedia.org/wiki/IOS – Consultat la 10.06.2015

[6]. http://www.techopedia.com/definition/25206/ios – Consultat la 10.06.2015

[7]. http:www.wikipedia.org/wiki/Windows_Phone – Consultat la 8.06.2015

[8]. Matteo Pagani – Windows Phone 8 Development Succintly [6]

[9]. http://searchsoftwarequality.techtarget.com/definition/native-application-native-app – Consultat la 15.06.2015

[10]. https://en.wikipedia.org/?title=Cross-platform#Cross-platform_software -Consultat la 17.06.2015

[11]. https://en.wikipedia.org/wiki/PhoneGap – Consultat la 11.06.2015

[12]. http://www.math.uaic.ro/~cgales/csharp/Curs1.pdf – Consultat la 13.06.2015

[13]. Charles Petzold – Creating Mobile Apps With Xamarin.Forms, Microsoft Press

[14]. http://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/sharing_code_options/ – Consultat la 13.06.2015

[15]. https://msdn.microsoft.com/en-us/library/windows/apps/dn726767.aspx – Consultat la 12.06.2015

[16]. https://zxingnet.codeplex.com – Consultat la 11.06.2015

[17]. http://mmaitre314.github.io/VideoEffect/ – Consultat la 21.06.2015

[18]. blog.xamarin.com/using-custom-controls-in-xamarin.forms-on-android/ – Consultat la 23.06.2015

[19]. http://www.wintellect.com/devcenter/jprosise/supercharging-xamarin-forms-with-custom-renderers-part-1 – Consultat la 22.06.2015

[20]. https://msdn.microsoft.com/en-us/library/windows/apps/ff402536(v=vs.105).aspx – Consultat la 24.06.2015

[21]. https://en.wikipedia.org/wiki/Web_API – Consultat la 17.06.2015

[22]. https://msdn.microsoft.com/en-us/library/hh833994(v=vs.108).aspx – Consultat la 16.06.2015