Come si confronta Windows 8 Runtime (app WinRT / Windows Store / Windows 10 Universal) con Silverlight e WPF? [chiuso]

Sto cercando di capire come funziona il nuovo Windows 8 Runtime utilizzato per creare app in stile Metro . So che puoi usarlo con XAML ed è basato su .NET, quindi C # e VB.NET possono essere usati per scrivere le app, ma sembra avere qualcosa a che fare con HTML, CSS, DOM e JavaScript.

Qualcuno può spiegare di cosa si tratta in pochi paragrafi, in termini che un programmatore dell'interfaccia utente .NET può capire? (Mi manca qualcosa di "chiave" che è necessario per capirlo.)

Sappiamo tutti che WPF, Silverlight , Windows Form , ecc. Continueranno a funzionare su Windows 8 (e Windows 10) almeno su sistemi Intel, quindi per favore non dirmi che ...

Al livello più basso, WinRT è un modello a oggetti definito a livello ABI. Usa COM come base (quindi ogni oggetto WinRT implementa IUnknowne ricontatta) e costruisce da lì. Aggiunge molti nuovi concetti rispetto a COM di vecchi, la maggior parte dei quali provengono direttamente da .NET - ad esempio, il modello a oggetti WinRT ha delegati e gli eventi sono fatti in stile .NET (con delegati e aggiungi / rimuovi abbonato metodi, uno per evento) anziché il vecchio modello COM di origini e sink di eventi. Tra le altre cose degne di nota, WinRT ha anche interfacce parametrizzate ("generiche").

Un altro grande cambiamento è che tutti i componenti WinRT hanno metadati disponibili per loro, proprio come gli assembly .NET. In COM è una specie di quello con typelibs, ma non tutti i componenti COM li avevano. Per WinRT, i metadati sono contenuti nei file .winmd - guarda dentro "C: \ Programmi (x86) \ Windows Kits \ 8.0 \ Windows Metadata \" in Anteprima sviluppatore. Se cerchi, vedrai che in realtà sono assiemi CLI senza codice, solo tabelle di metadati. Puoi aprirli con ILDASM, in effetti. Nota, questo non significa che WinRT stesso sia gestito, ma semplicemente riutilizza il formato del file.

Quindi ci sono un certo numero di librerie implementate in termini di quel modello di oggetti - che definiscono le interfacce e le classi WinRT. Ancora una volta, guarda la cartella "Windows Metadata" di cui sopra per vedere cosa c'è lì; o semplicemente avvia Object Browser in VS e seleziona "Windows 8.0" nel selettore di framework, per vedere cosa è coperto. C'è molto lì e non si occupa solo dell'interfaccia utente: ottieni anche spazi dei nomi come Windows.Data.Json, o Windows.Graphics.Printing, o Windows.Networking.Sockets.

Quindi ottieni diverse librerie, che si occupano in particolare dell'interfaccia utente - per lo più si tratta di vari spazi dei nomi sotto Windows.UIo Windows.UI.Xaml. Molti di loro sono molto simili agli spazi dei nomi WPF / Silverlight - ad esempio, Windows.UI.Xaml.Controlssono strettamente corrispondenti System.Windows.Controls; idem per Windows.UI.Xaml.Documentsecc.

Ora .NET ha la possibilità di fare riferimento direttamente ai componenti WinRT come se fossero assembly .NET. Funziona diversamente dall'interoperabilità COM: non sono necessari artefatti intermedi come gli assembly di interoperabilità, è solo /run file .winmd e tutti i tipi e i relativi membri nei suoi metadati diventano visibili a te come se fossero oggetti .NET. Si noti che le stesse librerie WinRT sono completamente native (e quindi i programmi C ++ nativi che utilizzano WinRT non richiedono affatto CLR) - la magia per esporre tutta quella roba come gestita è all'interno del CLR stesso, ed è di livello abbastanza basso. Se ildasm un programma .NET che fa riferimento a un .winmd, vedrai che in realtà sembra un riferimento ad un assieme esterno - non ci sono giochi di prestigio come il tipo di inserimento lì.

Non è nemmeno una mappatura smussata: CLR tenta di adattare i tipi di WinRT ai loro equivalenti, ove possibile. Ad esempio, GUID, date e URI diventano System.Guid, System.DateTimee System.Uri, rispettivamente; Interfacce di raccolta WinRT come IIterable<T>e IVector<T>diventano IEnumerable<T>e IList<T>; e così via. Questo funziona in entrambi i modi: se si dispone di un oggetto .NET che lo implementa IEnumerable<T>e lo restituisce a WinRT, lo vedrà come IIterable<T>.

In definitiva, ciò significa che le tue app .NET Metro hanno accesso a un sottoinsieme delle librerie .NET standard esistenti e anche alle librerie (native) WinRT, alcune delle quali - in particolare Windows.UI- sembrano molto simili a Silverlight, per quanto riguarda le API. Hai ancora XAML per definire la tua interfaccia utente e gestisci ancora gli stessi concetti di base di Silverlight: associazioni di dati, risorse, stili, modelli ecc. In molti casi, è possibile eseguire il porting di un'app Silverlight semplicemente con usingi nuovi spazi dei nomi, e modificando alcuni punti del codice in cui l'API è stata modificata.

WinRT stesso non ha nulla a che fare con HTML e CSS, e ha relazione con JavaScript solo nel senso che è anche esposto lì, in modo simile a come viene fatto per .NET. Non è necessario occuparsi di HTML / CSS / JS quando si utilizzano le librerie dell'interfaccia utente WinRT nella propria app .NET Metro (beh, immagino, se proprio lo si desidera, è possibile ospitare un WebViewcontrollo ...). Tutte le tue competenze .NET e Silverlight rimangono molto rilevanti in questo modello di programmazione.

Dal keynote di Build :

Stanno fornendo API comuni sia alle app HTML / CSS / JavaScript che alle app C # / XAML. Verranno utilizzati C # e XAML, ma non saranno esattamente WPF o Silverlight.

L'idea chiave è che ora ci sono due tracce di sviluppo: Desktop e Metro.

• Il desktop è dove vivono le vecchie app.
• La nuova classe di applicazioni, le applicazioni Metro, può essere costruita in diversi modi, tra cui VB.NET, C # o C ++. Queste tre opzioni di lingua possono utilizzare XAML per creare l'interfaccia utente. L'alternativa è utilizzare JavaScript / HTML5 / CSS per lo sviluppo dell'interfaccia utente e del codice dell'applicazione.

Alcuni punti importanti:

• Windows 8 sembra un sistema operativo per telefoni cellulari evoluto.
• In Metro, non ci sono finestre di livello superiore sovrapposte, proprio come non ce ne sono su un telefono cellulare. Se si desidera un'applicazione in stile MDI, è necessario rimanere sul desktop.
• Le app in stile Metro vengono automaticamente sospese quando non sono visibili. Questo è stato fatto per prolungare la durata della batteria. Ciò significa che non ha senso per molte app desktop esistenti, che eseguono l'elaborazione in background anche quando l'utente non interagisce con esse, per essere trasferite su Metro.
• La versione ARM di Windows 8 non supporterà le applicazioni desktop. Quindi, se vuoi scrivere un'app e vuoi che funzioni su qualsiasi versione di Windows, allora deve essere un'app Metro.

C'è una versione modificata dell'architettura che ti aiuterà sicuramente a capire esattamente dove si trovano le cose. Uno dei ninja di Telerik ha chattato con il team CLR e ha modificato l'immagine:

Qui puoi vedere dove si trova il CLR. Il framework .NET ora ha due profili

1- Profilo Metro .NET (CLR che si occupa dell'applicazione Metro)

2- Profilo client .NET (runtime CLR per applicazioni C # e VB.NET)

Spero che questo ti dia un'immagine più chiara. Leggi l'articolo completo in Una brutta foto vale mille discussioni lunghe. .

Molti dettagli da Microsoft qui .

Windows Runtime è esposto mediante metadati API (file .winmd). Questo è lo stesso formato utilizzato dal framework .NET (Ecma-335). Il contratto binario sottostante semplifica l'accesso alle API di Windows Runtime direttamente nella lingua di sviluppo desiderata. La forma e la struttura delle API di Windows Runtime possono essere comprese sia da linguaggi statici come C # sia da linguaggi dinamici come JavaScript. IntelliSense è disponibile in JavaScript, C #, Visual Basic e C ++.

In breve, Windows Runtime è un nuovo set di librerie che espone le funzionalità di Windows e disponibile per JavaScript / C # / VB / C ++. Ogni lingua è stata fatta per capire ed essere in grado di chiamarli direttamente piuttosto che dover passare attraverso un certo livello di thunking.

Silverlight e WPF sono versioni di XAML eseguite sul CLR. Tra le altre funzionalità, Windows Runtime espone una versione di XAML molto simile a Silverlight, ma lo fa in modo nativo, non tramite CLR. È possibile accedervi dal CLR, ma anche dal C ++.