ef lucr. dr. inf. Pitic Antoniu Gabriel Îndrumător: Ș ef lucr. dr. inf. Pitic Antoniu Gabriel Absolvent: Rădulescu Vasile-Adrian Specializarea:… [603467]

UNIVERSITATEA “LUCIAN BLAGA” DIN SIBIU

FACULTATEA DE INGINERIE

DEPARTAMENTUL DE CALCULATOARE
Ș
I INGINERIE ELECTRICĂ

Proiect de diplomă

Conducător
ș
tiin
ț
ific:
Ș
ef lucr. dr. inf. Pitic Antoniu Gabriel

Îndrumător:
Ș
ef lucr. dr. inf. Pitic Antoniu Gabriel

Absolvent: [anonimizat]: Calculatoare

– Sibiu, 2018 –

UNIVERSITATEA “LUCIAN BLAGA” DIN SIBIU

FACULTATEA DE INGINERIE

DEPARTAMENTUL DE CALCULATOARE
Ș
I INGINERIE ELECTRICĂ

Business Clock, Weather and News

Conducător
ș
tiin
ț
ific:
Ș
ef lucr. dr. inf. Pitic Antoniu Gabriel

Îndrumător:
Ș
ef lucr. dr. inf. Pitic Antoniu Gabriel

Absolvent: [anonimizat]: Calculatoare

1

Proiect de diplomă
0

Business Clock, Weather and News
1

Abstract
3

Capitolul 1. Introducere
4

1.1 Contextul proiectului
4

1.1.1 Fusuri orare
5

1.2 Ideea proiectului
6

1.3 Solu
ț
ii existente în domeniul proiectului (state of the art)
7

Capitolul 2. Arhitectura aplica
ț
iei
10

Capitolul 3. Tehnologii folosite
12

3.1 Swift
13

3.1.1 Limbajul de programare Swift
15

3.2 SQLite
18

3.2 Sistemul de operare iOS
19

3.3 Model-View-Controller pattern
24

3.4 Swifty JSON
25

3.5 Servicii REST
26

Capitolul 4. Detalii de implementare
29

4.1 Dosarul principal
30

4.2 Model Folder
31

4.3 View and Cells folder
32

4.4 Controllers folder
33

4.4.1 Configurare indicatoare ceas
33

4.4.2 Adăugarea unui ora
ș
37

4.5 Resources folder
41

Capitolul 5. Utilizarea aplica
ț
iei
43

2

5.1 Descrierea aplica
ț
iei
43

5.2 Scenarii de utilizare
47

Capitolul 6. Concluzii
58

Capitolul 7. Bibliografie
59

3

Abstract

Lucrarea are ca scop prezentarea detaliilor de design
ș
i implementare a proiectului

Business Clock, Weather and News.

Proiectul Business Clock, Weather and News este construit pentru a furniza o gama

cat mai larga de informa
ț
ii despre un anumit ora
ș
utilizând cea mai uzuala metoda de a accesa

informa
ț
ii, folosind smart phone-uri. Acesta este structurat pe capitole, încercând să acopere

informa
ț
iile de baza privi nd ideea, arhitectura, tehnologiile, etc.

Primul capitol cuprinde introducerea în sfera proiectului, oferind informa
ț
ii generale

structurate pe subcapitole. Primul subcapitol se refera la încadrarea proiectului în contextul

actual, următorul capitol reprezentând motiva
ț
ia ideii care a dus la crearea acestui proiect.

Ultimul subcapitol cuprinde un rezumat
ș
i un rezultat al cercetărilor realizate asupra

aplica
ț
iilor deja existente pe pia
ț
ă.

Următorul capitol prezintă arhitectura aplica
ț
iei. Pentru că am încercat sa utilizez o

implementare cât mai standardizata, am plecat de la modele utilizate în general, acestea fiind

prezentate într-o diagramă.

Al treilea capitol este constituit din tehnologiile studiate
ș
i folosite în carul

proiectului, descrise succint, pentru a ajuta cititorul sa în
ț
eleagă rolul folosirii acestora
ș
i

pentru a crea o imagine în legătură cu modul de utilizare al lor. Tehnologiile utilizate sunt

gratuite
ș
i se încadrează î n cele mai folosite tehnologii pentru astfel de proiecte.

Al patrulea capitol cuprinde detaliile de implementare
ș
i modul de folosire a

tehnologiilor , aici regăsindu-se
ș
i por
ț
iuni de cod care explică mo dul de implementare al

proiectului.

Al cincilea capitol este conceput pentru a prezenta aplica
ț
ia, designul acesteia precum

ș
i modul de utilizare. În a cest capitol regăsim capturi de ecran care prezintă modul în care

aplica
ț
ia a fost concepută .

Al
ș
aselea capitol este dedicat concluziilor realizate pe procesul dezvoltării

proiectului, precum
ș
i direc
ț
ia dezvoltărilor viitoare.

În ultimul capitol am enumerat resursele la care am apelat pentru a face posibila

realizarea acestei aplica
ț
ii.

4

Capitolul 1. Introducere

1.1 Contextul proiectului

În contextul actual în care comunicarea este din ce în ce mai importantă, iar nevoia de

a fi în contact cu ceilal
ț
i se manifestă în toate activită
ț
ile, tehnologia joacă un rol esen
ț
ial.

Tehnologia modernă sprijină această nevoie, iar dispozitivele mobile reprezintă probabil

exponentul cel mai de seamă al acestei tehnologii. Noile telefoane, dotate cu sisteme de

operare din ce în ce mai avansate, tind să con
ț
ină o parte din personalitatea noastră: agenda

telefonică,
ș
tiri de ultimă oră, alarme, contacte cu prietenii, jocuri, întâlniri de afaceri, dieta,

orarul tratamentului medicamentos, etc..

Rata
de
utilizare
a
telefoanelor
inteligente
în
rândul
popula
ț
iei
din
România
a
explodat

în
ultimii
ani,
ajungând
la
circa
40%
în
prezent,
la
fel
ca
ș
i
consumul
de
date
mobile,
în
timp

ce aproximativ 32% din români folosesc internetul pe mobil imediat ce se trezesc.[5]

Pentru
că
tehnologia
actuală
face
posibilă
comunicarea
la
orice
distan
ț
ă
cu
orice

“col
ț
”
al
lumii,
discu
ț
iile
ș
i
ș
edin
ț
ele
prin
mediul
on-line
sunt
la
ordinea
zilei
pentru
foarte

multe companii, mai ales pentru cele din domeniul IT.

Proiectul
se
încadrează
în
domeniul
înlesnirii
comunicării
dintre
oameni
afla
ț
i
în
ț
ări

diferite,
în
fusuri
orare
diferite
ș
i
cu
programe
de
lucru
diferite.
Această
aplica
ț
ie
se
axează

majoritar
pe
mediul
urban,
mai
exact
mediul
business
deoarece
în
aceste
medii
sunt
folosite

cu
precădere
întâlnirile
ș
i
ș
edin
ț
ele
on-line
ș
i
se
bazează
pe
diferen
ț
a
de
fusuri
orare
dintre

persoane,
pe
baza
căreia
se
personalizează
toate
detaliile
ce
urmează
sa
fie
prezentate.
Mai

jos se regăsesc detalii despre fusuri orare, diferen
ț
a de timp dintre diferite regiuni ale Terrei.

5

1.1.1 Fusuri orare

Un
fus
orar
este
o
zonă
pe
Terra
în
care
este
legal
în
vigoare
aceea
ș
i
oră
.
Timpul
aflat

legal în vigoare într-un anumit loc mai este numit standard sau oră locală.

Timpul
civil
se
define
ș
te
prin
măsurători
astronomice
astfel
încât
amiaza
locului

(Soarele
este
în
apogeu
pe
cer)
coincide
cu
ora
12,
dar
astfel
s-ar
ajunge
la
situa
ț
ia
în
care

fiecare
loc
de
pe
Pământ
ar
avea
o
oră
diferită,
lucru
nu
tocmai
ideal
într-o
lume
atât
de

interconectată.
Pentru
locurile
situate
pe
acela
ș
i
meridian,
timpul
civil
este
acela
ș
i
cu
timpul

legal.

Pentru
a
se
evita
situa
ț
ia
de
mai
sus
s-a
stabilit
împăr
ț
irea
suprafe
ț
ei
Pământului
în

zone
numite
fusuri
orare,
fiecare
meridian
având
asociat
un
meridian
denumit
meridianul

central
al
fusului
orar.
În
cadrul
marin
sunt
luate
ca
meridiane
centrale
toate
cele
ce
sunt

multiplu
de
15°.
Se
ajunge
astfel
că
diferen
ț
a
în
orice
punct
de
pe
Terra
dintre
timpul
legal
ș
i

civil
să
fie
de
maxim
30
de
minute.
Timpul
legal
al
fiecărui
fus
orar
este
specificat
în
rela
ț
ie

cu timpul universal coordonat (UTC), acesta reprezentând timpul civil al meridianului 0°.[7]

Figura 1.1.1.1 Fusurile orare mondiale standard [7]

În realitate însă, liniile de separare dintre fusurile orare sunt alterate astfel încât să

corespundă peste grani
ț
ele statelor, ajungându-se în acest fel la existen
ț
a unei diferen
ț
e mai

mari de 30 de minute între timpul civil
ș
i timpul legal.

6

1.2 Ideea proiectului

Ideea proiectului a pornit de la nevoia diferitelor persoane din mediul înconjurător

serviciului meu, precum
ș
i a mea, de a fluidiza comunicarea dintre persoane aflate în loca
ț
ii

foarte îndepărtate
ș
i nu nu mai, de a păstra o agendă clara
ș
i concisă asupra
ș
edin
ț
elor
ș
i

asupra organizării acestora. Fiind implicat în proiecte care necesitau stabilirea discu
ț
iilor cu

clien
ț
i din alte fusuri orar e, administrarea timpului de lucru
ș
i programarea acestuia a devenit

o provocare, în condi
ț
iile în care orele stabilite împreună cu clientul nu coincid cu timpul

nostru.

De asemenea, observând că de multe ori se ajunge într-un “punct mort” al discu
ț
iei,

am inclus în aplica
ț
ie mo dulele de Weather
ș
i News, care să permită atingerea unor subiecte

comune, subiecte care altfel ar putea fi men
ț
ionate doar după căutări specifice pentru fiecare

client, care pot fi amplasa
ț
i în col
ț
uri diferite ale lumii având pun cte de interes diferite.

În a
ș
a numitul “se col al vitezei” în care trăim
ș
i ne desfă
ș
urăm activită
ț
ile de zi cu zi,

fiecare sarcină care poate fi optimizată, cu siguran
ț
ă va fi. Dificultă
ț
ile men
ț
ionate mai sus

m-au condus la decizia de a încerca să optimizez acest proces cât mai mult, să ofer un mijloc

simplu de cre
ș
tere a nivel ului de calitate în muncă din punctul de vedere al administrării

timpului. Astfel a luat forma aplica
ț
ia Business Clock, Weather and News, al cărui pur scop

este rezolvarea unei probleme de care multe persoane nu sunt con
ș
tiente până nu le este

prezentată, o problemă pe care mul
ț
i o trec cu vederea – timpul
ș
i mai exact organizarea

acestuia într-un mod eficient.

Un avantaj al acestei aplica
ț
ii este că oferă o vedere generală asupra mai multor

domenii dominante din via
ț
a ordinară, folosindu-se de resurse
ș
i servicii gratuite, disponibile

pentru to
ț
i, dar folosite de pu
ț
ini.

7

1.3 Solu
ț
ii existente în domeniul proiectului (state of the art)

Solu
ț
iile existente în domeniu se pot contura prin intermediul unui studiu de pia
ț
ă care

să ajute la crearea unui proiect diferit, pornind de la o idee comună, rolul acestuia fiind

cunoa
ș
terea dinamicii act uale a pie
ț
ei.

Studiul
pie
ț
ei
reprezintă
colectarea
informa
ț
iilor
de
pe
pia
ț
ă,
în
func
ț
ie
de
ce

informa
ț
ii
sunt
necesare ,
dezvoltatorul
abordează
cercetarea
privind
cererea,
oferta
sau

mediul înconjurător de pe pia
ț
a respectivă [2].

În
ceea
ce
prive
ș
te
oferta,
cercetarea
ar
trebui
să
ia
în
considerare
care
sunt
poten
ț
ialii

concuren
ț
i
de
pe
pia
ț
ă,
care
sunt
ofertele
lor
sau
care
este
politi ca
lor
comercială.
Pe
de
altă

parte,
este
importantă
cererea,
deoarece
ea
poate
veni
din
partea
unor
firme
sau
din
partea

consumatorilor
(comunită
ț
ii).
Cunoa
ș
terea
cererii
înseamnă
să
se
ș
tie
care
este
publicul
la

care
dezvoltatorul
dore
ș
te
să
facă
referin
ț
ă
(vârsta,
sex,
segment ,
stil
de
via
ț
ă,
venituri),
care

sunt
motiva
ț
iile
achizi
ț
ionării
unui
produs.
Al
treilea
factor
este,
în
unele
cazuri,
cel
mai

important
deoarece
cunoa
ș
terea
mediului
extern
este
un
factor
pentru
a
în
ț
elege
oportunită
ț
ile

ș
i
ocolirea
posibilelor
amenin
ț
ări.
Acesta
reprezintă
asigurare a
că
reglementările
(legi,

norme,etc.)
sunt
aplicate
corect,
influen
ț
a
situa
ț
iilor
economice,
influen
ț
a
factorilor
sociali

(presiuni
ecologice,
sindicale,
etc.)
sau
existen
ț
a
noilor
tehnologii
pentru
produsul/produsele

în cauză [4].

Un studiu de pia
ț
ă este constituit din mai multe etape:

●
stabilirea contextului în care se încadrează proiectul, acesta fiind studiul aplica
ț
iilor

care oferă capabilită
ț
i similare cu cele oferite de aplica
ț
ia Business Clock, Weather

and News, restrâns însă la nivelul de operare iOS, deoarece compatibilitatea între

platforme nu este momentan posibilă

●
colectarea informa
ț
iilor disponibile în diferite medii (căr
ț
i, site-uri web, etc). Având în

vedere multitudinea de surse disponibile, această sarcina necesită o aten
ț
ie sporită.

Ț
inând cont de co ntextul proiectului, au fost abordate mai multe surse precum

magazinul de aplica
ț
ii disponibil pe sistemul de operare iOS (App Store), rezultatul

fiind unul nesatisfăcător din cauza faptului cămajoritatea acestor aplica
ț
ii oferă un

singur modul separat din cele trei disponibile în aplica
ț
ia prezentata în proiect, în timp

ce nevoia era pentru o colec
ț
ie de func
ț
ionalită
ț
i. Privind modulele individual însă,

8

aceasta cercetare a fost fructuoasă deoarece exista foarte multe aplica
ț
ii care arată
ș
i

func
ț
ionează irepr o
ș
abil.

●
analizarea informa
ț
iilor găsite în amănunt, în urma căreia sa se realizeze grafice
ș
i

statistici, precum
ș
i compara
ț
ii pro
ș
i contra pentru a alege cea mai bună variantă

pentru fiecare modul. [6] Propor
ț
iile problemelor regăsite în urma acestui proces sunt

prezentate în figura de mai jos:

Figura 1.3.1

După cum se poate observa în Figura 1.3.1, majoritatea aplica
ț
iilor studiate se bazează

pe prezentarea de reclame către utilizator, reclame care de multe ori împiedică utilizarea în

condi
ț
ii normale a aplica
ț
iei. De asemenea, acestea au implica
ț
ii la nivelul performan
ț
ei

deoarece utilizează accesul la internet, acest lucru aducând cu sine un consum mai mare de

date.

Aplica
ț
ia BCWN nu se bazează pe reclame, deoarece serviciile folosite sunt oferite

gratuit, iar scopul acesteia este o alternativă sănătoasă la ceea ce se regăse
ș
te pe pia
ț
ă în

contextul proiectului.

9

●
ultimul pas în acest proces îl reprezintă raportul studiului, raport efectuat în urma

analizei avantajelor
ș
i dezavantajelor.Luând în considerare contextul prezentat mai

sus, pe pia
ț
ă nu ex istă aplica
ț
ii care să satisfacă suficient d e bine consumatorii.[6]

10

Capitolul 2. Arhitectura aplica
ț
iei

Aplica
ț
ia Busines s Clock, Weather and News este structurata la nivel abstract pe 4

layere:

●
Frontend

●
Servicii

●
Business

●
Persistenta

Layer-ul de frontend este responsabil cu implementarea, desenarea
ș
i prezentarea

tuturor componentelor grafice din cadrul aplica
ț
iei, la nivelul acestuia realizandu-se logica de

User Interface. Pentru căam dorit o posibilitate mare de customizare a aplica
ț
iei, am ales sa

desenez majoritatea compontentelor folosind imagini clasice, imbracate în clasa Layer oferita

de Swift. Astfel, designul aplica
ț
iei poate fi modificat foarte u
ș
or în func
ț
ie de preferintele

dezvoltatorului, fără a fi nevoie de schimbare de cod complex în cazul unei modificari a unei

imagini. De asemenea, a fost nevoie de gasirea
ș
i implementarea unui component grafic de

tip Switch folosit la selectarea setarilor din cadrul aplica
ț
iei, precum
ș
i la activarea
ș
i

dezactivarea alarmelor.

În layer-ul de servicii am realizat comunicarea cu API-urile oferite de diverse servicii

on-line, cum ar fi cele de la Weather Underground pentru prognoza meteo. Acesta este cel

mai predispus la inconsistente de functionare deoarece serviciile oferite nu sunt garantate,

astfel căa fost nevoie de verificări la fiecare pas din tot procesul de preluare a datelor pentru a

preveni eventuale exceptii
ș
i erori care ar putea “strica” aplica
ț
ia. Din testele rezlizate pana

acum am constatat căserviciile sunt în majoritatea timpului stabile, dar depinde foarte mult de

loca
ț
ia pentru care se dor esc informatiile

Layer-ul de business se ocupa cu trnasportul datelor intre diferite componente
ș
i

servicii din cadrul aplica
ț
iei, în incercarea de a realiza o implementare “low coupled”,

implementare care este foarte u
ș
or de diagnosticat
ș
i care oferă o reducere a complexitatii

logicii de functionare a diferitelor metode.

11

Persistenta este un layer foarte important care este folosit pe tot parcursul aplica
ț
iei,

deoarece fără acesta am putea realiza doar aplica
ț
ii cu o complexitate extrem de redusă
ș
i care

nu ar aduce un real beneficiu problemei pe care aplica
ț
ia Business Clock, Weather and News

încearcă sa o rezolve într-o oarecare măsură.
De asemenea, pe lângă aspectul vital de stocare

a datelor legate de alarme
ș
i loca
ț
ii, acest layer are implica
ț
ii
ș
i în experienta utilizatorului în

aplica
ț
ie deoarece print in termediul acestuia se salvează preferin
ț
ele legate de unită
ț
i de

măsură, de
ș
tiri
ș
i altele.

Figura 2.1 Model de arhitectura pe care se bazează aplica
ț
ia

12

Capitolul 3. Tehnologii folosite

Termenul de tehnologie provine din limba greacă de la cuvântul “teknologia”, acesta

fiind format din două cuvinte de bază :
​
“tekhnë” care înseamnă meserie sau artă
ș
i cuvântul

“logos” care înseamnă cuvânt. În programare, termenul de tehnologie se referă la algoritmul

sau multitudinea de algoritmi combina
ț
i care ajută la dezvoltarea unui produs software.[20]

După definirea unei arhitecturi pentru o aplica
ț
ie, este necesară stabilirea tehnologiilor

ce vor fi utilizate în cadrul proiectului, din urma cărora să rezulte produsul final. Un aspect

foarte important îl reprezintă compatibilitatea acestor tehnologii, fiind astfel nevoie de o

cercetare temeinică înainte de a se începe dezvoltarea pentru a se evita situa
ț
ia în care

aplica
ț
ia trebuie să sufere o schimbare majoră pentru că anumite tehnologii nu pot să coexiste

în acela
ș
i context.

3.1 Swift

Swift este un limbaj de programare cu scop general, orientat obiect, dezvoltat de către

compania Apple pentru sistemele de operare proprietare acestora (iOS, macOS, watchOS,

tvOS), fiind mai apoi pus la dispozi
ț
ie
ș
i pentru Linux. Limbajul Swift este proiectat astfel

încât să lucreze cu framework-urile proprietare Apple Cocoa
ș
i Cocoa Touch, păstrând însă

compatibilitatea cu Objective-C
​
. Folosirea librăriilor runtime ale Objective-C permite

executarea de cod C++, Objective-C
ș
i Swift în cadrul aceluia
ș
i program.[17]

Încă de la lansarea acestuia, Swift s-a situat în topurile limbajelor de programare, dar

fiindcă este foarte specific pentru mediul Apple, implicit aplica
ț
iile pentru sistemele acestora,

răspândirea
ș
i acceptarea acestuia au fost îngreunate. Programatorii doresc sa înve
ț
e
ș
i să se

specializeze pe limbaje
ș
i medii de programare care le permit să î
ș
i aplice cuno
ș
tin
ț
ele pe o

multitudine de platforme, un exemplu foarte bun fiind Java. Totu
ș
i, Swift are câteva elemente

specifice care au fost primite cu deschidere de către programatori, printre care se numără

renun
ț
area semnului punc t
ș
i virgula la sfâr
ș
itul fiecărei linii de cod, semănând în acest fel cu

Ruby
ș
i făcând utilizarea limbajului mult mai facilă
​
.[16] De asemenea, modulul Playgrounds

este un alt element specific, în care
​
se poate observa foarte clar cum se compilează
ș
i rulează

13

diferite fragmente de cod, făcând astfel învă
ț
area
ș
i testarea acestui limbaj un proces mult mai

u
ș
or pentru începători, da r în asemenea măsură
ș
i pentru cei mai avansa
ț
i.

Figura 3.1.1 Playgrounds

Pentru codul de mai sus, se poate observa că în partea dreapta avem o consola “live”,

în care putem observa variabilele
ș
i valorile acestora în timp ce acestea rulează
ș
i imediat la

scriere dacă se pot compila
ș
i rula rapid (în background).[18]

De asemenea, Swift dispune de un sistem de “colectare a gunoaielor” a
ș
a cum

regăsim de exemplu în Java, acesta presupunând eliminarea din memorie a tuturor obiectelor

ș
i informa
ț
iilor în mod automat de către sistem, nefiind necesară implicarea programatorului

în procesul de alocare
ș
i dealocare a resurselor, asa cum era de exemplu cazul limbajelor mai

vechi în care administrarea memoriei era o problema foarte importantă.

14

3.1.1 Limbajul de programare Swift

Limbajul Swift este bazat pe programarea orientata obiect sau OOP (Object Oriented

Programming), acesta fiind un concept de programare apărut în anii 1950-1960. Un sistem

orientat obiect are la baza comunicarea dintre doua sau mai multe obiecte.

Obiectul se caracterizează prin stare
ș
i comportament, fiind compus din proprietă
ț
i
ș
i

metode care să asigure comunicarea. Metodele reprezintă de fapt func
ț
iile clasice din

cunoscutele limbaje de programare precedente, cu o diferen
ț
ă majora,
ș
i anume pointer-ul

“this” care se referă la contextul actual în care ne aflam,
ș
i anume func
ț
ia. În momentul în

care se apelează o metoda, se trimite de fapt un mesaj unui obiect sau mai multora,

instruindu-le cu privire la ce anume trebuie să facă.[16] O metodă poate avea mai mul
ț
i

parametri de intrare
ș
i un singur parametru de ie
ș
ire, printre care se afla
ș
i “void”. În cazul

Swift se poate returna un tuplu de valori, astfel că nu suntem limita
ț
i la o singura valoare sau

la un vector de valori. De asemenea, acest lucru ne oferă posibilitatea de a returna valori de

tip diferit, un exemplu fiind cel de mai jos:

În exemplul de mai sus, constantei “http404error” i se atribuie tuplul de valori 404
ș
i

Not Found, acestea fiind de tip Int
ș
i String. Astfel, se pot returna o combina
ț
ie de valori de

diferite tipuri, făcând implementarea metodelor complexe, mult mai u
ș
oară, nefiind nevoie de

împăr
ț
irea unei metode p rincipale în mai multe doar pentru a ob
ț
ine rezultatul dorit.

Acest tuplu de valori are mai multe func
ț
ionalită
ț
i foarte folositoare, precum

descompunerea acestuia în componentele ce îl alcătuiesc:

Un alt element definitoriu pentru Swift este reprezentat de “Optionals”, un concept

relativ u
ș
or de utilizat la î nceput dar care se dovede
ș
te foarte util. Aceste op
ț
ionale se

folosesc în contextele în care o valoare poate fi absentă, fiind foarte folositoare în cazurile în

15

care se a
ș
teaptă după valo area unei variabile sau nu exista certitudinea acesteia, oferindu-se

astfel posibilitatea de a implementa
ș
i de a continua programul în func
ț
ie de cazurile

prezentate mai jos. Un op
ț
ional reprezinta doua posibilită
ț
i:

●
exista valoare pentru variabila respectiva, caz în care se poate face unwrap la aceasta

ș
i se poate folosi v aloarea din interior

●
nu exista valoare, caz în care se va arunca o excep
ț
ie

În imaginea de mai sus, variabila “serverResponseCode” este declarata ca Int?,

semnul ? indicând faptul că este un op
ț
ional,
ș
i i se atribuie valoare 404. Dacă încercăm să ii

facem unwrap, vom găsi ca variabila este de tip Int
ș
i con
ț
ine valoarea definita mai sus. Dacă

însă ii atribuim nil (null) într-un fragment de cod mai jos, valoarea acestuia va fi null, de
ș
i

mai sus a fost declarata ca fiind Int.

În principiu, limbajul Swift se bazează pe clase
ș
i structuri, acestea fiind mult mai

apropiate ca func
ț
ionalita te decât în alte limbaje, păstrând însă diferen
ț
ele de rigoare.

Clasele
ș
i structurile au m ulte lucruri în comun, ambele fiind capabile de:

●
definirea unor proprietă
ț
i pentru a stoca valori

●
definirea unor metode pentru a oferi func
ț
ionalită
ț
i

●
definirea de ini
ț
ializatori pentru a seta starea ini
ț
ială

●
a fi extinse pentru a-
ș
i mari func
ț
ionalitatea dincolo de o i mplementare default

Pe lângă cele de mai sus, clasele au func
ț
ionalită
ț
i care nu sunt regăsite
ș
i în cazul

structurilor:

●
inheritance, permite mo
ș
tenirea caracteristicilor altor clase

●
type casting care permite verificare
ș
i interpretarea unei clase la runtime

●
deinitializatori care permit dealocarea manuala a resurselor atribuite unei clase

●
numărarea referin
ț
elor care permite ca o instan
ț
ă de clasa sa fie referen
ț
iată de mai

multe obiecte

16

În imaginea de mai sus se poate observa diferen
ț
a dintre declararea unei structuri,

respectiv a unei clase. În structura denumita Resolution sunt definite doua proprietă
ț
i, iar în

clasa denumita VideoMode sunt definite patru proprietă
ț
i variabile stocate, printre care se

regăse
ș
te
ș
i structura definita mai sus.

Caracteristicile principale ale limbajului Swift:

●
Securitate
​
– este un limbaj de programare foarte sigur, furnizând mecanisme

complexe de securitate, fiind ajutat
ș
i de faptul că este orientat către platforme

proprietare

●
Neutralitate
​

​
arhitecturala
​
– rularea unei aplica
ț
ii nu depinde de arhitectura fizică a

device-ului pe care rulează

●
Robuste
ț
e
​
– prin e liminarea pointerilor, administrarea automata a memoriei
ș
i

eliminarea elementelor nefolositoare

●
Performan
ț
ă
​
– fiind orientat către mediul Apple, acest limbaj este foarte bine

optimizat pentru device-urile proprietare, nefiind nevoie sa se adapteze pentru diverse

sisteme de operare sau telefoane

17

3.2 SQLite

SQLite este un sistem de management al datelor rela
ț
ional con
ț
inut într-o librărie de

programare C. Comparativ cu alte sisteme de management al datelor, SQLite nu este o bază

de date client-server, aceasta fiind incorporată în program. SQLite este cea mai folosita bază

de date din lume, fiind folosită în browsere, sisteme de operare
ș
i sisteme incorporate, fiind

foarte populară pentru aplica
ț
iile mobile.[14]

Engine-ul SQLite nu are procese de sine stătătoare cu care aplica
ț
ia în care este folosit

să comunice, acesta devenind parte integrantă a aplica
ț
iei deoarece este legat de aceasta.

Acesta este descris ca fiind “zero-conf” deoarece nu necesita un serviciu de configurare (cum

ar fi un script de pornire), sau controlul accesului bazat pe parole. Accesul controlului este

gestionat pe baza permisiunilor fi
ș
ierelor de sistem date bazei de date

SQLite este un motor de bază de date SQL încorporat. Spre deosebire de cele mai

multe baze de date SQL, SQLite nu are un proces server separat. SQLite cite
ș
te
ș
i scrie direct

fi
ș
ierele obi
ș
nuite pe disc. O bază de date completă SQL cu mai m ulte tabele, indicii,

declan
ș
atoare
ș
i vizualizări este con
ț
inută într-un singur fi
ș
ier de disc. Formatul de fi
ș
ier de

bază de date este cross-platform – pute
ț
i copia în mod liber o bază de date între sistemele pe

32 de bi
ț
i
ș
i pe 64 de bi
ț
i sau între arhitecturile mari-endian
ș
i pu
ț
in endian . Aceste

caracteristici fac SQLite o alegere populară ca format de fi
ș
ier de aplica
ț
ie . Fi
ș
ierele bazei de

date SQLite sunt un format recomandat de stocare de către Biblioteca Congresului SUA.

SQLite este o bibliotecă compactă. Cu toate func
ț
iile activate, dimensiunea bibliotecii

poate fi mai mică de 500KiB, în func
ț
ie de platforma
ț
intă
ș
i de setările de optimizare a

compilatorului. (Codul pe 64 de bi
ț
i este mai mare
ș
i unele optimizări ale compilatoarelor,

cum ar fi inscrip
ț
ionarea agresivă a func
ț
iilor
ș
i derularea buclelor, pot determina un cod de

obiect mult mai mare.) Există un compromis între utilizarea memoriei
ș
i viteza. SQLite

rulează în general mai repede cu cât mai multă memorie le da
ț
i. Cu toate acestea, performan
ț
a

este de obicei destul de bună chiar
ș
i în medii cu memorie redusă. În func
ț
ie de modul în care

este utilizat, SQLite poate fi mai rapid decât sistemul I / O direct de sistem de fi
ș
iere.[15]

18

3.2 Sistemul de operare iOS

iOS este un sistem de operare bazat pe Unix creat
ș
i dezvoltat de către compania

Apple pentru hardware-ul exclusiv acestora. Este al doilea cel mai popular sistem de operare,

fiind detronat doar de Android. Acesta sta la baza iPhone, iPad
ș
i iPod Touch.

Dezvăluit ini
ț
ial în 2007
ș
i orientat exclusiv pentru iPhone , acesta a fost ulterior extins

ș
i pentru iPod touch în se ptembrie 2007.

Figura 3.2.1 Logo iOS[8]

Interfa
ț
a iOS este bazată pe manipulare directă, folosind gesturi multiple (denumite

multi-touch). Controlul elementelor de interfa
ț
ă se realizează prin intermediul sliderelor,

switch-urilor
ș
i butoanelo r. La nivel de sistem de operare sunt definite diferite gesturi (swipe,

pinch, etc), care însă pot fi alterate pentru a satisface nevoile aplica
ț
iilor în care sunt folosite,

recomandarea venita de la Apple fiind însă să se păstreze pe cat posibil func
ț
ionalită
ț
ile

originale pentru a păstra o consistenta pe parcursul întregii experiente a utilizatorului.

Pentru a sugera importan
ț
a acestei consisten
ț
e, fiecare aplica
ț
ie care se dore
ș
te să fie

pusă spre disponibilitatea utilizatorilor trebuie să se conformeze unor standarde impuse de

Apple, standarde care se numesc “Human Interface Guidelines”. Acest document con
ț
ine un

set de reguli
ș
i de sugesti i care trebuie să fie respectate de către toate aplica
ț
iile. Consecin
ț
ele

nerespectării acestora fiind unele mai pu
ț
in plăcute deoarece fiecare aplica
ț
ie este supusă unei

verificări înainte de a fi publicată în AppStore (magazinul online de aplica
ț
ii proprietar

Apple)
​
. Încălcarea acestor reguli atrage respingerea publicării aplica
ț
iei în AppStore,

publicarea aplica
ț
iei fiind posibilă doar după remedierea regulilor încălcate.

19

[8]

Figura 3.2.2 Utilizarea iOS

Graficul de mai sus ilustrează utilizarea diferitelor versiuni de sisteme de operare

conform statisticilor oferite de AppStore pana la data de 31 mai 2018.

Figura 3.2.3 – Structura iOS generală [3]

20

Structura generală iOS este alcătuită din patru componente, asa cum se poate observa

în Figura 3.2.3, acestea fiind:

●
Core OS –
​
nivelul Core OS con
ț
ine sistemul de operare
ș
i serviciile pe care sunt

construite celelalte tehnologii pentru aplica
ț
ia iOS

●
Core Services – serviciile de bază reprezintă un set de interfe
ț
e de programare a

aplica
ț
iilor iOS, c are din punct de vedere arhitectural sunt sub Cocoa Touch. În plus

fa
ț
ă de Funda
ț
ia Core, acestea includ
ș
i alte API-uri, inclusiv Grand Central Dispatch,

CFNetwork
ș
i OSServices

●
Media –
​
nivelul media se referă la framework-uri
ș
i tehnologii software care permit

capabilită
ț
i audio, vizuale
ș
i alte multimedia într-un dispo zitiv cu iOS. Acesta

define
ș
te întreaga arhitectură multimedia în dispozitivele
ș
i aplica
ț
iile mobile din

universul Apple

●
Cocoa Touch – este un framework pentru User Interface folosit la construirea de

programe software care rulează pe iOS pentru iPhone, iPod Touch
ș
i iPad

21

Figura 3.2.4 Arhitectura iOS [9]

22

În Figura 3.2.4 se poate observa în mod detaliat arhitectura sistemului de operare iOS,

acesta fiind împăr
ț
it în m ai multe categorii generale, asa cum putem observa în figura 3.2.3.

Multe framework-uri din cele de mai sus sunt regăsite
ș
i în arhitectura celorlalte produse de

la Apple, precum WatchOS sau TVOS.

Pentru a adăuga un layer de securitate, s-a introdus ideea de sandbox specific fiecărei

aplica
ț
ii, astfel că aplica
ț
iile rulează în propriul lor mediu, fără a a vea impact direct asupra

celorlalte sisteme din cadrul iOS. Până la introducerea folderului de Files, care permite

accesarea
ș
i gestionarea t uturor fi
ș
ierelor din cadrul sistemului de operare, transferul de

fi
ș
iere intre diferite aplica
ț
ii era destul de complicat, tocmai pentr u a descuraja
ș
i împiedica

eventuale bre
ș
e de securi tate.

Am ales sa folosesc sistemul de operare iOS în cadrul proiectului Business Clock,

Weather and News deoarece dezvoltarea aplica
ț
iilor este foarte facilă în condi
ț
iile în care

de
ț
ii un computer Apple, având la dispozi
ț
ie o multitudine de resurse
ș
i comunită
ț
i care să

sprijine dezvoltarea eficientă de aplica
ț
ii. Un alt factor important a fost limbajul de

programare Swift, prezentat mai sus.

23

3.3 Model-View-Controller pattern

În implementarea proiectului s-a utilizat modelul de programare de tip “Model View

Controller”, sau a
ș
a cum este cunoscut prescurtat MVC. Dintr-un punct de vedere high-level,

MVC este precum ii spune numele, fiind alcătuit din 3 layere:

●
Modelul
​
este locul în care se regăsesc datele, locul în care persisten
ț
a, modelele

obiectelor, parserele
ș
i codul care implică re
ț
eaua sunt implementate

●
View-ul
​
este “fata” aplica
ț
iei, clasele sunt de obicei reutilizabile deoarece nu sunt

legate de o anumită implementare. Un exemplu ar fi tabelul din iOS

●
Controller-ul
​
este mediatorul dintre cele două men
ț
ionate mai sus, de obicei prin

intermediul unui model de delega
ț
i. Într-un scenariu ideal, controllerul nu trebuie să

cunoască niciun detaliu de implementare din cele două de mai sus, logica aplica
ț
iei

fiind definită în Model
ș
i View.

Figura 3.1 MVC [10]

24

3.4 Swifty JSON

JavaScript Object Notation (JSON) este un format de schimb de date foarte utilizat

datorita u
ș
urin
ț
ei cu care poate fi citit
ș
i scris de către oameni
ș
i pentru u
ș
urin
ț
a computerelor

în a-l parsa
ș
i genera. JSO N este construit pe doua structuri:

●
o colec
ț
ie de pere chi nume/valoare

●
o lista ordonata de valori[ 17]

Limbajul de programare Swift pune foarte tare accent pe tipul datelor, ceea ce în

multe situa
ț
ii este foarte b enefic,dar în cadrul prelucrării JSON devine o dificultate. Pentru că

parsarea
ș
i generarea de J SON în contextul pur Swift necesită o mul
ț
ime de blocuri

conditionale “if”, au apărut librării care să facă această muncă mai u
ș
oară, a
ș
a cum este cazul

SwiftyJSON.

Pentru a prelua o valoare din JSON în context pur Swift, ar fi nevoie de cod precum în

imaginea de mai jos, ceea ce nu reprezintă cea mai bună
ș
i cea mai eficientă variantă:

Folosind SwiftyJSON, tot codul de mai sus se reduce la:

Se observă clar avantajul acestei librarii, dar pe lângă toate acestea, SwiftyJSON

rezolvă
ș
i problema op
ț
ionalelor men
ț
ionate mai sus, având logica tratării acestora deja

implementată.

25

3.5 Servicii REST

Representational State Transfer (REST) reprezintă o modalitate de a utiliza comenzile

HTTP ca
ș
i API pentru ap lica
ț
ia client. Toate serviciile REST sun t scalabile, au o interfa
ț
ă

uniforma
ș
i sunt mai perf ormante decât serviciile ce utilizează nivelul SOAP peste HTTP.

Toate opera
ț
iile
ș
i datele folosite de REST sunt considerat e resurse, accesibile prin

adrese URI (Uniform Resource Identifiers). În cadrul acestor servicii, server-ul
ș
i clien
ț
ii fac

schimb de informat
ț
ie int re ei folosind o interfa
ț
ă standard
ș
i un protocol.

Cele mai utilizate metode HTPP pentru definirea serviciilor REST sunt:

●
GET

●
POST

●
PUT

●
DELETE

În general, cu metoda GET se realizează citirea unei resurse fără a o modifica,

opera
ț
ia nefiind folosită l a crearea de resurse. POST este utilizat în general la upload-ul unei

noi resurse, sau pentru modificarea uneia deja existente, dar execu
ț
ii repetate pot avea efecte

diferite. PUT este utilizat doar pentru crearea de noi resurse, execu
ț
iile repetate având acela
ș
i

efect ca
ș
i o execu
ț
ie individuală.

REST reprezintă un stil arhitectural bazat pe standardele HTTP
ș
i Web, partea de

server având posibilitatea de a con
ț
ine mai multe nivele, fără ca modificări ale acestora să

aibă efecte asupra poten
ț
ialilor clien
ț
i. De asemenea, are o arhitec tura scalabilă datorită

separări responsabilită
ț
ilor clien
ț
ilor, respectiv a serverului. Ca ex emplu, responsabilitatea

serverului este sa realizeze managementul datelor fără a men
ț
ine nicio stare legată de

utilizatori, în timp ce responsabilitatea clientului este pur
ș
i simplu de a păstra starea unui

utilizator. Serverul nu trebuie sa men
ț
ină nicio stare referitoare la client, concept cunoscut ca

stateless, resursele având posibilitatea de a avea diferite reprezentări (XML, JSON). [11]

26

De fiecare data când este trimis un request către server, acesta prelucrează informa
ț
iile

primite
ș
i returnează un c od de răspuns la cererea primita conform imaginii de mai jos:

Figura 3.5.1 Request serviciu REST [12]

În acest exemplu un client trimite un request de tip GET către un server prin

intermediul HTTP. Intre client
ș
i resurse se regăse
ș
te serverul, acesta fiind singurul care poate

accesa direct resursele. Răspunsul trimis de server are codul 200, ceea ce înseamnă că cererea

a fost procesată cu succes. De asemenea, observăm ca tipul datelor returnate este XML.

Constrângerile stilului arhitectural REST afectează următoarele proprietă
ț
i

arhitecturale:

●
performan
ț
a în int erac
ț
iunile componentelor, care poate fi factorul dominant în

performan
ț
a perce pută de utilizator
ș
i eficien
ț
a re
ț
elei

●
scalabilitate care să permită sus
ț
inerea unui număr mare de componente
ș
i interac
ț
iuni

între componente

●
simplitatea unei interfe
ț
e uniforme

●
capacitatea de modificare a componentelor pentru a răspunde nevoilor în schimbare

(chiar
ș
i în timp c e aplica
ț
ia se execută)

●
vizibilitatea comunicării între componente de către agen
ț
ii de servicii

●
portabilitatea componentelor prin mutarea codului de program cu datele

●
fiabilitatea rezisten
ț
ei la defec
ț
iuni la nivelul sistemului în prezen
ț
a unor defec
ț
iuni în

componente, conectori sau date

27

Ș
ase constrângeri de ghidare definesc un sistem RESTful. Aceste constrângeri

restric
ț
ionează modurile î n care serverul poate procesa
ș
i răspunde solicitărilor clientului,

astfel încât, prin operarea în cadrul acestor constrângeri, serviciul câ
ș
tigă proprietă
ț
i

nefunc
ț
ionale dorite, cum ar fi performan
ț
a, scalabilitatea, simplitatea, capacitatea de

modificare, vizibilitatea, portabilitatea
ș
i fiabilitatea. Dacă un serviciu încalcă oricare dintre

constrângerile necesare, nu poate fi considerat RESTful.

Beneficiile REST folosind protocolul HTTP creează însă
ș
i restric
ț
ii. Multe dintre

limitările HTTP se transformă, de asemenea, în deficien
ț
e ale stilului arhitectural REST. De

exemplu, HTTP nu stochează informa
ț
iile bazate pe stare între ciclurile de solicitare
ș
i

răspuns, ceea ce înseamnă că toate sarcinile de gestionare a stării trebuie să fie executate de

client. [13]

În aplica
ț
ia Busin ess Clock, Weather and News sunt folosite servicii REST intensiv

deoarece toate datele ce trebuie preluate de pe internet, precum informa
ț
iile despre prognoza

meteo
ș
i informa
ț
iile despre
ș
tirile dintr-o anumita zonă.

28

Capitolul 4. Detalii de implementare

În prima versiune, aplica
ț
ia Business Clock, Weather and News este formata din

aplica
ț
ia propriu-zisa pen tru iOS, aceasta fiind în momentul de fa
ț
ă întreg proiectul. În viitor,

ca
ș
i extindere ulterioara a aplica
ț
iei doresc sa adaug un modul de server pentru a permite

crearea de conturi de utilizatori în scopul personalizării mult mai accentuate, precum
ș
i pentru

analizarea unor statistici în func
ț
ie de utilizatori.

Pentru crearea aplica
ț
iei am folosit Swift, ca mediu de dezvoltare am folosit Xcode iar

pentru o mai buna organizare a aplica
ț
iei am folosit module. Proiectul este structurat conform

pattern-ului MVC, asa cum se poate observa în Figura 4.1.

Figura 4.1 Structura proiectului

29

4.1 Dosarul principal

Pentru că în Swift nu există no
ț
iunea de pachete a
ș
a cum este aceasta regăsită în

celelalte limbaje de programare cum ar fi Java, ne vom referi la acestea ca fiind dosare. Astfel

ca în primul folder, cel general aplica
ț
iei regăsim punctele de pornire a aplica
ț
iei
ș
i totodată

printre cele mai importante: Main.Storyboard
ș
i AppDelegate.

“Main”-ul aplica
ț
iei este reprezentat de un Storyboard (sau mai multe în caz că este

nevoie). Storyboard-urile fac parte din modului Interface Builder din cadrul Xcode, rolul

acesta fiind acela de a facilita designul aplica
ț
iilor folosindu-se de drag-and-drop pentru

element grafice. De asemenea, la nivelul acesteia se definesc
ș
i rela
ț
iile dintre dintre

screen-uri precum
ș
i rela
ț
iile dintre diferite elemente grafice.

Figura 4.2 Storyboard-ul aplica
ț
iei

30

Cel de-al doilea punct important men
ț
ionat este clasa AppDelegate, acesta

reprezentând punctul central de configurare generala a oricărei aplica
ț
ii, aici regăsindu-se

setări
ș
i proprietă
ț
i care nu sunt neapărat specifice unei singure ap lica
ț
ii.

Figura 4.3 AppDelegate

4.2 Model Folder

Următorul folder pe care îl regăsim în proiect este cel de Model, la nivelul acestuia

regăsindu-se structura obiectelor
ș
i datelor folosite în general în aplica
ț
ie, un exemplu clasa

CityDetails care con
ț
ine p roprietă
ț
ile observate în Figura 4.4.

Figura 4.4 City Details

31

4.3 View and Cells folder

Cel de-al doilea dosar este cel de “View and Cells” care se referă la modului de View

din pattern-ul MVC. În acesta regăsim toate detaliile de configurare a screen-urilor aplica
ț
iei,

neavând însă detalii de implementare. În acest fel se păstrează o decuplare între diferitele

păr
ț
i din cod, făcând debu g-ul
ș
i dezvoltarea ulterioara mult mai u
ș
oară. De asemenea, o

structură clară
ș
i bine def inită sprijină o mai buna în
ț
elegere a codului pentru cineva care nu a

avut contact cu aplica
ț
ia.

Figura 4.5 HourlyForecastCell

În Figura 4.5 putem observa un exemplu de definire a unui view în care doar se

realizează conexiunile dintre componentele majore ale unui tabel din cadrul screen-ului de

Weather.

32

4.4 Controllers folder

Ultimul folder este “Controllers” care se refera la modulul de Controller din cadrul

pattern-ului MVC. În acest dosar este implementata cea mai multa logica din aplica
ț
ie

deoarece aici se realizează transferul de informa
ț
ie dintre View
ș
i Model, precum
ș
i

comportamentul aplica
ț
iei în cazul utilizării acesteia. Tot în acest dosar se regăse
ș
te
ș
i

implementarea algoritmului de rota
ț
ie a indicatoarelor ceasului deoarece acestea sunt în

legătură directa cu View-ul. Aceasta logica este formata din 2 păr
ț
i pentru fiecare indicator,

una dintre acestea fiind comună.

4.4.1 Configurare indicatoare ceas

Pentru a păstra lucrurile simple
ș
i eficiente, am ales sa rotesc infinit o imagine

conform algoritmului din Figura 4.6. Atunci când este nevoie sa se deseneze, ceasul va avea

nevoie de o pozi
ț
ie (oră) de la care sa pornească, aceasta fiind în cazul nostru ora curenta a

loca
ț
iei pentru care se viz ualizează detaliile. Astfel, pornind de la o valoare care sa reprezinte

ora, minutul sau secunda am implementat metode care sa determine unghiul la care trebuie sa

fie rotita imaginea pentru a ob
ț
ine punctul de pe ceas corespunzător timpului din loca
ț
ia în

cauza.

În exemplele de mai jos sunt prezenta
ț
i algoritmii folosi
ț
i pentru a determina unghiul

la care trebuie rotite imaginile pentru ca acestea sa indice ora corectă primita ca parametru de

tip double.

Figura 4.6 Transformare pentru secunde

33

Figura 4.7 Layer pentru secunde

Figura 4.8 Transformare pentru minute

Figura 4.9 Layer pentru minute

Figura 4.10 Transformare pentru ore

34

Figura 4.11 Layer pentru minute

Pentru a adăuga o posibilitate de customizare aplica
ț
iei, am ales ca indicatoarele

ceasurilor sa se reprezinte folosind imagini, iar pentru acest lucru am avut la dispozi
ț
ie 2

variante, fiecare cu avantaje
ș
i dezavantaje:

●
folosind curbe Bezier pentru a desena cadrul în care se va desena imaginea, aceasta

metoda fiind prima din cele încercate
ș
i cea care oferta avantaje considerabile, dar ale

cărei dezavantaje au făcut ca utilizarea acesteia sa nu fie cea mai buna solu
ț
ie

○
avantaje:

ș
datorita faptului ca curbele Bezier se desenează folosind puncte unite

intre ele, se oferă posibilitatea de a crea forme foarte complexe
ș
i care

sa corespunda complet cu cerin
ț
ele programatorului

ș
încărcare
ș
i desenare a resurselor mai rapida

○
dezavantaje:

ș
se pot seta imagini, dar dimensiunea
ș
i rezolu
ț
ia acestora în cadrul

formelor Bezier nu permite un mare nivel de customizare, astfel ca se

pot ob
ț
ine rezultate neplăcute din punct de vedere vizual

ș
sunt optimizate pentru a seta culori în interior, dar astfel se

restric
ț
ionează utilizarea unor imagini complexe

ș
complexitate crescuta din cauza faptului ca este nevoie sa se calculeze

manual pozi
ț
ia fiecărui punct

●
cea de-a doua varianta este cea implementata
ș
i care presupune folosirea imaginilor

clasice, puse însă într-un layer. Layer-ul este de fapt o clasa din Swift care permite

adăugarea de con
ț
inut în cadrul acestuia. Ca
ș
i mai sus, aceasta metoda are avantaje
ș
i

dezavantaje dar avantajele au avut câ
ș
tig de cauza în acest caz

35

○
avantaje:

ș
putere foarte mare de configurare datorita posibilită
ț
ii de a utiliza

imagini pentru a seta înfă
ț
i
ș
area indicatoar elor ceasului

ș
în
ț
elegere mult mai u
ș
oară a algoritmului
ș
i implicit implementare

ș
complexitate redusa datorata faptului ca este nevoie doar de o

coordonata X
ș
i un Y pentru a seta pozi
ț
ia

○
dezavantaje:

ș
rotirea unei imagini la pozi
ț
ia dorita este mai complicata deoarece

trebuie întâi corectata pozi
ț
ia desenului în imagine, după care a

imaginii în layer-ului
ș
i în final a layer-ul în screen

ș
din cauza ca este nevoie de multe layere pentru a desena un screen

complet cu toate componentele, interac
ț
iunea dintre acestea poate sa

producă confuzie

Algoritmul pentru rotirea imaginii la pozi
ț
ia dorita este prezentat în Figura 4.12.

Primul pas este reprezentat de crearea layerului
ș
i a imaginii pe care urmează să o con
ț
ină

urmând ca mai apoi sa se seteze cadrul în care va fi desenata imaginea. Pentru a putea roti un

layer, este nevoie sa se seteze un punct de ancorare, configurarea acestuia realizându-se prin

setarea coordonatelor X
ș
i Y. Un exemplu este prezentat în Figura 4.13.

Figura 4.12 Configurarea layer-ului

36

Figura 4.13 Setarea punctului de ancorare [1]

4.4.2 Adăugarea unui ora
ș

Adăugarea ora
ș
elor este posibila utilizând API-urile puse la dispozi
ț
ie de Apple
ș
i

Google, astfel ca pentru a ob
ț
ine func
ț
ionalitatea dorita am combi nat serviciile acestora.

În primul rând a fost nevoie sa preiau coordonatele utilizatorului pentru a determina

ora
ș
ul în care acesta se af la în momentul în care se dore
ș
te adăugarea loca
ț
iei curente, aici

fiind folosit API-ul de determinare a loca
ț
iei pus la dispozi
ț
ie de Apple, algoritmul fiind

prezentat în figura 4.14.

37

Figura 4.14 Coordonatele curente

Următorul pas este determinarea ora
ș
ului pe baza coordonatelor de mai sus, aici

intervenind API-ul de la Google, care pe baza latitudinii
ș
i longitudinii determina o loca
ț
ie

aproximativa, urmând ca mai apoi sa returneze un nume pentru loca
ț
ia respectiva. Rezultatele

nu sunt întotdeauna exacte deoarece aproximările sunt realizate în func
ț
ie de acurate
ț
ea cu

care acestea se pot determina. Pentru a folosi API-ul este nevoie de un cont de dezvoltator în

re
ț
eaua Google pentru a p rimi o cheie unica. Aceasta func
ț
ionalitate este foarte utila deoarece

Google oferă tool-uri pentru vizionarea statisticilor legate de apelurile pe care aceste le

prime
ș
te. În figura 4.15 o bservam implementarea algoritmului de determinare a numelui

ora
ș
ului. Atunci când se î ncearcă adăugarea unui ora
ș
, se verifica
ș
i dacă acesta nu există deja

în lista pentru a evita astfel apari
ț
ia duplicatelor (Figura 4.16).

38

Figura 4.15 Determinare nume ora
ș

Figura 4.16 Verificare duplicate

Numele ora
ș
ului n u este important doar din punct de vedere vizual, pentru a ajuta

utilizatorul sa retina numele ora
ș
elor, este folosit pentru modulul de Weather
ș
i va fi utilizat

pentru modulul de News. De aceea este nevoie de o aproximare cat mai corecta a loca
ț
iei, un

nume eronat având un impact negativ asupra experientei utilizatorului.

Aplica
ț
ia Busines s Clock, Weather and News pune la dispozi
ț
ie informa
ț
iile despre

vreme pe parcursul unei zile
ș
i pe parcursul a 3 zile, aceste func
ț
ionalită
ț
i fiind posibile

datorita API-ului de la WeatherUnderground. Aceste API este folosit de majoritatea

39

aplica
ț
iilor de Weather in vestigate în pasul de cercetare a pie
ț
ei, astfel ca acesta a fost un

candidat foarte bun pentru alegerea în implementare. Diferen
ț
a a fost făcută de faptul ca se

oferă un pachet gratuit, limitat însă la un anumita număr de cereri per secunda
ș
i per 24 de

ore, care poate fi accesat cu un simplu cont de utilizator.

Pentru a prelua prognoza meteo pe ore, se interoghează API-ul la un URL format

dinamic la apelarea metodei precum se poate observa în Figura 4.18. În Figura 4.17 se poate

observa formarea URL-ului în func
ț
ie de parametrii metodei. Pentru ca în Statele Unite ale

Americii ora
ș
ele sunt ind exate în func
ț
ie de statul de care apar
ț
in, este nevoie sa se apeleze

API-ul nu doar cu numele ora
ș
ului ci
ș
i cu numele statului.

Figura 4.17 Formarea URL-urilor

Figura 4.18 Prognoza meteo pe ore

40

Figura 4.19 Prognoza meteo pe zile

4.5 Resources folder

Un alt folder semnificativ este cel de Resources în care se regăsesc metodele globale,

implementate pentru a reduce redundanta din cadrul proiectului. Tot aici este implementată

logica de încărcare
ș
i crea re a bazei de date la prima rulare a aplica
ț
iei, prezentata în imaginea

4.20.

Figura 4.20 Baza de date

41

Un punct forte al Swift combinat cu SQLite este posibilitatea de a utiliza query-uri

native către baza de date, făcând astfel procesul de lucru cu datele mult mai u
ș
or.

Figura 4.21 Query-uri SQL

42

Capitolul 5. Utilizarea aplica
ț
iei

Aplica
ț
ia Busines s Clock, Weather and News are ca scop eficientizarea organizării

ș
edin
ț
elor între utilizatori din diferite loca
ț
ii de pe Pământ cu diferite fusuri orare, precum
ș
i

furnizarea de informa
ț
ii despre loca
ț
iile respective precum vreme a
ș
i
ș
tirile specifice în

scopul unei mai bune comunicări între persoanele implicate.

BCWN este dezvoltată pentru sistemul de operare iOS,
ș
i este împăr
ț
ită în mai multe

sub-sisteme:

●
adăugarea
ș
i gesti onarea loca
ț
iilor

●
alarme

●
prognoza meteo

●
ș
tiri

5.1 Descrierea aplica
ț
iei

Aplica
ț
ia iOS ben eficiază de un design u
ș
or de în
ț
eles, atrăgător
ș
i simplist. Prima

pagină este un ”Splash Screen” (observabil în Figura 5.1), aceasta fiind un pas intermediar

între pornirea aplica
ț
iei
ș
i încărcarea acesteia cu scopul de a oferi utilizatorului o experien
ț
ă

plăcută
ș
i fluentă, fără înt reruperi cauzate de procesarea diferitelor elemente grafice necesare.

43

Figura 5.1 Flow-ul aplica
ț
iei

În ecranul principal sunt afi
ș
ate toate ora
ș
ele adăugate anterior, precum
ș
i diverse

detalii despre acestea:

●
ora locală a ora
ș
ului (bazată pe Timezone-ul specific)

●
temperatura (în grade Celsius, precum
ș
i în grade Fahrenheit)

●
o imagine care reprezintă condi
ț
iile meteo actuale

Din pagina principală utilizatorul are posibilitatea de a adăuga noi ora
ș
e (loca
ț
ii),

condi
ț
ia fiind ca ora
ș
ul să nu fie deja prezent în listă, precum
ș
i op
ț
iunea de a
ș
terge o loca
ț
ie

44

deja existentă. Tot din acest punct se poate accesa
ș
i ecranul de setări generale ale aplica
ț
iei

care permit modificarea unită
ț
ilor de măsură pentru temperatură, viteza precum
ș
i a setărilor

legate de func
ț
ionalitatea aplica
ț
iei.

Figura 5.1.1 Loca
ț
ii curente

45

Figura 5.1.2 Splash Screen

46

5.2 Scenarii de utilizare

Pentru a putea folosi aplica
ț
ia în scopul în care aceasta a fost gândită, utilizatorul

trebuie să adauge ora
ș
ele pentru care dore
ș
te informa
ț
ii. Sunt oferite două modalită
ț
i pentru a

realiza acest lucru:

●
adăugarea loca
ț
iei curente, utilizând API-urile puse la dispozi
ț
ie de Apple pentru a

prelua coordonatele GPS
ș
i API-ul Google Maps pentru identificarea loca
ț
iei în

func
ț
ie de coordon atele provenite de le GPS

Figura 5.2.1 Adăugarea loca
ț
iilor

●
a doua modalitate de a adăuga noi ora
ș
e este prin folosirea search-ului, care utilizează

serviciul pus la dispozi
ț
ie de Google pentru a returna ora
ș
e
ș
i coordonate GPS în

func
ț
ie de numele relativ al ora
ș
ului, asa cum se poate obs erva în Figura 5.1.1.

47

După ce utilizatorul adaugă cel pu
ț
in un ora
ș
, se pot accesa detaliile despre acesta

având la dispozi
ț
ie 3 mod ule cu diferite func
ț
ionalită
ț
i. După selectare unei loca
ț
ii, se vor

deschide detaliile despre aceasta, urmând ca mai apoi să se utilizeze o bară de naviga
ț
ie

pentru a schimba între ecranele aplica
ț
iei.

Figura 5.2.2 Tab Bar

Primul dintre acestea este modulul de Alarms, a
ș
a cum se poate observa în Figura

5.2.3. Aici se pot gestiona alarme pentru diferite ore ale loca
ț
iei, urmând ca în backend să se

calculeze diferen
ț
a dintre fusurile orare ale ora
ș
elor (ora
ș
ul curent, respectiv ora
ș
ul adăugat

de user). Un ceas static este afi
ș
at pentru fiecare alarmă, astfel încât ora setată să fie fie

vizibilă de la o primă privire. De asemenea, fundalul fiecărui ceas se setează cu fundaluri

diferite în func
ț
ie de perio ada zilei corespunzătoare alarmei.

Figura 5.2.3 Night Clock

Figura 5.2.4 Day Clock

48

Figura 5.2.3 Alarms Screen

Pentru a fi setată o nouă alarmă, se apasă butonul ”+”, care va deschide un nou screen

cu detaliile despre alarma ce urmează a fi setată, a
ș
a cum putem vedea în figura 5.2.4. Ora

poate fi setată folosind un “Time Picker”, urmând apoi adăugarea noti
ț
elor specifice alarmei

(dacă există). Alarma va avea un sunet implicit, dar va putea fi selectat utilizând butonul de

“Sound”, care va deschide un nou screen con
ț
inând sunetele disponibile la nivelul iOS-ului,

precum
ș
i sunete custom din storage-ul telefonului. (Figura 5.2.5). O altă setare care poate fi

customizată în func
ț
ie de preferin
ț
e este perioada la care să se rep ete alarma (op
ț
ional),

demonstrat în figura 5.2.6. Pentru a păstra un mediu familiar cu cel implicit aplica
ț
iei de

alarmă din iOS, paleta culorilor este în acela
ș
i domeniu.

49

Figura 5.2.4 Add Alarm

50

Figura 5.2.5 Alegere sunet alarmă

51

Figura 5.2.6 Repetare alarmă

Prin apăsarea butonului
se pot edita detaliile
ș
i setările pentru fiecare alarmă în

parte, ecranul care se deschide fiind acela
ș
i cu cel de adăugare a unei alarme noi, cu diferen
ț
a

că toate câmpurile sunt deja populate cu detaliile introduse anterior. (Figura 5.2.4).

Cel de-al doilea modul al aplica
ț
iei este cel de “Weather”, acesta fiind unul din cele

mai mari consumatoare de timp
ș
i resurse, deoarece utilizează servicii on-line de prognoză

meteo pentru a afi
ș
a detal ii semnificative pentru ora
ș
ul dorit.

52

În momentul în care se atinge butonul
din bara de naviga
ț
ie din Figura 5.2.2, se

apelează metoda care accesează API-ul de la Weather Underground, pentru a se încerca

reducerea timpului de a
ș
teptare necesar procesului de încărcare a datelor despre vreme

deoarece sunt întârzieri semnificative cauzate de natura apelului către acest API.

Figura 5.2.7 Weather Screen

53

În ecranul de “Weather” (Figura 5.2.7) utilizatorului i se pun la dispozi
ț
ie mai multe

detalii despre vreme precum prognoza pe 6 ore (dacă este disponibilă prin serviciu), în care

sunt afi
ș
ate mai multe com ponente:

●
ora pentru care sunt afi
ș
ate detaliile

●
condi
ț
iile atmosfe rice reprezentate printr-o imagine care se adaptează în func
ț
ie de

ceea ce primim de la API

●
temperatura

●
probabilitatea averselor

●
viteza aproximativă a vântului, precum
ș
i direc
ț
ia acestuia

O altă caracteristică a vremii este de asemenea disponibilă, mai exact prognoza pe 3

zile (dacă este disponibilă). Detaliile afi
ș
ate aici sunt condi
ț
iile actuale reprezentate printr-o

imagine
ș
i temperatura m edie pentru ora
ș
ul în cauză.

Ultimul modul major al aplica
ț
iei poate fi accesat apăsând butonul
din

bara de naviga
ț
ie din Figu ra 5.2.2, acesta fiind cel de “News”, în care vor fi afi
ș
ate
ș
tiri din

diferite categorii (definite de utilizator pentru fiecare ora
ș
) cu men
ț
iunea că
ș
tirile sunt bazate

pe loca
ț
ie, mai exact mod ulul va încerca să găsească
ș
tiri din regiunea aproximativă a

ora
ș
ului. În figura 5.2.8 s e poate observa structura modulului de “News”.

54

Figura 5.2.8 News Screen

În acest ecran utilizatorul poate accesa setările pentru preferin
ț
ele
ș
tirilor apăsând

butonul
care va deschide un nou screen cu detaliile men
ț
ionate mai sus, prezentat în

figura 5.2.9. În acesta se pot alege categoriile de
ș
tiri pentru care se doresc informa
ț
ii

(implicit sunt fi 4 categorii disponibile):

●
tehnologie

●
afaceri

●
sport

●
economie

55

Figura 5.2.9 Categorii
ș
tiri

56

O ultimă parte a aplica
ț
iei (dar care joacă un rol major în experien
ț
a generală a

aplica
ț
iei) este reprezenta tă de ecranul de setări generale, în care se pot alege unită
ț
ile de

măsură în func
ț
ie de siste mul de măsură folosit în regiunea în cauză. Acesta poate fi accesat

apăsând butonul
din bara din Figura 5.2.2.

Figura 5.2.10

57

Capitolul 6. Concluzii

Proiectul Business Clock, Weather and News este dezvoltat pentru persoanele din

mediul afacerilor
ș
i nu nu mai care doresc o modalitate mai eficienta
ș
i mai simple de

organizare a diferitelor evenimente, în special cu persoane aflate în alte fusuri orare.

Dezvoltarea aplica
ț
iei a necesitat acumularea de cuno
ș
tin
ț
e noi care, pe lângă cele

existente, au ajutat la crearea unui produs care a încercat sa ridice standardele existente pe

pia
ț
ă din punct de vedere al combina
ț
iei modulelor într-o singura aplica
ț
ie universala.

Business Clock, Weather and News este un produs care se dezvolta pentru platforma

iOS iar pentru aceasta a fost nevoie de cuno
ș
tin
ț
e în dezvoltarea de aplica
ț
ii iOS. Aplica
ț
ia a

necesitat cuno
ș
tin
ț
e din diverse domenii de programare, un exem plu fiind nevoia de salvare a

datelor (ora
ș
e, alarme). P entru persistarea datelor am utilizat o baza de date embedded pentru

o mai mare eficienta
ș
i pentru simplitatea
ș
i robuste
ț
ea oferită de SQLite. Pentru ca aplica
ț
ia

are nevoie sa preia date din diverse servicii on-line a fost necesara utilizarea serviciilor REST

oferite de acestea prin intermediul diverselor API-uri. De asemenea, pentru ca am dorit ca

aplica
ț
ia sa fie cat mai plă cută din punct de vedere vizual, am cercetat, utilizat
ș
i implementat

componente grafice care nu se regăsesc în mod normal în mediul de programare Xcode. Cu

toate acestea, am ales sa păstrez aspectul acestor componente cat mai aproape de cele de baza

din iOS pentru ca am sim
ț
it nevoia de consistenta în cadrul aplica
ț
iei
ș
i de simbioza cu

sistemul de operare, aceasta fiind filozofia Apple.

În continuare ne-am propus sa dezvoltam aplica
ț
ia din mai multe puncte de vedere,

unul dintre acestea fiind adăugarea unui layer de personalizare la nivelul utilizatorului prin

crearea de conturi. Acest lucru ar aduce doua beneficii majore:

●
posibilitatea păstrării datelor utilizatorului în cazul migrării pe un alt telefon sau

device, avantajul fiind ca nu am fi limita
ț
i doar la sistemul de operare iOS. Astfel, în

cazul unei eventuale aplica
ț
ii dezvoltate pentru Android, vom avea la dispozi
ț
ie datele

într-un format disponibil ambelor platforme

●
datorita conturilor de utilizator
ș
i a datelor stocate, putem realiza unelte statistice de

analiza a datelor pe baza cărora putem urmări diferitele zone active din cadrul

aplica
ț
iei, precum
ș
i preferin
ț
ele legate de domeniile de
ș
tiri de care utilizatorii sunt

interesa
ț
i

58

Capitolul 7. Bibliografie

[1] Anchor Point,

https://2cupsoftech.wordpress.com/2014/03/05/understanding-calayer-anchorpoint-and-positi
on-property/

[2] Ce este un studiu de pia
ț
ă,
​
http://www.ensight.ro/newsletter/no15/articol4.htm

[3] Cocoa Layered Architecture,

http://www.knowstack.com/cocoa-layered-architecture-for-mac-osx/

[4] Defini
ț
ia unui studiu d e pia
ț
ă,
​
http://www.studii-piata.ro/defin itie.htm

[5] Statistici ale utilizării telefoanelor mobile,

http://www.zf.ro/business-hi-tech/aplicatiile-mobile-au-devenit-o-normalitate-peste-30-din-

romani-folosesc-internetul-pe-mobil-imediat-ce-se-trezesc-14135443

[6] Etapele unui studiu de pia
ț
ă,
​
http://www.studii-piata.ro/etape.htm

[7] Fusuri orare,
​
https://en.wikipedia.org/wiki/Time_zone

[8] iOS,
​
https://en.wikipedia.org/wiki/IOS

[9] Layers of the iOS architecture,

https://www.safaribooksonline.com/library/view/xcode-4-ios/9781849691307/ch01s04.html

[10] Model-View-Controller (MVC) in iOS: A Modern Approach,

https://www.raywenderlich.com/132662/mvc-in-ios-a-modern-approach

[11] Representational state transfer,

https://en.wikipedia.org/wiki/Representational_state_transfer

[12] Request Servicii REST,

http://crunchify.com/how-to-create-restful-java-client-with-jersey-client-example/

[13] REST (REpresentational State Transfer),

https://searchmicroservices.techtarget.com/definition/REST-representational-state-transfer

[14] SQLite,
​
https://www.sqlite.org/about.html

[15] SQlLite,
​
https://en.wikipedia.org/wiki/SQLite

[16] Swift (programming language),

https://en.wikipedia.org/wiki/Swift_(programming_language)

[17] Swift,
​
https://developer.apple.com/swift/

[18] Swift Playgrounds,
​
https://www.apple.com/swift/playgrounds/

59

[19] SwiftyJSON,
​
https://github.com/SwiftyJSON/SwiftyJSON

[20] Tehnologie,
​
https://ro.wikipedia.org/wiki/Tehnologie

60