Progettazione e sviluppo di un controller per la chat di un'applicazione mobile - Università degli Studi di Padova - SIAGAS
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Università degli Studi di Padova
Dipartimento di Matematica
“Tullio Levi-Civita”
Corso di Laurea in Informatica
Progettazione e sviluppo di un
controller per la chat di
un’applicazione mobile
Relatore Autore
Prof. Gilberto Filè Sara Feltrin
Luglio 2019
Sara Feltrin: Progettazione e sviluppo di un controller per la chat di un’applicazione mobile, Tesi di laurea triennale, c Luglio 2019.
Forse non è la felicità ciò che voglio
Ma il percorso per raggiungerla
Un alpinista che non vorrà quella vetta
Ma solo il rischio di cadere giù
Forse non è la felicità - Fast Animals And Slow Kids
Ringraziamenti Ringrazio il Prof. Gilberto Filè, relatore della mia tesi, per avermi seguito durante la stesura del lavoro. Desidero ringraziare con affetto i miei genitori, mio fratello Luca e i miei nonni per il sostegno, il grande aiuto e per essermi stati vicini in ogni momento durante gli anni di studio. Un ringraziamento speciale va a tutto il team di Zextras S.r.l., che mi hanno permesso di vivere questa bella esperienza in un settore dell’informatica così inte- ressante. Un ringraziamento speciale va a Marco, che più di tutti ha dovuto subirmi i miei alti e i miei bassi, che ha sempre creduto in me anche quando io stessa non lo facevo e mi ha sempre supportato in tutte le mie scelte, giuste o sbagliate che fossero. Infine, non posso non ringraziare i miei amici e compagni di università per le sessioni di studio e le serata passate assieme, con voi questi anni di università sono volati. Padova, Luglio 2019 Sara Feltrin
Sommario Il presente documento ha lo scopo di descrivere l’attività di stage svolta presso l’azienda Zextras s.r.l. con sede a Torri di Quartesolo (VI) dal 6 maggio al 28 giugno 2019. Il lavoro si è concentrato sulla progettazione e l’implementazione di una parte dell’applicazione Team. Essa è un’app mobile di messaggistica istantanea creata con lo scopo di fornire una rete di comunicazione tra i dipendenti di un’azienda che utilizza la suite di prodotti Zextras per la posta elettronica e lo storage dei file. In particolare, lo stage si concentra sull’implementazione del dettaglio delle chat di gruppo. Le funzionalità principali richieste sono: la possibilità di modificare topic e immagine delle chat di gruppo, la gestione dei partecipanti e l’accesso diretto alle chat private con i vari membri del gruppo. Tale lavoro è sviluppato per dispositivi mobile Apple utilizzando il linguaggio di programmazione nativo Swift e l’IDE xCode. Quest’ultimo da la possibilità di sviluppare il codice sorgente, costruire l’interfaccia grafica e implementare unit test e UI test senza l’ausilio di altri strumenti.
Indice
1 Introduzione 1
1.1 Organizzazione del documento . . . . . . . . . . . . . . . . . . . . . 1
1.2 Convenzioni adottate . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Presentazione del progetto . . . . . . . . . . . . . . . . . . . . . . . 2
2 L’azienda 3
2.1 Profilo dell’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Zimbra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2 Zextras Suite . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Metodo di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Strumenti utilizzati . . . . . . . . . . . . . . . . . . . . . . . 6
3 Organizzazione del progetto 9
3.1 Motivo del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Piano di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Pianificazione del progetto . . . . . . . . . . . . . . . . . . . . . . . 10
4 Tecnologie utilizzate 11
4.1 xCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Swift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3 Realm Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4 SVProgressHUD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5 Alamofire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6 Alamofire Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.7 SwiftyJSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.8 WebSocket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.9 Firebase Cloud Messaging . . . . . . . . . . . . . . . . . . . . . . . 14
5 Analisi dei requisiti 15
5.1 Attori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.1 Attori primari . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.2 Attori secondari . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2 Casi d’uso principali . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.1 Principali requisiti funzionali . . . . . . . . . . . . . . . . . . 17
5.3.2 Requisiti di vincolo . . . . . . . . . . . . . . . . . . . . . . . 18
ixx INDICE
5.3.3 Requisiti di qualità . . . . . . . . . . . . . . . . . . . . . . . 18
6 Sviluppo 19
6.1 Gestione delle API . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1.1 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1.2 WebSocket . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1.3 Firebase Cloud Messaging . . . . . . . . . . . . . . . . . . . 21
6.2 Codifica del controller . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2.1 UX/UI Mockup Mobile . . . . . . . . . . . . . . . . . . . . . 23
6.2.2 ColorsPalette for Group . . . . . . . . . . . . . . . . . . . . 24
6.2.3 Interface builder . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2.4 Struttura dell’applicazione . . . . . . . . . . . . . . . . . . . 26
7 Verifica e Validazione 27
7.1 Unit Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.2 UI Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.3 Test manuali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.4 Beta test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.4.1 Test Flight . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8 Conclusioni 29
8.1 Valutazioni del prodotto finale . . . . . . . . . . . . . . . . . . . . . 29
8.2 Valutazioni sull’esperienza di stage . . . . . . . . . . . . . . . . . . 30
A Descrizione dei casi d’uso 33
A.1 UC1 - Visualizzazione dettaglio della chat di gruppo . . . . . . . . . 33
A.2 UC2 - Modifica dell’immagine del gruppo . . . . . . . . . . . . . . . 33
A.3 UC2.1 - Errore formato immagine non valido . . . . . . . . . . . . . 34
A.4 UC3 - Modifica del topic del gruppo . . . . . . . . . . . . . . . . . . 35
A.5 UC3.1 - Errore topic inserito troppo lungo . . . . . . . . . . . . . . 35
A.6 UC4 - Modifica delle notifiche del gruppo . . . . . . . . . . . . . . . 36
A.7 UC5 - Aggiunta di un nuovo partecipante al gruppo . . . . . . . . . 36
A.8 UC6 - Visualizzazione della lista di tutti gli utenti Zimbra . . . . . 37
A.9 UC7 - Selezionare più utenti da aggiungere alla chat . . . . . . . . . 38
A.10 UC8 - Abbandonare la chat di gruppo . . . . . . . . . . . . . . . . 38
A.11 UC9 - Visualizzazione della lista dei partecipanti alla chat . . . . . 39
A.12 UC10 - Accesso alla chat privata . . . . . . . . . . . . . . . . . . . . 39
A.13 UC11 - Ritorno al dettaglio della chat di gruppo . . . . . . . . . . . 40
A.14 UC12 - Visualizzazione della lista dei media condivisi . . . . . . . . 41
A.15 UC13 - Visualizzazione del dettaglio del media selezionato . . . . . 41
A.16 UC14 - Visualizzazione della lista dei link condivisi . . . . . . . . . 42
A.17 UC15 - Visualizzazione del dettaglio del link selezionato . . . . . . . 42
Glossary 43
Bibliografia 49Elenco delle figure
2.1 Logo Zextras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Logo Zimbra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Zextras Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Diagramma funzionamento Scrum . . . . . . . . . . . . . . . . . . . 6
2.5 Logo Bitbucket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6 Logo Jira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.7 Logo Confluence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.8 Logo Jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.9 Logo SourceTree . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Logo xCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Logo Swift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Logo Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4 SVProgressHUD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5 Logo Alamofire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6 Logo Firebase Cloud Messaging . . . . . . . . . . . . . . . . . . . . 14
5.1 Diagramma dei casi d’uso . . . . . . . . . . . . . . . . . . . . . . . 16
6.1 Protocollo HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2 Funzionamento di WebSocket . . . . . . . . . . . . . . . . . . . . . 21
6.3 Funzionamento Firebase . . . . . . . . . . . . . . . . . . . . . . . . 22
6.4 Documento UX/UI Mockup Mobile . . . . . . . . . . . . . . . . . . 23
6.5 Documento ColorsPalette for Group . . . . . . . . . . . . . . . . . . 24
8.1 Esempio errore di localizzazione . . . . . . . . . . . . . . . . . . . . 30
xiElenco delle tabelle
3.1 Organizzazione del progetto in sprint . . . . . . . . . . . . . . . . . 10
5.1 Requisiti funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2 Requisiti di vincolo . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3 Requisiti di qualità . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
xiiiCAPITOLO 1
Introduzione
1.1 Organizzazione del documento
Questo elaborato è organizzato come segue:
• Capitolo 1: descrizione della struttura del documento e delle convenzioni
adottate nella sua stesura;
• Capitolo 2: introduzione dell’azienda ospitante, dei suoi prodotti nel mercato
e del metodo di lavoro seguito al suo interno;
• Capitolo 3: presentazione del progetto svolto durante questo stage, degli
obiettivi raggiunti e come è stato pianificato il lavoro;
• Capitolo 4: esposizione delle tecnologie che sono state studiate e adottate
durante l’attività di stage;
• Capitolo 5: elenco dei requisiti che l’azienda ha definito per il prodotto finale;
• Capitolo 6: spiegazione delle scelte implementative e di design dell’applicazio-
ne;
• Capitolo 7: descrizione delle fasi di verifica e validazione del prodotto svolte;
• Capitolo 8: conclusione con delle mie considerazioni sull’applicazione prodotta,
sul lavoro svolto e il periodo di stage in generale.
1.2 Convenzioni adottate
Nella stesura del presente elaborato vengono adottate le seguenti convenzioni
tipografiche:
• la prima occorrenza di termini tecnici, ambigui o di acronimi verrà marcata
in corsivo e con la lettera g a pedice, in modo da indicare la sua presenza nel
glossario, riportato alla fine del documento;
12 CAPITOLO 1. INTRODUZIONE
• i termini tecnici in lingua inglese non traducibili e non presenti nel glossario,
verranno evidenziati in corsivo;
• la prima occorrenza di un acronimo viene riportata con la dicitura estesa, in
corsivo, e le lettere che compongono l’acronimo vengono riportate in grassetto.
Ogni successiva occorrenza presenterà solo la forma contratta;
• le parole chiave presenti in ciascun paragrafo ssono marcate in grassetto, così
da consentirne una facile individuazione;
• ogni termine corrispondente a nomi di file, componenti dell’architettura o
codice viene marcato utilizzando un font a larghezza fissa;
• i diagrammi Unified Modeling Language (UML) sono espressi seguendo lo
standard 2.0.
1.3 Presentazione del progetto
Il progetto proposto dall’azienda per il lavoro di stage consiste nella progettazione e
nello sviluppo di un controllerG di una applicazione chat per dispositivi mobili, nello
specifico si tratta del controller che gestisce le informazioni della conversazione di
gruppo. Le funzionalità richieste nella schermata del dettaglio della chat di gruppo
sono: modificare avatarG e topicG del gruppo, abbandonare il gruppo, aggiungere
nuovi membri al gruppo, consultare la lista di tutti i partecipanti alla chat e infine
entrare nella conversazione, nuova oppure già avviata, con l’utente della lista che
si desidera premendo su di esso. La grafica dell’applicazione deve rispettare lo
stile del modulo Chat, già progettato dall’azienda, e seguire le linee guida per le
applicazioni iOSG . Tale prodotto viene sviluppato utilizzando l’IDEG xCode, un
ambiente di sviluppo progettato da Apple che grazie alla sua suiteG di strumenti
facilità lo sviluppo di applicazioni per sistemi iOS.CAPITOLO 2
L’azienda
2.1 Profilo dell’azienda
figure 2.1: Logo dell’azienda Zextras
L’attività di stage descritta in questo elaborato è stata svolta presso l’azienda
Zextras s.r.l. che ha sede a Torri Di Quartesolo (VI). Questa società è nata nel
2011 con l’obiettivo di espandere le funzionalità della suiteG di prodotti offerti
da Zimbra, uno dei sistemi di collaborazione più diffusi al mondo che propone
diversi servizi, tra cui una propria posta elettronica, un calendario e un’agenda
contatti. Da questo proposito nasce Zextras Suite, un insieme di estensioni per
Zimbra Collaboration che migliorano i servizi già presenti e aggiungono funzionalità
importanti per favorire lo sviluppo di software. In pochi anni Zextras è riuscita
a rendere la propria suite di prodotti l’estensione professionale per Zimbra Open
Source più avanzata tra le soluzioni di collaborazione sul mercato. I loro prodotti
sono riconosciuti come ottimali anche dall’azienda proprietaria Synacor, e ciò si è
tradotto in una cooperazione per lo sviluppo di alcuni prodotti open sourceG e per
Zimbra Suite Plus. Ad oggi l’azienda presenta sedi secondarie in diversi paesi, quali
Francia, Brasile, Russia e Stati Uniti, oltre a possedere partner in tutto il mondo.
2.1.1 Zimbra
figure 2.2: Logo dell’azienda Zimbra
34 CAPITOLO 2. L’AZIENDA
Zimbra è un server di workgroupG open sourceG che mette a disposizione una suiteG
di software collaborativi che consentono di condividere documenti e attività. Di
base essa offre i seguenti servizi:
• configurazione personalizzata;
• gestione della posta elettronica;
• rubriche, calendari e condivisione di file;
• chat e chiamate vocali;
• integrazione con i canali web;
• privacy e alti livelli di sicurezza;
• integrazione per i dispositivi mobili: oltre che mediante client Zimbra Web e
attraverso i client di posta elettronica tradizionale, è possibile accedere alle
e-mail, ai calendari e alle altre offerte da dispositivi mobile.
Le funzionalità di Zimbra possono essere facilmente estese grazie alla possibilità
di creare ed aggiungere degli add-on chiamati zimletG , unendo le funzionalità del
software principale con servizi web o applicazioni di terzi.
Zimbra è disponibile in due versioni:
• Zimbra Open Source Edition: soluzione completamente open source, che offre
un insieme ristretto di funzionalità standard;
• Zimbra Network Edition: soluzione completa di tutte le funzionalità sia per
l’amministratore di sistema sia per l’utente finale.
2.1.2 Zextras Suite
Zextras Suite è un add-on per Zimbra Collaboration: i suoi prodotti sono progettati
per espandere le funzioni di Zimbra Open Source Edition in maniera a se stante
rispetto i moduli Zimbra Network Edition. Infatti, tale soluzione software, non
è distribuito assieme ad alcun binario o sorgente sotto il copyrightG di Zimbra.
Le principali innovazioni che sono state portate nel mondo Zimbra riguardano la
sicurezza dei dati, la mobilità e la gestione dello storageG . La suite comprende i
seguenti prodotti:
• Zextras Backup: modulo di backupG professionale che permette il salvatag-
gio realtimeG dei dati;
• Zextras Mobile: modulo per la gestione e sincronizzazione di email, contatti,
eventi e task con qualsiasi device mobile tramite Exchange ActiveSyncG ;
• Zextras Powerstore: modulo per la gestione avanzata di storage locali e
remoti, così da ottimizzare i volumi dei dati Zimbra e risparmiare spazio
attraverso la compressione e la deduplicazioneG ;2.2. METODO DI LAVORO 5
• Zextras Admin: interfaccia amministrativa avanzata per monitorare gli
utenti e le funzionalità di Zimbra, Zextras Suite e ogni altra zimletG ;
• Zextras Chat: piattaforma client/server integrata in Zimbra per la messag-
gistica istantanea e le videochat.
Zextras Suite è un’estensione modulare per Zimbra Open Source che può essere
applicata secondo le proprie esigenze e, grazie alla sua duttilità, la rende la scelta
migliore per un uso professionale di Zimbra.
figure 2.3: Moduli della Zextras Suite
2.2 Metodo di lavoro
La necessità di sviluppare progetti particolarmente complessi che si unisce all’esigen-
za di mantenere una certa flessibilità e trasparenza, ha portato l’azienda ad adottare
un ciclo di sviluppo del software di tipo agileG , rispetto a metodi di managementG
più tradizionali incentrati sui processi di sviluppo ma non reattivi ai cambiamenti.
Questi, infatti, causerebbero una maggior dispersione di risorse, soprattutto nel
caso di una forte interazione con il cliente. La filosofia dello sviluppo agile si basa
su quattro pilastri fondamentali che la caratterizzano. Essi sono:
• gli individui e le interazioni sono più importanti dei processi e degli strumenti;
• è più importante avere del software funzionante rispetto ad avere una docu-
mentazione esaustiva;
• è più importante la collaborazione col cliente del rispetto dei contratti;
• bisogna essere pronti a rispondere ai cambiamenti oltre che aderire alla
pianificazione.
Questi principi sono ampiamente condivisi dalla compagine aziendale, la quale
basa lo sviluppo dei propri prodotti sulla continua interazione con gli stakeholderG
e con i clienti.6 CAPITOLO 2. L’AZIENDA
2.2.1 Scrum
L’azienda, in particolare, utilizza il metodo ScrumG che, oltre ad essere uno dei
sistemi più diffusi, è particolarmente adatto a progetti complessi ed innovativi. Lo
Scrum prevede un modello di sviluppo iterativo nel quale ogni ciclo viene definito
sprint: esso è un periodo di tempo, solitamente di durata compresa tra 1 a 4
settimane, nel quale viene prefissata una lista di requisiti e funzionalità che devono
essere implementate in tale periodo. Questa lista di funzionalità e requisiti viene
definita prima in una Product BacklogG , documento che contiene tutti i requisiti
necessari per la realizzazione del progetto, e poi, periodicamente, in una Sprint
BacklogG , documento nel quale vengono definiti tutti i task da completare nei singoli
sprint.
figure 2.4: Diagramma di funzionamento del metodo agile Scrum
L’azienda prevede sprint di due settimane e la fine di ognuno di essi coincide con
una release del software. Per gestire al meglio sprint e backlog di ogni progetto
vengono eseguite delle riunioni periodiche di diverse tipologie:
• Sprint Planning: riunione che precede l’inizio del progetto in cui si stila la
Product Backlog e si determina il numero e la durata degli sprint in base al
tempo a disposizione e agli obiettivi. Viene inoltre definita la Sprint Backlog
per il primo sprint;
• Daily Scrum: breve confronto giornaliero che permette di sincronizzare i
lavoro di tutto il team e di affrontare tempestivamente i problemi riscontrati;
• Sprint Review: revisione al termine di ogni sprint che serve a valutare se gli
obiettivi prefissati sono stati completati in modo esaustivo o se è necessario
modificare la pianificazione del lavoro per lo sprint successivo;
2.2.2 Strumenti utilizzati
Zextras S.r.l. utilizza la suiteG Atlassian, composta da una serie di prodotti atti
al miglioramento dello sviluppo del software, della gestione dei progetti e della
collaborazione all’interno del team di lavoro.2.2. METODO DI LAVORO 7
2.2.2.1 Bitbucket Cloud
Per il versionamentoG del software viene utilizzato BitBucket Cloud, un servizio di
cloud-hostingG per repositoryG GitG e per il controllo delle versioni. Permette di
eseguire tutte le operazioni di base di Git (è un servizio simile a GitHubG ) ed in più
consente un pieno controllo all’accesso in lettura e scrittura del codice. BitBucket
Cloud ha il vantaggio di consentire una gestione semplificata in quanto non è
necessario avere dei server locali nei quali installare Bitbucket server e mantenere
i propri repository. Inoltre permette l’integrazione con altri strumenti sviluppati
dall’azienda Atlassian, tra i quali Jira e Confluence.
figure 2.5: Logo del servizio Bitbucket Cloud
2.2.2.2 Jira
Jira è un prodotto di issue-trackingG che fornisce funzionalità quali tracciamento dei
bugG , rilevamento dei problemi e gestione di progetti. Questo software permettere
di scegliere il tipo di ciclo di sviluppo con cui si preferisce gestire il progetto: nel
caso dell’azienda Zextras si adatta perfettamente alla metodologia di lavoro scelta e
al sistema ScrumG , in quanto permette di gestire al meglio gli sprintG e le relative
backlogG .
figure 2.6: Logo del servizio di issue-tracking Jira
2.2.2.3 Confluence
Confluence è un software di collaborazione per la creazione di documenti che
permette di creare, organizzare e lavorare su materiale condiviso. Permette di
centralizzare le informazioni, tenere traccia di ogni modifica e, inoltre, supporta
una gestione granulare dei permessi di accesso ad ogni singolo file.
figure 2.7: Logo del software per la gestione dei documenti Confluence
2.2.2.3.1 Jenkins Jenkins è uno strumento open sourceG per la continuous
integrationG e deploymentG . Con esso è possibile configurare uno o più lavori dove
ognuno di essi è composto da vari passaggi da svolgere per ottenere una buildG
corretta e funzionante del progetto che ci interessa. Inoltre terrà traccia tramite
una cronologia dell’andamento delle build, salverà l’output della console e quanti
successi/fallimenti ci sono stati, oltre a notificare, tramite email allo sviluppatore,
cosa è successo.8 CAPITOLO 2. L’AZIENDA
figure 2.8: Logo del strumento per la continuous integration Jenkins
2.2.2.4 SourceTree
SourceTree è un’applicazione utilizzata per gestire GitG in modo facile e rapido e
che fornisce un’interfaccia grafica semplice e intuitiva. Il software è completamente
gratuito e integra perfettamente con le piattaforme di Git più utilizzate, come
BitBucket.
figure 2.9: Logo dell’applicazione SourceTreeCAPITOLO 3
Organizzazione del progetto
3.1 Motivo del progetto
Team, l’applicazione in cui è stato integrato il lavoro implementato durante lo
stage, si appoggia al software Chat, modulo sviluppato da Zextras disponibile
come zimletG su Zimbra, che richiede l’installazione di Zextras core. L’obbiettivo
dell’azienda è di ottenere al termine dello stage un prototipo dell’applicazione di
messaggistica con le stesse funzionalità dell’applicazione web:
• verificare l’effettiva utilità del progetto;
• studiare le migliori soluzioni progettuali per sviluppare un’applicazione mobile
in linguaggio nativo, ambito non ancora affrontato dall’azienda;
• validare le tecnologie proposte e, in caso, proporre nuove libreria da integrare
per lo sviluppo;
• ampliare e/o modificare le proprie User Experience (UX) guidelinesG in base
alle differenze tra dispositivi mobile e desktop.
3.2 Piano di lavoro
Il progetto di stage proposto dall’azienda prevede un lavoro di 312 ore, così suddivise:
• Formazione (40h): introduzione a Zimbra, Zextras, agli strumenti e alle
procedure aziendali; inoltre viene dedicato del tempo alla formazione indivi-
duale sulle tecnologie da utilizzare per lo sviluppo di applicazioni mobile in
linguaggio nativo;
• Progettazione UX (40h): studio delle guidelinesG fornite dal team di designer
e applicazione di esse;
• Progettazione architetturale (40h): progettazione dell’architettura client/-
server necessaria per l’implementazione dell’applicazione seguendo le bozze
dell’UX;
910 CAPITOLO 3. ORGANIZZAZIONE DEL PROGETTO
• Implementazione (192): sviluppo di piccole applicazioni per apprendere il
linguaggio Swift ed entrate in confidenza con i diversi strumenti da utilizzare;
maggiore attenzione e impegno vengono riservati per lo sviluppo del controllerG
da integrare nell’applicazione con lo scopo di aumentare e migliore le sue
funzionalità.
3.3 Pianificazione del progetto
Dopo un primo periodo di formazione, viene pianificato in maggior dettaglio il
lavoro da svolgere. Le otto settimane di stage sono quindi suddivise in quattro sprint
di due settimane ognuno, riuscendo così a sincronizzare lo sviluppo dell’applicazione
con gli sprintG degli altri progetti seguiti dall’azienda. Al fine di seguire il metodo
lavorativo aziendale, viene associata una versione di releaseG del prototipo per
ognuno dei quattro sprint decisi.
I quattro sprint sono stati così suddivisi:
Sprint Inizio Fine Release
I 06/05/19 17/05/19 S1
II 20/05/19 31/05/19 S2
III 03/06/19 14/06/19 Beta
IV 17/06/19 28/06/19 Release
table 3.1: Organizzazione del progetto in sprintCAPITOLO 4
Tecnologie utilizzate
4.1 xCode
xCode è un ambiente di sviluppo integrato sviluppato da Apple per agevolare lo
sviluppo di software per Mac OS X. L’azienda ha scelto di utilizzare questo IDEG in
quanto lavora in congiunzione con Interface Builder, un toolG grafico che permette
di realizzare interfacce grafiche più velocemente e di gestirle in modo più semplice.
Inoltre è possibile espandere le capacità di questo IDE tramite l’installazione di
pluginG e offre l’integrazione con molteplici linguaggi di programmazione, tra cui
Swift.
figure 4.1: Logo dell’IDE xCode
4.2 Swift
Swift è un linguaggio di programmazione conciso, tipizzatoG , efficiente e facile da
imparare sviluppato da Apple e rilasciato nel 2014. Esso incorpora le caratteristiche
e funzionalità, ad esempio gli Optionals e le collezioni, appartenenti a vari linguaggi
di programmazione moderni, come C#, JavaScript, Python, Rust e Go. Rispetto
ad Objective-C,il suo predecessore, il codice risulta più conciso e leggibile, modifi-
candone la sintassi. È stato introdotto il concetto di type inference grazie al quale
non è necessario specificare esplicitamente il tipo di variabili e costanti se questo
può essere determinato dal contesto. Non è più necessario avere un header fileG
ed un implementation fileG separato per ogni classe, ma la definizione di queste
avviene in un unico file. Sebbene Swift non abbia ancora rimpiazzato del tutto
Objective-C, ne è stata preferita l’adozione poiché è un linguaggio più recente e
sul quale Apple stessa sta puntando molto. Inoltre si è deciso di utilizzare un
1112 CAPITOLO 4. TECNOLOGIE UTILIZZATE
linguaggio nativo per lo sviluppo dell’applicazione a causa dei precedenti risultati
non soddisfacenti ottenuti dall’azienda nel implementare questo tipo di applicazioni
sfruttando frameworkG cross-platformG .
figure 4.2: Logo del linguaggio di programmazione Swift
4.3 Realm Database
Realm è un sistema open sourceG utilizzato per la gestione di un database. Esso
offre, tra le funzionalità di base, le operazioni CRUDG e la trasformazione di oggetti
del database in oggetti Swift in modo automatico. L’applicazione utilizza questa
libreria per la creazione e la gestione del database locale nel quale salvare gli utenti,
i messaggi e le conversazioni. L’azienda ha deciso di utilizzare Realm in quanto i
risultati delle query sono delle viste locali al threadG di esecuzione della versione
del database al momento della richiesta. Tale viste vengono aggiornate in modo
automatico ogni qual volta una transazione del database viene conclusa, indipen-
dentemente dal thread in cui viene eseguita, e, in questo modo, lo sviluppatore non
deve preoccuparsi di eventuali conflitti di accesso ai dati del database.
figure 4.3: Logo del framework Realm
4.4 SVProgressHUD
SVProgressHUD è una libreria per mostrare e gestire in modo semplice e altamente
personalizzabile un elemento grafico che indica l’attesa della risposta di una certa
attività. All’interno del progetto viene utilizzata, ad esempio, nel momento in
cui l’utente fa la richiesta di modifica del topicG di un gruppo oppure quando
aggiorna l’immagine della chat. Si è scelto di utilizzare questa libreria poiché la
sua personalizzazione si adattava alle UX guidelinesG definite per l’applicazione.
figure 4.4: Esempio di progress bar costruita con SVProgressHUD4.5. ALAMOFIRE 13
4.5 Alamofire
Alamofire è la libreria divenuta ormai standard de facto per quanto riguarda il
networkingG in Swift, fornendo in modo semplificato una serie di funzionalità per
accedere allo stackG di networking definito dai prodotti Apple. Tra le funzionalità
base troviamo la possibilità di concatenare tra loro metodi di richiesta e risposta,
la serializzazione automatica dei parametri e delle risposte in formato JSON e
metodi di utilità per l’autenticazione. Poiché in questo modo semplifica il lavoro del
programmatore, all’interno del progetto tutte le richieste alla rete vengono gestite
utilizzando questa libreria.
figure 4.5: Logo della libreria Swift per il networking Alamofire
4.6 Alamofire Image
Alamofire Image è una libreria Swift, estensione della libreria Alamofire, che
semplifica la gestione e il download delle immagini. Il principale utilizzo di questo
software è il cachingG di immagini. All’interno del progetto viene utilizzata per
gestire le immagini di profilo di tutti gli utenti e dei diversi gruppi.
4.7 SwiftyJSON
SwiftyJSON è una libreria che semplifica la deserializzazioneG di oggetti JSON
in Swift, permettendo di disporre in serie vari tipi di oggetti come stringhe, array
e dizionari a partire da oggetti in formato JSON, oltre che fornire un insieme di
metodi utili per la modifica e la visita di JSONObject. Tra le funzionalità più
avanzate permette di creare metodi personalizzati per la deserializzazione di JSON
direttamente in classi Swift. L’utilizzo di questa libreria ha facilitato la gestione
dei JSON dati come risposta dalle chiamate API.
4.8 WebSocket
WebSocket è un protocolloG di messaggistica per la comunicazione bidirezionale su
connessioni TCPG . Una connessione di questo tipo nasce in modo molto simile a
una richiesta HTTPG , nella quale viene specificato dal clientG che si vuole utilizzare
questo tipo di protocollo. Sfruttando questo tipo di tecnologia si hanno risulti
più performanti rispetto ad altre soluzioni come il pollingG . Inoltre richiedono
meno banda poichè i messaggi di questo tipo non hanno necessità di alcun tipo di14 CAPITOLO 4. TECNOLOGIE UTILIZZATE
intestazione, semplificando inoltre il loro utilizzo. Questo protocollo è utilizzato per
la comunicazione tra l’applicazione e il server di Zextras.
4.9 Firebase Cloud Messaging
Firebase Cloud Messaging(FCM) è un servizio sviluppato da Google che permette
di salvare e sincronizzare i dati elaborati da applicazioni web e mobile. L’azienda
ha deciso di integrarlo nel progetto poiché è in grado di aggiornare i dati istantanea-
mente e i dati immagazzinati sono replicati e sottoposti a backupG continuamente
rendendo l’applicazione sicura.
La chat utilizza sia WebSocket che FCM per la comunicazione tra applicazione
e server poiché essa ha prestazioni migliori ma non è disponibile in tutti i Paesi
mentre WebSocket lo è e questa dualità rende il software disponibile ovunque.
figure 4.6: Logo del servizio Firebase Cloud MessagingCAPITOLO 5
Analisi dei requisiti
5.1 Attori
La parte di progettazione prevista dallo stage inizia con lo studio e l’analisi dei
requisiti. Questa attività ha lo scopo di individuare quali sono gli attori coinvolti e
come essi partecipano all’interno dello scenario studiato.
5.1.1 Attori primari
L’analisi dei requisiti ha evidenziato due tipologie di attori primari: l’utente non
autenticato e l’utente autenticato.
5.1.1.1 Utente non autenticato
Con utente non autenticato si definisce un utente in possesso di credenziali per
accedere a Zimbra. Ciò vuol dire che si può accedere all’applicazione solamente se
si è in possesso di un’email e una password registrate nel server Zimbra.
5.1.1.2 Utente autenticato
Con utente autenticato si indica l’utente che, attraverso l’inserimento di email
e password, ha eseguito l’acceso a Team e può usufruire delle varie funzionalità
dell’applicazione.
5.1.2 Attori secondari
Il sistema prevede solamente un attore secondario che è il server Zimbra.
5.1.2.1 Server Zimbra
Un server Zimbra è un’istanziazione della suiteG di prodotti Zimbra al quale è
stata aggiunta la suite Zextras. Tramite esso è possibile accedere a tutti i dati del
profilo Zimbra così da mantenerli sincronizzati tra i vari dispositivi in cui l’utente è
autenticato.
1516 CAPITOLO 5. ANALISI DEI REQUISITI
5.2 Casi d’uso principali
Considerando lo scopo del progetto di stage e il metodo di lavoro utilizzato, i casi
d’uso e i requisiti, una volta definiti, sono rimasti pressoché immutati durante tutto
l’arco del progetto. Per l’identificazione dei requisiti funzionali sono stati delineati i
casi d’uso principali tramite le richieste dell’azienda e quelli di alto livello, in modo
da poter dare un quadro generale più chiaro del prodotto sviluppato. Il diagramma
seguente rappresenta il diagramma dei casi d’uso principali.
figure 5.1: Diagramma dei casi d’uso5.3. REQUISITI 17
5.3 Requisiti
Ogni requisito è identificato da un codice che è così strutturato:
R{importanza}{tipo}{numero_vincolo}
• "R" è prefisso di tutti i codici dei requisiti;
• il primo valore rappresenta l’importanza: 0 se il requisito è obbligatorio, 1 se
è desiderabile, 2 per gli opzionali;
• il terzo valore indica il tipo: F per i requisiti funzionali, Q per quelli di qualità,
P se prestazionale, V se di vincolo;
• l’ultimo numero indica il numero del vincolo. La struttura numerica di
quest’ultimo rispetta le stesse regole dei Casi D’Uso.
5.3.1 Principali requisiti funzionali
Requisito Descrizione
L’utente autenticato deve poter accedere al dettaglio della chat di
R0F1
gruppo a cui sta partecipando.
R0F2 L’utente autenticato deve poter modificare l’immagine del gruppo.
L’utente autenticato deve poter visualizzare un messaggio di errore
R0F2.1
nel caso in cui il formato dell’immagine inserita sia errato.
R0F3 L’utente autenticato deve poter modificare il topic del gruppo.
L’utente autenticato deve poter visualizzare un messaggio di errore
R0F3.1
nel caso in cui sia inserito un topic troppo lungo.
L’utente autenticato deve poter abilitare e disabilitare le notifiche
R1F4
del gruppo.
L’utente autenticato deve poter aggiungere un nuovo membro al
R0F5
gruppo.
L’utente autenticato deve poter consultare la lista di tutti gli utenti
R0F6
Zimbra.
L’utente autenticato deve poter selezionare più utenti da aggiungere
R0F7
al gruppo.
R0F8 L’utente autenticato deve poter abbandonare il gruppo.
L’utente autenticato deve poter consultare la lista dei partecipanti
R0F9
alla chat.
L’utente autenticato deve poter visualizzare nella lista il nome di
R0F9.1
ogni partecipante alla chat.
L’utente autenticato deve poter visualizzare nella lista lo status di
R0F9.2
ogni partecipante alla chat.
L’utente autenticato deve poter visualizzare nella lista l’immagine
R0F9.3
profilo di ogni partecipante alla chat.
L’utente autenticato deve poter visualizzare la chat privata del
R0F10 membro del gruppo selezionato dalla lista dei partecipanti alla
chat.18 CAPITOLO 5. ANALISI DEI REQUISITI
L’utente autenticato deve poter tornare al dettaglio della chat
R0F11 uscendo dalla conversazione privata con il membro del gruppo
selezionato dalla lista dei partecipanti alla chat.
L’utente autenticato deve poter visualizzare la lista di media
R2F12
condivisi nella conversazione di gruppo.
L’utente deve poter visualizzare in dettaglio il media selezionato
R2F13
dalla lista.
L’utente autenticato deve poter visualizzare la lista dei link
R2F14
condivisi nella conversazione.
L’utente autenticato deve poter visualizzare in dettaglio il link
R2F15
selezionato dalla lista.
table 5.1: Requisiti funzionali
5.3.2 Requisiti di vincolo
Requisito Descrizione
L’applicazione deve essere sviluppa con linguaggio nativo Swift,
R0V1
versione 5.
L’applicazione deve essere supportata da modello iPhone5 o
R0V2
superiore.
L’applicazione deve essere supportata da modelli di iPhone con
R0V3
versione del sistema operativo maggiore uguale a iOS 10.
L’implementazione dell’interfaccia grafica deve utilizzare lo
R0V4
strumento di Auto Layout.
table 5.2: Requisiti di vincolo
5.3.3 Requisiti di qualità
Requisito Descrizione
L’applicazione deve aggiornare i dati in tutti i dispositivi in cui è
R0Q1
installata.
L’interfaccia grafica dell’applicazione deve seguire quanto indicato
R0Q2
dai documenti contenenti le UX guidelines.
La documentazione riguardante lo sviluppo dell’applicazione deve
R0Q3
essere sempre aggiornata e disponibile.
L’applicazione mobile deve contenere le stesse funzionalità della
R0Q4
corrispettiva applicazione web Teamwork.
table 5.3: Requisiti di qualitàCAPITOLO 6
Sviluppo
La codifica della parte di applicazione assegnatami per lo stage è stata preceduta
dall’attività di studio e comprensione dell’architettura generale di Team. Quest’ul-
tima è una applicazione di messaggistica istantanea pensata come integrazione
alla già presente suite di prodotti Zextras, con lo scopo di poter fornire le stesse
funzionalità dell’ambiente desktop in ambiente mobile. La sua progettazione ha
avuto inizio ad aprile da parte del team dedicato ed è stato necessario comprendere
la struttura del progetto e di quanto implementato per poter procedere con il lavoro
dello stage.
6.1 Gestione delle API
L’applicazione prevede l’utilizzo di tre canali per la comunicazione con il server,
ovvero: HTTPG , WebSocket and Firebase Cloud Messaging.
6.1.1 HTTP
Il protocolloG HTTP (HyperText Transfer Protocol) è un protocollo a livello appli-
cativo usato per la trasmissione di informazioni sul web in una tipica architetturaG
client-server. Questo protocollo è utilizzato nel contesto dell’applicazione per quasi
tutti i comandi del client e ogni richiesta viene autenticata attraverso un cookieG
standard. La trasmissione dei dati avviene mediante il sistema RESTG (Repre-
sentational State Transfer) che, a differenza di SOAPG , non aggiunge ulteriori
livelli per la trasmissione. Infatti le chiamate al server prevedono l’utilizzo di una
struttura ben definita degli UrlG , così da identificare in modo univoco una risorsa.
Quest’ultima restituita in risposta attraverso l’utilizzo dei metodi specifici, come
GET per il recupero dell’informazione e POST per la sua modifica.
1920 CAPITOLO 6. SVILUPPO
figure 6.1: Scambio di informazioni tra server e client utilizzando JSON e il protocollo
HTTP
6.1.2 WebSocket
Come avviene per l’applicazione web, il canale per le notifiche è implementato
sfruttando i WebSocket, in modo tale da notificare il clientG ogni qualvolta sia
necessario, evitando sprechi di batteria. Ogni connessione WebSocket inizia la
sua vita come una richiesta HTTPG . Tale richiesta è molto simile a tutte le altre
richieste salvo che nell’intestazione viene specificata un operazione di tipo Upgrade
che indica che il client vuole aggiornare la connessione ad un protocollo diverso,
in questo caso a WebSocket. Ad aggiornamento avvenuto si ha una connessione
di tipo WebSocket tra client e server: tale connessione riutilizza il canale creato
durante la fase iniziale tra le due e può essere utilizzato per le comunicazioni in
entrambe le direzioni.
L’operazione di Upgrade viene così eseguita: il server applica un’operazione nota
(sia al cliente che al server) al valore della chiave Sec–WebSocket–Key presente nel-
l’header della chiamata per generare il valore della Sec–WebSocket–Accept . Il client
fa la stessa operazione sempre sul valore della stessa chiave Sec–WebSocket–Key, e,
se il valore ricevuto dal server coincide con il valore calcolato dal client la connessio-
ne può considerarsi come stabilita con successo e client e server possono cominciare
a comunicare.6.1. GESTIONE DELLE API 21
figure 6.2: Scambio di informazioni tra client e server mediante WebSocket
6.1.3 Firebase Cloud Messaging
Diversamente dall’applicazione web, l’applicazione mobile utilizza anche Firebase
Cloud Messaging (FCM) per gestire l’invio e l’accodamento dei messaggi tra il
clientG e il server. Quando un messaggio è inviato dal server al client, il server invia
il messaggio a un server Google per le connessioni FCM. Quest’ultimo provvederà ad
inoltrare il messaggio al client quando l’applicazione è in esecuzione. Dal momento
che l’applicazione client può non essere sempre in esecuzione o connessa, il server
per le connessioni FCM accodano e salvano i messaggi prima di inoltrarli, in modo
tale che possano essere inviati quando l’applicazione client è raggiungibile. In
modo speculare questo avviene per i messaggi inviati dal client al server quando
quest’ultimo non è disponibile. Per questa ragione, a FCM non vengono affidate
notifiche di eventi in cui il tempo è un fattore determinante, come notificare se un
utente è online oppure offline, e quindi viene utilizzato insieme a WebSocket.22 CAPITOLO 6. SVILUPPO
figure 6.3: Funzionamento di Firebase Cloud Messaging
6.2 Codifica del controller
La progettazione di User Experience (UX) e di User Interface (UI) viene fatta dal
team di designer che mette a disposizione dei programmatori le linee guida da
adottare per creare la grafica dell’applicazione, definendo quali elementi devono
essere presenti e in che modo devono essere rappresentati.
Lo scopo è quello di migliorare l’esperienza utente, fornendogli nel modo più semplice
e intuitivo ciò che gli serve. Inoltre è importante trovare il giusto accostamento
di forme e colori, oltre a posizionare bene le call to action, ovvero quei bottoni
che se selezionati portano l’utente in una nuova vista. Quindi grazie a una buona
progettazione è possibile guidare l’utente all’interno delle viewG , indicandogli con
chiarezza e precisione dove può trovare ciò che cerca esclusivamente attraverso
l’interfaccia.
Il materiale che viene fornito dai grafici è reperibile sulla piattaforma Confluence
nella sezione dedicata e i file principalmente usati sono i seguenti:
• UX/UI Mockup Mobile;
• ColorsPalette for Group.6.2. CODIFICA DEL CONTROLLER 23
6.2.1 UX/UI Mockup Mobile
figure 6.4: Documento UX/UI Mockup Mobile24 CAPITOLO 6. SVILUPPO
Con questo documento vengono rappresentate tutte le schermate che è possibile
trovare all’interno dell’applicazione e il flusso che deriva da ciascuna di esse. Si
inizia dalla schermata di login e, in seguito all’autenticazione, viene presentata
la viewG con la lista delle proprie conversazioni. Da qui hanno origine tre flowG
distinti: avviare una nuova conversazione, entrare in una delle conversazioni già
presenti ed entrare nell’area "impostazioni". Se l’utente sceglie di iniziare una
nuova conversazione, può scegliere se crearla singola o di gruppo. Nel caso della
conversazione singola, si seleziona la persona con cui si desidera comunicare e infine
si apre la chat con cui si può iniziare lo scambio di messaggi. Nel caso, invece, della
conversazione di gruppo, compare anche in questo caso la lista di tutti gli utenti in
cui si possono selezionare al massimo 10 membri e successivamente viene chiesto
di inserire immagine e topicG del gruppo. Premendo su "crea", viene istanziata la
conversazione e si può iniziare lo scambio di messaggi. Inoltre, sia da chat singole
che di gruppo, si può accedere al dettaglio della conversazione.
Se, invece, l’utente seleziona direttamente una conversazione dalla lista, si accede
ad una chat precedentemente avviata in cui vengono mostrati tutti i messaggi che
si sono scambiati. Anche in questo caso si può accedere al relativo dettaglio.
Infine, se l’utente sceglie di accedere alle impostazioni, può entrare nella view con il
dettaglio del proprio profilo, impostare le preferenze delle notifiche, entrare nella
sezione delle licenze che utilizza l’applicazione, visionare le informazioni relative
all’applicazione e infine procedere con il logout da Team.
6.2.2 ColorsPalette for Group
#EF9A9A RGB rgb(239,154,154)
#F48FB1 RGB rgb(244,143,177)
#CE93D8 RGB rgb(206,147,216)
#B39DDB RGB rgb(179,157,219)
#9FA8DA RGB rgb(159,168,218)
#90CAF9 RGB rgb(144,202,249)
#81D4FA RGB rgb(129,212,250)
#80DEEA RGB rgb(128,222,234)
#80CBC4 RGB rgb(128,203,196)
#A5D6A7 RGB rgb(165,214,167)
#C5E1A5 RGB rgb(197,225,165)
#E6EE9C RGB rgb(230,238,156)
#FFE082 RGB rgb(255,224,130)
#FFCC80 RGB rgb(255,204,128)
#FFAB91 RGB rgb(255,171,145)
1
figure 6.5: Documento ColorsPalette for Group6.2. CODIFICA DEL CONTROLLER 25 Questo documento elenca i colori che l’applicazione deve adottare per generare l’avatarG degli utenti e dei gruppi sprovvisti di immagine, oltre che assegnarli all’interno della chat ai diversi membri di un gruppo per facilitare la distinzione dei messaggi appartenenti ad utenti diversi. Ogni colore viene rappresentato nella tabella con una raffigurazione visiva e le sue relative codifiche in formato esadecimale e RGBG . 6.2.3 Interface builder xCode, l’IDEG scelto per implementare questo progetto, offre la possibilità di costruire le interfacce grafiche attraverso l’uso di un interface builderG che facili- tà al programmatore il compito di comporre e collegare le viewG relative a una storyboard. Le view sono gli elementi che rappresentano una specifica schermata dell’applicazione, come, per esempio, il dettaglio di una conversazione. Con story- board, letteralmente "tavola della storia", si intende l’insieme di viste che definisce un flusso di azione dell’applicazione. Nel caso specifico del lavoro svolto durante lo stage, lo storyboard utilizzato è stato il "Conversation.storyboard" in cui sono presenti diverse view: partendo dalla vista della conversazione, collegata al relativo dettaglio di chat, fino alla schermata con la lista di utenti da poter aggiungere alla conversazione. Una delle funzionalità principali dell’interface builder è la gestione delle constraintG , ovvero dei vincoli a cui sono legati gli elementi grafici. Questi vincoli sono necessari affinché gli elementi grafici mantengano la stessa disposizione e le stesse propor- zioni indipendentemente dalla grandezza dello schermo del dispositivo in cui viene installata l’applicazione e dall’orientamento in cui esso viene utilizzato.
26 CAPITOLO 6. SVILUPPO 6.2.4 Struttura dell’applicazione L’applicazione segue il patternG Model-View-Controller (MVC). Infatti per quanto riguarda la business logicG , i dati necessari al funzionamento dell’applicativo vengo- no recuperati dai server utilizzando WebSocket e/o Firebase e vengono memorizzati all’interno di un database locale al dispositivo mobile. Per questo viene utilizzato Realm (aggiungere riferimento) che grazie alla sua gestione automatica dei conflitti che potrebbero nascere dalla modifica concorrente dei dati, semplifica il lavoro al programmatore. La View è costruita seguendo le linee guida fornite dagli UX/UI designer prima di procede all’implementazione della logica del Controller. Essa rappresenta il dettaglio della chat di gruppo che prevede l’utilizzo di una tabella con tre sezioni: informazioni, impostazioni e partecipanti del gruppo. Le prime due sezioni sono statiche, ovvero è fisso il numero di celle che le compongono, mentre la terza e ultima sezione è dinamica, quindi il numero di celle cresce e/o diminuisce dinamicamente in base al numero di partecipanti. Inoltre ogni cella è collegata ad una azione, se questa la prevede: premendo la cella in cui compare il nome del gruppo viene mostrato una finestra per modificarne il topic, cliccando su "Invita partecipanti" si accede alla viewG con la lista di tutti gli utenti presenti in Team che si possono aggiungere alla conversazione, con la cella con scritto "Abbandona il gruppo" si può compiere l’omonima azione mentre selezionando uno dei membri della lista dei partecipanti è possibile aprire la conversazione privata con quell’utente. Infine il Controller si occupa di legare i dati della business logic con la loro rappre- sentazione visiva. In particolare, questa componente dell’architettura ha il compito, come citato prima, di recuperare i dati dal server, oltre che elaborarli e aggiornarli in seguito a interazioni dell’utente con l’interfaccia grafica.
CAPITOLO 7
Verifica e Validazione
La parte conclusiva dello stage si è focalizzata sull’implementazione dei test au-
tomatici e, in parte, dei test manuali. La loro esecuzione, dando esito positivo, è
stata fondamentale per garantire il soddisfacimento dei requisiti concordati con
l’azienda oltre che alla correttezza del codice.
7.1 Unit Test
Gli unit test sono una parte dei test automatici che sono stati implementati e il
loro scopo è testare una singola componente del programma. Per creare dei test di
unità che siano indipendenti dalla connessione al server e dal loro stato, sono stati
implementati degli StubG che riproduco le risposte del server che si vogliono ottenere
nell’esecuzione di un determinato test. In questo modo è possibile concentrarsi
solamente nella porzione di codice scritta tralasciando gli errori che potrebbero
derivare da fattori esterni.
Gli unit test da me implementati hanno lo scopo di controllare che la manipolazione
e il salvataggio dei dati in locale avvenga nella maniera attesa, sia nel caso in cui i
dati siano corretti sia nel caso in cui l’inserimento non vada a buon fine. Inoltre vi
sono anche degli unit test che certificano le richieste che vengono fatte al server e
anche in questo caso, viene testano sia il successo che il fallimento della chiamata
all’APIG .
7.2 UI Test
Gli UI Test (User Interface Test) identifica i test che vengono eseguiti utilizzando
direttamente l’interfaccia grafica per verificare che non vi siano difetti nell’applica-
zione. Esistono diversi approcci per implementarli ed eseguirli, come ad esempio
l’approccio manuale e l’approccio "cattura e ripeti".
L’approccio manuale consiste nell’eseguire a mano di ogni singolo test e questo
comporta molti svantaggi: data la necessità dell’intervento di un operato umano,
si ha un maggiore impiego di tempo e una maggiore probabilità di errore rispetto
all’esecuzione di un test automatico.
L’approccio capture & replay prevede la cattura delle azioni che vengono fatte
2728 CAPITOLO 7. VERIFICA E VALIDAZIONE
dal tester e le codifica in istruzioni da eseguire. In questo modo è possibile poter
replicare la stessa sequenza di azioni ogni qualvolta che viene eseguito il test.
Gli UI test da me implementati, che seguono quest’ultimo approccio, hanno lo
scopo di testare la corretta sequenza di azioni e componenti utilizzate per eseguire
un determinato flowG . Ogni flow ha partenza dalla schermata di login che appare
quando viene installata l’applicazione per la prima volta e termina in una delle
successive schermate. In tal modo è possibile verificare in modo automatico il
raggiungimento di ogni vista eseguendo i passi corretti.
7.3 Test manuali
Infine ho eseguito una parte di test manuali per verificare la corretta impostazione
delle constraintG e il relativo autolayoutG . Per fare ciò ho utilizzato il simulatore
messo a disposizione da xCode che permette di eseguire l’applicazione su diversi
dispositivi. I dispositivi testati sono:
• iPhone 5s;
• iPhone 6;
• iPhone 7;
• iPhone 8 Plus;
• iPhone X;
• iPhone XS Max.
Si è scelto di testare solo questi dispositivi mobili poiché offrono una gamma di
diverse dimensioni dello schermo sufficientemente ampia da ricoprire una grande
porzione dei smartphone attualmente in commercio.
7.4 Beta test
Con il rilascio della beta, inizia la fase di beta testing interno in cui l’applicazione è
stata rilasciata all’interno dell’azienda. Ciò è possibile utilizzando il software Test
Flight.
7.4.1 Test Flight
TestFlight è una piattaforma utilizzata per testare applicazioni non ancora presenti
nello storeG ufficiale, usufruibile da chiunque sia stato invitato a provare la beta.
Tramite questo programma si ha la possibilità di distribuire l’applicazione fino ad
un massimo di 25 persone. Grazie ai beta tester, gli sviluppatori riceveranno dati
concernenti lo stato dell’applicazione in funzione, insieme agli errori e i warningG
emersi, così da avere una overviewG generale del funzionamento dell’applicazione
su altri device. Inoltre i betaG tester possono inviare segnalazione e suggerimenti.
Dopo questa prima fase di testing interno, si procedere ad un testing esterno
arrivando successivamente a pubblicare l’applicazione nell’Apple Store.CAPITOLO 8
Conclusioni
8.1 Valutazioni del prodotto finale
Il lavoro svolto durante il periodo di stage soddisfa a pieno tutti i requisiti definiti
dall’azienda nel piano di lavoro e si integra senza alcun problema con quanto
già implementato, sia del punto di vista grafico che da quello delle funzionalità
offerte. Gli elementi presenti nel dettaglio della chat di gruppo sono sufficienti
per un uso piacevole dell’applicazione, anche se non sono ancora presenti degli
elementi tra quelli definiti dai requisiti complessivi di Team, ovvero lo switch per
attivare e disabilitare le notifiche per la chat e gli share di immagini e link. Tale
mancanza è dovuta alle criticità riscontrate dal team back end nel strutturare le
adeguate chiamate API. Per questo motivo, il rilascio degli share, come quello
dell’impostazione delle notifiche, è previsto per la prossima release.
Il team mobile è riuscito a progettare un’applicazione che possa essere usufruibile
e utile agli utenti della suite Zextras, andando a colmare un vuoto che è presente
nell’ambito della comunicazione tramite dispositivi mobili.
Il team di UX/UI ha saputo definire un’interfaccia grafica che semplifica l’utilizzo
dell’applicazione, rispettando le linee guida utilizzate dalle app di messaggistica
mobile più famose, come WhatsApp e Telegram. Ciò permette di fornire all’utente
finale un’esperienza di utilizzo più piacevole e uniforme, oltre che semplificare
il mio lavoro di sviluppo, in quanto sono abituata ad utilizzare le piattaforme
precedentemente citate e quindi consapevole delle funzionalità offerte.
Il prodotto, alla fine del mio stage, è ancora alla versione betaG : le funzionalità
di base sono infatti già implementate, ma il rilascio interno all’azienda ha fatto
emergere delle problematiche che non erano state evidenziate dal team mobile nella
fase di testing.
29Puoi anche leggere
