Aplicatii Pentru Dispozitive Mobile

DISERTAȚIE

Aplicații pentru dispozitive mobile

Cuprins

Cuprins

Introducere

Capitolul I. Platforme mobile

I.1 Platforma Android

I.2 Platforma iOS

I.3 Platforma Windows Phone

Capitolul II. Soluții pentru aplicații utilizate pe dispozitive mobile

II.1 Contextul actual

II.2 Soluții posibile de implementare

II.2.1 Aplicații native

II.2.2 Aplicații hibride

II.2.3 Aplicații native prin cod portabil compilat.

II.3 Alegerea soluției optime

Capitolul III. Proiectarea aplicațiilor pentru dispozitive mobile

III.1 Concepte de design a interfețelor

III.1.1 Elemente principale de design

III.1.2 Designul grafic pentru ambele orientări

III.1.3 Design grafic optimizat pentru tablete

III.1.4 Wireframe-uri și prototipuri

III.2 Metodologii de dezvoltare a aplicațiilor

III.2.1 Rational Unified Process (RUP)

III.2.2 Programarea extremă (XP)

III.2.3 SCRUM

III.2.4 Alegerea soluției optime

Capitolul IV. Studiu de caz – aplicația U-BT-Mobitelco

IV.1 Implementarea aplicației U-BT-Mobitelco

IV.2 Pentru implementarea lui am folosit componenta de tip lista „ListView”.

Capitolul V. Concluzii

Capitolul VI. Capitolul VI. Bibliografie

Introducere

Trăind într-o lume în continuă mișcare, evoluția necesității oamenilor de a fi informați este în continuă creștere, prin urmare, internetul a devenit indispensabil societății contemporane, fiind unul dintre cele mai rapide și eficiente metode de informare.

În trecut dezvoltarea aplicațiilor pentru dispozitive mobile era foarte greoaie față de prezent, în prezent sistemele de operare mobile și dispozitivele mobile inteligente oferă multe posibilități de a crea aplicații tot mai complexe.

Modalitatea rapidă prin care laptopurile au înlocuit desktop–urile, cu câțiva ani în urmă ne lasă o idee foarte clară asupra trendului crescător al tehnologiei ce dispune de facilități de accesare a datelor de oriunde în orice moment.

Tabletele și telefoanele inteligente au devenit o parte integrantă a vieții de zi cu zi a oamenilor mai mult sau mai puțin activi. Mulțumită acestor medii online relativ noi, s-au deschis oportunități pentru multe companii de a fi prezente și mai mult în viața consumatorilor decât eram obișnuiți în trecut prin intermediul unui website.

Dezvoltatorii de aplicații s-au orientat de la aplicații web și aplicații desktop către aplicații mobile deoarece piața telefoanelor inteligente și tabletelor a crescut foarte mult în ultimii ani înlocuind laptopurile și calculatoarele. În prezent foarte mulți utilizatori folosesc dispozitive inteligente.

În cadrul acestei lucrări se prezintă informații foarte folositoare pentru realizarea unei aplicații pentru dispozitivele mobile de la alegerea platformei până la gestionarea proiectului, prezentând de asemenea sfaturi pentru realizarea unui design foarte reușit.

Platforme mobile

Sistemele de operare mobile sunt sisteme de operare gândite pentru dispozitive mobile care au specificații mai inferiore decât calculatoarele având putere de calcul, memorie, și capacitatea de stocare mult mai limitată. În momentul actual sistemele de operare mobile au cea mai mare creștere din toate tipurile de sisteme de operare.

Cele mai populare sisteme de operare mobile sunt: Android, iOS,Windows Phone, Bada, BlackBerry OS și Symbian.

Figura I-1. Tipuri de platforme mobile.

Sistemele de operare iOS si Android sunt cele mai populare sisteme de operare pentru terminale mobile, cota lor de piața este peste 90%. Vânzările producătorilor de telefoane mobile inteligente sunt prezentate în tabelul de mai jos.

Tabel I-1. Statistica volumului de vânzări pentru anul 2012 și anul 2013[3].

Se poate observa în tabelul precedent că brandurile Samsung si Apple conduc cu detașare vânzările de telefoane inteligente.

În figura I-2 sunt prezentate vânzările producătorilor de telefoane mobile inteligente.

Figura I-2.Volumul de vânzări pentru anul 2012 și anul 2013 [3].

În tabelul I-2 sunt prezentate vânzările pentru sistemele de operare specifice dispozitivelor mobile inteligente.

Tabel I-2. Volumul de vânzări pentru anul 2013 și anul 2012 pentru sistemele de operare[3].

Cel mai folosit sistem de operare din lume la momentul actual este Android, circa patru din cinci telefoane rulează cu acest sistem de operare. Pe locul doi se poziționează sistemul de operare iOS care a mai pierdut un pic din cota sa de piața. În figura I-3 este prezentată statistica privind volumul vânzărilor sistemelor de operare mobile.

Figura I-3. Volumul de vânzări pentru anul 2013 și anul 2012 pentru sistemele de operare[3].

Conform organizației „International Data Corporation”, ritmul de creștere va încetini ușor în anii care urmează, în principal din cauza saturației piețelor dezvoltate (precum Europa sau America de Nord).

Se estimează că vânzările totale de telefoane mobile vor ajunge la 1,7 miliarde în 2017. Se poate observa în tabelul I-3 faptul că ratele preconizate de creștere în cazul acestor două piețe vor fi de două sau chiar de trei ori mai reduse decât cele înregistrate în celelalte trei regiuni (cea mai dinamică urmând să fie America Latină).

Tabel I-3. Volumul vânzărilor preconizate în anul 2017.

Platforma Android

Android este o platformă software, un sistem de operare bazat pe nucleul Linux pentru dispozitive mobile, dezvoltat de compania Google. Android permite dezvoltatorilor să scrie cod în limbajul Java, controlând dispozitivul prin intermediul bibliotecilor Java dar oferă și posibilitatea ca o parte din aplicație sau toata aplicația sa fie scris intr-un alt limbaj cum ar fi C și C++ prin intermediul Android NDK. Android NDK este foarte utilă pentru anumite tipuri de aplicații, oferind posibilitatea de a reutiliza bibliotecile deja existente, de a porta jocuri (aplicații) de pe alte platforme, utilizarea unui framework de jocuri sau in cazul editoarelor foto si video de a avea mai multa putere de procesare. Cele mai multe aplicații nu au nevoie de Android NDK.

În momentul actual este cel mai răspândit sistem de operare mobil deținând 80% din piața. Codul sistemului de operare Android este sub licența Apache, o licență de tip soft gratuit și open source.

Exista un număr relativ mare de dispozitive care utilizează o anumită versiune de Android. În tabelul următor este prezentata distribuția versiunilor de Android.

Tabel I-4. Distribuția versiunilor de Android.

Graficul următor arată cum este distribuit sistemul Android în toate versiunile sale lansate până acum.

Figura I-4. Distribuția versiunilor de Android.

Se poate observa din tabelul I-4 și figura I-4 că există o fragmentare software în ecosistemul Android. La această fragmentare au contribuit următoarele aspecte: dispozitivele noi cu versiuni mai vechi ale sistemului de operare si actualizările sistemelor de operare oficiale întârziate să apară sau care nu au mai apărut deloc după 2 ani de la apariția dispozitivului mobil.

Deoarece Android este un sistem de operare de tip open source, orice producător de telefoane mobile poate să folosească acest sistem de operare iar producătorii (Samsung sau HTC) au implementat versiuni modificate de Android, care sunt greu de actualizat.

Pentru producătorii de aplicații mobile fragmentarea mai sunt menționata reprezintă o problemă pentru că implică un efort mai mare în dezvoltarea aplicațiilor. Google pune la dispoziție biblioteca numită „Android Suport Library” care dă posibilitatea integrării ultimelor funcționalității majore într-o aplicație care să fie compatibilă și cu versiuni mai vechi ale sistemului de operare.

Se poate observa din figura I-5că există forte multe dispozitive cu Android de la diferiți producători.

Figura I-5. Dispozitive cu Android.

Sistemul de operare Android rulează pe sute de tipuri de telefoane și tablete de la zeci de producători, cu o combinație aproape infinită de configurații. Pentru dezvoltatori este practic imposibil să dezvolte o aplicație compatibilă cu toate dispozitivele cu Android.

Se preconizează că fragmentarea din Android va continua să existe si pe viitor, dar ar trebui să scadă cu câteva procente, deoarece Google a lansat versiunea KitKat pe 31 Octombrie 2013 care vine cu multe îmbunătățiri. A fost optimizat managementul memoriei pentru a fi suportate și de dispozitive cu resurse mai puține (de la 512Mb de memorie RAM) , de asemenea Google oferă o serie de documente care descriu cum se poate optimiza consumul de memorie a unei aplicații.

Elemente pro alegerii platformei Android:

Cota de piață – Android este liderul mondial de necontestat în industria de telefonie mobilă, peste 70% din utilizatorii de dispozitive mobile inteligente folosesc Android.

Limbajul de programare – Aplicațiile pentru sistemul de operare Android sunt scrise în limbajul bine cunoscut, Java.

Libertate (posibilități) – Android oferă cea mai mare libertate (posibilități) pentru realizarea unei aplicații mobile.

Integrare cu Google – Integrare facilă (ușoară) cu serviciile Google.

Testare și distribuire – Aplicațiile Android pot fi distribuite și testate pe orice dispozitiv cu Android, nu există limitări la distribuire ca la celelalte platforme mobile.

Publicarea aplicațiilor – Aplicațiile sunt publicate în scurt timp pe market, deoarece nu presupune un proces de verificare amplu al aplicației comparativ cu AppStore.

Costul de publicare – Pentru a publica pe Google Play, este nevoie de un cont de developer care costă 25 de dolari, iar venitul din vânzarea unei aplicații plătite se împarte în 70% pentru dezvoltatori și 30% reținut de Google pentru costurile operaționale.

Android este o platformă open-source care permite dezvoltatorilor să utilizeze instrumente de la terți pentru a optimiza aplicațiile lor. Accesul la codul sursă ajută dezvoltatorii să integreze aplicațiile lor cu ușurință în ecosistemul Android. Dezvoltatorii au posibilitatea de a crea versiuni modificate ale sistemului de operare.

Google oferă multe instrumente și o documentație generoasă și foarte bine pusă la punct, iar comunitatea online de dezvoltatori este foarte activă, cu foarte multe tutoriale și exemple disponibile gratuit.

Costurile de dezvoltare mici – O aplicație Android poate fi dezvoltată pe un calculator cu sisteme de operare Linux, care sunt gratuite, reducând costurile licențelor și a hardware-ului la minimum.

Faima – O aplicație pentru Android poate să aducă faimă unei companii.

Elemente contra alegerii platformei Android:

Natura open source a Android-ului aduce probleme de securitate ce permit apariția breșelor de securitate.

Țările din care se pot publica aplicații pe bani de către dezvoltatori sunt mult mai puține față de AppStore.

Veniturile aduse de Android sunt semnificativ mai mici decât cele aduse de iOS.

Fragmentarea existentă duce la un efort mai mare din partea echipei de dezvoltare.

Platforma iOS

Platforma iOS (anterior numit iPhone OS) este un sistem de operare bazată pe nucleul Linux pentru dispozitive mobile și este dezvoltat de compania Apple. Aplicațiile pentru iOS sunt scrise in limbajul Objective-C, C++, Swift .La momentul actual se afla pe locul doi privind cota de piață, dar se află pe primul loc la veniturile aduse dezvoltatorilor. În graficul următor se prezintă cum sunt distribuite toate versiunile sistemului de operare iOS lansate până acum.

Figura I-6. Distribuția versiunilor de iOS.

Se poate observa pe baza graficul de mai sus că nu prea există o fragmentare a sistemului de operare iOS. Pentru dezvoltatori acest lucru este un beneficiu deoarece pot să folosească ultimele noutăți ale sistemului de operare.

Elemente pro alegerii platformei iOS:

Aplicații pe bani – AppStore oferă posibilitatea de a publica aplicații plătite de către dezvoltatori din foarte multe țări.

Veniturile aduse :AppStore se află pe primul loc la veniturile aduse dezvoltatorilor , utilizatorii iOS sunt mult mai dispuși să cheltuie bani decât omologii lor de pe Android sau Windows Phone.

Faima – O aplicație pentru iOS poate să aducă faimă dezvoltatorului (companiei).

Apple oferă multe instrumente pentru crearea unei aplicații.

Pentru că nu sunt așa multe modele cu iOS, se pot optimiza mai ușor aplicațiile dar cu ultima versiune iOS 7 care aduce multe modificări programatorii au mai mult de lucrat pentru a optimiza aplicația.

iOS este un sistem de operare închis, ceea ce îl face mult mai sigur și mai puțin predispus la malware (amenințări).

Apple este una dintre cele mai recunoscute branduri din lume și utilizatorii sunt foarte loiali.

Elemente contra alegerii platformei iOS:

Ecosistemul închis descurajează utilizarea de instrumente 3rd-party pentru optimizarea aplicațiilor, programatorul este limitat la posibilitățile oferite.

Publicarea pe AppStore necesită un proces de revizuire strict, care poate să dureze destul de mult și poate să ducă la amânarea lansării produsului pe piață.

Cota de piață – Se află pe locul doi după Android având cota de piață de 13% și în ultimul an a fost într-o ușoară scădere.

Dezvoltarea de aplicații pentru iOS 7 și versiuni mai vechi este o investiție costisitoare.

Testarea și distribuirea – Programatorul este limitat în distribuirea aplicației pentru testare. Se pot distribui aplicații pentru testare numai prin serviciul TestFlight.

Platforma Windows Phone

Windows Phone este un sistem de operare pentru dispozitive mobile dezvoltat de Microsoft și este succesorul platformei Windows Mobile. Aplicațiile sunt scrise in C#, VB.NET si C++. La momentul actual este poziționat pe locul 3 si deține o cotă de piață de 5-6%. Se estimează că pe viitor popularitatea lui va crește.

Graficul de mai jos arată cum este distribuit sistemul de operare Windows Phone.

Figura I-7. Distribuția versiunilor de Windows Phone.

Windows Phone are două versiuni majore, Windows Phone 7 și Windows Phone 8, Windows Phone 8 este o nouă generație a sistemului de operare care aduce foarte multe îmbunătățiri și înlocuiește arhitectura anterioară Windows CE cu o arhitectură bazată pe Kernel-ul NT.

Elemente pro alegerii platformei Windows Phone:

Dobândirea cunoștințelor necesare pentru un programator obișnuit cu tehnologiile Microsoft și limbajul C# la Windows Phone este facilă.

Microsoft oferă multe instrumente pentru crearea unei aplicații.

Numărul de aplicații disponibile – Deoarece numărul de aplicații existente este mai mic în comparație cu celelalte platforme concurente, este mai ușor de a intra pe piață.

Windows Phone este în creștere în mai multe zone de pe glob (Europa, Asia, etc.).

Windows Phone este un sistem de operare închis, ceea ce face mult mai sigur și mai puțin predispus la malware (amenințări).

Elemente contra alegerii platformei Windows Phone:

Ecosistemul închis descurajează utilizarea de instrumente 3rd-party pentru optimizarea aplicațiilor, programatorul este limitat destul de mult la posibilitățile oferite.

Realizarea aplicațiilor care să suporte ambele versiuni de Windows Phone este mult mai complicată decât în alte platforme mobile.

Cota de piață: Cota de piață pentru Windows Phone este 3-4 % la mare distanță de Android și iOS, dar este în continuă creștere și se află pe locul 3.

Dezvoltatorii au raportat suport tehnic sărac de la Microsoft în timpul dezvoltării.

Veniturile aduse și faima: Deoarece are o cota de piața de numai 3-4%, veniturile și faima de o aplicație pentru această platformă pot sa fie mult mai mici față de celelalte platforme.

Dispozitive – Nu sunt multe tipuri de dispozitive mobile cu acest sistem de operare, dar în ultima perioadă sunt în creștere (oferirea gratuită a sistemului de operare a dus la creșterea numărului de dispozitive).

Testarea si distribuirea – Programatorul este limitat în distribuirea aplicației pentru testare.

În concluzie, sistemele de operare care trebuie luate în considerare la crearea unei aplicații mobile sunt Android, iOS și Windows Phone, fiecare cu avantajele și respectiv dezavantajele prezentate mai sus.

Soluții pentru aplicații utilizate pe dispozitive mobile

Contextul actual

Având în vedere dinamica aplicațiilor pe dispozitivele mobile precum și multitudinea de dispozitive și sisteme de operare utilizate în momentul actual, s-a constatat că nu există o soluție universal valabilă în ceea ce privește dezvoltarea de aplicații.

Pentru alegerea unei soluții optime se vor lua în considerare următoarele elemente: avantajele și dezavantajele abordărilor existente la momentul respectiv; principalii jucători de pe piață; așteptările clienților; nevoile și nivelul programatorilor.

În ceea ce privește așteptările clienților, soluția propusă este privită prin prisma următoarelor criterii: costuri reduse, flexibilitate, întreținere ușoară și dezvoltare rapidă.

Clienții sunt întotdeauna interesați să obțină o valoare cât mai mare pentru prețul pe care îl plătesc. Totodată își doresc să nu se facă rabat de la calitate, iar produsul să fie disponibil pe piață într-un timp cât mai scurt.

În plus, se urmărește ca eventualele îmbunătățiri ale sistemelor de operare sau apariția unor dispozitive mai performante, cu mai multe opțiuni hardware, să afecteze cât mai puțin produsul software existent. Pe scurt, se urmărește o întreținere ușoară a produsului software. Mai mult decât atât, flexibilitatea este dorită pentru ca extinderea ulterioară a produsului cu noi caracteristici să se petreacă într-o manieră cât mai simplă și rapidă.

În schimb, cei implicați direct în dezvoltarea aplicațiilor (programatorii) sunt mai degrabă interesați de: control complet asupra codului, eleganță în dezvoltare, creștere profesională.

Programatorii sunt interesați să aibă un control cât mai complet al codului sursă, vor fi reticenți la acele unelte care generează automat cod și care nu sunt suficient de flexibile pentru a oferi posibilitatea unor eventuale modificări. Alegerea unei soluții tehnice care nu oferă posibilitatea de a învăța și experimenta lucruri noi, duce la o anumită rodare rezultând invariabil o dorință a programatorilor de a părăsi proiectul.

Abordări posibile în dezvoltarea aplicațiilor mobile ce trebuie luate în considerare:

Aplicații native (cod nativ)

Aplicații hibride (cod portabil interpretat/Cod hibrid)

Aplicații native prin cod portabil cu compilare multi-platformă (cod portabil cu compilare multi-platformă)

Soluții posibile de implementare

Aplicații native

Aplicațiile native sunt scrise în limbajul de programare specific platformei și reprezintă varianta cea mai recomandată ce oferă aplicații rapide, interactive și de bună calitate.

În tabelul II-1 sunt prezentate cele mai importante sisteme de operare mobile împreună cu limbajul de programare folosit și platforma de dezvoltare.

Tabel II-1. Sistemele de operare mobile cu caracteristicile lor.

O aplicație nativă este dezvoltată folosind limbajul de programare și API-uri pentru o anumită platformă. Dezvoltatorul are acces deplin la sistemul de operare al dispozitivului, senzori și primitivele interfeței cu utilizatorul.

Pentru realizarea aplicațiilor native sunt necesare cunoștințe avansate de programare a platformei respective. Fiecare platformă mobilă de obicei folosește alte limbaje de programare și cadre de dezvoltare, de aceea este foarte dificilă obținerea competențelor necesare pentru a sprijini o gamă largă de platforme eterogene.

În figura II-1 sunt prezentate schematic pașii prin care trece o aplicație pornind de la specificații până la dezvoltarea de aplicații corespunzătoare mai multor platforme mobile distincte.

Figura II-1. Dezvoltarea și instalarea aplicațiilor folosind cod nativ.

Marii producători de sisteme de operare mobile sunt tot mai preocupați pe îmbunătățirea mediilor de dezvoltare și a șabloanelor de lucru, pentru a atrage de partea lor cât mai mulți dezvoltatori. Pentru dezvoltatori acest lucru este benefic deoarece micșorează munca necesară pentru realizarea aplicațiilor, astfel dezvoltatorii o să aibă mai mult timp care poate fi folosit în finisarea produsului sau în alte proiecte.

Aplicațiile native trebuie să respecte regulile de dezvoltare specifice platformei pentru care este destinată. Nu se recomandă folosirea resurselor grafice: butoane, icoane, fundaluri, etc. pentru mai mult de o platformă. Aplicațiile native trebuie să păstreze comportamentul și designul sistemului de operare pe care rulează. Acestea trebuie să se integreze în platforma aleasă de utilizatorul final.

Dezvoltatorul în această abordare are frâu liber imaginației fiind limitat doar de resursele dispozitivului pe care aplicația va rula.

În figura de mai jos este prezentată interfața aplicației Viber pe platformele Android cât și pe iOS.

Figura Interfața aplicației Viber pentru Android și iOS.

În tabelul de mai jos 6 se prezintă analiza SWOT pentru a alege folosirea codului nativ.

Tabel II-2. analiza SWOT pentru a alege folosirea codului nativ.

Aplicațiile native pot aduce utilizatori noi și fidelizează pe cei anteriori. Majoritatea brand-urilor mari din lume (Facebook, Twitter, LinkedIn, etc.) au ales această opțiune deoarece și-au dat seama că oferă foarte multe beneficii si că atrage utilizatori.

Aplicații hibride

Aplicațiile mobile hibride (Cod hibriCod portabil interpretat) sunt aplicații care sunt dezvoltate folosind tehnologii WEB cum ar fi JavaScript, HTML și CSS.

În tabelul II-3 de mai jos se prezintă cele mai folosite medii de dezvoltare ale aplicațiilor hibride:

Tabel II-3. Cele mai folosite medii de dezvoltare ale aplicațiilor hibride.

Aplicațiile hibride de regulă sunt formate din două părți:

componentă nativă, specifică fiecărui platforme, ce conține în esență instanța unui browser modificat astfel încât să aibă acces la resursele hardware ale dispozitivului (ex. camera video, lista de contacte, etc.) și care accesează aplicația web;

aplicație web – HTML5, CSS, JavaScript, etc. – capabilă să ruleze în orice browser.

În figura II-2 se reprezintă schematic pașii pornind de la specificații și până la dezvoltarea de aplicații hibride corespunzătoare mai multor platforme mobile distincte.

Figura II-2. Dezvoltarea și instalarea aplicațiilor folosind cod hibrid / cod portabil interpretat.

Aplicațiile hibride în ultima perioada încep să prindă rădăcini tot mai puternice datorită faptului că multe medii de dezvoltare devin tot mai stabile și oferă acces la mai multe funcționalități hardware ale dispozitivelor.

Realizarea interfeței aplicațiile hibride cât mai fidelă platformei pe care rulează implică un efort major din partea programatorului din lipsa controalelor native. De aceea, de regulă, aplicațiile hibride au același design grafic pe toate platformele pe care au fost publicate fără să țină cont de ghidul de implementare și care duce la pierderea utilizatorilor.

Avantajul major acestei abordări este aceea că trebuie scrisă numai o singură aplicație care va putea rula pe mai multe platforme. Din această cauză aplicațiile sunt dezvoltate într-un timp mult mai scurt decât în cazul celorlalte soluții.

În figura de mai jos este prezentată interfața aplicației „Școala Auto” pe platforma Android și pe iOS care este scrisă în cod hibrid.

Figura II-3. Exemplu de aplicație realizată pin cod hibrid.

Datorită faptului că majoritatea uneltelor de dezvoltare folosesc tehnologiile web pentru implementarea aplicației, găsirea unui programator este foarte facilă deoarece există foarte mulți programatori ce au cunoștințe web.

În tabelul II-4 este prezentată analiza SWOT privind alegerea codului hibrid.

Tabel II-4 analiza SWOT pentru a alege folosirea codului hibrid.

Aplicații native prin cod portabil compilat.

A treia abordare presupune de asemenea folosirea unui cod comun, dar și al unui compilator care să știe să interpreteze acest cod și să îl compileze generând cod nativ pentru fiecare platformă în parte.

În figura II-4 se reprezintă schematic pașii parcurși pornind de la specificații și până la dezvoltarea de aplicații corespunzătoare mai multor platforme mobile distincte.

Figura II-4. Dezvoltarea și instalarea aplicațiilor folosind cod portabil compilat.

Instrumentele și limbajele de programare utilizate sunt prezentate în tabelul II-5:

Tabel II-5 Cadre de dezvoltare pentru cod portabil compilat.

În tabelul II-6 se prezintă analiza SWOT pentru alegerea codului portabil compilat.

Tabel II-6. analiza SWOT pentru alegerea codului portabil compilat.

Avantajele și dezavantajele acestei abordări reprezintă o combinație a celor două direcții de dezvoltare a aplicațiilor mobile anterior menționate.

Alegerea soluției optime

Toate cele 3 modalități care au fost prezentate pot fi folosite pentru dezvoltarea aplicațiilor pentru dispozitivele mobile. Important este să se decidă dacă aplicația trebuie să fie bogată din punct de vedere al funcționalităților, dacă se dorește publicarea aplicației pe mai multe platforme sau cât de mare este bugetul alocat dezvoltării aplicației respective.

Alegeți dezvoltarea nativă a aplicației dacă timpul de dezvoltare și implicit bugetul nu sunt mici. Această opțiune poate aduce utilizatori fideli pe termen lung, comentarii pozitive și faima. În același timp vă ajută să distribuiți clienților versiuni ale aplicației care pot rula pe cele mai noi versiuni ale sistemelor de operare încă de la lansarea acestora.

Alegeți dezvoltarea hibridă a aplicației dacă timpul de dezvoltare și bugetul sunt mici iar complexitatea aplicației este mai redusă. Această opțiune de dezvoltare se potrivește foarte bine și dacă doriți să experimentați o idee nouă de aplicație. Aplicațiile hibride sunt foarte bune pentru un start-up, acestea vă ajută să acaparați atenție pe mai multe platforme cu un minim de efort.

Alegeți dezvoltarea hibridă prin cod portabil compilat a aplicației dacă nu aveți în echipă programatori specializați pentru fiecare platformă în parte, dar aveți programatori care știu un limbaj de programare cunoscut cum ar fi C# ,Ruby, HTML. Se alege această abordare dacă doriți să creați o aplicație nativă și aveți un buget alocat mai mare decât în cazul aplicațiilor hibride.

În tabelul II-7 se prezintă comparația între cele 3 soluții.

Tabel II-7. Comparația între cele 3 abordări posibile pentru realizarea unei aplicații mobile.

În concluzie vom alege aplicația nativă când:

aplicația este destul de complexă și necesită acces la resursele dispozitivului și a sistemului de operare;

contează foarte mult performanța;

se dorește ca aplicația sa aibă o interfață cât mai specifică platformei.

În concluzie vom alege aplicație hibridă (codul portabil) când:

vorbim despre o aplicație relativ simplă;

aplicația nu accesează multe dintre resursele dispozitivului;

se așteaptă multe îmbunătățiri cu implementare rapidă în viitorul apropiat;

avem la dispoziție un buget redus;

se dorește lansarea simultană pe toate magazinele de aplicații.

În concluzie vom alege aplicații hibride prin cod portabil compilat când:

se dorește lansarea simultană pe toate magazinele de aplicații;

timpul dedicat dezvoltării este mai scurt și există un termen limită destul de scurt;

nu avem programatori specializați pentru fiecare platformă în parte.

Proiectarea aplicațiilor pentru dispozitive mobile

Concepte de design a interfețelor

Design-ul este unul dintre elementele principale ale unei aplicații. Un design reușit poate sa aducă și să fidelizeze mulți utilizatori. Scopul este de a crea o aplicație utilă, ușor de folosit, și stabilă.

Pentru realizarea unei aplicații mobile se recomandă prealabil realizarea unui concept. Pe baza conceptului se realizează mult mai ușor aplicația și pe baza lui se realizează primele schițe ale interfeței aplicației.

Design-ul este un factor important în succesul unei aplicații mobile, atât în modul în care utilizatorul interacționează cu aceasta (cât mai ușor, intuitiv și comod), cât și în modul în care este organizată informația, viteza de acces la informație, și terminând cu partea pur vizuală.

Elemente principale de design

Se prezinte în rândurile de mai jos principale elemente pentru un design reușit.

Logo-ul (Icon) aplicației este primul element care reprezintă aplicația, felul în care este realizat poate face diferența între succes și eșec pe piață (a instala sau nu aplicația). Forma, culoarea, logo-ul formează un conglomerat de forme, emoții și înțelesuri care pot foarte bine să esențializeze ceea ce înseamnă și se vrea să fie aplicația. Poate să sugereze funcția ei, cui i se adresează, cât de bine este făcută prin aceste elemente simple. Aici intervine creativitatea designerului care reușește să împacheteze toate aceste lucruri într-o formă și culori simple, dar înțelese și cu impact vizual care respectă regulile de pe fiecare platformă. El se va regăsi în aplicație sub alte forme în interfața utilizatorului, dar fără să obosească sau să încurce pe utilizator în utilizarea aplicației.

Identitatea aplicației trebuie reprezentată în interfața aplicației într-un mod non-obstructiv, astfel încât utilizatorii să nu fie deranjați în interacțiunea cu aplicația și ea poate fi prezentă în fundalul aplicației, culorile aplicației, culorile controalelor în imagini, în amplasarea elementelor pe ecran, în ecran de introducere(intro) sau în alte elemente grafice ale aplicației.

Culorile trebuie alese cu mare grijă în așa fel încât să existe contrast între ele și interfața să fie cât mai simplă și aerisită ca utilizatorul să nu aibă o experiență obositoare din cauza încărcării interfeței. Elementele grafice folosite în interfață aplicației trebuie să aibă o rezoluție ridicată pentru ca utilizatorul să aibă experiența vizuală foarte plăcută.

Butoanele din aplicație trebuie să fie suficient de mari, la fel și distanțate între ele, pentru a permite o interacțiune fără erori. Se recomandă ca elementele ce pot fi apăsate să aibă o dimensiune mai mare 7 mm (48dp la Android; 48 px și 95px la iOS). În figura de mai jos este exemplificat acest lucru.

Figura III-1. Dimensiune minimă recomandată pentru butoane.

Este foarte important ca dimensiunea textului să fie destul de mare încât utilizatorul să poată citi cu ușurință textul. Fonturile aplicației trebuie alese în concordanță cu designul aplicației. De asemenea este indicat ca fonturile mai decorative sau mai minimale care sunt greu de citit, să fie folosite la titluri sau capitole. Iar pentru texte se recomandă folosirea fonturilor lizibile pentru ca utilizatorul să poată citi cu ușurință informațiile oferite.

Pentru realizarea unui design cât mai reușit se recomandă studierea aplicațiilor concurente.

În funcție de conținutul și tipul aplicației se va realiza scenariul de utilizare. Unele aplicații au scenarii mai simple, ca de exemplu o aplicație de PDF va avea un singur ecran în care este prezentată întreaga informație. Alte aplicații au scenarii mult mai complexe în care utilizatorul navighează prin multe ecrane. Pentru a realiza si prezenta cât mai ușor scenariul se folosesc wireframe-uri pentru a evidenția cât mai bine detaliile.

Designul din aplicație pentru fiecare ecran trebuie să fie cât mai unitar ca utilizatorul să poată învăța cat mai repede să folosească aplicația. De exemplu, dacă se schimbă culoarea unui buton de la un ecran la altul, această schimbare trebuie să fie foarte justificată și trebuie luat în calcul impactul pe care l-ar avea asupra utilizatorilor, dacă vor înțelege semnificația schimbării sau nu.

Merită acordat timp pentru studierea pieței și a altor aplicații ce sunt asemănătoare cu cea pe care vreți să o realizați și prin părerile utilizatorilor despre o astfel de aplicație se pot trage concluzii care pot fi valorificate în aplicația dumneavoastră.

Interfața cu utilizatorul trebuie să fie cât mai simplă și intuitivă. Să nu fie încărcată cu foarte multe stiluri sau culori ce ar putea întârzia utilizatorul să ajungă la informația dorită, de asemenea nivelul de adâncime din aplicație nu trebuie să depășească 4-5 nivele.

Aplicațiile ca LinkedIn, Twitter, Google+, Google Play etc. au făcut multe schimbări în designul lor pentru a crea o aplicație cu navigare cât mai rapidă, care permite utilizatorului să aibă acces ușor la toate secțiunile aplicației.

Pentru a avea o interfață cât mai simplă și intuitivă, se pot folosi diferite elemente de interfață: meniuri simple sau de tip slide, dashboard, controlul de tab, bară de acțiuni (bara de navigare), meniuri de tip pop-up, etc.

Meniurile de tip slide (meniuri laterale) ajută la navigarea cât mai rapidă între categoriile principale ale aplicației. Se prezintă în figura de mai jos un meniu de tip slide din Android (Navigation Drawer).

Figura 1. Navigation Drawer – meniul de tip slide din Android.

Controlul de tab împarte informația în mai multe categorii și astfel utilizatorul poate ajunge mai repede la informația dorită.

Figura III-2. Controlul de tab din Android, iOS și Windows Phone.

Bara de acțiuni (bara de navigare) oferă funcții de navigare și posibilitatea de a avea acțiuni rapide. Fiecare platformă are implementări diferite și de aceea trebuie regândită întreaga structură și refăcut designul.

Figura III-3. Bara de navigare iOS și bara de acțiuni Android.

Elementele de interfață prezentate mai sus sunt câteva elemente care se pot folosi pentru a realiza o interfață simplă și intuitivă, dar există multe alte elemente de interfață și concepte care se pot folosi.

Designul aplicației trebuie să respecte regulile de dezvoltare specifice platformei pentru care este destinată. Nu se recomandă folosirea resurselor grafice: butoane, icoane, fundaluri, etc. pentru mai mult de o platformă. Aplicațiile native trebuie să păstreze comportamentul și designul sistemului de operare pe care rulează. Acestea trebuie să se integreze în platforma aleasă de utilizatorul final.

Utilizând aceleași resurse grafice (componente de interfață) pentru mai multe platforme utilizatori finali ai aplicației vor fi iritați, deoarece ei sunt obișnuiți cu elementele specifice ale platformei pe care o folosesc și este foarte posibil ca mulți utilizatori să renunțe la aplicație.

În figura de mai jos sunt prezentate diferențele dintre elementele de interfață din diferite platforme mobile.

Figura III-4. Exemple de elemente de interfața de pe Android, iOS și Windows Phone.

Realizarea unei aplicații mobile pentru mai multe platforme mobile implică un efort major din partea echipei de dezvoltare deoarece sunt necesare redefinirea designului și implementarea lui pentru fiecare platformă în parte care uneori implică și modificarea scenariul aplicației. Dar efortul implicat merită pentru ca utilizatorii să adopte ușor aplicația.

Designul grafic pentru ambele orientări

Este important să se realizeze designul pentru ambele orientări spre folosirea cât mai eficientă a spațiului oferit.

Există diferite abordări care pot fi folosite pentru optimizarea designului ambelor orientări. În rândurile următoare sunt prezentate cele mai cunoscute abordări care pot fi folosite pentru a realiza interfața landscape.

Stretching

Această abordare este cea mai simplă soluție care implică extinderea elementelor grafice pe toată lungimea ecranului, dar duce la irosirea spațiului disponibil.

În figura de mai jos este exemplificată această abordare.

Figura III-5. Abordarea stretching.

Avantajul major al acestei abordări este că implică un efort mic pentru a adapta interfața la modul landscape. Pentru unele dispozitive aceasta abordare nu este cea mai bună, deoarece în cazul listelor sau altor elemente zona de derulare poate să fie mică și utilizatorul va fi nevoit să deruleze foarte mult pentru a ajunge la o informație dorită. O soluție pentru a rezolva această experiență neplăcută este folosirea unui control de tip grid în locul unei liste simple și în funcție de orientare să prezinte informația pe o singură coloană sau pe mai multe.

Zoom (Mărire)

O altă abordare este principiul folosit de aplicația YouTube Android, care modifică interfața în funcție de orientarea telefonului. Aceasta afișează mai multe informații în mod portrait, iar în mod landscape prezintă numai informația cea mai importantă, videoclipul.

În figura de mai jos este exemplificată această abordare:

Figura III-6. Abordarea zoom

Această abordare este utilă în special pentru aplicații cu conținut media (video, muzică, reviste sau altele) și în funcție de orientarea dispozitivului se vor prezenta mai multe sau mai puține informații legate de conținutul principal.

Fluid

A treia abordare implică rearanjarea elementelor în funcție de orientarea ecranului.

În figura de mai jos este prezentată această abordare.

Figura III-7. Abordarea fluid

Din figura 18. se poate observa că poziția elementelor principale se schimbă în funcție de orientare. În mod portrait ele sunt afișate într-o grilă de 4 × 4, iar în mod landscape simbolurile grafice (icons) sunt aranjate într-un rând de 4 × 1, astfel că în ambele orientări posibile ele sunt vizibile fără a fi nevoie de scroll (derulare).

Această abordare implică un efort mai mare pentru că trebuie realizată interfața pentru ambele orientări dar utilizatorul aplicației va avea la dispoziție o interfața mult mai ușor de folosit.

Design grafic optimizat pentru tablete

Este important ca interfața unei aplicații mobile să fie adaptată pentru dispozitive cu ecran mai mare, cum sunt tabletele, și se recomandă folosirea întregului spațiu oferit de aceste dispozitive.

Cea mai simplă soluție pentru adaptarea interfeței la dispozitive cu ecran mai mare este folosirea principiului prezentat mai sus, „Stretching”, care presupune extinderea elementelor grafice pe toată lungimea ecranului.

O altă abordare este redefinirea interfeței prin împărțirea layout-ului în panouri mai mici, tehnică numită „multi-panel”. Această tehnică duce la eficientizarea spațiului folosit.

În funcție de dimensiunea, orientarea ecranului și informația dorită se pot folosi mai multe panouri în care să fie afișată informația. În figura următoare sunt prezentate câteva strategii pe care cei de la Android le propun pentru aranjarea elementelor pe tablete.

Figura III-8. Strategii de design pentru tablete.

Principiul „multi-panel” prezentat mai sus ușurează crearea interfeței și pentru tablete, deoarece se pot refolosi ecranele implementate pentru versiunea de telefon și în acest caz fiecare ecran va fi afișat într-un panou al interfeței.

Wireframe-uri și prototipuri

Un wireframe este o schița a viitorului proiect creat cu scopul de a prezenta vizual structura acestuia. Este o reprezentare schematică a interfeței. Scopul wireframe-urilor este acela de a prezenta funcționalitățile și conceptul aplicației. Ușurează munca designer-ului și a programatorilor deoarece pot vizualiza imediat schița și astfel se economisește mult timp.

Wireframe-urile se pot face cu pixul pe foaie sau folosind anumite unelte specifice (programe specializate). Schița pe foaie poate să fie punctul de plecare la definirea designului (conceptului). Schițele realizate astfel sunt mai ușor de modificat, însă folosind aplicații specializate, se realizează schițe mult mai complexe care pot fi transformate în prototipuri.

Cea mai bună modalitate de a vizualiza și a evalua interacțiunea aplicației este prototipul. Având prototipul aplicației, se poate prezenta și discuta conceptul cu alții. Pentru realizarea prototipului se pot folosi instrumente specializate sau desenarea pe hârtie.

În figura de mai jos este prezentată schița interfeței unei aplicații realizate pe foaie.

Figura III-9. Schița unei aplicații mobile.

Aplicații pentru wireframe-uri și prototipuri

Se prezintă în rândurile de mai jos instrumente pentru realizarea wireframe-urilor și prototipurilor.

1 Fluid UI:

Este un instrument online în care se pot realiza prototipuri interactive pentru toate cele mai utilizate platforme mobile și desktop (iOS, Android, Windows și aplicații Web). Aplicația oferă multe elemente de interfață prin care se poate realiza schița aplicației destul de fidelă pentru fiecare platformă. Există posibilitatea de a partaja schița cu alte persoane. Costul acestei aplicații este de la 12$ pe lună, dar există și versiune gratuită în care se pot face maxim 10 proiecte.

În figura de mai jos este prezentat un prototip realizat în Fluid UI.

Figura III-10. Prototip realizat în Fluid UI.

2. Indigo-Studio

Este o aplicație desktop în care se pot realiza repede și simplu prototipuri interactive pentru toate cele mai utilizate platforme mobile (iOS ,Android, Windows). Aplicația oferă posibilitatea de a crea prototipuri complet funcționale. Costul acestei aplicații este de la 24$ pe lună, dar există și versiune de încercare pentru 15 zile.

În figura de mai jos este prezentat un prototip realizat în Aplicația Indigo-Studio.

Figura III-11. Prototip realizat în Aplicația Indigo-Studio.

3. NinjaMock

Este un instrument online gratuit în care se pot realiza prototipuri simple pentru platformele mobile și oferă posibilitatea de a colabora cu alți utilizatori.

În figura de mai jos este prezentat un prototip realizat în aplicația NinjaMock.

Figura III-12. Prototip realizat în aplicația NinjaMock.

4. POP – Prototyping on Paper

POP este o aplicație pentru iOS și Android care permite transformarea schițelor de pe foaie în prototipuri interactive. Introducerea schițelor în aplicație se realizează foarte simplu prin fotografierea fiecărei schițe și ulterior se poate adăuga interacțiune la fiecare schiță.

Astfel, se poate crea rapid un prototip funcțional de la simple schițe realizate pe foaie care pot fi testate. Testarea este foarte importantă pentru că putem încerca experiența de utilizare, astfel se pot găsi din timp probleme și se pot corecta.

În figura de mai jos este prezentat un prototip realizat în aplicația POP.

Figura III-13. Prototip realizat în aplicația POP.

Verificarea designului de către utilizatori

Pentru a realiza un design reușit este foarte importantă părerea utilizatorilor. Este necesară părerea lor despre design cât mai repede posibil, astfel se vor putea face corecții din timp.

Pentru a realiza un design cât mai reușit se recomandă evitarea următoarelor greșeli:

– Depășirea bugetului pentru dezvoltare;

– Animații care nu sunt necesare;

– Încărcarea ecranului;

– Imaginile de slabă calitate;

– Copierea design-ului (elementelor grafice) de la alte sisteme de operare;

– Complicarea exagerată a aplicației.

În concluzie, pentru realizarea designului cât mai reușit este nevoie de creerea în primul rând a conceptului. Pe baza lui și prin respectarea regulilor specifice fiecărei platforme se va realiza designul aplicației.

Metodologii de dezvoltare a aplicațiilor

Dezvoltarea software este un proces complex de realizare a soluțiilor pornind de la un set specific de cerințe. Pentru ușurarea dezvoltării și managementul aplicaților s-au creat diferite metodologii de dezvoltare .

O metodologie de dezvoltare reprezintă o platformă folosită pentru a structura, planifica și controla procesul de dezvoltare a unui sistem informatic.

Există multe metodologii de dezvoltare a sistemelor, și fiecare dintre ele este unică în funcție de ordinea și importanța fiecărei faze din ciclul de dezvoltare. Unele metodologii reprezintă standarde formale folosite de agenții guvernamentale, în timp ce altele au fost dezvoltate de firme de consultanță pentru a fi vândute clienților. Multe organizații au metodologiile lor interne care au fost rafinate de-a lungul anilor.

Principalele metodologii de dezvoltare a sistemelor informatice pentru dispozitive mobile sunt reprezentate de: programarea extremă, SCRUM și Rational Unified Process.

Rational Unified Process (RUP)

Rational Unified Process (RUP) este o metodologie iterativă de dezvoltare software și este o implementare concretă a Unified Process creat de Rational Software și dezvoltat de IBM după preluarea acestei companii. În figura următoare sunt prezentate fazele fiecărei activități în cadrul RUP.

Figura III-14: Activitățile în cadrul RUP.

Rational Unified Process definește următoarele activități fundamentale:

Modelarea afacerii (Business Modeling) – Obiectivul acestui proces este de a aduna și înțelege cerințele de afacerii ale organizației, de a identifica problema pe care proiectul încearcă sa o rezolve și de a identifica o soluție software viabilă pentru această problemă;

Cerințe (Requirements) – Se definesc după specificațiile clientului;

Analiză și proiectare (Analysis & Design) – În funcție de cerințele proiectului se realizează arhitectura sistemului;

Implementare (Implementation) – Se creează programul în conformitate cu arhitectura aleasă astfel încât comportamentul acestuia să fie apropiat de cel dorit;

Testare (Test) – Obiectivul acestui proces este de a evalua și de a asigura calitatea soluției software. Aceasta include găsirea defectelor, validarea că sistemul software funcționează conform specificaților și verificarea că cerințele sunt satisfăcute;

Instalare (Deployment) – Se efectuează activitățile necesare punerii în funcțiune a programului.

Aceste activități nu sunt separate în timp. Aici ele sunt executate în paralel pe parcursul întregului proiect. După cum reiese din figura 1.4, cantitatea de cod scrisă la începutul proiectului este mică, dar nu egală cu zero. Pe măsură ce proiectul evoluează, cele mai multe dintre cerințe devin cunoscute, însă noi cerințe sunt identificate. Aceasta înseamnă că activitatea de cerințe se regăsește pe întreaga durată de viață a procesului, însă apare cu pregnanță la începutul acestuia.

Pe măsură ce procesul de dezvoltare evoluează, importanța anumitor activități scade sau crește. Este permis ca aceste activități să se execute în orice moment al dezvoltării.

Un proiect bazat pe RUP evoluează în anumiți pași numiți iterații. Scopul unei iterații este să dezvolte un program funcțional care să poată fi prezentat clientului, iar clientul să îl poată evalua.

Întinderea în timp a unei iterații depinde de tipul de proiect la care se lucrează, de experiența echipei, etc. Durata recomandată a unei iterații este de o săptămână sau două.

Se disting patru faze în RUP:

Concepție (Inception) – Obiectivul acestei faze este de a determina cerințele inițiale ale proiectului, identificarea soluțiilor tehnice posibile și stabilirea planului preliminar de dezvoltare;

Elaborare (Elaboration) – Pe parcursul acestei faze se stabilesc: soluția tehnică optimă, echipa de lucru, un plan detaliat pentru iterațiile următoare;

Construire (Construction) – Obiectivul acestei faze este implementarea aplicației, într-un mod incremental, adăugând treptat funcționalități noi;

Tranziție (Transition) – În cadrul acestei faze se adaugă ultimele funcționalități dorite la produsul software și la terminarea acestei faze produsul este instalat în mediul de producție, unde va fi utilizat de către utilizatorii finali.

Avantaje:

Este o metodologie completă cu accent pe o documentație amplă.

Clienții au abilitatea de a modifica cerințele din mers.

Timpul de dezvoltare este mai redus datorită faptului că elementele componente pot fi reutilizate.

Dezavantaje:

Membri echipei trebuie sa fie experți în domeniul lor pentru a concepe/dezvolta un software care să respecte această metodologie.

Procesul de dezvoltare este complex și greu de implementat.

În cazul proiectelor de ultima oră care utilizează tehnologii noi, reutilizarea componentelor nu se poate realiza.

Programarea extremă (XP)

Programarea extremă (Extreme Programming – XP) este o metodologie de dezvoltare software care are scopul de a îmbunătăți calitatea software-ul creat și de a răspunde la schimbarea cerințelor clientului. Este un tip de dezvoltare software care aparține de metodologia Agile.

Obiectivul XP vizează reducerea costurilor modificărilor cerințelor prin dezvoltarea incrementală.

Cele patru valori ale programării extreme sunt:

Comunicarea: Programarea Extremă încurajează comunicarea dintre membrii echipei și client în locul documentațiilor stufoase.

Simplitatea: Programarea Extremă încurajează plecarea de la soluții cât mai simple și refacerea lor în soluții mai bune în viitor.

Feedback-ul: Feedback-ul este foarte important, prin feedback-ul obținut se pot identifica din timp problemele din proiect și corectat din timp.

Curajul: Programatorii trebuie să aibă curajul să refactorizeze codul, sau chiar să renunțe la părți din cod și să reproiecteze arhitectura software dacă acest lucru devine necesar.

Programarea extremă este folosită în echipe de dimensiuni mici sau medii pentru o dezvoltare rapidă și eficientă, cu o durată și un cost predictibil.

Clientul observă progresul echipei prin intermediul unui soft funcțional primit la un interval de timp prestabilit. Astfel clientul poate să orienteze proiectul, să îl ghideze către nevoile și dorințele lui.

În figura următoare se prezintă etapele principale ale programării extreme.

Figura III-15. Etapele principale ale programării extreme.

Elementele principale ale Programării Extreme:

1) Planificare Extremă: Este cunoscută sub denumirea de Planning Game în care întreaga echipă și clientul se adună pentru a decide care sunt funcționalitățile care vor alcătui următoarea iterație (sprint).

2) Extreme Design: Urmează principiile privind simplitatea. Software-ul este conceput în cel mai simplu mod cu putință. Design-ul nu presupune un lucru pe care îl faci o singură dată, ci e un proces continuu.

3) Programare Extremă (Extreme Coding): Principalele practici privind programarea în XP sunt următoarele:

a) Programare în pereche – Doi programatori lucrează împreună pe un singur terminal și colaborează pentru elaborarea aceluiași algoritm sau program.

b) Implicarea clientului (Customer on site) – Clientul trebuie să fie disponibil pe toată durata proiectului.

c) Integrarea continuă (Continuous integration) – Programatorii trebuie să integreze codul și să îl pună într-un depozit de mai multe ori pe zi. Fiecare unitate trebuie testată înainte și după integrare.

4) Testare extremă (Extreme Testing) – În cadrul acestei abordări este foarte importantă testarea codului, care se realizează prin teste unitare.

Avantaje:

Soluție bună pentru proiecte mici.

Programare organizată.

Reducerea numărului de greșeli.

Clientul deține controlul.

Permite echipei să se adapteze rapid la schimbările (cerințelor) proiectului.

Oferă oportunitate de învățare pentru programatori.

Datorita feedback-ului constant, deficiențele sistemului sunt detectate în fază incipientă.

Dezavantaje:

Lipsește structura și documentația.

XP se bazează pe implicarea permanentă a clienților.

Necesită multă experiență în domeniu (programatorii seniori).

Greu de implementat (Tranziția către programarea extremă este foarte grea).

Poate deveni uneori o metodă ineficientă și poate să ducă la rescriere masivă de cod.

Poate să ducă la probleme de colaborare în echipă.

XP este centrat pe cod. Lipsa designului poate fi o problemă pentru proiectele de o dimensiune mai mare.

Din cauza lipsei de structură, poate fi dificilă găsirea defectelor în timpul testării.

SCRUM

SCRUM este o metodologie de dezvoltare software iterativ și incremental care are scopul de a îmbunătăți calitatea software-ului creat și de a răspunde la schimbarea cerințelor clientului. Este un tip de dezvoltare software care aparține de metodologia Agile.

În figura III-16 se reprezintă schematic arhitectura Scrum.

Figura III-16. Arhitectura Scrum[8].

Scrum este ideal pentru proiectele care au cerințe ce se schimbă rapid sau care apar urgent în timpul proiectării.

Metoda Scrum admite faptul că provocările fundamentale nu pot fi adresate tradițional – predictiv. În felul acesta, Scrum adoptă o abordare empirică, deci se acceptă faptul că problema nu se poate înțelege sau defini complet, așadar, se concentrează pe maximizarea abilității echipei de a livra rapid și a răspunde eficient la noi cerințe.

Roluri:

Product owner: este persona care este responsabilă de produsul realizat, coordonatorul echipei de dezvoltare și reprezintă legătura cu clientul. El este cel care definește și stabilește funcționalitățile prioritare și alege data și conținutul fiecărui sprint.

Scrum Master: facilitează buna desfășurare a proiectului, are grijă ca fiecare membru să poată lucra la capacitate maximă eliminând impedimentele și protejând echipa de perturbările exterioare. De asemenea, trebuie să se asigure că procesul de dezvoltare evoluează în conformitate cu tehnicile, valorile și regulile Scrum.

Echipa: este responsabilă cu dezvoltarea produsului; are autoritatea de a decide ce măsuri trebuie luate pentru a rezolva sarcina asociată fiecărui sprint și are dreptul de a se autoorganiza tot în același scop. În general o echipă Scrum este alcătuită din 5-10 persoane. Echipa este implicată în mod direct în procesul de analiză, design, implemnetare și testare și toate sarcinile trebuie duse la capăt corect de către membrii echipei.

Scrum necesită patru tipuri de ședințe:

Ședințele zilnice (Daily Meeting sau Daily Scrum): echipa se reunește în fiecare zi în timpul sprint-ului și petrece circa 15 minute, pentru a povesti statusul proiectului și se vor aduce la cunoștință problemele apărute.

Ședințele de planificare a sprint-ului: întreaga echipă se adună pentru a decide care sunt funcționalitățile care vor alcătui următorul sprint și pentru a actualiza Product Backlog.

Ședința de prezentare a rezultatelor (Sprint Review): în timpul acestei ședințe, echipa prezintă funcționalitățile realizate.

Retrospectiva sprint-ului (Sprint Retrospective): la finalul fiecărui sprint, echipa analizează aspectele care au funcționat bine, precum și pe cele care au funcționat mai puțin bine. În timpul acestei ședințe de 15–30 de minute, fiecare membru vorbește în nume propriu.

Elementele caracteristice metodei Scrum sunt:

Sprint:

Sprint-ul este o perioadă determinată de timp în care trebuie îndeplinită o listă de cerințe iar durata sa este cuprinsă între 1-4 săptămâni. Aceasta include etape de cerințe, analiză, design, dezvoltare, livrare. Echipa se organizează astfel încât să producă o nouă unitate funcțională a produsului la sfârșitul unui sprint.

În timpul Sprint-ului:

Nu se aduc modificări care ar putea afecta obiectivul Sprint-ului;

Componența echipei de dezvoltare rămâne constantă;

Se pot clarifica și renegocia cerințele din sprint-ul curent între Product Owner și echipa de dezvoltare.

Burn down

Este un grafic în care se prezintă progresul echipei din Sprint-ul curent și pe baza lui se poate observa munca rămasă până la terminarea sprint-ului. Este actualizat zilnic și ajută la estimarea datei la care va fi gata sprint-ul. Inițial se prezintă volumul total de muncă, acesta scăzând zilnic.

În figura III-17 este reprezentat un exemplu de Burn Down.

Figura III-17. Burn Down.

Product Backlog:

Product Backlog-ul este un document care descrie funcționalitatea dorită pentru produs și prioritățile pentru funcționalitatea respectivă. Backlog-ul este un document care va fi modificat constant de către product owner în cazul în care prioritățile sau funcționalitatea se schimbă sau este necesară o funcționalitate nouă.

În figura III-18 este prezentat un exemplu de document „product backlog”:

Figura III-18. Product backlog.

Sprint Backlog:

Sprint Backlog-ul este setul de cerințe (elemente) din Product Backlog care trebuie îndeplinite într-un sprint.

În figura III-19 este prezentat un exemplu de document sprint backlog:

Figura III-19. Exemplu de document sprint backlog.

Avantaje:

Încurajează lucrul în echipă, ajută pe oamenii noi din echipă să devină productivi cât mai repede și să înțeleagă proiectul.

Se concentrează pe funcționalități clare și se pot prevedea costurile viitoare.

Reducerea documentației la minim cu scopul sporirii productivității.

Compunerea secvențială a conținutului sprint-urilor permite efectuarea unei modificări sau adăugarea unei funcționalități care nu era prevăzută inițial.

Timpul de livrare a produsului final se reduce semnificativ.

Dezavantaje:

Împărțirea task-urilor în echipă poate duce la probleme din cauza nepotrivirii pe anumite task-uri.

Pot apărea dificultăți în estimarea costului final al proiectului, datorate dorinței permanente de a adăuga noi caracteristici care apar pe parcurs.

Refactoring-ul are prioritate scăzută din cauza actualizării constante a statusului și a cererii de noi funcționalități. Aceasta poate afecta mai târziu arhitectura, scalabilitatea și securitatea.

Se poate întâmplă ca membrii echipei să se piardă în detalii și să uite scopul general al proiectului.

Dimensiunea echipei este limitată la 7 – 10 persoane și calitatea produsului realizat poate scădea cu creșterea persoanelor, deoarece în această situație calitatea este mai greu de controlat.

Pot apărea cereri multiple provenite din mai multe surse în cadrul unui proiect și pot uneori să fie dificil de gestionat datorită aspectului lor contradictoriu.

Alegerea soluției optime

Metodologiile SCRUM și XP sunt metode iterative care permit dezvoltarea proiectelor în iterații mici succesive, livrează părți din proiect mult mai repede decât prin metodologia RUP și se culege feedback de la client mult mai repede, și astfel se pot corecta greșelile din timp. Specificațiile proiectului se pot modifica sau schimba foarte ușor de la un sprint la altul în cele două metodologii.

SCRUM propune echipa multidisciplinară care să rezolve toate sarcinile ce trebuie realizate într-un sprint prin colaborare directă între programator, tester, designer, analist, eliminând timpii morți care îi poate avea un membru al echipei, cât timp ceilalți lucrează la partea făcută de el.

In aplicațiile mobile apar schimbări dese datorită faptului că apar dispozitive noi, versiuni noi ale sistemului de operare, specificații noi iar dacă proiectul este definit cu RUP, costul de a face modificări este mult mai mare decât cazul celorlalte două.

XP și SCRUM implică direct clientul în desfășurarea proiectului prin el sau printr-un reprezentant de al lui care are rolul de product owner și care este foarte aproape de echipa și se asigură că se livrează elementele așteptate de client la sfârșitul fiecărui sprint. Rup implică clientul doar la începutul și la sfârșitul proiectului, ceea ce poate genera probleme semnificative la sfârșit dacă proiectul nu este implementat exact cum își dorește el.

SCRUM și XP propun echipe de mici dimensiuni care sunt foarte potrivite pentru dezvoltarea aplicațiilor mobile. Acestea sunt de obicei proiecte de dimensiuni mai mici care durează câteva luni. Ambele metodologii ajută la livrarea rapidă prin reducerea timpului necesar petrecut pentru scrierea documentațiilor și a altor activității din metodologii clasice. În schimb, RUP implică echipa de dimensiuni mai mari și este potrivit pentru proiecte de dimensiuni mari care poate să dureze mulți ani care pot să folosească beneficiile oferite de activitățile din RUP.

SCRUM și XP ajută la livrarea rapidă de bucăți funcționale din aplicația la o calitate ridicată datorită proceselor și metodelor pe care le propun atât pentru managementul proiectului, cât și pentru programatori și testări. RUP ajută la livrarea proiectelor de dimensiuni mari si care trec în timpul dezvoltării prin mai multe faze pentru a găsi soluția tehnică perfectă pentru proiect.

Din cele trei metodologii prezentate, SCRUM este cel mai ușor de integrat într-o echipă și în proiecte deoarece nu implică nevoie de a avea programatori experimentați sau documentație stufoasă ca în cazul celorlalte două.

Metodologia RUP este potrivită în proiectele în care toate specificațiile clientului sunt cunoscute de la începutul proiectului și nu se acceptă modificări în timpul execuției proiectului. În schimb, metodologiile SCRUM și XP sunt potrivite pentru proiectele cu conținut flexibil în care se știe cât timp este alocat proiectului și doar în linii mari ce trebuie livrat. În timpul proiectului clientul este cel care decide la fiecare sprint care sunt prioritățile și specificațiile.

În concluzie, toate cele 3 metodologii anterior prezentate în această lucrare trebuie luate in considerare la dezvoltarea aplicațiilor mobile, dar cea mai răspândită, mai ușor de implementat și cea mai recomandată este metodologia SCRUM.

Studiu de caz – aplicația U-BT-Mobitelco

Platformele alese pentru studiul de caz considerat sunt iOS și Android fiind cele mai importate sisteme de operare mobile la momentul actual.

Implementarea efectivă a implicat utilizarea platformei Android care necesită cunoștințe de Android și elemente de programare din limbajului Java.

Pentru realizarea aplicației considerată ca studiu de caz s-a utilizat metodologia de proiectare SCRUM deoarece este una din cele mai utilizate metodologi pentru aplicații mobile, este ușor de implementat când se lucrează la proiect și în echipă, iar pentru echipe mici este foarte practică.

Echipa care a implementat aplicația prezentată ca studiu de caz a fost formata din 5 persoane: 3 programatori (iOS, Android, .Net), un Scrum Master și un Product Owner.

Implementarea aplicației U-BT-Mobitelco

Aplicația U-BT-Mobitelco este o aplicație care prezintă informații despre clubul de baschet U-Mobitelco din Cluj, schema bloc de implementare conține 8 secțiuni principale care sunt: Ultimele știri, Live Score, Rezultate Program, Clasament, Prezentare club, U-BT-Mobitelco, Echipa juniori, Sponsori.

Figura IV-1 Schema bloc a aplicației.

Pentru navigarea cât mai ușoară printre secțiunile principale ale aplicației am ales folosirea unui meniu de tip lateral (Slide). Se prezintă în figura x meniul aplicației.

Figura IV-2. Meniul Aplicației.

Pentru implementarea meniului am folosit librăria „SlidingMenu” care permite adăugarea facilă de meniu de tip slide. In activitatea de bază BaseSlideActivity am adăugat meniul de tip slide ,codul este prezentat mai jos:

Clasa MenuFragment este implementarea propriu-zisă a conținutului meniului,codul simplificat este detaliat mai jos:

Secțiunea principala a aplicației „Ultimele Știri” conține ultimele noutăți legate de echipa de baschet U-Mobitelco și se poate selecta o știre pentru a vizualiza detaliile știrii.

Figura IV-3. Ultimele știri.

Pentru implementarea secțiunii „Ultimele Știri” s-a folosit

Pentru prezentarea informaților sa folosit o lista si fiecare rând al listei este prezentat sub forma de cârduri. Elementele din lista se incarca in bath de 20 elemente si pentru incarcarea următoarelor pagini sa folosit librăria PullToRefresh realizat de 2.

Culorile aleasa pentru secțiunea „ultimele Știri” este incordonta cu culorile clubului

Pentru descărcarea si afișarea imaginilor din aplicație am folosit biblioteca „Picaso” care incarca imaginile asincron si le salvaseza si in memorie si pe hard disk pentru a incarca cat mai repede imaginile si aplicația sa fie mai rapida()

Secțiunea „Live Score” conține informații in timp real despre meciurile de baschet in desfășurare .

se prezintă meciurile care sunt în desfășurare .

Figura IV-4. Live Score.

Secțiunea „Rezultate /Program” conține rezultatele din campionat și cupă. De asemenea se poate vizualiza programul etapelor viitoare.

Figura IV-5. Rezultate si Program.

Secțiunea „clasament”

În aceasta secțiune se prezintă clasamentul ligi naționale de baschet.

Figura IV-6. Clasament.

Pentru implementarea lui sa folosit elementul de lista,pentru descărcarea

In secțiunea „prezentare club” se prezintă clubul cu o scurtă prezentare a istoriei clubului.

Figura IV-7. Prezentare Club.

În secțiunea „U-BT-Mobitelco” conține informații echipa de baschet a clubului și arată fiecare jucător sub forma de card-uri, se poate selecta un jucător sau un membru din staff pentru a afla mai multe detalii legat de el.

Figura IV-8. Prezentare Echipa Seniori.

Design-ul acestei secțiuni carusel de card-uri ca utilizatorul aplicației sa aibă experinta ca cu niște cârduri cu jucători din realitate.

Pentru implementarea carusel de card-uri am extins componenta ViewPager , si pentru realizarea efectului dorit de carusel am implement un efect de transformare a pagini de tip scalare ,codul simplificat este detaliat mai jos:

În clasa CarouselViewPager am extins clasa ViewPager și am implementat o funcția animateZoom care scalează paginile în funcția de poziția de ecran astfel realizând un efect de carousel.

În aceasta secțiune „Echipa juniori” este prezentată fiecare echipă de juniori cu tot cu staff.

Figura IV-9. Prezentare Echipele de juniori.

În secțiunea „Sponsori” se prezintă sponsorii principalii al echipei.

Figura IV-10. Sponsori principali al echipei

Pentru implementarea lui am folosit componenta de tip lista „ListView”.

Implementare comunicare

Comunicarea între aplicație și server s-a realizat prin comunicare de tip REST și tipul de mesaj folosit. Pentru comunicare s-a folosit formatul JSON deoarece din acest format pe platforma Android este mai ușor de deserializat informațiile din el cu ajutorul Librari GSON de la Google.

Implementarea comunicării cu serverul sa folosit librăria „Android Asynchronous Http Client” creat de James Smith.

Se prezintă in figura de mai jos schema bloc al aplicației:

Figura IV-11 Comunicarea aplicației

Implementare bara de acțiuni

În Android 3.0 a fost introdusă bara de acțiuni pentru acțiuni rapide, dar aceasta nu este compatibilă cu versiuni mai vechi,dar pentru a avea compatibilitate cu versiunile mai vechi am folosit librăria „Appcompat library” din biblioteca „Android Support Library” creat de către Google.

Concluzii

Lucrarea de față descrie modul în care, trebuie realizată o aplicație mobilă de la concept până la produsul final. În primul capitol sunt prezentate sistemele de operare mobile cele mai utilizate și platforma care trebuie luată în calcul pentru dezvoltarea de aplicații mobile. Alegerea se realizează in funcție de tipul aplicației, platforma folosită de utilizatori, și în funcție de cunoștințele programatorilor.

În al doilea capitol sunt prezentate abordările pentru crearea unei aplicații mobile și se prezintă modul cum trebuie aleasă abordarea cea mai potrivită pentru o aplicație mobilă. Se prezintă cum ar trebui o aplicație mobile să arate si ce metodologii sunt disponibile pentru gestionarea proiectelor pentru dispozitive mobile. În funcție de platforma aleasă, funcționalitățile dorite, cunoștințele programatorilor, bugetul disponibil se alege abordarea cea mai corespunzătore.

Studiul de caz U BT Mobitelco prezentată în această lucrare este o aplicație mobilă, nativă pentru platformele Android și iOS care prezintă echipa de baschet U BT Mobitelco din Cluj Napoca. Platformele alese sunt Android și iOS și au fost selectate pe baza principiilor prezentate în capitolul I. S-a ales abordarea nativă pentru crearea unei aplicații deoarece programatorii au cunoștințele necesare pentru a dezvolta aplicații pentru ambele platforme și de asemenea s-a dorit ca aplicația să includă multe efecte grafice. Metodologia a fost aleasă în concordanță cu principiile prezentate în capitolul III. Această metodologie selectată este Scrum.

Cum lumea este în continuă mișcare și schimbare, sunt conștient că la fiecare 6 luni această lucrare ar trebui actualizată cu ultimele modificări apărute. Aplicația considerată ca studiu de caz poate fi modificată ca să prezinte mult mai în detaliu viața unei aplicații mobile de la idei până la rezultatul final.

Aplicația mobilă U BT Mobitelco ar putea să sufere pe viitor următoarele îmbunătățiri: realizarea interfeței pentru tablete, prin reutilizarea elementelor de interfață din versiunea actuală; modificarea aplicației pentru a rula și în modul landscape nu doar portrait; adăugare de noi funcționalități: vânzare de bilete, vânzarea abonamentelor, vânzare de produse cu însemnele clubului, streaming video a meciurilor și reportaje video cu echipă.

Bibliografie

Statistica Android,http://developer.android.com/about/dashboards/index.html

Statistica iOS ,http://david-smith.org/iosversionstats/

http://en.wikipedia.org/wiki/Extreme_programming

http://en.wikipedia.org/wiki/Scrum

http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process

Ken Schwaber și Jeff Sutherland , „Ghidul Scrum”. 2011.

Satya Komatineni, Dave MacLean, Sayed Y. Hashimi „Pro Android 3”, Ed. Apress, 2011.

P. Nicolas, “Introduction to SCRUM Agile Process for Global software development”, Coalesce Network, pp. 1-9, 2007.

J.Sutherland and K.Schwaber, “The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework”, SCRUM Training Institute. 2010

Agile Processes in Software Engineering and Extreme Programming-12th International Conference, XP 2011 Madrid, Spain, May 10-13, 2011 Proceedings.

Agile Programming: Design to Accommodate Change-Dave Thomas-Vol. 22, No. 3 May/June 2005.

Ovidiu Gheorghieș:http://www.infoiasi.ro/~ogh/files/ip/curs- 01.pdf

Philippe Kruchten, Rational Unified Process—An Introduction, Addison-Wesley, 1999.

J. Rumbaugh, I. Jacobson, G. Booch, The Unified Modeling Language Reference manual, 2nd edition, Addison Wesley,2004.

F. Leon, Ingineria Programarii, note de curs, http://eureka.cs.tuiasi.ro/~fleon.

Introduction to Extreme Programming by Mike Grant

Extreme programming by Ganesh Sambasivam

Extreme programming explained by Kent Beck

Extreme programming and agile software development methodologies by Lowell Lindstrom and Ron Jeffries

K. Schwaber, M. Beedle. Agile software development with SCRUM. Prentice Hall, 2001.

An Introduction to Agile Software Development June 2007

Abrahamsson, P. (2007). Agile Software Development of Mobile Information Systems. In Advanced Information Systems (pp. 1-4). Berlin: Springer.

Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile Software Development Metods: Review and Analysis. VTT Electronics.

Luke Welling, Laura Thomson , „PHP and MySQL Web Development”, Ed. Sams Publishing, 2001.

Richard Bloor ,Marco Tabor MOBILE DEVELOPER’S GUIDE TO THE GALAXY , 14th Edition February 2014

TODAY SOFTWARE MGAZINE No. 14 • August 2013 • www.todaysoftmag.ro •

TODAY SOFTWARE MAGAZINE No. 6 • August 2013 • www.todaysoftmag.ro •

https://scoutzie.com/blog/how-to-design-a-mobile-app

Android Design https://developer.android.com/design

http://www.hongkiat.com/blog/mobile-app-ui/

https://developer.apple.com/library/ios/documentation/userexperience/

http://dev.windowsphone.com/en-us/design/library

http://petrnohejl.github.io/Android-Cheatsheet-For-Graphic-Designers/

http://www.thinslices.ro/2013/01/25/mvp-wireframe/

https://ctrl-d.ro/design/resurse-design/aplicatii-pentru-wireframe-uri/

http://uxdesign.ro/aplicatii-pentru-wireframe-uri-si-prototipuri/

http://blog.startapp.com/android-ios-windows-phone/

https://www.udemy.com/blog/ios-vs-android-vs-windows/

https://ctrl-d.ro/development/resurse-development/aplicatii-mobile-native-versus-aplicatii-compilate-ionut-ion-timo-editia-14/

!!! nu uita sa referi toate elementele bibliografice in partea de teorie !!!