POLITECNICO DI MILANO · 2.5 Esempio di progetto Xamarin in Visual Studio. . . . . . . . . . . . ....

POLITECNICO DI MILANO

Scuola di Ingegneria Industriale e dell’Informazione

Dipartimento di Elettronica, Informatica e Bioingegneria

Corso di Laurea Magistrale in Computer Science and Engineering

2.2 . | il marchio, il logotipo: le declinaZioni

Generazione automatica di applicazioni

mobili native secondo un approccio

model-driven

Relatore: Prof. Luciano BARESI

Tesi di Laurea di:

Aldo PINTUS Matr. 823545

Anno Accademico 2015-2016

Un ringraziamento speciale va ai miei genitori, per avermi permesso di essere qui a

portare a termine il primo grande traguardo della mia vita. Grazie Papa, per avermi

dato tutto e avermi reso cio che sono, grazie Mamma per il tuo sostegno infinito e la

fiducia che hai sempre dimostrato nei miei confronti, e grazie anche a te Daniela, che

mi hai insegnato cosa significhino il sacrificio e la passione di inseguire un sogno.

Grazie a te Chiara, che nonostante tutti i miei difetti, sei sempre qui accanto a me

e hai saputo rendermi una persona migliore. Spero di condividere tanti altri traguardi

importanti della mia vita insieme a te.

Grazie ai miei amici di sempre, che sono un punto di riferimento ormai da molti

anni e che hanno condiviso con me tanti momenti felici, e grazie ai miei compagni

di universita, con cui ho speso forse troppo poco tempo al Politecnico, ma che mi han

dato la forza di andare avanti, tra un esame andato male e una partita ai videogame

in pausa pranzo.

Infine un ringraziamento sincero va al Professor Luciano Baresi, che mi ha permesso

di unire il lavoro con la mia grande passione per le tecnologie web e mobile, alleggerendo

le fatiche di questi mesi e regalandomi davvero tanto entusiasmo e soddisfazione.

Aldo

Indice

1 Introduzione 1

2 Contesto generale 4

2.1 Stato dell’arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Applicazioni di prototipizzazione . . . . . . . . . . . . . . . . . 5

2.1.2 Applicazioni per sviluppatori . . . . . . . . . . . . . . . . . . . . 9

2.1.2.1 Applicazioni multipiattaforma ibride . . . . . . . . . . 9

2.1.2.2 Applicazioni cross-compilate o interpretate . . . . . . . 10

2.1.2.3 Applicazioni native . . . . . . . . . . . . . . . . . . . . 13

2.2 Obiettivo della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Soluzione proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Generazione del modello astratto 19

3.1 Protocode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Librerie software . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.2 Architettura software originale . . . . . . . . . . . . . . . . . . . 24

3.1.2.1 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.2.2 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.2.3 Controller . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.2.4 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.1.3 Interfaccia grafica dell’applicazione . . . . . . . . . . . . . . . . 32

3.2 Aggiornamento di Protocode . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2.1 Design della logica applicativa . . . . . . . . . . . . . . . . . . . 37

3.2.1.1 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2.1.2 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2.1.3 Controller . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.2.1.4 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.2.2 Aggiornamento dell’interfaccia grafica . . . . . . . . . . . . . . . 56

3.3 Generazione del modello . . . . . . . . . . . . . . . . . . . . . . . . . . 64

I

4 Traduzione in codice nativo 72

4.1 MobileCodeGenerator . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.1.1 Epsilon Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.1.1.1 Eclipse Modeling Framework . . . . . . . . . . . . . . 73

4.1.1.2 openArchitectureWare . . . . . . . . . . . . . . . . . . 74

4.1.2 Struttura del progetto . . . . . . . . . . . . . . . . . . . . . . . 77

4.1.2.1 Metamodello dell’applicazione mobile . . . . . . . . . . 78

4.1.2.2 Templates di traduzione . . . . . . . . . . . . . . . . . 79

4.2 Traduzione in codice nativo . . . . . . . . . . . . . . . . . . . . . . . . 86

5 Valutazione 98

5.1 Analisi quantitativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.1.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

5.1.2 iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

5.1.3 Considerazioni finali . . . . . . . . . . . . . . . . . . . . . . . . 106

5.2 Analisi qualitativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

6 Conclusioni 112

6.1 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Bibliografia 116

Appendice A 121

II

Elenco delle figure

2.1 Interfaccia grafica di FluidUI . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Interfaccia grafica di Proto.io . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Interfaccia grafica di InvisionApp . . . . . . . . . . . . . . . . . . . . . 7

2.4 Interfaccia grafica di Pixate . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 Esempio di progetto Xamarin in Visual Studio . . . . . . . . . . . . . . 11

2.6 Esempio di classe Java generata con Titanium . . . . . . . . . . . . . . 12

3.1 Struttura di Protocode . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Modello logico di Protocode . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3 Schema dei controller di Protocode . . . . . . . . . . . . . . . . . . . . 29

3.4 Gerarchia delle view di Protocode . . . . . . . . . . . . . . . . . . . . . 31

3.5 Anteprima applicazione Android su Protocode . . . . . . . . . . . . . . 32

3.6 Anteprima applicazione iOS su Protocode . . . . . . . . . . . . . . . . 33

3.7 Modello logico finale di Protocode . . . . . . . . . . . . . . . . . . . . . 40

3.8 Schema dei controller finale di Protocode . . . . . . . . . . . . . . . . . 53

3.9 Gerarchia finale delle view di Protocode . . . . . . . . . . . . . . . . . 55

3.10 Anteprima applicazione smartphone Android su Protocode . . . . . . . 56

3.11 Anteprima applicazione smartwatch WatchOS su Protocode . . . . . . 57

4.1 Meccanismo di traduzione di MobileCodeGenerator . . . . . . . . . . . 74

4.2 Struttra del progetto di MobileCodeGenerator . . . . . . . . . . . . . . 77

5.1 Modello dell’applicazione ParkTraining su smartphone . . . . . . . . . 99

5.2 Modello dell’applicazione ParkTraining su smartwatch . . . . . . . . . . 100

5.3 Applicazione ParkTraining simulata su Apple Watch 42mm . . . . . . . 102

5.4 Applicazione ParkTraining simulata su iPhone6s Plus - 1 . . . . . . . . 102

5.5 Applicazione ParkTraining simulata su iPhone6s Plus - 2 . . . . . . . . 103

5.6 Immagini a confronto della schermata chat di WhatsApp . . . . . . . . 109

5.7 Immagini a confronto della schermata dettaglio chat di WhatsApp . . . 110

5.8 Immagini a confronto della schermata impostazioni di WhatsApp . . . 110

III

Elenco delle tabelle

3.1 Tabella dei widget di Protocode . . . . . . . . . . . . . . . . . . . . . . 36

3.2 Tabella dei widget smartphone nella versione finale di Protocode . . . . 61

3.3 Tabella dei widget smartwatch nella versione finale di Protocode . . . . 63

4.1 Tabella dei widget smartphone tradotti con MobileCodeGenerator . . . 94

4.2 Tabella dei widget smartwatch tradotti con MobileCodeGenerator . . . 96

5.1 Copertura codice sorgente ParkTraining Android Studio . . . . . . . . 105

5.2 Copertura codice sorgente ParkTraining Xcode . . . . . . . . . . . . . . 106

IV

Sommario

I dispositivi mobili sono oramai diventati uno strumento indispensabile nella vita di

tutti i giorni e il loro mercato e costantemente in crescita: la piu grande rivoluzione a cui

stiamo assistendo negli ultimi anni e la nascita e diffusione degli smartwatches, ovvero

gli orologi intelligenti, che non sono piu solo semplici estensioni dello smartphone, ma

veri e propri dispositivi indipendenti. I colossi del mercato, Apple e Google, permettono

oggi di creare applicazioni mobili per entrambi i dispositivi, ma i costi di progettazione

della stessa applicazione per entrambe le piattaforme, iOS e Android, sono spesso il

motivo per cui si rinuncia alla potenza dello sviluppo in codice nativo, in favore di

altre soluzioni ibride. Il lavoro svolto in questa tesi, consiste nel creare uno strumento

che permetta di generare applicazioni mobili per le suddette piattaforme, traducendo

in codice nativo un unico modello astratto dell’applicazione, realizzato semplicemente

attraverso un editor grafico: questo approccio, chiamato model-driven, permettera di

generare la stessa applicazione sia per iOS che per Android a partire da un unico

modello iniziale, dimezzando quindi i tempi di sviluppo del software almeno nelle sue

fasi preliminari. Viene dunque descritto il funzionamento della toolchain di traduzione e

condotta un’analisi qualitativa e quantitativa su di essa, in un vero processo di sviluppo,

per dimostrare quanto questo approccio possa essere decisivo nel ridurre i tempi e i

costi della realizzazione di applicazioni mobili native.

V

Abstract

Mobile devices have now become an essential tool in everyday life, and their market is

constantly growing: the biggest revolution we are seeing in recent years is the emer-

gence and spread of smartwatches, that are not longer just simple extensions of the

smartphone, but real independent devices. The giants of the market, Apple and Goo-

gle, now allow you to create mobile applications for both devices, but the design costs

of the same application for both platforms, iOS and Android, are often the reason for

missing out on the power of native code development, in favor of other hybrid solu-

tions. The work done in this thesis is to create a tool that allows to generate mobile

applications for these platforms, translating into native code a single abstract model

of the application, achieved simply through a graphic editor: this approach, called

model-driven, will allow to generate the same application for both iOS and Android,

starting from a single initial model, thus halving software development times, at least

in its preliminary stages. It is then described the behaviour of the translation tool-

chain, and finally, it is conducted a qualitative and quantitative analysis on it, in a real

development process, to show how this approach can be decisive in reducing the time

and costs of the realization of native mobile applications.

VI

Capitolo 1

Introduzione

I dispositivi mobili sono oramai diventati uno strumento indispensabile nella vita di

tutti i giorni, riuscendo a compensare i bisogni dei consumatori sotto tutti i punti di

vista, dallo svago alla produttivita: il loro strettissimo legame con i social media, li ha

inevitabilmente resi lo strumento per eccellenza della comunicazione e della condivisio-

ne di informazioni in tutto il mondo. Il mercato dei dispositivi mobili e costantemente

in crescita sin dai primi anni 2000 e sebbene ancora oggi i piu grandi produttori di

smartphone, l’americana Apple [1] e il colosso coreano Samsung [2], siano saldamente

al comando della classifica, negli ultimi anni anche il mercato cinese ha cominciato ad

imporsi grazie al marchio Huawei [3] [4]. Tuttavia, la situazione dei sistemi operativi a

bordo di questi dispositivi, resta invariata praticamente dal 2008 con iOS [5] di Apple

e Android [6] di Google [7] che dominano la scena, lasciando attualmente ai competitor

Windows Phone [8] e BlackBerry OS [9] meno dell’1% del mercato [10].

La piu grande rivoluzione a cui stiamo assistendo negli ultimi 2-3 anni e la nascita

e diffusione degli smartwatch, ovvero gli orologi intelligenti che montano sistemi ope-

rativi del tutto simili ai corrispettivi su smartphone, e che nel giro di poco tempo sono

passati da semplice estensione dei telefoni a dispostivi quasi completamente indipen-

1

1. INTRODUZIONE

denti, in grado di connettersi ad Internet e scambiare informazioni autonomamente. Il

mercato in questo senso e ancora una volta dominato da Apple con il suo Apple Watch

[11] e in buona parte anche da Samsung con i vari Samsung Gear [12], le quali pro-

ducono rispettivamente il 52.4% e il 14.3% degli smartwatch in commercio dall’inizio

del 2016 [13]; restano comunque altri validi competitor quali LG [14], Motorola [15] e

ASUS [16] i quali, a differenza di Samsung che ha quasi completamente rimpiazzato

Android con Tizen [17], montano il sistema operativo Android Wear [18] di Google.

Apple Watch, naturalmente, possiede il sistema operativo di casa Apple watchOS [19].

Fatte queste premesse, risulta evidente che per quel che riguarda lo sviluppo di ap-

plicazioni mobili, sia per smartphone che per smartwatch, la soluzione piu promettente

in termini di ricavi e diffusione sul mercato e senza dubbio quella di Google e/o Apple;

la vera questione in termini di sviluppo sta nello scegliere se progettare due appli-

cazione indipendenti per i due sistemi operativi, oppure scegliere un’unica soluzione

compatibile per entrambi, con i conseguenti pregi e difetti. Se nel primo caso i costi di

progetto in termini di tempo e denaro possono risultare maggiori, poiche e inevitabile

procedere contemporaneamente su almeno due team di sviluppo differenti, nel secondo

caso non e invece possibile raggiungere lo stesso risultato di un’applicazione scritta ad

hoc per un specifico sistema operativo (nativa), sia in termini di prestazioni, sia in

relazione al look-and-feel dell’applicazione, per il quale i designer di Apple e Google

hanno maturato concetti decisamente differenti.

In questo elaborato di tesi, si e scelto di progettare un sistema in grado di suppor-

tare lo sviluppo di applicazioni mobili compatibili con le piattaforme Android, iOS e i

loro sistemi smartwatch, che produca sı due applicazioni distinte e indipendenti, ma che

generi automaticamente buona parte del codice sorgente dell’applicazione, a partire da

un unico modello sviluppato tramite un semplice tool grafico. Questo permetterebbe

sostanzialmente di risparmiare un enorme quantita di tempo nelle prime fasi di pro-

getto, andando a colmare il gap temporale di cui si e parlato sopra e ottenendo tutti i

benefici di un’applicazione scritta per uno specifico sistema operativo.

2

1. INTRODUZIONE

Il progetto di tesi prende forma a partire da una toolchain composta da una web app,

che permette di creare un modello astratto di un’applicazione tramite un semplice

editor grafico, e un’applicazione nativa per PC che traduce il modello generato pre-

cedentemente in codice sorgente per Android e iOS, creata originariamente da altri

tesisti che mi hanno preceduto. Il mio compito e stato dunque riprogettare parzial-

mente la toolchain, per renderla uno strumento in grado di produrre applicazioni che

rispettino gli standard qualitativi delle app di ultima generazione: poiche essa e stata

sviluppata originariamente nel 2012-13, attualmente non e piu in grado di soddisfare

le esigenze del mercato, ma nonostante questo, mi ha permesso di partire da un eco-

sistema gia di per se completo e funzionante, senza dover progettare tutto dal principio.

Di seguito e riportata una breve descrizione del contenuto di ciascun capitolo della tesi:

� Il secondo capitolo descrive il contesto attuale dello sviluppo di applicazioni mobili

multipiattaforma, a partire dai tool di prototipizzazione interattiva, fino agli

strumenti per sviluppare applicazioni cross-platform o in codice nativo.

� Il terzo capitolo illustra la struttura della web app in grado di generare il modello

astratto di un’applicazione mobile e quali siano stati gli interventi apportati al

fine di renderla uno strumento oggi valido e competitivo.

� Il quarto capitolo illustra invece la struttura dell’applicazione in grado di tradurre

il modello astratto in codice nativo, con tutte le modifiche introdotte personal-

mente, al fine di generare tutto cio che di nuovo e stato inserito nella web app

descritta nel capitolo precedente.

� Il quinto capitolo presenta dunque un’analisi quantitativa e qualitativa degli stru-

menti che sono stati sviluppati, prendendo come riferimento un’applicazione pro-

gettata senza di essi, e mettendo in evidenza quanto e stato possibile generare

automaticamente.

� Il sesto capitolo infine, riporta le considerazioni conclusive sul lavoro svolto e

illustra i possibili sviluppi futuri.

3

Capitolo 2

Contesto generale

In questo capitolo viene presentato il contesto generale in cui si trovano ad operare

gli sviluppatori di applicazioni per dispositivi mobili, con una breve parentesi sugli

strumenti di supporto alla fase di prototipizzazione e concentrandosi in particolar modo

sugli strumenti effettivamente utilizzabili per lo sviluppo vero e proprio. Vengono

prese in considerazione alcune tra le migliori possibilita presenti oggi sul mercato, per

evidenziare quali possano essere i fattori determinanti nel garantire uno sviluppo rapido

e ottimizzato per le piattaforme iOS e Android, tenendo conto del risultato finale sia

in termini di prestazioni, sia in relazione alla qualita dell’interfaccia grafica prodotta.

2.1 Stato dell’arte

Al termine della fase di design di un’applicazione, in cui vengono definiti tutti i requisiti

del software e viene descritta accuratamente l’architettura e l’interazione delle varie

componenti, comincia il processo di sviluppo vero e proprio; generalmente la stesura

del codice sorgente viene pero preceduta da una fase di prototipizzazione, che consiste

nella realizzazione di una versione dimostrativa dell’applicativo in grado di simulare il

comportamento dell’interfaccia grafica e possibilmente la navigazione dei contenuti. In

questa sezione viene illustrato lo stato dell’arte del processo di sviluppo.

4

2. CONTESTO GENERALE

2.1.1 Applicazioni di prototipizzazione

Le applicazioni di prototipizzazione sono uno strumento fondamentale nella progetta-

zione di un’applicazione di successo: sebbene Apple faccia della qualita dell’interfaccia

grafica un suo valore fondante da sempre, anche Google ha ormai da anni dettato le li-

nea guida su cio che un applicazione Android dovrebbe sempre rispettare, il cosiddetto

Material Design [20].

Si riportano di seguito i maggiori tool di prototipizzazione per applicazioni mobili

disponibili sul mercato.

FluidUI

Si tratta di una web app che permette lo sviluppo di un prototipo tramite widgets:

l’utente puo creare un certo numero di schermate per poi decorarle con i controlli for-

niti dall’editor dell’applicazione, ed eventualmente puo gestire la navigazione tramite

bottoni o gestures. FluidUI permette di simulare il comportamento dell’applicazione

tramite un web player oppure di esportare semplicemente le immagini delle varie scher-

mate; il piano gratuito prevede un limite di 1 progetto di 10 schermate, mentre il piano

piu economico costa 12$/mese e garantisce un numero illimitato di schermate. [21]

Figura 2.1: Interfaccia grafica di FluidUI

5


Proto.io

Anche Proto.io e distributo sottoforma di web app e come il precedente tool, permette

lo sviluppo di un prototipo tramite l’utilizzo di widgets: l’utente puo creare un certo nu-

mero di schermate per poi decorarle con i controlli forniti dall’editor dell’applicazione,

ed eventualmente puo gestire la navigazione tramite bottoni o gestures. L’applicazione

permette di simulare il comportamento del prototipo direttamente su di un dispositivo

reale, grazie all’app mobile di Proto.io che puo essere installata sullo smartphone e

riprodurre il prototipo generato via web; in alternativa e sempre possibile scaricare le

immagini delle varie schermate. Il piano gratuito e disponibile per un periodo di prova

di 15 giorni, mentre il piano piu economico costa 29$/mese e permette di gestire fino

a 5 progetti differenti. [22]

Figura 2.2: Interfaccia grafica di Proto.io

6


InvisionApp

Si tratta anche in questo caso di un’applicazione di prototipizzazione disponibile via

web, ma a differenza delle due precedenti si basa su di un approccio completamente

differente: l’utente puo solamente caricare delle immagini che ha precedentemente rea-

lizzato tramite un’altra applicazione di manipolazione delle stesse e posizionarle all’in-

terno delle varie schermate. Per rendere interattivo il prototipo, e possibile selezionare

alcune aree all’interno di una specifica schermata e trasformarle in dei collegamenti

che permettano di navigare tra i vari contenuti. La simulazione del comportamento

dell’applicazione puo avvenire sia tramite un web player, sia direttamente su di un

dispositivo reale, scaricando l’app di InvisionApp sul proprio smartphone. Il piano

gratuito e disponibile per un periodo di prova di 7 giorni, mentre il piano piu econo-

mico costa 15$/mese e permette di gestire fino a 3 progetti differenti. [23]

Figura 2.3: Interfaccia grafica di InvisionApp

7


Pixate

Si tratta di un’applicazione nativa per PC disponibile per le piattaforme Windows [25]

e OSX [26], corredata anch’essa da un’app per smartphone che permette di simulare

il comportamento del prototipo direttamente sul proprio dispositivo; anche Pixate e

uno strumento di prototipizzazione basato su immagini, percio e necessario ancora una

volta, creare prima le immagini delle schermate dell’applicazione e poi eventualmente

aggiungervi delle aree cliccabili che permettano la navigazione dei contenuti. La qualita

di un prototipo realizzato con questo tipo di applicazioni, dipende molto dall’abilita

dell’utente nell’utilizzo di applicazioni di elaborazione delle immagini, in quanto questi

strumenti forniscono solamente un supporto nel dimensionamento delle immagini che

vengono inserite nelle diverse schermate. [24]

Figura 2.4: Interfaccia grafica di Pixate

Allo stato attuale delle cose questo genere di applicazioni, indipendentemente dall’ap-

proccio basato su widgets o su immagini, rimane esclusivamente rilegato alla fase di

prototipizzazione, senza poter dare alcun contributo concreto alla stesura del codice

sorgente; nonostante il buon livello di interattivita, non e possibile estrarre alcun tipo

di informazione che possa essere riutilizzata automaticamente nella fase di sviluppo del

software vero e proprio.

8


2.1.2 Applicazioni per sviluppatori

Le applicazioni per sviluppatori rappresentano il cuore della progettazione di un’ap-

plicazione mobile: indipendentemente dal fatto che sia stato sviluppato o meno un

prototipo, esse rappresentano lo strumento tramite il quale avviene la stesura vera e

propria del codice sorgente e si differiscono tra loro per la tecnologia che utilizzano al

fine di generare un’applicativo per smartphone o altri dispositivi mobili. Generalmente

ci si riferisce a queste applicazioni col il termine IDE (Integrated Development Environ-

ment) poiche appunto rappresentano il cosiddetto ambiente di sviluppo del software,

in grado si fornire al programmatore tutto cio che serve per la stesura del codice sor-

gente: un editor di testo, un compilatore e/o interprete, un tool di building automatico

e solitamente un debugger. In questa sezione vengono riportati i piu celebri software

di sviluppo, suddivisi in base alla tecnologia utilizzata al fine di produrre applicazioni

mobili multipiattaforma.

2.1.2.1 Applicazioni multipiattaforma ibride

Una prima tipologia di applicazioni mobili multipiattaforma presenti oggi sul merca-

to, sono le cosiddette applicazioni ibride, ovvero realizzate tramite una tecnologia che

permette l’esecuzione dell’applicativo su qualunque tipo di dispositivo mobile, sia esso

Android, iOS o qualunque altro sistema in grado di riprodurre contenuti web.

Un applicazione ibrida nasce originariamente come una normale web app HTML5,

che viene successivamente incapsulata in una generico involucro di contenuti web (la

cosiddetta WebView) disponibile nativamente su tutti i dispositivi mobili: in pratica e

come se il dispositivo mostrasse una normale pagina web, costruita con le tradizionali

tecnologie HTML5, CSS3 e Javascript. E bene precisare che solitamente una web app

viene progettata tramite il paradigma SPA (Single Page Application), ovvero viene

simulata la navigazione dei contenuti rimpiazzando gli elementi presenti nella pagina

ogni volta che viene cliccato un link, dando la senzazione di navigare all’interno di una

vera e propria applicazione, piuttosto che su di un normale sito web: tutto questo e

oggi possibile grazie a librerie Javascript come AngularJS [27].

9


Per quando riguarda lo sviluppo del software, in questo contesto si fa riferimento piu

precisamente a dei framework, ovvero l’architettura logica di supporto che permette

l’incapsulamento della web app in una generica WebView: il piu celebre dei framework

per applicazioni ibride multipiattaforma e attualmente Apache Cordova [28]. Cio

che rende questo framework un vero e proprio strumento di sviluppo per applicazioni

mobili, e il fatto che la web app non viene solamente impacchettata in un contenitore

diverso dal semplice browser, ma fornisce delle API (Application Programming Inter-

face) che lo sviluppatore puo utilizzare per accedere a tutte le funzionalita esclusive

di un dispositivo mobile, come l’accesso in memoria, alla fotocamera o ai vari sensori

presenti sullo smartphone.

2.1.2.2 Applicazioni cross-compilate o interpretate

Una seconda tipologia di sviluppo di applicazioni mobili multipiattaforma e quella che

segue l’approccio della cross-compilazione: si tratta di utilizzare un solo linguaggio di

programmazione, indipendentemente dal numero di piattaforme sulle quali verra di-

stribuita l’applicazione, poiche tramite la cross-compilazione sara possibile tradurre il

codice sorgente in eseguibili compatibili con la piattaforma desiderata.

Il principio che sta alla base di questo approccio e il cosiddetto “write once, run any-

where” ovvero scrivi una sola volta, esegui ovunque; le applicazioni che seguono questa

filosofia generalmente forniscono un IDE dedicato con tutti gli strumenti necessari allo

sviluppo come se si stesse lavorando in ambiente nativo.

Xamarin

E il piu famoso ambiente di sviluppo che sfrutta esattamente il principio della cross-

compilazione: l’applicazione puo essere scritta interamente in C# per poi essere tradot-

ta in eseguibili compatibili con le piattaforme Android e iOS. Xamarin, inoltre, fornisce

tutte le API necessarie per accedere alle risorse hardware del dispositivo mobile, an-

che se per sviluppare contemporaneamente per Android e iOS, e necessario creare due

sotto-progetti distinti per le due piattaforme: di conseguenza, la quantita di codice che

viene sfruttato in maniera totalmente orizzontale e solamente una piccola parte.

10


Ad esempio, tramite le cosiddette Xamarin.Form, e possibile definire l’interfaccia gra-

fica dell’applicazione una sola volta per entrambi i sistemi operativi, ma in generale

e necessario implementare due logiche applicative distinte per le due piattaforme. Lo

sviluppo di applicazioni Xamarin e supportato da un IDE dedicato chiamato Xamarin

Studio sui sistemi OSX oppure tramite un estensione di Visual Studio [29] sui sistemi

Windows. [30]

Figura 2.5: Esempio di progetto Xamarin in Visual Studio

Appcelerator Titanium

E un’ambiente di sviluppo completamente basato sull’utilizzo di Javascript: tramite

l’SDK (Software Development Kit) Titanium, e possibile comporre tutta la logica appli-

cativa e l’interfaccia grafica dell’applicazione, sfruttando solamente questo linguaggio.

Titanium infatti, fornisce tutte le API necessarie per interagire con il dispositivo mobi-

le indipendentemente dalla piattaforma finale: e possibile infatti compilare il progetto

scritto interamente in Javascript e ottenere delle normali classi Java per Android e

Objective-C per iOS. Tuttavia, all’interno delle classi generate da Titanium, non vi e

11


un normale sviluppo del codice sorgente come avverrebbe in ambiente nativo, ma bensı

vengono semplicemente richiamati i motori Javascript del dispositivo (ad esempio V8

[31] per Android) al fine di interpretare a run-time il codice Javascript originale: non si

tratta dunque di una vera e propria cross-compilazione ma piu precisamente di un’in-

terpretazione. Lo sviluppo di applicazioni Titanium e supportato da un IDE dedicato

chiamato Titanium Studio [32] disponibile gratuitamente solo per un periodo di prova.

[33]

Figura 2.6: Esempio di classe Java generata con Titanium

React Native

Si tratta anche in questo caso di applicazioni mobili multipiattaforma basate interamen-

te su Javascript, dove sia la logica applicativa che l’interfaccia grafica, sono realizzate

utilizzando solamente questo linguaggio: come nel caso di Titanium, e possibile compi-

lare il progetto scritto completamente in Javascript e ottenere delle normali classi Java

per Android e Objective-C per iOS. Tutti i componenti grafici vengono definiti con una

sintassi basata su XML e durante l’interpretazione a run-time della logica applicativa,

essi vengono istanziati come dei veri e propri componenti nativi, con i conseguenti be-

nefici per quanto riguarda il look-and-feel dell’applicazione; inoltre, i componenti non

12


disponibili all’interno di React Native, possono essere definiti all’interno delle classi

Java o Swift e richiamati dalle classi Javascript del progetto, estendendo dunque le

funzionalita basilari di questo framework. [34]

NativeScript

Anche questo strumento si basa sugli stessi principi gia evidenziati per Titanium e

React Native, ovvero la scrittura del codice sorgente totalmente in Javascript ed la sua

interpretazione a run-time sul dispositivo reale, per richiamare nativamente le funzio-

nalita del sistema operativo utilizzato. La grande differenza rispetto ai due precedenti

framework, sta nel fatto che NativeScript non implementa solamente dei moduli che

espongano le API Javascript, ma permette anche di utilizzare direttamente tutti i me-

todi disponibili per iOS e Android, seguendo esattamente la stessa sintassi descritta

nella documentazione dalle due piattaforme. Questo permette di spingere al massimo il

livello di performance dell’applicazione, sempre nell’ambito comunque di un’esecuzione

Javascript interpretata, e di non avere alcun limite riguardo i componenti disponibili o

eventuali aggiornamenti delle piattaforme iOS e Android. [35]

2.1.2.3 Applicazioni native

Gli approcci descritti fino ad ora, sebbene in apparenza risultino delle soluzioni conve-

nienti per poter riutilizzare la stessa applicazione su piattaforme differenti, sono soggetti

ad alcune criticita sia in termini di prestazioni, sia in termini di qualita dell’interfaccia

grafica prodotta.

Per quanto riguarda le applicazioni ibride, nonstante ci sia un riutilizzo al 100% del

codice sorgente, il risultato in termini di prestazioni puo risultare particolarmente sca-

dente per applicazioni di una certa dimensione, in quanto tutte le risorse del dispositivo

sono concentrate nel riprodurre una web app all’interno di una semplice WebView. Inol-

tre, l’interfaccia grafica e generalmente poco fedele all’aspetto nativo della piattaforma

mobile, anche utilizzando dei framework dedicati a generare interfacce specifiche per

ciascun sistema operativo, come ad esempio Ionic Framework [36].

13


Utilizzando invece l’approccio della cross-compilazione, si possono riscontrare criticita

differenti in base alla tecnologia utilizzata: nel caso di Xamarin, il codice completamen-

te riutilizzabile su piattaforme differenti e in realta solo quello riguardante la gestione

dei dati o eventualmente, quello dedicato all’interfaccia grafica (Xamarin.Form) che

comunque non e equiparabile a quella creata tramite gli ambienti di sviluppo nativi.

Nel caso infine di applicazioni basate su Javascript, poiche non si tratta di una vera

e propria cross-compilazione ma semplicemente di un’interpretazione a run-time della

logica applicativa, le prestazioni possono risultare notevolmente inferiori, oltre al fatto

che non sempre sono disponibili tutte le API e i componenti grafici offerti naturalmente

in ambiente nativo.

Per queste ragioni, e talvolta indispensabile scegliere di intraprendere uno sviluppo

completamente nativo per ciascuna piattaforma, utilizzando gli ambienti di sviluppo

predefiniti per Android e iOS ovvero rispettivamente Android Studio [37] e Xcode [38].

Un approccio di questo tipo naturalmente, non genera problemi di scarsa qualita dell’in-

terfaccia grafica, ne tantomeno problemi di prestazioni o accesso alle risorse hardware

del dispositivo, sebbene si tratti di sviluppare due applicazioni completamente distinte

per ciascuna piattaforma.

14


2.2 Obiettivo della tesi

Stabilito che non sia possibile in alcun caso superare la qualita ne tantomeno le pre-

stazioni di un’applicazione mobile nativa, ci si chiede se sia possibile ridurre il tempo

necessario allo sviluppo di un’applicativo su due piattaforme differenti, sfruttando le

informazioni contenute nel prototipo dell’applicazione. L’obiettivo di questa ricerca e

quello di far si che durante la realizzazione del prototipo dell’applicazione, sia possibile

conservare le sue caratteristiche all’interno di un modello di dati strutturato, che possa

essere riutilizzato per generare del codice nativo per piu piattaforme differenti.

Un approccio di questo tipo, ovvero quello di generare applicazioni per diverse piat-

taforme a partire da un unico modello ad alto livello, prende il nome di approccio

model-driven o model-driven development ed e stato concettualmente sviluppato anche

nell’ambito di applicazioni mobili multipiattaforma [39][40]. In generale, l’idea e quella

di descrivere l’applicativo mobile secondo un modello ad alto livello, per poi procedere

ad una generazione model2text del codice sorgente, eventualmente passando attraver-

so ulteriori modelli specifici per ciascuna piattaforma (traduzione model2model). In

ambito nativo, e stato anche sviluppato un framework chiamato md 2 [41] che pero

si basa sulla definizione del modello dell’applicazione in maniera puramente testuale:

cio che manca dunque, e la possibilita di generare un modello in maniera semplice ed

intuitiva, come puo essere un’applicazione che metta a disposizione un editor grafico

simile a quello delle tradizionali app di prototipizzazione. [42]

Esiste sul mercato uno strumento recentemente sviluppato che fa al caso nostro, chia-

mato Neonto Studio [43]: si tratta un’applicazione disponibile solamente su OSX in

grado di generare automaticamente un progetto Android Studio e/o un progetto Xcode

a partire da un semplice prototipo realizzato graficamente. Attualmente supporta una

buona quantita di widgets per smartphone come bottoni, campi di testo, immagini, vi-

deo, webviews, liste, griglie e un bottone che richiama in automatico la fotocamera del

dispositivo; nella versione a pagamento (99$ una tantum) inoltre, permette lo sviluppo

di applicazioni per smartwatch, ma solamente di casa Apple.

15


In alternativa, esiste una toolchain di strumenti sviluppata per lo stesso scopo da alcuni

tesisti che mi hanno preceduto, in grado di ottenere il medesimo risultato, almeno sulle

piattaforme smartphone: si tratta di Protocode [44], creato nel 2013 da Mattia Natali,

e MobileCodeGenerator [60], sviluppato da Gregorio Perego e Stefania Pezzetti nel

2012; il primo strumento permette la creazione del prototipo di un’applicazione mobile,

e produce un file di informazioni che, dato in input al secondo applicativo, genera i

progetti Android e iOS automaticamente. Sebbene Neonto Studio sia gia indirizzato

verso il mondo degli orologi, i widget generati per smartphone sono decisamente meno

potenti di quelli disponibili su Protocode, mancando ad esempio di funzionalita come

registrare e riprodurre file audio automaticamente: per quanto riguarda invece il codi-

ce sorgente generato, entrambe le soluzioni producono del codice Java per Android e

Objective-C per iOS.

Gli elementi di notiva assoluta sul mercato sono quindi rappresentati dalla possibilita

di generare applicazioni iOS completamente scritte in codice Swift e di poter progettare

applicativi smartwatch gratuitamente per entrambi le piattaforme mobili Android Wear

e watchOS: sara dunque la toolchain Protocode/MobileCodeGenerator, completamen-

te open-source e disponibile su tutti i sistemi operativi per PC, il punto di partenza

per il lavoro descritto in questa tesi.

16


2.3 Soluzione proposta

La soluzione proposta in questo elaborato di tesi, consiste nel riprogettare buona par-

te della toolchain Protocode/MobileCodeGenerator al fine di renderla uno strumento

davvero competitivo e unico nel suo genere: poiche gli applicativi risalgono al 2012-

2013 non sono piu in grado di soddisfare le esigenze del mercato, ma possono essere

aggiornati in modo da rispettare gli standard qualitativi delle applicazioni di ultima

generazione.

Per prima cosa verra esteso il set di widget disponibile su Protocode e verra approfondi-

to il loro livello di personalizzazione, riducendo ulteriormente il lavoro delle successive

fasi di sviluppo; inoltre, la veste grafica di default dei componenti e del sistema ope-

rativo, dovra rispecchiare le ultime versioni di Android e iOS oggi disponibili sui piu

recenti dispositivi mobili, rispettivamente Android Marshmallow e iOS 9.3. Di conse-

guenza, verra aggiornato il meccanismo di generazione automatica di codice sorgente

di MobileCodeGenerator a partire da quanto introdotto su Protocode: tutti i nuovi

componenti e gli aggiornamenti introdotti in fase di prototipizzazione verranno tradot-

ti in codice nativo per le due piattaforme.

In secondo luogo verra rivisto il sistema di generazione di codice per quel che riguarda

il mondo iOS: la traduzione in Objective-C verra completamente rimpiazzata in favore

del nuovo linguaggio di casa Apple, ovvero Swift.

Si tratta certamente di una scelta che produrra risultati migliori in termini di sem-

plicita della sintassi, leggibilita del codice e quantita di file prodotti (eliminazione di

file header .h e di implementazione .m in favore di un unico file .swift); fattori che,

nonostante la continua evoluzione del linguaggio (Swift 3 e gia disponibile in preview

release nonostante la versione 2 stable sia uscita a Settembre 2015) lo rendono facile da

mantenere e aggiornare. Inoltre, le performance della prima versione di Swift erano gia

paragonabili a quelle di C++ secondo alcuni benchmarks puramente computazionali

(Greekbench 3) [61] e largamente superiori a quelle di Objective-C nell’ambito dei piu

17


noti algoritmi di ordinamento degli array [62], grazie soprattutto alle ottimizzazioni

introdotte ad-hoc a livello di compilatore [63]. Ad esempio, un compilatore Swift e in

grado di riconoscere se un metodo sia completamente vuoto e dunque evitare di effet-

tuare qualunque chiamata ad esso oppure, ipotesi piu probabile, rilevare se un oggetto

inizializzato non venga mai realmente utilizzato e dunque evitare di allocare spazio in

memoria.

Infine, verra reso possibile lo sviluppo della controparte smartwatch dell’applicazio-

ne mobile gia in fase di prototipizzazione: sara dunque possibile generare un certo

numero di schermate e arrichirle con dei widgets dedicati all’interno di Protocode, e

verra di conseguenza aggiornato MobileCodeGenerator, al fine di tradurre il prototipo

in un’applicazione per le piattaforme wearable Andriod Wear e watchOS.

Il risultato finale dovra produrre uno strumento unico nel suo genere e in grado di

supportare concretamente lo sviluppo di un’applicazione per Android e iOS, rendendo

la fase di prototipizzazione parte integrante nella stesura del codice sorgente.

18

Capitolo 3

Generazione del modello astratto

In questo capitolo viene descritto il processo di generazione del modello astratto del-

l’applicazione mobile, utilizzato per la creazione automatica di applicativi Android e

iOS. L’approccio seguito e il cosiddetto approccio model-driven che permette di de-

scrivere il funzionamento dell’applicazione con un modello del tutto trasparente alle

piattaforme per le quali questo verra successivamente implementato. L’applicazione

utilizzata per la generazione di questo modello e una web application chiamata Pro-

tocode, sviluppata originariamente nel 2013 per un precedente lavoro di tesi: vengono

qui riportate l’architettura originale dell’applicazione e come sia stata riprogettata per

gli scopi di questa ricerca. [65]

3.1 Protocode

Protocode e un applicazione web che permette all’utente di creare un prototipo di un

applicativo mobile tramite un editor grafico semplice ed intuitivo: segue il cosiddetto

paradigma WYSIWYG (What You See Is What You Get) ovvero cio che vedi e cio

che ottieni, ma a differenza di un normale strumento di prototipizzazione, Protocode

permette di esportare le informazioni contenute nel prototipo sottoforma di un file

XML e non di comuni immagini o file .pdf.

19

3. GENERAZIONE DEL MODELLO ASTRATTO

Lo scopo di questo applicativo infatti, e quello di produrre una serie di dati strutturati

relativi ad un prototipo di un’applicazione mobile, che possano essere riutilizzati per

la generazione automatica di codice sorgente nelle fasi preliminari di sviluppo, con la

semplicita di un normale editor visivo.

L’utente puo inserire e posizionare una serie di widgets all’interno delle varie schermate

dell’applicazione, proprio come in un qualunque altro strumento di prototipizzazione,

con il vantaggio che tutte queste informazioni vengono conservate in maniera struttu-

rata e possono essere successivamente accedute da un applicativo software in grado di

fare del parsing di dati in formato XML.

Vengono di seguito descritte le librerie software che costituiscono l’architettura logica

dell’applicazione web.

3.1.1 Librerie software

Protocode e una normale web app HTML5 basata sul framework Javascript Ember.js

[45], il cui sviluppo e supportato da una serie di strumenti di gestione e distribuzione

del software, oltre che da i piu classici plug-in CSS3 per la definizione dell’interfaccia

grafica.

Ember.js

Si tratta di un framework Javascript open-source basato sul pattern Model-View-

ViewModel (MVVM), che permette di creare una cosiddetta Single Page (Web) Ap-

plication: progettata sul paradigma design-over-configuration, predilige le convezioni

piuttosto che le configurazioni, liberando lo sviluppatore dalla creazione di codice che

connetta i vari componenti dell’applicazione (boilerplate code).

Utilizza Ember Data [46], una libreria per il salvataggio dei dati che mappa i modelli

lato utente a quelli lato server, usata in questo caso per salvare i dati direttamen-

te sul client che esegue l’applicazione, sfruttando in particolar modo il local storage

disponibile oggi su qualunque browser di navigazione.

20


Ember.js si fonda su alcuni concetti chiave che sono fondamentali per la comprensione

della struttura del progetto di Protocode:

� Template: Descrive una particolare interfaccia grafica dell’applicazione ed e co-

stituito da un file .hbs (handlebars) scritto in codice HTML e decorato con delle

espressioni Javascript. Ogni template fa riferimento ad uno specifico dato o in-

sieme di dati (model); la somma di tutti i template costituisce l’intera interfaccia

grafica dell’applicazione.

� View: E un componente utilizzato per definire una sezione dell’interfaccia grafica

che richiede una sofisticata interazione con l’utente: e generalmente costituita

da un file .js che ne descrive il comportamento in base a determinati eventi

(inizializzazione, click del mouse e simili) e un file .hbs che ne descrive la veste

grafica.

� Router: E il cuore di qualunque Single Page Application, in quanto stabilisce

quale template mostrare sulla base dell’URL inserito: la navigazione infatti e

solamente simulata, rimpiazzando i template ogni volta che l’utente seleziona un

link.

� Model: Si tratta di un oggetto Javascript salvato in maniera persistente, conte-

nente una serie di proprieta e metodi che vengono mostrati attraverso i template

dell’applicazione: la somma di tutti i model costituisce in pratica lo strato dei

dati dell’applicativo.

� Route: E il componente che collega ogni template al modello che deve mostrare,

e viene normalmente generato automaticamente secondo il principio di design-

over-configuration, nel momento in cui il template e il model siano stati definiti

secondo le convenzioni di Ember.

� Controller: Si tratta di un oggetto Javascript che puo essere assegnato ad un

template per definire delle caratteristiche transitorie: in pratica ogni template

mostra dei dati che sono salvati in maniera persistente nel model ed eventual-

mente alcuni dati relativi allo stato attuale dell’applicazione, che sono pero salvati

e manipolati da uno specifico controller.

21


Yeoman.io

Yeoman.io e uno strumento di scaffolding per lo sviluppo di web applications, in grado

automatizzare una serie di operazioni di gestione e distribuzione del software tramite

alcune semplici direttive dettate dal programmatore. [47]

Si descrivono in seguito i 4 tool che lo compongono :

� Yo: Strumento che genera automaticamente lo scheletro dell’applicazione, defi-

nendo la struttura del progetto e delle directory da cui esso e costituito. [48]

� Compass: Framework CSS che permette una gestione ottimizzata dei fogli di

stile, introducendo l’utilizzo di variabili all’interno dei file .scss e la possibilita di

definire dichiarazioni innestate delle classi CSS. [49]

� Grunt: E un cosiddetto task runner, ovvero uno strumento in grado di creare un

server con installata la web application e che osserva in tempo reale le modifiche

ai file dell’applicazione, oltre che compattare e unire i file Javascript e SCSS per

produrre la versione di distribuzione della web application. [50]

� Bower: Package manager che permette di installare le librerie esterne dell’ap-

plicazione, tramite la definizione di un file contenente la lista delle librerie ed una

loro eventuale versione che si intende utilizzare. [51]

Bootstrap

Si tratta di un framework per la gestione dell’interfaccia grafica di una web application,

costituito fondamentalmente da un foglio di stile e da una serie di file Javascript che

permettono di utilizzare dei componenti grafici particolarmente elaborati e interattivi;

inoltre, permette con estrema semplicita di definire il layout dell’applicazione in manie-

ra responsive, ovvero adattando i contenuti alla dimensioni dello schermo su cui viene

eseguita la web application. [52]

22


Altre librerie

Vengono di seguito descritte le altre librerie che compongono l’architettura logica di

Protocode :

� Ember Data Local Storage Adapter: Libreria Javascript che permette di

utilizzare le normali funzionalita di Ember Data per salvare i dati all’interno del

browser, nel local storage appunto. [53]

� JQuery: Framework di sviluppo dell’interfaccia grafica che sta alla base dell’u-

tilizzo di Bootstrap e che ne permette dunque il funzionamento. [54]

� Font Awesome: Kit di icone per il web. [55]

� Blob e File Saver: Librerie per il download di dati lato client, viene utilizzata

in questo caso per scaricare il file XML contente le informazioni sul prototipo

dell’applicazione mobile. [56] [57]

� vkBeautify: Libreria per indentare automaticamente il codice XML generato

dall’applicazione prima del download. [58]

23


3.1.2 Architettura software originale

In questa sezione viene presentata l’architettura originale di Protocode, cosı come si

presentava all’inizio di questo lavoro di tesi, a partire dalla gerarchia di cartelle al-

l’interno dell’applicazione, fino alla descrizione della logica dei componenti e alla loro

interazione. Si riporta di seguito la struttura gerarchica delle directory dell’applicativo:

� root: cartella principale, contiene tutte le successive cartelle e i file di confi-

gurazione di Grunt e Bower; il primo descrive i task da seguire per la normale

esecuzione su localhost e quelli per la distribuzione dell’applicazione, il secondo

invece contiene la lista delle librerie esterne e la loro versione da scaricare.

� node modules: contiene le librerie necessarie al funzionamento di Grunt e degli

altri applicativi basati su Node.js [59].

� test: contiene i file per il testing dell’applicazione.

� dist: contiene la versione di distribuzione dell’applicazione generata da Grunt,

ovvero dove i fogli di stile e i file Javascript sono compattati e unificati, rimuoven-

do il codice commentato e codificando gli script dell’applicazione, che rimarreb-

bero altrimenti accessibili a chiunque tramite la console del browser. Oltretutto,

questo processo garantisce maggiori prestazioni dell’applicazione, nel momento

in cui questa venisse pubblicata su un qualunque webserver in rete.

� app: contiene l’applicazione vera e propria, suddivisa sostanzialmente in logica

applicativa, template delle pagine, fogli di stile e immagini; al suo interno si

trovano inoltre tutte le librerie installate tramite Bower che sono state elencate

in precedenza.

Di seguito viene descritto accuratamente il contenuto della cartella app, focalizzan-

do l’attenzione sul ruolo che i vari file ricoprono nel funzionamento di Protocode: la

trattazione e suddivisa nei quattro meccanismi chiave che regolano la web application

ovvero routing, model, controller e view.

24


Figura 3.1: Struttura di Protocode

3.1.2.1 Routing

Con il termine routing si intende il meccanismo che permette di mappare l’URL presen-

te nella barra di navigazione del browser con il template che deve essere visualizzato;

oltre al router principale (app/scripts/router.js) vengono definiti anche degli ogget-

ti route, che specificano quale modello debba essere mostrato all’interno di ciascun

template. Essi si trovano all’interno della directory app/scripts/routes.

3.1.2.2 Model

Per model si intendono tutti gli oggetti che vengono salvati in maniera persistente

all’interno di Protocode: solo alcuni di questi verranno utilizzati effettivamente per la

generazione del modello astratto dell’applicazione mobile, mentre altri sono solamente

legati al funzionamento della web app; i file Javascript contenenti la descrizione dei

modelli si trovano nella cartella app/scripts/model. Si riporta di seguito un diagramma

dei modelli di Protocode che verranno cosı esportati al termine della prototipizzazione.

25


Figura 3.2: Modello logico di Protocode

26


3.1.2.3 Controller

Con il termine controller, si intende quel componente che viene assegnato ad un tem-

plate per manipolarne temporaneamente alcune caratteristiche: in pratica tutte le

informazioni mostrate dinamicamente da un template, prima di essere eventualmente

salvate in maniera persistente, sono gestite dal suo controller. I controller di Protocode

sono contenuti nella cartella app/scripts/controllers/.

A questa categoria appartengono anche i cosiddetti mixins, ovvero dei componenti

che contengono delle proprieta e dei metodi che possono essere ereditati dai controller

veri e propri, in modo da rendere piu snella e scalabile la logica applicativa: essi si

trovano nella directory app/scripts/mixins/.

Si descrivono di seguito i dettagli di ciascun mixin :

� Deletable, Saveable: contengono i metodi per la creazione e la cancellazione di

un modello dell’applicazione.

� ClickListeneable: contiene la logica necessaria per la gestione e la cancellazione

di modelli che sono collegati direttamente ad un oggetto ClickListener.

� Navigable: contiene la logica necessaria per la gestione e la cancellazione di

modelli che sono collegati direttamente ad un oggetto Navigation.

� TextAlignable: contiene i metodi per la gestione dell’allineamento orizzontale del

testo di uno specifico widget.

� WithSourceType: contiene la logica necessaria per la gestione di modelli che hanno

un particolare file sorgente (audio, immagini e video).

� UiMoveable: contiene la logica applicativa necessaria per la gestione del trasci-

namento di un widget sullo schermo del dispositivo e l’aggiornamento in tempo

reale delle sue coordinate.

� UiDroppable: contiene i metodi per la gestione del drag&drop dei widget sullo

schermo.

27


Un esempio di manipolazione della logica applicativa in cui i controller giocano un

ruolo fondamentale e la gestione del sistema dei vincoli tra i vari widget presenti sulla

schermata.

Questo sistema, e stato pensato per essere riutilizzato facilmente all’interno del Relati-

veLayout di Android e del sistema dei constraints della Storyboard di iOS : in pratica,

per supportare agilmente schermi di dimensioni differenti, e indispensabile posizionare

i componenti relativamente allo schermo che li contiene o ai componenti che popolano

la stessa schermata, tramite le proprieta presenti nel modello UiControl di Protocode.

In particolare il controller UiControlController, ogni qual volta viene aggiunto un nuo-

vo vincolo per un widget, effettua una verifica su tutti i vincoli presenti per eliminare

eventuali circolarita: ad esempio, un widget A posizionato sopra a B e un widget B

posizionato sotto ad A creano un loop nella verifica dei vincoli poiche manca una coor-

dinata di riferimento per almeno uno dei due widget. Questa circolarita viene spezzata

semplicemente rimuovendo l’ultimo vincolo inserito ed invitando quindi l’utente a ve-

rificare che non siano gia presenti tutti i vincoli necessari.

Si riporta in seguito uno schema dei controller di Protocode.

28


Figura 3.3: Schema dei controller di Protocode

29


3.1.2.4 View

Il concetto di view incorpora tutti i componenti che vengono utilizzati per la definizione

dell’interfaccia grafica dell’applicazione, e si dividono sostanzialmente in due categorie:

i template veri e propri, contenuti nella directory app/templates/, e le cosiddette view

che sono invece delle piccole porzioni di interfaccia grafica che necessitano la definizione

di una logica piu elaborata; queste ultime sono descritte da un file .hbs contenuto in

app/templates/views/ e sono manipolate da un file .js contenuto in app/scripts/views/

e possono eventualmente ereditare delle caratteristiche provenienti da un mixin esat-

tamente come i controller puri.

Sono stati definiti inoltre alcuni componenti HTML particolarmente sofisticati, che

come le view sono descritti da un file .hbs contenuto in app/templates/components/ e

sono controllati da un file .js presente in app/scripts/components/.

Tutta l’interfaccia grafica dell’applicazione e stata definita dal punto di vista pura-

mente estetico, dai fogli di stile contenuti nella directory app/styles/. In pratica, i file

Javascript che manipolano le view, permettono di rimuovere e/o aggiungere delle classi

CSS a queste ultime, sulla base di particolari eventi provocati dall’utente: ad esempio,

quando viene modificato il tipo di dispositivo presente nell’editor di Protocode, in base

alla piattaforma di questo, verranno inserite le classi CSS .android oppure .ios diret-

tamente nel DOM (Document Object Model) e si aggiornera di conseguenza l’aspetto

di tutti i componenti presenti nella schermata corrente.

Si riporta in seguito un diagramma della gerarchia delle view dell’applicazione.

30


Figura 3.4: Gerarchia delle view di Protocode

31


3.1.3 Interfaccia grafica dell’applicazione

In questa sezione viene presentata l’interfaccia grafica originale di Protocode, mostran-

do come l’utente possa effettivamente creare un prototipo di un applicazione mobile ed

esportare il modello astratto di questa.

Innanzitutto, nella barra di navigazione in alto sono presenti i controlli per creare

o eliminare il modello che si vuole generare, e un collegamento all’editor grafico ve-

ro e proprio; all’interno di questa sezione dunque, e possibile rinominare il modello e

cominciare la creazione delle varie schermate, che possono essere visualizzate in moda-

lita Android oppure iOS semplicemente selezionando il corrispondente dispositivo dallo

specifico menu a tendina.

Infine, in alto a destra, e presente un bottone che permette da qualunque sezione

di scaricare il modello dell’applicazione generata fino a quel momento.

Figura 3.5: Anteprima applicazione Android su Protocode

32


Figura 3.6: Anteprima applicazione iOS su Protocode

Smartphones

L’anteprima dell’applicazione e disponibile in versione iOS 7 su di un iPhone 5s oppure

in modalita Android KitKat su di un Google Nexus 5 : e possibile decorare le schermate

dell’applicazione semplicemente trascinandoci sopra i widget presenti nel pannello in

basso a sinistra oppure modificarne alcune caratteristiche tramite il pannello di destra.

Naturalmente, l’aspetto dell’anteprima e perfettamente fedele al risultato finale del-

l’applicazione, poiche la dimensione delle schermate e dei componenti viene calcolata

prendendo in considerazione la dimensione dell’immagine .png del dispositivo, la di-

mensione reale dello schermo del dispositivo e scalando proporzionalmente tutti i com-

ponenti; quest’ultima in particolare, viene definita in base alla sua densita di pixel,

piuttosto che alla sua generica risoluzione, cosı come avviene all’interno degli IDE di

sviluppo nativi. Ogni dispositivo mobile infatti, nonostante esistano in commercio in-

numerevoli risoluzioni, e caratterizzato da una certa densita di pixel, ovvero il rapporto

fra il numero di pixel presenti sullo schermo e la sua dimensione in cm o pollici: que-

sto consente di utilizzare un’unita di misura astratta, i points per iOS e i dp (density

pixels) per Android, che permetta di dire quanto sia “grande” un particolare schermo

in termini assoluti.

33


Dunque, tramite il pannello di destra, e possibile aggiungere per ogni schermata un

certo numero di dialogs e definire un eventuale menu di navigazione: per iOS e stato

adottata la navigazione tramite la Bottom Bar in basso nello schermo, mentre per

Android si e scelto di replicare per ogni schermata il classico menu a tendina in alto.

Widgets

Una volta trascinato un widget sullo schermo, e possibile selezionarlo per modificarne

la dimensione, il posizionamento e alcune caratteristiche specifiche di quel componen-

te; il pannello di destra contenente le informazioni generali della schermata, viene

rimpiazzato da un pannello suddiviso nelle tre seguenti sezioni :

� Caratteristiche, che permette di modificare le proprieta specifiche del componente

� Posizione, che permette di modificare le coordinate X,Y del componente sia in

termini assoluti che relativamente allo schermo e agli altri componenti

� Dimensione, che permette di impostare l’altezza, la larghezza e i margini del

componente

Si riporta in seguito una tabella esplicativa di tutti i widget presenti su Protocode.

Widget Android iOS Personalizzazione

ButtonBottone grigio con

testo nero

Bottone bianco con

testo azzurro

Testo

ClickListener

Posizione

Dimensione

Label Testo nero Testo nero

Testo

Allineamento del testo

Posizione

Dimensione

34


EditTextCampo di input

con bordo inferiore

Casella di input

con bordo

arrotondato

Testo

Placeholder

Posizione

Dimensione

WebViewRettangolo verde

con icona del globo

Rettangolo azzurro

con la scritta

UIWebView

Nome del file sorgente

Posizione

Dimensione

ImageView

Rettangolo verde

con icona di

un’immagine

Rettangolo azzurro

con la scritta

UIImageView

Tipo di sorgente

URI del file sorgente

Posizione

Dimensione

VideoView

Rettangolo verde

con icona di una

videocamera

Rettangolo azzurro

con icona di una

videocamera

Tipo di sorgente


Posizione

Dimensione

AudioPlayer

Contenitore di 3

bottoni grigi

allineati con la

scritta nera play,

pause, stop

Contenitore di 3

bottoni bianchi

allineati con la

scritta azzurra

play, pause, stop

Tipo di sorgente


Posizione

Dimensione

ListViewContenitore

trasparente

Contenitore

trasparente

ClickListener

Posizione

Dimensione

ListViewCell

Cella orizzontale

contenente solo

testo

Cella orizzontale

contenente solo

testo

Testo

GridViewContenitore

trasparente

Contenitore

trasparente

ClickListener

Posizione

Dimensione

35


GridViewCell

Cella quadrata

contenente solo

testo

Cella quadrata

contenente solo

testo

Testo

Photocamera

Controller

Bottone grigio con

la scritta nera

“Fotocamera”

Botton bianco con

la scritta azzurra

“Fotocamera”

ImageView di

anteprima

(hardwareFile)

Posizione

Dimensione

Videocamera

Controller

Bottone grigio con

la scritta nera

“Videocamera”

Bottone bianco con

la scritta azzurra

“Videocamera”

VideoView di

anteprima

(hardwareFile)

Posizione

Dimensione

Audio

Recorder

Bottone grigio con

la scritta nera

“Rec”

Bottone bianco con

la scritta azzurra

“Rec”

AudioPlayer di

anteprima

(hardwareFile)

Posizione

Dimensione

Menu

Menu a lista a

destra della

ActionBar

TabBar in basso

nella schermata

Tabella 3.1: Tabella dei widget di Protocode

36


3.2 Aggiornamento di Protocode

In questa sezione vengono presentate tutte le modifiche e gli aggiornamenti che sono

stati apportati all’applicazione, in modo da poter soddisfare le esigenze di questo lavoro

di tesi: seguendo lo stesso percorso utilizzato per la descrizione dell’architettura del

software originale, verranno descritti gli interventi apportati all’applicativo e il risulta-

to finale raggiunto.

Come gia anticipato, l’obiettivo principale per quel che riguarda la fase di prototi-

pizzazione su Protocode era quello di estendere la possibilita di creare un modello

anche per la controparte smartwatch dell’applicazione: in altre parole, e stato reso

possibile gestire sia l’interfaccia grafica dell’applicazione mobile, sia quella che verra

eventualmente installata sullo smartwatch. Per fare questo, si e dovuto quindi creare

un editor dedicato agli orologi, con i relativi widget tipici di quell’ambiente, e modifi-

care il modello alla base di Protocode in maniera da poter esportare un file XML che

comprendesse le informazioni relative ad entrambi i dispositivi.

Prima di tutto pero, e stato approfondito il livello di personalizzazione dei componenti

disponibili per smartphone e sono stati introdotti i widget piu recenti, poiche quelli gia

presenti erano ormai praticamente obsoleti o comunque scarsamente personalizzabili in

fase di prototipizzazione.

3.2.1 Design della logica applicativa

L’intervento sulla logica applicativa di Protocode e stato diviso sostanzialmente in due

fasi: nella prima, si e scelto di agire “in verticale” ovvero si e andata ad approfondire

la modellizzazione di tutti i componenti presenti e del sistema operativo mostrato

nell’editor grafico; nella seconda invece, si e ridefinito il funzionamento dell’applicativo

dando la possibilita all’utente di creare una controparte smartwatch dell’applicazione

con conseguenze anche sui modelli e i sui template originali. La trattazione verra

ancora una volta mostrata focalizzandosi sugli elementi chiave della web application

ossia routing, model, controller e view.

37


3.2.1.1 Routing

Per quanto riguarda il routing dell’applicazione, e stato necessario innanzitutto esten-

dere i percorsi disponibili, introducendo le risorse relative ai nuovi widget che sarebbero

stati creati: in pratica, e stato modificato il router principale per configurare gli URL

che collegano i modelli dei nuovi widget, ai rispettivi template dell’interfaccia grafica.

In secondo luogo, e stato introdotto un percorso di navigazione “parallelo” a quello

principale, che permettesse di scegliere se aprire l’editor grafico dello smartphone op-

pure quello dello smartwatch e mostrare di conseguenza il rispettivo dispositivo e i

widget ad esso associati.

3.2.1.2 Model

Lo strato dei dati dell’applicativo e quello che piu di tutti ha subito una riprogettazio-

ne, poiche e da questo che deriva il modello finale che verra esportato al termine della

prototipizzazione.

Per prima cosa, sono stati rimodellati i widget disponibili, aggiungendo numerose carat-

teristiche che sarebbero diventate quindi personalizzabili gia all’interno di Protocode;

per alcuni di questi e stato necessario intervenire anche sul sistema di posizionamento,

forzando alcune caratteristiche che altrimenti avrebbero prodotto dei risultati sgrade-

voli alla fine della traduzione in codice nativo. Un esempio di rimodellazione partico-

larmente approfondita dei widget e stato quello delle ListView e delle GridView, che

sono state trasformate in modo da poter contenere oltre che a del semplice testo, anche

delle immagini o delle icone, fondamentali per un’interfaccia grafica di buona qualita.

In seguito, sono stati introdotti i nuovi modelli relativi ai widget non ancora esistenti,

con le relative caratteristiche e vincoli di dimensione e posizionamento: sono stati crea-

ti praticamente tutti i widget oggi disponibili negli IDE Android Studio e Xcode, come

mappe, pickers e bottoni di ogni genere; sono stati quindi introdotti gli smartphone

di ultima generazione di casa Google e Apple con i relativi sistemi operativi alla loro

ultima versione.

38


Infine, sono stati creati i modelli per i dispositivi smartwatch e una serie di widget

disponibili sulle piattaforme Android Wear e watchOS, con delle caratteristiche del

tutto simili a quelli per smartphone in termini di posizionamento e dimensione; at-

tualmente, solo le applicazioni per Android Wear permettono un posizionamento dei

componenti completamente libero, mentre su watchOS possono solo essere organizzati

verticalmente o in delle griglie chiamate groups, ma non e escluso che in futuro possa

essere introdotto un sistema di vincoli simile a quello per iPhone, ragion per cui si e

scelto di non limitare a priori il posizionamento dei vari widget.

Si riporta in seguito il diagramma dei modelli di Protocode nella sua versione fina-

le: sono indicati in verde i modelli che hanno subito delle modifiche e tutti i nuovi

modelli e relazioni che sono stati introdotti. Si descrive quindi ciascun componente e

le sue caratteristiche, per evidenziare la profondita con cui questi siano stati modellati

e quanto dunque sara possibile tradurre automaticamente senza alcun intervento nella

fase di stesura del codice sorgente.

39


Figura 3.7: Modello logico finale di Protocode

40


Application

Elemento radice del modello astratto XML esportato da Protocode

Attributi

name identificativo che rappresenta il nome dell’applicazione mobile

Relazioni

menu relazione 0:1 tra l’applicazione e il suo menu

viewControllers relazione 0:n tra l’applicazione e le sue schermate smartphone

watchControllers relazione 0:n tra l’applicazione e le sue schermate smartwatch

ViewController

Rappresenta una singola schermata dell’applicazione su smartphone

Attributi

name identificativo che rappresenta il nome della schermata

backgroundColor stringa che indica il colore dello sfondo

backgroundImage stringa che indica il nome dell’immagine di sfondo

launcher booleano che indica se sia la prima schermata a comparire

Relazioni

application relazione 1:1 tra la schermata e l’applicazione

uiPhoneControls relazione 0:n tra la schermata e i suoi widgets

alertDialogs relazione 0:n tra la schermata e i suoi dialog di conferma

progressDialogs relazione 0:n tra la schermata e i suoi dialog di progresso

asyncTasks relazione 0:n tra la schermata e i suoi task asincroni

WatchController

Rappresenta una singola schermata dell’applicazione su smartwatch

Attributi

name identificativo che rappresenta il nome della schermata

launcher booleano che indica se sia la prima schermata a comparire

Relazioni

application relazione 1:1 tra la schermata e l’applicazione

uiWatchControls relazione 0:n tra la schermata e i suoi widgets

41


Dialog

Rappresenta un dialog visualizzabile in una determinata schermata su smartphone

Attributi

name identificativo che rappresenta il nome del dialog

title stringa che indica il titolo del dialog

message stringa che indica il messaggio contenuto nel dialog

Dialog - AlertDialog

Rappresenta un dialog con bottoni di conferma

Dialog - ProgressDialog

Rappresenta un dialog per un attivita in corso

Attributi

spinner booleano che indica se visualizzare uno spinner

AsynchTask

Rappresenta un task asincrono eseguito in background su smartphone

Attributi

name identificativo che rappresenta il nome del task asincrono

Menu

Rappresenta il menu di navigazione dell’applicazione su smartphone

Relazioni

menuItems relazione 0:n tra il menu e le voci che lo compongono

MenuItem

Rappresenta una singola voce del menu

Attributi

name identificativo della voce del menu

title stringa che indica il nome da visualizzare nella voce del menu

Relazioni

navigation relazione 1:1 tra la voce del menu e un oggetto di navigazione

parentMenu relazione 1:1 tra la voce del menu e il menu che lo contiene

42


Navigation

Rappresenta un oggetto di navigazione utilizzato come ponte tra il componente per

smartphone che richiede la navigazione e la schermata di destinazione

Relazioni

destination relazione 1:1 tra Navigation e la sua destinazione

WatchNavigation

Rappresenta un oggetto di navigazione utilizzato come ponte tra il componente per

smartwatch che richiede la navigazione e la schermata di destinazione

Relazioni

destination relazione 1:1 tra WatchNavigation e la sua destinazione

ClickListener

Rappresenta un oggetto utilizzato come punto di collegamento tra tutti i componenti

per smartphone che possono richiedere una navigazione e l’oggetto di navigazione

Relazioni

navigation relazione 0:1 tra ClickListener e Navigation

WatchClickListener

Rappresenta un oggetto utilizzato come punto di collegamento tra tutti i componenti

per smartwatch che possono richiedere una navigazione e l’oggetto di navigazione

Relazioni

navigation relazione 0:1 tra WatchClickListener e WatchNavigation

SourceType

Rappresenta un oggetto astratto utilizzato per i componenti che necessitano di un

particolare file sorgente (immagini, video, audio)

Attributi

type stringa che indica il tipo di file sorgente: risorsa di progetto

(localFile), file remoto (remoteFile) oppure proveniente dal

dispositivo (hardwareFile)

fileUri stringa che indica l’URL del file sorgente di tipo remoto

43


UiControl

Rappresenta un widget che puo essere aggiunto ad una schermata.

E la superclasse da cui ereditano tutti widget per smartphone e smartwatch, i quali

pero, potranno essere messi in relazione solo fra di loro poiche appartengo ovviamente

a schermate differenti.

Attributi

name identificativo che rappresenta il nome del widget

posX, posY float che indicano le coordinate del widget

width, height float che indicano la larghezza e l’altezza del widget

padding float che indica il margine interno al bordo del widget

margin float che indica il margine esterno al bordo del widget

alignParent booleano che indica se il widget e allineato al bordo

superiore,destro, inferiore e/o sinistro della schermata

xmlName stringa che indica il nome dell’elemento nel modello XML che

verra esportato da Protocode

UiPhoneControl

Rappresenta un widget che puo essere aggiunto a una schermata su smartphone.

Relazioni

viewController relazione 1:1 tra il widget e la sua schermata

align relazione 0:1 tra i widgets che permette di allinearli

relativamente l’uno all’altro

above relazione 0:1 tra i widgets che permette di posizionarne uno

sopra l’altro

below relazione 0:1 tra i widgets che permette di posizionarne uno

sotto l’altro

toStartOf relazione 0:1 tra i widgets che permette di posizionare l’estre-

mo destro del widget all’estremo sinistro di un altro, ovvero

all’inizio

toEndOf relazione 0:1 tra i widgets che permette di posizionare l’estre-

mo sinistro del widget all’estremo destro di un altro, ovvero

alla fine

44


UiPhoneControl - AudioPlayer

Rappresenta un contenitore dei bottoni play, pausa, stop posizionabile sulla schermata

Relazioni

sourceType relazione 1:1 tra l’AudioPlayer e il tipo di file sorgente

UiPhoneControl - AudioRecorder

Rappresenta un bottone che richiamera la funzione di registratore del dispositivo.

Relazioni

audioPlayer relazione 0:1 tra l’AudioRecorder e l’eventuale AudioPlayer

UiPhoneControl - Button

Rappresenta un bottone posizionabile sulla schermata

Attributi

title stringa che indica il testo contenuto nel bottone

textColor stringa che indica il colore del testo contenuto nel bottone

backgroundColor stringa che indica il colore di sfondo del bottone

clickColor stringa che indica il colore di sfondo al momento del click

borderRadius intero che indica l’arrotondamento dei bordi del bottone

Relazioni

clickListener relazione 0:1 tra il bottone e l’oggetto ClickListener

UiPhoneControl - Card

Rappresenta una Cardview posizionabile sulla schermata

Attributi

title stringa che indica il titolo contenuto nella card

subtitle stringa che indica il sottotitolo contenuto nella card

numActions intero che indica il numero di bottoni disponibili nella card

UiPhoneControl - Datepicker

Rappresenta un calendario posizionabile sulla schermata

UiPhoneControl - Timepicker

Rappresenta un orologio posizionabile sulla schermata

45


UiPhoneControl - Label

Rappresenta un’etichetta di testo posizionabile sulla schermata

Attributi

title stringa che indica il testo da visualizzare

textColor stringa che indica il colore del testo

textSize intero che indica la dimensione del testo da visualizzare

textAlign stringa che indica l’allineamento orizzontale del testo

textDecoration stringa che indica il formato del testo da visualizzare

UiPhoneControl - EditText

Rappresenta un input di testo posizionabile sulla schermata

Attributi


textColor stringa che indica il colore del testo

textSize intero che indica la dimensione del testo da visualizzare

placeholder stringa che indica un suggerimento per il campo di testo

UiPhoneControl - ListView

Rappresenta una lista di elementi posizionabile sulla schermata

Attributi

backgroundColor stringa che indica il colore di sfondo della lista

listType stringa che indica il tipo di lista da visualizzare

Relazioni

clickListener relazione 0:1 tra la lista e l’oggetto ClickListener

listViewCells relazione 0:n tra la lista e gli elementi che compongono la lista

ListViewCell

Rappresenta un singolo elemento di una ListView

Attributi

name identificativo dell’elemento della lista


subtitle stringa che indica un eventuale sottotitolo da visualizzare

Relazioni

parentListView relazione 1:1 tra l’elemento e la lista che lo contiene

46


UiPhoneControl - GridView

Rappresenta una griglia di elementi posizionabile sulla schermata

Attributi

gridType stringa che indica il tipo di griglia da visualizzare

Relazioni

clickListener relazione 0:1 tra la griglia e l’oggetto ClickListener

gridViewCells relazione 0:n tra la griglia e gli elementi che la compongono

GridViewCell

Rappresenta un singolo elemento di una GridView

Attributi

name identificativo dell’elemento della griglia


Relazioni

parentGridView relazione 1:1 tra l’elemento e la griglia che lo contiene

UiPhoneControl - Map

Rappresenta una mappa posizionabile sulla schermata

Attributi

lat float che indica la latitudine a cui centrare la mappa

lon float che indica la longitudine a cui centrare la mappa

UiPhoneControl - Slider

Rappresenta uno slider posizionabile sulla schermata

UiPhoneControl - Spinner

Rappresenta un selettore di elementi posizionabile sulla schermata

UiPhoneControl - Switch

Rappresenta un bottone a interruttore (switch) posizionabile sulla schermata

47


UiPhoneControl - WebView

Rappresenta un contenitore di pagine web

Attributi

htmlFileName stringa che indica il file HTML sorgente da visualizzare

UiPhoneControl - ImageView

Rappresenta un’immagine posizionabile sulla schermata

Relazioni

sourceType relazione 1:1 tra l’ImageView e il tipo di file sorgente

UiPhoneControl - PhotocameraController

Rappresenta un bottone che richiami la fotocamera del dispositivo

Attributi

backgroundType stringa che indica se sia presente l’icona della fotocamera

Relazioni

imageView relazione 0:1 tra il PhotocameraCtrl e l’eventuale ImageView

UiPhoneControl - VideoView

Rappresenta un filmato posizionabile sulla schermata

Relazioni

sourceType relazione 1:1 tra la VideoView e il tipo di file sorgente

UiPhoneControl - VideocameraController

Rappresenta un bottone che richiami la videocamera del dispositivo

Attributi

backgroundType stringa che indica se sia presente l’icona della videocamera

Relazioni

videoView relazione 0:1 tra il VideocameraCtrl e l’eventuale VideoView

48


UiWatchControl

Rappresenta un widget che puo essere aggiunto a una schermata su smartwatch

Attributi

order intero che indica la posizione del widget dall’alto verso il basso

nella schermata

Relazioni

watchController relazione 1:1 tra il widget e la sua schermata

align relazione 0:1 tra i widgets che permette di allinearli

relativamente l’uno all’altro

above relazione 0:1 tra i widgets che permette di posizionarne uno

sopra l’altro

below relazione 0:1 tra i widgets che permette di posizionarne uno

sotto l’altro

toStartOf relazione 0:1 tra i widgets che permette di posizionare l’estre-

mo destro del widget all’estremo sinistro di un altro, ovvero

all’inizio

toEndOf relazione 0:1 tra i widgets che permette di posizionare l’estre-

mo sinistro del widget all’estremo destro di un altro, ovvero

alla fine

UiWatchControl - WatchButton

Rappresenta un bottone posizionabile sulla schermata

Attributi

title stringa che indica il testo contenuto nel bottone

Relazioni

watchClickListener relazione 0:1 tra il bottone e l’oggetto WatchClickListener

UiWatchControl - WatchLabel

Rappresenta un etichetta di testo posizionabile sulla schermata

Attributi


textAlign stringa che indica l’allineamento orizzontale del testo

textDecoration stringa che indica il formato del testo da visualizzare

49


UiWatchControl - WatchSlider

Rappresenta uno slider posizionabile sulla schermata

UiWatchControl - WatchSwitch

Rappresenta un bottone a interruttore (switch) posizionabile sulla schermata

Attributi

title stringa che indica il testo da visualizzare accanto allo switch

UiWatchControl - WatchVoiceMessage

Rappresenta un bottone che invii un input vocale dallo smartwatch allo smartphone

Si descrive in seguito come siano stati modificati i modelli riguardanti i dispositivi

visualizzabili nell’editor grafico di Protocode e i controlli di anteprima trascinabili sul-

la schermata per istanziare i vari widgets.

Device

Rappresenta un dispositivo che viene utilizzato per posizionare i vari widget di Proto-

code. E la superclasse da cui ereditano i modelli Smartphone e Smartwatch

Attributi

name identificativo che rappresenta il nome del dispositivo mobile

label stringa che indica il nome da visualizzare nel menu di selezione

del dispositivo

platform stringa che indica la piattaforma del dispositivo

screenWidth,

screenHeight

stringa che indica la dimensione della superficie dello schermo

del dispositivo reale

viewTop,

viewBottom

stringa che indica la dimensione della superficie dello schermo

che viene occupata da eventuali barre di navigazione o header

in maniera permanente

cssWidth,

cssHeight

stringa che indica la dimensione in pixel della superficie dello

schermo all’interno dell’editor di Protocode

50


Smartphone

Rappresenta un device di tipo smartphone

Smartwatch

Rappresenta un device di tipo smartwatch

UiPhoneControlTemplate

Rappresenta un oggetto di anteprima dei widget per smartphone

Attributi

label stringa che indica il nome del relativo widget

nameImg stringa che indica il nome dell’immagine da visualizzare

all’interno dell’anteprima

type stringa che indica il tipo di widget che verra istanziato

UiWatchControlTemplate

Rappresenta un oggetto di anteprima dei widget per smartwatch

Attributi

label stringa che indica il nome del relativo widget

nameImg stringa che indica il nome dell’immagine da visualizzare

all’interno dell’anteprima

type stringa che indica il tipo di widget che verra istanziato

51


3.2.1.3 Controller

Per quanto riguarda la gestione dei controller, sono stati innanzitutto creati quelli

relativi ai nuovi widget per smartphone e smartwatch, e sono stati quindi adeguati i

vecchi controller al fine di manipolare le nuove caratteristiche introdotte per i widgets

gia presenti. Inoltre, sono stati aggiunti due ulteriori mixins per la gestione dei nuovi

componenti:

� TextDecorable: implementato sia dalle Label per smartphone che per smartwatch,

permette di manipolare l’aspetto del testo presente nelle etichette (normale,

grassetto o corsivo)

� WatchClickListenable: contiene la logica necessaria per la gestione e la cancella-

zione di modelli che sono collegati direttamente ad un oggetto WatchClickListener

E stato quindi rivisto il meccanismo di aggiunta dei widget su smartphone, impedendo

ad alcuni controlli di essere istanziati piu di una volta nella stessa schermata: in par-

ticolare, oggetti come le VideoView e le Mappe possono causare un arresto anomalo

dell’applicazione mobile su alcuni dispositivi e/o versioni di Android meno recenti, se

presenti piu di una volta nella stessa schermata.

Infine, per quanto riguarda gli smartwatch, il sistema di introduzione e cancellazio-

ne dei widget e stato naturalmente adeguato per tenere conto dell’ordinamento in

verticale dei componenti sulla schermata.

Si riporta in seguito lo schema dei controller di Protocode nella sua versione finale:

sono indicati in verde i controller che hanno subito delle modifiche e tutti i nuovi

controller e relazioni che sono stati introdotti.

52


Figura 3.8: Schema dei controller finale di Protocode

53


3.2.1.4 View

Il primo intervento riguardo il meccanismo delle view, e stato quello di adeguare quelle

relative ai widget gia presenti nell’applicazione, in maniera tale da visualizzare le nuove

caratteristiche introdotte e, solo in seguito, sono state create le view corrispondenti ai

nuovi componenti.

Per modificare le proprieta riguardanti il colore di sfondo o quello del testo dei wid-

get di Protocode, e stato necessario introdurre dei componenti HTML dedicati, che

permettessero di scegliere un colore tramite il cosiddetto color picker, come avviene co-

munemente in tutti gli applicativi di manipolazione delle immagini: per questo scopo si

e utilizzata una libreria javascript/css, basata sempre su Bootstrap, chiamata Mjolnic

Bootstrap Colorpicker [64].

Per quel che riguarda invece la gestione dell’interfaccia grafica degli smartwatch, sono

stati introdotti i template dedicati a mostrare l’orologio nel pannello di editing grafico

e quelli relativi alle proprieta specifiche dei widget: il risultato ricalca esattamente il

template gia utilizzato per gli smartphone, rendendo la navigazione particolarmente

semplice ed intuitiva.

Poiche l’applicazione aveva ormai raggiunto una dimensione piuttosto consistente, sono

stati riorganizzati i fogli di stile in piu di un file .scss, ciascuno dedicato ad un parti-

colare sistema operativo, rendendo la manipolazione dell’interfaccia grafica piu snella

e scalabile.

Si riporta in seguito la gerarchia finale delle view di Protocode: sono indicate in verde

le view che hanno subito delle modifiche e tutte le nuove view e relazioni che sono state

introdotte.

54


Figura 3.9: Gerarchia finale delle view di Protocode

55


3.2.2 Aggiornamento dell’interfaccia grafica

L’interfaccia grafica dell’applicazione ha subito in primo luogo una revisione puramen-

te estetica, riguardo il tema principale dei colori e riguardo la dimensione dei pannelli

contenenti i dispositivi e i relativi widgets: inoltre, sono state rimpiazzate le vecchie

icone dei widgets con un set di immagini piu moderno, che ricalcasse l’aspetto odierno

dei vecchi componenti e di quelli appena inseriti all’interno di Protocode.

A seguito dell’introduzione degli smartwatch dunque, e stato creato un menu a tendina

dedicato alla scelta dell’orologio da visualizzare e il relativo pannello di editing grafico,

mantenendo comunque l’impostazione iniziale di Protocode per rendere la navigazione

il piu lineare possibile. In sostanza, accedendo alla sezione dedicata all’editor, non

viene piu mostrato direttamente il pannello relativo alla modifica delle schermate per

smartphone, ma viene data la possibilita di scegliere quale tipo di dispositivo modificare

tramite un menu a bottoni posizionato appena sotto la barra di navigazione principale.

Figura 3.10: Anteprima applicazione smartphone Android su Protocode

56


Figura 3.11: Anteprima applicazione smartwatch WatchOS su Protocode

Smartphones

Per quanto riguarda gli smartphone, sono stati introdotti nuovi dispositivi sia per An-

droid che per iOS, rispettivamente il Nexus 6P e gli iPhones 6 e 6 Plus : in questo

modo e ora possibile visualizzare il risultato finale su dispositivi con lo stesso sistema

operativo ma con risoluzioni diverse, supportando l’utente in maniera ancora piu age-

vole durante la fase di design dell’interfaccia grafica.

A questo proposito, si e scelto di utilizzare delle immagini .png dei dispositivi con

uno schermo la cui risoluzione in pixels fosse esattamente uguale alla dimensione del-

lo schermo reale del dispositivo in dp per Android o in points per iOS: cosı facendo,

si eliminano completamente i difetti di approssimazione poiche tutto cio che viene

rappresentato nel browser avra una dimensione in scala 1:1 con il risultato finale sul

dispositivo reale.

I sistemi operativi visualizzati sugli smartphones, sono stati portati alla loro ultima

versione, rispettivamente Android Marshmallow per i dispositivi Nexus e iOS 9 per

gli iPhones; in particolare, il menu di navigazione a tendina per Android e stato com-

pletamente rimpiazzato da una navigazione tramite Tab Bar, che rispecchia molto piu

57


efficacemente il comportamento della Bottom Bar presente in basso nelle applicazioni

per iOS. Nonostante il grosso sforzo che questo comportera nella traduzione in codice

nativo, si e scelto di fare questo aggiornamento in quanto la versione originale di Pro-

tocode prevedeva che tutte le schermate su Android avessero lo stesso menu a tendina

nella Action Bar, creando un’incredibile confusione durante la navigazione, a causa del

continuo sovrapporsi di nuove schermate.

Widgets per smartphones

Si riporta in seguito una descrizione dettagliata di tutti i widgets per smartphones

disponibili nella versione finale di Protocode.

Widget Android iOS Personalizzazione

ButtonBottone grigio con

testo nero

Bottone bianco con

testo azzurro

Testo

Colore del testo

Colore di sfondo

Colore al click

Curvatura del bordo

ClickListener

Posizione

Dimensione

Label Testo nero Testo nero

Testo

Colore del testo

Dimensione del testo

Stile del testo


Posizione

Dimensione

58


EditText

Campo di input

con bordo inferiore

rosa

Casella di input

con bordo

arrotondato

Testo

Placeholder

Colore del testo

Dimensione del testo

Posizione

Dimensione

Spinner

Menu di selezione a

tendina con bordo

inferiore rosa

Classica picker

view trasparente

Posizione

Dimensione

SwitchBottone a

interruttore rosa

Bottone a

interruttore verde

Posizione

Dimensione

SliderBarra di

scorrimento rosa

Barra di

scorrimento

azzurra

Posizione

Dimensione

WebView

Rettangolo grigio

con la scritta

WebView

Rettangolo azzurro

con la scritta

UIWebView

Nome del file sorgente

Posizione

Dimensione

ImageView

Rettangolo grigio

con icona di

un’immagine

Rettangolo azzurro

con la scritta

UIImageView

Tipo di sorgente


Posizione

Dimensione

VideoView

Rettangolo grigio

con la scritta

VideoView

Rettangolo azzurro

con la scritta

UIVideoView

Tipo di sorgente


Posizione

Dimensione

59


AudioPlayer

Contenitore di 3

bottoni rosa

rotondi e allineati

con i simboli

bianchi di play,

pause, stop

Contenitore di 3

bottoni bianchi

allineati con i

simboli azzurri di

play, pause, stop

Tipo di sorgente


Posizione

Dimensione

ListViewContenitore

trasparente

Contenitore

trasparente

Colore di sfondo

Tipo di lista

ClickListener

Posizione

Dimensione

ListViewCell

Cella orizzontale

contenente

immagini e icone

oltre che ad un

titolo e sottotitolo

Cella orizzontale

contenente

immagini e icone

oltre che ad un

titolo e sottotitolo

Testo

Sottotitolo

GridViewContenitore

trasparente

Contenitore

trasparente

Tipo di griglia

ClickListener

Posizione

Dimensione

GridViewCell

Cella quadrata

contenente

immagini con testo

Cella quadrata

contenente

immagini con testo

Testo

Photocamera

Controller

Bottone grigio con

la scritta nera

“Fotocamera”

oppure con icona

di Fotocamera

Botton bianco con

la scritta azzurra

“Fotocamera”

oppure con icona

di Fotocamera

ImageView di

anteprima

(hardwareFile)

Posizione

Dimensione

60


Videocamera

Controller

Bottone grigio con

la scritta nera

“Videocamera”

oppure con icona

di Videocamera

Bottone bianco con

la scritta azzurra

“Videocamera”

oppure con icona

di Videocamera

VideoView di

anteprima

(hardwareFile)

Posizione

Dimensione

Audio

Recorder

Bottone grigio con

la scritta nera

“Rec”

Bottone bianco con

la scritta azzurra

“Rec”

AudioPlayer di

anteprima

(hardwareFile)

Posizione

Dimensione

Map Google Map Map View iOS

Longitudine del centro

Latitudine del centro

Posizione

Dimensione

DatepickerCalendario

trasparente

Classica picker

view trasparente

Posizione

Dimensione

Timepicker

Orologio digitale

con bottone rosa di

tracking

Classica picker

view trasparente

Posizione

Dimensione

Card

CardView a tutto

schermo con titolo

sottotitolo e

bottoni

CardView a tutto

schermo con titolo

sottotitolo e

bottoni

Titolo

Sottotitolo

Numero di bottoni

Posizione

Dimensione

MenuTabBar in alto

nella schermata

BottomBar in

basso nella

schermata

Tabella 3.2: Tabella dei widget smartphone nella versione finale di Protocode

61


Smartwatches

I dispositivi smartwatch introdotti nella nuova versione di Protocode sono i seguenti:

� Apple Watch 42mm, con sistema operativo watchOS di Apple, di forma rettan-

golare e con una risoluzione di 156x195 points.

� Asus Zen Watch, con sistema operativo Android Wear, di forma quadrata e con

una risoluzione di 213x213 dp.

� Moto 360, con sistema operativo Android Wear, di forma circolare e con una

risoluzione di 241x248 dp.

Anche in questo caso, sono state utilizzate delle immagini .png dei dispositivi con uno

schermo le cui dimensioni in pixels combaciassero con le risoluzioni reali degli schermi

degli orologi.

Widgets per smartwatches

Come gia anticipato nelle sezioni precedenti, sebbene anche i widgets per smartwatch

posseggano tutte le proprieta necessarie per un posizionamento completamente libero

sulla schermata e un sistema di vincoli identico ai componenti per smartphone, queste

proprieta non saranno comunque personalizzabili dall’utente.

Si e scelto di vincolare i dispositivi Android Wear a quelli watchOS, posizionando i

vari widgets consecutivamente l’uno sotto l’altro: questo in pratica, significa che sa-

ranno tutti larghi esattamente quanto la schermata dell’orologio e con le proprieta di

allineamento verticale “forzate a true” nel momento in cui questi vengono istanziati.

Si riporta in seguito una descrizione dettagliata di tutti i widgets per smartwatch

che e possibile aggiungere alle varie schermate.

62


Widget Android Wear watchOS Personalizzazione

WatchButton

Bottone grigio

chiaro con testo

bianco

Bottone grigio

scuro con testo

bianco

Testo

WatchClickListener

Altezza del bottone

WatchLabel Testo bianco Testo bianco

Testo

Stile del testo


Altezza dell’etichetta

WatchSlider

Barra di

scorrimento

azzurra

Barra verde

suddivisa in step

con bottoni bianchi

+,-

Altezza del contenitore

della barra

WatchSwitch

Bottone a

interruttore

azzurro con testo

bianco

Bottone a

interruttore verde

con testo bianco

Testo

Altezza del contenitore

Watch-

VoiceMessage

Bottone grigio

chiaro con testo

bianco

Bottone grigio

scuro con testo

bianco

Altezza del bottone

Tabella 3.3: Tabella dei widget smartwatch nella versione finale di Protocode

63


3.3 Generazione del modello

In questa sezione, viene presentato il meccanismo con cui viene generato il modello

astratto dell’applicazione mobile e la sua struttura nel dettaglio: l’approccio model-

driven seguito per creare questo modello, si concretizza nella generazione di un file

XML che contiene tutte le informazioni riguardanti il prototipo creato graficamente,

senza dover conoscere in alcun modo la tecnologia con cui questo verra implementato.

In altre parole, il modello generato con Protocode, potrebbe essere utilizzato per gene-

rare applicazioni di natura completamente differente dallo scopo di questa ricerca, con

linguaggi e tecnologie diverse da quelle utilizzate per Android e iOS.

Come gia anticipato nella sezione riguardante i modelli dell’applicazione, ogni com-

ponente creato con Protocode possiede un attributo xmlName e un metodo toXml(),

che trasformano le proprieta degli oggetti Javascript in una stringa di testo secondo

la sintassi XML: al momento del download del modello, a partire dall’elemento radice

application, vengono richiamati ricorsivamente i metodi toXml() di tutte le schermate

dell’applicazione e dei loro widgets, per produrre appunto il modello astratto scritto in

formato XML. Naturalmente, si e dovuto intervenire sui vecchi modelli di Protocode,

oltre che su quelli appena introdotti, in maniera da poter generare tutte le nuove pro-

prieta, i nuovi componenti per smartphone e le schermate relative agli smartwatch.

Si presenta di seguito la struttura del modello astratto generato da Protocode nella sua

versione finale, descritta per compattezza tramite una grammatica EBNF (Extended

Backus-Naur Form).

64


XML →

<?xml version="1.0" encoding="UTF-8"?>

<metamodel:Application

name="APPNAME" companyIdentifier="it.polimi">

(VCONTROLLER)∗

(WCONTROLLER)∗

<menu>

(MENUITEM)∗

</menu>

</metamodel:Application>

VCONTROLLER →

<viewControllers

name="ID" backgroundColor="COLOR"

backgroundImage="STRING" launcher="BOOL">

(ALERTDIALOG)∗

(PROGRESSDIALOG)∗

(ASYNCTASK)∗

(UIPHONECONTROL)∗

</viewControllers>

WCONTROLLER →

<watchControllers name="ID" launcher="BOOL">

(UIWATCHCONTROL)∗

</watchControllers>

MENUITEM →

<menuItems title="STRING" id="ID">

<navigation destination="ID"/>

</menuItems>

65


LABEL →

<textViews

PROPERTIES

viewController="ID"

content="STRING"

textAlign="STRING" textColor="COLOR"

textSize="INT" textDecoration="STRING" />

EDITTEXT →

<editTexts

PROPERTIES

viewController="ID"

initialContent="STRING" placeholder="STRING"

textColor="COLOR" textSize="INT" />

SPINNER → <spinners PROPERTIES viewController="ID" />

SWITCH → <switches PROPERTIES viewController="ID" />

SLIDER → <sliders PROPERTIES viewController="ID" />

WEBVIEW →

<webViews

PROPERTIES

viewController="ID"

HTMLFileName="STRING" />

IMAGEVIEW →

<imageViews

PROPERTIES

viewController="ID" sourceType="STRING" fileUri="STRING" />

67


VIDEOVIEW →

<videoViews

PROPERTIES


AUDIOPLAYER →

<audioPlayers

PROPERTIES


LISTVIEW →

<listViews

PROPERTIES

viewController="ID"

backgroundColor="COLOR" listType="STRING">

(CLICKLISTENER)? (LISTVIEWCELL)∗

</listViews>

GRIDVIEW →

<gridViews

PROPERTIES

viewController="ID" gridType="STRING">

(CLICKLISTENER)? (GRIDVIEWCELL)∗

</gridViews>

PHOTOCONTROLLER →

<photocameraController

PROPERTIES

viewController="ID" imageViewId="ID" />

68


VIDEOCONTROLLER →

<videocameraController

PROPERTIES

viewController="ID" videoViewId="ID" />

AUDIORECORDER →

<audioRecorder

PROPERTIES

viewController="ID" audioPlayerId="ID" />

MAP →

<map

PROPERTIES

viewController="ID" lat="REAL" lon="REAL" />

DATEPICKER → <datepickers PROPERTIES viewController="ID"/>

TIMEPICKER → <timepickers PROPERTIES viewController="ID"/>

CARD →

<cards

PROPERTIES

viewController="ID"

title="STRING" subtitle="STRING" numActions="INT" />

WATCHBUTTON →

<watchButtons

PROPERTIES

watchController="ID" order="INT" title="STRING">

(WATCHCLICKLISTENER)?

</watchButtons>

69


WATCHLABEL →

<watchTextViews

PROPERTIES

watchController="ID"

order="INT" content="STRING"

textAlign="STRING" textDecoration="STRING"/>

WATCHSLIDER →

<watchSliders

PROPERTIES

watchController="ID" order="INT"/>

WATCHSWITCH →

<watchSwitches

PROPERTIES

watchController="ID" order="INT" title="STRING"/>

WATCHVOICEMESSAGE →

<watchVoiceMessage

PROPERTIES

watchController="ID" order="INT" title="STRING"/>

CLICKLISTENER →

<clickListener>

<navigation destination="ID"/>

</clickListener>

WATCHCLICKLISTENER →

<watchClickListener>

<watchNavigation destination="ID"/>

</watchClickListener>

70


LISTVIEWCELL →

<listViewCells title="STRING" subtitle="STRING" />

GRIDVIEWCELL →

<gridViewCells title="STRING" />

PROPERTIES →

id="ID" posX="REAL" posY="REAL" width="INT" height="INT"

paddingTop="INT" paddingBottom="INT"

paddingStart="INT" paddingEnd="INT"

marginTop="INT" marginBottom="INT"

marginStart="INT" marginEnd="INT"

alignParentTop="BOOL" alignParentBottom="BOOL"

alignParentStart="BOOL" alignParentEnd="BOOL"

alignTop="ID" alignBottom="ID" alignStart="ID" alignEnd="ID"

above="ID" below="ID" toStartOf="ID" toEndOf="ID"

APPNAME → ( a-z | A-Z )+

ID → ( a-z | A-Z )( a-z | A-Z | 0-9 | )∗

STRING → ( a-z | A-Z | 0-9 | )∗

REAL → ( 0-9 )+.( 0-9 )+

INT → ( 0-9 )+

BOOL → true | false

COLOR → #( A-F | 0-9 ){6}

Il modello cosı ottenuto al termine della fase di prototipizzazione, verra utilizzato per

generare le applicazioni Android e iOS in codice nativo senza ulteriori interventi da

parte dello sviluppatore: nel prossimo capitolo verra mostrato lo strumento in grado

di leggere questo modello e produrre delle applicazioni vere e proprie, semplicemente

prendendo in input questo file XML ed eseguendo la routine di traduzione, che potra

essere avviata con pochi click da parte dell’utente.

71

Capitolo 4

Traduzione in codice nativo

In questo capito viene descritto il meccanismo di traduzione in codice nativo del mo-

dello astratto generato tramite Protocode: lo strumento realizzato per la generazione

di codice sorgente e basato sulle stesse tecnologie che venivano utilizzate nella tool-

chain originale, ma le regole di traduzione sono state quasi completamente rimpiazzate

per adeguare lo strumento alle novita introdotte in fase di prototipizzazione. In que-

sto caso, verra esclusa dalla trattazione la descrizione della struttura originale dello

strumento di traduzione, poiche le modifiche introdotte durante questa ricerca, hanno

quasi completamente sostituito i vecchi meccanismi di generazione di codice nativo;

non mancheranno comunque eventuali segnalazioni riguardo componenti che sono stati

utilizzati senza alcuna modifica rispetto alla versione originale del progetto.

4.1 MobileCodeGenerator

L’applicativo utilizzato per la traduzione in codice sorgente del modello dell’applica-

zione mobile prende il nome di MobileCodeGenerator [66]: si tratta di un progetto che

si sviluppa all’interno dell’IDE Eclipse [67], ed e basato su una serie di strumenti che

permettono di generare un’istanza di un modello di dati strutturati e di tradurla in

codice sorgente per un particolare applicativo.

72

4. TRADUZIONE IN CODICE NATIVO

Nella sua versione originale, MobileCodeGenerator produceva un’applicazione Android

scritta in Java e un’applicazione iOS scritta in Objective-C: la prima, sottoforma di

file di progetto per Eclipse con ADT (Android Developer Tools) mentre la seconda,

sottoforma di file di progetto per Xcode. Si e modificato il funzionamento dell’applica-

tivo al fine di produrre un’applicazione mobile Android importabile direttamente nel

nuovo IDE dedicato Android Studio, e un’applicazione mobile iOS scritta con il nuovo

linguaggio Swift: in entrambi i casi, verranno generati anche tutti i file per la gestione

della controparte smartwatch degli applicativi all’interno dei rispettivi IDE di sviluppo.

4.1.1 Epsilon Suite

Lo strumento di traduzione del modello in codice nativo e basato su due principali

framework di modellazione, disponibili all’interno della distribuzione Epsilon di Eclipse:

EMF (Eclipse Modeling Framework), il quale permette la creazione e la gestione del

modello dell’applicazione mobile [68], e oAW (openArchitectureWare) che invece mette

a disposizione tutta una serie di strumenti utili alla traduzione del modello in codice

sorgente, in questo caso Java per Android e Swift per iOS. [69]

4.1.1.1 Eclipse Modeling Framework

E il framework che sta alla base della definizione del modello dell’applicazione mobi-

le e che permette di generare automaticamente un’istanza di questo modello, per poi

eventualmente tradurla in codice sorgente per un determinato applicativo; in questo

caso pero, EMF e stato utilizzato solamente per definire il modello dell’applicazione

mobile, in quanto la traduzione e stata progettata utilizzando gli strumenti disponibili

all’interno del framework oAW.

In teoria tramite EMF, una volta definito il modello dell’applicazione mobile, sareb-

be possibile anche generare un’istanza di questo sottoforma di file XML: nel nostro

caso pero, l’istanza del modello viene fornita direttamente dal file XML esportato da

Protocode, mentre il modello definito all’interno di MobileCodeGenerator serve per

garantire la correttezza delle regole di traduzione in termini di proprieta e relazioni fra

i vari componenti del modello.

73


4.1.1.2 openArchitectureWare

A partire dell’istanza del modello definito tramite EMF, e stato dunque possibile vali-

dare le proprieta di questa istanza e procedere alla fase di traduzione vera e propria: gli

strumenti utilizzati per questo proposito, sono tutti contenuti all’interno del framework

oAW e sono i seguenti:

� Xpand : per definire le regole di traduzione dell’istanza del modello.

� Xtend : per aggiungere alle funzionalita di Xpand la potenza del linguaggio Java.

� Check : per validare l’istanza del modello dell’applicazione.

� Modeling Workflow Engine: per definire il flusso di task da eseguire durante la

fase di traduzione vera e propria.

Figura 4.1: Meccanismo di traduzione di MobileCodeGenerator

74


Xpand

Si tratta di un framework che permette allo sviluppatore di produrre dell’output te-

stuale a partire da un modello EMF Ecore, UML2, JavaBeans o XMLSchema: nel caso

di MobileCodeGenerator, il modello dell’applicazione mobile e di tipo Ecore, e l’out-

put testuale prodotto e naturalmente linguaggio Java o Swift. Le regole di traduzione

possono essere modularizzate in piu file di estensione .xpt e contengono al loro interno

dei costrutti che permettono di produrre dell’output testuale sulla base degli elementi

che compongono l’istanza del modello, ad esempio :

�IMPORT metamodel�

�DEFINE attributesDeclarations FOR ViewController-�

�FOREACH buttons AS b-�

private Button �b.id�;

�ENDFOREACH-�

�ENDDEFINE-�

Il costrutto IMPORT viene utilizzato per far riferimento al modello dell’applicazione e

permette quindi di definire le regole di traduzione come attributesDeclarations che, per

ogni bottone presente nell’istanza del modello (FOREACH buttons), produce l’output

testuale “private Button �b.id�;”. [70]

Xtend

Grazie a questo strumento e possibile utilizzare dei metodi scritti completamente in

Java all’interno dei file Xpand che regolano la traduzione del modello: sono state create

alcune classi Java contenenti delle routine relative alla creazione delle directory di pro-

getto o alla creazione di nuovi file sorgente, che possono essere richiamate all’interno dei

file Xpand semplicemente utilizzando il costrutto �EXTENSION path-to-java-class� e

riportando all’interno di un file .ext di Xtend la lista dei metodi contenuti nella classe

Java originale. [71]

Si riporta una porzione di codice Xtend a titolo di esempio.

75


AndroidJavaUtil.java

public static void deleteApplicationFolder() {

File androidAppFolder =

new File(AndroidConstants.destinationFilesFolder);

AppJavaUtil.deleteFolder(androidAppFolder);

}

Java.ext

Void deleteApplicationFolder():JAVA

android extensions.AndroidJavaUtil.deleteApplicationFolder();

Check

Il linguaggio Check permette di definire all’interno di alcuni file con estensione .chk,

una serie di regole per la validazione dell’istanza del modello dell’applicazione mobile,

che verranno richiamate per prime durante la fase di traduzione vera e propria: anche in

questo caso, e possibile fare ricorso ad Xtend per effettuare delle verifiche piu articolate

utilizzando dei metodi scritti puramente in Java. All’interno di Check, e possibile

utilizzare dei costrutti tipici della logica matematica come forAll ed exists, combinarli

con semplici metodi Java come matches e dunque verificare determinate condizioni

per ciascun elemento dell’istanza del modello: nel caso in cui queste condizioni non

risultino verificate, e possibile sollevare un WARNING oppure un ERROR, bloccando

in quest’ultimo caso il processo di traduzione. [72]

Modeling Workflow Engine

Si tratta del framework che permette di definire il processo di traduzione vera e propria:

grazie ad esso, e possibile creare dei file .mwe all’interno dei quali, sono contenuti in

maniera sequenziale tutti i task da eseguire durante il processo di traduzione. In altre

parole, al suo interno si troveranno dei componenti scritti in un linguaggio basato su

XML, che leggono l’istanza del modello, verificano i vincoli scritti all’interno dei file

Check, eseguono la traduzione definita con Xpand e producono i file risultanti all’in-

terno di una particolare cartella di destinazione. [73]

76


4.1.2 Struttura del progetto

In questa sezione viene presentata la struttura del progetto di MobileCodeGenerator,

andando ad analizzare tutti i package che lo compongono e il loro ruolo nel meccanismo

di traduzione in codice nativo; in generale, lo scheletro dell’applicativo e composto da

tre sezioni principali: la cartella src contenente i cosiddetti template di traduzione e il

modello dell’applicazione, la cartella utils contenente i file che l’utente intende aggiun-

gere come risorse di progetto e la cartella src-gen che conterra i progetti per Android

Studio e Xcode al termine della traduzione. Tra i sorgenti ci sono inoltre tutte le li-

brerie di sistema, i plugin ed i file di configurazione necessari per garantire il corretto

funzionamento di MobileCodeGenerator.

Figura 4.2: Struttra del progetto di MobileCodeGenerator

77


4.1.2.1 Metamodello dell’applicazione mobile

All’interno della cartella src/metamodel si trova il cosiddetto metamodello dell’appli-

cazione mobile, ovvero la descrizione del modello dell’applicativo che verra tradotto

in codice nativo: come gia anticipato, si tratta di un modello di tipo .ecore, e ricalca

esattamente il modello utilizzato all’interno di Protocode, oltre al fatto che e accompa-

gnato anche da un modello grafico con estensione .ecore diagram, che rende ancora piu

esplicite le proprieta e le relazioni che i componenti dell’applicazione devono rispetta-

re. L’istanza del modello dell’applicazione, si trova invece nel percorso src/model ed e

costituito dal file XML generato al termine della fase di prototipizzazione.

Il package model checks infine, contiene i file relativi alla validazione dell’istanza del

modello da tradurre in codice nativo, rispettivamente:

� Checks.chk, che contiene tutti i controlli relativi alle proprieta del modello che

non sono state verificate gia in fase di prototipizzazione e che solleveranno even-

tualmente un errore in fase di traduzione.

� JavaChecks.java, che contiene dei metodi scritti in Java per i controlli di valida-

zione particolarmente elaborati.

� Extension.ext, che funge da ponte tra i metodi Java e i controlli Check contenuti

nei due precedenti file.

La validazione del modello effettuata tramite Check, riguarda ad esempio i file inseriti

dall’utente come immagini, audio e video, la corretta definizione del menu di naviga-

zione e la nomenclatura utilizzata per le schermate ed i widgets, come gia descritta

nella sezione relativa al modello esportato da Protocode.

78


4.1.2.2 Templates di traduzione

Si descrivono in seguito i cosiddetti template di traduzione, ovvero i file Xpand conte-

nenti le regole di traduzione e decorate da espressioni Java grazie ad Xtend, oltre che

il contenuto delle cartelle utils e src-gen utilizzate rispettivamente all’inizio e alla fine

della fase di traduzione.

Cartella src

� android activities templates: contiene tutti i template relativi alla generazio-

ne della componente logica di ciascun widget per smartphone su Android, dalla

loro dichiarazione fino ai metodi piu complessi che ne garantiscono il corretto

funzionamento. Sono stati modularizzati in piu file specifici alcuni metodi Java,

relativi al ciclo di vita delle Activities di Android come onCreate, onCreateView,

onPause e onResume.

� ios viewcontrollers templates: contiene tutti i template relativi alla genera-

zione della componente logica di ciascun widget per smartphone su iOS, dalla

loro dichiarazione fino ai metodi piu complessi che ne garantiscono il corret-

to funzionamento. Sono stati modularizzati in piu file specifici alcuni metodi

Swift, relativi al ciclo di vita dei ViewControllers di iOS come viewDidAppear,

viewDidDisappear e viewDidLoad.

� androidwear activities templates: contiene tutti i template relativi alla ge-

nerazione della componente logica di ciascun widget per smartwatch su Android-

Wear, dalla loro dichiarazione fino ai metodi piu complessi che ne garantiscono il

corretto funzionamento. Sono stati modularizzati in piu file specifici alcuni me-

todi Java, relativi al ciclo di vita delle Activities di AndroidWear come onCreate

e onLayoutInflated.

� ios watchcontrollers templates: contiene tutti i template relativi alla gene-

razione della componente logica di ciascun widget per smartwatch su watchOS,

dalla loro dichiarazione fino ai metodi piu complessi che ne garantiscono il cor-

retto funzionamento. Sono stati modularizzati in piu file specifici alcuni me-

79


todi Swift, relativi al ciclo di vita degli InterfaceControllers di watchOS come

awakeWithContext, willActivate e didDeactivate.

� android templates

– AndroidManifest.xpt : descrive il file Manifest per smartphone, con la lista

delle Activities e di tutti i permessi necessari.

– AndroidManifestWatch.xpt : descrive il file Manifest per smartwatch, con la

lista delle Activities e di tutti i permessi necessari.

– Activities.xpt : descrive la componente logica di ogni schermata dell’appli-

cazione per smartphone, ovvero la struttura delle Activities (in assenza di

un menu di navigazione), oppure quella dei Fragments (nel caso in cui una

schermata sia anche una sezione del menu dell’applicazione). Questa distin-

zione e inevitabile dal momento che si e scelto di utilizzare una navigazione

a Tab Bar per i sistemi Android, ma nonostante il differente ciclo di vita tra

Activities e Fragments, verra mantenuto lo stesso aspetto e comportamento

di ogni widget indipendentemente dal tipo di schermata.

– ActivitiesWatch.xpt : descrive la componente logica di ogni schermata del-

l’applicazione per smartwatch.

– XMLFiles.xpt : descrive l’interfaccia grafica di ogni schermata dell’applica-

zione per smartphone, che come avviene naturalmente per Android, consiste

in un singolo file in formato XML. All’interno di questo template, vengono

generati anche i file relativi al layout di ListView e GridView che conten-

gano immagini o icone e quelli relativi ai bottoni che non abbiano l’aspetto

grigio di default; inoltre, viene qui gestita la traduzione dei vincoli di posi-

zionamento tra i widgets secondo il sistema del RelativeLayout utilizzato da

Android. Anche in questo caso, la struttura generale del file XML e piutto-

sto differente a seconda che si tratti dell’interfaccia grafica di un’Activity o

di quella di un Fragment.

– XMLFilesWatch.xpt : descrive l’interfaccia grafica di ogni schermata dell’ap-

plicazione per smartwatch, ricalcando il sistema di posizionamento utilizzato

per smartphone.

80


– DefaultFiles.xpt : descrive intere classi Java che e necessario produrre per il

corretto funzionamento di determinati widget dell’applicazione su smartpho-

ne. In particolare, in questo template si trovano i cosiddetti Adapters per

ListView e GridView sofisticate, la classe ImageDownloadingTask.java per il

download in background delle immagini e la classe MyWearableListenerSer-

vice.java per la ricezione dei messaggi provenienti dallo smartwatch. Infine

questo template, descrive il file di build di Gradle [74] per lo smartphone,

con la lista di tutte le librerie che devono essere scaricate e installate.

– DefaultFilesWatch.xpt : descrive il file di build di Gradle per lo smartwatch,

con la lista di tutte le librerie che devono essere scaricate e installate.

� ios templates

– Xcodeproj.xpt : descrive il file .xcodeproj dell’applicazione, contenente i rife-

rimenti a tutti i file di progetto, alle Storyboards, ai ViewControllers dello

smartphone e agli InterfaceControllers per smartwatch. Ognuno dei file qui

elencati e identificato da una coppia di identificativi esadecimali che possono

avere un valore qualunque purche non siano ovviamente mai ripetuti.

– InfoPlist.xpt : descrive il file Info.plist dell’applicazione, contenente le infor-

mazioni relative alla compilazione del progetto, ed eventuali eccezioni per

gestire delle richieste HTTP che di default sono sempre proibite su iOS.

– MainStoryboard.xpt : descrive il file Main.storyboard dell’applicazione per

smartphone, contenente tutte le schermate e i relativi widgets. All’interno

di questo template naturalmente, viene gestita la traduzione dei vincoli di

posizionamento tra i widgets secondo il sistema dei vincoli di Xcode e l’e-

ventuale presenza o meno del menu di navigazione in basso nella Bottom

Bar; sono elencati in questo file anche tutti i collegamenti tra i widget e le

loro dichiarazioni all’interno dei ViewController, e gli eventuali meccanismi

di navigazione tra di essi.

– LaunchScreenStoryboard.xpt : descrive il file LaunchScreen.storyboard com-

posto solamente da una schermata bianca, mai visualizzata all’avvio dell’ap-

plicazione.

81


– ViewControllers.xpt : descrive la componente logica di ogni schermata del-

l’applicazione per smartphone, ovvero la struttura dei ViewControllers. Al

suo interno vi sono tutti i metodi riguardanti il ciclo di vita della schermata,

dove si andranno ad inserire i vari widgets e una sezione dedicata ai protocolli

da implementare per il corretto funzionamento di tutti i componenti.

– ViewConstraints.xpt : descrive in un template dedicato il meccanismo dei

vincoli tra i widgets all’interno di ogni schermata, poiche a differenza del

sistema utilizzato per Android, i vincoli su iOS sono diversi rispetto a quelli

dichiarati su Protocode e non possono essere semplicemente elencati tutti

quanti con dei parametri true o false. I vincoli in contrasto fra di loro, non

sempre possono essere ignorati a run-time come avviene per Android e percio

vanno verificati secondo un ordine ben preciso, per poi essere correttamente

importati nel template della Storyboard.

– InterfaceStoryboard.xpt : descrive il file Interface.storyboard dell’applicazione

per smartwatch, contenente tutte le schermate e i relativi widgets. All’inter-

no di questo template, torna finalmente utile il parametro order assegnato ai

widgets per smartwatch in fase di prototipizzazione, in quanto basta sempli-

camente elencare in ordine i vari componenti per posizionarli verticalmente

nella schermata. Come gia detto, il sistema di posizionamento per watchOS

e estremamente semplificato rispetto ad AndroidWear, e soprattutto e at-

tualmente molto difficile trovare dei punti in comune fra i due sistemi, se

non per la semplice altezza e larghezza dei widgets.

– InterfaceControllers.xpt : descrive la componente logica di ogni schermata

dell’applicazione per smartwatch, ovvero la struttura degli InterfaceCon-

trollers. Al suo interno vi sono tutti i metodi riguardanti il ciclo di vita

della schermata, dove si andranno ad inserire i vari widgets e una sezione

dedicata ai protocolli da implementare per il corretto funzionamento di tutti

i componenti.

82

� android extensions: raccoglie le classi Java AndroidConstants e AndroidJa-

vaUtil contenenti i metodi relativi alla creazione e cancellazione di file sorgente

per Android, che vengono richiamati nei template di traduzione grazie alla classe

Xtend Java.ext

� ios extensions: raccoglie le classi Java iOSConstants e iOSJavaUtil contenenti

i metodi relativi alla creazione e cancellazione di file sorgente per iOS, la genera-

zione degli ID esadecimali per il file .xcodeproj e la traduzione dei colori da hex

a rgb, che vengono richiamati nei template di traduzione grazie alla classe Xtend

Java.ext

� app extensions: raccoglie la classe Java AppJavaUtil contenente i metodi rela-

tivi alla creazione e cancellazione dei file sorgente designati dall’utente in fase di

prototipizzazione, che vengono richiamati nei template di traduzione grazie alla

classe Xtend Java.ext

� workflow: raccoglie i file .mwe per l’avvio del processo di traduzione, Android-

Generator.mwe, iOSGenerator.mwe e iOSAndAndroidGenerator.mwe, che con-

tengono un riferimento all’istanza del modello, ai file Check per la sua validazio-

ne e la sequenza dei template di traduzione Xpand da eseguire per la specifica

piattaforma. Si descrive in seguito la struttura generale dei file .mwe:

<workflow>



<property name="model" value="../model/file.xmi"/>



<property name="src-gen" value="src-gen/piattaforma"/>

<bean class=".StandaloneSetup">

<platformUri value=".."/>

</bean>

83

<bean id="mm emf" class=".EmfRegistryMetaModel"/>



<component class=".Reader">

<uri value="platform:/resource/${model}"/>

<modelSlot value="model"/>

</component>



<component class=".CheckComponent">

<metaModel id="mm" class=".EmfRegistryMetaModel"/>

<checkFile value="model checks::Checks"/>

<emfAllChildrenSlot value="model"/>

</component>



<component class=".Generator">

<metaModel idRef="mm emf"/>

<expand value="n-esimo template xpand"/>

<outlet path="${src-gen}">

<postprocessor class=".JavaBeautifier"/>

</outlet>

<resourceManager class =".ResourceManagerDefaultImpl">

<fileEncoding value="ISO-8859-1"/>

</resourceManager>

</component>

...

...

...

</workflow>

84


Cartella utils

La cartella utils, contiene tutti i file che devono essere aggiunti come sorgenti di pro-

getto sia per smartphone che per smartwatch oltre che ai file relativi ad immagini,

video e audio che sono stati gia previsti in fase di prototipizzazione: in particolare, an-

droid default files e ios default files, contengono rispettivamente le icone per Android

e i file di build di Gradle, e tutti gli asset da importare in Xcode, mentre user files

contiene le immagini, i video e i sorgenti audio che l’utente vuole inserire all’interno

dell’applicazione.

Cartella src-gen

Infine, la cartella src-gen contiene tutti i file di progetto per Android e iOS: nel primo

caso bastera aprire Android Studio, fare click su “Open an existing Android Studio

project” e selezionare la cartella presente in src-gen/android/, mentre per iOS bastera

fare click sul file .xcodeproj nella cartella src-gen/ios/ e attendere l’avvio di Xcode.

85


4.2 Traduzione in codice nativo

In questa sezione viene presentato il risultato finale della traduzione in codice nativo,

con una panoramica sui progetti Android Studio e Xcode generati, e una descrizione

dettagliata della logica di tutti i componenti.

Per quanto riguarda Android, vengono generate nella directory src-gen/android/NOME-

APP le due cartelle mobile e wear contenenti tutti i file relativi rispettivamente all’ap-

plicazione mobile su smartphone e su smartwatch oltre che ad un file Gradle, che

all’avvio di Android Studio, scarichera tutte le librerie necessarie e avviera la com-

pilazione automatica del progetto. L’applicazione generata sara dunque compatibi-

le con le versioni Android dalla API 16 alla 23 sia per smartphone che per tablet,

e tramite l’applicazione dedicata di AndroidWear sara possibile connettere il dispo-

sitivo all’orologio e installare la controparte dell’applicativo. La scelta di limitarsi

al range di APIs sopra specificato, ha permesso di sfruttare tutti i componenti gra-

fici piu moderni, utilizzando semplicemente le librerie di retro-compatibilita fornite

da Google (com.android.support:support-v4:23.4.0 e com.android.support:appcompat-

v7:23.2.1 ) coprendo allo stesso tempo il 95.2% dei dispositivi attualmente attivi sul

Google Play Store (dati forniti direttamente da Android Studio). Fa eccezione solamen-

te il Timepicker, che nella sua ultima versione del Material Design, non e compatibile

con APIs inferiori alla 21, e dunque, per mantenere un aspetto coerente su tutti i

dispositivi, si e scelto di utilizzare una libreria esterna per istanziare un Timepicker

retro-compatibile chiamata com.github.ugurtekbas:dialTimePicker:9f4af78e90.

Per quanto riguarda iOS invece, vengono generate nella directory src-gen/ios/NOME-

APP le tre cartelle NOME-APP, NOME-APP Watchkit App e NOME-APP Watch-

Kit Extension contenenti tutti i file relativi rispettivamente all’applicazione mobile su

smartphone e su smartwatch (le due cartelle WatchKit) oltre che al file .xcodeproj

contenente tutti gli identificativi dei file di progetto. L’applicazione generata avra co-

me SO target iOS 9 sia per iPhone che per iPad, e tramite l’applicazione dedicata di

watchOS sara possibile connettere il dispositivo all’orologio e installare la controparte

86


dell’applicativo. I componenti generati per iOS sono tutti e soli i widgets disponibili

nativamente all’interno di Xcode, ad eccezione della CardView che e un componente

specifico della piattaforma Android, e che e stato replicato creando una View persona-

lizzata.

Si presenta in seguito una descrizione dettagliata della logica applicativa di tutti i

componenti generati al termine della traduzione con MobileCodeGenerator.

Widget Android iOS

Button

Dichiarazione di un oggetto

Button. Metodo onClick()

dichiarato all’interno di

onCreateView() oppure

onCreate() a seconda della

presenza o meno del menu, che

gestisce eventualmente la

navigazione tramite Intent.


UIButton. Metodi touchDown()

e touchUpInside() che

gestiscono l’interazione con il

bottone. La logica di

navigazione e a carico della

Storyboard.

EditTextDichiarazione di un oggetto

AppCompatEditText.


UITextField.

Spinner


AppCompatSpinner. Metodi

onItemSelected() e

onNothingSelected() dichiarati

all’interno di onCreateView()

oppure onCreate() e invocati

sui rispettivi eventi.


UIPickerView. Metodi

pickerView(...) per gestire il

contenuto dello Spinner e la

selezione di un elemento.

87


Switch


SwitchCompat. Metodo

onCheckedChanged() dichiarato


oppure onCreate() e invocato

nel momento in cui vi e un

cambio di stato dello Switch.


UISwitch. Metodo

valueChangedAction() per

rilevare lo stato dello Switch.

Slider


AppCompatSeekBar. Metodi

onProgressChanged(),

onStartTrackingTouch() e

onStopTrackingTouch()

dichiarati all’interno di


onCreate() e invocati sui

rispettivi eventi.


UISlider. Metodo


rilevare lo stato dello Slider.

WebView


WebView. Metodo

loadDataWithBaseURL()



onCreate(), che carica il

contenuto HTML della

WebView.


UIWebView. Metodo

loadRequest() che carica il

contenuto HTML della

UIWebView.

88


ImageView


ImageView. Metodo ImageDo-

wnloadingTask().execute()



onCreate(), che scarica

l’immagine nel caso sia di tipo

remoto e non fra le risorse di

progetto.


UIImageView. Metodo

ImageDownloadingTa-

sk().downloadImage() che

scarica l’immagine nel caso sia

di tipo remoto e non fra le

risorse di progetto.

VideoView


VideoView. Inizializzazione


oppure onCreate(), che carica il

file sorgente ed esegue la

riproduzione del video.


UIWebView. Inizializzazione

all’interno di viewDidAppear()

che carica un iFrame HTML

all’interno della WebView

contenente l’indirizzo del

filmato.

AudioPlayer

Dichiarazione di 3 oggetti

FloatingActionButton (play,

pause e stop) e un MediaPlayer.

Metodi onClick() per ciascun

bottone che richiamano i

metodi MediaPlayer.play(),

MediaPlayer.pause() e

MediaPlayer.stop(). Gestione

della riproduzione audio

all’interno di onResume() e

onPause() dell’Activity.


AVAudioPlayer inizializzato in

viewDidAppear(). Metodi

play(), pause() e stop() collegati

ai bottoni della Storyboard.

Gestione della riproduzione

audio all’interno di

viewDidAppear() e

viewDidDisappear() del

ViewController.

89


ListView

Dichiarazione degli oggetti

ListView e ListViewAdapter,

dichiarazione di array di Integer

e String a seconda degli

elementi che decorano la

ListView. Metodo

onItemClick() che gestisce

eventualmente la navigazione

tramite Intent.


UITableView, dichiarazione di

array di UIImage e String a

seconda degli elementi che

decorano la ListView. Metodi

tableView(...) per gestire il

contenuto della ListView, e

prepareForSegue() per

configurare i parametri da

passare eventualmente durante

la navigazione.

GridView


GridView e GridViewAdapter,

dichiarazione di array di Integer

e String a seconda degli

elementi che decorano la

GridView. Metodo

onItemClick() che gestisce


tramite Intent.


UICollectionView, dichiarazione

di array di UIImage e String a

seconda degli elementi che

decorano la GridView. Metodi

collectionView(...) per gestire il

contenuto della GridView, e

prepareForSegue() per

configurare i parametri da

passare eventualmente durante

la navigazione.

90


Photocamera

Controller


Button o ImageButton. Metodo

onClick() dichiarato all’interno

di onCreateView() oppure

onCreate(), che gestisce

eventualmente l’accesso alla

fotocamera tramite Intent.

Metodi

copyImageInImagesFolder() e

onActivityResult() per gestire il

ritorno dalla fotocamera.

Metodi openPhotoCamera() e

imagePickerController() per

accedere alla fotocamera del

dispositivo, metodo UIImageW-

riteToSavedPhotosAlbum() per

salvare la fotografia.

Videocamera

Controller


Button o ImageButton. Metodo

onClick() dichiarato all’interno

di onCreateView() oppure

onCreate(), che gestisce

eventualmente l’accesso alla

videocamera tramite Intent.

Metodi

copyVideoInVideosFolder() e

onActivityResult() per gestire il

ritorno dalla videocamera.

Metodi openVideoCamera e

imagePickerController per

accedere alla videocamera del

dispositivo, metodo UISaveVi-

deoAtPathToSavedPhotosAlbum

per salvare il filmato.

91


Audio

Recorder


Button e un MediaRecorder.

Metodi setUpAudioRecorder(),

startRecording() e

stopRecording( ), richiamati in

maniera differente a seconda

della presenza o meno del menu

di navigazione. Gestione della

registrazione audio all’interno

di onResume() e onPause()

dell’Activity.


UIButton e AVAudioRecorder.

Metodo record() per richiamare

il microfono del dispositivo.

Gestione della registrazione

audio all’interno di

onResume(viewDidAppear) e

viewDidDisappear() del

ViewController.

Map


MapView e GoogleMap, il

primo utilizzato nei Fragment

in assenza di menu di

navigazione, il secondo nelle

normali Activities. Metodo

onMapReady() che inizializza la

mappa e la centra alle

coordinate stabilite.


MKMapView. Inizializzazione

all’interno di viewDidLoad() che

centra la mappa nelle

coordinate stabilite.

Datepicker


MaterialCalendarView. Metodo

onDateSelected() dichiarato


oppure onCreate(), che rileva la

data selezionata.


UIDatePicker. Metodo


rilevare la data selezionata.

92


Timepicker


Picker. Metodo timeChanged()



onCreate() a seconda della

presenza o meno del menu di

navigazione, che rileva l’orario

selezionato.


UIDatePicker. Metodo


rilevare l’orario selezionato.

Card


CardView, ImageView e




onCreate(), che rileva il click di

un bottone nella CardView.

Metodo setUpCardView() per

scalare correttamente la

CardView rispetto alla

dimensione dello schermo.


UIView, che ricalca l’aspetto

della CardView Android grazie

alla composizione di molteplici

Views all’interno della

Storyboard. Metodo

touchUpInside() per rilevare la

selezione di un particolare

bottone nella Card.

Alert

Dialog

Metodo show() invocato

all’interno di

setUserVisibilityHint() oppure

onCreate(), che richiama

l’oggetto AlertDialog.Builder e

il metodo AlertDialog.show()

Metodo

presentViewController()

invocato all’interno di

viewDidAppear() su di un

oggetto UIAlertController.

93


Progress

Dialog

Metodo show() invocato

all’interno di

setUserVisibilityHint() oppure

onCreate(), che richiama

l’oggetto ProgressDialog e il

metodo ProgressDialog.show()

Metodo

presentViewController()


viewDidAppear() su di un

oggetto UIAlertController.

AsyncTask

Metodo

AsyncTask.execute(/*param1,

param2 ... */) invocato


oppure onCreate(), che

richiama i metodi

doInBackground(Void...

params),

onProgressUpdate(Void...

progress) e onPostExecute(Void

result)

Metodo dispatch async()


viewDidLoad() che permette di

riprodurre dei task in maniera

asincrona e dunque proseguire

con le operazioni successive.

Tabella 4.1: Tabella dei widget smartphone tradotti con MobileCodeGenerator

94


Widget AndroidWear watchOS

WatchButton




onLayoutInflated(), che gestisce


tramite Intent.


WKInterfaceButton. Metodo

action() che gestisce

l’interazione col bottone.

WatchSwitch


Switch. Metodo

onCheckedChanged() dichiarato

all’interno di onLayoutInflated()

e invocato nel momento in cui

vi e un cambio di stato dello

Switch.


WKInterfaceSwitch. Metodo


rilevare lo stato dello Switch.

WatchSlider


SeekBar. Metodi

onProgressChanged(),

onStartTrackingTouch() e

onStopTrackingTouch()

dichiarati all’interno di

onLayoutInflated() e invocati

sui rispettivi eventi.


WKInterfaceSlider. Metodo

action() per rilevare lo stato

dello Slider.

95


WatchVoice

Message


Button, GoogleApiClient e

DelayedConfirmationView.

Metodi

displaySpeechRecognizer() che

visualizza il traduttore

speech-to-text di Google,

displayDelayedViewContainer()

che visualizza il Dialog animato

per l’invio del messaggio

registrato, e infine

sendMessage(String message)

che invia il messaggio al

dispositivo associato

all’orologio.


WCSession, inizializzato

all’interno di willActivate() per

stabilire se l’orologio sia

connesso o meno allo

smartphone. Metodo

send(messageId: String) che

mostra il traduttore

speech-to-text di watchOS e

invia il messaggio al dispositivo

associato.

Tabella 4.2: Tabella dei widget smartwatch tradotti con MobileCodeGenerator

Come evidenziato in tabella, l’inizializzazione dei componenti Android e fortemente in-

fluenzata dalla presenza o meno del menu di navigazione, poiche i gruppi di Fragments

hanno un ciclo di vita differente rispetto alle normali Activities: non e possibile infatti

riportare tutto cio che viene normalmente inizializzato all’interno del metodo onCreate

delle Activities all’interno dell’onCreateView dei Fragments, poiche questo permette-

rebbe ad esempio ad un Fragment appena creato ma non ancora visibile sullo schermo,

di riprodurre una traccia audio/video o mostrare dei Dialog che niente hanno a che

fare con il Fragment che viene realmente mostrato. Casi come quello appena descritto,

hanno fatto sı che per ciascun componente, si e dovuto analizzare quale fosse il modo

migliore possibile per inizializzarlo senza intaccare le schermate adiacenti a quella cor-

rentemente attiva, ad esempio verificando se il Fragment fosse realmente visibile (oltre

che attivo) tramite il metodo setUserVisibilityHint(). Nonostante questo abbia reso il

96


meccanismo di traduzione decisamente piu complesso rispetto a quello sviluppato in

Swift per iOS, si e riusciti dunque ad ottenere un comportamento pressoche identico

su entrambe le piattaforme.

Per quanto riguarda gli smartwatch, si e cercato di creare dei componenti che non

fossero soltanto rilegati alla dimensione dell’orologio, ma che fossero gia in grado di

comunicare con lo smartphone associato: in particolare, il WatchVoiceMessage e un

bottone che permette di inviare un messaggio registrato dall’orologio tramite il mec-

canismo dei Messages di AndroidWear, oppure delle WCSessions di watchOS. In en-

trambi i casi, quando lo smartphone o in generale il dispositivo cosiddetto handheld si

connettera con lo smartwatch e avviera l’applicazione, ricevera tutti i messaggi inviati

dall’orologio e li manterra in memoria fino alla chiusura dell’applicazione, a meno che

non vengano salvati in maniera persistente nel database del dispositivo.

Infine si vuole precisare che, l’interfaccia grafica dei componenti, ricalca perfettamen-

te la descrizione gia affrontata nella sezione relativa a Protocode, ed e stata percio

volutamente esclusa dalla precedente tabella di riepilogo; nel prossimo capitolo verra

mostrata un’analisi qualitativa e quantitativa dello sviluppo di un’applicazione mobile

tramite l’utilizzo della toolchain descritta fino ad ora, al fine di dimostrare le reali

capacita di questo strumento nella fase iniziale dello sviluppo di applicazioni mobili.

97

Capitolo 5

Valutazione

In questo capitolo vengono presentati due esempi di processo di sviluppo di un’ap-

plicazione mobile tramite gli strumenti Protocode e MobileCodeGenerator: nel primo

caso, viene valutata la quantita di codice sorgente che e stato possibile generare per

un’applicazione di medie dimensioni creata da zero, mentre nel secondo caso si e cer-

cato di riprodurre il piu fedelmente possibile l’interfaccia grafica di un’applicazione gia

presente sul mercato, per valutare la qualita degli strumenti sviluppati.

5.1 Analisi quantitativa

Per analizzare i risultati prodotti della toolchain Protocode/MobileCodeGenerator e

stata creata un’applicazione mobile per smartphone e smartwatch chiamata ParkTrai-

ning : si tratta di un’applicativo dedicato all’allenamento all’aria aperta, che permette

all’utente di raccogliere una serie di esercizi, di registrare fotografie e filmati dell’alle-

namento e di salvare delle posizioni relative ai luoghi di allenamento preferiti. Tramite

lo smartwatch, l’utente e in grado di aggiungere nuovi esercizi, semplicemente selezio-

nando il numero di ripetizioni e pronunciando il nome del nuovo esercizio, che verra

automaticamente inviato allo smartphone e salvato in maniera persistente. Si descrive

in seguito il modello dell’applicazione ParkTraining generato tramite Protocode.

98

5. VALUTAZIONE

Figura 5.1: Modello dell’applicazione ParkTraining su smartphone

99

5. VALUTAZIONE

Figura 5.2: Modello dell’applicazione ParkTraining su smartwatch

Come e possibile intuire dal modello appena proposto, l’applicazione e composta sostan-

zialmente da 4 schermate, tutte racchiuse nel menu di navigazione principale: ognuna

di queste, mostra l’elenco di esercizi, foto, video e luoghi salvati all’interno dell’applica-

zione, alcuni sottoforma di lista, altri sottoforma di griglia; inoltre, ciascuna schermata

contiene un bottone in grado di aggiungere un nuovo elemento dello stesso tipo, ovvia-

mente secondo meccanismi differenti.

Innanzitutto la schermata degli esercizi, e quella che verra mostrata per prima al-

l’avvio dell’applicazione, e contiene appunto una lista di tutti gli esercizi, con nome e

numero di ripetizioni; facendo click su un elemento della lista, viene creata una nuova

schermata che consente di modificare le ripetizioni o il nome dell’esercizio. Premendo

invece sul bottone presente nella schermata principale, e possibile aggiungere un nuovo

esercizio tramite una schermata contenente un campo di testo e un paio di spinner che

indicano il numero di serie e di ripetizioni.

100

5. VALUTAZIONE

Nel caso di foto e video invece, premendo sul bottone presente in basso nello schermo,

viene creata una nuova schermata contenente il bottone che richiama rispettivamente

la fotocamera o la videocamera dello smartphone, e la relativa ImageView o Video-

View che mostrano il file catturato dal dispositivo: e quindi possibile salvare il file

appena creato, oppure semplicemente tornare alla schermata precedente. Nella scher-

mata principale delle foto, naturalmente, viene mostrata una griglia contente tutte le

immagini in anteprima, mentre in quella dei video, la griglia mostra il primo frame di

ogni filmato e la sua durata totale.

Per quanto riguarda i luoghi di allenamento, e possibile aggiungere nuove posizioni

facendo click sul bottone in basso nella schermata, che recupera le attuali coordinate

dell’utente tramite GPS e le salva direttamente nel database dell’applicazione; cliccan-

do su di uno dei luoghi presenti nella lista principale invece, viene mostrata la posizione

del luogo di allenamento selezionato all’interno di una mappa.

Le schermate presenti su smartwatch infine sono solamente 3, e permettono di sele-

zionare in questo ordine, il numero di serie, il numero di ripetizioni e il nome dell’eser-

cizio da aggiungere alla raccolta presente sullo smartphone: cliccando sul bottone rec

presente nell’ultima schermata, verra richiamata la funzionalita speech-to-text dell’oro-

logio, che traduce in una stringa di testo l’input vocale registrato dall’utente e la invia

direttamente allo smartphone per salvarla in maniera persistente.

101

5. VALUTAZIONE

Figura 5.3: Applicazione ParkTraining simulata su Apple Watch 42mm

Figura 5.4: Applicazione ParkTraining simulata su iPhone6s Plus - 1

102

5. VALUTAZIONE

Figura 5.5: Applicazione ParkTraining simulata su iPhone6s Plus - 2

103

5. VALUTAZIONE

5.1.1 Android

Una volta tradotto il modello dell’applicazione in un progetto Android Studio tramite

MobileCodeGenerator, e stato necessario effettuare alcune modifiche preliminari al co-

dice sorgente, per correggere il comportamento di alcuni componenti dell’applicativo:

innanzitutto, e stata creata una Google Map API key tramite la Developers Console

di Google (http://console.developers.google.com) ed e stata inserita all’interno

del file Manifest dell’applicazione, per poter inizializzare la Google Map all’interno

dell’Activity Locations. Quindi, sono stati spostati i metodi show() relativi ai Dialog

di conferma per la cancellazione di esercizi, foto, video e luoghi, all’interno della fun-

zione che viene evocata quando l’utente clicca appunto sul bottone di cancellazione;

in origine infatti, i Dialogs creati su Protocode e tradotti in codice sorgente, venivano

semplicemente visualizzati all’apertura della relativa Activity. Infine, sono stati sosti-

tuiti tutti i testi come “add” o “delete” presenti sui bottoni, con le rispettive icone di

salvataggio e cancellazione.

A questo punto, l’applicazione necessitava dell’introduzione di uno strato di dati per-

sistente, in maniera da divenire concretamente utilizzabile: per fare cio, sono state

create le classi Java che permettono all’applicazione di interfacciarsi con il database

SQLite del dispositivo, ovvero le classi relative agli oggetti Exercise.java, Photo.java,

Video.java e Location.java oltre che al SQLiteHelper.java e al DatabaseAdapter.java

necessari per la gestione delle operazioni CRUD (Create Read Update Delete) sulla

base di dati.

Infine, e stato modificato il WearableListenerService.java, ovvero la classe incarica-

ta di gestire la ricezione dei messaggi dallo smartwatch, in maniera tale che questi

venissero converiti in oggetti Exercise.java e inseriti nel database; d’altra parte, non

e stato necessario intervenire pesantemente sul codice sorgente generato per lo smart-

watch, che e risultato essere completo quasi al 100%, se non per il semplice passaggio

di parametri da una scherma all’altra, che ha necessitato di pochissime righe di codice.

104

5. VALUTAZIONE

Si presenta di seguito una tabella relativa alle Logical SLOC del progetto Android Stu-

dio (ovvero le righe di codice che compongono il progetto senza considerare i commenti

e gli spazi vuoti fra gli statementes) sia cosı come generato da MobileCodeGenerator

e sia cosı come si presenta nella sua forma finale, al termine delle modifiche descritte

sopra.

App Generata App Completa Percentuale

Mobile Java SLOC 1254 1967 63.8%

Mobile XML 1591 1591 100%

Wear Java SLOC 285 295 96.6%

Wear XML 761 761 100%

Tabella 5.1: Copertura codice sorgente ParkTraining Android Studio

5.1.2 iOS

Per quanto riguarda la generazione del progetto Xcode tramite MobileCodeGenerator,

sono state effettuate anche in questo caso alcune modifiche preliminari, del tutto simili

alle precedenti introdotte per Android: sono stati spostati i metodi relativi alla visua-

lizzazione dei Dialogs di cancellazione di esercizi, foto, video e luoghi, all’interno della

funzione che viene evocata quando l’utente clicca appunto sul bottone di cancellazione,

e sono stati sostituiti tutti i testi come “add” o “delete” presenti sui bottoni, con le

rispettive icone di salvataggio e cancellazione.

A questo punto, per poter creare e manipolare gli oggetti dell’applicazione in ma-

niera persistente, e stato necessario introdurre la libreria Core Data all’interno del

progetto: essa fa si che i dati vengano manipolati utilizzando degli oggetti ad alto

livello (NSManagedObject), che rappresentano le relazioni e gli attributi tra le entita

del modello dell’applicazione, interfacciandosi direttamente con SQLite e slegando il

105

5. VALUTAZIONE

programmatore dalla gestione a basso livello della base di dati. In altre parole, e sta-

to importato un riferimento alla libreria Core Data nell’ApplicationDelegate.swift del

progetto, e sono stati scritti tutti i metodi necessari per gestire le operazioni CRUD.

Anche in questo caso, il codice generato per la parte smartwatch dell’applicazione

e risultato essere completo quasi al 100% se non per il semplice passaggio di parametri

da una scherma all’altra, che ha necessitato di pochissime righe di codice; naturalmen-

te, all’interno dell’ApplicationDelegate dello smartphone, e stato modificato il codice

relativo alla ricezione dei messaggi, per poter salvare in maniera persistente gli esercizi

inviati dallo smartwatch.

Si presenta di seguito una tabella relativa alle Logical SLOC del progetto Xcode, sia

cosı come generato da MobileCodeGenerator e sia cosı come si presenta sua forma fi-

nale, al termine delle modifiche descritte sopra.

App Generata App Completa Percentuale

App Swift SLOC 951 1167 81.5%

App Storyboard 1059 1059 100%

Tabella 5.2: Copertura codice sorgente ParkTraining Xcode

5.1.3 Considerazioni finali

I risultati raccolti al termine di questo esperimento, permettono di trarre una serie

di conclusioni sugli strumenti sviluppati: in primo luogo, come previsto all’inizio della

progettazione, tutto cio che riguarda il funzionamento dell’interfaccia grafica dell’appli-

cazione non ha necessitato in alcun caso di un intervento successivo tramite gli IDE di

sviluppo nativi, confermando la qualita dello strumento di prototipizzazione. In buona

sostanza, sia per Android che per iOS, e stato necessario semplicemente configurare le

106

5. VALUTAZIONE

classi e i metodi necessari all’applicazione per creare e manipolare le informazioni in

maniera persistente, tramite il database SQLite del dispositivo: di conseguenza, sono

stati modificati gli statements che servivano a popolare i componenti come le ListView

e le GridView in maniera che ricevessero le informazioni in maniera dinamica tramire

i records contenuti nelle tabelle dell’applicazione.

Risulta evidente come la copertura di codice generata automaticamente per iOS sia

nettamente superiore a quella generata per Android, ma questo e in larga misura do-

vuto al fatto che per configurare il Core Data di iOS, e stato sufficiente popolare un

file di estensione .xcdatamodeld con la lista delle tabelle del database e i loro attributi,

mentre per Android sono state create ben 6 classi Java per lo stesso obiettivo. Per

l’esattezza, sono state conteggiate 411 SLOC Java relative al SQLAdapter, al Databa-

seAdapter e alle 4 classi dei modelli, di conseguenza, se si sottraggono queste righe di

codice al totale delle SLOC conteggiate in tabella, otteniamo solamente 1556 SLOC

Java: questo significa sostanzialmente una copertura di codice sorgente pari all’ 80.6%,

risultato molto simile a quello ottenuto per iOS.

Il nuovo risultato tiene comunque in considerazione tutte le modifiche introdotte per

richiamare i metodi necessari a manipolare gli oggetti dell’applicazione in maniera per-

sistente, ma lascia in disparte tutto il codice Java che non ha una precisa controparte

Swift, in quanto appunto la configurazione dello strato dati dell’applicativo avviene

quasi totalmente tramite il file .xcdatamodeld e senza utilizzare nuove classi Swift ad-

hoc, come invece avviene per Android.

Per quanto riguarda invece il tempo necessario allo sviluppo dell’applicazione, si puo

innanzitutto escludere quello necessario all’integrazione tra l’applicativo e il database

del dispositivo, poiche si tratta di una fase inevitabile sia con il normale approccio

tramite IDE, sia utilizzando la toolchain Protocode/MobileCodeGenerator: dunque,

sarebbe possibile in linea teorica, valutare quantomeno il tempo necessario a produrre

lo stesso risultato ottenuto con la suddetta toolchain, utilizzando solamente gli IDE di

sviluppo nativi.

107

5. VALUTAZIONE

Tuttavia, si tratta di una valutazione che risulta estremamente legata alle capacita dello

sviluppatore e alle dimensioni dell’applicazione, percio ci si limita a sottolineare che per

questa particolare applicazione e stato sufficiente un arco di tempo fra i 60-90 minuti

utilizzando Protocode/MobileCodeGenerator, e che per produrre la stessa interfaccia

grafica con Android Studio e Xcode e stata necessaria una quantita di tempo pressoche

identica per ciascun IDE, senza pero ottenere automaticamente tutta la controparte

logica Java e Swift. Questo dato ci porta ad affermare con assoluta certezza, che i

tempi di sviluppo tramite la toolchain Protocode/MobileCodeGenerator sono inferiori

almeno del 50% rispetto al normale approccio tramite gli IDE nativi.

108

5. VALUTAZIONE

5.2 Analisi qualitativa

In questa sezione si propone un’analisi qualitativa della toolchain Protocode e Mobile-

CodeGenerator, andando a replicare l’interfaccia grafica di un’applicazione gia esistente

sul mercato e confrontando il risultato finale della traduzione del modello astratto, con

l’applicativo vero e proprio. Per fare cio si e scelta l’applicazione WhatsApp [75], ov-

vero la ben nota app di instant messaging disponibile su entrambe le piattaforme, iOS

e Android, che chiunque oggigiorno possiede sul proprio smartphone: si sottolinea an-

cora una volta, che non e intenzione di questo esempio riprodurre un’applicazione di

messaggistica istantanea completa e funzionante, ma semplicemente stabilire se e pos-

sibile creare un ottimo punto di partenza per l’applicazione WhatsApp almeno sotto il

punto di vista puramente estetico.

Vengono di seguito riportate alcune immagini che mettono a confronto le scherma-

te realizzate con Protocode e MobileCodeGenerator con quelle reali dell’applicazione

WhatsApp.

Figura 5.6: Immagini a confronto della schermata chat di WhatsApp

109

5. VALUTAZIONE

Figura 5.7: Immagini a confronto della schermata dettaglio chat di WhatsApp

Figura 5.8: Immagini a confronto della schermata impostazioni di WhatsApp

La prima immagine da sinistra, rappresenta la schermata catturata direttamente da

Protocode in fase di prototipizzazione, mentre l’ultima immagine sulla destra, rap-

presenta la schermata originale di WhatsApp catturata su di un dispositivo reale; la

schermata centrale dunque, e quella che viene generata tramite MobileCodeGenerator,

alla quale e stato semplicemente cambiato il colore e il testo della Tool Bar all’interno

di Android Studio, senza modificare ovviamente tutto il resto dei contenuti.

110

5. VALUTAZIONE

In questo esempio, si e scelto di riprodurre solamente una porzione dell’intera applica-

zione, soprattutto poiche buona parte della navigazione dei contenuti viene gestita in

maniera differente nelle versioni Android e iOS di WhatsApp. Ecco alcuni commenti

ai risultati ottenuti:

� Tutte le ListView che sono state create sono piuttosto simili a quelle originali, ed

e comunque possibile con poche e semplici modifiche ai file di layout di Android

o alla Storyboard di iOS, ottenere un risultato identico all’originale.

� Il menu di navigazione e solamente parziale, poiche nello specifico su Android,

alcune funzioni sono state rilegate a dei bottoni nella Tool Bar in alto: per fare

cio sarebbe sufficiente introdurre questi bottoni e aggiungere i collegamenti alle

relative schermate, mentre su iOS si tratterebbe di proseguire la navigazione

al’interno della Bottom Bar.

� La schermata di dettaglio di una conversazione e composta da elementi grafici

molto semplici, e anche se sono stati riprodotti solo con discreta fedelta, bisogna

sottolineare che sia il collegamento alla fotocamera che quello al microfono, sono

gia perfettamente funzionanti.

In generale dunque, si puo affermare che effettivamente l’utilizzo della toolchain svi-

luppata permetta di creare un ottimo punto di partenza per la realizzazione di un’ap-

plicazione mobile di questo tipo, producendo in un colpo solo ben due progetti nativi,

pronti ad essere continuati (eventualmente in direzioni differenti) senza alcun tipo di

criticita. Quello che appare evidente e la scarsa possibilita di accedere alla Tool Bar di

Android gia in fase di prototipizzazione, ma e comunque un risultato che ci si aspetta,

nel momento in cui si considera che il modello originale deve essere il piu possibile

uniforme e trasparente alle due piattaforme Android e iOS, per non vincolare nessuna

delle due ad elementi esclusivi dell’altra.

111

Capitolo 6

Conclusioni

Il lavoro svolto in questo progetto di tesi ha permesso di creare uno strumento estre-

mamente potente nello sviluppo di applicazioni mobile native iOS, Android e le loro

piattaforme wearable, dimostrando che la soluzione model-driven adottata, puo risulta-

re vantaggiosa rispetto ai metodi di progettazione tradizionali sotto molti punti di vista.

L’interfaccia grafica delle applicazioni prodotta grazie a Protocode e sicuramente equi-

parabile a quella dei maggiori tool di prototipizzazione presenti oggi sul web, e com-

prende tutti i widgets disponibili all’interno degli ambienti di sviluppo nativi Xcode e

Android Studio con l’ulteriore vantaggio di poter decidere se modellare un componente

nella stessa maniera per entrambe le piattaforme, oppure rispettare l’aspetto tipico del

sistema operativo finale. Grazie alla sua semplicita e immediatezza, l’editor grafico di

Protocode permette di realizzare un’interfaccia grafica all’avanguardia, praticamente

con la stessa velocita degli editor presenti negli IDE di sviluppo nativi, e laddove natu-

ralmente non e stato possibile raggiungere lo stesso livello di dettaglio, e stata invece

garantita la generazione automatica di ogni singolo componente sotto il punto di vista

della sua logica applicativa.

112

6. CONCLUSIONI

Il risultato prodotto dalla toolchain per quanto riguarda gli smartwatch, puo consi-

derarsi gia un ottimo punto di partenza per il futuro, in quanto non solo sono presenti

tutti i maggiori widgets dedicati agli orologi, ma e anche gia possibile generare auto-

maticamente un primo meccanismo di comunicazione verso gli smartphones. Poiche si

tratta di una realta in continua evoluzione, sara presto necessario migliorare la qualita

delle interfacce e provare a generare piu meccanismi di comunicazione, che al momento

sono disponibili in una sola direzione.

Sebbene sia oggettivamente impossibile stabilire numericamente, quanto tempo sia

possibile risparmiare tramite la toolchain Protocode/MobileCodeGenerator, poiche sa-

rebbe necessario un grosso campione di applicazioni e sviluppatori, e senza dubbio

evidente che anche soltanto la generazione delle interfacce permetta di risparmiare il

50% del tempo necessario, per il semplice fatto che da un unico modello vengono ge-

nerati ben due applicativi. Inoltre, qualunque siano le capacita di uno sviluppatore,

e ragionevole pensare che non possa che impiegare una buon quantita di tempo piu

o meno rilevante per descrivere la logica applicativa di ogni singolo componente, che

invece viene generata in pochissimi secondi grazie a MobileCodeGenerator. Infine, sara

sı necessaria una piu o meno consistente fase di testing e debugging dell’applicazione,

ma quantomeno per i singoli componenti e stato gia “garantito” il loro corretto fun-

zionamento, dai lunghi mesi di verifica che sono stati spesi durante la realizzazione di

MobileCodeGenerator.

L’utilizzo di questi strumenti nello sviluppo di applicazioni mobili native, risulta van-

taggiosa sia per un team di sviluppatori esperti, che possono risparmiare un’enorme

quantita di tempo nella definizione della struttura portante dell’applicativo, sia per

gli sviluppatori in erba, poiche mette a disposizione un intero progetto Android o

iOS e una serie di meccanismi piuttosto avanzati, senza doversi preoccupare di svi-

lupparli dal principio. Per tutti questi motivi, si ritiene che la toolchain realizzata

secondo l’approccio model-driven, possa essere davvero uno strumento in grado di sup-

portare concretamente lo sviluppo di applicazioni mobili native, rendendo la fase di

prototipizzazione parte integrante nella stesura del codice sorgente.

113

6. CONCLUSIONI

6.1 Sviluppi futuri

Per quanto riguarda gli eventuali sviluppi futuri degli strumenti realizzati, e possibile

definire delle linee guida su cio che sarebbe necessario approfondire ulteriormente per

continuare a mantenere il passo con le applicazioni mobili piu moderne, ed evidenziare

una soluzione relativa alla generazione dello strato di dati dell’applicativo, che come

visto in precedenza, necessita di una configurazione piuttosto lunga e ripetitiva, so-

prattutto per la piattaforma Android.

Per quanto riguarda l’interfaccia grafica delle applicazioni su smartphone, e possibile

identificare 3 elementi che sono sicuramente il punto di partenza per rimanere al passo

con la continua evoluzione dei layout delle due piattaforme:

� I containers, ovvero delle view vuote in cui organizzare una serie di widgets del-

l’applicazione: sebbene sia abbastanza semplice raggruppare piu elementi all’in-

terno degli editor forniti dagli IDE nativi, introdurre un componente del genere

gia all’interno di Protocode, permetterebbe di risparmiare molto tempo nella

ridefinizione dei vincoli di posizionamento.

� Le liste o griglie di CardViews, che possano essere scrollate in orizzontale o in

verticale dall’utente, per racchiudere parecchie funzionalita all’interno di un unico

componente particolarmente elaborato ma estremamente intuitivo.

� Il menu laterale di navigazione, che sebbene sia un elemento nativo dell’ambiente

Android, e possibile introdurre anche per iOS tramite l’utilizzo di librerie di terze

parti, e rappresenta un elemento ormai molto comune per molte applicazioni

mobili multipiattaforma.

Introdurre gli elementi sopra descritti, rappresenterebbe gia di per se un notevole sfor-

zo nell’aggiornamento della toolchain Protocode/MobileCodeGenerator ma porterebbe

sicuramente un contributo sostanziale nel miglioramento dell’applicazione.

114

6. CONCLUSIONI

Come gia detto nella sezione relativa all’analisi quantitativa degli strumenti, sareb-

be interessante anche provvedere ad introdurre una sezione all’interno di Protocode,

che permetta all’utente di elencare le tabelle SQLite e le loro proprieta relazionali, per

poi generarle automaticamente tramite MobileCodeGenerator: questo porterebbe sicu-

ramente ad aumentare la copertura di codice sorgente soprattutto per quanto riguarda

il mondo Android, liberando lo sviluppatore dalla necessita di creare le relative classi

Java manualmente.

Infine, relativamente alla generazione del software per smartwatch, si ritiene che i

widget attualmente disponibili siano piuttosto validi ma che sarebbe opportuno appro-

fondire il loro livello di modellazione e successivamente introdurre anche delle ListView

in versione wearable per un supporto piu completo. L’interazione fra orologi e smart-

phone, risulta in generale un meccanismo strettamente collegato all’applicazione che

si intende sviluppare e difficile da modellare in maniera del tutto generale: sulla falsa

riga di quanto detto per i database SQLite, si potrebbe pensare di modellare in par-

tenza alcuni oggetti che in futuro potrebbero essere utilizzati sia su smartwatch che su

smartphone, secondo i principi di sincronizzazione implementati dalle due piattaforme

mobili.

115

Bibliografia

[1] Apple Inc. - Cupertino, California, USA

http://www.apple.com

[2] Samsung Group - Samsung Town, Seoul, Corea del Sud

http://www.samsung.com

[3] Huawei Technologies Co. Ltd. - Shenzhen, Guandong, Cina

http://www.huawei.com

[4] International Data Corporation - Top Five Smartphone Vendors, Shipments,

Market Share and Year-Over-Year Growth, Q1 2016. 27 Aprile 2016

http://www.idc.com/getdoc.jsp?containerId=prUS41216716

[5] iOS - Apple Inc. - http://www.apple.com/ios/

[6] Android - Google Inc. - http://www.android.com

[7] Google Inc. - Mountain View, California, USA

http://www.google.com

[8] Windows Phone Operating System - Microsoft Corporation

http://www.microsoft.com/it-it/windows/phones

[9] BlackBerry Operating System - BlackBerry Ltd.

http://global.blackberry.com/en/software/smartphones/

blackberry-10-os.html

[10] Gartner - Gartner Says Worldwide Smartphone Sales Grew 3.9 Percent in First

Quarter of 2016. 19 Maggio 2016.

http://www.gartner.com/newsroom/id/3323017

[11] Apple Watch - Apple Inc. -

http://www.apple.com/watch

116

http://www.apple.com


http://www.huawei.com

http://www.idc.com/getdoc.jsp?containerId=prUS41216716

http://www.apple.com/ios/

http://www.android.com

http://www.google.com

http://www.microsoft.com/it-it/windows/phones

http://www.global.blackberry.com/en/software/smartphones/blackberry-10-os.html

http://www.global.blackberry.com/en/software/smartphones/blackberry-10-os.html

http://www.gartner.com/newsroom/id/3323017


BIBLIOGRAFIA

[12] Samsung Gear Line - Samsung Electronics -


[13] Strategy Analytics - Apple Watch Slips to 52% Global Smartwatch Marketshare

in Q1 2016. 28 Aprile 2016.

http://bit.ly/strategy-analytics-press-releases-20160428

[14] LG Corporation - Seoul, Corea del Sud - http://www.lg.com

[15] Motorola Inc. - Schaumburg, Illinois, USA - http://www.motorola.com

[16] ASUSTeK Computer Inc. - Beitou District, Taipei, Taiwan

http://www.asus.com

[17] Tizen - Tizen Association, Samsung, Intel - http://www.tizen.org/

[18] Android Wear - Google Inc. - http://www.android.com/wear/

[19] Apple Watch - Apple Inc. - http://www.apple.com/watch

[20] Material Design - Google Inc. - http://material.google.com/

[21] FluidUI - Fluid Software - http://www.fluidui.com

[22] Proto.io - Labs Division of SNQ Digital - http://proto.io

[23] InvisionApp - InVision - http://www.invisionapp.com

[24] Pixate - Google Inc. - http://www.pixate.com

[25] Microsoft Windows - Microsoft Corporation - http://www.microsoft.com

[26] OSX - Apple Inc. - http://www.apple.com/osx

[27] AngularJS - Google Inc. - http://www.angularjs.org

[28] Apache Cordova - Apache Cordova - http://cordova.apache.org

[29] Microsoft Visual Studio - Microsoft Corporation -

http://www.visualstudio.com

117


http://bit.ly/strategy-analytics-press-releases-20160428

http://www.lg.com

http://www.motorola.com

http://www.asus.com

http://www.tizen.org/

http://www.android.com/wear/


http://material.google.com/

http://www.fluidui.com

http://proto.io

http://www.invisionapp.com

http://www.pixate.com

http://www.microsoft.com

http://www.apple.com/osx

http://www.angularjs.org

http://cordova.apache.org

http://www.visualstudio.com

BIBLIOGRAFIA

[30] Xamarin - Microsoft Corporation - http://www.xamarin.com

[31] V8 Javascript Engine - The Chromium Project -

http://developers.google.com/v8/

[32] Titanium Studio - Appcelerator Inc.

http://www.appcelerator.com/developers

[33] Appcelerator Titanium - Appcelerator Inc. -


[34] React Native - Facebook Inc. - http://facebook.github.io/react/

[35] NativeScript - Telerik - http://www.nativescript.org/

[36] Ionic Framework - Drifty - http://ionicframework.com

[37] Android Studio - Google Inc. - http://developer.android.com/studio

[38] Xcode - Apple Inc. - http://developer.apple.com/xcode/

[39] Eric Umuhoza, Hamza Ed-douibi, Marco Brambilla, Jordi Cabot, Aldo Bongio.

“Automatic code generation for cross-platform, multi-device mobile apps: some

reflections from an industrial experience”. In Proceedings of the 3rd International

Workshop on Mobile Development Lifecycle, ACM, 2015.

[40] Brambilla Marco, Andrea Mauri, and Eric Umuhoza. “Extending the Interaction

Flow Modeling Language (IFML) for Model Driven Development of Mobile Appli-

cations Front End”. In Mobile Web Information Systems, Springer International

Publishing, 2014.

[41] md2 - Model-driven Mobile Development - http://wwu-pi.github.io/md2-web/

[42] Heitkotter, Henning, Tim A. Majchrzak, and Herbert Kuchen. “Cross-platform

model-driven development of mobile applications with md2””. In Proceedings of

the 28th Annual ACM Symposium on Applied Computing, ACM, 2013.

[43] Neonto Studio - Neonto Ltd. - http://www.neonto.com/

118

http://www.xamarin.com

http://developers.google.com/v8/



http://facebook.github.io/react/

http://www.nativescript.org/

http://ionicframework.com

http://developer.android.com/studio

http://developer.apple.com/xcode/

http://wwu-pi.github.io/md2-web/

http://www.neonto.com/

BIBLIOGRAFIA

[44] Protocode - Mattia Natali

http://www.github.com/deib-polimi/protocode

[45] Ember.js - Ember Core Team - http://www.emberjs.com/

[46] Ember Data - Ember Core Team - http://www.emberjs.com/

[47] Yeoman.io - Google Chrome Developer Relations team -

http://www.yeoman.io/

[48] Yo - Google Chrome Developer Relations Team - http://www.yeoman.io/

[49] Compass - CSS Authoring Framework - http://www.compass-style.org/

[50] Grunt - Grunt Development Team - http://www.gruntjs.com/

[51] Bower - Twitter - http://www.bower.io/

[52] Bootstrap - Twitter - http://www.getbootstrap.com/

[53] Ember Data Local Storage Adapter - Ricardo Mendes -

https://www.github.com/locks/ember-localstorage-adapter

[54] JQuery - JQuery Team - http://www.jquery.com/

[55] Font Awesome - Dave Gandy - http://www.fontawesome.io/

[56] Ember.js - Eli Grey - http://www.github.com/eligrey/Blob.js/

[57] FileSaver - Eli Grey - http://www.github.com/eligrey/FileSaver.js/

[58] vkBeautify - Vadim Kiryukhin -

http://www.github.com/vkiryukhin/vkBeautify

[59] Node.js - Node.js Developers - http://www.nodejs.org

[60] MobileCodeGenerator - Gregorio Perego, Stefania Pezzetti

http://www.github.com/deib-polimi/mobilecodegenerator

[61] Greekbench 3 - Primate Labs, 03 Dicembre 2014

http://www.primatelabs.com/blog/2014/12/swift-performance/

119

http://www.github.com/deib-polimi/protocode

http://www.emberjs.com/

http://www.emberjs.com/



http://www.compass-style.org/

http://www.gruntjs.com/

http://www.bower.io/

http://www.getbootstrap.com/

https://www.github.com/locks/ember-localstorage-adapter

http://www.jquery.com/

http://www.fontawesome.io/

http://www.github.com/eligrey/Blob.js/

http://www.github.com/eligrey/FileSaver.js/

http://www.github.com/vkiryukhin/vkBeautify

http://www.nodejs.org

http://www.github.com/deib-polimi/mobilecodegenerator

http://www.primatelabs.com/blog/2014/12/swift-performance/

BIBLIOGRAFIA

[62] An analysis of sorts between Objective-C and Swift

Jesse Squires, 06 Agosto 2014

http://www.jessesquires.com/apples-to-apples-part-two/

[63] Friday Q&A 2014-07-04: Secrets of Swift’s Speed - Mike Ash

http://mikeash.com/pyblog/

friday-qa-2014-07-04-secrets-of-swifts-speed.html

[64] Mjolnic Bootstrap Colorpicker - Javier Aguilar

http://www.github.com/mjolnic/bootstrap-colorpicker

[65] Prototipizzazione Rapida per Applicazioni Mobili Multipiattaforma -

Mattia Natali, 2013

[66] Un Approccio Model-Driven per lo sviluppo di Applicazioni Mobili

Native - Gregorio Perego, Stefania Pezzetti, 2012

[67] Eclipse - Eclipse Foundation - http://www.eclipse.org

[68] Eclipse Modeling Framework - Eclipse Foundation -

http://www.eclipse.org/modeling/emf/

[69] openArchitectureWare - openArchitectureWare -

http://oawbranch.pluginbuilder.org/releases/

[70] Xpand - oAW - https://wiki.eclipse.org/Xpand

[71] Xtend - oAW - http://www.eclipse.org/xtend/

[72] Check - oAW - https://wiki.eclipse.org/Xpand

[73] Modeling Workflow Engine - oAW -

https://wiki.eclipse.org/Modeling Workflow Engine (MWE)

[74] Gradle - http://www.gradle.org/

[75] WhatsApp - WhatsApp Inc.

http://www.whatsapp.com/

120

http://www.jessesquires.com/apples-to-apples-part-two/

http://mikeash.com/pyblog/friday-qa-2014-07-04-secrets-of-swifts-speed.html

http://mikeash.com/pyblog/friday-qa-2014-07-04-secrets-of-swifts-speed.html

http://www.github.com/mjolnic/bootstrap-colorpicker

http://www.eclipse.org

http://www.eclipse.org/modeling/emf/

http://oawbranch.pluginbuilder.org/releases/

https://wiki.eclipse.org/Xpand

http://www.eclipse.org/xtend/

https://wiki.eclipse.org/Xpand

https://wiki.eclipse.org/Modeling_Workflow_Engine_(MWE)

http://www.gradle.org/

http://www.whatsapp.com/

Appendice A

Lista degli acronimi

API Application Programming Interface

CRUD Create Read Update Delete

CSS Cascading Style Sheets

DOM Document Object Model

EMF Eclipse Modeling Framework

HTML Hyper-Text Markup Language

IDE Integrated Development Environment

MWE Modeliing Workflow Engine

oAW openArchitectureWare

SDK Software Development Kit

UML Unified Modeling Language

XML eXtensible Markup Language

121

POLITECNICO DI MILANO · 2.5 Esempio di progetto Xamarin in Visual Studio. . . . . . . . . . . . ....

Documents

Transcript of POLITECNICO DI MILANO · 2.5 Esempio di progetto Xamarin in Visual Studio. . . . . . . . . . . . ....