Sviluppare Metro style app per Windows 8 in WinRT con Visual Studio 11
Attenzione: questo articolo contiene contenuti dedicati ad una versione non definitiva. Le informazioni contenute potrebbe variare in seguito al rilascio della versione definitiva.
Nell'articolo introduttivo a Windows 8 si sono viste le principali caratteristiche della prossima versione del sistema operativo Microsoft. L'introduzione di WinRT è la base per lo sviluppo di una nuova tipologia di applicazioni di nome Metro style app, che sono caratterizzate prima di tutto da un nuovo tipo di interfaccia, Metro per l'appunto, ma che in realtà porta con sé un nuovo modo di mostrare le informazioni e di pensare le applicazioni, facendole lavorare tra di loro.
Lo scopo di questo nuovo genere di app è di mettere al centro l'esperienza dell'utente, rendendo più facile l'interfaccia, ma anche ponendo limiti e regole che gli sviluppatori devono rispettare. Il nuovo framework, infatti, è ripensato per rispecchiare l'evoluzione della programmazione, introducendo un modello object oriented, con nuove o riviste API, è implementato con codice nativo per essere il più performante possibile, ed è utilizzabile potenzialmente da qualsiasi framework di sviluppo.
Tra le innovazioni introdotte con Windows 8 c'è infatti la possibilità di usare o creare projection che permettano a qualsiasi linguaggio e motore di rendering di usare WinRT per accedere alle funzionalità di Windows 8, senza alcuna differenza tra lo strumento scelto, se non nell'abilita del programmatore o del team che deve scegliere e usare tale strumento.
Microsoft di queste projection, ne implementa nativamente tre: per C++, C#/VB e JavaScript; per supportare lo sviluppo con queste tecnologie è disponibile una nuova versione dello strumento principale per Windows: Visual Studio. In questo articolo si vuole quindi introdurre la nuova versione 11 per capire, a seconda dell'ambiente su cui si è orientati, come muovere i primi passi.
Panoramica sul Windows Runtime
Come anticipato, Windows Runtime (WinRT) è il nuovo set di API che si ha a disposizione per sviluppare Metro style app. Indipendentemente dal linguaggio che si vuole sviluppare, è la base che si deve conoscere per interagire con il sistema, con le periferiche, con la rete e con l'interfaccia.
Questo nuovo runtime nasce dall'esperienza maturata negli anni e si affianca alle Win32 API, come user32.dll, gdi32.dll o kernel32.dll, che sono ancora presenti per l'ambiente desktop. Queste nuove API sono però al passo con i tempi perché non più in C-style, ma si può dire in .NET Framework style, perché orientate agli oggetti, suddivise in namespace, con tanto di eventi, generics e metadati. Quest'ultimi sono rappresentati da file con estensione .winmd che si possono trovare in %windows%\system32 (o SysWOW64) e rispettano lo standard CLI per la descrizione dei tipi e dei rispettivi membri. Sono quindi del tutto simili a un assembly .NET (una dll), ma non è presente il codice implementativo; si possono quindi guardare e analizzare con tool come ILdasm, .NET Reflector o ILSpy.
Sebbene i metadati e le API siano molto simili al .NET Framework, gli oggetti non sono implementati con codice managed, ma in codice nativo compilato in modo specifico per ogni piattaforma x86, x64 e ARM a seconda delle CPU che dispone. La ricerca e la creazione degli oggetti avviene mediante un sistema molto simile a COM, basato quindi su GUID salvati nel registro di sistema, dove vi sono le interfacce, gli oggetti e il riferimento a dove localizzare la dll. Se in passato COM è stato causa di sgradevoli esperienze o ha rappresentato instabilità e conflitti in Windows, tanto da far sperare che potesse essere rimpiazzato dal .NET Framework, in realtà in WinRT queste problematiche sono state notevolmente circoscritte.
I problemi di COM erano e sono sostanzialmente dovuti alla poca facilità per il programmatore nel farne uso o nel sviluppare nuovi componenti, incappando spesso in problemi di reference counting, conflitti di versione e sovrappopolamento del registro di sistema. Grazie alle projection però, il reference counting è gestito interamente dal CLR, per quanto riguarda C# e VB, dall'engine di JavaScript, e da template ATL o da una variante del linguaggio per quanto riguarda C++. I conflitti di versione sono poi facilmente risolti perché non è più possibile creare componenti di sistema, ad eccezioni del WinRT stesso che è gestito da Microsoft. Ogni Metro style app ha quindi le proprie dipendenze che, ormai con le grande capacità dei dischi, potrebbero essere replicate tra app differenti, ma dando la certezza di non trovarsi con dll diverse con versioni identiche o viceversa. Infine, la registrazione e la deregistrazione del componente è gestita da Microsoft stessa attraverso l'engine di deployment dello store.
Contenuti dell'articolo
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Creare un'applicazione React e configurare Tailwind CSS
Eseguire operazioni con timeout in React
Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
Migrare una service connection a workload identity federation in Azure DevOps
Eseguire attività con Azure Container Jobs
Gestire domini wildcard in Azure Container Apps
Creazione di plugin per Tailwind CSS: espandere le funzionalità del framework dinamicamente
Usare le collection expression per inizializzare una lista di oggetti in C#
Eseguire query manipolando le liste contenute in un oggetto mappato verso una colonna JSON
Sfruttare MQTT in cloud e in edge con Azure Event Grid
Sfruttare i KeyedService in un'applicazione Blazor in .NET 8
Generare token per autenicarsi sulle API di GitHub
Top Ten Articoli
- Blazor e il pattern Model-View-ViewModel
di Giampaolo Tucci - Realizzare una Progressive Web Application con Blazor e ASP.NET Core
di Giampaolo Tucci - Gestire le chiamate a servizi esterni in ASP.NET Core e Blazor tramite Polly
di Morgan Pizzini - Le novità in ASP.NET Core e Blazor con .NET 7
di Morgan Pizzini - Creare API GraphQL con ASP.NET Core e HotChocolate
di Moreno Gentili - Introduzione a Blazor WebAssembly
di Marco De Sanctis, Moreno Gentili - Usare gRPC come infrastruttura per i nostri servizi web
di Morgan Pizzini - Utilizzare scene 3D in Windows Presentation Foundation
di Marco Leoncini - Abilitare e gestire il prerendering nelle applicazioni Blazor WebAssembly
di Marco De Sanctis - Le novità di ASP.NET Core 5
di Marco De Sanctis
Articoli via e-mail
Iscriviti alla nostra newsletter nuoviarticoli per ricevere via e-mail le notifiche!
In primo piano
I più letti di oggi
- Miglioramenti nelle performance di Angular 16
- Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
- HTML5 con CSS e JavaScript
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Ottimizzazione dei block template in Angular 17
- Disabilitare automaticamente un workflow di GitHub (parte 2)
In evidenza
- Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
- Disabilitare automaticamente un workflow di GitHub (parte 2)
- Ottimizzazione dei block template in Angular 17
- Utilizzare il trigger SQL con le Azure Function
- Paginare i risultati con QuickGrid in Blazor
- Come EF 8 ha ottimizzato le query che usano il metodo Contains
- Evitare (o ridurre) il repo-jacking sulle GitHub Actions
- Definire stili a livello di libreria in Angular