lurar linŢĂ - profs.info.uaic.roalaiba/pub/absolvire/2017 iarna/auto service finder.pdf · un...

47
UNIVERSITATEA „ALEXANDRU IOAN CUZA” IAŞI FACULTATEA DE INFORMATICĂ LUCRARE DE LICENŢĂ Auto Service Finder propusă de Lucău Andrei Iulian Sesiunea: februarie, 2017 Coordonator ştiinţific Asist. Dr. Vasile Alaiba

Upload: others

Post on 22-Oct-2019

10 views

Category:

Documents


0 download

TRANSCRIPT

UNIVERSITATEA „ALEXANDRU IOAN CUZA” IAŞI

FACULTATEA DE INFORMATICĂ

LUCRARE DE LICENŢĂ

Auto Service Finder

propusă de

Lucău Andrei Iulian

Sesiunea: februarie, 2017

Coordonator ştiinţific

Asist. Dr. Vasile Alaiba

UNIVERSITATEA „ALEXANDRU IOAN CUZA” IAŞI

FACULTATEA DE INFORMATICĂ

Auto Service Finder

Lucău Andrei Iulian

Sesiunea: februarie, 2017

Coordonator ştiinţific

Asist. Dr. Vasile Alaiba

DECLARAŢIE PRIVIND ORIGINALITATE ŞI RESPECTAREA

DREPTURILOR DE AUTOR

Prin prezenta declar că Lucrarea de licenţă cu titlul „Auto Service Finder” este scrisă de mine şi nu a

mai fost prezentată niciodată la o altă facultate sau instituţie de învăţământ superior din ţară sau

străinătate. De asemenea, declar că toate sursele utilizate, inclusiv cele preluate de pe Internet, sunt

indicate în lucrare, cu respectarea regulilor de evitare a plagiatului:

toate fragmentele de text reproduse exact, chiar şi în traducere proprie din altă limbă, sunt

scrise între ghilimele şi deţin referinţa precisă a sursei;

reformularea în cuvinte proprii a textelor scrise de către alţi autori deţine referinţa precisă;

codul sursă, imaginile etc. preluate din proiecte open-source sau alte surse sunt utilizate cu

respectarea drepturilor de autor şi deţin referinţe precise;

rezumarea ideilor altor autori precizează referinţa precisă la textul original.

Iaşi, data

Absolvent Lucău Andrei Iulian

_________________________

DECLARAŢIE DE CONSIMŢĂMÂNT

Prin prezenta declar că sunt de acord ca Lucrarea de licență cu titlul „Auto Service Finder”, codul

sursă al programelor şi celelalte conţinuturi (grafice, multimedia, date de test etc.) care însoţesc

această lucrare să fie utilizate în cadrul Facultăţii de Informatică.

De asemenea, sunt de acord ca Facultatea de Informatică de la Universitatea „Alexandru Ioan Cuza”

Iași să utilizeze, modifice, reproducă şi să distribuie în scopuri necomerciale programele-calculator,

format executabil şi sursă, realizate de mine în cadrul prezentei lucrări de licenţă.

Iaşi, data

Absolvent Lucău Andrei Iulian

_________________________

Cuprins

Introducere ................................................................................................................................................... 1

Contribuții ..................................................................................................................................................... 3

1. Tehnologii folosite .................................................................................................................................... 4

1.1 iOS SDK ............................................................................................................................................... 4

1.2 XCode .................................................................................................................................................. 5

1.3 Google Maps iOS SDK ......................................................................................................................... 6

1.4 Eclipse ................................................................................................................................................. 6

1.5 Jetty: framework Java ........................................................................................................................ 6

1.6 MySQL ................................................................................................................................................. 7

2. Analiza soluției ......................................................................................................................................... 8

3. Proiectare ................................................................................................................................................. 9

3.1 Arhitectura soluției ............................................................................................................................ 9

3.2 Client – aplicația iOS ........................................................................................................................... 9

3.2.1 MVC – Model ............................................................................................................................. 11

3.2.2 MVC - View ............................................................................................................................... 14

3.2.3 MVC – Controller ....................................................................................................................... 16

3.3 Server ................................................................................................................................................ 29

4. Manual de utilizare ................................................................................................................................ 34

5. Concluzii .................................................................................................................................................. 41

6. Bibliografie ............................................................................................................................................. 42

1

Introducere

Motivație

Auto Service Finder este o aplicație dezvoltată pe platforma iOS care se adresează

șoferilor auto și managerilor de garaje.

Aplicația dorește să vină în sprijinul șoferilor puși în dificultatea de a nu ști la ce service

auto să apeleze în cazul unor probleme la mașină. La început ideea de bază era de a ajuta șoferii

care au nevoie mai mult sau mai puțin urgentă de un service auto. Problema acestei idei era

prin ce mijloc poate fi pus la dispoziție eventualul răspuns la întrebare. Cel mai bun mod de

rezolvare a problemei a fost crearea a două tipuri de utilizatori cu scopul ca aceștia să-și rezolve

problemele reciproc. Șoferii vor apela la serviciile oferite chiar de către managerii service-urilor

auto.

Context

În prezent sunt dezvoltate tot mai multe aplicații mobile cu scopul de a rezolva

probleme întâlnite zi de zi în domeniul auto. Sunt aplicații care rezolvă probleme de localizare,

găsirea unei stații pentru alimentare, dar o problemă la care nu am găsit rezolvare este

localizarea unui service auto în caz de nevoie, problemă deseori întâlnită.

Așadar tema propusă poate fi soluția care va fi utilă cel puțin până la dezvoltarea unei

mașini care nu se defectează.

Funcționalități

1. Înregistrarea

Aplicația permite crearea a două tipuri de utilizatori: șofer și manager de service

auto. După efectuarea autentificării aplicația este configurată pe baza tipului de

cont.

2. Utilizatorul șofer

2.1 Scopul principal al șoferului este acela de a căuta un service auto. Afișarea

rezultatelor se face pe hartă în funcție de poziția utilizatorului.

2.2 Vizualizarea rezultatelor este foarte importantă. Descrierea completă și detaliile

garajului sunt cele care pot influența direcția aleasă de utilizator.

2.3 În cazul în care utilizatorul s-a decis în privința unui garaj, aplicația oferă ruta

spre destinație.

2

3. Utilizatorul manager de service

3.1 Una dintre cele mai importante funcționalități este aceea de a adăuga un garaj

nou. Acesta presupune un nume, o adresă, descrierea pe scurt a

funcționalităților garajului și în ultimul rând localizarea pe hartă a acestuia. Ea se

poate face manual (prin introducerea coordonatelor garajului) sau automat (la

fața locului telefonul va lua singur coordonatele cu permisiunea utilizatorului).

3.2 Managerul poate vizualiza lista garajelor introduce de el în aplicație.

3.3 În cazul în care un garaj introdus anterior va suferi modificări, aplicația oferă

modul de editare.

3.4 Dacă afacerea suferă și numărul garajelor active se schimbă, managerul poate

actualiza lista prin ștergerea celor care sunt închise.

4. Setări

4.1 Utilizatorul aplicației poate schimba limba utilizată în aplicație optând pentru

engleză sau română.

Specificații tehnice

Auto Service Finder are la bază pe lângă aplicația client, un server care face legătura cu

baza de date a aplicației.

Partea de client este reprezentată de o aplicație iOS (pentru iPhone) cu suport până la

ultima versiune de iOS(10), dezvoltată utilizând limbajul de programare Objective C în cadrul

aplicației Xcode.

Partea de server este dezvoltată folosind limbajul de programare Java, utilizînd mediul

de dezvoltare Eclipse. Tot aici a fost folosit Jetty, un framework de server. În ceea ce privește

stocarea datelor la nivel de server s-a folosit baza de date MySQL din cadrul facultății. Pentru

afișarea garajelor și a traseelor pe hartă a fost utilizat Google Maps[1]. Aplicația necesită

conexiune la internet și permisiunea utilizatorului pentru accesarea locației.

iOS este un sistem de operare creat și dezvoltat de către Apple. El este distribuit pe

dispozitivele Apple cum ar fi iPhone, iPad și chiar iPod.[2]

Objective C este principalul limbaj de programare folosit în dezvoltarea de programe

pentru sistemele OS X și iOS dar și pentru crearea de aplicații compatibile cu cele două sisteme.

La baza acestuia stă limbajul C, cunoscut pentru capacitatea de programare structurată.[3]

Xcode este un mediu de dezvoltare la baza căruia se află o serie de instrumente de

dezvoltare a programelor create de către Apple, pentru a implementa aplicații utilizate pe

platformele macOS, iOS, WatchOS și tvOS.[4]

Limbajul de programare Java a fost dezvoltat pe baza limbajului C++ dar cu un mod

simplificat de utilizare. Și aici ca și în cazul limbajului Objective C este folosită paradigma

3

programării orientate pe obiecte. Aplicațiile pot fi utilizate atât pe un singur calculator cât și pe

servere distribuite dar și de către mai mulți clienți care aparțin unei rețele.[5]

Eclipse este o platformă open source bazată pe limbajul Java. Ea permite dezvoltatorilor

de programe crearea și utilizarea de diverse plugin-uri.[6]

Jetty Web Server pune la dispoziție un server HTTP și un container Servlet capabil să

deservească atât conținut static cât și dinamic.[7]

MySQL este un sistem de gestiune a bazelor de date, foarte rapid și robust. O bază de

date permite stocarea, căutarea și sortarea datelor. Serverul MySQL controlează accesul la date

pentru a oferi simultan acces mai multor utilizatori.[8]

Contribuții

La realizarea acestui proiect am contribuit în totalitate, de la ideea proiectului până la

implementarea produsului finit. Procesul de creare a constat în cercetare, înțelegerea

tehnologiilor, design și programare.

În cadrul acestui proiect am realizat următoarele: am gândit și șlefuit ideea temei, am creat

schițele și modul în care va arăta aplicația, am creat structura aplicației client și cea a serverului,

am creat și implementat baza de date (tabelele plus câmpurile acestora și legăturile dintre ele)

și am scris codul pentru client și server.

4

1. Tehnologii folosite

În acest capitol este explicată partea teoretică a aplicației Auto Service Finder, mai exact

constrângerile tehnice, bibliotecile folosite și câteva idei despre procesul de cercetare.

1.1 iOS SDK

Aplicațiile destinate platformei iOS sunt dezvoltate folosind iOS SDK. Acesta este scris și

dezvoltat în momentul de față pentru limbajele de programare Swift și Objective C chiar de

către Apple Inc. exclusiv pentru produsele acestora. Pentru a ajuta viitorii dezvoltatori de

aplicații iOS, Apple pune la dispoziție documentația care stă la bază iOS cât și tutoriale, exemple

de aplicații. Apple și-a făcut un obicei prin a lansa o nouă versiune a iOS SDK în toamna fiecărui

an. Treptat, versiuni minore sunt eliberate pe parcursul anului cu scopul rezolvării feedback-

ului primit.

Figura 1: Diagrama popularității versiunilor de iOS, iulie 2016[9]

Majoritatea dispozitivelor iPhone rulează versiuni de iOS incepând de la 8 înainte iar

aplicația Auto Service Finder este dezvoltată în așa fel încât să fie compatibilă cu toate

acestea.[2]

5

1.2 XCode

Mediul de dezvoltare pentru platforma iOS este Xcode. Dezvoltat de către Apple, acesta

conține o serie de unelte utilizate în crearea de aplicații pentru macOS, iOS, tvOS și WatchOS.

Prima versiune a fost lansată în anul 2003 iar în acest moment versiunea cea mai stabilă este

cea cu numărul 10.

Xcode a fost creat pentru a comunica cu ușurință cu site-ul Apple pentru dezvoltatori,

astfel încât servicii precum Game Center sau Passbook să poată fi activate prin apăsarea unui

singur buton. Deasemenea este posibilă setarea unui bot pentru a crea în mod continuu,

analiza, testa și pentru a crea pachete ale aplicației. Un alt aspect important este faptul că în

momentul în care aplicația este gata aceasta poate fi trimisă în App Store, mediul online utilizat

în achiziționarea de programe pentru dispozitivele Apple.

Două elemente centrale din Xcode sunt Assistant Editor și Interface Builder.

Figura 2: Xcode, Assistant Editor și Interface Builder

Assistant Editor împarte editorul Xcode în două ferestre de lucru, partea din stânga

reprezintă documentul de lucru principal. În dreapta se află asistentul inteligent. Acesta din

urmă va determina pe baza activității desfățurate în partea din stânga de ce este nevoie și va

afișa pe partea lui de lucru.

6

Interface Builder, pune la dispoziția dezvoltatorilor un mediu pentru implementarea

interfeței grafice a aplicației fără a fi nevoie de scrierea de linii de cod. Utilizând Assistant

Editor se poate lucra în același timp la design și la codul sursă. Astfel se pot stabili legăturile

dintre cod și elementele de interfață.[4]

1.3 Google Maps iOS SDK

Acest SDK permite adăugarea la cerere de hărți ce au la bază date de la Google, în

aplicația dorită. El se ocupă în mod automat de accesul la serverele Google Maps, afișarea pe

hartă, răspunde la gesturile utilizatorului cum ar fi gesturi de tragere, clic. Se pot adăuga

marker-e pentru a însemna diferite locații, trasee de la o locație la alta, ferestre cu diferite

informații. Aceste obiecte asigură informații adiționale pentru locațiile de pe hartă și permit

utilizatorului să interacționeze cu acestea.

Pentru a folosi această componentă este necesară respectarea termenilor de utilizare și

asigurarea că aplicația este în conformitate cu legile în vigoare. În schimbul folosirii acestuia,

aplicația trimite la fiecare solicitare un pachet de informații către serverul din spatele Google

Maps. Informațiile incluse sunt numele aplicației, versiunea acesteia, informații de autentificare

și un identificator anonim.[1]

1.4 Eclipse

Eclipse este o platformă proiectată special pentru web și pentru crearea de unelte

pentru aplicații. Aceasta nu oferă o mare funcționalitate utilizatorului final. Valoarea ei este

reprezentată prin ceea ce încurajează: dezvoltarea rapidă a caracteristicilor integrate bazate pe

un model de plug-in.

Eclipse oferă un model de interfață pentru utilizatorii obișnuiți cu lucrul cu instrumente.

Acesta este proiectată pentru a rula pe sisteme de operare multiple oferind în același timp

integrare cu diverse sisteme de operare pe care se poate face dezvoltarea. Plug-in-urile pot fi

programate la API-urile portabile aparținând de Eclipse și rula neschimbat pe oricare dintre

sistemele de operare suportate.[6]

1.5 Jetty: framework Java

Jetty este un server HTTP Java și un servlet container Java. În timp ce serverele Web sunt

de obicei asociate cu servirea documentelor către utilizatori, Jetty este acum adesea folosit

pentru comunicarea mașină-mașină, de obicei în cazul soft-urilor ce contin framework-uri

foarte mari. Acesta este dezvoltat ca un proiect gratuit și open source, ca parte a Eclipse

7

Foundation. Serverul Web este utilizat în produse cum ar fi Apache ActiveMQ, Alfresco, Apache

Geronimo, Apache Maven, Apache Spark, Google App Engine, Eclipse și altele. Suportă ultima

versiune a Java servlet API precum și protocoalele HTTP/2 și WebSocket.[7]

1.6 MySQL

MySQL este un sistem de management al bazelor de date relaționale open source.

Numele său este o combinație a „My”, numele fetei co-fondatorului Michael Widenius și „SQL”,

prescurtarea pentru Structured Query Language. Proiectul de dezvoltare MySQL a făcut codul

sursă disponibil sub termenii GNU, General Public License, precum și în conformitate cu o

varietate de acorduri de proprietate.

MySQL a fost deținut și sponsorizat de către o singură firmă pentru profit, compania

suedeză MySQL AB, deținută în prezent de către Oracle Corporation. Sunt câteva ediții ce oferă

funcționalități suplimentare dar în schimbul unei sume de bani.[8]

8

2. Analiza soluției

Dezvoltarea aplicației Auto Service Finder a început de la o idee, crearea unei aplicații

care să ajute șoferii ce s-au lovit de problema de a nu avea un service auto la care să poată

apela în cazul unor probleme ce pot apărea. Pasul următor reprezintă analiza problemelor

posibile și găsirea soluțiilor favorabile pentru rezolvarea acestora.

În urma analizei amănunțite s-a decis dezvoltarea unei aplicații client pentru device-urile

iOS și a unui server cu care va putea comunica citirea/scrierea datelor într-o bază de date. O

astfel de arhitectură va rezolva mai multe probleme apărute.

Serverul se va conecta la baza de date permițând înregistrarea de noi seturi de date cum

ar fi: șoferi, manageri de garaje, garaje. Totodată serverul va prelucra datele și le va transmite

aplicației client. În acest mod datele sunt disponibile tuturor utilizatorilor.

O funcționalitate importantă a aplicației este creare și afișarea unui traseu către garajul

dorit. Acest lucru a fost posibil utilizând SDK-ul Google Maps, versiunea pentru iOS Pentru

crearea traseului dintre două puncte s-a utilizat un serviciu gratuit de la Google care returnează

punctele cheie dintre două locații.

Analiza problemelor și găsirea soluțiilor a reprezentat un pas important în dezvoltarea

acestui proiect, însemnând și primele decizii luate pentru realizarea unei fundații stabile.

Așadar stocarea, prelucrarea și aprovizionarea datelor au fost principalul motiv pentru

care s-a recurs la dezvoltarea unui mic server, iar pentru afișarea hărții cu punctele de interes și

a traseelor la Google Maps.

9

3. Proiectare

3.1 Arhitectura soluției

Această lucrare este alcătuită dintr-o aplicație client dezvoltată pentru platforma iOS și

partea de server la care s-a lucrat în limbajul Java folosind framework-ul Jetty, framework

pentru servere. Comunicarea aplicației cu serverul face ca aceasta să depindă de o conexiune la

internet.

Figura 3: Dinamica aplicației

3.2 Client – aplicația iOS

Aplicația Auto Service Finder este dezvoltată pe platforma iOS și constituie unul din cele

două puncte cheie ale acestei lucrări pe lângă partea de server. Ea este dezvoltată folosind

limbajul de programare Objective C și utilizând mediul de dezvoltare Xcode, program special

conceput pentru dezvoltarea aplicațiilor destinate dispozitivelor Apple.

La baza aplicației client stă modelul architectural de dezvoltare recomandat de Apple,

Model-View-Controller sau mai pe scurt MVC.[10]

Figura 4: Model architectural de dezvoltare – MVC[11]

Aplicație iOS

Server

Google Maps

API Google Maps SDK

Baza de

date Internet

Internet

10

Acesta are rolul de a modulariza aplicația, de a delimita în mod clar părțile componente pentru

a putea fi ușor modificate iar după modificare, acestea să fie compatibile cu celelalte module ce

formează aplicația. Pe lângă faptul că definește rolul obiectelor, acesta stabilește modul în care

ele comunică unele cu altele. Fiecare dintre cele trei tipuri de obiecte este separat de celelalte

prin limite abstracte și comunică cu obiecte ale altor tipuri peste aceste limite. Cele trei mari

componente ale MVC sunt model-ul, view-ul și controller-ul.

Model-ul se ocupă de comportarea și datele aplicației, răspunde la cereri despre starea

sistemului, la cereri de schimbare de stare și notifică utilizatorul atunci când aceste schimbări

au avut loc pentru ca acesta să poată reacționa.

View-ul transpune model-ul într-o formă care permite o interacționare ușoară, în mod

tipic o interfață vizuală. Pot exista multiple view-uri pentru un singur model pentru scopuri

diferite.

Controller-ul primește date de intrare de la utilizator și inițiază un răspuns în urma

cererilor către obiectele model. Controller-ul este cel care controlează celelalte două clase de

obiecte, view și model, instructându-le să execute operații pe baza datelor de intrare primite de

la utilizator.

MVC – Istoric

MVC a fost descris pentru prima oară în 1979 de către Trygve Reenskaug care pe vremea

aceea lucra la Smalltalk din cadrul Xerox PARC. Implementarea originală este descrisă în detaliu

în lucrarea Applications Programming în Smalltalk-80: How to use Model–View–Controller.[12]

MVC – Implementare

O aplicație orientată pe principiile MVC poate fi o colecție de triade

model/view/controller, fiecare responsabilă de un element diferit al interfeței cu utilizatorul.

MVC este des întâlnit în aplicații web unde view-ul este codul HTML generat de

aplicație. Controller-ul primește variabile GET și POST ca și date de intrare și decide ce să facă

cu acestea, trimițându-le mai departe model-ului. Model-ul, care conține logica de business și

regulile aferente, poate efectua operațiile necesare asupra datelor pentru a putea permite

aplicației generarea codului HTML mai sus menționat via engine-urile de template, pipeline-uri

XML, cereri de tip Ajax, etc.

Model-ul nu este neapărat doar o bază de date, fiind adesea atât bază de date cât și

logica de business necesară pentru a manipula datele în interiorul aplicației. Multe aplicații

folosesc un mecanism persistent de stocare a datelor. MVC nu specifică în mod explicit nivelul

de acces la date tocmai pentru că este de la sine înțeles că acesta se află încapsulat în model.

11

În unele aplicații simple care au puține reguli de business logic impuse, model-ul se poate limita

doar la o bază de date și la funcționalitățile oferite de aceasta.

View-ul, de asemenea nu este limitat doar la afișarea informației, el având un rol

important și în interacțiunea cu utilizatorul. În cazul exemplului de mai sus al aplicațiilor web

interfața generată via cod html este cea care se ocupă și de preluarea datelor de intrare și de

măsurile luate pentru ca acesta sa fie corect.

Controller-ul este adesea confundat cu aplicația însăși, pe când rolul său este de a dirija

datele între celelalte două clase de obiecte. Într-adevăr, se pot executa multe operații asupra

datelor de către model, insă aceste operații țin de formatul în care se prezintă datele la un

moment dat. Adesea se întâlnește cazul în care datele afișate/culese de la utilizator diferă

semnificativ de cele stocate în baza de date. Aceste diferențe se datorează conversiilor ce pot fi

aplicate asupra datelor de către controller pentru a facilita traficul de informație între

componente. Fiecare clasă de obiect are anumite expectative definite în ceea ce privește

formatul datelor, ori aceste transformări de format trebuie realizate automat pentru a menține

un flux constant de date, degrevând celelalte clase de grija conversiilor și asigurând aplicația că

fiecare modul primește ceea ce așteaptă. Asta pe lângă funcția de bază de a controla traficul de

cereri între module.

MVC – Funcționare

Schema de funcționare a unei aplicații modelate după arhitectura MVC decurge, în linii

mari, în felul următor:

1. User-ul interactionează cu interfața.

2. Controller-ul primește acțiunea apăsării butonului și o convertește într-o acțiune pe

întelesul model-ului.

3. Controller-ul notifică model-ul de acțiunea utilizatorului, urmând de obicei o

schimbare a stării model-ului.

4. Un view interoghează model-ul pentru a genera o interfață corespunzătoare.

5. Interfața asteaptă acțiuni suplimentare din partea utilizatorului, ciclul reluându-se.

3.2.1 MVC – Model

Modelul este inima aplicației, partea care nu se schimbă. El este partea ce conține

datele, informațiile despre utilizatori. Este, în general, principalul obiectiv al programatorilor, el

constituind marea parte a efortului de programare. Modelul este cel ce răspunde anumitor

comenzi și cel ce comunică cu baze de date externe.

12

Model-ul are nevoie de existența unei baze de date pentru stocarea permanentă a

datelor. Aceasta poate fi încapsulată în model sau poate fi la o anumită locație cunoscută de

model. Totuși, în aplicațiile simple, model-ul poate fi confundat cu baza de date însăși, dacă

operațiile pe care le face model-ul sunt operații foarte simple.

Într-o aplicație creată astfel încât să respecte acest concept, partea de model va lucra

doar cu starea aplicației și cu logica ei, nu va conta cum este sau va fi reprezentată această stare

către utilizator sau cum interacționează acesta cu aplicația.

Un alt aspect important este că atât view-ul, cât și controller-ul depind de model, în

timp ce model-ul nu depinde de ele. Astfel modelul poate fi implementat și testat fără să fie

nevoie de interfață grafică, dezvoltarea acesteia făcându-se în paralel.

Model-ul este utilizat la organizarea informației și anunțarea când aceasta se modifică.

El conține doar date și funcționalități care sunt legate printr-un scop comun. Dacă ar fi fost

cazul de a modela date din două grupuri care nu sunt legate între ele, s-ar fi creat două modele

separate. Un model va conține mai mult decât date și funcții care operează pe aceste date.

Scopul unui model este de a realiza o aproximare, sau abstractizare, în mediul informațional al

unor procese sau sisteme din lumea reală. El nu trebuie să se limiteze la a captura starea unui

proces sau sistem, ci chiar la cum acel sistem funcționează, ceea ce face foarte ușoară folosirea

modelării din lumea reală la definirea propriilor sisteme.

Rolurile părții de model

Partea de model înmagazinează datele sub forma de proprietăți și pune la dispoziție

metode specifice aplicației care permit extragerea și înregistrarea datelor. Metodele care

gestionează datele nu sunt ceva generic, ele sunt adaptate cerințelor aplicației și trebuie să fie

cunoscute părtilor de control și de vedere. Datele din cadrul părții de model pot fi modificate

extern de către o clasă externă sau intern ca urmare a logicii proprii. Partea de model trebuie să

pună la dispoziție o modalitate prin care view-urile să fie inregistrate sau să iasă din evidență

singure, și modelul să organizeze o listă a view-urilor înregistrate. De fiecare dată când modelul

observă o schimbare importantă a propriei stării, trebuie să anunțe toate view-urile

înregistrate. În final, modelul este acela care implementează partea logică a „triadei” MVC. De

asemenea el furnizează și servicii de validare a datelor și alte utilității specifice aplicației.

Comunicare model – view

În mod normal, modelul nu are nici o informație în legătură cu view-ul. Totuși există o

comunicare între aceste 2 părți și ea are loc dacă:

13

• A fost apăsat un buton și a fost trimisă o comandă model-ului.

• O valoare nouă a fost scrisă într-un „text field” și un mesaj de actualizare a fost trimis

model-ului.

• Dacă o valoare este necesară view-ului, o cerere îi este trimisă model-ului pentru acea

valoare.

Astfel, comunicarea are loc dacă se întâmplă un eveniment. View-ul trimite o cerere

către model care trebuie să fie capabil să o descifreze și să îi trimită un răspuns, indiferent dacă

acest răspuns este o valoare sau o serie de operații mai complicate. Bineînțeles că este nevoie

de o programare bună a modelului care trebuie să fie capabil să descifreze un număr mare de

astfel de operații.

Model-ul în aplicația Auto Service Finder

În cadrul aplicației dezvoltarea model-ului a pornit de la însăși ideea de bază, șoferii

caută garaje. Primul element al model-ului este reprezentat de utilizatorul aplicației.

În cadrul aplicației, implicit al model-ului acesta este cunoscut sub numele de „User”.

Atributele sale, ceea ce va caracteriza acest obiect sunt nume, prenume, email, parola, limba. În

momentul în care s-a decis adăugarea unui alt tip de utilizator înafară de șofer, cel de manager

de garaj, obiectul user a primit atributele tip utilizator și listă garaje, atribute care vor face

diferența între cele două tipuri de utilizatori ai aplicației, cel de șofer și managerul de garaj.

Obiectul user are implementate trei metode care îl vor manipula.

Metoda SaveUserInfo(), va salva în memoria telefonului email-ul, parola și limba

utilizată. Apelarea acestei metode se face la prima autentificare cu success a unui utilizator.

O altă metodă a obiectului User este LoadUserInfo() care va încărca datele utilizatorului

din memoria telefonului în aplicație. Acest lucru va declanșa metoda de autentificare a

utilizatorului fără ca acesta să mai fie nevoit să completeze datele pentru autentificare.

Ultima metodă implementată pentru obiectul User este ClearUserInfo(). Ea va șterge

datele utilizatorului din memoria telefonului, permițând posibila autentificare a unui alt

utilizator.

Un lucru important este acela că obiectul User din model va exista o singură dată la o

lansare în execuție a aplicației, aceasta având un singur User pe durata rulării în execuție a

aplicației.

Cel de-al doilea și ultimul element al modelului este reprezentat de către Garaj.

Atributele acestuia sunt nume, adresa, email-ul managerului care a introdus garajul, detaliile

garajului cum ar fi o scurtă descriere a serviciilor oferite, id-ul garajului și în ultimul rând

coordonatele acestuia, latitudinea și longitudinea. Garajul reprezintă interesul utilizatorilor de

tip șofer.

14

Acest obiect conține implementarea a două metode care vor ajuta la manipularea

datelor.

Metoda de bază este getGarageFromDictionary(). Ea crează un obiect de tip Garaj iar pe

baza unui parametru al metodei de tip dicționar va primi pentru fiecare atribut valoarea

asociată din dicționar.

Cealaltă metodă este getGaragesFromArray(). Un parametru al acesteia este

reprezentat de o listă de dicționare ce conțin datele ce vor crea obiecte de tip Garaj folosind

metoda descrisă mai sus.

Figurile 5 și 6 reprezintă clasele celor două tipuri de obiecte

3.2.2 MVC - View

View-ul este una dintre cele trei componente ale arhitecturii Model-View-Controller și

are rolul de a atribui Model-ului o formă adecvată pentru interacțiune, de obicei un element de

interfață cu utilizatorul. Pot exista mai multe view-uri pentru același model.

De fiecare dată când este schimbat modelul, fiecare view al modelului este anunțat că

trebuie să schimbe reprezentarea vizuală pe ecran. O regiune a afișajului care nu este în

concordanță cu informația primită de la model se numește „dăunătoare” sau „invalidă”. Când

se face o schimbare, view-ul identifică partea de ecran modificată și o raportează la „sistemul

de ferestre” ca fiind invalidă. Acesta confirmă zona „stricată”, urmând să fie redesenată de

către view.

RELAȚIA VIEW-CONTROLLER

View și controller sunt strâns legate. Fiecare instanță a View-ului este asociată cu o

instanță unică a Controller-ului (fiecare instanță a Controller-ului fiind asociată la randul ei cu o

instanță unică a View).

15

În mod logic, dacă View și Controller sunt strâns legate unul de altul, intrarea și ieșirea

aplicației să fie și ele într-o relație strânsă. În majoritatea „framework-urilor” MVC, View și

Controller formează un singur obiect. Acesta se numește „Document View”. View și Controller

sunt „combinate” în „View”, iar Model devine cunoscut ca „Document”. Un model pasiv comută

responsabilitățile către controller care trebuie să anunțe view-ul când face modificări. MVC-ul

modern atribuie responsabilitățile „tradiționale” ale View-ului către Controller. Acesta devine

responsabil de crearea și selectarea View-urilor.

View-ul în aplicația Auto Service Finder

În cadrul aplicației, așa cum s-a mai precizat, fiecare componentă view este atașată unei

componente controller. Prin intermediul view-ului se face schimbul de informații dintre

utilizator și aplicație.

La prima lansare în execuție a aplicației primul view pe care utilizatorul îl va vedea va fi

cel de conectare. El conține logo-ul cu numele aplicației, textfield-urile pentru email și parolă,

un buton pentru funcția de conectare, un buton pentru funcția de înregistrare și un label care

vine în ajutorul utilizatorului. În cazul în care utilizatorul a mai folosit aplicația, funcția de

conectare se execută fără a mai fi nevoie ca view-ul acesta să fie afișat deoarece email-ul și

parola sunt salvate în memoria telefonului, introducerea din nou a acestora fiind inutilă.

S-a precizat mai sus despre butonul de înregistrare care aparține view-ului conectare.

Acesta va deschide un nou view cu un controller asociat pentru funcția aplicației de înregistare

utilizator. Aici sunt textfield-urile pentru nume, prenume, email, parolă și confirmare parolă. În

continuare mai sunt un label care specifică rolul următoarei componente, cea care va

determina tipul de utilizator, cel de șofer sau manager de garaj. Ultima componentă este

reprezentată de butonul care va accesa funcția de înregistrare.

Revenind la view-ul cu funcția de conectare, după introducerea datelor utilizatorului și

apăsarea butonului de conectare, în cazul unei cereri cu succes, următorul view este unul

intermediar. Aici sunt logo-ul și numele aplicației și un label în care este afișat un mesaj

intermediar.

Următorul view și controller asociat este cel pentru profilul utilizatorului. Acesta va afișa

informațiile pentru ambele tipuri de utilizatori, conținând detaliile acestora. Sunt label-uri care

prezintă emailul, numele complet și tipul de utilizator al celui conectat. În cazul în care

utilizatorul este unul de tip manager de garaj, sub detaliile contului va apărea un buton care

duce în view-ul ce conține garajele utilizatorului.

16

În ultimul rând, un ultim element al acestui view este butonul pentru afișarea meniului

situat în colțul din stânga sus al view-ului.

Butonul pentru garajele utilizatorului, afișat doar în cazul în care acesta este manager de

garaje, duce spre view-ul garajele mele. Aici garajele utilizatorului sunt afișate într-o listă,

fiecare dintre acestea conținând numele garajului, email-ul managerului și detaliile despre

garaj. Despre funționalitățile acestui view pot fi precizate mai multe în cadrul controller-ului

asociat acestui view.

Mai sus era precizat view-ul destinat meniului aplicației. Acesta este pregătit în funcție

de tipul de utilizator, lista de elemente a meniului fiind diferită. Utilizatorii șofer și manager au

în comun opțiunile „Profilul meu”, „Setări” și „Deconectare”. În plus utilizatorul manager are

„Adaugă garaj” iar utilizatorul șofer are „Caută garaj”. Selectare unei opțiuni din meniu va duce

spre view-ul asociat.

Unul dintre cele mai importante view-uri ale aplicației este direct asociat utilizatorului

manager pentru funcția de adăugare garaj. Aici sunt textfield-uri pentru numele, adresa și

informațiile garajului.

View-ul și controller-ul pentru adăugare garaj este refolosit pentru a crea un view și

controller pentru editarea unui garaj, câmpurile celor două view-uri fiind același

Același view și controller folosite pentru funcția de adăugare garaj sunt refolosite pentru

funcția de afișare a detaliilor garajului. Cele trei view-uri și controllere folosesc aproximativ

aceiași parametrii doar funcțiile fiind diferie, acest lucru facilitând refolosirea pentru crearea

unor noi view-uri pentru diferitele funții.

Principalul motiv pentru care un utilizator șofer va folosi această aplicației este acela de

a căuta un garaj pentru nevoile sale. Astfel acesta poate accesa view-ul cu controller-ul asociat

pentru „Caută Garaj”. Aici prin intermediul Google Maps sunt afișate rezultatele unei căutări

efectuate cu succes.

Utimul view și controller asociat dezvoltat este cel de „Setări”. În cadrul acestuia s-a

inclus doar un label care sugerează singura funcție implementată, aceea de schimbare a limbii

utilizate, și două butoane pentru selectare.

3.2.3 MVC – Controller

Controller-ul este componenta principală a arhitecturii MVC, ce conţine logica de

execuţie a aplicaţiei. El reprezintă atât punctul de intrare în aplicaţie, cât şi cel de ieşire şi se

17

foloseşte de celelalte componente (model şi view) pentru a-şi îndeplini sarcina dată. Controller-

ul este conceptualizat ca o clasă ce poate îndeplini mai multe funcţii, numite acţiuni. Fiecare

funcţie primeşte un set de date de intrare, ce reprezintă parametri sau informaţii date de către

utilizator (datele problemei ce se doreşte a fi soluţionată). Aceste date sunt puse cap la cap de

către logica internă a controller-ului, cu ajutorul claselor model. În urma prelucrării lor, rezultă

datele de ieşire, reprezentând soluţia aplicaţiei, date ce sunt trimise unei clase view pentru a

putea fi transformate într-un format înţeles de către utilizator. Controller-ul este astfel o cutie

neagră ce acceptă anumite date de intrare, şi produce în urma unor prelucrări datele de ieşire.

Procesarea datelor de intrare în cadrul unui controller se face prin simpla manipulare a

claselor model, ce pun la dispoziţie interfeţe, adică metode şi proprietăţi ce pot fi accesate,

utilizate şi modificate din exterior (de către controller) fără a cunoaşte structura internă a

model-ului. Astfel controller-ul lucrează cu aceste obiecte, modificându-le în modul acceptat de

către interfaţa clasei. Deşi acest lucru înseamnă transparenţă totală, nefiind nevoie a se

cunoaşte structura internă a clasei respective, apar şi limitări legate de imposibilitatea de a

accesa date sau a face prelucrări ce nu au fost prevăzute în clasa respectivă. Un exemplu de

astfel de situaţie se poate întâlni atunci când clasele model reprezintă echivalenţe a unor tabele

dintr-o bază de date, şi se doreşte efectuarea unui anumit tip de interogare în cadrul controller-

ului, interogare ce nu a fost prevăzută de model. Principial, controllerul nu are acces direct la

baza de date, care este considerată doar un mod de stocare brut, deci nu poate efectua în mod

direct interogări. Singura soluţie este implementarea de către model a unei interogări

corespunzătoare care să satisfacă cerinţele controller-ului.

Deşi acest principiu duce la o separare a logicii programului (aplicaţiei) şi face mai

uşoară atât depanarea ulterioară cât şi modificarea operaţiilor prin simplificarea desfăşurării

codului (code flow-ului), se produce de asemenea şi o creştere a dependenţei controller-ului de

model, fiind limitat la un set de operaţii pus la dispoziţie de acesta. Situaţia se complică şi mai

mult atunci când doi sau mai mulţi programatori lucrează pe secţiuni diferite de cod.

Un programator este specializat în baze de date şi lucrează cu clasele model, în timp ce

altul încearcă să facă o aplicaţie ce se foloseşte de acest model. Orice facilitate neprevăzută de

interfaţa model-ului va trebui implementată pe loc, ducând la o întârziere de efectuare a

programării pe partea controllerului.

Pe de altă parte, programatorul care se ocupă de controllere nu va trebui să cunoască

niciun aspect al arhitecturii bazelor de date spre exemplu, făcând distribuirea forţei de muncă

mult mai flexibilă.

18

Controller-ul în aplicația Auto Service Finder

Comunicarea utilizatorului cu aplicația se realizează la nivel vizual prin intermediul view-

urilor însă, în spatele fiecărui view se află un controller care face toată treaba, preia cererile

utilizatorului și oferă rezultatele.

Conectare

Lansarea în execuție a aplicației pentru prima dată va afișa utilizatorului view-ul de login

împreună cu controller-ul asociat acestuia. Acest controller poate îndeplini funcțiile de

conectare sau înregistrare utilizator.

Funcția de conectare începe odată cu declanșarea butonului de conectare. Urmează o

serie de pași. Primul lucru reprezintă verificarea datelor introduse de utilizator, email-ul și

parola. Validarea acestora se realizează înaintea începerii procesului de conectare.

Este important ca ambele credențiale să fie valide. Verificarea email-ului se face pentru a stabili

dacă are formatul corect. Acest lucru se face apelând funcția isEmailValid() care primește ca

parametru un string, o parolă. Va întoarce o valoare booleană, în cazul în care emailul este

valid, true, altfel false. În cazul parolei, singura restricție este ca aceasta să aibă o lungime

diferită de 0. Metoda care verifică credențialele la fel ca cea pentru verificarea email-ului va

returna o valoare booleană. În cazul în care apar probleme la una sau ambele validări, răspunsul

returnat va fi false, procesul de conectare fiind oprit, un mesaj de avertisment va fi afișat în

legătură cu problema apărută în timpul validării credențialelor introduse de utilizator. În caz

contrar, dacă datele introduse au fost validate și sunt corecte, parola va fi preluată și criptată

folosind sistemul MD5.

Având email-ul și parola criptată se poate apela cererea pentru conectare, cea care

primește aceste valori ca parametri. Următorul pas este cel de verificare a răspunsului venit de

la cerere. În cazul efectuării cu succes a cererii, din răspuns se preiau datele ce reprezintă

detaliile utilizatorului.

19

Acestea sunt salvate în memoria telefonului pentru ca următorul proces de conectare să se

desfășoare mai rapid, fără a fi nevoie trecerea din nou prin fereastra de conectare.

Înregistrare

În cazul în care utilizatorul nu are un cont pentru aplicație, butonul de înregistrare va

deschide fereastra care îndeplinește această funcție.

Controller-ul acesta va valida datele necesare înregistrării. Pe lângă email mai sunt două

câmpuri pentru parolă, cel de-al doilea fiind pentru confirmarea parolei. Mai sunt câmpuri

pentru nume, prenume. Acestea vor fi validate folosind același procedeu utilizat și în procesul

de conectare. Pentru selectarea tipului de cont este folosită componenta SegmentController,

care va fi setată implicit pe tipul de utilizator șofer.

20

Înainte de crearea cererii pentru înregistrare, este creat un NSDictionary, care va

conține parametrii trimiși către server: nume, prenume, email, parola criptată folosind MD5 și

tipul de utilizator.

Răspunsul primit în urma executării cererii va fi interpretat. În cazul efectuării cu succes,

acesta va conține și datele utilizatorului creat care vor fi salvate la fel ca în procesul de

conectare utilizator. Astfel se revine înapoi la controller-ul de conectare. În cazul în care a

intervenit o eroare va fi afișat pe ecran un mesaj de alertă prin intermediul componentei

UIAlertView, care va conține un titlu, mesaj și un buton de închidere a mesajului.

Loading Screen

După efectuarea cu succes a procesului de conectare aplicație se pregătește pentru

utilizator în cadrul controller-ului LoadingScreen. Se va putea observa animația logo-ului cât și

un mesaj intermediar. Animația este una de bază care primește ca parametrii tipul de animație,

în acest caz de rotație, de unde să înceapă, unde să se oprească, viteza, durata. Ea este pusă pe

logo-ul aplicației determinând rotirea acestuia.

Un aspect foarte important al acestui controller este faptul că pregătește arhitectura

aplicației care va avea la bază un controller principal și unul secundar care va fi reprezentat de

către meniu. Componenta folosită este ViewDeckController[13], o componentă care suportă

adăugarea meniului.

21

Profilul Meu

Acesta reprezintă principalul controller al aplicației. Aici sunt afișate datele utilizatorului

împreună cu tipul de cont. În cazul în care acesta este de tip manager se execută cererea pentru

returnarea garajelor utilizatorului. Vor putea fi vizualizate utilizând butonul Garajele mele.

Singurul parametru necesitat de acestă cerere este email-ul utilizatorului după cum se

poate vedea. În cazul în care nu intervin erori, sunt preluate datele din răspunsul cererii iar în

cazul în care răspunsul conține o listă de rezultate, acestea sunt prelucrate rezultând o listă de

garaje.

Meniu

Controller-ul pentru meniu este responsabil cu afișarea opțiunilor pentru utilizator.

Deasemenea conține protocolul LeftMenuViewControllerDelegate, protocol care

implementează metoda itemFromMenuWasSelectedOnIndex(), metodă care transmite ca

parametru indexul opțiunii selectate.

Trebuie menționat faptul că acest protocol este utilizat în controller-ul Profilul meu. Astfel, când

este selectată o opțiune din meniu, ea este transmisă în controller-ul menționat mai sus iar

acesta la selectarea unei opțiuni din listă va executa acțiunea aferentă.

22

Se observă transmiterea indexului opțiunii selectate de către utilizator în controller-ul care a

implementat metoda. În controller-ul Profilul meu se alfă implementată metoda care

interpretează opțiunea selectată de utilizator.

Un exemplu concret, dacă utilizatorul este de tip șofer și dorește adăugarea unui nou garaj, va

selecta din meniu Adaugă garaj, opțiune la indexul 1 și se va executa metoda

addGarageBtnPressed().

Această metodă crează un controller de tip AddGarageViewController și îi afișează view-

ul asociat.

Adaugă garaj

Controller-ul Adaugă garaj este unul special. Pentru optimizare s-a decis utilizarea

acestuia pentru trei funcții mari. În loc de implementarea a trei controllere diferite pentru

23

adăugare, editare și vizualizare de garaje, s-a optat pentru crearea unui singur controller care va

fi manipulat astfel încât să se potrivească diferitelor funcții ale aplicației. Cu toate că el poate

îndeplini trei funcții, acestea pot fi apelate din mai multe direcții.

Mai sus este arătat modul în care controller-ul Adaugă garaj este pregătit pentru cele

trei funcții ale sale. Acesta are un parametru iar în funcție de locul în care controller-ul este

accesat el este schimbat. În cazul în care este nevoie de funcția de editare este pregătit intr-un

mod, pentru funcția de vizualizare este pregătit în alt mod iar pentru adăugare nu necesită

pregătire suplimentară

Utilizatorul manager va accesa funcția de adăugare garaj din meniu. În acest caz

controller-ul va trebui să manipuleze datele introduse de manager. Ele sunt validate, pregătite

pentru cererea de adăugare garaj ce va urma.

Primul set de date pentru un garaj este reprezentat de către numele, adresa și detaliile

acestora. Ele sunt validate în mod asemănător ca validarea datelor la procesul de înregistrare.

Următorul set de date este reprezentat de locația garajului. Pentru acest lucru s-a folosit

un controller nou, AddGarageCoordinates. Aici utilizatorul are opțiunea de a adăuga

coordonatele în mod automat folosind locația telefonului sau prin introducerea acestora în

mod manual de către utilizator.

Locația în mod automat se obține prin folosirea managerului de locație pus la dispoziție

de către Apple. Odată permisiunea pentru locație activă, metodele protocolului de localizare

intră în acțiune.

24

Coordonatele sunt salvate și gata de transmis folosind protocolul AddCoordinates_delegate,

metoda acestuia, addCoordinatesWithLatitude: andLongitude: fiind implementată în controller-

ul care le va folosi și anume Adaugă garaj.

După cum s-a precizat mai sus, datele sunt pregătite, funcția requestAddGarageWithGarage()

poate fi lansată în execuție. Sunt validate datele. În cazul în care metoda validateGarageData()

întoarce true, valoare booleană, este creat dicționarul cu date ce va fi și singurul parametru al

cererii de adăugare garaj.

25

Tot utilizatorul manager poate accesa acest controller pentru funcția de editare garaj chiar din

lista sa de garaje. Ea este asemănătoare cu cea de adăugare doar că datele garajului sunt

precompletate în câmpurile aferente ale view-ului asociat controller-ului.

Mai sus este precizat faptul că se poate seta funcția pentru care este dorit controller-ul Adaugă

garaj. Se poate observat cum ea este setată pe editare cât și faptul că este setat garajul ce va fi

editat.

Utilizarea funcției de vizualizare detalii garaj este posibilă pentru ambele tipuri de

utilizatori. Ea se poate accesa din lista de garaje pentru manager iar pentru utilizatorul șofer din

fereastra de căutare garaj. Se setează pe controller-ul Adaugă garaj tipul de funcție de

vizualizare cât și garajul dorit spre vizualizare. Din view-ul acestuia singura opțiune a

utilizatorului este cea de întoarcere la ecranul anterior.

Caută garaj

Acest controller și view-ul asociat reprezintă interesul utilizatorului șofer. Principala

preocupare este afișarea garajelor găsite iar mai apoi ruta spre opțiunea aleasă. Pentru a afișa

rezultate pe hartă este nevoie de execuția cererii pentru garaje.

Aceasta nu primește niciun parametru și va returna toate garajele găsite. În caz de succes,

răspunsul este prelucrat, din el se va obține o listă de garaje. Se poate observa următorul pas,

acesta fiind adăugarea de marker-e, garaje pe hartă. Acest lucru se va face prin trecerea prin

26

lista de garaje iar în cazul în care acestea au locația fixată vor fi folosite pentru crearea de

GMSMarker-e, puncte ce vor fi afișate pe hartă.

După cum se poate observa, un GMSMarker conține poziția și datele garajului, harta de care

aparține și un icon.

Ceea ce nu poate lipsi este locația utilizatorului iar pentru obținerea ei se va folosi același

procedeu ca cel de la adăugarea unui garaj, managerul de locație nativ din iOS.

După activarea serviciului de locație, managerul de locație se va updata și va fi gata de utilizare.

În acest moment toate componentele sunt gata de prezentare pe hartă. Urmează afișarea

acestora.

27

Mai sus se poate observa adăugarea marker-elor și a poziției utilizatorului pe hartă și

actualizarea modului de vizualizare al acesteia pentru a putea vizualiza toate rezultatele.

Treaba controller-ului nu s-a terminat. Prin selectarea unui marker de pe hartă se vor

întâmpla două lucruri. Creare și afișarea unui view ce conține mici detalii despre garajul.

Cel de-al doilea lucru este crearea unui traseu începând de la poziția utilizatorului până la locul

unde se află garajul pe hartă.

Acest lucru nu ar putea fi posibil fără executarea unei cereri care are ca parametrii poziția de

start și cea de destinație.

28

În caz de succes și cu rezultate găsite, pe baza acestora se vor extrage punctele cheie dintre cele

două locații trimise ca parametrii pentru crearea unui traseu ce va fi afișat mai apoi pe hartă.

Setări

Ultimul controller al aplicației dorește internaționalizarea aplicației. Acest lucru este

permis prin punerea la dispoziția utilizatorului a două limbii, română și engleză.

Odată selectată una dintre cele două limbi, ea este salvată în memoria telefonului iar la

următoarea deschidere a aplicației traducerile se vor face conform cu limba nou selectată.

Acestea se fac prin crearea a două fișiere, unul pentru limba română și unul pentru limba

engleză iar în fiecare dintre acestea sunt puse traducerile pentru fiecare string utilizat în cadrul

aplicației. Trebuie menționat faptul că fiecare string are asociată o traducere pentru română,

una pentru engleză dar un singur stringID pe baza căruia se va face traducerea.

Traducerile sunt efectuate în fiecare controller la începutul inițializării acestuia.

29

3.3 Server

Partea de server a aplicației Auto Service Finder este implementată în mediul de

dezvoltare Eclipse. Limbajul de dezvoltare utilizat este Java. Rolul de server este atins prin

integrarea framework-ului Jetty, cunoscut pentru funcționalitatea sa de server.

În momentul lansării în execuție a clasei main a serverului, ServerMain, sunt pregătite

serverul și baza de date pentru operațiunile ce vor urma.

Este configurat accesul la baza de date prin setarea host-ului, a user-ului și a parolei de

acces. Serverul este și el configurat prin setarea numelui și a portului utilizat. Valorile utilizate în

executarea acestor configurări sunt nemodificabile. De partea serverului este creat un handler

care se va ocupă de rezolvarea apelurilor ce solicită serverul.

Rolul clasei ApiHandler este de a deosebi apelurile venite la server și de a trimite mai

departe o cerere de rezolvare împreună cu datele trimise ca parametru către clasa care rezolvă

apelul respectiv.

30

Serviciul de Conectare - Login

După cum spune și numele, serviciul de conectare este apelat atunci când un utilizator

deschide aplicația și dorește să se autentifice. Parametrii trimiși la acest apel sunt email-ul și

parola utilizatorului. După rezolvarea cererii de conectare răspunsul de la server va cuprinde

numele și prenumele utilizatorului, adresa, tipul de utilizator. Pe lângă aceste valori mai sunt

cuprinse valorile pentru success și error. Pentru cheia success din răspuns pot fi două valori

booleene. În cazul unei conectări cu succes valoarea va fi setată pe valoarea true, altfel false.

Pentru cheia error din răspuns va fi atașat un mesaj care justifică o problemă apărută în

momentul operațiunii.

Se poate observa faptul că cererea de conectare este rezolvată în mai mulți pași.

Verificarea datelor de intrare, date corecte implică o căutare în baza de date iar o căutare

presupune și un răspuns care va fi trimis solicitării efectuate.

Serviciul de Înregistrare – RegisterUser

Serviciul de înregistrare primește ca parametrii email, parola, nume, prenume, adresa și

tipul de cont al viitorului utilizator. În cazul unei operațiuni effectuate cu success, răspunsul

trimis de server va conține o valoare booleană pentru cheia success iar în caz contrar răspunsul

va conține un mesaj cu problema apărută pentru cheia error.

Verificarea datelor de intrare și setarea unui răspuns în cazul în care acestea sunt invalide.

31

Servicul de Returnare listă garaje – GetGarageList

Acest serviciu este disponibil atât utilizatorului de tip șofer cât și utilizatorului de tip

manager de garaj. Diferențierea se face prin sigurul parametru al serviciului, ownerID, acesta

fiind opțional.

În rezolvarea cererii, din datele de intrare este preluată valoarea pentru owner_email.

Urmează apoi verificarea și stabilirea răspunsului. În cazul în care acesta este setat sunt căutate

în baza de date garajele care aparțin utilizatorului cu email-ul dat. În caz contrar se face

returnarea tuturor garajelor din baza de date, cererea venind de la un utilizator de tip șofer.

Serviciul de Înregistrare garaj – RegisterGarage

Apelarea acestui serviciu se face doar din partea utilizatorului de tip manager de garaj.

Acesta trimite serverului un set de date reprezentând informațiile noului garaj, nume, email

manager, adresa, detalii, coordonatele acestuia(latitudine și longitudine).

După validarea datelor, în cazul în care acestea sunt valide, se face o verificare în baza

de date pentru a verifica ca nu cumva aceasta să mai conțină acest garaj. În cazul în care în baza

de date se află un garaj cu același nume și aceeași locație răspunsul va conține un mesaj de

eroare ce va explica acest lucru.

32

Mai sus, metoda care crează o nouă intrare în baza de date reprezentând noul garaj. În cazul

unei posibile probleme răspunsul cererii de adăugare va conține acest lucru.

Serviciul pentru Actualizare garaj – UpdateGarage

Un alt serviciu utilizat de contul de utilizator manager este cel de actualizare garaj. Este

necesară posibilitatea de update pentru cazul în care un garaj suferă modificări de locație,

servicii disponibile.

Datele de intrare ale acestui serviciu sunt id-ul, email-ul managerului, numele, adresa,

detaliile, locația reprezentând latitudinea și longitudinea. Pașii în tratarea acestei funcții sunt de

verificare a datelor de intrare, căutare în baza de date și actualizarea garajului în cazul în care

acesta a fost găsit. Dacă a fost găsit garajul și actualizat, mesajul de răspuns va conține valoarea

1 pentru cheia succes, ceea ce reprezintă o actualizare făcută cu succes.

Serviciul pentru Detalii garaj – GetGarage

Apelarea acestui serviciu se face pentru obținerea detaliilor unui garaj selectat. Serviciul

primește ca parametru un garageID pe baza căruia se va căuta în baza de date.

Înainte de a efectua căutarea în baza de date se verifică id-ul obținut din serviciu pentru

a știi dacă acesta este valid. Se tratează cazul în care acesta ar fi invalid prin atașarea în răspuns

a unui mesaj de eroare corespunzător. Pe baza garageID-ului se face căutarea în baza de date

33

iar în funcție de rezultat este creat răspunsul. Mesaj de eroare în cazul în care nu s-a găsit un

rezultat iar în caz de succes în răspuns sunt adăugate chei și valori cu datele garajului.

Serviciul de Ștergere garaj – DeleteGarage

Acest serviciu este responsabil cu ștergerea unui garaj din baza de date, serviciu apelat

doar de utilizatorul de tip manager de garaj. Parametrul însoțit de acest apel este garageID-ul.

Ca la fiecare serviciu implementat primul pas este reprezentat de verificarea datelor de intrare.

Fiecare pas este însoțit de tratarea cazului în care poate apărea o problemă, atașarea în răspuns

a unui mesaj corespunzător. Următorul pas este reprezentat de o căutare după ID în baza de

date și acest caz fiind tratat pentru cazul în care a fost găsit garajul sau în cazul în care nu există

acel garaj.

În eventualitatea în care garajul există, este apelată metoda removeGarage() care va șterge

intrarea din baza de date pe baza garageID-ului. Dacă toți pașii au fost efectuați cu succes

răspunsul cererii va conține mesajul de succes pentru cheia cu același nume.

34

4. Manual de utilizare

Splash screen

Ecranul de splash sau splash screen-ul, este primul ecran pe care utilizatorul îl poate

observa după lansarea în execuție a aplicației. El conține logo-ul și numele aplicației. Rolul

acestuia nu este decât unul de informare. Pe platforma iOS în cadrul ecranului de splash nu se

pot executa alte acțiuni.

Conectare și înregistrare

După afișarea splash screen-ului, aplicația va verifica dacă utilizatorul a mai fost

conectat. În cazul în care aplicația nu a mai fost folosită sau la ultima folosire a ei s-a accesat

funcția de deconectare, următorul ecran cu care utilizatorul intră în contact este cel de

conectare. El îndeplinește funcția cu același nume sau poate direcționa utilizatorul spre ecranul

de creare cont.

35

Acesta din urmă are funcția de înregistrare a utilizatorului cu nume, prenume, adresă de email,

parolă și confirmare parolă iar în ultimul rând tipul de utilizator dorit. Ultimul parametru în

crearea contului va decide rolul în cadrul aplicației. Utilizatorul este nevoit să completeze toate

câmpurile de date. În cazul în care acesta nu selectează tipul de cont dorit, el va fi implicit un

cont pentru utilizator șofer.

O înregistrare cu succes va întoarce aplicația la ecranul de conectare. În caz contrar un

mesaj de avertisment va fi afișat, acesta conținând motivul problemei apărute. Înapoi la ecranul

de conectare se poate reveni accesând butonul cu simbol săgeată spre stânga, anulând orice

date introduse în câmpurile pentru înregistrare.

O conectare a utilizatorului cu succes va redirecta aplicația într-un ecran intermediar. În

caz contrar va fi afișat un mesaj cu motivul problemei apărute.

Ecranul de încărcare

Acest ecran are rolul de a pregăti aplicația pentru utilizator. În spate se crează structura

care va fi folosită. Acesta are un rol important în arhitectura aplicației. În cazul în care

36

utilizatorul a mai folosit aplicația și nu s-a deconectat la următoarea lansare în execuție a

acesteia procesul de conectare se face automat, aplicația deschizându-se la acest ecran

intermediar.

Utilizatorul va observa logo-ul aplicației învârtindu-se asemenea unui spinner pentru

progres și un mesaj care îl anunță ce se întâmplă la acest moment.

Profilul meu, Garajele mele, Editare, Adaugă coordonate

După autentificarea cu succes aplicația navighează până la ecranul de profil al

utilizatorului. Aici se observă datele contului, numele complet, email-ul și tipul de cont. În cazul

în care tipul de cont este cel de manager în centrul ecranului apare butonul care va direcționa

utilizatorul spre garajele introduse de acesta.

37

După cum se poate observa, ecranul ce conține garajele managerului reprezintă o listă.

Din ea se poate selecta pe rând câte un garaj. Opțiunile oferite sunt de editare, ștergere garaj

sau anulare a selecției făcute.

38

După cum sugerează și numele, funcția de editare permite schimbarea datelor garajului

cum ar fi numele, adresa, în caz că acesta a fost mutat, detaliile, poate au fost adăugate funcții

noi. Deasemenea pot fi editate coordonatele garajului. Acestea pot fi adăugate automat

utilizând locația telefonului sau pot fi introduse manual de utilizator. Accesarea butonului de

editare va trimite noile detalii ale garajului selectat către server, actualizându-le.

Meniu, Adaugă garaj

Meniul aplicației poate fi accesat din ecranul profilului utilizatorului, utilizând butonul

din stânga sus. Acesta prezintă opțiunile oferite de aplicație. Una dintre opțiunile utilizatorului

manager este aceea de a adăuga garaje noi.

Opțiunea de adăugare garaj folosește același ecran ca cea de editare. Utilizatorul este

nevoit să completeze toate câmpurile pentru a crea un garaj valid. Adăugarea coordonatelor se

face în același mod în care se face și în ecranul de editare. Butonul de adăugare va trimite la

server noul garaj creat.

39

Caută garaj

Funcțiile oferite de aplicație, de adăugare și căutare de garaje sunt cele mai importante

pentru aplicație și pentru utilizatori.

40

În acest ecran sunt afișate poziția utilizatorului și a garajelor pe hartă. Tot aici se pot

obține informații în legătură cu garajele dar și crearea de rute spre acestea. Prin atingerea unui

marker de pe hartă se crează o rută spre garajul selectat și se pot observa informații sumare

despre acesta. Selectarea ferestrei cu informații va redirecționa utilizatorul în fereastra cu

detaliile garajului selectat.

Setări

O altă opțiune oferită de aplicație este cea aflată în ecranul pentru setări, accesibil din

meniu și anume posibilitatea de schimbare a limbii utilizate în aplicație.

Deconectare

O ultimă opțiune oferită de aplicație tot prin intermediul meniului este cea de

deconectare a utilizatorului. Odată selectată această funcție, datele contului sunt șterse din

memoria telefonului iar aplicația este redirecționată la ecranul de conectare.

41

5. Concluzii

Aplicația Auto Service Finder se adresează utilizatorilor care îndeplinesc unul din cele

două roluri, șofer auto sau manager de garaj. Ceea ce-și propune aplicația să îndeplinească este

ajutarea managerilor în promovarea service-urilor auto iar pe șoferi cu posibilitatea alegerii

dintr-o gamă variată de opțiuni.

Un pas important îl reprezintă direcția de viitor. Noi funcții pentru a îmbunătăți și pentru

a mări numărul de servicii puse la dispoziție în cadrul aplicației, ar putea fi implementate.

- un sistem de rating pentru garaje

Posibilitatea utilizatorilor șoferi de a aprecia mai bine sau mai rău serviciile primite în

urma alegerii garajului dorit.

- un sistem de review-uri și comentarii

O notă primită de un garaj nu spune multe însă o descriere mai amplă a acestora ar

putea ajuta alți utilizatori în momentul în care aceștia sunt în fața unei alegeri.

- un sistem de comunicare șofer-manager

În cazul în care utilizatorii șoferi au întrebări, nelămuriri în legătură cu anumite chestiuni

aceste ar putea fi rezolvate printr-un schimb de mesaje

Aceste câteva idei arată faptul că aplicația poate avea continuitate oferind noi servicii,

îmbunătățite care ar putea veni în sprijinul utilizatorilor ei.

42

6. Bibliografie

[1] Google Maps iOS SDK

https://developers.google.com/maps/documentation/ios-sdk/

[2] iOS

https://developer.apple.com/ios/

[3] Objective C

https://developer.apple.com/reference/objectivec

[4] Xcode

https://developer.apple.com/xcode/

[5] Java

https://www.oracle.com/java/index.html

[6] Eclipse

https://eclipse.org/

[7] Framework-ul Jetty

https://eclipse.org/jetty/

[8] MySQL

https://dev.mysql.com/

[9] Diagrama versiunilor iOS, iulie 2016

http://blogs.cisco.com/getyourbuildon/fosdem-2016-part-4-what-netflows-tells-us

[10] Model View Controller în dezvoltarea aplicațiilor iOS

https://developer.apple.com/library/content/documentation/General/Conceptual/Dev

Pedia-CocoaCore/MVC.html

[11] Schema Model View Controller

https://developer.apple.com/library/content/documentation/General/Conceptual/Dev

Pedia-CocoaCore/Art/model_view_controller_2x.png

[12] Model View Controller

http://msdn.microsoft.com/en-us/library/ff649643.aspx

[13] Biblioteca ViewDeck

https://github.com/ViewDeck/ViewDeck