Mobile Apps

II parte: Trend e tecnologie. Pro e contro delle app native e ibridedi

Continuiamo la serie sulle applicazioni per dispositivi mobile affrontando la oramai proverbiale diatriba: app native o app ibride. Come vedremo, ci sono svariati aspetti, e non solo tecnologici, da tenere in considerazione prima di pronunciare troppo semplicisticamente il verdetto.

Panoramica dei sistemi operativi mobile

Il mondo dei sistemi operativi mobile (MOS, "mobile OS") è in rapida evoluzione. I guadagni generati dalle app sono in competizione con quelli generati delle "classiche" applicazioni desktop. Basti pensare che negli ultimi sistemi operativi desktop di Apple e Microsoft sono nati gli App Store. Gli utenti possono comprare le applicazioni desktop in maniera analoga a come comprano le app sullo smartphone. Questo ha lo scopo di uniformare l'esperienza di acquisto degli utenti.

Uniformare

Questa è la parola chiave per chi opera nel settore e cerca di ridurre i costi di produzione di un software. Se negli anni Novanta e agli inizi del Duemila la maggior parte delle applicazioni era desktop e la scelta più semplice ed economicamente vantaggiosa era quella di farle per sistemi Windows, ora non è più cosi.

Ora ci si confronta con un mondo vasto ed eterogeneo dove le persone vivono le applicazioni su dispositivi e sistemi operativi diversi. Gli attori principali del mondo desktop sono Microsoft, Apple e Linux. Quelli del mondo mobile sono Google, Apple, Backberry e Microsoft.

Non dobbiamo poi dimenticare HTML5. Negli ultimi anni, grazie al consolidamento dello standard HTML5 [1], in stato di Candidate Recommendation da questo febbraio, stanno emergendo altre piattaforme che possiamo quasi assimilare a nuovi sistemi operativi: i moderni web browser Chrome, Safari, Firefox e Internet Explorer (solo in versione IE 11, l'ultima, poiche' le altre non le considererei moderne).

Se ora ritorniamo nei panni di chi deve sviluppare un nuovo applicativo o servizio software una domanda ci viene spontanea: come orientarsi in questo mondo cercando di ridurre i costi e i tempi e soddisfare le esigenze del maggior numero di utenti possibile?

Nel prossimo paragrafo vedremo quali sono le possibili alternative per lo sviluppo di un'app, tenendo anche conto che ormai il concetto di app sta entrando anche nel mondo desktop.

Il bytecode del futuro

Il sogno di molti sviluppatori è: "scrivo una volta il codice, carico i contenuti, verifico che tutto funzioni e lo rilascio per tutti i device senza problemi di performance e necessità di personalizzazioni". Non è un discorso nuovo ("write once, run everywhere" esiste da una ventina d'anni come concetto…) e ci stiamo pian piano avvicinando a questa realtà; ma spesso con dei compromessi che la storia di Java ci insegna: il cross-platform ha un prezzo. Infatti, quando un codice "gira" su più piattaforme è meno efficiente perchè non gira direttamente a livello di sistema operativo ma dentro una virtual machine che astrae il sistema operativo sottostante aggiungendo overhead e limiti alla esecuzione dell'applicazione.

Efficienza della virtualizzazione

Queste virtualizzazioni stanno diventando sempre più efficienti e snelle. Forse un giorno arriveremo all'astrazione totale senza compromessi. Potrebbe essere grazie a JavaScript?

Se ci pensate, gli engine JavaScript sono diventati delle vere e proprie macchine virtuali che girano sia all'interno dei web browser sia sui server grazie a Node.js. Che sia davvero JavaScript il bytecode del futuro? Sulla base di questa ipotesi andiamo ad analizzare alcune opzioni per sviluppare le app.

Alternative per lo sviluppo di un'app

Possiamo identificare 5 strategie per sviluppare un'app:

  1. Native: sviluppare in codice nativo legato al sistema operativo del dispositivo. Esempi: Objective-C per iOS e Java per Android.
  2. Ibrido HTML5: sviluppare web app HTML5 e "impacchettarle" in una web view custom. Esempio: Apache Cordova.
  3. Compilatori da altri linguaggi: tradurre in automatico un linguaggio conosciuto nei linguaggi nativi dei diversi dispositivi mobile. Esempio: Xamarin.
  4. Runtime custom: usare dei runtime custom che fanno girare l'app. Esempio: Appcelerator Titanium.
  5. Web app: costruire un sito web visibile e fruibile dal web browser dello smartphone come se fosse una app. Esempio: Sencha Touch.

Vediamo di seguito gli aspetti salienti di ciascuna delle 5 soluzioni presentate

App native

Scrivere un'app in codice nativo permette di accedere in modo semplice e veloce a tutti i dispositivi del device e di sfruttare al meglio l'hardware ottimizzando le performance.

Inoltre le app si basano su SDK mantenuti dai produttori dei diversi sistemi mobile e quindi hanno una vita più lunga, anche se comunque molto dinamica.

Lo svantaggio più grande è quello di dover realizzare più volte la stessa app usando linguaggi e SDK differenti, con una diversa implementazione per per ciascun sistema operativo mobile, quando non addirittura per specifici device.

App ibride HTML5

L'approccio HTML5 risolve il problema di dover scrivere più volte la stessa app in linguaggi differenti. Infatti l'app gira all'interno di un runtime custom che contiene una web view. Il runtime estende questa web view con API che "wrappano" quelle del dispositivo mobile ed espongono le API in JavaScript. È quindi sufficiente chiamare dalla web view queste API per poter accedere all'hardware del dispositivo come, ad esempio l'accelerometro, i contatti o la fotocamera del telefono, cosa che invece è proibita da un web browser normale.

Inoltre questa strada non vi lega a nessun vendor (se non per l'SDK) perche' di fatto sviluppate secondo lo standard HTML5 che è una piattaforma open.

Di contro le app HTML5 ibride soffrono di prestazioni peggiori di quelle native perche' il rendering UI simula con CSS e JavaScript il look & feel di una app nativa, e non è gestito nativamente dal sistema operativo, ma dalla web view. Questo passaggio fa sì che le app ibride siano più lente quando il livello di interazione e grafica è alto.

Se vi avvicinate a questo mondo, vi consiglio di partire con Apache Cordova [2] e Sencha Touch [3].

Compilatori da altri linguaggi

Come idea, non è male poter scrivere codice nel nostro linguaggio preferito e poter raggiungere tutti i mobile OS con la semplice pressione di un tasto: Xamarin [4] è un esempio molto ben riuscito di questo approccio. In questo caso le performance non ne soffrono.

Sembra la soluzione ottimale, ma anche questo approccio presenta degli svantaggi: il problema più rilevante è quello di riuscire a star dietro ai sistemi mobile che evolvono nel tempo e continuare ad aggiornare di conseguenza i compilatori. Scegliere questa strada vi semplifica molto la vita, ma vi lega fortemente al compilatore che avete deciso di usare.

Runtime custom

Appcelerator Titanium [5] è un esempio di engine che gira sul dispositivo e interpreta a runtime il JavaScript richiamando i metodi native del sistema operativo. L'approccio coniuga la bellezza della standardizzazione HTML5 con una performace più vicina a quella delle app native. La soluzione sembra perfetta… però anche qui c'è un "ma".

Anche in questo caso il runtime deve evolvere con l'evoluzione del sistema operativo e questo fa sì che si sia, ancora una volta, fortemente legati al vendor del runtime.

Web apps

Questo approccio è molto simile alle app ibride HTML5 e infatti si usano spesso le stesse librerie. La diversità è che, al posto di impacchettare l'app in una custom web view come Cordova, la app viene fruita direttamente dal web browser del dispositivo.

Il livello di performace è praticamente lo stesso di quello delle app ibride. Il principale vantaggio di una web app è quello di poterla rilasciare come un sito web senza passare dallo store. Quindi, oltre ad essere fruibile dai device mobili, è fruibile anche da tutti i web browser desktop.

Come aspetto negativo, abbiamo che la web app non ha accesso a molti dei dispositivi hardware del device perche' proibito dalla sandbox del web browser. Oltre a questo limite, non dimentichiamoci che il suo comportamento può variare a seconda del web browser che andiamo ad usare: ebbene sì, la "guerra dei web browser" non è ancora finita…

Il Device APIs Working Group [6] del W3C sta lavorando a vari standard per permettere una maggiore integrazione delle web app con i dispositivi, ma siamo ancora lontani da un'implementazione uniforme e completa.

 

 

Figura 1 - Un confronto tra web app e app ibride.

Quale strada prendere?

Ad oggi non è facile dire quale sia la strada corretta da prendere per sviluppare un'app. La scelta può dipendere da diversi fattori quali la conoscenza di un linguaggio, la complessità dell'app, le interazioni con altri sistemi esistenti e il livello grafico e d'interazione utente.

Risparmi reali di tempo

Nella mia esperienza, ho visto che, a differenza di quello che ci si potrebbe aspettare, scrivere una app ibrida HTML5 e "reimpacchettarla" poi per iOS e Android non dimezza i tempi rispetto a scrivere due app separate (una per Android e una per Apple), ma li riduce comunque del 30% circa.

Infatti, anche se il codice HTML5 è lo stesso per i due sistemi operativi, la complessità degli SDK ibridi e la loro veloce evoluzione fanno si che molto tempo sia comunque trascorso a correggere errori dovuti alla giovane età di queste soluzioni.

Un aiuto per la decisione

È comunque possibile suggerire un algoritmo decisionale a chi debba prendere delle decisioni riguardo alle varie possibilità di sviluppo delle app per dispositivi mobili. Per quanto imperfetto, il processo decisionale che propongo è il seguente:

  • se l'app ha solo controlli base quali bottoni, aree di testo, immagini, list, drop down, video, date picker e similari…
  • se l'app non prevede una UI molto ricca e piena di effetti grafici…
  • se conoscete bene JavaScript e CSS…

…allora usate Cordova, Sencha Touch 2 o Titanium Appceletator.

Invece,

  • se l'app ha grafica 2D o 3D interattiva…
  • se conoscete bene Objective-C e Java su Android…
  • se le performance sono un punto fondamentale…
  • se l'interfaccia utente è ricca di effetti e interazioni…

…allora sviluppate app native multiple, per i diversi sistemi operativi mobili, e gestite più codebase; in alternativa, è anche possibile affidarsi ai runtime custom.

Conclusioni

Abbiamo visto come la molteplicità dei sistemi operativi mobile e delle emergenti piattaforme basate su browser costituiscano un panorama di frammentazione con il quale si deve confrontare ogni sviluppatore di app.

Forse un giorno questa distinzione non ci sarà più, ma per ora dobbiamo fare i conti con la realtà. Chissà se nel prossimo futuro Apple, Google e Microsoft si metteranno d'accordo per un unico framework per lo sviluppo delle app, oppure se la strategia di chiudere gli ambienti rimarrà prevalente. Una cosa è certa: nello scenario attuale, è necessario affrontare il problema ed effettuare la scelta della soluzione migliore in maniera oculata e sulla base di una serie di considerazioni ponderate, sia di ambito tecnologico, sia di ambito "commerciale".

Riferimenti

[1] HTML5

http://www.w3.org/TR/html5/

 

[2] Apache Cordova

https://cordova.apache.org/

 

[3] Sencha Touch

http://www.sencha.com/products/touch/

 

[4] Xamarin

http://xamarin.com/how-it-works

 

[5] Appcelerator Titanium

http://www.appcelerator.com/titanium/

 

[6] Device APIs Working Group

http://www.w3.org/2009/dap/

 

 

 

 

Condividi

Pubblicato nel numero
194 aprile 2014
Giulio Roggero è consulente specializzato in formazione e coaching sui temi di Lean-Agile Project Management e tecnologie Web, Mobile e Cloud. Co-fondatore della startup www.makeitapp.eu e CTO di Intre srl, aiuta le aziende ICT a creare nuovi prodotti e semplificare i loro processi, spostando l‘attenzione verso il valore per il…
Articoli nella stessa serie
  • Mobile Apps
    I parte: Applicazioni mobili, un mercato maturo e in crescita
  • Mobile apps
    III parte: Backend as a Service (BaaS)
Ti potrebbe interessare anche