lurar linŢĂ - profs.info.uaic.roalaiba/pub/absolvire/2017 iarna/auto service finder.pdf · un...
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