sabato 30 maggio 2015

Xamarin, perché e cos'è

(Articolo modificato dopo pubblicazione iniziale)


Leggendo il mio profilo si può leggere che programmo in C#, ma che sono un programmatore mobile per Android e iOS.

Come è possibile, si domanderanno alcuni, considerando che il linguaggio di programmazione per Android è Java (anche C++ e C) e per iOS obj-c (e swift)?

La risposta è: Xamarin.

Xamarin è un framework, il quale permette di scrivere app in ambiente nativo, quindi con la creazione di apk e ipa e pubblicazione sui rispettivi store e possibilità di usare le risorse del sistema, usando (quasi) esclusivamente il linguaggio C#. Questo è possibile utilizzando l'ambiente Mono, personalizzato per Android e iOS (Xamarin.Android e Xamarin.iOS).


Il solo fatto di poter scrivere app in C# è già una gran cosa, soprattutto in ambiente iOS, e ad oggi è possibile scrivere lo strato Model di una generica app per entrambe le versioni in un colpo solo e condividerlo tra le due piattaforme. Addirittura tre, se si considera Windows Phone. Il risparmio di tempo è notevole, soprattutto se la app gestisce una certa mole di dati (se interagisce con un gestionale, questa parte può essere composta tranquillamente da 3000 e più righe di codice)

La parte grafica, invece, deve essere composta singolarmente per ogni piattaforma. Se comunque si usa il linguaggio C#, ci si appoggia alle risorse dell'ambiente sottostante. In iOS si usano le storyboard e i file .nib, in Android si richiamano i file xml. Lato Android in questo settore il framework risulta una sorta di binding, infatti le sintassi tra ambiente nativo e ambiente Xamarin risultano estremamente simili, dove la differenza è più dovuta al name convention che al linguaggio di programmazione.

Es. recupero di un oggetto da un xml per Android
//java, nativo
Button bottone = (Button) findViewById(R.id.my_button);

//C#, Xamarin
var bottone = FindViewById<Button>(Resource.Id.my_button);

In ambiente iOS le cose sono un po' diverse. Nel caso di un file .nib La piattaforma crea una sorta di clone del file .h (header), comunque da popolare tramite drag 'n' drop. Il "clone" viene generato in automatico e vi sono i riferimenti ai singoli componenti grafici. In questo modo, come nell'ambiente nativo, un oggetto grafico è una proprietà (privata) della classe che gestisce il file stesso.

Oltre a permettere la condivisione del codice e di non dover imparare altri linguaggi di programmazione, il framework Xamarin permette di usare nelle app quasi tutte le funzionalità del framework .NET (v 4.5). Dico quasi, perché alcune componenti non sono disponibili, in quanto in Mono non tutte le librerie dell'ambiente .NET sono fruibili e nell'ambiente mobile vi sono ulteriori restrizioni, anche se al momento non ne ho trovate di seccanti. Non scriverò qui un elenco di ottime cose che sono disponibili in ambiente C# e librerie collegate. Mi limito a segnalare che poter usare Visual Studio (per la parte Android) è una gran cosa.

Altra cosa da segnalare, la possibilità di creare binding con l'ausilio di tool automatici, ma qui bisogna conoscere le piattaforme native per ovviare a vari problemi (es. le classi interne di java possono essere di istanza o no, in C#sono solo slegate dall'istanza della classe contenitore. In Java c'è la covarianza per il tipo di ritorno, in C# no, ecc ecc.)

Naturalmente vi sono degli svantaggi con questo genere di approccio:
  • La piattaforma non è completamente trasparente. Il programmatore deve comunque conoscere un minimo ciò che vi è sotto. Ad esempio deve sapere che in una app iOS se una UIView contiene un riferimento alla UIView padre c'è il rischio di un memory leak. In Android, certi oggetti hanno un riferimento sia nella macchina virtuale nativa (Dalvik o ART) sia in quella di Mono, con rischi di memory leak e un aumento della memoria usata
  • Le app create con Xamarin sono più grosse, soprattutto in Android
  • Può capitare che alcune funzionalità disponibili in ambiente nativo non lo siano in Xamarin. Personalmente non ho riscontrato tale limitazione, ma potenzialmente può capitare
  • Si possono sommare i bug già presenti in Android e iOS con quelli del framework. Questo è un problema di tutti i framework, d'altro canto.
  • Le performance sono più basse. Essendoci un'interazione tra due macchine virtuali (Android) e una generazione automatica del codice (iOS) le prestazioni dell'app sviluppata possono essere sensibilmente peggiori
Xamarin, quindi, conviene se si ha familiarità con l'ambiente C# e si progetta di sviluppare app grosse con un Model molto sviluppato. In tempi recenti hanno raggiunto un milione di sviluppatori univoci e ciò fa ben sperare che possa diventare una realtà diffusa e non limitata a pochi, ma al momento in cui scrivo (30/05/2015) i prezzi per uno sviluppatore indipendente sono ancora troppo alti (300 dollari all'anno per una versione Indie, a cui va aggiunto il costo di una licenza Apple, altri 99 dollari, e l'acquisto di un Mac per poter sviluppare in ambiente iOS). Inoltre alcune funzionalità del framework sono disponibili in base alla licenza (la compilazione LLVM è disponibile nelle licenze Business ed Enterprise, ma anche la Business ha dei limiti).

Personalmente ritengo grandioso che si possa sviluppare app per più piattaforme senza dover conoscere tutti i segreti delle piattaforme stesse e mi auguro che in futuro si arrivi a questo approccio, ma questo prodotto è una scelta interessante solo per aziende medio-grandi, ma in futuro potrebbe non essere così.

Nessun commento :

Posta un commento