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
Corso di Laurea in Informatica
App mobile con framework basati su
tecnologie HTML5 e JavaScript
Tesi di laurea triennale
Relatore
Prof. Massimo Marchiori
Laureando
Alberto Nessi
Anno Accademico 2015-2016
Alberto Nessi: App mobile con framework basati su tecnologie HTML5 e JavaScript, Tesi di laurea triennale, c Ott 2015.
"Una volta un tale che doveva fare una ricerca andava in biblioteca, trovava dieci titoli
sull’argomento e li leggeva; oggi schiaccia un bottone del suo computer, riceve una
bibliografia di diecimila titoli, e rinuncia."
— Umberto Eco
Dedicato ai miei genitori.
Sommario
Il presente documento descrive il lavoro svolto durante il periodo di stage, della durata
di 320 ore, dal laureando Alberto Nessi presso l’azienda InfoCert S.p.A..
L’obiettivo principale dello stage era quello di compiere uno studio sulle tecnologie
esistenti nell’ambito delle web app approfondendo Phonegap/Cordova, Appcelerator
Titanium ed eventuali altri framework.
In secondo luogo, è stato fatto un approfondimento su alcuni framework UI per
lo sviluppo di interfacce utente per applicazioni mobili.
In seguito è stato realizzato un prototipo del core di un’applicazione utilizzando
il framework scelto.
v
Ringraziamenti
Innanzitutto, vorrei esprimere la mia gratitudine al prof. Massimo Marchiori, relatore
della mia tesi, per l’aiuto e il sostegno fornitomi durante la stesura del lavoro.
Desidero ringraziare con affetto i miei genitori per avermi sostenuto, fatto capire
l’importanza dello studio e l’importanza di pensare con la propria testa.
Ho desiderio di ringraziare poi i miei amici di sempre Umberto e Stefano per aver
sopportato tutte le mie lamentele quando gli esami non andavano come speravo e per
esserci sempre stati.
Un ringraziamento va anche a tutti i miei amici, conoscenti e parenti che al primo
problema con la tecnologia mi chiamano dicendo: "Tu fai informatica e quindi sai
come si risolve!".
Da ultimo, un ringraziamento particolare ad Oliviero Trivellato per l’opportunità di
svolgere lo stage presso l’azienda InfoCert S.p.A. e ad Enrico Francescato e colleghi
per l’accoglienza che mi hanno riservato; grazie a loro ho vissuto un’esperienza che
mi ha gratificato non solo dal punto di vista professionale, ma anche dal lato umano.
Ho avuto la fortuna di lavorare fianco a fianco con persone molto preparate ma anche
molto entusiaste ed appassionate del loro lavoro.
Padova, Ott 2015 Alberto Nessi
vii
Indice
1 Introduzione 1
1.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Dati aziendali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Storia ed attività aziendali . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Prodotti e servizi forniti . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5.1 DiKe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5.2 LegalMail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5.3 Business Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5.4 Legal Invoice . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5.5 SecureDrive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.6 Certificati SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.7 LegalDoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Organizzazione del testo . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Progetto 7
2.1 Integrazione del progetto in azienda . . . . . . . . . . . . . . . . . . . 7
2.2 Obiettivi dello stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Motivazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Vincoli del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1 Vincoli tecnologici . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.2 Vincoli temporali . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Descrizione dello stage 15
3.1 Finalità dello studio e del progetto . . . . . . . . . . . . . . . . . . . . 15
3.2 Piano di progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 Attività e disciplina del lavoro . . . . . . . . . . . . . . . . . . 17
3.2.2 Studio del dominio e analisi dei requisiti . . . . . . . . . . . . . 18
3.2.3 Analisi framework UI . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.4 Rischi tecnologici . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Attività di analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.1 Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Progettazione ad alto livello . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.1 Descrizione delle componenti . . . . . . . . . . . . . . . . . . . 33
3.4.2 Plugin utilizzati e testati . . . . . . . . . . . . . . . . . . . . . 35
3.5 Altre tecnologie utilizzate . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5.2 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
ix
x INDICE
3.5.3 AngularJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.5.4 HTML5 e CSS3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.5.5 ngCordova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.5.6 GenyMotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.5.7 CryptoJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5.8 Bower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.6 Verifica e validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4 Conclusione e valutazione retrospettiva 47
4.1 Consuntivo ore finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Raggiungimento obiettivi di progetto . . . . . . . . . . . . . . . . . . . 47
4.3 Conoscenze pregresse ed acquisite . . . . . . . . . . . . . . . . . . . . . 47
4.4 Problematiche incontrate e fattibilità di alcuni requisiti . . . . . . . . 49
4.4.1 Firma remota . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.2 Integrazione con SecureDrive . . . . . . . . . . . . . . . . . . . 49
4.5 Considerazioni finali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
A Glossario 53
A.1 Termini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.2 Acronimi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Bibliografia 59
A.3 Riferimenti bibliografici . . . . . . . . . . . . . . . . . . . . . . . . . . 59
A.4 Siti web consultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Elenco delle figure
1.1 Logo InfoCert S.p.A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Logo DiKe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Logo LegalMail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Logo Business Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Alcuni modelli di Business Key . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Logo LegalInvoice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.7 Logo SecureDrive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.8 Logo di LegalDoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Distribuzione del sistema operativo Android al 1 settembre 2014. Fonte:
developer.android.com . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Distribuzione del sistema operativo iOS al 3 dicembre 2014. Fonte:
developer.apple.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Diagramma di Gantt delle attività . . . . . . . . . . . . . . . . . . . . 17
3.2 Tre macrocategorie di app: native, ibride e webview based. . . . . . . 18
3.3 Architettura generale del framework Titanium di Appcelerator. . . . . 20
3.4 Esempio di codice TSS in Titanium. Anche le classi CSS è possibile
riferirle a specifiche piattaforme target. . . . . . . . . . . . . . . . . . . 20
3.5 Esempio di anti-pattern in Titanium. . . . . . . . . . . . . . . . . . . . 21
3.6 Comportamenti diversi a seconda della piattaforma target possono creare
codice poco manutenibile. . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.7 Componenti di PhoneGap ad alto livello. . . . . . . . . . . . . . . . . . 23
3.8 Il framework Xamarin. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.9 Due stili diversi del framework Ratchet per le piattaforme iOS sulla
sinistra ed Android sulla destra.. . . . . . . . . . . . . . . . . . . . . . 25
3.10 Sworkit, app dedicata al fitness: una delle più famose negli app-store
realizzata con Ionic framework. . . . . . . . . . . . . . . . . . . . . . . 26
3.11 Ionic Creator, l’interface builder di Ionic dotato di interfaccia drag-and-
drop e possibilità di esportare il codice. . . . . . . . . . . . . . . . . . . 27
3.12 UC1.1: visualizzazione ad alto livello dello scenario "firma remota e
marca temporale". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.13 UC3: visualizzazione ad alto livello dello scenario "gestione impostazioni". 32
3.14 Architettura ad alto livello dell’applicazione CorDiKe. . . . . . . . . . 33
3.15 Struttura di un applicativo AngularJS. . . . . . . . . . . . . . . . . . . 33
3.16 Esempio di notifica "toast" nella parte alta. . . . . . . . . . . . . . . . 36
3.17 Esempio di splash-screen. . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.18 Logo di Java (Oracle). . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
xi3.19 Logo di AngularJS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.20 Dependency Injection in AngularJS. . . . . . . . . . . . . . . . . . . . 42
3.21 Loghi di HTML5 e CSS3. . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.22 Logo ngCordova, il nome deriva dalla fusione dei nomi Cordova ed
AngularJS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.23 Logo emulatore GenyMotion. . . . . . . . . . . . . . . . . . . . . . . . 44
3.24 Visitando chrome://inspect da un browser basato su Chromium è pos-
sibile collegarsi alla WebView in esecuzione del dispositivo Android
emulato. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.25 Logo Bower. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Elenco delle tabelle
3.1 Panoramica sullo sviluppo di applicazioni native. . . . . . . . . . . . . 19
3.2 Panoramica sullo sviluppo di WebView-based app. . . . . . . . . . . . . 19
3.3 Elenco dei requisiti ad alto livello del sistema CorDike. . . . . . . . . . 30
4.1 Rapporto orario a consuntivo. . . . . . . . . . . . . . . . . . . . . . . . 48
xiiCapitolo 1
Introduzione
1.1 Introduzione
Il seguente capitolo ha la funzione di elencare le informazioni dell’azienda presso la
quale è stato svolto lo stage. Vengono descritte la storia dell’azienda e i principali
prodotti forniti dall’azienda ai propri clienti.
1.2 Dati aziendali
Nome: InfoCert S.p.A.
Partita IVA: 07945211006
Indirizzo: Corso Stati Uniti 14bis, 35127 Padova
Telefono: 199 500130
Email (tutor aziendale): enrico.francescato@infocert.it
Sito web: http://www.infocert.it
figura 1.1: Logo InfoCert S.p.A.
12 CAPITOLO 1. INTRODUZIONE
1.3 Storia ed attività aziendali
InfoCert S.p.A. nasce nel 2007 come new company posseduta al 100% da InfoCamere,
la Società Consortile di Informatica delle Camere di Commercio Italiane.
La società è nata come risultato della cessione del ramo d’azienda denominato
“Prodotti e servizi Mercato Privato e Pubblica Amministrazione” e comprende servizi
di certificazione digitale, servizi riguardanti il commercio elettronico, la conservazione
sostitutiva, la gestione documentale, la posta elettronica certificata, i servizi di consu-
lenza e sicurezza informatica, rivolte non soltanto alle pubbliche amministrazioni, ma
anche al mercato dei privati.
1.4 Mission
La nuova società è dotata di circa 160 dipendenti distribuiti tra le sedi di Roma,
Milano e Padova. È già pienamente operativa nella commercializzazione di LegalDoc,
la suite in architettura Web che copre l’intero processo della gestione documentale
garantendo il passaggio dalla carta al digitale in assoluta sicurezza e nel pieno rispetto
della normativa vigente in materia.
InfoCert è inoltre un ente certificatore di firma digitale (certificati ospitati sulla
innovativa Business Key) e dei servizi di posta elettronica certificata (distribuiti con il
marchio LegalMail). InfoCamere continuerà a gestire tutti i servizi informatici per le
Camere di Commercio italiane, configurandosi sempre più come supporto allo sviluppo
tecnologico e informativo del sistema camerale nazionale.
1.5 Prodotti e servizi forniti
I principali prodotti forniti dall’azienda sono:
1.5.1 DiKe
Software multipiattaforma (Windows, Mac, Linux, iOS) che consente di firmare o
marcare temporalmente un qualunque tipo di file, nonché di verificare le firme e le
marche temporali associate ad un documento.
La firma digitale è il risultato di una procedura informatica che consente a chi firma
un documento digitale (file di scrittura, foglio elettronico o immagine in tutti i formati
autorizzati) di rendere manifesta e garantire:
∗ l’autenticità, cioè che il documento è originale;
∗ la paternità, ossia chi ha firmato il documento;
∗ l’integrità, ovvero che il documento non sia stato modificato dopo essere stato
firmato digitalmente.
La firma digitale presenta vantaggi in termini di semplificazione dei rapporti tra
aziende e tra queste e gli enti pubblici. Si pensi all’invio di un qualsiasi documento
cartaceo: va scritto, stampato, firmato e poi spedito tramite posta tradizionale.1.5. PRODOTTI E SERVIZI FORNITI 3
Con la firma digitale si firma il documento attraverso dispositivi elettronici e lo si
invia elettronicamente, senza stamparlo. Si risparmia, quindi, in costi di stampa del
cartaceo e tempi di trasmissione, con la sicurezza dell’inalterabilità dei contenuti.
figura 1.2: Logo DiKe
1.5.2 LegalMail
LegalMail è il nome del servizio con cui InfoCert commercializza il proprio servizio di
posta elettronica certificata.
Negli ultimi anni alcune direttive governative hanno indicato la PEC come strumento
di primaria importanza per le Pubbliche Amministrazioni. In questo contesto rivestono
particolare importanza le caselle istituzionali delle P.A., previste dalla normativa sul
protocollo, e l’indice generale delle Pubbliche Amministrazioni italiane - IPA: un sito
che consente di individuare le P.A. italiane utilizzando diversi criteri di ricerca e,
per ciascuna P.A. fornisce informazioni tra cui la casella istituzionale (ove presente).
L’indice della P.A. rappresenta il principale indirizzario di posta certificata presente in
rete.
L’utilizzo della PEC si sta rapidamente diffondendo anche in molti altri settori in
quanto permette di sostituire la raccomandata e il fax nei rapporti ufficiali e si
può usare anche per l’inoltro di comunicazioni che attestino l’invio ma non richiedano
la certificazione della consegna (ad esempio le fatture):
∗ Invio di ordini, contratti, fatture
∗ Convocazioni di Consigli, Assemblee, Giunte
∗ Inoltro di circolari e direttive
∗ Gestione delle comunicazioni ufficiali all’interno di organizzazioni articolate o a
"rete" (franchising, agenti, eccetera)
∗ Integrazione delle trasmissioni certificate in altri prodotti come ERP, paghe e
stipendi, protocollo, gestori documentali, workflow[g]
figura 1.3: Logo LegalMail
1.5.3 Business Key
La Business Key è un dispositivo hardware di firma di facile utilizzo perché contiene al
suo interno tutto il software necessario per la firma digitale dei documenti (DiKe) e
l’accesso sicuro ai siti web.4 CAPITOLO 1. INTRODUZIONE
figura 1.4: Logo Business Key
figura 1.5: Alcuni modelli di Business Key
1.5.4 Legal Invoice
Legal Invoice, è il servizio online per la fatturazione elettronica. Esiste in quattro
versioni, a seconda delle esigenze:
∗ LegalInvoice PA
∗ LegalInvoice PA Multimpresa
∗ LegalInvoice PA Engine
∗ LegalInvoice Enti Pubblici
figura 1.6: Logo LegalInvoice
Le disposizioni della legge finanziaria 2008 prevedono che, al fine di semplificare il
procedimento di fatturazione e registrazione delle operazioni imponibili, l’emissione, la
trasmissione, la conservazione e l’archiviazione delle fatture emesse nei rapporti con le
pubbliche amministrazioni, anche ad ordinamento autonomo, e con gli enti pubblici
nazionali, anche sotto forma di nota, conto, parcella e simili, deve essere effettuata
esclusivamente in forma elettronica.
A livello normativo, quindi, tutte le PA destinatarie non potranno né accettare
le fatture emesse o trasmesse in forma cartacea né procedere al pagamento, neppure1.5. PRODOTTI E SERVIZI FORNITI 5
parziale, sino all’invio del documento in forma elettronica.
InfoCert S.p.A. con il suo servizio Legal Invoice sta quindi riscuotendo un grande
successo, basi pensare che dal 6 giugno 2014 le amministrazioni centrali (Ministeri,
Agenzie Fiscali, Scuole ed Enti Previdenziali) non possono più accettare fatture emesse
o trasmesse in forma cartacea. Dal 31 marzo 2015 inoltre, anche le amministrazioni
locali devono rispettare gli obblighi di fatturazione elettronica.
1.5.5 SecureDrive
Servizio di cloud-storage disponibile nei tagli da 1GB, 10GB e 30GB. Fornisce uno
spazio digitale sicuro dove poter effettuare copie di backup dei propri dati o condividere
file con altri utenti. Compreso nel servizio vi è anche SecurePassword, un password
wallet per memorizzare le proprie password in modo sicuro.
figura 1.7: Logo SecureDrive
1.5.6 Certificati SSL
Essendo InfoCert S.p.A. una Certification Authority, rilascia certificati SSL standard,
multidomain e wildcard.
Avere un certificato SSL infatti, diventa sempre più importante per chiunque intenda
affacciarsi al web in modo professionale:
∗ le imprese, i professionisti, le associazioni e le Pubbliche Amministrazio-
ni che intendono accrescere la fiducia dei propri utenti o clienti che navigano sul
web, rendendo le proprie informazioni affidabili e sicure soprattutto nel momento
in cui viene richiesto di inserire dati personali o di compilare form on-line;
∗ tutte le realtà che possiedono un sito e-commerce e certificano la propria
identità nel momento in cui i clienti acquistano on-line.
1.5.7 LegalDoc
La conservazione digitale è quel processo "disciplinato" che permette di conservare
i documenti in formato digitale consentendo di distruggere l’originale cartaceo o di
non procedere con la sua stampa. Serve a garantire autenticità, integrità, affidabilità,
leggibilità e reperibilità dei documenti.
Per "conservazione digitale" si intende quindi "sostituire i documenti cartacei, con
lo stesso documento in formato digitale" la cui valenza legale di forma, contenuto e
tempo è testimoniata con una firma digitale e una marca temporale.
Per conservare i documenti a norma è necessario possedere:6 CAPITOLO 1. INTRODUZIONE
∗ la firma digitale, ossia quella firma elettronica che si applica ai documenti
informatici, esattamente come la firma tradizionale (autografa) viene apposta sui
documenti cartacei;
∗ la marca temporale, ossia una successione di caratteri che rappresentano una
data e/o un orario per assodare l’effettivo avvenimento di un’attività/evento.
L’unione della firma digitale alla marca temporale consente di dare la conferma
dell’origine del documento informatico e di rendendolo immodificabile.
figura 1.8: Logo di LegalDoc
1.6 Organizzazione del testo
Il secondo capitolo descrive lo scopo del progetto, gli obiettivi, i vincoli e la pianifi-
cazione di esso.
Il terzo capitolo suddiviso in varie sottosezioni, approfondisce lo studio dei fra-
mework [g] oggetto dello stage evidenziandone le loro peculiarità ed i loro punti
deboli; vengono inoltre trattati l’analisi dei requisiti, alcuni casi d’uso, la pro-
gettazione di alto livello, le tecnologie e gli strumenti utilizzati, le attività di
sviluppo, codifica, verifica e validazione.
Il quarto capitolo contiene alcune considerazioni finali con riferimento al soddisfaci-
mento dei requisiti.
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 parti del gergo tecnico sono evidenziati con
il carattere corsivo.Capitolo 2
Progetto
Il seguente capitolo fornisce una descrizione del progetto svolto con un’analisi degli obiettivi,
dei vincoli e dei rischi associati.
2.1 Integrazione del progetto in azienda
In occasione dell’evento Stage-IT 2014 svoltosi a Padova il 14 maggio 2014, c’è stato un
primo colloquio con alcuni dipendenti dell’azienda che hanno illustrato alcuni progetti
di stage riguardanti varie tematiche.
Stage-IT, promossa da una collaborazione tra Università di Padova e Confindustria,
è un’iniziativa che mira ad agevolare l’incontro tra le imprese e gli studenti che entre-
ranno a breve in stage nel mondo del lavoro con specifico riferimento al settore ICT,
favorendo un’occasione di conoscenza reciproca mediante colloqui individuali.
In seguito, vi è stato un secondo colloquio più specifico durante il quale ho manife-
stato il mio interesse verso il progetto che mi sembrava più stimolante; in particolare
ho trovato di mio interesse approfondire l’ambito delle applicazioni per smartphone.
Abbiamo quindi scelto assieme al tutor aziendale di svolgere uno studio sui fra-
mework esistenti per la creazione di app ibride; tali framework infatti, permettono di
realizzare app multipiattaforma in modo agevole essendo in possesso delle conoscenze
riguardanti le tecnologie conosciute da un comune sviluppatore web (HTML5, CSS,
JavaScript).
Si è iniziato con uno studio panoramico ed una comparazione delle tecnologie
esistenti nell’ambito delle web app approfondendo Phonegap/Cordova, Appcelerator
Titanium ed eventuali altri framework.
Sono stati poi approfonditi framework UI per sviluppo parte UX di app mobile con
tecnologie web (Ionic, Ratchet).
Successivamente è stata fatta una valutazione delle potenzialità dell’interazione di
funzioni native sviluppando un plugin [g] per sfruttare moduli nativi.
78 CAPITOLO 2. PROGETTO
Inizialmente era stata prevista la realizzazione di un prototipo di una tra le due
applicazioni proposte dall’azienda:
∗ SecureDrive per la gestione sicura dei documenti nel cloud ;
∗ DiKe per la firma e marca temporale di documenti.
Quello su cui ci si è focalizzati, e lo si può vedere in dettaglio nei capitoli suc-
cessivi, è un’app che implementa le funzionalità di base di entrambe le app sopraccitate.
Una volta terminata quindi l’attività di analisi dei requisiti, si è passati alla
progettazione, per poi passare alla codifica ed alcuni test per poi finire con un rilascio
di un prototipo del core dell’applicazione.
2.2 Obiettivi dello stage
Gli obiettivi dello stage sono stati discussi durante i colloqui che hanno preceduto
l’inizio delo stage. Durante questi incontri, sono state delineate quelle che sarebbero
dovute essere le caratteristiche principali da sviluppare affinché il tirocinio potesse
essere considerato edificante per lo stagista e di utilità per l’azienda stessa.
∗ obiettivi esplorativi: rappresentano quanto lo stagiaire sia abile nel valutare,
studiare ed approfondire le nuove tecnologie che si evolvono di continuo, migliora-
no o diventano obsolete. Si tratta quindi di stabilire quanto una nuova tecnologia
presa in esame, sia matura; quali siano quindi i suoi limiti e quali siano le sue
peculiarità, tenendo conto anche di alcuni requisiti prestazionali. Alcune delle
tecnologie prese in esame ed alcuni tool utilizzati, ad esempio Ionic Framework
oppure Android Studio, erano ancora in "beta" durante il periodo dello stage.
Nella analisi si è tenuto conto anche della retro-compatibilità; cioè la possibilità
per l’applicazione mobile di poter eseguire senza problemi anche in dispositivi
più datati e magari dotati di un hardware non eccezionale. Più nello specifico,
gli obiettivi da raggiungere sono:
– comparativa tra i più noti framework attuali per lo sviluppo di app ibride:
Cordova/PhoneGap, Appcelerator Titanium e Xamarin;
– compratativa tra i framework UX per app mobile, non soltanto per riuscire
a dare al prototipo dell’applicazione aspetto gradevole ed usabile, ma anche
per cercare di avvicinarsi il più possibile ad un look and feel [g] proprio di
una app nativa;
– studio di fattibilità del progetto e realizzazione dello stesso con tecnologie
non ancora esplorate in dettaglio dall’azienda;
– permettere allo stagiaire di essere consapevole dei rischi che l’eventuale
adozione e variabilità delle tecnologie in esame comportano.
L’approfondimento sui framework oggetto dello stage, permette all’azienda di
avere una visione chiara di quali sono i limiti ed i benefici di queste tecnologie; può
quindi pensare ad una semplificazione nello sviluppo di alcune app attualmente
sviluppate come native (ad esempio DiKe per iOS ed Android [g] ). Lo sviluppo di
app ibride richiede la conoscenza dei linguaggi di programmazione conosciuti da
un comune sviluppatore web; una conoscenza quindi meno specifica rispetto ad2.2. OBIETTIVI DELLO STAGE 9
uno sviluppatore di app native. Si può pensare quindi allo sviluppo di un’unica
app ibrida eventualmente estendendola con uno o più plugin nativi specifici per
ogni piattaforma per cui si vuole effettuare il deploy.
∗ obiettivi funzionali: sono quelli che riguardano il soddisfacimento dei requisiti
inerenti le funzionalità principali che il prototipo dell’applicazione deve avere
al termine dello stage. Per meglio definire questi obiettivi, sono state prese in
considerazione le caratteristiche principali dell’app nativa DiKe per iOS per la
firma e marca temporale di documenti e la web app di SecureDrive, un servizio di
cloud storage (ancora in beta durante lo stage). Più nello specifico, gli obiettivi
da raggiungere sono:
– funzionalità di firma remota dell’hash[g] di un file dialogando con il web
service [g] ;
– funzionalità di visualizzazione dell’hash firmato per i file già firmati con la
firma remota;
– funzionalità di salvataggio in locale delle credenziali per l’autenticazione ai
servizi di firma remota e account cloud storage SecureDrive;
– funzionalità di visualizzazione del proprio certificato di firma remota;
– funzionalità di ricerca per nome file tra i file precedentemente firmati;
– funzionalità di ricezione di notifiche push [g] attraverso il cloud messaging
service di Google;
– funzionalità di visualizzazione dei file presenti nel cloud di SecureDrive e
visualizzazione informazioni riguardanti l’account SecureDrive.
La documentazione da me redatta potrà essere d’aiuto ed impiegata come punto
di partenza per lo sviluppo di future applicazioni, nonostante lo studio sui
framework abbia dato origine ad un prototipo di una applicazione che non verrà
poi manutenuta dall’azienda.
∗ obiettivi funzionali opzionali: delineano quelli che sono gli obiettivi che
l’azienda ha ritenuto opzionali, quindi realizzabili dopo il completamento di tutti
i requisiti funzionali sopraccitati. Più precisamente, tali requisiti sono:
– garantire la compatibilità del prototipo dell’app con il sistema operativo
Windows Mobile;
– funzionalità di salvataggio credenziali di marca temporale ed implementa-
zione dell’interazione con il web service adibito a tale scopo.
Riguardo la compatibilità con Windows Mobile, si è ritenuto opportuno focaliz-
zarsi sulle due piattaforme attualmente più diffuse.
Si è ritenuto inserire la funzionalità di marca temporale tra gli obiettivi funzionali
opzionali, dato che è del tutto simile all’implementazione della firma remota
(trattandosi di una connessione ad un webservice simile a quello per la firma
remota); si è preferito quindi impiegare il tempo per approfondire maggiormente
obiettivi più critici e più interessanti;10 CAPITOLO 2. PROGETTO
∗ obiettivi operativi: specificano che competenze che lo stagiaire deve acquisire
per essere in grado di lavorare in una realtà aziendale analoga a quella incontrata
durante il periodo di stage. Tali obiettivi includono alcune procedure aziendali:
– strumenti per la comunicazione all’interno della azienda;
– sistema di controllo di versione aziendale (repository);
– stesura della documentazione e comunicazione con il tutor aziendale.
Per il progetto di stage, è stato creato un repository condiviso tra lo stagiaire ed
il tutor aziendale. Dato che l’azienda utilizza SVN[g] come sistema di controllo di
versione, è stato utilizzato anche per il progetto di stage. Lo stagiaire inoltre,
benché impegnato nel progetto di stage, ha avuto modo essendo immerso nella
realtà aziendale, di osservare le regole e le procedure di lavoro del team e al termpo
stesso anche i servizi utilizzati a supporto delle procedure stesse. Dall’altro lato,
l’azienda ha senza dubbio osservato le procedure di gestione e l’organizzazione del
lavoro nello studio compiuto dallo stagiaire, nella documentazione, nei diagrammi
e nel codice da lui prodotto in modo da poter valutare eventuali collaborazioni
future con lo stagiaire.
∗ obiettivi formativi: descrivono quanto c’è da apprendere ed approfondire per
uno studio dettagliato sulle tecnologie prese in esame, sia a titolo professionale
ma soprattutto al fine della realizzazione del prototipo dell’app.
– conoscenza dei framework Appcelerator Titanium e Cordova/PhoneGap per
quanto riguarda lo sviluppo su piattaforme Android e iOS ;
– conoscenza di Java per la programmazione di alcuni plugin nativi per
Android per estendere l’app e al tempo stesso capire i limiti ed i punti di
forza dei framework per lo sviluppo di app ibride;
– conoscenza di framework CSS (Ionic e Ratchet) per creare un look and feel
quanto più simile alle app native;
– ulteriori framework Javascript (AngularJS) per favorire l’utilizzo di design
pattern [g] e la coesione delle componenti;
– arricchimento professionale riguardante la gesione dei progetti, il loro
sviluppo ed il contesto lavorativo;
– conoscenza di problematiche in ambito mobile, relative all’adozione di nuove
tecnologie; ricerca di soluzioni a problemi di questo tipo.
2.3 Motivazioni
Le motivazioni che hanno spinto l’azienda a proporre lo stage in questione sono
prevalentemente di natura esplorativa. Sebbene esista in azienda un asset dedicato alla
R&D, essersi dotati di una presenza che approfidisse un ambito ancora sconosciuto, è
stato sicuramente utile.
L’ambito di ricerca inoltre è molto interessante dal punto di vista strategico per
l’azienda dato che l’app DiKe per la firma remota è disponibile nativamente solo per
iOS ed è stata affidata in outsourcing; l’applicazione web di SecureDrive invece, durante
il periodo di stage, era ancora in sviluppo come webapp e non era ancora stata rilasciata
per il pubblico. Nel primo caso quindi, lo studio su queste tecnologie perché è possibile2.4. VINCOLI DEL PROGETTO 11
ripensare ad uno sviluppo "unificato" per le principali piattaforme (Android, iOS e
Windows Phone) e magari con qualche plugin specifico (firma remota) per implementare
funzionalità native, per ogni piattaforma. Nel secondo caso di SecureDrive invece,
può essere interessante integrare la webapp già in costruzione, con funzionalità native
di ogni piattaforma normalmente impossibili da ottenere con una webapp quali ad
esempio l’accesso al file system [g] , le notifiche push o l’accesso al calendario di sistema.
L’approfondimento inerente le app ibride inoltre, consente all’azienda di affacciarsi
nel mondo mobile in modo diverso, minimizzando gli investimenti iniziali circa lo
studio di tecnologie dato che si tratta di conoscenza di linguaggi e tecnologie di cui
uno sviluppatore web è in possesso; conoscenze sicuramente meno specifiche rispetto
ad uno sviluppatore di app native.
Considerata inoltre la capillare diffusione degli smartphone, è importante per
l’azienda adeguare i propri prodotti con questi nuovi strumenti che fanno sempre più
parte della nostra vita e di quella di potenziali clienti.
2.4 Vincoli del progetto
Durante una prima analisi, sono stati evidenziati alcuni vincoli di progetto in particolare
vincoli tecnologici e temporali. I vincoli tecnologici sono vincoli fissati dall’azienda
e riguardano le tecnologie da utilizzare; i vincoli temporali invece sono riferiti alle
funzionalità da implementare nei tempi stabiliti dal piano di lavoro.
2.4.1 Vincoli tecnologici
Di seguito sono descritti in breve alcuni vincoli strutturali importi dai sistemi mobile
e dai framework oggetto di studio che si è scelto di utilizzare. Una descrizione più
dettagliata è presente nel capitolo successivo.
Vincoli delle piattaforme Android ed iOS
∗ Frammentazione delle versioni di Android: è un dato di fatto con cui è
opportuno imparare a convivere. Tuttavia per farlo, è richiesta una attività di
ricerca per riuscire a mantenere la retro-compatibilità delle varie componenti
anche con le versioni di Android più datate. Nel mondo iOS tale fenomeno è
molto meno presente dato che vi è una frammentazione molto bassa; in Android
però, la frammentazione è molto più elevata.
∗ Frammentazione delle risoluzioni degli schermi: occorre realizzare un’interfaccia
utente che sia fluida e che quindi sia in grado di adattarsi ad almeno quattro
taglie di grandezza (se si considera una taglia per gli smartphone, una per i tablet
e i due orientamenti possibili del dispositivo).
∗ HTML5 e funzionalità di store: non tutte le tecnologie di archiviazione
sono totalmente supportate dai sistemi operativi mobile (ad esempio indexedDB
e WebSQL) e hanno limiti in termini di spazio di archiviazione.
∗ Le WebView ed i loro limiti: per quanto riguarda il mondo Android, le WebView
precedenti ad Android 4.4 sono basate sul motore del browser[g] nativo del sistema
operativo stesso. Tale motore è più lento rispeto a Google Chrome mobile
e supporta solo parzialmente alcune delle nuove funzionalità di HTML5; in
particolare il supporto all’accelerazione grafica è più limitato e la differenza si12 CAPITOLO 2. PROGETTO
figura 2.1: Distribuzione del sistema operativo Android al 1 settembre 2014.
Fonte: developer.android.com
figura 2.2: Distribuzione del sistema operativo iOS al 3 dicembre 2014.
Fonte: developer.apple.com
fa sentire maggiormente in dispositivi più datati. Nel mondo iOS invece, la
WebView è basata su Safari e, a partire da iOS 6, la WebView viene equipaggiata
con un nuovo motore Javascript chiamato Nitro che rispetto al motore usato
nelle precedenti release di iOS promette prestazioni anche del 200% superiori.
∗ Memoria limitata: nella scelta dei framework da utilizzare e nel memorizzare
dati in-memory occorre fare scelte nell’ottica del basso dispendio di memoria. Si
consideri inoltre l’elevato consumo che comporta l’esecuzione della WebView in
Android.
Vincoli del framework scelto: Cordova/PhoneGap
Una applicazione realizzata con il framework Cordova/PhoneGap apre un’unica view
(o Activity [g] utilizzando la terminologia del mondo Android). Tutti gli eventi e le
interazioni con l’utente vengono gestiti attraverso JavaScript incorporato in pagine
HTML che vengono quindi eseguite nel browser web del device. I vincoli da considerare
sono quindi quelli relativi all’interprete JavaScript e quelli relativi al dispositivo stesso
e alle performance del browser.
∗ Attivare processi in background : lavorando solo lato JavaScript non è
possibile far eseguire thread che rimangano in ascolto di determinati eventi a
basso livello. Tuttavia è possibile realizzare dei plugin codificati come componenti2.4. VINCOLI DEL PROGETTO 13
native che svolgano tale compito. Lo sviluppo di componenti native naturalmente
va ad influire sul grado di portabilità dell’applicazione.
∗ Performance della UI: l’interfaccia grafica deve risultare agli occhi dell’utente
quanto più fluida possibile; vanno evitati pertanto possibili cammini di esecuzione
che provochino intensi burst CPU-bound [g] che andrebbero a bloccare la UI.
JavaScript infatti è un linguaggio che viene eseguito su un solo thread che viene
condiviso tra l’interprete ed i processi del browser adibiti al rendering.
∗ User experience: anche nello sviluppo di applicazioni in ambito mobile, non
vanno trascurate quelle che sono le convenzioni concettuali e grafiche con cui
l’utente è abiutato ad interagire utilizzando altri sistemi simili. Va quindi fatto il
possibile per non rompere queste convenzioni che creerebbero disagio nell’utente.
Per motivi legati al tempo limitato tuttavia,
∗ Utilizzo di plugin: tra le centinaia di plugin disponibili nel repository ufficiale
di Cordova chiamato Plugin Registry, molti plugin sono sviluppati da sviluppatori
non fidati e spesso non vengono mantenuti aggiornati. Occorre quindi utilizzare i
plugin con moderazione o se si usano plugin sviluppati da terzi, analizzare questi
aspetti.
Vincoli metodologici di lavoro
L’azienda mi ha lasciato notevole libertà circa questo tipo di vincoli. Più nello specifico,
si segnalano:
∗ Sistema di controllo di versione: obbligatorio da utilizzare. Ho scelto SVN dato
che veniva già utilizzato a livello aziendale per altri progetti.
∗ Riunioni: sono avvenute a cadenza settimanale per rivedere gli obiettivi intermedi
di volta in volta e per verificare l’avanzamento nello studio e nello sviluppo dell’app.
Accanto a questo ci sono state brevi comunicazioni quasi quotidiane con il tutor
aziendale.
∗ Documentazione: l’azienda ha richiesto una documentazione del codice sorgente
ma ancor prima, una lista di requisiti e diagrammi UML[g] per evidenziare i casi
d’uso e diagrammi delle classi.
2.4.2 Vincoli temporali
Le principali funzioni del prodotto devono essere implementate e correttamente funzio-
nanti al termine del periodo definito dal piano di lavoro. In particolare, il prodotto
deve fornire le funzionalità corrispondenti alle caratteristiche obbligatorie definite più
in dettaglio nella sezione 3.
La definizione delle attività e del loro peso in termini di ore impiegate sul totale,
sono state fissate nel piano di lavoro circa un paio di mesi prima dell’inizio dello stage.
Lavorando a contatto con gli sviluppatori dei principali prodotti offerti dall’azienda,
è stata possibile una facile comunicazione nei rari casi di problematiche con l’interfac-
ciamento a loro servizi già esistenti. Una comunicazione a distanza, avrebbe dilatato
inutilmente i tempi.Capitolo 3
Descrizione dello stage
In questo capitolo viene descritta una panoramica sulle tecnologie mobile oggetto di studio.
Vengono inoltre descritti lo sviluppo del progetto di stage evidenziandone le problematiche
incontrate, la ricerca e la presentazione delle soluzioni.
3.1 Finalità dello studio e del progetto
Durante i colloqui iniziali sono state discusse le seguenti funzionalità che delineano quelle
che sarebbero dovute essere le tematiche da analizzare, le tecnologie da approfondire
e le caratteristiche del prototipo dell’app affinché lo stage potesse essere ritenuto
completato in maniera soddisfacente.
∗ Studio framework mobile: lo stagiaire effettua uno studio tra le tecnologie
disponibili per lo sviluppo di app mobile con framework basati su HTML5
considerando in particolare Cordova/PhoneGap, Appcelerator Titanium. Per
ogni framework sono state evidenziate le principali peculiarità e gli svantaggi o i
problemi emersi.
∗ Approfondimento e scelta framework UI : lo stagiaire effettua uno studio
tra i principali framework per la creazione di UX al fine di ricreare un look and
feel quanto più possibile vicino a quello delle app native;
∗ Salvataggio credenziali: l’utente deve poter salvare lato browser le proprie
credenziali di accesso ai servizi offerti (firma remota, marca temporale, accesso
al cloud-storage SecureDrive). A questo proposito, è stata fatta anche una breve
panoramica sui modi possibili (con relativi vantaggi/svantaggi) per salvare dati
lato browser ;
∗ Funzionalità di firma remota: l’utente ha la possibilità di visualizzare
il proprio certificato di firma remota rilasciato dall’azienda stessa (che è una
Certification Authority). Lo stagiaire effettua anche uno studio di fattibilità per
quanto guarda la creazione lato JavaScript della busta PKCS7 dopo aver ricevuto
l’hash firmato.
∗ Visualizzazione documenti firmati: l’utente può inoltre visualizzare la lista
di file firmati dall’app visualizzandone l’hash firmato dal web service dell’azienda
adibito a tale scopo.
1516 CAPITOLO 3. DESCRIZIONE DELLO STAGE
∗ Interazione con API[g] di servizi aziendali: l’utente può autenticarsi e sal-
vare le credenziali del proprio account SecureDrive, visualizzarne le statistiche,
consultare la lista dei file presenti nel suo spazio di cloud-storage.
L’azienda ha inoltre proposto i seguenti vincoli di carattere tecnologico; alcuni di
essi condizionano le scelte progettuali, altri invece sono vincoli prestazionali e implicano
una ricerca approfondita circa le tecnologie da utilizzare.
∗ Supporto dalla versione target Android 4.0 Ice Cream Sandwich e successivo;
∗ Supporto dalla versione target iOS 6 e successivo;
∗ Utilizzo dello strato di API fornito dal team di sviluppo dell’azienda per interfac-
ciarsi con i servizi di firma remota e marca temporale;
∗ Utilizzo dello strato di API fornito dal team di sviluppo dell’azienda per interfac-
ciarsi con il servizio di cloud-storage SecureDrive;
∗ Interfaccia utente "fluida" in grando di adattarsi ai dispositivi tablet, smartphone,
sia in portrait che in landscape mode;
∗ Interfaccia grafica che non rompa le convenzioni a cui l’utente Android/iOS è
abituato, seguendo le linee guida consigliate da Apple e Google;
3.2 Piano di progetto
Il diagramma di Gantt in figura 3.1 illustra la suddivisione del lavoro in attività e
la loro ripartizione oraria a preventivo. La data di inizio stage era prevista per il 22
settembre 2014, mentre quella di fine il giorno 14 novembre 2014 per un totale di 320
ore ovvero 40 ore settimanali per otto settimane.
Si riporta qui di seguito una elencazione temporale delle attività con una breve
descrizione degli obiettivi da perseguire in oguna di esse:
∗ Conoscenze generali (A1): approfondimento sulle piattaforme disponibili per
lo sviluppo di app mobile cross platform con tecnologie web (Phonegap/Cordova,
Appcelerator Titanium, eventuali altri tool ).
Ore stimate: 80 ore (10 giorni)
∗ Studio integrazione API native (A2): valutazione delle potenzialità nell’in-
tegrazione di funzioni native.
Ore stimate: 40 ore (5 giorni)
∗ Analisi dei requisiti (A3): delineare in modo più dettagliato le caratteristiche
funzionali che l’applicativo dovrà avere. Le funzionalità che verranno analizzate
terranno conto delle funzionalità già presenti nei prodotti DiKe e SecureDrive.
Ore stimate: 40 ore (5 giorni)
∗ Progettazione (A4): progettazione architetturale e di dettaglio degli oggetti
coinvolti; progettazione dell’interfaccia utente.
Ore stimate: 60 ore (8 giorni)
∗ Codifica, test e rilascio prototipo (A5): sviluppo seguendo le norme di
codifica utilizzate all’interno dell’azienda; test e release di un prototipo del core
dell’applicazione.
Ore stimate: 100 ore (12 giorni)3.2. PIANO DI PROGETTO 17
Dal seguente diagramma di Gantt è possibile vedere la pianificazione delle attività
concordata assieme al tutor aziendale.
figura 3.1: Diagramma di Gantt delle attività
3.2.1 Attività e disciplina del lavoro
Dopo aver fissato le scadenze per lo svolgimento dello stage, sono state individuate le
principali attività da svolgere; a loro volta sono state scomposte in sotto attività. Gli
obiettivi intermedi venivano fissati con cadenza settimanale mediante un briefing con
il tutor aziendale che comunque veniva quotidianamente informato sugli sviluppi.
Analisi del dominio ed analisi dei requisiti
L’analisi del dominio applicativo in genere precede l’analisi dei requisiti. Tuttavia a
causa delle tempistiche ristrette, durante l’ultima parte dei primi 15 giorni dello stage,
sono state svolte in parallelo attività di studio del dominio ad attività di analisi dei
requisiti. In sede di analisi dei requisiti, utilizzando tecniche di brainstorming [g] , ho
annotato in un foglio di lavoro condiviso con il tutor aziendale, i punti fondamentali
circa i servizi ed i vincoli del sistema. Ho prodotto quindi una specifica testuale dei
requisiti mattendo in pratica gli insegnamenti del corso universitario di "Ingegneria del
software". Infine la stesura dei casi d’uso ha permesso di far emergere nuovi requisiti
che non erano così evidenti in prima battuta. Ciò ha facilitato la successiva trattazione
dei requisiti software.
Progettazione
Noti gli output delle attività precedenti, ho quindi definito l’architettura ad alto livello
del sistema. La scelta delle tecnologie ha influenzato alcune scelte architetturali. Sono
stati utilizzati design pattern al fine di risolvere problemi strutturali.
Codifica
Per l’attività di codifica, il codice è stato scritto seguendo gli standard di stile del
linguaggio di programmazione, utilizzando tool di analisi statica.18 CAPITOLO 3. DESCRIZIONE DELLO STAGE
3.2.2 Studio del dominio e analisi dei requisiti
Panoramica - sviluppo mobile
Allo stato attuale, nei vari app-store sono presenti applicazioni raggruppabili in tre
macro-categorie: le app native, le app ibride e le web view based app.
figura 3.2: Tre macrocategorie di app: native, ibride e webview based.
Le app native sono applicazioni sviluppate utilizzando specifici linguaggi e tec-
nologie derivate direttamente dalla piattaforma target del device. Per iOS vengono
impiegati Objective-C[g] e Swift con la relativa Apple SDK[g] e per il mondo Android
invece utilizzato Java accompagnato dalla Android SDK.
Le app ibride sono vere e proprie applicazioni native che vengono però compilate
partendo da una traduzione del codice JavaScript in codice oggetto attraverso un
motore JavaScript di processing. La logica dell’applicazione quindi non viene più
interpretata a runtime, ma è costituita da codice oggetto che viene eseguito, proprio
come una vera app nativa.
Le WebView-based app sono invece applicazioni scritte utilizzando le tecnologie
HTML5 e JavaScript, ma vengono compilate ed eseguite come appplicazioni native.
Questa categoria di applicazioni, generalmente sono costituite da un unico thread che
invoca l’esecuzione della WebView di sistema aprendo un file HTML a schermo intero.
Sarà poi l’utente a controllarne l’esecuzione attraverso le interazioni con la WebView
stessa.
Comparativa tra le tecnologie di sviluppo
Ognuna delle tre macrocategorie di app introduce vantaggi e svantaggi differenti. Lo
sviluppatore, nel ruolo di analista, deve quindi essere in grado di saper identificare
queli sono le condizioni per le quali abbia senso intraprendere lo sviluppo di una
WebView-based app oppure di una app nativa. Nel caso specifico di questo progetto,
con l’emergere dei requisiti, era sempre più chiara quale fosse la strada da intraprendere;
si è scelto di realizzare una WebView-based app per i seguenti motivi:
∗ Riuso del codice: il codice JavaScript può essere facilmente riutilizzato in
contesti simili ma con diversi obiettivi e finalità. Il poter produrre codice portabile
su diverse piattaforme mobile rende appetibile l’impiego di queste tecnologie.3.2. PIANO DI PROGETTO 19
∗ Comunicazione HTTP[g] : eventuali connessioni tramite web services via
HTTP per una app mobile sono le medesime che si effettuerebbero da una
normale pagina web: il workflow di comunicazione non cambia. Inoltre è possibile
testare l’applicazione in modo agevole utilizzando un browser desktop.
∗ Facilità nello sviluppare: grazie al corso universitario di "Tecnologie Web" e
ad esperienze personali extracurricolari, possedevo un buon livello di familiarità
con tecnologie come HTML e JavaScript. Lo staff aziendale, lavorando con queste
tecnologie da tempo, ha un ottimo livello di conoscenza in merito. Inoltre, la
conoscenza di queste tecnologie è più diffusa rispetto ai linguaggi nativi quindi
ciò richiede meno sforzo da parte dell’azienda per formare una risorsa in merito
a queste tecnologie.
∗ Presentazione e versatilità: è semplice, con l’utilizzo di appositi framework,
realizzare interfacce grafiche "fluide", capaci di adattarsi alle diverse dimensioni
degli schermi dei dispositivi. Le viste inoltre possono essere modificate tramite
CSS con grande facilità.
Volendo riassumere i vantaggi e gli svantaggi dello sviluppo nativo e di quello
WebView-based, si riportano qui di seguito due tabelle riepilogative.
tabella 3.1: Panoramica sullo sviluppo di applicazioni native.
Vantaggi Svantaggi
Un linguaggio specifico per ogni
- Codice oggetto ottimizzato -
piattaforma
Interfaccia utente nativa, look and feel della
- - Curva di sviluppo ripida
piattaforma
- Uso immediato di nuove funzionalità
- Accesso a tutte le funzionalità del dispositivo
- Scaricabile dagli app-store
tabella 3.2: Panoramica sullo sviluppo di WebView-based app.
Vantaggi Svantaggi
- Rapida curva di sviluppo - Nessuna ottimizzazione del codice
- Accesso a tutte le funzionalità del device - Alcune parti dipendono dalla piattaforma
- Medesimo linguaggio per tutte le piattaforme - Limiti prestazionali delle WebView
- UI facilmente realizzabile - UI lontane da quelle native
- Facilità di test direttamente da browser - Attesa di standardizzazione dal W3C[g]
- Facilità di riuso prima di utilizzare nuove funzionalità
- Scaricabile dagli app-store HTML5 e CSS3
Appcelerator Titanium
Titanium di Appcelerator è un framework per lo sviluppo cross-platform [g] che traduce
codice JavaScript in vere e proprie applicazioni native. Contrariamente alle WebView-
based app, non utilizza WebView del dispositivo per eseguire il codice JavaScript.20 CAPITOLO 3. DESCRIZIONE DELLO STAGE
figura 3.3: Architettura generale del framework Titanium di Appcelerator.
Sviluppando con il solo utilizzo di una singola codebase JavaScript è possibile quindi
creare app per iOS, Android, Windows Phone, BlackBerry OS e Tizen. Nel SDK
è incluso anche Alloy, un framework MVC [g] che organizza il codice per le viste in
XML[g] , i figli di stile come oggetti JSON[g] (più nello specifico il formato si chiama
TSS che non è altro che un foglio di stile CSS in notazione JSON).
figura 3.4: Esempio di codice TSS in Titanium. Anche le classi CSS è possibile riferirle a
specifiche piattaforme target.
Titanium fornisce, oltre ad un set di API che permettono di accedere alle funzionalità
native, anche altri set di istruzioni che permettono di utilizzare componenti grafiche e
widget.
Per l’interfaccia grafica ad esempio, vengono utilizzate anche qui istruzioni JavaScript
che poi vengono tradotte per utilizzare le componenti native della piattaforma.
Uno studio del framework Titanium ha potuto evidenziare alcuni aspetti negativi:
∗ Codice fortemente dipendente dalla piattaforma: le numerose API fornite
dal framework allo sviluppatore legano fortemente la progettazione della logica
applicativa al framework stesso; se da un lato il framework permette con un
unico set di API di scrivere codice con cui poi verrà fatto il deploy per numerose
piattaforme target, dall’altro ha lo svantaggio di proporre un livello di astrazione
molto alto e al termpo stesso generico. Ciò può rappresentare un problema
in ambito mobile, perché se nel mondo delle applicazioni desktop può essere
favorevole, in quello mobile i sistemi operativi evolvono in archi di tempo molto
più ristretti e la frammentazione delle loro release, come già visto, si fa sentire
maggiormanete. Non è da escludere quindi che nuove versioni di Titanium
introducano dei cambiamenti radicali della logica sottostante le API che vada
quindi a comportare onerose riprogettazioni dell’applicazione realizzata.
Proprio per il forte legame con la piattaforma sottostante, è possibile cadere3.2. PIANO DI PROGETTO 21
in anti-pattern com quello nella figura sottostante: è pericoloso scrivere codice
del genere in quanto non si tiene conto di eventuali piattaforme che magari al
momento della stesura del codice, neanche esistono.
figura 3.5: Esempio di anti-pattern in Titanium.
∗ Scarso supporto e documentazione: la documentazione presente nel sito
presenta alcune parti non aggiornate e talvolta si è costretti a documentarsi ana-
lizzando il codice sorgente o consultando siti terzi poco affidabili. La community
di Titanium sebbene ad agosto 2013 contasse 500.000 sviluppatori, non sembra
molto attiva nei forum. In un paio di occasioni, la risposta ad un mio quesito
non è mai arrivata dal forum ufficiale ma da altre fonti.
∗ UI poco flessibili: non è sempre possibile utilizzare stessi frammenti di codice
per realizzare una stessa interfaccia o componente grafica. Ciò è causato da bug
specifici che si manifestano a runtime su determinate piattaforme target. Questo,
oltre ad aumentare il tempo dedicato all’attività di test, va ad aumentare la
complessità del codice; come si può vedere dalla figura sottostante, è facile creare
codice poco manutenibile.
figura 3.6: Comportamenti diversi a seconda della piattaforma target possono creare codice
poco manutenibile.
∗ Bug non risolti: nella traduzione da codice JavaScript a quello nativo, vengono
introdotto parecchie anomalie fastidiose per la user experience. Quelle che più
colpiscono e che si manifestano soprattutto in Android sono legate ad alcune
transazioni grafiche che se in iOS vengono rese fluide, in Android presentano
rallentamenti insoliti. Risulta difficile accorgersi di questi comportamenti dalla
sola lettura della documentazione anche perché Titanium si pone come scatola
nera tra il codice JavaScript scritto dallo sviluppatore ed il codice che verrà
realmente eseguito dal dispositivo.
∗ Scarsa ottimizzazione: nel deployment per la piattaforma target Android,
utilizzando Titanium SDK v3.2.1 ho potuto constatare come il file APK in output,
pronto per essere distribuito nell’app store di Google, sia particolarmente pesante.
Per una semplice applicazione che stampa un "Hello World", il file APK finale è
arrivato a pesare quasi 11 MiB. Il peso eccessivo è dovuto al fatto che nel creare
la build [g] finale, Titanium incorpora ben tre interpreti JavaScript per architetture
diverse:22 CAPITOLO 3. DESCRIZIONE DELLO STAGE
– ARM v7a: ovvero dispositivi con Cortex A* come ad esempio Cortex A8,
A9 e A15 con il supporto a processori multicore.
– ARMeabi: ovvero dispositivi con ARM v5 (e.g. ARM9) e ARM v6 (e.g.
ARM11).
– x86: ovvero processori basati su architettura x86.
Non è possibile nella release di Titanium Studio provata (v3.2.1 del 02/10/2014)
selezionare quali interpreti JavaScript includere al momento della build.
Come soluzione individuata al fine di alleggerire il peso finale delle build, si
possono rimuovere manualmente gli interpreti non desiderati e fare ad esempio 3
build separate, ognuna specifica per ogni architettura CPU.
Google stessa, come indicato nel suo sito, supporta l’invio di molteplici APK
differenti a seconda dell’architettura CPU target della build.
Il framework si è rivelato non adeguato per la realizzazione del prototipo.
A parte le problematiche (risolvibili) di ottimizzazione nella build per Android e alcuni
problemi prestazionali, ho preferito abbandonare la scelta di tale framework soprattutto
per il rischio troppo elevato di duplicazione del codice per la parte UI: una duplicazione
vera e propria in quanto non si tratta di un semplice adattamento del codice al fine di
favorire e migliorare la user experience, quanto piuttosto di introdurre workaround per
sopperire ai limiti del framework stesso.
Nel SDK di Titanium inoltre manca un interface builder (cosa che invece ad esempio
Xcode[g] offre per il mondo iOS). Per testare le componenti grafiche quindi è necessario
un utilizzo intenso del simulatore per valutare di volta in volta le modifiche apportate
al codice.
PhoneGap (Cordova)
PhoneGap è un framework JavaScript per lo sviluppo mobile cross-platform di app
WebView-based prodotto dala canadese Nitobi, acquisita poi da Adobe nel 2011.
L’architettura di PhoneGap, le cui componenti ad alto livello sono mostrate nella
figura sottostante, prevede uno strato di astrazione del dispositivo che espone le proprie
funzionalità attraverso delle API JavaScript richiamabili dall’applicazione. Attraverso
tali API sono supportate diverse funzionalità native (accesso alla rubrica, notifiche
push, fotocamera e accesso al file-system) ed è possibile avere accesso ai vari sensori
(bussola, geolocation e accelerometro).
In una applicazione realizzata con PhoneGap si possono quindi riconoscere quattro
parti funzionali:
∗ Le implementazioni native che accedono alle funzionalità ed ai sensori del device
a basso livello.
∗ Un set di API strutturate (il bridge phonegap.js) che consente alla logica
applicativa di comunicare con le componenti native sottostanti.
∗ Un contenitore di risorse statiche che includono il JavaScript della business ed
application logic, le viste HTML, immagini, fogli di stile CSS e framework a
supporto per lo sviluppo.
∗ La webview nativa per l’esecuzione del codice JavaScript e l’apertura delle viste
HTML.Puoi anche leggere
