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
Sviluppo di un’applicazione iOS per il personale
retail
Tesi di laurea triennale
Relatore
Prof.Francesco Ranzato
Laureando
Andrea Pavin
Anno Accademico 2018-2019
Andrea Pavin: Sviluppo di un’applicazione iOS per il personale retail, Tesi di laurea triennale, c Dicembre 2019.
A Gabriella Dino e Giulia
Sommario
Il presente documento descrive il lavoro svolto durante il periodo di stage, della
durata di circa trecento ore, dal laureando Andrea Pavin presso l’azienda Zero12
s.r.l.
Il lavoro svolto consiste nella realizzazione di una parte di un’ applicazione mobile
iOS, di questa era necessario creare il layout di più schermate, definire il loro
comportamento, sviluppare un back-end a supporto della sezione.
vRingraziamenti
Innanzitutto, vorrei esprimere la mia gratitudine al Prof. Ranzato Francesco, relatore
della mia tesi, per l’aiuto e il sostegno fornitomi durante la stesura del lavoro.
Desidero ringraziare con affetto i miei genitori per il sostegno, il grande aiuto e per
essermi stati vicini in ogni momento durante gli anni di studio.
Un caloroso ringraziamento va agli amici che ho avuto modo di conoscere in questi
anni di università che mi hanno fornito sostegno, risate e conforto.
Padova, Dicembre 2019 Andrea Pavin
viiIndice
1 Introduzione 1
1.1 Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.1 Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Proposta di stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Organizzazione del testo . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Descrizione dello stage 5
2.1 Introduzione al progetto . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Analisi preventiva dei rischi . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Obiettivi aziendali . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Obiettivi formativi . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Pianificazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Metodologia di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6 Team di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Analisi dei requisiti 9
3.1 Requisiti fissati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Tabelle dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4 Tecnologie e strumenti utilizzati 13
4.1 Versionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Linguaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 IDE[g] e editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4 Framework e librerie . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4.1 CocoaPods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.2 Mongoose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.5 Database e servizi di archiviazione . . . . . . . . . . . . . . . . . . . 18
4.5.1 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5.2 Amazon S3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.6 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.6.1 Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.6.2 Simulatore iPhone . . . . . . . . . . . . . . . . . . . . . . . . 19
5 Panoramica su iOS 21
5.1 Architettura iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
ixx INDICE
5.2 Modalità sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3 Architettura Model View Controller . . . . . . . . . . . . . . . . . . 23
6 Sviluppo Applicazione iOS 25
6.1 Inizio del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2 Organizzazione cartelle . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.3 Codifica programmatica dell’interfaccia grafica . . . . . . . . . . . . 26
6.4 Schermate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.4.1 Scelta della modalità di autenticazione . . . . . . . . . . . . . 27
6.4.2 Login tramite certificato . . . . . . . . . . . . . . . . . . . . . 28
6.4.3 Login standard . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.4.4 Sezione store experience . . . . . . . . . . . . . . . . . . . . . 29
6.4.5 Daily morning brief . . . . . . . . . . . . . . . . . . . . . . . 29
6.4.6 Let’s Talk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.4.7 Feedback utente . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.4.8 Lista prodotti . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.4.9 Feedback prodotto . . . . . . . . . . . . . . . . . . . . . . . . 32
6.5 Gestione richieste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7 Sviluppo Back-end 35
7.1 Organizzazione server-side . . . . . . . . . . . . . . . . . . . . . . . . 36
7.2 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.3 Caricamento di File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.4 Localizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8 Conclusioni 41
8.1 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . 41
8.2 Stato finale del prodotto . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.3 Conoscenze acquisite . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.4 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Glossary 45
Acronyms 49Elenco delle figure
1.1 Logo Zero12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.1 Logo di Swift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Logo di JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Logo di Xcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Logo di CocoaPods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5 Logo di Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.6 Logo di MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.7 Logo di Amazon S3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.8 Logo di Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1 Architettura del sistema operativo iOS . . . . . . . . . . . . . . . . . 21
5.2 Un’applicazione iOS operante nella sua directory in modalità sandbox 23
6.1 Tab bar dell’applicazione . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2 Schermata di scelta login . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3 Schermata del login standard . . . . . . . . . . . . . . . . . . . . . . 28
6.4 Schermata della sezione Store experience . . . . . . . . . . . . . . . . 29
6.5 Diagramma delle classi per il calendario nella schermata Daily morning
brief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.6 Schermata della card Let’s Talk . . . . . . . . . . . . . . . . . . . . . 30
6.7 Schermata di feedback utente . . . . . . . . . . . . . . . . . . . . . . 31
6.8 Schermata della lista prodotti . . . . . . . . . . . . . . . . . . . . . . 32
6.9 Schermata del feedback prodotto . . . . . . . . . . . . . . . . . . . . 32
7.1 Architettura del back-end . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2 Lista (incompleta) categorizzata delle richieste in Postman . . . . . . 38
xixii ELENCO DELLE TABELLE
8.1 Requisiti soddisfatti e non soddisfatti . . . . . . . . . . . . . . . . . . 41
Elenco delle tabelle
2.1 Tabella della pianificazione settimanale . . . . . . . . . . . . . . . . . 7
3.1 Tabella dei requisiti obbligatori . . . . . . . . . . . . . . . . . . . . . 11
3.2 Tabella dei requisiti desiderabili . . . . . . . . . . . . . . . . . . . . . 11
3.3 Tabella del tracciamento dei requisiti formativi . . . . . . . . . . . . 12
7.1 Tabella CRUD-HTTP . . . . . . . . . . . . . . . . . . . . . . . . . 37Capitolo 1
Introduzione
1.1 Stage
L’attività di stage è obbligatoria e prevista dal piano di studi, lo scopo è quello di
dare l’opportunità di vivere un esperienza professionale nella fase finale del ciclo di
laurea. Al fine di scegliere l’azienda in cui effettuare lo stage in modo oculato ho
deciso di partecipare all’iniziativa denominata Stage-IT, organizzata da Confindustria
Padova in collaborazione con l’Università di Padova e Venezia. Per l’evento, ho
stilato una lista di possibili aziende a cui presentarmi, facendo soprattutto attenzione
ai progetti proposti. Dopo aver discusso con vari rappresentanti aziendali all’evento,
nonostante molti progetti avessero attratto la mia curiosità, la mia scelta è ricaduta
su quello proposto da Zero12 s.r.l.
Questi i motivi:
• le tecnologie proposte mi sono sembrate moderne, interessanti e utili per il
futuro;
• l’ambiente lavorativo, già brevemente conosciuto durante il progetto di inge-
gneria del software, mi è parso dinamico e giovanile;
• la taglia del progetto era abbastanza grossa sicchè era prevista l’integrazione
in un team di sviluppo;
• la difficoltà nel portarlo a termine, sulla carta, era piuttosto elevata, permet-
tendomi di confrontarmi con le mie capacità e forzandomi ad imparare.
1.2 L’azienda
Zero12 è un’azienda padovana il cui focus è la progettazione e realizzazione di solu-
zioni cloud basate su tecnologie Amazon. Nasce nel 2012 dall’ idea di quattro soci,
con un approccio da start-up. Nel corso di 7 anni è arrivata ad avere 14 dipendenti
in un ambiente di lavoro dinamico e giovane, ma contemporaneamente professionale.
È uno dei partner principali di Amazon Web Services in Italia, affiancando prestigiosi
brand nei settori più importanti del Made in Italy e realizzando progetti cloud
che favoriscono l’internazionalizzazione delle aziende e l’engagement dei clienti. Ha
realizzato numerose soluzioni innovative: nell’Automotive, per esempio, ha elaborato
12 CAPITOLO 1. INTRODUZIONE
Figura 1.1: Logo Zero12
la possibilità di identificare un veicolo ovunque esso si trovi per inviare dei soccorsi
in caso di necessità in tempi brevi; nel settore Fashion & Luxury ha sviluppato un
progetto che permette di utilizzare la realtà aumentata per creare nuove esperienze
di acquisto e, in ambito sportivo, ha usato la tecnologia per creare nuove forme di
allenamento. Ha inoltre realizzato progetti di predictive maintenance nel settore
manifatturiero, applicazioni mobile per rendere l’esperienza utente sempre più coin-
volgente e soluzioni di videoanalisi sia in ambito sicurezza sia nel settore retail, il
tutto sfruttando la piattaforma Amazon Web Services.
Zero12 si basa su una concezione di lavoro innovativa , sulla motivazione della diri-
genza e del personale e sull’impegno a rinnovare metodologie e organizzazione.
Questi i quattro pilastri fondamentali dell’azienda:
• Fiducia tra il personale e la dirigenza che comporta il riconoscimento, la
valorizzazione e il rispetto delle competenze specifiche di ciascuno;
• Autonomia di ciascun dipendente, conseguente alla conoscenza approfondita e
precisa del progetto e dei suoi obiettivi;
• Sostenibilità del progetto, garantita da un costante monitoraggio dei suoi costi;
• Cooperazione e buone relazioni sociali che accrescono il benessere nel luogo di
lavoro e rendono le persone più sane, ispirate e produttive.
1.2.1 Servizi
Cloud computing
L’azienda offre un supporto verticale per l’analisi, progettazione e sviluppo
di soluzioni cloud pubblico, privato ed ibrido. Offre ai propri clienti tutte le
garanzie per la migrazione o realizzazione di nuovi processi aziendali su cloud,
gestendo infrastrutture virtuali capaci di adattarsi in qualsiasi momento ad
ogni esigenza del cliente;
Mobile application
Zero12 s.r.l. si propone come supporto alle aziende che vogliono dare la possi-
bilità al proprio personale di svolgere l’attività lavorativa anche in mobilità. Si
propongono, quindi, come punto di riferimento per la realizzazione di applica-
zioni mobile, in grado di interfacciarsi a sistemi informativi aziendali esistenti,
aumentandone così la fruibilità e l’utilizzo;1.3. PROPOSTA DI STAGE 3
Web application
L’azienda offre la possibilità di analizzare, progettare e sviluppare Web Applica-
tion, sfruttando al meglio servizi di Cloud Computing e garantendo scalabilità,
affidabilità ed efficienza maggiori rispetto all’utilizzo di classici Server.
1.3 Proposta di stage
La proposta consiste nella realizzazione di una parte di una applicazione mobile
che verrà messa effettivamente in atto, per un cliente operante nel settore Fashion
& Luxury. Questa applicazione servirà al personale dei negozi come digital hub e
strumento di formazione immediato e rapido. Vista la mole dell’ applicazione allo
stagista è richiesto di realizzarne solo parti.
1.4 Organizzazione del testo
Il secondo capitolo offre una panoramica sullo stage, obiettivi, rischi e metodologia
di sviluppo.
Il terzo capitolo descrive i requisiti del progetto.
Il quarto capitolo descrive le tecnologie e gli strumenti utilizzati durante il pro-
getto.
Il quinto capitolo approfondisce il sistema su cui viene eseguita l’applicazione.
Il sesto capitolo descrive lo sviluppo e i risultati dell’applicazione iOS.
Nel settimo capitolo descrive lo sviluppo e lo stato finale del back-end.
Nell’ottavo capitolo descrive le conclusioni tratte dal periodo di stage.
Riguardo la stesura del testo, relativamente al documento sono state adottate le
seguenti convenzioni tipografiche:
• gli acronimi, le abbreviazioni e i termini ambigui o di uso non comune menzionati
vengono definiti nel glossario, situato alla fine del presente documento;
• per la prima occorrenza dei termini riportati nel glossario viene utilizzata la
seguente nomenclatura: parola [g]
• i termini in lingua straniera o facenti parte del gergo tecnico sono evidenziati
con il carattere corsivo.
• i termini riguardanti parti di codice sono evidenziati con il font courier.Capitolo 2
Descrizione dello stage
2.1 Introduzione al progetto
Come descritto brevemente nell’introduzione l’applicazione servirà al personale dei
negozi come digital hub e strumento di formazione, per capire più profondamente
la soluzione che si vuole mettere in atto è necessario definire le personas[g] che, con
ruoli diversi, interagiranno con la piattaforma:
Client Advisor: è il personale di store a cui è destinata tutta l’attività di informa-
zione e formazione. Rappresenta l’utente principale della piattaforma;
Store Manager: è il coordinatore dello store a cui rispondono tutti i Client Advisor.
Il suo ruolo è quello di creare le condizioni tali per cui i Client Advisor possano
svolgere al meglio il proprio lavoro. Rappresenta il secondo destinatario del
progetto;
Content creator: rappresenta le personas dell’HQ (headquarter ) che si occuperanno
di creare i contenuti;
Coordinator: rappresenta le personas operanti dal quartier generale, che si oc-
cuperanno di definire il piano editoriale e coordinare i content creator nella
generazione delle informazioni richieste;
Translator: rappresentano le personas esterne all’azienda il cui ruolo è quello di
tradurre i contenuti nelle diverse lingue in cui i contenuti saranno disponibili.
Si capisce quindi che è necessario dividere il sistema in due sotto-piattaforme: una
per la fruizione e una per la creazione dei contenuti, la fruizione avverrà tramite
applicazione iOS[g] installata sui dispositivi di client advisor e store manager mentre
i contenuti verranno inseriti tramite content management system[g] attraverso la
parte web .
In un contesto di lavoro comprendente un team di 8 persone mi sono state affidate le
seguenti sezioni:
Autenticazione: sezione dell’app da cui è possibile autenticarsi tramite SSO[g] o
login standard.
Morning Brief: sezione dell’app, navigabile per data, mediante la quale è possibile
leggere i dettagli dei morning briefs[g] .
56 CAPITOLO 2. DESCRIZIONE DELLO STAGE
Store Experience: sezione dell’app mediante la quale l’utente, compilando dei form,
potrà inviare delle opinioni, necessità o qualsiasi altra cosa all’HQ. Allo stesso
tempo sarà possibile rilasciare feedback su una lista di prodotti rispondendo a
diverse domande.
Di queste sezioni ho sviluppato front-end[g] e back-end[g] , non era richiesto lo sviluppo
della piattaforma amministrativa, cioè il mezzo mediante il quale il personale potrà
creare e inserire i contenuti da visualizzare nell’applicazione.
2.2 Analisi preventiva dei rischi
Per prevenire e arginare situazioni potenzialmente pericolose, durante la fase di
analisi iniziale e sotto avviso del tutor aziendale sono stati individuati alcuni possibili
rischi a cui si potrà andare incontro. Si è quindi proceduto a elaborare delle possibili
soluzioni per far fronte a tali rischi.
1. Difficoltà nel comprendere il contesto mobile
Descrizione: É probabile che lo stagista non abbia esperienza con progetti mobile,
un progetto di taglia come da offerta stage potrebbe non rispettare tempi e qualità
previste.
Soluzione: accurato studio del dominio e coinvolgimento del mobile solution
director (direttore per le soluzioni mobile) dell’azienda.
2. Rapporti con team di sviluppo
Descrizione: É possibile che lo stagista non sia in grado di lavorare efficientemente
in un team di sviluppo già consolidato.
Soluzione: impegno di adattamento da parte dello stagista e coinvolgimento del
referente aziendale in caso di problematiche.
3. Postazione di lavoro non collegata a gruppo di continuità
Descrizione: Frequenti spegnimenti inattesi del computer per sbalzi di tensione.
Soluzione: salvataggi e allineamenti con l’ambiente di lavoro condiviso frequenti.
4. Scarsa familiarità con sistemi operativi Apple iOS e macOS
Descrizione: É possibile che la scarsa familiarità con sistemi operativi nuovi abbassi
l’efficienza del lavoro.
Soluzione: breve studio dei sistemi operativi apple e memorizzazione delle shortcut.
2.3 Obiettivi
2.3.1 Obiettivi aziendali
ID Priorità Descrizione
O001 Obbligatorio Creazione schermate principali
O002 Obbligatorio Creazione API[g] REST[g] JSON[g]
O003 Obbligatorio Interfacciamento API
D001 Desiderabile Gestione contenuti multi-lingua
D002 Desiderabile Gestione targettizzazione2.4. PIANIFICAZIONE 7
2.3.2 Obiettivi formativi
I risultati da raggiungere per quanto riguarda la proprietà formativa dello stage sono
i seguenti:
• Avvicinarsi allo sviluppo di applicazioni mobile;
• Avvicinarsi alla progettazione e sviluppo di applicativi in ambito enterprise nel
settore retail ;
• Essere inserito in un contesto operativo dinamico;
• Sperimentare tecnologie interessanti.
2.4 Pianificazione
Di seguito è riportato il piano di lavoro previsto per le 8 settimane di stage per 40
ore a settimana:
Tabella 2.1: Tabella della pianificazione settimanale
Settimana Periodo Compito (Task )
1 2 - 6 Settembre Studio Swift e analisi del progetto
Progettazione e sviluppo sezione Login e allacciamento
2 9 - 13 Settembre
a back-end pre-esistente
3 16 - 20 Settembre Progettazione e sviluppo sezione morning briefs
4 23 - 27 Settembre Progettazione e sviluppo sezione feedback utente
5 30 Settembre - 4 Ottobre Progettazione e sviluppo sezione feedback prodotti
Studio e analisi MongoDB, REST, NodeJs e librerie
6 7 - 11 Ottobre
annesse
Progettazione e sviluppo Application Program Interface
7 14 - 18 Ottobre
(API) REST JSON
8 21 - 25 Ottobre Collegamento api al front-end
2.5 Metodologia di sviluppo
L’azienda utilizza una modalità di sviluppo che segue i principi delle metodologie
Agile[g] :
Persone ed iterazioni piuttosto che processi e strumenti;
Collaborazione col cliente piuttosto che negoziazione del contratto;
Software funzionante piuttosto che avere una documentazione esaustiva;
Risposta al cambiamento piuttosto che seguire un piano.
Zero12 segue questi principi mettendo in atto:8 CAPITOLO 2. DESCRIZIONE DELLO STAGE
Stretta collaborazione: il team si muove in modo coordinato e collabora con
i clienti coinvolgendoli costantemente nell’evoluzione del progetto attraverso
conference call, meeting online, attività emphon-site o presso la nostra struttura.
Il rapporto di collaborazione con il cliente nasce prima della negoziazione,
vengono condivisi eventuali problemi e, in modo trasparente, si fa assieme una
retrospettiva per crescere ed ottenere il risultato migliore;
Valorizzare il team: il team deve essere responsabile delle soluzioni e dei servizi
che offre, per fare questo deve essere coinvolto in ogni fase del processo deci-
sionale ed autonomo nel prendere decisioni. La nostra è una scelta difficile e
richiede una cultura aziendale forte ma siamo convinti che sia finito il tempo
delle organizzazioni gerarchiche e “ippopotamiche”, dove più in alto sei posizio-
nato nella piramide e più importante è il tuo giudizio. . . il parere di tutti è
fondamentale perché le buone idee nascono da ognuno di noi;
Feedback Rapidi: nel processo di innovazione, che prevede lo sviluppo di software,
il rischio di errori di progettazione si riduce di molto grazie al rilascio periodico
di quanto realizzato ( Iterazioni brevi di delivery ). Questo permette di applicare
la soluzione al contesto operativo e di raccogliere feedback costanti e precisi
dalle persone che realmente la utilizzeranno;
Realizzare soluzioni semplici: nello sviluppo di un software, così come anche di
un servizio o prodotto, è fondamentale partire dalle funzioni necessarie e non da
quelle che potrebbero esserlo. Per fare questo è necessario realizzare soluzioni
semplici e minimali che consentono all’utente di raggiungere benefici concreti.
Zero12 - Metodologia Agile. url: http://www.zero12.it/metodologia-agile/
2.6 Team di sviluppo
Dopo aver appreso in modo teorico e pratico le basi delle tecnologie che avrei dovuto
adoperare, sono stato inserito in un team di 8 persone, queste comprendevano sia il
personale addetto al back-end sia quello addetto unicamente all’applicazione, io ed
altri membri abbiamo operato su entrambi i lati. Per la comunicazione del gruppo
sono stati instaurati dei canali grazie all’applicativo slack. Si sono inoltre svolti dei
meeting in cui si è discusso estensivamente dello stato del progetto e organizzate le
task future.Capitolo 3
Analisi dei requisiti
3.1 Requisiti fissati
L’individuazione dei requisiti è stata effettuata basandosi su
• studio del progetto;
• meeting aziendali;
• direttive del cliente;
• mockup delle schermate dell’applicazione;
• user-stories compilate in meeting precedenti al mio arrivo.
I requisiti sotto esposti non corrispondono in tutto a quelli stilati inizialmente visto
che il cliente, durante lo svolgimento del progetto, ha più volte cambiato idea su
alcune parti
Sono stati individuati diversi tipi di requisiti e si è quindi fatto utilizzo di una
classificazione per distinguerli.
Il codice dei requisiti è così strutturato:
R[T ipo] − [N umero]
dove T ipo corrisponde a :
O: obbligatorio, un requisito che deve essere necessariamente soddisfatto in quanto
richiesto dal committente;
D: desiderabile, un requisito non vincolante o non strettamente necessario ma dal
riconoscibile valore aggiunto;
F: formativo, un requisito che ha come scopo l’insegnamento o l’apprendimento
di una nozione.
Il valore T ipo è invece un valore numerico incrementale che rende il codice univoco.
Nelle tabelle 3.1, 3.2 e 3.3 sono riassunti i requisiti.
910 CAPITOLO 3. ANALISI DEI REQUISITI
3.2 Tabelle dei requisiti
Per quanto riguarda i requisiti estrapolati, questi mirano a delineare il funzionamento
atteso dell’applicazione:
• l’autenticazione (da RO-1 a RO-4), regola l’accesso dell’utenza al sistema;
• la sezione di feedback utente (da RO-8 a RO-8.2), che permette all’utente di
inviare un feedback all’HQ;
• la sezione di feedback prodotto (da RO-9 a RO-9.1.4), che permette all’utente
di inviare un feedback sui prodotti del negozio all’HQ;
• la necessità di rispettare l’estetica e il comportamento grafico concordati (RO-5);
• la necessità dell’applicazione di essere fruibile in più lingue, dato il dislocamento
degli store (RO-6 e RD-2);
• la necessità (implicita) di un back-end a supporto delle network operations
(RO-10);
• la necessità di gestire le informazioni che ogni categoria di utenza ha a
disposizione (RD-1).
I requisiti formativi rappresentano finalità dell’azienda rispetto al periodo di stage.3.2. TABELLE DEI REQUISITI 11
Tabella 3.1: Tabella dei requisiti obbligatori
Requisito Descrizione
RO-1 L’applicativo deve permettere l’accesso ad un utente tramite
certificato installato sul dispositivo
RO-2 L’applicativo deve permettere l’accesso ad un utente tramite nome
utente e password
RO-3 L’utente visualizza messaggio di errore per autenticazione con
certificato fallita
RO-4 L’utente visualizza messaggio di errore per autenticazione standard
fallita
RO-5 L’applicativo deve mostrare ogni schermata secondo layout e
comportamento grafico concordato (proveniente dal cliente)
RO-6 L’applicativo deve essere multilingua
RO-7 L’utente visualizza il contenuto del morning brief
RO-7.1 L’utente può selezionare una data, compresa entro le ultime tre
settimane correnti, e vederne il contenuto associato
RO-8 L’utente visualizza un form per l’invio di un feedback utente
RO-8.1 L’utente visualizza un messaggio di errore quando il form non è stato
compilato correttamente
RO-8.2 L’utente visualizza un messaggio di successo quando il form è stato
compilato correttamente
RO-9 L’utente visualizza una lista di prodotti da recensire
RO-9.1 L’utente, selezionando un prodotto, visualizza un form per l’invio di
un feedback prodotto
RO-9.1.1 L’utente visualizza una lista di domande dinamiche nel form
RO-9.1.2 L’utente visualizza un messaggio di errore quando il form non è stato
compilato correttamente
RO-9.1.3 L’utente visualizza un messaggio di successo quando il form è stato
compilato correttamente
RO-9.1.4 L’applicativo elimina il prodotto dalla lista con un’animazione quando
il form è stato compilato e inviato correttamente
RO-10 L’applicativo deve disporre di un back-end a supporto delle funzioni
sopracitate
Tabella 3.2: Tabella dei requisiti desiderabili
Requisito Descrizione
RD-1 Il back-end deve gestire la targettizzazione dei contenuti
RD-2 Il back-end deve gestire la localizzazione dei contenuti12 CAPITOLO 3. ANALISI DEI REQUISITI
Tabella 3.3: Tabella del tracciamento dei requisiti formativi
Requisito Descrizione
RF-1 Lo stagista deve apprendere le modalità di sviluppo mobile
RF-2 Lo stagista deve avvicinarsi alla progettazione e sviluppo di
applicativi in ambito enterprise nel settore retail
RF-3 Lo stagista deve apprendere le modalità di lavoro in un contesto
dinamicoCapitolo 4
Tecnologie e strumenti utilizzati
Di seguito viene data una panoramica delle tecnologie e degli strumenti utilizzati.
4.1 Versionamento
Amazon CodeCommit
È un servizio completamente gestito di controllo del codice sorgente che consente
l’hosting di repositories[g] sicuri basati su Git[g] . Semplifica la collaborazione tra i
team sul codice in un ambiente sicuro e altamente scalabile.
SourceTree
Graphical User Interface (GUI)[g] per software di versionamento, offre una rappre-
sentazione grafica delle repositories.
4.2 Linguaggi
Swift
Figura 4.1: Logo di Swift
Swift (dall’inglese "rondone" e "rapido, repentino") è un linguaggio di program-
mazione object-oriented per sistemi macOS, iOS, watchOS, tvOS e Linux, presentato
da Apple durante la WWDC 2014. Swift è concepito per coesistere con il linguaggio
1314 CAPITOLO 4. TECNOLOGIE E STRUMENTI UTILIZZATI
Objective-C, tipico degli sviluppi per i sistemi operativi Apple, semplificando la
scrittura del codice. Swift è stato progettato per essere più resiliente agli errori nel
codice. Utilizza il compilatore LLVM incluso in Xcode e il run time di Objective
C, permettendo l’uso di codice Objective C, Objective C++ e Swift in un singolo
programma.
Swift, già dalla prima release, è fino a 8.4 volte più veloce di Python e fino a 2.6
volte più veloce di Objective C in alcuni tipi di algoritmi.
Per quanto riguarda la mia esperienza, non ho avuto modo di utilizzarlo slegato dai
framework iOS che ne "costringono" un utilizzo conforme alle best practices[g] , ma
ho solo valutazioni positive sul linguaggio: è di facile apprensione, sintatticamente
elegante e potente.
JavaScript
Figura 4.2: Logo di JavaScript
JavaScript è un linguaggio di scripting orientato agli oggetti e agli eventi, comu-
nemente utilizzato nella programmazione Web lato client, recentemente esteso anche
al lato server, per la creazione, in siti web e applicazioni web, di effetti dinamici
interattivi tramite funzioni di script invocate da eventi innescati a loro volta in vari
modi dall’utente sulla pagina web in uso (mouse, tastiera, caricamento della pagina
ecc...).
Tali funzioni di script, utilizzati dunque nella logica di presentazione, possono
essere opportunamente inserite in file HTML, in pagine JSP o in appositi file separati
con estensione .js poi richiamati nella logica di business. Ultimamente il suo campo
di utilizzo è stato esteso alle cosiddette Hybrid App (app ibride), con le quali è
possibile creare app per più sistemi operativi utilizzando un unico codice sorgente
basato appunto su JavaScript, HTML e CSS.
Per quanto mi riguarda l’ho utilizzato completamente come strumento lato server,
cioè per quello che non era stato inizialmente progettato ma a cui è arrivato con
l’ausilio del runtime Node.js.
4.3 IDE[g] e editor
Xcode
Xcode è un ambiente di sviluppo integrato, completamente sviluppato e mantenuto
da Apple, contenente una suite di strumenti utili allo sviluppo di software per i
sistemi macOS, iOS, watchOS e tvOS.4.4. FRAMEWORK E LIBRERIE 15
Figura 4.3: Logo di Xcode
Precedentemente era fornito gratuitamente in bundle con il sistema operativo,
a partire da Mac OS X Panther, sebbene sia in grado di generare programmi per
qualsiasi versione di macOS. Di recente invece non è più in bundle con il sistema
operativo, ma è possibile scaricarlo gratuitamente dal Mac App Store. Estende e
rimpiazza il precedente tool di sviluppo della Apple, Project Builder, che era stato
ereditato dalla NeXT e lavora in congiunzione con Interface Builder (proveniente da
NeXT), un tool grafico per realizzare interfacce grafiche.
Da Xcode 4.2 Apple propone LLVM come compilatore di default e da Xcode 5.0 llvm
è l’unico compilatore presente nella suite.
L’ ho utilizzato per sviluppare l’ applicazione iOS, soggettivamente ho trovato un
curva di apprendimento bassa specie se paragonato a IDE più blasonati. Nonostante
l’hardware datato del computer di lavoro l’ esecuzione è sempre stata fluida .
Visual Studio Code
È un editor di codice sorgente sviluppato da Microsoft per Windows, Linux e
macOS. Esso include supporto per debugging, un controllo per Git integrato, Syntax
highlighting, IntelliSense, Snippet e refactoring del codice. È anche personalizzabile:
gli utenti possono cambiare il tema dell’editor, le scorciatoie da tastierafirstoccur le
preferenze. È un software libero, anche se la versione ufficiale è sotto una licenza
proprietaria.
L’ ho utilizzato per sviluppare le API, è l’unico strumento con cui avevo già familiarità
tra quelli utilizzati nel progetto di stage.
4.4 Framework e librerie
UIKit
È un framework sviluppato da Apple che fornisce le infrastrutture fondamentali per
le app iOS. Fornisce l’architettura MVC[g] per le interfacce, la gestione degli eventi, la
gestione degli input e il loop di esecuzione necessario a gestire interazioni tra utente,
sistema e applicazione. Altre caratteristiche offerte sono:
• supporto alle animazioni;
• supporto a disegno e stampa;16 CAPITOLO 4. TECNOLOGIE E STRUMENTI UTILIZZATI
• informazioni sul dispositivo;
• gestione del display e del testo;
• supporto per la ricerca testuale e vocale;
• supporto per l’accessibilità;
• gestione delle risorse.
Nello sviluppo di un’app è buona norma ereditare dai componenti forniti da questo
framework, specie UIView e UIViewController.
4.4.1 CocoaPods
Figura 4.4: Logo di CocoaPods
CocoaPods è un dependency manager, ovvero un modulo software che integra,
coordina e amministra librerie esterne in un’applicazione, le librerie utilizzate nel
progetto, chiamate in ambiente iOS Pods, sono le seguenti:
Alamofire: utilizzata per gestire il networking dell’app, è sviluppata a partire dalla
libreria Foundation di base di Apple;
ObjectMapper: fornisce strumenti e modelli per la traduzione modello-JSON e
JSON-modello.
Realm: database specifico per il campo mobile;
RxSwift: permette di utilizzare gli elementi della programmazione reactive[g] in
swift;
Snapkit: semplicizza il codice necessario per l’assegnazione dei vincoli di layout,
fortemente verboso nella sintassi pensata da Apple;
Node.js
È una runtime di JavaScript Open source multipiattaforma orientato agli eventi per
l’esecuzione di codice JavaScript, costruita sul motore V8 di Google Chrome. Molti
dei suoi moduli base sono scritti in JavaScript, gli sviluppatori possono scrivere nuovi
moduli.4.5. DATABASE E SERVIZI DI ARCHIVIAZIONE 17
Figura 4.5: Logo di Node
In origine JavaScript veniva utilizzato principalmente lato client. In questo scenario
gli script JavaScript, generalmente incorporati all’interno dell’HTML di una pagina
web, vengono interpretati da un motore di esecuzione incorporato direttamente
all’interno di un browser. Node.js consente invece di utilizzare JavaScript anche per
scrivere codice da eseguire lato server, ad esempio per la produzione del contenuto
delle pagine web dinamiche prima che la pagina venga inviata al browser dell’utente.
Node.js in questo modo permette di implementare il cosiddetto paradigma "JavaScript
everywhere" (JavaScript ovunque), unificando lo sviluppo di applicazioni web intorno
ad un unico linguaggio di programmazione (JavaScript).
Node.js ha un’architettura orientata agli eventi che rende possibile l’I/O asincrono.
Questo design punta ad ottimizzare il throughput e la scalabilità nelle applicazioni
web con molte operazioni di input/output, è inoltre ottimo per applicazioni web
real-time (ad esempio programmi di comunicazione in tempo reale o browser game).
Express web framework
Express è un framework di tipo unopinionated[g] , scritto in Javascript ed eseguito in
un ambiente di runtime Node.js. Fornisce meccanismi per:
• Scrivere gestori per le richieste con i differenti verbi HTTP[g] a diversi URL[g] ;
• Impostare le porte di connessione e la locazione dei template per interpretare
la risposta;
• Aggiungere processi middleware in qualsiasi punto della catena di richieste.
Sono proprio questi middleware che hanno permesso al minimalismo di base di
Express di fornire soluzioni a praticamente ogni problema comune nell’ambito
dello sviluppo web.
4.4.2 Mongoose
È una libreria per MongoDB e Node.js, fa da driver per il database sottostante:
gestisce le relazioni tra i dati, fornisce strumenti di validazione degli schemi, traduce
tra la rappresentazione degli oggetti nel codice con la forma rappresentata dentro il
database.18 CAPITOLO 4. TECNOLOGIE E STRUMENTI UTILIZZATI
Figura 4.6: Logo di MongoDB
4.5 Database e servizi di archiviazione
4.5.1 MongoDB
MongoDB (da "humongous", enorme) è un DBMS non relazionale, orientato ai
documenti. Classificato come un database di tipo NoSQL, MongoDB si allontana
dalla struttura tradizionale basata su tabelle dei database relazionali in favore di
documenti in stile JSON con schema dinamico (MongoDB chiama il formato BSON),
rendendo l’integrazione di dati di alcuni tipi di applicazioni più facile e veloce.
4.5.2 Amazon S3
Figura 4.7: Logo di Amazon S3
Amazon S3 (Simple Storage Service, in italiano: Servizio di archiviazione semplice)
è un servizio web di memorizzazione offerto da Amazon Web Services.
4.6 Testing
4.6.1 Postman
Figura 4.8: Logo di Postman
È una piattaforma condivisa per lo sviluppo e il test di API, permette di inviare
richieste e visualizzarne il risultato, automatizzare i test, simulare i comportamenti
di un server, generare documentazione e monitorare lo stato delle API.4.6. TESTING 19 4.6.2 Simulatore iPhone Permette di testare applicazioni come se fossero eseguite su un vero dispositivo durante lo sviluppo. È uno strumento fornito con Xcode, ma si può utilizzare anche separatamente, sono forniti simulatori per iPhone, iPad, Apple Watch, Apple TV. Simulando l’esecuzione di un’app nel simulatore è possibile: • trovare problemi importanti in fase di progettazione e codifica iniziale; • utilizzare strumenti di sviluppo non presenti nei dispositivi fisici;
Capitolo 5
Panoramica su iOS
5.1 Architettura iOS
Il sistema operativo iOS è organizzato come una pila di componenti software Unix-
like[g] e deriva direttamente dal sistema operativo per computer OS X, il sistema
operativo non aveva un nome ufficiale fino all’uscita della prima beta dell’iPhone
SDK il 6 marzo 2008; prima di allora, il marketing Apple affermava che "iPhone usa
OS X". L’architettura può essere divisa in 4 componenti principali:
Kernel e Device Drivers Rappresenta il livello più basso e vicino all’hardware, il
kernel ibrido, denominato XNU è derivato (con pesanti modifiche) dal kernel
OSFMK;
Core OS Rappresenta lo strato in cui sono esposte le tecnologie e i framework che
Figura 5.1: Architettura del sistema operativo iOS
2122 CAPITOLO 5. PANORAMICA SU IOS
offrono servizi di basso livello relativi all’hardware e al networking;
Core Services Strato che provvede ai servizi essenziali per le applicazioni che però
non hanno influenza diretta sull’interfaccia grafica;
Media Strato che permette l’incorporamento di grafica 2D e 3D, animazioni, effetti,
audio e funzionalità video nelle applicazioni;
Cocoa Touch Strato responsabile dell’interfacciamento utente con le applicazio-
ni, fornisce accesso a input tattili, contatti, videocamera, notifiche push e
condivisione di dati.
5.2 Modalità sandbox
Un applicazione iOS (e più in generale le applicazioni mobile) operano in modalità
sandbox: l’idea si basa su un principio semplice, che riguarda la sicurezza delle app:
semplicemente, quelle non attendibili devono essere eseguite in un compartimento
isolato, come se l’esecuzione fosse spostata in un ambiente di “quarantena” nel quale
tutte le operazioni sono soggette a restrizioni. Precedentemente, in macOS Leopard
questa tecnica veniva chiamata seatbelt, rinominata ai giorni nostri a sandbox. Le
restrizioni di questa modalità sono essenzialmente:
• Impossibilità di uscire dalla directory dell’app. L’app vede effettivamente la
propria directory (/var/mobile/Applications/) come root;
• Impossibilità di accedere a qualsiasi altro processo sul sistema;
• Impossibilità di utilizzare direttamente qualsiasi dispositivo hardware esterno
senza passare attraverso i framework di Apple;
• Impossibilità di generare dinamicamente del codice;
• Impossibilità di eseguire qualsiasi operazione, tranne di un insieme: quelle
consentite per l’utente mobile;
• L’accesso e la creazione di file da parte di un’applicazione è possibile solo
passando per le interfacce di sistema pubbliche di iOS.
Vi sono 3 contenitori (containers) nella directory sandbox di un’applicazione:
Bundle container: Contiene tutti i file dell’applicazione appena installata: l’e-
seguibile, gli asset, i metadati, il manifest[g] , file di configurazione, file di
localizzazione etc.;
Data container: Contiene i file che gli sviluppatori ritengono necessario siano
salvati durante il tempo di permanenza dell’applicazione sul dispositivo. Questi
possono comprendere informazioni di cache e informazioni offline di backup. I
file salvati in questa directory sono dinamici: cambiano mentre l’applicazione è
in uso;
icloud Container: Contiene informazioni utilizzate da applicazioni in cui è abilitato
l’accesso ad iCloud[g] .5.3. ARCHITETTURA MODEL VIEW CONTROLLER 23
Figura 5.2: Un’applicazione iOS operante nella sua directory in modalità sandbox
5.3 Architettura Model View Controller
È uno dei pattern forzati by-design nello sviluppo in ambiente iOS, anche se è
possibile utilizzare varianti. Per il progetto si è utilizzato l’architettura MVC come
da linee guida iOS:
Model Qui è inserita la business logic[g] , in particolare è buona norma inserirvi:
• codice di networking;
• codice persistente;
• codice di parsing;
• costanti;
• estensioni.
View È responsabile della visualizzazione e dell’aspetto grafico, in termine di codice
è opportuno confinarvi qui i seguenti elementi:
• viste e layout;
• classi del framework UIKit/AppKit;
• animazioni e grafiche core.
Controller Strato di minor riusabilità dell’architettura visto che include la maggior
parte del codice specifico del dominio dell’attuale applicazione, le classi in
questo strato hanno responsabilità di decidere:
• a cosa accedere prima, se ai dati persistenti o provenienti da network;
• con che frequenza effettuare il refresh delll’applicazione;
• la schermata successiva e sotto che circostanze;24 CAPITOLO 5. PANORAMICA SU IOS
• procedure nel caso in cui l’app vada in background ;
• cosa fare dopo l’input tattile dell’utente.Capitolo 6
Sviluppo Applicazione iOS
6.1 Inizio del progetto
Le scelte progettuali iniziali sono state prese durante un meeting svoltosi il 16
settembre, durante questo incontro, a cui hanno partecipato tutte le figure aziendali
coinvolte nel progetto, si è discusso del back-end amministrativo, già in sviluppo da
un mese e si è poi discusso dell’applicazione iOS, questa non ancora nata. Durante
questa discussione si è diviso e assegnato il lavoro, inoltre sono state definite le norme
per l’applicazione:
• l’organizzazione delle cartelle del progetto, nome delle directory e loro percorso;
• regole di sintassi;
• framework comuni;
• canali di comunicazione esclusivi per il team.
6.2 Organizzazione cartelle
I file nella radice della directory e i file principali in cui sono raggruppati i componenti
dell’applicazione servono anche a descriverne la configurazione, sono qui elencati e
brevemente descritti:
AppDelegate.swift : cuore e punto di avvio dell’app, come da nome è un delegate:
viene notificato quando gli oggetti connessi raggiungono un certo stato o evento.
Info.plist : contiene i metadati per l’applicazione sotto forma di coppie di chiave-
valore.
Localizable.strings : contiene il dizionario per la localizzazione dei dati persistenti
dell’applicazione.
Resources : contiene:
• le classi per le richieste HTTP;
• i modelli per la traduzione JSON-oggetto swift;
2526 CAPITOLO 6. SVILUPPO APPLICAZIONE IOS
• i font;
• i modelli per il database mobile Realm;
• costanti.
Sources : contiene:
• i layout per le celle di TableView e CollectionView;
• viste riutilizzate;
• i ViewController.
6.3 Codifica programmatica dell’interfaccia grafica
Per definire layout e viste delle schermate di un’applicazione iOS esistono due modi:
Storyboard È una rappresentazione grafica dell’interfaccia, mostra i contenuti,
le schermate e le connessioni tra queste, una storyboard è composta da una
sequenza di scene, ognuna di queste rappresenta un view controller e le sue viste,
le scene sono connesse da oggetti denominati segue objects, questi rappresentano
la transizione tra due view controller.
La storyboard (introdotta con iOS 5 e Xcode 4.2) rappresenta quindi una modo
di disegnare interfacce grafiche molto user-friendly, permette di implementare
viste e vincoli di layout in modo molto veloce, visualizzando le schermate
in modo molto simile a quello che si vedrà una volta eseguita effettivamente
l’applicazione.
Programmaticamente In questa modalità ogni elemento della schermata viene
definito via codice, questo porta i seguenti vantaggi:
• Merge puliti: lavorando con le storyboard in un ambiente di lavoro
condiviso si ha un’altissima incidenza di conflitti di merge, data la natura
stessa delle soryboard. Definendo l’interfaccia programmaticamente si
evitano completamente questi conflitti;
• Riusabilità: al contrario delle storyboard, il codice utilizzato per definire
una schermata può essere riutilizzato (ed esteso);
• Facilità di navigazione: troppi elementi in una schermata, anche se rap-
presentati graficamente dalla storyboard, diventano difficili da discernere
ed è difficile individuarne i confini;
• Facilità di connessione vista-comportamento: con le storyboard
questa connessione viene effettuata tramite identificatori: ogni vista ha un
identificatore e questo deve essere riportato per definirne il comportamento
via codice. Questa procedura, in aggiunta alla necessità di mantenere
l’associazione vista-identificatore consistente, rende l’implementazione
programmatica dell’interfaccia un procedimento meno tedioso.
Per il progetto si è quindi deciso per la modalità programmatica che, a rigor di logica,
rappresenta anche una best practice. È evidente che l’uso delle storyboard è stato
pensato per progetti di taglia piccola e in cui non è necessario l’utilizzo di interfacce
fortemente personalizzate.6.4. SCHERMATE 27
6.4 Schermate
Nelle figure delle schermate sono stati rimossi riferimenti, loghi ed immagini che possano
rivelare l’identità dei clienti.
Figura 6.1: Tab bar dell’applicazione
Tranne che nella fase di autenticazione la navigazione dell’applicazione, nelle sue
componenti macroscopiche, è affidata ad una tab bar. Questa è visualizzata nella
parte inferiore dello schermo e presenta 5 icone, le sezioni che rappresentano da
sinistra a destra sono rispettivamente:
Homepage Si tratta della schermata principale dell’applicazione dove sono riportate,
in sequenza temporale dal più recente al meno recente, le notizie proposte per
l’utente. In homepage sono presente le preview delle notizie e, per ognuna di
queste sarà possibile, visualizzare il numero di like, il tempo di lettura richieste
il numero di commenti lasciati dagli altri colleghi.
Training module La sezione di training è caratterizzata da un elenco di banner che
rappresentano i training in evidenza ed una sequenza di moduli di formazione.
Ogni modulo rappresenta una cartella che contiene uno o più corsi di formazione
inerenti all’argomento del modulo.
Game la sezione game ha lo scopo di avere una competizione aperta tra client
advisor e store manager per periodi di tempo prestabiliti. In questa sezione
il personale HQ proporrà periodicamente delle sfide che gli utenti dovranno
svolgere per guadagnare punti in classifica.
Store experience Sezione dell’app mediante la quale l’utente, compilando un sem-
plice form, potrà inviare delle opinioni, necessità o qualsiasi altra cosa all’HQ.
Allo stesso tempo sarà possibile ricercare i prodotti e lasciare un feedback
rispondendo, sempre in modo anonimo, a piccole domande. All’interno di
questa sezione il client advisor potrà consultare la sintesi dei morning brief
scritta dallo store manager.
Profilo utente Si tratta della sezione dell’applicazione dove l’utente può perso-
nalizzare il proprio avatar, consultare il suo livello di competenze sulla base
delle esperienze acquisite. Sempre all’interno del proprio profilo l’utente potrà
trovare i recommendation block per monitorare il proprio stato di studio.
6.4.1 Scelta della modalità di autenticazione
Dopo una splash page riportante il logo del cliente questa è la prima pagina che viene
visualizzata (in futuro si implementerà un wizard iniziale), da qui si può scegliere se
autenticarsi tramite certificato o tramite nome utente e password.28 CAPITOLO 6. SVILUPPO APPLICAZIONE IOS
Figura 6.2: Schermata di scelta login
6.4.2 Login tramite certificato
Premendo sul bottone riportante: "Enter with certificate", il sistema apre il browser
del telefono indirizzandolo ad una pagina di autenticazione tramite certificato, questo
sistema (esterno all’applicazione) controllerà se il dispositivo dispone del certificato
SSL[g] necessario e in caso di successo restituirà il controllo all’applicazione passandole
i parametri necessari.
6.4.3 Login standard
Figura 6.3: Schermata del login standard6.4. SCHERMATE 29
Il login standard è necessario sopratutto per utenti esterni al cliente, quali anche gli
sviluppatori del team, sprovvisti di certificati. Premendo sull’etichetta sottolineata:
"Enter with another account" si viene portati ad una schermata di login classica, con
input per nome utente e password. Oltre a definire struttura e comportamento delle
viste che compongono la schermata ho implementato la validazione delle stringhe,
la gestione degli errori e il collegamento alle API. L’autenticazione in questo caso è
gestita dal back-end sviluppato dal team.
6.4.4 Sezione store experience
Figura 6.4: Schermata della sezione Store experience
La sezione è composta da due sottoschermate incastrate in due cards, queste
sono celle fortemente customizzate che ereditano da UICollectionViewCell, lo
scorrimento è verticale e i titoli superiori delle due sezioni non escono mai dalla
schermata.
6.4.5 Daily morning brief
In questa card si visualizzano i morning briefs scritti dagli store manager, l’utente
visualizza il contenuto testuale, navigabile verticalmente, nome e avatar dell’autore.
Il calendario posizionato sotto il titolo della sezione è scorribile orizzontalmente, ogni
pagina mostra una settimana, da domenica a domenica, partendo dalla settimana
corrente a ritroso, premendo su una data si aggiorna la sezione mostrando il contenuto
per tale data. È un componente custom, ha rappresentato per me il primo vero
scoglio durante il periodo di stage: non esistono viste dirette da cui ereditarlo e
anche online non ho trovato componenti simili su cui basarlo; l’ ho quindi progettato
e codificato ereditando da UIView e UIViewController che sono gli oggetti base
rispettivamente di viste e controller e UIPageViewController che è il componente
base per la navigazione paginata.30 CAPITOLO 6. SVILUPPO APPLICAZIONE IOS
Figura 6.5: Diagramma delle classi per il calendario nella schermata Daily morning brief
6.4.6 Let’s Talk
Figura 6.6: Schermata della card Let’s Talk
Questa sezione è rappresentata nella card sottostante alla sezione morning brief,
presenta i pulsanti PRODUCT’S FEEDBACK e CONTACT US che rimanderanno
rispettivamente alle sezioni di feedback prodotti e feedback utente. Oltre ai bottoni
sono presenti dei testi che informano dell’anonimità dei dati inviati.
6.4.7 Feedback utente
La schermata presenta un form in cui sono presenti i seguenti campi:
Oggetto del messaggio Come per le mail, un titolo per il contenuto del feedback
che si vuole inviare;6.4. SCHERMATE 31
Figura 6.7: Schermata di feedback utente
Categoria Premendo sull’area di input si aprirà in basso una lista orizzontale
scorrevole con le categorie (caricate da back-end)
Corpo del testo Spazio adibito alla digitazione della parte testuale del feedback;
Bottone inserimento immagine Premendolo è possibile caricare una foto scat-
tandola con la fotocamera del dispositivo o caricandola dalla galleria, è possibile
rimuovere successivamente la foto premendo sull’apposito pulsante;
Bottone di invio Premendolo verrà prima validato il form e poi in caso di successo
si verrà riportati alla sezione Let’s Talk, in sovraimpressione su questa verrà
mostrata un’animazione e la conferma di invio.
6.4.8 Lista prodotti
In questa schermata è visualizzata una lista dei prodotti (caricata da back-end), decisi
dall’HQ, di cui si vuole dare un feedback, in ogni cella sono visualizzati
• immagine;
• nome;
• codice identificativo.
La lista è scrollabile verticalmente, è stato un componente facile da implementare,
eredita da un UITableViewCellController che carica il layout che ho definito per
le celle e ne gestisce caricamento e riutilizzo. Premendo su una cella si accede alla
schermata di feedback prodotto corrispondente, completato il modulo di feedback si
ritorna in automatico a questa lista e si visualizza un’animazione che mostra la cella
che scompare verso destra.32 CAPITOLO 6. SVILUPPO APPLICAZIONE IOS
Figura 6.8: Schermata della lista prodotti
Figura 6.9: Schermata del feedback prodotto
6.4.9 Feedback prodotto
In questa schermata è possibile dare un feedback sul prodotto rispondendo ad alcune
domande, data l’eterogeneità dei prodotti e, di conseguenza, delle informazioni che si
vogliono raccogliere, il numero di domande e le domande stesse sono dinamiche, mi è
stato chiesto di implementare una tipologia a slider ed una a campo testuale.
6.5 Gestione richieste
Per la gestione delle richieste si fatto largo uso della libreria: AlamoFire , questa
mi ha permesso di implementare la classe RequestManager in modo che gestisse6.5. GESTIONE RICHIESTE 33
ogni tipologia di richiesta con il minimo riutilizzo di codice ed un alto livello di
disaccoppiamento. La classe è una singleton, tutti gli elementi che ne necessitano
invocano la stessa istanza, le sue responsabilità sono:
• memorizzare gli endpoint;
• memorizzare la coda di richieste;
• aggiungere e rimuovere richieste dalla coda;
• aggiornare gli header della richiesta;
• eseguire le richieste;
• gestire le callback.
Ogni richiesta eredita dalla classe astratta Request. Questa memorizza gli attributi
della richiesta (URL, verbo HTTP, parametri interni, immagini etc.) ed espone due
metodi virtuali, processSuccess e processFailure, che verrano implementati dalle
classi effettive. Questo è un esempio del metodo processSuccess implementato
nella classe GetCategories, che serve ad ottenere le categorie nella sezione feedback
utente:
override func processSuccess(response: AFDataResponse) {
if let json = response.value as? [String: Any] {
let contactUsCategoryListModel =
Mapper()
.map(JSON: json)
completion?(contactUsCategoryListModel, nil)
} else {
completion?(nil, nil)
}
}
La risposta ottenuta dal server viene mappata attraverso i modelli definiti con la
libreria ObjectMapper, in questo caso: ContactUsCategoryListModel, il modello
viene passato alla closure completion, le closure si comportano in modo simile ai
costrutti definiti come Lambda in Java, è di fatto una funzione senza nome, che
è possibile assegnare ad una variabile o ad una costante, passare come parametro
o restituire come se fosse un valore. In questo caso viene utilizzata per definire il
comportamento da avere con i dati restituiti dalla richiesta nel viewController in
cui viene fatta.Puoi anche leggere
