Mobile Programming - Arhitectura Aplicatiilor Mobile

36
Arhitectura aplicațiilor mobile Cuprins Piața aplicațiilor mobile.......................................4 Direcții ale arhitecturii.......................................4 Utilizabilitate............................................... 4 Portabilitate................................................. 5 Instalare..................................................... 5 Scalabilitate................................................. 5 Alegerea tehnologiei............................................5 Dezvoltarea nativă: cea mai bună interfață dar cu un cost ridicat.............................................................7 Framework-uri cross-platform: costuri mai reduse cu prețul unei interfețe mai sărace................................................7 Aplicații web pentru mobile: compatibilitate extinsă dar cu performanță și ergonomie reduse.....................................8 Cum facem alegerea ?..........................................8 Cine va folosi aplicația ?...................................9 Ce așteaptă utilizatorii de la interfața grafică ?...........9 Ce funcționalități sunt necesare ?...........................9 Cât de importantă este compatibilitatea cu platforme multiple ?........................................................9 Aplicația trebuie să ruleze offline sau cu o conexiune slabă ? ..................................................................9 Există exigențe specifice domeniului aplicației ?............9 Cât de repede trebuie să lansăm aplicația ?..................9 Cât de repede trebuie implementată compatibilitatea cu noile versiuni ?.......................................................10 Arhitectura aplicațiilor client-server pentru mobile...........10 Aplicația client............................................. 10 1

description

-

Transcript of Mobile Programming - Arhitectura Aplicatiilor Mobile

Arhitectura aplicaiilor mobileCuprinsPiaa aplicaiilor mobile4Direcii ale arhitecturii4Utilizabilitate4Portabilitate5Instalare5Scalabilitate5Alegerea tehnologiei5Dezvoltarea nativ: cea mai bun interfa dar cu un cost ridicat7Framework-uri cross-platform: costuri mai reduse cu preul unei interfee mai srace7Aplicaii web pentru mobile: compatibilitate extins dar cu performan i ergonomie reduse8Cum facem alegerea ?8Cine va folosi aplicaia ?9Ce ateapt utilizatorii de la interfaa grafic ?9Ce funcionaliti sunt necesare ?9Ct de important este compatibilitatea cu platforme multiple ?9Aplicaia trebuie s ruleze offline sau cu o conexiune slab ?9Exist exigene specifice domeniului aplicaiei ?9Ct de repede trebuie s lansm aplicaia ?9Ct de repede trebuie implementat compatibilitatea cu noile versiuni ?10Arhitectura aplicaiilor client-server pentru mobile10Aplicaia client10Client thin10Client fat10Aplicaia server11Arhitectura cu un nivel11Arhitectura cu dou niveluri11Arhitectura cu trei niveluri12Sincronizarea informaiei12Arhitectura SOA13Introducere13Definiie i componente13Avantaje i Dezavantaje13Tipuri de arhitecturi SOA Mobile14Servicii Google Cloud14Limbaje pentru serviciile web15XML eXtensible Markup Language15XSLT- eXtensible Stylesheet Language Transformations16XQuery16JSON- JavaScript Object Notation16Transmiterea datelor non-textuale16Arhitecturi i limbaje utilizate16Arhitecturi de dezvoltare16Limbaje de programare17Securitate17abloane de securitate18Securitatea datelor19Managementul excepiilor20Validri20Comunicarea n reea20Performana aplicaiilor mobile21Chrome Developer Tools21Fiddler21Tehnici de performan22ntotdeauna numrul de cereri http trebuie redus pe ct posibil22ntotdeauna utilizai Gzip pentru compresie22ntotdeauna trebuie s se combine i s se minimizeze codul CSS i JavaScript22ntotdeauna trebuie s se pstreze un cache partea de client, dac este posibil22ntotdeauna optimizeaz atunci cnd sunt incluse n pagin scripturi i CSS23ntotdeauna optimizai imaginile23Poate fi avut n vedere folosirea sprite-urilor CSS24Poate fi avut n vedere utilizarea unei reele cu livrare de coninut24Arhitectura la nivel de GUI (design)24UI declarativ24UI programatic24Ce metod se recomand pentru a se utiliza?25View-uri i layout-uri25LinearLayout25TableLayout26FrameLayout26RelativeLayout27

Piaa aplicaiilor mobileDispozitivele mobile (telefoane, tablete) folosite la momentul actual variaz ca numr de mrci, sisteme de operare, dimensiuni ale ecranului, operatori de telefonie .a.m.d. Modele noi apar odat la cteva luni. Performana lor a ajuns deja la un nivel ridicat, din punct de vedere al capacitii de procesare, limii de band (bandwidth) i capabilitii hardware.O mare parte a populaiei, la nivel mondial, folosete dispozitive mobile i din aceast cauz un numr de faciliti sunt prezente, ca standard, pe o gam larg de dispozitive. Cu toate acestea, software-ul dezvoltat trebuie s fie specializat pentru un anume sistem de operare sau dispozitiv pentru a putea folosi capabilitile specifice fiecrui dispozitiv n parte i pentru o interfa grafic ergonomic.Arhitectura aplicaiilor mobile are n vedere urmtoarele obiective de pia: portabilitate: aplicaia trebuie s poat fi folosit pe o varietate ct mai larg de dispozitive mobile capabiliti native: dac este nevoie, aplicaia trebuie s utilizeze la maxim capabilitile native ale dispozitivelor. Acest lucru se refer att la capabiliti software (ex. input text) ct i hardware (camer video, GPS, ...). timp de dezvoltare: timpul pn la ieirea efectiv pe pia a produsului software trebuie s fie ct mai scurt posibil oportunitatea lansrii: apariia soft-ului pe pia trebuie s fie sincronizat cu apariia dispozitivelor mobile int compatibilitate: soft-ul trebuie s fie compatibil cu versiunile ulterioare ale dispozitivelor pe care poate rula. Este bine ca utilizatorii s poat s l foloseasc n continuare chiar dac i cumpr un nou telefon. Direcii ale arhitecturiin aceast seciune vom prezenta cteva direcii care influeneaz designul, dezvoltarea, instalarea i, n ultim instan, succesul aplicaiilor mobile.UtilizabilitatePentru a fi uor adoptat de utilizatori soft-ul trebuie sa fie uor de utilizat. Acest lucru implic urmtoarele: s fie uor de gsit i instalat s fie accesibil i uor de utilizat s fie performant i folositorn termeni practici acest lucru se traduce prin alegerea de a implementa sau nu aplicaia n limbajul nativ telefonului cu avantaje i dezavantaje care vor fi prezentate n capitolul urmtor.PortabilitatePentru a avea o cot de pia ct mai mare, aplicaia trebuie s poat fi utilizat pe un numr ct mai mare de dispozitive. Pe plan mondial sunt folosite bilioane de dispozitive. Un numr mare dintre acestea pot accesa internetul.Din punct de vedere tehnic acest lucru este ngreunat de diferenele de hardware i software dintre dispozitive: proprietile ecranului: rezoluie, culori numrul de butoane/taste protocoalele de reea suportate: GPRS, CDMA add-on-uri: GPS, camer video conectivitate: WiFi, Bluetooth, USBPortabilitatea este influenat negativ de dependena de un feature sau altul.InstalareUn posibil obstacol este modul de instalare. Aplicaia trebuie s fie uor de gsit i instalat i este bine ca update-urile s fie transparente utilizatorului. De obicei, instalarea se face folosind (n funcie de productorul dispozitivului i sistemul de operare) Google Play, Amazon AppStore sau AppStore-ul celor de la Apple.Scalabilitaten cazul unei aplicaii client server trebuie s avem n vedere numrul maxim de utilizatori conectai la un moment dat, cum putem testa cu o ncrcare similar i s avem n vedere un design care s permit mrirea acestei capaciti fr s fie nevoie s rescriem toat aplicaia.Arhitectura prii de client a aplicaiei trebuie s permit execuia cu performane satisfctoare pe telefoane sau tablete mai puin performante dar i pe cele de ultim generaie.Alegerea tehnologieiAlegerea tehnologiei este un pas foarte important n dezvoltarea software-ului pentru mobile. Pe o pia variat i n continu dezvoltare succesul depinde n mare msur de livrarea rapid a aplicaiilor ale cror caracteristici s ndeplineasc nevoile utilizatorilor de performan i utilizabilitate.Odat cu dezvoltarea terminalelor mobile, lucrurile au avansat i n domeniul tehnologiilor pentru aplicaii mobile existente. Plaja de opiuni se ntinde de la HTML5 sau framework-uri ca jQuery Mobile sau Sencha la aplicaii native pentru diverse versiuni de iOS i Android, BlackBerry i Windows Phone pn la framework-uri cross-platform cum ar fi IBM Worklight, PhoneGap, RhoMobile, Titanium Appcelerator.Dar, dei sunt multe tehnologii disponibile, exist trei moduri fundamentale de a dezvolta aplicaiile pentru mobile:1. Aplicaii native: aplicaia este compilat i optimizat pentru a rula pe un anumit dispozitiv i sistem de operare. Aplicaia este descrcat de pe AppStore i instalat local, n memoria dispozitivului.2. Aplicaii cross-platform: aplicaia este dezvoltat folosind un framework cross-platform i apoi este optimizat pentru execuia pe mai multe platforme mobile. La fel ca n cazul aplicaiilor native, aplicaia este descrcat de pe AppStore i instalat local.3. Aplicaii Web: aplicaia rezid pe un server www i este executat n browser.Fiecare opiune are avantaje i dezavantaje inerente i cazuri diferite de utilizare. Tabelul urmtor prezint n mod sumar caracteristicile fiecreia:Tabel 1. Caracteristici de alegere a tehnologiilorTehnologia folositNativFrameworkcross-platformWeb Mobile

Definiie i tool-uriAplicaii dezvoltate utiliznd un framework nativ: iPhone SDK Android SDK Windows Phone SDKAplicaii care, odat dezvoltarea ncheiat, pot fi executate ca aplicaii native pe mai multe platforme: RhoMobile Titanium Appcelerator PhoneGap WorklightAplicaii care utilizeaz tehnologii web: HTML5 Sencha jQuery Mobile

Tehnologia de baz iPhone: Objective C Android: Java Windows Phone: .NET RhoMobile: Ruby on Rails Appcelerator: Javascript, HTML PhoneGap: Javascript, HTML Worklight: Javascript, HTML Javascript, HTML

Mod de instalareApp storeApp storeWorld Wide Web

Cazuri de utilizare principale Aplicaii ce necesit o interfa grafic sofisticat i tranzacionale Mai muli utilizatori pe acelai tip de dispozitiv Utilizare offline Aplicaii ce necesit utilizarea extensiv a funciilor software/hardware Aplicaii mai simple de natur mai ales informaional Utilizare offline Mai multe tipuri de dispozitive sunt utilizate Funcioneaz satisfctor pentru aplicaii care nu necesit utilizarea extensiv a funciilor telefonului Interfa generic, performana depinde de viteza conexiunii la internet Baz de utilizatori distribuit pe diverse tipuri de platforme Aplicaia are un singur cod surs Numr limitat de funcii ale telefonului

Dezvoltarea nativ: cea mai bun interfa dar cu un cost ridicatAplicaiile dezvoltate n cod nativ ofer, fa de celelalte opiuni, cea mai bogat i captivant interfa grafic. Codul este optimizat pentru sistemul de operare pe care urmeaz a fi executate i pot s profite de toate capabilitile software (calendar, contacte, sistem de fiiere ) sau hardware (GPS, camer foto ) ale dispozitivului. Un alt avantaj este posibilitatea de a fi executate offline datorit faptului c aplicaia, odat descrcat de pe appStore, rmne instalat n memoria aparatului. Transferurile de date pot fi continuate odat cu refacerea conexiunii.Acest tip de dezvoltare este necesar dac aplicaia trebuie s foloseasc capabilitile telefonului. Diferit de aplicaiile cross-platform, care pot accesa unele funcii ale aparatului, aplicaiile native asigur accesul complet i performan maxim la aceste funcii, mai ales n cazul dispozitivelor echipate cu noi tehnologii.Dezavantajul principal al acestei tehnologii este costul, din urmtoarele cauze: Aplicaia trebuie s fie dezvoltat din nou, n proporie de 75 80%, pentru a fi compilat i executat pe o nou platform. Doar 20 25% din costuri pot fi economisite prin pstrarea designului interfeei grafice i a task-urilor de integrare. (Pentru BlackBerry ponderea costului de dezvoltare poate sa fie chiar 150% fa de platforma precedent din cauza versiunilor diferite de dispozitive i sisteme de operare folosite) Dezvoltarea se face folosind mai multe limbaje de programare. Aceasta necesit personal calificat pe mai multe tehnologii (ceea ce presupune un timp mare de nvare, iar calitatea obinut este adeseori nesatisfctoare) sau angajarea de personal specializat Mentenana aplicaiei implic dezvoltare, testare i deployment la apariia a noi versiuni ale dispozitivelor sau ale sistemelor de operareFramework-uri cross-platform: costuri mai reduse cu preul unei interfee mai sraceDezvoltarea cross-platform permite dezvoltarea software-ului folosind un limbaj de programare i utilizarea unor framework-uri (Appcelerator, PhoneGap, RhoMobile, IBM Worklight) pentru a-l adapta la execuia pe mai multe platforme, reducndu-se astfel costurile de dezvoltare. Majoritatea acestor framework-uri folosesc tehnologii Web HTML/Javascript, doar RhoMobile folosete Ruby on Rails.Fiecare dintre framework-uri are puncte forte i puncte slabe iar alegerea unuia anume depinde de necesitile aplicaiei i ale business-ului. O exigen necesar este ca framework-ul s fie compatibil cu dispozitivele i sistemele de operare pentru care este dezvoltat aplicaia. Alte considerente pentru alegerea unui framework sunt fiabilitatea adaptrii la caracteristicile platformei destinaie, suportul pentru capabiliti software/hardware, volumul de munc necesar pentru implementare i costul framework-ului.Urmtoarele observaii se aplic acestui tip de dezvoltare: Pentru majoritatea framework-urilor cross-platform aspectul i funcionalitatea interfaei grafice este mai apropiat cu cea a aplicaiilor web dect de o interfa nativ. n afar de Appcelerator, care creeaz aplicaii native pentru fiecare platform compatibil, celelalte framework-uri creeaz wrapper-e native pentru aplicaiile dezvoltate. dei teoretic modelul este compilare care ruleaz pe mai multe platforme n practic este nevoie de reglaj fin pentru fiecare platform n parte ceea ce se poate aduga 20 25% la efortul de dezvoltare pentru fiecare platform n parte. Este necesar o analiz a funciilor puse implicit la dispoziie de framework sau a costului de implementare a unor plug-in-uri care s permit folosirea altor capabiliti ale dispozitivului. compatibilitatea cu noi modele sau versiuni apare dup un timp de dezvoltare i nu este garantat de dezvoltatorii framework-urilor. n cazul aplicaiilor native compatibilitatea este imediatAplicaii web pentru mobile: compatibilitate extins dar cu performan i ergonomie reduseAvantajul principal al aplicaiilor web este compatibilitatea cu orice model de dispozitiv sau sistem de operare. Aplicaiile ruleaz ntr-un browser web deci pot fi accesate de pe orice dispozitiv fr sa fie nevoie s scriem cod specific fiecrei platforme n parte. Limitrile care au marcat de la nceput aplicaiile web sunt: nu pot folosi resursele hardware/software ale telefonului conexiunea cu internetul trebuie s fie activ pentru a fi executateHTML5, ultima versiune a limbajului HTML, ncepe s depeasc aceste limitri. Putem folosi funcionaliti ale telefonului iar aplicaiile vor putea fi executate i offline. Dar, deocamdat, HTML5 este un limbaj n dezvoltare i funcionalitatea sa este limitat comparativ cu aplicaiile native sau cross-platform. Chiar aa, exist deja mai multe aplicaii web dezvoltate folosind HTML5 care se anun o tehnologie a viitorului.Ce trebuie s avem n vedere pentru o dezvoltare web mobile?1. HTML5 nu este complet compatibil cu Internet Explorer i majoritatea celorlalte browsere ceea ce nseamn c unele funcii pot s nu funcioneze2. aplicaiile HTML5 au totui nevoie s fie optimizate pentru diferite platforme3. poate s fie nevoie s folosim framework-uri adiionale JQuery Mobile, Sencha pentru a avea cele mai bune rezultateCum facem alegerea ?Alegerea unei tehnologii depinde de cerinele business astfel nct putem defini o serie de factori care contribuie n luarea deciziei. Urmtoarele ntrebri ajut la stabilirea unui cadru pentru o tehnologie posibil.Cine va folosi aplicaia ?Rspunsul la aceast ntrebare este primul pas n alegerea unei tehnologii sau n restrngerea opiunilor. Analiza audienei int va evidenia platformele pentru care va fi dezvoltat aplicaia i caracteristici ale interfeei grafice. Ce ateapt utilizatorii de la interfaa grafic ?Pentru o aplicaie comercial aspectul interfeei grafice conteaz foarte mult: o interfa plcut, sau chiar impresionant, duce la folosirea n continuare a aplicaiei. n acest caz este potrivit implementarea unei aplicaii native.Pentru o aplicaie folosit n cadrul unei companii de ctre angajai (care folosesc platforme diferite) este suficient un aspect ngrijit al interfeei deci putem apela la o implementare cross-platform sau web.Ce funcionaliti sunt necesare ?Identificm funciile cheie ale aplicaiei care pot fi imprite n funcii informaionale, tranzacionale sau funcii furnizate de dispozitiv: dac funcia principal este de prezentare a coninutului, de a transmite informaie, este de preferat o implementare cross-platform sau web dac utilizatorul folosete aplicaia pentru execuia unui task sau avem nevoie s accesm funcionaliti ale dispozitivului (s crem o tranzacie in modul offline sau s accesm fiiere) ne vom ndrepta spre implementarea nativ sau cross-platformCt de important este compatibilitatea cu platforme multiple ?Dac exist o platform preferat putem urma mai multe strategii de implementare n paralel. De exemplu, putem implementa o aplicaie nativ pentru iOS i o versiune HTML5 pentru celelalte platforme.Aplicaia trebuie s ruleze offline sau cu o conexiune slab ?n cazul aplicaiilor comerciale o parte de baz a aplicaiei poate s rezide n memoria dispozitivului i s poat fi folosit fr conexiune la internet. n cazul angajailor unei companii poate fi necesar utilizarea aplicaiei offline. Informaia salvat poate fi sincronizat cu serverul odat cu revenirea conexiunii.Exist exigene specifice domeniului aplicaiei ?Uneori domeniul aplicaiei induce unele exigene care oblig la alegerea unei anumite soluii. De exemplu, pe piaa de retail este important ca aplicaia s fie vizibil i uor de gsit. n acest caz este mai potrivit o aplicaie web care poate fi optimizat pentru motoarele de cutare. Putem implementa o aplicaie web pentru atragerea noilor clieni (fiind mai uor de gsit) i o versiune nativ folosit clienii existeni.Ct de repede trebuie s lansm aplicaia ?Cel mai puin dureaz implementarea unei aplicaii web aceasta poate fi lansat pentru o audien maxim. Urmarea poate fi implementarea unor aplicaii native pentru platformele cheie.Ct de repede trebuie implementat compatibilitatea cu noile versiuni ?Unul din avantajele implementrii unei aplicaii native este compatibilitatea imediat cu noile versiuni de dispozitiv sau sistem de operare. n cazul aplicaiilor cross-platform compatibilitatea trebuie implementat mai nti de proprietarul framework-ului, proces ce poate dura pn la cteva luni. Dac aplicaia este complet implementat conform cerinelor nu este o nevoie urgent s o facem compatibil cu ultimele versiuni.Arhitectura aplicaiilor client-server pentru mobileO aplicaie pentru dispozitive mobile poate fi implementat folosind arhitectura client-server. Mai multe aplicaii client, executate pe terminalele mobile, se conecteaz i solicit informaie sau servicii existente pe un server. O aplicaie server primete aceste cereri, proceseaz informaia primit i returneaz clientului respectiv un rspuns corespunztor.Aplicaia clientClient thinUn client thin nu conine implementare a logicii de business care este furnizat de aplicaia server. O aplicaie web folosete un client thin dar putem avea i clieni nativi care conin doar interfaa grafic cu utilizatorul.Mentenana clientului thin este mai uor de realizat i aplicaia mai uor de optimizat pentru diferite platforme. n cazul aplicaiilor web nu este nevoie s lum n considerare distribuirea codului pe dispozitivele clienilor datorit faptului c aplicaia rezid pe server.Dezavantajul unui client thin este c nu poate fi folosit n lipsa conexiunii cu serverul de care depinde pentru funcionalitate. n cazul unei conexiuni slabe sau instabile un client fat este mai folositor.Client fatUn client fat conine logic de business, poate accesa servicii sau funcionaliti furnizate de o aplicaie server i poate rula fr conexiune la server. Astfel utilizatorul poate, de exemplu, s foloseasc aplicaia care salveaz n memorie informaia pe care o sincronizeaz cu serverul la reluarea conexiunii.Un client fat poate fi implementat ca aplicaie nativ (eventual folosind un framework cross-platform) ceea ce duce la avantajele i dezavantajele prezentate n capitolul anterior.Cele trei niveluri de cod sunt urmtoarele:1. Prezentare (view): interfaa grafic2. Business: funcionalitatea aplicaiei3. Data access: persistena informaiei i conexiunea cu serverulAplicaiile client fat au implementarea mprit n unul, dou sau trei niveluri (logice) de cod codul rmne mai mult sau mai puin acelai dar este mprit logic (clase i package-uri diferite, de exemplu). mprirea pe niveluri, dei poate dura mai mult timp are ca avantaje posibilitatea de a reutiliza codul, de a-l distribui pe mai multe dispozitive. Funcionalitile fiind izolate, mentenana acestora este mai uor de realizat.Aplicaia serverAplicaia server poate fi implementat, ca i n cazul clientului fat, izolnd codul n unul, dou sau trei niveluri view, business i data access. Fiecare tip de implementare are avantaje i dezavantaje care vor fi prezentate n cele ce urmeaz.Arhitectura cu un nivel

Figura 1. Arhitectura cu un nivelO aplicaie conine implementarea pentru toate cele trei nivelurile la un loc. Avantajul este simplificarea modelului arhitectural, faptul c avem tot codul la un loc iar deploymentul i configurarea sunt foarte simple. Dezvoltarea dureaz mai puin timp. Unul din dezavantaje este imposibilitatea de a distribui aplicaia server ceea ce ar crete scalabilitatea i securitatea acesteia.Arhitectura cu dou niveluri

Figura 2. Arhitectura cu dou nivelurin acest caz nivelul de Data Access este separat (fie logic, fie n alt aplicaie) i nivelurile de view i business sunt mpreun. Aplicaia este mai scalabil i poate fi specializat pentru un tip de baze de date. Implementarea, deploymentul i configurarea sunt mai dificile.Arhitectura cu trei niveluriAre cel mai mare potenial de scalabilitate poate fi implementat ca trei aplicaii diferite care rezid pe computere diferite. Nivelul de securitate poate crete, aplicaia client accesnd doar nivelul de view (sau de prezentare n cazul n care funcionalitatea este accesat prin RPC sau SOAP) iar celelalte niveluri pot fi securizate cu firewall-uri.

Figura 3. Arhitectura cu trei niveluriPe de alt parte, costurile i timpul de implementare sunt mai mari. Deploymentul i configurarea sunt mai complicate i trebuie s avem n vedere timpul de transfer pe reea n cazul n care nivelurile aplicaiei sunt distribuite.Sincronizarea informaieiDispozitivele mobile funcioneaz n unul din modurile urmtoare: mereu conectate: fie c este vorba de internet pe mobil sau wi-fi esenial este faptul c utilizatorii sunt mereu conectai conectate parial: utilizatorul se conecteaz din cnd n cand la internet este cel mai plauzibil scenariu din cauza costurilor internetului mobil, consumului rapid al bateriei. neconectate: dispozitivele pentru jocuri, de exemplu, nu au nevoie de conexiune la curent la internetn cazul conexiunii pariale este interesant problema sincronizrii informaiei ntre aplicaiile server i client. Utilizatorul continu s lucreze offline i n acest mod de funcionare informaia este stocat local. n momentul reconectrii dispozitivului informaia trebuie sincronizat cu serverul.O problem ce trebuie avut n vedere n momentul sincronizrii este integritatea datelor. Este posibil ca mai muli utilizatori s modifice aceleai informaii. O strategie posibil este verificarea momentului n care au fost fcute modificrile i atenionarea utilizatorilor n cazul n care modificrile fcute offline sunt n conflict cu modificrile altor utilizatori.Arhitectura SOAIntroduceren prezent peste un miliard de oameni folosesc smartphone-uri sau tablete in viaa de zi cu zi, pentru care utilizatorii pot alege din sute de mii de aplicaii. Majoritatea dintre acestea sunt personalizate, fiind utile dect n cazul n care pot accesa i date care nu sunt stocate pe telefon, comunicnd cu unul sau mai multe servere. Modul ideal prin care acestea comunic cu serverul se realizeaz prin intermediul serviciilor web. n cele ce urmeaz, vom detalia ce reprezint arhitectura bazat pe servicii, ce este un serviciu, tehnologiile folosite i modul prin care putem implementa servicii pe platformele existente.Definiie i componenteSOA este un tip de arhitectur software care presuspune mprirea funcionalitii aplicaiei n uniti distincte, servicii, care sunt distribuite ntr-o reea i pot fi utilizate mpreun. Acestea comunic ntre ele prin protocoale, fcnd transfer de informaie, neavnd apeluri unele ctre altele nglobate n interiorul lor, fiecare implementnd cel puin o aciune.[footnoteRef:1] [1: Creating Consumable Web Services for Mobile Devices-Professional Mobile Application Development, Jeff McWherter, Scott Gowell, Ed. John Wiley & Sons Inc., 2012, pag. 38]

O caracteristic important este reprezentat de modul prin care SOA promoveaz integrarea universal a serviciilor, permind aplicaiilor s fac schimb de mesaje, indiferent de mediul n care sunt executate.Un serviciu web permite comunicarea dintre dou dispozitive electronice prin intermediul internetului. Potrivit The World Wide Web Consortium, serviciul web este definit drept un sistem software realizat pentru a susine interaciunile interoperabile de tip main-main din cadrul unei reele.Componentele cheie n ceea ce privete arhitectura mobil bazat pe servicii web sunt: Clienii de dispozitive mobile (Orice combinaie ntre utilizatorii Android, iOS si HTML/JavaScript) Aplicaia mobil de tip back-end ce este responsabil cu soluionarea cererilor clienilor Stratul de comunicare dintre clieni si aplicaie Servicii cloud variate care stocheaz datele aplicaiei, genernd notificriAvantaje i DezavantajePrincipalele avantaje oferite prin intermediul serviciilor web sunt reprezentate de uurina de access si uurina de consum, fiind strns legate de conceptul de simplitate. Acestea sunt uor de accesat datorit faptului c folosesc aceleai tehnologii ca i World Wide Web, respectiv navigatoare i servere web, tehnologii ce s-au caracterizat n timp prin robustee. Cel de al doilea avantaj, uurina de consum, este caracterizat prin abilitatea de a inelege ce comunic serverul, detaliind acest lucru n cele ce urmeaz, descriind limbajele serviciilor web.[footnoteRef:2] [2: Creating Consumable Web Services for Mobile Devices-Professional Mobile Application Development, Jeff McWherter, Scott Gowell, Ed. John Wiley & Sons Inc., 2012, pag 39]

Un alt avantaj este reprezentat de capacitatea mare de reutilizare a serviciilor, aplicaia fiind structurat ntr-o mulime de module mai mici, neasociate, ce determin faptul c acest tip de arhitectur poate fi considerat o evoluie a programrii distribuite i modulare.Un dezavantaj poate fi reprezentat de gestionarea generaiilor viitoare de servicii, respectiv de imposibilitatea de a le integra perfect, problem ce este n general generat de lipsa unui framework pentru nelegerea cerinelor afacerii.Un alt dezavantaj mai este reprezentat i de numrul mare de servicii necesare pentru a atinge scopul afacerii, cauznd deseori probleme ce in de limitarea tehnic. Acestea pot fi controlate prin accesarea soluiilor oferite de unele sisteme de tip cloud.Tipuri de arhitecturi SOA Mobile

1. Client-Server cu client nativSe caracterizeaz prin flexibilitate crescut n legatur cu implementarea interfeei grafice i integrarea funciilor dispozitivului mobil. 2. Client-Server cu client Java mobileSe caracterizeaz prin faptul c se evit problemele legate de portabilitate si mentenan, asigurndu-se un mediu de execuie standard i un model de implementare pentru aplicaiile client din dispozitiv.3. Client-Server cu client thin Abordarea bazat pe browser a fost una de succes n cazul PC-urilor i a internetului, dei iniial uzabilitatea serviciilor oferite de navigator a fost redus, unele avnd probleme serioase legate de compatibilitate. Dezvoltarea serviciilor bazate pe navigator pentru clienii de aplicatii mobile se confrunt i n prezent cu probleme asemntoare, una dintre ele reprezentnd mrimea ecranului i modul n care informaia este afiat pe acesta.Servicii Google CloudIn cadrul platformei Google Cloud se poate construi cu usurin un backend pentru o soluie mobil Android, ct i iOS. Aceasta ofer servicii ce in de stocarea datelor, optimizarea accesului la date, prelucrarea asincron a sarcinilor n cozi, notificri de tip push, distribuirea de coninut static, distribuirea i prelucrarea imaginilor, servicii de cutare bazate pe locaie, administrarea sarcinilor i alte servicii importante.[footnoteRef:3] [3: *** https://cloud.google.com/developers/articles/mobile-application-solutions ]

Astfel putem afirma c prin valorificarea platformei Google Cloud, putem dezvolta cu uurin un backend pentru o soluie mobila, care s se caracterizeze prin scalabilitate, ndeplinind toate cerinele utlizatorului. Acest lucru este favorizat prin intermediul Google App Engine fiind platforma ideal pentru rularea de cod.Limbaje pentru serviciile webPentru ca dou calculatoare s poat comunica ele trebuie s foloseasc acelai limbaj, la fel cum n viaa de zi cu zi persoanele folosesc un anumit limbaj pentru a comunica. Limbajele de programare, precum C++, facilitateaz comunicarea dintre oameni i calculatoare, acestea putnd interpreta doar informaii reprezentate n sistemul binar. O facilitate a serviciilor web este aceea c folosesc limbaje descriptive, uor de interpretat de ctre toi utilizatorii.Alegerea formatului utilizat este un lucru foarte important pentru c influeneaz modul de acces i performana unei aplicaii. Unul din factorii care determin alegerea unui limbaj este modul n care este accesat aplicaia. De exemplu, dispozitivele mobile au mai puin putere de procesare dect calculatoarele desktop. Un alt lucru de care trebuie inut cont este platforma, intruct fiecare platform are API-uri diferite pentru accesul i utilizarea datelor. Cele mai utilizate i mai eficiente formate sunt XML i JSON.[footnoteRef:4] [4: Web Services Languages(Formats), Professional Mobile Application Development, Jeff McWherter, Scott Gowell, Ed. John Wiley & Sons Inc., 2012, pag 40.]

XML eXtensible Markup Language XML este un format utilizat pentru interschimbul de date, fiind uor de interpretat att de utilizatorii umani ct i de calculatoare.XML permite definirea de limbaje sistem folosite pentru comunicare prin crearea unui XML Schema Document (XSD). Un XSD specific modul in care se decriu formal elementele dintr-un document XML. XSD reprezint un set de reguli pe care un document XML trebuie s le respecte pentru a fi considerat valid conform schemei sale. n absena unui fiier XSD programatorii ar trebui s scrie cod pentru a nelege un document XML.Avantajele XML Maturitatea platformei; Are incorporate o mulime de instrumente : XPath, XQuery, XSLT, XSD; Majoritatea sistemelor lucreaz bine cu XML.XSLT- eXtensible Stylesheet Language TransformationsXSLT este un limbaj utilizat pentru transformarea documentelor XML n alte formate, precum XHTML (EXtensible HyperText Markup Language o versiune mai strict i pur a limbajului HTML) sau alte limbaje, n vederea utilizrii informaiillor de ctre alte aplicaii care nu recunosc documentele XML.XQueryXQuery este un limbaj de interogare i programare folosit pentru interogarea i recuperarea coleciilor de date structurate i nestructurate n format XML. XQuery ofer modaliti de extragere a datelor din documentele XML similar modului in care limbajele de interogare a bazelor de date (ex: SQL) extrag date din bazele de date.XQuery utilizeaz o serie de expresii pentru efectuarea jonciunilor i foloseste 5 clauze : FOR, LET, WHERE, ORDER BY i RETURN.Limbajul are la baz XPath Data Model (XDM) care folosete o structur arborescent a coninutului documentelor XML i conine 7 tipuri de noduri: noduri document, elemente, atribute, noduri text, comentarii, instruciuni de procesare i spaii de nume.JSON- JavaScript Object NotationJSON este un limbaj care folosete sintaxa JavaScript i este foarte uor de utilizat avnd puine reguli i puine tipuri de baz. Formatul JSON este folosit pentru transmiterea datelor ntre sisteme, ca alternativ a XML, deoarece este simplu, bazat pe text i este un format auto-descriptiv.Trebuie acordat o atenie deosebit modului n care sunt reprezentate datele calendaristice pentru c nu exist un tip de baz i nici un anumit standard pentru reprezentarea lor. Este recomandat folosirea formatului International Standards Organisation 8601 ( ISO-8601). O data completa este reprezentata de ISO-801 astfel: 2014-08-7T19:10:30.45+01:00, unde litera T reprezint un delimitator.Transmiterea datelor non-textualeAtt JSON, ct i XML creeaz documente text. Pentru transmiterea datelor non-textuale (imagini, video, documente PDF) se folosete reprezentarea binar. Pentru transmiterea datelor binare sub forma de text este necesar codificarea n Base64. Exist dou dezavantaje pentru codificare Base64: Creterea cu pan la 33% a marimii textului Procesarea adiional pe care att emitorul, ct i receptorul trebuie s o suporte pentru codificarea i decodificarea datelor.Arhitecturi i limbaje utilizateArhitecturi de dezvoltareExist mai multe modaliti prin care sunt incluse soluii informatice n cadrul dispozitivelor mobile: rularea unui browser pe dispozitivul mobil. Astfel, o aplicaie mobil este o aplicaie web optimizat pentru rularea pe dispositive mobile.Avantaje controlul rmne la aplicaia central nu necesit instalare sau update aplicaiile se dezvolt n aceeai maniera ca i nainte.

Aplicaiile native create direct pe platforma dispozitivului mobil. Din cauza faptului c fiecare platform are particularitile ei, costurile dezvoltarii unei astfel de aplicaii cresc considerabil. Astfel se urmrete crearea unor medii de dezvoltare interpretative care s permit dezvoltarea aplicaiilor pentru fiecare platform pornind de la un cod de baz uniform.Momentan nu s-a demonstrat care abordare va catiga, acest domeniu fiind n continua dezvoltare.[footnoteRef:5] [5: *** http://www.oracle.com/technetwork/articles/soa/ind-soa-mobile-2045748.html ]

Limbaje de programareAproape fiecare platform are propriul limbaj de programare: Apple Objective C Microsoft .NET pe platforma Windows Phone 8.x Google JavaJava este un limbaj extrem de raspandit. Este folosit in programarea pe partea de client pentru platforma Android. Exist i varianta pentru alte platforme JavaME ( Java Mobile Edition) care, n prezent se afl in declin. Varianta pentru platformele Oracle Java FX Mobile iniiat de SUN a euat, ns a fost nlocuit de Java FX 2 . HTML 5 reprezint ultima varianta HTML, avnd numeroase facilitai pentru camera video, microfon, busol, senzori de miscare, localizare GPS etc i include folosirea JavaScript i CSS. JavaScript este un limbaj vechi care a renscut odata cu apariia HTML 5.SecuritateDin cauza faptului c accesul la date n cadrul aplicaiilor mobile se realizeaz, n general, cu ajutorul serviciilor Web, este necesar asigurarea securitii acestora pe toate nivelurile aplicaiei, pentru a evita orice expunere la atacuri i riscuri iminente. Primordial este alegerea unei tehnologii adecvate tipurilor de date disponibile, deoarece fiecare rezolv probleme particulare i sunt potrivite n contexte diferite. De exemplu, n timp ce Silverlight este specializat pe dezvoltarea interfeei cu utilizatorul, .Net Compact Framework maximizeaz performana i timpii de rspuns pe platformele mobile. Exist aa numitele matrice de tehnologii pentru acces la date, care prezint avantajele acestora, precum i cazurile n care este recomandat abordarea lor.n principal, dispozitivele mobile sunt expuse multor ameninri, atacuri i programe prejudiciabile n continu cretere i dezvoltare, care pun n pericol sigurana platformelor, dar i a utilizatorilor. Astfel, breele de securitate i vulnerabilitatea aplicaiilor destinate acestora, trebuie diminuate, dac nu chiar eliminate pentru a aprea riscuri imprevizibile. Potrivit unui raport[footnoteRef:6] publicat de GAO (Gouvernment Accountability Office), acestea sunt cele mai frecvent ntlnite puncte sensibile n domeniul securitii mobile: [6: CYBERSECURITY Threats Impacting the Nation, United States Gouvernment Accountability Office, 2012]

lipsa controlului identitii prin parole se pierde controlul asupra datelor stocate, chiar i atunci cnd dispozitivul folosete numere de identificare personal sau mecanisme de blocarea ecranului; transmisiile wireless sunt necriptate mesajele trimise de ctre dispozitivele mobile sunt rareori codificate, periclitnd confidenialitatea utilizatorilor; dispozitivele conin deja programe malware utilizatorii pot instala aplicaii virusate n necunotin de cauz, iar lipsa unui software de securitate poate genera efecte negative ce se vor propaga i asupra altor aplicaii; sistemul de operare nu este actualizat odat ce un productor efectueaz o actualizare dureaz luni de zile pn cnd aceasta va fi fcut disponibil clienilor, timp n care pot aprea numeroase noi ameninri.Avnd n vedere multitudinea de scenarii i evenimente ce pot aprea n contextul utilizrii dispozitivelor mobile, exist numeroase soluii de asigurare a securitii i confidenialitii ce pot fi implementate, n funcie de necesiti.abloane de securitaten general, utilizarea unui API de servicii Web[footnoteRef:7] se bazeaz pe autentificarea utilizatorului pentru verificarea identitii acestuia. Acest procedeu se realizeaz pe baza de token, astfel c atunci cnd apelantul serviciului se nregistreaz cu un nume de utilizator i o parol, el va primi un token unic dup ce informaiile introduse au fost supuse tuturor filtrelor de verificare. El va fi folosit ulterior pentru toate cererile efectuate pe server pentru a identifica utilizatorul n cauz i a oferi serviciile la care are acces. n funcie de impelmentarea aplicaiei, identificatorul respectiv expir dup o perioad determinat de timp, dar trebuie prevenite evenimente precum captarea pachetelor i compromiterea acestuia prin asigurarea comunicrii ntre clientul mobil i serverul Web pe baza protocolului Secure Sockets Layer. [7: Mobile Architecture Best Practices: Best Practices for Mobile Application Design and Development, John Sprunger, Ed. West Monroe, 2012, pag. 5]

n cazul n care se dorete controlarea fluxului de la apelant ctre nivelurile de substrat ale aplicaiei, se recomand folosirea de impersonri i delegai. Aadar, accesul la resurse se face cu identitatea unui utilizator autentificat.De asemenea, se poate introduce mecanismul de subsisteme sau servere de tip trusted, care atribuie roluri din punct de vedere logic, tuturor utilizatorilor. Astfel, un rol le ofer aceleai drepturi tuturor membrilor si. Cu alte cuvinte, accesul la diverse funcionaliti i resurse se realizeaz pe baza nivelului de ncredere stabilit pentru apelant la un moment dat.Pentru asigurarea unui mai bun control asupra utilizatorilor, se pot introduce grupuri de utilizatori, fiecare avnd anumite drepturi alocate. Acest procedeu se bazeaz pe asignarea de identiti multiple n serviciile de tip trusted. Ca i reguli generale, indiferent de ablonul folosit, autentificarea utilizatorilor se face n mod controlat i securizat, accesul la date fcndu-se pe baz de ncredere i drepturi acordate. Din punct de vedere al sistemelor de comunicaii, protocolul SSL se va ntrebuina doar pentru autentificri de baz, iar mesajele SOAP vor fi protejate prin Web Services Security n vederea asigurrii integritii i confidenialitii acestora, desigur utilizndu-se strategii de codare i criptare potrivite.Securitatea datelorDin cauz c platformele mobile sunt mult mai vulnerabile dect serverele din centrele de date, n ceea ce privete asigurarea securitii informaiilor, se recomand ca datele importante sau confideniale s fie stocate pe un server back-end, cu posibilitatea de descrcare. Alternativ, se recomand criptarea acestora cu o cheie ce nu va fi memorat pe acelai dispozitiv[footnoteRef:8]. [8: Mobile Application Architecture Guide, J.D. Meier, Ed. Microsoft Corporation, 2008, paginile 108 - 138]

Mai mult, pentru asigurarea integritii datelor este necesar separarea datelor de logica de business i componentele de business. Astfel, pentru ca nivelul de business s nu aib acces direct la toate acestea, se va introduce un nivel de date distinct, iar interogrile se vor realiza cu ajutorul obiectelor. Regulile de business nu trebuie nici ele s fie implementate n cadrul structurilor de date. n cazul datelor volatile, se recomand stocarea acestora n fiiere XML, iar daca volumul de date este sczut, se pot utiliza seturi de date pentru operaii efectuate fr conectare. Este de preferat s fie implementat un mecanism de serializare, precum i folosirea interoperabilitii, ct mai mult posibil.Faza de proiectare a aplicaiei se bazeaz pe abstractizare i maparea structurilor de date existente n entiti corespunztoare. Aceste entiti vor putea fi serializate i memorate pe uniti fizice de stocare sau transferate. Cum tabelele din baza de date vor avea ca i corespondent o anumit entitate, pentru proiectarea nivelului de business este folosit ablonul Table Module fundamentat pe principiul c o singur instan gestioneaz logica de business pentru toate nregistrrile dintr-o tabel. Informaiile de conectare trebuie protejate de accesul neautorizat al clienilor. Pentru stocarea datelor precum imagini sau sunete sunt folosite colecii de tip binary large object, ce vor fi convertite la tipuri de date specifice aplicaiei. Ele sunt stocate n baza de date mpreun cu alte cmpuri adiionale, astfel c se va facilita sincronizarea obiectelor de volum mare ntre servere.La depozitarea datelor, se folosete mecanismul de cache pentru a mbunti timpii de rspuns, ns trebuie avut n vedere c unele date nu se pot stoca aici. De exemplu, datele care i schimb frecvent coninutul vor fi memorate n cache, doar dac nu sunt necesare ntr-un context de conectare. Nici datele sensitive sau confideniale nu se stocheaz n acest mediu, dect dac sunt criptate i este neaprat necesar. De asemenea, se vor realiza teste pentru a verifica dac n cazul de fa, memoria cache chiar contribuie la mbuntirea performanelor aplicaiei, pentru a nu risca deteriorarea informaiilor.n ceea ce privete operaiile de interogare a datelor, clauzele SQL trebuie s foloseasc parametri n locul lucrului cu iruri de caractere, pentru prevenirea atacurilor SLQ injection. De asemenea, este descurajat folosirea concatenrii irurilor de caractere atunci cnd se genereaz interogri n mod dinamic. Pentru evitarea interogrii excesive a bazei de date, i deci diminuarea riscurilor asupra securitii, comenzile SQL se pot grupa n batch-uri, care urmeaz s fie executate ulterior laolalt. Astfel scade numrul interogrilor efectuate, crete performana nivelului de date i se minimizeaz traficul n reea. Sistemul de tranzacii se va folosi doar cnd este necesar, iar dimensiunea lor va fi ct mai redus pentru a nu genera blocaje interminabile. Tranzaciile explicite se folosesc doar atunci cnd se lucreaz cu o singur baz de date la un moment dat. Ca i cazuri particulare, nu se vor folosi tranzacii imbricate cnd se lucreaz cu SQL Server Compact i nu se folosesc tranzacii distribuite cu tehnologia .NET Compact. Managementul excepiilorO alt soluie pentru mbuntirea performanelor n ceea ce privete securitatea este tratarea excepiilor. Trebuie avut n vedere faptul c mesajele de eroare nu trebuie s conin date sensitive i nici nu sunt folosite pentru a controla nivelul logic. Toate excepiile netratate trebuie captate pentru a nu risca apariia unor erori necontrolabile la interaciunea utilizatorului cu aplicaia. Este important proiectarea unei strategii de propagare a excepiilor, astfel c ele vor fi tratate doar dac este posibil, iar excepiile rmase netratate vor fi rezolvate printr-un handler global. Stocarea ct mai multor informaii despre fiecare eroare este necesar i poate fi realizat prin fiiere log, ns ntr-un format comprimat i inndu-se cont de restriciile aplicaiei i de tipul datelor gestionate. Validrin ceea ce privete nivelul de prezentare prin intermediul cruia utilizatorul interacioneaz cu aplicaia, trebuie asigurat corectitudinea informaiilor introduse n oricare component de tip input. Strategia de validare va verifica lungimea, formatul i tipul datelor de intrare introduse de utilizatorul curent, protejndu-se dispozitivul i aplicaia. Procesul acesta este obligatoriu, mai ales atunci cnd se lucreaz cu instruciuni SQL dinamice, generate de utilizator. Cu toate acestea, validrile trebuie s se regseasc i la nivel logic pentru a elimina posibilitatea de introducere a unor date cu caracter nociv i tratarea cererilor nevalide. Acest mecanism este eficient i pentru prevenirea efecturii de cereri inutile i interogri abuzive, fiind necesar i pentru protecia echipamentelor hardware precum camera Web, atunci cnd se verific metodele ce garanteaz accesul automat la aceasta. Din cauza limitei de memorie disponibil pe dispozitivele mobile, toate operaiunile de asigurare a securitii trebuie realizatate cu o amprent de memorie minim. Comunicarea n reeaAplicaiile mobile sunt dependente de accesarea resurselor prin intermediul reelelor de comunicaii, care pot fi de tip provider, WiFi etc. n primul rnd trebuie stabilit dac mesajele sunt transmise ntr-un singur sens sau n ambele sensuri i se vor gestiona apelurile asincrone, care rezolv blocajele survenite n cadrul operaiilor de intrare/ieire, precum i conflictele de sincronizare. De asemenea, se va realiza o separare ntre interfaa grafic i navigarea propriu-zis n aplicaie, mai ales dac logica deplasrii de la o pagin la alta este complex. Aadar, pentru separarea interfeei de nivelul logic se va folosi ablonul Page Controller ce trateaz cererile efectuate ntr-o anumit pagin, iar dac se dorete navigarea n mod dinamic, se va apela la ablonul Front Controller. Acesta din urm, soluioneaz cererile prin oferirea unui punct de intrare centralizat i rezolv probleme legate de fluxurile de lucru. Mai mult, cererile nu trebuie s blocheze accesul la interfaa grafic cu utilizatorul, deci componentele accesate de cererile utilizatorului nu trebuie s fie aceleai cu cumponentele ce redau elementele din interfa sau cu cele de business.Performana aplicaiilor mobilePerformana reprezint un factor extrem de important ce trebuie avut n vedere n momentul n care dezvoltm site-uri web pentru dispozitivele mobile. Dac folosirea pe scar tot mai larg a internetului ne-a obinuit cu un internet relativ instant, atunci cnd l folosim prin intermediul telefonului mobil, lucrurile pot deveni de-a dreptul lente. Principalul motiv este faptul c vitezele conexiunilor mobile sunt destul de reduse comparativ cu internetul de mare vitez, n care viteza efectiv de transfer (randamentul) este foarte mare, fcnd ca practicile neglijente de dezvoltare s nu afecteze performanele aplicaiei.n cazul aplicaiilor mobile, se impune testarea lor n condiiile n care utilizatorul este fie deconectat de la internet, fie cu Wi-Fi-ul oprit i n locaii diverse cu diferite niveluri de putere a semnalului. Aceeai pagin web, care dureaz cteva secunde pentru a se ncrca folosind tehnologia 3G, poate fi accesat n mai puin de o secund, dac Wi-Fi-ul este pornit. Dei performanele unei aplicaii mobile par s depind critic de conexiunea de care dispune dispozitivul, acest lucru poate fi evitat folosind mai multe tehnici preluate din realizarea site-urilor web desktop rapide, care se aplic n egal msur i n cazul dispozitivelor mobile. Fiecare dintre aceste tehnici este legat de reea, ntruct cea mai mare constrngere pentru dispozitivele mobile const n limea de band disponibil n reea. Aadar, se urmrete n esen optimizarea a ceea ce se ntmpl ntre server i dispozitiv. n continuare vom prezenta cteva tool-uri de baz, care sunt utilizate n msurarea peformanei. Aceste instrumente se pot dovedi extrem de utile atunci cnd se dorete testarea performanei unui site web. Vom discuta despre Chrome Developer Tools i Fiddler.Chrome Developer Tools pune la dispoziie o serie de funcii folositoare n analiza performanei:1. Toolul reea (Network Tool) ofer o reprezentare grafic a modului n care componentele paginilor web de pe client se ncarc i ct timp dureaz. Timpului necesar livrrii paginii iniiale (care poate fi redus) i se adaug cel necesar ncrcrii celorlalte elemente (fonturi, scripturi, imagini etc.) i chiar dac browserul este capabil s fac mai multe cereri n paralel, faptul c unele resurse sunt condiionate de existena altora, ngreuneaz ncrcarea complet a paginii.2. Tab-ul de audit (Audits Tab) aplic unele reguli de performan bine cunoscute paginii vizualizate. Recomandrile pe care le face sunt mprite n dou categorii, una care vizeaz partea de reea i alta care ine de performana browserului, i evideniate folosind culori adecvate pentru a atrage atenia asupra celor mai grave probleme.

Fiddler este un proxy folosit pentru depanarea web, utilizat pentru a observa ce se ntmpl n reea. El dispune de instrumente remarcabile prin care se pot analiza biii care trec n ambele sensuri n reea. Poate fi, de asemenea, folosit ca un server proxy.Tehnici de performanExist tehnici care se aplic totdeauna i altele care sunt doar recomandri [footnoteRef:9] ce au rezultate bune, dar nu se dovedesc a fi mereu necesare. [9: Mobile Performance Mobile ASP.NET MVC 5, Eric Sowell, Editura Apress, 2013, paginile 140 - 156]

ntotdeauna numrul de cereri http trebuie redus pe ct posibilCel mai important mod prin care se crete performana aplicaiilor mobile este reducerea numrului de cereri http, nainte ca pagina s se ncarce. Cererile suplimentare nu fac dect s oblige browserul s ia legtura cu nivelul transport, care va aduce toate resursele i i le va returna, ceea ce se traduce n milisecunde importante care se scurg pn ca utilizatorul s vizualizeze pagina i, de asemenea, va crete consumul bateriei.ntotdeauna utilizai Gzip pentru compresieGzip este un instrument de compresie/decompresie extrem de utilizat pentru traficul web, fiind suportat att de browsere, ct i de servere. Se recomand s fie inut activat. Trebuie avut n vedere faptul c atunci cnd serverul este unul propriu, local, el trebuie configurat folosind IIS, pentru a suporta compresia coninutului dinamic (pentru cel static este implicit). ntruct viteza efectiv de transfer a datelor n reea este extrem de important n cazul dispozitivelor mobile, n permanen este indicat ca partea de HTML, CSS i JavaScript s fie adecvat comprimat.ntotdeauna trebuie s se combine i s se minimizeze codul CSS i JavaScriptCele mai multe site-uri folosesc cantiti semnificative de cod CSS i JavaScript, de aceea dezvoltatorii prefer s-l organizeze separat, n mai multe fiiere, ntruct gestionarea unuia singur de dimensiune mare poate deveni greoaie. Totui, unul sau dou fiiere mai mari se preteaz mai bine din punct de vedere al performanei browserului, dect mai multe fiiere mici, aadar, este indicat ca acestea s fie combinate nainte de a fi trimise. Pe lng aceasta, o alt recomandare include minimizarea codului din fiiere, astfel nct s se reduc numrul total de octei care se transmit n reea. De exemplu, ASP.NET dispune de o librrie capabil s realizeze n mod simplu aceste task-uri (Microsoft ASP.NET Web Optimization Framework).ntotdeauna trebuie s se pstreze un cache partea de client, dac este posibilEvident, cele mai rapide elemente dintr-o pagin sunt cele pe care nu trebuie s le descarci. Prima dat cnd componentele unui site sunt solicitate de ctre un browser, acestea trebuie preluate fie de pe server, fie folosind un proxy de cache ntre browser i server. Ne vom axa ns pe cererile ulterioare. n cazul n care aceste elemente solicitate pot fi pstrate n memoria cache, atunci browserul fie nu trebuie s solicite toate componentele, fie nici nu trebuie sa fac o alt cerere. Exist mai multe headere http, care pot fi folosite pentru a controla acest lucru: Dac a fost modificat (If-Modified-Since) indic faptul c browserul are o copie a resursei n memoria cache, ns va verifica serverul pentru a vedea dac este disponibil o versiune mai nou a acesteia. Dac nu exist, va returna statusul 304 (niciun coninut), informnd astfel browserul c trebuie s foloseasc ceea ce e salvat n cache, reducnd numrul de bytes care traverseaz reeaua nainte ca pagina s fie ncrcat. Dac gsete un coninut nou, atunci acesta va fi returnat. Expir (Expires) este folosit pentru a arata ct timp pagina se afl memorat n cache i poate fi prelut de browser de acolo, fr a fi necesar verificarea n prealabil a reelei, pentru un potenial nou coninut, ca n cazul anterior. Acest header nu se preteaz ns n cazul n care coninutul paginii se schimb constant, iar afiarea unor date vechi nu este convenabil utilizatorului. Controlul memoriei cache (Cache Control) este util corelat cu headerul Expires. Potenial, orice proxy intermediar situat ntre server i browser poate pstra n cache o resurs. Dac acest header este setat ca fiind public, atunci resursa poate fi memorat n cache de ctre orice cache, far a se limita doar la memoria cache a browserului. Dac este privat, atunci rspunsul nu poate fi pstrat de orice cache partajat (precum cel al furnizorului de servicii de internet), ci doar de cel al browserului.ntotdeauna optimizeaz atunci cnd sunt incluse n pagin scripturi i CSSLocul n care este plasat un fiier CSS sau JavaScript ntr-o pagin influeneaz performana (perceput sau real), uneori chiar n mod dramatic. Totdeauna, ntr-o pagin web fiierele CSS trebuie ncrcate n antet (head), iar fiierele JavaScript n subsol (footer). Astfel, dac exist mai multe fiiere CSS atunci ele pot fi descrcate n paralel, dar n acest timp redarea paginii este blocat, deoarece n caz contrar tot procesul de redare ar trebui s se repete pe msur ce alte stiluri sunt aplicate. Incluznd fiierul CSS la nceputul paginii se evit vizualizarea unui coninut nestilizat acolo unde pagina se ncarc nainte ca CSS-ul s fie aplicat. Fiierele JavaScript, pe de alt parte, nu pot fi descrcate n paralel i conduc la blocarea redrii paginii, precum i a altor descrcri care pot surveni. Acesta este motivul principal pentru care se recomand plasarea lor la finalul paginii. Aceste sfaturi au ns un impact major mai degrab asupra performanei percepute de utilizator, ntruct se dorete ca el s poat vizualiza pagina web n forma sa final, stilizat, ct mai repede posibil, iar funcionalitatea conferit de scripturi poate s fie adugat ulterior, la scurt timp. ntotdeauna optimizai imaginilePrincipalul obiectiv al acestei tehnici este mbuntirea experienei de navigare a utilizatorului. Cele mai utilizate formate de imagine n web sunt PNG, JPG i GIF, fiecare cu avantajele lor, ns se recomand s fie ncercate toate pentru a alege formatul care ofer cel mai bun raport calitate/compresie la un moment dat. Dac GIF i PNG nu folosesc compresia i suport transparena, fiind utilizate de regul n partea de web design, JPG nu permite transparena i suport un grad mare de comprimare, pretndu-se mai degrab pentru fotografii i mai puin pentru imagini care conin text sau forme geometrice.De cele mai multe ori, imaginile au ncorporate date suplimentare, care nu sunt necesare i pot fi nlturate, micornd dimensiunea fr a afecta ns calitatea. Nu n ultimul rnd, imaginile de calitate superioar este indicat s fie folosite doar pentru dispozitivele care pot beneficia de aceste avantaje, pentru cele cu ecrane de calitate sczut ncetinind inutil site-ul, fr vreun alt avantaj.Poate fi avut n vedere folosirea sprite-urilor CSSAceast tehnic vizeaz n fond reducerea pe ct posibil a cererilor http, despre care am discutat. Dac exist mai multe elemente ntr-o pagin care au nevoie de o imagine, atunci folosirea unui tag de imagine de fiecare dat nu este cea mai elegant i performant metod, ntruct fiecare tag n parte va necesita o nou cerere http. n acest caz, soluia este dat de utilizarea sprite-urilor CSS care conduc la obinerea aceluiai efect vizual, dar limiteaz numrul de cereri http.Poate fi avut n vedere utilizarea unei reele cu livrare de coninutO reea cu livrare de coninut este un serviciu specializat n distribuirea de coninut, precum imagini, fiiere CSS i Javascript, clipuri video, pe o arie geografic mai larg dect locaia de care aparine, de regul, un site. Este recomandat pentru site-uri cu un trafic crescut, ducnd la mbuntirea performanei pe baza proximitii geografice. Chiar dac un site este extrem de optimizat, atunci cnd se ncearc accesarea lui dintr-o alt ar, de exemplu, din cauza distanei va dura mai mult pn cnd coninutul va putea fi vizualizat. Dac ns elementele de pe partea de client ar fi gzduite pe o reea cu livrare de coninut ce are locaii peste tot n lume, va crete considerabil timpul de rspuns.n concluzie, atunci cnd discutm despre dispozitive mobile performana este un factor extrem de important, n special din cauza faptului c acestea nu dispun de o vitez efectiv mare de transfer a datelor n reea. Exist ns o serie de practici care conduc la optimizarea performanei i care pot fi folosite cu succes pentru a mbunti interaciunea dispozitivului cu serverul.Arhitectura la nivel de GUI (design)n Android, pentru a crea o interfa utilizator (UI) exist dou modaliti i anume: Declarativ; Programatic;UI declarativAceast abordare de creare a unei interfee utilizator implic folosirea XML-urilor prin intermediul crora se vor specifica toate componentele pe care UI-ul le va conine. Acest procedeu este asemntor cu cel de realizare a unei pagini HTML, la nivelul creia se defineau diferite tag-uri i elemente.Un avantaj al modalitii declarative este c poate utiliza instrumentele WYSIWYG, care apar fie ca o extensie n Eclipse Android Development Tools (ADT), fie sunt furnizate de diferii teri. XML-urile sunt uor de utilizat, astfel persoane nefamiliarizate cu platforma Android pot crea fr probleme diferite interfee. De asemenea, aceast abordare prezint i un dezavantaj prin faptul c XML-urile nu ofer o modalitate bun de gestionare a datelor introduse de utilizator, n acest caz abordarea programatic este mai eficient.UI programaticAceast modalitate presupune scrierea de cod Java pentru a dezvolta UI-uri, fiind destul de asemntoare cu cea de creare a Swing-urilor sau AWT-urilor. De exemplu, pentru a se crea un buton, prin aceast abordare, se vor realiza urmtori pai: definirea unei variabile de tipul buton i a unei instane a acesteia, adugarea ntr-un container i setarea diferitelor proprieti cum ar fi culoarea, textul, dimensiunea textului, fundalul etc. Practic, programatic se pot realiza toate elementele pe care le poti face i declarativ. Dar, marele avantaj al acestei abordri pentru realizarea unei interfee utilizator l constituie faptul c poate s specifice ceea ce se ntmpl n momenentul n care o component este accesat de utilizator.Ce metod se recomand pentru a se utiliza? Se recomand a se utiliza mpreun cele dou modaliti, astfel XML-urile, care sunt statice, pot fi folosite pentru a se declara toate elementele ce realizeaz interfaa, cum ar fi aspectul ecranului, widget-urile etc. Apoi se utilizeaz cealalt abordare pentru a specifica ceea ce se ntmpl atunci cnd utilizatorul interacioneaz cu diferite widget-uri din interfa. Cu alte cuvinte, se folosesc XML-urile pentru a determina aspectul elementelor, iar Java pentru a specifica ceea ce fac acestea. View-uri i layout-uriAndroid organizeaz toate elementele UI n view-uri i layout-uri, astfel tot ceea ce se poate vizualiza pe o interfa (butoane, etichete, casete de text etc.) reprezint un view. Gruparea mai multor view-uri (spre exemplu o etichet cu un buton) sunt gestionate prin intermediul layout-urilor. Pentru cei familiarizai cu Java AWT i Java Swing, layout-urile sunt similare cu containerele Java, iar view-rile cu componentele Java. De asemenea, layout-urile pot conine la rndul lor ali copii, acetia putnd fii chiar alte layout-uri, realizndu-se astfel o structur UI complex. Tot n sarcina printelui cade responsabilitatea de a aloca spaiu pentru fiecare copil al su. Cele mai utilizate tipuri de layout-uri[footnoteRef:10] sunt urmtoarele: [10: Android user interface Learning Android, 2nd Edition, Marko Gargenta, Masumi Nakamura, Editura OReilly, 2014, pag. 89 - 92]

LinearLayout; TableLayout; FrameLayout; RelativeLayout;LinearLayoutLinearLayout este unul dintre cele mai simple i frecvente layout-uri, n cadrul su toi copii sunt situai unul lng altul, fie pe vertical sau orizontal. Ordinea n care sunt adugai descendeni este important, deoarece alocarea spaiului neceser pentru fiecare copil se face n funcie de introducerea acestora. Astfel, dac un copil necesit tot spaiul deinut de layout nu se vor mai putea aduga alte widget-uri n cadrul acestuia. Dispunerea orizontal sau vertical a elementelor din cadrul unui LinearLayout se realizeaz cu ajutorul proprietii layout_orientation. De asemenea, un LinearLayout respect marginile dintre copii si precum i gravitatea (alinierea la dreapta, stnga sau centru) a fiecrui copil.

Figura 4. Linear LayoutTableLayout n cadrul acestui tip de layout, toate elementele sunt dispuse ntr-un tabel, acesta coninnd un anumit numr de obiecte de tipul TableRow. Aceste obiecte pot conine diferite widget-uri specifice unei interfee pentru utilizator. Widget-urile TableRow sunt aezate unul lng altul ca i n cazul unui LinearLayout cu orientare orizontal. Pentru cei care au utilizat HTML, TableLayout este asemntor cu elementul , iar TableRow cu tag-ul . De asemenea, HTML ofer i tag-ul pentru a gestiona fiecare celul din cadrul tabelului, n Android numrul de coloane este determinat dinamic n funcie de numrul de view-uri adugate ntr-un TableRow.

Figura 5. Table LayoutFrameLayoutFrameLayout-ul presupune adugarea de view-uri unu peste altul, astfel ultimul i acoper pe toi ceilali, ca ntr-un pachet de cri. De asemenea, acest tip de layout mai este utilizat pentru a gzdui widget-uri ce vor fi adugate programatic la un moment dat.

Figura 6. Frame LayoutRelativeLayoutRelativeLayout permite adugarea copiilor n poziii relative unu fa de cellalt. Acest tip de layout este foarte utili, deoarece nu necesit combinarea mai multor layout-uri pentru a obine aspectul dorit. De exemplu, dac se dorete realizarea unei matrice doi pe doi de widget-uri se poate utiliza un singur RelativeLayout, n loc de dou LinearLayout-uri orizontale n interioriul unui LinearLayout vertical. De asemenea, RelativeLayout aduce o anumit complexitate view-urilor prin adgarea unor ID-uri prin intermediul crora se realizeaz poziionarea relativ a unui copil fa de ceilali. n prezent, acesta este cel mai utilizat layout dintre cele prezentate mai sus.

Figura 7. Relative Layout

2