ComputerLand

Tu sei qui: Articoli MSDN

Notizie dal web

Guest post: dotNET{podcast}

E-mail Stampa PDF

Questo post è stato scritto da Roberto Albano, Team Leader in Lynx.

Cos'è dotNET{podcast}

dotNET{podcast} (www.dotnetpodcast.com) è il primo podcast italiano interamente dedicato alle tecnologie Microsoft.

Lo scopo principale è quello è quello di informare, divulgare, incuriosire l'ascoltatore e dargli spunti di riflessione su cui avviare in maniera autonoma degli approfondimenti.

La formula del podcast è quella dell'intervista, in cui ci si trova a chiacchierare sulle tematiche con vari ospiti, tutte persone appassionate ed estremamente disponibili, e con le quali confrontarsi sulle tecnologie per le quali hanno, per lavoro o per passione, una grande esperienza o un particolare interesse.

Quando nasce

L'idea nasce nell'estate del 2014, quindi ormai un anno fa, quando ci si rese conto (io, Antonio Giglio e Massimo Bonanni) che non esistevano podcast tecnici dedicati al mondo Microsoft in lingua italiana.
Questa "grave" mancanza andava colmata ad ogni costo e così avviammo il progetto prendendo spunto da format di successo e già collaudati quali, ad esempio dotNetRocks e HanselMinutes, e modellammo il tutto tenendo conto delle nostre idee e calandolo nel contesto italiano.

La potenzialità dell'iniziativa fu chiara praticamente da subito, infatti prima ancora di partire con qualunque attività, facemmo un veloce sondaggio tra vari MVP ed appassionati (ovvero i potenziali ospiti), e l'idea fu subito accolta con grande simpatia.

In poco meno di un mese (lavorando anche di notte, nel vero senso della parola) si riuscì a partire e nel settembre 2014 pubblicammo la prima puntata, con Massimo Bonanni come primo ospite/cavia.

Da allora ogni lunedì siamo riusciti a produrre sempre una nuova puntata, in alcuni casi anche puntate supplementari di mercoledì.

In poco tempo siamo stati riconosciuti, con grande e sincero orgoglio, quale community tecnica nel circuito delle Microsoft Technical Communities, e questo onore è per noi un vanto oltre che uno sprono per continuare sempre nella divulgazione.

Anche per questo sono nate le puntate "community" (pubblicate appunto di mercoledì) che intendono, di volta in volta, presentare le community tecniche esistenti in Italia (sia locali che nazionali), per promuoverle ulteriormente e far sì che siano conosciute da chi vive nella zona di competenza e non ne conosce l'esistenza o le attività.

Le difficoltà

Il progetto, le idee, i vari argomenti, ok… Ma cosa vuol dire fare un podcast?

Senza scendere troppo nel dettaglio, elenchiamo alcune delle fasi necessarie per realizzare ognuna delle puntate che abbiamo pubblicato:

  • Scelta degli argomenti e degli ospiti
  • Contatto dell'ospite
  • Studio dell'argomento e preparazione delle domande
  • Condivisione delle domande con l'ospite per la verifica
  • Pianificazione della puntata
  • Registrazione della puntata
  • Montaggio

Ognuno di questi passaggi, scritto così, sembra poca roba, ma per completare ogni fase ci vuole impegno e, soprattutto, tempo.

E siccome (non so se si era capito) per questi podcast "nessuna ora di lavoro aziendale viene e/o verrà sacrificata", bisogna affidarsi al tempo rimanente, ovvero al tempo libero (in pratica sera e weekend).

Santi subito i nostri familiari, che ci sopportano in questa "insana pazzia" di voler dedicare questo tempo (tanto, spesso troppo) per realizzare un progetto che, tra l'altro, non porta alcun tipo di ricavo, anzi…

Ma noi siamo caparbi, e soprattutto abbastanza folli da continuare ancora, e continueremo finché ce la faremo a reggere i ritmi, anche se sempre più pesanti, di questo (a tutti gli effetti) "secondo lavoro".

Gli obiettivi

L'obiettivo di dotNET{podcast} è tanto semplice quanto ambizioso: essere utile.

La crescita che abbiamo avuto, in termini numerici e di consensi, soprattutto se rapportati alla difficoltà di diffusione dei podcast (sempre erroneamente sottovalutati) ci ha portato a pensare a nuove idee per renderci utili. Quindi, nello stesso tempo a disposizione (sempre meno) abbiamo aumentato le cose da fare.

La prossima idea, che vedrà la luce a brevissimo, sarà una nuova sezione relativa ai "premi" per chi ci ascolta.
Spiego meglio la cosa: in quanto community tecnica, abbiamo a disposizione dei gadget (comunque di valore, ad esempio e-book, subscription per siti tecnici, licenze software ecc.) che ci vengono forniti per gli eventi che le community normalmente organizzano.

Fermo restando che l'idea di un evento non è lontana dal realizzarsi (non a breve termine ma ci saranno sicuramente), intanto abbiamo pensato di mettere a disposizione di chi ci ascolta questi gadget.
Un incentivo in più ad ascoltare le nostre puntate e migliorare il proprio bagaglio di conoscenze, unito piacere di avere allo stesso tempo ricevere un libro tecnico da leggere o una licenza per vedere webcast di grossi esperti internazionali o licenze utile per migliorare, ad esempio, le proprie app mobile con controlli più evoluti.
Insomma oltre ad aiutarvi nella crescita professionale, proviamo a darmi una mano anche con qualche "strumento" di lavoro, e tutto ovviamente in maniera gratuita. E scusate se è poco :-).

I social

Per far conoscere più possibile la nostra community ci siamo affidati ovviamente ai canali social, quindi al nostro account Twitter, al nostro gruppo Facebook e per chi è pigro o "poco social" abbiamo anche una newsletter a cui potersi iscrivervi per seguire le nostre attività e/o le nuove puntate pubblicate.

Per chi invece ha un po' più di dimestichezza con i podcast, abbiamo allestito anche un feed RSS da cui potete alimentare i vostri lettori RSS e/o di podcast per poterci seguire in maniera automatica.

Infine, per chi volesse contattarci direttamente può farlo attraverso la pagina dei contatti del nostro sito.

Insomma, non ci siamo risparmiati per seguirvi e farci seguire, cercando di essere sempre presenti più possibile sui social in modo da poter interagire ancora di più. Dai nostri ascoltatori ci piace sicuramente ricevere complimenti, ma anche e soprattutto suggerimenti, idee, e anche critiche che possano in maniera costruttiva aiutarci a crescere e migliorare.

L'interazione è garantita anche puntata per puntata, infatti in ogni pagina della puntata è possibile inserire commenti e feedback più puntuali.

Gli ospiti

Uno dei fattori di successo del podcast sono stati sicuramente i nostri ospiti, tutti estremamente gentili e disponibili, oltre che ovviamente preparati.

Abbiamo avuto da subito una buona "adesione" e man mano che siamo "cresciuti", abbiamo riscontrato sempre maggiori consensi, sia dagli ascoltatori che abbiamo avuto modo di incontrare agli eventi, ma ancor di più dagli "addetti ai lavori".

Questo ovviamente ci gratifica e ci rende più lieve il duro lavoro che costa ogni puntata, dietro le quinte.

Approfitto di questa occasione, a nome di tutto lo staff di dotNET{podcast}, per ringraziare ancora una volta tutti gli ospiti che sono intervenuti finora (e anticipatamente quelli che verranno) per la loro disponibilità.
Senza di loro, nessuna delle oltre cinquanta puntate pubblicate finora avrebbe avuto lo stesso valore.

Gli argomenti

Arduo ma non troppo scegliere gli argomenti per le puntate. Con l'ampio ventaglio di tecnologie e prodotti Microsoft a disposizione, la scelta è sicuramente facilitata.
In alcuni casi, tuttavia, alcuni degli argomenti scelti sembravano assolutamente inadatti ad essere oggetto di una spiegazione solo verbale.
Ma alla fine, quasi inspiegabilmente, alcune di queste puntate sono state tra le più ascoltate.

Citiamo alcuni esempi:

  • la puntata dedicata a DDD e CQRS con Andrea Saltarello (DDD e CQRS per tutti), parla di argomenti architetturali che, generalmente, vengono trattati durante sessioni tecniche coadiuvate da slide e codice ma che, anche grazie alla particolare capacità dell'ospite, sono stati perfettamente spiegati e sono diventati fruibili anche solo con il "verbo";
  • analogo discorso per la puntata dedicata a NServiceBus di Mauro Servienti che, a dispetto dell'argomento decisamente ostico è stata una delle più seguite e apprezzate;
  • sul fronte dei linguaggi di programmazione, puntate come quella su F# con Alessandro Melchiori (Introduzione a F#) oppure C++ con Marco Arena (Perchè nel 2015 parliamo ancora di C++ ?), sembravano pura follia, e invece sono risultate molto gradite e ascoltate;
  • infine l'argomento del cloud di Microsoft, ovvero Microsoft Azure, di cui abbiamo prima fatto una puntata introduttiva con Vito Flavio Lorusso (Azure for developers), e a cui sono seguite poi altre puntate su funzionalità specifiche, è sembrato un argomento gradito, e su cui sicuramente continueremo a lavorare.

La cosa che, comunque, ci ha sorpreso di più è che la maggior parte delle puntate sono state apprezzate (alcune hanno avuto dei picchi ma non abbiamo avuto puntate particolarmente inascoltate) il che ci conferma che la scelta di un podcast "made in italy" è quella giusta!

Starà a noi, e soprattutto a voi ascoltatori, continuare su questa strada e, se possibile, migliorare ulteriormente.

Per questa estate, scaricate le puntate e portateci con voi, al mare sotto l'ombrellone o al fresco in alta montagna, vi terremo compagnia!

Ci risentiamo a settembre con nuove puntate e iniziative!!!


read full article

Guest post: Pubblicare e migrare la vostra prima Universal Windows app per Windows 10

E-mail Stampa PDF

Questo post è stato scritto da Matteo Pagani, Support Engineer in Microsoft per il programma AppConsult.

Le ultime due settimane sono state molto importanti per gli sviluppatori Microsoft e non: il 20 Luglio è stata rilasciata la RTM di Visual Studio 2015, mentre il 29 Luglio, oltre al rilascio ufficiale di Windows 10, è stata distribuita la versione finale dell'SDK che consente lo sviluppo e la pubblicazione di Universal Windows app per Windows 10.

A partire da tale data, infatti, il Dev Center ha aperto le porte alla pubblicazione di applicazioni Windows 10 sullo Store. Se negli ultimi mesi avete sfruttato le preview per iniziare a sviluppare (o a migrare) la vostra prima Universal Windows app per Windows 10, ora finalmente avete la possibilità di pubblicarla e farla scaricare alle tantissime persone che in questi giorni stanno aggiornando, in maniera completamente gratuita, il loro PC dotato di Windows 7 o Windows 8.1 (è di ieri la notizia che, a 24 ore dal lancio, Windows 10 è già stato installato su oltre 14 milioni di computer).

Se provate, però, ad aprire il vostro progetto dopo aver installato la versione finale di Visual Studio 2015 e dei tool di Windows 10, vi accorgerete di una serie di problemi che vi impediranno di preparare il pacchetto da caricare sullo Store, da quelli più semplici da risolvere (come il fatto che il progetto non si apra perché cerca una versione dell'SDK che non esiste più) a quelli invece all'apparenza più misteriosi (come la mancanza di classi fondamentali del framework .NET).

Il motivo è che la struttura del progetto Universal Windows app ha subito delle sostanziali modifiche, collegate in particolar modo alle novità introdotte dalla nuova versione di NuGet. La soluzione più semplice per risolvere il problema è creare un nuovo progetto di tipo Universal Windows app e copiare tutti i file che fanno parte della vostra soluzione attuale (classi, asset, ecc.). Questa soluzione è documentata direttamente su MSDN, all'indirizzo https://msdn.microsoft.com/en-us/library/windows/apps/xaml/mt188198.aspx

In alcuni casi, però, si tratta di una strada non percorribile. Pensiamo, ad esempio, ad un progetto sotto source control: il fatto di dover eliminare il vecchio progetto e sostituirlo con uno nuovo potrebbe essere difficile da gestire. Vediamo perciò i passaggi da seguire per modificare un progetto già esistente e renderlo compatibile con il nuovo formato introdotto con la versione finale dei tool di sviluppo.

I prerequisiti: i tool di sviluppo

Le informazioni riportate in questo paragrafo, in realtà, sono utili a chiunque voglia sviluppare un'applicazione per Windows 10 e non solo a chi è già pronto per pubblicare la sua prima applicazione.

Il primo requisito è quello di avere Windows 10: non è indispensabile, dato che i tool di sviluppo possono essere utilizzati anche su un PC con Windows 8.1, ma è sicuramente la strada più semplice, dato che potrete gestire la fase di sviluppo e di testing sulla stessa macchina. In caso contrario, potete continuare ad utilizzare Windows 8.1 per lo sviluppo, ma avrete bisogno di un altro device con Windows 10 (un altro computer, un tablet, ecc.) per testare e fare debug della vostra app.

La distribuzione di Windows 10 è iniziata il 29 Luglio come aggiornamento gratuito per chiunque abbia una copia valida di Windows 7 o Windows 8.1. Trovate tutte le informazioni necessarie all'indirizzo http://www.microsoft.com/en-us/windows/windows-10-upgrade Se, invece, siete iscritti al programma Insider, assicuratevi che il vostro PC sia aggiornato e che siate sulla build 10240 (potete verificarlo aprendo un prompt dei comandi, in cima viene sempre riportata l'indicazione sul numero di versione).

Il secondo requisito è installare Visual Studio 2015: ne esistono diverse versioni, a seconda delle vostre esigenze, che trovate sul sito ufficiale http://www.visualstudio.com. È importante sottolineare, però, la presenza di una versione, definita Community, che è completamente gratuita per gli sviluppatori indipendenti e per i progetti open source, che offre le stesse funzionalità della versione Professional.

Nel momento in cui lanciate il setup di Visual Studio 2015, è importante non procedere con l'installazione standard ma utilizzare questa personalizzata: questo perché, come impostazione predefinita, l'SDK di Windows 10 non viene installata. Assicuratevi, perciò, che l'opzione rappresentata nella schermata seguente sia abilitata prima di procedere:

Una volta terminata l'installazione, siete pronti per creare un nuovo progetto per Windows 10 (grazie ai template presenti nella categoria Windows Universal) o a migrarne uno già esistente.

Il primo passo: modificare i progetti

Una delle novità più importanti di Windows 10 è la Universal Windows Platform (abbreviata, UWP): una piattaforma per gli sviluppatori che è disponibile, in maniera trasversale, su tutti i device Windows 10, siano essi computer, tablet, telefoni o Raspberry PI 2. La Universal Windows Platform ha la peculiarità di potersi evolvere in maniera indipendente dal sistema operativo: ciò significa che, in futuro, come Microsoft potremo rilasciare delle nuove versioni della UWP, senza per questo rilasciare però una nuova versione di Windows. Di conseguenza, le Universal Windows app per Windows 10 non hanno più come target di riferimento una versione specifica del sistema operativo, ma una versione della UWP.

 

Ecco il motivo per cui, una volta aperta la soluzione che avete creato con Visual Studio 2015 RC, vi comparirà un messaggio di errore e il Solution Explorer vi mostrerà il vostro progetto (o progetti) con, di fianco, la dicitura Update Required.

L'installazione di Visual Studio 2015 e dell'SDK finale di Windows 10, infatti, si fa carico di eliminare tutte le versioni precedenti della UWP, le quali erano in Preview. Di conseguenza, la versione corrente del vostro progetto sarà configurata per utilizzare una versione della UWP (come la 10069 o la 10166) che sul vostro computer non esiste più.

Potete verificare tutte le versioni della Universal Windows Platform installate sul vostro computer aprendo il percorso C:\Program Files (x86)\Windows Kits\10\Platforms\UAP. Se avete installato correttamente i tool in versione finale, dovreste trovare solamente una cartella relativa alla versione 10240.

 

Il primo passaggio, perciò, è quello di modificare il progetto per utilizzare la versione 10240 della UWP: dovete intervenire manualmente, modificando il file .csproj che contiene la configurazione del progetto. Dato che, al momento, il progetto non è attivo, potete farlo direttamente da Visual Studio: fatevi click con il tasto destro e scegliete la voce Edit, che sarà seguite dal nome del file di progetto. In questo modo, direttamente in Visual Studio si aprirà il file .csproj in versione testuale, che non è altro che un file XML che contiene tutte le informazioni sulla struttura del progetto (nome, file e reference, configurazioni, ecc.)

All'interno, troverete le due seguenti proprietà:

<TargetPlatformVersion>10.0.10069.0</TargetPlatformVersion>

<TargetPlatformMinVersion>10.0.10069.0</TargetPlatformMinVersion>

All'interno, troverete la versione della UWP su cui è basata la vostra applicazione, che dovrete modificare indicando la più recente, ovvero la versione 10240. La proprietà più importante è TargetPlatformVersion, che dovrete impostare su 10.0.10240.0: grazie a questa modifica, avrete la possibilità di aprire il progetto in Visual Studio, semplicemente facendoci clic sopra con il tasto destro e scegliendo la voce Reload project. La proprietà TargetPlatformMinVersion specifica, invece, la versione minima della Universal Windows Platforms su cui l'applicazione è in grado di funzionare. Nella maggior parte dei casi, in questo momento, le due proprietà avranno lo stesso valore, in quanto la versione 10240 coincide con la prima release ufficiale di Windows 10 (le versioni precedenti erano accessibili in forma di preview solamente agli iscritti al programma Insider). In futuro, invece, con l'evoluzione di Windows 10 e il rilascio di nuove versioni della UWP, invece, sarà plausibile che queste due proprietà possano differire.

Il secondo passo: modificare il file di manifest

Una delle novità che sicuramente noterete con maggiore piacere della versione finale dei tool di sviluppo è il ritorno dell'editor visuale del file di manifest. Facendo doppio clic sul file Package.appxmanifest, infatti, si aprirà una comoda interfaccia visuale, che vi permetterà con semplicità di configurare le capability, gli asset predefiniti, ecc.

Dietro le quinte, però, il file di manifest non è altro che un file XML che, a sua volta, contiene anche lui l'informazione su quale sia la UWP di riferimento. Tale informazione, però, non è accessibile dall'interfaccia grafica; dovrete, perciò, fare click con il tasto destro sul file Package.appxmanifest e scegliere la voce View code. All'interno del file XML troverete le seguenti righe:

<Dependencies>

<TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.10069.0" MaxVersionTested="10.0.10240.0" />

</Dependencies>

Anche in questo caso, dovrete specificare:

  1. La versione della UWP utilizzata, tramite la proprietà MinVersion. Un dispositivo con una versione della UWP inferiore non sarà in grado di utilizzare l'applicazione.
  2. La versione massima della UWP con cui abbiamo testato la nostra applicazione e per la quale siamo sicuri non ci siano problemi di compatibilità, tramite la proprietà MaxVersionTested.

Anche in questo caso vale il ragionamento fatto in precedenza: essendo la 10240 la prima versione ufficiale di Windows 10, in questo momento le due proprietà probabilmente coincideranno nella maggior parte dei casi.

Goodbye packages.config, welcome project.json

La novità forse più importante della versione finale dei tool di sviluppo è l'utilizzo di un nuovo formato per la gestione delle dipendenze di un progetto, legato all'introduzione della versione 3.0 di NuGet, il celebre package manager di Visual Studio.

Le versioni precedenti erano basate su un file, incluso nella root del progetto, chiamato packages.config: si tratta di un XML che contiene la descrizione di tutti i pacchetti che sono stati installati tramite NuGet. Le nuove applicazioni Windows 10, invece, fanno uso di un nuovo file di nome project.json che, usando il formato JSON, descrive tutte le dipendenze che sono necessarie all'applicazione per essere compilata correttamente.

Ecco un esempio di file project.json:

{

"dependencies": {

"Microsoft.ApplicationInsights": "1.1.0",

"Microsoft.ApplicationInsights.PersistenceChannel": "1.1.0",

"Microsoft.ApplicationInsights.WindowsApps": "1.1.0",

"Microsoft.NETCore.UniversalWindowsPlatform": "5.0.0",

"Newtonsoft.Json": "7.0.1",

},

"frameworks": {

"uap10.0": {}

},

"runtimes": {

"win10-arm": {},

"win10-arm-aot": {},

"win10-x86": {},

"win10-x86-aot": {},

"win10-x64": {},

"win10-x64-aot": {}

}

}

Come vedete, contiene la definizione dei pacchetti NuGet (dependencies), dei framework utilizzati (frameworks) e dei runtime per cui viene compilata l'app (runtimes). Se osservate le dipendenze, ne noterete una particolare: .NET Core, ovvero la libreria che vi permette di sfruttare il bridge specifico di .NET per la Universal Windows Platform.

Questo è il motivo per cui, se cercherete di compilare il vostro progetto otterrete una serie di errori, all'apparenza misteriosi, relativi alla mancanza di classi base del framework .NET, come Object o string. Di conseguenza, anche se avete un progetto che non contiene alcuna riferimento a librerie esterne (e, di conseguenza, non ha un file packages.config) avrete comunque bisogno di un file project.json: senza di esso, mancherà il fondamentale riferimento a .NET Core.

Il modo più semplice per migrare il vostro progetto è seguire questi passaggi:

  1. Annotatevi da qualche parte il contenuto del file packages.config, così da avere un riferimento di tutte le librerie che avete installato.
  2. Dall'interfaccia di NuGet, disinstallate tutte le librerie installate. Per visualizzarle, scegliete la voce Installed dal menu a tendina Filter: ora, una per una, selezionatala e, dal menu a tendina Action, scegliete l'opzione Uninstall.

     

     

  3. Eliminate dal vostro progetto il file packages.config.
  4. Ora create un file di nome project.json e aggiungetelo al progetto, con la seguente definizione base:

{

"dependencies": {

"Microsoft.NETCore.UniversalWindowsPlatform": "5.0.0",

},

"frameworks": {

"uap10.0": {}

},

"runtimes": {

"win10-arm": {},

"win10-arm-aot": {},

"win10-x86": {},

"win10-x86-aot": {},

"win10-x64": {},

"win10-x64-aot": {}

}

}

  1. Chiudete Visual Studio e riaprite la soluzione.
  2. Ora riaprite l'interfaccia di NuGet e, aiutandovi con il contenuto del vecchio file packages.config che avete annotato in precedenza, reinstallate tutte le librerie utilizzate dal vostro progetto. In questo modo, andrete in automatico ad utilizzare la nuova versione di NuGet e noterete che i riferimenti alle librerie non saranno più aggiunti nel file packages.config, ma all'interno del nodo dependencies del file project.json.

Gestire le Extension SDK

Se avete già iniziato a sviluppare Universal Windows app per Windows 10, dovreste conoscere il concetto di Extension SDK. La UWP, come già detto, è una piattaforma di sviluppo in comune tra tutti i device con Windows 10. A volte, però, si ha la necessità di sfruttare delle funzionalità che sono disponibili solamente su una tipologia di device: ad esempio, non avrebbe senso utilizzare le API per interagire con i GPIO di un micro computer come Raspberry PI 2 su un pc o un tablet. Di conseguenza, all'interno del menu Add reference di Visual Studio, alla voce Extensions, troverete una serie di librerie in grado di aggiungere alla UWP una serie di funzionalità specifiche in base alla famiglia di device (mobile, desktop, IoT, ecc.).

Nel passaggio alla versione 10240 della UWP anche queste extension sono state aggiornate: di conseguenza, se ne facevate uso, dovrete rimuovere nella sezione References del progetto il riferimento a quelle vecchie e aggiungere, invece, quella nuova.

 

È giunta l'ora di pubblicare!

Se avete seguito correttamente i passaggi fin qui riportati, ora il vostro progetto dovrebbe compilare senza errori e sarete in grado di lanciare la vostra applicazione sia sul vostro PC che sull'emulatore della versione mobile di Windows 10. A questo punto, potete procedere con la pubblicazione con le stesse modalità utilizzate per le applicazioni 8.1: fate clic con il tasto destro sul vostro progetto e, alla voce Store, scegliete l'opzione Create app packages. Seguendo il wizard (che vi guiderà passo per passo chiedendovi una serie di informazioni, come il numero di versione dell'applicazione) otterrete alla fine un pacchetto di tipo .appxupload, che dovrete caricare sul Dev Center quando vi sarà richiesto durante la procedura di invio.

Non vediamo l'ora di vedere e provare le vostre Universal Windows app! Happy coding!


read full article

Player Framework 3.0 finale per Windows 10

E-mail Stampa PDF

Un piccolo post per segnalare che è disponibile la versione finale del Player Framework 3.0 per Windows 10.

Per maggiori dettagli e per capire cosa serve il Player Framework con Windows 10 vi rimando al post che avevo fatto tre settimane fa.

-Lorenzo


read full article

Visual Studio 2015: alcune informazioni sulla RTM

E-mail Stampa PDF

Lunedì è finalmente uscito Visual Studio 2015 RTM, come annunciato da Soma sul suo blog.

Vi ricordo solo alcune cose:

  • Le versioni Premium e Ultimate di Visual Studio e MSDN sono state unificate nella versione Enterprise
  • La versione Community di Visual Studio è equivalente alla Professional (a meno della funzione CodeLens). E’ completamente gratuita fino a 5 developer che lavorano in aziende medio/piccolema per una visione di tutte le condizioni di utilizzo usate questa pagina: condizioni di utilizzo gratuito.
  • La versione Community di Visual Studio può essere usato da QUALSIASI developer per contribuire a progetti Open Source, per fare ricerca in ambito accademico e istruzione.
  • Fino al 29 luglio NON UTILIZZATE LA RTM se volete sviluppare Universale Windows Platform App per Windows 10, in quanto i tool per Windows 10 non funzionano ancora sulla RTM e verranno rilasciati il 29 luglio con la disponibilità per tutti di Windows 10.

Ci sono centinaia di novità nella nuova versione di Visual Studio, in tutti i campi, nei linguaggi, per il cloud, per lo sviluppo mobile, desktop e web, per il cross-platform, etc... etc.. vi invito a guardare tutte le risorse nel post di Soma.

Un video molto breve che vi consiglio di vedere è il seguente, che fa vedere com'è cambiato e come sta cambiando lo sviluppo di Visual Studio: 

-Lorenzo


read full article

Guest post: Fare il crop delle immagini usando l’app Foto di Windows 10

E-mail Stampa PDF

Questo post è stato scritto da Fela Ameghino, developer Windows Phone di fama internazionale.

Una delle feature più interessanti di Silverlight per Windows Phone erano sicuramente i Task, che ci permettevano di lanciare alcune app di sistema per fare eseguire all'utente alcune semplici operazioni.

Uno dei Task più utilizzati era il PhotoChooserTask, che con l'avvento del Windows Runtime è stato sostituito dalla classe FileOpenPicker. Quest'ultima ci dà più flessibilità, permettendoci di selezionare altre tipologie di file oltre alle immagini, ma perde una funzionalità molto utile del vecchio Task, cioè la possibilità di far ritagliare l'immagine all'utente per averla delle dimensioni che preferisce

Grazie a Windows 10 troviamo una soluzione al problema, utilizzando la nuova app Foto e il nuovo metodo Launcher.LaunchUriForResults. Se ricordate, già nelle precedenti versioni di Windows e Windows Phone era possibile utilizzare il meccanismo di Protocol Activation per lanciare una determinata app, ma questa nuova versione ci permette anche di ricevere una risposta dalla stessa.

Il protocollo che dobbiamo utilizzare è microsoft.windows.photos.crop: e richiede i seguenti parametri:

CropWidthPixels

int

Larghezza dell'immagine che vogliamo ottenere

CropHeightPixels

int

Altezza dell'immagine che vogliamo ottenere

EllipticalCrop

bool

L'indicatore visuale del crop può essere rotondo (Il risultato sarà comunque rettangolare)

ShowCamera

bool

Ci permette di mostrare un bottone per permettere all'utente di scattare una foto sul momento

InputToken

string

 

DestinationToken

string

 

 

Dato che l'app Foto non ha la possibilità di prendersi a carico l'immagine ritagliata (visto che per lei è un file temporaneo) siamo noi a doverle dire dove salvare quest'ultima e, non potendo passare direttamente come parametro lo StorageFile dobbiamo usare SharedStorageAccessManager.AddFile. Quest'ultimo ci consente di ottenere un token (riscattabile tramite RedeemTokenForFileAsync) che ci permette di condividere più facilmente il file con altre app. Una volta ottenuto il token dobbiamo passarlo tramite il parametro DestinationToken.

Possiamo usare lo stesso procedimento per il parametro opzionale InputToken, che ci permette di passare direttamente all'app l'immagine da ritagliare. Quest'ultimo può rivelarsi utile se volessimo far scegliere ad esempio l'immagine tramite FileOpenPicker, o la ottenessimo tramite contratto Share.

Una volta passati i parametri e attesa l'interazione dell'utente, l'app ci restituirà un parametro "Status" dal valore "OK" per confermarci il completamento dell'operazione. A questo punto potremo aprire il nostro file per utilizzare l'immagine ottenuta.

 

Ecco un esempio completo:

private async Task CropImage()

{

// Creo il file di destinazione e ottengo il token per la condivisione

var file = await ApplicationData.Current.LocalFolder.CreateFileAsync("Cropped.jpg", CreationCollisionOption.ReplaceExisting);

var token = SharedStorageAccessManager.AddFile(file);

 

// Specifico l'app che deve aprirsi tramite LaunchUriForResults

var options = new LauncherOptions();

options.TargetApplicationPackageFamilyName = "Microsoft.Windows.Photos_8wekyb3d8bbwe";

 

// Specifico tutti i parametri necessari

var parameters = new ValueSet();

parameters.Add("CropWidthPixels", 500);

parameters.Add("CropHeightPixels", 500);

parameters.Add("EllipticalCrop", true);

parameters.Add("ShowCamera", false);

parameters.Add("DestinationToken", token);

 

// Lancio l'app e attendo la sua risposta

var result = await Launcher.LaunchUriForResultsAsync(new Uri("microsoft.windows.photos.crop:"), options, parameters);

// Verifico che l'utente abbia davvero ritagliato l'immagine

if (result.Status == LaunchUriStatus.Success && result.Result != null)

{

// Carico l'immagine

var stream = await file.OpenReadAsync();

var bitmap = new BitmapImage();

await bitmap.SetSourceAsync(stream);

 

// E la imposto come Source di un controllo Image

Preview.Source = bitmap;

}

}


read full article

Una nuova libreria per integrare Facebook nelle applicazioni Windows 8.1, Windows Phone 8.1 e Windows 10

E-mail Stampa PDF

Questo post è stato scritto da Matteo Pagani, Support Engineer in Microsoft per il programma AppConsult.

Qualche tempo fa, sempre su questo blog, ho avuto il piacere di pubblicare alcuni articoli dedicati all'integrazione con Facebook nelle Windows Store app per Windows e Windows Phone 8.1.

Oggi sono qui per parlarvi di una nuova libreria dedicata a questo scopo che, come Microsoft, abbiamo recentemente rilasciato sotto forma di progetto open source disponibile su GitHub.

I punti di forza di questa libreria rispetto a Facebook. NET (trattata nei precedenti articoli) sono:

  1. Maggiore semplicità di utilizzo, soprattutto per quanto riguarda l'integrazione del login
  2. E' sviluppata in C++, di conseguenza offre migliori performance e non ha dipendenze dal CLR di .NET
  3. Oltre a supportare le Windows Store app per Windows 8.1 e Windows Phone 8.1, è compatibile anche con le nuovissime Universal Windows app di Windows 10

Nel corso di questo post vedremo come integrarla e utilizzarla nelle nostre applicazioni.

Aggiungere la libreria al vostro progetto

La libreria non viene, al momento, distribuita come pacchetto NuGet. Di conseguenza, dovete scaricarla manualmente a aggiungerla alla vostra soluzione di Visual Studio. Il progetto, come già anticipato, è disponibile su GitHub all'indirizzo https://github.com/Microsoft/winsdkfb: il modo più semplice per scaricarlo è usare i tool Git integrati in Visual Studio. In questo modo, sarà più semplice per voi mantenere la libreria aggiornata ogni qualvolta il team rilascerà degli aggiornamenti.

Ecco come fare:

  1. Aprite Visual Studio (il riferimento per questa guida è la versione 2015, ma i passaggi sono gli stessi con la 2013).
  2. Aprite Team Explorer (se non è già presente nella schermata iniziale, lo trovate dal menu View – Team Explorer)
  3. Troverete la voce "Local Git repositories": premete il pulsante Clone e specificate
    1. Nel primo campo, l'URL del repository GIT, ovvero https://github.com/Microsoft/winsdkfb
    2. Nel secondo campo, la cartella sul vostro disco nella quale volete creare una copia del progetto
  4. A questo punto premete il pulsante Clone e Visual Studio creerà una copia locale del progetto sul vostro computer. In qualsiasi momento, potrete accedere, sempre da Team Explorer, al repository e alla sezione Sync, che vi permetterà di sincronizzare la copia locale con quella presente su GitHub, dandovi così la possibilità di scaricare eventuali aggiornamenti.

 

 

Ora che avete una copia locale della libreria, potete aggiungerla alla soluzione che contiene la vostra Windows Store app. Fate clic, perciò, con il tasto destro in Solution Explorer sulla soluzione e scegliete Add -> Existing Project.

Dovrete aggiungere il progetto:

  • FBWinSDK\FBSDK-UWP\FBSDK-UWP\FBSDK-UWP.vcxproj nel caso in cui stiate sviluppando una Universal Windows app per Windows 10. In tal caso, il progetto compilerà solo con Visual Studio 2015 e l'SDK di Windows 10 installata.
  • FBWinSDK\FBWinSDK\FBWinSDK.Windows\FBWinSDK.Windows.vcxproj nel caso in cui stiate sviluppando una Windows Store app per Windows 8.1.
  • FBWinSDK\FBWinSDK\FBWinSDK.WindowsPhone\FBWinSDK.WindowsPhone.vcxproj nel caso in cui stiate sviluppando una Windows Store app per Windows Phone 8.1

A questo punto, dovreste avere una soluzione in Visual Studio molto simile alla seguente:

L'ultimo passaggio necessario è aggiungere un riferimento, nel progetto principale dell'applicazione, alla libreria: fate clic con il tasto destro sul progetto, scegliete Add reference e andate a cercare alla voce Projects l'elemento di nome Facebook.

La configurazione è completata. Ora è necessario procedere alla configurazione dell'applicazione sul portale sviluppatori di Facebook.

Registrare l'applicazione Facebook

Se ricordate quanto descritto nel primo post dedicato alla vecchia libreria Facebook .NET, l'integrazione di un'applicazione con Facebook richiede la configurazione della stessa su un portale apposito gestito dal social network. Ad ogni applicazione web, desktop o mobile, infatti, deve corrispondere un'applicazione sul portale di Facebook: ciò è necessario per gestire la fase di autenticazione, nonchè i vari permessi per accedere alle funzionalità offerte dal social network.

L'utilizzo di questa nuova libreria non fa eccezione a questa regola: dovrete, perciò, seguire la stessa procedura descritta nel post originale, al fine di ottenere un Package SID, da includere poi alla voce Windows Store ID nella configurazione dell'applicazione sul portale sviluppatori di Facebook. Dato che la procedura rimane invariata, non riporterò nuovamente qui i passaggi.

Unica eccezione: se siete in fase di testing e, per il momento, non avete intenzione di pubblicare l'applicazione, avete la possibilitè di ottenere un Package SID di test senza dover iniziare il procedimento di pubblicazione sullo Store. Tale SID si ottiene tramite una API del Windows Runtime, ovvero:

string SID = WebAuthenticationBroker.GetCurrentApplicationCallbackUri().ToString();

Vi basta, perciò, includere la riga di codice precedente nella vostra applicazione e recuperare il valore della variabile SID (mettendo un breakpoint, mostrandola a schermo, stampandola nella console di debug, ecc.). Tale SID andrà poi inserito, come descritto nel post originale, all'interno della sezione Settings dell'applicazione sul portale Facebook, alla voce Windows Store ID. E' importante ricordarsi che bisogna rimuovere il protocollo ms-app:/// dal valore ottenuto. Se, ad esempio, il metodo precedente vi restituisce il valore:

ms-app://s-1-15-2-2031376880-2039615047-2889735989-2649504141-752107641-3656655002-2863893494/

L'ID da inserire nel portale Facebook sarà il seguente:

s-1-15-2-2031376880-2039615047-2889735989-2649504141-752107641-3656655002-2863893494

Una volta completata questa procedura e configurata l'applicazione Facebook, siamo pronti per "sporcarci le mani" e scrivere un po' di codice.

Effettuare il login

Effettuare il login è un'operazione molto semplice con la nuova libreria, grazie alla classe FBSession che rappresenta una sessione di Facebook. Per iniziare la procedura di autenticazione ci servono alcune informazioni:

  1. Il Package SID, che abbiamo recuperato in precedenza
  2. L'AppId di Facebook, che possiamo recuperare dal portale sviluppatori di Facebook nella pagina principale della Dashboard (vedi immagine seguente).

  1. I permessi di Facebook che abbiamo intenzione di utilizzare. Facebook, infatti, utilizza un sistema di permessi per definire che tipo di interazioni con il social network può effettuare un'applicazione. Si va da quelli base (come recuperare le informazioni sull'utente collegato o la lista degli amici) a quelli più avanzati (come fare il like di una pagina, pubblicare un post o una foto sulla timeline dell'utente, ecc.). A questo indirizzo trovate l'elenco di tutti i permessi disponibili: https://developers.facebook.com/docs/facebook-login/permissions/v2.4#reference E' importante sottolinare però che, come comportamento predefinito, Facebook fornisce ad un'applicazione solo una serie di permessi base, ovvero:
    1. email, per accedere alla mail con cui è registrato l'utente
    2. public_profile, per accedere alle informazioni pubbliche del profilo dell'utente
    3. user_friends, per accedere all'elenco degli amici che stanno utilizzando anch'essi la vostra applicazione

    Qualsiasi altro permesso (come publish_actions, che vi da la possibilità di pubblicare contenuti sulla timeline dell'utente), richiede che la vostra applicazione Facebook superi una fase di revisione, nella quale dovrete dettagliare le motivazioni e i casi d'uso per i quali avete la necessità di usare questi permessi. Si tratta di un processo di validazione gestito da Facebook e indipendente dalla certificazione dell'applicazione Windows sullo Store. Trovate maggiori dettagli all'indirizzo https://developers.facebook.com/docs/apps/review

     

Ecco un esempio di codice completo di login:

private async void OnLoginClicked(object sender, RoutedEventArgs e)

{

string SID = WebAuthenticationBroker.GetCurrentApplicationCallbackUri().ToString();

string AppId = "858381294217135";

 

FBSession session = FBSession.ActiveSession;

session.FBAppId = AppId;

session.WinAppId = SID;

session.AddPermission("public_profile");

 

FBResult result = await session.LoginAsync();

if (result.Succeeded)

{

//user is logged in

}

}

Innanzitutto si recupera un riferimento alla sessione corrente, tramite la proprietà ActiveSession della classe FBSession. Dopodichè, il SID e l'AppId di Facebook vengono valorizzati, rispettivamente, usando le proprietà WinAppId e FBAppId. Infine, i permessi vengono aggiunti con il metodo AddPermission(), che richiede come parametro l'identificativo del permesso, secondo la tabella già segnalata in precedenza. Nell'esempio, richiediamo il permesso di tipo public_profile, che ci da accesso alle informazioni pubbliche dell'utente.

Il login viene effettuato chiamando il metodo LoginAsync(): a questo punto, l'applicazione mostrerà un flyout (il cui contenuto è gestito direttamente da Facebook) in cui l'utente dovrà inserire le proprie credenziali, come nell'immagine seguente.

Una volta che l'utente ha completato l'operazione, vi verrà restituto un oggetto di tipo FBResult con l'esito dell'operazione. Nello specifico, tramite la proprietà Succeded potrete scoprire se l'operazione è andata a buon fine oppure no (ed, eventualmente, scoprire tramite la proprietà ErrorInfo cosa è andato storto).

Mostrare il profilo dell'utente

La classe FBSession contiene una proprietà di nome User che, una volta che il login è stato completato con successo, viene valorizzata con le informazioni sull'utente collegato. La maggior parte delle proprietà esposte sono di facile comprensione e vi permettono di recuperare le informazioni del profilo Facebook che l'utente ha scelto di rendere pubbliche, come Name (il nome e cognome), Gender (il sesso), Location (la sua posizione), ecc.

Una funzionalità interessante è che la libreria contiene un controllo già pronto per mostrare l'immagine del profilo dell'utente. Il controllo si chiama ProfilePictureControl ed è incluso nel namespace Facebook, che dovete dichiarare nell'intestazione della pagina, come nell'esempio seguente:

<Page

x:Class="Windows10.MainPage"

xmlns:facebook="using:Facebook"

mc:Ignorable="d">

 

<facebook:ProfilePictureControl x:Name="Profile" Width="300" Height="300" />

 

</Page>

 

Una volta inserito il controllo nella pagina, potrete mostrare l'immagine del profilo semplicemente valorizzando la proprietà UserId del controllo con l'id Facebook dell'utente, che potete recuperare dalla classe FBUser vista in precedenza. Ecco un esempio completo di login che, in caso di successo, mostra alcune informazioni dell'utente, inclusa l'immagine del profilo:

private async void OnLoginClicked(object sender, RoutedEventArgs e)

{

string SID = WebAuthenticationBroker.GetCurrentApplicationCallbackUri().ToString();

string AppId = "858381294217135";

 

session = FBSession.ActiveSession;

session.FBAppId = AppId;

session.WinAppId = SID;

session.AddPermission("public_profile");

 

FBResult result = await session.LoginAsync();

if (result.Succeeded)

{

FBUser user = session.User;

UserName.Text = user.Name;

UserId.Text = user.Id;

Profile.UserId = user.Id;

}

}

 

Mostrare delle dialog

Facebook offre il concetto di dialog, ovvero dei flyout che la vostra applicazione può mostrare per demandare al social network alcune operazioni che, normalmente, richiederebbero per motivi di sicurezza dei permessi avanzati.

L'SDK di Facebook supporta due tipologie di dialog:

  • Feed dialog, per pubblicare un contento sulla timeline dell'utente. Si richiama con il metodo ShowFeedDialog().
  • Request dialog, per invitare altre persone ad usare la vostra applicazione (questa funzionalità è disponibile solo se la vostra applicazione, sul portale di Facebook, è stata inserita nella categoria Games). Si richiama con il metodo ShowRequestsDialog().

Entrambe le tipologie di dialog sfruttano lo stesso approccio:

  1. Si definiscono i parametri di configurazione, tramite la classe PropertySet
  2. Si chiama il metodo dell'SDK che mostra la dialog, passando i parametri definiti nel punto precedente
  3. Anche in questo caso, una volta che l'utente ha terminato di interagire con la dialog viene restituito un oggetto di tipo FBResult, che ci permette di determinare l'esito dell'operazione.

Nell'esempio seguente utilizziamo il metodo ShowFeedDialog() per consentire all'utente la pubblicazione di un link sulla sua timeline:

private async void OnPostClicked(object sender, RoutedEventArgs e)

{

FBSession session = FBSession.ActiveSession;

if (session.LoggedIn)

{

PropertySet parameters = new PropertySet();

parameters.Add("title", "MSDN Italy blog");

parameters.Add("link", "http://blogs.msdn.com/b/italy/");

parameters.Add("description", "Il blog ufficiale di MSDN Italia");

 

FBResult result = await session.ShowFeedDialog(parameters);

string message;

if (result.Succeeded)

{

message = "Succeded";

}

else

{

message = "Failed";

}

 

MessageDialog dialog = new MessageDialog(message);

await dialog.ShowAsync();

}

}

Dato che, in questo caso, presumiamo che l'utente abbia già fatto login, non ripetiamo nuovamente tutta la procedura vista in precedenza. Ci limitiamo, per scrupolo e per evitare errori imprevisti, a recuperare un riferimento alla sessione corrente (tramite la proprietà ActiveSession della classe FBSession) e a verificare che la proprietà LoggedIn sia uguale a true.

Nell'esempio possiamo vedere il funzionamento della classe PropertySet: si tratta semplicemente di un contenitore di coppie chiave / valore, all'interno del quale inserire i vari parametri necessari per la richiesta. Nello specifico, per consentire la pubblicazione di un link, ci servono tre parametri:

  • title, con il nome del sito
  • link, con l'URL del sito
  • description, con una descrizione testuale

L'oggetto di tipo PropertySet viene poi passato come parametro al metodo ShowFeedDialog() che si fa carico di mostrare all'utente la schermata di condivisione, come nell'immagine seguente.

 

 

Una volta che l'utente ha completato la condivisione, siamo in grado di determinare l'esito dell'operazione. Un caso tipico di errore è la chiusura, da parte dell'utente, della finestra di dialogo o la pressione del pulsante Cancel per annullare l'operazione.

Interagire con le Graph API

Uno degli utilizzi più frequenti dell'SDK di Facebook è l'interazione con le Graph API, ovvero un set di API REST che Facebook mette a disposizione per effettuare le operazioni più comuni con i servizi offerti dal social network e che trovate documentate all'indirizzo https://developers.facebook.com/docs/graph-api

Come per la maggior parte dei servizi moderni, si tratta di un insieme di API REST che comunicano sfruttando il formato JSON e i principali comandi del protocollo HTTP, come GET o POST. I vari endpoint delle Graph API sono dei normalissimi URL. Ad esempio, per accedere alle informazioni sul proprio profilo si usa l'endpoint /me e una chiamata di tipo GET. Oppure, se volessimo pubblicare un contenuto sulla timeline dell'utente, dobbiamo usare l'endpoint /{user-id}/feed e una chiamata di tipo POST.

La nuova SDK di Facebook offre una serie di metodi che semplificano l'integrazione con queste API e permettono di lavorare con classi e oggetti, anzichè direttamente con il formato JSON. Attenzione che, come ricordato in precedenza, molte di queste API richiedono dei permessi speciali da parte di Facebook, che sono ottenibili solo dopo aver superato un processo di review.

Per questo motivo, per il prossimo esempio, vi mostrerò un altro approccio per recuperare le informazioni sul profilo dell'utente: invece di usare la classe FBUser, recupereremo manualmente i dati tramite le Graph API. Ovviamente, si tratta di un esempio puramente didattico: nella realtà, è consigliato utilizzare la classe FBUser, molto più semplice e immediata. Questo approccio ci permette però di dimostrare in maniera semplice l'interazione con le Graph API senza la necessità di avere permessi speciali: è sufficiente, infatti, utilizzare il permesso public_profile per recuperare questa informazione.

Il punto di partenza è la creazione di una classe che rappresenti la risposta in JSON dell'API che vogliamo utilizzare. Potete fare riferimento alla documentazione delle Graph API: non è necessario che tutte le proprietà siano mappate, è sufficiente definire quelle che vi servono realmente. Ad esempio, nel nostro scenario, dobbiamo utilizzare l'endpoint /me per recuperare il profilo dell'utente collegato. In base alla documentazione, tale servizio ci restituisce un JSON con le proprietà descritte in questa pagina: https://developers.facebook.com/docs/graph-api/reference/user

Nel nostro caso, siamo interessati solamente al nome e all'id dell'utente: di conseguenza, è sufficiente creare una classe che abbia queste due proprietà. E' importante che abbiano lo stesso nome di quelle riportate nella documentazione, come nell'esempio seguente:

public class Profile

{

public string Name { get; set; }

 

public string Id { get; set; }

}

Tale classe ci servirà per gestire la deserializzazione del JSON, ovvero la procedura che si farà carico, in automatico, di convertire il JSON restituito dal servizio Facebook (che è un dato "piatto", di tipo testuale) in un oggetto che possiamo manipolare all'interno dell'applicazione.

Il passaggio successivo è quello di definire un metodo statico all'interno della classe, che riceverà in ingresso il JSON di risposta e restituirà l'oggetto deserializzato. Questo approccio è indispensabile per poter usare correttamente le API fornite dall'SDK di Facebook. Per aiutarci in questo compito, sfruttiamo la libreria JSON.NET, disponibile su NuGet e installabile facendo clic con il tasto destro sul vostro progetto e scegliendo la voce Manage NuGet Packages. L'identificativo della libreria è il seguente http://www.nuget.org/packages/Newtonsoft.Json/

Nota bene! L'ultima versione stabile della libreria è la 7.0.1 ma, quando utilizzata in una Universal Windows app, potrebbe darvi un errore di compilazione, lamentando la mancanza della libreria System.Runtime.Serialization. Il workaround, per il momento, è di fare un downgrade ed installare la versione 6.0.8.

Ecco come appare la definizione della classe Profile al termine del nostro lavoro:

public class Profile

{

public static Profile FromJson(string jsonText)

{

Profile profile = JsonConvert.DeserializeObject<Profile>(jsonText);

return profile;

}

 

public string Name { get; set; }

 

public string Id { get; set; }

}

Il metodo statico FromJson() non fa altro che ricevere in ingresso il dato JSON restituito da Facebook e di deserializzarlo, convertendolo in un oggetto di tipo Profile tramite il metodo DeserializeObject<T> della classe JsonConvert.

Ora che abbiamo definito questo metodo, possiamo utilizzarlo per interagire con le Graph API, come nell'esempio seguente:

private async void OnGetInfoClicked(object sender, RoutedEventArgs e)

{

string endpoint = "/me";

FBSingleValue value = new FBSingleValue(endpoint, null, Entities.Profile.FromJson);

FBResult result = await value.Get();

if (result.Succeeded)

{

Profile profile = result.Object as Profile;

string name = profile?.Name;

MessageDialog dialog = new MessageDialog(name);

await dialog.ShowAsync();

}

}

La comunicazione avviene tramite la classe FBSingleValue, che in fase di inizializzazione richiede tre parametri.

  1. L'endpoint delle Graph API da utilizzare (in questo caso, /me)
  2. Eventuali parametri di input, tramite un oggetto di tipo PropertySet (che abbiamo visto in precedenza). In questo caso, l'endpoint /me non richiede alcun parametro di configurazione, quindi possiamo passare null.
  3. Un riferimento al metodo statico che abbiamo definito in precedenza per effettuare la deserializzazione della risposta JSON.

Una volta inizializzato l'oggetto, la classe FBSingleValue espone un metodo asincrono per ogni principale comando HTTP. In questo caso, l'endpoint /me richiede una chiamata di tipo GET, perciò utilizziamo il metodo Get(): ci verrà nuovamente restituito un oggetto di tipo FBResult, con il risultato dell'operazione. Se avessi voluto invece, ad esempio, pubblicare un post sulla timeline dell'utente, sarebbe stata una chiamata di tipo POST: in questo caso, avremmo usato il metodo Post().

Se è andato tutto a buon fine, all'interno della proprietà Object troveremo la risposta del servizio già deserializzata: nel nostro caso, si tratta di un oggetto di tipo Profile. Nell'esempio, ci limitiamo a mostrare all'utente il nome dell'utente.

Nota bene: avrete notato, all'interno del codice, l'utilizzo della sintassi profile?.Name per recuperare il nome dell'utente. Si tratta di una delle nuove funzionalità introdotte in C# 6, che semplifica la gestione di potenziali valori nulli quando lavoriamo come un oggetto. Nell'esempio, il cast della proprietà Object al tipo Profile potrebbe fallire e, di conseguenza, la variabile profile essere uguale a null. In tal caso, la riga successiva darebbe un errore, perchè tenteremmo di accedere ad una proprietà di un oggetto non inizializzato. L'utilizzo del punto interrogativo dopo il nome della variabile fa sì che, in automatico, il codice non venga eseguito nel caso in cui questa sia nulla.

In conclusione

Nel corso di questo post abbiamo visto un'introduzione all'utilizzo della nuova libreria per integrare Facebook nelle vostre applicazioni. L'esempio mostrato nel corso del post è relativo ad una Universal Windows app per Windows 10, ma lo stesso approccio si può utilizzare all'interno di un'applicazione per Windows 8.1 e Windows Phone 8.1.

Potete scaricare il progetto di esempio per Windows 10 dal mio repository GitHub all'indirizzo: https://github.com/qmatteoq/FacebookSDKSample

Se, invece, volete contribuire allo sviluppo della libreria, segnalare eventuali problemi o leggere la documentazione ufficiale, potete fare riferimento al repository ufficiale: https://github.com/Microsoft/winsdkfb

Happy coding!


read full article

Universal Smooth Streaming Client SDK e Player Framework per Windows 10

E-mail Stampa PDF

In vista dell'imminente rilascio di Windows 10 il 29 luglio e del corrispondente SDK per lo sviluppo di app per la nuova Universal Windows Platform, abbiamo rilasciato la versione Windows 10 del Microsoft Universal Smooth
Streaming Client SDK
 e del Player Framework.

Le funzionalità principali del nuovo SDK sono:

  • X86, x64, and ARM platform support
  • On-demand Playback (Play, Pause, Seek, Stop)
  • Live with Seeking capabilities (Play, Pause, Seek, Go to Live)*
  • Support for video codecs – H.264, VC-1
  • Support for Audio codecs – AAC, Dolby DD+, WMA Pro
  • Multiple audio languages switching with APIs*
  • Track-selection for playback (for example, restrict the available bitrates)*
  • Offline playback scenarios via Downloader Plugin*
  • Text and Sparse Track APIs*
  • Content protection – Microsoft PlayReady integration
  • Trickplay (slow motion, fast-forward, and rewind)
  • Microsoft PlayReady Key rotation

Il Player Framework invece è stato aggiornato alla versione 3.0 per permettere di "mantenere" alcune feature delle versioni precedenti che non sono ancora state integrate nativamente in Windows 10. A tendere, quando tutte le funzionalità del Player Framework saranno native in Windows 10, verrà via via dismesso. A breve verranno rilasciate le guideline su come effettuare questa migrazione.


read full article

Guest post: Il nuovo binding di Windows 10

E-mail Stampa PDF

Questo post è stato scritto da Matteo Pagani, Support Engineer in Microsoft per il programma AppConsult

Una delle novità principali della Universal Windows Platform di Windows 10 è l’introduzione di una serie di nuove markup expression, che faranno la gioia di tutti gli sviluppatori che si affidano alle potenzialità dello XAML nello sviluppo delle loro applicazioni.
Tali markup expression permettono, infatti, di ottimizzare notevolmente le performance nel rendering dello XAML e di rendere l’interfaccia utente delle nostre applicazioni ancora più fluida e reattiva.
Vediamole in dettaglio.

 

x:Bind – Un nuovo modo per gestire il binding

Il binding è sicuramente una delle funzionalità più potenti dello XAML, la quale permette di creare un canale di comunicazione (anche bidirezionale) tra i controlli presenti nell’interfaccia utente e gli oggetti presenti nel nostro codice. In questo modo, grazie alle dependency property e all’interfaccia INotifyPropertyChanged, non dobbiamo preoccuparci di aggiornare manualmente l’interfaccia grafica: ogni qualvolta andremo a modificare gli oggetti nel nostro codice, i controlli ad essi collegati si aggiorneranno di conseguenza.

Ecco un esempio di binding utilizzando la sintassi standard:

 

<TextBlock Text="{Binding Path=Message}" />

 

 

Questo codice di esempio mostra la proprietà Text di un controllo TextBlock collegata ad una proprietà di nome Message definita nel nostro codice e, più precisamente, nella classe che è definita come DataContext della nostra pagina.

Questo tipo di binding, però, ha due svantaggi:

  1.  Performance: il binding, dietro le quinte, sfrutta il meccanismo della reflection. Questo ha un costo a livello di performance, dato che ogni espressione viene valutata a runtime.
  2.  Gestione degli errori: dato che il binding viene risolto a runtime, eventuali errori non vengono evidenziati in fase di compilazione. Nell’esempio precedente, se la proprietà di nome Message non esistesse, ce ne accorgeremmo solo eseguendo l’applicazione, in quanto il controllo TextBlock sarebbe vuoto.

Windows 10 introduce una nuova espressione di binding che risolve entrambi i problemi, dato che è in grado di generare codice fortemente tipizzato in fase di compilazione. In questo modo, si otterrà sia un guadagno di performance (dato che il binding non deve essere valutato a runtime), sia una migliore gestione degli errori (dato che eventuali problemi verranno evidenziati immediatamente in fase di compilazione).

La nuova markup expression si chiama x:Bind e va a sostituire la parola chiave Binding, come nell’esempio seguente:

 

<TextBlock Text="{x:Bind Path=Message}" />

 

 

C’è però una importante considerazione da fare: dato che l’espressione di binding viene a tutti gli effetti compilata, la proprietà non viene più cercata all’interno del DataContext, ma direttamente all’interno del code behind. Se volete approfondire l’argomento, vi consiglio la lettura di questo post a cura di Nick Randolph, MVP Microsoft, che tratta in maniera dettagliata il funzionamento, dietro le quinte, di questa nuova espressione.
Di conseguenza, lo XAML dell’esempio precedente, per funzionare correttamente, richiede la definizione di una proprietà di nome Message all’interno del code-behind della pagina, come nell’esempio seguente:

 

public sealed partial class StandardBinding : Page

    public StandardBinding() 
   
        this.InitializeComponent();
        Message = "Hello from the new x:Bind expression!"
    }

 

    publicstring Message { get; set; } 
}


Un’altra importante differenza rispetto al binding tradizionale è che, come impostazione predefinita, viene applicata la modalità di aggiornamento OneTime: questo significa che, una volta effettuato il binding, eventuali modifiche alla proprietà non saranno più recepite dal controllo. Se abbiamo bisogno di mantenere aggiornata la proprietà nel corso dell’esecuzione dell’applicazione, dovremo perciò ricordarci di impostare manualmente la modalità OneWay o TwoWay (in caso di comunicazione bidirezionale), come nell’esempio seguente:

 

<TextBlock Text="{x:Bind Path=Message, Mode=OneWay }" />

 

 

x:Bind ed eventi

Una importante novità della nuova markup expression è che consente il binding non solo di proprietà, ma anche di eventi. Ciò significa che, ad esempio, possiamo gestire la pressione di un pulsante con il seguente codice XAML:

 

<Button Content="Show message" Click="{x:Bind OnShowMessageClicked}" />

 

Nel code behind, sarà sufficiente dichiarare un evento con il nome specificato nell’espressione di binding per gestire l’evento Click, come nell’esempio seguente:

 

public sealed partial class EventsBinding : Page

    public EventsBinding() 
   
        this.InitializeComponent(); 
    }

 

    public async void OnShowMessageClicked() 
    { 
        MessageDialog dialog = new MessageDialog("Hello world!"); 
        await dialog.ShowAsync(); 
    }
}

 

Questa nuova funzionalità risulta particolarmente utile quando si lavora con il pattern Model-View-ViewModel (MVVM): siamo abituati, infatti, ad usare la proprietà Command per gestire gli eventi all’interno di un ViewModel, ovvero una classe separata da quella di code behind. Tale proprietà, però, è legata solamente all’interazione primaria offerta dal controllo (ad esempio, nel caso del controllo Button, la pressione del pulsante). Se abbiamo la necessità di gestire altre interazioni (ad esempio, il drag and drop o il doppio tap) dobbiamo ricorrere ad altre strategie (come l’invio di messaggi). Questa nuova funzionalità offerta dalla markup expression x:Bind ci permette di risolvere questo problema in maniera ottimale.

 

x:Bind e Model-View-ViewModel

Gli sviluppatori abituati a lavorare con il pattern MVVM saranno sicuramente trasaliti leggendo il paragrafo precedente: dato che lo scopo del pattern è quello di favorire la separazione tra logica e UI dell’applicazione, quando si utilizza questo approccio tutte le interazioni con l’interfaccia grafica vengono gestite in una classe separata (chiamata ViewModel) e non nel code-behind, come invece richiesto dall’espressione x:Bind.

Fortunatamente, esiste una semplice soluzione: esporre il ViewModel associato alla pagina corrente come proprietà nel code-behind. Ipotizziamo di avere una pagina, il cui DataContext è associato ad uno specifico ViewModel, come nell’esempio seguente:

 

<Page
    x:Class="NewBindingSample.Views.MvvmBinding"
    DataContext="{Binding Source={StaticResource MainViewModel}}">
</Page>

 

 

Come anticipato, tramite l’espressione x:Bind non sareste in grado di accedere alle proprietà esposte dalla classe di tipo MainViewModel, perché è una classe differente da quella di code behind. La soluzione è, nel code behind della pagina, trasformare il DataContext in una proprietà pubblica della classe, come nell’esempio seguente:

 

public sealed partial class MvvmBinding : Page

    public MainViewModel ViewModel { get; set; }

 

    public MvvmBinding()
    { 
        this.InitializeComponent();
        ViewModel = this.DataContext as MainViewModel
    }
}

 

A questo punto, avrete la possibilità di sfruttare la proprietà di nome ViewModel per gestire il binding con la nuova markup expression e di accedere a tutte le proprietà esposte dal ViewModel, come nell’esempio seguente:

 

<TextBlock Text="{x:Bind Path=ViewModel.Message}"/>

 

 

x:Bind e i DataTemplate

Anche se non fate uso del pattern MVVM, c’è uno scenario in cui l’uso del binding è praticamente indispensabile: i DataTemplate. Quando dovete mostrare, ad esempio, una collezione di elementi usando un controllo ListView o GridView, dovete associare un DataTemplate alla proprietà ItemTemplate: tale template rappresenta lo XAML che sarà utilizzato per definire, a livello visuale, ogni singolo elemento della lista.

Il meccanismo con cui possiamo collegare il template con le proprietà dell’oggetto che vogliamo rappresentare è proprio il binding. Anche in questo caso possiamo affidarci alla nuova markup expression x:Bind. L’unica differenza è che, in fase di definizione del template, dobbiamo specificare qual è la classe a cui si riferisce, usando l’attributo x:DataType.

Ipotizziamo di avere una classe, come la seguente, che rappresenti una persona:

 

public class Person

    publicstring Name { get; set; } 
    publicstring Surname { get; set; }
}

 

 

Ecco come possiamo rappresentare, usando la markup expression x:Bind, una collezione di oggetti di tipo Person con un controllo ListView:

 

<Page
    x:Class="NewBindingSample.MainPage"
    xmlns:model="using:NewBindingSample.Model">

    <Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
        <ListView x:Name="PeopleList">
            <ListView.ItemTemplate>
                <DataTemplate x:DataType="model:Person">
                    <StackPanel>
                        <TextBlock Text="{x:Bind Path=Name}"/>
                        <TextBlock Text="{x:Bind Path=Surname}" />
                    </StackPanel>
                </DataTemplate>
            </ListView.ItemTemplate>
        </ListView>
    </Grid>

</Page>

 

Potete notare come, tra i namespace della pagina XAML, ne sia stato aggiunto uno nuovo di nome model, che punta al namespace della classe Person. Dopodichè, nella definizione del DataTemplate usato per la lista, abbiamo specificato l’attributo x:DataType, indicando che tale template sarà utilizzato per rappresentare un oggetto di tipo Person.

 

x:Bind e i Resource Dictionary

Quando si lavora con un’applicazione complessa, ricca di stili e template, risultano molto utili i Resource Dictionary, ovvero dei file XAML contenuti nel progetto in cui è possibile dichiarare le risorse che si vogliono utilizzare all’interno dell’applicazione. In questo modo, si evita di appesantire e di rendere poco leggibile il codice XAML delle pagine vere e proprie.

Se però, provaste ad usare le nuove markup expression all’interno di un normale Resource Dictionary (creato utilizzando l’omonimo template in Visual Studio) otterrete una serie di errori difficili da decifrare. Il motivo è che, come abbiamo imparato nei paragrafi precedenti, la markup expression x:Bind è legata al code behind, all’interno del quale il compilatore va a cercare le risorse per generare il codice necessario. Un Resource Dictionary, invece, è un file XAML sprovvisto di code behind, proprio perché non contiene alcuna logica.

La soluzione è quella di creare un Resource Dictionary che, analogamente ad una pagina, abbia una corrispettiva classe di code behind. Purtroppo, però, Visual Studio non offre, al momento, un template specifico per questo scenario. Il workaround è quello di creare una nuova pagina e poi modificarla per comportarsi come un Resource Dictionary. Vediamo come fare.

Il primo passo è quello di aggiungere un nuovo elemento al proprio progetto: nella lista dei template disponibili, scegliamo Blank page. A questo punto, dobbiamo cambiare il tipo base del file da Page a ResourceDictionary, come nell’esempio:

 

<ResourceDictionary
    x:Class="NewBindingSample.Styles.Templates"
    xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation
    xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml
    xmlns:local="using:NewBindingSample.Styles"
    xmlns:d=http://schemas.microsoft.com/expression/blend/2008
    xmlns:model="using:NewBindingSample.Model"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006">

 

    <DataTemplate x:DataType="model:Person" x:Key="PeopleTemplate">
        <StackPanel Orientation="Horizontal">
            <TextBlock Text="{x:Bind Path=Name}" Margin="0, 0, 5, 0" />
            <TextBlock Text="{x:Bind Path=Surname}"/>
        </StackPanel>
    </DataTemplate>

</ResourceDictionary>

 

Il secondo passaggio è quello di cambiare la classe base nel code behind: come impostazione predefinita, infatti, le pagine ereditano dalla classe Page, mentre nel nostro caso deve ereditare dalla classe ResourceDictionary, come nell’esempio seguente.

 

public sealed partial class Templates : ResourceDictionary

   public Templates() 
   { 
       this.InitializeComponent(); 
   } 
}


Il terzo e ultimo passaggio è registrare il Resource Dictionary come risorsa globale nell’applicazione. Anche in questo caso si utilizza un approccio differente da un dictionary tradizionale: è necessario registrare la classe stessa, al posto di usare il tag ResourceDictionary, come nell’esempio seguente.

 

<Application
    x:Class="NewBindingSample.App"
    xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation
    xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml
    xmlns:templates="using:NewBindingSample.Styles"
    RequestedTheme="Light">

    <Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <templates:Templates />
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </Application.Resources>

 

</Application>

 

 

Si definisce un nuovo namespace nello XAML, che punta alla classe che funge da Resource Dictionary, e lo si utilizza per includere una nuova istanza della stessa all’interno della proprietà MergedDictionaries del controllo ResourceDictionary. In questo modo, diventa possibile accedere ai DataTemplate definiti all’interno del Resource Dictionary come se fossero dei normali stili, ovvero sfruttando la markup extension StaticResource, come nell’esempio seguente:

 

<ListView ItemTemplate="{StaticResource PeopleTemplate}" x:Name="PeopleList" />

 

 

Ottimizzare il caricamento: la markup expression x:Phase

Un’altra interessante novità introdotta nello XAML è la possibilità di definire l’ordine di caricamento dei controlli presenti nella pagina. In questo modo possiamo dare priorità a quelli più semplici e veloci da caricare, così da dare all’utente una migliore impressione di fluidità e reattività. Tale risultato si ottiene con una nuova markup expression di nome x:Phase, che è strettamente collegata a x:Bind: è possibile, infatti, utilizzarle solamente in combinazione; non è possibile utilizzare x:Phase se nessuna delle proprietà del controllo viene valorizzata tramite binding.

Implementarla è molto semplice, è sufficiente valorizzare la proprietà x:Phase del controllo con un numero ordinale, che rappresenta l’ordine di caricamento. Ecco un esempio:

 

<DataTemplate x:DataType="model:Person">
    <Grid>
        <Image Source="{x:Bind Path=Image}" x:Phase="2" VerticalAlignment="Bottom" Stretch="UniformToFill" />
        <Border Background="Gray" Opacity="0.8" Height="100" VerticalAlignment="Bottom">
           <TextBlock Text="{x:Bind Path=Name}" Foreground="White" FontSize="30" Margin="19, 0, 0, 19"
            VerticalAlignment="Bottom" x:Phase="1"/>
        </Border>
    </Grid>
</DataTemplate>

 

 

Questo DataTemplate, il cui scopo è quello di mostrare il dettaglio di una persona, include due informazioni, un’immagine e il nome, entrambe valorizzate tramite l’espressione x:Bind. Sfruttando la nuova proprietà x:Phase, siamo in grado di specificare che il nome della persona debba essere caricato prima dell’immagine. In questo modo, anche se il caricamento delle immagini dovesse richiedere parecchio tempo (ad esempio, perché sono pubblicate su un server remoto), l’utente avrebbe comunque la possibilità di vedere la lista e i nomi delle persone presenti nella collezione.

 

In conclusione

Nel corso di questo post abbiamo visto alcune delle potenzialità delle nuove markup expression introdotte nella Universal Windows Platform di Windows 10. Potete trovare diversi esempi di queste nuove espressioni (insieme a molti altri) su GitHub all’indirizzo https://github.com/qmatteoq/Windows10-Samples

 

 


read full article

Pagina 2 di 49

 
 
 
 
Certificazioni