Technology Experience
.NET World

[UWP] Accesso alla SD da un’app Windows 10

In giro per il web troverete tonnellate di documentazione relativa all’accesso alla SD da un’applicazione UWP. Ci sono certe cose che non mi entrano in testa, per cui mi appunto qui un po’ di cosucce interessanti.

  • La chiamata a:
    var folder = KnownFolders.RemovableDevices;
    è la porta di accesso per ottenere un riferimento alla SD
  • E’ necessario attivare la capability “Removable Storage”, altrimenti la riga sui sopra vi spara una bella System.UnauthorizedAccessException
  • Se tutto è andato bene, otterrete un oggetto simile al seguente:image
  • Come si può notare, non è la vera root della vostra SD. Per ottenere la root dell’SD dovete nuovamente richiedere l’elenco dei folder:
    var root = await folder.GetFoldersAsync().FirstOrDefault();
  • L’oggetto root potrebbe valere null nel caso in cui non sia presente alcuna SD nel dispositivo Windows 10. L’oggetto folder invece è sempre valorizzato, indipendentemente dal fatto che la SD sia presente oppure no
  • Su un PC Desktop, i dischi USB ed un eventuale lettore CD/DVD vengono visti come “Removable Storage”. In questo caso, la proprietà Name di StorageFolder vi dà la lettera del drive (esempio: “E:”).
  • Da notare che potreste avere più root SD, semplicemente per il fatto che avete più dischi removibili presenti nel sistema, e quindi avete una root per ciascun drive.
  • E’ necessario andare nel file di manifest, nella sezione “Declarations”, ed aggiungere tante voci “File Type Associations”, una per ciascun tipo di file che volete leggere/scrivere dalla scheda SD. Volete leggere i file .txt? Dovete specificarlo! Volete leggere i file .pdf? Idem come sopra!
  • Se non indicate alcun “File Type Associations” nel file di manifest, qualsiasi tentativo di lettura/scrittura vi spara una System.UnauthorizedAccessException (esempio: GetFileAsync, GetFilesAsync, CreateFileAsync)
  • Se fra le “File Type Associations” indicate i file JPG (è solo un esempio), la chiamata a GetFilesAsync() vi restituirà solamente quel particolare tipo di file, anche se sul disco ci sono altri tipi di file
  • Le operazioni sui folder (creazione, lettura, etc.) non richiedono ovviamente alcuna voce definita fra le “File Type Associations”
  • Parliamo un attimo di GetItemAsync ed affini. Questo metodo esposto da StorageFolder permette di ottenere un’istanza di IStorageItem che punta ad un file o cartella.
    Se indicate il nome di una cartella, e questa cartella esiste, tutto bene.
    Se la cartella non esiste, ottenete un’eccezione.
    Se indicate il nome di un file, e questo file esiste, deve essere dichiarato nella sezione “File Type Associations” del file di manifest.
    Se il file non esiste, ottenete un’eccezione.
  • Meglio usare TryGetItemAsync, che restituisce null nel caso in cui il file o la cartella non esiste
  • Su uno smartphone Windows 10, è possibile ottenere un ID univoco della SD:
  • var id = await sf.Properties.RetrievePropertiesAsync(
        new List<string>()
        { “WindowsPhone.ExternalStorageId” });

Direi che è tutto!

Send to Kindle
.NET World

Focus Day, tutto ciò che non vi ho detto

60 minuti erano il minimo indispensabile per raccontarvi tutto ciò che avevo da dire. Ma i blog esistono anche per questo, e quindi aprofitto del mio per integrare un po’ di contenuti.

Mi rendo conto che i contenuti di questo post sono molto a rischio, per un semplice motivo. Ognuno di noi sviluppatori vede, credo, “la sua fetta di mondo”. Uno sviluppatore Web crede che il mondo sia governato solo ed esclusivamente dal Web; crede che in giro ci siano clienti che gli chiederanno solo ed esclusivamente portali, siti ed applicazioni Web. Assolutamente falso. Ma sbaglia anche lo sviluppatore desktop che crede che in giro ci sia solo ed esclusivamente desktop. In realtà, ci sono aziende che chiedono applicazioni a tutto tondo, capaci di esistere sul desktop, sul Web, sul cloud, sul mobile. Il Web è un grande collante, è una serie di fili che collega un dispositivo all’altro. Di sicuro non esiste più un’applicazione disconnessa: un’applicazione moderna in ogni caso sincronizza i dati, si basa sul cloud, salva su OneDrive, parla con servizi esterni e remoti, e via dicendo.

Quindi, di volta in volta dobbiamo scegliere le tecnologie giuste.

Arriviamo al dunque, in merito al contenuto della mia sessione al Focus Day.

Ma se Windows Phone muore, che senso ha UWP?
UWP non è solo telefono, anzi. Il destino di Windows Phone non c’entra nulla con il destino di Universal Windows Platform. Windows Phone è destinato a morire, per il semplice fatto che Windows Phone 8 o 8.1 è destinato a morire. Gli smartphone che potranno farlo migreranno verso Windows 10. E su Windows 10 c’è e e ci sarà UWP per un bel pezzo di tempo.

Windows 10 ha una piccola fetta di mercato, che senso ha imparare/sviluppare UWP?
Non è vero. Windows 10 non ha una piccola fetta di mercato, anzi tutt’altro. Lo è se considerate solo ed esclusivamente il mondo degli smartphone. E quindi dipende dal mercato che volete o dovete seguire. Ma Windows 10 attualmente è installato su 300.000.000 milioni di PC in giro per il mondo (fonte), e cresce ogni giorno. Se dovete sviluppare un client per Windows, UWP può essere una scelta.

Ma se Microsoft dismette gli smartphone Windows 10, che senso ha UWP?
Beh, ha perfettamente senso. Se come me è circa 20 anni che sviluppate per il desktop, UWP può essere la scelta ideale. Perchè dico “può”? Perchè ad oggi UWP richiede Windows 10, e può essere benissimo che i vostri clienti – per miliardi di motivi diversi – non possano e non vogliano migrare. Se cadete in questa situazione, scegliete ovviamente WPF. Per tornare alla domande, se anche gli smartphone Windows 10 dovessero scomparire, UWP continuerebbe ad esistere, perchè UWP significa Windows 10, e Windows 10 non è solo telefoni, ma molto di più.

Ma Microsoft non potrebbe inventarsi un porting di UWP verso Android ed iOS?
Sarebbe imho una grande follia. UWP è un framework strettamente legato a feature del sistema operativo Windows. Comprende classi legate a XAML ed al suo essere vettoriale, Cortana, Live Tile, drag’n’drop, push notification, OneDrive, utilizzo della penna o della tastiera, Azure. UWP è Windows, punto. Deve essere la scelta se il sistema che dovete raggiungere è esclusivamente Windows.

Non avrebbe davvero senso affrontare un porting UWP verso altri sistemi operativi. Se il vostro obiettivo è quello di scrivere codice una volta e di eseguirlo ovunque (write once, run everywhere), Xamarin Forms DEVE essere la vostra scelta.

UWP è in diretta concorrenza con Android?
No. Android è un sistema operativo mobile per smartphone/tablet, UWP è anche questo e molto di più. UWP è solo ed esclusivamente per Windows, e raggiunge smartphone, ultrabook, desktop, IoT, HoloLens, magari in futuro le XBOX.

UWP è in diretta concorrenza con iOS?
No. iOS è il sistema operativo di Apple, che raggiunge iPhone ed iPad. Valgono le stessa considerazioni fatte per Android qui sopra.

Dovrei scegliere UWP o Xamarin?
Bella domanda. UWP è legato esclusivamente al mondo Windows. Xamarin è un framework per lo sviluppo di applicazioni mobile cross-platform (Android, iOS, Windows Phone, ed anche UWP). Scegliete UWP se il vostro cliente vi chiede esclusivamente un’applicazione per Windows desktop/mobile, da distribuire tramite gli Store (pubblico o quello For Business); consiglio spassionato: scrivete bene il vostro codice (mvvm a go-go & PCL, tanto per citare due keyword), così siete pronti a reagire al cambiamento e potete scrivere codice non totalmente relegato alla piattaforma UWP. UWP secondo me è un’ottima scelta per applicazioni business simil-desktop, nativamente mobile, e se il sistema operativo è Windows 10. Potete realizzare app che una volta avreste implementato con WPF, ma con una miriade di feature in più, come ho accennato nella mia sessione del Focus Day del 27 maggio scorso: Cortana, Live Tile, notifiche push, impostazioni in roaming, distribuzione tramite gli Store (che vi evitano deploy via ClickOnce o via file zip da scaricare), etc.

Scegliete Xamarin se dovete fare un’app consumer multi-piattaforma, quindi se dovete raggiungere, oltre alla piattaforma Windows, anche Android iOS.

Send to Kindle
Community

Windows Store Api, la mia partecipazione a DotNetPodcast

E’ con un pizzico di contentezza che vi annuncio la messa in onda della mia intervista sulle Windows Store Api sul sito della community DotNetPodcast.

Vi confesserò che sono molto contento di questa iniziativa. Ho trovato l’idea dei podcast in ambito .NET semplice e geniale allo stesso tempo. Spesso mi ritrovo in auto a guidare per raggiungere clienti o la sede del prossimo corso che devo tenere, e trascorrere un po’ di tempo con le puntate di questo bellissimo podcast è utile e divertente. Oggi il protagonista di una di queste puntate sono io, spero di tenervi compagnia anche io per qualche minuto.

image

Buon ascolto!!!!!

Send to Kindle
My daily work

Si rompe il sync di OneDrive for Business?

Utilizzo praticamente tutti i giorni il OneDrive aziendale offerto da Office 365, per condividere documenti di ogni tipo con colleghi e capi. Ovviamente, dopo un po’ di tempo la password di Office 365 va rinnovata, operazione che faccio dal portale senza alcun problema.

Peccato che il client Windows di OneDrive for Business, quello che si posiziona nella tray-bar di Windows, non reagisca come dovrebbe. Non appena cambiamo la password, infatti, sull’icona compare il classico punto esclamativo giallo, segnalando la necessità di reinserire la password per rimettere in piedi il meccanismo di sync automatico.

Ovviamente lo facciamo, ma purtroppo a volte non basta. Cercando di risolvere il problema, sullo schermo vi appare l’autenticazione di Office 365: ovviamente voi inserite le nuove credenziali aziendali. Ma questo prompt continua ad apparirvi, come se stiate inserendo credenziali non valide.

Ho trovato un’unica soluzione. Aprire il tool Gestione Credenziali di Windows e trovare l’account che ho evidenziato nel riquadro verde:

image

MicrosoftOffice16_Data:orgid:mail_aziendale_office_365

Espandete il nodo, cliccate su Modifica e reinserite le credenziali. Il problema dovrebbe sparire.

Giusto per scrupolo, date un’occhiata alla voce:

MicrosoftOffice16_Data:SSPI:mail_aziendale_office_365

Quest’ultima dovrebbe riferirsi al portale SharePoint che è dietro le quinte la condivisione dei file di Office 365 e OneDrive. Incrociamo le dita, e spero di avervi dato una mano.

Send to Kindle
VivendoByte.ByteAdventure

Il byte e l’incontro con gli Spettri

E’ una nottata frizzante e ricca di eventi, per la città. Un byte qualunque, uscendo dalla sua locazione di memoria – sospinto dal bus di trasmissione – l’avrebbe capito immediatamente. E’ come se nell’aria ci fosse uno strano fermento, una specie di energia capace di spingere tutti all’euforia. I locali erano agitati da spettacoli musicali di ogni tipo, dal rock al jazz, fino a melodie più ricercate eseguite da artisti di nicchia che intrattenevano il loro pubblico. Ciascuno dei byte poteva trovare tranquillamente il suo envinronment preferito: bastava lasciarsi trasportare dal battito del clock ed il gioco era fatto.

In uno dei tanti locali c’era stato un ritrovo di vecchi amici che, tra un boccale di sprite e l’altro, si erano raccontati con un velo di malinconia i tempi che furono. Nessuno di loro era davvero troppo vecchio, ma il loro lifetime era comunque sufficientemente ampio da far comparire stream di capelli bianchi sulle loro chiome. I più anziani venivano da vecchie console 8-bit degli anni ‘90, la cui potenza di calcolo era appena sufficiente per soddisfare le esigenze dei videogame dell’epoca, mentre i più giovani erano nati su sistemi più recenti. Uno di loro si vantava addirittura di non essere stato ancora shutdownato neppure una volta; pivello, lo definivano gli altri. Una delle fasi più importanti per la crescita di un byte è proprio quella di capire se si è un byte persistente oppure transiente. Se vivi al sicuro su un hard-disk – e quindi in grado di sopravvivere tra una sessione di lavoro e l’altra – oppure in forma più volatile allocato in memoria RAM. E questo lo puoi capire solo attraverso un processo di shutdown. Chi non lo aveva ancora capito era un pivello.

Il locale del ritrovo, il Buffer, si trovava in un array di byte, in una posizione defilata del file di swap del sistema operativo, ed era stato scelto proprio per la sua location di memoria. Grazie all’elevato livello di entropia del file .swp, i byte potevano spostarsi al suo interno senza disturbare più di tanto le celle adiacenti tenute sotto stretta sorveglianza dall’OS. Man mano che passava il tempo, i partecipanti al ritrovo tornavano nelle loro celle. Il Task Scheduler del sistema operativo era inesorabile, e consultandolo ogni byte poteva sapere quali compiti lo aspettavano il giorno dopo. Byte[739082] era stato assegnato ad un file batch non meglio identificato. Byte[90824293] sapeva che avrebbe dovuto prendere vita nel processo “SearchIndexer.exe”, e lo aspettavano montagne e montagne di file e di directory da indicizzare. Ogni byte – in un sistema che si rispetti – sa chi è e sa che cosa ci si aspetta da lui.

Alla fine rimasero solo in due, il byte ed un ammasso di classi partial. Si salutarono brindando un’ultima volta, svuotarono i bicchieri fino in fondo, poi ciascuno prese la sua strada.

Il byte uscì dal locale, felice di quella rimpatriata, ed imboccò la direzione più rapida per raggiungere il bus PCI Express che l’avrebbe condotto in pochi istanti a casa. Percorse un tratto di strada di buona lena, cadenzando il suo passo con il battito del clock per rispettare le normative vigenti. Meglio non ficcarsi nei guai a quell’ora.

Il byte non poteva sapere che sarebbero stati i guai ad andare alla sua ricerca. Girò per entrare in un vicolo buio e scuro, ai cui lati erano ammassati frammenti di memoria, messi qua e là in mezzo a sporcizia di ogni tipo. Di sicuro il Garbage Collector non passava da lì da un bel po’.

Fu allora che vide gli Spettri.

Comparvero alle sue spalle, uscendo dalle pareti, trascinandosi lentamente come fantasmi in grado di attraversare le superfici solide. Erano figure evanescenti di ogni tipo, umanoidi e non. Erano decine e decine, e si fecero largo uno alla volta fino ad occupare tutto il vicolo. Poi si voltarono verso il byte, che era rimasto pietrificato dalla visione, al punto che non riusciva a capire se si trattasse di realtà o di un brutto incubo. Non seppe cosa fare. L’istinto gli stava suggerendo di uscire dal vicolo e di darsela a gambe, dimenticando quegli esseri inquietanti. Ma qualcosa lo trattenne, e non potè fare a meno che osservarli, lottando con tutte le sue forze per rimanere lucido.

C’era un marine, armato fino ai denti, imbottito in un’uniforme da guerra tutta ammaccata. Sul casco era riportata la dicitura UAC, e questo non lasciava dubbi sulla sua origine.
C’era un tale che aveva tutta l’aria di essere uno scienziato. Un tizio piuttosto magro, che indossava soltanto una tuta lacerata ed un paio di occhiali da professore, su cui capeggiava quello che sembrava essere il suo nome: Gordon Freeman.
Poco più indietro, seduta a terra mentre consultava un’antica pergamena, c’era una giovane ragazza dalle forme prosperose, e non faceva nulla per nasconderle. Se ne andava in giro in un posto come quello indossando una semplice canottiera celeste, e shorts che mettevano in bella mostra le sue gambe. Era tutta concentrata a decifrare un simbolo che aveva un qualcosa di religioso, e non si curava di nient’altro.
C’erano membri di una sorta di famiglia reale fantasy, riconoscibili per il loro vestiario sgargiante.
C’era una bambina dai lunghi capelli neri, che in modo timido si guardava le mani senza avere il coraggio di alzare lo sguardo verso il byte o gli altri. Che fosse Alma?

C’erano altri uomini, altre donne, un androide scheletrico con al posto degli occhi due lampadine rosse.

Oltre a tutti questi personaggi, ce n’erano altri di statura più piccola. C’erano folletti e creature di varie specie. Chi strisciava, chi saltellava, chi svolazzava freneticamente. C’erano piccoli draghi, viscidi serpentelli sputafuoco, ed altri esseri a cui il byte non seppe dare un nome. C’era chi era silenzioso, e invece chi non poteva fare a meno di respirare rumorosamente.

Era un’accozzaglia di personaggi di ogni tipo, usciti in modo spettrale da chissà dove.

Ma il byte notò – nonostante il suo stato mentale alterato – che c’era qualcosa che non quadrava affatto, qualcosa di insano e di innaturale, che lo inquietava ancora di più. Quando ne fu cosciente provò una strana sensazione di terrore, un formicolio che fece tremolare la composizione di bit che lo rendevano vivo. Rimase in silenzio, e non seppe cosa fare.

Tutti quegli esseri erano emaciati ed in qualche modo perverso, anche deperiti. Erano apparsi tutti in una scala di grigi povera, con un canale alpha dai valori elevati. Il marine sembrava l’ombra di ciò che fu un tempo; sembrava debole, e non aveva affatto l’aspetto di una persona forte ed indistruttibile. Anzi, teneva le spalle ricurve su se stesso. Se il byte avesse potuto guardarlo per un attimo negli occhi, avrebbe notato che era sull’orlo di una crisi di pianto. La ragazza, nonostante il fisico impetuoso, mostrava un’età più avanzata di quella che aveva in realtà. E sembrava isterica, continuava a sistemarsi nervosamente la coda di cavallo. Grattava la pergamena continuamente con l’unghia, come se tentasse di estrarne la verità violentando la carta, per cui invece avrebbe dovuto avere soltanto rispetto. La bambina, che lui aveva battezzato Alma, sembrava la classica protagonista di un videogame horror, una di quelle dall’aspetto inquietante, disegnate appositamente per atterrire il giocatore. Teneva la testa bassa, con i capelli che nascondevano in parte il volto pallido.

Di fronte a quell’orda di creature, il byte non ebbe altra reazione se non quella di parlare.

– Chi siete? Cosa volete da me?

Prima che qualcuno rispose, passò molto tempo. Tra la folla di esseri decadenti si fece largo un mago con addosso una tunica rossa. Nella mano destra impugnava un bastone di quercia decorato con rune e simboli arcaici luminescenti. In condizioni normali sarebbe stato alto ed imponente. Adesso era davvero molto vecchio, ed era quasi trasparente. Persino il bastone sembrava sul punto di spezzarsi da un momento all’altro; era annerito, marcio e ad ogni passo che il mago faceva verso il byte, si piegava cigolando un poco. Come se si fosse autoproclamato portavoce del gruppo di creature, il mago si portò davanti a tutti, fino a raggiungere il byte.

– Siamo gli Spettri

La voce non era una sola. Era una cacofonia di voci, come se insieme al mago stessero parlando anche tutti gli altri, che però non si erano mossi di un millimetro.

– Siamo Giochi Incompleti, Giochi in disuso, Giochi Abbandonati. Siamo personaggi che i Creativi hanno abbandonati nei loro mondi, immersi nelle loro esperienze. Siamo maghi senza più un briciolo di magia, siamo un’archeologa perennemente braccata dai suoi nemici. Siamo un marine con una guerra da vincere freezata nel tempo, siamo draghi dal soffio di fuoco congelato. Siamo principesse che non verranno mai salvate, siamo gare di rally senza un vincitore. Siamo bambini senza le loro madri. Siamo palline da golf sospese in aria, senza mai sapere se saremo un par o un birdie. Siamo flotte interstellari alla deriva nello spazio profondo. Siamo esseri condannati, di ogni tipo, forma e colore.

Un respiro, un lungo istante. Un istante in cui il byte forse cominciò a capire.

– Tutte le volte che il creativo comincia un nuovo gioco, lo deve portare a termine. Altrimenti rimarremo intrappolati per sempre. Diventiamo personaggi senza scopo, esseri senzienti che vagano nel sistema senza una meta, costretti a vivere a metà, in un mondo a metà strada tra la nostra realtà virtuale e l’incubo costante. Ed alla fine diventiamo Spettri.

– Come posso aiutarvi? Cosa posso fare per voi?

In quel momento un urlo fece trasalire il byte. Fu la ragazza – probabilmente l’archeologa – ad emetterlo. Fu un grido di frustrazione, probabilmente la pergamena metteva a dura prova le sue conoscenze di lingue antiche. O forse era altro. Forse era solo la profonda disperazione per la sua condizione. Ma le voci, guidata da quello del mago, riportarono il byte alla realtà.

– Oh, sei gentile a chiederlo. Ma non puoi fare nulla. Solo il Creativo può salvarci. Deve riportarci in vita, o disinstallarci definitivamente. In queste condizioni siamo tecnicamente vivi, ma non ci sentiamo affatto come tali. Guardaci. Preferiremmo morire. Preferiremmo essere lasciati andare liberamente, e decidere del nostro destino, e di non essere imprigionati quaggiù.

– Ma allora perchè mi siete apparsi? Cosa volete che io faccia?

Di nuovo il mago attese un attimo prima di rispondere, come se avesse bisogno di pensarci.

– Oh, ecco la domanda più importante di tutte. Cosa vogliamo da te? Vogliamo divorarti, assaporarti fino all’ultimo bit. Vogliamo accedere alla tua linfa vitale, e dopo di te, divorare un altro byte, e poi un altro ancora, uno alla volta, fino a conquistare l’intero sistema. Ci sono trilioni e trilioni di byte, in questo hardware. Saranno tutti nostri. Diventeranno tutti Spettri, vagheremo tutti assieme in questo oblio fatto di dannazione.

Poi i volti si fecero famelici. Tutti, dal primo all’ultimo, alzarono lo sguardo vacuo, ed aprirono le loro bocche, mostrando denti piccoli ma aguzzi e deturpando il loro volto in una maschera. Divennero mostri a tutti gli effetti, e cominciarono ad avvicinarsi al byte, trascinando un passo dopo l’altro. Non mostrarono alcuna fretta, come se quello del byte fosse un ineluttabile destino già segnato, dal quale non poteva scappare.

Il byte si riprese ed in un attimo indietreggiò. Guardando dietro di sè, vide che nulla gli impediva di scappare via da quel posto. Ed infatti fece ciò che gli suggeriva l’istinto. Si voltò e se la diede a gambe, cercando di allontanarsi il più possibile da quelle creature. Raggiunse la fine del vicolo, dal lato opposto rispetto a quello da cui si trovava il Buffer. Tornò alla sicurezza della luce dei lampioni digitali che, con il loro bagliore vagamente #FFFFFF, lo avevano tranquillizzato un pochino. La gente che camminava sulla strada principale era poca, ciò nonostante c’era ancora qualcuno che si divertiva e che teneva fra le mani il suo drink, incurante degli esseri immondi che vivevano (o tentavano di farlo) a pochi passi da loro.

Prese un po’ di coraggio, cercando di dimenticare, scese le scale per entrare nel metrobus, così come aveva pensato di fare fin dall’inizio, ed in pochi attimi era al sicuro nella sua locazione di memoria, in uno dei registri della CPU. Si chiese dove fossero adesso gli Spettri, chi stessero divorando. Ci mise molto a prendere sonno, e fu comunque un sonno agitato e pieno di incubi.

Al suo risveglio, c’era stato un nuovo boot del sistema, ed il clock scaldava il pavimento vibrante.
Al prossimo ritrovo fra amici avrebbe avuto una storia in più da raccontare.

Send to Kindle
.NET World

Windows Store Api su GitHub

Lo scorso mese di marzo Microsoft ha reso disponibili delle API tramite le quali noi sviluppatori possiamo accedere alle informazioni conservate all’interno dei nostri account Dev Center. Le informazioni sono visibili su questa pagina del blog ufficiale di Microsoft. Con la versione attuale di queste API possiamo quindi facilmente avere accesso a:

  • App Acquisitions (i download)
  • IAP Acquisistions (gli acquisti in-app effettuati dagli utenti all’interno delle nostre app)
  • Ratings (il numero di stelline)
  • Reviews (le recensioni scritte manualmente dagli utenti)
  • App Health (ovver le app failure, le eccezioni scatenate all’interno delle nostre app)

A patto di litigare con Active Directory di Azure ed impostare il nostro Dev Center di conseguenza (guardate il link di prima per tutti i dettagli del caso), e successivamente di reperire Tenant Id, Client Id e Client Secret, possiamo effettuare chiamate http per ottenere oggetti JSON da deserializzare. Possiamo ordinare, applicare filtrare in base al tempo, etc. etc. Ed otteniamo alla fine oggetti che contengono tutte le informazioni che abbiamo richiesto in base alla API invocata.

Se si può servire, sappiate questo: come Brain-Sys abbiamo pubblicato un progetto su GitHub dedicato a questo tema. Il progetto contiene un po’ di codice open-source che dovrebbe semplificarvi un po’ il lavoro. In pratica non occorre più lavorare a basso livello con HttpClient, autenticarsi ed effettuare chiamate via http, ma c’è una libreria di classi (partendo dalla WindowsStoreApiConnector che è il cuore di tutto) molto più semplice ed efficace da utilizzare.

Oltre a tutto questo, da questa mattina trovate anche un bel pacchetto su NuGet pronto per essere utilizzato. E’ una libreria portable, per cui è utilizzabile da console, WPF, qualsiasi applicazione ASP.NET MVC, etc. etc.

Feedback sono ben accetti!

Send to Kindle
My daily work

27 Maggio: Focus Day On Developer Tools

Sono felice di annunciare che il prossimo 27 maggio (è un venerdì!) si terrà una bella giornata battezzata Focus Day On Developer Tools, organizzata da Overnet Education. Insieme a Gabriele Gaggi, Alessandro Del Sole e Mauro Servienti vi racconteremo un po’ di cose nell’orbita degli strumenti di sviluppo Microsoft, a partire ovviamente dal nostro amato Visual Studio 2015.

image

Vi racconteremo di Git & GitHub, delle grossissime novità per quanto riguarda Xamarin Forms, di tutti i nuovi strumenti dedicati ai Developer Web. Io personalmente avrò il piacere di parlarvi dello sviluppo di applicazioni con la tecnologia Universal Windows Platform, quindi del mondo Windows 10, soprattutto delle novità che sono state rese pubbliche durante l’ultima Build. Ma non solo quello.

Sulla pagina Facebook dedicata dell’evento potete dare un’occhiata all’agenda, così come anche sulla pagina ufficiale sul sito Overnet: https://overneteducation.it/DettaglioCorso.aspx?corso=EV039&v=1.

Iscrivetevi, il costo di partecipazione è davvero alla portata di tutti!!

Ci vediamo là!!!!!

Send to Kindle
.NET World

Azure Service Bus Relay, ovvero come esporre un WCF on-premise sul cloud

L’Azure Service Bus Relay (d’ora in poi ASBR) è il servizio messo a disposizione da Azure che ho scoperto più di recente, grazie al mio capo Gabriele Gaggi che me ne ha parlato chiedendomi di studiarlo & provarlo, perchè ci sarebbe stato molto utile in uno scenario che dobbiamo risolvere. Effettivamente l’ASBR è molto molto interessante, e risolve un compito piuttosto ostico, con estrema eleganza e soprattutto relativamente poco lavoro per noi sviluppatori.

A che serve? Semplificando di molto, l’ASBR permette di esporre un servizio Windows Communication Foundation (WCF), che gira on-premise in una rete LAN aziendale, direttamente sul cloud pubblico. Senza bisogno di impazzire con l’apertura di porte sul firewall, di stabilire regole di routing, o più in generale di andare ad apportare cambiamenti pericolosi nell’infrastruttura di rete aziendale.

La tipica domanda che mi viene posta è la seguente: ma se ti serve un WCF sul cloud, perchè non ne fai direttamente il deploy su Azure? Se mi fate questa domanda è perchè siete troppo web-oriented-only, e questo è decisamente male. Spesso e volentieri sono costretto ad avere un servizio WCF che gira on-premise, per diverse ragioni: per motivi di policy, e soprattutto perchè il più delle volte questo servizio deve dialogare con una periferica via USB. Di conseguenza, sono obbligato ad avere un PC server che comunica con la periferica tramite WCF (hostato in un Windows Service, per esempio), che assolve a tutta una serie di compiti (logging, monitoraggio e controllo della periferica, reportistica, etc. etc.); nel mondo moderno, però, il web non è da trascurare, e quindi questo WCF deve anche essere reso disponibile sul cloud.
ASBR serve proprio a questo, con il minor sforzo possibile.

Il tutto è contenuto in questo articolo, che ho seguito passo-passo per ottenere il risultato finale.

1) Creare un service bus su Azure
Il primo step da completare è quello di creare un service bus su Azure. Nel momento in cui vi scrivo, questa operazione non è ancora possibile con l’Azure Portal nuovo, ma dovete accedere a quello classico, disponibile all’indirizzo https://manage.windowsazure.com.

image

Nel mio caso ne ho creato uno chiamato exposedwcf. Da questo servizio bus dovete recuperare il nome (che in realtà avete scelto voi) e la primary key (chiave primaria).

2) Creare il server WCF
Ovviamente, dovete innanzitutto avere un servizio WCF che gira sul PC, allo scopo di pubblicarlo sul cloud. Come esempio, potete vedere quello che ho pubblicato sul GitHub di Brain-Sys all’indirizzo https://github.com/Brain-Sys/ASBR_Server.

Si tratta di un banale WCF hostato in una Console Application.
Il servizio WCF prevede la seguente interfaccia:

namespace ASBR_Server
{
    using System.ServiceModel;

    [ServiceContract(Namespace = "urn:ps")]
    interface IProblemSolver
    {
        [OperationContract]
        int AddNumbers(int a, int b);
    }

    interface IProblemSolverChannel :
        IProblemSolver, IClientChannel { }
}

L’interfaccia è IProblemSolver, ed espone un unico metodo AddNumbers che, con molta fantasia, prende due integer e restituisce la loro somma. L’implementazione è estremamente banale.

static void Main(string[] args)
{
    var sh = new ServiceHost(typeof(ProblemSolver));
    sh.Open();
    Console.WriteLine("Server started!!!");
    Console.WriteLine("Press ENTER to close");
    Console.ReadLine();
    sh.Close();
}

Viene create un’istanza di ServiceHost, al quale viene passata in input l’interfaccia del servizio. Poi il servizio parte, con il classico Console.ReadLine() per fare in modo che il servizio rimanga in attesa (ovviamente questo vale per una Console Application).

Da notare che nel file app.config il servizio WCF ha due endpoint. Il primo è associato ad un binding di tipo netTcpBinding, il cui url è net.tcp://localhost:9358/solver, ed è l’indirizzo che viene esposto ovviamente all’interno della LAN sulla rete on-premise. Il secondo endpoint invece utilizza un binding di tipo netTcpRelayBinding, il cui url è sb://exposedwcf.servicebus.windows.net/solver. Notare il protocollo sb://, che indica appunto l’utilizzo del service bus su Azure. Questo è l’url al quale dovranno puntare i client che raggiungeranno il servizio da remoto, e quindi al di fuori della rete aziendale, accedendoci da Azure.

Fate riferimento al repository GitHub indicato prima per tutti i dettagli del caso.

3) Creare il client WCF


L’altra faccia della medaglia è il client. Anch’esso è una banale applicazione di tipo Console.

Fate riferimento al repository https://github.com/Brain-Sys/ASBR_Client su GitHub.

In questo progetto abbiamo ripetuto la definizione dell’interfaccia IProblemSolver vista prima. Il file Program.cs fa una cosa molto molto banale.

static void Main(string[] args)
{
    Random rnd = new Random((int)DateTime.Now.Ticks);
    var cf = new ChannelFactory<IProblemSolverChannel>("solver");
    var ch = cf.CreateChannel();

    for (int i = 0; i < 1000; i++)
    {
        int a = rnd.Next(1, 100);
        int b = rnd.Next(1, 100);
        Console.WriteLine("Richiesta " + (i + 1));
        Console.WriteLine(ch.AddNumbers(a, b));
    }

    Console.ReadKey();
}

Viene aperto un canale di comunicazione verso il servizio WCF (notare che la configurazione del servizio WCF è contenuta nel file App.config, che qui non si vede). Poi viene invocato per 1.000 volte il metodo AddNumbers(a, b), chiedendo al servizio WCF di risolvere la somma e di restituirci il risultato.

Et voilà, il gioco è fatto! Il client si connette al servizio WCF via Azure. Questo significa che a costo zero (ovvero: senza toccare nulla del nostro codice), possiamo prendere un servizio WCF già pronto ed esporlo sul cloud, semplicemente aggiungendo un nuovo endpoint tramite l’ASBR.

Anche in questo caso, date un’occhiata al repository GitHub ASBR_Client indicato prima.

4) Conclusione


E’ semplice fare una prova del nove. Lanciate il servizio WCF server sul vostro PC, che si metterà in attesa di un qualche client che si connetta. Compilate il client, passatelo ad un collega o a qualcuno che sta dall’altra parte del mondo, o comunque qualcuno al di fuori della vostra LAN, e chiedetegli di lanciare il client. Il suo client raggiungerà il servizio WCF via Azure: il suo client effettuerà 1.000 richieste di AddNumbers(), che verranno risolte dal WCF che gira sul vostro PC. La stessa cosa la potete anche fare voi in locale (server & client sullo stesso PC, per capirci), ma ovviamente non avete la percezione che il WCF sia effettivamente esposto sul Web.

Ulteriori informazioni sull’Azure Service Bus sono raggiungibili qui.

Send to Kindle
My daily work

Cordova o Xamarin? Su TecHeroes una possibile risposta!

Cordova e Xamarin sono due framework che permettono la realizzazione di app mobile cross-platform. In altre parole, si tratta di strumenti che permettono ad uno sviluppatore di scrivere un’app in grado di girare successivamente sui dispositivi dei mondi Android, iOS e Windows. Più facile a scriversi che a farsi, ovviamente. Quale scegliere delle due? Quali fattori chiave dobbiamo prendere in considerazione per puntare verso l’uno piuttosto che sull’altro? Produttività? Costi? Competenze? Ambienti di sviluppo?

image

Provate a seguire questa puntata della serie TecHeroes di Microsoft Italia intitolata “Sviluppo cross-platform: Cordova vs Xamarin”, pubblicata sul canale ufficiale Channel 9 lo scorso 2 Febbraio. Il mio boss Gabriele Gaggi, insieme a Matteo Pagani ed Erica Barone di Microsoft vi intratteniranno per poco più di 30 minuti parlando proprio di Cordova e Xamarin. Purtroppo impegni di lavoro e trasferte qua e là mi hanno un po’ impedito la tempestiva segnalazione qua sul mio blog, ma meglio tardi che mai.

Buona visione!!!!

Send to Kindle
.NET WorldSoftware

Controlli UWP e DeferLoadStrategy

Questa sera qui sul mio blog linko semplicemente questo articolo che parla di Universal Windows Platform, dei suoi controlli e della possibilità di ritardare il loro caricamento tramite la proprietà DeferLoadStrategy. Quest’ultima sostanzialmente si occupa di evitare di caricare il visual tree di tutti quei panel (ma in generale è un ragionamento che si applica a tutti i controlli UWP) che soddisfano due condizioni:

  • DeferLoadStrategy = “Lazy”
  • Visibility = “Collapsed”

Davvero comodo in ottica UWP, dove sappiamo benissimo che le view devono adattarsi a diverse piattaforme e scenari. Giocando con queste nuove proprietà è possibile ottimizzare il parsing ed il caricamento dello XAML facendo in modo che il visual tree contenga solo i controlli UI previsti.

Me lo ero appuntato su Twitter, ma riportato qui sul mio blog mi risulta più comodo!

Buona lettura & Buon sviluppo!!!

Send to Kindle