Home > Mobile > Sviluppo di applicazioni su piattaforma mobile: quali soluzioni?

Sviluppo di applicazioni su piattaforma mobile: quali soluzioni?


La sempre più ampia diffusione di dispositivi mobili, siano essi smartphone o tablet (vedi i dati riportati del numero di possessori di smartphone nel mercato USA nel mio recente post), apre grandi opportunità a tutti coloro che hanno come business quello di creare applicazioni con cui offrire servizi da “consumare” attraverso questi dispositivi.

Si stima, infatti, che il mercato del mobile entro pochi anni supererà (sostituirà?), quello dell’attuale personal computer, ampliandone e diffondendone l’uso e quindi la potenzialità di usare, fruire e consumare servizi siano essi gratuiti e/o a pagamento.

Le applicazioni e servizi offerti per il mobile devono affrontare una sfida molto difficile: fornire informazioni / tools tenendo in considerazione gli aspetti legati a chi, dove, quando e cosa un utente sta facendo, operare nelle condizioni più “ostili”, distribuirle il più rapidamente possibile, a costi sempre più bassi e competitivi ad una comunità di utenti con aspettative sempre più ampie.

Chi debba realizzare le applicazioni / servizi di riferimento deve al tempo stesso tenere in forte considerazione e dimostrare di saper governare al meglio, l’eterogeneità del mondo mobile che è amplissima: dispositivi, sistemi operativi, linguaggi di sviluppo, diverse UI, tipologia di applicazioni (web app? app native?), ecc …

Più quanto realizzato è in grado di operare in modo indistinto sui diversi dispositivi e piattaforme (trasversalità), sfruttandone al tempo stesso le peculiarità (versatilità), maggiore e il potenziale di diffusione di quell’applicazione.

Non esiste al momento “la” soluzione e questo post cerca di analizzare quello che è lo stato dell’arte cercando di dare spiegazioni e motivazioni, evidenziando punti di forza e limiti delle possibilità attuali. Resta il mito del “write once, run everywhere” vedremo nel seguito se raggiungibile o meno.

Occorre poi considerare che questo mondo è in vertiginosa evoluzione e quindi potrei essere rapidamente smentito nelle mie affermazioni quindi, al netto delle cose qui affermate e dei riferimenti che riporterò, …. stay tuned!!

Applicazioni per mobile: si ma di che tipo?
Prima di addentrarci nelle diverse alternative occorre necessariamente fare un po’ di premesse e chiarezza sin dall’inizio.

Ho parlato di “applicazioni” ma sin da questo punto occorre distinguere: le applicazioni per mobile possono essere di due categorie, le “web app” e le “app” spesso denominate anche “app native“.

La distinzione tra le due è legata al fatto che le web app “girano” sostanzialmente dentro un browser presente sul dispositivo, mentre le app native “girano” direttamente sul dispositivo. La distinzione è un po’ a grana grossa (non me ne vogliano i puristi ……), ma rende l’idea e permette di capire.

Con quale codice realizzo l’applicazione: codice nativo (quale?), Javascript / HTML 5, Flex, Adobe Air? Altro?
Per sviluppare un’applicazione mobile è necessario individuare il linguaggio di sviluppo da cui partire e qui ci si scontra sin da subito con l’eterogeneità di questo mondo: per ogni tipo di sistema operativo abbiamo praticamente un linguaggio tra cui spiccano Java (nelle sue diverse accezioni), C (nelle sue varie accezioni), .NET, HTML, Javascript, CSS, ecc ….

Il quadro sintetico è il seguente:

Un azienda che quindi, sulla carta, volesse garantire la propria app per mobile supportata sui vari dispositivi dovrebbe avere nelle proprie direzioni di produzione tutti gli skill di cui sopra.

Praticamente impossibile!

Vic Gundotra, VP of engineering a Google, ha dichiarato che “…… even Google was not rich enough to support all of the different mobile platforms from Apple’s App Store to those of the BlackBerry, Windows Mobile, Android, and the many variations of the Nokia platform,…….“.

In realtà un elemento in comune è possibile individuarlo: tutti questi sistemi operativi supportano il browser mobile accessibile da codice nativo.

Ogni piattaforma quindi permette di istanziare un browser ed interagire con la sua interfaccia Javascript via codice nativo.

Questa possibilità, nota come tecnica PhoneGap, è stata presentata da Eric Oesterle, Rob Ellis, and Brock Whitten per il primo iPhone OS SDK allo iPhoneDevCamp nel 2008, e poi adottata anche da altri produttori quali Android e Blackberry e via via a tutte le piattaforme supportate da PhoneGap. PhoneGap è un framework open source che fornisce un ambiente agli sviluppatori in cui possono creare apps in HTML, CSS e Javascript e richiamare caratteristiche del device attraverso uno strato API Javascript comune.

La scelta Javascript / HTML 5 al momento sembra quindi essere “la” scelta di sviluppo per le web app.

Due news recenti a supporto:

  • nel recente FOSS4G 2011, piuttosto ovvio in un contesto di una conferenza legata al Open Source, per quanto si possa considerare di “nicchia”, le soluzioni per mobile erano basate su Javascript / HTML 5 e nessuna faceva riferimento a Flex o Silverlight, viste quasi come applicazioni legacy, riuscendo ad offrire analoghe funzionalità
  • una news ha annunciato il passaggio di Slideshare (questa volta un qualcosa molto meno di nicchia), da Flash ad HTML 5

L’evoluzione di Javascript e HTML 5 è anche determinata dalla spinta che stanno ponendo i principali attori nel mondo dei browser mobile, Microsoft, Google, Apple, Opera, e Mozilla per cercare di migliorare la loro offerta in particolare sul fronte delle prestazioni.

Dagli ultimi benchmarks Mozzilla SpiderMonkey si sta avvicinando a Google V8, mentre JavaScriptCore di Apple che si trova in molti WebKit browser presenti su diversi dispostivi mobili, sta nel mezzo.

Ecco una figura che riporta un po’ di dati

Questo non vuol affermare che altre soluzioni quali Flex / Flash siano morte, ma certo la rapida crescita di HTML 5 e il suo supporto sulle versioni più recenti di browser in parallelo con il fatto che, ad oggi, sia Apple sia Microsoft sulle loro soluzioni mobile non permettano l’installazione di plug-in Flash (Flex necessità dell’installazione del plug-in per poter funzionare ……), costituiscono due fattori di impatto sulla diffusione di Flex come soluzioni web app per mobile di cui va tenuto conto.

Discorso leggermente diverso per le soluzioni app native: qui Adobe ha una freccia in più sul proprio arco sfruttando la disponibilità di una piattaforma come Abobe Air che è un’applicazione che va installato sul dispositivo ma che non sfrutta alcun browser plug-in,

Mobile Air si presenta quindi come una piattaforma (installata) cross-mobile che permette di raggiungere l’obiettivo “write once, run everywhere” vale a dire scrivere un solo codice che venga eseguito su dispositivi diversi Apple iOS, Android, Blackberry, ecc .. senza necessità di codice di terze parti per la conversione come PhoneGap.

Adobe Air e Flex sono molto simili quindi se da un lato Flex può diventare meno popolare per le soluzioni web app per motivi legati a decisioni di business prese da Apple e Microsoft, Adobe Air sembra avere grosse potenzialità sul fronte apps che “girino” direttamente sul dispositivo..

Write once, run everywhere?
Come detto in precedenza questo è un mito che ha caratterizzato da sempre il mondo informatico, attento alla portabilità e ai costi di manutenzione del software.

Periodicamente si ripropone ad ogni cambio significativo di paradigma e il mobile non fa eccezione.

Negli anni infatti ci sono stati diversi tentativi di creare ambienti cross-platform già sul mondo desktop, Java è l’esempio più significativo ed eclatante, ma non l’unico.

Tutti questi tentativi non hanno mai avuto un vero e proprio successo su tutta la linea anche se, casi come Java, rappresentano quelli di maggior lustro. Sarà diverso con il mondo mobile? E se sì perché? Si saprà fare tesoro delle esperienze passate? Si riadotteranno gli stessi modelli di soluzione?

Uno degli aspetti su cui spesso questi tentativi sono caduti è quello legato alla variabilità dei controlli di user interface (UI) sulle diverse piattaforme, aspetto che si ripropone, enfatizzato, anche nel caso del mobile.

Si possono adottare due strategie: usare le componenti “native” di ogni piattaforma oppure emulare i componenti usando le primitive grafiche, alias creare nel modo più efficace possibile il proprio sistema di UI.

Continuando il parallelo con il mondo Java questa e la differenza tra Swing (emulazione) e SWT (controlli nativi).

Entrambi gli approcci hanno pro e contro ovviamente.

Se si usano i controlli nativi si deve tenere conto che controlli simili su piattaforme diverse hanno più o meno lievi differenze nel come lavorano, il che rende difficile fare una buona astrazione comune (trasversalità).

Al tempo stesso occorre decidere come ci si comporta rispetto a caratteristiche che sono disponibili solo su determinate piattaforme: si “abbassa” il livello sino allo strato comunemente condiviso tra tutte le piattaforme? Scelta non felice.

L’emulazione diventa di interesse o come approccio complessivo o per realizzare quei controlli che non sono disponibili su determinate piattaforme.

L’emulazione ha però un paio di punti critici: è difficile ottenere un UI emulato che risponda in modo sufficientemente accettabile e, secondo, è molto difficile far si che i controlli eseguano “esattamente” come  i controlli nativi.

Il rischio e di finire in un canale senza uscita in cui le cose funzionano in modo “simile” ai controlli nativi ma restano sempre delle differenze (più o meno lievi), che non rendono le cose “uguali” e questo, in un mondo come quello mobile in cui anche la parte estetica e di user esperienze (maggiore rispetto ai paradigmi precedenti, sia del mondo web sia del mondo desktop), hanno il loro peso, rischia di allontanare gli utenti di queste soluzioni.

Diverse piattaforme hanno infatti diverse modalità con cui i loro utenti, inconsciamente, si aspettano di interagire. “Portare” un’applicazione pensata per una piattaforma (es. Android), su un’altra piattaforma (es. iOS), può portare anche alla completa revisione delle modalità di interazione tra le due piattaforme, un costo che, se non pensato inizialmente, può essere insostenibile anche per una buona app, e al tempo stesso, se pensata inizialmente ne può aumentare di costi di prima realizzazione.

Queste motivazioni sono quelle che portano a considerare che, per quanto tecnicamente fattibili, le soluzioni cross-platform nel mondo mobile continueranno, e forse con maggior enfasi, ad essere un mito, in modo del tutto analogo a come è avvenuto in passato, o che comunque, le parti di sviluppo custom saranno ancora considerevoli per produrre applicazioni che siano fruibili “in modo nativo” sulle diverse piattaforme mobili disponibili.

Discorso leggermente diverso è per le web app in cui abbiamo già un elemento accomunante e di disaccoppiamento che è il browser stesso. In questo contesto è quindi più facile realizzare un’applicazione in grado di essere fruita, in modo analogo, da dispositivi diversi eterogenei tra loro e non ci si deve curare degli aspetti del look and feel in quanto l’approccio è del tutto analogo a quando si realizza una web application tradizionale.

In questo caso il limite dell’approccio web app è l’uso offline in caso di mancanza di rete che non po’ non essere considerato. Esistono soluzioni che permettono lo storage di informazioni in locale ma è ovvio che non potrà mai essere come un’app nativa.

Non esiste quindi “la” soluzione occorre mediare rispetto al contesto applicativo e alle esigenze di progetto. In linea di massima:

  • usare una soluzione basata su web app ove possibile, considerando che il limite maggiore, da non sottovalutare, è che questa non è in grado di operare in mancanza di rete
  • nel caso in cui si debba optare per la realizzazione di un’app, nell’ambito del possibile, cercare di fare riferimento, in modo chiaro e concordato con il committente, ad una piattaforma, Valutare nell’ambito dei costi di progetto se la soluzione debba essere portabile o meno su altre piattaforme
  • valutare attentamente eventuali toolkit cross-platform che possono si semplificare lo sviluppo e garantire una qualche portabilità, spesso però a scapito di una non piena aderenza allo “stile” delle applicazioni native preseti sugli stessi dispositivi

User Experience: un fattore da non sottovalutare
Chiudo questo post con alcuni approfondimenti sulla user experience.

In ambito mobile, più ancora che in ambito desktop o web, la user experience (termine che intende racchiudere l’esperienza totale che l’utente ha nell’utilizzo di un’applicazione), ha un peso da non sottovalutare.

Una buona web app in termini funzionali che però risulti essere non in linea con il pattern di utilizzo tipico per quel determinato tipo di smartphone, porta rapidamente all’abbandono dell’applicazione stessa.

Possiamo considerare la user experience composta da due elementi:

  • il contesto: elementi che devono essere compresi e noti ma sui quali non si ha il controllo e che non possono essere modificati. Ad esempio possibilità della piattaforma, convenzioni di UI, ecc ….
  • l’implementazione: elementi che possono (e devono), essere controllati in una applicazione. Ad esempio performance, design, interazione con features delle piattaforme, ecc …

Contesto
Fanno parte del contesto le diverse caratteristiche fisiche dei dispositivi quali dimensione fisica, colore, risoluzione dello schermo, trackball, touchscreen, microfoni, camera, ecc ..  la combinazione di tutti questo fattori influenza come l’applicazione apparirà e funzionerà.

Ogni piattaforma ha una propria convenzione a livello di user-interface ad esempio la modalità di avere un go-back nel browser aspetto che viene gestito diversamente su iOS, Android e Blackberry.

Anche l’ambiente può influenzare la percezione della nostra applicazione. E’ giorno o è notte? L’utente è seduto o in piedi? E’ in movimento? Ha una o due mani libere? Le combinazioni sono infinite!

Implementazione
Un aspetto importante di cui tenere conto sicuramente sono le performance. Ad esempio usare JSON (JavaScript Object Notation), nello scambio dei dati permette di occupare meno “banda” che non usando XML, ma d’altro canto l’uso dell’XML può facilitare la parificazione nel momento in cui si debba produrre un HTML perché nel caso di JSON questo andrà parificato, quindi dipende se quello che arriva dal servizio e passa sulla banda è un “oggetto” o una “rappresentazione di informazione” e quindi scegliere poi caso per caso.

Fonti:

GeoSpatial Mobile Development: Flash or HTML5? – Web Map Solutions

Cross-platform mobile development: worth pursuing, or a mirage? – ITJOBLOG

CrossPlatformMobile – Javalobby

Mobile Application Development: Web vs. Native – acmqueue

  1. 21 marzo 2013 alle 9:21 am

    Mi sembra di qualche interesse anche la prospettiva offerta da http://www.gruppozenit.com/ita/portable_apps.html non fosse altro che per l’italianità della cosa…

  1. No trackbacks yet.

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: