1 Commento

La soluzione venti percento

Quel difficile anywhere

di

thumbnail

20

nov

2015

Write once, una sola base di codice per qualsiasi piattaforma, è facile. Il problema è farlo funzionare realmente ovunque.

Per chi bazzica da tanto tempo il mondo Linux, il nome Miguel de Icaza non è una novità. Il quarantatreenne programmatore messicano è stato autore e fondatore di progetti del calibro di Gnome – uno dei desktop manager di riferimento per Linux – di Mono e perfino di Midnight Commander ed è considerato una figura di spicco nel mondo del software open source.

Miguel però è anche il fondatore di Xamarin, l’azienda – da tempo nell’orbita Microsoft – che con la sua piattaforma di sviluppo mobile in C# permette di usare una unica codebase per generare applicazioni native su tutte le piattaforme mobili di mercato: iOS, Android e Windows e con performance eccellenti.

Prestazioni di Xamarin

Le prestazioni di Xamarin con il variare di hardware e software.

Xamarin, come anche Rubymotion, RoboVM o J2ObjC, risponde ad una esigenza sostanziale: scrivere software di qualità. Mi spiego meglio: è difficile essere fluente nei tre (e più) linguaggi di programmazione di riferimento nel mobile. Spostarsi su quello che si conosce meglio – magari uno di quelli che usate per lo sviluppo web – può essere un vantaggio per produrre una applicazione bene scritta e quindi di potenziale successo.

Ma come funziona Xamarin? Lo spiega bene Edward Wilde sul suo blog parlando delle build iOS:

Xamarin.iOS compila codice sorgente C# a fronte di un sottoinsieme speciale del framework mono. Questa versione di mono comprende librerie addizionali che offrono accesso a funzioni specifiche di iOS. Il compilatore Xamarin.iOS, smsc, prende il sorgente e lo compila in un linguaggio intermedio, ECMA CIL (Common Intermediate Language). Quando una applicazione Xamarin.iOS è stata compilata in CIL, deve essere compilata ancora in codice macchina nativo che possa essere eseguito su apparecchi iOS. Questo viene effettuato dallo strumento mtouch dell’SDK, che come risultato crea un bundle applicativo compatibile con il simulatore di iOS o con un apparecchio reale, per esempio un iPhone o un iPad.

Quindi niente codice interpretato, WebView e applicazioni con una esperienza d’uso subottimale.

Il problema di Xamarin è però che Android e iOS non hanno usano soltanto linguaggi di riferimento differenti (ObjC/Swift e Java) ma sono proprio mondi diversi. Racconta in un bel post Lee Whitney:

Chi cerca di sviluppare una app di qualità per iOS e Android con una user experience (UX) nativa e amichevole trova che il problema più grosso consiste nella vasta differenza tra le architetture UX delle piattaforme. Su questo, Xamarin non aiuta molto. Siccome queste differenze costituiscono oltre l’80 percento della difficoltà, il massimo che Xamarin può offrire è di fatto la soluzione al 20 percento del problema. È difficile minimizzare le problematiche che Xamarin non risolve. La differenza in codifica della UX, animazioni, risorse, sincronizzazione, viste, flusso di lavoro e così via tra iOS e Android è come quella tra notte e giorno e non parliamo di .NET. Xamarin permette di usare ovunque C#, tuttavia si tratta spesso di C# che usa due framework differenti con differenti classi e semantiche.

Con la sua ultima creatura open source, React Native, Facebook propone l’approccio learn once, write anywhere provando ad enfatizzare che nessuna ricetta semplifica in assoluto lo sviluppo mobile ed è inevitabile dover mettere mano al proprio codice per garantire ai propri utenti una esperienza d’uso in linea con le aspettative.

Metabolizzato però questo concetto e abbondata la chimera di avere una applicazione perfetta per tutte le piattaforme con lo stesso codice, rimane il fatto che se non siete una azienda enterprise o se avete in mente di realizzare delle applicazioni di non elevata complessità, le soluzioni come Xamarin (Rubymotion, RoboVM e perché no anche React Native) meritano sicuramente di essere prese in considerazione.

In questi articoli i nostri autori esaminano da ogni punto di vista la creazione di una app, dal design alla programmazione al marketing alle questioni legali, sotto lo hashtag #mifacciolappTutti i post della serie sono consultabili a partire dalla pagina Come fare una app.




Andrea C. Granata (@andreacgranata) ha pigiato i primi tasti su un bianco VIC20 quando ancora Internet era in fasce. Un po’ sistemista un po’ sviluppatore, ha una passione per FreeBSD, programmazione in Ruby, metodologie Agile e infrastrutture cloud. Si occupa di Enterprise Architecture e di DevOps per una delle più importanti banche italiane. Nel tempo libero si divide tra la passione per la cucina, il pattinaggio di figura e i viaggi in Oriente.

Letto 2.932 volte | Tag: , , , , , , , , , , , , , , , , , , , , ,

Un commento

  1. Alberto

    Possiamo a mio parere aggiungere anche B4AA, un IDE completo di librerie che in linguaggio BASIC consente di scrivere app Androind/Ios e Windows.
    Ma anche con Kivy-Python anche se in modo meno immediato consente di fare questo.
    Ciao
    Alberto

Lascia il tuo commento