theses

Transcript

theses

Università degli Studi Mediterranea di Reggio Calabria
Dipartimento di Ingegneria dell’Informazione, delle Infrastrutture e
dell’Energia Sostenibile
Corso di Laurea Magistrale in Ingegneria Informatica e dei Sistemi per le
Telecomunicazioni
Tesi di Laurea
Progettazione e implementazione di un’app ibrida per il
supporto al turismo nella città di Reggio Calabria: la
componente di front-end
Relatori
Candidato
Prof. Domenico Ursino
Maurizio Rizzo
Dott. Antonio Quattrocchi
Anno Accademico 2014-2015
Indice
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Analisi dei requisiti e studio di fattibilità . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 L’applicazione multipiattaforma EnjoyRC . . . . . . . . . . . . . . . . .
1.1.2 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Studio di fattibilità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 La situazione attuale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2 Progetto di massima della soluzione . . . . . . . . . . . . . . . . . . . . . .
1.2.3 Analisi dei rischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.4 Modalità di attuazione del progetto . . . . . . . . . . . . . . . . . . . . . . .
1.2.5 Analisi dei tempi e delle risorse umane . . . . . . . . . . . . . . . . . . . .
1.2.6 Analisi di impatto: Costi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
7
7
8
12
12
12
13
13
14
14
Tecnologie ibride di seconda generazione: AppGyver . . . . . . . . . . . . . . . .
2.1 La rivoluzione del mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Mobile application: app nativa, ibrida e webApp . . . . . . . . . . .
2.1.2 I principali ambienti di sviluppo di app ibride . . . . . . . . . . . . . .
2.2 Framework di prima generazione: Cordova e Appcelerator . . . . . . . . .
2.2.1 Apache Cordova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Titanium Appcelerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Framework di seconda generazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Ionic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 AppGyver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Il Composer di AppGyver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2 Steroids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.3 Supersonic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.4 AngularJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
15
16
18
18
18
21
23
24
26
27
28
32
39
Funzionalità e Mockup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 Funzionalità del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Funzionalità relative alla Mobile Application . . . . . . . . . . . . . . .
3.1.2 Funzionalità relative alla Web Application . . . . . . . . . . . . . . . . .
41
41
41
45
IV
Indice
3.2 Mockup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Mockup relativo alla Home Page e al Drawer Menu . . . . . . . . .
3.2.2 Mockup relativo alla sezione “Ricerca” . . . . . . . . . . . . . . . . . . . .
3.2.3 Mockup relativi alla sezione “Punti di interesse” . . . . . . . . . . . .
3.2.4 Mockup relativi alla sezione “Ristorazione” . . . . . . . . . . . . . . . .
3.2.5 Mockup relativi alla sezione “Percorsi turistici” . . . . . . . . . . . .
3.2.6 Mockup relativi alla sezione “Svaghi” . . . . . . . . . . . . . . . . . . . . .
3.2.7 Mockup relativi alla sezione “Eventi” . . . . . . . . . . . . . . . . . . . . .
3.2.8 Mockup relativo alla sezione “La città” . . . . . . . . . . . . . . . . . . . .
47
47
48
49
51
53
53
54
54
Progettazione delle funzionalità di base . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1 Architettura dell’applicazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Progettazione della componente applicativa . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Diagrammi dei casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 Diagrammi di attività . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3 Diagrammi di sequenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
57
59
59
61
63
Implementezione delle funzionalità di base . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 Strumenti a supporto dell’implementazione . . . . . . . . . . . . . . . . . . . . . .
5.1.1 IDE di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2 IDE JetBrains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.3 Sistemi di versioning e Bitbucket . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Problemi affrontati e scelte implementative effettuate . . . . . . . . . . . . .
5.2.1 Premessa: architettura del framework e librerie realizzate . . . .
5.2.2 Implementazione del macro-blocco “Punti di interesse” . . . . . .
5.2.3 Implementazione del macro-blocco “La città” . . . . . . . . . . . . . .
69
69
69
69
70
73
73
79
84
Progettazione e implementazione dei percorsi tematici . . . . . . . . . . . . . . 87
6.1 Progettazione della componente applicativa . . . . . . . . . . . . . . . . . . . . . . 87
6.2 Implementazione delle funzionalità lato client . . . . . . . . . . . . . . . . . . . . 94
6.3 Implementazione delle funzionalità lato server . . . . . . . . . . . . . . . . . . . . 99
6.3.1 Implementazione della funzionalità relativa all’inserimento
di un waypoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.3.2 Implementazione della funzionalità relativa all’inserimento
di un percorso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Manuale utente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.2 La Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.3 Il Drawer Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.4 La sezione “Ricerca” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.5 La sezione “Punti di interesse” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.6 Le macro-aree relative alle attività commerciali . . . . . . . . . . . . . . . . . . . 117
7.6.1 La sezione “Ristorazioni” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.6.2 Le sezioni “Pernottamenti” e “Svaghi” . . . . . . . . . . . . . . . . . . . . 119
7.7 La sezioni “Percorsi turistici statici” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7.8 La sezioni “Servizi primari” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
7.9 La sezioni “Eventi” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Indice
V
7.10 La sezione “La città” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Confronto con sistemi correlati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
8.1 Punti di forza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
8.2 Punti di debolezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
8.3 Confronto con sistemi correlati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
8.3.1 Tutto Calabria in App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
8.3.2 Bergamo City Tour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
8.3.3 Venezia Unica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
8.3.4 Neslo Barcellona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
8.3.5 Dubai Travel Guide and Offline Map . . . . . . . . . . . . . . . . . . . . . . 140
8.3.6 World Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Conclusioni e sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
9.1 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
9.2 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Ringraziamenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Riferimenti bibliografici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Elenco delle figure
1.1
Il diagramma di Gantt iniziale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
Apache Cordova e PhoneGap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architettura di Apache Cordova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logo di Titanium Appcelerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architettura di Alloy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il logo di Ionic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il meccanismo di interazione tra i tre framework . . . . . . . . . . . . . . . . . . .
L’AppGyver Accademy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il tool visuale del Composer di AppGyver. . . . . . . . . . . . . . . . . . . . . . . . .
Il servizio Connect di AppGyver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
La console di gestione dei log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
La sezione relativa alla gestione della documentazione . . . . . . . . . . . . . .
La sezione relativa alla gestione dei servizi cloud . . . . . . . . . . . . . . . . . .
La sezione relativa alla gestione dei contenuti . . . . . . . . . . . . . . . . . . . . .
L’architettura delle directory di un progetto Supersonic . . . . . . . . . . . .
Le principali differenze tra Supersonic e Ionic . . . . . . . . . . . . . . . . . . . . .
19
21
22
23
24
25
27
29
30
31
31
32
33
36
38
Il mockup di primo livello relativo alla Home Page e al Drawer Menu
Il mockup di secondo livello relativo alla Home Page e al Drawer
Menu, con relative “gesture” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Il mockup di primo livello relativo alla sezione “Ricerca” . . . . . . . . . . .
3.4 Il mockup di secondo livello relativo alla sezione “Ricerca”, con
relative “gesture” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Il mockup di primo livello relativo alla sezione “Punti di interesse” . .
3.6 Il mockup di secondo livello relativo alla sezione “Punti di interesse”,
con relative “gesture” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7 Il mockup di primo livello relativo alla sezione “Ristorazione” . . . . . . .
3.8 Il mockup di secondo livello relativo alla sezione “Ristorazione”, con
3.9 Il mockup di primo livello relativo alla sezione “Percorsi turistici” . . .
3.10 Il mockup di secondo livello relativo alla sezione “Percorsi turistici”
con relative gesture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
3.1
3.2
49
50
50
51
51
52
52
53
54
VIII
Elenco delle figure
3.11 Il mockup di primo livello relativo alla sezione “Svaghi” . . . . . . . . . . . .
3.12 Il mockup di secondo livello relativo alla sezione “Svaghi” con
relative gesture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.13 Il mockup di secondo livello relativo alla sezione “Eventi”, con
3.14 Il mockup di secondo livello relativo alla sezione “La città”, con
54
4.1
4.2
58
55
55
56
4.8
4.9
L’architettura dell’applicazione EnjoyRC . . . . . . . . . . . . . . . . . . . . . . . . .
Il diagramma dei casi d’uso relativo al macro-blocco “Punti di
interesse” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il diagramma dei casi d’uso relativo al macro-blocco “La città” . . . . . .
Il diagramma di attività relativo al macro-blocco “Punti di interesse”
Il diagramma di attività relativo al macro-blocco “La città” . . . . . . . .
Il diagramma di attività relativo al recupero delle informazioni
riguardanti la città . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il diagramma di attività relativo al recupero delle informazioni
riguardanti il menù del macro-blocco “La città” . . . . . . . . . . . . . . . . . . .
Il diagramma di sequenza relativo al macro-blocco “Punti di interesse”
Il diagramma di sequenza relativo al macro-blocco “La città” . . . . . . .
5.1
5.2
5.3
Il funzionamento dell’operazione di commit in Git . . . . . . . . . . . . . . . . . 71
La dashboard di un progetto Bitbucket . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
L’architettura dei package del sistema EnjoyRC . . . . . . . . . . . . . . . . . . . 74
6.1
Il diagramma dei casi d’uso relativo al macro-blocco “Percorsi
turistici” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il diagramma di attività riguardante la navigazione all’interno del
macro-blocco “Percorsi turistici” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il diagramma di attività relativo al recupero delle categorie dei
percorsi turistici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il diagramma di attività relativo al recupero delle categorie dei
percorsi turistici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il diagramma di sequenza riguardante la navigazione all’interno del
macro-blocco “Percorsi turistici” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il diagramma di sequenza relativo alla creazione di un percorso . . . . . .
4.3
4.4
4.5
4.6
4.7
6.2
6.3
6.4
6.5
6.6
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
60
61
62
64
65
66
67
68
88
89
90
92
93
95
La Home Page dell’applicazione EnjoyRC . . . . . . . . . . . . . . . . . . . . . . . . 110
Il Drawer Menu dell’applicazione EnjoyRC . . . . . . . . . . . . . . . . . . . . . . . 111
Le sezioni Credits e Manual, accessibili dal Drawer Menu
dell’applicazione EnjoyRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Le sezioni di ricerca dell’applicazione EnjoyRC . . . . . . . . . . . . . . . . . . . . 113
Le pagina contente i filtri per la ricerca personalizzata . . . . . . . . . . . . . 114
Le pagina contenente le categorie dei punti di interesse . . . . . . . . . . . . . 115
La pagina contenente la lista dei punti di interesse associati ad una
categoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Le pagina contenente il dettaglio di un punto di interesse . . . . . . . . . . . 116
La pagina contenente la mappa relativa ad un punto di interesse . . . . 117
Elenco delle figure
1
7.10 La pagina contenente le categorie dei punti di ristorazione . . . . . . . . . . 118
7.11 La pagina contenente i punti di ristorazione associati ad una
determinata categoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.12 La pagina di dettaglio relativa ad un punto di ristorazione . . . . . . . . . . 119
7.13 La pagina contenente la mappa relativa ad un punto di ristorazione . . 120
7.14 La pagina contenente la categorie dei pernottamenti . . . . . . . . . . . . . . . 120
7.15 La pagina contenente la categorie degli svaghi . . . . . . . . . . . . . . . . . . . . . 121
7.16 La pagina contenente le categorie dei percorsi turistici . . . . . . . . . . . . . 121
7.17 La pagina contenente la lista dei percorsi turistici associati ad una
specifica categoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
7.18 La pagina contenente il dettaglio di un percorso turistico . . . . . . . . . . . 123
7.19 La pagina contenente il dettaglio di una delle tratte in cui è
suddiviso un percorso turistico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.20 La pagina contenente il dettaglio di un servizio primario . . . . . . . . . . . . 124
7.21 La pagina contenente le categorie degli eventi . . . . . . . . . . . . . . . . . . . . . 125
7.22 La pagina contenente la lista degli eventi . . . . . . . . . . . . . . . . . . . . . . . . . 125
7.23 La pagina contenente il dettaglio di un evento . . . . . . . . . . . . . . . . . . . . . 126
7.24 La Home Page della sezione “La città” . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
7.25 La pagina contenente le indicazioni stradali per raggiungere la città . . 127
7.26 La pagina contenente le informazioni utili a visitare la città . . . . . . . . . 128
7.27 La pagina contenente l’elenco dei negozi di prodotti tipici presenti
in città . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
7.28 La pagina contenente la lista delle tradizioni calabresi . . . . . . . . . . . . . . 129
8.1
8.2
8.3
8.4
8.5
8.6
Il menù laterale dell’applicazione Tutto Calabria in App . . . . . . . . . . . . 134
La Home Page dell’applicazione Bergamo City Tour . . . . . . . . . . . . . . . 136
Una schermata dell’applicazione Venezia Unica . . . . . . . . . . . . . . . . . . . . 138
La Home Page dell’applicazione Neslo Barcellona . . . . . . . . . . . . . . . . . . 139
La lista dei contenuti più popolari dell’applicazione Dubai Travel
Guide and Offline Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
La Home Page dell’applicazione World Explorer . . . . . . . . . . . . . . . . . . . 143
Introduzione
Da qualche anno a questa parte i dispositivi mobili stanno cambiando in modo
radicale la comunicazione. Si parla di “Mobile First” per indicare non solo la tecnologia di riferimento, ma anche, e soprattutto, quello che ormai è diventato un
vero e proprio stile di vita. Periodicamente nuovi studi e ricerche forniscono delle
statistiche che evidenziano quanto sia importante dedicare agli utenti in mobilità
un’attenzione che, fino a poco tempo fa, si era per lo più concentrata sugli utenti
desktop.
Il mobile rappresenta una forza rivoluzionaria in grado di modificare le attuali modalità di scambio delle informazioni. Utenti sempre più esperti ed esigenze
sempre più in crescita hanno sensibilmente modificato i modelli di servizio. Le attività usufruibili tramite smartphone sono destinate a crescere e stanno, quindi,
aumentando anche le aspettative in termini di funzionalità aggiuntive.
Per rimanere competitive le aziende si trovano a dover affrontare tale fenomeno,
introducendo modalità più efficaci di sviluppo delle applicazioni per soddisfare le
esigenze degli utenti in mobilità. Infatti, il costante aumento dell’utenza porta a una
continua proposta di nuove tecnologie migliorative rispetto a quelle già esistenti.
Negli ultimi anni lo sviluppo di schermi ad elevata risoluzione, la diminuzione
dei costi delle memorie e l’aumento di capacità computazionale hanno portato alla
nascita di nuovi dispositivi mobili con alte prestazioni. Se a questo si aggiunge una
crescita del livello di conoscenza da parte degli utenti rispetto alle possibilità offerte
dalla tecnologia, si comprende come il numero di servizi a disposizione sia in continuo
aumento; ciò riguarda, in modo particolare, i servizi Internet. Il successo dei servizi
Internet basati sul protocollo IP si affianca al grande beneficio dell’evoluzione dei
dispositivi mobili portando ad avere un bacino di utenza e, più in generale, uno
spettro di utilizzo molto più ampio di tali tecnologie.
Grazie alla mobilità dell’utente possono, inoltre, nascere diversi servizi, dedicati
specificamente a dispositivi di mobile computing, come smartphone, basati anche
sulle informazioni aggiuntive fornite proprio dal protocollo IP, come, ad esempio, la
geolocalizzazzione. Uno smartphone, in italiano “cellulare intelligente”, è un dispositivo portatile che abbina le funzionalità proprie di un telefono cellulare con quelle
di un gestore di dati per migliorare la produttività personale ed aziendale; costruito
su una piattaforma di mobile computing, esso presenta capacità computazionali e
livelli di connettività elevati rispetto ai comuni telefoni cellulari.
4
Introduzione
Tutto questo ha permesso di definire un livello ancora più elevato di “intelligenza” nei dispositivi, dove la geolocalizzazione, basata su differenti tecnologie, come
GPS, WiFi ed LTE, si presenta, ora, come una funzionalità indispensabile; i sistemi operativi associati a questa fascia di prodotti offrono tutti un market-place o
uno store da dove poter scaricare applicazioni di ogni tipo e per qualsiasi utilizzo,
cambiando radicalmente la percezione che l’utente finale ha di tali dispositivi: da
semplici cellulari si giunge a considerarli veri e propri computer in miniatura.
Uno degli aspetti peculiari per gli smartphone è la possibilità di installarvi ulteriori applicazioni, aggiungendo, cosı̀, nuove funzionalità. Tali dispositivi si differenziano, inoltre, per l’adozione di API (Application Programming Interfaces)
avanzate, permettendo alle applicazioni di terze parti una migliore integrazione con
il loro sistema operativo.
Le applicazioni mobili giocano un ruolo trainante nel panorama software attuale,
portando il loro sviluppo ad assumere un ruolo simile a quello che ha avuto lo
sviluppo del Web negli anni novanta. Basti pensare al numero di app presenti sui
diversi market-place, nonché alla varietà di piattaforme disponibili per categorie
di dispositivi in continua evoluzione: da iOS ad Android, da Windows Phone a
Blackberry OS.
Questa evoluzione, d’altra parte, rende sempre più difficile, per ogni singolo sviluppatore, imparare a lavorare contemporaneamente su tutte le piattaforme. Inoltre,
anche per un’azienda, avere un team di sviluppatori specializzati in ognuna delle
principali piattaforme esistenti può essere oneroso. Al giorno d’oggi vi è la necessità di realizzare prodotti “performanti”, ma allo stesso tempo, di ridurre i costi di
produzione.
Di fronte a tali necessità è risultato utile valutare una nuova visione unificata
delle diverse piattaforme, seguendo una strada che passa per le tecnologie Web; da
questa idea è nato il cosiddetto approccio ibrido alla programmazione mobile. Esso
sfrutta gli strumenti di gestione di interfacce HTML, come le web app, per creare
applicazioni multi-piattaforma, rendendo più semplice la realizzazione di uno stesso
software per dispositivi differenti.
Un’app ibrida è, tipicamente, un’pp nativa contenente una componente web.
Essa si adatta facilmente alle diverse piattaforme e ai diversi dispositivi mobili. Il
vantaggio principale delle app ibride risiede nel fatto che il codice necessario alla
loro realizzazione viene scritto con un linguaggio comune a tutti i dispositivi ed
è solo il contenitore a dover essere cambiato in funzione del dispositivo che deve
ospitare l’applicazione. Questo significa che, per la realizzazione di un’app ibrida, ci
sono tempi e costi più bassi rispetto a quelli necessari per le applicazioni native. Le
app ibride, grazie ai potenti framework realizzati nel corso degli anni, presentano
delle prestazioni paragonabili a quelle realizzate tramite un approccio nativo.
Il mobile, al giorno d’oggi, viene utilizzato in tantissimi contesti molto comuni,
quali il commercio elettronico, l’accesso alle social network e l’utilizzo di sistemi di
navigazione. Oltre a tali contesti, esso ricopre un ruolo molto importante nel settore
dedicato al turismo.
La valorizzazione dei beni culturali e ambientali e lo sviluppo turistico, per una
città come Reggio Calabria, sono temi strettamente connessi, in quanto la nostra
città dispone di un ingente patrimonio culturale e ambientale.
Introduzione
5
Tale patrimonio possiede molteplici punti di forza che possono tornare utili allo sviluppo del turismo; citando ad esempio, i siti archeologici di antiche civiltà
mediterranee della Magna Grecia, che possono dar luogo ad itinerari turistici di rilevanza eccezionale, le coste marine, che offrono spiagge sul Mediterraneo, le foreste
dell’Aspromonte, per il turismo di montagna, la valorizzazione di prodotti enogastronomici tipici, che possono fungere da attrattori turistici e dare luogo ad itinerari
enogastronomici per le specialità locali.
Reggio Calabria soffre di una serie di punti di debolezza che gravano sullo sviluppo del turismo. Essa, infatti, non offre un servizio di comunicazione informativa
adeguata a distanza, limita l’accesso fisico ai punti di interesse a causa della scarsità
di vie e mezzi di trasporto, non offre una adeguata accessibilità al bene artistico
con informazioni in loco e consente una limitata visione del bene culturale.
In accordo con il Comune di Reggio Calabria si è deciso di sfruttare le potenzialità offerte dalle tecnologie web e mobile per realizzare un sistema in grado di
risolvere, o ridurre al minimo, gli svantaggi introdotti da questa serie di problematiche. Abbiamo deciso di chiamare tale sistema EnjoyRC. Esso è costituito da
un’applicazione mobile multipiattaforma e da un server di supporto dedicato alla
gestione dei contenuti.
Il sistema in esame fornisce tutte le principali funzionalità necessarie a supportare il turismo nella città di Reggio Calabria. Ciascuna funzionalità è resa possibile
grazie al portale a cui l’applicazione si appoggia. EnjoyRC implementa una serie di
funzionalità che permetteranno ad un utente di visualizzare delle liste di punti di
interesse opportunamente organizzate per categorie. Egli avrà la possibilità di accedere al dettaglio di un punto di interesse, visualizzando le informazioni generali dello
stesso e, tramite un opportuna mappa, le informazioni stradali per raggiungerlo.
Oltre a quelle relative ai punti di interesse, verranno implementate una serie di
funzionalità che permettono di esporre, in maniera analoga, i dati relativi ai punti
di ristorazione, ai punti di pernottamento e agli svaghi offerti dalla città.
Oltre a tali sezioni, l’utente potrà accedere a quelle in cui sono riportati tutti
gli eventi svolti in città, nonchè le informazioni riguardanti i servizi primari, tra cui
mezzi pubblici e servizi sanitari. L’applicazione realizzerà un’area secondaria, che
mira a mostrare le tradizioni e i prodotti tipici reggini, includendo all’interno della
stessa le informazioni stradali che permettono di raggiungere la città e quelle che
permettono di spostarsi al suo interno.
Infine, EnjoyRC darà maggiore rilievo all’implementazione di due particolari
sezioni, ovvero quella dei percorsi turistici e quella della ricerca dei contenuti. La
prima offrirà all’utente la possibilità di conoscere quante più informazioni possibili
riguardanti ogni percorso tematico, sia che questo sia stato organizzato da qualcuno,
sia che corrisponda, semplicemente, ad una sequenza di punti di interesse consigliati.
La seconda, invece, offrirà la possibilità ad un utente di effettuare una ricerca, sia
generica che personalizzata, all’interno di tutti i contenuti. Il sistema, ad esempio,
offrirà consentirà ad un utente di ricercare i punti di ristorazione ancora aperti o
quelli che offrono servizi per celiaci, di conoscere i punti di interesse più vicini alla
sua posizione o i punti di pernottamento che rientrano in una determinata fascia di
prezzo.
Il presente lavoro di tesi è strutturato come di seguito specificato:
6
•
•
•
•
•
•
•
•
•
Introduzione
Nel Capitolo 1 vengono illustrate le fasi di analisi dei requisiti e di studio di fattibilità, necessarie alla progettazione e all’implementazione del sistema, specificando le principali motivazioni che ci hanno spinto a realizzarlo. Nello specifico,
vengono analizzati i requisiti raccolti e tutte le problematiche che si potranno
riscontrare in fase di produzione, offrendo delle possibili soluzione nel caso in cui
queste ultime dovessero presentare.
Nel Capitolo 2 vengono descritte le differenze principali tra la programmazione
nativa, quella orientata alle web app e quella ibrida; di quest’ultima vengono
descritti i framework più diffusi, soffermandosi, maggiormente, sulla piattaforma
adottata nella presente tesi, ovvero AppGyver, e giustificandone la scelta.
Nel Capitolo 3 vengono illustrate nel dettaglio le funzionalità che riguardano sia
l’applicazione mobile che il server. Vengono illustrati, inoltre, sia i mockup di
primo livello che quelli di secondo livello.
Nel Capitolo 4 viene illustrata la progettazione delle funzionalità di base dell’applicazione EnjoyRC. Nello specifico, vengono prese in considerazione la struttura
del client e la fase di progettazione della componente applicativa.
Nel Capitolo 5 viene analizzata l’implementazione delle funzionalità di base di
EnjoyRC. Nello specifico, vengono analizzati gli strumenti utilizzati e le porzioni
di codice che hanno soddisfatto i requisiti citati in precedenza.
Nel Capitolo 6 vengono illustrate la fase di progettazione e quella di implementazione della sezione relativa ai percorsi turistici tematici. Nello specifico,
vengono prese in considerazione la fase di progettazione della componente applicativa nonchè l’implementazione delle funzionalità riguardanti sia la componente
client che quella server.
Nel Capitolo 7 viene presentato il manuale utente dell’applicazione.
Nel Capitolo 8 vengono analizzati i punti di forza e di debolezza del sistema
realizzato; viene, inoltre, effettuato un confronto con altri sistemi esistenti in
commercio, evidenziando, per ciascuno di essi, le analogie e le differenze rispetto
al nostro sistema.
Nel Capitolo 9 vengono tratte le conclusioni del presente lavoro di tesi e, infine,
vengono analizzate le linee evolutive ed alcuni possibili sviluppi futuri.
1
Analisi dei requisiti e studio di fattibilità
Questo capitolo illustra le fasi di analisi dei requisiti e di studio di fattibilità necessarie alla progettazione e all’implementazione di un sistema a supporto del turismo
della città di Reggio Calabria. Si esporranno, inoltre, i motivi che ci hanno spinto
alla realizzazione di questo progetto.
1.1 Analisi dei requisiti
1.1.1 L’applicazione multipiattaforma EnjoyRC
Nella realtà di un comune come quello di Reggio Calabria, il turismo rappresenta
l’aspetto più importante del suo rapporto con il resto del mondo e funge, o dovrebbe
fungere, da traino per tutti i settori della sua fragile economia. La posizione geografica, il clima mite, le località naturali, le tradizioni, le ricchezze storiche e artistiche
che la città possiede sarebbero, in sè, sufficienti ad accrescere l’appeal che essa esercita sui turisti del resto d’Italia e del mondo. Ciò che però limita profondamente il
turismo reggino è la quasi totale assenza di una buona organizzazione e, in molti
casi, l’incapacità di valorizzare le bellezze della provincia, anche con l’aiuto delle
nuove tecnologie. Per questo motivo si è deciso di realizzare un sistema, in accordo
con gli enti comunali, che permettesse di superare i problemi appena citati.
L’obbiettivo del sistema oggetto della presente tesi è quello di fornire un supporto
al turismo della città di Reggio Calabria cercando, allo stesso tempo, di promuovere
le sue potenzialità tra i cittadini stessi, in quanto, troppo spesso, si corre il rischio
di non guardare con attenzione cosa ci accade intorno, dando poca importanza e
tenendo in cattiva considerazione i luoghi e gli ambienti che ci hanno visto nascere
e crescere.
Il sistema che verrà realizzato sarà una sorta di guida turistica smart, semplice ed
intuitiva, che permetterà, a chiunque lo desideri, di organizzare in maniera autonoma
il proprio soggiorno sul territorio reggino; allo stesso tempo essa rappresenterà una
vetrina per i punti di maggiore interesse turistico e per le attività distribuite sul
territorio, i servizi primari offerti dal comune e gli eventi organizzati in città. Il
nome del sistema è stato opportunamente pensato e concordato con gli stackholder
principali, effettuando sondaggi e interviste. Dopo una serie di proposte, si è scelto
8
1 Analisi dei requisiti e studio di fattibilità
di associare all’applicativo il nome EnjoyRC, che richiama in sè la protagonista vera
del progetto, cioè la città di Reggio Calabria e sottolinea l’obiettivo principale del
sistema, cioè rendere gradevole al turista il soggiorno presso la nostra città.
Tale sistema consisterà in un’applicazione mobile multi-piattaforma e in un server di supporto ad essa. Dato il contesto e la natura dell’applicazione che si svilupperà, è stato chiesto che essa sia multi-lingua e che sia suddivisa in una serie di
macro-aree di riferimento, ciascuna inerente ad uno specifico aspetto o funzionalità
dell’applicazione.
Per quanto riguarda il server di supporto, si è scelto di realizzare un sito web
“responsive” tramite l’utilizzo di un CMS, in modo da permettere una facile gestione
dei contenuti che saranno visualizzati sui dispositivi mobili e in modo tale creare
una predisposizione ad-hoc per i prospetti futuri.
1.1.2 Requisiti
Il punto di partenza per la realizzazione del sistema è stata una fase preliminare di
interviste e incontri con gli stackholder (enti comunali, negozianti, comuni cittadini,
etc.) che ci hanno permesso di realizzare la stesura dei documenti fondamentali
alla base della progettazione. Il primo documento realizzato, previa definizione di
un template base ufficiale, è stato quello relativo all’analisi dei requisiti. Come
già anticipato nel precedente paragrafo, il sistema dovrà essere necessariamente
usufruibile in tre differenti lingue opportunamente scelte dagli stakeholder, ovvero:
Inglese, Spagnolo e Italiano. Per una più accurata e completa descrizione dei requisiti
raccolti, gli stessi sono stati suddivisi in una serie di macro-aree di riferimento,
ciascuna delle quali inerente ad un task da informatizzare. Le macro-aree individuate
sono le seguenti:
•
•
•
•
•
•
•
•
•
•
Macro-area
Macro-area
Macro-area
Macro-area
Macro-area
Macro-area
Macro-area
Macro-area
Macro-area
Macro-area
1, relativa ai punti di interesse;
2, relativa ai punti di ristorazione;
3, relativa ai pernottamenti;
4, relativa agli svaghi;
5, relativa ai percorsi turistici statici;
6, relativa alle informazioni di base sulla città;
7, relativa ai servizi primari;
8, relativa agli eventi;
9, relativa alla ricerca dei contenuti;
10, relativa alla gestione dei contenuti..
É opportuno definire con chiarezza ciascuna macro-area poichè queste costituiscono il punto di partenza per la progettazione del sistema. Tutti i requisiti
descriveranno ciò che il sistema dovrà fare, ma non come dovrà farlo.
Sezione relativa ai punti di interesse
Con il termine “punti interesse” definiamo una serie di location, costruzioni e opere,
presenti sul territorio reggino, che possiedono una particolare importanza dal punto
di vista turistico. La macro-area in esame dovrà contenere, ed opportunamente
catalogare, questi ultimi, in modo da garantire una semplice e veloce consultazione
9
da parte dell’utente. Sulla base delle indicazioni raccolte durante la fase di confronto
con gli stackholder si è deciso di adottare la seguente tassonomia:
•
•
•
•
•
•
•
•
•
Monumenti Religiosi;
Funivie/scale mobili;
Monumenti e siti storici;
Strutture centenarie;
Musei;
Teatri;
Località balneari;
Natura;
Parchi.
Inizialmente il sistema visualizzerà la lista delle categorie alle quali è stato associato almeno un punto di interesse; a questo punto l’utente potrà selezionare un’opportuna categoria e visualizzare la lista completa dei punti ad essa associati. Attraverso la selezione di uno di essi si potrà accedere all’area relativa al suo dettaglio,
in cui saranno presenti le informazioni necessarie per conoscerlo e raggiungerlo.
Sezione relativa ai punti di ristorazione
Tale sezione conterrà i punti di ristorazione dislocati sul territorio comunale e provinciale. Anche in questo caso l’organizzazione dei contenuti si baserà sulla categorizzazione degli esercizi da visualizzare. Nel caso dei punti di ristorazione si è scelto
di prevedere le seguenti categorie:
•
•
•
•
•
•
Pizzerie;
Pub;
Ristoranti;
Paninoteche;
Cucina tradizionale calabrese;
Bar/pasticcerie/gelaterie.
L’utente potrà, dunque, selezionare una specifica tipologia di ristorazione e scegliere tra le varie alternative visualizzate quella che più si adatta alle sue esigenze;
per esempio, saranno evidenziati gli esercizi ancora aperti rispetto all’orario corrente
o che offrono un servizio piuttosto che un altro.
Sezione relativa ai pernottamenti
Questa sezione fornirà informazioni accurate sulle varie strutture alberghiere e i
B&B presenti in città. L’utente avrà la possibilità di consultare la lista fornita e
di valutare quale struttura risponde meglio a ciò che cerca. Tra le informazioni
riportate, assumono particolare importanza la fascia di prezzo nella quale ricade
quello specifico albergo o B&B, la posizione e le indicazioni stradali per raggiungere
la struttura.
10
Sezione relativa agli svaghi
All’interno della sezione relativa agli svaghi saranno incluse le attività che hanno a
che fare con il tempo libero, gli hobby e il divertimento. Esse avranno la seguente
tassonomia:
•
•
•
•
•
•
Cinema;
Centri benessere;
Villaggi Turistici;
Sport;
Stabilimenti balneari;
Disco;
Come nelle sezioni precedenti, sarà presente un’area di dettaglio in cui l’utilizzatore finale avrà a disposizione le informazioni necessarie per conoscere più nello
specifico uno svago e per raggiungere il luogo in cui la corrispettiva location si trova.
Sezione relativa ai percorsi turistici statici
Una delle macro-aree più importanti dell’intero sistema riguarda i percorsi turistici
statici, che hanno lo scopo di valorizzare le bellezze della provincia reggina e facendole scoprire all’utente. Essi saranno creati dagli amministratori del sistema e
non potranno essere personalizzati dagli utilizzatori finali. I vari percorsi forniti dal
sistema saranno suddivisi in tre categorie:
•
•
•
Percorso enogastronomico, relativo al turista che ama conoscere i sapori, i
profumi e le tradizioni dei luoghi che sta visitando.
Percorso storico/culturale, relativo al turista che ama scoprire la storia e il
fascino culturale della provincia di Reggio Calabria.
Percorso naturalistico, relativo al turista che vuole godersi le bellezze paesaggistiche e naturalistiche della provincia.
Ogni percorso potrà essere suddiviso in un numero variabile di tratte delle quali
saranno fornite informazioni legate alle modalità e al tempo di percorrenza.
Sezione relativa alle informazioni di base sulla città
All’interno del sistema sarà dedicata una sezione nella quale saranno fornite tutte
le informazioni di carattere generale:
•
•
•
•
Come arrivarci;
Come visitarla;
Negozi di prodotti tipici;
Tradizioni.
11
Sezione relativa ai servizi primari
Tale area sarà una guida per l’utente per usufruire dei servizi principali forniti dal
comune di Reggio Calabria; tra questi i servizi sanitari, i trasporti, il Wi-Fi pubblico,
etc. I servizi saranno organizzati in tipologie e queste ultime in categorie. Di seguito
viene mostrata la corrispettiva tassonomia:
•
•
•
Servizi sanitari:
– Guardia Medica;
– Ospedali;
– Farmacie/Parafarmacie.
Trasporti:
– Aereoporti;
– Stazioni ferroviarie;
– Taxi;
– Traghetti;
– Bus e pullman.
Parcheggi:
– Parcheggi pubblici;
– Parcheggi privati.
Sezione relativa agli eventi
Questa macro-area del sistema avrà l’obbiettivo di sponsorizzare gli eventi che si
svolgono nella provincia di Reggio Calabria. L’utente potrà consultare la lista degli
eventi disponibili categorizzati secondo la seguente tassonomia:
•
•
•
Culturale;
Musica e spettacolo;
Sport.
Il sistema dovrà visualizzare solo gli eventi ancora in corso e quelli futuri.
Sezione relativa alla ricerca dei contenuti
Attraverso questo requisito funzionale, un utente dovrà poter effettuare una ricerca
tra tutti i contenuti disponibili per individuare quelli capaci di soddisfare le proprie
esigenze. I risultati della ricerca porteranno ad una lista che conterrà tutti quei
contenuti che rispondono ai criteri di ricerca inseriti. A questo punto, l’applicazione consentirà l’accesso ad un’area di dettaglio, in cui verranno riportate tutte le
informazioni riguardanti il singolo contenuto. In particolare, si distingueranno due
tipologie di ricerca:
•
•
Ricerca generica: potrà permettere all’utente di ricercare un contenuto generico
senza specificare nessun filtro;
Ricerca avanza: potrà permettere all’utente di ricercare un contenuto generico
specificando il contesto di riferimento e utilizzando opportuni filtri.
12
Sezione relativa alla gestione dei contenuti
I contenuti visualizzati sui dispositivi mobili non dovranno essere memorizzati localmente, ma risiederanno su un sistema esterno, il quale verrà amministrato tramite
un sito “web responsive”. Tale scelta è stata fatta per creare un facile accesso all’area di gestione (attività CRUD) e per una predisposizione ad-hoc per le future
release.
1.2 Studio di fattibilità
Dopo la fase preliminare di raccolta dei requisiti è stato necessario produrre un
documento esplicativo dello studio di fattibilità che raccogliesse tutti gli aspetti
relativi ai possibili rischi che si potranno incontrare in fase di produzione ed eventuali
anomalie e/o eventuali aspetti non fattibili. In questa sezione parleremo proprio di
questo studio di fattbilità prendendo in considerazione i seguenti quattro aspetti:
•
•
•
•
Progetto di massima della soluzione: specifiche e modalità di realizzazione.
Analisi dei rischi: fattori di rischio e modalità di gestione del rischio.
Modalità di attuazione del progetto: segmentazione, realizzazioni previste, piano
di massima, tempi e risorse, comprese, naturalmente, le risorse umane.
Analisi di impatto: stima dei costi e analisi di investimenti necessari ed eventuali.
1.2.1 La situazione attuale
Il prodotto finale, come già definito nel documento di analisi dei requisiti, sarà costituito da un’applicazione mobile multi-piattaforma di supporto ai turisti e fungerà
da vetrina per la città di Reggio Calabria. Il sistema commissionato dovrà fornire
una serie di servizi agli utenti finali; questi potranno essere: turisti, cittadini, esercenti e amministratori comunali. L’obbiettivo finale sarà, dunque, la pubblicazione
dell’applicativo sui principali marketplace (Apple Store e Play Store) e la fornitura
di un pannello di amministrazione per la gestione dei contenuti.
1.2.2 Progetto di massima della soluzione
Il punto di partenza per la produzione di una soluzione è quello di individuare
le specifiche applicative che riguardano l’architettura dei dati, l’architettura applicativa e l’interfaccia utente. Dal punto di vista tecnologico, l’architettura dei dati
sarà gestita mediante un DBMS relazionale. L’architettura applicativa e l’interfaccia
utente, per quanto riguarda gli user administrator, saranno gestite tramite un sito
web “responsive”, mentre, per la fruizione dei servizi da parte degli utenti passivi,
sarà utilizzata un’applicazione mobile multipiattaforma.
L’architettura verrà realizzata in maniera modulare, in modo tale da permettere
il riutilizzo di ciascun modulo per tutti gli aspetti comuni risparmiando in termini
di tempi di sviluppo e mantenendo una buona scalabilità e una buona gestione del
software.
1.2 Studio di fattibilità
13
1.2.3 Analisi dei rischi
La dimensione progettuale e la complessità generale non implicano rischi sulla fase
di produzione in quanto la fase di analisi ha ben chiarito tutti i task da realizzare.
La modalità di attuazione del progetto prevede una segmentazione indipendente
che faciliterà la parallelizzazione del lavoro.
Fattori di rischio trasversali
I fattori di rischio trasversale che si possono individuare nel presente progetto sono
i seguenti:
•
•
•
•
la mancata partecipazione degli enti comunali nel fruire dati necessari al sistema;
la scarsa disponibilità di risorse in quanto il progetto non prevede alcun tipo di
finanziamento;
l’utilizzo di un unico server centralizzato che potrebbe bloccare il processo di
sviluppo in caso di mal funzionamento;
la possibilità di guasto o malfunzionamento dei calcolatori personali utilizzati
dagli sviluppatori, che può provocare rallentamenti di produzione dei singoli
task.
Per fronteggiare tali problematiche si cercherà di creare una struttura il meno
dipendente possibile dai contenuti, che si appoggia su strutture di testing fornite
dall’Università Mediterranea di Reggio Calabria, dando la priorità allo sviluppo
di componenti software lato server. Inoltre, per gestire le richieste di modifiche e
aggiunte durante la fase di produzione, si creeranno dei check-point con cadenza
settimanale. I tempi di sviluppo sono stati valutati con un ampio margine di tolleranza. La scelta di adottare strumenti innovativi per lo sviluppo potrà rappresentare
un fattore di rallentamento in fase iniziale di produzione. Quantificando il rischio
in termini di impatto, questo può considerarsi basso.
1.2.4 Modalità di attuazione del progetto
Segmentazione del progetto
Come già sottolineato nella fase di analisi dei requisiti, si è suddiviso il sistema in
una serie di macro-aree. La segmentazione del progetto consiste nella progettazione
e nell’implementazione separata di esse. La struttura e le funzionalità delle singole
macro-aree sono state discusse e concordate in seguito a colloqui ed interviste con
gli stakeholder.
Problemi sui singoli segmenti
Dopo aver analizzato la macro-area 10, riguardante la gestione dei contenuti, sono state riscontrate alcune problematiche di carattere implementativo, gestionale e
legate alle regole del libero mercato. Il punto focale del problema era relativo all’impossibilità di attingere in maniera automatica e programmata ad informazioni
relative ad enti privati (ristorazioni, pernottamenti e svaghi) e a quelle legate ad
14
eventi comunali e non. Oltre a questo, l’inserimento di una particolare attività (effettuato dall’amministratore) rispetto ad un’altra potrebbe portare al non rispetto
delle normali regole di equità di mercato.
Per questa serie di motivi è stato fissato un nuovo incontro con gli stakeholder
(nello specifico con un rappresentante dell’amministrazione comunale), durante il
quale è stata proposta una soluzione alternativa. La soluzione individuata ha richiesto la realizzazione di una nuova funzionalità, grazie alla quale gli esercenti, previo
acquisto di opportune credenziali, potranno accedere al pannello di amministrazione
e inserire i dati relativi alla propria attività o all’evento da loro organizzato. Tale
soluzione sarà disponibile nella seconda release del sistema.
Un altro aspetto di cui si è discusso durante il secondo incontro con gli stakeholder è stato quello relativo alla macro-area riguardante i servizi primari; più
nello specifico, in fase preliminare, si era pensato di fornire informazioni dettagliate
legate ai servizi offerti da varie aziende dei trasporti. Una soluzione di questo tipo
non sarebbe stata possibile in quanto alcune aziende avevano già progettato di realizzare delle proprie applicazioni. Per questo motivo si è deciso di ridurre il livello
di dettaglio.
Gli altri macro blocchi non presentano altri limiti temporali o implementativi.
1.2.5 Analisi dei tempi e delle risorse umane
Nella Figura 1.1 vediamo il diagramma di Gantt che illustra in maniera generale la
stima dei tempi di produzione del progetto.
Figura 1.1. Il diagramma di Gantt iniziale
Le risorse umane necessarie per la realizzazione del progetto sono due figure di
analisti e programmatori.
1.2.6 Analisi di impatto: Costi
L’analisi di impatto relativo ai costi ha portato ad individuare due differenti fonti
di spesa. Da una parte risulta necessario prendere in considerazioni i costi base per
il rilascio dell’applicativo mobile, ovvero 25 e per Android (una tantum) e 100 e
per iOS (all’anno); e dall’altra i costi relativi al server (non stimati in questa fase del progetto in quanto, per il momento, ospitati presso il SIAT dell’Università
Mediterranea di Reggio Calabria.).
2
Tecnologie ibride di seconda generazione:
AppGyver
Questo capitolo presenterà la tecnologia software che è stata adottata per la realizzazione della componente client-side del sistema. Verranno descritte le differenze
principali tra programmazione nativa, quella orientata al web e quella ibrida; di
quest’ultima si analizzeranno i framework più diffusi e, infine, ci si soffermerà sulla
piattaforma scelta per il progetto di tesi, ovvero AppGyver.
2.1 La rivoluzione del mobile
L’Italia è al primo posto in Europa per il numero di smartphone posseduti dalla
popolazione e si presenta come la cartina di tornasole per analizzare il mercato
tecnologico che interessa l’intero pianeta. La grande rivoluzione è avvenuta tra il
2009 e il 2012 con il boom degli smartphone la cui percentuale di possesso da parte
della popolazione è passata dal 15% al 27,7%. Il 2011 rappresenta un’altra data
cruciale; esso è, infatti, l’anno in cui è avvenuto lo storico sorpasso dei dispositivi
mobili sui PC; i 100 milioni di dispositivi mobili venduti in tutto il mondo, contro i
93 milioni di PC, non rappresentano soltanto una semplice inversione di tendenza a
livello di mercato, ma una vera e propria svolta tecnologica e sociale, l’inizio di una
nuova era. Questa rivoluzione ha comportato un cambio nella modalità di accesso
e fruizione dei contenuti, nel modo di pensare degli utenti, nel modo di interagire
tra loro e di effettuare tutte quelle operazioni quotidiane che prima richiedevano, se
non la presenza fisica in un determinato luogo, almeno l’utilizzo di un dispositivo
fisso, o relativamente ingombrante, come computer e notebook.
Il successo dei dispositivi mobili si diffonde di pari passo con la crescita delle
cosiddette app, sostantivo, questo, che è ormai entrato a far parte del vocabolario
comune di milioni di persone, nonostante, fino a pochi anni fa non avesse alcun
rilevante significato. Il termine app deriva dal termine inglese “application”; tecnicamente si tratta di applicazioni di vario genere, gratuite o meno, che è possibile
scaricare sui propri smartphone o tablet, direttamente dai principali marketplace.
Il vero punto di forza delle applicazioni mobili è, sicuramente, rappresentato facilità
di utilizzo e dalla vasta gamma di servizi che possono essere consumati mediante il
loro utilizzo.
16
2 Tecnologie ibride di seconda generazione: AppGyver
Parallelamente alla diffusione sul mercato delle applicazioni mobili si è avuta
una crescita esponenziale delle aziende che hanno focalizzato il loro core business
sullo sviluppo software delle app. Per la creazione di un’applicazione, le aziende
del settore, ma anche gli sviluppatori indipendenti, si trovano di fronte almeno
tre possibilità: sviluppare su una specifica piattaforma e rilasciare la propria app
soltanto per essa, lavorare su più piattaforme per garantirsi un pubblico più vasto
oppure adottare l’approccio ibrido o cross-platform.
2.1.1 Mobile application: app nativa, ibrida e webApp
Dopo aver introdotto il concetto di applicazione mobile, vediamo quali sono le tecnologie utilizzate per il loro sviluppo, evidenziandone le differenze, compresi i vantaggi
e gli svantaggi. In generale, è possibile scegliere tra diversi approcci per la realizzazione di applicazioni per smartphone e tablet. Più specificatamente, nel panorama
attuale è possibile individuare le seguenti soluzioni:
•
•
•
applicazioni native;
web app;
applicazioni ibride.
Queste saranno esaminate più in dettaglio nelle prossime sottosezioni.
Applicazioni native
Le app native sono applicazioni create appositamente per un certo sistema operativo
mobile, scritte con il linguaggio della piattaforma su cui dovranno girare e installabili
sul dispositivo. Ad esempio, nel caso del sistema operativo iOS, un’app nativa sarà
scritta in linguaggio Objective-C o Swift e sarà scaricabile da App Store; invece,
un’app per Android sarà scritta in Java e sarà possibile eseguire il download su
Google Play Store.
Web app
Le web app sono pagine web orientate ai dispositivi mobili scritte in un linguaggio
cross-platform come HTML. Essendo pagine web, esse sono accessibili da qualsiasi
dispositivo mobile che, però, supporti le più recenti tecnologie web (come HTML5
e CSS3). C’è da dire, però, che le web app hanno un accesso parziale all’hardware
del dispositivo. Esse, infine, hanno velocità ragionevoli e non posseggono uno store
dedicato.
Applicazioni ibride
Le app ibride sono applicazioni scritte in un linguaggio cross-platform (in genere,
Javascript + HTML5), come le web app; a differenze di queste ultime, però, esse
possono essere incapsulate tramite web view nel linguaggio nativo di una determinata piattaforma. Si possono, quindi, scaricare dagli store di riferimento ed installare
sui rispettivi dispositivi: esse presentono un discreto accesso al sistema operativo
2.1 La rivoluzione del mobile
17
anche se non sono state scritte interamente nel linguaggio specifico della piattaforma. Questa soluzione è un giusto compromesso tra sviluppo web standard e app
native, in quanto permette l’accesso e il controllo all’hardware sviluppando, però, il
cuore dell’applicazione in linguaggi standard dedicati al web.
Vantaggi e svantaggi delle tre tecnologie
Ogni tecnologia precedentemente descritta ha aspetti positivi e negativi e la scelta di
una di esse deve essere fatta valutando attentamente le diverse condizioni ed il contesto in cui si va ad operare. Descriviamo, adesso, gli aspetti positivi e negativi delle
tecnologie sopra descritte. Le applicazioni native sono quelle che si interfacciano al
sistema operativo mobile nel modo più completo. Essendo sviluppate per quella specifica piattaforma possono interfacciarsi del tutto con le API della stessa, andando,
cosı̀, ad interagire totalmente con l’hardware e il software (o, comunque, con le parti
hardware e software rese accessibili dal gestore della piattaforma). Ne consegue che
esse potranno sfruttare le funzioni più importanti del dispositivo, integrandole e
potenziandole: stiamo parlando dell’accesso alla fotocamera, alla geolocalizzazione,
al file system, alla rubrica, alle funzioni di pinch-to-zoom, e molto altro ancora.
In questo modo, le applicazioni native riescono ad offrire una maggiore velocità
di esecuzione e, quindi, prestazioni elevate. Senza dubbio, tale approccio fornisce una
user experience sensazionale, ma ha anche dei punti negativi. Più specificatamente:
•
•
Le applicazioni native sono legate alla piattaforma per la quale vengono sviluppate.
Se si vuole rendere disponibile il software su più piattaforme, esso dovrà essere
realizzato tramite l’utilizzo di tecnologie differenti; per questo motivo il tempo
di sviluppo sarà molto lungo poiché, nonostante il risultato finale sia più o meno
lo stesso in tutte le piattaforme, l’app dovrà essere scritta in linguaggi diversi.
Le web app hanno lo svantaggio di non potersi interfacciare con le API del sistema operativo e di non poter, quindi, accedere ad hardware e software del dispositivo
(ad esempio, non sono in grado di accedere al file system). Esse non sono installate
sul dispositivo ma su un server web, quindi sono accessibili soltanto in modalità
online “responsive”.
Il loro grande vantaggio è quello di non incidere particolarmente sulla memoria
RAM e sulla capacità di calcolo del dispositivo in uso; in sostanza, una web app
funziona con le medesime prestazioni su smartphone che possiedono processori con
performance differenti. Ciò che influenzerà le prestazioni sarà la connessione internet più o meno veloce. Tale approccio è perfetto per applicazioni per cui non è
strettamente necessario accedere alle funzioni “fisiche” del dispositivo o in casi in
cui i tempi di rilascio sono molto brevi.
Le app ibride fondono i vantaggi delle web app con quelle delle app native,
con la conseguenza di un time-to-market molto ridotto. In altre parole esse offrono
la possibilità di programmare una sola volta per poi incapsulare il codice, tramite opportune operazioni, negli specifici “gusci” costituiti dai sorgenti di ciascuna
piattaforma. Esse offrono, atresı̀, la possibilità di interagire con le funzioni software
e hardware del dispositivo. Un’app ibrida non sarà mai fluida e ottimizzata come
un’app nativa, e comunque richiederà un tempo di sviluppo superiore a un’app web.
18
Le app ibride, però, abbattono i costi di sviluppo, avendo un costo di produzione
più contenuto rispetto a quello delle app native, e offrono una curva di apprendimento migliore. Infine, esse non implicano la conoscenza di tutti i linguaggi di
programmazione delle piattaforme mobili.
Anche nel caso di sviluppo di applicazioni mobili tramite tecnologie ibride si
incontrano degli svantaggi; il loro livello di rilevanza varia in maniera differente
anche in base al tipo di piattaforma utilizzata. I principali svantaggi da considerare riguardano la minore efficienza nel rendering grafico, non confrontabile con
quello effettuato tramite la tecnologia nativa, la potenziale lentezza di esecuzione
nell’accesso alle risorse locali e, infine, in base ai framework utilizzati, l’aspetto
dell’interfaccia grafica che potrebbe non risultare abbastanza omogenea rispetto a
quella nativa della piattaforma. In linea di massima, le app ibride si pongono a metà
strada tra le app native e le web app, rappresentando un buon compromesso per la
creazione di applicazioni mobili multipiattaforma con un supporto nativo.
Le precedenti considerazioni sono alla base della nostra scelta di sviluppare la
componente mobile del sistema oggetto della presente tesi utilizzando un approccio
ibrido. Nello specifico, abbiamo deciso di adottare la piattaforma per lo sviluppo di
applicazioni mobile ibride AppGyver.
2.1.2 I principali ambienti di sviluppo di app ibride
Nello sviluppo delle applicazioni mobili, la scelta del framework e della modalità di
sviluppo del progetto, che si adatta meglio alle esigenze di mercato del cliente, è un
elemento critico che deve essere valutato con grande attenzione visti gli impatti sul
business nel medio e breve termine. Quando si parla di framework per lo sviluppo
di applicazioni mobili ibride si intende un insieme di librerie sulle quali un software
può essere progettato, realizzato e distribuito su più piattaforme scrivendo il codice
sorgente una sola volta. Il compito del framework è infatti quello di ricompilare il
codice in modo che si adatti automaticamente a sistemi operativi diversi come ad
esempio iOS, Android e Windows Phone. In ambito mobile, è possibile identificare
due possibili tipologie di framwork:
•
•
Wrapper, framework di prima generazione;
Librerie, framework di seconda generazione.
2.2 Framework di prima generazione: Cordova e
Appcelerator
Per quanto riguarda i framework di prima generazione, in questa sezione si è scelto
di analizzare Apache Cordova e Titanium Appcelerator. Tali framework sono stati
nel passato, e continuano a rappresentare nel presente, una delle scelte principali,
per aziende e sviluppatori indipendenti, nella creazione di app cross-platform.
2.2.1 Apache Cordova
Apache Cordova (Figura 2.1) nasce dal progetto PhoneGap avviato da un’azienda
canadese, Nitobi Software, e venduto nel 2011 ad Abobe. Contestualmente alla
2.2 Framework di prima generazione: Cordova e Appcelerator
19
trattativa con Adobe, Nitobi ha donato alla fondazione Apache il progetto che in un
primo tempo aveva assunto il nome di Apache Callback e, successivamente, il nome
attuale di Apache Cordova. Si tratta, quindi, un software open source distribuito
con licenza Apache 2.0.
Figura 2.1. Apache Cordova e PhoneGap
Aspetti tecnici e architettura del framework
Apache Cordova è un framework di sviluppo per applicazioni mobili open source.
Esso fornisce gli strumenti necessari a sviluppare software per i dispositivi mobili
che utilizzano JavaScript, HTML5 e CSS3, senza che questi ultimi debbano utilizzare API specifiche della piattaforma, come quelle di Android, iOS o Windows Phone.
Anche se Cordova è un framework multipiattaforma, i requisiti software variano in
base alla piattaforma mobile di riferimento. Ad esempio, per sviluppare un’applicazione e compilarla per Android possiamo usare indifferentemente un PC Linux,
Windows o un Mac, mentre possiamo sviluppare un’app iOS solo su Mac. Questo
perché, per ciascuna piattaforma mobile di riferimento, dobbiamo avere installato il
relativo SDK di sviluppo. Il codice HTML, CSS, JavaScript scritto non è compilato
da Apache Cordova nel linguaggio nativo del dispositivo scelto. Sostanzialmente,
l’architettura di Apache Cordova si presenta come una sorta di contenitore di applicazione web eseguita localmente. Cordova è, infatti, costituita da una web view che
occupa l’intero schermo del dispositivo all’interno della quale vendono “renderizzati” l’HTML e CSS, e viene eseguito il codice JavaScript. L’utilizzo di quest’ultimo
permette di sfruttare le API necessarie per far comunicare la web view con il dispositivo che lo occupa. In altre parole, le applicazioni vengono eseguite in un wrapper
specifico per ogni piattaforma, il quale utilizza le API messe a disposizione dagli
ambienti specifici per accedere alle risorse hardware e software di ogni dispositivo.
Nonostante il framework si basi sul principio di unicità del codice è, comunque,
inevitabile che la fase ultima di deploy dell’applicazione debba essere effettuata su
una piattaforma di sviluppo nativa. Una volta completato lo sviluppo basato su
HTML, JS e CSS, la fase finale prevede la creazione, su X-Code per iOS e su Eclipse per Android, di un progetto che, sfruttando le librerie native di Cordova (una
20
per ogni tipo di piattaforma) permetterà la fruizione e l’interoperabilità con l’applicativo scritto in linguaggio universale. Per la creazione di tali progetti, necessari
al porting dell’applicazione, non è richiesta alcuna conoscenza di linguaggio nativo
in quanto i passaggi sono illustrati nel dettaglio sul sito di Apache Cordova. Per
utilizzare le funzionalità native dei dispositivi, il framework in questione mette a
disposizione dei componenti software che prendono il nome di plugin. Essi consistono in porzioni di codice implementate da una web view che permette di “mappare”
una funzione Java Script su una funzione nativa. Tali plugin sono usufruibili tramite
un’interfaccia JavaScript la quale fornisce diverse implementazioni dipendenti dalla
specifica piattaforma. Tutti i plugin di sistema sono contenuti nel Cordova Registry,
uno specifico repository messa a disposizione dal framework. Tramite tali plugin,
specifici per ogni esigenza, è possibile accedere alle seguenti classi di funzionalità:
•
•
•
•
•
•
•
•
•
Accelerometro: questo plugin consente di accedere all’accelerometro del dispositivo. Quest’ultimo è un sensore di movimento che rileva il cambiamento (delta) nel
movimento relativo all’orientamento corrente del dispositivo in tre dimensioni
lungo gli assi x, y e z.
Camera: tale plugin definisce un oggetto globale navigator.camera, il quale
permette l’accesso alla fotocamera, fornendo la possibilità di salvare l’immagine
scattata come file oppure di ottenerla con codifica base64 (codifica utilizzata
per la trasmissione tramite chiamate http). Esso fornisce, per la maggior parte
delle piattaforme, anche la possibilità di accedere alle immagini già presenti nella
libreria fotografica del dispositivo.
Capture: questo plugin è più generico rispetto al plugin Camera. Esso permette
l’acquisizione di file multimediali di tipo audio, immagine o video, offrendo la
possibilità di specificare diversi formati di acquisizione.
Connection: Tale plugin ci permette di accedere alle informazioni relative alla
connettività attuale del dispositivo; è possibile sapere se essa non è presente, se
è di tipo ETHERNET, WIFI, 2G, 3G o 4G.
Contacts: esso consente di accedere alle informazioni relative ai contatti, permettondo anche, di crearne di nuovi o di modificare quelli esistenti.
Device: tale plugin permette di accedere alle informazioni hardware e software
del dispositivo in uso.
Events: tale plugin permette di gestire gli eventi che si verificano sul dispositivo.
Gli eventi che è possibile gestire sono:
– dispositivo pronto (quando l’applicazione è completamente caricata);
– dispositivo in pausa (quando l’applicazione va in background);
– dispositivo online (quando viene rilevata la connettività);
– dispositivo offline (quando viene rilevata mancanza di connettività);
– pressione tasto back (se presente);
– rilevato livello critico o basso livello batteria;
– dispositivo offline (rilevata mancanza di connettività);
– rilevata pressione di pulsanti hardware vari.
File: questo plugin permette di interfacciarsi con il file system e consente
l’accesso in lettura e scrittura ai file e alle cartelle che risiedono sul dispositivo.
Geolocation: tale plugin consente di utilizzare il sensore GPS e, quindi, di rilevare
la posizione corrente del dispositivo anche quando quest’ultimo è in movimento. La posizione restituita corrisponderà alle coordinate fornite dal sensore o,
2.2 Framework di prima generazione: Cordova e Appcelerator
•
•
•
21
nel caso in cui queste ultime non fossero presenti, alle coordinate calcolate in
base alle specifiche W3C delle API di geolocalizzazione. Le coordinate vengono
restituite sotto forma di latitudine e longitudine.
Globalization: tale plugin permette di avere informazioni riguardo le lingue e le
impostazioni internazionali correnti del dispositivo (lingua attuale, separatore
delle migliaia, decimali, formato per la data, etc.).
Notification: questo plugin permette di gestire le azioni di notifica, come visualizzazione di messaggi (alert), alla vibrazione, ai suoni; a tal fine esso utilizza
audio e grafica nativi del dispositivo utilizzato.
Storage: esso permette l’utilizzo dello storage del dispositivo basato sulla specifica W3C dei database SQL web.
Nella Figura 2.2 viene rappresentata l’architettura che si è appena descritta.
Figura 2.2. Architettura di Apache Cordova
2.2.2 Titanium Appcelerator
Titanium Appcelerator (Figura 2.3), introdotto nel dicembre 2008, è una piattaforma software open source di sviluppo, che permette la creazione di applicazioni
multipiattaforma per dispositivi mobili utilizzando i linguaggi tipici dello sviluppo
web come Javascript, HTML e CSS. Questa peculiarità fornisce, ai programmatori
provenienti dallo sviluppo su web, una possibilità di riutilizzare le proprie competenze anche in ambito mobile, producendo applicazioni native (cioè che non girano
dentro una WebView) e multipiattaforma. Ad oggi, Titanium supporta lo sviluppo
sulle più importanti piattaforme mobile.
22
Figura 2.3. Logo di Titanium Appcelerator
Titanium viene definito come un framework di tipo “write once adapt everywhere”,
cioè un framework in cui gran parte della logica di business, delle funzioni di base,
della gestione degli eventi può essere considerata al 100% “cross-platform”, ma allo
stesso tempo permette di scrivere del codice dedicato ad aspetti relativi ad una
specifica piattaforma e non disponibile su altre. Ad esempio, le User Interface di
Android e iOS hanno entrambe a disposizione oggetti grafici come etichette (Label)
e pulsanti (Button), ma iOS ne utilizza altri che non sono presenti su Android.
Titanium permette di scrivere app in grado di sfruttare le peculiarità di ciascuna piattaforma su cui è previsto il rilascio; sarà possibile, ad esempio, utilizzare
l’ActionBar, se l’app gira su Android, oppure la NavigationBar, se l’app gira su
iOS.
Titanium funge da mediatore tra il codice sorgente dell’applicazione e il sistema
operativo nativo. Le applicazioni, scritte in JavaScript, non usano il DOM ma effettuano chiamate all’API esposta dall’SDK di Titanium. Quando si implementano
funzionalità che necessitano di interfacciarsi col sistema operativo, ad esempio per
disegnare un pulsante o per interrogare il GPS, sarà necessario richiamare specifiche
funzioni dell’SDK che, attraverso l’uso di oggetti Proxy, permetteranno di effettuare
il mapping tra richieste effettuate attraverso JavaScript e le equivalenti chiamate
in codice nativo. Il medesimo meccanismo continua a valere anche nel caso in cui il
sistema operativo ha la necessità di notificare un evento all’applicazione, ad esempio un evento scatenato dall’interazione dell’utente con la User Interface. In questo
caso, esso segue il percorso inverso e verrà gestito all’interno del codice JavaScript.
Il sistema dei proxy permette alle applicazioni Titanium di avere il “look and feel”
delle applicazioni native (perchè la UI è disegnata attraverso chiamate ai metodi
nativi del sistema operativo) con il vantaggio, per lo sviluppatore, di dover gestire
un solo progetto e una sola base di codice per più piattaforme, per di più utilizzando
un linguaggio semplice e potente come JavaScript.
Le applicazioni realizzate sfruttando tale framework saranno, come ipotizzabile,
leggermente più lente delle equivalenti native, ma, allo stesso tempo, si avrà un
guadagno in termini di tempi e costi di sviluppo. Titanium è un framework gratuito ma è disponibile anche una versione enterprise a pagamento, per sistemi OSX,
Windows e Linux. Può essere usato sia con la IDE proprietaria (Titanium Studio)
che con una CLI (Command Line Interface) basata su Node.js e personalizzabile.
Mediante Titanium Studio è possibile effettuare un debug del codice durante l’ese-
2.3 Framework di seconda generazione
23
cuzione dell’applicazione sia sul simulatore che sul dispositivo fisico; quest’ultimo
risulta indispensabile nel caso di sviluppo su Android (dal momento che l’emulatore
di Google non presenta una performance elevata).
Alloy: il framework di Titanium
Alloy è il framework di sviluppo open source creato per rendere più rapida l’implementazione delle applicazioni Titanium. Esso adotta un’architettura basato sul
pattern MVC e, tramite l’utilizzo di file XML e CSS-like, permette di separare la
logica di business dalla User Interface e dal modello dei dati. In un progetto Titanium Alloy la relazione tra una view e il suo controller è data dal nome dei file che,
ad esclusione dell’estensione, deve essere lo stesso per entrambi. Quindi, se abbiamo chiamato una view example.xml, il suo controller si chiamerà necessariamente
example.js. I due file però non verranno salvati nella stessa cartella, perchè Alloy
prevede che view e controller abbiano una directory a loro dedicata.
In Figura 2.4 viene descritta l’archittettura di Alloy, basata sul pattern MVC.
Figura 2.4. Architettura di Alloy
In questa sezione si descriveranno le caratteristiche principali dei framework mobile
di seconda generazione e si approfondirà lo studio su Ionic, uno degli ultimi nati
nell’ambito di sviluppo per applicazioni mobile. Si tratterà di un punto di partenza
per il successivo approfondimento della piattaforma AppGyver, utilizzata per la
realizzazione della componente mobile del sistema oggetto della presente tesi.
I framework di seconda generazione sono formati da un insieme di librerie che
offrono, tramite i linguaggi del web, gli strumenti per riprodurre e simulare i comportamenti tipici delle interfacce native sia in termini di grafica sia in termini di
interattività con le interfacce utente. Essi facilitano la manipolazione del DOM
(Document Object Model), l’utilizzo di librerie AJAX e la gestione degli eventi,
fornendo gli strumenti necessari a semplificare lo sviluppo delle web app.
Tali framework consentono di adattare automaticamente il layout dell’app al
display del dispositivo, seguendo le regole di RWD (Responsive Web Design) che
24
permettono di adattare l’app all’ambiente nel quale verrà eseguita supportando una
vasta gamma di dispositivi con differenti risoluzioni dello schermo e modalità di interazione. Alcune di queste librerie permettono di sfruttare il pattern architetturale
MVC (Model-View-Controller); esse sono tutte più o meno compatibili con uno o
più wrapper, e gratuite.
2.3.1 Ionic
Ionic (Figura 2.5) è un framework open source di seconda generazione che permette
di sviluppare la componente front-end di applicazioni mobile ibride. È stato realizzato da Ben Sperry, Adam Bradley Lynch del team Drifty ed è considerato dagli
autori stessi il “Bootstrap per le applicazioni ibride”. Se Bootstrap ha rivoluzionato
la creazione di interfacce per siti web, Ionic è nato con l’obbiettivo di diventare lo
strumento principe per la creazione di app mobile ibride. Tale framework è nato
nel Novembre del 2013 e la sua popolarità è cresciuta molto rapidamente fino al
raggiungimento di numeri importanti: basti pensare che vengono create migliaia di
applicazioni con Ionic ogni mese.
Figura 2.5. Il logo di Ionic
Per lo sviluppo di applicazioni tramite questo framework, si fa riferimento ad altri
due componenti essenziali per il processo di sviluppo, ovvero:
•
•
AngularJS;
Apache Cordova.
L’utilizzo cooperativo di queste due tecnologie con Ionic rende la costruzione
dell’app ibrida veloce e facile. Nella Figura 2.6 viene mostrato come queste tecnologie collaborino tra di loro, anche se il meccanismo di interazione dei tre framework
rimane trasparente all’utente.
25
Figura 2.6. Il meccanismo di interazione tra i tre framework
Nello specifico, è possibile identificare quattro differenti figure chiave, ciascuna
delle quali ricopre un ruolo specifico e fondamentale. In particolare:
•
•
•
•
Il dispositivo carica l’applicazione Ionic di cui l’utente ha deciso di fare utilizzo.
Esso contiene il sistema operativo, che gestisce l’installazione delle applicazioni e
fornisce un set di API da usare per accedere alle diverse caratteristiche hardware,
come la localizzazione GPS, l’elenco dei contatti e la fotocamera.
L’applicazione, una volta caricata, altro non è che un contenitore nativo (wrapper), realizzato con Cordova, al cui interno è presente l’applicazione web e la
cosiddetta Web View. Cordova rappresenta lo strumento necessario per creare
un ponte tra la piattaforma e l’applicazione web e ha accesso a quest’ultima
attraverso le API Javascript.
L’applicazione web, eseguita dentro la Web View, viene creata attraverso AngularJS, un framework JavaScript basato sul pattern MVC.
L’interfaccia utente dell’applicazione è curata da Ionic, che riesce a fornisce
controlli ottimizzati in grado di garantire un’esperienza di utilizzo piacevole.
Tali controlli vengono eseguiti direttamente all’interno della Web View.
Ionic fornisce un insieme di componenti legati all’interfaccia utente di cui
HTML5 non dispone. Tali componenti presentano una struttura costituita da una
combinazione di CSS, HTML e Javascript e si comportano in modo molto simile a
quanto avviene quando si utilizzano i controlli nativi. I componenti Ionic sono utilizzati tutti insieme per creare un’efficace User Interface. Ionic è la dimostrazione
che non è vero che le app native sono l’unica via per ottenere applicazioni veloci e
con supporto alle caratteristiche hardware.
Punti di forza del framework
È possibile individuare i seguenti punti di forza del framework Ionic:
•
•
Performance e reattività: la velocità, la reattività, e in generale le performance
del prodotto, rappresentano gli aspetti principali nello sviluppo di un’applicazione. Ionic è stato costruito per garantire alti livelli di prestazione. Tale framework
elimina la necessità di modificare direttamente il DOM nonchè di utilizzare librerie di terze parti per le animazioni e le transizioni. Quest’ultimo aspetto è
possibile grazie al supporto dell’accelerazione grafica hardware.
Combinazione perfetta con AngularJS: in Ionic la logica di business è gestita
da AngularJS. Il connubio tra le potenzialità offerte da AngularJS e le ricche
26
•
•
funzionalità grafiche messe a disposizione da Ionic produce uno degli strumenti
più adatti alla creazione di applicazioni mobili.
Orientamento nativo: le componenti grafiche di Ionic sono state progettate per
non discostarsi troppo da quelle native delle piattaforme mobili permettendo,
cosı̀, di garantire all’applicazione un look and feel molto simile a quello di un’applicazione nativa. In questo modo il programmatore non dovrà preoccuparsi dell’aspetto che il sistema avrà sui vari dispositivi mobili, in quanto ogni Web View
è totalmente “responsive”.
Command Line-Interface (CLI) dedicata, Ionic permette di eseguire numerose
funzioni attraverso la digitazione di semplici comandi nella CLI dedicata come
la creazione di un nuovo progetto, l’anteprima dell’applicazione nel browser o la
compilazione di un progetto già esistente.
2.4 AppGyver
La storia di AppGyver inizia solo cinque anni fa quando gli imprenditori Marko
Lehtimäki e Henri Vähäkainu ebbero l’idea di sviluppare applicazioni mobili per i
propri clienti, ma si resero presto conto che non esisteva una piattaforma completa
che permettesse tutto ciò. È possibile racchiudere la mission aziendale di AppGyver
nella volontà di rendere le applicazioni HTML5 ibride indistinguibili dalle applicazioni native e, allo stesso tempo, puntare alla realizzazione di una piattaforma
completa per lo sviluppo e che permetta la creazione di applicazioni nel modo più
rapido possibile.
Questo si può tradurre nel fornire un set di strumenti completi, sia per principianti che per esperti sviluppatori, per costruire rapidamente, testare e distribuire le
proprie applicazioni mobili. In una fase iniziale, i fondatori provarono ad utilizzare
altre soluzioni preesistenti, ma non raggiunsero la qualità che si erano prefissati per
le loro app. L’unica opzione rimasta era quella di costruirsi la propria piattaforma
personale ed è proprio adottando tale scelta che venne costruita AppGyver. AppGyver Inc. fornisce un nuovo strumento per lo sviluppo di applicazioni mobili che
possiede funzionalità multi-piattaforma in grado di garantire prestazioni paragonabili a quelle derivate dagli approcci nativi; esso garantisce, altresı̀, la capacità di
creare rapidamente applicazioni completamente funzionali senza scrivere tantissime
righe di codice.
Le applicazioni mobili realizzate tramite approcci ibridi sono viste come un compromesso per la creazione di applicazioni native, introdotte per superare i problemi
di quest’ultime, principalmente legati a tempi e costi elevati impiegati per lo sviluppo. Esse sono in grado di ottenere prestazioni accettabili utilizzando la tecnologia
web. L’approccio ibrido, anche se utilizza tecnologie orientate al web, fornisce gli
strumenti per accedere a funzioni native attraverso wrapper e web view.
AppGyver ha trovato una soluzione perspicace al problema delle scarse prestazioni delle applicazioni scritte in HTML5, le quali sono state sovrastate dalle
applicazioni native che presentano, generalmente, una performance molto migliore.
Esso offre due opzioni differenti per la costruzione di applicazioni ibride, l’utilizzo di Steroids o del più semplice, ma allo stesso tempo limitato, Composer. Questa piattaforma, rispetto alle tecnologie che la precedono, presenta alcuni vantaggi
importanti:
2.4 AppGyver
•
•
•
27
Data Binding; consiste nella gestione dell’integrazione dei dati. Utilizzando la
struttura classica delle web app, Steroids possiede un supporto per built.io, Parse
e l’integrazione con ogni REST API, tutto mediante l’utilizzo di un’interfaccia
utente point-and-click che vedremo a breve.
Non solo un framework e un compilatore; la maggior parte delle altre soluzioni
per la creazione di app ibride sono o framework di interfaccia utente o piattaforme che permettono l’utilizzo di API native e la compilazione. AppGyver invece
è una piattaforma indipendente dal linguaggio, che permette l’integrazione dei
dati e la distribuzione con un notevole supporto per plug-in.
Prestazioni native; le applicazioni ibride sono spesso criticate per non riuscire
a raggiungere sia la performance che la completezza grafica delle applicazioni
native, soprattutto quando si tratta di transizioni tra viste e animazioni. AppGyver offre tutti gli strumenti per rendere le applicazioni ibride completamente
indistinguibili da quelle native.
La piattaforma mette a disposizione degli sviluppatori gli strumenti necessari a costruire applicazioni cross-platform e pubblicarle nei marketplace, come, ad
esempio “l’AppGyver’s Academy” (Figura 2.7) , che fornisce soluzioni su tematiche
comuni e guide sui framework a disposizione.
Figura 2.7. L’AppGyver Accademy.
2.4.1 Il Composer di AppGyver
Uno dei più recenti strumenti messi a disposizione della comunity di AppGyver è il
Composer. Esso è uno strumento visuale basato sul browser che permette l’avvio e
la modifica di applicazioni in modo rapido, semplice e senza un’eccessiva esperienza
di programmazione. Esso è dotato di un modello di programmazione “drag-anddrop”, che permette di realizzare app mobile iOS e Android; esso fornisce, altresı̀,
28
un’interfaccia flessibile che consente, a chi possiede conoscenze tecniche limitate, di
costruire applicazioni di alta qualità, sia dal punto di vista della logica di business
che dal punto di vista della user interface.
Il Composer è un tool gratuito, integrato con Adobe PhoneGap, messo a disposizione degli sviluppatori, in cui sono presenti i servizi di base. Tramite acquisto è
possibile utilizzare i componenti aggiuntivi, come un proxy di dati e i servizi cloud.
Questo risulta essere un approccio sempre più in crescita, portando, cosı̀, a una
nuova classe di sviluppo di applicazioni mobili, dove non è più necessario avere una
forte conoscenza di linguaggi di programmazione specifici.
Questo tool è intuitivo e presenta una curva di apprendimento relativamente
bassa.
Ogniqualvolta si crea un progetto viene fornita una libreria di componenti comuni per l’interfaccia utente; tra questi troviamo numerosi elementi dei moduli, immagini, pannelli, elenchi, pulsanti. Allo stesso tempo, viene garantita la possibilità
di aggiungere codice HTML personalizzato.
Tutti questi componenti prendono vita tramite un editor di logica visiva in cui è
possibile configurare numerosi controlli di interazione e logica condizionale. Basta,
infatti, una conoscenza di base dei principi di programmazione per creare una logica
relativamente complessa.
Il Composer consente agli sviluppatori di utilizzare le API REST per aggiungere
un back-end personalizzato o per integrare i servizi cloud di terze parti, come Parse
e Kimono. Esso utilizza il framework JavaScript AngularJS assieme al framework
Ionic.
La compagnia di AppGyver sostiene che sono state realizzate più di 10.000
applicazioni grazie agli strumenti che essa fornisce, sponsorizzando un nuovo livello
per lo sviluppo di applicazioni mobili ibride.
Tramite l’utilizzo del Composer di AppGyver è possibile quindi, gestire la logica
applicativa, anche se complessa, semplicemente effettuando un drag-and-drop visivo. Il prodotto realizzato tramite questo strumento può essere esportato come un
progetto AppGyver Steroids per affrontare uno sviluppo più complesso. In Figura
2.8 vediamo il pannello del Composer fornito tramite browser.
2.4.2 Steroids
La società informatica odierna sostiene che l’approccio basato su CSS e JavaScript
non si avvicini abbastanza ai vantaggi offerti dal mondo nativo. Per questo motivo, AppGyver ha rilasciato Steroids Hybrid UI. Esso permette di usufruire di
una programmazione più avanzata, legata in maniera più stringente con la logica
di business, grazie alla “Steroids Command-Line Interface (CLI) hybrid UI”, con
l’obbiettivo di raggiungere le prestazioni tipicamente garantite dalle app native. Il
framework Steroids è nato con lo scopo di migliorare sostanzialmente la tecnologia
PhoneGap ponendosi l’obiettivo di creare applicazioni costruite, tramite l’utilizzo di
HTML5 e strumenti proprietari, non distinguibili da applicazioni native. Esso consente di utilizzare i componenti nativi dell’interfaccia utente relativi all’app HTML5
attraverso delle semplici API JavaScript. AppGyver Steroids colma ampiamente il
divario tra le applicazioni ibride HTML5 e le applicazioni native.
2.4 AppGyver
29
Figura 2.8. Il tool visuale del Composer di AppGyver.
Steroids UI consente di includere componenti dell’interfaccia utente nativi in
un’app HTML5 utilizzando una API JavaScript di base.
AppGyver utilizza un approccio ibrido per la realizzazione della UI, creando
animazioni e funzionalità non vincolate in maniera stringente con CSS o JavaScript.
Steroids mette a disposizione la navigazione nativa, i side menù, le animazioni, le
transazioni, e tanto altro ancora. In parallelo, il Composer utilizza l’approccio dragand-drop per aiutare lo sviluppatore a creare applicazioni e integrare API in maniera
semplice e guidata.
Steroids richiede l’integrazione di una serie di librerie esterne, che risultano essere
essenziali per il suo utilizzo. I tool esterni da integrare in fase di installazione sono
i seguenti:
•
•
•
Git; si tratta di un sistema open source di versioning distribuito, pensato per
gestire progetti di piccole o medie dimensioni
Node.js; è un framework per la realizzazione di applicazioni web in JavaScript, che permette di utilizzare questo linguaggio, tipicamente adottato per
applicazioni client-side, anche per la scrittura di applicazioni server-side.
Steroids CLI; è un’interfaccia, usufruibile lato terminale, che permette di creare,
compilare e gestire un progetto Supersonic.
Nella fase preliminare e di creazione del progetto è possibile scegliere di configurare l’applicazione come un’app single-page o multi-page (file HTLM multipli).
Steroids è in grado di generare un progetto che presenta delle impostazioni e delle
configurazioni standard e di base ma che possono essere personalizzate utilizzando il
proprio codice, oppure importando delle specifiche componenti Web, disponibili grazie all’utilizzo di un gestore di pacchetti, come Bower, un “Power tool” che permette
di affrontare lo sviluppo front-end di applicazioni single page, mobile, o comunque
di app moderne, adottando un approccio più strutturato, quasi enterprise.
30
In seguito alla personalizzazione del progetto originario, l’esecuzione del codice
avverrà su un server locale sul quale Steroids rileverà le modifiche apportate e
ricaricherà l’applicazione su un dispositivo reale o su un emulatore iOS o Android.
Il framework in questione offre un’interfaccia grafica basata su browser che
permette di usufruire dei seguenti servizi aggiuntivi:
•
•
•
•
•
connect;
logs;
documentation;
cloud;
data.
Tali servizi verrano illustrati in dettaglio nelle prossime sottosezioni.
Connect
Connect rappresenta il servizio “build distribution”, il quale permette la distribuzione della pre-release dell’app tramite l’utilizzo di un codice QR e dell’applicazione
Scanner AppGyver. Utilizzando quest’ultima applicazione, scaricabile gratuitamente sia per iOS che per Android, sarà possibile condividere e testare facilmente le
applicazioni. Ogni applicazione avrà associato un QR Code accessibile via web.
Nella Figura 2.9 è presentato il servizio Connect di AppGyver.
Figura 2.9. Il servizio Connect di AppGyver
2.4 AppGyver
31
Logs
Steroids fornisce una pipeline integrata per l’invio di eventi di log a Steroids CLI,
“bypassando” l’utilizzo del Web Inspector di Safari o del debuger di Chrome. Tale
servizio, tramite l’istruzione console.log, permette di visualizzare i messaggi in
base alla loro classe di appartenenza. Le classi disponibili sono le sequenti:
•
•
•
•
info;
errors;
warning;
debug.
Nello specifico, è possibile visualizzare i messaggi di log anche direttamente sul
dispositivo mobile, tramite l’istruzione steroids.logger. Nella Figura 2.10 viene
mostrata la console relativa alla gestione dei log di AppGyver.
Figura 2.10. La console di gestione dei log
Documentation
Questa sezione (Figura 2.11) permette di accedere a tutta la documentazione presente relativa al framework Supersonic e a tutte le API a disposizione; oltre a ciò,
essa fornisce la documentazione necessaria a sottoscrivere il codice prodotto per
renderlo disponibile a tutta la comunità.
Figura 2.11. La sezione relativa alla gestione della documentazione
32
Cloud
In quest’area (Figura 2.12) è possibile distribuire la propria applicazione sull’AppGyver Cloud e gestire le impostazioni della stessa. Nello specifico, tramite il “Build
Services”, è possibile creare la versione dell’applicazione necessaria per la sua distribuzione sui vari market-place, o creare distribuzioni ad hoc, nonchè applicazioni
scanner personalizzate che includono plugin personalizzati e altre configurazioni.
Figura 2.12. La sezione relativa alla gestione dei servizi cloud
Data
Questa area (Figura 2.13) fornisce gli strumenti necessari alla gestione dei contenuti.
Il framework permette di integrare qualsiasi back-end a supporto dell’applicazione
mobile. AppGyver fornisce anche un “Sandbox Database”, situato sul cloud, per
la memorizzazione e la gestione dei dati, utile nel caso in cui non si disponga di
un back-end esterno. Questo tipo di servizio risulta essere vantaggioso nel caso in
cui l’organizzazione dei dati non necessiti di una struttura particolare, in quanto è
possibile personalizzare le richieste sui dati tramite questo pannello utilizzando gli
strumenti forniti dallo stesso.
Risulta apparentemente impossibile integrare l’applicazione mobile direttamente
con un back-end senza migrare i dati attraverso il cloud. Questo problema può essere
aggirato non configurando la connessione tramite questo servizio ma gestendola
direttamente lato codice tramite l’utilizzo del framework AngularJS o delle librerie
Ajax.
2.4.3 Supersonic
AppGyver Steroids offre una splendida soluzione per integrare un’applicazione
HTML5 con funzionalità native del dispositivo. Tale soluzione è rappresentata da
2.4 AppGyver
33
Figura 2.13. La sezione relativa alla gestione dei contenuti
Supersonic. Esso è un framework “agnostico” che permette di estendere il codice
HTML tramite l’introduzione di nuovi tag grazie ai quali è possibile utilizzare oggetti grafici ed effetti nativi. Tale framework mette a disposizione degli sviluppatori
un vasto insieme di componenti, tra cui librerie che permettono di usufruire di oggetti grafici nativi, come Side Menu, Tab Bar, Nav Bar, e una serie di classi CSS
combinate con blocchi di codice HTML per la modellizzazione completa della UI.
Come citato nelle sezioni precedenti, Supersonic permette, tramite opportune
istruzioni, di usufruire degli oggetti grafici e degli effetti delle piattaforme Android
e iOS. Di seguito elenchiamo alcuni componenti dell’interfaccia utente che vengono
implementati in modo nativo in Supersonic:
•
•
•
tab bar;
navigation bar;
drawer.
Questi verranno illustrati in dettaglio nelle prossime sottosezioni.
Tab bar
La tab bar è una speciale barra ancorata nella parte inferiore dell’app, che permette
di raggiungere facilmente le principali view dell’applicazione. La tab bar fornita da
Supersonic è implementata tramite codice nativo; essa, quindi, è sempre situata al
di sotto dei contenuti e non interferisce né risulta influenzata dal posizionamento
degli elementi HTML. Ogni tab mantiene la propria pila di livelli (pila di view),
in modo che tutti questi e i loro contenuti siano separati dai corrispettivi presenti
nelle pile differenti.
34
Definizione delle tab
Il ciclo di vita delle tab è strettamente collegato a quello dell’applicazione, in quanto, quando quest’ultima viene terminata, le tab vengono deallocate. Esse vengono
definite all’interno del file structure.coffee, attraverso uno speciale array. La
definizione di un tab ha tre proprietà, ovvero:
•
•
•
title;
id;
location.
Nel file structure.coffee avviene la dichiarazione di un array di tab. Tale
dichiarazione è riportata nel Listato 2.1.
tabs: [
{
title: "Index"
id: "index"
location: "example#getting-started"
}
]
Listato 2.1. Dichiarazione di un array di tab
Navigation Bar
La navigation bar è posizionata al di sopra del codice HTML. Dal momento che
essa è realizzata in maniera nativa, non sarà influenzata dai vari CSS presenti nè
dai contenuti. La navigation bar ha due funzioni principali, ovvero:
•
•
offre la possibilità di mostrare un titolo o dei pulsanti opzionali per la vista
corrente.
offre automaticamente dei pulsanti che permettono di spostarsi all’interno della
pila di navigazione.
La navigation bar viene creata in maniera dichiarativa all’interno del codice
HTML grazie all’utilizzo del tag <super-navbar>. Nello specifico, attraverso l’utilizzo del tag figlio <super-navbar-title>, è possibile impostare il titolo alla pagina
corrente. Un esempio è mostrato nel Listato 2.2:
<super-navbar>
<super-navbar-title>
Titolo
</super-navbar-title>
</super-navbar>
Listato 2.2. Dichiarazione di una navigation bar
Drawer Menu
Un drawer è un container che si trova, in genere, sulla parte sinistra della view e può
essere richiamato facendo scorrere lo schermo tramite opportune gesture o utilizzando le API di Supersonic. Nel maggior parte dei casi questo oggetto grafico nativo
2.4 AppGyver
35
viene utilizzato per realizzare il “side menu”, ovvero un menu che per impostazione
predefinita, rimane nascosto fino a quando non vi è necessità di usarlo, come, ad
esempio, per accedere ad un’altra view.
La view del drawer può visualizzare codice HTML come qualsiasi altra view.
Quest’oggetto risponde alle interazioni dell’utente con la view proprio come un
drawer nativo, cosı̀ da favorire la sua apertura e la sua chiusura.
Definizione del drawer menu
I drawer vengono definiti all’interno del file /config/structure.coffee prima
di essere utilizzati all’interno dell’applicazione. Per potere abilitare un drawer, si
definisce un oggetto drawer con le seguenti tre proprietà:
•
•
•
left: per la definizione del drawer a sinistra;
right: per la definizione del drawer a destra;
location: per la definizione della configurazione condivisa dei drawer, come, ad
esempio l’animazione da utilizzare per la loro visualizzazione.
Nel Listato 2.3 possiamo osservare il codice necessario per la creazione di un
drawer menu:
drawers:
left:
id: "leftDrawer"
location: "example#drawer"
showOnAppLoad: false
options:
animation: "swingingDoor"
Listato 2.3. Dichiarazione di un drawer menu
Le proprietà left e right definiscono la posizione in cui sarà visualizzato il
drawer menu. Esse, a loro volta, possiedono a sua volta altre tre proprietà, ovvero:
•
•
•
id: utilizzata per associare un identificativo univoco al drawer in modo da poterlo
richiamare all’interno di altre web view.
location: rappresenta la view a cui riferisce la voce del drawer menù corrispondente.
showAppLoad: determina se il drawer menu dovrebbe essere visibile sullo schermo
quando l’applicazione si avvia. Tale proprietà può essere usata ad esempio per
creare un menù fisso laterale per l’applicazione.
Supersonic Native API Bridge
Per poter far comunicare le Web Views scritte in HTML5 e il codice nativo, è
necessario che ci sia un “API bridge”, che gestisca tale comunicazione. Il ponte
nativo lavora in maniera asincrona. La chiamata API viene attivata e passata al
gestore “native-side”, che si occuperà di attivare una callback appropriata.
Supersonic riesce, inoltre, a migliorare tale meccanismo avvolgendo le stesse API
JavaScript nelle cosı̀ddette “promises”. Una promise è un oggetto proxy per un
evento che non è necessariamente ancora avvenuto. Una funzione callback relativa
al successo o al fallimento può essere assegnata ad una promise e, una volta che la
promise si risolve o viene rifiutata, il callback corrispondente viene chiamato.
36
La funzionalità di base del ponte nativo è dimostrata tramite la funzione
supersonic.debug.ping, che restituisce, semplicemente, una stringa “Pong!”.
Architettura di un progetto Supersonic
In questa sezione verrà descritta in modo dettagliato la struttura di un progetto
Supersonic; allo stesso tempo verranno introdotti altri concetti importanti, come
l’architettura MVC e il concetto di vista parziale.
Nella Figura 2.14 si osserva la struttura di un progetto Supersonic di default, nel
quale sono presenti una serie di directory differenti. In particolare saremo interessati
alle directory /app e /config.
•
•
/app presenta, al proprio interno, tutto il contenuto dell’applicazione creato. Ciò
significa che tutti i file HTML, CSS e script saranno in tale cartella.
/config presenta, al proprio interno, file speciali per la configurazione e la definizione del comportamento dell’applicazione. Tali file includono la definizione
delle operazioni iniziali, la configurazione per il comportamento predefinito e il
codice per abilitare e disabilitare lo scroll per tutte le view dell’app.
Figura 2.14. L’architettura delle directory di un progetto Supersonic
Le restanti cartelle contengono dipendenze di terze parti richiesti dal framework
e varie altre cose. La cartella /dist non esiste in un progetto completamente nuovo,
viene creato solo una volta nel momento in cui l’applicazione viene compilata.
Architettura MVC
Le applicazioni Supersonic utilizzano di default il pattern MVC; ciò significa che
l’interfaccia utente (View), la logica (Controller) e il modello dei dati (model) sono tenuti separati l’uno dall’altro, con ognuno la propria area di responsabilità
nel gestire le funzionalità dell’applicazione. Utilizzando il pattern MVC si riesce a
promuovere la leggibilità del codice e il suo riutilizzo.
Le responsabilità di base dei diversi componenti MVC sono di seguito elencate:
•
Model: gestisce gli oggetti di dati di uno specifico modulo. Ciò significa che un
model non ha influenza diretta sulla User Interface dell’applicazione o sulla sua
logica, ma può essere “osservato” dagli altri componenti del pattern. In progetti
Supersonic il model sarà generalmente fornito da Supersonic Data (l’oggetto
$scope di Angular).
2.4 AppGyver
•
•
37
View: altro non è che il componente del modulo rivolto verso l’esterno e che fornisce l’interfaccia attraverso la quale gli utenti possono interagire con l’applicazione. Una View, generalmente, gestisce gli input forniti dall’utente e visualizza
i corrispettivi risultati.
Controller: rappresenta il collante tra la view e il model e contiene la maggior
parte della logica dell’applicazione. Esso è responsabile dell’aggiornamento di
una view in seguito alla modifica di un model, nonchè dell’aggiornamento del
model in base all’input fornito dall’utente.
Le viste parziali
Qualsiasi file HTML che viene creato in un progetto Supersonic, per esempio
/applicazione/views/index.html, non è un documento HTML completo; al suo
interno viene dichiarato solo un elemento <div> che si lega ad un controller mediante
l’attributo ng-controller. Tale aspetto è noto come vista parziale. Per rendere il
documento HTML valido, è necessario collegarlo ad un file speciale, detto di layout,
che, al suo interno, conterrà tutte le dichiarazioni mancanti.
Quando una specifica applicazione viene compilata, il CLI di Steroids cerca
il file layout.html nel modulo di riferimento e completa la vista parziale per la
visualizzazione della pagina HTML.
Il file layout.html specifica gli script e i fogli di stile che devono essere abbinati ad una specifica vista parziale. Esso presenta, anche, una logica speciale per
l’integrazione di Angualar.
Alcune differenze con Ionic
Il framework Supersonic presenta una serie di differenze con il framework Ionic.
Quest’ultimo viene eseguito all’interno di un’unica Web View, dove tutto viene
“renderizzato” tramite CSS. La navigazione, i menu laterali e tutte le schede sono
implementate tramite direttive AngularJS; in questo modo, se si verifica una condizione per la quale vi è la necessità di modifcare la struttura del DOM, basterà
modificare il Controller.
Supersonic, invece, sfrutta lo stack nativo di navigazione per includere più Web
View che rappresentano documenti HTML diversi, come, ad esempio, index.html
e show.html. Ciò significa che, passando da una view a quella successiva, quella
principale rimane ancora allocata e presente al livello inferiore dello stack, mentre
la nuova view si trova in cima alla pila e viene animata sullo schermo del dispositivo.
Grazie all’utilizzo di tale stack di navigazione non vi è la necessità di specificare i
percorsi espliciti.
Inoltre, Supersonic include componenti nativi dell’interfaccia utente utilizzando
i web component, riuscendo a mantenere la loro posizione originale senza dover
necessariamente creare un container che includa la logica applicativa necessaria a
realizzarli.
Supersonic sfrutta il tool Steroids di AppGyver, che fornisce emulatori Android
e iOS facilitando il debbugging, il logging cross-platform che permette la creazione
stand-alone dell’APK e dell’IPA senza la necessità di utilizzare Android Studio e
XCode.
38
La comunity di AppGyver fornisce un elenco (Figura 2.15) in cui sono presenti
le principali differenze tecniche tra i due framework.
Figura 2.15. Le principali differenze tra Supersonic e Ionic
AngularJS e Supersonic
Supersonic utilizza AngularJS come impostazione predefinita per garantire all’applicazione una struttura basata sul pattern MVC. Ogni view all’interno di
un modulo dichiara un Controller che ne gestisce la logica. Ad esempio nel file
index.html, la View verrà associata al proprio Controller mediante l’istruzione:
<div ng-controller=‘‘IndexController’’>
Il Controller è realizzato all’interno di un file JavaScript mediante l’istruzione
riportata nel Listato 2.4.
angular
.module(’superhero’)
.controller("IndexController", function($scope, Superhero) {
!!logica!!
});
Listato 2.4. Istruzione per la realizzazione di un Controller
In questo caso, la dipendenza “Superhero” viene iniettata all’interno del Controller.
2.4 AppGyver
39
2.4.4 AngularJS
AngularJS è un framework JavaScript client-side di ultima generazione rilasciato
per la prima volta nel 2012, per lo sviluppo di applicazioni Web client-side. Esso si
basa su un’infrastruttura che incoraggia l’organizzazione del codice e la separazione
dei compiti nei vari componenti. Ciascun componente del framework opera con tutti
gli altri in maniera interconnessa garantendo alte performance.
AngularJS si basa principalmente sul pattern MVC, risultando totalmente
estendibile. Esso, pertanto, non necessità di altre librerie.
AngularJS può anche essere visto come un’infrastruttura per la creazione di
applicazioni, composta da un insieme di funzionalità. Esso potenzia l’approccio
dichiarativo dell’HTML nella definizione dell’interfaccia grafica fornendo strumenti
per la costruzione di un’architettura modulare.
Essendo basato su codice JavaScript puro, AngularJS è perfetto per creare Single
Page Application, cioè applicazioni le cui risorse vengono caricate dinamicamente
su richiesta, senza necessità di ricaricare l’intera pagina. Per fare ciò, AngularJS
richiede solo linguaggi client-side come HTML, CSS e JavaScript.
Funzionalità principali
AngularJS è un framework avanzato che possiede funzionalità di rilievo utili non
solo per gli sviluppatori ma anche per i designer. Le principali funzionalità che
permettono di sfruttare al meglio questo strumento di sviluppo sono:
•
•
•
•
•
•
•
il binding bidirezionale (two-way binding);
la dependency injection;
il supporto al pattern MVC;
il supporto ai moduli;
la separazione delle competenze;
la testabilità del codice;
la riusabilità dei componenti.
Essendo AngularJS un framework, esso ha una sua infrastruttura ed un suo modello di esecuzione all’interno del quale viene inserito il codice scritto dal programmatore. Il suo funzionamento generale prevede una serie di fasi. La prima riguarda
il caricamento del framework. Il passo successivo riguarda la creazione dell’oggetto
globale angular e l’avvio del cosiddetto bootstrap, cioè il processo di inizializzazione del framework e di analisi dell’applicazione. In questa fase, AngularJS scandisce
il codice HTML della pagina corrente alla ricerca della direttiva ng-app che individua la root della nostra applicazione. Tutti gli elementi figli dell’elemento marcato
con ng-app verranno analizzati da AngularJS alla ricerca di direttive ed espressioni da valutare. Al termine di queste inizializzazioni, Angular rimane in attesa del
verificarsi di un evento.
AngularJS basa la propria logica di funzionamento sul design pattern MVC
(Model-View-Controller) e, dunque, segue il principio di separazione delle competenze.
3
Funzionalità e Mockup
Questo capitolo fornisce una descrizione dettagliata delle funzionalità che riguardano sia l’applicazione che il server. Verranno illustrati, inoltre, sia i mockup di
primo livello che quelli di secondo livello.
3.1 Funzionalità del sistema
Come conseguenza dell’analisi dei requisiti e dello studio di fattibilità descritti nei
capitoli precedenti, è stato possibile stilare l’elenco delle funzionalità che, una volta
realizzate, daranno vita al sistema EnjoyRC.
Il sistema da realizzare presenterà una struttura ben definita, derivante da
una suddivisione in macro blocchi; ciacuno di questi rappresenterà una specifica
area tematica e racchiuderà un insieme più o meno complesso di funzionalità che
riguarderanno sia la componente mobile che la quella server.
3.1.1 Funzionalità relative alla Mobile Application
Le funzionalità che verrano descritte nella presente sezione riguarderanno esclusivamente quelle necessarie a realizzare la componente client-side del sistema. Nello
specifico, esse avranno il compito di prelevare i dati memorizzati sul server, utilizzarli
come base per la creazione dell’interfaccia e, infine, renderli usufruibili dall’utente.
Allo stesso tempo, si farà una distinzione tra funzionalità verticali e funzionalità
orizzontali.
Funzionalità orizzontali
Le funzionalità orizzontali rappresentano tutti quegli aspetti che prevedono un flusso
logico indipendente rispetto agli altri task del sistema. Di seguito riportiamo tutte
le funzionalità orizzontali relative alla componente client-side del sistema:
•
•
•
realizzazione della Home Page;
realizzazione del Drawer Menu;
realizzazione dell’area relativa ai punti di interesse;
42
•
•
•
•
•
•
•
•
3 Funzionalità e Mockup
realizzazione
realizzazione
realizzazione
realizzazione
realizzazione
realizzazione
realizzazione
realizzazione
dell’area
dell’area
dell’area
dell’area
dell’area
dell’area
dell’area
dell’area
relativa
relativa
relativa
relativa
relativa
relativa
relativa
relativa
alle ristorazioni;
ai pernottamenti;
agli svaghi;
ai servizi primari;
ai percorsi turistici statici;
alle informazioni di base riguardanti la città;
agli eventi;
alla ricerca dei contenuti.
Nel seguito esamineremo più nel dettaglio ciascuna di queste funzionalità.
Realizzazione della Home Page
La Home Page rappresenta, per l’utente, la pagina di accesso ai vari contenuti del
sistema. Tramite la visualizzazione di un opportuno menu, essa permetterà di accedere a tutte le aree nelle quali l’applicazione mobile è suddivisa. Per la realizzazione
della Home Page sarà necessario prevedere l’interazione della componente clientside con il server di supporto, nel quale risiedono le informazioni utili alla creazione
delle voci di menu. Al suo interno verrà, inoltre, integrata una Navigation Bar con
lo scopo di gestire le seguenti problematiche:
•
•
•
accesso al Drawer Menu;
accesso all’area relativa alla ricerca dei contenuti;
gestione del flusso di navigazione attraverso la creazione di uno stack di view.
Realizzazione del Drawer Menu
Il Drawer Menu è un pannello a scorrimento che permetterà all’utente di accedere a
quelle aree dell’applicazione che contengono le informazioni generali. Nello specifico,
le voci di menu che esso dovrà contenere sono le seguenti:
•
•
•
•
Credits: permetterà all’utente di accedere all’area nella quale sono contenute le informazioni relative a coloro che hanno contribuito alla realizzazione
Manual: questa voce di menù dovrà permettere l’accesso all’area relativo al
manuale utente. Questa conterrà le descrizione delle varie aree dell’applicazione.
Rate EnjoyRC: questa voce di menù permetterà all’utente di accedere alla
sezione del market-place relativa al rilascio delle recensioni e alle votazioni.
Exit: questa voce di menù permetterà di uscire dall’applicazione.
Realizzazione dell’area relativa ai punti di interesse
L’area relativa ai punti di interesse dovrà essere realizzata mediante una serie di
funzionalità che creeranno una struttura di navigazione sui più livelli. Ad ogni livello
dovrà essere prevista l’interazione tra la componente client-side e il server. In queste
fasi verranno prelevati i dati relativi alla categorizzazione dei punti di interesse e
al loro dettaglio; allo stesso tempo si gestirà l’organizzazione dei contenuti e la loro
rappresentazione personalizzata in base al livello di riferimento.
43
Realizzazione dell’area relativa alle ristorazioni, ai pernottamenti e agli svaghi
Per la realizzazione delle aree relative alle attività commerciali, quali ristorazioni,
pernottamenti e svaghi, è risultato necessario realizzare un insieme di funzioni tra
loro eterogenee che, nel complesso, permettono l’interscambio di dati tra il server e
la componente client-side, con lo scopo di creare una gerarchia di view che comporrà
la struttura di navigazione.
Tale distribuzione dovrà permettere di categorizzare i contenuti sul primo livello
della gerarchia, fino ad arrivare ad un ultimo livello di dettaglio relativo all’elemento
scelto (ovvero, una ristorazione, un punto di pernottamento o uno svago), in cui dovranno essere visualizzate tutte le informazioni indispensabili che lo caratterizzano.
In quest’ultimo livello ricoprono un ruolo fondamentale le informazioni relative ai
servizi offerti dalla specifica attività.
Realizzazione dell’area relativa ai servizi primari
Le funzionalità legate alla realizzazione dell’area relativa ai servizi primari permettono, tramite l’utilizzo dei Web Service offerti dalla componente server-side del
sistema, di effettuare una doppia categorizzazione degli elementi appartenenti a differenti contesti di riferimento. A differenza delle precedenti aree descritte, quella in
questione non prevede un livello di dettaglio per il singolo servizio. L’ultimo livello
sarà costituito da una lista contenente tutte le informazioni in maniera sintetica ma
esaustiva.
Realizzazione dell’area relativa ai percorsi turistici statici
Le funzionalità relative alla realizzazione di quest’area dovranno essere tali da permettere all’utente di ricevere quante più informazioni possibili riguardanti gli itinerari turistici offerti dalla città. Anche in questo caso, l’utilizzo dei servizi dispensati dalla componente server-side permetterà di associare una tassonomia alle
informazioni da visualizzare.
Rispetto all’architettura a livelli, descritta nelle sezioni precedenti, quella dei
percorsi turistici statici presenterà un ulteriore livello di dettaglio nel quale verrà
descritta ogni singola tratta in cui un dato percorso è suddiviso. Tra le funzionalità presenti saranno utilizzate quelle relative ai servizi di Google Map. Esse
permetteranno di visualizzare su mappa l’intero itinerario da percorrere, aggiungendo informazioni di geolocalizzazione, che faciliteranno l’utente ad orientarsi per
intraprendere il percorso scelto.
Realizzazione dell’area relativa alle informazioni di base riguardanti la città
Le funzionalità necessarie per la realizzazione dell’area contenente le informazioni
di base della città dovranno essere tali da garantire la creazione di una Home Page
dalla quale partirà un flusso di navigazione secondario. La Home Page secondaria
sarà costituita da un opportuno menu con struttura a tile; ciascun tile permetterà l’accesso ad un specifica sezione. Di seguito sono elencate e descritte le aree
accessibili da questa sezione:
44
•
•
•
•
Come arrivarci: in tale sezione saranno riportate le informazioni utili a raggiungere la città di Reggio Calabria, sfruttando le funzionalità offerte da Google
Maps;
Come visitarla: in tale sezione verranno elencate le modalità con le quali è
possibile spostarsi in città;
Negozi di prodotti tipici: in tale sezione verrà contenuta una lista con le informazioni relative ai negozi di prodotti tipici presenti sul territorio;
Tradizioni: in tale sezione saranno elencate e descritte le principali tradizioni
reggine.
Realizzazione dell’area relativa agli eventi
Le funzionalità necessarie alla realizzazione di quest’area dovranno consentire ad
un utente di entrare a conoscenza delle informazioni relative agli eventi organizzati
nella città di Reggio Calabria. La lista degli eventi visualizzati dovrà essere opportunamente ordinata in modo da sponsorizzare maggiormente quelli più prossimi
alla data corrente. Per facilitarne la consultazione, gli eventi saranno organizzati
secondo una specifica tassonomia; inoltre, per ogni singolo evento, in aggiunta alle
informazioni di carattere generale, sarà fornita la locandina corrispondente.
Realizzazione dell’area relativa alla ricerca dei contenuti
Attraverso questo requisito funzionale, un utente, dovrà poter effettuare una ricerca
tra tutti i contenuti disponibili per individuare quelli capaci di soddisfare le proprie
esigenze. I risultati della ricerca verranno organizzati in una opportuna lista, la quale permetterà di accedere ad uno specifico elemento; in questo modo l’utente verrà
reindirizzato alla corrispondente pagina di dettaglio e potrà consultare le informazioni presenti. Tali funzionalità saranno realizzate in modo tale da non far gravare
le operazioni di ricerca sulla componente mobile ma solo sul server. Le operazioni da
gestire lato client saranno l’invio delle chiavi di ricerca (ed eventualmente l’aggiunta
di opportuni filtri) e la ricezione e l’organizzazione dei risultati.
Il sistema garantirà due modalità differenti per effettuare la ricerca dei contenuti:
•
•
ricerca generica dei contenuti; tale modalità utilizzerà un unico parametro per
ricercare i contenuti su tutto il set di dati del sistema;
ricerca personalizzata dei contenuti; tale modalità offrirà all’utente la possibilità
di inserire più parametri per effettuare la ricerca dei contenuti, specificando il
contesto di interesse e impostando una serie di filtri.
Funzionalità verticali
Le funzionalità verticali saranno quelle utilizzate per realizzare gli aspetti comuni
ai task del sistema. Esse verranno utilizzate per creare una sorta di struttura di
supporto per le funzionalità relative alle singole macro-aree gia descritte nei paragrafi precedenti. Il loro scopo sarà quello di dividere la logica applicativa, necessaria
alla realizzazione delle aree del sistema, con la gestione di aspetti generali che non
riguardano la logica di business. Tali funzionalità non sono quindi associabili ad
una specifica macro-area ma sono utilizzate in maniera indiscriminata e a volte
trasparente in tutte le sezioni dell’applicazione.
Di seguito sono elencate le funzionalità verticali:
•
•
•
•
45
Gestione del “multi-lingua”: tale funzionalità avrà l’obiettivo di gestire le operazioni di globalizzazione. Esse permettono di ottenere informazioni legate alla
lingua, al fuso orario e alla località geografica in cui l’utente si trova. Tali informazioni verranno utilizzate all’interno della libreria dei servizi in modo da
comunicare al server in che lingua dovranno essere restituiti i contenuti.
Integrazione dei servizi di Google Map: le funzionalità legate ai servizi di Google
Map risulteranno essere di fondamentale importanza per il sistema da realizzare;
esse ci permetteranno di creare una libreria interna che fornirà, oltre agli strumenti necessari per la visualizzazione di un percorso turistico su mappa, anche
un supporto alla navigazione mediante opportune indicazioni.
Gestione del caching dei dati: tale funzionalità permetterà di memorizzare temporaneamente in locale i contenuti prelevati dal server; in questo modo si renderanno disponibili in maniera più rapida, i dati da visualizzare e si ridurranno
le richieste HTTP, ottimizzando le prestazioni e il consumo di banda.
Gestione della connessione alla rete: tale funzionalità ci permetterà di verificare
se il dispositivo mobile sia o meno interconnesso con la rete. In caso di riscontro
negativo ogni comunicazione con il server verrà inibita e verrà opportunamente
comunicato all’utente che, per usufruire dei servizi, sarà necessario attivare una
connessione.
3.1.2 Funzionalità relative alla Web Application
In questa sezione verranno descritte le funzionalità legate alla componente serverside del sistema. Nel complesso, esse formeranno un’infrastruttura in grado di gestire
i contenuti e, nello stesso tempo, di collegare l’applicazione mobile con la base di dati
sottostante. Per favorire una descrizione più chiara ed esaustiva, possiamo dividere
le funzionalità nella seguente tassonomia:
•
•
•
•
funzionalità
funzionalità
funzionalità
funzionalità
CRUD;
legate alla realizzazione dei Web Service;
legate all’integrazione dei servizi di Google Map;
legate alla gestione delle immagini.
Esse verranno descritte in dettaglio nelle prossime sottosezioni.
Funzionalità CRUD
Tali funzionalità permetteranno la gestione e la manipolazione dei contenuti relativi
a quelle specifiche tabelle che rappresentano la realtà di interesse; nello specifico il
sistema dovrà:
•
•
•
•
•
fornire un modulo di autenticazione per gli amministratori;
permettere all’amministratore di inserire i dati relativi ad un punto di interesse;
permettere all’amministratore di visualizzare la lista dei punti di interesse;
permettere la modifica e la cancellazione di un punto di interesse;
permettere all’amministratore di inserire i dati relativi ad un punto di ristorazione, di pernottamento e di svago;
46
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
permettere all’amministratore di visualizzare la lista dei punti di ristorazioni,
dipernottamento e degli svagho;
permettere la modifica e la cancellazione di un punto di ristorazione, di pernottamento o di svago;
permettere all’amministratore di inserire un percorso turistico statico;
permettere la modifica e la cancellazione di un way point;
permettere all’amministratore di visualizzare la lista dei percorsi turistici;
permettere all’amministratore di visualizzare la lista delle tratte;
permettere la modifica e la cancellazione di un percorso turistico statico;
permettere la modifica e la cancellazione di un way point;
permettere all’amministratore di inserire i dati relativi ad un servizio primario;
permettere all’amministratore di visualizzare la lista dei servizi primari;
permettere la modifica e la cancellazione di un servizio primario;
permettere all’amministratore di inserire i dati relativi ad un negozio di prodotti
tipici;
permettere all’amministratore di visualizzare la lista dei negozi di prodotti tipici;
permettere la modifica e la cancellazione di un negozio di prodotti tipici;
permettere all’amministratore di inserire i dati relativi ad una tradizione;
permettere all’amministratore di visualizzare la lista delle tradizioni;
permettere la modifica e la cancellazione dei dati relativi ad una tradizione;
permettere all’amministratore di inserire i dati relativi ad un evento;
permettere all’amministratore di visualizzare la lista degli eventi;
permettere la modifica e la cancellazione di un evento;
permettere all’amministratore di inserire i dati relativi al manuale utente;
permettere all’amministratore di visualizzare le informazioni contenute nel manuale utente;
permettere la modifica e la cancellazione delle informazioni contenute nel manuale utente;
permettere all’amministratore di inserire una nuovo elemento nella Home Page
dell’applicazione mobile;
permettere all’amministratore di visualizzare gli elementi della Home Page
permettere la modifica e la cancellazione di un un elemento della Home Page
permettere all’amministratore di inserire una nuovo elemento nel Drawer Menu
permettere all’amministratore di visualizzare gli elementi del Drawer Menu
permettere la modifica e la cancellazione di un un elemento del Drawer Menu
permettere di effettuare una ricerca all’interno dei contenuti del database.
Funzionalità legate alla realizzazione dei Web Service
Le funzionalità relative ai Web Service permetteranno di esporre i dati che verranno visualizzati dall’applicazione. Per la realizzazione di ciascun Web Service sarà
necessario fornire al sistema un insieme di parametri che permetteranno di filtrare
3.2 Mockup
47
opportunamente la richiesta e di conoscere la lingua nella quale dovranno essere
restituiti i contenuti. L’architettura utilizzata per la realizzazione dei servivi sarà
un’architettura “RESTful”, in quanto per accedere alla risorsa, bisognerà conoscerne
la locazione specifica senza l’utilizzo di nessuna interfaccia.
Funzionalità legate all’integrazione dei servizi di Google Map
Per agevolare la creazione di un percorso turistico e per automatizzare il processo di
recupero delle informazioni legate alla posizione geografica di tutti gli elementi che
la richiedono, risulterà utile usufruire di alcune API fornite da Google Map. L’integrazione di tali librerie risulta essere fondamentale in quanto eviterà l’inserimento
di informazioni errate.
Nello specifico, per quanto riguarda i percorsi turistici, tutte le informazioni
estrapolate grazie all’utilizzo di tali librerie verranno memorizzate e messe a disposizione dell’applicazione mobile, dispensandola dall’effettuare operazioni troppo
onerose.
Funzionalità legate alla gestione delle immagini
Il sistema dovrà prevedere una serie di funzionalità che forniranno un supporto
al caricamento di un’immagine; tale operazione risulterà essere verticale rispetto a
quelle descritte in precedenza. Nel dettaglio, essa permetterà di memorizzare un’immagine all’interno di una specifica cartella situata all’interno del server, gestendone
il ridimensionamento e l’estensione. Tutte queste funzionalità dovranno essere rese
disponibili all’interno di un’opportuna libreria.
3.2 Mockup
Questa sezione descriverà i mockup di primo e di secondo livello che ci consentiranno
di illustrate in dettaglio le principali funzionalità fornite dall’applicazione EnjoyRC.
Un mockup è una rappresentazione statica del progetto finale dalla qualità medioalta; di solito è un progetto grafico molto dettagliato, a volte coincidente con il
progetto finale vero e proprio.
Un mockup ben realizzato ha la funzione di:
•
•
•
rappresentare nel dettaglio i vari contenuti;
rappresentare le funzionalità di base in maniera statica;
illustrare il lato grafico del progetto.
Di seguito verranno descritti i mockup che rappresenteranno i vari macro-blocchi
del sistema.
3.2.1 Mockup relativo alla Home Page e al Drawer Menu
La Home Page rappresenta la pagina più importante dell’intera applicazione in
quanto è la prima pagina con la quale l’utente si interfaccia. Si è scelto di realizzare
48
una Home Page semplice ed intuitiva che, come le altre parti dell’applicazione,
seguirà le regole dello User Experience Design. La Home Page sarà caratterizzata
da una barra di navigazione superiore con l’accesso al Drawer Menu sulla sinistra
e all’area di ricerca sulla destra. Al centro sarà messo in evidenza il logo ufficiale
dell’applicazione. Il corpo centrale sarà costituito da un massimo di 8 icone che
permetteranno ad un utente di accedere alle varie sezioni dell’applicazione. Queste
ultime rappresentano i vari macro-blocchi di cui sopra. Tali macro-aree sono:
•
•
•
•
•
•
•
•
Punti di interesse;
Ristorazione;
Pernottamento;
Percorsi;
Servizi Primari;
Svaghi;
La città;
Eventi.
Nelle Figure 3.1 e 3.2 vengono mostrati, rispettivamente, i mockup di primo e
di secondo livello relativi alla Home Page e al Drawer Menu.
Figura 3.1. Il mockup di primo livello relativo alla Home Page e al Drawer Menu
3.2.2 Mockup relativo alla sezione “Ricerca”
La pagina relativa alla funzionalità di ricerca risulterà divisa in due aree distinte. La
prima, in alto, permetterà all’utente di effettuare una ricerca generica all’interno dei
3.2 Mockup
49
Figura 3.2. Il mockup di secondo livello relativo alla Home Page e al Drawer Menu, con
relative “gesture”
contenuti dell’applicazione; la seconda, in basso, consentirà all’utente di ricercare
un’informazione applicando dei filtri prestabiliti. In questa seconda modalità di
ricerca si potrà scegliere uno specifico ambito (ristorazione, pernottamento, etc.) ed
accedere ad un secondo livello di ricerca più dettagliato, in cui si potranno definire
i valori di alcuni parametri.
Nelle Figure 7.4 e 7.5 vengoo mostrati, rispettivamente, i mockup di primo e di
secondo livello relativi alla sezione di ricerca.
3.2.3 Mockup relativi alla sezione “Punti di interesse”
Il macro-blocco relativo ai punti di interesse permetterà all’utente di consultare una
lista completa dei principali luoghi e delle principali attrattive di interesse turistico.
Tale sezione prevede una tassonomia in cui saranno divisi i vari punti. Il secondo
livello mostra la lista dei punti di interesse associata ad una particolare tipologia;
per ciascun punto vengono mostratati un’anteprima dell’immagine, il nome e la
locazione.
Il dettaglio consiste in un’immagine del punto in questione, nel nome esteso,
nella locazione, una breve descrizione, e infine, grazie al supporto di una mappa
(mostrata nell’ultimo livello), le informazioni che permettono di raggiungerlo.
di secondo livello relativi alla sezione “Punti di interesse”.
50
Figura 3.3. Il mockup di primo livello relativo alla sezione “Ricerca”
Figura 3.4. Il mockup di secondo livello relativo alla sezione “Ricerca”, con relative
“gesture”
3.2 Mockup
51
Figura 3.5. Il mockup di primo livello relativo alla sezione “Punti di interesse”
Figura 3.6. Il mockup di secondo livello relativo alla sezione “Punti di interesse”, con
relative “gesture”
3.2.4 Mockup relativi alla sezione “Ristorazione”
Nel momento in cui l’utente sceglie di accedere alla sezione “Ristorazione”, egli si
ritroverà di fronte tutte le possibili categorie (pizzerie, ristoranti, bar e gelaterie,
etc.) tra le quali effettuare la propria scelta. Passando al secondo livello di dettaglio,
ipotizzando di aver selezionato la categoria “Pizzeria”, egli potrà consultare l’elenco
completo delle pizzerie salvate sul database. La pagina di dettaglio prevede il nome
del locale in alto, un’immagine caratteristica dello stesso e, ovviamente, tutte le
informazioni di base, presentate in un listato a cascata.
Due aspetti meritano di essere sottolineati; il primo è la presenza di alcune icone
al di sotto dell’immagine, che indicano i servizi usufruibili in quello specifico locale;
il secondo è la possibilità, mediante il pulsante “Go-To”, di usufruire delle mappe
per ottenere indicazioni stradali utili e, quindi, la visualizzazione della localizzazione
dell’esercizio.
di secondo livello relativi alla sezione “Ristorazione”.
52
Figura 3.7. Il mockup di primo livello relativo alla sezione “Ristorazione”
Figura 3.8. Il mockup di secondo livello relativo alla sezione “Ristorazione”, con relative
“gesture”
3.2 Mockup
53
3.2.5 Mockup relativi alla sezione “Percorsi turistici”
Il macro-blocco dei percorsi turistici raccoglie una lista di percorsi “statici”, scelti
a priori, che l’utilizzatore del sistema può consultare ed, eventualmente, provare.
Tali percorsi saranno organizzati secondo una tassonomia prestabilita. Essa sarà
mostrata tramite una prima lista che presenta la tipologia dei percorsi; cliccando su
una riga si potrà accedere ad una seconda lista contenente i percorsi corrispondenti.
Selezionando, a sua volta, un elemento di questa seconda lista si accederà all’area
relativa al dettaglio del percorso prescelto.
Il dettaglio di un percorso sarà formato da una mappa che conterrà il punto di
inizio e di fine, la lista dei vari tratti, un’indicazione relativa al punto di partenza
consigliato (con la possibilità di ricavare, tramite mappa, le informazioni utili per
raggiungerlo) e una breve descrizione.
Un altro livello di dettaglio è stato aggiunto per descrivere ciascuna tratta del
percorso. La singola tratta, a sua volta, sarà composta da una mappa con il punto
di inizio e di fine, la durata in Km, nonchè una breve descrizione.
di secondo livello relativi alla sezione “Percorsi turistici”.
Figura 3.9. Il mockup di primo livello relativo alla sezione “Percorsi turistici”
3.2.6 Mockup relativi alla sezione “Svaghi”
La sezione “Svaghi” presenta una struttura simile a quella della sezione “Ristorazione”. Anche il mockup di riferimento risulta essere simile a quello descritto in
precedenza. Saranno presenti il nome dell’attività selezionata, la sua immagine di
riferimento, le informazioni basilari (orario, fascia di prezzo, sito Internet e descrizione), nonché le icone dei servizi offerti, nonchè ( qualora lo si voglia) le indicazioni
stradali per raggiungere l’attività selezionata.
Nelle Figure 7.15 e 3.12 vengono mostrati, rispettivamente, i mockup di primo
e di secondo livello relativi alla sezione “Svaghi”.
54
Figura 3.10. Il mockup di secondo livello relativo alla sezione “Percorsi turistici” con
relative gesture.
Figura 3.11. Il mockup di primo livello relativo alla sezione “Svaghi”
3.2.7 Mockup relativi alla sezione “Eventi”
La sezione “Eventi” dell’applicazione sarà costituita da tre livelli di dettaglio e,
quindi, rappresentata da tre differenti tipologie di pagine. La pagina principale avrà
una struttura abbastanza semplice in cui verrà visualizzata una classificazione degli
eventi (culturale, musica e spettacolo, sport, etc.). Cliccando sull’apposito pulsante,
l’utente sarà reindirizzato alla pagina di secondo livello nella quale potrà visualizzare
tutti gli eventi legati all’ambito scelto e consultare alcune informazioni di base.
Sarà, inoltre, possibile accedere ai dettagli dell’evento, visualizzando la locandina,
gli orari, le date, il luogo e la descrizione.
Nelle Figure 3.13 viene mostrato il mockup di secondo livello relativo alla sezione
“Eventi”.
3.2.8 Mockup relativo alla sezione “La città”
Questo macro-blocco contiene le informazioni generali relative alla città di Reggio
Calabria. Nel primo livello verranno mostrate una breve descrizione della città e
3.2 Mockup
55
Figura 3.12. Il mockup di secondo livello relativo alla sezione “Svaghi” con relative
gesture.
Figura 3.13. Il mockup di secondo livello relativo alla sezione “Eventi”, con relative
“gesture”
56
una lista per consultare varie informazioni più nel dettaglio. Tra queste abbiamo:
•
•
•
•
Come si arriva;
Come visitarla;
Negozi prodotti tipici;
Tradizioni.
Cliccando su “Come si arriva” e su “Come visitarla” verranno mostrate tutte le
informazioni utili all’utente per raggiungere e visitare la città di Reggio Calabria; a
tal fine ci si avvale del supporto di opportune mappe.
Nelle Figura 7.25 viene mostrato il mockup di secondo livello relativo alla sezione
“La città”.
Figura 3.14. Il mockup di secondo livello relativo alla sezione “La città”, con relative
“gesture”
4
Progettazione delle funzionalità di base
Questo capitolo fornisce una descrizione dettagliata della fase di progettazione che
riguarda l’applicazione EnjoyRC. In particolare, verranno prese in considerazione
la struttura del client e la fase di progettazione della componente applicativa.
4.1 Architettura dell’applicazione
L’architettura generale della componente client-side del nostro sistema, denominato EnjoyRC, è mostrata nella Figura 4.1. Tale architettura evidenzia come sono
organizzati i contenuti e come è possibile navigare attraverso di essi.
Questa struttura gerarchica mostra come si estende il sistema a partire dalla
radice dell’albero, ovvero la Home Page, fino ad arrivare alle foglie, rappresentate dalle pagine di dettaglio. I vari colori corrispondono a flussi logici differenti e
ogni livello dell’albero evidenzia l’importanza ricoperta dalla pagina corrispondente
durante il flusso di lavoro dell’applicazione. Percorrendo l’albero da sinistra verso
destra, partendo dal nodo radice, incontreremo otto flussi logici differenti:
•
•
•
•
Punti di interesse: questo flusso di navigazione è formato dalla lista di categorie a
cui è associato almeno un punto di interesse, dalla lista dei contenuti organizzati
per categorie, dal dettaglio di un singolo punto e, infine, dalla mappa che indica
come raggiungerlo.
Punti di Ristorazione: questo flusso di navigazione è formato dalla lista di categorie a cui è associato almeno una punto di ristorazione, dalla lista dei contenuti
organizzati per categorie, dal dettaglio di un singolo punto e, infine, dalla mappa
che indica come raggiungerlo.
Punti di Pernottamento: questo flusso di navigazione è formato dalla lista di
categorie a cui è associato almeno un punto di pernottamento, dalla lista dei
contenuti organizzati per categorie, dal dettaglio di un singolo pernottamento,
e infine, dalla mappa che indica come raggiungerlo.
Percorsi turistici: questo flusso di navigazione è formato dalla lista di categorie a
cui è associato almeno un percorso turistico, dalla lista dei contenuti organizzati
per categorie, dal dettaglio di un singolo percorso, dal dettaglio delle tratte di
cui esso è composto e, infine, dalla mappa che indica come raggiungere il punto
di partenza.
58
4 Progettazione delle funzionalità di base
Figura 4.1. L’architettura dell’applicazione EnjoyRC
•
•
•
•
Servizi Primari: questo flusso di navigazione è formato dalla lista delle tipologie
di servizi a disposizione, dalle categorie dei servizi organizzate per tipo e, infine,
dalla lista dei contenuti organizzati per categorie.
Svaghi: questo flusso di navigazione è formato dalla lista di categorie a cui è associato almeno uno svago, dalla lista dei contenuti organizzati per categorie, dal
dettaglio di un singolo svago e, infine, dalla mappa che indica come raggiungerlo.
La città: questo flusso di navigazione porta ad una home page secondaria da cui
partono 4 task differenti, ovvero:
– Negozi di prodotti tipici: il nodo foglia di questo ramo è rappresentato dalla
pagina contenente la lista dei negozi di prodotti tipici.
– Tradizioni: il nodo foglia di questo ramo è rappresentato dalla pagina
contenente la lista delle tradizioni.
– Come arrivare in città: il nodo foglia di questo ramo è rappresentato da una
mappa che indica come arrivare in città.
– Come visitare la città: il nodo foglia di questo ramo è rappresentato da una
lista di informazioni inerenti a come muoversi all’interno della città.
Eventi: questo flusso di navigazione è formato dalla lista di categorie a cui è
4.2 Progettazione della componente applicativa
59
associato almeno un evento, dalla lista dei contenuti organizzati per categorie e,
infine, dal dettaglio di un singolo evento.
Percorrendo l’albero da destra verso sinistra, partendo dal nodo radice, incontreremo due ramificazioni differenti in cui i nodi di partenza sono “L’Area di ricerca”
e il “Drawer Menù”. Il primo si ramifica in due tipologie di ricerca e termina nella
pagina di dettaglio che mostra il risultato di queste due operazioni. Il secondo porta
a tre nodi foglia le cui view corrispondenti contengono informazioni di supporto
all’utilizzo del sistema.
Per progettazione delle applicazioni si intende quella fase della progettazione di
un sistema informativo che si occupa di progettare l’insieme delle applicazioni o,
per meglio dire, dei gruppi di funzionalità di cui esso è composto. Questa fase di
progettazione non può che tenere fortemente in considerazione le metodologie e gli
strumenti tipici dell’Ingegneria del Software. In questo settore il meta-modello di
riferimento è UML. Esso, infatti, supporta in modo estremamente preciso e rigoroso
sia la progettazione orientata agli oggetti che la progettazione basata sui componenti, che rappresentano le tecniche di programmazione di gran lunga più utilizzate
attualmente nel contesto della produzione del software.
Utilizzando UML come meta-modello di riferimento, la progettazione della componente applicativa del sistema EnjoyRC può essere effettuata utilizzando i seguenti
diagrammi:
•
•
•
diagrammi dei casi d’uso;
diagrammi di attività;
diagrammi di sequenza.
4.2.1 Diagrammi dei casi d’uso
I diagrammi dei casi d’uso sono quei diagrammi dedicati alla descrizione delle funzioni o ai servizi offerti da un sistema o da una sua parte, cosı̀ come sono percepiti e
utilizzati dagli attori che interagiscono col sistema stesso. Esso permette di esprime
un comportamento, offerto o desiderato, sulla base dei suoi risultati osservabili. Esso
individua chi o che cosa ha a che fare con il sistema (attore) e che cosa viene fatto
(caso d’uso). Si tratta, tipicamente, del primo tipo di diagramma ad essere creato
in un processo o ciclo di sviluppo, nell’ambito dell’analisi dei requisiti. Il suo scopo
principale è quello di modellare i requisiti funzionali di un sistema. Per semplicità di
comprensione, si è preferito organizzare i diagrammi dei casi d’uso sulla base della
suddivisione in macro-blocchi del sistema.
Diagramma dei casi d’uso relativo alla sezione “Punti di interesse”
In Figura 4.2 viene mostrato il diagramma dei casi d’uso relativo al macro-blocco
“Punti di interesse”.
60
Figura 4.2. Il diagramma dei casi d’uso relativo al macro-blocco “Punti di interesse”
La navigazione all’interno di questa sezione è consentita tramite l’utilizzo di
questo insieme di casi d’uso. Quelli relativi alla visualizzazione dei contenuti vengono
realizzati per fornire un punto di ingresso ad ogni livello della gerarchia di view;
tuttavia, per la loro esistenza, essi devono estendere i casi d’uso relativi alla ricerca.
Questi ultimi, ad eccezione di quello relativo alla ricerca di un punto di interesse,
sono dei casi d’uso più complessi rispetto a quelli descritti precedentemente; ciò
deriva dal fatto che le operazioni che li compongono includono delle interazioni con
un sistema esterno.
I macro-blocchi “Ristorazioni”, “Pernottamenti”, “Svaghi” e “Servizi primari”
presentano delle analogie funzionali rispetto a quanto appena descritto e, di conseguenza, anche diagrammi dei casi d’uso simili. Per questo motivo, essi, non verranno
descritti nel seguito.
Diagramma dei casi d’uso relativo alla sezione “La città”
“La città”.
61
Figura 4.3. Il diagramma dei casi d’uso relativo al macro-blocco “La città”
La realizzazione di questa sezione è consentita tramite l’utilizzo dai casi d’uso
visualizzati nella figura. Essi risultano essere differenti rispetto a quelli rappresentati
in precedenza dal momento che, oltre al contesto differente, permettono di realizzare una seconda struttura di navigazione perfettamente collegata con la prima.
In aggiunta ai casi d’uso relativi alla visualizzazione e alla ricerca dei contenuti,
incontriamo quelli riguardanti la visualizzazione della mappa della città. Un utente, grazie all’utilizzo di questi casi d’uso, entra a conoscenza di tutte le indicazioni
necessarie a raggiungere e visitare la città.
4.2.2 Diagrammi di attività
I diagrammi di attività sono quelli che descrivono un processo e organizzano più
entità in un insieme di azioni secondo un determinato flusso. Un diagramma di
attività descrive fondamentalmente un’attività relativa ad un qualsiasi elemento di
modellazione, come classi, casi d’uso, interfacce, componenti e operazioni di classe.
Tipicamente, i diagrammi di attività vengono utilizzati per modellare il flusso di un
caso d’uso (analisi) o il funzionamento di un’operazione.
Un diagramma di attività è formato dalle seguenti componenti:
•
•
•
•
Nodi azione: specificano unità atomiche e istantanee di comportamento.
Nodi di inizio e di fine: sono nodi speciali che indicano l’inizio e la fine di un
flusso.
Nodi oggetto: sono oggetti particolarmente importanti usati come input e output
di azioni.
Nodi controllo: descrivono il flusso dell’attività.
62
Diagramma di attività relativo alla sezione “Punti di interesse”
In Figura 4.4 viene mostrato il diagramma di attività relativo al macro-blocco
Figura 4.4. Il diagramma di attività relativo al macro-blocco “Punti di interesse”
L’attività parte dal nodo di controllo iniziale denominato Start e si sposta nel
nodo azione Preleva categorie punti di interesse. Esso richiama un comportamento più complesso, formato da un insieme di attività che effettuano una serie
di chiamate a dei servizi esterni e interpretano il risultato ottenuto. Una volta terminata tale attività, il flusso si sposta in quella relativa alla visualizzazione delle
informazioni prelevate. A questo punto l’utente può scegliere di terminare l’attività o di visualizzare i punti di interesse associati ad una determinata categoria.
In quest’ultimo caso il flusso si sposta nel nodo azione Preleva i punti punti
63
di interesse della categoria selezionata. Esso rappresenta la chiamata all’attività che avrà il compito di consumare i servizi necessari al recupero delle informazioni richieste; da qui il flusso si sposterà al nodo che visualizzerà i punti di
interesse recuperati. Giunto a questo punto, l’utente potrà scegliere se terminare il
flusso di lavoro o se visualizzare il dettaglio di un elemento. In quest’ultimo caso
il flusso verrà indirizzato nel nodo deputato a mostrare in dettaglio il contenuto
selezionato. Infine, l’utente potrà scegliere se spostare il flusso direttamente verso il
nodo di controllo denominato End oppure se passare dapprima per il nodo deputato
a visualizzare la mappa in cui è presente la posizione del punto.
Diagramma di attività relativo alla sezione “La città”
In Figura 4.5 viene mostrato il diagramma di attività relativo al macro-blocco “La
città”. L’attività parte dal nodo di controllo iniziale, denominato Start e si dirige verso il nodo di biforcazione (fork). Quest’ultimo ha il compito di duplicare i
token in ingresso sulle uscite in modo da parallelizzare due flussi di lavoro concorrenti, rappresentati, rispettivamente, dalle attività Preleva info città e Preleva
voci di menù. I due token concorrenti si dirigono in un nodo ricongiunzione (join).
Quest’ultimo farà partire il flusso in uscita soltanto quando tutte le due attività
arriveranno al suo ingresso. A questo punto un nodo decisione offrirà la possibilità
di visualizzare la descrizione della città o di navigare all’interno del menù presente
in questa sezione. Il flusso terminerà nel nodo End.
Nelle Figura 4.6 viene rappresentato la macro-attività Preleva info città.
Il suo flusso parte dal nodo di controllo Start per poi verificare la presenza di
una connessione alla rete. In caso di riscontro negativo, l’attività termina. In caso
contrario, invece, il flusso si sposta nel nodo che rappresenta l’invio della richiesta
HTTP per recuperare i dati memorizzati sul server. Le successive attività descrivono
le operazioni effettuate sul server necessarie al recupero e all’esposizione dei dati
richiesti. L’attività termina nel nodo di controllo End.
Nella Figura 4.7 è rappresentata la macro-attività Preleva voci di menù. Il
suo flusso è formato da una serie di attività con uguale granularità rispetto alla precedente. Anche qui viene verificata la presenza di una connessione alla rete. In caso
di riscontro positivo viene inviata una richiesta HTTP al server. In questo caso non
ci sarà nessuna attività corrispondente al recupero delle informazioni dal database,
dal momento che queste verranno generate al momento. Una volta terminata l’attività relativa alla creazione delle voci di menù, il flusso si sposta nell’attività che ha
il compito di esporre i dati richiesti. Una volta elaborati i dati, il flusso terminerà
nel nodo End.
4.2.3 Diagrammi di sequenza
I diagrammi di sequenza sono quelli che modellano le interazioni tra le varie entità di
un sistema e ne visualizzano lo scambio di messaggi nel tempo. Il loro scopo è quello
di mostrare come un certo comportamento viene realizzato dalla collaborazione delle
entità di cui il sistema è composto. Tali diagrammi mostrano la realizzazione di un
comportamento offerto e la sequenza temporale degli avvenimenti per ogni entità
coinvolta. I componenti di un diagramma di sequenza sono:
64
Figura 4.5. Il diagramma di attività relativo al macro-blocco “La città”
•
•
istanze di classificatori, ciascuna delle quali rappresenta uno specifico oggetto;
linee di vita (lifeline) di classificatori, ciascuna delle quali rappresenta un’istanza
arbitraria di un classificatore. Essa esprime il ruolo giocato da un’istanza senza
preoccuparsi della sua identità.
Diagramma di sequenza relativo alla sezione “Punti di interesse”
In Figura 4.8 viene mostrato il diagramma di sequenza relativo al macro-blocco
Tale diagramma mostra le interazioni tra i vari oggetti coinvolti nel processo di
navigazione. Il flusso temporale parte nel momento in cui l’utente richiede di visualizzare le categorie inerenti a quest’area. Tale richiesta è destinata alla componente
mobile del sistema, la quale, prima di procedere al recupero delle informazioni, verifica la presenza di una connessione alla rete Internet. In caso di esito negativo,
essa ne comunicherà l’assenza all’utente. In caso contrario, invece, essa contatterà
il Web service provider per recuperare le categorie.
Il Web service provider interagirà con il DBMS sottostante per recuperare le
informazioni necessarie a soddisfare la richiesta. Tale comportamento è rappresentato da un secondo diagramma di attività, denominato Ricerca categorie punti
di interesse, (che, per brevità, non descriveremo in dettaglio) incluso tramite
65
Figura 4.6. Il diagramma di attività relativo al recupero delle informazioni riguardanti
la città
l’utilizzo di un ref. Una volta recuperate le categorie, queste ultime, tramite uno
scambio di messaggi, arriveranno alla componente mobile per poi essere visualizzate. A questo punto, se l’utente seleziona una categoria, la componente mobile, dopo
aver verificato la presenza di una connessione, invierà una richiesta al Web service
provider per recuperare tutti i punti di interesse inerenti al contesto scelto.
L’azione svolta dal web service provider per prelevare le informazioni desiderate è rappresentato dal diagramma di sequenza Ricerca punti di interesse
(che, per brevità, non descriveremo in dettaglio), incluso tramite l’utilizzo di un
ref. Tramite uno scambio di messaggi, l’utente riuscirà a visualizzare la lista dei
punti di interesse relativi alla categoria scelta. A questo punto, egli potrà richiedere
alla componente mobile di visualizzare il dettaglio di un punto, oppure una mappa,
per conoscerne la posizione esatta.
Diagramma di sequenza relativo alla sezione “La città”
In Figura 4.9 viene mostrato il diagramma di sequenza relativo al macro-blocco “La
città”.
66
Figura 4.7. Il diagramma di attività relativo al recupero delle informazioni riguardanti il
menù del macro-blocco “La città”
Esso mostra le interazioni tra i vari oggetti coinvolti nel processi di navigazione. Il flusso temporale parte nel momento in cui l’utente richiede di visualizzare
il menù fornito da questa sezione. La richiesta verrà elaborata dalla componente
mobile che verificherà la presenza della connessione alla rete Internet. In caso di
riscontro negativo, essa ne comunicherà l’assenza all’utente. In caso contrario, invece, essa comunicherà con il Web service provider per recuperare le informazioni
generali riguardanti la città e le voci di menù. Il processo di recupero delle prime
è rappresentato dal diagramma di sequenza Ricerca info città, incluso tramite
l’utilizzo di un ref; questa attività coinvolge sia il Web service provider che il
database. Le informazioni prelevabili da questa seconda struttura verranno generate
al momento.
Una volta terminato il processo di recupero, tramite uno scambio di messaggi,
tutte le informazioni richieste dall’utente arriveranno alla componente mobile e potranno essere visualizzate. A questo punto, l’utente potrà decidere se visualizzare
le descrizione della città o se continuare la navigazione all’interno del menù offerto
da quest’area. Quest’ultimo comportamento è rappresentato dal diagramma di sequenza Naviga all’interno del Menù Città, incluso con un ref, del quale non
Figura 4.8. Il diagramma di sequenza relativo al macro-blocco “Punti di interesse”
67
68
citeremo i dettagli.
Figura 4.9. Il diagramma di sequenza relativo al macro-blocco “La città”
5
Implementezione delle funzionalità di base
Questo capitolo descrive la fase di implementazione della componente client del
sistema EnjoyRC. In particolare, verranno descritti gli strumenti utilizzati e verranno illustrate le porzioni di codice che hanno reso possibile il soddisfacimento dei
requisiti citati in precedenza.
5.1 Strumenti a supporto dell’implementazione
La realizzazione del sistema oggetto della presente tesi ha previsto l’utilizzo di un
insieme di strumenti, alcuni dei quali fondamentali per la fase di implementazione.
Tra questi analizzeremo gli IDE di sviluppo adottati per la stesura del codice e il
sistema di versioning utilizzato per favorire la collaborazione dei componenti del
team di sviluppo.
5.1.1 IDE di sviluppo
Uno degli strumenti più importanti per lo sviluppo di un software è, senza dubbio,
l’IDE (Integrated Development Environment/Ambiente Integrato di Sviluppo). Tale applicativo aiuta a redigere il codice in modo intuitivo e ordinato mettendo a
disposizione una serie di funzionalità che semplificano notevolmente il processo di
sviluppo. Ciò che rende indispensabile un IDE è la possibilità di organizzare i lavori
per progetti, di usufruire dei messaggi di errore durante la scrittura del codice, di
sfruttare la sintassi evidenziata del codice sorgente, di utilizzare il completamento
automatico e di effettuare una ricerca simultanea nei file dell’intero progetto.
Gli IDE adottati nella presente tesi fanno parte della famiglia JetBrains, una
società di sviluppo software il cui target è rappresentato da sviluppatori e project
manager.
5.1.2 IDE JetBrains
JetBrains PhpStorm è un software commerciale nato come piattaforma per lo sviluppo integrato di applicazioni PHP (supporta le versioni 5.3, 5.4, 5.5, 5.6 di PHP).
Esso fornisce un editor anche per i linguaggi JavaScript e HTML. PhpStorm è dotato
70
5 Implementezione delle funzionalità di base
di caratteristiche di rilievo finalizzate ad aumentare la produttività degli utilizzatori
e a permettere l’analisi del codice a caldo. Allo stesso tempo, esso permette di effettuare la prevenzione degli errori e il refactoring in maniera automatizzata sia per
PHP che per JavaScript. PhpStorm si basa sulla piattaforma IntelliJ IDEA (scritta
in Java), che fornisce la possibilità di estendere l’IDE con l’integrazione di plugin
proprietari o di terze parti. Il debugging avviene secondo una modalità visuale per
rendere più agevole la fase di implementazione del software. In sintesi, PhpStorm
permette di:
•
•
•
•
•
Gestire basi di dati supportando la sintassi SQL. Nello specifico, esso permette
di modificare uno schema attivo, di generare script per la sua migrazione, di
esportare il risultato delle query su file o appunti e di modificare le procedure
memorizzate.
Effettuare una distribuzione remota del codice tramite FTP, SFTP, FTPS, con
sincronizzazione automatica.
Integrare i principali sistemi di controllo di versione, tra cui Git, Subversion,
Mercurial, Perforce, VS e TFS, permettendo l’esecuzione delle operazioni di
merge, commit, etc. direttamente dall’IDE.
Creare i diagrammi delle classi UML dai quali è possibile effettuare direttamente
il refactoring del codice PHP.
Supportare Vagrant, console SSH e altri tool remoti.
JetBrains WebStorm è uno dei più potenti software per lo sviluppo di applicazioni JavaScript, HTML, CSS e per molte altre tecnologie web. Tale IDE fornisce gli
strumenti necessari allo sviluppo di complessi sistemi lato client e, grazie all’utilizzo
di Node.js, anche lato server. Analogamente a PhpStorm, esso fornisce la gestione
intelligente del codice, il completamento automatico a supporto della stesura dello
stesso, le funzionalità di refactoring e la prevenzione degli errori “on-the-fly”. PhpStorm supporta i principali framework JavaScript, come AngularJS e Meteor, e, allo
stesso tempo, permette di integrare numerosi strumenti per effettuare le operazioni
di test, analisi e controllo di versione del codice.
La differenza sostanziale tra i due IDE appena descritti è che l’ultimo non permette lo sviluppo di applicazioni PHP nè fornisce un supporto per l’integrazione
con i DBMS.
5.1.3 Sistemi di versioning e Bitbucket
Un sistema di controllo di versione è una combinazione di tecnologie e procedure
per tracciare i cambiamenti dei file di uno specifico progetto, in particolar modo
del codice sorgente e della sua documentazione. La ragione per cui il controllo di
versione è cosı̀ universalmente adottato sta nel fatto che esso aiuta potenzialmente
ogni aspetto della gestione di un progetto: comunicazioni tra sviluppatori, gestione
dei rilasci, gestione dei bug, stabilità del codice, tentativi di sviluppo sperimentali
e attribuzione e autorizzazione di cambiamenti da parte di alcuni sviluppatori.
Tutti questi aspetti hanno reso l’adozione di un sistema per il controllo di versione di fondamentale importanza anche nel contesto specifico del presente lavoro
di tesi. Tale sistema consente una corretta e semplice collaborazione tra i membri
5.1 Strumenti a supporto dell’implementazione
71
del team di sviluppo, permettendo agli stessi di lavorare contemporaneamente su
diversi file o, addirittura, sullo stesso file, parallelizzando i compiti.
È possibile classificare i sistemi di controllo di versione in due grandi tipologie:
•
•
Sistemi di controllo di versione centralizzati (Centralized Versioning Control System - CVCS): questi sistemi, come CVS, Subversion e Perforce, hanno un unico
server che contiene tutte le versioni dei file e un numero di utenti che li scaricano
dal server centrale. Essi offrono molti vantaggi. Infatti, gli Gli amministratori
hanno un controllo preciso su chi può fare cosa; inoltre, la la gestione dei controlli
è molto più semplice. Tuttavia, tale configurazione presenta anche una serie di
controindicazioni; la più ovvia è che il server centralizzato rappresenta il singolo
punto di rottura del sistema.
Sistemi di controllo distribuiti (Distributed Versioning Control System - DVCS):
in tali sistemi i client non solo controllano la versione più recente dei file, ma
effettuano una copia completa del repository. In questo modo se un server dovesse
presentare un malfunzionamento, il repository di un qualsiasi client può essere
copiato sul server per ripristinare quest’ultimo.
Git Version
Per dare un supporto alla fase di realizzazione della componente client del sistema
si è scelto, a seguito dei vantaggi citati precedentemente, di adottare un sistema
di versioning distribuito, ovvero Git Version. Se i sistemi di controllo di versione
centralizzati salvano l’informazione come una lista di cambiamenti apportati ai file
e ne memorizzano le modifiche su ciascuno di essi, Git, invece, considera i propri
dati come una serie di istantanee (snapshot) di un mini filesystem.
Ogniqualvolta si vuole effettuare il caricamento delle modifiche (commit) o il
salvataggio dello stato del progetto, Git realizza fondamentalmente un’immagine
di tutti i file, salvando un riferimento allo snapshot. Per essere efficiente, se alcuni
file non sono cambiati, Git non effettua il salvataggio, ma crea, semplicemente, un
collegamento al file precedentemente salvati (come mostrato in Figura 5.1).
Figura 5.1. Il funzionamento dell’operazione di commit in Git
72
Git presenta una serie di vantaggi rispetto ai suoi predecessori; infatti:
•
•
•
Esso consente la navigazione di un progetto senza la necessità di connettersi
al server per scaricarlo, accedendo direttamente al database locale; Git, infatti,
necessita solo di file e risorse locali per operare.
In Git ogni aspetto è controllato tramite checksum; questo significa che è impossibile cambiare il contenuto di qualsiasi file o directory senza che Git lo sappia.
Si tratta di una funzionalità interna di basso livello di Git, intrinseca alla sua
filosofia.
Quasi tutte le azioni in Git aggiungono dati al suo database. È piuttosto difficile
effettuare operazioni irreversibili o cancellare i dati in modo permanente.
Architettura e operazioni di base
Un progetto Git presenta una struttura ben definita. Esso è costituito dalle seguenti
componenti:
•
•
•
Working dir: essa contiene i file appartenenti alla versione corrente del progetto
sulla quale l’intero team, e nello specifico l’utente, stanno lavorando.
Index: essa contiene i file candidati a subire un operazione di commit.
Head: essa contiene gli ultimi file di cui è stato effettuato il commit.
Il punto di partenza per l’inizializzazione di un progetto Git consiste nel clonare
un repository esistente da un altro server o nel definire un nuovo progetto come
“GIT Repository”. In quest’ultimo caso è necessario accedere alla directory del
progetto e lanciare il comando init. A seguito di ciò, creerà una nuova directory
nella quale saranno inseriti i file di configurazione del repository.
Uno dei punti di forza di Git è la gestione dei Branch (ramificazioni). Questi
ultimi sono utilizzati per sviluppare feature isolate l’una dall’altra. Il repository
creato in fase di inizializzazione corrisponde al “Branch Master”. È possibile creare
altre ramificazioni per lo sviluppo di attività secondarie ed, infine, incorporarle in
quella principale. Tale operazione risulta essere di fondamentale importanza nel
momento in cui si sviluppano nuove funzionalità indipendenti dalla versione stabile
del software. Per creare un nuovo Branch è sufficiente utilizzare l’operazione di
“checkout”, specificando il nome che si vuole attribuire a quello specifico branch.
Bitbucket
Bitbucket è una piattaforma adottata per la gestione delle operazioni di controllo di
versione. Essa permette di ospitare il proprio codice direttamente online, rendendo
molto semplice il lavoro quotidiano del team di sviluppo, favorendo l’aggiornamento
del nuovo codice e offrendo la possibilità di dividerlo in più branch. Tale piattaforma
mette a disposizione spazi e strumenti per la gestione dei propri progetti di sviluppo.
Tra i vantaggi dell’utilizzo di Bitbucket c’è la possibilità di commentare il codice
sorgente, di visualizzare i branch per tenere sotto controllo i progressi del team e di
permettere allo stesso di collaborare per la fase di revisione del codice.
Bitbucket permette all’utente di usufruire dei servizi offerti da Git e Mercurial sfruttando tre differenti approcci: linea di comando, interfaccia web e software
desktop.
5.2 Problemi affrontati e scelte implementative effettuate
73
Il vantaggio di accedere a Bitbucket mediante interfaccia web è quello di realizzare l’editing dei file indipendentemente dal tipo di piattaforma utilizzata per
lo sviluppo e, quindi, apportare le modifiche tramite le operazioni di commit. In
Figura 5.2 è mostrata la dashboard di un progetto Bitbucket.
Figura 5.2. La dashboard di un progetto Bitbucket
5.2.1 Premessa: architettura del framework e librerie realizzate
Come accennato in precedenza, la componente client del sistema EnjoyRC è stata
realizzato tramite l’utilizzo del framework Supersonic di AppGyver. Ogni applicazione realizzata tramite questo specifico strumento deve rispettare una struttura
ben definita, all’interno della quale il codice stilato verrà eseguito. In Figura 5.3
viene mostrata l’architettura dei package del sistema in esame; al suo interno è
possibile osservare come l’organizzazione dei file HTML e JavaScript rispecchi il
pattern MVC e i vincoli imposti dal framework.
Risulta importante evidenziare i ruoli ricoperti dai file e dalle cartelle che compongono il progetto e come questi vengono interpretati dal framework. In questa
sezione ci soffermeremo ad osservare tutti gli aspetti di carattere generale non riguardanti la logica di business e descriveremo alcune delle librerie realizzate in fase
di sviluppo. Il package common (incluso nel package app) ricopre un ruolo di natura
trasversale in quanto, al suo interno, sono contenuti i file comuni a tutti i componenti dell’applicazione; alcuni di questi vengono forniti dal sistema, mentre altri
vengono generati ad-hoc per soddisfare specifiche richieste. Tale package contiene i
seguenti componenti:
74
Figura 5.3. L’architettura dei package del sistema EnjoyRC
•
•
•
•
•
•
assets: esso è fornito dal sistema e contiene tutte le immagini e le icone utilizzate
dall’applicazione.
js: esso è stato realizzato per contenere le librerie JavaScript utilizzate per
soddisfare esigenze comuni a più componenti, come la gestione delle mappe.
native-styles: esso è fornito dal sistema e contiene i fogli di stile specifici
delle piattaforme Android e iOS, grazie ai quali è possibile gestire il layout degli
oggetti grafici nativi.
services: esso è stato realizzato per contenere la libreria relativa ai servizi.
stylesheets: esso è fornito dal sistema e contiene i fogli di stile utilizzati per
gestire contemporaneamente il layout delle piattaforme Android e iOS.
views: esso è fornito dal sistema e contiene il file HMTL utilizzato per includere
tutti i componenti (fogli di stile e di scripting) utilizzati dal framework.
Un altro package che gestisce aspetti comuni all’applicazione è config. Esso
contiene due file CoffeeScript1 , denominati app.coffee e structure.coffee. All’interno di tali file sarà possibile impostare il nome dell’applicazione e decidere
quale view, tra quelle presenti, corrisponderà alla Home Page; allo stesso tempo
sarà possibile gestire le operazioni di scroll, definire le impostazioni del Drawer
Menù e abilitare o disabilitare le operazioni di “gesture recognizer”.
Il codice utilizzato per gestire queste operazioni è mostrato nei Listati 5.1 e 5.2.
1
2
3
4
1
# Read more about app configs at http://docs.appgyver.com
module.exports =
app:
CoffeeScript è un linguaggio di programmazione che transcompila in JavaScript.
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
75
name: "EnjoyRC"
# steroidsAppId and steroidsApiKey headers are required by Supersonic Data
# network:
# extraResponseHeaders:
#
"Access-Control-Allow-Origin": "*"
#
"Access-Control-Allow-Headers": "Content-Type, X-Requested-With, steroidsAppId, steroidsApiKey"
webView:
viewsIgnoreStatusBar: false
enableDoubleTapToFocus: false
disableOverscroll: true
enableViewportScale: false
enablePopGestureRecognition: true
allowInlineMediaPlayback: true
# Applies on iOS only
statusBar:
enabled: true
style: "default"
Listato 5.1. Il contenuto del File CoffeeScript app.coffee
1
2
3
4
5
6
7
8
9
10
11
module.exports =
rootView:
location: "home#index"
drawers:
left:
id: "leftDrawer"
location: "drawer#index"
showOnAppLoad: false
options:
button:""
Listato 5.2. Il contenuto del File CoffeeScript structure.coffee
Il package bower components include al suo interno tutte le librerie fornite dal
framework, che di base sono quelle relative ad AngulaJS, Steroids-js, Supersonic e
ai Web Component. Vi è la possibilità di integrare librerie di terze parti, tramite
l’utilizzo di “Bower”, uno strumento che permette di gestire tutte le dipendenze
web e di includerle all’interno di questo package.
Implementazione della libreria relativa alla consumazione dei servizi
web
Tra tutti i componenti citati, quello che ricopre un ruolo centrale per il sistema è
la libreria dei servizi. Essa è stata realizzata con lo scopo di inglobare all’interno
di un unico file, ovvero service.js, tutte le funzioni necessarie al recupero dei
dati dal server. Nello specifico, all’interno di questa libreria, sono presenti tutte
quelle operazioni necessarie al recupero della lingua utilizzata dal dispositivo, alla
memorizzazione del path assoluto del server, non che le operazioni che permettono
lo scambio di dati con lo stesso. Un approccio di questo tipo, che prevede la separazione delle competenze, permette di esonerare il controller dalla gestione della
comunicazione con il server, ottenendo un sistema più flessibile dal punto di vista
delle future implementazioni e manutenzioni. Ogni servizio implementato è un oggetto singleton, ovvero ne esisterà una sola istanza accessibile dagli altri componenti
Nel Listato 5.3 viene mostrato il codice necessario a prelevare la lingua del
dispositivo:
1
.service("getLanguage", function() {
76
2
3
this.lang = navigator.language.split(",");
})
Listato 5.3. Il service Angular getLanguage
Tramite l’istruzione Cordova navigator.language è stato possibile prelevare
la lingua attualmente utilizzata dal dispositivo. Essa è stata incapsulata all’interno
del servizio Angular getLanguage, il quale ha permesso a tutte quelle funzioni che
comunicano con il server di conoscere la lingua in cui dovranno essere restituiti i
dati.
Nel Listato 5.4 viene mostrato il codice necessario a memorizzare il path del
server.
1
2
3
.service("path",function(){
this.path_server="http://www.enjoyrc.unirc.it/";
})
Listato 5.4. Il service Angular path
Questi due tipi di servizi servono esclusivamente per lo scambio di dati tra le
funzionalità presenti in questa libreria. Per quanto riguarda invece i servizi utilizzati
per la consumazione delle API REST fornite dal server, se ne può osservare un
esempio nel Listato 5.5.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// servizio relativo alle voci di menu della Home Page//
.service("servicesHome", function(getLanguage,path,$http) {
var that = this;
this.items = [];
this.getItems = function() {
return $http.get(path.pathServer+’home/?language=’+getLanguage.lang)
.success(function (data) {
data.forEach(function(item){
that.items.push(item);
});
}).error(function(data){
alert("err");
console.log(’errore lettura servizio home’);
});
};
})
Listato 5.5. Il service Angular servicesHome
Questo servizio mostra le operazioni effettuate per recuperare le voci di menù
della Home Page. Attraverso un processo denominato “dependency injections”, vengono iniettati, all’interno dello stesso, i risultato dei servizi getLanguage, path e
$http. I primi due vengono utilizzati per la creazione dell’URL necessaria per effettuare la chiamata REST, mentre il terzo corrisponde a quel servizio predefinito per
effettuare chiamate AJAX in AngularJS. Quest’ultimo espone diversi metodi per le
chiamate HTTP. Tali metodi accettano come parametro l’URL da chiamare e restituiscono una “promise”, per poter gestire la risposta del server. Quella mostrata nel
Listato 5.5 è una delle tante chiamate GET presenti all’interno della libreria. Per
prima cosa abbiamo realizzato il caricamento dei dati esterni attraverso l’istruzione $http.get(path.pathServer+’home/?language=’+getLanguage.lang). Grazie alle promise success ed error, una volta che la chiamata REST ha restituito
un riscontro, viene indicata l’operazione da eseguire nel caso in cui questo sia positivo o meno. Nel caso di esito positivo i dati ricavati verranno inseriti all’interno
77
di un array. Nel caso di esito negativo verrà visualizzato un messaggio di errore. In
ogni caso, tale servizio restituirà il risultato delle sue operazioni tramite l’istruzione
return.
Implementazione della libreria relativa ai servizi di geolocalizzazione
Un ulteriore componente necessario per il funzionamento del sistema corrisponde
alla libreria dei servizi di geolocalizzazione. Tale componente è stato realizzato con
lo scopo di raggruppare tutte le funzionalità inerenti a questo contesto all’interno
di un unico file denominato map.js. Il loro compito è quello di fornire gli strumenti
necessari alla creazione di una mappa e al calcolo di un percorso.
Questo componente è stato implementato tramite l’utilizzo di JavaScript e di
API fornite da Google Map. In questo modo è stato possibile separare la logica di business da queste funzionalità di supporto, rendendo trasparente il loro
funzionamento a tutti i componenti che le utilizzano.
Nel Listato 6.15 viene mostrato il codice della funzione initMap utilizzata per
la creazione di una mappa.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
function initMap() {
directionsService = new google.maps.DirectionsService;
directionsDisplay = new google.maps.DirectionsRenderer;
map = new google.maps.Map(document.getElementById(’map’), {
zoom: 8,
center: {lat: 38.1038882, lng: 15.6336553}
});
directionsDisplay.setMap(map);
directionsDisplay.setPanel(document.getElementById(’right-panel’));
if(latitude_start!="" && longitude_start !="") {
calculateAndDisplayRoute(directionsService, directionsDisplay, ’DRIVING’);
}
}
Listato 5.6. La funzione initMap utilizzata per la creazione di una mappa
Tale funzione imposta gli attributi zoom e center dell’oggetto map ed effettua
un controllo sull’esistenza di un punto di partenza. In caso di riscontro positivo,
verrà richiamata la funzione calculateAndDisplayRoute, la cui implementazione
è mostrata nel Listato 5.7.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
function calculateAndDisplayRoute(directionsService, directionsDisplay, travelMode) {
var first_start; var first_end;
try{
if(latitude_start!="" && longitude_start !="" && document.getElementById(’start’).value =="Start") {
first_start = new google.maps.LatLng(latitude_start, longitude_start);
}else {
first_start = document.getElementById(’start’).value;
}if(latitude_end!="" && longitude_end!=""){
first_end=new google.maps.LatLng(latitude_end, longitude_end);
}else{
first_end=new google.maps.LatLng(38.1038882, 15.6336553);
}
}catch(err){
alert(err.message);
}
try{
directionsService.route({
origin: first_start,
destination:first_end,
travelMode: google.maps.TravelMode[travelMode]
}, function(response, status) {
if (status === google.maps.DirectionsStatus.OK) {
directionsDisplay.setDirections(response);
if(travelMode==’DRIVING’){
document.getElementById(’DRIVING’).className = "active";
document.getElementById(’WALKING’).className = "";
document.getElementById(’BICYCLING’).className = "";
document.getElementById(’TRANSIT’).className = "";
78
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
}else if(travelMode==’WALKING’){
document.getElementById(’DRIVING’).className =
document.getElementById(’WALKING’).className =
document.getElementById(’BICYCLING’).className
document.getElementById(’TRANSIT’).className =
}else if(travelMode==’BICYCLING’){
}else if(travelMode==’TRANSIT’){
}
"";
"active";
= "";
"";
"";
"";
= "active";
"";
"";
"";
= "";
"active";
}
});
}catch(err){
alert(err.message);
}
}
Listato 5.7. La funzione calculateAndDisplayRoute, utilizzata per il calcolo del percorso
verso il centro della città
Essa avrà il compito di calcolare il percorso tra il centro della mappa e un
punto di partenza, sia che questo corrisponda alla posizione del dispositivo, sia che
venga inserito manualmente dall’utente. Inoltre permetterà di gestire la modalità di
percorrenza. Nel Listato 5.8 è mostrata l’implementazione di una seconda funzione
per il calcolo di un percorso, considerando, questa volta, anche dei punti intermedi
all’interno dello stesso.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
function calculateAndDisplayRoute2(directionsService, directionsDisplay,lat_origigine, lng_origigine,
lat_destinazione, lng_destinazione, wp_array,flag) {
var waypts = [];
try{
for (var i = 0; i < wp_array.length; i++) {
var latlangwp =wp_array[i];
var latlangwp =latlangwp.split("|");
var lat_orig_wp= latlangwp[0]; var lng_orig_wp= latlangwp[1];
waypts.push({
location: new google.maps.LatLng(lat_orig_wp, lng_orig_wp),
stopover: true
});
}
}catch(err){
alert(err.message);
}
lat_orig= lat_origigine; lng_orig= lng_origigine;
lat_dest= lat_destinazione; lng_dest= lng_destinazione;
try{
var container_via_partenza = document.getElementById(’start_address’);
container_via_partenza.innerHTML = ’’;
}catch(err){
alert(err.message);
}
try{
origin: new google.maps.LatLng(lat_orig, lng_orig),
destination: new google.maps.LatLng(lat_dest, lng_dest),
waypoints: waypts,
optimizeWaypoints: true,
travelMode: google.maps.TravelMode.DRIVING
if (status === google.maps.DirectionsStatus.OK) {
var route = response.routes[0];
var start = route.legs[0].start_address;
var input = document.createElement("textarea");
input.maxLength = "100";
input.cols = "27";
input.rows = "2";
input.setAttribute("id", "textarea_start");
input.setAttribute("value", start);
input.setAttribute("readOnly", true);
container_via_partenza.appendChild(input);
document.getElementById("textarea_start").value=start;
if(flag==1){
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
79
var container_via_arrivo = document.getElementById(’end_address’);
container_via_arrivo.innerHTML = ’’;
var end = route.legs[0].end_address;
var input1 = document.createElement("textarea");
input1.maxLength = "100";
input1.cols = "25";
input1.rows = "2";
input1.setAttribute("id", "textarea_end");
input.setAttribute("value", end);
input1.setAttribute("readOnly", true);
container_via_arrivo.appendChild(input1);
document.getElementById("textarea_end").value=end;
}
} else {
window.alert(’Directions request failed due to ’ + status);
}
});
}catch(err){
alert(err.message);
}
}
Listato 5.8. La funzione calculateAndDisplayRoute2 utilizzata per il calcolo di una
percorso formato da più tratte
5.2.2 Implementazione del macro-blocco “Punti di interesse”
Questo macro-blocco, come accennato nei capitoli precedenti, permette ad un utente di visualizzare le informazioni relative ai punti di interesse distribuiti lungo il
territorio. L’utilizzatore potrà accedere a quest’area attraverso il menù presente
nella Home Page. Durante il caricamento di quest’ultima verrà eseguita la prima
comunicazione con il server, grazie alla quale verranno caricate le voci di menù. Una
volta selezionata la voce corrispondente ai punti di interesse, il sistema presenterà
la pagina contenente le categorie corrispondenti. Nel Listato 5.9 viene mostrato il
codice che permette di richiamare la pagina di primo livello appena citata.
1
2
3
4
5
6
7
<div ng-if="item.ordine!=7">
<super-navigate location="first_level#index" data-params-id="{{ item }}">
<img src="{{item.url_icona}}" class="img_circle" >
<p class="dimEtichetta"> {{item.nome}}
</p>
</super-navigate>
</div>
Listato 5.9. Il Web Component super-navigate di Supersonic
Il framework Supersonic permette di gestire il flusso di navigazione in maniera
nativa, creando uno stack di view per ogni determinato processo tramite l’utilizzo
del Web Component super-navigate. Esso definisce la struttura di navigazione dell’applicazione ed è formato da due attributi: location e data-params-id. Il primo
viene utilizzato per specificare la view di destinazione, che, nel nostro caso, risulta
essere index.html contenuta all’interno del package first level; il secondo, invece, gestisce lo scambio di dati con il livello successivo. In questo caso le informazioni
trasmesse corrispondono a quelle necessarie a conoscere il tipo di categorie da recuperare. Prima che la view di destinazione venga presentata, il framework elabora il
codice del controller ad essa associata. Tale codice è mostrato nel Listato 5.10.
1
2
3
4
5
6
angular
.module(’first_level’)
.controller(’IndexController’, function($scope,$http, servicesCategoriePoi,
servicesCategorieRistorazioni, servicesCategoriePernottamento,
servicesCategorieSvaghi, servicesCategoriePercorsi,
servicesTipiCategorie, servicesCategorieServiziByTipo) {
80
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
$scope.items = [];
supersonic.ui.views.current.params.onValue( function (values) {
$scope.item1 = values.id;
try{
$scope.item = JSON.parse($scope.item1);
}catch(err){
var options = {
message: err.message,
buttonLabel: "Chiudi"
};
supersonic.ui.dialog.alert("Successo", options).then(function() {
supersonic.logger.log("Alert closed.");
});
}
});
try{
$scope.destinazione="second_level#index";
if ($scope.item.ordine==1) {
if (!localStorage.servicesCategoriePoi) {
servicesCategoriePoi.getItems().then(function () {
$scope.items = servicesCategoriePoi.items;
localStorage.servicesCategoriePoi = JSON.stringify({
giorno: dd, mese: mm, anno: yyyy,
source: $scope.items
})
});
}else{
if (JSON.parse(localStorage.servicesCategoriePoi).giorno < dd &&
JSON.parse(localStorage.servicesCategoriePoi).mese == mm &&
JSON.parse(localStorage.servicesCategoriePoi).anno == yyyy) {
localStorage.removeItem("servicesCategoriePoi");
servicesCategoriePoi.getItems().then(function () {
$scope.items = servicesCategoriePoi.items;
localStorage.servicesCategoriePoi = JSON.stringify({
})
});
}else{
$scope.items= JSON.parse(localStorage.servicesCategoriePoi).source;
}
}
}
}catch(e){
alert(e.message);
}
});
Listato 5.10. Il controller della view relativa al primo livello di gerarchia dell’applicazione
La prima operazione effettuata dal controller è quella di recuperare i dati ricevuti
dalla view che lo ha richiamato, per poi convertirli in formato JSON e inserirli
all’interno dell’oggetto $scope. Nella terminologia di AngularJS uno “scope” indica
il contesto in cui vengono salvati i dati di un’applicazione (il model) ed in cui
vengono valutate le espressioni utilizzate nella view. Una volta terminata questa
fase, verrà verificato se i dati da visualizzare sono presenti in cache o dovranno
essere richiamati dal servizio. Tale operazione è effettuata tramite il controllo if
(!localStorage.servicesCategoriePoi).
Se la condizione di questa istruzione risulta verificata, allora verrà richiamato
il servizio relativo al recupero delle categorie, il cui codice è mostrato nel Listato
5.11, per poi memorizzarne il contenuto all’interno della cache.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
.service("servicesCategoriePoi", function(getLanguage,path,$http) {
var that = this;
this.items = [];
return $http.get(path.pathServer+’categorie-punti-di-interesse/?language=’+getLanguage.lang)
});
15
16
17
18
19
20
21
81
console.log(’errore categorie poi’);
});
};
})
Listato 5.11. Il codice relativo al servizio servicesCategoriePoi
Se la condizione dell’istruzione precedente non sarà verificata, ovvero il dato
richiesto è presente nella cache, verrà eseguito un ulteriore controllo per testare se
la data del suo inserimento è precedente alla data attuale. In questo caso esso verrà
eliminato e recuperato dal servizio; in caso contrario, esso verrà recuperato dalla
cache ed inserito nello scope.
Al termine di queste fasi di controllo e di configurazione, i dati recuperati
verranno visualizzati in una lista attraverso il codice mostrato nel Listato 5.12.
1
2
3
4
5
6
7
8
9
10
11
12
<div class="card" ng-repeat="categoria in items">
<super-navigate location="{{destinazione}}" data-params-id="{{categoria}}">
<div class="item item-text-wrap">
<div class="div_container_image">
<img src="{{categoria.url_icona}}" class="img_circle_dettagli" >
</div>
<div ng-hide="true">{{categoria.ordine=item.ordine}}</div>
</div>
</div>
</super-navigate>
</div>
Listato 5.12. Il codice relativo alla visualizzazione della lista delle categorie dei punti di
interesse
Grazie alla direttiva ng-repeat abbiamo generato un elenco di elementi HTML
a partire dalla collezione di dati items creata dal controller e messa a disposizione
della view, grazie all’oggetto $scope. A questo punto un utente potrà selezionare
una categoria per visualizzarne i punti associati. Questa operazione, come nel caso
precedente, è permessa grazie alla presenza del Web Component super-navigate.
Il processo di caricamento della view contenente i punti di interesse è simile a quello
descritto precedentemente: viene eseguito il codice relativo al controller della view
richiamata per poi visualizzare i dati recuperati in una lista. Nel Listato 5.13 viene
mostrato il codice relativo alla visualizzazione dei punti di interesse.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<div ng-repeat="punto in items">
<div ng-if="item.ordine!=4 && item.ordine!=’Tradizioni’ && item.ordine!=’Prodotti Tipici’">
<super-navigate location="third_level#index"data-params-id="{{punto}}">
<div class="item item-thumbnail-left">
<img src="{{item.url_image}}">
<h2>{{punto.nome}}</h2>
<p>{{punto.via}}</p>
<p ng-if="$scope.item.ordine==9">
<p>{{punto.sito}}</p>
</p>
<div ng-hide="true">{{punto.ordine=item.ordine}}</div>
</div>
</super-navigate>
</div>
</div>
Listato 5.13. Il codice relativo alla visualizzazione della lista dei punti di interesse
Come nel caso precedente, tale lista è realizzata grazie alla direttiva Angular
ng-repeat. Tramite la selezione degli elementi visualizzati da quest’ultima sarà
82
possibile accedere al dettaglio di un punto di interesse. Grazie all’utilizzo del Web
Component super-navigate, queste informazioni verranno inviate alla pagina di
dettaglio senza la necessità di consumare un nuovo servizio per recuperarli.
Nel Listato 5.14 viene mostrata una porzione di codice necessaria alla visualizzazione del dettaglio.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
<div class="list card">
<div class="item item-avatar">
<img src="{{icon}}">
<h2><strong>{{item.nome}}</strong></h2>
<p>{{item.via}}</p>
</div>
</div>
<div ng-if="item.ordine==9">
<h2 align="center"><strong>{{item.nome}}</strong></h2>
<p align="center">{{item.via}}</p>
</div>
<div class="item item-body">
<img class="full-image" src="{{item.url_image}}" >
<div class="padding">
<div class="div_servizi_affiancati" ng-repeat="service in services">
<i class="{{service.style}}"></i>
</div>
</div>
<p class="testo_giustificato">
{{item.descrizione}}
</p>
<div class="div_affiancati">
<a href="tel://{{item.recapito}}" class="coloro_testo_detaglio_elemento">{{item.recapito}}</a>
</div>
<div class="div_affiancati" ng-if="item.sito">
<a href="{{item.sito}}" class="coloro_testo_detaglio_elemento">Web Site</a>
</div>
<div ng-show="item.ordine==2 || item.ordine==3 || item.ordine==6" class="div_clear">
<ul class="list">
<li class="item">
<li class="item">
<i class="super-ios-circle-filled"></i>
Giorno Chiusua: <a href="#" class="subdued">{{item.giorno_chiusura}}</a>
</li>
<li class="item">
Orario Apertura: <a href="#" class="subdued">{{item.orario_apertura}}</a>
</li>
<li class="item">
Orario Chiusura: <a href="#" class="subdued">{{item.orario_chiusura}}</a>
</li>
<li class="item">
Prezzo Medio: <a href="#" class="subdued"> {{item.prezzo_medio}}</a>
</li>
<li class="item">
Numero Coperti: <a href="#" class="subdued">{{item.n_coperti}}</a>
</li>
</ul>
</div>
<div class="item">
<super-navigate location="map#index" data-params-id="{{item}}">
GO-TO
</super-navigate>
</div>
</div>
</div>
</div>
Listato 5.14. Il codice relativo alla visualizzazione del dettaglio di un punto di interesse
All’interno del codice mostrato in questo listato, è possibile identificare le direttive Angular ng-if, utilizzate per la visualizzazione condizionata di alcuni elementi del DOM HTML. A questo punto un utente, attraverso la selezione del tag
super-navigate, potrà accedere alla pagina contenente le informazioni di locazio-
83
ne del punto e le indicazioni stradali per raggiungerlo; queste verranno mostrate
tramite una mappa e alcuni contenuti testuali. Per realizzare quest’ultimo livello,
si è fatto uso della libreria relativa ai servizi geolocalizzazione citata in precedenza.
Il codice della view relativo a quest’ultima sezione è mostrato nel Listato 5.15.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
<div id="map"></div>
<input type="hidden" name="mode" id="mode" value="DRIVING">
<div>
<ul class="nav nav-tabs">
<li id="DRIVING" class="active">
<a href="#" onclick="setValue(’DRIVING’)">
<img src="/icons/car.svg" class="displayed">
</a>
</li>
<li id="WALKING">
<a href="#" onclick="setValue(’WALKING’)">
<img src="/icons/walk.svg" class="displayed">
</a>
</li>
<li id="BICYCLING">
<a href="#" onclick="setValue(’BICYCLING’)">
<img src="/icons/bicycle.svg" class="displayed">
</a>
</li>
<li id="TRANSIT">
<a href="#" onclick="setValue(’TRANSIT’)">
<img src="/icons/bus.svg" class="displayed">
</a>
</li>
</ul>
</div>
<div ng-controller="IndexController" class="padding-form-map">
<div class="list">
<a class="item item-icon-left" href="#" id="form-color-id">
<i class="icon super-gear-a"></i>
<input type="text" id="start" onchange="calcRouteByCar();" value="Start"
onclick="clearvalue()" class="form-color">
</a>
</div>
<div ng-if="make==true">
{{getPosition()}}
</div>
</div>
<div id="right-panel" ></div>
<script type="text/javascript" src="https://code.jquery.com/jquery-2.1.1.min.js"></script>
<script src="https://maps.googleapis.com/maps/api/js?key=AIzaSyCBEhcmPPw2-zcQYyzSroeXglMLtEyRlw&signed_in=true&callback=initMap"r></script>
Listato 5.15. Il codice relativo alla visualizzazione della lista dei punti di interesse
Attraverso il tag <ul class="nav nav-tabs"> viene visualizzata la lista delle
modalità di percorrenza della tratta creata. Infine, sarà anche presente un form per
l’inserimento di un nuovo punto di partenza, realizzato tramite l’istruzione <input
type="text" id="start" onchange="calcRouteByCar();" value="Start" onclick="clearvalue()" class="form-color">. Grazie alla presenza dell’attributo onchange del tag input, verrà catturato l’evento relativo alla compilazione di
tale form e verrà richiamata la funzione calcRouteByCar fornita dalla libreria dei
servizi di geolocalizzazione. Il codice relativo a tale funzione è mostrato nel Listato
5.16.
1
2
3
function calcRouteByCar(){
calculateAndDisplayRoute(directionsService, directionsDisplay, "DRIVING");
}
Listato 5.16. Il codice relativo alla funzione calcRouteByCar
All’interno del codice relativo a tale funzione verrà richiamata la funzione necessaria al calcolo di un tragitto vincolando l’utilizzo di un mezzo privato come
modalità di percorrenza.
84
5.2.3 Implementazione del macro-blocco “La città”
Questo macro-blocco, come descritto nei capitoli precedenti, permetterà ad un utente di accedere alle informazioni di natura generale riguardanti la città. L’utilizzatore
potrà accedervi tramite il menù presente nella pagina principale dell’applicazione.
Il punto di partenza di quest’area si presenta come una seconda Home Page formata
da un menù di accesso ai contenuti avente una struttura a tile. Il codice utilizzato
per la realizzazione della view corrispondente a tale sezione è mostrato nel Listato
5.17.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
<div ng-controller="IndexController">
<super-navbar>
<super-navbar-title>
{{item.nome}}
</super-navbar-title>
</super-navbar>
<img class="img_header" src="{{item.url_image}}">
<div class="padding_citta_header"/>
<div class="card" >
<div class="item item-text-wrap">
<div class="altezza_descrizione">
{{info_citta[0].descrizione}}
</div>
<a href="#" ng-click="present_dialog()">
<i class="icon super-more"></i>
</a>
</div>
</div>
<div class="row margin_container_la_citta">
<div class="col margin_container_la_citta">
<div class="card margin_container_la_citta" >
<img class="immagine_opaca" src="{{voci_menu[0].url_image}}">
<div class="dim_tex_button">
{{voci_menu[0].nome}}
</div>
</div>
</super-navigate>
</div>
<super-navigate location="come_visitarla#index" data-params-id="{{info_citta[0]}}">
<div class="card margin_container_la_citta">
</div>
</div>
</super-navigate>
</div>
</div>
<div class="row margin_container_la_citta">
<super-navigate location="second_level#index" data-params-id="{{item_second_view1}}">
</div>
</div>
<div ng-hide="true">{{item_second_view1.nome=voci_menu[2].nome}}</div>
<div ng-hide="true">{{item_second_view1.ordine=’Prodotti Tipici’}}</div>
<div ng-hide="true">{{item_second_view1.url_image=voci_menu[2].url_image}}</div>
</super-navigate>
</div>
<super-navigate location="second_level#index" data-params-id="{{item_second_view2}}">
</div>
</div>
76
77
78
79
80
81
82
83
84
85
<div ng-hide="true">{{item_second_view2.nome=voci_menu[3].nome}}</div>
<div ng-hide="true">{{item_second_view2.ordine=’Tradizioni’}}</div>
<div ng-hide="true">{{item_second_view2.url_image=voci_menu[3].url_image}}</div>
</super-navigate>
</div>
</div>
</div>
Listato 5.17. Il codice utilizzato per la creazione della Home Page relativa al macro-blocco
“La città”
Il codice relativo al controller di tale view e mostrato nel Listato 5.18.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
angular
.module(’citta’)
.controller(’IndexController’, function($scope, $http,supersonic, servicesInfoCitta, servicesMenuCitta) {
var today = new Date();
var dd = today.getDate(); var mm = today.getMonth()+1; var yyyy = today.getFullYear();
try{
}catch(err){
var options = {
};
});
}
});
if (!localStorage.servicesInfoCitta) {
servicesInfoCitta.getItems().then(function () {
$scope.info_citta = servicesInfoCitta.items;
localStorage.servicesInfoCitta = JSON.stringify({
giorno: dd,
mese: mm,
anno: yyyy,
source: $scope.info_citta
})
});
}else{
if (JSON.parse(localStorage.servicesInfoCitta).giorno < dd &&
JSON.parse(localStorage.servicesInfoCitta).mese == mm &&
JSON.parse(localStorage.servicesInfoCitta).anno == yyyy) {
localStorage.removeItem("servicesInfoCitta");
servicesInfoCitta.getItems().then(function () {
$scope.info_citta = servicesInfoCitta.items;
localStorage.servicesInfoCitta = JSON.stringify({
giorno: dd,
mese: mm,
anno: yyyy,
source: $scope.info_citta
})
});
}else{
$scope.info_citta= JSON.parse(localStorage.servicesInfoCitta).source;
}
}
if (!localStorage.servicesMenuCitta) {
servicesMenuCitta.getItems().then(function () {
$scope.voci_menu = servicesMenuCitta.items;
localStorage.servicesMenuCitta = JSON.stringify({
giorno: dd,
mese: mm,
anno: yyyy,
source: $scope.voci_menu
})
});
}else{
if (JSON.parse(localStorage.servicesMenuCitta).giorno < dd &&
JSON.parse(localStorage.servicesMenuCitta).mese == mm &&
JSON.parse(localStorage.servicesMenuCitta).anno == yyyy) {
localStorage.removeItem("servicesMenuCitta");
servicesMenuCitta.getItems().then(function () {
$scope.voci_menu = servicesMenuCitta.items;
localStorage.servicesMenuCitta = JSON.stringify({
giorno: dd,
mese: mm,
anno: yyyy,
source: $scope.voci_menu
})
});
86
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
}else{
$scope.voci_menu= JSON.parse(localStorage.servicesMenuCitta).source;
}
}
$scope.present_dialog = function() {
var options = {
message: $scope.info_citta[0].descrizione,
buttonLabels: ["Close"]
};
supersonic.ui.dialog.confirm("La città", options).then(function(index) {
});
};
supersonic.device.geolocation.getPosition().then( function(position) {
$scope.item.position_dev_lat=position.coords.latitude;
$scope.item.position_dev_long=position.coords.longitude;
});
$scope.item.latitudine=38.1084741;
$scope.item.longitudine=15.6441848;
});
Listato 5.18. Il codice relativo al controller associato alla view della Home Page del
macro-blocco “La città”
Il codice descritto nei Listati 5.17 e 5.18 segue una serie di passi logici per creare
la struttura precedentemente citata. In particolare, esso:
•
•
•
•
Interpreta i dati ricevuti dalla view che lo ha richiamato.
Effettua un controllo sulla cache con lo scopo di verificare se i dati da visualizzare
siano gia stati prelevati o meno:
– in caso di riscontro negativo, richiama i servizi corrispondenti e inserisce i
dati prelevati all’interno dello scope e della memoria locale;
– in caso di riscontro positivo, inserisce i dati all’interno dello scope prelevandoli dalla cache.
Se il GPS del dispositivo è attivo, preleva le coordinate della posizione corrente
e le memorizza all’interno dello scope.
Permette alla view di accedere al modello dei dati tramite il controller e crea la
struttura per la loro visualizzazione.
Per la realizzazione delle altre pagine che compongono questa sezione il codice
prodotto è analogo a quello visto finora; per tale ragione si è ritenuto opportuno
non descriverlo in dettaglio.
6
Progettazione e implementazione dei percorsi
tematici
Questo capitolo fornisce una descrizione dettagliata delle fasi di progettazione e
implementazione riguardanti il macro-blocco dei percorsi turistici tematici. Verranno prese in considerazione la progettazione della componente applicativa nonchè
l’implementazione delle funzionalità riguardante la componenti client-side e quella
server-side.
Come descritto nei capitoli precedenti, la fase di progettazione della componente
applicativa, riguardante il macro-blocco dei percorsi turistici tematici, ha previsto l’utilizzo di UML come meta-modello. In questa sezione descriveremo tale fase
facendo riferimento ai seguenti diagrammi UML:
•
•
•
diagrammi dei casi d’uso;
diagrammi di attività;
diagrammi di sequenza.
Diagramma dei casi d’uso relativo alla sezione “Percorsi turistici”
“Percorsi turistici”. Esso raggruppa quell’insieme di funzionalità che consentono la
navigazione all’interno di questa sezione e l’amministrazione dei contenuti ad essa
associata. La differenza sostanziale tra il diagramma visualizzato in questa figura
e quelli descritti nei capitoli precedenti riguarda la presenza di un nuovo attore
raffigurante l’amministratore del sistema.
I casi d’uso con cui esso interagisce rappresentano quelli relativi all’amministrazione di un percorso turistico, gestita tramite la componente back-end. L’amministratore, infatti, potrà creare, visualizzare, modificare ed eliminare sia un percorso
turistico che un waypoint (quest’ultimo utilizzato per la creazione delle varie tratte).
I casi d’uso con cui interagisce l’attore “utente” riguardano la navigazione all’interno di quest’area attraverso la componente client-side del sistema. Nello specifico,
l’utente potrà visualizzare le categorie a cui è associato almeno un percorso turistico, la lista dei percorsi di ogni categoria, il loro dettaglio, il dettaglio di ogni singola
88
6 Progettazione e implementazione dei percorsi tematici
tratta di cui essi si compongono e la mappa che indica come raggiungere il punto
di partenza.
Figura 6.1. Il diagramma dei casi d’uso relativo al macro-blocco “Percorsi turistici”
Diagrammi di attività
Diagramma di attività “Visualizza percorsi turistici”
In Figura 6.2 viene mostrato il diagramma di attività riguardante la navigazione
all’interno del macro-blocco “Percorsi turistici”, associato alla componente clientside del sistema. Il flusso parte dal nodo di controllo iniziale, denominato Start, e
si dirige verso il nodo Preleva categorie percorsi turistici che richiama un
comportamento più complesso. Una volta terminata quest’attività, il flusso riparte e si dirige verso l’attività relativa alla visualizzazione dei risultati ottenuti. A
questo punto l’utente può scegliere di terminare l’attività oppure di visualizzare i
percorsi turistici associati ad una determinata categoria. In quest’ultimo caso il flusso si sposta nel nodo azione Preleva percorsi della categoria selezionata.
Esso rappresenta la chiamata all’attività che avrà il compito di consumare i servizi
necessari al recupero delle informazioni richieste.
89
Una volta recuperata la lista dei percorsi turistici, il flusso si sposta nel nodo
che avrà il compito di visualizzarla. Giunto a questo punto, l’utente potrà scegliere
se terminare il flusso di lavoro o se visualizzare il dettaglio di un percorso. In quest’ultimo caso, il flusso verrà indirizzato nel nodo deputato a mostrare in dettaglio
il contenuto selezionato. Infine, l’utente potrà decidere di spostare il flusso in uno
dei seguenti tre nodi:
•
•
•
il nodo di controllo denominato End, con il quale l’attività generale sarà terminata;
il nodo deputato a visualizzare la mappa in cui è indicato come raggiungere il
punto di partenza;
il nodo deputato a mostrare il dettaglio di una tratta del percorso.
Figura 6.2. Il diagramma di attività riguardante la navigazione all’interno del macroblocco “Percorsi turistici”
In Figura 6.3 viene rappresentata la macro-attività PrelevaCategoriePercorsi.
Il suo flusso parte dal nodo di controllo Start per poi verificare la presenza di una
90
connessione alla rete. In caso di riscontro negativo, l’attività termina. In caso contrario, invece, il flusso si sposta nel nodo che rappresenta l’invio della richiesta HTTP
per recuperare le informazioni memorizzate sul server. A questo punto, il flusso si
dirige verso quelle attività che rappresentano le operazioni effettuate dal server per
interpretare la richiesta, prelevare le categorie ed esporre i dati ricavati. Una volta
che questi saranno elaborati, il flusso termina nel nodo di controllo End.
Figura 6.3. Il diagramma di attività relativo al recupero delle categorie dei percorsi
turistici
Diagramma di attività “Crea percorso turistico”
In Figura 6.4 viene mostrato il diagramma di attività relativo alla creazione di un
percorso. L’attività parte dal nodo di controllo iniziale, denominato Start, e si dirige
verso il nodo di biforcazione (fork). Quest’ultimo duplica i token in ingresso sulle
91
uscite per parallelizzare due flussi di lavoro corrispondenti alle attività Seleziona
categoria percorso e Inserisci info percorso. Esse si dirigono verso un nodo
ricongiunzione (join). Quest’ultimo farà partire il flusso in uscita solo quando le due
attività arriveranno al suo ingresso. Tale flusso attraverserà il nodo di fusione Merge
per dirigersi verso un nuovo nodo di ricongiunzione. Da quest’ultimo partiranno
tre attività le quali rappresentano, rispettivamente, l’inserimento di un punto di
partenza, di un insieme di punti intermedi e di un punto di arrivo.
Il loro flusso si dirigerà verso un nodo di fusione per poi spostarsi in quello
avente il compito di verificare l’esistenza su mappa dei punti selezionati. Nel caso
in cui essi non formino un itinerario fisicamente percorribile, il flusso tornerà nel
nodo di Merge per permettere di ripetere la loro selezione. In caso contrario, il
flusso si sposterà nel nodo loop Inserisci descrizioni tratte che rappresenta
l’operazione di inserimento di una descrizione per ogni tratta. Una volta terminato
il ciclo, il flusso si sposterà sull’ultima attività, avente il compito di confermare i
dati inseriti, per poi dirigersi verso nodo di controllo End.
Diagrammi di sequenza
Diagrammi di sequenza “Visualizza percorsi turistici”
In Figura 6.5 viene mostrato il diagramma di sequenza relativo al macro-blocco
“Percorsi turistici”. Tale diagramma mostra le interazioni tra i vari oggetti coinvolti
nel processo di navigazione.
Il flusso temporale parte nel momento in cui l’utente richiede di visualizzare le
categorie inerenti a quest’area. Tale richiesta è indirizzata alla componente mobile
del sistema, la quale, prima di procedere con il recupero delle informazioni, verifica
la presenza di una connessione alla rete Internet. In caso di esito negativo, essa ne
comunicherà l’assenza all’utente. In caso contrario, invece, essa invierà una richiesta
al Web service provider per recuperare le categorie richieste.
Il Web services provider interagirà con il DBMS sottostante per recuperare le informazioni necessarie a soddisfare la richiesta. Tale fase è rappresentata
da un secondo diagramma di attività, denominato Ricerca categorie percorsi
turistici, che, per brevità, non descriveremo in dettaglio; quest’ultimo diagramma
sarà incluso nel primo tramite l’utilizzo di un ref.
Una volta recuperate le informazioni riguardanti la tassonomia dei percorsi turistici, queste ultime, tramite una scambio di messaggi, verranno inviate alla componente mobile per poi essere visualizzate. A questo punto, se l’utente seleziona una
categoria, la componente mobile, dopo aver verificato la presenza di una connessione, contatterà il Web service provider per recuperare tutti i percorsi turistici
inerenti al contesto scelto.
Anche in questo caso il Web service provider, per recuperare le informazioni
richieste, dovrà interagire con il DBMS sottostante. Tale azione è rappresentata
dal diagramma di sequenza Ricerca percorsi turistici (che, per brevità, non
descriviamo in dettaglio), incluso tramite l’utilizzo di un ref. Le informazioni, recuperate tramite uno scambio di messaggi, verranno inviate alla componente mobile
per poi essere visualizzate. A questo punto, l’utente potrà richiedere alla componente mobile di visualizzare il dettaglio di un percorso. La componente mobile, dopo
92
Figura 6.4. Il diagramma di attività relativo al recupero delle categorie dei percorsi
turistici
93
Figura 6.5. Il diagramma di sequenza riguardante la navigazione all’interno del macroblocco “Percorsi turistici”
94
aver elaborato i dati del contenuto richiesto, procederà con la loro visualizzazione.
Infine, l’utilizzatore potrà decidere di visualizzare il dettaglio di una tratta, oppure una mappa per conoscere le informazioni necessarie a raggiungere il punto di
partenza.
Diagrammi di sequenza “Crea percorso turistico”
In Figura 6.6 viene mostrato il diagramma di sequenza relativo alla creazione di
un percorso. Tale diagramma mostra le interazioni tra i vari oggetti coinvolti nel
processo di creazione. Dal momento che queste operazioni verranno gestite lato
back-end, le entità e gli attori coinvolti in questo diagramma saranno differenti
rispetto a quelli presenti nei diagrammi precedentemente descritti.
Il flusso temporale parte nel momento in cui l’amministratore decide di creare un nuovo percorso turistico; in questo caso, egli invia una richiesta alla Web
application, la quale risponderà fornendo le informazioni riguardanti le categorie
a disposizione. L’attore, a questo punto, comunicherà la categoria scelta e le informazioni di natura generale riguardanti il percorso. Una volta terminata questa fase,
la Web application visualizzerà una mappa per permettere all’amministratore di
comporre il percorso, consentendogli di scegliere il numero di tratte.
Se queste ultime non saranno fisicamente percorribili, allora verrà ripetuto il
processo relativo al loro inserimento. In caso contrario la Web application verificherà, per ogni tratta selezionata, se essa sia stata gia scelta in precedenza per far
parte di altri percorsi. In caso affermativo, il sistema preleverà le sue informazioni;
in caso negativo, invece, il sistema permetterà all’amministratore di associare una
descrizione. Infine, l’amministratore invierà una richiesta alla Web application per
confermare l’inserimento del nuovo percorso.
6.2 Implementazione delle funzionalità lato client
La componente client-side di questo macro-blocco permette ad un utente di visualizzare le informazioni riguardanti i percorsi turistici offerti dalla città. L’utilizzatore
potrà accedere a quest’area attraverso il menù presente nella Home Page. Come
descritto nei capitoli precedenti, per recuperare le informazioni utili alla creazione
di quest’ultima, si è utilizzata una funzione fornita dalla libreria dei servizi, grazie
alla quale è stato possibile recuperare i dati relativi alle voci di menù.
Per richiamare la pagina contenente le categorie dei percorsi turistici, corrispondente al primo livello della gerarchia di view, il framework sfrutta il web component
super-navigate, presentato in questo caso sotto forma di un pulsante circolare.
Prima che la view corrispondente a tale livello venga presentata, verrà interpretato
il codice relativo al suo controller.
Esso permetterà di recuperare il modello dei dati e di inserirlo all’interno dell’oggetto $scope. Questa operazione è stata implementata attraverso il codice mostrato
nel Listato 6.1.
1
2
3
4
5
if (!localStorage.servicesCategoriePercorsi) {
servicesCategoriePercorsi.getItems().then(function () {
$scope.items = servicesCategoriePercorsi.items;
localStorage.servicesCategoriePercorsi = JSON.stringify({
Figura 6.6. Il diagramma di sequenza relativo alla creazione di un percorso
95
96
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
})
});
}else{
if (JSON.parse(localStorage.servicesCategoriePercorsi).giorno < dd &&
JSON.parse(localStorage.servicesCategoriePercorsi).mese == mm &&
JSON.parse(localStorage.servicesCategoriePercorsi).anno == yyyy) {
localStorage.removeItem("servicesCategoriePercorsi");
servicesCategoriePercorsi.getItems().then(function () {
$scope.items = servicesCategoriePercorsi.items;
localStorage.servicesCategoriePercorsi = JSON.stringify({
})
});
}else{
$scope.items= JSON.parse(localStorage.servicesCategoriePercorsi).source;
}
}
Listato 6.1. Il codice relativo al recupero delle categorie dei percorsi memorizzati
all’interno del sistema
Per prima cosa, il controller verifica se i dati relativi alla categorie da visualizzare siano presenti nella memoria locale. In caso contrario, esso richiama il servizio
specifico per recuperare tali dati dal server. Nel caso in cui le categorie siano già
state prelevate in precedenza, il controller verifica se la data del loro inserimento precede quella attuale. In caso affermativo le categorie verranno recuperate dal
server e reinserite nella memoria cache. L’operazione necessaria al recupero delle
categorie dal server è stata implementata tramite il codice riportato nel Listato 6.2.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
.service("servicesCategoriePercorsi", function(getLanguage,path,$http) {
var that = this;
this.items = [];
return $http.get(path.pathServer+’categorie-percorsi/?language=’+getLanguage.lang)
});
console.log(’errore servicesCategoriePercorsi’);
});
};
})
Listato 6.2. Il codice relativo al servizio servicesCategoriePercorsi
Quest’ultimo compone l’URL utilizzata per effettuare la chiamata REST e consuma il servizio dispensato dal server, recuperando, cosı̀, i dati richiesti. A questo
punto, un utente potrà selezionare una categoria per visualizzarne i percorsi associati. Il processo utilizzato per il recupero di questi ultimi è del tutto analogo a
quello utilizzato per il recupero delle categorie. Una volta recuperate le informazioni
relative alla lista dei percorsi, l’utente potrà accedere al dettaglio di ogni singolo
contenuto. Come nei casi precedenti, prima che la view venga presentata, il framework elabora il codice del controller ad essa associata. Tale codice è mostrato nel
Listato 6.3.
1
2
3
4
5
6
7
8
9
10
11
angular
.module(’percorsi_third_level’)
.controller(’IndexController’, function($scope, supersonic) {
try{
}catch(err){
var options = {
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
97
};
});
}
});
waypoints=[];
var coordinate_partenza = $scope.item.archi[0].posizione_partenza.split("|");
var coordinate_arrivo = $scope.item.archi[$scope.item.archi.length-1].posizione_arrivo.
split("|");
$scope.latitudine_partenza=coordinate_partenza[0];
$scope.longitudine_partenza=coordinate_partenza[1];
var latitudine_arrivo=coordinate_arrivo[0];
var longitudine_arrivo=coordinate_arrivo[1];
for(var j=0;j<$scope.item.archi.length;j++) {
if(j!=$scope.item.archi.length-1){
waypoints.push($scope.item.archi[j].posizione_arrivo);
}
}
supersonic.device.geolocation.getPosition().then( function(position) {
$scope.item.position_dev_lat=position.coords.latitude;
scope.item.position_dev_long=position.coords.longitude;
});
calculate_route_percorso($scope.latitudine_partenza, $scope.longitudine_partenza,
latitudine_arrivo, longitudine_arrivo, waypoints,0);
});
Listato 6.3. Il codice relativo al controller della pagina di dettaglio di un percorso turistico
La prima operazione effettuata dal controller è quella di recuperare i dati ricevuti
dalla view che lo ha richiamato. Tali dati, una volta interpretati, corrisponderanno
ad un oggetto JSON raffigurante il percorso di cui si vuole visualizzare il dettaglio.
Dopo di ciò, il punto di partenza e di arrivo del percorso verranno inseriti all’interno
dello scope per poi ricavare un vettore di waypoint. Infine, una volta ricavati i dati
necessari, verrà richiamata la funzione calculate route percorso appartenente
alla libreria dei servizi di geolocalizzazione, con lo scopo di raffigurare il percorso.
Al termine di questa chiamata, verrà mostrata la view in questione, il cui codice
viene mostrato nel Listato 6.4.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
<div ng-controller="IndexController" class="padding-form-map">
<div class="padding">
<div class="button-bar">
<div ng-repeat="arco in item.archi" >
<div class="div_elenco_tratte_affiancate">
<super-navigate location="percorsi_fourth_level#index" data-params-id="{{arco}}">
<span class="button button-positive padding_icon_text" ng-if="$index==0">
A-B
<div ng-hide="true">{{arco.numero="A-B"}}</div>
</span>
B-C
<div ng-hide="true">{{arco.numero="B-C"}}</div>
</span>
C-D
<div ng-hide="true">{{arco.numero="C-D"}}</div>
</span>
D-E
<div ng-hide="true">{{arco.numero="D-E"}}</div>
</span>
E-F
<div ng-hide="true">{{arco.numero="E-F"}}</div>
</span>
F-G
<div ng-hide="true">{{arco.numero="F-G"}}</div>
</span>
</super-navigate>
</div>
</div>
</div>
</div>
<div ng-hide="true">{{item.latitudine=latitudine_partenza}}</div>
<div ng-hide="true">{{item.longitudine=longitudine_partenza}}</div>
98
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
<div class="list card">
<img src="/icons/goto.svg">
<p><strong>GO-TO START</strong></p>
<h2><div id="start_address"/></h2>
</super-navigate>
</div>
<div class="div_clear">
<a href="#" class="subdued">
<div class="testo_giustificato">
<h2><strong>{{item.nome}}</strong></h2>
{{item.descrizione}}
<br/>
</div>
</a>
</div>
</div>
</div>
</div>
</div>
<script type="text/javascript" src="js/materialize.min.js"></script>
<style>
#map {
height: 50%;
}
</style>
Listato 6.4. Il codice relativo alla pagina di dettaglio di un percorso turistico
L’istruzione <div id="map"></div> del presente listato permetterà di inserire
la raffigurazione del percorso come intestazione della pagina; a seguire, verranno
illustrate tutte le informazioni che lo riguardano. Tra queste, sono presenti anche le
tratte di cui il percorso in questione è composto. Esse sono rappresentate tramite una
lista realizzata attraverso l’istruzione <div ng-repeat="arco in item.archi">.
Ogni elemento di questa lista, fornirà l’accesso ad una specifica area, che conterrà
il dettaglio della rispettiva tratta selezionata. Il codice della view di tale dettaglio
è mostrato nel Listato 6.5:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
<div ng-controller="IndexController">
<img src="/icons/tratta.jpg" class="bordo_cerchio_icona">
<div class="row">
<div class="col">{{arco.numero}}</div>
<div class="col">{{arco.durata}}</div>
</div>
</div>
<i class="icon super-location dim_piker_punto">
<div class="piker_punto_partenza">{{partenza}}</div>
</i>
<div id="start_address"/>
</div>
</div>
</div>
<i class="icon super-location dim_piker_punto">
<div class="piker_punto_arrivo">{{arrivo}}</div>
</i>
<div id="end_address"/>
</div>
{{arco.descrizione}}
</div>
</div>
</div>
6.3 Implementazione delle funzionalità lato server
38
39
40
41
42
43
44
45
46
<script type="text/javascript" src="js/materialize.min.js"></script>
<style>
#map {
height: 50%;
}
</style>
99
Listato 6.5. Il codice relativo alla pagina di dettaglio di una tratta associata ad un
percorso turistico
Il codice del controller associato a questa view è descritto nel Listato 6.6.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
angular
.module(’percorsi_fourth_level’)
.controller(’IndexController’, function($scope, supersonic) {
try{
$scope.arco = JSON.parse($scope.item1);
}catch(err){
var options = {
};
});
}
});
var numero=$scope.arco.numero;
numero=numero.split("-");
$scope.partenza=numero[0];
$scope.arrivo=numero[1];
try{
waypoints=[];
var coordinate_partenza = $scope.arco.posizione_partenza.split("|");
$scope.latitudine_partenza=coordinate_partenza[0];
$scope.longitudine_partenza=coordinate_partenza[1];
var coordinate_arrivo = $scope.arco.posizione_arrivo.split("|");
$scope.latitudine_arrivo=coordinate_arrivo[0];
$scope.longitudine_arrivo=coordinate_arrivo[1];
}catch(err){
alert(err.message);
}
calculate_route_percorso($scope.latitudine_partenza, $scope.longitudine_partenza,
$scope.latitudine_arrivo, $scope.longitudine_arrivo,
waypoints,1);
});
Listato 6.6. Il codice relativo al controller associato alla view del dettaglio di una tratta
Grazie al codice mostrato in questi due listati, sarà possibile visualizzare la
rappresentazione grafica della tratta e le informazioni che la riguardano. Infine,
verrà offerta la possibilità di accedere alla pagina che conterrà le informazioni utili
a raggiungere il punto di partenza del percorso.
In questa sezione, verrà descritta l’implementazione di alcune delle funzionalità che
hanno permesso di realizzare quella componente di back-end in grado di gestire i
contenuti riguardanti i percorsi turistici. La stesura di tali funzionalità ha previsto
la realizzazione dei seguenti file, scritti nei linguaggi PHP e JavaScript.
•
function percorsi turistici statici.php;
100
•
•
•
•
•
•
•
•
functions way point.php;
functions arco.php;
inserisci way point.php;
inserisci percorso turistico statico.php;
support percorsi.js;
categorie percorsi json.php;
verifica esistenza arco json.php;
percorsi by categoria json.php;
Nello specifico, essi ci permetteranno di gestire l’inserimento di un percorso e di
un waypoint.
6.3.1 Implementazione della funzionalità relativa all’inserimento di un
waypoint
Nel Listato 6.7 viene mostrato il contenuto del file inserisci way point.php
rappresentante la pagina di inserimento di un waypoint.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?php
get_header();
?>
<form action="" method="post" onsubmit="return false" name="form_ins_wp">
<div id="coordinate_div"></div>
<?php if(isset($_POST[’way_point’])&&isset($_POST[’coordinate’])){
inserisci_way_point($_POST[’way_point’],$_POST[’coordinate’]);
$_POST[’way_point’] = array();
}
print_form_inserisci_way_point();
?>
</form>
Listato 6.7. Il contenuto del file inserisci way point.php
All’interno del tag form è presente la funzione print form inserisci way point,
la quale verrà richiamata al momento del caricamento della pagina. Essa avrà il compito di effettuare il rendering del form relativo all’inserimento di un waypoint. Il
codice di tale funzione è mostrato nel Listato 6.8.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
function print_form_inserisci_way_point(){
?>
<h1 align="center">Inserisci WayPoint</h1>
<div class="cotainer_block_map_wp">
<input id="pac-input" class="controls" type="text" placeholder="Enter a location" name="way_point"
onchange="hidde_button()">
</div>
<div class="cotainer_block_map_wp">
<input type="hidden" id="button-hidden" value="Inserisci WayPoint" onclick="document.form_ins_wp.submit()">
</div>
<?php
}
?>
Listato 6.8. Il codice della funzione print form inserisci way point
Tale funzione fa uso delle funzioni JavaScript mostrate nel Listato 6.9.
1
2
function hidde_button(){
var button_hidden = document.getElementById(’button-hidden’);
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
101
button_hidden.type=’hidden’;
}
var mapOpt = {
center:new google.maps.LatLng(38.0978092,15.5313428),
zoom:10,
mapTypeId:google.maps.MapTypeId.ROADMAP
};
map=new google.maps.Map(document.getElementById("map"),mapOpt);
var myLatLng = ’’;
var marker = new google.maps.Marker({
position: myLatLng,
map: map,
title: ’Hello World!’
});
var input = (document.getElementById(’pac-input’));
var types = document.getElementById(’type-selector’);
map.controls[google.maps.ControlPosition.TOP_LEFT].push(input);
map.controls[google.maps.ControlPosition.TOP_LEFT].push(types);
var autocomplete = new google.maps.places.Autocomplete(input);
autocomplete.bindTo(’bounds’, map);
var infowindow = new google.maps.InfoWindow();
var marker = new google.maps.Marker({
map: map,
anchorPoint: new google.maps.Point(0, -29)
});
autocomplete.addListener(’place_changed’, function() {
infowindow.close();
marker.setVisible(false);
var place = autocomplete.getPlace();
if (place.geometry.viewport) {
button_hidden.type=’button’;
map.fitBounds(place.geometry.viewport);
} else {
button_hidden.type=’button’;
map.setCenter(place.geometry.location);
map.setZoom(17);
}
marker.setIcon(({
url: place.icon,
size: new google.maps.Size(71, 71),
origin: new google.maps.Point(0, 0),
anchor: new google.maps.Point(17, 34),
scaledSize: new google.maps.Size(35, 35)
}));
marker.setPosition(place.geometry.location);
marker.setVisible(true);
var coordinateDiv = document.getElementById(’coordinate_div’);
coordinateDiv.innerHTML = ’’;
var coordinate = document.createElement("input");
coordinate.type = "hidden";
coordinate.setAttribute("name", "coordinate");
coordinate.setAttribute("value", map.getCenter());
coordinateDiv.appendChild(coordinate);
var address = ’’;
if (place.address_components) {
address = [
(place.address_components[0] && place.address_components[0].short_name || ’’),
(place.address_components[1] && place.address_components[1].short_name || ’’),
(place.address_components[2] && place.address_components[2].short_name || ’’)
].join(’ ’);
}
infowindow.setContent(’<div><strong>’ + place.name + ’</strong><br>’ + address);
infowindow.open(map, marker);
});
setupClickListener(’changetype-all’, []);
setupClickListener(’changetype-address’, [’address’]);
setupClickListener(’changetype-establishment’, [’establishment’]);
setupClickListener(’changetype-geocode’, [’geocode’]);
Listato 6.9. Il codice JavaScript relativo all’auto-completamento del form e
all’inizializzazione della mappa
Le funzioni JavaScript mostrate in questo listato ricoprono un ruolo di fondamentale importanza all’interno del processo di creazione di un waypoint. Principalmente esse, tramite l’ausilio delle API di Google Map, forniscono gli strumenti
102
necessari alla visualizzazione di una mappa e alla gestione della compilazione di
form. Nel dettaglio, quest’ultimo aspetto eviterà l’inserimento di riferimenti geografici inesistenti e, allo stesso tempo, guiderà l’utente in tale fase, suggerendo solo
vie o punti di riferimento fisicamente rappresentabili su mappa.
Soltanto in seguito al corretto inserimento dell’input e alla conseguente creazione del marker associato, verrà visualizzato il pulsante per confermare l’inserimento
del punto. In parallelo alla visualizzazione di tale pulsante, verrà creato un tag
input nascosto a cui sarà associata la coordinata del riferimento geografico prescelto. A seguito della conferma dell’inserimento di quest’ultima informazione, come
mostrato nel Listato 6.7, verrà richiamata la funzione inserisci way point, la cui
implementazione è mostrata nel Listato 6.10.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
function inserisci_way_point($way_point, $coordinare){
try {
$coordinare = str_replace("(", "", $coordinare);
$coordinare = str_replace(")", "", $coordinare);
$coordinare = explode(", ", $coordinare);
$lat= $coordinare[0];
$long= $coordinare[1];
$wp = get_waypoints();
$trovato =false;
$way_point = str_replace(",", "", $way_point);
for ($ind = 0; $ind < count($wp); $ind++) {
similar_text(strtolower($wp[$ind]->nome), strtolower($way_point), $percent);
if($percent>90){
$trovato =true;
}
}
if($trovato==false){
global $wpdb;
$query_way_point= $wpdb ->prepare ("insert into wp_waypoint(nome, latitudine, longitudine)
value(%s, %s, %s)", $way_point, $lat,
$long);
$wpdb -> query($query_way_point);
echo "<p>Way point inseriti con sueccesso</p>";
}else{
echo "<p align=’center’>wp $way_point gia presente</p>";
}
} catch (Exception $e) {
echo "<p align=’center’>waypoint non inseriti</p>";
echo ’Caught exception: ’, $e->getMessage(), "\n";
}
}
Listato 6.10. Il codice della funzione inserisci way point
Tale funzione riceve in ingresso il nome del waypoint e la sua coordinata. Una
volta ricavate la longitudine e la latitudine di quest’ultima, il sistema verificherà
la presenza del punto sul database. Nel caso in cui esso fosse assente, la funzione
procederà con l’effettuare il suo inserimento. Per evitare attacchi di tipo SQLInjection, prima di essere eseguita, la query utilizzata verrà data in ingresso alla funzione
prepare.
6.3.2 Implementazione della funzionalità relativa all’inserimento di un
percorso
Nel Listato 6.11 viene mostrato il contenuto del file inserisci percorso turistico statico.php. Esso corrisponde alla pagina di inserimento di un percorso.
1
2
<?php
get_header();
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
103
?>
<form action="" method="post">
<?php
if(isset($_POST[’Descrizione’])&&isset($_POST[’Descrizione_en’]) && $_POST[’Descrizione_es’])
&& isset($_POST[’Nome’]) $_POST[’categoria’]) && isset($_POST[’descrizione_tratte’])
&& $_POST[’descrizione_tratte_en’]) && isset($_POST[’descrizione_tratte_es’])
&& $_POST[’distance’]) && isset($_POST[’archi’]) && $_POST[’Start’])
&& isset($_POST[’End’])){
$descrizione_percorso_it= $_POST[’Descrizione’];
$descrizione_percorso_en= $_POST[’Descrizione_en’];
$descrizione_percorso_es= $_POST[’Descrizione_es’];
$nome_percorso= $_POST[’Nome’];
$categoria=$_POST[’categoria’];
$descrizione_tratte_it= $_POST[’descrizione_tratte’];
$descrizione_tratte_en= $_POST[’descrizione_tratte_en’];
$descrizione_tratte_es= $_POST[’descrizione_tratte_es’];
$distance= $_POST[’distance’];
$archi=$_POST[’archi’];
$start=$_POST[’Start’];
$end=$_POST[’End’];
$way_points=array();
array_push($way_points,$start);
foreach ($_POST[’WayPoint’] as $selected_option) {
array_push($way_points,$selected_option);
}
array_push($way_points,$end);
inserisci_percorso_turistico_completo($descrizione_percorso_it,$descrizione_percorso_en,
$descrizione_percorso_es, $nome_percorso, $categoria,
$descrizione_tratte_it, $descrizione_tratte_en,
$descrizione_tratte_es, $distance, $archi);
}
$_POST=array();
print_form_inserisci_percorso_turistico_statico();
?>
</form>
<?php
}
Listato 6.11. Il contenuto del file inserisci percorso turistico statico.php
All’interno del tag form è presente la funzione print form inserisci percorso turistico statico, la quale verrà richiamata al momento del caricamento della
pagina. Essa dividerà l’area di inserimento in più sezioni. La prima riguarderà la
selezione della categoria e l’inserimento dei dati generici; il codice per realizzazione
di tale sezione è mostrato nel Listato 6.12.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
<?php
function print_form_inserisci_percorso_turistico_statico(){
$categorie = get_categorie();
?>
<div class="cotainer_block">
<fieldset>
<legend>Categorie</legend>
<select name="categoria" >";
<?php
for ($ind = 0; $ind < count($categorie); $ind++) {?>
<option value="<?php echo $categorie[$ind]->nome ?>">
<?php echo $categorie[$ind]->nome ?>
</option>
<?php }?>
</select>
</fieldset>
</div>
Nome: <input type="text" name="Nome" required />
Descrizione: <input type="text" name="Descrizione" required />
Descrizione ES: <input type="text" name="Descrizione_es" required />
Descrizione EN: <input type="text" name="Descrizione_en" required />
104
31
32
33
34
</div>
[...]
<?php }
Listato 6.12. La porzione di codice della funzione print form inserisci percorso turistico statico, relativo alla selezione di una categoria e all’inserimento dei dati generici
di un percorso
La prima operazione mostrata in questo listato corrisponde al recupero delle
categorie dal database e al loro inserimento all’interno di un vettore. Il contenuto di
tale vettore sarà mostrato tramite un menù a discesa in modo da permetterne la selezione dei suoi elementi. Infine, all’interno del tag <div class="cotainer block">,
verranno inseriti i campi utilizzati per la specificazione del nome e della descrizione
del percorso.
Successivamente, la funzione in esame realizzerà una seconda area dedicata alla
composizione del percorso da effettuare con il supporto di una mappa. Il codice che
ha permesso ciò e mostrato nel Listato 6.13.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
<?php
[...]
$wps=get_waypoints();
?>
[...]
<b>Start:</b>
<select id="start" name="Start">
<?php for ($ind = 0; $ind < count($wps); $ind++) {?>
<option value="<?php echo $wps[$ind]->latitudine."|".$wps[$ind]->longitudine."|".
$wps[$ind]->id_waypoint?>">
<?php echo $wps[$ind]->nome?></option>
<?php}?>
</select>
<br>
<b>Waypoints:</b> <br>
<i>(Ctrl-Click for multiple selection)</i><br>
<select multiple name="WayPoint[]" id="waypoints" >
<?php}?>
</select>
<br>
<b>End:</b>
<select id="end" name="End">
<?php}?>
</select>
</div>
<div class="cotainer_block_map">
</div>
</div>
<div class="cotainer_botton_link">
<a id="submit" value="Testa percorso">Testa Percorso</a>
</div>
[...]
Listato 6.13. La porzione di codice della funzione print form inserisci percorso turistico statico, utilizzata per la composizione grafica di un percorso
La prima operazione effettuata dalla funzione mostrata in questo listato consiste
nel recuperare i waypoint presenti nel database. In seguito, essa creerà tre menù a
discesa per permettere la selezione del punto di partenza, del punto di arrivo e dei
punti intermedi. Infine, nel caso in cui il percorso selezionato sarà visualizzato sulla
mappa di supporto, verrà presentato un ulteriore blocco, contenente gli input per le
105
descrizioni delle singole tratte e il pulsante per confermare l’inserimento. Il codice
utilizzato per la realizzazione di quest’ultima sezione è mostrato nel Listato 6.14.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
<?php
[...]
$wps=get_waypoints();
?>
[...]
<div class="cotainer_botton">
<input type="hidden" id="ins_percorso" value="Inserisci Percorso" />
</div>
<div class="cotainer_description">
<div class="cotainer_block_description">
<h1>Blocco IT</h1>
<div id="descrizione_tratte_it"></div>
</div>
<h1>Blocco EN</h1>
<div id="descrizione_tratte_en"></div>
</div>
<h1>Blocco ES</h1>
<div id="descrizione_tratte_es"></div>
</div>
</div>
<div id="directions-panel"></div>
<div id="right-panel">
<input type="hidden" id="vettore_tratte" value="">
<script src="https://maps.googleapis.com/maps/api/js?key=AIzaSyCBEhcmPPw2-zcQYyzSroeXglMLtEyRlw&signed_in=true&libraries=places&callback=initMap" async defer></script>
<?php }
Listato 6.14. La porzione di codice della funzione print form inserisci percorso turistico statico, che presenta gli input relativi alle descrizioni delle singole tratte
Le operazioni descritte dai listati precedenti fanno uso di un insieme di funzioni JavaScript. Queste ultime sono contenute all’interno del file denominato
support percorsi.js. Di tale file saranno descritte in dettaglio soltanto le funzioni più importanti. Il Listato 6.15 mostra l’implementazione della funzione initMap,
tramite la quale è stata realizzata la mappa utilizzata per le operazioni di testing.
1
2
3
4
5
6
7
8
9
10
11
12
var directionsService = new google.maps.DirectionsService;
var directionsDisplay = new google.maps.DirectionsRenderer;
var map = new google.maps.Map(document.getElementById(’map’), {
zoom: 10,
center: {lat: 38.0978092, lng: 15.531342}
});
directionsDisplay.setMap(map);
document.getElementById(’submit’).addEventListener(’click’, function() {
var is_percorso_disponibile = calculateAndDisplayRoute(directionsService, directionsDisplay);
});
}
Listato 6.15. La funzione initMap, contenuta all’interno del file support percorsi.js
Oltre ad impostare i parametri della mappa, questa funzione associerà all’evento
di pressione del tag submit la chiamata della funzione calculateAndDisplayRoute,
tramite la quale verrà calcolata e visualizzata la rotta. Tale funzione risolverà le tre
seguenti problematiche:
•
•
•
il prelievo dei punti di partenza, di arrivo e di quelli intermedi;
il calcolo della rotta;
la creazione degli input relativi alla descrizione delle singole tratte.
Il codice relativo al recupero dei punti di partenza, di arrivo e di quelli intermedi,
selezionati tramite menù a discesa, è mostrato nel Listato 6.16.
106
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
function calculateAndDisplayRoute(directionsService, directionsDisplay) {
var checkboxArray = document.getElementById(’waypoints’);
var latlangorig = document.getElementById(’start’).value;
var latlangorig = latlangorig.split("|");
lat_orig= latlangorig[0]; lng_orig= latlangorig[1];
try{
id_way_points.push(latlangorig[2]);
}catch(err){
alert(err.message);
}
for (var i = 0; i < checkboxArray.length; i++) {
if (checkboxArray.options[i].selected) {
var latlangwp =checkboxArray[i].value;
var latlangwp =latlangwp.split("|");
var lat_orig_wp= latlangwp[0]; var lng_orig_wp= latlangwp[1];
try{
id_way_points.push( latlangwp[2]);
}catch(err){
alert(err.message);
}
waypts.push({
location: new google.maps.LatLng(lat_orig_wp, lng_orig_wp),
stopover: true
});
}
}
var latlangdest = document.getElementById(’end’).value;
var latlangdest = latlangdest.split("|");
lat_dest= latlangdest[0];
lng_dest= latlangdest[1];
try{
id_way_points.push(latlangdest[2]);
}catch(err){
alert(err.message);
}
[...]
}
Listato 6.16. La porzione di codice della funzione calculateAndDisplayRoute, utilizzata
per il recupero dei punti del percorso
Una volta recuperati tali dati, essi verranno inseriti all’interno di opportune
variabili. Queste saranno utilizzate per il calcolo del percorso. Il codice che permette
di effettuare quest’ultima operazione è mostrato nel Listato 6.17.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
try{
origin: new google.maps.LatLng(lat_orig, lng_orig),
destination: new google.maps.LatLng(lat_dest, lng_dest),
waypoints: waypts,
optimizeWaypoints: true,
travelMode: google.maps.TravelMode.DRIVING
if (status == google.maps.DirectionsStatus.OK) {
[...]
}
});
}catch(err){
alert("errore calcolo rotta "+err.message);
}
per il calcolo del percorso
La funzione route, applicata all’oggetto directionsService, permetterà di
calcolare il percorso. Essa riceverà in ingresso il punto di partenza, il punto di
arrivo, il vettore dei waypoint e la modalità di percorrenza. Nel caso in cui
le informazioni utilizzate da tale funzione porteranno alla creazione di un per-
107
corso, verrà eseguito il codice contenuto all’interno dell’istruzione if (status
==google.maps.DirectionsStatus.OK). Tale codice è mostrato nel Listato 6.18.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
[...]
var input_ins_percorso = document.getElementById(’ins_percorso’);
input_ins_percorso.setAttribute("type","submit");
var route = response.routes[0];
var summaryPanel = document.getElementById(’directions-panel’);
summaryPanel.innerHTML = ’’;
var container_descrizione_tratte = document.
getElementById(’descrizione_tratte_it’);
container_descrizione_tratte.innerHTML = ’’;
var container_descrizione_tratte_en = document.
getElementById(’descrizione_tratte_en’);
container_descrizione_tratte_en.innerHTML = ’’;
var container_descrizione_tratte_es = document.
getElementById(’descrizione_tratte_es’);
container_descrizione_tratte_es.innerHTML = ’’;
var id_it="";
var id_en="";
var id_es="";
for (var i = 0; i < route.legs.length; i++) {
var input = document.createElement("input");
input.type = "hidden";
input.setAttribute("id", i+1);
input.setAttribute("name", "distance[]");
input.setAttribute("value", route.legs[i].distance.text);
summaryPanel.appendChild(input);
id_it="id"+i;
id_en="id"+i+1;
id_es="id"+i+2;
var
var
var
var
var
start = route.legs[i].start_address;
end = route.legs[i].end_address;
arr=route.legs[i];
start = start.replace(",","");
end = end.replace(",","");
var input_archi = document.createElement("input");
input_archi.type = "hidden";
input_archi.setAttribute("name", "archi[]");
input_archi.setAttribute("value", id_way_points[i]+"|"+
id_way_points[i+1]);
summaryPanel.appendChild(input_archi);
var descrizione_it=""; var descrizione_en=""; var descrizione_es="";
jQuery.ajax({
type:’GET’,
url: "/verifica_esistenza_arco/?origin=" + start + "&
destination=" + end,
crossDomain: true,
dataType: "json",
async: false,
success: function (jsonData) {
var data=eval(jsonData);
data.forEach(function(a){
descrizione_it=a.it; descrizione_en=a.en;
descrizione_es=a.es;
});
},error: function (e) {
alert(e.message);
}
});
var input_it = document.createElement("input");
input_it.type = "text";
input_it.setAttribute("id", id_it);
input_it.setAttribute("name", "descrizione_tratte[]");
if(descrizione_it!=""){
input_it.setAttribute("value", descrizione_it);
input_it.setAttribute("readOnly", true);
}
var label_input_it = document.createElement("label");
label_input_it.setAttribute("for",id_it);
label_input_it.innerHTML = "Descrizione-IT Tratta: "+start+"|"+end;
var input_en = document.createElement("input");
input_en.type = "text";
input_en.setAttribute("id", id_en);
input_en.setAttribute("name", "descrizione_tratte_en[]");
if(descrizione_en!="") {
input_en.setAttribute("value", descrizione_en);
input_en.setAttribute("readOnly", true);
108
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
}
var label_input_en = document.createElement("label");
label_input_en.setAttribute("for",id_en);
label_input_en.innerHTML = "Descrizione-EN Tratta: "+start+"|"+end;
var input_es = document.createElement("input");
input_es.type = "text";
input_es.setAttribute("id", id_es);
input_es.setAttribute("name", "descrizione_tratte_es[]");
if(descrizione_es!="") {
input_es.setAttribute("value", descrizione_es);
input_es.setAttribute("readOnly", true);
}
var label_input_es = document.createElement("label");
label_input_es.setAttribute("for",id_es);
label_input_es.innerHTML = "Descrizione-ES Tratta: "+start+"|"+end;
container_descrizione_tratte.appendChild(label_input_it);
container_descrizione_tratte.appendChild(input_it);
container_descrizione_tratte_en.appendChild(label_input_en);
container_descrizione_tratte_en.appendChild(input_en);
container_descrizione_tratte_es.appendChild(label_input_es);
container_descrizione_tratte_es.appendChild(input_es);
[...]
per la creazione di input testuali
La prima istruzione mostrata in questo listato corrisponde alla creazione del
pulsante con il quale si potrà confermare l’inserimento del percorso. In seguito si
preleveranno i riferimenti dei tag HTML che avranno il compito di incapsulare le
descrizioni delle tratte. Per ogni tratta del percorso assemblato, verranno eseguite
le seguenti operazioni:
•
•
•
Il prelievo del punto di inizio, del punto di fine e della lunghezza.
La verifica dell’esistenza della tratta tramite una chiamata AJAX. Essa contatterà
un file PHP il quale interrogherà il database per ricercare il dato richiesto. Nel
caso in cui la ricerca restituirà un risultato, questo verrà reso disponibile nel
formato JSON. Al verificarsi di quest’ultimo caso, la tratta recuperata verrà
associata al percorso, evitando, cosı̀, di crearne una nuova.
L’inserimento dei tag relativi alla descrizione all’interno dei propri container.
7
Manuale utente
Questo capitolo rappresenta un manuale d’uso dell’applicazione realizzata. In particolare, il suo scopo è quello di illustrare le modalità di utilizzo che gli utenti dovranno
seguire per sfruttare correttamente l’applicazione. Verranno descritti, inoltre, tutti i
servizi forniti dal sistema e verranno analizzate le schermate principali con cui l’utente dovrà interagire. Nello specifico, verranno mostrate le corrispettive schermate
relative ad un dispositivo iOS e ad un dispositivo Android.
7.1 Introduzione
L’applicazione EnjoyRC ha lo scopo di guidare l’utente durante il suo soggiorno
nella provincia di Reggio Calabria; si tratta, quindi, di una guida turistica di facile
consultazione, sempre a disposizione sul proprio dispositivo mobile. Il turismo “fai
da te” ha assunto, negli ultimi anni, uno sviluppo molto importante; sono sempre più
numerosi, infatti, i turisti che preferiscono organizzare autonomamente la propria
vacanza, magari con l’ausilio delle numerose app disponibili o sfruttando i tanti siti
Web del settore.
EnjoyRC può essere considerata il punto di partenza per un soggiorno nella provincia reggina; essa fornisce informazioni e curiosità sui luoghi, organizza percorsi
turistici, e consiglia hotel e locali presenti sul territorio. Allo stesso tempo, EnjoyRC
rappresenta una finestra multimediale sulla città alla quale tutti i cittadini possono
affacciarsi. Una caratteristica dell’applicazione in questione è la semplicità di utilizzo; le schermate con cui l’utente si troverà a interagire saranno user friendly ed
essenziali, tipiche dei sistemi per dispositivi mobili, che riescono a combinare una
grafica accattivante, ma essenziale, a buone funzionalità.
Di seguito verranno mostrate tutte le schermate relative alle macro-aree del
sistema.
7.2 La Home Page
Tutte le macro-aree presenti nell’applicazione sono direttamente accessibili dalla Home Page del sistema. Nella Figura 7.1 è possibile osservare la semplice organizzazione
della stessa.
110
7 Manuale utente
Figura 7.1. La Home Page dell’applicazione EnjoyRC
L’utente potrà accedere alle macro-aree disponibili ed usufruire di tutti i servizi
implementati sfruttando il menù visualizzato in primo piano e le due icone disposte
sulla navigation bar. Le macro-aree raggiungibili attraverso il menù centrale sono
le seguenti:
•
•
•
•
•
•
•
•
Punti di interesse;
Ristorazioni;
Pernottamenti;
Percorsi;
Servizi primari;
Svaghi;
La città;
Eventi.
Le due macro-aree raggiungibili attraverso le icone presenti sulla navigation bar
sono le seguenti:
•
•
Drawer menù;
Ricerca.
7.4 La sezione “Ricerca”
111
7.3 Il Drawer Menu
Il Drawer Menu, mostrato in Figura 7.2, permetterà all’utente di accedere all’area
dell’applicazione in cui sono contenute le informazioni generali della stessa.
Figura 7.2. Il Drawer Menu dell’applicazione EnjoyRC
Esso è costituito da quattro voci di menù:
•
•
•
•
Credits: fornirà le informazioni su coloro che hanno contribuito alla realizzazione
di EnjoyRC;
Manual: fornirà alcune indicazioni per l’utilizzo dell’applicazione;
Rate EnjoyRC: da tale sezione si verrà reindirizzati al market-place specifico,
per il rilascio di recensioni e votazioni;
Exit: permetterà di uscire dall’app.
Tra queste, le più importanti risultano essere Credits e Manual, le cui schermate
vengono mostrate in Figura 7.3.
La pagina relativa alle funzionalità di ricerca sarà divisa in due aree differenti.
La prima, situata nella parte alta della schermata, permetterà all’utente di inserire una parola chiave per effettuare una ricerca generica all’interno dei contenuti
112
7 Manuale utente
Figura 7.3. Le sezioni Credits e Manual, accessibili dal Drawer Menu dell’applicazione
EnjoyRC
113
dell’applicazione. La seconda in basso permetterà all’utente di avviare una ricerca
personalizzata. In Figura 7.4 è possibile osservare la schemata appena descritta e il
risultato di una ricerca generica.
Figura 7.4. Le sezioni di ricerca dell’applicazione EnjoyRC
Nel caso della ricerca personalizzata, l’utente potrà selezionarne l’ambito cliccando sul corrispondente pulsante. Fatto ciò, sarà reindirizzato alla pagina che per-
114
7 Manuale utente
metterà di effettuare le operazioni di setting mediante filtri prestabiliti. In Figura
7.5 viene mostrata la schermata contenente i filtri di ricerca.
Figura 7.5. Le pagina contente i filtri per la ricerca personalizzata
7.5 La sezione “Punti di interesse”
115
7.5 La sezione “Punti di interesse”
Selezionando dalla Home Page l’icona corrispondente, l’utente sarà reindirizzato alla
schermata contenente le categorie dei punti di interesse memorizzate nel sistema
(Figura 7.6).
Figura 7.6. Le pagina contenente le categorie dei punti di interesse
Selezionando una specifica categoria, verrà mostrata la lista dei punti di interesse
ad essa associati. Tale lista è rappresentata nella Figura 7.7.
L’utente potrà visualizzare il dettaglio di uno specifico elemento della lista cliccando su di esso. A seguito di ciò, si aprirà una nuova schermata in cui verranno
organizzate tutte le informazioni relative a quel dato punto di interesse. La pagina
di dettaglio è mostrata nella Figura 7.8.
Nella medesima schermata si potrà scegliere di visualizzare la mappa contenente
le informazioni per raggiungere tale punto (Figura 7.9). L’applicazione preleverà
automaticamente la posizione del dispositivo e calcolerà il tragitto più breve. Allo
stesso tempo, essa permetterà di scegliere la modalità di percorrenza. Nel caso in
cui il GPS del dispositivo non fosse in funzione, l’utente potrà digitare e scegliere
manualmente il punto di partenza.
116
7 Manuale utente
Figura 7.7. La pagina contenente la lista dei punti di interesse associati ad una categoria
Figura 7.8. Le pagina contenente il dettaglio di un punto di interesse
7.6 Le macro-aree relative alle attività commerciali
117
Figura 7.9. La pagina contenente la mappa relativa ad un punto di interesse
7.6 Le macro-aree relative alle attività commerciali
7.6.1 La sezione “Ristorazioni”
La sezione relativa alle ristorazioni conterrà tutte le informazioni riguardanti le attività del comparto eno-gastronomico. Tale sezione presenterà una struttura simile
a quella relativa ai punti di interesse precedentemente descritta. Al primo livello, il
sistema presenterà all’utente la categorizzazione dei vari punti di ristorazione (Figura 7.10); da essa egli potrà scegliere una delle categorie visualizzate e procedere alla
navigazione. La schermata successiva che gli verrà mostrata conterrà la lista dei locali appartenenti alla categoria precedentemente scelta (Figura 7.11). Selezionando
un dato locale, si verrà reindirizzati alla pagina di dettaglio (Figura 7.12).
In tale pagina verranno visualizzate una serie di informazioni relative al locale,
ovvero:
•
•
•
•
•
•
•
l’icona caratterizzante le ristorazioni;
il recapito telefonico;
il sito web;
la descrizione;
il giorno di chiusura;
gli orari di apertura e chiusura;
le icone rappresentanti i servizi offerti.
118
7 Manuale utente
Figura 7.10. La pagina contenente le categorie dei punti di ristorazione
Figura 7.11. La pagina contenente i punti di ristorazione associati ad una determinata
categoria
7.7 La sezioni “Percorsi turistici statici”
119
Figura 7.12. La pagina di dettaglio relativa ad un punto di ristorazione
Infine, si potranno consultare le informazioni stradali per raggiungere il locale
accedendo alla sezione dedicata. Tale sezione è mostrata nella Figura 7.13.
7.6.2 Le sezioni “Pernottamenti” e “Svaghi”
Tali sezioni conterranno le informazioni relative ai punti di pernottamento e di svago
presenti in città. L’organizzazione dei contenuti e le funzioni usufruibili dall’utente
in tale sezione sono le medesime rispetto a quelle precedentemente descritte nella
sezione “Ristorazione”. Per tale motivo verranno mostrate esclusivamente le pagine
di primo livello (Figura 7.14 e 7.15).
Un’altra importante sezione dell’applicazione EnjoyRC è quella relativa ai percorsi
turistici statici. Il sistema offrirà all’utente l’opportunità di consultare vari percorsi
turistici prestabiliti e categorizzati sulla base di una tipologia. Nella Figura 7.16
sono mostrate le tre categorie presenti, tra le quali sarà possibile scegliere.
Selezionando una particolare categoria, verranno mostrati sullo schermo tutti
gli itinerari ad essa associati (Figura 7.17). A questo punto, l’utente potrà accedere
all’area di dettaglio di un particolare percorso e visualizzare, cosı̀, quante più informazioni possibili riguardanti tale itinerario. Nell’area di dettaglio verranno mostrate
la mappa dell’intero percorso e una descrizione generale dello stesso (Figura 7.18).
120
7 Manuale utente
Figura 7.13. La pagina contenente la mappa relativa ad un punto di ristorazione
Figura 7.14. La pagina contenente la categorie dei pernottamenti
Figura 7.15. La pagina contenente la categorie degli svaghi
Figura 7.16. La pagina contenente le categorie dei percorsi turistici
121
122
7 Manuale utente
Tale sezione, rispetto a quelle precedentemente illustrate, presenterà un ulteriore
livello di dettaglio nel quale verranno descritte le tratte in cui ogni percorso può
essere suddiviso. Nella Figura 7.19 viene mostrata la pagina di dettaglio relativa ad
una tratta specifica di un percorso.
Figura 7.17. La pagina contenente la lista dei percorsi turistici associati ad una specifica
categoria
7.8 La sezioni “Servizi primari”
Tale sezione fornirà all’utente informazioni utili riguardanti i principali servizi offerti
dalla città. In questo caso è stata adottata una doppia categorizzazione, organizzando i servizi prima per tipologia e dopo per contesto di riferimento. La struttura
utilizzata per la visualizzazione dei servizi e delle categorie ad essi associate risulta simile a quelle precedentemente analizzate. L’unica differenza è riscontrabile nel
livello di dettaglio mostrato nella Figura 7.20.
7.9 La sezioni “Eventi”
La pagina principale di tale sezione prevede una struttura abbastanza semplice,
in cui verrà visualizzata una classificazione degli eventi (Figura 7.21). Cliccando
7.9 La sezioni “Eventi”
123
Figura 7.18. La pagina contenente il dettaglio di un percorso turistico
Figura 7.19. La pagina contenente il dettaglio di una delle tratte in cui è suddiviso un
percorso turistico
124
7 Manuale utente
Figura 7.20. La pagina contenente il dettaglio di un servizio primario
sull’apposito pulsante, l’utente accederà alla pagina di secondo livello nella quale
saranno visualizzati tutti gli eventi legati all’ambito scelto in precedenza. Nella
Figura 7.22 viene mostrata la schermata contenente la lista degli eventi. Come è
possibile osservare, si tratta di una lista che visualizza molti più dettagli rispetto
a quelli precedentemente visualizzati. Per ogni evento, infatti, saranno visualizzati
la data, il luogo e il nome. Tale lista mostrerà gli eventi dal più recente al meno
recente.
L’utente potrà selezionare ciascun elemento della lista; a seguito di un’operazione
di selezione, egli potrà accedere all’area di dettaglio nella quale saranno mostrati la
locandina, la descrizione, la data, l’ora e il luogo (Figura 7.23).
7.10 La sezione “La città”
Dalla Home Page dell’applicazione sarà possibile accedere alla sezione “La città”.
Essa conterrà una serie di informazioni generali riguardanti la città di Reggio Calabria. La prima schermata che il sistema visualizzerà all’utente (Figura 7.24),
conterrà una breve descrizione e un menù per accedere alle seguenti sotto-sezioni:
•
•
•
•
Come arrivarci;
Come visitarla;
Negozi di prodotti tipici;
Tradizioni.
Figura 7.21. La pagina contenente le categorie degli eventi
Figura 7.22. La pagina contenente la lista degli eventi
125
126
7 Manuale utente
Figura 7.23. La pagina contenente il dettaglio di un evento
Figura 7.24. La Home Page della sezione “La città”
127
Le view di queste sotto-sezioni sono rappresentate nelle Figure 7.25, 7.26, 7.27
e 7.28
Figura 7.25. La pagina contenente le indicazioni stradali per raggiungere la città
128
7 Manuale utente
Figura 7.26. La pagina contenente le informazioni utili a visitare la città
Figura 7.27. La pagina contenente l’elenco dei negozi di prodotti tipici presenti in città
Figura 7.28. La pagina contenente la lista delle tradizioni calabresi
129
8
Confronto con sistemi correlati
In questo capitolo verrà proposta un’analisi comparativa dell’applicazione EnjoyRC.
In particolare, verranno considerati diversi sistemi del settore turistico con caratteristiche simili a quello descritto in questa tesi, evidenziando, per ciascuno di essi, le
analogie e le differenze con la nostra applicazione. L’analisi comparativa è preceduta
da una disamina attenta dei principali punti di forza e di debolezza di EnjoyRC.
8.1 Punti di forza
Per la realizzazione dell’applicazione EnjoyRC abbiamo tenuto in considerazione
i principi teorizzati dalla User Experience Design (UXD). Un’applicazione mobile,
infatti, deve racchiudere tutte le funzionalità di un normale sito Internet e riadattare
i contenuti in modo da essere facilmente e velocemente consultabile in mobilità. I
principi della UXD applicati alle applicazioni mobili hanno permesso di concentrarsi
sulle esigenze dell’utente, ottimizzando il prodotto finale.
Tali principi ci hanno guidato nella realizzazione della logica che sta alla base dell’applicativo e nella realizzazione della componente grafica alla base dell’interazione
con gli utenti.
La semplicità di utilizzo, l’organizzazione e la completezza dei contenuti, nonchè
la chiarezza dell’interfaccia sono i presupposti irrinunciabili per qualsiasi nuova proposta che intenda generare apprezzamento nel mondo delle guide turistiche per i
dispositivi mobili.
La presente sezione ha lo scopo di presentare e di illustrare i punti di forza del
sistema sviluppato. Nello specifico, EnjoyRC :
•
•
•
•
•
•
risulta essere disponibile per le piattaforme Android e iOS;
risulta essere compatibile sia per smartphone che per tablet;
sfrutta al minimo le risorse hardware e software, in quanto il carico computazionale è rivolto maggiormente sulla componente server;
è basata sui principi della UXD;
offre un contenuto informativo dinamico, in quanto i dati visualizzati non
risiedono nello smartphone ma in un server esterno;
fornisce la possibilità di usufruire delle mappe con e senza l’utilizzo del GPS;
132
•
•
8 Confronto con sistemi correlati
permette di sponsorizzare le attività e, in generale, i punti di interesse dislocati
sul territorio reggino;
risulta essere multi-lingua.
I punti di forza appena citati rendono il sistema da noi realizzato particolarmente
efficiente ed innovativo. La principale innovazione riguarda l’adozione di alcune delle
migliori tecnologie di ultima generazione riguardanti lo sviluppo di applicazioni
mobile e web.
Nello specifico, si è scelto di utilizzare una delle migliori piattaforme per lo
sviluppo di applicazioni mobile ibride, ovvero AppGyver, che integra al suo interno
i principali vantaggi forniti dal framework AngularJS, ad oggi ritenuto la punta di
diamante del linguaggio JavaScript.
Sfruttando le caratteristiche delle tecnologie appena citate, è stato possibile
realizzare un’applicazione multipiattaforma compatibile con tutti gli smartphone e
i tablet delle famiglie Google ed Apple.
Anche se l’applicativo risiede su un dispositivo mobile, esso riesce a fornire un
supporto efficiente, utilizzando un quantitativo di risorse minimo, senza appesantire
il dispositivo che lo ospita con un carico computazionale elevato. Oltre a tutto ciò,
è importante evidenziare il fatto che la maggior parte della logica che permette
la realizzazione di tutte le funzionalità è concentrata sulla componente server del
sistema su cui l’applicativo si appoggia; grazie a ciò il complesso delle funzionalità
offerte non grava in maniera considerevole sulle risorse hardware e software del
dispositivo.
Utilizzando le linee guida fornite dallo User Experience Design è stata realizzata
un’interfaccia grafica gradevole e per niente complessa, che favorisce l’interazione
con gli utenti.
Il sistema realizzato rappresenta una guida turistica dettagliata e completa per
i turisti che volessero visitare i luoghi più belli della provincia reggina, ma anche,
al contempo, un punto di riferimento per i cittadini. Esso, per fornire un supporto
concreto ai turisti, è stato pensato in modo tale da poter visualizzare i contenuti
nelle lingue italiano, inglese e spagnolo.
EnjoyRC guiderà l’utente in maniera interattiva, mediante la proposta di alcuni
itinerari specifici e l’integrazione dei servizi di geolocalizzazione offerti da Google
Map.
8.2 Punti di debolezza
I punti di debolezza del sistema EnjoyRC sono i seguenti:
•
•
•
•
•
assenza di un meccanismo che gestisca la profilazione dell’utente;
impossibilità di creare un percorso turistico personalizzato;
impossibilità di usufruire dei contenuti in modalità off-line e di memorizzarli tra
i preferiti;
assenza di un sistema distribuito per la gestione dei dati;
mancanza di compatibilità per Windows Phone.
8.3 Confronto con sistemi correlati
133
L’assenza di un meccanismo di profilazione non permette ad un utente di visualizzare lo storico delle sue operazioni su dispositivi differenti; ad esempio, egli non
potrà tenere traccia dei percorsi già intrapresi o dei luoghi già visitati.
La sezione dedicata ai percorsi turistici non offre la possibilità di creare un nuovo
percorso turistico personalizzandone l’itinerario.
Per il momento, la consultazione dei contenuti offerti dall’applicazione potrà
avvenire esclusivamente in presenza di una connessione Internet, a causa dell’assenza
di un meccanismo di storage locale. Questo comporta l’impossibilità di memorizzare
localmente i contenuti preferiti.
Tutte le informazioni visualizzate dall’utente risiedono attualmente in un unico server. Un malfunzionamento dello stesso causerà l’impossibilità di usufruire,
temporaneamente, dei servizi offerti dall’app.
Infine, non è stata ancora prevista una versione compatibile con il sistema
operativo Windows Phone.
Questi punti di debolezza verranno eliminati nei futuri rilasci dell’applicazione.
La loro attuale presenza non nasce da una cattiva progettazione, ma dal fatto che
si è datà priorità ai quei requisiti che hanno permesso di informatizzare il contesto
scelto nel modo più efficiente possibile.
Di seguito verranno elencate alcune delle applicazioni mobili, legate al mondo del
turismo, che hanno l’obbiettivo di guidare i viaggiatori durante la visita di alcune
città italiane o alcune località geografiche sparse per il mondo. Per ciascuna di esse
verrà effettuato un confronto con l’applicativo descritto in questa tesi, evidenziando
tutte le analogie e le differenze. Le applicazioni prese in esame sono:
•
•
•
•
•
•
Tutto Calabria in App;
Bergamo City Tour;
Venezia Unica;
Neslo Barcellona;
Dubai mappa online e guida turistica;
World Explorer.
8.3.1 Tutto Calabria in App
Tutto Calabria in App è una delle poche applicazioni dedicate alla regione Calabria
che focalizza la propria attenzione sulle attività commerciali, gli eventi e le news
relativi alle cinque provincie calabresi.
Tale applicazione raggruppa tutte le aziende, le imprese locali, le associazioni,
gli enti pubblici, e molto altro, in un unico grande menu a cascata; inoltre, la loro
locazione viene riportata su mappa.
Ciò che caratterizza maggiormente Tutto Calabria in App è, appunto, lo stretto
legame tra le informazioni contenute e la loro rappresentazione geografica. L’utente
interagirà quasi unicamente con il menu laterale, mostrato nella Figura 8.1, dal
quale potrà selezionare la categoria di interesse; successivamente, sarà reindirizzato
134
Figura 8.1. Il menù laterale dell’applicazione Tutto Calabria in App
alla mappa geografica. Su tale mappa saranno mostrati gli elementi relativi alla
categoria precedentemente selezionata.
La mappa geografica conterrà le informazioni di base relative all’attività scelta.
Le informazioni usufruibili sono le seguenti: numero di telefono, indirizzo e-mail,
sito web e link immediato a Google Maps.
Allo stesso tempo, tale applicazione fornisce la possibilità di consultare un’ampia
galleria fotografica, la quale potrà essere aggiornata direttamente dagli enti pubblici
e dalle associazioni che promuovono il turismo.
L’applicazione che si sta analizzando, pur fornendo una vasta gamma di categorie tra le quali scegliere nonchè un ottimo supporto alle mappe e ai servizi di
geolocalizzazione, presenta alcuni punti deboli che è necessario sottolineare. Tra
questi è possibile elencare i seguenti:
•
•
•
•
le schede di dettaglio relative ad un punto di interesse o ad un’attività non sono
particolarmente esaustive;
l’organizzazione dei contenuti non permette una navigazione semplice ed immediata tra gli stessi;
le indicazioni stradali sono usufruibili tramite l’utilizzo di Google Maps;
la mole di dati presenti nel sistema risulta essere insufficiente.
135
Analogie
A seguito di un’attenta analisi del sistema descritto in precedenza sono state individuate alcune analogie con l’applicazione oggetto del presente lavoro di tesi. Tutto
Calabria in App organizza i contenuti basandosi su un’attenta categorizzazione degli
stessi. Allo stesso tempo, ad ogni elemento rappresentato viene associato un servizio
di localizzazione. Essa è stata sviluppata per i sistemi operativi Android e iOS.
Differenze
Tale applicazione, pur adottando una suddivisione dei contenuti per categorie, non
prevede un’organizzazione delle stesse in sezioni dedicate. Per quanto detto in precedenza, dunque, l’organizzazione dei contenuti risulta essere quasi totalmente differente rispetto a quella adottata da EnjoyRC. Ogni azione da parte dell’utente sarà
gestita da un menù laterale a cascata che non permette una chiara visualizzazione
dei contenuti. L’utente sarà, dunque, costretto ad usufruire continuamente di una
lunghissima lista di difficile consultazione.
La Home Page di Tutto Calabria in App, pur prevedendo cinque differenti pulsanti, reindirizzerà l’utente sempre alla medesima pagina. Tale schermata conterrà
una grande mappa geografica in primo piano priva di utilità e il menù a cascata
accessibile dalla navigation bar. In EnjoyRC invece, la Home Page rappresenta il
punto di partenza essenziale per la navigazione tra i contenuti e per accedere alle
funzionalità previste dall’applicazione.
Un’altra differenza rilevante tra le due applicazioni è legata alla sezione “Percorsi”. Tutto Calabria in App non prevede, infatti, una sezione in cui sono riportati dei
percorsi turistici ed degli itinerari da consultare. Tale sezione, invece, rappresenta
uno dei punti di forza del nostro applicativo. Infine, l’app descritta non può essere
consultata in lingua spagnola.
8.3.2 Bergamo City Tour
Bergamo City Tour è un’applicazione turistica ideata e realizzata dal Comune di
Bergamo, in collaborazione con numerosi enti, con lo scopo di pubblicizzare la città
lombarda. Tale applicazione offre la possibilità ai turisti di essere guidati attraverso
la città, seguendo tre differenti itinerari, e di conoscere i principali punti di interesse
presenti sul territorio.
I contenuti dell’applicazione, ad eccezione degli eventi giornalieri e dei contenuti
multimediali, sono accessibili in modalità offline, ovvero fruibili senza la presenza
di una connessione Internet. Il punto di accesso dell’applicazione è una Home Page
organizzata a tile (Figura 8.2).
Ciascun tile consente l’accesso a una differente sezione dell’applicazione. I tile
della Home Page presentano tutti la medesima forma e dimensione, eccezione fatta
per quello relativo agli itinerari che è più grande, per rimarcare l’importanza di
quest’ultima.
L’applicazione contiene oltre 100 punti di interesse presentati con sintetici testi descrittivi, immagini e curiosità. Un’area specifica dell’applicazione è dedicata
136
Figura 8.2. La Home Page dell’applicazione Bergamo City Tour
a divertenti quiz relativi alla città e alla provincia. Sulle piattaforme iOS, ad eccezione degli eventi, i quali sono visualizzati in lingua italiana, tutti i contenuti
dell’applicazione sono presentati in lingua inglese.
Analogie
L’applicazione che si sta analizzando presenta molti aspetti comuni con il nostro
sistema. Di seguito sono elencate le principali analogie:
•
•
•
•
•
•
tutte le sezioni dell’applicazione sono accessibili dalla Home Page;
ogni sezione presenta una categorizzazione dei contenuti in modo da facilitare la
navigazione;
la funzionalità di ricerca è accessibile mediante una specifica icona presente sulla
navigation bar;
l’attenzione è focalizzata sulla sezione dei percorsi turistici;
il sistema risulta essere multipiattaforma;
la struttura dei primi livelli di navigazione visualizza le categorie dei contenuti.
137
Differenze
L’applicazione analizzata, pur presentando numerose analogie con il nostro sistema,
si differenzia da esso per alcuni importanti aspetti. Tra questi risulta essere di particolare rilevanza la funzionalità relativa alla ricerca. Accedendo all’area specifica, si
potrà effettuare una ricerca generica esclusivamente all’interno della sezione “attrazioni” non comprendendo tutti gli altri contenuti. Allo stesso tempo, da tale area non
sarà possibile filtrare i risultati mediante un’operazione di ricerca personalizzata.
Infine, un’ulteriore differenza da sottolineare riguarda l’assenza della sezione
relativa ai punti di pernottamento, compensata dalla presenza delle sezioni “Quiz”
e “Gallery”, assenti in EnjoyRC.
8.3.3 Venezia Unica
Venezia Unica è un progetto curato dalla testata giornalistica telematica ARTE.it.
Essa rappresenta un sistema introdotto dalla città di Venezia per accedere ai servizi
di trasporto, culturali e turistici del territorio. Nello specifico, Venezia Unica è
indirizzata sia al turista che ai cittadini veneziani.
Venezia Unica è un supporto utile per conoscere i punti di interesse storico e
artistico di Venezia: musei, mostre, piazze, monumenti, chiese, palazzi e giardini. Si
possono consultare gli orari ufficiali del trasporto pubblico locale e organizzare al
meglio gli spostamenti in città. Grazie alla georeferenziazione dei punti di interesse,
è possibile programmare la visita in base al tempo a disposizione. L’applicazione
contiene la descrizione di oltre 300 punti di interesse, schede descrittive corredate
da immagini e biografie di artisti.
Allo stesso tempo, è possibile accedere ad informazioni riguardanti luoghi di
divertimento, ristoranti, mercati e librerie.
Venezia Unica fornisce il calendario aggiornato degli eventi d’arte in corso e in
programmazione (mostre, eventi ed esposizioni d’arte) con una breve descrizione
dell’evento e con la relativa localizzazione.
Inoltre, questa applicazione fornisce le informazioni riguardanti gli appuntamenti
di arte e cultura che si svolgono in città. In Figura 8.3 viene mostrata una schermata
Analogie
L’applicazione Venezia Unica permette di accedere ai contenuti attraverso un pratico menù che occupa l’intera Home Page. Ogni sezione, analogamente a quanto
avviene per EnjoyRC, è caratterizzata da una specifica icona. L’area di dettaglio di
un singolo contenuto presenta molti campi in comune con la nostra applicazione,
consentendo di geolocalizzare, laddove possibile, il contenuto scelto.
Differenze
Uno dei principali servizi offerti dall’applicazione Venezia Unica, non previsto da
EnjoyRC, è quello relativo ad una mappa interattiva, che permette di geolocalizzare
138
Figura 8.3. Una schermata dell’applicazione Venezia Unica
l’utente e, per ogni elemento di interesse, riporta sulla stessa la sua posizione. Inoltre, Venezia Unica prevede alcune sezioni non presenti in EnjoyRC, ovvero quelle
contenenti le cartoline e quella relativa agli artisti veneziani.
Pur prevedendo un’area relativa ad itinerari statici, Venezia Unica presenta una
struttura e un livello di dettaglio differente rispetto a quello da noi adottato.
8.3.4 Neslo Barcellona
Neslo Barcellona è un’applicazione turistica dedicata alla città spagnola di Barcellona, contenente migliaia di riferimenti a località, punti interesse e attività commerciali. Tale applicazione presenta quattro pagine principali, raggiungibili mediante
una tab bar:
•
•
•
Cerca: rappresenta la pagina iniziale dell’applicazione. Essa contiene la lista delle
otto sezioni che possono essere consultate. All’interno della medesima pagina
sarà possibile effettuare una ricerca su tutti i contenuti grazie al form presente
sulla parte superiore della stessa.
Mappa: contiene una mappa della città di Barcellona.
Trasporto: mostra, all’interno di una mappa, gli itinerari di tutti i mezzi pubblici.
•
139
Preferiti: mostra tutti i contenuti dell’applicazione segnalati dall’utente come
preferiti.
La schermata in cui vengono visualizzate le otto sezioni dell’app risulta essere
quella più importante. A partire da essa, l’utente potrà consultare i vari contenuti
(Figura 8.4).
Figura 8.4. La Home Page dell’applicazione Neslo Barcellona
Analogie
Neslo Barcellona presenta numerosissime analogie con l’applicazione da noi sviluppata. Anch’essa adotta una suddivisione netta in macro-aree, accessibili dalla
Home Page. Inoltre, Neslo Barcellona offre la possibilità di estendere le operazioni
di ricerca a tutti i contenuti e di applicare particolari filtri.
Per quanto riguarda i punti di interesse e le attività, anche quest’app permette di
geolocalizzarli su mappa. La categorizzazione che tale applicazione offre rispecchia
quasi totalmente quella da noi adottata.
140
Differenze
Neslo Barcellona offre la possibilità di accedere direttamente al sito booking.com per
poter effettuare la prenotazione di un hotel presente in città.
Per quanto riguarda la lista dei contenuti, oltre alla sua visualizzazione integrale,
sarà possibile adottare un filtro sulla base dell’orario di apertura o rispetto alla posizione attuale. Per quanto riguarda il singolo contenuto, esso potrà essere visualizzato
su mappa, ma non verranno fornite le indicazioni stradali per raggiungerlo.
A differenza della nostra applicazione, i vari contenuti potranno essere aggiunti
ad una lista di preferiti.
8.3.5 Dubai Travel Guide and Offline Map
Dubai Travel Guide and Offline Map è la piattaforma sviluppata da Ultron, una
startup australiana specializzata nella creazione di applicazioni turistiche.
Tale app fornisce un servizio che permette l’utilizzo di mappe senza la presenza
di una connessione alla rete Internet, consentendo di visualizzare la posizione del
proprio dispositivo sulle stesse. Essa è in grado di localizzare strade, indirizzi e punti
di interesse fornendo un percorso per raggiungerli.
La Home Page è formata da una mappa centrata sull’aeroporto di Dubai. Il punto
di accesso ai contenuti è rappresentato da un pulsante a forma di mappamondo
presente sulla navigation bar.
Tramite esso si accederà alla sezione contenente una lista dei principali luoghi da
visitare. Essi saranno ordinati in base al loro grado di popolarità, non prevedendo
una categorizzazione per contesto di riferimento. Tale organizzazione dei contenuti,
in assenza di una funzionalità di ricerca, risulterà di difficile consultazione.
Il sistema offre due tipologie di ricerche, specifiche per alberghi, tour e attività.
Per la ricerca relativa ai pernottamenti, tale app permette di inserire opportuni
filtri riguardanti il giorno di arrivo, la durata del soggiorno e gli ospiti per stanza.
Nella lista filtrata verranno visualizzati, per ogni elemento, il prezzo di partenza, la
recensione e il riferimento a booking.com.
Per quanto riguarda i tour e le attività, questi vengono mostrati indistintamente
nella medesima lista. Soltanto in un secondo momento sarà possibile filtrare gli
stessi per categoria, destinazioni, lingua, durata e tipo di servizio.
Tale applicazione consente ad un utente registrato di:
•
•
•
recensire e votare i luoghi visitati;
creare un account utente e utilizzarlo, accedendo da qualsiasi dispositivo iOS,
per la visualizzazione dei propri contenuti;
memorizzare mappe e contenuti direttamente sul dispositivo in modo da potervi accedere anche in modalità offline. La connessione alla rete Internet è
fondamentale per il download dei dati e per la prenotazione dei pernottamenti.
Il primo svantaggio riscontrato in questo applicativo riguarda la presenza delle
numerose pubblicità contenute al suo interno che, nella maggior parte dei casi,
rallentano la navigazione all’interno dello stesso.
141
Analogie
Entrambe le applicazioni sfruttano un sistema di geolocalizzazione per agevolare
la navigazione all’interno dei contesti rispettivamente rappresentati e offrono la
possibilità di votare il sistema sui rispettivi store.
Differenze
L’applicazione descritta presenta una struttura di navigazione completamente differente rispetto a quella di EnjoyRC. Essa permette l’accesso ai contenuti tramite
una piccola icona situata sulla navigation bar. Tale soluzione risulta essere poco
intuitiva e funzionale.
EnjoyRC, grazie alla categorizzazione intelligente dei dati, permette all’utente
di accedere direttamente alle informazioni relative al contesto di proprio interesse.
L’applicazione descritta in questa sezione, invece, presenta direttamente i contenuti
più popolari, senza offrire la possibilità di filtrarli (Figura 8.5).
Figura 8.5. La lista dei contenuti più popolari dell’applicazione Dubai Travel Guide and
Offline Map
142
L’applicazione che si sta analizzando permette di effettuare una ricerca esclusivamente sui pernottamenti, sui tour e sugli eventi, a differenza della nostra, che
permette di effettuarla all’interno di tutte le sezioni, specificando anche opportuni
filtri.
I dati relativi alle mappe, utilizzate da Dubai Travel Guide and Offline Map,
sono forniti da OpenStreetMap, un progetto aperto paragonabile a Wikipedia. Tale
progetto permette agli utilizzatori di contribuire al miglioramento delle informazioni
riguardanti la mappa e i punti di interesse. In generale, i contenuti dell’applicazione
sono prelevati da fonti esterne, come Wikipedia, booking.com e getyourguid. Per
quanto riguarda EnjoyRC, invece, essi sono prelevati dalla componente backend del
sistema.
Infine, Dubai Travel Guide and Offline Map non funziona su dispositivi con
sistema operativo Android.
8.3.6 World Explorer
World Explorer è una guida turistica mondiale, che fornisce agli utenti informazioni
riguardanti tutte le località sparse per il mondo. Ciò che caratterizza principalmente
questa applicazione è la modalità utilizzata per fornire agli utenti le informazioni
turistiche di loro interesse. A differenza dei normali sistemi del settore turistico,
non sarà l’utente a richiedere le informazioni al sistema, ma sarà in automatico
l’app a suggerire la propria soluzione. World Explorer, infatti, è in grado di creare
una lista dei centri d’interesse in prossimità dell’utente (monumenti, musei, villaggi), accompagnati da una nota esplicativa, secondo il loro interesse turistico. Per
sfruttare tale servizio, si rende necessario consentire all’app di ottenere la posizione approssimativa dell’utente. Tale posizione viene ottenuta mediante il servizio di
geolocalizzazione.
L’utente potrà scegliere un elemento della lista visualizzata (Figura 8.6) e
consultarne le informazioni annesse: storia, aneddoti, dati e foto.
Le descrizioni presenti nell’app vengono integralmente ottenute da Wikipedia.
Il primo aspetto negativo riscontrato è l’eccessiva presenza di annunci pubblicitari, i quali distolgono l’attenzione dell’utente dalla navigazione.
Gli elementi visualizzati nella Home Page presentano, spesso, delle incoerenze
tra l’immagine mostrata e il contenuto che essi rappresentano.
Tale applicazione non risulta, inoltre, ottimizzata per tutti i dispositivi e necessita l’update ad una versione a pagamento per usufruire di alcune fondamentali
funzionalità.
Analogie
World Explorer, come EnjoyRC, gestisce la globalizzazione permettendo la visualizzazione dei contenuti in più di due lingue. Un’altra analogia è quella relativa ai
sistemi operativi supportati. World Explorer è, infatti, disponibile sia per dispositivi
Android che per dispositivi iOS.
Anche in questo caso, l’esperienza di navigazione dell’utente risulta essere
semplificata in quanto i contenuti vengono visualizzati su due semplici livelli.
143
Figura 8.6. La Home Page dell’applicazione World Explorer
Differenze
World Explorer non è un’applicazione turistica dedicata ad una singola città o area
geografica, come invece EnjoyRC, bensı̀ si riferisce a qualsiasi punto geografico sparso per il mondo. L’intero applicativo si sviluppa su due unici livelli: il primo relativo
alla visualizzazione di una lista di punti di interesse, il secondo riguardante la pagina
di dettaglio dello stesso. I contenuti dell’area di dettaglio vengono prelevati automaticamente da Wikipedia. Questo aspetto è vincolante in quanto non è possibile
personalizzare le informazioni visualizzate. Nel nostro sistema, invece, i contenuti
sono gestiti tramite un pannello di amministrazione.
Gli elementi visualizzati vengono organizzati senza nessun tipo di categorizzazione, e, allo stesso tempo, tra questi non sono presenti punti di ristorazione, punti di
pernottamento ed eventi. Inoltre, non vengono gestiti i percorsi turistici nè vengono
riportate informazioni riguardanti i servizi primari.
Da sottolineare il fatto che tale applicazione fornisce un servizio di notifiche
istantanee.
9
Conclusioni e sviluppi futuri
In questo capitolo verranno tratte delle conclusioni in merito al presente lavoro di
tesi e verranno delineati alcuni possibili sviluppi futuri.
9.1 Conclusioni
Il lavoro svolto per la presente tesi è consistito nell’analisi dei requisiti e nello studio
di fattibilità di un sistema capace di fornire un supporto al turismo nella città di
Reggio Calabria. Tale sistema è formato da un’applicazione mobile ibrida e da un
server per la gestione dei contenuti che essa dovrà visualizzare.
A seguito della fase di analisi, ci si è concentrati sugli strumenti necessari allo
sviluppo della componente mobile del sistema, per poi passare alla definizione delle
funzionalità da realizzare e allo studio dei mockup. Dopo di ciò, si è passati alla
fase di progettazione delle funzionalità di base del sistema, per poi descrivere la
fase di implementazione. A seguire, ci si è concentrati sulla fase di progettazione
e implementazione del macro-blocco “Percorsi turistici”, riguardante sia la componente client che quella server. Infine, si è realizzato un manuale utente per descrivere
ogni sezione e funzionalità ed è stato effettuato un confronto con altre applicazioni
presenti sui vari market-place riguardanti il nostro stesso contesto di riferimento.
Nella fase iniziale di analisi si è evidenziato quanto il turismo possa assumere un
ruolo di fondamentale importanza per favorire l’interazione tra la città di Reggio
Calabria ed il resto del mondo. Da queste considerazioni è nata l’esigenza di sfruttare le moderne tecnologie per promuovere sia il turismo sia le potenzialità che la
città stessa nasconde ai cittadini. Allo stesso tempo, si sono descritte tutte le fasi
preliminari che hanno permesso di raccogliere i requisiti fondamentali alla realizzazione del sistema; in seguito si è definita una suddivisione degli stessi in macro-aree
e, per ciascuna di esse, si è descritto il contesto che rappresentano.
La fase iniziale di analisi ha permesso di produrre uno studio di fattibilità con
lo scopo di evidenziare tutti i possibili rischi riscontrabili in fase di produzione,
eventuali anomalie e/o eventuali aspetti non fattibili. In questo modo si sono potute
definire le pratiche da adottare per favorire lo sviluppo del progetto, per evidenziare
i fattori di rischio, proponendo delle ipotetiche soluzioni alle conseguenze degli stessi,
e infine, per definire la modalità di attuazione del progetto.
146
9 Conclusioni e sviluppi futuri
A questo punto, è stato effettuato uno studio approfondito riguardante le tecnologie necessarie allo sviluppo della componente mobile del sistema; esso, ha portato
alla scelta, tra le varie opzioni disponibili, di un approccio ibrido, e nello specifico,
ad adottare la piattaforma AppGyver e il framework JavaScript AngularJS.
Una volta definita la piattaforma di sviluppo, è stata effettuata la progettazione
delle funzionalità di base riguardanti la componente mobile; nello specifico, è stata
effettuata la progettazione della componente applicativa. Fatto ciò, si è passati alla
fase riguardante l’implementazione di tali funzionalità. Inizialmente, si sono descritti
nel dettaglio gli strumenti che hanno fornito un supporto a tale fase, tra cui i sistemi
di versioning e gli IDE di sviluppo, per poi analizzare tutte le scelte implementative
adoperate per soddisfare i requisiti emersi durante la fase di analisi.
Infine, essendo un punto di forza del nostro sistema, si sono descritte in dettaglio la fase di progettazione della componente applicativa e le relative scelte
implementative riguardanti, macro-blocco “Percorsi turistici”.
9.2 Sviluppi futuri
Con il sistema EnjoyRC abbiamo costruito un progetto in grado di evolversi, prefissandoci di effettuare un manutenzione continua durante il suo ciclo di vita e
prevedendo l’aggiunta di nuove funzionalità e di nuovi aggiornamenti. Tutto ciò
sarà finalizzato ad ottenere un sistema efficiente e, allo stesso tempo, paragonabile
con i più popolari sistemi di supporto al turismo.
Oltre a ciò, si punterà ad integrare soluzioni innovative non previste dai competitor del settore, rendendo l’utilizzo della nostra applicazione un’esperienza nuova
e coinvolgente.
Alla base del processo di manutenzione evolutiva del sistema EnjoyRC vi è stata un’accurata pianificazione dei rilasci futuri, mirati alla correzione dei problemi
presenti nella prima versione, ad un miglioramento delle funzionalità già realizzate e all’integrazione di nuovi componenti. La prima versione del sistema è stata
dettagliatamente descritta in questo elaborato di tesi.
La distribuzione pianificata dei nuovi componenti, nei vari rilasci del sistema, è
stata una diretta conseguenza di un’analisi effettuata tramite il metodo MoSCoW.
Tale tecnica viene impiegata nella business analysis e nello sviluppo del software
per definire la priorità dei vari requisiti. In particolare, il metodo MoSCoW prevede
quattro categorie distinte di requisiti, ovvero:
•
•
•
•
Must Have: descrive i requisiti che devono essere soddisfatti necessariamente
nella soluzione finale.
Should Have: rappresenta un aspetto ad alta priorità, il quale dovrebbe essere
compreso nella soluzione.
Could Have: descrive un requisito che è considerato auspicabile, ma non necessario. Sarà incluso solo se il tempo e le risorse lo permettono.
Won’t Have: rappresenta un requisito che gli stakeholder hanno accettato di non
vedere implementato nella versione del software che si sta realizzando, ma che
può essere considerato in futuro.
9.2 Sviluppi futuri
147
Il processo di prioritizzazione è scaturito dal confronto con gli stakeholder durante il quale si è associata una delle categorie precedentemente descritte ad ogni nuovo
requisito. A fine di ciò sono state programmate tre ulteriori release, identificate dalle
Versioni 2.0, 3.0 e 4.0.
La versione 2.0 prevede l’ottimizzazione delle funzionalità già fornite dalla prima release e l’integrazione della “realtà aumentata”. Quest’ultima permetterà di
arricchire le informazioni contenute all’interno della macro-area dei punti di interesse con oggetti virtuali. Essa sarà dotata di un motore di riconoscimento delle
immagini che permetterà, inquadrando con la fotocamera un punto di interesse,
di associare tale punto alla corrispettiva pagina di dettaglio presente in memoria,
aggiungendovi contenuti multimediali ed elementi 3D.
Tra le operazioni di ottimizzazione previste, vi sarà quella che garantirà agli
stakeholder del settore turistico (strutture ricettive, istituzioni pubbliche, esercizi commerciali, strutture alberghiere, gestori delle attrazioni turistiche, sistemi di
trasporto, etc.) di accedere alle piattaforme web inserire o aggiornare autonomamente le informazioni relative alle proprie attività. Ciò sarà reso possibile soltanto
in seguito all’acquisizione di opportune credenziali d’accesso.
La Versione 3.0 prevederà l’integrazione di due complessi macro-blocchi. Il primo
sarà quello relativo alla creazione di una social network, mentre il secondo consisterà
in un sistema di User Agent basato sulla profilazione utente.
La scelta di adottare WordPress come strumento di amministrazione della componente server è nata anche dalla richiesta di predisporre il sistema ad ospitare
una social network tematica. Infatti, grazie agli strumenti forniti dalla community
di WordPress, si potranno integrare le funzionalità tipiche di una social network
direttamente sul sistema EnjoyRC.
Il sistema da noi realizzato si evolverà coinvolgendo sempre di più gli utenti.
La gestione del processo di profilazione sarà alla base del sistema di User Agent
da integrare. Grazie ad esso, verranno fornite informazioni personalizzate sulla base
degli interessi e delle esperienze di ogni singolo utilizzatore.
La Versione 4.0 integrerà le funzionalità che permetteranno all’utente di acquistare i titoli di ingresso relativi ad un luogo da visitare (musei, teatri, eventi
sportivi), di creare un percorso con un itinerario personalizzato che preveda tratte
terra/mare, e di essere avvisato della presenza di interruzioni del traffico cittadino
durante la creazione di un percorso, suggerendone uno alternativo.
Tale release, inoltre, permetterà l’interazione dello smartphone con i beacon
distribuiti lungo il territorio e all’interno di specifiche strutture. I beacon sono a
piccoli dispositivi bluetooth che, se collocati in uno spazio fisico come un museo,
trasmettono intorno a sé segnali radio a basso consumo e a corto raggio. Questa loro
caratteristica potrà essere sfruttata per scatenare un evento sul dispositivo quando
esso si troverà all’interno del raggio di azione del beacon.
Ringraziamenti
Trovarsi nuovamente a scrivere i ringraziamenti è una bella sensazione, perché significa che un nuovo traguardo è alle porte. Risulta ugualmente difficile trovare le
parole per poter ringraziare tutti in queste poche righe, ma è doveroso ringraziare
coloro che in un modo o in un altro, hanno dato un contributo al raggiungimento
di questo nuovo obbiettivo.
Un ringraziamento generale va a chi mi è stato sempre vicino e a chi mi ha lasciato solo nel momento del bisogno, perché ha contribuito maggiormente a formare
la persona forte e responsabile che oggi sono. Non sarà bello perdere i colleghi, gli
amici e tutti coloro che, come me, hanno dedicato questi ultimi due anni allo studio
e al sacrificio, mettendo in secondo piano tutto il resto. Spero che almeno questa
volta, gli studi ingegneristici non abbiano influenzato il mio modo di scrivere.
Affrontare questa tesi mi ha messo alla prova, dandomi la possibilità di affrontare
delle realtà che nel corso dei miei studi non ho mai incontrato e, onestamente, non
avrei mai pensato fossero cosi dure da sostenere. Spero di essere stato all’altezza
del compito che mi è stato assegnato e di aver raggiunto gli obbiettivi prefissati ma
sopratutto, spero che questa esperienza sia la prima di tante.
Non posso fare a meno di ringraziare il mio compagno di avventura Alessandro
e i miei relatori, il prof. Domenico Ursino e il dott. Antonio Quattrocchi. La loro
disponibilità, la loro esperienza, la loro pazienza e i loro insegnamenti sono stati
fondamentali per la realizzazione di questa tesi.
Durante tutto il mio cammino universitario sono molte le persone che mi sono
state vicine. Non potrò mai dimenticare ciò che la mia famiglia ha fatto per me
nonostante tutti i problemi, il loro sostegno, sia morale che economico, non è mai
venuto meno; soprattutto non finirò mai di ringraziare i miei Genitori, i miei Nipoti,
i miei Fratelli, le mie Sorelle e i miei Amici perché, anche nei momenti peggiori, non
mi hanno mai lasciato solo.
Un particolare ringraziamento va a tutti quegli amici che hanno messo una mano
sulla mia spalla nei momenti in cui ne avevo bisogno e hanno vissuto assieme a me
momenti davvero importanti. È grazie a tutte queste persone se adesso, anche se con
mio stupore, ho raggiunto questo traguardo, un traguardo che non avrei pensato di
riattraversare.
Mi sembra ieri il giorno in cui ho conseguito la laurea triennale, e non riesco a
credere di essere prossimo alla quella magistrale. Adesso posso davvero dire di non
150
Ringraziamenti
essermi pentito di aver riaffrontato questa carriera universitaria, con la promessa
che il mio percorso non finirà qui e che questo secondo traguardo è solo un ponte
che va verso il mondo lavorativo.
A tutti voi, grazie!
Riferimenti bibliografici
1. HTML5 Introduzione.
http://www.mrwebmaster.it/html/introduzione_10743.
html, 2012.
2. JavaScript Tutorial. http://www.w3schools.com/js/, 2013.
3. AppGyver. http://www.appgyver.io/supersonic/, 2014.
4. Guida HTML5. http://www.html.it/guide/guida-html5/, 2014.
5. HTML.it.
http://www.html.it/articoli/apps-mobile-con-steroidsintroduzione/, 2014.
6. Hybrid Mobile App Command-Line Smackdown. http://developer.telerik.com/
featured/hybrid-mobile-app-command-line-smackdown/, 2014.
7. JS e HTML, librerie e codice JavaScript esterno. http://www.html.it/pag/46494/
caricare-javascript-esterno/, 2014.
8. What is JavaScript.
https://developer.mozilla.org/en-US/Learn/Getting_
started_with_the_web/JavaScript_basics, 2014.
9. WordPress Get Started. https://learn.wordpress.com/, 2014.
10. Advantages of Self-Hosted WordPress Blog.
https://codex.wordpress.org/
WordPress_Quick_Start_Guide, 2015.
11. AppGyver. http://www.redherring.com/company-profiles/appgyver/, 2015.
12. AppGyver, Hybrid App Development That Goes Beyond Just Code.
http://www.sitepoint.com/appgyver-hybrid-app-development-goes-beyondjust-code/, 2015.
13. Appgyver, Steroids, and Composer Cross-Platform Mobile Dev.
http:
//tarnaeluin.houseofbeor.net/appgyver-steroids-and-composer-crossplatform-mobile-dev/, 2015.
14. How to Create a Cross-Platform App In Minutes with AppGyver and Syncano. https://www.syncano.io/blog/how-to-create-a-cross-platform-app-inminutes-with-appgyver-and-syncano/, 2015.
15. HTML5 Introduction. http://www.w3schools.com/html/html5_intro.asp, 2015.
16. HTML.it. http://www.html.it/guide/guida-angularjs/, 2015.
17. What distinguishes Ionic Framework from AppGyver’s Supersonic Framework
for cross-platform mobile app development?
https://www.quora.com/Whatdistinguishes-Ionic-Framework-from-AppGyvers-Supersonic-Framework-forcross-platform-mobile-app-development, 2015.
18. WordPress 4.2.2 release di mantenimento e sicurezza. http://www.wpitaly.it/2015/
05/07/wordpress-4-2-2-release-di-mantenimento-e-sicurezza/, 2015.
19. AngularJS. https://angularjs.org/, 2016.
20. AngularJS Material. https://material.angularjs.org/latest/, 2016.
152
Riferimenti bibliografici
21. PHP. https://secure.php.net/manual/, 2016.
22. R. Azuma, Y. Baillot, R. Behringer, S. Feiner, S. Julier, and B. MacIntyre. Recent advances in augmented reality. IEEE Computer Graphics and Applications, 21 (6):34.47,
2002.
23. T. Boronczyc. PHP 6, Apache, MySQL: Sviluppo di siti Web. Hoepli, 2012.
24. C. S. Chan and J. L. Hong. HTML Validation for PHP Web Applications. Australian
Journal of Intelligent Information Processing Systems, 12 (2), 2014.
25. A. Charland and B. Leroux. Mobile application development: web vs. native.
Comunications of the ACM, 54 (5):49.53, 2011.
26. D. Flanagan. JavaScript: The Definitive Guide: Activate Your Web Pages. O’Reily,
2011.
27. A. Freeman. Pro AngularJS. Apress, 2014.
28. G. Gigliotti. HTML5. Apogeo, 2012.
29. M. Haverbeke. Javascript. Guida completa per lo sviluppatore. Hepli, 2016.
30. T. D. Hedengren. Sviluppare con WordPress. Apogeo, 2014.
31. R. G. Hollands. Will the real smart city please stand up. City: analysis of urban
trends, culture, theory, policy, action, 12 (3):303.320, 2008.
32. M. Kenteris, D. Gavalas, and D. Economou. An innovative mobile electronic tourist
guide application. Personal and Ubiquitous Computing, 13 (2):103.118, 2009.
33. M. MacDonald. HTML5: The Missing Manual. O’Reily, 2014.
34. P. MacIntyre. PHP. Le tecniche per scrivere il codice migliore. O’Reily, 2010.
35. T. Nam and T. A. Pardo. Digital Government Research. In Software engineering
issues for mobile application development, page 282.291, New York, USA, 2011.
36. B. Pollentine. Appcelerator Titanium Smartphone App Development Cookbook by
Boydlee Pollentine. Packt Publishing, 2011.
37. S. Radford. Sviluppare applicazioni web con AngularJS e Bootstrap. Apogeo, 2015.
38. A. Ravulavaru. Learning Ionic - Build Hybrid Mobile Applications with HTML5. Packt
Publishing, 2015.
39. K. Su, J. Li, and H. Fu. Electronics, Communications and Control (ICECC), 2011
International Conference on. In Smart city and the applications, page 1028.1031,
Zhejiang, 2011.
40. A. I. Wasserman. Proceedings of the FSE/SDP workshop on Future of software engineering research. In Conceptualizing smart city with dimensions of technology, people,
and institutions, page 397.400, Santa Fe, NM, USA, 2010.
41. B. Williams, D. Damstra, and H. Stern. Professional WordPress: Design and
Development. Wrox, 2015.

theses

Transcript

Documenti analoghi

Ricchi e Poveri - LIVE A GROTTE DI CASTRO (12-8-15)

Modulo d`iscrizione

IRCA SPA Div. RICA - Zoppas Industries

Relazione annuale 2014 - Azienda Ospedaliera di Padova

Estate 2015 – Spese

Un clacson diventa musica "Così conquisto Fabri Fibra"

Bambini e genitori piangono la loro maestra Dominique

25MHz 40MHz Oscilloscopio digitale 2 Canali

Scheda segnalazione Palme infette e/o sospette