Aplicație pentru dispositive mobile (Android), cu scopul de a calcula suprafețe de teren, prin coordinate GPS [307853]

Aplicație pentru dispositive mobile (Android), cu scopul de a [anonimizat]: George Michael TAȘCU

Conducător științific: Prof.dr.ing. Honoriu VĂLEAN

Autor: [anonimizat]: Crearea unei aplicații pentru identificarea poziției in timp real al autobuzului dorit

Conținutul proiectului: (enumerarea părților componente) [anonimizat], [anonimizat], Introducere, [anonimizat], Analiză, Proiectare, Implementare, Concluzii, Bibliografie.

Locul documentației: [anonimizat]:

Data emiterii temei: 15 noiembrie 2016

Data predării: septembrie 2017

Semnătura autorului

Semnătura conducătorului științific

Declarație pe proprie răspundere privind

autenticitatea proiectului de diplomă

Subsemnatul(a) [anonimizat](ă) cu CI seria HD nr.609615 ,CNP [anonimizat] ,

autorul lucrării:

[anonimizat] a [anonimizat] ,

[anonimizat],

sesiunea a anului universitar 2016-2017,

[anonimizat], [anonimizat], și în bibliografie.

Declar, [anonimizat] a convențiilor internaționale privind drepturile de autor.

Declar, [anonimizat] a mai fost prezentată în fața unei alte comisii de examen de licență.

In cazul constatării ulterioare a [anonimizat], respectiv, anularea examenului de licență.

[anonimizat]

1.09.2017

(semnătura)

SINTEZA

proiectului de diplomă cu titlul:

[anonimizat]: George Michael TAȘCU

Conducător științific: Prog.dr.ing. Honoriu VĂLEAN

1. Cerințele temei: Implementarea unei aplicații care permite utilizatorului să masoare o suprafață de teren direct prin coordonate GPS.

2. Soluții alese: Proiectarea unui sistem de trasare a suprafeței pe harta și calcularea acesteia.

3. Rezultate obținute: [anonimizat].

4. Testări și verificări: Calcularea unei suprafețe deja cunoscute și verificarea funcțiilor implementate.

5. Contribuții personale:Analiza, structurarea și implementarea aplicației și încă cateva funcții adiționale;

6. Surse de documentare: [anonimizat]-[anonimizat], cărți.

Semnătura autorului

Semnătura conducătorului științific

Introducere

1.1 [anonimizat] a [anonimizat] a maximiza aceste lucruri este internetul. O altă caracteristică foarte importantă a vitezei de acces la informație este reprezentată de dispozitivele cu acces la internet. Relativ cu două decenii în urmă, principala unealtă folosită pentru accesul la internet a fost calculatorul, dar în ziua de astăzi este preferat un smartphone. Acesta poate fii achiziționat la un preț accesibil oricui și cu o performanță foarte ridicată, insoțită și de funcționalități cum ar fi GPS, Wi-Fi, 4G, cameră foto/video, etc… Totuși, cea mai importantă caracteristică a acestuia este portabilitatea, deoarece toate aceste funcționalități le avem la dispoziție, în buzunar.

Un studiu ne arată că în 2016, 99.6% din piața mondială a smartphone-urilor rulează ca sistem de operare Android sau iOS, Android deținând procentajul major de 81.7%[1]. Android este și o platforma software pentru smartphone-uri și tablete care are la bază un kernel Linux. Dezvoltatorii sistemului sunt Andy Rubin, Rich Miner, Nick Sears și Chris White, care au înființat compania Android în anul 2003, ce a fost cumpărată de Google în 2005. În anul 2008, Android devine o platformă open source, datorită coaliției Open Handset Alliance[2][3].

Din 2008 până în prezent, aplicațiile Android au devenit foarte frecvent utilizate datorită faptului că sunt disponibile unui public larg, iar implementarea lor a devenit accesibilă.

Limbajul nativ folosit în dezvoltarea aplicațiilor Android este Java, împreună cu unele librării oferite de Google. Pentru a implementa o aplicație cu succes, se utilizează un SDK (Software Development Kit), deoarece acesta compilează codul și resursele adăugate în proiect. SDK-ul folosit în acest proiect și în multe altele este Android SDK. Acesta mai conține diferite unelte folositoare programatorului, cum ar fi: emulator, debugger, documentație, tutoriale, secvențe de cod, etc… Rezultatul după compilare, este un fișier de tip APK (Android application package), care va fi portat pe dispozitivul Android sau pe un AVD (Android Virtual Device).

1.2 Obiective

Aplicația a fost dezvoltată în așa fel încât orice utiliztor să poată beneficia de aceasta, indiferent de locația sa. Utilitatea acestieia variază în funcție de interesul utilizatorului și este ușor de folosit.

Obiectivele principale ale dezvoltării acestei aplicații sunt:

Posibilitatea de autentificare a user-ului cu un cont personal;

Posibilitatea de înregistrare a unui cont nou de utilizator;

Interfață simplă pentru o utilizare ușoară;

Folosirea gesturilor în lucrul cu Google Maps pentru a beneficia de un ecran puțin încărcat de butoane;

Formarea suprafeței ce se dorește a fi calculată prin markeri plasați la locația atingeri ecranului;

Calculul suprafeței a formelor neregulate, nu doar a triunghiurilor;

Posibilitatea de curățare a hărții după fiecare calcul;

Vizualizarea hărții în diferite tipuri, în funcție de natura suprafeței ce se dorește a fi măsurată;

Navigarea cu ușurință între activitățile aplicației;

Și nu în ultimul rând, dezvoltarea abilității personale de a utiliza și aprofunda cunoștințe legate de implementarea aplicațiilor pe Android.

1.3 Specificații

Specificațiile unei aplicații reprezintă un set de informații pe care un sistem trebuie să le îndeplinească pentru a putea rula un program, o aplicație, etc… Aceste specificații pot fi de doua tipuri:

1.3.1 Specificații hardware

Specificațiile hardware reprezintă descrierea componentelor fizice, aflate într-un sistem informatic. Aceste componente servesc la culegerea, stocarea, prelucrarea, transmiterea, afișarea, verificarea datelor, în funcție de rolul fiecăreia.

Specificațiile hardware folosite și minime:

Pentru PC:

Procesor: Intel Core i7-4500U 1.8 GHz || minim Intel Pentium 4 2.4GHz;

Memorie RAM: 8GB || minim 4GB;

Memore pe hard: minim 2GB, recomandat 4GB;

Rezoluție ecran: 1366×768 || minim 1280×800.

Pentru dispozitiv mobil:

Procesor: Quad-Core 1.3GHz;

Memorie RAM: 2GB;

Memorie de stocare: 16GB;

Rezolutie ecran: 1280×800;

GPS: Da;

USB: Da;

Wi-Fi: Da.

Specificații software

Specificațiile software reprezintă descrierea părților logice a unui sistem informatic. Produsul final trebuie să fie format pe baza specificațiilor cerute de client, deoarece specificațiile software stau la baza înțelegerii dintre cumpărător și dezvoltator. Cu cât aceste specificații sunt mai bine stabilite înaintea începerii etapei de proiectare, cu atât mai mult se poate reduce timpul reproiectării sau dezvoltării produsului final.

Specificații software folosite și minime:

Pentru PC:

Sistem de operare: Microsoft® Windows® 10 64-bit || minim Microsoft® Windows® 7 32-bit, Mac® OS X® 10.10 (Yosemite) sau Linux GNOME or KDE desktop;

IDE(Integrated Development Environment): Android Studio;

Adițional: Android SDK și JDK(Java Development Kit).

Pentru dispozitiv mobil:

Sistem de operare: Android;

Versiune: 5.1.1(Lollipop) || minim 4.2(Jelly Bean).

Dispozitivul mobil folosit pentru această lucrare este o tabletă Lenovo YT3-X50F. Am ales acest dispozitiv pentru a evidenția faptul că aplicația poate rula fără nicio problema și pe o versiune de android învechită, dar și datorită dimensiunii ecranului, mai exact 10.1 inch.

Dezvoltarea și testarea aplicației au fost realizate tot pe acest dispozitiv, ceea ce reprezintă neutilizarea unui AVD(Android Virtual Device), însemnând că toate fazele aplicației au fost realizate pe un dispozitiv real.

Studiu bibliografic

Programare Orientată pe Obiecte(POO)

2.1.1 Definire POO

Programarea orientată pe obiecte(POO), sau OOP(Object-Oriented Programming) în engleză, este o paradigmă, un model pe programare, ci nu un limbaj în sine. Există o varietate de limbaje de programare care implementează acest model, cum ar fi: Java, C#, python, etc…

La baza POO se află 4 mari concepte, însă pentru a ne putea însuși aceste concepte, mai întâi trebuie să înțelegem ce este un obiect și ce este o clasă.

Obiectul

Din punct de vedere strict și pur OOP, un obect reprezintă o instant a unei clase. Acesta poate fi văzut ca un lucru ce poate efectua un set de activități conexe, iar comportamentul său este definit de acest set. Se identifică unic prin nume și poate fi considerat un atribut al altei clase. Un obiect poate fi caracterizat de metode și attribute definite în clasa căreia îi aparține.

Clasa

O clasa reprezintă un șablon prin care sunt descrise detaliile unui model după care sunt create obiecte individuale. Clasa se caracterizează prin nume, attribute și metode. Metodele reprezintă acțiunile sau operațiile pe care un obiect le poate executa, iar atributele descriu valoric proprietățile unui obiect.

Conceptele POO

O aplicație OOP este constituită dintr-o mulțime de clase ce trebuie prelucrate și manevrate. Pentru reducerea complexității unei aplicații, există diferite tehnici de gestionare a claselor, ce le putem grupa în 4 concepte, anume[4][5]:

Abstractizare;

Încapsulare

Moștenire;

Polimorfism.

Figura 2.1 Concepte POO;

Abstractizarea

Ascunderea detaliilor interne și demonstrarea funcționalității caracterizează cel mai bine termenul de abstractizare. De exemplu, un apel telefonic, nu cunoaștem procesarea internă, dar vedem efectul.

Abstractizarea înseamnă reprezentarea complexității prin utilizarea unor lucruri simple. Știm cu toții cum să pornim televizorul, dar nu trebuie să știm cum funcționează pentru a ne bucura de el.

Pentru a declara o clasă abstractă, folosim cuvântul cheie „abstract”. Aceste clase nu pot fi instantiate ci doar folosite drept super-clasă pentru a fi moștenită de alte clase. O clasă abstractă este implementată atunci când se realizează o subclasă a acesteia, însemnând că trebuie suprascrise toate metodele și proprietățile abstacte ale acestiea.

Moștenirea

Moștenirea este o caracteristică specială a programării orientate pe obiecte. Aceasta permite programatorilor să creeze clase noi care să preia unele, sau toate atributele unei clasei deja existente prin extinderea acesteia. Acest lucru ne permite să ne bazăm pe munca anterioară fără a rescrie bucăți mari de cod de fiecare dată.

Pentru o înțelegere mai ușoară a acestui concept, cel mai bine ar fi să luăm un exemplu din lumea reală. Dacă spunem că un leu este un mamifer, ne referim la faptul că acesta își însușește calitățile unui mamifer, de exemplu: naște pui vii, îi hrănește cu lapte, are păr, etc…, dar pe lângă acestea mai este și felină, prădător și se hrănește cu carne, s.a.m.d. O vacă este tot un mamifer care își însușește caracteristicile generale ale acestora, însă are alte caracteristici specifice cum ar fi: este bovină, animal domestic, se hrănește cu iarbă, s.a.m.d. Atât leul cât și vacă moștenesc clasa mamifer datorită caracteristicilor generale, dar și specializează mamiferele la propriile lor subtipuri specifice.

Încapsularea

Încapsularea reprezintă păstrarea câmpurilor într-o clasă privată, oferind apoi acces la ele prin metode publice. Este o barieră de protecție care păstrează datele și codul în siguranță în clasa însăși, deoarece în acest fel putem reutiliza obiectele drept componente de cod sau variabile, fără a permite accesul direct la date.Practic, ne permite să reutilizăm funcționalitatea codului fără a compromite siguranță.

Încapsularea este un concept puternic în OOP, deoarece ne ajută să economisim mult timp. De exemplu, putem crea o bucată de cod care să apeleze date specifice dintr-o bază de date sau să reutilizăm acest cod cu alte baze de date deja existente. Încapsularea ne permite să facem acest lucru păstrând, în același timp, datele originale private. De asemenea, ne permite să modificăm codul original fără a îi afecta pe alții care l-au adoptat între timp.

Polimorfismul

Polimorfismul este un termen generic care provine din două cuvinte grecești, poli și morf.Poli înseamnă mai multe, iar morf înseamnă forme, așadar cuvântul s-ar traduce „cu mai multeforme”. Mai precis, polimorfismul înseamnă capacitatea de a solicită ca aceleași operațiuni săfie efectuate de către o gamă largă de tipuri diferite de lucruri.

În Java, polimorfismul funcționează utilizând o referință la o clasă părinte pentru a afecta un obiect din clasa copil. Am putea crea o clasă numită „cal” prin extinderea clasei „animal”. Această clasă ar putea, de asemenea, să pună în aplicare clasa „animale de curse”. Clasa „cal” este „polimorfă”, deoarece moștenește atribute atât din clasa „animal”, cât și din categoria „animale de curse”. Putem folosi supraîncărcarea metodei și suprascrierea metodei pentru a realiza polimorfismul.

În supraîncărcarea metodei, o singură metodă poate avea diferite rezultate, în funcție de contextul în care se apelează. Aceasta înseamnă că un singur apel al metodei, ar putea funcționa în moduri diferite, în funcție de argumentele pe care le transmitem.

În suprascrierea metodei, clasa copil poate folosi conceptul de polimorfism din OOP, pentru a suprascrie o metodă a clasei părinte. Aceasta permite unui programator să utilizeze o metodă în moduri diferite, determinate de faptul că este invocată de un obiect al clasei părinte sau de un obiect al clasei copil.Dezvoltarea software pe Android

2.2 Dezvoltarea software pe Android

2.2.1 Arhitectura software Android

Figura 2.2 Arhitectura software Android;

După cum se observă în figura 2.2, arhitectura sistemului de operare Android cuprinde 5 secțiuni grupate pe 4 niveluri[6]:

Kernel Linux

Kernelul Linux (cu unele modificări) conține driver-ele pentru diferitele componente hardware (ecran, camera foto, tastatură, antena WiFi, memoria flash, dispozitive audio), fiind responsabil cu gestiunea proceselor, memoriei, perifericelor (audio/video, GPS, WiFi), dispozitivelor de intrare/ieșire, rețelei și a consumului de energie.

Biblioteci

Bibliotecile (user-space) conțin codul care oferă principalele funcționalități a sistemului de operare Android, făcând legătura între kernel și aplicații. Sunt incluse aici motorul open-source pentru navigare WebKit, biblioteca FreeType pentru suportul seturilor de caractere, baza de date SQLite utilizată atât ca spațiu de stocare cât și pentru partajarea datelor specifice aplicațiilor, biblioteca libc (Bionic), biblioteca de sistem C bazată pe BSD și optimizată pentru dispozitive mobile bazate pe Linux, biblioteci pentru redarea și înregistrarea de conținut audio/video (bazate pe OpenCORE de la PacketVideo), biblioteci SSL pentru asigurarea securității pe Internet și Surface Manager, biblioteca pentru controlul accesului la sistemul de afișare care suportă 2D și 3D. Aceste biblioteci nu sunt expuse prin API, reprezentând detalii de implementare Android.

Motorul Android

Motorul Android este reprezentat de:

un set de biblioteci de bază care permit utilizatorilor să dezvolte aplicații Android folosind limbajul de programare Java; acestea includ acces la funcțiile telefonului (telefonie, mesaje, resurse, locații), interfața cu utilizatorul, furnizori de conținut și gestiunea pachetelor (instalare, securitate)

mașina virtuală (Java) Dalvik este optimizată special pentru Android (dispozitive mobile alimentate de o baterie, resurse de procesare și de memorie limitate, sistem de operare fără swap). Arhitectura sa se bazează pe registri, fiind echipată cu un compilator JIT (just-în-time), executabilul obținut putând fi modificat când este instalat pe dispozitivul mobil. Întrucât este utilizată o bibliotecă proprie ce pornește de la un subset al implementării Java realizată de Apache Harmony, nu sunt conținute pachetele pentru AWT / Swing, imprimare sau alte componente speciale. Prin urmare, deși de poate utiliza versiunea curentă de Java (7) pentru dezvoltarea aplicației, facilitățile ce pot fi folosite sunt limitate aproximativ la versiunea 6. Bytecode-ul este compilat în fișiere .dex – Dalvik Executable (în loc de .class), datele duplicate provenind din clase diferite (șiruri de caractere, alte constante) fiind incluse o singură dată, motiv pentru care un astfel de fișier necomprimat va avea o dimensiune mai mică decât o arhivă .jar (comprimată). De asemenea, se permite ca fiecare aplicație Android să ruleze în procesul propriu, într-o instanță a mașinii virtuale Dalvik.

Cadrul pentru aplicații

Cadrul pentru Aplicații expune diferitele funcționalități ale sistemului de operare Android către programatori, astfel încât aceștia să le poată utiliza în aplicațiile lor.

Aplicații

La nivelul de aplicații se regăsesc atât produsele împreună cu care este livrat dispozitivul mobil (Calculator, Camera, Contacts, Clock, FM Radio, Music Player, S Note, S Planner, Video Player, Voice Recorder), cât și produsele instalate de pe Play Store sau cele dezvoltate de programatori.

2.2.2 Caracteristici Android

Principalele caracteristici ale unei aplicații Android[7]:

La baza, este o aplicație Java executată de către o mașină virtuală Dalvikș mașina virtuală (VM) Dalvik execută fișiere „ .dex”, obținute din fișiere „ .class” Java, cu ajutorul unei unelte „dx”, cu care se realizează conversia din cod Java în byte-code;

Se distribuie într-un pachet Android (Android Package), care este un fișier de tip

„ .apk”

Aplicatia este executată de către sistemul de operare Android (un Linux multi-utilizator), într-un sandbox;

Fiecare aplicație are un ID utilizator unic și resursele sale pot fi accesate numai de către acel utilizator;

Fiecare aplicație rulează în procesul Linux propriu și în propria instanța de mașină virtuală; în ciuda acestui fapt, două aplicații diferite pot avea același ID de utilizator pentru a partaja resursele lor;

Operațiile critice (acces la Internet, citire/scriere date de contact, monitorizare SMS, acces la modulul GPS), pot fi restricționate sau se poate solicita permisiunea utilizatorului, utilizând fișierul manifest de configurare a aplicației, „AndroidManifest.xml”;

O aplicație Android înseamnă una sau mai multe activități (o activitate poate fi asociată cu un ecran sau o fereastră, dar este mai mult decât atât) și procesul Linux;

Ciclul de viață al unei activități nu este legat de ciclul de viață al procesului; activitatea poate rula chiar în cazul în care procesul sau nu mai există;

O aplicație poate executa o componentă (activitate) din altă aplicație; componenta (activitatea) este executată de procesul de care aparține;

O aplicație Android NU are un punct unic de intrare, cum ar fi metoda „main()” în aplicațiile Java, C sau C++.

2.2.3 Componentele unei aplicații Android

Componentele principale ale unei aplicații Android sunt[7]:

2.2.3.1 Activitatea

Activitatea reprezintă o interfață cu utilizatorul și este responsabilă de interacțiunea utilizatorului cu ecranul dispozitivului mobil;

O aplicație Android poate avea una sau mai multe activități;Fiecare Activitate are propriul sau ciclu de viață, independent de ciclul de viață al procesului asociat aplicației;

Fiecare activitate are propria stare și datele acesteia pot fi salvate sau restaurate;

Activitățile pot fi pornite de aplicații diferite (dacă este permis);

Are un ciclu de viață complex deoarece aplicațiile pot avea activități multiple și doar una este în prim-plan;

În SDK, Activitatea este implementată folosind o subclasă a clasei Activity care extinde clasa Context.

2.2.3.2 Serviciul

Un task care se execută în fundal, fără interacțiunea directă cu utilizatorul;

Este gestionat de o instanță a clasei Service.

2.2.3.3 Intenția

Reprezintă o metodă de a comunica între componente folosită pentru a descrie o operațiune care urmează să fie executată;

Comunică printr-un mesaj asincron, pentru a activa alte activități sau servicii, din cadrul activității curente;

Este gestionată de o instanță a clasei Intent.

2.2.3.4 Managerul de conținut

Este un API folosit pentru a gestiona datele private ale aplicației;

Se ocupă cu transferul de date de la o aplicație la alt ape baza de permisiuni;

Utilizează diferite metode pentru manevrarea datelor(fișiere, bază de date, rețele, etc…);

Implementat de o subclasă a clasei ContentProvider.

2.2.3.5 Broadcast reciver

O componentă care răspunde la evenimentele difuzate la nivel de sistem; putem spune că se comport ca un event handler global;

Și aplicațiile pot iniția astfel de broadcast-uri;

Implementat de o subclasă a clasei BroadcastReceiver.

2.2.4 Funcționalitățile unui sistem Android

În funcție de tipul dispozitivului (telefon, tabletă, smartwatch, smartTV, etc…), funcționalitățile variază constant de la una la cealaltă. Totuși, putem enumera câteva funcții care se regăsesc în toate aceste dispositive, anume:

Wi-Fi;

Posibilitate de stocare a datelor;

Conectivitate pentru semnal de rețea și internet;

Suport pentru fișiere multimedia;

Suport pentru mai multe limbi;

Interfață grafică;

Ecran tactil.

2.2.5 Ciclul de viață al unei activități

Acest ciclu este un aspect cheie înspre înțelegerea arhitecturii unei aplicații mobile Android, și trebuie stăpânit de programator pentru a-l putea controla. Ciclul este format din 4 stări (etape) controlate de 7 metode „callback”, oferite de clasa „Activity”, ce vor fi prezentate ulterior[7].

Figura 2.3 Ciclul de viață al unei activități;

2.2.5.1 Running (În execuție)

Activitatea a fost creată ( onCreate() ), pornită ( onStart() ) și este afișată pe ecranul aparatului; în cazul în care activitatea a mai fost utilizată și aplicația a salvat starea acesteia ( onSaveInstanceState() ), activitatea este reluată din acel punct ( onRestoreInstanceState() și onResume() ); în această stare utilizatorul interacționează cu activitatea prin intermediul interfeței dispozitivului (tastatură, touchscreen, display).

2.2.5.2 Paused (Întreruptă temporar)

Activitatea pierde prim-planul ( onPause() ), deoarece o altă activitate este executată, cum ar fi o fereastră de dialog; de asemenea, în cazul în care aparatul intră în modul sleep, activitatea este oprită temporar; activitatea își poate relua execuția ( onResume() ) și este plasată înapoi în prim-plan.

2.2.5.3 Stopped (Oprită)

Activitatea nu este mai în uz și pentru că este oprită ( onStop() ), nu este vizibilă; pentru a fi reactivată (ea deja există), activitatea trebuie să fi repornită ( onRestart() și onStart() ) și reluată ( onResume() ).

2.2.5.4 Destroyed (Inexistentă)

Activitatea este distrusă (onDestroy()) și memoria s-a eliberat, deoarece nu mai este necesară sau sistemul are nevoie de memorie suplimentară pentru rutinele proprii ori pentru alte activități; deoarece managementul memoriei este un aspect important pentru sistemul de operare Linux al dispozitivului mobil, procesul care găzduiește o activitate întreruptă, oprită sau distrusă, poate fi terminat pentru a elibera memorie pentru noi activități; doar procesele ce gestionează activități ce rulează sunt protejate.

2.2.5.5 Metodele de navigare între stări

onCreate(Bundle) – apelată când activitatea este creată; folosind argumentul metodei de tip Bundle există posibilitatea să restabiliți starea activității, care a fost salvată într-o sesiune anterioară; după ce activitatea a fost creată, va fi pornită ( onStart() );

onStart( ) – apelată în cazul în care activitatea urmează să fie afișată; din acest punct, activitatea poate veni în prim-plan ( onResume() ) sau rămâne ascunsă în fundal ( onStop() );

onResume( ) – apelată când activitatea este vizibilă iar utilizatorul poate interacționa cu această; din această stare, activitatea poate fi plasată în fundal, devenind întreruptă ( onPause() );

onRestart( ) – apelată în cazul în care activitatea revine în prim-plan dintr-o stare oprită (stopped); după această, activitate este pornită ( onStart() ) din nou;

onPause( ) – apelată atunci când sistemul aduce în prim-plan o altă activitate; activitatea curentă este mutată în fundal și mai târziu poate fi oprită ( onStop() ) sau repornită și afișată ( onResume() ); acesta este un moment bun pentru a salva datele aplicației într-un mediu de stocare persistent (fișiere, baze de date) deoarece după această faza activitatea poate fi terminată și distrusă fără a se anunță acest lucru.

onStop( ) – apelată în cazul în care activitatea nu mai este utilizată și nu mai este vizibilă deoarece o altă activitate interacționează cu utilizatorul; din acest punct, activitatea poate fi repornită ( onRestart() ) sau distrusă ( onDestroy() );

onDestroy( ) – apelată în cazul în care activitatea este distrusă, iar memoria sa eliberată; acest lucru se poate întâmplă în cazul în care sistemul necesită mai multă memorie sau dacă programatorul termină explicit activitatea apelând metodă finish() din clasa Activity[7].

Tehnologii folosite

3.1 Android Studio

3.1.1 Generalități

Android studio este IDE-ul (Integrated Development Environment) oficial pentru dezvoltarea de sofware pe android. Acesta este bazat pe un nucleu IntelliJ, dar mai are și alte unelte suplimentare, specifice dezvoltării pe android, pentru a face munca mai ușoară pentru programatori. Înainte de Android Studio, programatorii foloseau ca mediu de dezvoltare android, Eclipse împreună cu un ADT (Android Developmnet Tools). Și-a făcut apariția în mai 2013 cu prima versiune 0.1 dată spre testare, iar în decembrie 2014 a apărut și prima versiune stabilă 1.0. Ultima versiune stabilă fiind 2.3.3, voi aborda câteva dintre beneficiile acesteia:

Integrare cu GitHub pentru a importa cod sau pentru a construi părți comune ale aplicațiilor;

Integrarea unor template-uri pentru tipuri de activități comune;

Un sistem Gradle mai flexibil;

Suport C++ și NDK;

Suport încorporat cu Google Cloud Platform;

Instrumente pentru testare mai performante;

Emulator mai performant și mai rapid;

Mediu unificat în care se poate dezvolta pe toate dispozitivele;

Instant Run.

3.1.2 Structura unui proiect

Pentru a putea naviga cu ușurință printre fișierele componente ale unui proiect android, este impotant ca programatorul să cunoască structura acestui proiect. Implicit, structura proiectului este afișată sub forma „Android project view”, însă Android studio ne permite să selectăm și alte 9 view-uri pe langa acesta, în funcție de interesul nostru, acelea fiind: Project, Packages, Scratches, Project Files, Production, Problems, Tests, Local Unit Tests și Android Instrumented Tests. În continuare voi prezenta view-ul sub formă „Android project”, care se împarte în 2 mari părți, anume Application și Gradle Scripts.

Application

Această parte a proectului este structurată la rândul ei în 3 părți:

Manifests: Acest folder conține fișierul AndroidManifest.xml. Acesta este unul dintre cele mai importante fișiere ale unei aplicații Android și este conținut de toate acestea. Aici se definesc informațiile de care are nevoie sistemul înainte de a rula o aplicație, câteva dintre acestea fiind:

permisiunile de care are nevoie sistemul pentru a accesa funcții ale dispozitivului;

descrierea componentelor aplicației: activități, servicii, etc…;

setarea unui nume de pechet ce servește drept identificator unic fiecărei aplicații;

definește relațiile de conexiune între părțile componente ale aplicației sau conexiunile cu alte aplicații;

realizează integrarea cu API-urile folosite în cadrul aplicației.

Figura 3.1 Android Manifest file;

Java: Acest foler conține fișierele sursă ale aplicației, acelea fiind: Clase, Activități, etc…, dar și codul de test JUnit. Practic aici se vor găsi funcționalitățile aplicației pe care programatorul dorește să le implementeze.

Res: După cum spune și numele, în acest folder se găsesc toate resursele unui proiect Android, ce nu conțin cod sursă, organizate în felul următor:

Drawable: în acest director se găsesc toate imaginile din cadrul proiectului, cum ar fi: background-urile de la unele activități, imagini folosite în proiect, etc..; dar poate conține și fișiere .xml, definite de utilizator, care servesc drept model pentru o componență cum ar fi forma sau backgroundul unui buton. Putem spune că este asemenea unui ListAdapter personalizat.

Layout: acest director conține fișierele .xml ce reprezintă interfața grafică a activităților aflate în directorul Java. Se poate spune că aceste fișiere reprezintă partea de front-end pentru aplicațiile android, iar activitățile reprezintă partea de back-end. Sunt formate din unul sau mai multe layout-uri (Linear, Relative, etc…) sau fragmente, ce conțin elemente de interacțiune (Butoane, textViews, etc…), iar acestea formează interfața cu care interacționează utilizatorul.

Mipmap: aici se găsesc iconițele aplicației în diferite dimensiuni, pentru a avea o claritate bună pe orice rezoluție, în funcție de dispozitivul utilizatorului.

Values: în acest director se regăsesc fișiere .xml, care definesc un set de valori care sunt recunoscute în tot proiectul. De exemplu, în fișierul „strings.xml” se pot defini șiruri de caractere folosite în cadrul proiectului cum ar fi: numele aplicației sau cheia de la Google API, sau elementele dintr-un spinner, s.a.m.d. În fișierul ”colors.xml”, după cum îi spune și numele, se pot defini culori în cod hexazecimal, sub un nume stabilit de utilizator.

Gradle Scripts

Figura 3.2 Gradle.build file;

Pe scurt, putem spune că gradle este un build system. Acest sistem ia automat toate fișierele .java sau .xml și aplică unealtă necesară construirii(de exempu dx ia fișierele .java și le transformă în .dex, pentru a putea fi rulate de mașina virtuală Dalvik), după care le grupează într-un fișier comprimat, acesta fiind APK-ul.

Tot în gradle, există și un sistem bazat pe plugin. Acest sistem ne permite introducerea API-urilor și a pachetelor de pe GitHub sau alte surse externe, direct prin compilarea acestora.

Google a implementat acest sistem de construcție, deoarece utilizatorii pot crea scripturi personale, fără a fi necesar să dețină cunoștințe de Groovy sau alte limbaje noi și fără a fi nevoiți să învețe detalii importante de programare „low level” pentru a înțelege ce tool-uri să folosească din SDK.

3.1.3 Interfața grafică

În această secțiune vă voi prezenta pe scurt interfața mediului de dezvoltare Android Studio, pentru a vă familiariza cu aspectul grafic al acestuia.

Figura 3.3 Interfața grafică Android Studio;

Bara de unelte (Toolbar): Aceasta conține scurtături la funcțiile de bază ale unui editor de text (Salvare, Deschidere, Înapoi, Decupare, Lipire, Copiere, etc…), dar și scurtături la câteva funcții principale și des folosite în Android Studio (Rulare, Depanare, Oprire, Build, Android SDK, AVD, etc…);

Bara de navigare (Navigation bar): Aduce o vizualizare mai compactă a casetei ce conține fișierele proiectului și ajută la o navigare mai ușoară între fișiere, pentru editarea acestora;

Editorul de text (Editor window): În această fereastră se întâmplă magia. Aici introducem sau modificăm codul, indiferent de tipul fișierului. Acesta se adaptează tipului de fișier care este deschis, de exemplu: dacă avem deschis un fișier layout de tip .xml, editorul va deveni LayoutEditor.

Bara de instrumente (Tool window bar): Această bară se situează în afara IDE-ului, înconjurând-ul, și deține butoane care extind și comasează instrumente individuale.

Fereastra de instrumente (Tool window): Ne permite accesul la task-uri specifice, cum ar fi: project management, search, console, terminal, android monitor, etc…

Bara de stare (Status bar): Aici se afișează starea curentă a proietului împreună cu mesajele de eroare, avertismentele, durata execuției, etc…

3.2 Android SDK

Generalități

Android SDK (Software Development Kit) este o colecție de tool-uri ce servesc programatorilor la dezvoltarea de aplicații, care folosește cele mai recente caracteristici lansate de pe platforma Android. La fiecare versiune de software Android lansată pe piață, Google atașează și o versiune a SDK-ului corespunzătoare acesteia.

Acest kit de dezvoltare cuprinde o varietate de instrumente necesare dezvoltării aplicațiilor pentru această platformă, unele dintre cele mai importante fiind Managerul Android SDK, Managerul AVD și un emulator al acestora.

Android SDK Manager

Figura 3.4 Managerul Android SDK;

Managerul Android SDK este componentă care conține toate elementele necesare dezvoltării Android, iar acestea sunt organizate în pachete gata de instalare.

După cum se observă și în figura 3.4, sub fiecare versiune de Android există un set de instrumente corespunzătoare acelei versiuni, care este necesar să fie instalat pentu a putea realiza o aplicație compatibilă cu acea versiune. Pe lângă API-uri și servicii, se regăsesc și o serie de instrumente care sunt necesare AVD-urilor, ce vor fi detaliate mai jos.

Managerul AVD

Figura 3.5 AVD Manager;

După cum precizăm și mai deveme, Managerul AVD este furnizat tot de către Android SDK, iar scopul acestuia este de a gestiona lucrul cu dispozitivele virtuale. Un dispozitiv virtual poate fi creat cu o serie de caracteristici personalizate de user, care imită caracteristicile unui dispozitiv real, cum ar fi: memoria RAM, procesorul, dimensiunile ecranului, funcționalități fizice (camera, accelerometru, aspect, etc…). Rostul emulatorului este de a simula acest dispozitiv creat de programator, pentru a testa aplicațiile direct pe el, fără a fi nevoie de un dispozitiv extern conectat.

În figura 3.4 se poate observă la fiecare versiune de SDK, o serie de procesoare ce pot fi descărcate și instalate. Aceste procesoare sunt necesare în simularea cu succes a unui AVD, iar unele dintre aceștia pot fi accelerate cu ajutorul unor software-uri specifice.

Totuși, una dintre cele mai importante unelte în dezvoltare este chiar Androidul în sine, deoarece elimină necesitatea AVD-ului și permite crearea de aplicații, gestionarea proiectelor și actualizarea SDK-ului, direct pe dispozitivul real.

Instrumente de depanare (Debugger)

Un alt instrument important din cadrul SDK-ului este ADB-ul (Android Debug Bridge), acesta fiind responsabil cu depanarea aplicațiilor Android. ADB-ul permite testarea atât pe emulator cât și pe un dispozitiv fizic. În scenariul în care dispozitivul devine „bricked”, adică dispozitivul este blocat sau nu mai pornește, ADB-ul se ocupă cu restaurarea, repornirea acestuia, chiar și instalarea, dezinstalarea de aplicații sau crearea de back-up-uri.

ADB-ul este constituit din 3 părți, anume[9]:

Serverul: procesul care execută în fundal;

Clientul: capătul „bridge-ului” ce rulează pe PC, Laptop, Mac, etc…;

Daemon: capătul „bridge-ului” ce rulează pe dispozitivul sau emulatorul supus testării.

În cazul în care testarea se face pe un dispozitiv fizic, acesta trebuie să aibă modulul de debugging prin USB activat.

Firebase

3.3.1 Generalități

Pentru a putea integra inregistrarea și autentificarea unui utilizator în aplicația realizată, am avut nevoie de o bază de date pentru a stoca credențialele și pentru a le accesa. Am ales Firebase, deoarece este o platformă care permite aceste lucruri și multe altele, dar este și integrată cu Android studio.

Firebase are utilitate pentru pratformele de dezvoltare mobile și web, înființată în anul 2011 de către Andrew Lee și James Tamplin. Compania a fost cumpărată de Google în anul 2014, singura utilitate a acestei platforme fiind o bază de date sincronă pentru un număr vast de clienți. În anul 2016 lista funcționalităților acestei platforme se lungește, astăzi putând beneficia de următoarele servicii:

Firebase Auth;

Firebase Cloud Messaging;

Realtime Database;

Firebase Hosting;

Firebase Storage;

Firebase test lab for Android;

Firebase Crash Reporting;

Firebase integrează multe limbaje de programare cu platforma lor, de exemplu: iOS, Android, JavaScript, Node, etc… Platforma reprezintă un serviciu back-end pentru aplicațiile ce implementează una sau mai multe funcții dintre cele enumerate mai sus.

Implementarea

Înaintea începerii prorpriu-zise a implementării, ca prim pas trebuie să înregistrăm proiectul care se dorește să implementeze servicii oferite de Firebase, pe serverul acestora.

Înregistrarea proiectului este relativ simplă, tot ce trebuie făcut este alegerea platformei de lucru, Android, iOS, sau web, după care se înregistrează pachetul din care face parte aplicația, acesta regăsindu-se în fișierul androidmanifest.xml, descris anterior.

O caracteristică opțională, totuși recomandată, ar fi atașarea unei chei SHA-1, unică fiecărui proiect, care restricționează accesul serviciilor doar pentru acel proiect. Obținerea acestei chei va fi prezentată în cadrul înregistrării proiectului cu Google Maps API.

După obținerea cheii SHA-1 și înregistrarea cu succes a proiectului în cadrul Firebase, mai sunt câțiva pași de urmat pentru a putea începe lucrul cu serviciile acestora.

Serviciul folosit în acest proeict este Firebase Auth, însă acesta, ca oricare altul, trebuie activat și integrat în proiect. Activarea se face în consola Firebase, accesată direct din browser, iar integrarea în proiect se face cu ajutorul sistemului gradle, pe care l-am descris anterior.

Figura 3.6 Dependențele Firebase;

Ca ultim pas mai trebuie adăugate și librăriile folosite în proiect. Am adăugat mai multe dintre acestea pentru o dezvoltare ulterioară a aplicației.

Figura 3.7 Integrarea librăriilor Firebase în proiect;

Google Maps API V2

3.4.1 Generalități

API-ul (Application Programming Interface) este un set de proceduri și instrumente care permit crearea aplicațiilor ce accesează date de la o altă aplicație sau serviciu. În consola Google se regăsesc mai multeAPI-uri cu diferite funcții cum ar fi: hărți, traducere, mail, etc… Pachetul acestor servicii se numește Google play services, acesta fiind responsabil pentru comunicarea aplicațiilor cu serviciile Google.

În acest proiect se utilizează API-ul ce se ocupă cu gestionarea hărților. Voi detalia subiectul cu Google Maps API în câteva momente, dar mai întâi vreau să menționez faptul că acest API implementează hărțile prin GPS.

GPS (Global Positioning System)

Cu ceva timp în urmă, GPS-ul era considerat o tehnologie rară. În prezent, majoritatea dispozitivelor mobile implementează această tehnologie.

GPS-ul reprezintă o rețea de sateliți care orbitează în jurul planetei și trimit detalii specifice privind poziția lor, înapoi pe pământ. Semnalele sunt traduse de receptorii GPS, cum ar fi dispozitivele ce calculează poziția, viteza și timpul unei mașini într-o locație. Înainte ca semnalul să fie obținut de aceste dispozitive receptoare, pentru o acuratețe mai mare, semnalul este captat de cele mai apropiate 3 releuri de poziția dorită, prin triangulație.

Sistemul GPS a fost dezvoltat în anii 1960 de către americani, pentru o navigare mai ușoară a unităților navale pe oceane. Din anii 1980, acest serviciu a fost dat liber și gratuit înspre utilizare, oricui avea un receptor GPS.

Sistemul GPS este format din 3 parți numite segmente[10]:

Segmentul spațial: este alcătuit din rețeaua de 31 de sateliți din orbită (februarie 2016), care transmit semnale modulare. Fiecare dintre aceștia emit câte două unde radio, una receptată de sistemul militar și una de sistemul civil;

Segmentul de control: se află pe pământ și este alcătuit din stații de recepție cu rolul de a intercepta toate mesajele de la toți sateliții și de a calcula poziția fiecăruia, retransmițând-o înapoi la sateliți;

Segmentul de utilizator: reprezintă mulțimea utilizatorilor care folosesc un receptor GPS, indiferent dacă este militar sau civil.

Am tot amintit de acești receptori GPS, însă nu am dat nicio definiție pentru ei, așadar, un receptor GPS este un aparat capabil de a percepe semnalele emise de sateliți prin care poate determina poziția sa pe Pământ, sub formă de coordonate, care sunt reprezentate în sistemul geodezic mondial WGS84. Locația este exprimată în plan 2D prin latitudine și longitudine.

Majoritatea dispozitivelor mobile au preinsatalata o aplicație ce implementează un software pentru navigație. Cel mai popular printre acestea este Google Maps, iar acesta va fii folosit și în acest proiect.

Implementarea și consola Google pentru dezvoltatori

Înainte de a putea folosi API-ul oferit de Google în proiectul nostru, acesta va trebui înregistrat cum că implementează servicii oferite de Google. Procesul este absolut gratuit, însă absolut necesar pentru ca astfel de aplicații să funcționeze.

Acest lucru poate fi realizat în consola pentru dezvoltatori Google, ce se accesează direct din browser și arată în felul următor:

Figura 3.8 Consola pentru dezvoltatori Google 1;

După cum spuneam, în această consolă vom crea un proiect nou cu numele aplicației (punctul 1 din figura 3.8), iar după ce crearea a fost finalizată cu succes, se vor activă API-urile care dorim să le utilizăm în proiect (punctul 2 din figura 3.8).

La apăsarea butonului „Enable API’s and services”, consola va trece în tab-ul Library, unde se pot vizualiza toate API-urile și servcile care pot fi incluse în proiectul dvs. În acest proiect singurul API de care vom avea nevoie este Google Maps Android API v2.

Figura 3.9 Consola pentru dezvoltatori Google 2;

După selectarea API-ului dorit și activarea acestuia, Google va oferi o cheie unică (API key), care trebuie introdusă în fișierul androidmanifest.xml al proiectului, pentru a putea beneficia de acest API.

Figura 3.10 Introducerea cheii în proiect;

Pentru siguranță și securitate în aplicația dvs., această cheie trebuie restricționată pentru proiectul în care doriți să o utilizați, iar restricționarea acesteia se face prin atașarea unor credențiale în consola.

Figura 3.11 Consola pentru dezvoltatori Google 3;

Datele necesare pentru restricționare sunt: numele pachetului din care face parte aplicația și amprenta digitală SHA-1. Numele pachetului se găsește în fișierul androidmanifest.xml din cadrul aplicației, iar amprenta SHA-1 se obține prin aplicarea unei comenzi asupra a două fișiere, anume „keytool-ul” din cadrul JDK-ului (Java Developement Kit) și „keystore-ul” din cadrul Android SDK-ului.

Odată ce cheia API-ului a fost introdusă în proiect, tot ce rămâne de făcut este obținerea hărții prin cod. Pentru a folosi harta în cadrul unei aplicații android se poate folosi un MapFragment sau MapView. Acestea reprezintă două tipuri de layout-uri din cadrul fișierelor .xml, harta fiind descărcată automat pe bucăți și vizualizată in acestea. În acest proiect este utilizat MapFragment.

MapFragment-ul acționează că un suport pentru harta, această putând fii mutată, mărită, micșorată, înclinată, etc…

Google Maps oferă 5 tipuri de harți:

Normal – conține elemente din natură și drumuri;

Hibrid – conține imagini din satelit și drumuri;

Satelit – conține doar imagini din satelit;

Teren – conțin date topografice;

Niciuna – conține doar grile goale.

Figura 3.12 Tipuri de hărți;

Informații suplimentare despre vederile și implementarea hărții se vor găsi în secțiunea de implementare a aplicației.

Analiză, Proiectare și Implementare

Analiza

În ceea ce privește construirea și dezvoltarea aplicației, am analizat mai multe programe disponibile în momentul prezent. Având în vedere că dezvoltarea pe Android are o amploare foarte mare la ora actuală și că pentru dezvolatrea pe iOS este necesară detinerea unui dispozitiv ce rulează macOS sau o mașină virtuală cu acest sistem de operare, m-am decis să implementez această aplicație pe Android.

Ca medii de dezvoltare ale aplicației am luat în considerare Xamarin împreună cu Visual Studio și Android Studio. Limbajul de programare nativ pentru Android este Java, iar aplicațiile implementate cu Xamarin, spre deosebire de cele implementate cu Android Studio, folosesc C# ca limbaj de programare. La început, am considerat Xamarin pentru a realiza implementarea, deoarece personal, mereu am fost mai atras de C# decât de Java, însă după realizarea unei variante inițiale a aplicației în Xamarin, neavând o experiență vastă în realizarea aplicațiilor mobile, iar sursa principală de informații fiind internetul, m-am regăsit în postura în care informațiile în concordanță cu Java erau mai accesibile decât cele cu C#. Așadar, într-un final am ales ca mediu de dezvoltare Android Studio.

La ora actuală, pe piață există diferite tipuri de aplicații ce măsoară suprafețe de teren prin coordonate GPS, însă marea majoritate sunt cu caracter profesional ce necesită anumite cunoștințe pentru a fi utilizate, sau sunt inaccesibile multora dintre utilizatori.

Luând în considerare faptul că în prezent tot mai multă lume folosește smartphone-uri, scopul principal al acestui proiect a fost de a oferi o interfață intuitivă și cât mai ușor de folosit, indiferent de utilizator. De asemenea, s-a încercat pe cât se poate că aplicația să fie bine structurată pentru a fi ușor de îmbunătăți și actualizat.

4.2 Proiectarea

Pentru etapa de proiectare am pregătit două tipuri de diagrame, anume diagrama claselor UML și diagrama cazurilor de utilizare. Datorită structurii acestor diagrame se pot înțelege cu ușurință principiile de funcționare și structura aplicației.

Diagrama claselor (UML)

In aceasta diagrama se pot observa activitățile aplicației, împreuna cu legăturile de asociere și împlementarea interfețelor necesare realizării acesteia.

Cu portocaliu sunt prezentate clasele activităților, împărțite în 3 secțiuni:

În prima secțiune se observă numele clasei;

În a doua secțiune avem atributele împreună cu tipul acestora;

În a treia secțiune sunt metodele (operațiile) din cadrul clasei cu tot cu specificatorii tipului de date returnat.

Cu alb sunt afișate interfețele implementate de clasa MapActivity. Acestea au tot aceeași structură de 3 secțiuni, însă deoarece interfețele sunt abstracte, în clasa care le implementează trebuie suprascrise metodele și atributele ce dorim să le utilizăm, așa că le-am adugat doar pe cele folosite.

Figura 4.1 Diagrama claselor UML;

Diagrama cazurilor de utilizare (UML)

Prin această diagramă s-a încercat acoperirea cât mai bună a cazurilor în care se poate află utilizatorul în interacțiunea sa cu aplicația. Această are scopul de a observa și analiza acțiunile utilizatorului asupra aplicației și ce cazuri pot apărea în diferite instanțe ale sale.

Figura 4.2 Diagrama cazurilor de utilizare;

Structura acestei diagrame este formată din:

Actori: în cazul de față este utilizatorul;

Sistem: acesta este fundalul gri ce conține toate elementele, reprezentând de fapt toată aplicația;

Cazuri: ovalele verzi reprezintă cazurile de utilizare ale aplicației;

Relații: săgețile dintre elementele diagramei reprezintă tipul relației dintre acestea.

Implementarea

4.3.1 Mediul de dezvoltare

Generalități despre mediul de dezvoltare folosit au fost prezentate anterior în această lucrare, așa că aici voi aminti pe scrut. IDE-ul folosit este Android Studio și reprezintă 90% din implementare, iar pentru înregistrarea și autentificarea utilizatorilor am folosit Firebase.

Uneltele necesare pentru implementarea unui proiect Android:

JDK (Java Development Kit) – de preferat ultima versiune stabilă;

IDE (Integrated Development Environment) – Android Studio în acest caz;

SDK (Android SDK) – pentru API-urile necesare dezvoltării;

AVD (Android Virtual Device) sau un dispozitiv fizic – pentru testare;

Crearea și configurarea unei aplicații

Asumând faptul că uneltele precizate mai sus sunt instalate, pentru crearea unei aplicații se deschide Android Studio și se selectează opțiunea Start a new Android Studio project.

Figura 4.3 Crearea unui proiect nou;

După finalizarea acestui pas, fereastra următoare va reprezenta începutul configurării proiectului dvs.

Figura 4.4 Configurarea unei aplicații 1;

În această fereastră va fii necesar să introduceți numele aplicației, domeniul, iar din acestea se va forma numele pachetului corespunzător. În josul ferestrei se poate selecta și locația unde doriți să salvați proiectul.

Figura 4.5 Configurarea unei aplicații 2;

În fereastra din figura 4.5 se va configura platforma pe care se dorește dezvoltarea aplicației și cel mai mic API Android pe care aceasta poate rula. Cu cât API-ul selectat este mai mic, cu atât raza de acoperire a dispozitivelor este mai mare, dar în același timp și funcționalitățile ce pot fi implementate sunt în număr redus, deoarece un nivel mai scăzut al API-ului conține mai puține caracteristici țintind și dispozitive mai vechi care sunt depreciate. Cu cât API-ul selectat este mai mare, performanța și caracteristicile acestuia sunt ridicate, însă numărul de dispozitive care pot rula aplicația este limitat.

În cazul de față s-a ales API 21: Android 5.0 (Lollipop), deoarece are o vechime de 3 ani, acesta fiind lansat la sfârșitul anului 2014, și o acoperirie de 71.3% din piața dispozitivelor ce sunt active în Google Play Store. Totodată am ales acest nivel de API deoarce dispozitivul pe care am realizat testarea rulează versiunea Android 5.1.1 (Lollipop).

Telefoanele și tabletele fiind cele mai răspândite dintre dispozitivele cu Android, această platformă a fost și target-ul ales în proiect.

Figura 4.6 Configurarea unei aplicații 3;

Deoarece orice aplicație Android conține cel puțin o activitate, Android Studio ne oferă opțiunea de a adăuga una direct din faza de configurare. Activitatea selectată va deveni cea principală până la intervenția programatorului în acest aspect.

În figura 4.6 se observă un set de șabloane pentru activități, acestea fiind ajutătoare programatorului, fiecare având un caracter specific, util în functe de tipul aplicației dorite.

În cazul în care se alege crearea unei activități după unnul dintre șabloane, automat se va genera și un fișier .xml corespunzător acestuia. Dacă se selectează o activitate necompletată (Empty Activity), în fereastră următoare există posibilitatea de a atașa și un fișier .xml necompletat, după dorința programatorului.

Figura 4.7 Configurarea unei aplicații 4;

Figura 4.7 reprezintă ultimul pas în configurarea aplicației. Tot ce rămâne de făcut este selectarea numelui activității și a fișierului .xml. Orice activitate creată moștenește clasa Activity, dar la selectarea opțiunii Backwards Compatibility, activitatea va moșteni clasa AppCompatActivity, această la rândul ei fiind extinsă tot de clasa Activity, dar aduce câteva noțiuni de estetică, cum ar fi corelarea între tema aplicației și bară de activități.

La câteva momente după apăsarea butonului Finish, Android Studio va intra în forma prezentată în figura 3.3, de unde puteți începe implementarea ulterioară a aplicației.

Configurarea dispozitivului sau emulatorului

Configurarea dispozitivului mobil

Pentru încărcarea și rularea cu success a unei aplicații pe un dispozitiv mobil, acesta trebuie să aibă modulele de dezvoltare și debugging active. În general, majoritatea dispozitivelor mobile vor deschide automat fereastră din figura 4.8 în momentul conectării acestuia la un PC sau Laptop. Dacă fereastra nu apare automat, aceasta se poate găsi în setările dispozitivului.

Figura 4.8 Configurarea dispozitivului mobil;

Configurarea emulatorului

Pentru a putea încarcă aplicația pe un emulator, în primul rând trebuie să se creeze unul. Acest lucru se realizează din AVD Manager, făcând click pe buton Create New Virtual Device. Puteți vizualiza interfață grafică a managerului AVD în figura 3.5. După ce s-a făcut click pe butonul de Create New Virtual Device, se va deschide fereastră din figura 4.9.

Figura 4.9 Crearea unui dispozitiv virtual;

După selectarea modelului de dispozitiv, următoarea setare pe care va trebui să o facem este selectarea versiunii API-ului care să fie instalat pe emulator. Managerul AVD va descarcă versiunea dorită și o va instala automat pe dispozitivul virtual, acesta funcționând la fel că un dispozitiv fizic, însă spre deosebire de cel fizic, emulatorul nu își poate adapta API-ul la o versiune mai nouă, iar pentru acest lucru va trebui creat unul nou.

Figura 4.10 Configurarea emulatorului;

Ultima parte din configurarea emulatorului ține de denumirea și dimensionarea dispozitivului, dar și adăugarea unor caracteristice fizice cum ar fi: camera foto, performanțe grafice, performanțe hardware referitoare tipul de procesor și memoria Cache a acestuia, sau memoria RAM.

După configurarea cu succes a dispozitivelor și a IDE-ului, totul este pregătit pentru dezvoltarea completă a unei aplicații Android.

Implementarea aplicației

Acest proiect este format din 4 activități care comunică intre ele, anume:

Login Activity;

Register Activity;

Map Activity;

Help Activity;

Fiecare are o funcție bine definită care va fi prezentată mai ulerior.

Login Activity

Figura 4.11 Activitatea de logare a utilizatorului;

Am început cu această activitate, deoare este activitatea principala a aplicației, adică este prima cu care interacționează utilizatorul după pornirea aplicației.

După cum se poate observă în figura 4.11, elementele regăsite în această activitate sunt: două câmpuri EditText, un TextView și două Butoane. În spatele acestora este și o imagine de fundal personalizată pentru a fi în tema cu aplicația, dar totodată fără a reduce vizibilitatea elementelor de interacțiune. Câmpurile EditText au, în mod implicit, sugestii cu ce trebuie introdus, iar butoanele au numele acțiunii care este implementată fiecăruia.

Această activitate este conectată cu alte două activități, anume activitatea de înregstrare a utilizatorului (figura 4.12) și activitatea cu harta (figura 4.13). Navigarea între aceste activități se face prin apăsarea butoanelor, fiecare fiind legat la o altă interfață.

În cazul în care datele introduse în câmpurile E-mail și Password se află înregistrate în Firebase, la apăsarea butonului LOGIN, aplicația va trece în activitatea hărții, iar aceasta va fi distrusă. În cazul în care datele nu sunt înregistrate, utilizatorul trebuie să treacă la interfață de înregistrare, prin apăsarea butonului REGISTER, unde își va putea înregistra un cont cu care se poate loga.

Register Activity

Figura 4.12 Activitatea de înregistrare a utilizatorului;

După apăsarea butonului REGISTER din activitatea de logare, fereastra din figura 4.12 va fii deschisă. În această activitate se regăsesc următoarele elemente: 4 câmpuri EditText, un RadioGroup cu două RadioButtons și încă două Butoane.

La apăsarea butonului REGISTER, contul utilizatorului va fii salvat în Firebase, însă ca acest lucru să fie realizat cu succes, toate câmpurile trebuie completate cu date valide și corespunzătoare cerinței fiecăruia.

User Name – numele utilizatorului; poate conține cifre, litere și caractere speciale;

Password – parola stabilită de utilizator; poate conține doar cifre și litere și trebuie să fie minim 6 caractere pentru a fi validă;

Re-enter password – trebuie să aibă exact același conținut ca și câmpul password;

E-mail – se introduce o adresă de email de forma standard user@gmail.com;

Gender – se selectează una dintre cele două opțiuni.

În colțul din stânga sus este un buton sub formă de săgeata. În cazul înregistrării cu succes a contului de utilizator, acest buton va trece direct la activitatea hărții. În cazul în care utilizatorul nu s-a înregistrat cu succes, acest buton va trece înapoi la activitatea de logare.

Map Activity

Figura 4.13 Activitatea hărții;

La autentificarea cu succes a unui utilizator înregistrat în Firebase, se va deschide fereastra din figura 4.13. Aceasta va fi fereastra cu cea mai mare interacțiune, așa că voi detalia puțin implementarea acestiea și a elementelor corespunzătoare.

În secțiunea 3.4.3 am explicat faptul că harta trebuie conținută de un layout de tip fragment. În figura 4.13 se poate observa rezultatul acelui fragment ce conține harta. Primu pas fiind realizat, rămân de implementat funcționalități ale hărții.

În primul rând, elementele regăsite în această interfață sunt doar două Butoane și un Spinner, restul funcționalităților fiind implementate prin gesturi.

Butonul negru din colțul dreapta jos este butonul de deconectare a utilizatorului. La apăsarea acestu buton aplicația va reveni la activitatea de logare. Butonul din colțul stânga jos va face aplicația să treacă din activitatea curentă în activitatea de ajutor, pentru informații suplimentare asupra utilizării funcțiilor. Voi detalia această activitate în secțiunea următoare.

Spinner-ul din colțul dreapta sus oferă posibilitatea de a selecta între tipurile de hărți oferite de Google, care au fost prezentate în figura 3.12. Selectarea tipului de harta poate conta în funcție de ce fel de suprafață se dorește a fi măsurată.

In continuare vor fi prezentate operatiile prin care se realizează calculul suprafeței.

Adăugarea unui marcator pe hartă;

public void onMapClick(final LatLng latLng) {

if (isClicked == false) {

mMap.addMarker(new MarkerOptions()
.draggable(true)
.position(latLng)
.icon(BitmapDescriptorFactory.defaultMarker(

BitmapDescriptorFactory.HUE_CYAN))
.title(String.format("%.3f", latLng.latitude) + "," + String.format("%.3f", latLng.longitude)));
arrayList.add(latLng);
}

Activitatea hărții implementeaz interfata OnMapClickListener, si prin suprascrierea metodei din acceast interfata, putem adauga markerii la locatia atingerii ecranului.

Obiectul Map reprezintă harta pe care o vizualizam în fragment, iar addMarker este una dintre operațiile ce pot fi efectuate pe hartă. Această operație adaugă pe hartă un marker de tipul MarkerOptions, care are un set de caracteristici pentru fieare marker în parte. Cea mai importantă caracteristică, care este și necesară, este position. Prin această caracteristică se specifică locația la care se amplasează marker-ul pe hartă. În cazul de față, această poziție este obținută de la atributul metodei onMapClick, ceea ce ne permite să amplasăm marker-ul la poziția atingerii hărții. Celelalte atribute sunt pentru personalizarea acestora, de exemplu: icon poate schimba formă sau culoarea marcatorilor, title adaugă un titlu, vizibil la apăsarea pe marker, draggable activează opțiunea ca marcatorii să poată fi mutați, s.a.m.d.

Linia de cod „arrayList.add(latLng)” va salva poziția fiecărui marcator plasat pe hară într-un tablou bidimensional ce conține date de tip LatLng, adică coordonate. Acest tablou va fi folosit pentru a forma poligonul format din punctele amplasate de utilizator.

Formarea poligonului;

public void polygonPoints() {

if (arrayList.size() >= 3) {
isClicked = true;
polygon = mMap.addPolygon(new PolygonOptions()
.clickable(true)
.addAll(arrayList)
.strokeColor(Color.CYAN)
.strokeWidth(3)
.fillColor(Color.argb(127, 255, 0, 0)));

}
}

În metoda „polygonOptions()” se creează practic poligonul. Prima condiție pentru a putea face acest lucru este să înțelegem ce înseamnă un poligon. Un poligon reprezintă o formă neregulă închisă, formată din 3 sau mai multe puncte, deoarece două puncte sunt întotdeauna coloniare și nu se poate forma o suprafață închisă doar din acestea. Așadar am pus condiția ca mulțimea punctelor salvate în arrayList să fie mai mare sau egală cu 3. În momentul în care această condiție este îndeplinită putem forma un poligon cu acele puncte, prin operația addPolygon.

Caracteristica principală a acestuia este adăugarea punctelor, cu metoda addAll(arrayList). În momentul acesta poligonul este format, restul metodelor fiind pentru personalizare. Am activat opțiunea ca poligonul să fie clickable, deoarece la efectuarea unui click pe acesta, se va obține aria suprafeței formate de poligon, într-un mesaj Toast.

Calculul suprafeței;

Codul pentru calculul suprafeței este conținut de o metodă numită „computeArea()”, din pacetul SphericalUtil. Metodă a fost invocată în cadrul listener-ului la efectuarea unui click pe poligon, și transmite un mesaj de tip Toast cu aria poligonului calculată în metrii pătrați.

Codul metodei „computeArea()” este relativ vast pentru a fi introdus în această documentație, însă îl puteți vedea în proiectul atașat.

Curățarea hărții.

public void onMapLongClick(LatLng latLng) {

mMap.clear();
arrayList.clear();
isClicked = false;
}

După ce suprafața dorită a fost formată și măsurată, la apăsarea lungă a ecranului, înafara poligonului, toate elementele adăugate vor fi curățate pentru a putea efectua altă măsurare.

Cu „mMap.clear()” se va curăța harta de elementele adăugate, iar cu „arrayList.clear()” se vor șterge coordonatele salvate. După ce ștergerea a fost efectuată, poligonul revine în starea inițială.

Help Activity

Figura 4.14 Activitatea cu informații despre utilizare;

Deoarece majoritatea funcționalităților sunt realizate cu gesturi, un utilizator nu are de unde să știe toate uneltele și operațiile aplicației. Așadar am implementat o activitate ce arată, clar și pe scurt, care sunt utilitățile aplicației.

Activitatea este compusă dintr-un TextView și un Buton. În interiorul TextView-ului este încărcat un fișier de tip text, care se află în folderul cu asset-urile aplicației. Fișierul text conține un scurt manual de instrucțiuni în limba engleză. Butonul din colțul dreapta jos, sub formă de săgeata de culoarea albastră, are rolul de a trece aplicația înapoi la activitatea hărții, odată ce utilizatorul a terminat de citit informațiile. Această activitate se poate accesa oricând în timpul funcționarii, dar va întrerupe procesele ce rulează în activitatea hărții.

Testare și Validare

După finalizarea aplicației, pasul următor este testarea acesteia, deoarece trebuie să ne asigurăm că nu apar eventuale probleme cu interfață sau funcționalitatea, dar și că aceasta se ridică la așteptările menționate. Câteva dintre aspectele testate vor fi prezentate mai jos, iar cele mai importante dintre acestea vor fi evidențiate printr-o serie de imagini drept dovezi.

Crearea unui cont de utilizator;

Login/ Logout;

Interfață;

Menținerea autentificării;

Validarea campurilor de text;

Corectitudine și coerență în text;

Compatibilitatea cu diferite dispozitive;

Integrarea cu Google Maps;

Corectitudinea coordonatelor;

Corectitudinea măsurării;

Performanța aplicației.

Testarea a fost realizată de mine, dar și de alți colegi, prieteni sau membri ai familie, scopul fiind de a observa aplicația utilizată de mai multe tipuri de utilizatori, cu mai multe sau mai puține cunoștințe legate de acest domeniu.

În continuare se vor observa câteva din testele realizate pe interfețele de logare, înregistrare și corectitudine a măsurării.

Figura 5.1 Testare interfață de logare;

Pentru interfața de logare am testat atât adrese de email sub formă greșită cât și modele corecte, dar neînregistrate în Firebase. Până la introducerea unui cont de utilizator valid, aplicația va afișa mesajul din figura 5.1. Mai există și cazul în care nu se introduce nimic, unde aplicația va afișa un Toast cu mesajul „Please enter a registered account”.

Figura 5.2 Testare interfață de înregistrare;

În interfața de înregistrare pot apărea tot felul de erori în funcție de fieare câmp, acestea având mesaje de notificare independente. În secțiunea 4.3.4.2 am menționat ce fel de date trebuie să conțină fiecare câmp pentru a putea înregistra cu succes un utilizator.

La introducerea corectă a tuturor câmpurilor, utilizatorul va primi un mesaj de notificare cum că a fost înregistrat cu succes, iar acesta se poate loga cu contul proaspăt creat.

Dintre aceste câmpuri, cele care contează sunt email și password, deoarece aceste date vor fii folosite pentru autentificare. Celelate câmpuri sunt obligatorii de introdus pentru a crea cu succes un cont, deoarece ele vor fii folositoare la consituirea unui profil de utilizator într-o bază de date, pe viitor.

Figura 5.3 Suprafața caminului 7 Observator;

Figura 5.4 Suprafața terenului Cluj Arena;

Pentru a verifica corectitudinea măsurătorii, am ales o suprafață de teren cunoscută, aceea fiind terenul de fotbal din Cluj Arena (figura 5.4). Conform unui articol realizat în anul 2011 [11], terenul are 105m lungime și 68m lățime, însemnând 7140m2. Doarece măsurătoarea din aplicație se face cu click-ul ci nu prin coordonate exacte, are o eroare relative mică. Tehnic vorbind, nu putem pune marcatorul pe hartă exact în același punct în care putem pune ruleta pe iarbă. Așadar chiar dacă nu am reușit să fixăm punctele exact în colțurile terenului, suprafață selectată tot este correct calculată.

Concluzii

Rezultate

Implementarea aplicației prezentată în acest document, ce poartă numele EriaGon, a reprezentat o provocare personală și un drum spre cunoștințe noi. Înainte să mă apuc de acest proiect, singurele cunoștințe legate de mobile development pe care le dețineam, erau acumulate în cadrul laboratorului de „Transmisia datelor”, din cadrul facultății. În momentul în care am ales această tema, primul scop ce l-am avut în minte a fost să învăț dezvoltare de aplicații pe dispozitive mobile.

Am considerat această tema de aplicație o experiență benefică în dezvoltarea personală și profesională, deoarece, în prezent, există o varietate de locuri de muncă pe piață, în care informațiile acumulate pe parcursul acestui proiect sunt valoroase.

Pentru partea de implementare am avut de studiat destul de multe documente de natură diferită: cărți de specialitate, site-uri academice, tutoriale online, etc… Indiferent ce specializare aveau informațiile, OOP, Android, Firebase sau Google Maps, acestea au fost necesare pentru a obține produsul final în întregime și mi le-am însușit cu drag. Bineînțeles, am întâmpinat și momente în care nu credeam că voi putea implementa aplicația cu succes în întregime , însă răspunsul era la o pagină distanță sau cu un paragraf mai jos.

După cum am precizat și la inceputlul lucrării, pe lângă viteză, în ziua de azi contează foarte mult accesibilitatea la informație și portabilitatea acesteia. Așadar, rezultatele obținute consider că au atins obiectivele setate la început, acestea fiind mai multe decât cele cerute de tema în sine. Obiectivele au fost împărțite la rândul lor în task-uri mai mici, pentru o structurare mai ușoară.

În cadrul unei corporații din domeniu, împărțirea sarcinilor este bine stabilită de la începutul fiecărui proiect, însă în acest proiect individual, analizarea, proiectarea, structurarea și implementarea au fost realizate de o singură persoană. Consider că aplicația poate fii îmbunătățită din foarte multe perspective de la design la implementare de funcționalități noi, dar ce este realizat în momentul de față constituie un prototip reușit ce poate servi drept punct de start pentru o dezvoltare ulterioară.

Contribuții personale

Pe parcursul acetui document s-a prezentat procesul de realizare a unei aplicații mobile pe Android, atât din punct de vedere al funcțiilor cât și ale design-ului. Tema cerută de acest proiect a fost implementarea unei aplicații mobile ce poate măsură suprafețe de teren prin coordonate GPS, practic tot ce se întâmplă în activitatea hărții. În plus pe lângă funcționalitatea principală, au fost aduse caracteristici ce vor fi folositoare pentru o dezvoltare ulterioară, despre care voi discuta puțin mai jos.

Funcționalitățile implementate pe lângă tema inițială sunt:

Crearea unei interfețe user-friendly care facilitează utiliarea aplicației pentru orice fel de utilizator;

Posibilitatea de înregistrare a unui cont de utilizator;

Posibilitatea de logare a utilizatorului;

Un manual de instrucțiuni ce cuprinde tot ce este necesar în utilizarea aplicației;

Implementarea neîncărcată a interfețelor, în așa fel încât să se distingă cu ușurință elemntele componente.

Direcții de dezvoltare

După cum am precizat anterior, această aplicație poate fii îmbunătățită în fel și chip, starea actuală fiind o versiune incipientă a sa, ce poate sta la baza unor dezvoltări ulterioare.

Utilizatorii vor de la o aplicație să fie cât mai complexă din punct de vedere al setului de funcționalități, dar și cât mai compactă în același timp. Câteva dintre funcționalitățile pe care vreau să le implementez pe viitor sunt prezentate mai jos:

Facebook and Google Login – tot mai multe aplicații de orice fel au început să abordeze această tehica de logare, deoarece majoritatea utilizatorilor au un profil de Facebook sau Google și este mai rapid și mai ușor să se importeze setările de la aceste profile, cu un singur click, decât crearea unuia nou;

Map Search – opțiunea de a căuta locații pe hartă prin introducerea de cuvinte cheie;

Database points – posibilitatea de a salva punctele dorite de pe harta, într-o bază de date;

Database areas – posibilitatea de a salva măsurătorile efetuate într-o bază de date, pentru comparare sau folosire ulterioară;

Posibilitatea de a formă poligonul măsurat direct prin introducerea coordonatelor;

Posibilitatea de a formă mai multe poligoane în același timp;

Reproiectarea aplicației pentru optimizare.

Bibliografie

https://www.theverge.com/2017/2/16/14634656/android-ios-market-share-blackberry-2016

https://en.wikipedia.org/wiki/Android_(operating_system)

https://www.phonearena.com/news/Googles-Android-OS-Past-Present-and-Future_id21273

OOP Concepts in Java: Defined and Explained with Examples

https://www.javatpoint.com/java-oops-concepts

http://pdsd2014.andreirosucojocaru.ro/wiki/laboratoare/laborator00

http://www.itcsolutions.eu/2011/09/08/android-tutorial-concepte-activitati-si-resurse-ale-unei-aplicatii-android/

https://developer.android.com/studio/intro/index.html

http://www.makeuseof.com/tag/new-adb-make-process-simple-easy/

https://ro.wikipedia.org/wiki/Global_Positioning_System

http://ziuadecj.realitatea.net/sport/terenul-de-pe-cluj-arena-cel-mai-mare-din-liga-i–75338.html

https://stackoverflow.com/questions

https://github.com/

Mark Murphy, „Beginning Android 3”, APress, 2011

http://studytipsandtricks.blogspot.ro/2012/04/features-of-object-oriented-programming.html