POLITECNICO DI TORINO - Corso di Laurea in Ingegneria Informatica
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
POLITECNICO DI TORINO
Corso di Laurea in Ingegneria Informatica
Tesi di Laurea Magistrale
Progetto e implementazione di
un’architettura mobile a supporto della
gestione logistica dei processi produttivi
Relatore Candidato
Prof. Giovanni MALNATI
Domenico PIZZATA
Aprile 2021
Alla mia famiglia,
sempre al mio fianco,
nei momenti belli
e in quelli brutti.
Questo traguardo,
lo dedico a voi.
ii
Sommario
Viviamo in una società all’ordine dei dati e tendenzialmente ad ogni ora del giorno
possiamo riceverne e trasmetterne. Ogni secondo, una grande quantità di dati
viaggia in tutto il mondo e ormai riusciamo a controllarla direttamente da una mano,
grazie ad uno smartphone, una cosa impensabile fino al secolo scorso. Raccogliere ed
analizzare i dati in modo preciso e puntuale sono, al giorno d’oggi, delle procedure
rilevanti e fondamentali soprattutto per le aziende. La moltitudine di interpretazioni
e possibili usi dei dati si trasforma però in uno scoglio nel processo di sviluppo di un
meccanismo automatizzato, che porti le applicazioni ad essere rapide e funzionali
in contesti dove il tempo gioca un ruolo chiave.
In questa tesi si affronta oltre ai problemi della raccolta e del trattamento dei
dati, anche il problema dell’automazione in processi logistici, in particolare, con
una soluzione al problema della configurazione delle applicazioni per dispositivi
mobili, con sistema Android. Si riferisce ad un contesto industriale dove si opera
in modo ordinario con la scansione e la trasmissione di tag RFID, codici a barre e
QR code, richiedendo quindi una notevole facilità e velocità nella configurazione
e nell’utilizzo delle applicazioni, per agire in modo corretto e tempestivo su una
vasta scala di prodotti che forniscono i dati per il progetto.
Nella prima parte dell’elaborato, si introducono i problemi presenti in contesti
lavorativi dove è necessario avere la massima funzionalità nel minor tempo possibile,
discutendo di come le applicazioni possono usare i dati per arrivare a questo
obbiettivo.
Nelle parti successive, si descrivono le scelte progettuali ed implementative con
una possibile soluzione ai problemi sopra introdotti, sfruttando le caratteristiche di
Android e le librerie messe a disposizione per programmare i dispositivi elettronici
utilizzati. Si espongono nel dettaglio alcune delle principali applicazioni sviluppate
per permettere le funzionalità necessarie.
Infine, sono proposti degli sviluppi futuri a questo progetto analizzando il lavoro
svolto fino a questo momento.
iii
Indice
Elenco delle figure vii
Abbreviazioni ix
1 Il problema dei dati nelle applicazioni 1
1.1 Operare con i dati . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 I dati in un contesto logistico . . . . . . . . . . . . . . . . . . . . . 2
1.3 Lo Standard EPCIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Configurazione delle applicazioni . . . . . . . . . . . . . . . . . . . . 5
2 Caratteristiche e specifiche di sistema 8
2.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Architettura Android . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 Applicazioni Android . . . . . . . . . . . . . . . . . . . . . . 10
2.1.3 Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Dispositivi elettronici utilizzati . . . . . . . . . . . . . . . . . . . . 12
2.2.1 TC20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 RFD2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Funzionalità delle applicazioni . . . . . . . . . . . . . . . . . . . . 14
2.4 Backend del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 Il server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2 Il database . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.3 L’utilizzo di Docker . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.4 Swagger come strumento di supporto . . . . . . . . . . . . . 19
2.5 Analisi dello scenario di operazione . . . . . . . . . . . . . . . . . . 19
3 Sviluppo e progettazione 22
3.1 Java e Kotlin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Build di progetti Android complessi . . . . . . . . . . . . . . . . . . 23
3.3 L’uso di Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Il pattern Model-View-ViewModel . . . . . . . . . . . . . . . . . . . 26
v
3.5 Autoconfigurazione dei dispositivi . . . . . . . . . . . . . . . . . . . 27
3.5.1 Installazione dinamica delle applicazioni . . . . . . . . . . . 28
3.6 Progettazione delle applicazioni . . . . . . . . . . . . . . . . . . . . 28
3.6.1 User Experience . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6.2 Progettazione del launcher . . . . . . . . . . . . . . . . . . . 30
3.6.3 Progettazione delle app per i processi logistici . . . . . . . . 31
4 Implementazione del software 34
4.1 Software per gestire i tag RFID . . . . . . . . . . . . . . . . . . . . 34
4.2 Software per gestire barcode e QR code . . . . . . . . . . . . . . . . 35
4.3 Implementazione delle applicazioni . . . . . . . . . . . . . . . . . . 36
4.3.1 Download e installazione di APK . . . . . . . . . . . . . . . 36
4.3.2 Autenticazione client . . . . . . . . . . . . . . . . . . . . . . 37
4.3.3 TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.4 OkHttp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.5 Implementazione del launcher . . . . . . . . . . . . . . . . . 41
4.3.6 Implementazione della parte comune delle app per la gestione
dei processi logistici . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.7 Implementazione dell’app per la registrazione di un prodotto 47
4.3.8 Implementazione dell’app per il tracciamento di un prodotto 49
4.3.9 Implementazione dell’app per l’impacchettamento di prodotti 51
4.3.10 Implementazione dell’app per la verifica di un ordine . . . . 53
5 Conclusioni 57
5.1 Possibili sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . 58
Bibliografia 60
vi
Elenco delle figure
1.1 Tracciabilità delle merci . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Cause di tempi di inattività non pianificati . . . . . . . . . . . . . . 5
2.1 Architettura Android . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Mobile computer TC20 . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Culla palmare RFID UHF RFD2000 . . . . . . . . . . . . . . . . . 14
2.4 Esempio di modello client-server . . . . . . . . . . . . . . . . . . . . 16
2.5 Esempio di architettura delle API RESTful . . . . . . . . . . . . . . 17
2.6 Virtual machines vs containeiners . . . . . . . . . . . . . . . . . . . 18
3.1 Architettura di Room . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Implementazione del MVVM . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Struttura del modello di Garrett . . . . . . . . . . . . . . . . . . . . 30
4.1 Flusso di autenticazione con JWT . . . . . . . . . . . . . . . . . . . 37
4.2 TLS - fase di handshake 1 . . . . . . . . . . . . . . . . . . . . . . . 39
4.3 TLS - fase di handshake 2 . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Architettura RecyclerView . . . . . . . . . . . . . . . . . . . . . . . 42
4.5 Launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.6 Eventi salvati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.7 App per la registrazione di un prodotto 1 . . . . . . . . . . . . . . . 48
4.8 App per la registrazione di un prodotto 2 . . . . . . . . . . . . . . . 48
4.9 App per la registrazione di un prodotto 3 . . . . . . . . . . . . . . . 48
4.10 Scansione barcode, QR code e tag RFID . . . . . . . . . . . . . . . 49
4.11 App per il tracciamento di un prodotto 1 . . . . . . . . . . . . . . . 50
4.12 App per il tracciamento di un prodotto 2 . . . . . . . . . . . . . . . 50
4.13 App per l’impacchettamento di prodotti . . . . . . . . . . . . . . . 52
4.14 App per la verifica di un ordine 1 . . . . . . . . . . . . . . . . . . . 54
4.15 App per la verifica di un ordine 2 . . . . . . . . . . . . . . . . . . . 54
vii
Abbreviazioni
API
Application Programming Interface
APK
Android PacKage
ARM
Advanced RISC Machines
COO
Chief Operating Officer
CPU
Central Processing Unit
DVM
Dalvik Virtual Machine
EPC
Electronic Product Code
EPCIS
Electronic Product Code Information Services
GPS
Global Positioning System
GS1
Global Standards
ixGLN
Global Location Number
GTIN
Global Trade Item Number
GUI
Graphical User Interface
GZIP
GNU ZIP
HTTP
HyperText Transfer Protocol
IDE
Integrated Development Environment
JSON
JavaScript Object Notation
JWT
Json Web Token
MVVM
Model View ViewModel
OAS
OpenAPI Specification
OOP
Object Oriented Programming
OS
Operating System
RAM
Random Access Memory
xREST
REpresentational State Transfer
RFID
Radio Frequency IDentification
SDK
Software Development Kit
SGLN
S Global Location Number
SGTIN
S Global Trade Item Number
SSL
Secure Sockets Layer
TLS
Transport Layer Security
UHF
Ultra High Frequency
UI
User Interface
URL
Uniform Resource Locator
UX
User eXperience
VM
Virtual Machine
xiCapitolo 1
Il problema dei dati nelle
applicazioni
Le operazioni di raccolta, trasmissione e analisi dei dati, che ricoprono una signifi-
cativa parte di lavoro all’interno di un’azienda, sono dei processi potenzialmente
cruciali che possono portare a complicazioni non trascurabili per lo sviluppo e la
buona riuscita di un progetto.
Riguardo lo sviluppo di un’applicazione, che essa sia mobile o web, le precedenti
operazioni sono ancora più importanti se si vuole sviluppare un software affidabile e
robusto, essendo un’applicazione dipendente da tali dati in molte fasi come durante
quella di configurazione.
1.1 Operare con i dati
Ormai ci troviamo ad avere a che fare con dati ovunque. Queste moli di informazioni
richiedono spesso grandi capacità di progettazione per risolvere in modo efficace ed
efficiente il problema per il quale sono stati raccolti ed analizzati.
Esistono molti modi per raccogliere i dati e anche molti dispositivi elettronici
capaci di farlo. Alcuni dati si possono estrapolare dalle informazioni già raccolte e
spesso essere anche trasmessi per essere analizzati in un secondo momento, dando
origine anche al problema dell’ interpretazione. Ci sono diversi standard che aiutano
quando si opera con i dati e le aziende devono capire quale fa al caso loro, per i
propri scopi ed obbiettivi.
Per le aziende è molto importante evitare di commettere errori in queste fasi
perchè una cattiva attività di raccolta, organizzazione ed interpretazione dei dati
può portare ad una perdita di guadagno, quindi è obbligatorio prendere le giuste
contromisure prima di imbattersi in problemi di questa natura [1].
1Il problema dei dati nelle applicazioni
Inoltre, occorre anche essere precisi nella raccolta, per partire fin da subito con
i dati corretti e non imbattersi in errori ancor prima di operare. Per questo motivo,
molte aziende si occupano di produrre dispositivi elettronici capaci di acquisire
le informazioni nel modo migliore possibile. Si descrive nei capitoli successivi la
tecnologia utilizzata in questo lavoro di tesi e quindi anche dei dispositivi elettronici
impiegati nella lettura dei dati necessari.
1.2 I dati in un contesto logistico
Quando si parla di logistica, non si può non pensare a grandi quantità di merci
sottoposte ad una serie di processi che richiedono una buona conoscenza dei dati
trattati. Tra le principali operazioni riconducibili a questo contesto troviamo:
• Organizzazione delle operazioni e dei sistemi di trasporto e stoccaggio, per
ottimizzare il flusso delle merci.
• Organizzazione e gestione dei centri di distribuzione per il ricevimento e lo
smistamento delle merci.
• Monitoraggio delle consegne degli ordini ai centri di distribuzione e ai punti
vendita.
• Monitoraggio delle consegne effettuate e dell’integrità dei prodotti.
• Organizzazione del sistema informatizzato degli ordini.
• Controllo dei costi delle operazioni.
• Problem solving relativo al trasporto merci.
Si intuisce che nelle operazioni elencate, se i dati vengono trattati nella maniera
più consona, i processi risultano guadagnare in facilità e rapidità e queste sono
caratteristiche ormai necessarie per tenersi al passo con i tempi. Molto esplicito
a questo riguardo è stato Claudio Caremi, COO di OPTIT, che riguardo il tema
della ottimizzazione della logistica di fabbrica, sottolinea il fatto che per le aziende
che si vogliono affermare, essere rapidi nel supportare le decisioni con i dati è
diventato un "must have" [2]. Questo è facilmente intuibile, pensando alla grossa
quantità di prodotti presenti nei più grandi magazzini. Risulta impensabile svolgere
questi processi nel modo corretto e in poco tempo senza una buona raccolta e
un buon trattamento dei dati, utilizzando il giusto hardware e software studiati
appositamente per operare in questo contesto.
2Il problema dei dati nelle applicazioni
1.3 Lo Standard EPCIS
Soprattutto in un contesto logistico, avere ben chiaro il ciclo di vita di un prodotto
è molto importante. EPCIS è uno standard GS1 per il monitoraggio in tempo reale
e permette di tracciare l’intera vita del prodotto su tutta la filiera. Nella Figura 1.1
è possibile vedere un esempio di tracciamento del prodotto lungo la supply chain.
Figura 1.1: Tracciabilità delle merci
Per conoscere la storia di un particolare oggetto durante un determinato momento
della sua vita, questo standard ricorre a quattro domande, rispondendo alle quali è
possibile tracciare il prodotto. Queste domande sono:
• Cosa? (Gli identificatori dell’oggetto)
• Quando? (La data e l’ora in cui si è verificato l’evento)
• Dove? (L’identificativo del luogo in cui si è verificato l’evento)
3Il problema dei dati nelle applicazioni
• Perchè? (Informazioni sul contesto aziendale)
Per permettere di raccogliere ed associare i dati al prodotto considerato però è
indispensabile che questo sia identificabile per mezzo di:
• GTIN + numero seriale.
• GTIN + lotto.
Il GTIN è la chiave GS1 usata in tutto il mondo per identificare i prodotti
e tracciarli. Ne esistono di diversi tipi, in accordo con il tipo di prodotto da
identificare.
• GTIN-8: codici di 8 cifre formati da codice prodotto e cifra di controllo, usati
per identificare prodotti a peso fisso.
• GTIN-13: codici di 13 cifre formati da prefisso aziendale GS1, codice prodotto
e cifra di controllo, usati per identificare prodotti a peso fisso, prodotti a peso
variabile e unità imballo a peso fisso.
• GTIN-14: codici di 14 cifre formati da indicatore, GTIN-13 del prodotto
contenuto senza cifra di controllo e cifra di controllo, usati per identificare
unità imballo a peso fisso e unità imballo a peso variabile.
• SGTIN: codici generati a partire dal GTIN dell’unità commerciale e completato
da un identificativo seriale che è il numero che l’azienda assegna univocamente
al singolo pezzo, usati per identificare prodotti a peso fisso e unità imballo a
peso fisso.
Il GLN è la chiave GS1 usata per identificare sedi legali e operative, reparti interni,
magazzini, fabbriche ecc. Mentre l’SGLN serve per identificare univocamente un
punto interno ad un luogo dell’azienda che è già identificato con un GLN.
In questa tesi, questo standard è stato usato ampiamente, dal momento che la
maggior parte dei dati riguardanti i prodotti, sono trasmessi per essere analizzati
attraverso degli eventi EPCIS. Le tipologie di eventi che lo standard mette a
disposizione sono:
• Evento oggetto: gli oggetti specificati hanno partecipato a un evento.
• Evento di aggregazione: gli oggetti figlio specificati sono stati aggregati
fisicamente a (o disaggregati da) l’oggetto padre specificato.
• Evento di trasformazione: gli oggetti di input specificati sono stati utilizzati e
gli oggetti di output specificati sono stati prodotti.
4Il problema dei dati nelle applicazioni
• Evento di transazione: gli oggetti specificati sono stati definitivamente associati
(o dissociati) con le transazioni commerciali specificate.
• Evento quantità (obsoleto): la quantità specificata della classe specificata ha
partecipato a un evento. L’evento quantità è deprecato poiché è stato incluso
nelle nuove funzionalità aggiunte all’evento oggetto.
Se implementato correttamente, questo standard può portare a molti benefici
tra i quali migliorare e facilitare i processi logistici grazie ad informazioni accurate
e gestione efficiente dell’inventario [3].
1.4 Configurazione delle applicazioni
Le applicazioni richiedono spesso un gran numero di dati per funzionare corretta-
mente e svolgere le attività per le quali sono state sviluppate. Questi dati possono
servire in punti diversi della vita di un’applicazione e possono essere recuperati da
svariate fonti, come un database, uno o più file, un input dell’utente e così via.
Una delle prime fasi in cui servono sicuramente dei dati è la fase di configurazione,
in cui vengono modificate le caratteristiche funzionali dell’applicazione dopo la
sua installazione. Durante questa fase viene inizializzato il sistema ed è buona
norma farla durare il minor tempo possibile, sia perchè potrebbe essere snervante
aspettare per l’utente, sia perchè le funzionalità dell’applicazione potrebbero servire
nell’immediato, come nel caso di un processo di un’azienda dove il tempo per
svolgere un’attività potrebbe essere centellinato. Sorge quindi il problema di
dover rendere questa fase il più breve possibile, ma d’altro canto si vuole avere
un’applicazione ben configurata per garantire funzionalità e sicurezza.
Figura 1.2: Cause di tempi di inattività non pianificati
5Il problema dei dati nelle applicazioni
Una delle operazioni che genera più errori e perdita di tempo in questa fase è
far configurare il sistema direttamente a mano all’utente, inserendo per esempio
input da tastiera, e se non sono dati che variano il sistema potrebbe configurarsi da
se con maggiore rapidità e sicurezza. Nella Figura 1.2 si può vedere la conclusione
tratta da studi che hanno valutato i tempi di fermo non pianificati quando si ha
a che fare con un software [4], anche nella fase di configurazione. Molti di questi
tempi sono dovuti ad errori da parte dell’uomo come è possibile notare, ricoprendo
il 40% del grafico.
Un dato di fatto è che, al giorno d’oggi, ci si muove convintamente verso la
direzione dell’automazione riducendo la necessità dell’intervento umano. Serve un
primo sforzo per permettere alle macchine di svolgere da sole questo processo, ma
se ben programmate i risultati sono migliori e soprattutto ci sono meno errori.
Questo è un punto chiave del quale si discute in questa tesi, fornendo una
possibile soluzione al problema nel caso di applicazioni mobili in un contesto
logistico.
67
Capitolo 2
Caratteristiche e specifiche
di sistema
Prima di entrare in dettaglio nella spiegazione dell’implementazione svolta per
questa tesi, è utile capire i principi e la tecnologia hardware e software che stanno
dietro. Si è già detto nel primo capitolo, che l’idea base di questo lavoro è ottimizzare
i processi produttivi per garantire la loro corretta esecuzione nel minor tempo
possibile. Per fare questo, si è ricorso ai prodotti dell’azienda Zebra, produttrice
di dispositivi elettronici di ottima qualità, utilizzati da molte altre compagnie in
tutto il mondo. Il software sviluppato appositamente per sistemi Android, segue
il principio di ricorrere solo alle funzionalità necessarie volta per volta, infatti
in seguito viene trattata l’installazione dinamica e come essa aiuta anche a non
appesantire i dispositivi senza motivo e a velocizzare i tempi, in un processo di
autoconfigurazione dei dispositivi. Si fa anche una breve introduzione degli elementi
del backend con cui comunicano le applicazioni mobili sviluppate e dello scenario
di operazione.
2.1 Android
Dal momento che tutto il software sviluppato deve convivere in dispositivi con SO
Android, è opportuno capire le caratteristiche base che permettono il funzionamento
delle applicazioni al suo interno. Android è un sistema operativo per dispositivi
mobili sviluppato da Google. Viene utilizzato principalmente in sistemi embedded
come smartphone e tablet, ed è possibile trovarlo anche in TV, automobili, orologi,
occhiali e altri. Un altro dispositivo con SO Android è il TC20, che viene introdotto
in seguito. Le applicazioni Android sono scritte principalmente nei linguaggi di
programmazione come Kotlin e Java e usano lo stesso SDK.
82.1.1 Architettura Android
Android ha un’architettura gerarchica con strutturata a layer come mostrato nella
Figura 2.1.
Figura 2.1: Architettura Android
I layer comprendono un sistema operativo, un insieme di librerie native per le
funzionalità core della piattaforma, una implementazione della VM e un insieme di
librerie Java.
Il livello più basso è rappresentato dal kernel Linux che gestisce le periferiche
multimediali, il display, le connessione Wi-Fi e Bluetooth, l’alimentazione, il GPS,
la fotocamera ecc. La scelta di un kernel Linux si spiega attraverso la necessità
di avere un’alta affidabilità per esempio, per garantire il servizio di telefonia. Gli
utenti si aspettano l’affidabilità, ma allo stesso tempo vogliono un dispositivo che
possa garantire servizi più evoluti e Linux permette di raggiungere entrambi gli
scopi.
Salendo nella gerarchia troviamo un insieme di librerie native scritte C e C++ e
l’Android Runtime. Quest’ultimo è costituito dalle librerie core Java e dalla DVM,
una Virtual Machine ottimizzata per sfruttare la poca memoria dei dispositivi
mobili e di cui ogni applicazione dispone di un’istanza. Le librerie invece fanno
9parte di un insieme di progetti Open Source che aiutano nella gestione di tutto il
sistema.
Al prossimo livello si trova l’Application Framework, costituito da un insieme
di componenti che utilizzano le librerie native. Si tratta di un insieme di API e
componenti per l’esecuzione di funzionalità di base del sistema Android.
Al livello più alto si trova il layer delle applicazioni native. Le funzionalità base
del sistema, come per esempio il telefono, sono delle applicazioni scritte in Java e
che girano ognuna nella sua VM. A questo livello verrano installate le app create
dall’utente o scaricate dal Play Store.
2.1.2 Applicazioni Android
Un’applicazione Android è costituita da un insieme di dati e codice progettato
per eseguire una o più operazioni. Queste informazioni consistono in uno o più
componenti all’interno di un software "package" (APK), descritti nel Manifest file.
Il Manifest file raccoglie informazioni basilari sull’app, informazioni necessarie al
sistema per far girare qualsiasi porzione di codice della stessa e ogni applicazio-
ne ne deve avere uno. Ci sono quattro componenti essenziali che costituiscono
un’applicazione Android:
• Activity: un componente dell’applicazione che fornisce una schermata con
cui gli utenti possono interagire. Una normale applicazione consisterà in
una sequenza di activity. Quindi, ci sono diverse schermate che si alterna-
no sul display comunicando eventualmente tra di loro e scambiandosi delle
informazioni.
• Service: un componente dell’applicazione atto ad eseguire operazioni a lungo
termine in background, senza fornire alcuna interfaccia utente.
• Content Provider: un gestore dell’accesso ad un set di dati strutturati. Ogni
applicazione può definire una o più tipologie di dati e rendere poi disponibili
tali informazioni esponendo uno o più Content Provider. Invece, il sistema la
metterà in contatto con il corrispondente Content Provider precedentemente
installato se vorrà richiedere l’accesso ad un particolare tipo di dato.
• Broadcast Receiver: un componente che gestisce eventi di broadcast lanciati
dal sistema. Il sistema genera molti messaggi di broadcast e tale funzionalità
è svolta anche dalle applicazioni. I Broadcast Receiver (come i Service) non
mostrano un’interfaccia utente, ma possono creare una notifica sulla status
bar per avvertire l’utente che un determinato evento è avvenuto.
Alcuni di questi componenti possono comunicare tra loro attraverso degli Intent.
L’Intent è un meccanismo di messaggi che può attivare tre dei componenti di base
10di un’applicazione: activity, service e broadcast receiver. L’oggetto Intent è una
struttura dati passiva che contiene una descrizione astratta dell’operazione da
eseguire. Mandare un Intent è uno dei primi passi per far partire un’applicazione
Android. Per avere un’idea migliore del processo di avvio un’app Android, di
seguito sono riportati i passi principali:
• Con un tap dell’utente sull’icona dell’applicazione, le informazioni sull’activity
scelta sono racchiuse in un Intent, che è poi consegnato ad un processo di
sistema denominato Zygote, che si occupa di creare tutti gli altri processi
tramite fork.
• Zygote inizializza una primissima istanza di macchina virtuale Dalvik, pre-
caricata con tutte le classi comuni utilizzate dal framework dell’applicazione
Android, il che rende il tempo di avvio più veloce, perché solo le classi specifiche
dell’applicazione devono essere istanziate.
• Il processo creato da Zygote avvia un loop di messaggi e utilizzando l’Intent
individua e carica l’apk corretto e il file manifest.
• Il thread principale del processo creato istanzia un oggetto Applicazione che
crea un’istanza dell’activity principale. Il suo metodo OnCreate() è invocato e
l’applicazione inizia a funzionare, popolando una GUI e mostrandola.
2.1.3 Android Studio
Android Studio è un IDE per lo sviluppo di applicazioni Android. Questo IDE,
l’unico usato per lo sviluppo delle applicazioni di questa tesi, è organizzato in
diversi pannelli che possono essere riorganizzati a piacere dall’utente, in modo tale
da avere il necessario quando serve. Tra i pannelli che mette a disposizione si
trovano:
• Finestra del progetto che fornisce una panoramica gerarchica del progetto
considerato.
• Finestra dell’editor che visualizza un editor sensibile al contesto per il file
selezionato dalla scheda.
• Barra di stato che visualizza il risultato della compilazione oppure i messaggi
del registro di esecuzione.
• Barra degli strumenti che fornisce una selezione di scorciatoie per azioni
eseguite di frequente.
• Barre della finestra degli strumenti che consentono di individuare rapidamente
ulteriori finestre di ispezione del progetto.
11Android Studio permette anche di scaricare diversi emulatori con diverse versioni
di sistema operativo Android, per testare le app che si stanno sviluppando su diversi
dispositivi virtuali se l’applicazione deve girare su una vasta gamma di prodotti.
Dispone di un editor di codice intelligente che fornisce il completamento del codice
per i linguaggi principali Android e permette anche di analizzare diversi APK,
anche non prodotti con Android Studio, per avere un’idea delle dimensioni dell’app
[5].
2.2 Dispositivi elettronici utilizzati
Come introdotto sopra, i dispositivi elettronici utilizzati provengono dall’azienda
Zebra. Questa compagnia, fondata nel 1969, ha più di 4.400 brevetti. Tra i prodotti
che offre è possibile trovare scanner, computer portatili, tablet e stampanti aziendali.
Per il lavoro svolto, si è optato per due dispositivi particolari, di cui si approfondisce
la trattazione, il TC20 e il RFD2000.
2.2.1 TC20
Il TC20 è un computer portatile costruito per resistere ad ambienti di lavoro
impegnativi, come appunto i magazzini. Questo dispositivo è fornito di scansione
di codici a barre integrata e anche se il design ricorda quello di uno smartphone,
è un vero e proprio scanner. Nella Figura 2.2 è possibile vedere come si presenta
esteticamente il TC20. Per quanto riguarda alcune caratteristiche tecniche [6],
questo computer ha :
• CPU basata su processore ARM Cortex A53.
• memoria RAM 2GB – Flash 16GB.
• OS Android ver. 7.1.2 Nougat.
• Dimensioni 134 mm (lungh.) x 73,1 mm (largh.) x 16 mm (prof.).
• Schermo da 4,3 pollici.
• Lettore di codici a barre Imager SE4710 1D / 2D integrato.
• Fotocamera a colori con messa a fuoco automatica da 8 MP con flash.
Per l’obbiettivo della tesi, questo dispositivo è usato soprattutto per la raccolta e la
trasmissione dei dati, ed infatti, è capace di raccogliere dati in maniera differente,
anche grazie alla sua fotocamera. Nello specifico, i suoi componenti maggiormente
usati per eseguire le scansioni in questo lavoro sono:
12Figura 2.2: Mobile computer TC20
• Lettore di codice a barre integrato per leggere i codici a barre.
• RFD2000 (collegabile al TC20) per leggere i tag RFID.
2.2.2 RFD2000
RFD2000 è una culla palmare per il computer descritto in precedenza. Questo
dispositivo è progettato per dotare il TC20 di funzionalità RFID UHF e fornisce
le stesse prestazioni RFID di un dispositivo dedicato. Nella Figura 2.3 si nota
graficamente il dispositivo RFD2000. L’ergonomia e il design compatto e leggero
sono stati pensati per offrire comfort nelle attività di gestione dell’inventario, quindi
in questo progetto facilita il compito degli operatori che lo dovranno utilizzare.
Inoltre, collegarlo al TC20 è davvero semplice grazie ad un sistema ad incastro e
un collegamento elettrico a 8 pin. Alcune delle sue caratteristiche tecniche [7] sono:
• Peso 310 grammi.
• Velocità di lettura fino a 700 tag / sec.
• Dimensioni 14,9 cm alt. x 7,9 cm largh. x 13,3 cm lungh.
• Motore RFID con tecnologia radio proprietaria di Zebra.
13Figura 2.3: Culla palmare RFID UHF RFD2000
Esiste anche un’applicazione per il TC20 che fa da manager per questa culla.
Grazie a questa applicazione, è possibile verificare la carica della batteria, lo stato
di connesione e di attività del RFD2000.
2.3 Funzionalità delle applicazioni
Lo scopo di questo lavoro, è garantire agli operatori delle applicazioni performanti
che migliorino i processi logistici che si attuano tutti i giorni. Per fare questo, le
applicazioni devono essere pensate per risolvere i problemi introdotti nel primo
capitolo. Il software sviluppato deve:
• Configurare il sistema automaticamente dove possibile, evitando l’intervento
umano.
• Installare dinamicamente le applicazioni che servono in quel frangente, non
sprecando spazio di archiviazione e tempo.
• Funzionare al meglio sull’hardware su cui risiede, essendo sviluppato apposita-
mente per i dispositivi che saranno utilizzati.
• Essere ottimizzato, ma anche facile da utilizzare per gli utenti.
• Svolgere al meglio i processi logistici per i quali è stato pensato.
14Queste sono alcune delle caratteristiche specificate all’inizio di questo progetto,
e quindi quelle su cui si è lavorato per garantire la corretta implementazione. Come
specificato nel capitolo precedente, l’autoconfigurazione del sistema è un punto
chiave per questo lavoro.
Viene trattata nel dettaglio in seguito, ma come è possibile pensare, anche
l’installazione dinamica fa parte di questa fase. Il software, infatti, deve capire di
quali applicazioni i dispositivi hanno bisogno in quel determinato momento del loro
utilizzo e provvedere ad installarle nel breve tempo possibile. Si evita di installare
direttamente tutte le applicazioni perchè così facendo si aumenterebbero i tempi
d’attesa e per le aziende questa non è una buona cosa, dal momento che quel
dispositivo potrebbe essere dedicato per uno specifico processo ed avere all’interno
tutto il software non avrebbe molto senso oltre ad essere anche uno spreco di spazio.
Le applicazioni con il compito di raccogliere i dati, quindi tag RFID, codici a
barre e QR code, devono essere ottimizzate per i dispositivi TC20 e RFD2000.
Infatti, per queste specifiche operazioni, sono state usate rigorosamente le librerie
ed il software messi a disposizione da Zebra per programmare al meglio i propri
dispositivi.
Si è tenuto presente anche lo scenario in cui si lavora, cercando di garantire il
massimo rendimento, in modo facile e col minimo sforzo da parte degli operatori
che dovranno utilizzare i dispositivi, quindi l’utilizzo delle applicazioni deve essere
di facile comprensione.
Inoltre, la collaborazione con il backend è stata fondamentale in quanto i
dispositivi mobili comunicano con le sue componenti, per svolgere le operazioni
indispensabili ad attuare i processi logistici che i dispositivi non potrebbero portare
a termine da soli.
2.4 Backend del sistema
Con il termine backend, si identifica l’insieme delle applicazioni e dei programmi
essenziali al funzionamento del sistema, ma di cui l’utente non conosce le caratteri-
stiche, non essendo queste influenti su l’uso corretto dell’applicazione considerata.
Risulta essere comune, soprattutto nelle applicazioni che hanno a che fare con la
rete, avere un sistema client-server, di cui si può vedere un esempio in Figura 2.4,
in cui il client ha il compito di richiedere le informazioni e il server (con tutto
il sistema di backend) quello di fornirgliele se lo ritiene opportuno. Anche se il
backend di questo sistema non è lavoro di questa tesi, è opportuno fare una breve
introduzione per capire con cosa interagiscono le applicazioni mobili sviluppate,
partecipando al funzionamento di questo sistema.
15Figura 2.4: Esempio di modello client-server
2.4.1 Il server
Il server di questo progetto, si interfaccia col client attraverso delle API REST,
ovvero un set di definizioni e protocolli con i quali vengono realizzati e integrati
software applicativi conformi ai vincoli dell’architettura REST, note anche come
API RESTful. Nella Figura 2.5 si può vedere un esempio di architettura che
utilizza queste API. REST è uno stile architetturale usato nei sistemi distribuiti e
rappresenta un sistema di trasmissione di dati basato su HTTP, che non supporta
il concetto di sessione. Viene utilizzato con una struttura URL ben definita che
identifica in modo univoco una risorsa o un gruppo di risorse e utilizza i metodi
HTTP specifici per:
• Il recupero di informazioni (GET).
• La modifica (POST, PUT, PATCH, DELETE).
• Altri scopi (OPTIONS, ecc.).
Quando una richiesta viene inviata tramite un’API RESTful, questa trasferisce
al richiedente uno stato rappresentativo della risorsa. L’informazione, o rappre-
sentazione, viene consegnata in uno dei diversi formati tramite HTTP. Il formato
JSON è uno dei più diffusi, perché indipendente dal linguaggio e facilmente leggibile
da persone e macchine.
Il server, oltre a comunicare con il database per salvare, modificare e cancellare
dati, ha il compito di elaborare gli eventi EPCIS che arrivano dai dispositivi mobili,
per collaborare nell’esecuzione dei processi logistici.
16Figura 2.5: Esempio di architettura delle API RESTful
2.4.2 Il database
Il database utilizzato nel sistema di backend è MongoDB, un database distribuito
che negli ultimi anni si è affermando soprattutto in progetti come quello trattato.
MongoDB è un database document-based, cioè che archivia i dati sotto forma di
documenti di tipo JSON [8]. Questa sua caratteristica è molto utile in questo
contesto, perchè come si è detto, in questa tesi si lavora molto con i dati in
formato JSON. Di seguito sono riportati alcuni vantaggi nell’utilizzare questo tipo
di database:
• Latenza inferiore per query ( Nessun join, transazioni). Quindi, può gestire
un carico maggiore in termini di query al secondo.
• Molto scalabile grazie allo sharding, un metodo per distribuire i dati su più
macchine, consentendo il ridimensionamento orizzontale.
• Maggiore velocità di scrittura perché non deve preoccuparsi di bloccare in
caso di errori (No transazioni, rollback).
• Molto flessibile in quanto non ha uno schema.
• Esiste molta documentazione e una grande community.
17Si ricorda quindi che si deve progettare bene il sistema per prevenire gli errori
dovuti al fatto che MongoDB non supporta le transazioni.
2.4.3 L’utilizzo di Docker
Docker è una piattaforma software che consente di creare, testare e distribuire
applicazioni alla massima velocità [9]. Docker permette di raccogliere il software
in unità chiamate container, che forniscono tutto il necessario per una corretta
esecuzione, incluse librerie, strumenti di sistema, codice ecc. In questo modo, si
possono distribuire e ricalibrare le risorse delle applicazioni in qualsiasi ambiente
controllando sempre il codice in esecuzione. Docker è installato sul server e fornisce
semplici comandi con cui creare, avviare o interrompere i container. Nella Figura 2.6
si vede la differenza tra VMs e containers. Si nota come Docker permette di avere
ambienti di esecuzione piccoli e leggeri che fanno uso condiviso del kernel del sistema
operativo ma che si eseguono in modo isolato l’uno dall’altro.
Figura 2.6: Virtual machines vs containeiners
In questo progetto, è usato per eseguire alcune applicazioni, come il database di
cui si è parlato che all’avvio del server viene fatto partire in un container. Tra i
benefici di usare i Docker container ci sono:
• Semplificare il deployment di tutte le applicazione.
• Garantirne il funzionamento in ogni ambiente.
• Ottima portabilità.
• Le applicazioni e le risorse sono isolate, perché ogni container ha risorse isolate
da quelle degli altri.
18• Maggiore sicurezza in quanto le app eseguite sui container sono completamente
separate le une dalle altre.
2.4.4 Swagger come strumento di supporto
Swagger è un insieme di tool che seguono l’OAS (uno standard utilizzato per
descrivere le API Rest) per creare e documentare le API [10]. Lo standard OAS è
indipendente dai linguaggi di programmazione ed è concepito per essere compreso
da esseri umani e computer. Lo scopo è rendere il contenuto fornito dal servizio
più facile da capire senza dover accedere al codice sorgente o ad altri documenti.
Quindi è possibile vedere cosa risponde il server ad una determinata richiesta senza
implementare una funzione client apposita e realizzarla in seguito, quando si è
capito come interagire con quella specifica API. Tutto questo è stato molto utile
perchè ha permesso di comprendere il funzionamento del sistema prima di tuffarsi
ad occhi chiusi nello sviluppo delle applicazioni mobili, avendo una chiara visione
d’insieme e permettendo di realizzare le funzionalità richieste dalle diverse API.
2.5 Analisi dello scenario di operazione
Una caratteristica, la cui importanza non si deve sottovalutare, è lo scenario in
cui le applicazioni sviluppate sono utilizzate. Un’applicazione mobile può essere
ottimizzata, sicura, svolgere in modo impeccabile delle operazioni, ma tutto questo
non serve a nulla se l’utente finale non capisce il suo funzionamento o non riesce ad
utilizzarla per cause non riconducibili a lui personalmente. Nel contesto in cui il
lavoro di questa tesi propone una soluzione, l’utente finale è un operaio che svolge
dei processi logistici. Si è già discusso di come i dispositivi hardware siano pensati
appositamente per scenari di questo tipo, come il lavoro in un magazzino, e anche
il software non deve essere da meno. Si nota che l’utilizzatore delle applicazioni
potrebbe non essere abituato ad utilizzare dei dispositivi mobili, e la presenza di
tanti bottoni, menù, o in generale di componenti interattivi, potrebbe scoraggiarlo
e rendere il suo lavoro più complicato. Un altro aspetto cruciale, è il fatto che
l’utente in questione sta svolgendo un lavoro molto fisico, in posti polverosi e sotto
pressione, quindi la sua interazione con l’app dovrebbe essere facilitata in qualche
modo. Per risolvere questi problemi sono state fatte delle scelte che migliorano la
UX. Tra le caratteristiche pensate sono presenti:
• Ridurre al minimo la complessità delle applicazioni con la giusta quantità di
elementi interattivi, se un’operazione si può svolgere con la pressione di un
bottone, non ha senso metterne di più.
19• Le dimensioni dei vari componenti grafici devono facilitare il loro utilizzo, se
l’operaio è sotto pressione ed affaticato non riuscirà mai a premere un bottone
molto piccolo sullo schermo.
• I dispositivi elettronici dispongono già di alcuni componenti interattivi, non
ha senso mettere altri nel software che hanno lo stesso scopo.
Queste sono solo alcune delle accortezze che sono state prese per facilitare
l’utilizzo delle applicazioni, richiedendo poco impegno per svilupparle a livello di
codice, ma essenziali per rendere le applicazioni usabili e di facile comprensione.
2021
Capitolo 3
Sviluppo e progettazione
In questo capitolo sono riportate le principali scelte progettuali che hanno portato
allo sviluppo del software. In particolare sono riportate le scelte riguardanti i
linguaggi di programmazione, le decisioni a livello di struttura del progetto, le
caratteristiche dell’autoconfigurazione dei dispositivi e come viene sviluppata e resa
possibile.
3.1 Java e Kotlin
Quando si deve progettare un’applicazione Android, una delle decisioni che può
migliorare incredibilmente lo sviluppo della stessa, è la scelta del linguaggio di
programmazione da utilizzare. I due linguaggi principali sono Java, affermato già
da molti anni, e Kotlin che negli ultimi anni sta scalando la classifica, portando i
programmatori Android ad una difficile scelta tra i due quando devono iniziare a
programmare un app. Per capire meglio i punti di forza e i difetti dei due linguaggi,
di seguito sono riportate delle descrizioni di entrambi.
Java è utilizzato come linguaggio di programmazione dalle grandi imprese.
Lo sviluppo Java domina il mondo delle applicazioni aziendali, grazie alle sue
funzionalità come l’interoperabilità e la flessibilità. Tra i motivi principali del
suo utilizzo ci sono il paradigma di architettura OOP e la robustezza del codice,
rendendolo presente praticamente ovunque, come nei pc portatili, nelle console
per videogiochi, negli smartphone, ecc. La programmazione in Java ha i seguenti
vantaggi:
• È facile da imparare e da capire.
• È flessibile, cioè è eseguibile sia in rete, sia in un ambiente di esecuzione
virtuale. Questo è utile quando si riutilizza il codice e si aggiorna il software.
22• È parte integrante del kit di sviluppo Android, che contiene molte librerie
Java per la creazione di app compatibili con il sistema operativo.
• Ha un grande ecosistema open source, aggiornato e ricco di funzionalità.
• Lo sviluppo Java consente di gestire progetti di grandi dimensioni e complessi,
con l’aiuto di strumenti moderni che garantiscono la massima velocità di
compilazione e di realizzazione.
Kotlin è un linguaggio di programmazione open-source, progettato dai program-
matori di JetBrains nel 2011 e costantemente aggiornato dalla stessa community,
compatibile con Java, pensato proprio per risolvere alcuni problemi dello sviluppo
Java. Questo lo ha portato ad essere preferito da molte aziende, tra queste c’è
anche Google. Tra i vantaggi di utilizzare Kotlin, ci sono:
• È un linguaggio di programmazione più conciso e rapido rispetto a Java, cioè
è possibile scrivere meno codice che con Java.
• Ha la capacità di interagire e funzionare con lo stesso rivale Java, quindi è
interoperabile
• Ha un’architettura sicura. Questo consente, a differenza di Java, di non
incorrere in errori di codice, come il più comune che gli sviluppatori riscontrano
in Java, il NullPointerException.
• È un linguaggio di programmazione tipizzato e questo aumenta la velocità di
esecuzione, per esempio delle funzioni Lambda.
In questo progetto di tesi, sono stati usati entrambi i linguaggi, prendendo il
meglio e sfruttando i vantaggi dei due. Per esempio, si è sfruttata la fama di Java
con le librerie di Zebra scritte esclusivamente in Java, nonchè la sua flessibilità,
mentre per quanto riguarda Kotlin si è fatto uso delle coroutine, soprattuto in fase
di test e di monitoraggio delle applicazioni. Le coroutine sono blocchi di codice
che vengono eseguiti in modo asincrono senza bloccare il thread dal quale vengono
avviati.
3.2 Build di progetti Android complessi
Le applicazioni Android richieste e necessarie per questo progetto sono più di una,
basta pensare alla varietà di processi che bisogna gestire in un contesto logistico.
Un’idea non molto carina, almeno a livello di struttura, è quella di avere un
progetto di Android Studio per ogni app sviluppata. Questa idea è stata subito
abbandonata perchè ogni app ha delle caratteristiche in comune con le altre app,
23come per esempio l’autenticazione o il recupero della propria configurazione, che
a livello di codice sarebbe identico in ogni progetto. Riflettendo su quanto detto,
si è optato per creare delle varianti della stessa app, in quanto la parte diversa
consiste nell’esecuzione del processo che l’app deve svolgere, spesso tradotto in una
o comunque poche activity diverse.
Per avere delle versioni diverse della stessa app nello stesso progetto, si è ricorso
alla configurazione delle varianti di build. Le varianti di build sono un insieme
specifico di regole per combinare impostazioni, codice e risorse configurate nei
tipi di build e nelle versioni di prodotto (flavor). Non si configurano direttamente
le varianti di build, si configurano i tipi di build e le versioni di prodotto che
le formano. Una versione di prodotto specifica diverse caratteristiche e requisiti
del dispositivo, come codice sorgente personalizzato, risorse e livelli API minimi,
mentre il tipo di build applica diverse impostazioni di build e packaging, come
opzioni di debug e firma chiavi. Si possono creare e configurare i tipi di build e i
flavor nel build.gradle file all’interno del blocco android del progetto. Dopo aver
effettuato la sincronizzazione, Gradle (un sistema open source per l’automazione
dello sviluppo) crea automaticamente varianti di build in base ai tipi di build e ai
flavor dei prodotti e le denomina in base a . Si possono
anche applicare dei filtri se si vuole che un determinato tipo di build non abbia un
flavor, oppure viceversa, che un flavor non abbia un tipo di build.
Tutte queste funzionalità, hanno portato a creare un flavor denominato "main"
in cui ci sono tutte le caratteristiche comuni a tutte le app e dei flavor diversi per
ogni app sviluppata con la logica distinta per quella particolare app. In questo
modo, quando una determinata variante di build è eseguita, viene eseguito il codice
presente in "main", con le differenze che però sono presenti nel flavor di quella
variante. Quindi è possibile testare e creare gli APK di tutte le app avendo solo un
progetto che gestisce tutti processi logistici.
3.3 L’uso di Room
I dispositivi elettronici utilizzati devono essere collegati alla rete per poter comuni-
care con il server. La connessione però non è sempre garantita, soprattutto nello
scenario considerato, e si vuole che i dispositivi continuino comunque a funzionare,
avendo certamente delle limitazioni. Per questo motivo, si è deciso di utilizzare
Room. Room è un database locale che fornisce un livello di astrazione su SQLite,
usato soprattutto per memorizzare parti di dati rilevanti in modo che quando
il dispositivo non è connesso alla rete, l’utente può comunque navigare in quel
contenuto mentre è offline. Room è composto principalmente da tre componenti:
• La classe di database che contiene il database e rappresenta il punto di accesso
principale per la connessione sottostante ai dati persistenti dell’app.
24• Entità di dati che formano le tabelle nel database dell’app.
• Oggetti di accesso ai dati che forniscono metodi per eseguire le query nel
database.
Nella Figura 3.1 si può notare graficamente l’architettura di Room.
Figura 3.1: Architettura di Room
In questo progetto sono state create due entità:
• ItemCode che serve per salvare i codici dei prodotti che si devono registrare, per
poi utilizzarli in un secondo momento quando servono senza doverli richiedere
al server.
• ReadingEvent che viene utilizzata per salvare gli eventi EPCIS se la connessione
alla rete viene a mancare, per mandarli al server al ritorno della connessione.
Le query eseguibili si trovano rispettivamente in ItemCodeDao e in ReadingE-
ventDao, mentre l’istanza del database è la stessa.
253.4 Il pattern Model-View-ViewModel
I diversi componenti che formano un’applicazione Android possono essere avviati
e distrutti in un qualsiasi momento, indipendentemente dagli altri. Quindi, è
necessario che nessuno di essi memorizzi al proprio interno dei dati dell’applicazione
e nessuno dovrebbe dipendere dall’esistenza di un altro componente. Il contenuto
della UI deve riflettere un modello persistente in modo tale che gli utenti non
perdano i dati se l’app viene distrutta o si ha a che fare con connessioni di rete
problematiche. Tra i diversi modelli esistenti, si è scelto di utilizzare il MVVM. I
principali attori nel pattern MVVM sono:
• Model, che contiene tutte le classi per ottenere e salvare i dati.
• View, che informa il ViewModel sulle azioni dell’utente e rappresenta lo stato
corrente delle informazioni visibili.
• ViewModel, che espone flussi di dati rilevanti per la View. ViewModel e View
sono collegati tramite Databinding e LiveData osservabili.
Nella Figura 3.2 si può vedere una delle possibili implementazioni del MVVM.
Figura 3.2: Implementazione del MVVM
Come è possibile notare, le View sono di solito rappresentate da Activity o
Fragment (porzione di Activity) e hanno il compito di osservare i LiveData del
ViewModel. LiveData è una classe di dati osservabile che avvisa il suo osservatore
quando i dati sottostanti cambiano. Vengono aggiornati solo gli osservatori nei
componenti che si trovano in uno stato del ciclo di vita attivo. I ViewModel
recuperano i dati dalla repository che fornisce un accesso ai dati memorizzati in
26un server remoto o in una memoria locale (come Room di cui si è già parlato).
MVVM ha il vantaggio della separazione delle preoccupazioni e sfrutta i vantaggi
delle associazioni di dati. Il risultato è un modello che guida il maggior numero di
operazioni possibile, riducendo al minimo la logica nella vista. In questo progetto
si sono utilizzati due repository e due ViewModel, nel dettaglio:
• ItemCodeRepository e ItemCodeViewModel, rispettivamente per avere accesso
ai codici dei prodotti memorizzati e avere queste informazioni nel giusto
ViewModel per osservarne il cambiamento nelle activity/fragment dell’app.
• ReadingEventRepository e ReadingEventViewModel, rispettivamente per ave-
re accesso agli eventi EPCIS memorizzati e avere queste informazioni nel giusto
ViewModel per osservarne il cambiamento nelle activity/fragment dell’app.
3.5 Autoconfigurazione dei dispositivi
Come già anticipato, questo lavoro verte molto sul concetto di autoconfigurazione.
Questo processo deve facilitare e velocizzare il compito degli operatori finali che
utilizzano i dispositivi, e garantire meno errori dovuti all’intervento umano. Tra la
miriade di sorgenti da cui recuperare i dati per la configurazione, si è optato per
un file JSON.
Un file JSON è un file che memorizza semplici strutture dati e oggetti in formato
JSON, che è un formato di scambio dati standard. Viene utilizzato principalmente
per la trasmissione di dati tra un’applicazione e un server, buona scelta dal momento
che i dispositivi sono connessi ad una rete capace di comunicare con un server. I
file JSON sono leggeri, basati su testo e facilmente leggibili dall’uomo. Il file di
configurazione deve contenere:
• Informazioni per risalire al suddetto file, come id, nome e versione.
• Le credenziali per ottenere l’accesso alle applicazioni.
• L’indirizzo ip del server a cui fare le richieste.
• La lista delle applicazioni da scaricare ed installare.
Questo file, viene salvato nel dispositivo che ha richiesto di essere configurato
e grazie ad un’ apposita procedura, è possibile verificare la presenza di nuovi
file di configurazione. Comunque, si approfondisce questo aspetto a livello di
progettazione e codice implementato in seguito, quando si descrive l’applicazione
launcher sviluppata appositamente.
273.5.1 Installazione dinamica delle applicazioni
Una delle operazioni principali, durante la fase di autoconfigurazione, è l’instal-
lazione dinamica delle applicazioni. Dietro questa operazione, c’è l’idea di avere
solo le applicazioni necessarie sul dispositivo avendo benefici di spazio e di tempo.
Dal file JSON di configurazione è possibile ottenere la lista degli APK, precedente-
mente caricati sul server, che devono essere installati sul dispositivo in questione.
In particolare, ogni applicazione da scaricare ed installare presente nella lista è
rappresentata come un oggetto JSON, ognuno dei quali è composto da:
• Id dell’applicazione.
• Nome dell’applicazione.
• Il template dell’evento EPCIS che l’applicazione deve poter generare per il
processo che deve sostenere.
Per come è stato pensato il server con cui comunicano le applicazioni, per
evitare di generare ogni volta un evento EPCIS completo, sono stati creati dei
template specifici per ogni processo aziendale da supportare. Nel template che
l’applicazione deve trattare, ci sono dei dati fissi, come il nome del template o il
modo di calcolare la differenza di fuso orario che in una specifica sede è sempre
uguale, e i dati che l’utente può scegliere quando avrà a che fare con quell’evento,
come le liste di possibili valori per un determinato campo dell’evento. In questo
modo le applicazioni vengono configurate automaticamente e all’utente finale viene
lasciato il compito di decidere solo nei casi in cui è davvero richiesto il suo effettivo
intervento. Con questa procedura, dell’installazione dinamica, i dispositivi evitano
di appesantirsi e di perdere tempo ad installare applicazioni di cui magari non
avranno mai bisogno, guadagnando in velocità durante la fase di scaricamento ed
installazione e avendo comunque la possibilità di ottenere un’applicazione in futuro,
quando sarà davvero necessaria la sua funzionalità.
3.6 Progettazione delle applicazioni
Ora si introducono le scelte progettuali delle diverse applicazioni sviluppate, spie-
gando le ragioni che hanno portato al loro funzionamento e le caratteristiche che
possiedono, trattando anche le tecniche di progettazione della UX. In particolare si
descrive il funzionamento di due tipi di applicazioni, il launcher e le applicazioni
che gestiscono i processi logistici, portando in totale questo lavoro alla creazione di
due progetti Android Studio.
283.6.1 User Experience
Una caratteristica fondamentale per lo sviluppo di applicazioni mobili è quella di
progettare bene la UX altrimenti possono insorgere molti problemi legati al fatto
che gli utenti non sono invogliati ad utilizzare l’app. La valutazione del prodotto
dipende in larga misura dall’esperienza accumulata dall’utente nel processo di
utilizzo, quindi la funzionalità del prodotto è essenziale. La UX deve fornire
agli utenti la migliore esperienza utente in termini di facilità d’uso e sensazione
che gli utenti provano dall’utilizzo dell’applicazione. Pertanto, ha un impatto
sul miglioramento del valore aziendale perché aiuta a migliorare l’efficienza e
l’attenzione dell’azienda ai clienti e operatori. L’esperienza utente deve essere
comoda, intuitiva e chiara, progettata per trasformare gli utenti dell’app in utenti
felici di utilizzarla. Un modello di progettazione della UX è dato da J.J. Garrett,
un famoso User Experience Designer, secondo il quale ogni aspetto del design è il
risultato delle volontà specifiche del progettista. Il modello di Garrett si basa sul
fatto che il processo di progettazione della UX di un prodotto software è formato
da cinque fasi che corrispondono a cinque piani diversi. Nella Figura 3.3 si può
vedere la struttura del modello di Garrett. I cinque piani si sviluppano in verticale
e dal basso verso l’alto le problematiche si fanno sempre più specifiche, portando
quindi ogni piano ad essere dipendente dal piano precedente. Questa dipendenza
significa che le scelte disponibili nel piano sono limitate dalle decisioni prese nel
piano sottostante, quindi le scelte fatte al livello più basso (cioè il piano strategico)
hanno un impatto su tutta la struttura. Garrett ha sottolineato l’importanza di
iniziare le attività su un livello prima di completare le attività del livello successivo,
per evitare di sovrapporre più di due livelli. Per quanto riguarda i cinque piani,
partendo dal basso verso l’alto, quindi dal piano con problematiche più astratte a
quello con problematiche più concrete, ci sono:
• Il piano della Strategia. In questo piano, il più astratto, viene definito l’utente
del sistema, gli obiettivi che si è prefissato e quali sono le sue esigenze e gli
obiettivi aziendali.
• Il piano dell’Obiettivo. In questo piano, vengono descritte le specifiche
funzionali e il contenuto necessario del sistema per soddisfare le esigenze
dell’utente.
• Il piano della Struttura. Questo piano è utilizzato per definire l’interazione
tra l’utente e il sistema e l’organizzazione del contenuto in modo che l’utente
possa accedervi rapidamente ed efficacemente.
• Il piano dello Scheletro. In questo piano, è indicato il design dell’interfaccia
con cui gli utenti devono interagire, gli elementi che consentono agli utenti di
29Puoi anche leggere
