App mobile Geobox - C10315 - in SUPSI Tesi
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
App mobile Geobox
Studente/i Relatore
Gabriele Schincaglia Loris Grossi
Correlatore
Diego Frei
Committente
Chris Hodgins
Corso di laurea Modulo
Ingegneria Informatica C10315
Anno
2020/2021
Data
03 Settembre 2021
i
Sommario
Nell’ambito del progetto di diploma nel corso di Ingegneria Informatica, una startup
chiamata Geobox ha proposto un’idea di applicazione: ispirandosi alla pratica del
geo-caching e delle honesty box, il progetto mira a facilitare le transazioni di beni
locali attraverso l’uso di "smart-containers" e dell’applicazione smartphone, con cui
sarà possibile effettuare le operazioni di gestione dei container e dei prodotti.
L’obiettivo di questo progetto è realizzare l’architettura software dietro l’idea di Geo-
box, analizzando lo stato dell’arte in merito a soluzioni già esistenti e motivando le
scelte prese in fase di progettazione secondo l’attuale letteratura.
Si è deciso di realizzare un server backend utilizzando il framework Java, Spring Boot,
e un’applicazione smartphone multipiattaforma utilizzando Flutter.
Il server, inoltre, ha esposto una REST API al fine di permettere al client di consumare
i dati ad esso necessari.
Lo sviluppo del progetto è risultato in una prima versione dell’applicazione Geobox,
Community Access, in cui si forniscono agli utenti le prime funzionalità di gestione e
visualizzazione dei container. Questa prima versione rispecchia i requisiti posti ini-
zialmente, portando un’architettura conforme con gli standard di qualità odierni sia
in quanto a scelte di design e sia per quanto riguarda le tecnologie adottate.
Infine vengono proposti eventuali upgrade da apportare al backend qualora si doves-
se andare a relizzare le successive versioni di Geobox.
App mobile Geobox
ii App mobile Geobox
i
Abstract
Regarding the diploma project in the course of Computer Science Engineering, a
startup called Geobox proposed a concept for an application inspired by the "geo-
caching" procedure and honesty boxes.
The project aims at easing local goods transactions through the use of “smart-containers”
and a smartphone application, with which it will be possible to perform product and
container management operations.
The goal of this project is to implement the software architecture that’s at the heart
of the Geobox idea, analysing state-of-the-art solutions, all while justifying, according
to the current literature, the choices taken during the design phase.
A decision was made to implement a backend server using a Java framework called
Spring Boot, along with a multi platform smartphone application created with the
Flutter framework.
The server, moreover, has shown a REST API in order to allow the client to consume
the data required for it.
The development of the project has resulted in a first version of the Geobox appli-
cation called Community Access, where the user is provided with the first container
management and display features.
The first version reflects the initial requirements, revealing an architecture in com-
pliance with today’s quality standards, both in design and technology.
Lastly, possible upgrades for the backend will be recommended if the next versions
of Geobox were to be released.
App mobile Geoboxii App mobile Geobox
iii
Indice
1 Introduzione 1
1.1 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Compiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Motivazione e contesto 5
3 Stato dell’arte 7
4 Progettazione 9
4.1 Tecnologie utilizzate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1.1 Flutter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1.1.1 Google Maps Plugin . . . . . . . . . . . . . . . . . 11
4.1.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.2.1 Spring Boot . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2.2 Spring Data JPA . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2.3 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.3 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Versioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1.1 UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1.1.1 Mappa . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.1.1.2 Bottom sheets . . . . . . . . . . . . . . . . . . . . 20
4.3.1.1.3 Slivers . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.1.1.4 Search bar . . . . . . . . . . . . . . . . . . . . . . 22
4.3.1.2 State management . . . . . . . . . . . . . . . . . . . . . . 23
4.3.1.2.1 Provider . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.2.1 Architettura a livelli . . . . . . . . . . . . . . . . . . . . . . 26
App mobile Geoboxiv INDICE
4.3.2.2 Data Transfer Objects . . . . . . . . . . . . . . . . . . . . 26
4.4 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5 REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6 Sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6.1 Autenticazione - JWT . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.6.2 HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.6.3 Password hashing . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5 Sviluppo 33
5.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.1 Dipendenze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.2 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1.2.1 Serializzazione/Deserializzazione in formato JSON . . . . . 35
5.1.3 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.4 View Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.4.1 AsyncViewModel . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.5 UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2.1 Dipendenze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.2 Gerarchia di classi . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.3 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.3.1 DTO e Object Mapper . . . . . . . . . . . . . . . . . . . . . 43
5.2.4 Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.5 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.6 Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6 Testing 47
6.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.1.1 Unit Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.1.2 Widget Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7 Conclusioni 49
App mobile Geoboxv
Elenco delle figure
4.1 Suddivisione versioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Riconoscimento Flutter Favorite - Provider . . . . . . . . . . . . . . . . . 18
4.3 Bloc pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4 Floating button - Closed . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5 Floating button - Open . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.6 Sliver search bar - hidden . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.7 Sliver search bar - shown . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.8 Diagramma a blocchi - MVVM . . . . . . . . . . . . . . . . . . . . . . . . 25
4.9 Architettura a livelli - Server . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.10Diagramma E-R - Database . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.11Diagramma generale di un endpoint - Client/Server . . . . . . . . . . . . 30
5.1 Diagramma di classe - GeoboxContainer . . . . . . . . . . . . . . . . . . 36
5.2 Diagramma di classe - AsyncViewModel . . . . . . . . . . . . . . . . . . 39
5.3 Diagramma di classe - Classe astratta GeoboxResource . . . . . . . . . 42
App mobile Geoboxvi ELENCO DELLE FIGURE App mobile Geobox
1
Capitolo 1
Introduzione
In questa fase introduttiva verrà effettuata una breve descrizione del progetto, ver-
ranno definiti i compiti e gli obiettivi. Nella sezione Motivazione e contesto (2) si
descriverà il contesto nel quale si è svolta l’applicazione e l’idea che vi sta dietro.
Dopodichè nello Stato dell’arte (3) si andrà a contestualizzare l’idea che giace dietro
all’applicazione, andando a confrontare quest’ultima con le soluzioni già esistenti sul
mercato.
Nel capitolo Progettazione (4) si andrà ad esporre il processo astratto pre-implementazione
che ha portato alla scelta di specifiche tecnologie dati gli obiettivi. Inoltre verrà
descritta, rispettivamente per client e server, l’architettura dell’applicazione conse-
guentemente alle tecnologie scelte e alle fonti autorevoli in merito.
Per quanto riguarda la parte client, verranno brevemente esposte le feature salienti
riguardanti l’interfaccia utente. Nel capitolo Sviluppo (5) si descrive sia lato server,
sia lato client l’effettiva implementazione di quanto definito nella sezione preceden-
te, motivando l’architettura definita secondo le linee guida del software design.
Nel capitolo Testing (6) si descrivono brevemente le tipologie di testing applicate alla
codebase realizzata.
Infine nell’ultimo capitolo Conclusioni (7) si traggono le conclusioni basandosi sui ri-
sultati ottenuti rispetto gli obiettivi posti inizialmente. Secondariamente, si espongo-
no i limiti che si sono presentati durante la realizzazione del progetto e si discutono
sviluppi ed evoluzioni future dell’architettura realizzata.
1.1 Descrizione
L’idea di fondo di questo progetto è quella di realizzare l’architettura software dietro
Geobox.
Geobox è un’idea di applicazione che mira a costruire una community di produttori
locali che, attraverso un’applicazione mobile, potranno locare le proprie box/contai-
App mobile Geobox2 Introduzione
ner lungo il territorio e mettere al loro interno i prodotti di natura tipicamente agricola
(almeno inizialmente). Gli altri utenti potranno dunque visualizzare questi container e
operare le classiche operazioni di gestione (ricerca, preferiti, caricamento di un con-
tainer e aggiunta all’activity log di un container tramite scansione del relativo QR).
Si ha dunque necessità di costruire in primis un’applicazione mobile, che costituirà il
frontend, rappresentante il portale di controllo con cui dovrà interagire l’utente.
L’applicazione dovrà consumare dei dati che, a questo punto, dovranno provenire da
un server capace di processarli e salvarli in un database. Avendo questi "top-level
requirements", si andrà a progettare un’architettura client-server che sia in grado di
soddisfare i bisogni di Geobox.
1.2 Compiti
• Familiarizzare con il progetto e le conseguenti fasi di sviluppo
• Definizione di una base di dati in grado di memorizzare i dati relativi ai box e ai
produttori
• Sviluppo di una REST API che permetta di accedere alla base di dati definita
• Sviluppo di un’applicazione mobile multi-piattaforma che sia in grado di mostare
attraverso una mappa la posizione dei box e permetta la ricerca in base ai tag
di determinati box/prodotti.
1.3 Obiettivi
L’obiettivo di questo progetto è quello di costruire un’applicazione mobile
che fornisca indicazioni sulla posizione dei contenitori e mostri informazio-
ni inerenti ai produttori e ai prodotti offerti. L’app mobile dovrà appoggiarsi
ad un database accessibile tramite API REST. Gli utenti di Geobox dovran-
no essere in grado di scoprire i contenitori in base alla loro posizione e ai
tipi di prodotti cercati
Partendo da questa formulazione, lungo lo sviluppo del progetto si sono adattati i
requisiti in base alle necessità e alle richieste del committente, il quale, in forma set-
timanale, restituiva feedback in merito all’andamento del progetto. Alla conclusione
del progetto, infatti, sono presenti feature non richieste dagli obiettivi proposti:
• Login attraverso email e password
App mobile Geobox3
• Possibilità di caricare un container previa validazione da parte di un utente
admin
• Generazione di un codice QR per ogni container caricato
• Possibilità di scansionare il codice QR di un particolare container andando ad
aggiungerlo al proprio "activity log".
App mobile Geobox4 Introduzione App mobile Geobox
5
Capitolo 2
Motivazione e contesto
Nell’ambito del progetto di diploma del corso di Ingegneria Informatica, si è voluta
sviluppare una richiesta di progetto proveniente da un committente esterno, propo-
nente un’ idea riguardo la realizzazione di un’ applicazione. Essa necessita un’infra-
struttura informatica in grado di fornire all’utente finale uno strumento per accedere
ad un particolare servizio di scambio di beni. Geobox è una startup ticinese che mira
a creare una piattaforma e un servizio che faciliti le transazioni sicure di beni fisici
in qualsiasi luogo e tra due partecipanti qualsiasi. L’idea prende spunto dalla pratica
chiamata "geo-caching"; una sorta di "caccia al tesoro" nella quale l’obiettivo è trova-
re determinati contenitori disseminati nel territorio circostante attraverso l’utilizzo di
un ricevitore GPS. Infatti, Geobox mira ad offrire un servizio di scambio di beni tipici
del territorio, (Ticino inizialmente) attraverso l’infrastruttura informatica che si andrà
a sviluppare, la quale non si limita alla pratica di scambio ma vuole trasmettere una
vera e propria esperienza di scoperta dei luoghi di maggior interesse, affiancata alla
possibilità di provare in prima persona i prodotti locali.
Inoltre il concetto di contenitori nel quale scambiare particolari beni prende spunto
dalle "honesty-box", decisamente più presenti nella cultura anglosassone, nella quale
un individuo può acquistare in maniera del tutto self-service un particolare prodotto
locale. Infatti questa pratica è solitamente presente in aree rurali, dove la bassa
densità d’affluenza e il relativo poco valore dei prodotti contenuti in queste box non
costituiscono un problema. [1]
La prima fase del progetto Geobox mira a formare una comunità di box "self-service"
e a fornire una piattaforma per permettere ai consumatori di localizzare i box e ac-
quistare i prodotti nell’app mobile.
La piattaforma fornirà ai produttori gli strumenti per registrare i loro contenitori (i box
"self-service"), e tenere un inventario dei prodotti attualmente in stock.
Gli utenti dell’app mobile saranno in grado di localizzare i contenitori, mappare gli
App mobile Geobox6 Motivazione e contesto itinerari e conoscere i produttori. La piattaforma fornirà anche un modo per acquistare i prodotti in-app senza bisogno di contanti. Questo necessiterà l’integrazione con gli smart container realizzati appo- sitamente per questo progetto, i quali saranno aperti attraverso previa autorizzazione tramite app. Dato il contesto del progetto e la complessità dell’architettura, si è effettuata una suddivisione in base alle priorità e alle richieste del committente. Si è dunque posto il focus sulla versione I (verranno descritte più approfonditamente nella sezione 4.1). App mobile Geobox
7
Capitolo 3
Stato dell’arte
Partendo dall’analizzare l’idea che giace dietro Geobox, si nota come non siano at-
tualmente presenti soluzioni di grande rilievo sul mercato.
Questa idea in particolare prende spunto da pratiche tipiche che fino ad ora vengo-
no praticate nella loro versione convenzionale, senza trovare un supporto che invece
Geobox offrirebbe. Infatti, soprattutto in questi tempi, in cui per ragioni di entità sa-
nitaria i contatti e gli spostamenti sono fortemente limitati, le "honesty-box" hanno
trovato un loro spazio di effettiva utilità. [2]. In questo senso, quindi, l’idea portata
da Geobox risulta innovativa.
L’analisi dello stato dell’arte ha compreso soluzioni già esistenti di natura differente
ma che, per qualche ragione, presentavano funzionalità simili: si fa riferimento ad
applicazioni come Google Maps il cui focus è proprio la mappa e l’interazione con
essa. L’applicazione, sempre per quanto riguarda il territorio ticinese, hikeTicino che
presenta una mappa e la possibilità di filtrare i risultati ottenuti.
Si è posta attenzione alle modalità con le quali queste applicazioni fornivano le desi-
derate funzionalità all’utente e tramite quali componenti grafici venivano presentate.
In particolare:
• Interazione con i marker presenti sulla mappa, Google Maps infatti attraver-
so l’utilizzo di bottom sheets e search bar "galleggianti" riesce a provvedere
un’esperienza utente con un bassissimo golfo di valutazione.
• Ricerca di elementi in forma di lista e/o sulla mappa, in questo HikeTicino appor-
ta un approccio "2-way", in cui l’utente può visualizzare il risultato della ricerca
sia sulla mappa e sia in forma di lista.
Il design dell’applicazione ha cercato di ispirarsi a soluzioni ben più affermate; si è de-
notato come nella maggioranza dei casi, l’ottima esperienza utente offerta da queste
applicazioni è da ritrovarsi proprio nella loro semplcità di utilizzo, senza creare mec-
App mobile Geobox8 Stato dell’arte canismi sconosciuti al target di utenti utilizzatori. Da un punto di vista tecnico, invece, non possono essere effettuate particolari elucubrazioni in quanto, a dipendenza della tecnologia utilizzata, ogni applicazione viene implementata nella propria maniera. Il fatto di dover gestire dati complessi introduce la necessità di doversi appoggiare ad un server remoto; le soluzioni di maggior spicco solitamente si affidano ad una o più REST API al fine di consumare i dati richiesti. [3]. Ad oggi questo rappresenta lo standard adottato da ogni applicazione client-server. Infine, in ambito di persistenza, gli approcci standard stanno virando dai più datati ma stabili database relazionali a quelli di tipo NoSQL. Per la precisione, colossi come Facebook adottano un approccio ibrido, in cui sono presenti entrambi i tipi di data- base. [4] In generale la good practice è quella di adattare la scelta di un particolare database con la necessità a cui si deve far fronte, senza adottare un approccio in maniera aprioristica. [5] App mobile Geobox
9
Capitolo 4
Progettazione
Una volta compresi gli obiettivi e definita l’area di lavoro, si è voluto procedere con
la scelta delle tecnologie da utilizzare, basandosi sulle necessità incontrate e sulle
possibilità offerte dai framework presenti attualmente, sia lato server, sia lato client.
Da qui, parallelamente alle funzionalità offerte dai framework presi in considerazio-
ne, si è proceduto a definire la base di dati iniziale e in un secondo momento la scelta
della tecnologia da utilizzare in questo ambito, (relazionale/NoSQL) in accordo con
i relativi vantaggi e svantaggi. E, per quanto riguarda il client, la definizione di un’
interfaccia utente secondo i requisiti dati dal committente.
Segue quindi la definizione dell’architettura client-server e come viene strutturata,
prendendo quest’ultimi in maniera singolare e successivamente considerando l’inte-
ro sistema.
4.1 Tecnologie utilizzate
La scelta delle tecnologie utilizzate è stata effettuata prendendo in considerazione
gli obiettivi presentati e gli standard di qualità attualmente presenti nel panorama
odierno.
Infatti l’utilizzo di tecnologie appropriate, in termini di efficienza rispetto all’obiettivo
e in termini di popolarità, consentono di avere un conseguente transfer nella fase
di sviluppo, migliorando la riuscita finale del prodotto. Un framework affermato, al
passo con i tempi e largamente utilizzato, dunque ben mantenuto dai produttori, per-
mette la realizzazione di un prodotto con un grado di flessibilità ed estendibilità tale
per cui eventuali cambiamenti a livello architetturale non vengano inficiati e rallentati
ulteriormente da problematiche inerenti alla tecnologia sottostante, ma anzi alleviati
da un maggior comfort in fase di sviluppo e/o codifica. In aggiunta si è posta atten-
App mobile Geobox10 Progettazione zione alle conoscenze individuali da me proposte, dato che, anche qui, un maggior comfort riguardo un framework conosciuto avrebbe comportato una maggior facilità in termini di sviluppo e tempistiche. 4.1.1 Client Il focus del progetto, almeno da un punto di vista esterno e superficiale, è di sicuro l’applicazione destinata all’utente finale. Ed è proprio questa ad essere valutata nella sua usabilità, intuitività, e funzionalità. Inoltre oggigiorno non si può pensare di proporre un’applicazione relegata ad una par- ticolare piattaforma (iOS, Android), se non per rarissimi casi eccezionali. Considerando le tempistiche previste e la necessità del multipiattaforma è parso lo- gico pensare di procedere con una tecnologia che permetta di sviluppare un prodotto installabile ed utilizzabile sulle piattaforme più comuni. Fortunatamente oggigiorno diversi sono i framework, mobile e non, che permettono lo sviluppo di applicazioni multipiattaforma, ognuno con i propri vantaggi e svantaggi, sui quali ci si è concentrati per arrivare poi alla scelta. Si necessita menzionare come in altri contesti, con tempistiche maggiormente dilatate e la possibilità di poter svi- luppare due prodotti differenti, si sarebbe potuto optare per uno sviluppo "full-native" così da aver maggiore controllo sull’architettura e migliori performance di base. [6] La scelta è quindi ricaduta su Flutter, un giovane framework multipiattaforma anch’esso con performance comparabili al nativo. [7] Il vantaggio di poter scrivere una singola codebase realizzando allo stesso momen- to la stessa applicazione ma multipiattaforma giace instrinsicamente nel fatto che il progetto in generale risulterà meno prono a bug (data la minore quantità di codice) e sarà nel suo complesso più leggibile e mantenibile. Si aggiunge ancora una volta il fattore tempistiche. Con una sintassi e funzionalità vicine a quelle di Java, permette la costruzione di lo- giche di business che fanno uso di tecniche tipiche come polimorfismo, utilizzo di mixins, classi astratte, ecc. Questo permette l’utilizzo in primis dei comuni design pattern presenti nel mondo della programmazione ad oggetti, e in secondo luogo una maggior stabilità, conferita dalla tipizzazione opzionale di Dart, nella gestione dei tipi. In alternativa, un ipotetico candidato sarebbe potuto essere il più datato React Nati- ve, il quale non ha performance comparabili a quelle offerte da Flutter, ma presenta una maggior flessibilità nella composizione di componenti/widget. Al pari, Flutter pre- senta una maggiore stabilità a livello di logica di business grazie all’utilizzo di Dart, il linguaggio del framework. App mobile Geobox
11
4.1.1.1 Flutter
Flutter è un framework di sviluppo open-source multi piattaforma per la creazione di
interfacce native, in grado di creare applicazione eseguibili per iOS, Android, Web e
recentemente, con la versione 2.0, anche su Linux(Ubuntu).
Il framework utilizza Dart come linguaggio principale e, all’occorrenza, offre la pos-
sibilità di scrivere codice nativo iOS, Swift o Objective-C, o Android, Java o Kotlin,
creando un platform channel al fine di comunicare con le API native. [51]
Si tratta di un framework dichiarativo, in contrasto con i più comuni metodi impera-
tivi di programmazione, nel quale si descrive l’attuale stato della UI e non i passaggi
necessari per raggiungerlo.
Questo risulta essere un notevole vantaggio nello sviluppo di interfacce complesse
in quanto ci può essere un unico e solo cammino per ogni stato della UI. Si può in-
tendere quanto detto in una forma più matematica, infatti la UI ottenuta a schermo
può essere definita come il risultato dell’applicare una specifica funzione f allo stato
corrente dell’applicazione. [52]
U I = f (state)
Proprio per questa ragione il pattern architetturale maggiormente utilizzato è il Model-
View-ViewModel, che sarà poi quello che verrà utilizzato in questo progetto.
4.1.1.1.1 Google Maps Plugin
Dal momento che il requisito fondamentale lato client si sostanzia nella possibilità di
mostrare su una mappa geografica, personalizzabile secondo le necessità, la posi-
zione dei vari contenitori locati lungo il territorio del Ticino, la scelta del framework
avrebbe dovuto, in questo senso, facilitare l’implementazione della mappa stessa,
attraverso una libreria di alto livello.
Per questa ragione, data l’importanza del requisito, si è deciso di utilizzare un packa-
ge noto e supportato, in quanto sviluppato anch’esso da Google, ovvero l’implemen-
tazione in Dart delle mappe di Google Maps.
Dopo un setup effettuato dalla console di Google Cloud Platform, il plugin è utiliz-
zabile via codice includendo nell’ AndroidManifest (android/app/src/main/AndroidMa-
nifest.xml) la relativa chiave generata per l’accesso alle API di Google relative alle
mappe.
Il package permette di visualizzare specifici marker in prossimità di determinate coor-
dinate, modificare il colore degli stessi, visualizzare la posizione corrente del disposi-
App mobile Geobox12 Progettazione
1
tivo in uso ed effettuare le classiche gesture presenti su Google Maps.
Si fa nota come ad oggi si stia ancora valutando se sia ottimale o meno utilizzare
2
un plugin proprietario e non uno open source come flutter_map dal momento che
in futuro, quando sarà necessario visualizzare particolari itinerari lungo la mappa,
sarà necessario utilizzare un API per le direzioni al fine di poter visualizzare in tem-
po reale il percorso sulla mappa. Google Cloud Platform rende disponibile la Google
Maps Directions API che si integra seamlessly con il plugin di Google, ma richiede una
fatturazione e dunque un costo in quanto ogni richiesta effettuata andrebbe pagata
secondo tariffa.
Viceversa il secondo package è maggiormente bilanciato e aperto ad integrazioni
3
con API terze, come la Directions API offerta da MapQuest Anche quest’ultima non
è completamente free, ma permette un massimo di 15.000 richieste mensili (poche
in un ottica di scalabilità futura).
4.1.2 Server
Nell’ottica di questo progetto, il server (backend) avrebbe dovuto svolgere la sempli-
ce funzione di accesso ai dati tramite una REST API che permettesse all’applicazione
client di "consumare" i dati ritornati dal server.
Analizzando infatti i requisiti, la funzione del server si limita a processare e salvare i
dati in ingresso per poi essere ritornati al client quando richiesti, nella rappresenta-
zione appropriata.
In secondo luogo, questa determinata applicazione non ha la necessità di sopportare
intensi workload, nè tantomento di latenze particolarmente basse.
Il focus è stato posto su funzionalità prettamente di software design ed eventualmen-
te di facilità nella gestione del setup del server e della base di dati sulla quale andrà
ad appoggiarsi.
Il server, andando a costituire la "backbone" dell’applicazione, necessita una notevo-
le stabilità in merito alla gestione dei dati in transito, in entrata e in uscita.
Sono molte le soluzioni odierne per quanto riguarda i framework backend che utilizza-
no linguaggi debolmente tipizzati; il noto framework Laravel [8] per il mondo PHP o,
per esempio, il runtime environment Node [9] in grado di eseguire codice JavaScript
lato server. Entrambi rappresentano ottime soluzioni in quanto risultano essere tra
i framework più utilizzati nel 2020. [10]. Nonostante ciò, come accennato, si è po-
sta maggiore attenzione al software design e, ancora una volta, prediligendo un fra-
mework il quale utilizzasse un linguaggio con tipizzazione forte (o opzionale come nel
caso di Flutter).
1
google_maps_flutter: https://pub.dev/packages/googlem apsf lutter
2
flutter_map: https://pub.dev/packages/flutterm ap
3
MapQuest Directions API: https://business.mapquest.com/products/routing-directions-api
App mobile Geobox13
4.1.2.1 Spring Boot
Spring Boot è il framework backend Java più utilizzato al mondo [11] e offre diversi
moduli inerenti a funzionalità specifiche (Microservices, WebSocket, SSE, Reactive sy-
stems, JPA, ecc) capaci di alleviare il peso dello sviluppo del programmatore.
Il framework utilizza in maniera massiva il concetto di Dependency Injection [12] (DI)
e di IoC (Inversion of Control) permettendo un execution flow delle operazioni dina-
mico a seconda del contesto in fase di runtime. Grazie alla Dependency Injection,
infatti, è possibile bindare a runtime le funzionalità di una particolare classe ad un’
altra.
Così facendo si evitano lunghi spezzoni di codice boilerplate e il coupling statico che
si andrebbe a creare senza l’utilizzo di una metodologia come questa. [13]
Spring Boot non necessita di un server Tomcat come una comune applicazione server
in quanto "incorpora" Tomcat all’interno del JAR/WAR generato in fase di build. [14]
In Spring Boot "l’application layering" comunemente utilizzato è del tipo @Controller-
@Service-@Repository e anche questo progetto fa uso di quest’ultimo; questa divi-
sione di responsabilità si trasforma in una maggiore pulizia a livello del codice e un
miglior disaccoppiamento tra entità.
4.1.2.2 Spring Data JPA
Come verrà esposto successivamente, la scelta del tipo di database da utilizzare è
avvenuta parallelamente alla scelta del framework backend. La base di dati svilup-
pata andrà ad appoggiarsi ad un database di tipo relazionale, come MySQL in questo
caso.
Uno dei moduli di Spring, chiamato appunto Spring Data JPA, mira a facilitare l’imple-
mentazione di database relazionali con l’uso della Java Persistence API (JPA) attraver-
so un’astrazione del database stesso, fornendo una gestione direttamente via codice
della base di dati.
Analogamente a JPA, questo modulo permette l’utilizzo di specifiche annotazioni al-
l’interno delle classi relative al modello (domain classes) in grado di generare il corri-
spettivo DDL per generare la struttura del database.
Secondariamente, creando una specifica interfaccia (repository) e configurandola
coerentemente, sarà possibile accedere ai dati salvati, facendo uso dell’implemen-
tazione delle query generata direttamente da Spring.
In questo modo si va ancora una volta ad alleviare il peso del lavoro del programma-
tore, andando ad astrarre la definizione del database e fornendo al programmatore
App mobile Geobox14 Progettazione
una via di "più alto livello" per gestire il tutto.
[15]
4.1.2.3 Docker
Storicamente, una volta sviluppata un’ applicazione e pronta per essere rilasciata, si
doveva incorrere in lunghi e talvolta complessi lavori di gestione e setup dell’hard-
ware sul quale l’applicativo dovrà eseguire.
Questo oltre ad essere dispendioso in termini di tempo, necessitava di figure specia-
lizzate e competenti (diverse dallo sviluppatore), andando a toccare ambiti concer-
nenti la sicurezza e il load balancing per citarne due tra i più importanti. Si doveva
porre attenzione alle versioni dei software in uso, in quanto l’ambiente di sviluppo de-
l/i programmatore/i poteva differire rispetto a quello presente sulla macchina adibita
al deploy, causando problemi talvolta critici all’interno dell’applicazione in esame.
Oggigiorno, con l’avvento del cloud e i progressi fatti in ambito di virtualizzazione, si
riesce a portare lo stesso ambiente di sviluppo in fase di deploy, eludendo il problema
delle versioni.
Docker è la piattaforma per lo sviluppo e il deploy di applicazioni in un ambiente
isolato e virtualizzato (containers), che separa l’applicazione dall’infrastruttura sotto-
stante. [16]
Si ottiene dunque un ulteriore livello di astrazione e isolamento tra l’applicazione e i
servizi sui quali dipende.
Lavorando con Docker, sono fondamentali i concetti di "container" e "image":
• Image: si tratta di un template definito in un file chiamato Dockerfile compren-
dente le istruzioni per creare un container nel quale sarà eseguita l’applicazio-
ne. Concettualmente si può fare un’analogia tra un’immagine Docker e una
classe Java: una classe Java definisce il blueprint di una particolare istanza di
oggetto appartenente a quella classe, mentre un’immagine definisce il template
di un container.
• Container: rappresenta l’effettiva istanza in esecuzione di un’immagine. Un
container è completamente isolato rispetto all’esterno ed è possibile controllare
la sua esecuzione (start, stop, delete).
Insieme a Docker, docker-compose è uno strumento per realizzare applicazioni multi
container, nelle quali ogni container rappresenta un servizio isolato a sè stante, tra
cui il container relativo all’applicazione stessa. In un ulteriore file di configurazione
(docker-compose.yml), si andrà a definire la struttura dell’architettura e dei suoi ser-
vizi, definendo networks e dischi di storage sui quali salvare i dati dell’applicazione.
[17]
App mobile Geobox15
La scelta di questa tecnologia in fase di progettazione pone le sue ragioni in ottica
di deployment; infatti una volta conclusa la fase di sviluppo, il backend non avrebbe
avuto possibilità di eseguire se non su una macchina locale, in una rete anche’essa
locale.
4 5
Soluzioni cloud quali AWS o GCP per citarne due tra le più note, le quali permet-
tono, attraverso una serie di servizi offerti, il deploy di un’applicazione sfruttando le
risorse presenti sul cloud.
Docker svolge la sua funzione anche in questo caso: indipendentemente dal Cloud
provider che si andrà a scegliere, la presenza di Docker permetterà di buildare il con-
tainer secondo il template definito nel Dockerfile e utilizzare l’immagine creata sul
servizio cloud scelto.
4.1.3 Database
Nel 2021, quando ci si imbatte nella scelta della tecnologia da utilizzare in ambito
database, diverse sono le considerazioni a cui far fronte:
da diversi anni infatti database di tipo NoSQL hanno cominciato a divenire uno stru-
mento fortemente utilizzato in seguito alla richiesta di realizzare applicazioni con
modelli flessibili e dinamici nel tempi [18] Questi si contrappongono ai più datati e
comuni approcci relazionali.
Infatti i trend degli ultimi anni (vedi Big Data) hanno accompagnato e tratto beneficio
dallo sviluppo di database altamente flessibili, in quanto non strutturati come i rela-
zionali, andando a persistere i propri dati in file chiamati "documenti". Chiaramente
questo ha un transfer sulle performance, sulla flessibilità e soprattutto si ha la possi-
bilità di distribuire orizzontalmente il carico e la ridondanza dei dati, in accordo con
l’avvento di tecnologie come i sistemi distribuiti. [19]
In contrapposizione, i rigidi vincoli che si presentano quando si lavora con database
relazionali non permettono questo tipo di scalabilità orizzontale, ma, dalla loro par-
te, hanno una forte semantica relativa all’integrità dei dati (principi ACID) e, data la
struttura stessa del database, uno spazio di storage ottimizzato [20].
Dando uno sguardo al contesto nel quale si sta operando, si è proceduto con l’adotta-
re una soluzione relazionale; come esposto il server dovrà fungere principalmente da
punto di accesso centralizzato ai dati che l’app dovrà andare a processare e, almeno
in questa fase di sviluppo, non si hanno particolari necessità riguardanti la ridondan-
za dei dati e la scalabilità orizzontale.
Inoltre i dati che si dovranno gestire sono facilmente intendibili secondo un classico
4
Amazon Web Services: https://aws.amazon.com/it/
5
Google Cloud Platform: https://cloud.google.com/
App mobile Geobox16 Progettazione
schema relazionale.
Da stato dell’arte dunque non si sono trovate evidenti motivazioni per adottare un
approccio più progressivo come quello dei database NoSQL.
Considerando quindi la scelta effettuata in quanto a framework backend, si è deciso
di scegliere MySQL come RDBMS di riferimento, dato che l’architettura di Spring per-
mette un ulteriore vantaggio in termini di integrazione con quest’ultimo.
[21]
4.2 Versioni
Indipendentemente dai requisiti proposti per il progetto di diploma, essendo Geobox
un’idea di applicazione che verrà portata avanti nel futuro e, data la notevole quantità
di requisiti iniziali e che si sono aggiunti nel tempo, si è pensato di suddividere il ciclo
di sviluppo dell’applicazioni in 3 versioni distinte. (4.1)
• Community Access: la versione realizzata durante questo progetto. L’obietti-
vo è porre le basi per l’infrastruttura informatica che andrà a supportare l’idea
di Geobox.
Dovrà permettere ai primi produttori locali che si approcciano all’applicazione
di prendere esperienza con l’applicazione.
• Producer tool: la seconda versione che andrà ad essere realizzata dovrà com-
prendere funzionalità approfondite sulla gestione dei propri container, aggiun-
gere o rimuovere quantità indefinite di prodotti all’interno dei container caricati,
previa generazione di QR per ognuno.
• e-commerce: l’ultima versione in termini di funzionalità dovrà integrare la pos-
sibilità di acquistare via app i prodotti contenuti nelle box, tenere traccia delle
transazioni avvenute e mostrare per ogni utente una lista di acquisti effettuata.
Gli acquisti dovranno appoggiarsi ad un circuito di pagamento digitale.
4.3 Architettura
In questa sezione verranno esposti i principi teorici/architetturali che hanno sostenuto
lo sviluppo del progetto a partire dalla base, andando a costituire lo scheletro teorico
a cui fare riferimento nel momento di codifica.
Relativamente a client e server, verranno esposti i pattern architetturali che hanno
definito il loro funzionamento, la divisione logica delle entità in gioco e le interazioni
tra loro. Si andrà a descrivere la struttura del database proponendo il diagramma E-R
App mobile Geobox17
Figura 4.1: Suddivisione versioni
utilizzato in fase di progettazione ed infine si darà uno sguardo alla struttura della
REST API realizzata.
4.3.1 Client
Utilizzando Flutter come framework, diverse sono le soluzioni percorribili nella scelta
del pattern architetturale da adottare. Questa scelta, essendo Flutter un framework
dichiarativo, si rifletterà poi nel cosiddetto state management dell’applicazione.
Consultando la documentazione ufficiale di Flutter, vengono proposti diversi approcci,
tra cui:
• Provider 6 : L’approccio raccomandato dagli sviluppatori. 4.2
Si tratta di un package sviluppato da terzi che con il tempo è stato apprezzato
ed adottato dagli stessi sviluppatori di Flutter. [22] Esso incapsula al suo interno
l’approccio low-level precedentemente consigliato per il framework, l’Inherited
Widget. (vedi 4.3.1.2) Questo approccio permette una grande flessibilità a li-
vello delle classi di logica lato client, permettendo una stretta interazione tra
componenti senza andare ad intaccare il fattore accoppiamento. [50].
Questo particolare approccio si integra piuttosto bene con il noto MVVM.
6
provider: https://pub.dev/packages/provider
App mobile Geobox18 Progettazione
Figura 4.2: Riconoscimento Flutter Favorite - Provider
Bloc 7 : Bloc sta per Business Logic Component e oltre ad essere una
libreria implementa un vero e proprio pattern architetturale. Com-
ponente principale sono gli Stream di observables [53]. Infatti ogni
layer dell’architettura comunica con quello sottostante/sovrastante at-
traverso gli stream emessi o in entrata. 4.3
I layer proposti sono tre:UI, ovvero la View della nostra applicazione
Bloc, strato principale che si occupa della gestione degli eventi e degli
stati attraverso gli stream Data, strato atto a rendere accesso ai dati
dell’applicazione
Figura 4.3: Bloc pattern
8
–
* Redux : approccio ben più utilizzato in contesti di framework web (React,
Angular), si avvale del porting specifico per l’ambiente Flutter. Viene ci-
tato per semplice stato dell’arte in quanto non è stato considerato il suo
ipotetico utilizzo in questo progetto.
4.3.1.1 UI
La definizione della UI non ha seguito il processo comunemente utilizzato; solitamen-
te, infatti, si tende a realizzare in primis un mockup dell’interfaccia utente, verificando
la sua coerenza e appeal sotto ogni punto di vista e modificandola secondo requisiti
7
Bloc: https://bloclibrary.dev//
8
flutter_redux: https://pub.dev/packages/flutterr edux
App mobile Geobox19
del committente. In questo senso, Flutter ha permesso una protipazione rapida [54]
dell’interfaccia utente, andando a saltare la fase di mocking della UI.
Il vantaggio è stato quello di avere un approccio realmente agile dati i meeting set-
timanali con il committente. Questo ha permesso una rapida definizione dello stile
generale della UI, ispirandosi ancora una volta allo stato dell’arte di riferimento.
Il design generale ha fatto uso dei componenti Material Design presenti in Flutter:
in questo senso si sono seguite le guidelines relative al design descritte nel Material
Manifesto [23]. Nonostante ciò, si è voluto ottenere un look-and-feel che sia specifico
e peculiare rispetto al progetto Geobox, andando a modificare secondo le esigenze i
componenti esistenti.
Di seguito si vogliono brevemente descrivere i tratti contraddistintivi e salienti del-
l’interfaccia sviluppata.
4.3.1.1.1 Mappa
La mappa rappresenta il cuore pulsante dell’applicazione; si trova come prima scher-
mata e permette di svolgere la funzionalità principale che si vuole offrire in questo
progetto. Su di essa è possibile localizzare i container sparsi lungo il territorio attra-
verso dei marker indicanti la posizione di quest’ultimi. I marker sono interattivi e ,una
volta premuti, si ha la possibilità di visualizzare dettagli attraverso un bottom sheet.
[24]. Da qui sarà a sua volta possibile raggiungere la schermata di dettaglio del con-
tainer o aggiungere il container tra i propri preferiti.
Sulla mappa è possibile visualizzare risultati filtrati: è presente una shortcut che per-
mette facilmente di raggiungere una schermata, nel quale è possibile filtrare i con-
tainer da visualizzare sulla mappa secondo una stringa di ricerca o specifici tag. I
risultati saranno poi visibili o sulla mappa o in formato di lista.
La shortcut per la ricerca e la relativa schermata, come suggerisce il nome, avreb-
bero dovuto avere il compito di permettere all’utente di filtrare i container a piacere
senza interrompere l’esperienza dell’applicazione. Al fine, utilizzare una schermata
differente avrebbe portato quei secondi di ritardo non ammissibili in questo contesto.
Inoltre il risultato visivo sarebbe stato pessimo, in quanto cambiare schermata sareb-
be risultato in una bassa coesione tra schermate e funzionalità.
Si è quindi voluta creare una transizione più fluida e naturale. Come visibile da imma-
gini 4.5 e 4.4, la shortcut è "galleggiante" - dall’inglese floating - e una volta premuta
non va a creare una nuova schermata andando a reindirizzare l’utente ad essa, ben-
App mobile Geobox20 Progettazione
si’, utilizzando un’animazione di un package di Flutter 9 , va ad espandere la sua area
ponendosi al di sopra della schermata corrente e andando a visualizzare il contenuto
della schermata di ricerca.
Figura 4.4: Floating button - Closed
4.3.1.1.2 Bottom sheets
Questo tipo di visualizzazioni è stato utile nel mostrare informazioni contestuali cer-
cando di essere coerenti con il principio di coesione tra componenti grafici citato pre-
cedentemente.
Non sarebbe stato piacevole per l’utente scorrere diverse schermate per ottenere
l’informazione desiderata, questo avrebbe confluito in un golfo di valutazione ecces-
sivamente dilatato. [25]
9
animations: https://pub.dev/packages/animations
App mobile Geobox21
Figura 4.5: Floating button - Open
Con l’utilizzo dei cosiddetti bottom sheet è possibile visualizzare un qualsiasi tipo di
informazione secondaria richiesta dall’utente. Esso rappresenta uno strato di overlay
rispetto alla schermata sottostante, dando la possibilità all’utente di rimuoverlo se-
condo desiderio (modal bottom sheet).
Solitamente vengono utilizzati per mostrare liste o contenuti di dettaglio.
Diversi sono stati gli utilizzi all’interno del progetto, infatti, sempre seguendo le Ma-
terial guidelines, un bottom sheet deve visualizzare un’informazione complementare
alla schermata in analisi, supportando le informazioni di interesse, in un’area ergono-
mica e facilmente raggiungibile. [26]
4.3.1.1.3 Slivers
Si definisce Sliver una porzione di area scrollabile che può essere utilizzata per otte-
nere particolari tipi di scrolling lungo la schermata corrente. [56]
App mobile Geobox22 Progettazione
Risulta comune la necessità di dover rendere una schermata scrollabile in quanto in-
capace di mostrare l’intero contenuto, rimanendo nelle dimensioni del device sulla
quale essa è visualizzata.
Questo comporta l’utilizzo di specifici meccanismi atti a permettere all’utente di scor-
rere lungo la pagina al fine di visualizzare l’intero contenuto.
Facendo riferimento ad applicazioni ben più affermate, come Gmail 10 e Note di Keep
11
, per citarne due prodotte da Google, si può notare come, nella schermata principa-
le, vi sia una barra di ricerca "galleggiante" (floating).
Successivamente, quando si prova a scorrere la lista presente a schermo, questa bar-
ra scompare per poi riapparire al primo scroll a ritroso.
Questo comportamento può essere sintetizzato e associato al comportamento di un
ipotetico Sliver in Flutter. Così è stato nell’interfaccia grafica Geobox; nelle immagini
4.6, 4.7 si può vedere come nella schermata di ricerca il comportamento della barra
di ricerca è accostabile, se non identico, a quello esposto dalle applicazioni di Google
citate.
Si fa riferimento alle parole di Jakob Nielsen [27], gli utenti passano la maggior parte
del loro tempo su altre applicazioni. Questo significa che preferirebbero che quella
che si trovano davanti funzionasse nel modo che già conoscono.
4.3.1.1.4 Search bar
Nella schermata di ricerca è possibile, attraverso una barra di ricerca, filtrare la lista
dei container. Secondo l’architettura prevista, il compito dell’effettiva ricerca è sgra-
vato al server, lasciando al client direttamente i dati elaborati.
Così facendo si necessita di effettuare delle richieste lato client verso il server qualora
il contenuto di testo della barra di ricerca sia modificato.
Risulta chiaro che se un ipotetico utente si mettesse a scrivere 10 caratteri per secon-
do, dopo 10 secondi il client avrebbe effettuato 100 richieste verso il server intasando
inutilmente la rete.
Il caso preso in esempio rappresenta un’ eventualità estrema, ma in ogni caso è un
fattore non trascurabile in fase di progettazione di interfacce grafiche.
Proprio per questo alla ricerca effettuata viene applicata una particolare tecnica atta
a limitare il numero di volte che una funzione viene eseguita in un particolare slice di
tempo.
Nel caso di questo progetto si è utilizzata una tecnica chiamata Debounce. [28] Una
funzione, così, verrà chiamata solamente dopo che sarà intercorso k tempo dall’ulti-
ma chiamata effettuata. Stabilendo un k pari a 400 ms si avrà dunque una barra di
ricerca che invoca la funzione desiderata solo 450 ms dopo che l’utente ha smesso di
10
Gmail: https://mail.google.com/
11
Keep: https://www.google.it/keep/
App mobile Geobox23
Figura 4.6: Sliver search bar - hidden
generare eventi su di essa.
La scelta della tempistica è stata effettuata ponendo attenzione ai riscontri ottenuti
in fase di test dell’applicazione e basandosi sulla legge di Fitts. [29]. Secondo Fitts,
il tempo che un umano impiega per inquadrare un obiettivo è una funzione della di-
stanza e delle dimensioni del bersaglio, in questo caso lo smartphone.
Proprio per questa ragione, in questo contesto tempistiche che ricadono tra i 250-450
ms sono comunemente utilizzate.
4.3.1.2 State management
L’approccio che si è deciso di adottare in ambito state management è stato quello
consigliato da Google stessa, ovvero l’utilizzo del package provider in un’ architettu-
ra MVVM. Il MVVM (Model-View-ViewModel) (4.8) costituisce il pattern ormai maggior-
mente utilizzato dai framework dichiarativi odierni [30] [31].
App mobile Geobox24 Progettazione
Figura 4.7: Sliver search bar - shown
Questo perchè l’idea di avere uno strato logico atto a recepire gli eventi dell’utente,
processarli secondo logica e restituendoli in una rappresentazione tale per cui lo stra-
to di View sia capace a comprenderli e processarli, risulta particolarmente efficiente
lavorando con interfacce grafiche. [32]. L’astrazione nei confronti dello strato di View
permette di avere una minore quantità di business logic necessaria al funzionamento
dei componenti UI.
Attraverso tecniche di binding, si va quindi a definire le interazioni tra i vari com-
ponenti della UI, la loro integrazione e la loro comunicazione con funzionalità di più
basso livello, come l’accesso ai dati.
A tutti gli effetti, le classi di ViewModel, almeno in questa specifica implementazione,
rappresentano un wrapper nei confronti delle corrispettive classi di modello. La UI
è dunque completamente ignara del modello sottostante se non per le informazioni
ricevute da ViewModel relativo. Nell’implentazione di Geobox due possono essere i
App mobile Geobox25
Figura 4.8: Diagramma a blocchi - MVVM
tipi di classi ViewModel presenti:
• Widget ViewModel: sono quelle classi ViewModel che non hanno un modello a
cui fare riferimento. Come suggerisce il nome rappresentano la logica necessa-
ria al funzionamento dietro i singoli componenti. Definiscono il comportamento
globale di determinati widget e la loro interazione con widget secondari.
Non si occupano di gestire dati dell’applicazione.
• Standard ViewModel: questi ViewModel hanno il compito di gestire e processa-
re i dati provenienti dalle corrispettive classi di modello. A differenza dei primi,
questo tipo di ViewModel non solo fornisce rappresentazioni per la UI ma prov-
vede anche specifiche funzionalità per l’interfacciamento con i livelli sottostanti.
Costituiscono il fulcro dell’applicazione.
4.3.1.2.1 Provider
Il package Provider funge da astrazione al meccanismo base di propagazione di infor-
mazione lungo l’albero di widget in Flutter, chiamato Inherited Widget 12 . Inizialmente
l’Inherited Widget rappresentava l’approccio di state management di riferimento.
Questo approccio permette appunto la propagazione di dati lungo i rami del widget
tree, permettendo inoltre la notifica dei discendenti qualora un valore a cui si sono
sottoscritti andasse a variare.
La sintassi per orchestrare un funzionamento simile è da sempre risultata macchino-
sa e proprio a questo scopo viene utilizzato il package Provider.
Esso mette a disposizione un metodo più pulito e conciso per propagare i dati lungo i
rami dell’albero, al pari dell’Inherited Widget, attraverso una sintassi semplificata.
Insieme al MVVM permette di creare componenti flessibili e meno proni ad errori, gra-
12
Inherited Widget: https://api.flutter.dev/flutter/widgets/InheritedWidget-class.html
App mobile Geobox26 Progettazione
zie ad una struttura che permette una più fine gestione degli errori.
4.3.2 Server
Il processo che ha portato alla stesura della parte server è stato decisamente più
diretto; dal momento che le necessità lato backend permangono piuttosto modeste,
non si è voluta sovraingegnerizzare l’architettura generale ma bensì si è voluto man-
tenere un approccio semplice e funzionale, ancora una volta in ottica di tempistiche.
Sarebbe stato inutile orchestrare un backend eccessivamente ricco di funzionalità, in
quanto in questa fase di progetto il client non sarebbe stato in grado di usufruirne.
Si è posto il focus maggiormente sull’architettura software e sul renderla il più modu-
lare possibile, facilitando gli eventuali sviluppi futuri.
Trovandosi in ambiente Java e potendo sfruttare appieno della potenza dei costrut-
ti tipici della programmazione ad oggetti, l’architettura tipica di un server Spring si
basa sul concetto di layers. [33]
4.3.2.1 Architettura a livelli
Architettura viene suddivisa su tre livelli di astrazione differenti: (4.9)
• Web Layer: rappresentato dalle classi Controller presenti nell’architettura di
riferimento. Rappresentano il punto di accesso centralizzato per determinate ri-
sorse attraverso l’endpoint che espongono e che il client andrà a consumare.
Si occupa di ricevere le richieste provenienti dal client e gestire la rappresenta-
zione dei dati da fornire ai livelli sottostanti. A questo livello avviene la conver-
sione entity-DTO e viceversa
• Service Layer: si occupa di tutta la business logic del backend. A questo livello
viene segregato il compito di gestire le complesse interazioni del sistema. Si
tratta di oggetti modulari e riutilizzabili a piacimento dal Web Layer sovrastante.
• Data Layer: rappresentato dalle classi di modello e dai repository. A questo
livello si maneggiano i dati nella loro forma più grezza e vengono fornite le loro
corrette rappresentazioni per gli strati superiori.
I repsitory si occupano di fornire accesso al database, astraendo il concetto di
database e rendendo l’interazione diretta via codice. I modelli, in questo senso,
si occupano di definire le relazioni tra le entità.
4.3.2.2 Data Transfer Objects
Dal momento che si fa uso delle classi di modello al fine di referenziare le corrispet-
tive entità nel database, diverrebbe scomodo e macchinoso gestire la serializzazio-
App mobile Geobox27
Figura 4.9: Architettura a livelli - Server
ne/deserializzazione dei POJO a JSON e soprattutto potrebbe risultare notevolmente
dispendioso in termini di tempo. Per questo si fa uso di un particolare pattern chia-
mato Data Transfer Object. [34]
Il concetto che giace dietro consiste nel definire una copia degli oggetti che verranno
utilizzati in entrata e uscita dal server, utilizzati al posto delle classi di modello, man-
tenute trasparenti.
I DTO non forniscono funzionalità bensì la loro unica funzione è di storage. Questi
vengono convertiti a livello dei Controller (Web Layer) attraverso componenti chia-
mati Object Mappers.
Un Object Mapper è una classe che si occupa di gestire la conversione di un DTO nella
relativa entità e viceversa. Questo viene fatto appoggiandosi direttamente ai reposi-
tory, soprattuto in fase di conversione DTO->entity, in quanto è importante ricevere
la corretta referenza all’entita specifica e non una copia. Oggigiorno vengono utilizza-
te librerie come ModelMapper 13 , in grado di automaticamente generare le funzioni di
conversione riducendo notevolmente il codice boilerplate. Nonostante ciò, in questo
13
ModelMapper: http://modelmapper.org/
App mobile GeoboxPuoi anche leggere
