La struttura: Storyboard

Uno storybord è una rappresentazione visuale dell’interfaccia utente di un’ap- plicazione iOS. Esso è composto da una sequenza di scene, ciascuna delle quali rappresenta un UIViewController e le sue viste. Le transizioni tra le varie scene sono rappresentate con una segue.

Xcode fornisce un editor visuale per gestire gli storyboard e permette di definire il layout e il design della user interface semplicemente aggiungendo viste, botto- ni, tabelle e testo. Benché nato per un approccio di tipo visuale, lo storyboard può essere acceduto e modificato anche tramite codice . Si mostrerà la struttura dell’applicazione attraverso l’analisi dello storyboard.

CAPITOLO 4. IL CLIENT

La schermata iniziale è costituita da un semplice form per gestire il login del- l’utente accompagnatore. E’ anche disponibile una funzione per registrarsi. Una volta effettuato il login si entra nel core dell’applicazione, costituito da un Tab Bar View Controller: esso implementa un particolare tipo di view controller che gestisce un’interfaccia costituita da una serie di etichette, o tab, racchiuse in una Tab Bar in fondo allo schermo. A ciascuna etichetta è collegata una partico- lare vista che apparirà sullo schermo in base alla selezione dell’utente. E’ anche possibile associare un view controller annidato all’interno del UITabBarController per permettere all’utente di orientarsi meglio tra le viste. Nello specifico, nel- l’applicazione proposta sono presenti tre tabs: una per raccogliere le informazioni dell’utente, una per convalidare il contrassegno e infine una per richiederlo. Que- st’ultima contiene un UINavigationController, il quale si occupa di creare uno stack di navigazione delle viste, ovvero un array di view controller, e di navi- garle tramite segue normalmente associate ad un pulsante di back all’interno di un’apposita Navigation Bar. Una volta terminata la progettazione della user in- terface si procede all’implementazione delle classi che compongono l’applicazione. Generalmente, per sviluppare applicazioni iOS si utilizzano i linguaggi Swift e Objective-C. Quest’ultimo è il primo linguaggio di programmazione object-oriented usato per scrivere software per le piattaforme OSX e iOS. Esso eredita la sintassi e i tipi primitivi del C e aggiunge dichiarazioni per definire classi e metodi. Per fare un esempio, ogni view controller mostrato nello storyboard è implementato programmaticamente attraverso una sottoclasse di UIViewController. In seguito si analizzeranno nel dettaglio le classi di oggetti che sono maggiormente coinvolte nel progetto.

4.2.2

NsURLSession

Una classe utilizzata massicciamente all’interno dell’applicazione è sicuramente NSURLSession. Infatti essa permette di stabilire una connessione con il server e di inviare dati e richieste. La classe NSURLSession supporta nativamente la trasmissione di dati edi file e i protocolli FTP, HTTP e HTTPS. É possibile anche stabilire un protocollo di comunicazione personalizzato. In un’applicazione posso- no essere presenti una o più sessioni, ciascuna delle quali si occupa di una precisa

CAPITOLO 4. IL CLIENT

trasmissione dati, che prende il nome di task. Esistono tre tipi di task :

• Data Task il quale invia e riceve oggetti di classe NSData. Utilizzato speci- ficamente per piccole richieste al server quali il login, logout e registrazione dell’utente, ma anche per la richiesta di creazione di un pass;

• Upload Task simili ai Data Task, ma inviano dati e file, e supportano l’upload in background quando l’applicazione non è attiva. Questo task viene utiliz- zato per inviare al server il video da analizzare;

• Download Taks scarica dati e file. Anch’essa supporta il download in back- ground.

Ogni task è legato ad una NSURLSession e condivide con essa la sua configu- razione, la quale definisce il comportamento della connessione:

• Singleton shared session è per le richieste molto semplici. Non è personaliz- zabile e si usa normalmente quando non sono richiesti particolari requisiti; • Default session si comporta analogamente alla shared session, ma è perso-

nalizzabile e riceve i dati gradualmente tramite un delegate;

• Ephimeral session sono simili alle default session, ma non memorizzano caches, cookies o credenziali di autenticazioni sul disco;

• Background session permettono di svolgere l’upload e il download dei conte- nuti anche quando l’applicazione non è in stato di running.

Esempio di utilizzo di NSURLSession.  2 N S U R L S e s s i o n * s e s s i o n = [ N S U R L S e s s i o n s h a r e d S e s s i o n ]; N S U R L S e s s i o n D a t a T a s k * task =[ s e s s i o n 4 d a t a T a s k W i t h R e q u e s t : r e q u e s t c o m p l e t i o n H a n d l e r : ^( N S D a t a * data , 6 N S U R L R e s p o n s e * response , N S E r r o r * e r r o r ) { 8

CAPITOLO 4. IL CLIENT N S S t r i n g * r e s p o n s e S t r i n g W i t h E n c o d e d = [ 10 [ N S S t r i n g a l l o c ] i n i t W i t h D a t a : data e n c o d i n g : N S U T F 8 S t r i n g E n c o d i n g ]; 12 N S D i c t i o n a r y * r e s u l t = 14 [ N S J S O N S e r i a l i z a t i o n J S O N O b j e c t W i t h D a t a : data o p t i o n s : N S J S O N R e a d i n g M u t a b l e C o n t a i n e r s e r r o r :& e r r o r ]; 16 // Save m y P a s s in U s e r D e f a u l t s 18 N S L o g ( @ " User ␣ D e f a u l t s ␣ : ␣ % @ " , r e s u l t ); N S U s e r D e f a u l t s * m y A c t u a l P a s s = 20 [ N S U s e r D e f a u l t s s t a n d a r d U s e r D e f a u l t s ]; [ m y A c t u a l P a s s s e t O b j e c t : r e s u l t f o r K e y : @ " m y A c t u a l P a s s " ]; 22 [ m y A c t u a l P a s s s y n c h r o n i z e ]; } ]; 24 [ task r e s u m e ]; }  

4.2.3

AVFoundation

AvFoundation è uno degli innumerevoli framework che possono essere usati per riprodurre e creare audio, foto e video tramite un’interfaccia scritta in Objective- C. In questo progetto è stata utilizzata per registrare gli input della videocamera e del microfono dello smartphone. Tutte queste operazioni vengono gestite da una AVCaptureSession, la quale ha il compito di coordinare il flusso dei dati dai dispositivi input al file di output. Tutto quello di cui si ha bisogno è :

• un’istanza di AVCaptureDevice la quale rappresenta il dispositivo fisico volto a catturare l’immagine, e contiene tutte le proprietà di esso. Esiste un oggetto particolare per ogni tipo di dispositivo: uno per gestire l’input del mi- crofono e due per gestire la fotocamera frontale e quella sul retro. Si usa per configurare le proprietà dell’hardware e fornisce i dati alla AVCaptureSession; • un’istanza di AVCaptureInput , ovvero un oggetto che gestisce il flusso di

CAPITOLO 4. IL CLIENT

• un’istanza di AVCaptureOutput che serve per gestire l’output e convertirlo in un’immagine, in un video oppure un file audio.

Figura 4.2: Struttura di una AVCaptureSession

Quando si aggiunge un input o un output ad una AVCaptureSession, si crea una connessione tra tutte le porte input compatibili a registrare dati e gli output registrati. Questa connessione è rappresentata da un AVCaptureConnection. Per registrare un video è necessario utilizzare un delegate conforme al protocol- lo AVCaptureFileOutputRecordingDelegate. Bisogna quindi implementare due metodi :

• startRecordingToOutputFileURL:recordingDelegate è il metodo che in- dica l’inizio della registrazione. I parametri dati in input sono rispettiva- mente il path del video da salvare e l’oggetto da usare come delegate. Nel- l’applicazione proposta questo metodo è invocato all’interno della funzione (IBAction)takePhoto:(id)sender in quanto per rendere l’interfaccia user friendly si è rivelato necessario collegare l’azione di registrare un video ad un bottone da premere per iniziare e fermare la registrazione;

CAPITOLO 4. IL CLIENT

• captureOutput: didFinishRecordingToOutputFileAtURL: fromConnections: error: è il metodo che indica le azioni da svolgere una volta terminata la

registrazione del video. In input riceve il file che è stato appena scritto e il suo path, un array con tutte le AVCaptureConnection legate al video ed in- fine una variabile indicante eventuali errori. Appurato che non vi siano stati errori il video viene convertito in un flusso dati e inviato al server tramite una NSURLSession.

Capitolo 5

Possibili sviluppi futuri

Nei precedenti capitoli è stato esposto un possibile sistema per contrastare l’uso improprio del contrassegno per disabili. Tuttavia, la soluzione proposta deve essere considerata una base di partenza per la realizzazione di un software che garantisca sicurezza sia dal punto della protezione dei dati sensibili degli utenti, sia dal punto di vista della creazione di una challenge difficile da aggirare. Ecco quindi riportate in seguito una serie di idee che sono ritenute necessarie affinché il sistema effettivamente sostituirsi all’attuale pass cartaceo.

Innanzitutto si ritiene necessario il completamento della piattaforma per l’in- serimento dei soggetti svantaggiati nel database del Comune. In particolare, bi- sognerà implementare un’interfaccia user friendly che permetta rapidamente agli impiegati del Comune di Bologna di registrare volti e voci. Per aumentare la sicurezza del sistema, questa piattaforma dovrà essere accessibile ai dipendenti esclusivamente tramite i computer degli uffici del Comune e solamente durante il proprio turno di lavoro. Queste limitazioni hanno lo scopo di cercare di evitare che un impiegato comunale possa connettersi tramite il proprio pc di casa e alterare i database corrompendo l’integrità del riconoscimento facciale e vocale.

Dopodiché risulta doveroso sviluppare la componente del client anche per si- stemi operativi Android e Windows Phone, in modo da coprire la quasi totalità dei dispositivi mobili presenti in circolazione. Infatti, affinché il sistema possa effettivamente sostituire il contrassegno cartaceo,è necessario che tutti i citta- dini con disabilità siano in grado di poter usufruire del servizio informatizzato,

CAPITOLO 5. POSSIBILI SVILUPPI FUTURI

indipendentemente dal modello di smartphone posseduto.

Un altro punto nodale che andrebbe approfondito è la gestione delle challen- ge. In particolare si ritiene che un solo test potrebbe non essere sufficiente per garantire l’effettiva presenza del disabile a bordo, in quanto l’accompagnatore po- trebbe semplicemente effettuare il test prima di intraprendere il viaggio verso il centro. Per ovviare a questo si ritene necessario permettere all’applicazione mobile di generare richieste in background al server, in modo tale da ricevere una nuova challenge ogni t istante di tempo casuale compreso nelle ore di validità del pass. Il rischio di questa soluzione è che essendo t generato casualmente dal sistema, potrebbero essere generate n challenge, una per ogni minuto in cui il pass risulta attivo nel sistema. É evidente che questo approccio creerebbe un disagio sia nei confronti di una persona disabile, la quale verrebbe costantemente stressata dai continui test richiesti, sia nei confronti dell’accompagnatore il quale si ritrovereb- be costretto ad accostare continuamente l’automobile per effettuare il test. Per superare questo scoglio, si propone di permettere all’applicazione di tracciare il percorso che il disabile dovrà attraversare per raggiungere il luogo di interesse: in questo modo risulterebbe possibile stimare il tempo di percorrenza del viaggio e permettere all’accompagnatore di posticipare l’esecuzione del test al momento in cui sarà giunto a destinazione. Questo meccanismo tornerebbe utile anche nella situazione in cui sia necessario richiedere un pass per andare a prelevare un sogget- to affetto da disabilità che si trova già in centro urbano, permettendo all’utente di prenotare posticipare la verifica della prova a quando il disabile sarà effettivamente a bordo del veicolo.

Capitolo 6

Bibliografia

Articoli

Classsifying Facial Action di Paul Ekman, Joseph C.Hager,Marian Stewart Bartlett, Paul A. Viola, Terrence J. Sejnowski, Beatrice A. Golomb, Jan Larsen, Advances in Neural Information Processing Systems 8,823-829, 1996 A Practical Guide to Biometric Security Technology , di Simon Liu and

Mark Silverman,IT Pro, IEEE, January-February 2001

State-of-the-Art in Speaker Recognition , di Enric Monte-Moreno , Marcos Faundez-Zanuy, May 2005, IEEE A&E SYSTEMS MAGAZINE

Eigenface-based facial recognition di Dimitri PISSARENKO„ December 1, 2002

EIGENFACES AND FISHERFACES , di Naotoshi Seo, University of Ma- ryland ENEE633 Pattern Recognition Project 2-1

A Study of Various Face Detection Methods , di Ms. Varsha Gupta, Mr. Dipesh Sharma, International Journal of Advanced Research in Computer and Communication Engineering , May 2014, Vol. 3, Issue 5

Facial expression recognition from video sequences: temporal and static modeling di Ira Cohen„ Nicu Sebe, Ashutosh Garg, Lawrence S. Chen, and Thomas

CAPITOLO 6. BIBLIOGRAFIA

Vision Based Hand Gesture Recognition di Pragati Garg, Naveen Aggarwal and Sanjeev Sofat, , World Academy of Science, Engineering and Technology 49, 2009

Eigenfaces for recognition di Matthew Turk and Alex Pentland, Journal of Cognitive Neuroscience, , Number 1, Volume3, 1991

Voice Biometrics di Judith A. Markowitz, COMMUNICATIONS OF THE

ACM, No.9, Vol.43, September 2000 Sitografia

www.ilfattoquotidiano.it/2011/04/20/ di Gerardo Adinolfi, Auto dei calcia- tori col pass invalidi. Di Vaio ai pm: "Ci sono cose più importanti”, 20 aprile 2011

www.ilfattoquotidiano.it/2011/08/27/ Antonella Beccaria, Scandalo pass in- validi dei calciatori. La Procura indaga sulle responsabilità di Atc, 27 agosto 2011

www.poliziamunicipale.comune.verona.it/nqcontent.cfm?a_id=32481 , si- to della polizia municipale di Verona

http://docs.opencv.org/ Documentazione OpenCV

http://www.aci.it/i-servizi/per-la-mobilita/aci-per-il-sociale/ sito dell’A- CI