Xamarin Forms, MVVMCross e SkiaSharp: la Santissima Trinità dello sviluppo di app multipiattaforma

Parla di stabilire aspettative elevate. La santa trinità, niente di meno!

La verità è che lo sviluppo di app mobili è costoso quando si prendono di mira più piattaforme, perché non esiste un codice condiviso. Apple richiede di codificare in Objective-C o Swift, Android richiede di codificare in Java e WinPhone richiede di sviluppare in .NET, spesso C#. Aggiungi a ciò la pletora di librerie fornite da ciascuna piattaforma per gestire mappe, disegni, immagini o GPS: è necessaria un'enorme quantità di tempo e conoscenze per creare un'unica app mobile.

Inutile dire che la maggior parte delle startup non può permettersi di triplicare le proprie spese e anche le aziende affermate possono avere difficoltà a giustificare il prezzo di ingresso nello spazio mobile.

In questo articolo imparerai come Xamarin Forms, in combinazione con MVVMCross e SkiaSharp, può essere un modo praticabile per creare app mobili multipiattaforma senza compromettere familiarità, prestazioni e unicità. L'articolo esaminerà queste tre tecnologie e come possono ridurre i costi di sviluppo consentendo il massimo riutilizzo del codice su più piattaforme mobili.

Un problema importante

Il problema dello sviluppo di app mobili multipiattaforma è reale e, come tale, negli anni sono emerse molte soluzioni diverse per ridurre i costi di sviluppo condividendo il codice tra le piattaforme. Nel settore dei videogiochi, ad esempio, tutti i principali motori di gioco forniscono una soluzione multipiattaforma, con persino Unreal e Unity rivolti a telefoni cellulari e tablet.

Sul fronte delle app, nel corso degli anni sono stati numerosi i tentativi di guidare questo mercato multipiattaforma. Molti non sono stati all'altezza e si sono persi nell'abisso, ma un paio di loro sopravvivono ancora dopo diversi anni. Tra questi c'è Xamarin, l'unica soluzione .NET che offre supporto per tutte e tre le piattaforme mobili.

Nativo o no, eccomi

Quindi c'è una guerra tra diverse soluzioni e chi dice che guerra significa propaganda!

La guerra si combatte principalmente sul fronte della grande N : essere nativi! Devi stare attento alla parola perché non ha un significato chiaro. È la parola più usata nel mondo dello sviluppo mobile al giorno d'oggi ed è molto trendy. La verità è che nessuno è d'accordo su cosa significhi effettivamente.

Quando selezioni un framework multipiattaforma, tutte le opzioni "native" non sono uguali, quindi fai attenzione, potresti confrontare le mele con le arance. Per alcuni si tratta del linguaggio di programmazione, per altri si tratta di essere in grado di utilizzare le funzionalità hardware, altri pensano che riguardi l'uso di API/UI della piattaforma e spesso si tratta solo di non essere un'app Web.

Ci sono argomenti su ogni lato del dibattito e non ho intenzione di scavare più a fondo perché è inutile. Perché è inutile? Bene, lascia che ti dica un fatto difficile da digerire: ai tuoi utenti finali non importa!

Sì, hai letto bene, interessa solo ai tuoi programmatori. Il tuo utente finale non sceglierà mai la tua app a causa della tecnologia sottostante: sceglierà la tua app perché risponde al suo problema e offre una buona esperienza.

Quindi, invece di litigare sul significato di una parola, diamo un'occhiata a come Xamarin offre un modo efficiente per offrire agli utenti ciò che interessa loro.

Il Padre, il Figlio e lo Spirito Santo

Prima di andare avanti, chiariamo solo i tre elementi che compongono la nostra soluzione al problema dello sviluppo multipiattaforma.

Il padre: Xamarin

Come accennato in precedenza, Xamarin è una soluzione .NET per lo sviluppo di app per dispositivi mobili e desktop. È stato acquistato da Microsoft nel 2016 ma risale a circa quattro anni fa con il progetto Mono. Al giorno d'oggi, offre tre soluzioni: Xamarin.iOS, Xamarin.Android e Xamarin.Mac. Le altre piattaforme gestiscono già app .NET per impostazione predefinita, essendo soluzioni Microsoft. In breve, Xamarin offre un collegamento diretto alle API della piattaforma in .NET. È quindi possibile utilizzare le funzionalità native di un'app .NET. C'è anche un modulo di estensione per Xamarin chiamato Forms che fornisce un livello di astrazione per l'interfaccia utente.

Il figlio: SkiaSharp

SkiaSharp è un wrapper .NET sulla libreria di grafica vettoriale Skia di Google. Skia è il motore di rendering nativo di Android, Chrome, ChromeOS e Firefox. Con SkiaSharp, puoi utilizzare la libreria nella tua app .NET per renderla multipiattaforma. Ciò significa che l'ombra ordinata che il tuo designer dice "renderà la tua app molto migliore" può essere codificata solo una volta invece di essere ripetuta per ciascuna piattaforma di destinazione. Personalmente, penso che la sua caratteristica migliore sia la capacità di eseguire il rendering della grafica SVG in un modo che consente di prevenire la duplicazione dei vari fattori di forma mantenendo un rendering nitido e perfetto per i pixel.

Lo Spirito Santo: MVVMCross

Per mantenere tutto ben separato e liberamente accoppiato, la nostra soluzione santificata si baserà su MVVMCross. Questo framework implementa un'infrastruttura MVVM (Model-View-ViewModel) in modo che tutto possa essere mantenuto indipendente. Senza diventare troppo tecniche, le app sono generalmente suddivise in tre parti:

1. Il modello: una rappresentazione in memoria dei nostri dati
2. La vista: la nostra interfaccia utente, che presenta i dati e le azioni agli utenti
3. Il ViewModel: il livello che lega il nostro modello alla nostra vista e viceversa

Nell'ingegneria del software, ci sforziamo sempre di mantenere la vista separata dal ViewModel in modo che la logica dell'applicazione (nel ViewModel) possa essere riutilizzata anche se cambiamo la rappresentazione visiva. MVVMCross ci aiuta a raggiungere questo obiettivo gestendo i data binding e fornendo modelli e strumenti per l'astrazione della piattaforma.

A cosa interessano gli utenti finali

Solo per ricapitolare, ci sono cose diverse che differenziano le app di successo da quelle cattive. Un'app di successo:

1. Risolve un problema di vita reale
2. Offre un'esperienza piacevole

Il punto numero 1 ovviamente non ha nulla a che fare con il framework che scegli. Concentriamoci quindi sul punto numero 2. Ci sono tre aspetti principali che contribuiscono alla fruibilità della tua app:

1. Familiarità
2. Prestazione
3. Unicità

Familiarità

La familiarità si riferisce alla facilità d'uso e al trovare rapidamente la strada attraverso l'app.

In altre parole, si tratta di utilizzare i diversi paradigmi dell'interfaccia utente della piattaforma in modo coerente a livello di sistema. Ad esempio, cose semplici come la posizione dei pulsanti, l'elenco delle azioni contestuali o la navigazione contribuiscono tutti alla familiarità della tua app.

La familiarità è il principale punto debole delle app Web o dei framework basati su un'interfaccia Web. Xamarin Forms, d'altra parte, fornisce mapping multipiattaforma agli elementi dell'interfaccia utente forniti dal fornitore.

I tuoi utenti ottengono quindi un'esperienza conforme all'aspetto generale della piattaforma in modo che si sentano intuitivamente a proprio agio nella tua app.

Prestazione

Francamente, menzionare "nativo" nella tua propaganda di marketing non significa nulla. Prendi Jasonette come esempio che è "nativo su HTTP". L'interfaccia utente è archiviata su un server Web... ciao round trip e rallentamenti, quindi vediamo che non si può necessariamente presumere che il nativo implichi prestazioni migliori!

Quindi, con quel mito fuori mano, quando si esaminano i benchmark della vita reale, Xamarin risulta essere la soluzione più completa per quanto riguarda le prestazioni. Xamarin Forms, che non richiede molto più cambi di contesto, offre prestazioni paragonabili alle app in lingua madre.

La mia conclusione è che le tue scelte di implementazione sono ciò che può rallentare la tua app piuttosto che Xamarin rispetto alla lingua nativa. Altre opzioni là fuori sono in chiaro svantaggio per quanto riguarda le prestazioni.

Unicità

Anche la possibilità per i tuoi designer di creare un'app dall'aspetto unico è molto importante da considerare se vuoi fornire la migliore esperienza utente possibile e differenziare la tua app.

Molte volte, l'unicità implica la creazione di controlli, animazioni o gesti dall'aspetto personalizzato. Quando non è prontamente disponibile in Xamarin, puoi utilizzare SkiaSharp (un wrapper attorno alla libreria di rendering di grafica vettoriale Skia di Google) e sfruttare il concetto di renderer personalizzato di Xamarin Forms per avvicinarti il ​​più possibile all'hardware, codificando sempre in un unico linguaggio, qualcosa che le altre soluzioni non sono in grado di offrire.

A cosa ti occupi come azienda

A questo punto, molto probabilmente stai pensando che la scelta del framework sia anche una decisione aziendale. A parte i fattori che esulano dall'ambito di questo articolo, come la disponibilità delle risorse umane, Xamarin ha molto da offrire, soprattutto se associato a MVVMCross. Elaborerò quattro aspetti che vorrai considerare nella tua decisione:

1. Prezzo e costi di sviluppo
2. Riutilizzo del codice
3. Disponibilità dei componenti
4. Supporto e comunità

Prezzo e costi di sviluppo

Togliamo questo di mezzo. Dall'inizio di quest'anno, Xamarin è gratuito per i liberi professionisti e le piccole imprese come le startup (con Visual Studio Community Edition). Per le organizzazioni più grandi, viene fornito "gratuitamente" con una licenza di Visual Studio che potresti già avere. Xamarin Forms, MVVMCross e SkiaSharp sono anche tutti gratuiti e open source per finire!

Come ho già accennato, seguire il percorso .Net con Xamarin ti consente di sviluppare le tue app in un'unica lingua dall'inizio alla fine. La maggior parte delle altre soluzioni disponibili richiede che i tuoi programmatori conoscano lingue diverse. Nel caso di Cordova, ad esempio, devi essere fluente non solo in HTML, Javascript, CSS, ma eventualmente anche in Objective-C, Java e/o C# se devi accedere alle API del fornitore che non hanno un plug-in disponibile .

La varietà di linguaggi utilizzati consente più cambi di contesto e più strumenti da padroneggiare con conseguente riduzione dell'efficienza. Xamarin, d'altra parte, è una soluzione all-in-one: da Visual Studio crei, distribuisci ed esegui il debug su tutte le piattaforme.

Sebbene non sia direttamente correlato a Xamarin, in C# sono disponibili anche molte funzionalità che accelerano lo sviluppo scegliendo la soluzione .Net. Vale a dire, trai vantaggio dalle straordinarie funzionalità di C# 4.5+ come il facile multi-threading con async/await, chiusure e riflessione, che hanno tutti dimostrato di migliorare l'efficienza.

Riutilizzo del codice

Probabilmente hai pensato al riutilizzo del codice e molto probabilmente consideri tutte le soluzioni in qualche modo equivalenti a questo proposito. Mi dispiace dirlo amico, ma ti sbagli!

I programmatori tra di voi potrebbero essersi chiesti perché mai avrei proposto l'uso di MVVMCross sul livello MVVM integrato in Forms? Bene, ecco qualcosa da considerare: stai davvero creando solo app mobili?

Isolando la logica dell'app con MVVMCross e usando l'inversione del controllo che fornisce, puoi riutilizzare una quantità massima di codice su dispositivi mobili, ma anche su Windows e Mac (perché Xamarin.Mac è tuo amico).

Non solo ti farà risparmiare denaro, ma propone anche buone pratiche ingegneristiche che ridurranno i costi di manutenzione del codice.

Disponibilità dei componenti

Forse non sei come me, ma odio reinventare la ruota. Pertanto, avere accesso a componenti esistenti che puoi facilmente integrare nella tua app è fondamentale per accelerare il tuo time to market e spesso abbasserà i tuoi costi allo stesso tempo.

La scelta di Xamarin e MVVMCross offre due opzioni tra cui scegliere i componenti esistenti. Innanzitutto, sono disponibili sempre più componenti per Xamarin con o senza moduli. Xamarin ha un Component Store integrato all'interno di Visual Studio in cui puoi trovare varie soluzioni ai problemi comuni delle app e altre aziende vendono direttamente, quindi assicurati di cercare prima di iniziare a scrivere i tuoi componenti (o considera di venderli una volta creati).

In secondo luogo, vorrai cercare i pacchetti Nuget perché è probabile che qualcuno abbia già scritto il codice per fare ciò di cui hai bisogno. Tra questi pacchetti, troverai un elenco decente di plug-in MVVMCross multipiattaforma che risolveranno problemi comuni come e-mail, GPS o localizzazione.

Se hai già esperienza con C#, probabilmente hai i tuoi componenti preferiti. Certo, non vuoi lasciarli andare, si sentono così a loro agio. Stai tranquillo, puoi creare associazioni C# per i componenti esistenti e quindi usarli come se fossero in bundle con Xamarin, anche in Forms con un po' di aiuto dai renderer personalizzati.

A proposito, potresti voler dare un'occhiata al repository Github delle associazioni Xamarin prima di crearne uno tuo.

Supporto e Comunità

Infine, l'accesso al supporto e agli esempi è un fattore molto importante nella scelta di un framework. Xamarin è in circolazione da un po' di tempo, quindi la community è di dimensioni abbastanza buone oggi.

La ricerca di informazioni su Google di solito mostra un discreto numero di risposte (suggerimento: prova anche le tue ricerche per monotouch e monodroid, gli antenati di Xamarin) e Xamarin offre molti esempi e un'ottima documentazione sul loro sito Web.

Inoltre, poiché Xamarin è davvero solo un vincolo sulle API del fornitore, la documentazione di Apple e Google è sempre pertinente e risponderà a molte delle tue domande. È quindi possibile creare il proprio servizio MVVMCross per astrarre le API del fornitore all'interno del codice condiviso.

Per quanto riguarda il futuro di Xamarin, con la sua acquisizione lo scorso marzo da parte di Microsoft, scommetto che non andrà da nessuna parte se non in avanti. Da quella vendita e dal passaggio a un modello free-ish, la community è cresciuta, il supporto è migliorato e il prodotto ha continuato a migliorare forse anche a un ritmo più veloce!

Il futuro sembra luminoso per Xamarin.

Prepariamoci a rimbombare!

Sono consapevole del fatto che potrei aprire una lattina di vermi con questo articolo. Ora non fraintendermi, ci sono altre opzioni là fuori che vale la pena considerare e ti invito a farlo, perché le mie preoccupazioni potrebbero non essere le tue.

Tieni presente che se hai una sequenza temporale di sei settimane e quattro mesi dopo non hai ancora un'app pronta, non stai vincendo. Rimarrebbero due mesi e mezzo e un sacco di soldi per formare qualcuno internamente o per assumere qualcuno esperto. Insistere sulla creazione di un'app "nativa" a quel punto può essere piuttosto dannoso per il destino del tuo progetto.

Xamarin e queste tecnologie complementari forniscono esattamente ciò che interessa ai tuoi utenti e ciò di cui hai bisogno. Spero che questo articolo ti aiuti a prendere una decisione ben informata sul framework che potresti scegliere per la tua prossima app mobile.