Mobile Computing - Teoria

STRUMENTI E TECNICHE DI SVILUPPO PER DISPOSITIVI MOBILI

Android e iOS hanno molti aspetti concettuali in comune, tuttavia le applicazioni sono scritte in

linguaggi differenti:

 Android – Java

 iOS – Objective C, SWIFT

Per fare un’applicazione commerciale, devo scriverla due volte? Scrivo per una sola piattaforma?

La scelta della piattaforma deve seguire l’analisi di mercato, che non interessa in questo contesto.

Si possono considerare alcuni fattori per ciascuna tipologia di device (smartphone, tablet, ecc):

 Quanti dispositivi sono venduti;

 Quanti dispositivi sono attivi;

 Quante app sono disponibili sullo store;

 Quante app sono scaricate dallo store;

 Revenue (reddito) derivanti da app scaricate dallo store.

Bisogna tener conto anche la fascia dei device, ovvero molti dispositivi Android sono di fascia bassa,

e ciò è causa di minore attitudine degli utenti all’acquisto di app. Nel caso iOS sebbene la media di

dispositivi venduti e attivi sia minore, il reddito è nettamente più alto.

In conclusione, qualunque sia il nostro interesse, vendere le applicazioni e/o distribuirne un alto

numero sviluppando su un’unica piattaforma porta a perdere come minimo 1/3 del nostro target.

In genere lo sviluppo su una sola piattaforma non è accettabile.

Sviluppo di due versioni dell’applicazione in codice nativo

La soluzione più ovvia è sviluppare ogni applicazione due volte, per Android e iOS, che porta a

raddoppiare i costi di implementazione, testing e manutenzione. Questi svantaggi possono però

essere risolti dallo sviluppo cross-platform.

Sviluppo cross-platform

Permette di sviluppare l’applicazione, o una parte di essa, una sola volta per entrambe le

piattaforme. Esistono diverse soluzioni per lo sviluppo cross-platform:

 Codice in comune (C/C++)

Idea: scriviamo codice C/C++ che poi viene eseguito su iOS (ObjectiveC estende C/C++) e

Android (tramite JNI, Java Native Interface, che permette l’esecuzione di codice C/C++

all’interno di codice Java).

Vantaggi: il codice è scritto una sola volta, le performance sono elevate e possono essere

usate librerie esistenti di C/C++.

Svantaggi: non è possibile interagire direttamente con il SO, necessito di un bridge in

linguaggio nativo, incluso per le funzioni di interfaccia grafica.

In alcuni casi più essere una buona idea scrivere una libreria comune per iOS e Android

usando C/C++, ma non è il metodo adatto per creare applicazioni complete.

 Sviluppo di una web app

Idea: invece che creare un’app, creiamo un sito o una web app con HTML 5, CSS 3 e

Javascript, facendo accedere l’utente tramite browser.

Per creare una web app è indispensabile: single page app (AJAX), responsive design.

Vantaggi:

- La stessa app può funzionare anche sui dispositivi tradizionali;

- Le tecnologie sono ampiamente diffuse, note e ben documentate.

Svantaggi:

- User Experience non sempre paragonabile a quella delle app native;

- Accesso ad alcuni sensori del dispositivo non disponibile;

- Performance limitate;

- Accesso al SO limitato;

- L’app realizzata non è disponibile sullo store (importanza commerciale).

 Hybrid app

Idea: viene scritta una web app (HTML, CSS, JS), che viene eseguita all’interno di un’app

nativa che contiene una web view (componente grafico nativo in grado di mostrare

contenuto web). L’app nativa può essere generata in automatico.

ESEMPIO: Apache Cordova

È il framework opensource più diffuso per realizzare hybrid app. Il programmatore scrive in

HTML+CSS+JS e le applicazioni sono impacchettate per l’uso come le app native (pubblicabili

sugli store).

È possibile accedere ad alcune API del device (batteria, connessione, accelerometri) e si

possono scrivere parti di codice in linguaggio nativo (funzioni native JS).

ESEMPIO: PhoneGap

Framework commerciale di Adobe in aggiunta ad Apache Cordova, fornisce l’interfaccia

grafica per la gestione di Apache Cordova e strumenti avanzati di sviluppo e testing.

Precedentemente PhoneGap era il nome di Apache Cordova, ora i framework sono

differenti.

Vantaggi: è possibile adottare tecniche che permettono l’accesso ad alcune funzionalità del

sistema operativo oltre a quanto consentito da HTML. Inoltre l’app realizzata è disponibile

sullo store.

Svantaggi: l’user experience delle app ibride non è sempre soddisfacente. Vedi statistica

Facebook:

 Conversione del codice

Idea: scrivo il codice una volta sola in un qualunque linguaggio e tramite uno strumento

automatico lo converto in codice nativo per varie piattaforme.

ESEMPIO: React Native

Molto simile allo scrivere applicazioni ibride: vengono utilizzati HTML, CSS, JS. Al posto che

essere eseguito in una web view, il codice viene convertito in codice nativo.

L’obiettivo è risolvere i problemi di user experience (utilizzo di oggetti grafici nativi) e

prestazioni (codice nativo più performante).

Due soluzioni analoghe sono Titanium e Electron.

ESEMPIO: Xamarin

Società nata nel 2011 e ora di proprietà Microsoft: il programmatore scrive codice in C#, può

usare strumenti specifici delle piattaforme (Xcode per iOS), ha accesso a tutte le API dei vari

SO (tramite la libreria C#). Il framework genera automaticamente il codice nativo per varie

piattaforme (iOS, Android, Windows).

ESEMPIO: Unity

Motore grafico multipiattaforma (PC, console, mobile) usato principalmente per realizzare

giochi. Si sviluppa in C# o Javascript: il codice viene convertito per essere usato nativamente

sulle varie piattaforme. Piattaforma più usata per lo sviluppo di giochi.

I SO dei dispositivi mobili hanno alcune funzionalità in comune (non tutte, ad es: background)

e le espongono in modo diverso. Come si possono comportare i framework per la

conversione del codice?

ESEMPIO: acquisizione della posizione

iOS e Android rendono disponibili delle API che permettono di far richiamare un metodo

quando l’utente si sposta più di una certa soglia (es: 100m). Il nome delle chiamate, la sintassi

e i parametri sono diversi. Tuttavia è concettualmente semplice scrivere una libreria che

astragga il comportamento e che fornisca un’unica interfaccia per le due API.

ESEMPIO: il funzionamento in background

Per iOS e Android il comportamento del background è diverso: anche se posso scrivere

un’app in un unico linguaggio (es: C# perche uso Xamarin) devo scrivere il codice per gestire

il background due volte, una per Android e una per iOS.

Vantaggi: il programmatore può conoscere un solo linguaggio di programmazione, e molte

parti del codice possono essere scritte una sola volta. Ottime performance quando viene

eseguita l’applicazione, garantendo una user experience analoga a quella nativa (non per

Unity che solitamente presenta un’interfaccia diversa da quella nativa).

Svantaggi: alcune parti del codice devono essere comunque riscritte per ogni piattaforma

target, per esempio in tutte le parti in cui l’interazione con il SO è diversa tra iOS e Android.

Viene aggiunto un ulteriore livello di astrazione e di tecnologia su uno stack già complesso

ed in rapida evoluzione.

Considerazioni generali sullo sviluppo cross-platform

Queste tecniche, in linea di principio, permettono di dimezzare i costi di sviluppo, testing e

manutenzione del codice. Nella pratica viene introdotto un livello di astrazione in un ambiente

tecnologico in rapida evoluzione e non ancora del tutto consolidato. La scelta di utilizzare una

soluzione cross-platform deve essere preceduta da un’accurata valutazione di costi/benefici.

ANALISI E PROGETTAZIONE

L’analisi delle applicazioni per dispositivi mobili

Le app per i dispositivi mobili presentano delle differenze di contesto d’uso rispetto ai dispositivi

tradizionali: l’interazione può avvenire mentre l’utente è concentrato in altre attività (in mobilità,

tramite assistente vocale, ecc).

L’utente spesso utilizza le app per risolvere un problema contingente della vita quotidiana (es:

chiamare un amico, non scuocere la pasta, trovare la farmacia aperta, guardare il meteo), sfruttando

la caratteristica dei dispositivi mobili di essere sempre pronti all’uso (sempre accesi).

Un’altra importante differenza è la durata delle sessioni d’uso, mediamente molto più brevi: gli

utenti infatti vogliono risolvere il loro problema il più velocemente possibile. È necessario

minimizzare:

 Tempi di apprendimento – ESEMPIO quando Whatsapp ha iniziato a diffondersi c’erano

molte altre app alternative. I fattori principali che hanno reso Whatsapp l’app di riferimento

sono 1) l’assenza di registrazione e 2) l’aggiunta automatica dei contatti tra quelli presenti in

rubrica;

 Tempi di setup o registrazione al servizio;

 Tempi di utilizzo – ESEMPIO uno dei primi giochi che ha basato il suo successo su sessioni di

gioco molto brevi è Angry Birds. Una partita può durare anche solo pochi secondi e le

istruzioni fornite al primo livello sono presentate in un video di meno di 3 secondi.

Analizzando le funzionalità di un’app mobile, è tollerabile avere meno funzionalità rispetto a quelle

disponibili per dispositivi tradizionali, a patto che siano immediate da usare e semplici da imparare.

Nel caso dei tablet, essi sono visti come sostituti dei laptop, svolgendo quindi un ruolo ibrido. In

questo caso è ragionevole valutare di inserire più funzionalità e aumentare la complessità di quelle

presenti. Principi di progettazione delle interfacce

L’interazione con il dispositivo da parte dell’utente avviene tramite touch-screen e pochi pulsanti

fisici. Il touch screen permette un’interazione molto più sofisticata del mouse:

 È possibile definire azioni associate a gesti complessi;

 È possibile realizzare gesti con più dita;

 Negli ultimi dispositivi dotati di iOS è possibile considerare la forza della pressione sul touch

(force-touch o anche 3D touch).

Riguardo alle dimensioni dello schermo, nei dispositivi mobili si progettano GUI differenti in base

alle dimensioni degli schermi: gli ambienti di sviluppo supportano l’adattamento della GUI alla

dimensione dello schermo del dispositivo. Non vengono adattate solo le singole schermate, ma

viene a modificarsi il flusso di navigazione nell’app (es: menu a scomparsa/menu sempre visibile).

La GUI deve adattarsi anche all’orientamento dello schermo.

Integrità estetica

L’aspetto estetico dell’applicazione deve rifletterne la natura stessa, ad esempio per applicazioni

per la produttività è necessario un aspetto serio, semplice e lineare, al