theses - Università degli Studi Mediterranea

Transcript

Università degli Studi Mediterranea di Reggio Calabria
Dipartimento di Ingegneria dell’Informazione, delle Infrastrutture e dell’Energia Sostenibile
Corso di Laurea in Ingegneria delle Telecomunicazioni
Tesi di Laurea
Analisi di approcci per la gestione multipiattaforma di
app “mobile”
1
Relatore
Candidato
Prof. Domenico Ursino
Carlo Iannò
Anno Accademico 2013-2014
1
Sviluppo applicazioni mobile mediante la politica Cross-Platform
INTRODUZIONE
Lo stato attuale del mercato continua a dimostrare come l’interesse del pubblico verso i
dispositivi mobili sia in costante crescita. Se, fino a pochi anni fa, il termine “smartphone”
era quasi privo di significato, ora è abbastanza comune, per giovani e adulti, essere con‐
centrati su piccoli dispositivi dove è possibile eseguire numerose operazioni. Non è, quin‐
di, un caso se gli smartphone sono il secondo gruppo di dispositivi al mondo, in termini di
quantità di connessioni, che utilizzano Internet abitualmente e, viste le numerose alter‐
native di Sistemi Operativi, come iOS, Blackberry, Windows Phone, Android, etc, sono
sempre di più gli utenti che scelgono il proprio dispositivo, e quindi il Sistema Operativo
correlato, in base alle proprie esigenze.
Negli ultimi anni, soprattutto nel mondo aziendale, dove ogni dipendente portava con sé
sul posto di lavoro il proprio dispositivo ”mobile” personale rimpiazzando i tradizionali
computer desktop, si è sviluppato un trend chiamato BYOD (Bring Your Own Device)
che, tradotto letteralmente, significa “portare il tuo dispositivo”.
1
Dall’avvento di tale trend si è reso necessario creare un ambiente di lavoro unificato in
modo tale da garantire che ogni dipendente possa lavorare su qualunque documento,
indipendentemente dal dispositivo, e quindi dal Sistema Operativo, utilizzati. Nasce,
così, lo sviluppo “mobile” Cross‐Platform che significa Multi‐piattaforma “mobile”. Tale
approccio abbraccia una vasta gamma di Sistemi Operativi e, di conseguenza, risolve
problematiche che stanno alla base di ogni piattaforma; tra queste vediamo le diverse
interfacce utente (UI) ed esperienze utente (UX), il consumo della batteria e le prestazio‐
ni, il linguaggio di programmazione, la versione di Sistema Operativo, etc. Grazie allo
sviluppo Cross‐Platform sono state create delle strategie per risolvere le varie problema‐
tiche; tra queste vediamo il supporto diretto, che punta a concentrare il team di sviluppo
su una sola piattaforma per volta, l’attività di condivisione, la WebApp. Quest’ultima
Carlo Iannò|
1
strategia permette di creare applicazioni Web facendo riferimento ai framework. Tra i principa‐
li framework, con licenza commerciale, vediamo Xamarin.
Xamarin, nasce dalla necessità degli sviluppatori di trovare un ambiente migliore per poter
sviluppare applicazioni “mobile” Cross‐Platform. Ciò che gli sviluppatori vogliono ottenere da
Xamarin è un linguaggio di programmazione moderno, strumenti potenti, un flusso di lavoro
efficiente e, piacevole, nonché la possibilità di migliorare l’esperienza utente. Il linguaggio di
programmazione utilizzato da Xamarin è C#, che, grazie alla sua facilità di comprensione,
permette ad ogni sviluppatore di seguire la filosofia di Xamarin: rispettare l’unicità di ogni piat‐
taforma.
Xamarin, come altri framework multipiattaforma che vedremo nel capitoli seguenti, possiede
una politica di sviluppo basata su strumenti e strategie particolari; tra queste abbiamo la condi‐
visione del codice, l’utilizzo del pattern MVVM, etc. Al fine di migliorare lo sviluppo multipiatta‐
forma, Xamarin utilizza tre strumenti fondamentali, ovvero XamChat, basato su un’applicazio‐
ne di chat ed una connessione Internet per lo scambio di messaggi di testo, Windows Azure,
che consente di interagire come un server Web, ed, infine, Xamarin.mobile, che consente di
aggiungere componenti di terze parti al progetto semplicemente servendosi di Xamarin Com‐
ponent Store.
Come in ogni settore anche per lo sviluppo Cross‐Platform esistono delle alternative al fra‐
mework Xamarin; un esempio sono, appunto, i framework con licenza open source Adobe
PhoneGap e Apache Cordova.
PhoneGap è un progetto della Nitobi Software, un’azienda che crea applicazioni “mobile” e
Web application da diversi anni. Esso consiste in un insieme di librerie statiche che permettono
di sviluppare velocemente, ed in maniera molto efficace, applicazioni “mobile” che apparten‐
gono a diverse famiglie. La filosofia sulla quale è basato prevede di realizzare lo slogan “Write
once, port everywhere” che, tradotto, vuol dire “scrivi una volta, porta in tutto il mondo ”. Pho‐
neGap si propone di focalizzare gli sforzi degli sviluppatori sull’applicazione piuttosto che per‐
dere tempo ad adattala ad ogni piattaforma; questo è il principale motivo perché numerosi
sviluppatori preferiscono tale framework.
2 |Carlo Iannò
Per poter sviluppare con PhoneGap è necessario conoscere HTML, CSS e JavaScript;
questi tre elementi rappresentano i principali tool di sviluppo e vengono definiti linguaggi
di programmazione di markup. I requisiti sono semplici: installare le SDK dove richiesto,
assieme ai tool per consentire lo sviluppo delle applicazioni.
Un successore di Adobe PhoneGap è il framework open source Apache, anch’esso distri‐
buito con licenza open source. Cordova rappresenta un set di API che permette agli svi‐
luppatori di accedere alle funzionalità native dei dispositivi come, ad esempio, fotocame‐
ra, geolocalizzazione, accelerometro, etc. Tale framework , come il suo predecessore, fa
si che lo sviluppo si basi interamente sull’uso di HTML, CSS e JavaScript, seguendo il
tradizionale approccio delle WebApp.
I principali tool e le principali tecnologie vengono differenziate in due macro‐categorie:
tecnologie Client‐Side, le quali non hanno potere di calcolo e svolgono compiti legati
soltanto alla capacità di visualizzazione. (un esempio sono JavaScript e AJAX), e tecnolo‐
gie Server‐Side, le quali hanno potere di calcolo, e quindi gestiscono compiti particolar‐
mente pesanti e possono trasferire in rete grossi volumi di dati. (un esempio sono Apache
Tomcat e PostgreSQL).
Vista la diversità di tecnologie utilizzate dai diversi framework, sia commerciali che open
source, si è avuta la necessità di sviluppare soluzioni ottimizzate per fornire il massimo
rendimento durante la fase di sviluppo per il “mobile” Cross‐Platform, utilizzando i princi‐
pali framework multipiattaforma.
1
Un’azienda leader nel settore del “mobile” Cross‐Platform è IBM; grazie alla suite deno‐
minata IBM Worklight fornisce strategie di sviluppo complete, dalla protezione e gestio‐
ne dei dispositivi alla realizzazione di applicazioni.
IBM, sintetizza le fasi di sviluppo grazie al Lifecycle, dove ogni passo è rappresentato da
funzionalità volte a raggiungere determinati obiettivi. IBM propone un approccio proget‐
tuale completo anche grazie all’unione con sistemi e soluzioni SAP; ha, inoltre, identifica‐
to nella Business Analytics una priorità strategica, aiutando responsabili decisionali e
sviluppatori a trovare soluzioni software nel settore “mobile” multipiattaforma.
Carlo Iannò|
3
Un’ulteriore azienda leader nel fornire soluzioni strategiche nel settore “mobile” Cross‐
Platform è Kony. Tale azienda si occupa principalmente di garantire che ogni utente, o meglio
ogni utilizzatore, abbia un’esperienza di utilizzo unica ed ottimizzata. Kony consente di combi‐
nare le informazioni provenienti da più fonti e creare soluzioni applicative. Un’importanza
fondamentale delle soluzioni Kony è la piattaforma di sviluppo KonyOne che rappresenta una
struttura a strati in cui gli strati principali sono KonyOne Studio, che si occupa di fornire agli
sviluppatori un ambiente di sviluppo integrato (IDE) con la massima flessibilità, e KonyOne,
Server che fornisce sicurezza e scalabilità alle funzionalità di aggregazione, come, ad esempio,
il servizio basato su sviluppo di applicazioni Web con piena integrazione ad altre soluzioni
“mobile” multipiattaforma, come Adobe Omniture e IBM Coremetrics.
Negli ultimi anni, oltre alle aziende leader citate precedentemente, sono nati altri approcci
legati allo sviluppo “mobile” Cross‐Platform, tra questi abbiamo Sencha Touch, che utilizza i
tool standard ed è concepito per essere compatibile con molti Sistemi Operativi, SAPUI5 e SAP
FIORI, concepiti per creazione di interfacce utente che utilizzano elementi di programmazione
Web, Rhodes, framework open source che permette di costruire vere applicazioni native sfrut‐
tando funzionalità del dispositivo e che è, inoltre, uno dei pochi framework che supporta il
pattern MVC, separando la logica dell’applicazione dalla grafica, Titanium Mobile, un fra‐
mework open source che non si limita ad usare i più comuni linguaggi di programmazione, ma
crea soluzioni Web basate su Ruby, PHP, etc; ultima, ma altrettanto importante tecnologia,
che meno si discosta dalle soluzioni SAP, è NepTune Application Designer, basata su un IDE
grafico dove le funzioni dell’applicazione sono create nel sistema stesso.
Un importante strumento di valutazione, usatissimo nel settore della consulenza strategica,
dell’analisi e della ricerca nel campo dell’Information Technology (IT), è il Magic Quadrant
sviluppato da Gartner. Grazie a tale strumento di valutazione può essere visualizzata la posizio‐
ne dei framework descritti in questa tesi e, al tempo stesso, la posizione delle aziende leader
nel settore di sviluppo “mobile” Cross‐Platform.
4 |Carlo Iannò
La tesi è strutturata come di seguito specificato:
•
Nel primo capitolo verrà descritta la politica di sviluppo Cross‐Platform.
•
Nel secondo capitolo verrà descritto il framework commerciale Xamarin.
•
•
•
•
•
Nel terzo capitolo verrà illustrato il funzionamento dei framework open source
Adobe PhoneGap e Apache Cordova.
Nel quarto capitolo verranno illustrate le principali soluzioni IBM nel campo dello
sviluppo per applicazioni “mobile”.
Nel quinto capitolo verranno illustrate le principali soluzioni Kony nel campo di
sviluppo per applicazioni “mobile”.
Nel sesto capitolo verranno illustrati i framework Sencha Touch, Appcelerator Tita‐
nium e descriveremo le soluzioni SAPUI5 e SAP Fiori; il capitolo si concluderà con la
descrizione di NepTune Application Design.
Infine, verranno tratte delle conclusioni in merito all’argomento trattato e verranno
assegnati alcuni possibili sviluppi futuri.
1
Carlo Iannò|
5
6 |Carlo Iannò
1. MOBILE APPLICATION DEVELOPMENT
PLATFORMS (MADP)
In questo capitolo verrà definito il termine “Cross-Platform”. Partendo dal significato del
termine, verranno descritte le differenze fondamentali tra le piattaforme “mobile”. Successivamente, verranno esposte delle strategie Cross-Platform. Il capitolo si concluderà con un tool
di Banchmarking Report grazie al quale metteremo in evidenza le principali aziende che
forniscono strategie Cross-Platform.
1
Che cos’è il CrossPlatform
4
Tool di Benchmarking
Report
2
Differenze Fondamentali tra le Piattaforme
Mobile
3
Strategie CrossPlatform
1
Carlo Iannò |
7
CHE COS’È IL CROSS-PLATFORM
In Informatica il termine Cross-Platform , o
Multi-Piattaforma, può riferirsi ad un linguag‐
gio di programmazione, ad un’applicazione
software o ad un dispositivo hardware che
funziona su più di un sistema o, appunto,
piattaforma (ad esempio, Linux, Windows e
Macintosh).
Negli ultimi anni, e soprattutto nel mondo
aziendale, dove ogni dipendente portava con
sè sul posto di lavoro il proprio dispositivo
“mobile” personale per utilizzarlo al posto
dei tradizionali computer desktop, si è svilup‐
pato un trend chiamato BYOD (Bring Your
Own Device) che, tradotto letteralmente,
significa portare il proprio dispositivo.
Dall’avvento di tale trend si è reso necessario
per le imprese sviluppare delle applicazioni
mobili aziendali che fossero in grado di lavo‐
rare su qualunque documento con la massi‐
ma compatibilità possibile tra i dispositivi
mobili che operano su varie reti e che utiliz‐
zano diversi sistemi operativi.
Lo sviluppo Cross‐Platform, grazie al trend
BYOD, si è evoluto passando da piattaforme
fisse a piattaforme mobili così da creare un
ambiente di sviluppo non solo per computer
desktop ma anche per dispositivi mobili,
dando vita al concetto di Cross‐Platform
8 |Carlo Iannò
Development Mobile.
Sono nate e si sono sviluppate molte aziende
(ad esempio IBM, Kony, Adobe ) con lo scopo
principale di offrire soluzioni e startegie per il
“mobile” cross‐platform dando supporto ad
ambienti nativi come iOS, Android, Windows
Phone, BlackBerry, etc, consentendo un
ambiente singolo per lo sviluppo il quale sarà
poi tradotto in diverse piattaforme mobili.
Grazie alla nascita di software come Xama‐
rin, PhoneGap, Cordova, i quali forniscono
numerosi strumenti per gli sviluppatori, si è
riusciti a ridurre i costi e aumentare la veloci‐
tà con la quale si sviluppano applicazioni
nonché diminuire la complessità del codice
sfruttando degli strumenti semplici basati su
linguaggi comuni per lo scripting, tra cui
CSS, HTML e JavaScript.
Un esempio base di Cross‐Platform possono
essere considerate le applicazioni Web per‐
ché, idealmente, sono accessibili da qualsiasi
browser Web all’interno di diversi sistemi
operativi. Tali applicazioni utilizzano un
sistema client‐server e variano ampiamente
in complessità e funzionalità. Questa ampia
variabilità complica notevolmente l’obiettivo
dello sviluppo Cross‐Platform, che è in con‐
trasto con l’obiettivo di funzionalità.
DIFFERENZE FONDAMENTALI TRA LE PIATTAFORME MOBILE
Lo sviluppo Cross‐Platform, nonostante sia di notevole vantaggio poiché ci consente di scrivere
il codice una sola volta e tradurlo su più piattaforme, prevede delle differenze fondamentali tra
le diverse piattaforme “mobile”.
E’ necessario, quindi, descrivere le principali differenze in modo da poter preventivare eventuali
problemi che potrebbero sorgere quando si sviluppa del codice multipiattaforma.
Consideriamo sei principali differenze:
•
•
•
•
•
•
Linguaggio di programmazione e versione del Sistema Operativo (OS);
Interfaccia Utente (UI) e d’Esperienza Utente (UX) ;
Desktop Integration Support;
Multitasking Support;
Consumo della batteria e prestazioni;
Acquisto e pubblicità delle applicazioni.
Nel seguito di questo paragrafo verranno analizzate in dettaglio queste sei principali differen‐
ze.
Carlo Iannò |
9
LINGUAGGIO DI PROGRAMMAZIONE E VERSIONE OS
Considerando le principali piattaforme “mobile” attuali, possiamo notare che ognuna di esse
rilascia i propri SDK (Software Development Kit) che consentono di sviluppare applicazioni
basandosi soltanto sullo sviluppo nativo per ogni piattaforma e, quindi, supportando soltanto
il corrispettivo linguaggio di programmazione.
Tuttavia, questi linguaggi appartengono ad una delle poche famiglie di programmazione di
base. La seguente tabella fornisce una panoramica dei principali linguaggi di programmazio‐
ne e le rispettive piattaforme che supportano tali linguaggi:
10| Carlo Iannò
Possiamo adesso, definire il concetto di Framework Cross-Platform, in grado di superare le
barriere dei linguaggi di programmazione di base. Tale struttura si basa su tre parametri fon‐
damentali:
•
•
•
tecnologie Web;
Interpretazione;
compilazione Multipla.
Inoltre, la maggior parte delle piattaforme forniscono anche un insieme di API (Application
Programming Interface) multipiattaforma, che consentono di accedere a determinate funzio‐
ni del dispositivo come, per esempio, la geolocalizzazione, elementi multimediali, funzionalità
di rete, etc.
Un altro aspetto da considerare quando si sviluppa codice Cross‐Platform è la versione del
sistema operativo che, essendo in continua evoluzione, aggiunge un livello di complessità
maggiore; pertanto, gli strumenti Cross‐Platform a volte necessitano di aggiornamento.
INTERFACCIA UTENTE (UI) E D’ESPERIENZA UTENTE (UX)
Un ostacolo fondamentale per l’approccio Cross‐Platform è rappresentato dalla diversa Inter‐
faccia Utente (UI) ed Esperienza Utente (UX), modelli molto rilevanti sulle singole piattaforme
“mobile”. E’ relativamente facile creare un’interfaccia utente che funzioni su diverse piattafor‐
me; tuttavia, tale approccio potrebbe perdere sottigliezze UI
importanti, che sono disponibili solo su un’unica piattaforma e,
quindi, potrebbe migliorare drasticamente l’esperienza utente.
Carlo Iannò |
11
Un aspetto importante è la filosofia di progettazione delle piattaforme “mobile”; mentre mol‐
te piattaforme cercano un design realistico, e quindi puntano a migliorare l’Esperienza Utente
partendo dall’Interfaccia Utente, altre tendono a creare degli stili ben precisi e, quindi, basan‐
dosi su un’Interfaccia Utente più o meno unica, cercano di migliorare l’Esperienza Utente; un
esempio potrebbe essere l’interfaccia Metro di Windows Phone.
Un’altra sfida fondamentale per chi sviluppa applicazioni
Cross‐Platform è la familiarità con i diversi dispositivi; tale
aspetto può migliorare notevolmente l’Esperienza Uten‐
te, il quale riuscirà a “lavorare” con estrema facilità. Un
semplice esempio potrebbe essere quello di non inserire il
tasto fisico “Indietro”.
DESKTOP INTEGRATION SUPPORT
L’integrazione del desktop varia molto tra le piattaforme “mobile”; ciò consente di personaliz‐
zare l’home screen. Su iOS e Android è possibile utilizzare la schermata widget mentre su
Windows Phone è possibile creare piastrelle che aggiungono informazioni strutturate. Tutto
ciò comporta una carico di lavoro maggiore per coloro che sviluppano su sistemi multipli, ma
migliora drasticamente l’interazione con gli utenti.
MULTITASKING SUPPORT
Il multitasking consente di mantenere attivi servizi in background e di eseguire contempora‐
neamente diverse applicazioni. E’ realizzato in modo differente tra i sistemi operativi; per
esempio su alcune piattaforme non è possibile chiudere del tutto le applicazioni che rimango‐
no attive in modalità background e vengono chiuse definitivamente dal sistema operativo
soltanto quando il dispositivo esaurisce la memoria. Su altre piattaforme, invece vi è una sele‐
zione limitata di attività in background che possono continuare a funzionare dopo la chiusura
dell’applicazione. Quindi, si dovrebbero valutare strategie multipiattaforma che consentono
l’utilizzo della modalità background.
12| Carlo Iannò
CONSUMO DELLA BATTERIA E PRESTAZIONI
Il consumo della batteria è strettamente legato al concetto di multitasking. Secondo la Legge
di Moore il numero di transistor all’interno del microprocessori raddoppia ogni 24 mesi; di con‐
seguenza anche le prestazioni del microprocessore raddoppiano; tuttavia, la capacità della
batteria viene raddoppiata solo ogni sette anni.
Più si è vicini alla piattaforma in un sistema Cross‐Platform più è possibile controllare il consu‐
mo della batteria e le prestazioni dell’applicazione. Come regola generale, più velocemente si
vuole eseguire l’applicazione, maggiori prestazioni sono necessarie al dispositivo e, quindi,
maggiore sarà il consumo della batteria.
ACQUISTO E PUBBLICITÀ DELLE APPLICAZIONI
Ci sono diverse opzioni per la visualizzazione di annunci pubblicitari all’interno di ogni applica‐
zione mobile; infatti, ad ogni applicazione vengono offerti servizi pubblicitari specifici per
avere dei ricavi e migliorare l’Esperienza Utente. Tuttavia tali servizi utilizzano politiche diver‐
se tra le piattaforme e, quindi, necessitano di maggiore attenzione durante la fase di sviluppo.
Un altro aspetto importante da considerare è il costo, in quanto ogni applicazione, secondo la
piattaforma per la quale è stata sviluppata, potrebbe avere un costo diverso ed anche mecca‐
nismi di acquisto totalmente differenti; bisogna, quindi, prestare attenzione a tali differenze
quando si sviluppa del codice multipiattaforma.
Carlo Iannò |
13
STRATEGIE CROSS-PLATFORM
Questo paragrafo descrive alcune delle strategie che si possono utilizzare per implementare le
applicazioni su diverse piattaforme. In particolare, consideriamo quattro principali strategie multi‐
piattaforma:
• Supporto Diretto;
• Attività di Condivisione;
• Compilazione Multilinguaggio;
• Web Apps (Hybrid Apps) .
Nel seguito di questo paragrafo analizzeremo in dettaglio tali strategie
SUPPORTO DIRETTO
Il modo più semplice per sviluppare un’applicazione è quello di concentrare dapprima il team di
sviluppo su una sola piattaforma e, successivamente, raccogliere informazioni sull’interfaccia
utente e sull’esperienza utente per capire se risulta positivo passare ad ulteriori piattaforme .
Un modo più complesso è quello di supportare diversi team di sviluppo specializzati per ogni piat‐
taforma di destinazione; tutto ciò richiede un intenso lavoro ma, probabilmente, darà la migliore
integrazione ed esperienza utente su ciascun sistema.
14| Carlo Iannò
ATTIVITÀ DI CONDIVISIONE
Quando si supportano diversi team per più piattaforme è necessario condividere strutture
dati, algoritmi, idee e concetti basati sull’Interfaccia Utente e sull’Esperienza Utente. È bene,
anche, utilizzare un linguaggio comune di una macchina virtuale che operi attraverso una
varietà di piattaforme. Tutto ciò permette ai team di sviluppo di risparmiare molto tempo e
fatica durante la fase di sviluppo Cross‐Platform.
COMPILAZIONE MULTILINGUAGGIO
La compilazione multilinguaggio consente la codifica di un linguaggio che viene tradotto in
una specifica piattaforma. In termini di prestazioni questa spesso è la migliore soluzione
Cross‐Platform; tuttavia, ci potrebbero essere differenze di prestazioni rispetto alle applica‐
zioni native.
Ci sono tre approcci comuni per tradurre dal linguaggio multipiattaforma ad un linguaggio di
destinazione specifico: fonte diretta di traduzione, fonte indiretta di traduzione (cioè tradu‐
cendo il codice in un linguaggio intermedio tra quello sorgente e quello di destinazione) e
linguaggio di programmazione e compilazione da utilizzare direttamente sulla piattaforma
interessata.
WEB APPS (HYBRID)
Facendo riferimento ai framework, possiamo creare applicazioni Web che si comportano
quasi come applicazioni reali; tuttavia, bisogna essere consapevoli del fatto che le tecnologie
hanno delle limitazioni quando si tratta di integrazione delle piattaforme.
Carlo Iannò |
15
In genere non si ha accesso a caratteristiche hardware e interfaccia utente nativa in maniera
semplice, ma bisogna considerare il fatto che si stanno considerando delle strategie multi‐
piattaforma.
Lo sviluppo Web ibrido implica incorporare una WebView (Interfaccia Web) all’interno di
un’applicazione nativa. Tale approccio consente di accedere alle funzionalità native delle
singole piattaforme; in tale contesto si può utilizzare il codice nativo per migliorare le presta‐
zioni e l’esperienza utente.
Le applicazioni ibride consentono, tramite dei framework, di incrociare le parti di sviluppo
Web con la piattaforma di sviluppo scelta. Tali soluzioni consentono, inoltre, di sviluppare
applicazioni compatibili con il massimo numero possibile di dispositivi migliorando l’accesso
ai siti Web tramite i dispositivi mobili.
La seguente tabella fornisce un quadro generale sulle soluzioni principali, con la rispettiva
licenza, l’input e l’output, ovvero la piattaforma per la quale vengono fornite soluzioni par‐
tendo da un input che si riferisce al linguaggio di programmazione utilizzato:
16| Carlo Iannò
TOOL BENCHMARKING REPORT
Una delle tecniche manageriali di cui recentemente si è più discusso è il Benchmarking,
inteso come quel “processosistematicoecontinuoperlacomparazionedelleperformance,
dellefunzioniodeiprocessidelleorganizzazioni[...]alloscopononsolodiraggiungere
quelleperformancemadisuperarle”( Commissione Europea, 1996 ).
L’obiettivo di questo rapporto, secondo una politica di programmazione Cross‐Platform, è
quello di identificare lo strumento multipiattaforma più appropriato e i servizi per lo sviluppo
di applicazioni “mobile”.
Esso fornisce, inoltre, informazioni di monitoraggio sullo stato attuale del mercato e sull’a‐
nalisi comparativa, che include strumenti e servizi che supportano l’idea di sviluppare una
sola volta e tradurre su più piattaforme; tale analisi si basa su due progetti di ricerca condotti
tra Marzo e Maggio 2014 da research2guidance (the mobile research specialists):
• Strumento di Confronto. Research2guidance ha invitato i fornitori di tool Cross‐
Platform e i fornitori di servizi a condividere informazioni sulla loro piattaforma, sup‐
porto per i dispositivi, team di sviluppatori, costi, etc. Successivamente è stato chiesto
ai fornitori di compilare un sondaggio on‐line; dopodiché, per convalidare i risultati, è
stata richiesta un’ intervista. A tale richiesta hanno dato risposta positiva 40 produttori.
• Valutazione degli Utenti. Agli sviluppatori, agli editori e ai dirigenti che valutano l’app
nelle loro aziende è stato chiesto di condividere la loro esperienza con i tool Cross‐
Platform. Nel 2014 hanno partecipato al sondaggio globale online in 2.188; il livello di
partecipazione degli utenti è rappresentato nella seguente figura:
Carlo Iannò |
17
La classificazione degli strumenti e dei servizi si basa su un auto‐posizionamento dei fornito‐
ri di soluzioni Cross‐Platform secondo il seguente schema:
• Web App Toolkits. Strumenti che supportano il processo di sviluppo di applicazioni
Web e pagine Web “mobile”. Un esempio di tool che appartiene a tale categoria è
Vaadin.
• App Factories (Drag & Drop). Ambienti di sviluppo di applicazioni che consentono
anche ai “non sviluppatori” di sviluppare codice nativo o una Web App in pochi giorni o
addirittura ore. Esempi di tool che appartengono a tale categoria sono: AppShed,
GameBuilder Studio, Vizi Apps, etc.
• Cross‐Platform IDEs (Ambiente di Sviluppo Integrato). Questi strumenti utilizzano il
proprio SDK per lo sviluppo e la compilazione del codice sorgente per soddisfare i re‐
quisiti nativi. Tendono a concentrarsi su un minor numero di piattaforme per essere in
grado di tenere il passo con il ritmo dell’innovazione, d’altra parte la strategia è quella
di supportare più piattaforme possibili. Esempi di tool che appartengono a tale catego‐
ria sono: Xamarin, Unity, Appcelerator, Marmalade, Titanium etc.
• Cross‐Platform IDEs for Enterprises (Ambiente di Sviluppo Integrato Aziendale).
Questi strumenti supportano il flusso di lavoro e di sviluppo di App in un ambiente
aziendale e forniscono un maggior numero di API preinstallate. Alcuni di essi, inoltre,
fanno parte di una suite più ampia che consente la gestione dei dispositivi. AppConKit,
IBM Worklight, Appear IQ, etc.
18| Carlo Iannò
• Cross‐Platform Compilers. Sono degli strumenti che si concentrano sulla traduzione
di un codice sorgente unico basato su applicazioni native. Esempi di tool che apparten‐
gono a tale categoria sono: PhoneGap Build, Cocoon (Games) etc.
• Cross‐Platform Services. Sono servizi che consentono una facile integrazione tra le
piattaforme per supportare attività quali l’acquisto di App, notifiche push e pubblicità.
Esempi di tool che appartengono a tale categoria sono: Capriza, Codename One, Mo‐
bileSmith, etc.
Di seguito viene mostrato un grafico che rappresenta la crescita dei principali sviluppatori di
tool Cross‐Platform rispetto all’anno 2013:
CONCLUSIONI
Alla luce dello studio effettuato in questo capitolo si può affermare che, per sviluppare appli‐
cazioni “mobile” Cross‐Platform, bisogna, innanzitutto, fare un’analisi sulle principali diffe‐
renze tra le piattaforme; successivamente, è necessario adottare delle strategie specifiche
ed, infine, auto‐posizionarsi in un determinato settore per sviluppare strumenti Cross‐
Platform.
Carlo Iannò |
19
20| Carlo Iannò
2. XAMARIN
In questo capitolo verrà illustrato il funzionamento del software Xamarin. Si partirà con
un’introduzione sulla politica di condivisione del codice utilizzata da Xamarin; successivamente verranno spiegati i principali strumenti sui quali si basa tale software. Il capitolo si
concluderà con una descrizione dei principali vantaggi e svantaggi di tale software e con
un’illustrazione della sua posizione sul Magic Quadrant di Gartner.
1
Che cos’è Xamarin
4
Pro e Contro e Gartner
Magic Quadrant 2014
2
Condivisione del codice
secondo Xamarin
3
Gli strumenti di Xamarin
Carlo Iannò |
21
CHE COS’È XAMARIN
Nel Maggio del 2011 dall’omonima società
che l’ha creato nasce Xamarin, un software in
grado di sviluppare codice Cross-Platform.
Il motivo principale per il quale venne creato
un software come Xamarin è legato alla
necessità, per gli sviluppatori, di trovare un
ambiente migliore per poter sviluppare applicazioni “mobile”. Ciò che si vuole ottenere da
Xamarin è un linguaggio di programmazione
moderno, strumenti potenti, un flusso di
lavoro efficiente e piacevole e la possibilità di
creare migliori esperienze utente.
L’approccio principale di Xamarin è quello di
consentire agli sviluppatori di creare interfacce utente che sono uniche per ogni piattaforma e componenti che possono essere facilmente riutilizzati su un’altra piattaforma,
utilizzando il linguaggio di programmazione
C#.
La filosofia sulla quale è basato Xamarin
rispetta l’unicità di ogni piattaforma e non
obbliga gli sviluppatori a creare applicazioni
che sembrano le stesse su tutte le piattaforme; al contrario, li incoraggia a sfruttare le
caratteristiche che ogni piattaforma offre.
Tale software riconosce che, oltre all’interfaccia utente, le applicazioni hanno molte
22|Carlo Iannò
componenti altamente riutilizzabili che possono essere condivise tra le piattaforme,
come, ad esempio, il codice per l’accesso ai
servizi Web, che può essere riutilizzato facilmente.
La scelta del linguaggio di programmazione
è ricaduta su C# soprattutto per la sua facilità di utilizzo rispetto ai più comuni linguaggi,
consentendo a sviluppatori meno esperti di
creare soluzioni Cross-Platform utilizzando
Xamarin.
Negli ultimi due anni, e soprattutto nel 2013,
l’obiettivo principale della società Xamarin è
stato quello di rendere sempre più veloce e di
facile utilizzo il software; di conseguenza, per
soddisfare tutte le richieste degli sviluppatori
sono stati creati strumenti e servizi che comprendono diverse categorie di persone. Alcuni esempi sono: Xamarin Platform, Xamarin
Studio, Xamarin University, Test Cloud, etc.
Xamarin offre un’ampia suite di sviluppo con
diverse soluzioni accessibili ad un costo che
varia a seconda della licenza scelta. Vi è,
tuttavia, un pacchetto Starter con licenza
free che offre delle funzionalità base a chiunque volesse iniziare ad utilizzare Xamarin.
CONDIVISIONE DEL CODICE SECONDO XAMARIN
Il software Xamarin, tramite la suite Xamarin Studio, permette di condividere una buona
parte del codice tra le principali piattaforme di sviluppo sfruttando le API native. Secondo la
politica di Xamarin Studio, la condivisione del codice è di fondamentale importanza per poter
separare l’applicazione in diversi strati.
È necessario, quindi, considerare degli aspetti principali al fine di ottenere una ben precisa
condivisione del codice.
In particolare, consideriamo i sei seguenti aspetti principali:
• il design pattern Model-View — ViewModel (MVVM);
• strategie di organizzazione del progetto;
• librerie di classi portabili;
• utilizzo di istruzioni per il preprocessore;
• semplificazione dell’iniezione di dipendenza;
• implementazione dell’inversione di controllo.
Nel seguito di questo paragrafo verranno analizzate in dettaglio questi sei aspetti principali.
Carlo Iannò |
23
IL DESIGN PATTERN MODEL-VIEW—VIEWMODEL
Il Model-View—ViewModel (MVVM) è un modello di progettazione che è stato originariamente inventato per Windows
Presentation Foundation (WPF) e, successivamente, adottato da Xamarin per separare l’interfaccia utente dalla logica di business e sfruttare appieno il cosiddetto Data Binding, ossia stabilire una connessione tra UI e business logic.
Con questo modello l’architettura delle applicazioni ha uno strato di ViewModel distinto
che non ha dipendenze da nessuna interfaccia utente; questo consente di organizzare il
codice in modo da permettere la modifica di singole parti senza influire sulle altre. Tale
approccio offre numerosi vantaggi come la possibilità di adottare uno stile di codifica
iterativo e basato sull’esplorazione, il supporto della collaborazione in team, etc.
Le applicazioni basate sul modello MVVM sono suddivise nei seguenti livelli:
• Model. Include tutto il codice che implementa la logica di base dell’applicazione e definisce i tipi di codice necessari per modellare il dominio. È completamente indipendente
dalla View e dai livelli del ViewModel.
• View. Definisce l’interfaccia utente tramite un markup dichiarativo. Il data binding definisce la connessione fra componenti specifici dell’interfaccia utente e i vari membri del
ViewModel.
• ViewModel. Fornisce le destinazioni del data binding per la View. In molti casi il
ViewModel espone direttamente il Model e fornisce membri che eseguono il wrapping
di membri specifici del Model. Il ViewModel può anche definire membri che consentono
di tenere traccia dei dati rilevanti per l’interfaccia utente, ma non per il Model, ad esempio l’ordine di visualizzazione degli elementi di un elenco.
24|Carlo Iannò
La figura seguente mostra il design pa ern MVVM:
STRATEGIE DI ORGANIZZAZIONE DEL PROGETTO
Le applicazioni possono fare riferimento solo a librerie di classi consentite da Xamarin, ad
esempio per progetti specifici delle piattaforme iOS o Android bisogna utilizzare le librerie di
classi Xamarin.iOS o Xamarin.Android.
Una soluzione ammessa da Xamarin Studio per gestire in comune il codice ed avere progetti
comuni per ogni piattaforma è quella di adoperare delle strategie per la creazione di una soluzione Cross-Platform.
In tale contesto è possibile considerare tre strategie principali, ciascuna con i suoi vantaggi e
svantaggi:
• File di collegamento. Questa strategia si basa su una semplice libreria di classi .NET 4.0
o .NET 4.5, la quale contiene tutto il codice condiviso. Si potrebbe, quindi, avere un nuovo progetto, e quindi l’applicazione desiderata su ogni piattaforma specifica. È possibile
avere una sottodirectory con tutti i file collegati alla libreria della prima classe.
◊ Vantaggio: approccio molto flessibile. È possibile scegliere di collegare o meno
alcuni file; inoltre, è possibile fare riferimento a diverse librerie su Android rispetto
a iOS.
◊ Svantaggio: si deve gestire l’esistenza di un file in tre progetti, come la libreria di
base, iOS e Android. Potrebbe rallentare di molto il lavoro del team, soprattutto
se si tratta di un’applicazione di grandi dimensioni.
Carlo Iannò |
25
• Clonare file di progetto. È molto simile al file di collegamento, con la differenza principale che si
dispone di una libreria di classi per ogni piattaforma, oltre a quella principale relativa al del
progetto. I file possono facilmente essere aggiunti anche senza collegamento.
◊ Vantaggio: approccio molto flessibile come file di collegamento; non c’è bisogno di
collegare manualmente i file.
◊ Svantaggio: si deve garantire l’esistenza di un file in tre progetti.
• Librerie di classi portabili. Approccio ottimale; si inizia creando una libreria di classi portabile
(PCL), o meglio, il progetto per tutto il codice in comune. Si tratta di un particolare tipo di
progetto che consente a più piattaforme di fare riferimento ad esso e di utilizzare il più piccolo
sottoinsieme di C# e .NET disponibile su ogni piattaforma. In altre parole ogni progetto specifico per la piattaforma farebbe riferimento direttamente a questa libreria.
◊ Vantaggio: tutto il codice è condiviso in un progetto, e tutte le piattaforme utilizzano la stessa libreria. Questo è l’approccio ottimale e più comodo per raggiungere la
maggior parte delle applicazioni Cross-Platform.
◊ Svantaggi: non è possibile fare riferimenti a librerie differenti su ogni piattaforma. Si
potrebbe anche essere limitati ad un sottoinsieme di.NET in base al numero di piattaforme di destinazione.
LIBRERIE DI CLASSI PORTABILI
Una libreria di classi portabili (PCL) è
un progetto di libreria C# che può
essere supportato su più piattaforme,
tra cui iOS, Android, Windows. Un
esempio potrebbero essere le applicazioni di Windows Store, Silverlight e
Xbox 360.
Tale libreria è considerata una soluzione da parte di Microsoft per semplificare lo sviluppo tra
le diverse versioni di .NET framework. Xamarin ha aggiunto anche il supporto per iOS e Android nelle versioni più recenti dei loro prodotti. Molte soluzioni Cross-Platform sono basate
sulla libreria di classi portabile; alcuni esempi sono: JSON, MVVM Cross, etc.
26|Carlo Iannò
UTILIZZO DI ISTRUZIONI PER IL PREPROCESSORE
Quando si utilizzano i file di collegamento, o file di progetto clonati uno degli strumenti più
potenti è l’uso di istruzioni per il preprocessore. Se non si ha familiarità con tali strumenti, C#
ha la capacità di definire le variabili del preprocessore utilizzando #if IPHONE e #if !
IPHONE.
Un semplice esempio potrebbe essere quello mostrato in figura:
In Xamarin Studio è possibile definire le variabili del preprocessore all’interno delle impostazioni del progetto in fase di costruzione. È, inoltre, possibile definire queste variabili nella parte
superiore di qualsiasi file C# dichiarando #define IPHONE; tuttavia tali variabili saranno
applicate solo all’interno del file C#.
L’utilizzo di istruzioni per il preprocessore non è normalmente la soluzione migliore per lo
sviluppo multipiattaforma. Esse sono generalmente più utilizzati in semplici funzioni, perché,
altrimenti, il codice potrebbe diventare molto difficile da leggere, con molte dichiarazioni #if
e #else.
Una migliore soluzione consiste nell’utilizzo di eredità o interfacce quando si ha una classe che
fa riferimento a più piattaforme specifiche.
Carlo Iannò |
27
SEMPLIFICARE L’INIEZIONE DI DIPENDENZA
Il concetto è nato dai principi di progettazione Object-Oriented Single Open Liskov Interface
Dependency (SOLID), ossia un insieme di regole di ricerca. Si tratta di un modello di progettazione volto a rendere il codice del progetto, e quindi l’interno dell’applicazione, più flessibile, così da poter scambiare alcune funzioni in caso di necessità.
L’idea è quella di creare delle dipendenze tra le classi in un’applicazione così che ogni classe
interagisca solo con un’interfaccia o libreria base / classe astratta. Tutto ciò dà la libertà di
ignorare i diversi metodi su ogni piattaforma quando stiamo compilando funzionalità native.
IMPLEMENTAZIONE DI INVERSIONE DI CONTROLLO
L’inversione di controllo (IOC) è un modello di progettazione che serve per completare l’iniezione di dipendenza; in altre parole, è una tecnica di programmazione orientata agli oggetti
in cui l’accoppiamento tra gli oggetti è realizzato a runtime.
Il principio di base è che molti degli oggetti creati in tutta l’applicazione sono gestiti e creati
da una singola classe; invece di utilizzare i costruttori standard C# per le classi possiamo
utilizzare una classe di service locator, o meglio, una classe di servizio di individuazione.
“Se un oggetto necessita di accedere ad un particolare servizio l'oggetto
stesso si prende la responsabilità di gestirlo, o avendo un diretto riferimento al servizio, o individuandolo con un service locator che gli restituisce un riferimento ad una specifica implementazione del servizio”.
28|Carlo Iannò
GLI STRUMENTI DI XAMARIN
Xamarin ha sviluppato dei prodotti fondamentali per lo sviluppo di applicazioni CrossPlatform: Xamarin Studio (ex MonoDevelop), Xamarin.iOS (ex MonoTouch) e Xamarin.Android (ex Mono per Android). Tali strumenti consentono agli sviluppatori di sfruttare le
librerie native su iOS e Android e sono costruite sul runtime Mono.
Mono è un’implementazione open source di C# e .NET framework. In origine era sviluppato
da Novell per essere utilizzato su sistemi operativi come Linux. Dal momento che iOS e Android adottano la stessa politica di Linux, Novell ha sviluppato MonoTouch e Mono per Android come nuovi prodotti per indirizzare le piattaforme “mobile”.
Ottenere lo sviluppo di applicazioni Cross-Platform può richiedere un certo tempo e, come se
non bastasse, Apple e Google hanno entrambi i propri requisiti di sviluppo sulle rispettive
piattaforme.
Xamarin è stata fondata per concentrarsi completamente su questi strumenti per lo sviluppo
con C# e, basandosi su semplici applicazioni di sviluppo, crea un ambiente migliore per il
Cross-Platform.
È necessario, quindi, considerare alcuni strumenti al fine di migliorare la capacità di programmazione multipiattaforma.
Consideriamo tre strumenti principali:
• XamChat - un Cross-Platform App;
• Servizi Web con notifiche push: Windows Azure;
• Librerie di terze parti e introduzione a Xamarin.mobile.
Carlo Iannò |
29
XAMCHAT - UN CROSS-PLATFORM APP
Il modo migliore per imparare a programmare è quello di
prendere un progetto semplice e concentrarsi sui concetti che
si cerca di apprendere, senza doversi preoccupare di correggere errori, bug, etc.
Per migliorare la comprensione del codice Cross-Platform di Xamarin Studio è necessario
sviluppare una semplice applicazione chiamata XamChat per iOS e Android.
Il concetto è semplice: si tratta, infatti, di un’applicazione di chat che utilizza una connessione Internet standard per lo scambio di messaggi di testo, utilizzando un layout rapido della
domanda e della risposta per scambiare velocemente informazioni e comprendere al meglio
il codice all’interno delle applicazioni.
La seguente figura ne mostra un esempio:
Molte volte, durante lo sviluppo di un’applicazione “mobile”, potrebbe essere necessario
iniziare lo sviluppo dell’applicazione prima del previsto; una soluzione potrebbe essere quella
di servirsi di un servizio Web Back-end in modo tale da prevenire l’arresto completo di un’applicazione e sviluppare una versione finta del servizio.
Poiché la comunicazione con un servizio Web può essere un processo lungo è sempre consigliato l’utilizzo di una particolare classe detta Task<T> per le operazioni di login, register,
AddFriend, sendMessage, etc.
30|Carlo Iannò
Un’importanza fondamentale è assunta dal livello ViewModel; esso sarà responsabile della
presentazione di ciascuna operazione dell’interfaccia utente, della validazione dell’input, etc.
A questo punto sarebbe una buona idea includere la classe ServiceContainer e permettere ad essa di interagire con il livello del ViewModel così da sostenere l’iniezione di
dipendenza e l’inversione di controllo.
Si potrebbe utilizzare un’altra libreria e scrivere una classe base per tutti gli strati del
ViewModel all’interno del progetto; questa classe ha sempre la funzionalità comune a tutte
le classi ed è una buona soluzione per mettere alcune parti del codice che vengono utilizzati
da tutti i metodi delle classi. Esempi di metodi che appartengono a tali classi sono: le variazioni di notifica, i metodi o le istanze simili, etc.
La classe BaseViewModel è una classe ideale per inserire qualsiasi funzionalità comune
che si ha intenzione di riutilizzare in tutte le applicazioni. Ad esempio, per l’applicazione
XamChat, abbiamo solo bisogno di implementare alcune funzionalità per indicare se il livello
ViewModel è occupato. È necessario utilizzare una proprietà e un evento che l’interfaccia
utente sarà in grado di registrare e visualizzare un indicatore di attesa sullo schermo.
Carlo Iannò |
31
SERVIZI WEB CON NOTIFICHE PUSH: WINDOWS AZURE
Applicazioni “mobile” sono definite dalla connettività di rete. Un’applicazione “mobile” che
non interagisce con un server Web è molto rara e, ma allo stesso tempo, risulterebbe molto
noiosa da utilizzare.
Utilizzando la piattaforma Cloud Windows Azure possiamo implementare un Back-end lato
server e dimostrare come interagiscono le applicazioni come, per esempio, XamChat, che
utilizza una funzionalità denominata Azure Mobile Services, la quale ha il vantaggio di avere
le notifiche push incorporate. L’applicazione sarà in grado di comunicare con un Web Server
e permetterà ai suoi utenti di interagire fra loro.
Windows Azure è una piattaforma cloud eccellente; è stata rilasciata da Microsoft nel 2010
con lo scopo di favorire la costruzione di moderne applicazioni Web e servizi. Ciò significa
che fornisce l’accesso alle macchine virtuali all’interno delle quali è possibile installare qualunque sistema operativo o software. Azure fornisce anche strumenti multipiattaforma per
la creazione di applicazioni, come i siti Web Azure e SQL Azure.
I servizi forniti da Windows Azure e più comunemente utilizzati sono:
• Macchine Virtuali. Azure consente l’accesso a tutte le macchine virtuali e permette di
installare qualsiasi sistema operativo a scelta dello sviluppatore.
• Siti Web. È possibile eseguire qualsiasi tipo di sito Web in Microsoft Internet Information
Services (IIS)
• SQL Azure. Si tratta della versione Cloud-Based di Microsoft SQL Server utilizzata per
la memorizzazione dei dati.
32|Carlo Iannò
• Servizi “mobile”. È una piattaforma semplice per la creazione di servizi Web per applicazioni “mobile”. Utilizza SQL Azure per l’archiviazione back-end e un semplice JavaScript.
• Storage. Azure fornisce un metodo per la memorizzazione di file binari e per la memorizzazione delle tabelle; si tratti di una soluzione NoSQL per la persistenza dei dati.
• Servizi bus. Si tratta di una soluzione basata sul cloud per la creazione di code per facilitare la comunicazione tra gli altri servizi cloud. Comprende anche la notifica hub come
un modo semplice per fornire le notifiche push per le applicazioni “mobile”.
• Servizi cloud. Permette di raggruppare più servizi insieme e creare ambienti di produzione. Si tratta di un ottimo strumento per la distribuzione di software.
Windows Azure è una piattaforma cloud Microsoft; si tratta di una raccolta in continua crescita di servizi integrati per calcolo, archiviazione dati, rete e App. Tali servizi permettono di
essere più veloci, più efficienti e di risparmiare tempo e denaro.
Azure è un’importante piattaforma cloud classificata da Gartner come leader del settore per
Infrastructure-as-a-Service (IaaS) e Platform-as-a-Service (PaaS). Questa combinazione
avanzata di servizi gestiti e non gestiti consente di creare, distribuire e gestire applicazioni in
maniera autonoma e indipendente al fine di ottenere una produttività impareggiabile. Azure
supporta qualsiasi sistema operativo, linguaggio, strumento e framework, da Windows a
Linux, da SQL Server a Oracle, da C# a Java.
Esistono altri fornitori di servizi concorrenti di Windows Azure; alcuni esempi sono:
• Parse. Questo servizio fornisce un prodotto simile a quello di Azure “mobile” Service,
completo di memorizzazione dei dati e notifiche push.
• Urban Airship. Questo servizio fornisce le notifiche push per le applicazioni “mobile” su
più piattaforme.
• Amazon Web Services. Questo servizio è una soluzione cloud completa equivalente a
Windows Azure. Ha tutto il necessario per la distribuzione di applicazioni in cloud con il
totale supporto della macchina virtuale.
Carlo Iannò |
33
LIBRERIE DI TERZE PARTI E INTRODUZIONE A
XAMARIN.MOBILE
Xamarin supporta dei sottoinsiemi del framework .NET
e, per la maggior parte, include le API standard che si
trovano nelle librerie di classi di base.
Gran parte delle librerie open source di C# possono essere utilizzate da Xamarin; inoltre, se un
progetto non possiede al proprio interno una libreria di classi portabili, spesso, grazie all’uso di
Xamarin, la portabilità del codice viene effettuata automaticamente in maniera estremamente
semplice. Xamarin supporta, anche, linguaggi di programmazioni nativi come, per esempio, Objective-C e librerie Java.
Per aggiungere componenti di terze parti al progetto bisogna servirsi di Xamarin Component
Store. Esso rappresenta il negozio dove poter acquistare o installare semplicemente componenti
di terze parti; spesso, però, tali componenti hanno un costo di acquisto dalle poche decide di dollari fino ad arrivare a qualche migliaio di dollari. Un esempio di componenti di terze parti è rappresentato nella seguente figura:
Ci sono più di cento componenti disponibili per migliorare le applicazioni “mobile”; basta selezionare il componente di proprio interesse al seguente link www.components.xamarin.com/.
Ogni componente è completo di esempi, video dimostrativo, recensioni e altre informazioni delle
quali si ha bisogno prima di acquistarlo.
34|Carlo Iannò
Alcune delle caratteristiche più importanti
utilizzate dalle applicazioni “mobile” di oggi si
basano sui nuovi tipi di dati che possono essere acquisiti dai nostri dispositivi.
Caratteristiche come la posizione Global Positioning System (GPS) e l’utilizzo della fotocamera sono punti di forza per alcune applicazioni, come, per esempio, Istagram, Twitter, etc.
È difficile sviluppare applicazioni e non utilizzare alcune caratteristiche che i dispositivi offrono; è, quindi, necessario esplorare le opzioni per poter utilizzare queste nuove caratteristiche
con Xamarin.
Per semplificare lo sviluppo di queste caratteristiche su più piattaforme, Xamarin ha sviluppato una libreria chiamata Xamarin.Mobile. Essa offre una singola API per accedere ai contatti, alla posizione GPS, alla direzione cardinale, alla macchina fotografica, ad un album di
foto e video, etc.
Tale API si avvale anche di Task Parallel Libraries (TPL) per offrire un moderno C# il quale
rende gli sviluppatori più produttivi rispetto a come lo sarebbero se utilizzassero il codice di
sviluppo nativo.
Grazie alla combinazione di C# e delle API si dà la possibilità agli sviluppatori di scrivere
codice in maniera chiara, pulita e asincrona. Inoltre è possibile utilizzare lo stesso codice
sulle varie piattaforme, come iOS e Android.
Per installare Xamarin.Mobile basta collegarsi al seguente indirizzo
www.components.xamarin.com/ e aggiungere il componente Xamarin.Mobile ad un
progetto, come mostrato nella seguente figura:
Carlo Iannò |
35
PRO E CONTRO E GARTNER MAGIC QUADRANT
Il Magic Quadrant sviluppato da Gartner, azienda multinazionale
leader nel settore della consulenza strategica, dell’analisi e della
ricerca nel campo dell’Information Technology (IT), fornisce
un’analisi delle performance dei vendor (fornitori) appartenenti
ad un determinato settore di mercato.
L’obiettivo principale è informare agli acquirenti di servizi e prodotti sulle aziende partner che
meglio soddisfano le loro esigenze.
Di seguito, possiamo analizzare la posizione di Xamarin sul Magic Quadrant di Gartner:
36|Carlo Iannò
Tenendo in considerazione gli aspetti priStencipali e gli strumenti di Xamarin valutiamo un
bilancio generale, analizzando alcuni punti positivi e negativi.
• File collegati.
◊ Pro: stesso codice su tutte le piattaforme;
si possono usare le direttive preprocessore;
si può usare codice specifico per le piattaforme.
◊ Contro: si devono gestire più progetti.
• Direttive preprocessore.
◊ Pro: si può inserire codice specifico per
ogni piattaforma.
◊ Contro: codice non molto “pulito”.
• Librerie portabili.
◊ Pro: un’unica libreria per tutte le piattaforme, utilizzo della sola classe disponibile su tutte le piattaforme.
◊ Contro: non si possono usare le direttive
preprocessore; non si può usare codice
specifico per le piattaforme.
• Progetto collegato.
◊ Pro: auto collegamento ai file.
◊Contro: tutti i progetti devono essere nella
stessa soluzione.
CONCLUSIONI
Alla luce dello studio effettuato in questo capitolo si può affermare che per sviluppare applicazioni “mobile” Cross-Platform, è necessario servirsi di software adeguati, che consentono
la massima flessibilità del codice. Come si è potuto vedere in questo capitolo, l’utilizzo del
linguaggio di programmazione C#, combinato alle potenzialità del software Xamarin, migliora nettamente le prestazioni e semplifica il lavoro degli sviluppatori.
Carlo Iannò |
37
38|Carlo Iannò
3. ADOBE PHONEGAP E APACHE CORDOVA
In questo capitolo verrà illustrato il funzionamento dei framework open source Adobe PhoneGap e Apache Cordova. In particolare, verranno elencati i principali aspetti sui quali
sono basati tali framework, definendo innanzitutto il perché vengono utilizzati, le funzionalità offerte, i tool e le tecnologie sui quali sono basati. Successivamente verranno descritti i
pregi e difetti di entrambi i framework e verrà analizzata la loro posizione sul Gartner
Magic Quadrant.
1
Adobe PhoneGap
2
Apache Cordova
1
Carlo Iannò |
39
ADOBE PHONEGAP
PhoneGap è un progetto open source della
Nitobi Software, un’azienda che crea appli‐
cazioni “mobile” e Web application da diversi
anni.
Esso consiste in un insieme di librerie stati‐
che che permettono di sviluppare veloce‐
mente, ed in maniera molto efficace, applica‐
zioni “mobile” che appartengono a diverse
famiglie. La filosofia di base di tale software
consiste nel realizzare lo slogan “Writeonce,
porteverywhere”.
PhoneGap si propone di focalizzare gli sforzi
degli sviluppatori sull'applicazione piuttosto
che perdere tempo ad adattarla ad ogni
piattaforma.
Per poter realizzare un'applicazione con
Phonegap è necessario conoscere HTML,
CSS e JavaScript. Il porting verso le varie
piattaforme viene effettuato installando gli
ambienti di sviluppo relativi e compilando la
WebApp interessata. I requisiti sono quindi
quelli di installare le SDK dove richiesto,
assieme agli strumenti per consentire la
compilazione delle applicazioni.
Adobe Phonegap è disponibile secondo delle
licenze open source; come utente di Phone‐
Gap è possibile scegliere di utilizzare la licen‐
40 |Carlo Iannò
za BerkeleySoftwareDistribution(BSD),
ovvero una licenza che riflette l’idea più
ampia del “dono” inteso in senso liberale, ma
senza la “programmaticità”. Più specificata‐
mente, tale licenza è limitata a “fotografare il
presente”.
Un altro esempio è la licenza Massachusetts
InstituteofTechnology(MIT),ovvero una
licenza che permette il riutilizzo nel
“software proprietario” sotto la condizione
che essa sia distribuita con tale software e
che rispetti le condizioni di utilizzo ed impe‐
dendone altre, come, per esempio, la modifi‐
ca, la condivisione, la ridistribuzione, etc.
Oggi sono disponibili molte applicazioni
commerciali le quali sono state realizzate
tramite PhoneGap; è possibile trovare una
lista di tali applicazioni sul sito Web nella
sezione apps: www.phonegap.com/app.
PERCHÉ PHONEGAP
Sviluppare un'applicazione per tutte le maggiori piattaforme richiede la conoscenza dei
linguaggi delle stesse, l'installazione di IDE (Integrated Development Enviroment) per lo
sviluppo, la presenza di personale con delle competenze specifiche, etc.
La realizzazione di un'applicazione su varie piattaforme richiede, quindi, tempo e denaro, per
reclutare il personale, formarlo se necessario e, preparare gli ambienti di sviluppo per ogni
piattaforma.
A causa delle consistenti risorse da dover mettere in gioco, ciò che alcune aziende fanno è
sviluppare la propria applicazione solo per le piattaforme più utilizzate, o concentrare gli
sforzi sulle piattaforme con meno restrizioni. Ciò, ovviamente, porterebbe a ridurre il poten‐
ziale mercato dell'applicazione, oltre che ad impedire automaticamente agli utenti di altre
piattaforme di utilizzarla.
Grazie a PhoneGap lo sviluppatore può dedicarsi maggiormente allo sviluppo della sua
WebApp senza pensare agli intralci o impedimenti delle varie piattaforme. Chiaramente le
possibilità dell'applicazione saranno limitate a quelle di un’applicazione Web.
Carlo Iannò |
41
COME FUNZIONA
PhoneGap fa da ponte tra il sistema operativo e la WebApp realizzata dallo sviluppatore. Si
intuisce che occorre che dalla WebApp esista una modalità standard per invocare le API nati‐
ve in maniera indipendente dal tipo di piattaforma sottostante.
PhoneGap è, infatti, un framework che permette ad una WebApp di invocare le API native
mediante funzioni JavaScript. Un esempio potrebbe essere visualizzato nella seguente figura:
Il vantaggio nell'utilizzo di questo framework è che esso fornisce l'aggancio tra la piattaforma
native e la WebApp in modo che uno sviluppatore che non ha conoscenze specifiche sui lin‐
guaggi nativi possa dedicarsi allo sviluppo della WebApp con tecnologie standard.
La caratteristica fondamentale di PhoneGap sta nel fatto che, una volta realizzata l'applica‐
zione “mobile”, quest’ultima riesce ad adattarsi a qualunque piattaforma supportata.
PhoneGap userà il linguaggio nativo della piattaforma per accedere alle risorse hardware e
software in modo da aggiungere le funzionalità di base al motore JavaScript e renderle, così,
facilmente utilizzabili dall'applicazione come fossero tradizionali metodi di libreria.
In base alla tipologia di piattaforma con la quale dovrà interfacciarsi, l'implementazione di
aggancio sarà, di conseguenza, sviluppata in Objective C per iPhone, in Java per Android, in
C++ o C# per Windows Phone, etc. Tale implementazione è fornita dallo stesso framework;
in pratica, esiste un runtime basato su WebKit4 che è il motore di browser come Safari e
Google Chrome, in cui vengono iniettate le componenti statiche. Il risultato sarà un pacchet‐
to composto da due elementi principali con differenti responsabilità che operano tra loro per
fornire delle funzioni.
42 |Carlo Iannò
Nel caso specifico il runtime si occupa di dialogare direttamente con il dispositivo; un esempio
di architettura di un’applicazione realizzata con PhoneGap potrebbe essere quella mostrata nel
seguente schema:
Partendo dal basso verso l’alto, si può notare che la parte in blu è quella che riguarda il sistema
operativo della piattaforma nativa. Ad un livello superiore troviamo il framework PhoneGap,
anch’esso fornito insieme alle API JavaScript. Nel sottolivello relativo al framework PhoneGap
troviamo Embedded Browser, il quale incapsula le WebApp (HTML, CSS, JavaScript) e le API
JavaScript.
Ciò è stato fatto per mettere in evidenza che l'oggetto browser può essere aperto all'interno
dell'applicazione che si sta sviluppando e, dunque, dentro PhoneGap. Per comportamento di
default il browser viene aperto esternamente all'applicazione; di conseguenza, ad ogni richie‐
sta di una pagina Web si ha l'apertura del Web browser.
L'apertura di una pagina nell’ Embedded Browser nasconde la barra degli indirizzi nonché i
pulsanti forniti dal browser di default; in questo modo si oscura in parte il fatto che si tratti di
una pagina Web. Ciò è un vantaggio indiscutibile nel rendere l'esperienza più simile a quella di
un'applicazione nativa.
Per cui il pacchetto applicativo destinato alla distribuzione conterrà file statici come HTML,
JavaScript, CSS e le classi native di aggancio. Il pacchetto dovrà essere opportunamente firma‐
to prima di essere distribuito sullo Store ufficiale delle piattaforme di riferimento.
Carlo Iannò |
43
TOOL E TECNOLOGIE UTILIZZATE
Lo sviluppo di un’app richiede la sola conoscenza dei linguaggi come HTML, CSS, JavaScript.
Questi tre linguaggi contribuiscono a creare la struttura della pagina Web (HTML), di perso‐
nalizzarne il suo aspetto (CSS) , di renderla dinamica (ovvero di fare in modo che il contenuto
della pagina venga generato totalmente o parzialmente, al momento della richiesta ) e inte‐
rattiva mediante il codice JavaScript.
Nel seguito consideriamo quattro attori principali nell’ambito di tali tecnologie, ovvero:
• HyperText Markup Language (HTML / HTML5);
• Cascading Style Sheets (CSS);
• JavaScript;
• Application Programming Interface (API).
44 |Carlo Iannò
HyperText Markup Language (HTML)
È il linguaggio predominante delle pagine Web. Per descrive‐
re tali pagine viene usato un sistema di tag. I tag sono costi‐
tuiti da parentesi angolate ( come <html>); il browser è
programmato per riconoscere i tag e la loro funzione; un volta riconosciuti i tag, non li mostra
nella pagina finale ma li utilizza per costruire la pagina. E' possibile inserire immagini, oggetti,
creare moduli interattivi, etc. Esistono tag per strutturare il documento con link, intestazioni,
liste, paragrafi e altri elementi.
E' possibile inserire all'interno del codice della pagina altri linguaggi attivi; ad esempio, si può
incorporare del codice JavaScript o utilizzare altri linguaggi più “server‐side”, come Personal
Home Page (PHP) o JavaServer Pages (JSP) per svolgere compiti più complessi. Mediante tali
linguaggi è possibile creare pagine Web con contenuto dinamico con l'utilizzo di codice Java
incluso nella pagina HTML.
Una variante, molto innovativa rispetto all’HTML classico è HTML5; inizialmente, fino alla
versione HTML4, nonché per creare una pagina Web era necessario utilizzare moltissimi tag
<div >..</div> gli attributi id oppure class, per indicare la loro funzione, e caratteriz‐
zarli nel file CSS.
Uno schema di una pagina strutturata con HTML4è il seguente:
Con l’evoluzione di HTML, e quindi con HTML5, nonostante quest’ultimo linguaggio presenti le
stesse separazioni concettuali, possiamo notare che gli attributi vengono rappresentati dai tag
stessi.
Carlo Iannò |
45
Il markup per la pagina HTML5 è strutturato nel seguente modo:
Tale markup fa riferimento alla seguente struttura:
Una tale forma consente allo standard di essere retro compatibile, evitando scelte difficili agli
sviluppatori Web. Oltre a questi cambiamenti nella struttura della pagina, vengono messi a
disposizione alcuni tag aggiuntivi per gestire multimedialità e personalizzazione delle pagine.
Un esempio potrebbero essere i seguenti tag:
•
<canvas>; esso mette a disposizione uno spazio rettangolare di dimensione personaliz‐
zabile all’interno del quale è possibile disegnare a piacere qualunque tipo di forma,
immagine, animazione, etc. La creazione delle illustrazioni avverrà tramite primitive
JavaScript.
•
<audio> <video>; mediante questi tag è possibile includere e controllare conte‐
nuti multimediali. Tutto ciò era già possibile tramite Adobe Flash, ma ora, mediante
JavaScript, è possibile gestire i file multimediali senza appesantire la pagina.
46 |Carlo Iannò
Cascading Style Sheets (CSS)
È un linguaggio che definisce lo stile, la formattazione e l'a‐
spetto di un documento scritto in un linguaggio di markup.
E' più comunemente usato assieme alle pagine Web scritte in HTML, ma può anche essere
applicato ai documenti eXtensible Markup Language (XML).
Il linguaggio definisce i comportamenti visivi di una pagina Web. Ad ogni elemento della pagina
viene associata una serie di comandi che modicano l'aspetto dell'elemento stesso. e il suo com‐
portamento all'interno della pagina. L'intero codice porta alla creazione di uno script che viene
associato alla pagina stessa e definisce l'aspetto degli elementi in base ad alcune azioni dell'u‐
tente (spostamenti del mouse sopra elementi della pagina, click di alcuni elementi, etc).
Un file CSS definisce il posizionamento, la colorazione, il comportamento del testo, degli ele‐
menti, e delle immagini.
Mentre l'autore di un documento tipicamente associa quest’ultimo ad uno specifico CSS, i
lettori possono utilizzare un foglio di stile proprio e sovrascrivere quello che il proprietario ha
specificato. Le specifiche del CSS sono aggiornate dal World Wide Web Consortium (W3C) che
gestisce gli standard per le WebApp “mobile”.
Carlo Iannò |
47
JavaScript
JavaScript è un linguaggio di programmazione interpretato con un
rudimentale orientamento agli oggetti. Il suo ibiettivo è quello di
consentire l'inserimento di contenuto eseguibile in una pagina
Web. Ciò vuol dire che una pagina Web non presenta solo codice HTML classico, di tipo stati‐
co, ma può includere programmi dinamici che interagiscono con l'utente, controllano il brow‐
ser e creano dinamicamente contenuti HTML.
JavaScript può ottenere informazioni dall’utente e dal browser stesso; inoltre, può interagire
con l’utente per migliorare l’esperienza durante la navigazione. Per esempio può nascondere,
mostrare o alterare le proprietà e gli attributi associati a particolari elementi della pagina.
Un notevole esempio di JavaScript può essere la funzionalità del pulsante “indietro”, il quale
si trova in qualunque browser e ci permette di tornare alla pagina esattamente precedente a
quella visitata.
Un problema abbastanza noto che uno sviluppatore riscontra praticamente quando utilizza il
codice JavaScript è legato alla velocità. A chiunque è sicuramente capitato di provare ad
aprire una pagina Web ricca di contenuti e notare del ritardo nella visualizzazione di quelli
multimediali: spesso è a causa dell'uso pesante di codice JavaScript per la gestione di anima‐
zioni, navigazione, dinamicità della pagina. Lo stesso problema si è riscontrato nello sviluppo
con PhoneGap; pagine contenenti molto codice JavaScript tendono a essere lente nel carica‐
mento, soprattutto se pensiamo che a fare il rendering della pagina è il browser di un disposi‐
tivo “mobile”. Il problema è stato riscontrato sui vari dispositivi , in forma più o meno accen‐
tuata.
Tuttavia, è possibile eseguire un test per calcolare un bilancio complessivo del dispositivo e
per conoscere la velocità di esecuzione di codice JavaScript: è sufficiente collegarsi al seguen‐
te indirizzo: https://www.webkit.org/perf/sunspider/sunspider.html
48 |Carlo Iannò
Di seguito vengono illustrati due Report Benchmark eseguiti sui principali dispositivi “mobile” e
i principali browser che consentono l’esecuzione di codice JavaScript.
Carlo Iannò |
49
Application Programming Interface (API)
Il progetto Phonegap è sempre in via di sviluppo; la documentazio‐
ne sulle API è aggiornata costantemente.
Le funzionalità disponibili al momento, in base alla piattaforma utilizzata, sono illustrate
nella seguente figura:
Tale tabella ci aiuta ad avere un'idea di cosa è supportato e su che piattaforma; tuttavia, il
sito ufficiale ricorda che aggiornamenti più frequenti sono presenti al seguente link:
https://github.com/phonegap/phonegap/wiki
50 |Carlo Iannò
PROGETTI ASSOCIATI E GARTNER MAGIC QUADRANT
Per aiutare a migliorare l'applicazione finale occorre, inoltre, che esistono dei progetti che
nello sviluppo possono tornare utili. Esistono vari strumenti utili che possono facilitare il
lavoro dello sviluppatore. Un esempio di tali tool può essere visualizzato sul sito ufficiale al
seguente link: http://phonegap.com/tool/
Sono presenti framework JavaScript, API per lo sviluppo di giochi JavaScript, tool per dise‐
gnare widget. Alcuni di questi strumenti si sono rilevati utili; altri sono, comunque, degni di
attenzione.
Di seguito un elenco di tool che hanno riscosso maggiore successo:
XUI. Framework JavaScript particolarmente stringato. E' utile per realizzare applicazioni per i
browser più prestanti.
Sencha/Sencha animation.Permette lo sviluppo di applicazioni Web che sembrano native per
iPhone e Android.
JQuerymobile. Promette di fornire un'interfaccia utente unificata ad applicazioni Web per ogni
tipo di piattaforma “mobile”.
Ripple. Fornisce, mediante un'aggiunta a Google Chrome, il supporto per il testing della pagina
realizzata su dispositivi “mobile”. E' possibile visualizzare l’anteprima della pagina su diversi
tipi di schermi simulati da questa applicazione.
JQTouch. Plugin per JQuery per lo sviluppo Web su iPhone e iPodTouch.
Carlo Iannò |
51
Nel seguito indichiamo in rosso la posizione di Adobe PhoneGap nel Magic Quadrant di Gart‐
ner di cui si è discusso nel Capitolo 2.
52 |Carlo Iannò
APACHE CORDOVA
Apache Cordova (come il suo predecessore
Adobe PhoneGap), rappresenta un set di
API che permette a uno sviluppatore di
applicazioni “mobile” di accedere alle fun‐
zioni native dei dispositivi, come, ad esem‐
pio la fotocamera, l’accelerometro, le coor‐
dinate GPS, il File System, etc.
Grazie all’uso combinato di codice Java‐
Script e al framework UI come, ad esempio,
JQuery Mobile, fa si che l’applicazione ven‐
ga generata semplicemente con l’uso di
HTML, CSS e JavaScript, seguendo il tradi‐
zionale approccio delle applicazioni Web.
In altre parole, seguendo il tradizionale
approccio, Apache Cordova si occuperà di
tradurre un’applicazione Web in un’applica‐
zione “mobile”.
dispositivi diversi non comporti, se non in
minima parte, la necessità di modifiche al
codice.
Cordova, come anticipato, fornisce, quindi,
un set di librerie JavaScript che possono
essere invocate. Ogni chiamata verrà, poi,
tramutata dal framework nella relativa
chiamata in codice nativo in base al disposi‐
tivo di utilizzo. Il risultato di tale operazione
è un’informazione che risulterà essere uni‐
forme, indipendentemente dalla piattafor‐
ma di utilizzo, e che metterà lo sviluppatore
in condizione di disinteressarsi di quale sia
l’effettivo dispositivo di utilizzo finale.
Apache Cordova è disponibile per le seguen‐
ti piattaforme: iOS, Android, Blackberry,
Windows Phone, Palm WebOS, Bada e
Symbian.
Utilizzando le API di Cordova, l’applicazione
potrà essere utilizzata senza la necessità di
conoscere, e quindi di dover utilizzare, il
codice nativo (Objective‐C, Java, etc). Cor‐
dova si basa su tecnologie Web, solitamente
situate sul dispositivo stesso e non su un
server remoto. È proprio l’adozione di
HTML, CSS e JavaScript che rappresenta la
garanzia che l’applicazione sia a tutti gli
effetti, multipiattaforma e che il porting su
Carlo Iannò |
53
FUNZIONALITÀ OFFERTE
Le funzionalità di Cordova prevedono praticamente tutte le interazioni possibili con tutti i
dispositivi di ultima generazione e non.
Di seguito verranno definite tutte le classi di funzionalità che è possibile richiamare; successi‐
vamente, verranno illustrati alcuni esempi pratici delle principali funzionalità:
•
Accelerometro. Cattura il movimento del dispositivo misurando la sua accelerazione lungo
le direzioni x, y e z.
•
Camera. Permette l’accesso alla fotocamera, dà la possibilità di salvare l’immagine come
file oppure di ottenerla con codifica base64 (codifica utilizzata per la trasmissione trami‐
te chiamate HTTP). Per la maggior parte delle piattaforme dà anche la possibilità di
accedere alle immagini già presenti nella libreria fotografica del dispositivo.
•
Cattura. Più generico del precedente oggetto camera, permette l’acquisizione di file multi‐
mediali di tipo audio, immagine o video. E’ possibile specificare diversi formati di acqui‐
sizione.
•
Connessione. Fornisce informazioni sulla connettività attuale: se non è presente, se è di
tipo ethernet, WiFi, 2G, 3G o 4G.
•
Contatti. Consente di accedere alle informazioni relative ai contatti, di crearne nuovi o di
modificarli.
•
Device. Fornisce informazioni hardware e software del dispositivo in uso.
•
Eventi. Permette di gestire diversi tipi di eventi come, ad esempio, dispositivo pronto
(framework Cordova completamente caricato), pausa (quando l’applicazione va in
background), online (quando è stata rilevata la connettività), offline (quando è stata
rilevata la mancanza di connettività), pressione tasto back (se presente), rilevato livello
critico di batteria, basso livello batteria, rilevata pressione di pulsanti hardware, etc.
•
File. Permette l’accesso al File System; è possibile leggere e scrivere dai file e cartelle,
eseguirne l’upload online e ottenere i metadati.
54 |Carlo Iannò
•
Geolocalizzazione.Permette l’accesso al sensore Global Position System (GPS) e, quin‐
di, di rilevare la posizione corrente del dispositivo che corrisponderà alle coordinate
fornite dal sensore (se presente) o calcolate in base alle specifiche W3C delle API di
geolocalizzazione (in caso di asssenza). Le coordinate vengono restituite sotto forma di
latitudine e longitudine.
•
Globalizzazione. Permette di avere informazioni circa la lingue e le impostazioni interna‐
zionali correnti (lingua attuale, separatore migliaia, decimali, formato per la data, etc).
•
Notifiche.Permette di eseguire azioni di notifica, come la visualizzazione di messaggi
(alert), la vibrazione, la presenza di suoni. A tal fine utilizza audio e grafica native del
dispositivo utilizzato.
•
Archiviazione.Permette l’utilizzo dello storage del dispositivo basandosi sulla specifica
W3C dei Database SQL Web.
Carlo Iannò |
55
Consideriamo alcuni esempi delle principali funzionalità sopra elencate:
•
Geolocalizzazione.Ottenerelecoordinatecorrenti.Attraverso l’oggetto navigator.geolocationsi ha accesso a tutti i metodi e a tutte le informazioni sulla geolo‐
calizzazione del dispositivo. Per ottenere le coordinate è sufficiente richiamare il suo
metodo getCurrentPosition con i parametri relativi alle funzioni di “callback”
specifici per la tipologia di esito. Queste funzioni verranno, quindi, richiamate al termi‐
ne dell’acquisizione delle informazioni geografiche e, in caso di esito positivo, verrà
trasmesso un oggetto position con tutte le informazioni ricavate. Un esempio è
mostrato nella seguente figura:
function onSuccess(position){
var element = document getElementById(‘geolocation’);
element.innerHTML = ‘Latitude:’+position.coords.latitude+‘<br/>’+;
‘Longitude:’+position.coords.longitude+‘<br/>’+;
‘Altitude:’+position.coords.altitude+‘<br/>’+;
‘Accuracy:’+position.coords.accuracy +‘<br/>’+;
‘Heading:’+position.coords.heading+‘<br/>’+;
‘Speed:’+position.coords.speed+‘<br/>’+;
‘Timestamp:’ +position.coords.timestamp +‘<br/>’;
}
// onError Callback receives a PositionError object
Function onError(error){
alert(‘code:’ +error.code +‘\n’+‘message:’+error.message+‘\n’);
•
Camera:scattareunafoto.L’oggetto “navigator.camera”dà pieno accesso all’integra‐
zione con la fotocamera o, in alternativa, con la galleria di immagini presenti nel dispo‐
sitivo. All’interno della funzione “getPhoto” viene richiamata la funzione “getPicture”. A
questa funzione vengono passate le funzioni di “callback”,in caso di successo o di erro‐
re, e un oggetto contenente informazioni circa la qualità della foto desiderata, il forma‐
to dell’output (si può scegliere tra ottenere la stringa del percorso del file salvato o
l’intera immagine sotto forma di stringa ) e la sorgente (la fotocamera stessa o la galle‐
ria di immagini). Un esempio è mostrato nella seguente figura:
document.addEventListener
(“deviceready”,onDeviceReady,false);
function onDeviceReady(){
pictureSource=navigator.camera.PictureSourceType;
destinationType=navigator.camera.DestinationType;
}
//Called when a photo is succefully retrieved
56 |Carlo Iannò
•
File–Uploaddiunafotoestrattadallalibreriasuunserver.Apache Cordova dà la
possibilità di caricare un file su un server Web opportunamente configurato per ricever‐
lo. Ciò avviene attraverso l’oggetto “FileTransfer”. Ciò avviene, ad esempio, quando
viene selezionata un’immagine dalla galleria (metodo navigator.camera.getPicture) e,
successivamente, essa viene inviata a un server Web all’interno della funzione
“uploadPhoto”. Si noti che tale funzione è, appunto, indicata all’interno del metodo
“getPicture” per essere richiamata in caso di successo dell’acquisizione dell’immagine. Il
metodo “ft.upload” permette, quindi,l’invio dell’immagine con la possibilità di associare
parametri arbitrari al trasferimento del file. Un esempio è mostrato nella seguente
figura:
navigator.camera.getPicture(uploadPhoto,
function(message){alert(‘get picture failed’);},
{quality:50,
destinationType: navigator.camera.DestinationType.FILE_URI,
sourceType: navigator.camera.PictureSourceType.PHOTOLIBRARY};
function uploadPhoto(imageURI){
var options=new FileUploadOptions();
options.fileKey=“file”;
options.fileName=imageURI.substr(imageURI.lastIndexOf(‘/’)+1);
options.mimeType=“image/jpeg”;
var params=();
params.value1=“test”;
params.value2=“param”;
Carlo Iannò |
57
TOOL E TECNOLOGIE UTILIZZATE
Apache Cordova come il suo predecessore Adobe PhoneGap, suddivide i tool di sviluppo in
due diverse tecnologie, ovvero Tecnologie Client-Side e Tecnologie Server-Side.
Tecnologie Client-Side
Le tecnologie Client-Side di interesse sono le seguenti:
• JavaScript.A differenza di altri linguaggi, quali C o Java, che permettono la scrittura
di programmi completamente stand-alone, JavaScript viene utilizzato soprattutto
in quanto linguaggio di scripting, integrato, quindi, all'interno di un altro programma. L'idea di base è che il programma ospite (quello che ospita ed esegue lo script)
fornisca allo script un'API ben definita; tale API consente l'accesso ad operazioni
specifiche la cui implementazione è a carico del programma ospite stesso. Lo script,
quando eseguito, utilizza riferimenti a questa API per richiedere (al programma
ospite) l'esecuzione di operazioni specifiche, non previste dai costrutti del linguaggio JavaScript. In effetti, questo è esattamente lo stesso meccanismo che viene
adottato anche in un linguaggio quale C o Java, nel quale il programma si affida a
delle librerie, non previste dal linguaggio in sé, che permettono di effettuare operazioni quali l'I/O o l'esecuzione di chiamate a funzioni di sistema.
• AJAX.Acronimo di Asynchronous JavaScript and XML, è una tecnica di sviluppo per
la realizzazione di applicazioni Web interattive. Lo sviluppo di applicazioni HTML
con AJAX si basa su uno scambio di dati in background fra Web browser e server,
che consente l'aggiornamento dinamico di una pagina Web senza esplicito ricaricamento da parte dell'utente. AJAX è asincrono nel senso che i dati extra sono richiesti al server e caricati in background senza interferire con il comportamento della
pagina esistente. Normalmente le funzioni richiamate sono scritte in linguaggio
JavaScript. Tuttavia, e a dispetto del nome, l'uso di JavaScript e di XML non è obbligatorio, come non è necessario che le richieste di caricamento debbano essere
necessariamente asincrone. AJAX è una tecnica multipiattaforma utilizzabile su
molti sistemi operativi, architetture informatiche e browser Web. Esistono numerose implementazioni open source di librerie e framework come, ad esempio, XHTML
e CSS, per il markup e lo stile, DOM, per mostrare le informazioni e interagire, e
l’oggetto XMLHttpRequest, per l'interscambio asincrono dei dati tra il browser
dell'utente e il Web server.
58 |Carlo Iannò
• jQuery Mobile.Basato su jQuery, jQuery Mobile è un progetto molto giovane, ma
offre una buona stabilità ed un numero di funzionalità adeguate per sviluppare
applicazioni Web “mobile” complete. Gli sviluppatori di jQuery Mobile hanno ben
presente che offrire la stessa esperienza utente e le stesse funzionalità al mondo
dei dispositivi “mobile” è un’impresa pressoché impossibile, sia per le peculiarità
hardware di ogni dispositivo (dimensioni dello schermo, potenza del processore),
sia per la difficoltà nell’aggiornare il software, almeno per gli utenti con delle cono‐
scenze tecniche basse. Proprio per questo hanno scelto un approccio basato in
gruppi di dispositivi i quali vengono raggruppati in base ai diversi livelli di suppor‐
to. In questo modo, quelli più avanzati fruiranno di un’esperienza e di un’interfac‐
cia più ricca di quelli più obsoleti; tuttavia ambedue potranno comunque usufruire
dei contenuti e delle funzionalità offerte dall’applicazione. Sul sito ufficiale di
jQuery Mobile è disponibile una griglia aggiornata all’ultima versione della libreria
nella quale verificare il tipo di supporto offerto.
Tecnologie Server-Side
•
Apache Tomcat.Implementa le specifiche JavaServer Pages (JSP) e Servlet di Sun Mi‐
crosystems, fornendo, quindi, una piattaforma per l'esecuzione di applicazioni Web
sviluppate nel linguaggio Java. La sua distribuzione standard include anche le funziona‐
lità di Web server tradizionale, che corrispondono al prodotto Apache. Tomcat è rila‐
sciato sotto la Licenza Apache, ed è scritto interamente in Java; può, quindi, essere
eseguito su qualsiasi architettura su cui sia installata una Java Virtual Machine (JVM).
Tomcat presenta una serie di componenti sui quali si basa. Un gruppo di componenti
potrebbe essere costituito da: Catilina che è il contenitore di servlet Java, Coyote, che è
il componente "connettore HTTP", e Jasper, che è il motore JSP.
•
PostgreSQL.È un DBMS relazionale ad oggetti completo rilasciato con licenza free.
PostgreSQL usa il linguaggio SQL per eseguire delle query sui dati. Questi sono conser‐
vati come una serie di tabelle con chiavi esterne che servono per accedere ai dati corre‐
lati. I DBMS SQL conservano dati semplici in "flat table", richiedendo che sia l'utente a
prelevare e raggruppare le informazioni correlate utilizzando le query. Carlo Iannò |
59
TANTI PREGI, POCHI DIFETTI
Dopo aver elencato una serie di funzionalità offerte da Apache Cordova e, quindi, dopo aver
evidenziati i principali vantaggi offerti da tale framework è necessario evidenziarne alcuni
difetti (anche se pochi).
Essenzialmente, i difetti inevitabili sono, di fatto, due:
• L’impossibilità di utilizzare un debugger.Per quanto concerne questo difetto, si può
dedurre che, a livello concettuale, sia impensabile poter utilizzare le funzioni di
debugging native dell’ambiente di sviluppo (X-Code o di Eclipse). L’applicativo, agli
occhi del compilatore, non è altro che un browser, seppur integrato con l’utilizzo
delle risorse hardware del dispositivo, che non può riconoscere come linguaggio
proprio il codice JavaScript integrato nell’applicazione; esso, infatti, viene visto solo
come testo puro (come anche le altre porzioni di codice HTML, CSS, e via dicendo).
In realtà, gli sviluppatori di Cordova hanno cercato, tramite la piattaforma Weinre,
di creare un debugger fruibile online. L’idea è quella di includere nel proprio codice
HTML un riferimento a un codice JavaScript situato online e che abbia un riferimento del progetto stesso. Il codice HTML da incorporare è il seguente:
<script src="http://debug.phonegap.com/target/targetscript-min.js#nome_progetto"></script>
Nonostante l’idea sia ottima, questo tipo di debugger prevede solo la parte relativa
alla visione del codice HTML in tempo (quasi) reale e del codice CSS applicato a
ciascun elemento. Rimangono quindi, irrisolta la problematica relativa al debug del
codice JavaScript e la gestione delle chiamate al server remoto.
• Vincoli legati alle risorse di sistema utilizzabili (processore, ram). Il secondo problema
segnalato riguarda, invece, i limiti inerenti alle risorse hardware utilizzabili. Trattandosi di un’applicazione sviluppata all’interno di una Web App non è possibile usufruire appieno delle capacità hardware del dispositivo. Tale limitazione si nota soprattutto in fase di allocazione della memoria RAM che, in molti casi, avviserà,
tramite dei warning (visibili in fase di test su X-Code o Eclipse), il superamento della
soglia di memoria allocabile.
Anche dal punto di vista dall’aspetto grafico non si può certo pensare di ottenere gli
stessi risultati paragonando un’applicazione nativa all’applicazione Web che Cordova ci permette di creare.
60 |Carlo Iannò
4. IBM M
F
In questo capitolo verranno illustrate le principali soluzioni IBM nel campo dello sviluppo
per applicazioni “mobile”. Verrà illustrato il progetto IBM Worklight e il ciclo di vita sul
quale sono incentrate le soluzioni IBM Cross-Platform. Il capitolo si concluderà con l’analisi di strategie IBM partner Gold SAP e con un’illustrazione della sua posizione sul
Magic Quadrant di Gartner.
1
Panoramica
2
Il Worklight e Lifecycle
3
IBM partner GOLD SAP
1
4
IBM Business Analytics e
Magic Quadrant di
Gartner
Carlo Iannò |
61
PANORAMICA
IBM è stata costituita nel Giugno del
1911. La filiale italiana venne aperta
nel 1927. L’azienda produce computer
di tutte le dimensioni, software e
servizi informatici. Oltre a computer
e hardware, IBM, negli ultimi anni, ha
sposato la scelta di sostenere lo svi‐
luppo di software open source colla‐
borando con molti specialisti alla
realizzazione di pilastri come server
HTTP Apache. IBM si basa su ambien‐
ti di sviluppo come Eclipse, pensati
come framework multipiattaforma
facilmente integrabili e personalizza‐
bili per diversi ambienti e linguaggi di
programmazione, partendo da Java.
IBM sostiene le aziende lungo il cam‐
mino dello sviluppo “mobile” presen‐
tando una suite composta da soft‐
ware e servizi che consentono di
definire una strategia completa, dalla
protezione e gestione dei dispositivi,
alla realizzazione di app e all’analisi
dei dati.
Grazie al progetto sviluppato da IBM
denominato Worklight, il cui nome è
stato ereditato dall’omonima azienda
israeliana acquisita nel 2012, IBM
62 |Carlo iannò
offre uno strumento per lo sviluppo di
app native attraverso il software
Lifecycle Menagement. Tale software
dà la possibilità di creare facilmente
applicazioni “mobile” di qualità, ope‐
ranti su più piattaforme.
Un'altra importante novità riguarda le
funzioni di Business Analytics, che
consentono di acquisire in tempo
reale informazioni sull’esperienza dei
clienti.
I nuovi servizi “mobile” di pianificazio‐
ne e strategia, erogati dai consulenti
IBM, aiutano le aziende a individuare
e pianificare la strategia migliore per
raggiungere gli obiettivi di business
prefissati.
IL WORKLIGHT E LIFECYCLE
IBM Worklight è la suite di IBM MobileFirst. IBM, grazie alla suite Worklight, fornisce soluzio‐
ni “mobile” ottimizzate per diversi dispositivi, creando applicazioni UI (User Interface) stan‐
dard.
Worklight offre delle soluzioni end‐to‐end che consentono di unificare le diverse piattaforme
in modo tale da garantire una crescita nel business e nell’innovazione nel settore dei disposi‐
tivi “mobile”.
Esso rappresenta l’intero patrimonio tecnologico di offerte e servizi aziendali mobili di IBM,
consentendo di usufruire dell’esperienza di IBM (nell’analisi, nelle tecnologie sociali, nella
sicurezza) in questo settore.
Grazie al binomio (IBM MobileFirst, Worklight), si possono creare soluzioni per aiutare a
trasformare il proprio modello di business, per conquistare nuovi mercati e per estendere le
proprie imprese, pur mantenendo l’integrità e la sicurezza dei propri beni.
Worklight può essere integrato completamente con il ciclo di vita (Lifecycle) di sviluppo di
una generica applicazione. Un esempio di Lifecycle potrebbe essere il seguente:
Carlo Iannò |
63
Nel Lifecycle, ad ogni passo vengono migliorate le soluzioni per raggiungere un obiettivo com‐
mune, ovvero sviluppare soluzioni ottimizzate, e quindi creare un’applicazione compatibile con
gli standard del “mobile” Cross‐Platform. In particolare, ogni passo si occupa di una fase ben
definita, come, ad esempio :
• Develop/Test. In questa fase si cerca di spingere tutti verso l’innovazione, nonchédi svilup‐
pare in maniera molto rapida con il supporto di un team di business e di sviluppo. Si cerca,
altresì, di consegnare le applicazioni con rapidità, di consentire ai clienti di fare rapida‐
mente le proprie esperienze, e di ottenere reali risultati di business con il massimo succes‐
so possibile.
• Deploy. Crea soluzioni in maniera pipeline, o meglio automatizza le distribuzioni di ambien‐
ti di test e di produzione per un’azienda. Un aspetto fondamentale di questa fase è l’o‐
biettivo di ridurre il lavoro manuale, ovvero la risorsa “tempo di attesa”. Un secondo
obiettivo consiste nell’ottenimento, mediante installazioni push‐button, di una maggiore
frequenza di rilascio, con una netta riduzione degli errori e la trasparenza end‐to‐end per
la conformità.
• Operate. Monitorizza, automatizza e ottimizza la capacità di gestione delle performance e
la disponibilità di creare soluzioni per determinate applicazioni “mobile”.
La suite Worklight consente di semplificare lo sviluppo Web, ibrido e nativo, di applicazioni
Cross‐Platform, tra cui iOS, Android, BlackBerry, Windows Phone, etc. Essa fornisce capacità di
sviluppo e di modifica del codice sorgente per aiutare gli sviluppatori ad accelerare la fase si
sviluppo, test e la consegna di applicazioni “mobile”. Tale suite comprende un’ottimizzazione
quadro per consentire una ricca esperienza utente che si interfaccia con molteplici ambienti nel
campo dei dispositivi mobili.
64 |Carlo Iannò
IBM PARTNER GOLD SAP
L’implementazione di un sistema di Enterprise Resource Planning (ERP) è efficace se apporta
integrazione dei processi, accessibilità delle informazioni, sicurezza nei dati e, soprattutto,
innovazione. Questi risultati si ottengono abbracciando delle soluzioni SAP in modo mirato
per ogni singola azienda che opera nel settore “mobile”.
IBM persegue la specializzazione dell’azienda nella gestione del know how, nelle esperienze
dei team di lavoro, nella capitalizzazione delle implementazioni di progetto e nell’utilizzo delle
“Best Practices” di settore. I focus sui diversi settori di industria sono stati maturati a livello
italiano da IBM Global Business Services. Il risultato di questa formidabile competenza è un set
di soluzioni di azienda SAP; queste ultime uniscono il prodotto standard leader di mercato in
costante evoluzione (SAP ERP) con le
Best Practices IBM di settore.
IBM, partner GOLD SAP, propone un
approccio progettuale completo che
indirizza i temi di infrastruttura tecnolo‐
gica, di operatività dei processi, di ge‐
stione del cambiamento e di controllo
operativo e direzionale. IBM è un part‐
ner che porta valore e competenze nel
ridisegno delle strategie di sviluppo “mobile”. La certificazione SAP All‐in‐One, rilasciata da
SAP, è un ulteriore riconoscimento alla qualità delle strategie offerte da IBM.
Carlo Iannò |
65
IBM Application Management Services for SAP
Per affrontare le sfide del mercato, le aziende devono
concentrarsi sul proprio business e non sull’Information
Technology.
Un’infrastruttura innovativa e completa offre un grande valore aggiunto; tuttavia, mantenerla
sempre aggiornata diventa spesso complicato, specialmente per le aziende medio-piccole
nelle quali la componente costo e la ricerca di personale specializzato hanno un peso rilevante.
Molte aziende, come, ad esempio IBM , esternalizzano la gestione delle applicazioni in maniera parziale o totale, ovvero scelgono il partner giusto per accelerare le operazioni, ridurre i
costi e migliorare la qualità dei processi.
Le competenze di IBM, leader nella fornitura di soluzioni di business e nello sviluppo di applicazioni “mobile”, permettono di offrire servizi di gestione che coprono tutto il ciclo di vita delle
applicazioni. Tali servizi sono forniti da team di consulenti con approfondite competenze applicative, sia funzionali che tecniche, in grado di comprendere il sistema SAP e di gestire la
stabilità e l’evoluzione attraverso:
• assistenza operativa, ovvero Attività di supporto gestionale;
• manutenzione correttiva, ovvero attività di individuazione di errori e relative rimozioni;
• manutenzione evolutiva, ovvero Supporto per implementazioni/sviluppi o per nuove
attività;
• costi ottimizzati, per assicurare l’ottimizzazione dei servizi.
66 |Carlo Iannò
IBM Mobility Services
Il fenomeno del “mobile” sta assumendo nelle
aziende di tutto il mondo dimensioni sempre più
significative. Al giorno d’oggi circa il 34% dei lavo‐
ratori nel mondo svolge il proprio lavoro in modalità “mobile”, utilizzando in modo proficuo le
soluzioni che la tecnologia mette a disposizione. D’altro canto, moltissime persone hanno ini‐
ziato a utilizzare recentemente uno smartphone o un tablet per svolgere attività di business.
A tal proposito i vantaggi per le aziende sono stati evidenti: aumento della produttività, flessibi‐
lità, riduzione dei costi, etc. Altrettanto chiari sono i benefici per i dipendenti, i quali possono
decidere di lavorare senza essere vincolati ad un preciso luogo, ad un preciso momento, ad un
preciso dispositivo.
Si calcola che, entro il 2016, saranno ben 350 milioni gli utenti che lavoreranno utilizzando il
proprio dispositivo “mobile”, sposando in pieno la tendenza in atto del BYOD. In altre parole,
non si hanno più strategie di mobility opzionali, ma la mobilità diventerà una necessità per tutti
coloro che lavoreranno nel campo aziendale.
Carlo Iannò |
67
IBM BUSINESS ANALYTICS E MAGIC QUADRANT DI GARTNER
Data l’esigenza di migliorare i risultati di business, la responsabilità dei manager e dei loro
collaboratori è di ottenere risultati di business migliori come, ad esempio, maggior fatturato,
costi inferiori, rischi ridotti e previsioni accurate.
Negli ultimi anni, i leader aziendali come IBM hanno identificato nella Business Analytics una
priorità strategica. La ragione è semplice: la Business Analytics porta a risultati di business
migliori.
La Business Analytics fornisce conoscenza che consente di intervenire concretamente su ogni
aspetto legato alle performance aziendali. Grazie ad essa si può aumentare l’efficienza e l’effi‐
cacia dei processi principali e contribuire alla creazione di aziende altamente performanti che
operano su diversi settori come, ad esempio, la fornitura di strategie di sviluppo per applicazio‐
ni “mobile”.
Di seguito consideriamo i risultati di due studi condotti da IBM nel campo della Business Ana‐
lytics:
•
•
La Business Analytics migliora la strategia aziendale e la capacità di prendere deci‐
sioni. I CEO (Chief Executive Officer ), di alta qualità presentano un utilizzo medio
dei processi di pianificazione strategica nel settore mobile e non che è del 16%
superiore rispetto alla media di tutti i CEO. Hanno anche il 54 % di probabilità in più
di favorire decisioni rapide, le quali sono di fondamentale importanza nel settore
“mobile”.
La Business Analytics porta costantemente a risultati finanziari migliori. I CFO
(Chief Financial Officer) hanno ottenuto un incremento del fatturato pari o superio‐
re al 36%.
La Business Analytics consente di rispondere a queste tre domande fondamentali: In che mo‐
do stiamo operando ? Perché ? Cosa dovremmo fare ?
68 |Carlo Iannò
Aiutando i responsabili decisionali a rispondere a tali domande, il software e le soluzioni di
Business Analytics consentono alle aziende che operano nel settore “mobile” e che offrono
soluzioni Cross-Platform di:
•
•
•
•
•
•
•
•
•
•
•
individuare e analizzare tendenze e anomalie;
assemblare e interagire con informazioni pertinenti;
confrontare scenari simulati;
misurare e monitorare le performance;
prevedere potenziali minacce e opportunità;
pianificare, stanziare e prevedere risorse;
valutare e gestire il rischio;
automatizzare le decisioni;
allineare le decisioni strategiche e operative;
avviare conversazioni con i clienti;
...e molto altro.
Lo studio della Business Analytics consente di sviluppare conoscenze
approfondite e concretamente utilizzabili laddove i responsabili decisionali hanno bisogno per migliorare le performance aziendali. IBM
offre una suite completa di soluzioni di Business Intelligence, analitica
e gestionale delle performance finanziarie della strategia alla quale si
è interessati.
Con le strategie IBM, le aziende sono in grado di individuare tendenze, modelli, confrontare
scenari simulati, etc. Grazie alle tecnologie offerte da IBM, moltissimi sviluppatori che utilizzano soluzioni IBM sono in grado di comprendere meglio, prevedere e plasmare i risultati di
business.
Carlo Iannò |
69
Nel seguito indichiamo in rosso la posizione di IBM nel Magic Quadrant di Gartner di cui si è
discusso nel Capitolo 2.
70 |Carlo Iannò
5. K
In questo capitolo verranno illustrate le principali soluzioni Kony nel campo di sviluppo
per applicazioni “mobile”. In particolare, verrà illustrata la piattaforma KonyOne sulla
quale sono basate molte soluzioni “mobile”. Il capitolo si concluderà con l’analisi dei principali tool di sviluppo di Kony e con un’illustrazione della sua posizione sul Magic Quadrant di Gartner.
1
Panoramica
2
KonyOne
3
Tool di sviluppo e Magic
Quadrant di Gartner
Carlo Iannò |
71
PANORAMICA
Kony è un’azienda leader nel settore
di sviluppo per soluzioni CrossPlatform. Grazie alle soluzioni offerte
da Kony, moltissime aziende leader
nel settore “mobile” possono competere tra loro fornendo rapidamente
applicazioni multipiattaforma e possono utilizzare un’ampia gamma di
dispositivi.
Kony, attraverso le proprie soluzioni
di sviluppo, cerca di abbracciare tutti i
dispositivi e sistemi operativi, in modo efficiente ed efficace. L’approccio
multipiattaforma sfrutta strategie e
tecnologie all’avanguardia; tale approccio fa in modo di garantire che
ogni utente, o meglio ogni utilizzatore, abbia un’esperienza di utilizzo
unica e ottimizzata.
L’approccio di Kony consente alle
aziende di prendere il controllo della
propria strategia “mobile”, offrendo
esperienze coerenti tra l’App e la
moltitudine di dispositivi disponibili
oggi ed in futuro. È possibile fornire
esperienze ottimizzate non solo su
dispositivi mobili, come gli smartphone, ma ottimizzare le soluzioni per
72 |Carlo Iannò
ogni dispositivo, come ad esempio
applicazioni desktop, tablet, etc.
Lo sviluppo “mobile” di Kony consente di combinare le informazioni provenienti da più fonti come, ad esempio, dai siti Web e creare soluzioni
applicative. È possibile sviluppare
applicazioni multipiattaforma ricchi di
funzionalità che operano in ambiente
nativo e ibrido, ovvero creare delle
WebApp.
Qualunque sia il punto di partenza
(singola o multipiattaforma), Kony
fornisce il quadro generale, o meglio
soluzioni dal quale attingere per creare applicazioni Cross-Platform adattabili a diversi dispositivi mobili.
KONYONE
La piattaforma KonyOne è un’organizzazione, o meglio una soluzione software completa
end-to-end. Grazie a tale piattaforma si possono gestire, distribuire e sviluppare applicazioni “mobile” che possono essere native o Web, raggiungendo migliaia di dispositivi mobili,
come tablet, smartphone e desktop.
KonyOne risolve una miriade di incongruenze tra le diverse piattaforme di sviluppo, legate
alle caratteristiche stesse dei dispositivi, come, ad esempio, dimensioni dello schermo,
browser, aggiornamenti, nuove tecnologie, etc. Tutte queste caratteristiche sono curate
dalla piattaforma KonyOne che crea soluzioni Web raggruppandole in un’unica soluzione
adattabile su più piattaforme possibili.
Carlo Iannò |
73
I principali sviluppatori di applicazioni “mobile” utilizzano la piattaforma di sviluppo KonyOne per implementare tool di sviluppo di terze parti.
La piattaforma KonyOne comprende:
•
KonyOne Studio. Fornisce agli sviluppatori un ambiente di sviluppo integrato, completo e orientato visivamente (IDE), con la massima flessibilità di script. Tale suite
abbraccia completamente la politica di sviluppo multipiattaforma ed elimina la
necessità di avere degli sviluppatori per ogni singola piattaforma di sviluppo. Grazie a KonyOne Studio si ha la presenza di una singola squadra di sviluppatori che
lavorano simultaneamente su importanti elementi di sviluppo e creano soluzioni
ottimizzate per il “mobile”, secondo le esigenze di business. Un importante compito di KonyOne Studio è progettare l’interfaccia utente (UI).
•
KonyOne Server e Sync Server. Fornisce la scalabilità, la sicurezza e la gestione delle
sessioni in aggiunta alle funzionalità di aggregazione, come, ad esempio, il servizio
multipiattaforma, basato su sviluppo di applicazioni Web con piena integrazione
ad altre soluzioni di sviluppo, come Adobe Omniture e IBM Coremetrics. Inoltre,
grazie a Sync Server, è facile estendere e migliorare le funzionalità di base, sia per
sistemi EIS che per sistemi ERP.
74 |Carlo Iannò
Un esempio di struttura completa della piattaforma KonyOne è mostrato nella seguente
figura:
Carlo Iannò |
75
TOOL DI SVILUPPO E MAGIC QUADRANT DI GARTNER
La piattaforma di sviluppo KonyOne offre una vasta gamma di tool che consentono di
creare ricche soluzioni multipiattaforma.
Di seguito verranno elencati alcuni tool principali e, successivamente, le principali fasi di
sviluppo di applicazioni “mobile”:
• Visual App design multipiattaforma. Utilizza servizi, mapping dei dati e designer di
eventi per rendere l’esperienza utente coerente e personalizzabile attraverso diversi
criteri di sviluppo nativo o Web. Definisce la posizione dei pixel in scala secondo la
forma del dispositivo, gestisce come trascinare, scorrere e ruotare in 2D e 3D con le
API di animazione, etc.
• Editor di codice JavaScript. Usa le potenzialità di JavaScript esistenti nell’editor Kony
Studio. Permette di scrivere codice JavaScript collegato ad applicazioni native, Web
o ibride; utilizza Intellisense per accelerare la codifica, per importare ed esportare
codice nativo che viene riutilizzato all’interno dell’editor; classifica i file JavaScript in
moduli funzionali e li definisce dinamicamente.
• Costruire, eseguire e distribuire. Migliora la qualità delle App, velocizza il time-tomarket e mantiene le applicazioni in esecuzione con il minimo disturbo. Crea funzionalità e strumenti basati su piattaforme native come, ad esempio, Apple IPA, Google APK, Blackberry COD, etc.
Le principali fasi di sviluppo di un’applicazione “mobile” basata su KonyOne sono:
• Costruire (Build). Crea soluzioni per applicazioni ed esperienze Web adattabili alle piattaforme di sviluppo alle quali si è interessati. Tale fase si occupa di spingere la produzione di soluzioni multipiattaforma in modo tale da ottenere i migliori risultati
possibili con il minor tempo possibile.
76 |Carlo Iannò
• Test. Verifica l’aspetto e le prestazioni delle applicazioni. Viene condotto con emulatori
integrati nella versione di KonyOne Studio. Sono disponibili due opzioni: una online e
un’altra offline.
• Pubblicazione (Publish). Per rendere le applicazioni accessibili da un server Web è necessario scegliere il percorso server di destinazione e pubblicare l’App nella console di
KonyOne; la pubblicazione deve essere sicura e rispettare la politica adottata, come,
ad esempio, i diritti di accesso, le approvazioni, etc.
• Installazione (Install). Le applicazioni, prima di essere installate, saranno sottoposte a
verifiche da parte dei produttori di sistemi operativi, come Apple, Google, Microsoft,
etc. Successivamente, potranno essere installate attraverso i corrispettivi App Store.
Carlo Iannò |
77
Nel seguito indichiamo in rosso la posizione di KonyOne nel Magic Quadrant di Gartner
di cui si è discusso nel Capitolo 2.
78 |Carlo Iannò
6.
In questo capitolo verranno illustrati vari approcci “mobile” Cross-Platform. In tale contesto verranno descritte le principali caratteristiche dei diversi framework di sviluppo multipiattaforma. In particolare, analizzeremo i framework Sencha Touch, Appcelerator Titanium e descriveremo le soluzioni SAPUI5 e SAP Fiori; il capitolo si concluderà con la
descrizione di NepTune Application Design.
1
Sencha Touch
2
SAPUI5 e SAP Fiori
4
Titanium Mobile
5
NepTune Application
Designer
3
Rhodes
1
Carlo Iannò |
79
SENCHA TOUCH
Il gruppo Sencha ha rilasciato, nella seconda metà del 2010, Sencha Touch, un progetto
open source che permette di sviluppare interfacce Web per molti dispositivi “mobile”,
come tablet, smartphone, etc.
Sencha Touch utilizza gli standard HTML5, CSS e JavaScript; di conseguenza non è
necessario installare alcuna applicazione aggiuntiva sui dispositivi che supportano questi
standard. Con HTML5, le applicazioni Sencha Touch possono essere utilizzate anche
offline e, grazie alla geolocalizzazione, è possibile integrare dati geografici nei propri
progetti. L'uso di CSS permette di non avere praticamente nessuna immagine nelle
librerie dei componenti; un esempio potrebbero essere gli stili, i bordi, i gradienti, le
ombre, le transizioni, i menu e i pulsanti, tutti componenti creati con CSS puro. Tramite
JavaScript vengono gestite una buona parte delle interazioni con l'utente finale; inoltre, il
framework permette l'utilizzo di eventi multitouch, finora visti soltanto in applicazioni
native.
Sencha Touch è una soluzione concepita per essere multipiattaforma e, quindi, contem‐
poraneamente compatibile con iOS, Android e molti altri sistemi operativi. Grazie a Sen‐
cha Touch, la visualizzazione di tutti i componenti è indipendente dalla risoluzione dello
schermo e la fluidità dell'applicazione dipende dalle caratteristiche tecniche del dispositi‐
vo. Ci sono, tuttavia, alcune differenze minori tra i vari sistemi operativi ma nulla di rile‐
vante; ad esempio, le transizioni 3D con CSS non sono supportate da Android.
Sencha Touch viene distribuito con licenza gratuita ma con supporto a pagamento. L'uti‐
lizzo dell'IDE Sencha Architect è sottoposto a licenza di 399$. Le librerie Sencha Touch
sono disponibili sotto licenza GPLv3.
80 |Carlo Iannò
SAPUI5 E SAP FIORI
SAPUI5 è una tecnologia rilasciata nel 2012 per la creazione di interfacce utente e per appli‐
cazioni client, utilizzando elementi di programmazione Web (HTML, CSS3, JavaScript). La
componente runtime di SAPUI5 è una libreria client‐side per il rendering che offre un insie‐
me di funzioni per lo sviluppo di applicazioni desktop e “m0bile”. È disponibile un plugin per
Eclipse per la programmazione secondo il pattern Model-View-Controller (MVC); inoltre, è
possibile salvare ed avviare le proprie applicazioni in un SAP NetWeaver Application Server
utilizzando il SAPUI5 ABAP Repository. Un esempio di architettura SAPUI è mostrata nella
seguente figura:
1
Tale architettura è utilizzabile su qualsiasi dispositivo che abbia un browser che supporti
HTML5; questa struttura consente lo sviluppo di applicazioni Web based con temi simili a
quelli di altre applicazioni mobili come SAP Fiori. Un principale svantaggio di tale approccio
è la non conformità con il tema del dispositivo mobile utilizzato. La tecnologia SAPUI5 viene
rilasciata da SAP tramite delle librerie con licenza open source (Apache2) con il nome di
OpenUI5.
Carlo Iannò |
81
Un’altra architettura di sviluppo che abbraccia soluzioni SAP è costituita da SAP Fiori, la
quale può essere interpretata come una raccolta di applicazioni già sviluppate con SA‐
PUI5 che dovrebbero coprire una larga parte delle necessità dei clienti. È, comunque,
possibile personalizzare le applicazioni in base alle caratteristiche dei dispositivi.
Un esempio di architettura SAP Fiori è mostrata nella seguente figura:
Anche SAP Fiori, come SAPUI5, è utilizzabile su qualsiasi dispositivo che abbia un brow‐
ser che supporti HTML5. Grazie all’utilizzo di SAP Fiori si possono avere applicazioni già
sviluppate; inoltre, vengono assemblate anche delle potenzialità di Apache Cordova. La
tecnologia di estensione SAP Fiori viene distribuita con licenza pari a circa 150 Euro per
ogni singolo utente.
82 |Carlo Iannò
RHODES
Rhodes è un framework Ruby on Rails (chiamato anche RoR) open source creato per costrui‐
re rapidamente applicazioni native per tutti i principali smartphone (iOS, Android, Blackber‐
ry, Windows Phone e Symbian). Come linguaggi ausiliari Rhodes utilizza HTML, CSS e Java‐
Script. Esso permette di costruire vere applicazioni native, che permettono di sfruttare le
funzionalità del dispositivo. Esempi di funzionalità potrebbero essere i seguenti:
• Global Position System (GPS);
• contatti e calendario;
• macchina fotografica;
• codice a barre;
• cattura della firma;
• bluetooth;
• ...e molti altri.
Rhodes è uno dei pochi framework nel suo genere a supportare il pattern Model-ViewController (MVC), permettendo di separare quindi la logica dell’applicazione dalla grafica.
1
Carlo Iannò |
83
Il pattern MVC costituisce un punto di fondamentale importanza nella scelta di questo
framework. Sono, inoltre, disponibili due importanti servizi esclusivi di questo fra‐
mework:
•
RhoHub. È un servizio di host che effettua la costruzione del prodotto senza impor‐
re agli sviluppatori l’obbligo di “attrezzare” la propria piattaforma di lavoro per
tutti i dispositivi dei quali si intende effettuare lo sviluppo.
•
RhoSync. Riguarda la connettività ed è un metodo veloce per permettere a qual‐
siasi applicazione di connettersi, recuperare, analizzare e gestire DBMS sfrut‐
tando le API dei moderni dispositivi.
Lo sviluppo di applicazioni “mobile” multipiattaforma è molto più semplice se si utilizza
Rhodes, poiché c’è poco codice da scrivere ed inoltre si ha a disposizione un Object Rela‐
tional Manager (ORM) chiamato Rhom, il quale sincronizza dati remoti usando RhoSync.
84 |Carlo Iannò
TITANIUM MOBILE
Le tecnologie Web sono una delle soluzioni più usate negli ultimi anni per creare applicazioni.
Tali tecnologie consentono di sviluppare e aggiornare le applicazioni in maniera molto facile;
inoltre, il Web offre la possibilità di sviluppare applicazioni multipiattaforma.
Partendo da queste considerazioni, Titanium nasce per fornire agli sviluppatori un framework
open source per costruire applicazioni desktop o “mobile”, usando tecnologie Web come
HTML, CSS, JavaScript, Ruby, PHP, etc.
La piattaforma Titanium è stata introdotta da Appcelerator Inc. nel Dicembre del 2008, ma il
supporto per lo sviluppo di applicazioni “mobile” è stato aggiunto nel Giugno 2009. Per otte‐
nere la piattaforma di sviluppo Titanium Developer e, quindi, qualunque informazione di cui
si ha bisogno, è necessario registrarsi presso Appcelerator al seguente indirizzo: http://
www.appcelerator.com/
La piattaforma Titanium è composta da Titanium Desktop e da Titanium “Mobile”; un esem‐
pio è mostrato nella seguente figura:
1
Carlo Iannò |
85
•
Titanium Desktop. Permette di creare applicazioni Desktop native a partire da Ruby,
Python, JavaScript, CSS e HTML; il codice generato è portabile, e quindi compati‐
bile con Linux, Windows o Mac OS. Per esempio, rispetto alle applicazioni create
con Adobe AIR, le applicazioni sviluppate con Titanium Desktop hanno perfor‐
mance migliori , occupano il 10% in meno della memoria rispetto alle applicazioni
di Adobe AIR e garantiscono il pieno accesso a tutte le risorse del sistema opera‐
tivo. Le API Desktop permettono, inoltre, di generare una UI simile a quella del
sistema operativo scelto, ad esempio Mac OS, Windows, etc.
•
Titanium “Mobile”. Permette di creare applicazioni native per iOS o Android a
partire da JavaScript, HTML e CSS. Il codice creato viene tradotto dal compilato‐
re in Objective‐C (per iOS) o in Java (per Android). Titanium “Mobile” supporta
completamente le interfacce di Android e iOS e fornisce pieno supporto ai servizi
come Twitter, Facebook, Yahoo, nonché alle funzionalità del dispositivo, come
l'accelerometro, il rilevamento della posizione, le mappe, etc.
Titanium mette, inoltre, a disposizione degli sviluppatori una serie di servizi Cloud per
testare, distribuire e analizzare le applicazioni create. Inoltre, Titanium è un framework
open source e, quindi, chiunque può contribuire a migliorarlo.
86 |Carlo Iannò
NEPTUNE APPLICATION DESIGNER
Questa tecnologia è quella che meno si discosta dai sistemi SAP, perché lo sviluppo avviene
totalmente all'interno di SAP. Viene messo a disposizione un IDE grafico e le funzioni dell'ap‐
plicazione sono create nel sistema stesso ed invocate tramite chiamate AJAX.
Dal momento che è necessaria una conoscenza limitatissima delle tecnologie di sviluppo
Web, NepTune viene pubblicizzato come strumento per la creazione di applicazioni ed ideato
per coloro che conoscono solo l'ABAP (il linguaggio di programmazione utilizzato in SAP).
Lo sviluppo avviene sfruttando (automaticamente) le librerie SAPUI5; inoltre sono messe a
disposizione le librerie JQuery, il servizio PhoneGap Build (compilazione online in applicazioni
ibride) e la gestione della sicurezza con SAP “Mobile” Platform Cloud e SAP Afaria Cloud.
L’interfaccia grafica di NepTune è mostrata nella seguente figura:
1
Carlo Iannò |
87
Nella parte superiore viene visualizzato il nome dell’applicazione; successivamente è
possibile inserire una descrizione della stessa, un titolo e “l’Application Class”, ossia una
classe di supporto. Nel tab “Library” vanno indicate le librerie che verranno utilizzate; in
questo caso si tratta di un’applicazione SAPUI5, e quindi le librerie sono per dispositivi
mobili (contrassegnate dalla dicitura “mobile”).
Lo sviluppo con questa tecnologia è molto veloce; la programmazione consiste nel trasci‐
nare gli elementi, e ciò rende il lavoro molto più semplice anche a coloro che non sono dei
programmatori esperti. In questo modo anche se non si conosce alla perfezione il codice
si può, comunque, riuscire a creare un’applicazione “mobile”. L’unico inconveniente per
chi utilizza NepTune sta nella difficile gestione delle cose complesse ad esempio, un’ap‐
plicazione creata tramite CSS può avvenire creando un oggetto personalizzato le cui
proprietà devono essere riscritte, oppure è possibile utilizzare JQuery, il che comporta
lunghi tempi di debug per individuare le classi generate da NepTune.
NepTune è adattabile a qualsiasi dispositivo che abbia un browser, che supporti HTML5 e
in cui ci sia un sistema SAP con esso installato. Lo svantaggio principale di tale framework
è la rigidità nello sviluppo, poiché è possibile sviluppare solo attraverso l’IDE.
Il costo della licenza è pari a 160 Euro per ogni singola postazione.
88 |Carlo Iannò
CONCLUSIONI
In questa tesi è stato proposto, partendo dal trend BYOD, il modello di sviluppo “mobile”
Cross-Platform che, tradotto letteralmente, vuol dire multipiattaforma.
Nella tesi sono state descritte le principali aziende che sono nate e si sono sviluppate nel
settore “mobile” e che forniscono soluzioni e strategie per lo sviluppo Cross-Platform. Si
è visto come ogni azienda è basata su delle linee guida per realizzare applicazioni e soluzioni multipiattaforma. IBM, ad esempio, abbraccia quasi interamente soluzioni basate
su sistemi SAP e realizza sviluppi secondo il Lifecycle; Kony, grazie alla piattaforma KonyOne, fornisce soluzioni native o Web complete, raggruppandole in un’unica soluzione
adottabile alle varie piattaforme.
In questa tesi sono stati illustrati i principali framework di sviluppo come Xamarin, PhoneGap, Apache Cordova, etc, sui quali molte aziende basano, in parte o interamente, lo
sviluppo di soluzioni “mobile”. Si è visto come l’utilizzo di importanti linguaggi di programmazione, come HTML5, JavaScript e CSS3 abbia rafforzato il concetto di sviluppo
multipiattaforma, dando la possibilità a moltissime aziende leader nel settore “mobile” di
sviluppare soluzioni e di tradurle per dispositivi con caratteristiche differenti e Sistemi
Operativi diversi (Android, iOS, Windows Phone, etc).
1
Negli ultimi tempi si parla molto delle tecnologie del futuro, dei nuovi strumenti per lo
sviluppo di applicazioni Web, di applicazioni “mobile” e di framework multipiattaforma.
Tutti sembrano concordare su un punto: “il futuro del Web è mobile”.
Il “mobile” ha acquisito e acquisterà un’importanza estremamente rilevante grazie alla
grande diffusione e alla crescita di dispositivi mobili ed alle efficaci soluzioni CrossPlatform sviluppatesi negli ultimi anni.
Carlo Iannò |
89
90 |Carlo Iannò
BIBLIOGRAFIA
1.
Appcelerator Titanium. http://www.appcelerator.com/,2014
2.
Google Support. https://groups.google.com/forum/phonegap,2014
3.
IT Research. http://www.gartner.com/technology/researc.jsp,2014
4.
Info Tech research group. http://www.infotech.com/,2014
5.
Kony. http://www.kony.com/products/development/features,2014
6.
Kony. www.Kony.com/KonyOne,2014
7.
NepTune Software. http://neptune-software.com/,2014
8.
research2guidance. http://research2guidance.com/,2014
9.
Rhodes. http://www.motorolasolutions.com/US-EN/
RhoMobile+Suite/Rhodes,2014
10. SAP. http://www.sap.com/italy/index.html, 2014
1
11. Sencha. http://www.sencha.com/products/touch/, 2014
12. A.Balaz, R. Bloor, M. Tabor. Services and Tools for All Mobile Platform, Mobile developer’s guide to the galaxy. Enough Software, 2014
13. N. Calzavara. Il framework Phonegap vs Java Nativo per applicazioni mobile.
http://scholar.google.it/schhp?hl=it&as_sdt=0,5, 2011
14. A. Charland and B. Leroux. Mobile Application Development: Web vs. Native. Vol.54,
No. 5, Communications Of The ACM.
15. F. Cozzolino. Xamarin Mobile Day. http://dotnetside.org/blogs/fabio/,
2014
16. E.Damiani, Ingegneria del software con UML e Unified Process. McGraw-Hill Education, 2003
Carlo Iannò|
91
17. A. Fiumanò. Sviluppo di applicazioni mobile cross-platform con Apache Cordova.
http://scholar.google.it/schhp?hl=it&as_sdt=0,5
18. IBM Corp. Concentrati sul tuo business alla gestione del tuo sistema SAP.
www.IBM.ibm.com/gbs/it, 2014
19. IBM. Il mobile nelle aziende è multipiattaforma. http://www.ictbusiness.it/,
2014
20. IBM Software Business Analytics. Risultati di business migliori con la Business Analytics.
www.ibm.com/legal/copytrade.shtml, 2014
21. IBM United States Software Announcement dated April 22, 2014. IBM Worklight V6.2
22. W. Meng Lee. Developing Cross-Platform Mobile Apps using Xamarin. http:/
www.codemag.com/Article/1401051. CODE Magazine, 2014
23. T. Myer. Beginning PhoneGap. Safari Books Online, 2014
24. D. Parys. Windows, iOS, Android & Web-Viele Plattformen, ein Tool. http://
www.slideshare.net. Microsoft Deutschland, 2014
25. J. Peppers. Xamarin Cross-platform Application Development, Develop pruction-ready
applications for iOS and Android using Xamarin. PACKT Publishing, 2014
26. C. Petzold. Creating Mobile Apps with Xamatin.Form. Amazon Kindle, 2014
27. R. S. Pressman. Principi di ingegneria del software. McGraw-Hill Education, 5 edizione,
2008
28. O.Qorri. Rassegna dei framework per lo sviluppo di applicazioni mobili, 2014
29. I. Sommerville. Ingegneria del software. Pearson Education, 2007
30. J.M. Wargo. PhoneGap Essentials (Building Cross-Platform Mobile Apps). Pearson Education, Inc, 2012
31. Xamarin. The Xamarin Integrated Development Environment. http://
developer.xamarin.com/Guides/Android/User_Interface/
Designer_Overview/, 2014
92 |Carlo Iannò
1
Desidero ringraziare tutti coloro che mi hanno sostenuto nella stesura di questa tesi con suggerimenti, critiche ed
osservazioni. Ringrazio innanzitutto il professore Domenico
Ursino per l’impegno, i preziosi consigli e la dedizione dimostrata durante questo periodo. Ringrazio la mia famiglia
che con amore mi ha sempre confortato e incoraggiato . Ringrazio la mia fidanzata Lucia che, mi ha sempre incoraggiato a non mollare mai. Infine, ringrazio tutti i miei colleghi
ed amici che mi sono stati vicini in tutti questi anni.

theses - Università degli Studi Mediterranea

Transcript

Documenti analoghi

1994 - Processo per l`omicidio di Carlo D`Andrea

mezzogiorno in musica - Teatro Regio di Parma

scarica il documento in PDF, 15kb

Così ho ucciso mio cugino e suo cognato

quando il dolore si trasforma in amore

SCHEDA DI ADESIONE - Ospedale San Carlo

Mappa Carlo V

Esempio di lettera di accompagnamento o di presentazione

Marta Dassù editoriale 5 L`economia mondiale: falchi, colombe e

“AVERE FIDUCIA PER GENERARE FIDUCIA” Costruire