Ultimamente si fa davvero un gran parlare di framework che consentono di sviluppare sulle varie piattaforme mobile, senza dover necessariamente scrivere codice nativo. Tra queste, probabilmente la più famosa è PhoneGap, ultimamente davvero non passa giorno senza che venga nominata da qualche parte, ma anche Appcelerator Titanium, seppur meno menzionato, recita in un ruolo di protagonista nell'ambito di questo genere di prodotti. Alcune settimane fa, con 5DLabs abbiamo fatto una serie di studi di fattibilità in merito per conto di un cliente, e ho pensato di riportarvi un po' l'esperienza maturata.

Ma andiamo con ordine e spendiamo qualche parola su PhoneGap e Titanium per capire un po' meglio di cosa stiamo parlando. Iniziamo col dire che ambedue questi servono per sviluppare applicazioni native, pronte cioè a essere distribuite tramite AppStore, Android Market, Marketplace di Window Phone, ecc.ecc.. Entrambi utilizzano Javascript come linguaggio di sviluppo, ma con due filosofie profondamente diverse. In ogni caso, non possono prescindere, ovviamente, dagli SDK nativi per queste piattaforme. Conseguenza: se dovete sviluppare per iOS vi serve comunque un Mac con OSX.

PhoneGap

PhoneGap è un framework di sviluppo ibrido, nel senso che consente di realizzare App native per un  gran numero di piattaforme (sono supportate tutte le più diffuse, come riportato qui) utilizzando HTML5 + CSS3 + Javascript. Ok, ma come funziona nella pratica? Un'applicazione PhoneGap fondamentalmente è costituita da un'insieme di pagine eseguite all'interno di un controllo browser, pagine il cui codice Javascript sostituisce in tutto e per tutto quello che scriveremmo in Objective-C, Java o C#. Dovete invocare un servizio web? Chiamata AJAX, magari con jQuery. Dovete realizzare una form di input di dati? Vai di styling CSS, o jQuery Mobile o Sencha Touch che dir si voglia.

Ok, ma allora a cosa serve il framework? Beh, PhoneGap, oltre ad una serie di template di progetto per i vari ambienti di sviluppo, fondamentalmente è costituito da una libreria javascript che fa da bridge tra il nostro codice in pagina e le funzionalità native del telefono, dandoci di fatto la possibilità di accedere a funzionalità native del sistema e del dispositivo, come i contatti, il GPS o la fotocamera.

Punti a favore

Sicuramente il fatto che non dobbiamo praticamente imparare nulla, il Javascript è quello che abbiamo sempre usato, i framework anche, stesso discorso per i tool (e scusate se è poco!). Il passo per convertire un'app web in una nativa è davvero brevissimo. Inoltre l'enorme numero di dispositivi supportati, praticamente tutti gli smartphone moderni, è sicuramente un fattore non trascurabile. In buona sostanza, ad un costo quasi zero siamo in grado di sviluppare un'app nativa, anche considerando la natura assolutamente gratuita di questo prodotto. Non male eh? Purtroppo però non finisce qui.

Svantaggi

Diversi aspetti mi hanno deluso di PhoneGap, che presenta dei limiti davvero pesanti a causa dei quali non mi sono sentito di consigliarne l'adozione. In particolare, in ordine sparso:

• Siamo fondamentalmente costretti a reinventare la ruota: possiamo in buona sostanza dimenticarci tutti i controlli nativi per la piattaforma, con il risultato che le applicazioni perdono completamente il look & feel tipico del dispositivo su cui girano. Esistono alcuni plugin che supportano il rendering di 3 o 4 controlli nativi (AFAIK, TabBar, Toolbar, ActionSheet e StatusBar, e solo su iPhone), ma in questo modo si perde la portabilità. Ne vale davvero la pena, allora?
• Conseguenza diretta del punto precedente, è che la nostra app rischia di non essere accettata. Alcuni reviewers sono molto attenti, ad esempio, al rispetto delle guidelines della UX. Fatevi un giro su google e cercate "PhoneGap app rejected" e troverete davvero tanti casi.
• Generalmente il funzionamento dell'applicazione è meno responsivo e fluido di una eventuale controparte nativa (ma questo, invero, dipende dalla bontà del browser).
• Il codice è interpretato, niente compilazione. Quindi gli unici errori sono a runtime. Già così non è il massimo, ma, more than worse, ...
• ..il debug, come modernamente lo intendiamo, è praticamente impossibile. Scordatevi di mettere un breakpoint nel codice e di procedere step by step. Molti consigliano di eseguire l'applicazione su un browser tradizionale e debuggare da lì, ma a me sembra un timido palliativo, il debug lo voglio eseguire dal telefono o dal tablet! Alla fine vi toccherà tornare all'antico, con un sacco di begli alert sparsi qua e là nel codice.
• Per alcune funzionalità (es. riproduzione video) vi toccherà comunque imparare il codice nativo .
• PhoneGap non è Write Once Run Anywhere, semplicemente perchè se volete supportare n dispositivi avrete n progetti, magari ognuno la copia dell'altro, ma sempre n progetti da manutenere.

Appcelerator Titanium

Iniziamo dicendo che Titanium è un prodotto commerciale, si paga una fee mensile per utilizzarlo e sono previsti diversi livelli di abbonamento (tra cui uno "community" gratuito) che si distinguono, oltre che per il supporto, anche in base alle funzionalità attive. Il linguaggio utilizzato è sempre Javascript, ma l'approccio rispetto a PhoneGap è sensibilmente differente: il codice che scriviamo, infatti, questa volta non ha nulla a che vedere con HTML, CSS o sviluppo Web in generale, bensì si appoggia ad un object model proprietario che wrappa gli oggetti nativi delle varie piattaforme. Il risultato è che il progetto Titanium genera codice nativo, con un layer che ne consente l'invocazione via Javascript.

Punti a favore

Titanium ha un IDE proprietario, basato su Eclipse. Supporta l'autocompletamento del codice e ha un debugger integrato, basato su Firebug. Quando creiamo un nuovo progetto ci viene chiesto quali piattaforme supportare come target, poi in fase di compilazione scegliamo su quale compilare. Corollario: il progetto resta uno solo, non dobbiamo manutenerne n copie, molto più vicino all'idea di write once run anywhere.

Anche qui, comunque, è richiesta la presenza degli SDK ufficiali, quindi se vogliamo sviliuppare su iOS non abbiamo scelta e dobbiamo lavorare su OSX. Il risultato finale, comunque, è davvero notevole, e soprattutto indistinguibile da una qualsiasi app realizzata con XCode o Android SDK + Eclipse. Ovviamente non tutti gli oggetti di Titanium hanno corrispondenti sia su iOS che su Android, e pertanto alle volte è necessario qualche "if (platform == iOS)", ma alla fine non è drammatico.

Problemi

Il limite principale di Titanium è che, al momento, supporta esclusivamente Android e iOS. Niente Windows Phone, pertanto. Però può essere comunque interessante valutarlo se il nostro team è già skillato sulla piattaforma Microsoft e vogliamo comunque produrre applicazioni per questi altri due target.

Da un punto di vista dell'utilizzo, il primo ostacolo in cui mi sono imbattuto è l'assenza di un qualsiasi editor grafico, o comunque di un ausilio visuale per lo sviluppo di interfacce. In pratica siamo costretti a fare tutto da codice, istanziando controlli, valorizzandone le proprietà, aggiungendoli ad un controllo contenitore, e così via. Sicuramente è un approccio che si adatta non proprio bene a interfacce complesse e che rende molto difficoltosa l'interazione con un grafico.

L'aspetto che però mi è piaciuto meno, è la scarsa estendibilità flessibilità del framework, sicuramente uno dei limiti più difficilmente superabili dell'architettura. Nel mio caso, ad esempio, avevo bisogno di una ScrollView (i "pallini" che rappresentano la paginazione della springboard di iOS, per capirci) in direzione verticale; Titanium ne propone solo una orizzontale e sono stato costretto a parecchi hack per ottenerla, sebbene invece sia assolutamente esistente in XCode. In generale questa mancanza di flessibilità può rappresentare un problema non da poco, e dobbiamo essere pronti a rivedere le interfacce in base alle possibilità del framework.

[EDIT]Come mi segnala Alessandro Ghizzardi, in realtà, è possibile realizzare dei wrapper di funzionalità native ed esporle tramite Javascript in Titanium. Ovviamente, però, in questo caso si ha la necessità di scrivere codice in Objective-C e/o Java (a seconda della piattaforma), quindi le skill dobbiamo averle, però sicuramente è una feature che eleva di molto il livello del prodotto.

Conclusione

Entrambi i prodotti sono ben lungi dall'essere perfetti. PhoneGap, secondo me, dà come valore aggiunto il riutilizzo delle skill, ma ad un costo non indifferente, ossia tutte le problematiche che ho citato. Pertanto lo vedo magari adatto ad un progetto estemporaneo se non vogliamo investire su una piattaforma nel lungo periodo, per il resto davvero mi lascia molto scettico.

Con Titanium la storia è differente: non nego che, sebbene sulle prime mi abbia lasciato un po' spaesato, l'impressione che ne ho tratto è quella di un buon prodotto, con alcuni limiti oggettivi che lo rendono poco "snello" in progetti di alto livello. Però davvero non è male, provate a compilare Kitchen Sink per farvi un'idea. Il framework e il modello a oggetti dobbiamo comunque impararlo, però, quindi non ci sono grandi vantaggi se poi puntiamo ad una sola piattaforma delle due disponibili.

Per quanto mi riguarda, la prima opzione resta la piattaforma nativa, per tutta una serie di ragioni: ottimizzazione e controllo del codice, debug, facilità nel reperire documentazione, informazioni e componenti di terze parti, e potrei continuare... Sono aspetti che fanno la differenza, e che secondo me già nel medio periodo ripagano l'investimento sostenuto per acquisire le skill necessarie, investimento che, da professionisti, probabilmente è uno dei più futuribili che oggi possiamo fare.