Nei giorni scorsi ho avuto l'onore di fare un intervento all'evento Ge.Mobi, dedicato al mondo dello sviluppo mobile.

Nel corso di questo ho esposto l'interazione possibile di una app scritta in Xamarin Forms con i servizi Azure Mobile App Service (spesso abbreviato ZUMO cioè aZUre MObile), al fine di ottenere offline-sync dei dati nonchè l'autenticazione tramite un provider esterno (Facebbok).

Da questo intervento è nata la serie che state leggendo: spero Vi interessi e Vi piaccia.

Introduzione

Lo scopo di questa serie di post è di esporre la progettazione di una app che interagisce con una base dati remota, in questo caso un’istanza di Sql Server.

Sia l’istanza del database che i servizi backend che la app utilizzerà sono ospitati presso Azure, utilizzando l’infrastruttura Saas Mobile App.

Per dare un senso al mio scritto e proporre una traccia molto pratica ho deciso di esporre passo-passo la creazione la creazione di una app, scritta in Xamarin Forms, che permetterà condividere in modo social i posti migliore dove si mangia la famosa focaccia genovese, assegnando ad essi anche un voto: chiameremo questa app Focac-Book.

Oss.: In tutti i video sull’argomento viene mostrata la famosa app che serve per condividere quanti caffè al giorno vengono consumati, e pertanto ho deciso di "genovesizzare" questo famoso esempio. Inoltre il sottoscritto pur vivendo a Genova, è originario di un’altra città, e sin dai primi mesi di convivenza con i "locali" ho imparato quanto poco sono disposti a condividere con lo "straniero" (foresto, in dialletto) informazioni, tra le quali i posti dove si mangia la migliore focaccia. Ho quindi pensato a Focac-Book come uno strumento che potrebbe aiutare in tal senso.

Il punto critico a cui occorre porre attenzione per una app di questo genere è l’interazione con il database: nei moderni applicativi questo dovrebbe implementarsi consumando servizi via protocollo HTTPS, e tramite l'ausilio di chiamate Odata/REST e scambio dati via Json.

Implementare tutto questo non è in generale un’attività molto complessa: grazie ai moderni strumenti messi a disposizione da M$ con il framework .Net lato server è possibile scrivere con poco sforzo una Web Api, magari con l’ausilio di entity framework o anche usando core .Net per essere cross-platform (...e anche molto fighi, poichè oggi si parla solo di questo...).

Lato client invece è possibile utilizzare con poco sforzo una delle tante realizzazioni della classe HTTPClient

Le cose iniziano a farsi un poco più complicate quando si vuole introdurre uno strato di sicurezza alla nostra applicazione: nello specifico gestire l’autenticazione in modo moderno ed efficace, magari utilizzando un provider esterno, per esempio, come nel caso in analisi, Facebook, ma anche altri social.

Se, infine, si vuole anche introdurre la possibilità di lavorare con i dati in offline, le cose si complicano in modo un po' più serio.

Con il termine offline si intende la possibilità che la app sincronizzi un database locale (generalmente SQLite) con i dati (o una porzione di essi) ospitato su Sql Server: eventuali operazioni CRUD che avvengono sul database locale non avranno la necessità di alcun connettività e quindi interazione diretta con i servizi che permettono l’accesso a Sql Server.

Le modifiche rimarranno quindi solo sul database locale, senza alcun necessità di alcuna connettività nel momento in cui si esegue l’operazione di modifica dei dati.

Solo successivamente una procedura di sincronizzazione riporterà tutte le modifiche avvenute sul database locale nel database remoto: contestualmente anche le modifiche avvenute sul database remoto saranno riportate sul database locale.

Una gestione seria dell’offline introduce tutta una serie di ausili per gestire la concorrenza, cioè le modifiche concorrenti che possono avvenire sulle medesime righe.

Questa necessità è indotta dal fatto che lavorare con dati offline introduce delle latenze nella sincronizzazione dei dati posti nel backend, e quindi è più probabile dover gestire l’eventualità di modifiche concorrenti.

Questo rappresenta un’ulteriore aspetto che complica ulteriormente la realizzazione del progetto: infatti occorre introdurre un meccanismo che permetta di identificare e gestire modifiche concorrenti.

Se poi si vuole portare parte della logica che gestisce le modifiche concorrenti lato client, allora le cose iniziano a farsi ancora più complicate.

E’ per risolvere i punti sopra che è nato ed è possibile utilizzare in modo efficace l’SDK Microsoft Azure Mobile, che usa come backend i servizi Mobile App Service.

Questo SDK è presente in due forme: quello da utilizzarsi lato server backend, e quello lato client.

Nella pratica la backend l'SDK + relativi servizi si configurano come un wrapper delle straconosciute Web App proposte da Azure, però focalizzate e ottimizzate per il mondo mobile.

Lato client invece permette di esemplificare al massimo l'interazione con questo backend.

Prima di preseguire occorre dire che l’SDK per il client è disponibile per diverse piattaforme, tra cui Xamarin, Android, Ios e Cordova.

Qui si discuterà per la parte client della versione per Xamarin Forms, ma tutto quanto detto è assolutamente analogo per le altre piattaforme.

Il backend ospitato in Azure può essere scritto sia con NodeJS (Javascript) che con Asp.net (C#): qui ho preferito la seconda soluzione.

Perchè offline.-sync ??

Se una app enterprise-grade ha la necessità continua di interagire con un set di dati conservati remotamente (es.: Sql Server) è impensabile lavorare esclusivamente in modalità connessa.

L'ostacolo principale è ovviamente la non perfetta copertura 4G del territorio (nella figura la mappa della copertura 4G per l'operatore Vodafone nella mia zona, preso da opensignal.com): come si può vedere non è completa ! Inoltre possono esserci problrma relativi a situazioni geografiche sfavorevoli (palazzi, muri, etc) nelle quali ci si trovi ad oeprarre.

Ultimo ma non ultimo occorre valutare il contratto SIM, che può limitare il traffico una volta superate determinate soglie e quindi occorre gestire non solo i casi in cui la connettività viene a mancare o viene "strozzata", ma occorre anche ottimizzare lo scambio dati con la rete.

Per tutti i motivi citati sopra fare una app, per esempio, di raccolta ordini che lavora esclusivamente in modalità on-line, cioè sempre con l'ausilio della connettività, non è mai e poi mai una buona idea.

E perchè l'autenticazione tramite un provider esterno ??

E perchè occorre scomodare un provider esterno per autenticare l'accesso alla nostra app ??

Le risposte sono molteplici.

Per iniziare operando in questo modo si evita che l’utilizzatore debba inventarsi e gestire ulteriori account (userid e password).

Questo solleva anche il servizio di assistenza della nostra app dai problemi inerenti l'autenticazione (es: password persa).

Non posso fare a meno di osservare che molti miei clienti hanno serie difficoltà quando iniziano a usare qualche nuovo software che richiede loro una semplice userid e password per entrare: manca sempre qualcosa e qualche password misteriosamente non funziona o è andata persa e occorre resettarla.

La stessa difficoltà non la percepisco quando devono accedere, per esempio, alla loro pagina del loro social preferito: perchè allora non sfruttare questa possibilità per levarci qualche grattacapo ??

Ultimo ma non ultimo l'autenticazione con provider esterno è oggigiorno molto "cool": avete notato che i programmi che non la propongono sono oramai guardati con sufficienza ??

Dopo questo "pippotto" sugli scopi della serie Vi saluti e Vi rimando alle prossime puntate. Grazie della lettura.