Alessandro Del Sole's Blog

{ A programming space about Microsoft® .NET® }
posts - 1883, comments - 2047, trackbacks - 352

My Links

News

Your host

This is me! Questo spazio è dedicato a Microsoft® .NET®, di cui sono molto appassionato :-)

Cookie e Privacy

Disabilita cookie ShinyStat

Microsoft MVP

My MVP Profile

Microsoft Certified Professional

Microsoft Specialist

Il mio libro su VB 2015!

Pre-ordina il mio libro su VB 2015 Pre-ordina il mio libro "Visual Basic 2015 Unleashed". Clicca sulla copertina per informazioni!

Il mio libro su WPF 4.5.1!

Clicca sulla copertina per informazioni! E' uscito il mio libro "Programmare con WPF 4.5.1". Clicca sulla copertina per informazioni!

These postings are provided 'AS IS' for entertainment purposes only with absolutely no warranty expressed or implied and confer no rights.
If you're not an Italian user, please visit my English blog

Le vostre visite

I'm a VB!

Guarda la mia intervista a Seattle

Follow me on Twitter!

Altri spazi

CodePlex download Scarica i miei progetti open-source su CodePlex!

Article Categories

Archives

Post Categories

Image Galleries

Privacy Policy

lunedì 20 febbraio 2017

Nasce una nuova community: Visual Studio Tips & Tricks

Oggi, lunedì 20 febbraio 2017, abbiamo il piacere di annunciare la nascita di una nuova community tecnica chiamata Visual Studio Tips & Tricks.



Il nome è certamente e volutamente evocativo, ma questa community non è assolutamente un’estensione di Visual Basic Tips & Tricks.

E’ una realtà totalmente nuova, autonoma e piena di freschezza, che ha lo scopo di divulgare conoscenza sulle tecnologie Microsoft per lo sviluppo di software ad ampio raggio, negli ambiti Mobile, Desktop, Cloud con l’ecosistema di Microsoft Visual Studio, inclusi Visual Studio Code e Visual Studio for Mac.

Ciò vuol dire che ci occuperemo massicciamente di cose come Xamarin, intelligenza artificiale, Visual Studio Code, Roslyn, .NET Core, Azure, di Universal Windows Platform, di DevOps e Visual Studio Team Services, dei linguaggi .NET senza distinzione e di tutto ciò che può ruotare allo sviluppo di software con gli strumenti della famiglia Visual Studio.

Siamo già abituati a trattare tutti questi argomenti ma serviva uno spazio più adeguato, per noi stessi e per gli utenti che hanno avuto “timore” ad avvicinarsi a un sito il cui nome è legato a un linguaggio storico ma il cui uso è statisticamente ben circostanziato.

Il Team di questa nuova community è composto da Alessandro Del Sole, Renato Marzaro, Laura La Manna, Antonio Catucci e Igor Damiani. Persone abbastanza note nel mondo delle community Microsoft per la loro grande passione non solo per la tecnologia ma anche per la condivisione della conoscenza e legate tra loro da amicizie durature.

Il sito Web di questa community offre, gratuitamente, un’Area Articoli che già contiene numerosi articoli tecnici pronti per voi su argomenti come Xamarin, UWP e C# 7. C’è inoltre un’area dedicata a forum tecnici organizzati per area tematica nei quali potremo porre i nostri quesiti e rispondere a domande degli altri utenti. In cantiere ci sono anche diversi eventi che erogheremo in diverse città italiane in modo da poterci incontrare di persona e di condividere più da vicino la nostra passione con tutti voi.

Abbiamo inoltre creato un canale di community su YouTube dove pubblicheremo i nostri video tecnici e dove già ne trovate alcuni dedicati a Xamrin, Roslyn e Visual Studio for Mac.

Non potevamo inoltre mancare sui più diffusi social network, pertanto abbiamo creato:

La community è appena nata, quindi sicuramente ci saranno molti aggiustamenti da fare col tempo ma saremo felici se vorrete darci i vostri feedback.

Da parte del sottoscritto, due parole su VB T&T: continuerà a vivere e sarà supportata. La velocità con cui si muove la tecnologia e la direzione presa dal mondo dello sviluppo, ad ogni modo, ci porterà ad investire la maggior parte delle risorse e del tempo sulla nuova Visual Studio Tips & Tricks. Un motivo in più per visitare il nuovo sito e seguirci.

Come sempre, qualunque comunità non ha senso se non c’è la partecipazione e l’aggregazione delle persone. Quindi, i vostri contributi come articoli, partecipazione nei forum o video formativi saranno più che benvenuti.

Vi aspettiamo!

Alessandro

posted @ lunedì 20 febbraio 2017 08:37 | Filed Under [ .NET Framework Visual Basic C# Varie Windows Presentation Foundation LINQ Community and friends Windows Azure and SQL Azure UWP e Windows Store Apps Visual Studio 2015 .NET Compiler Platform (Roslyn) Windows 10 Xamarin Visual Studio 2017 Visual Studio Code ]

martedì 14 febbraio 2017

Xamarin, Azure e il Visual Studio Mobile Center - Autenticazione

Dopo aver parlato di sincronizzazione offline nel post precedente, in quest'ultimo post della mini serie dedicata al Visual Studio Mobile Center per Xamarin parliamo di autenticazione, login e accesso autorizzato ai dati.

Come promesso, il codice completo della solution con accesso al backend, sincronizzazione offline e autenticazione è disponibile su GitHub.

Tipologie di autenticazione

Gestire l'autenticazione con gli Azure Mobile App tramite il Mobile Center è semplicissimo se utilizziamo uno dei provider previsti. Si tratta di Microsoft Account, Facebook, Twitter, Google+ oltre alla Azure Active Directory. Ovviamente è possibile implementare l'autenticazione anche nei confronti di Web API custom, ma eventualmente ne riparlermo in quanto al di fuori dei discorsi su questi servizi. Capiamo prima bene quanti e quali provider vogliamo utilizzare. L'autenticazione avviene tramite il metodo LoginAsync della classe MobileServiceClient, a cui passiamo il provider di autenticazione. Poi fa tutto lui, posto che tutto sia stato configurato lato server. Restituisce un oggetto MobileServiceUser che contiene il token e lo user id dell'utente riconosciuto.

L'autenticazione nel servizio

Il primo passaggio da fare è abilitare l'autenticazione nel Mobile Service e assegnarla alle tabelle. Nel Mobile Center entriamo nell'area della nostra app, quindi click su Identity nel menu laterale. Ci verrà proposto l'elenco di provider, scegliamo Microsoft Account perché sicuramente ce l'avete. I passaggi sono comunque simili anche per gli altri provider e possiamo selezionarne più di uno:



Come vedete vengono chieste due info: application id e client secret. Per ciascun provider ci sono luoghi e portali diversi in cui generarli, ma per ognuno il Mobile Center vi fornisce link e documentazione. Nel caso di Microsoft Account, andate nel portale di gestione delle app e fate click su Add an app. Specificate un nome, poi verrà generato l'application id e se fate click su Generate New Password otterrete anche il client secret:


Entrambi andranno copia-incollati nel Mobile Center. Nota molto bene: in questo portale, il client secret lo vedrete solo la volta in cui viene generato. Sempre in questo portale, sotto Platforms, cliccate su Add New Platform, poi selezionate Web. Bisogna infatti fornire l'URL di redirect che, nel caso del MS Account, ha la forma visibile in figura:



Dove mobile-app-id.azurewebsites.net andrà sostituito con l'URL del vostro servizio di backend. Salvate le modifiche, tornate nel Mobile Center, salvate tutto anche li.

Autorizzazione sulle tabelle

Fate click su Tables, quindi sulla tabella Book (o su altra di vostro interesse). In alto a destra, cliccate sul pulsante coi tre punti sospensivi e dal menu contestuale scegliete Change Permissions. Per ciascuna operazione, potrete definire il livello di autenticazione tra Authenticated, Anonymous, Disabled:



Accertatevi che tutte abbiano lo stesso livello e che sia selezionata l'opzione Per-user data. Se vi ricordate, all'inizio della serie vi dissi che quest'opzione aggiunge una colonna chiamata userId di tipo stringa che consentirà di filtrare i dati sulla base dell'utente autorizzato. Lo potrete facilmente verificare dopo aver fatto click su Save.

Codice - il Model

Sono necessarie varie modifiche al codice della solution su cui stavamo lavorando. La prima riguarda la classe TableBase, che ora deve includere la proprietà UserId:

E questo è il primo passo.

Codice - l'autenticazione
L'autenticazione è in realtà platform-specific. Quindi, in una cartella chiamata Authentication del progetto PCL, definiamo la seguente interfaccia:


Essa demanda a ciascun progetto l'implementazione dell'autenticazione. Creiamo le relative classi Authentication nei progetti Droid e iOS.

Android:


iOS:

Ciò che cambia è, di fatto, il contesto di UI che il metodo LoginAsync riceve. Come vedete, è sufficiente cambiare un valore dell'enumerazione MobileServiceAuthenticationProvider per autenticare l'utente con un diverso provider. In entrambi i casi viene restituito il MobileUser col suo id e il suo token.

Codice - il ViewModel

Anche il ViewModel subisce modifiche. Ha senso definire due proprietà UserId e IsUserAuthenticated per poter memorizzare l'id utente da usare nelle query e nel salvataggio dei dati e per capire se l'utente può avviare le azioni richieste. Ovviamente la logica di determinazione se l'utente è autenticato è poi custom. Eccolo modificato:

E' anche evidente come venga esposto il metodo LoginAsync che chiama il suo omonimo su ciascuna piattaforma.

Codice - l'accesso ai dati

In realtà, avendo demandato al ViewModel l'inserimento dello user id in nuovi oggetti, l'unica vera modifica nella classe DataManager riguarda il metodo LoadAsync, che esegue una query filtrando il risultato proprio per user id. Ad ogni modo, per praticità, riporto l'intero codice della classe:


Codice - la UI

L'ultima parte riguarda il code-behind della pagina MainPage.xaml.cs, dove in OnAppearing verificheremo che l'utente sia autenticato e, se non lo è, invocheremo il metodo di autenticazione:


Lo facciamo qui piuttosto che nel costruttore perché vogliamo verificare l'autenticazione ogni volta che si arriva sulla pagina, che magari è andata solo in sospensione.

Un passaggio preliminare

C'è un piccolo difetto ad oggi nel Mobile Center che impedirebbe all'autenticazione di funzionare. Ciò che dovete fare è:

  1. andare nel portale di Azure
  2. cliccare su App Services e selezionare l'id corrispondente al vostro servizio
  3. cliccare su Authentication
  4. selezionare l'Enable token store
Speriamo che questa opzione venga presto importata nel Mobile Center.

Il risultato

Ecco cosa otterremo a questo punto nell'app:



Quindi, con pochi passaggi e poche righe, abbiamo introdotto l'autenticazione nella nostra app Xamarin sfruttando i servizi di Azure e il Mobile Center.

La solution completa

Tutta la solution completa è disponibile a questo indirizzo su GitHub.

Alessandro

posted @ martedì 14 febbraio 2017 23:00 | Filed Under [ Windows Azure and SQL Azure Xamarin ]

lunedì 13 febbraio 2017

Xamarin, Azure e il Visual Studio Mobile Center - Sincronizzazione offline

Nel post precedente abbiamo visto come sfruttare i servizi di backend di Azure esposti dal Visual Studio Mobile Center per creare una tabella a cui un'app scritta con Xamarin può accedere per memorizzare e recuperare dati.

Nota: il codice sorgente completo sarà fornito nel prossimo post, in cui parlo di autenticazione.

Quell'approccio ha un limite: non memorizza i dati localmente e richiede sempre connettività per poter lavorare. Per fortuna, l'SDK Azure Mobile Client e i servizi di Azure Mobile App offrono anche l'infrastruttura per poter avere dati locali e per sincronizzarli quando online.

(Nota: quanto vedremo in questo post non è legato al Visual Studio Mobile Center, ma è un arricchimento della serie di post).

Per fare questo, l'SDK si avvale di SQLite in locale ed espone il necessario attraverso la classe MobileServiceClient. La cosa bella è che non è necessario installare le apposite librerie di SQLite, perché ci pensa l'SDK a mappare gli oggetti giusti. Quindi, alla solution lasciata in sospeso la volta scorsa aggiungiamo un pacchetto NuGet chiamato Microsoft.Azure.Mobile.Client.SQLiteStore.

Il percorso del db locale
La prima cosa da fare è stabilire il percorso del db locale. Il file system è platform-specific, quindi non sotto lo strato unificato di Xamarin.Forms. Quindi si ricorre al dependency service, dapprima definendo un'interfaccia che stabilisce il contratto (e che creo nella cartella DataAccess della solution):

Fatto questo, vado a definire una classe chiamata DataConnection, che implementa l'interfaccia, su entrambe le piattaforme di mio interesse (Android e iOS perché sono le due ad oggi supportate dal Mobile Center). Ovviamente, su Windows il discorso è analogo.

Android:


iOS:

Ottenuto il percorso del db locale, andremo poi a crearlo e gestirlo.

Utilizzo del db locale
L'accesso al db locale avviene mediante la classe MobileServiceClient, ma il db fisico è rappresentato dalla classe MobileServiceSQLiteStore che va istanziata passando il percorso del file. Una volta istanziata, si invoca il metodo DefineTable<T> tante volte quante sono le tabelle che abbiamo bisogno di generare in locale. Questo metodo crea ma non sovrascrive una tabella. Fatto questo, bisogna inizializzare il meccanismo di sincronizzazione attraverso il metodo SyncContext.InitializeAsync della classe MobileServiceClient, a cui viene passata l'istanza della MobileServiceSQLiteStore e, opzionalmente, un cosiddetto handler che influisca sulla comunicazione. Per esempio, header di autenticazione tramite Web API o informazioni aggiuntive sulla serializzazione JSON.

Altra piccola modifica richiesta è l'utilizzo del metodo GetSyncTable<T> al posto di GetTable. Con GetSyncTable, la libreria sa che deve gestire anche una tabella locale e non solo remota. Poi le operazioni vengono fatte ugualmente con InsertAsync, UpdateAsync, ecc. Solo che il risultato rimane in locale finché non viene invocato PushAsync sul contesto. Questo metodo cercherà di inviare i dati alla tabella remota.

In fase di caricamento dei dati, invece, prima di fare una query o di ottenere un insieme tramite ToListAsync/ToEnumerableAsync, si invoca PullAsync sulla table. Questo metodo effettua una reale sincronizzazione tra remoto e locale e crea una query sulla tabella specificando un nome che serve al sync incrementale. Il nome è libero, in più bisogna passare il risultato di CreateQuery come secondo parametro. Tutto il succo di questo discorso è visibile nel seguente codice e vedrete che i cambiamenti sono davvero pochi, sebbene il codice risulti più lungo per via delle eccezioni da gestire:


Eccezioni e proprietà di sync
Le operazioni di sync possono ovviamente causare eccezioni. I motivi possono essere molto vari, come mancanza di connettività non gestita, differenze tra schema locale e schema remoto (soprattutto se il db remoto è SQL Server), ecc. Le eccezioni che tipicamente andranno gestite sono MobileServicePushFailedException e MobileServiceInvalidOperationException, la prima con la sua proprietà PushResult che contiene un elenco di Errors a rappresentare i vari problemi rilevati. Può anche essere utile conoscere il valore della proprietà PendingOperations, che espone il numero di operazioni in locale che non sono state ancora sincronizzate, per esempio per invocare poi PushAsync. L'ultimissima modifica è l'inizializzazione dello storage per piattaforma. Sia in MainActivity.cs (Android) che in AppDelegate.cs (iOS), prima della chiamata a LoadApplication va aggiunta la seguente riga:

Microsoft.WindowsAzure.MobileServices.CurrentPlatform.Init(); 

Null'altro è richiesto!

L'aver progettato l'app secondo MVVM non rende necessarie modifiche né al ViewModel né alla UI.

Test da fare

Per verificare il meccanismo di sync, provate ad avviare l'app e ad usarla col device disconnesso dalla rete. Poi provate a chiuderla, riconnettere la rete, riavviarla. Ovviamente in scenari reali dovreste prevedere la possibilità di un sync automatico, ad esempio tramite la tecnica del pull-to-refresh sulla ListView.

Questo è tutto. Vi ritroverete un db locale che vi consentirà di lavorare offline e una tabella remota con cui i dati verranno sincronizzati. Nel prossimo post concluderemo parlando di autenticazione.

Alessandro

posted @ lunedì 13 febbraio 2017 23:00 | Filed Under [ Windows Azure and SQL Azure Xamarin ]

domenica 12 febbraio 2017

Xamarin, Azure e il Visual Studio Mobile Center - Table e backend

Nel post precedente ho fatto un'introduzione del Visual Studio Mobile Center con una panoramica degli strumenti che offre. Avevamo iniziato creando un'app cross-platform con Xamarin, in cui avevamo attivato gli strumenti di analytics ma non avevamo fatto altro. Riprendiamo quindi il discorso parlando dei servizi di backend offerti dalle Tables, o Easy Tables nella terminologia di Azure, grazie alle quali possiamo avere delle tabelle in cui memorizzare dati nella Cloud.

Due note: ciò che si fa nel Visual Studio Mobile Center si fa anche nel portale di Azure, con la differenza che il Mobile Center semplifica enormemente le cose da fare; il portale di Azure torna comunque comodo per due aspetti, il primo relativo al fatto che le Tables usano SQLite ma per andare in produzione conviene mapparle a un database SQL Azure, cosa fattibile solo dal portale Azure, il secondo riguarderà poi l'autenticazione di cui parlerò tra due post.

Ciò premesso, andiamo nel Visual Studio Mobile Center e clicchiamo sul nome della nostra app. Infine, nel menu laterale click su Tables.

Creazione di una tabella
Nel post precedente vi ho accennato all'obiettivo da raggiungere, un'app che, in maniera chiaramente semplificata, gestisce un elenco di libri. Si tratta quindi di creare una tabella nella Cloud che memorizzi le informazioni tipiche di un libro come titolo, autore, ISBN, quantità e data di pubblicazione. Non includo il prezzo per una ragione: come vedrete tra breve, si utilizzerà JSON e serializzare un decimal richiede passaggi che "allungano troppo" il post e che rischiano di farci perdere il vero focus. Tenete a mente questo flash se vorrete farlo poi successivamente. Nella pagina del Mobile Center dovrete cliccare su un pulsante chiamato Create Table. A questo punto vi verrà richiesto di:

  • specificare un nome per la tabella. Chiamatela Book al singolare, per semplicità e per facile associazione al concetto di entity;
  • indicare se volete il soft delete, ossia evitare che un record venga eliminato fisicamente semplicemente marcandolo come eliminato ed escludendolo automaticamente dalle query. Selezionate questa opzione;
  • indicare se volete uno schema dinamico, che consentirà al servizio di generare le colonne sulla base dei dati che riceve; per il momento potete lasciarlo selezionato, se volete, ma deselezionatelo quando andate in produzione;
  • se volete che ogni utente abbia i propri dati. Questo farà sì che venga creata automaticamente una colonna chiamata userId sulla base della quale filtrare per utente. Ha senso in contesti di autenticazione, sia custom che tramite provider. La utilizzeremo tra due post, al momento deselezionatela.
Facendo click su Create, verrà creata una tabella con alcune colonne predefinite, più in particolare:

  • id, una stringa-Guid come identificativo del record.
  • deleted, un bool che indica se il record va marcato come eliminato o meno.
  • createdAt e updatedAt, due colonne data/ora che indicano la data e l'ora di creazione e modifica del record
  • version, che indica il numero di versione del record

Nota importante: il Mobile Center conosce solo 5 tipi di dato: Boolean, String, Number, Date e Version e quest'ultimo è usato solo dal sistema. Fate click su Edit Schema e poi su Add Column ripetutamente per aggiungere le seguenti colonne:

  • title, author, ISBN tutte e tre di tipo String;
  • publicationDate, di tipo Date;
  • quantity, di tipo Number.

Fondamentale: la nomenclatura non è casuale, il nome della colonna inizia con la lettera minuscola per poter piacere al formato JSON. Rispettatela!

Dopo aver salvato le modifiche, noterete che il Mobile Center vi fornisce un suggerimento su come referenziarla da codice:



Se avete già avuto esperienza con l'SDK di Azure per app client avrete familiarità, diversamente il suggerimento è poco utile. Niente paura, tra non molto vedremo cosa fare. Si tratterà, comunque, di scaricare l'Azure Mobile Client SDK per interagire da codice con le Table. I nostri dati sono chiaramente esposti in rete tramite un endpoint; per visualizzarlo, cliccate su Tables nel menu a sinistra, quindi sul nome della tabella per poterlo vedere come in figura:


Prendete nota di questo URL perché tra poco vi servirà.

Codice, model e un po' di architettura

Abbiamo la nostra tabella lato server nella Cloud, ora dobbiamo rappresentarla in codice C# con una classe che poi utilizzeremo per memorizzare e leggere i dati. Normalmente, il mio approccio nei post è quello di semplificare i progetti di esempio per consentirne una più facile comprensione anche a chi conosce meno determinati pattern come MVVM, ma questa volta non è così. Un minimo di architettura ci vuole per ottenere un risultato efficiente e soprattutto estendibile e riutilizzabile nei prossimi post (e anche per voi). Partiamo col dire che è necessario scaricare da NuGet la libreria chiamata Microsoft.Azure.Mobile.Client, da installare su tutti i progetti della solution (PCL, Android e iOS sicuramente). Questa si porta dietro Newtonsoft.Json come dipendenza, che utilizzeremo spesso. Vi faccio scaricare anche un altro pacchetto, il plugin chiamato Xam.Plugin.Connectivity, che consentirà di verificare la disponibilità di connettività direttamente dalla PCL.

Bisogna quindi creare una classe che rappresenti la nostra tabella. Ogni istanza di questa classe verrà serializzata in formato JSON e inviata alla Table dall'SDK di Azure. Il punto è che ogni tabella ha sempre delle colonne di sistema fisse, per cui l'idea è quella di partire da una classe astratta che chiamerò TableBase e che aggiungo in una cartella chiamata Model:

Notate come Version nella table sia mappato da un array byte[]. La classe implementa INotifyPropertyChanged affinché chiamanti come la UI possano aggiornarsi al variare dei dati. Notate come l'attributo JsonProperty consenta di mappare le proprietà .NET, con la relativa nomenclatura, alle colonne che hanno il nome aderente alla nomenclatura JSON. Altra nota importante: per i valori data/ora utilizzo DateTimeOffset invece che DateTime, perché i dati andranno a finire in SQLite (ora in Cloud ma la prossima volta anche in locale). SQLite ha un modo tutto suo di rappresentare le date e DateTimeOffset ci permette di rappresentare una data in formato UTC. Avendo una classe base, posso poi derivare più facilmente quelle che rappresentano un'entità specifica, come in questo caso Book che espone solo le proprietà caratteristiche di questo oggetto:

Fatto questo, definisco una classe statica che contiene una costante a rappresentare l'URL del mio servizio di backend:

Chiaramente, dovrete sostituire l'URL con quello del vostro servizio.

L'accesso ai dati

La comunicazione col servizio di backend avviene attraverso una classe chiamata MobileServiceClient dell'SDK di Azure. Questa classe va istanziata passando al costruttore l'URL del servizio. L'istanza, poi, offre una serie di metodi per lavorare coi dati: GetTable per ottenere un riferimento alla tabella, InsertAsync per aggiungere un oggetto, UpdateAsync per aggiornarlo, DeleteAsync per eliminarlo, ToListAsync/ToEnumerableAsync per ottenere elenchi anche tramite query filtrate. Sono tutti metodi generici, dove il type parameter è il tipo che mappa la tabella. In questo caso sarebbe Book. Dico sarebbe perché abbiamo creato una classe astratta, quindi a meno di esigenze specifiche, possiamo definire una classe che genericamente inserisca, aggiorni e carichi oggetti di tipo T. Se vi state chiedendo perché mi serve una classe apposita, è presto detto:

  • semplifico il salvataggio di un oggetto verificando che abbia bisogno di un insert o di un update
  • mi permette di verificare se c'è connettività in modo più organizzato
  • mi permette di migliorare la mia logica nelle query.

Ed eccola, una classe chiamata DataManager che metto in una cartella chiamata DataAccess:

Notate come la proprietà Id di ciascun oggetto venga utilizzata per capire se è da inserire o modificare. E' per questo che l'Id non viene generato in fase di istanza dell'oggetto. Ora capite perché questa classe è facilmente riutilizzabile, grazie ai generics e ai loro vincoli offre le stesse funzionalità a tutti gli oggetti che ereditano da TableBase. Un'istanza di questa classe serve a tutta l'applicazione, per cui la vado a mettere nella classe App:

A questo punto siamo pronti per definire il ViewModel.

Il ViewModel, con dati e comandi

Bisogna definire un ViewModel, che chiameremo BookViewModel e che creeremo in una cartella chiamata ViewModel. Il codice è abbastanza semplice: c'è una collection di Book che rappresenta l'elenco di dati, c'è un singolo Book a rappresentare l'elemento corrente, ci sono i vari command che richiamano i relativi metodi della classe DataManager. L'aggiunta e la rimozione, com'è ovvio, agiscono sulla collection.

La proprietà IsBusy ci servirà nella UI per il binding a un ActivityIndicator. Nota: a voler essere precisi, andrebbe gestito anche il CanExecute dei command. Per farlo conviene usare un'implementazione alternativa, ve la lascio come esercizio.

La User Interface

...che non sarà bellissima da vedere, ma fa quello che deve fare: lavorare in binding col ViewModel. Saprete poi voi come rendere la UI più gradevole o comunque più adatta alle vostre esigenze tramite apposite pagine e data template. Abbiamo quindi un ActivityIndicator per mostrare lo stato di "occupato", una ListView con un data template in binding con le varie proprietà dell'oggetto, alcuni pulsanti in binding coi vari command:

Da code behind, l'unica cosa che c'è da fare è istanziare il ViewModel e assegnarlo al context della pagina:

Test dell'app

A questo punto si va di F5 e si testa l'app nell'emulatore o su device fisico, come preferite. Vi ricordo che nel Mobile Center abbiamo aggiunto un'app per Android, ma gli stessi passaggi si possono fare anche per iOS.


La cosa interessante è che poi nel Mobile Center, accedendo alla nostra Table, saremo in grado di visualizzare l'elenco dei dati. Da li potranno essere eliminati oppure si potranno importare da file CSV. Si potrà anche gestire l'autorizzazione, ma lo faremo tra due post. Nel prossimo, invece, parleremo di sincronizzazione offline.

In sintesi, grazie al Mobile Center, siamo stati in grado di dotare la nostra app di un backend pronto all'uso nella Cloud con pochi passaggi e con la massima efficienza.

Alessandro

posted @ domenica 12 febbraio 2017 23:00 | Filed Under [ Windows Azure and SQL Azure Xamarin ]

sabato 11 febbraio 2017

Visual Studio 2017 disponibile il 7 marzo

Microsoft ha annunciato che Visual Studio 2017 sarà rilasciato il 7 marzo, in concomitanza con i 20 anni dall'uscita del primo Visual Studio.

Per l'occasione così importante e per celebrare degnamente questa importante milestone, verrà tenuto un evento online di due giorni. in cui si susseguiranno i più conosciuti tra executive e ingegneri di Redmond che illustreranno in dettaglio le novità.

Sarà un momento importante per tutti noi, quindi conviene non mancare all'appuntamento

Alessandro

posted @ sabato 11 febbraio 2017 13:05 | Filed Under [ Visual Studio 2017 ]

giovedì 9 febbraio 2017

Xamarin, Azure e il Visual Studio Mobile Center - Statistica e analisi crash

Con questo post inizio una mini-serie dedicata al Visual Studio Mobile Center e al suo utilizzo connesso ad applicazioni realizzate con Xamarin e Visual Studio. Con questo post iniziamo a vedere le funzionalità telemetriche di statistica e analisi dei crash, nei prossimi post vedremo come sfruttare il servizio di backend per le Table, per poi passare alla sincronizzazione offline dei dati e all'autenticazione/autorizzazione dell'utente.

Prerequisiti
Il Visual Studio Mobile Center è un servizio Cloud e usa Azure per esporre alcuni servizi. Ciò significa che è necessario avere una sottoscrizione Microsoft Azure, anche trial.

Il secondo prerequisito è avere installato Visual Studio 2015, anche Community, con i tool Xamarin.

Cos'è il Visual Studio Mobile Center
Il Visual Studio Mobile Center è un portale per l'accesso a servizi pensati espressamente per applicazioni Mobile, offerto da Microsoft tramite Cloud. Ad oggi si tratta di un servizio in preview e comunque ancora in crescita. Le app supportate ad oggi sono Android e iOS e, come ambienti, Xamarin, React Native e Objective-C/Swift. Come detto, il servizio è in preview e quindi è comprensibile che non tutte le piattaforme siano ancora supportate.

Cosa offre di bello? Innanzitutto una serie di servizi di backend in-Cloud per app, come telemetria per l'analisi dei crash e delle statistiche sull'uso delle app, ma anche backend per dati con tabelle per la memorizzazione di dati e strumenti per aggiungere alle app l'autenticazione degli utenti basata sui più diffusi provider. Precisiamo che tabelle e autenticazione sono basati su Azure Mobile App, quindi le stesse cose posso ottenerle anche nel portale di gestione di Azure, tuttavia il Visual Studio Mobile Center offre un approccio decisamente più semplice e immediato. Non di meno, il Mobile Center offre strumenti di build automation basata su repository Git.

L'obiettivo da raggiungere
Per dimostrare come sfruttare appieno le potenzialità del Mobile Center, ci proponiamo un obiettivo: creare un'app cross-platform con Xamarin.Forms che gestisca un elenco di libri semplificato. In questo post implementeremo le funzionalità di telemetria. Nel prossimo post quelle di backend su Azure. Poi, nell'ordine, la sincronizzazione offline dei dati e l'autenticazione degli utenti. Ciò premesso, in Visual Studio 2015 (o 2017 RC per i coraggiosi) create un nuovo progetto di tipo Blank Xaml App (Xamarin.Forms Portable), basato quindi su Portable Class Library. Tenete conto del fatto che il Mobile Center supporta, ad oggi, solo i client iOS e Android. A voi la scelta, quindi, di tenere nella solution i rimanenti progetti.

Accesso al Mobile Center
Per l'accesso al Mobile Center potrete autenticarvi sia tramite Microsoft Account che tramite account GitHub:



Una volta fatto l'accesso, troverete un pulsante chiamato Add new app, al cui click potrete specificare i dati della nuova applicazione. L'app di esempio si chiamerà Book Store App, basata su Android e Xamarin. Nota: prendo a base Android perché non tutti hanno un Mac per compilare l'app iOS, ma i passaggi sono identici ed eventualmente andranno duplicati. Ecco cosa fare:



Chiaramente, click su Add new app.

Configurazione della telemetria
Dopo la creazione della nuova app, il Mobile Center visualizzerà le istruzioni da seguire per abilitare la telemetria nella nostra app, sia per Xamarin Android che per Xamarin.Forms, tramite gli appositi SDK:



In sintesi bisogna:

  • a livello di intera solution, aggiungere i seguenti pacchetti NuGet: Microsoft.Azure.Mobile.Analytics, Microsoft.Azure.Mobile.Crashes e Microsoft.Azure.Mobile, ma quest'ultimo viene scaricato automaticamente quale dipendenza
  • in Xamarin.Forms, aggiungere la seguente riga all'interno del metodo OnStart del file App.xaml.cs:
       MobileCenter.Start(typeof(Analytics), typeof(Crashes));
  • nel progetto Droid e nel file MainActivity.cs, aggiungere la seguente riga prima della chiamata a LoadApplication:
       MobileCenter.Configure("YOUR-GUID");

Dove YOUR-GUID va sostituito col GUID visibile nel Mobile Center. Chiaramente vanno aggiunte le direttive using che puntano ai namespace omonimi dei pacchetti NuGet.
Questo è quanto: per abilitare la telemetria sono sufficienti queste due righe di codice. Ora provate ad eseguire l'app un po' di volte e provate a causare intenzionalmente delle eccezioni a runtime.

Analisi della telemetria
Con i pulsanti Analytics e Crashes, possiamo accedere alle informazioni raccolte tramite telemetria e visualizzare molte informazioni rilevanti. Per esempio, in figura si vede un insieme di informazioni di analisi sul numero di sessioni attive, i device utilizzati, la durata delle sessioni di utilizzo, il numero di installazioni per versione di app, ecc:



Una nota sui crash: Crashes è una classe dell'SDK e non serve solo ad abilitare la telemetria. Per esempio ha una proprietà HasCrashedInLastSession per sapere se l'ultima volta l'app si è chiusa per un crash, oppure espone eventi che si verificano a crash occorso e prima dell'invio dei dati, o ancora consente di richiedere il permesso all'utente di inviare i dati. Da tenere in debita considerazione.

Conclusioni
In questa prima parte abbiamo già potuto apprezzare il Visual Studio Mobile Center e le sue potenzialità telemetriche legate alla Cloud. Nel prossimo post vedremo come iniziare a lavorare con la parte di backend relativa ai dati.

Alessandro

posted @ giovedì 9 febbraio 2017 23:00 | Filed Under [ Visual Studio 2015 Xamarin Visual Studio 2017 ]

domenica 5 febbraio 2017

Cognitive Services e utilizzo cross-platform via REST con ASP.NET Core e Visual Studio Code

Abbiamo parlato recentemente dei Cognitive Services di Microsoft, i servizi di intelligenza artificiale basati su Cloud e utilizzabili tramite specifiche API esposte tramite l'approccio REpresentational State Transfer (REST).

Nei post precedenti, per praticità e convenienza per chi proviene da un mondo tipicamente mobile o desktop, sono state utilizzate alcune librerie client che semplificano l'accesso alle API dei servizi. Per quanto ottimale, l'approccio basato su librerie ha due limitazioni: non ci sono librerie per tutti i servizi e non tutte le tipologie di progetto supportano quelle esistenti (negli esempi visti su Xamarin, alcune librerie non vanno sui progetti Windows).

In realtà tutto questo è un non problema, nel senso che è sufficiente chiamare le API tramite REST, normalmente col verbo POST. Per farlo in C#, si usa la classe HttpClient che è disponibile sia in .NET "full" che .NET Core. Quindi vedremo un esempio d'uso basato su ASP.NET Core, dimostrando che, così facendo, questi servizi saranno fruibili anche da altri sistemi come Mac e Linux, olter che (ovviamente) Windows.

Nota bene: in questo post prenderò ad esempio i servizi di Computer Vision, ma trattandosi di chiamate REST l'approccio è identico per tutti le altre API di tutti gli altri Cognitive Services.

Il risultato da ottenere

E' risaputo che Web, HTML, CSS et similia non siano propriamente il mio pane Né è mia intenzione insegnare ASP.NET ed MVC quando c'è chi lo fa molto meglio di me e con competenze molto maggiori, io mi barcameno con l'indispensabile. Quindi vorrete perdonare la "bruttezza" dell'interfaccia grafica e l'essenzialità dei controlli utilizzati, ma sono certo che apprezzerete il risultato L'obiettivo da raggiungere è questo:



Quindi, un'applicazione Web creata con ASP.NET Core che consente di selezionare immagini, di farle analizzare dai Cognitive Services e di mostrare il risultato.

Creazione dell'applicazione
Mi baso su una versione di .NET Core basata sulle solution MSBuild, quindi non più project.json. Si, sono ancora versioni in preview, ma il futuro è MSBuild. In particolare sto utilizzando l'SDK 1.0 RC 3 build 004530. All'interno di una cartella, creiamo una nuova applicazione Web chiamata CrossComputerVision utilizzando la command line:

> dotnet new -t web
> dotnet restore

Fatto questo, apriamo la solution con Visual Studio Code:


Perché non uso Visual Studio? Perché magari siete capitati qui da Ubuntu o da un Mac...

Il controller C#
Come sapete, i progetti ASP.NET Core sono basati su MVC, quindi il cuore del lavoro da fare è in un controller. Fondamentalmente, e a fattor comune, i passaggi da eseguire sono i seguenti:

  1. ottenere un riferimento all'oggetto da far analizzare ai cognitive services
  2. trasformarlo in un tipo .NET che possa essere aggiunto agli header della richiesta HTTP POST
  3. istanziare HttpClient e passare le informazioni da aggiungere negli header, inclusa la subscription key
  4. invocare HttpClient.PostAsync
  5. deserializzare da JSON la risposta ottenuta

Nel caso di Computer Vision, Face ed Emotion API, l'oggetto da far analizzare è un'immagine che viene letta sotto forma di Stream e che deve poi essere serializzato in stringa in base 64. Tutti questi passaggi devono trovare espressione sotto forma di codice C#. In questo esempio di livello base, possiamo tranquillamente utilizzare il file HomeController.cs. Al suo interno bisogna definire:

  • un metodo che rappresenti la action da invocare (che chiameremo Vision)
  • un metodo che legga l'immagine selezionata dall'utente sotto forma di Stream
  • un metodo che converta lo stream in ToBase64String
  • l'implementazione vera e propria della action che costruirà la richiesta HTTP, che invocherà il servizio tramite HttpClient.PostAsync e che deserializzerà la risposta.

Ecco il codice del controller:

L'oggetto IFormFile rappresenta un file inviabile tramite HttpRequest. Ricordatevi di sostituire il placeholder con la vostra subscription key, che è la stessa utilizzata nei post precedenti. Notate la parte di deserializzazione tramite JObject. Qui è stata semplificata al massimo, proprio per non complicare il codice stesso. E' chiaro che le elaborazioni di deserializzazione possono essere migliorate e più approfondite per rispettare lo schema restituito dal servizio, piuttosto che ottenere l'intera risposta sotto forma di un'intera stringa.

La View
La pagina in cui selezionare l'immagine e visualizzare il risultato dell'analisi va creata all'interno della cartella Views\Home e si chiamerà Vision.cshtml. E' definita in modo essenziale: c'è un oggetto form in cui ci sono label per la visualizzazione di testo ma soprattutto l'elemento input per la selezione del file e l'altro input, un button per avviare l'upload. Nella parte sottostante c'è un controllo img per visualizzare l'immagine prescelta e una label che visualizzerà il risultato dell'analisi.

Le informazioni vengono recuperate dall'oggetto ViewData tramite il cosiddetto model-binding di MVC. Ecco il markup:


La pagina dovrà poi essere collegata al layout aggiungendo la seguente riga nel file Views\Shared\_Layout.cshtml insieme alle righe omologhe:

<li><a asp-area="" asp-controller="Home" asp-action="Vision">Vision</a></li>

E servirà a finalizzare l'associazione della pagina col controller e la relativa action.

Da Visual Studio Code sarà poi sufficiente attivare gli strumenti di debug e avviare l'applicazione nel browser secondo la configurazione .NET Core Launch (Web).

Cross-platform?

Beh, chiaramente si. Ecco il risultato su Ubuntu:



Come anticipato all'inizio, ricorrere all'approccio basato su HTTP e REST rende l'utilizzo dei Cognitive Services indipendente da piattaforme, linguaggi e strumenti di sviluppo, non è assolutamente ristretto a Computer Vision e porta questi strumenti di intelligenza artificiale Microsoft pressoché ovunque.

Alessandro

posted @ domenica 5 febbraio 2017 23:00 | Filed Under [ Visual Studio Code ]

venerdì 3 febbraio 2017

Condividere codice con Gist

Gist è un servizio di GitHub che consente di condividere file di codice. Non è come un repository, riferendosi più che altro a singoli file sui quali è possibile eseguire un numero limitato di operazioni, come la clonazione o la documentazione markdown. E' molto comodo perché genera l'HTML necessario per essere utilizzato all'interno di pagine Web, esattamente come blog post o articoli.

Non è certo né una novità né una scoperta, ma personalmente ho iniziato ad usarlo da poco tempo e mi fa piacere parlare di come si usa.

Innanzitutto è necessario essere registrati su GitHub, fare login e andare su https://gist.github.com. Si accederà così a un editor in cui si dovrà specificare un titolo e il nome del file. E' molto importante l'estensione, perché sulla base di essa l'editor attiverà la colorazione della sintassi più appropriata.

Ecco un esempio:



All'interno della pagina vedrete anche gli ultimi gist che avete pubblicato e il link per accedere allo storico. Potete creare gist pubblici o gist privati (secret). Questi ultimi potranno comunque essere condivisi via URL o html ma non saranno visibili sul vostro profilo. Dopo aver creato il gist, comparirà una pagina in cui potrete aggiungere commenti, cliccare su Edit per modificare il codice del gist (cosa che alimenterà il versoin control) e utilizzare una delle possibilità di condivisione ottenibili tramite la freccia vicino al pulsante Embed:



E' già disponibile uno script html da poter incorporare nelle pagine Web, il cui risultato è il seguente:


Se invece fate click su Revisions, potrete vedere le differenze tra le versioni del file, proprio grazie al version control di Git.

Sicuramente molto comodo se scrivete pubblicazioni online in cui dovete condividere codice e non volete impazzire con tool di formattazione spesso totalmente inadatti.

Alessandro

posted @ venerdì 3 febbraio 2017 08:35 | Filed Under [ Community and friends ]

Powered by:
Powered By Subtext Powered By ASP.NET