Windows Dev Center

Conversione da WPF e Microsoft Silverlight a WinRT

Se hai familiarità con altre piattaforme di programmazione basate su XAML, come Windows Presentation Foundation (WPF), Silverlight "desktop" o Silverlight per Windows Phone, puoi sfruttare le tue conoscenze per creare app di Windows Store. In questo argomento sono elencate le principali differenze di cui dovrai tenere conto per la migrazione del codice e dell'XAML dall'app di WPF o Silverlight originale.

Nota  Se intendi effettuare la migrazione di un'app di Windows Phone che usa XAML, vedi Risorse per sviluppatori Windows Phone.

Roadmap: che relazione c'è tra questo argomento e gli altri? Vedi: Roadmap per app di Windows Runtime in C# o Visual Basic

Tecniche generali per la conversione di XAML e codice

Quando esegui la migrazione di codice e XAML scritti in precedenza per un altro framework dell'interfaccia utente, come WPF o Silverlight, i passaggi per la migrazione sono più complessi rispetto, ad esempio, all'aggiornamento tra versioni dello stesso framework. Facendo riferimento a questo argomento per identificare le aree in cui vi sono differenze tra API e modelli di programmazione, potrai comunque riutilizzare parti del codice e del linguaggio XAML. Il modo migliore per farlo consiste nell'integrare queste parti nel codice e nella struttura XAML che ottieni da un modello di nuovo progetto di Microsoft Visual Studio per un'app di Windows Store in C++, C# o Visual Basic. In questo modo, otterrai una struttura di navigazione appropriata per le tue pagine XAML e gli spazi dei nomi di Windows Runtime inclusi per il code-behind. Se hai bisogno di più pagine XAML o codice, usa le opzioni Aggiungi nuovo per iniziare con un file di codice o una pagina di app di Windows Store, copia il linguaggio XAML o il codice originale come nuovi segmenti nel nuovo file o nella nuova pagina e quindi esegui le conversioni necessarie a livello di riga.

Le sezioni rimanenti di questo argomento illustrano diverse aree di funzionalità comuni sia ai framework dell'interfaccia utente iniziali che alle app di Windows Store. Leggi tutte le sezioni per una panoramica delle differenze e delle operazioni che potrebbero essere necessarie per far funzionare il linguaggio XAML e il codice di cui esegui la migrazione per un'app di Windows Store.

Nuovo aspetto e comportamento

Le app di Windows Store sono caratterizzate da un aspetto e da un comportamento particolare (personalità) che le distingue nettamente dalle altre app, comprese quelle create usando altre piattaforme basate su XAML. Prima di iniziare è importante imparare le procedure consigliate per la creazione di un'app di Windows Store di grande effetto. Per la fase di progettazione della creazione di un'app di Windows Store è spesso necessario ricomporre parti sostanziali dell'interfaccia utente. In particolare, potrebbero essere necessarie modifiche alle modalità di gestione di finestre di dialogo, menu, comandi di input ed elenchi, per rispettare le linee guida di progettazione. Vedi Creazione di entusiasmanti app di Windows Store e Linee guida per l'esperienza utente nelle app di Windows Store.

Oggetto applicazione e modello applicativo

  • Il modello di applicazione per l'attivazione e la durata dell'app è diverso, perché le app possono essere sospese e riprese. Per altre informazioni, vedi Avvio, ripresa e multitasking.
  • Il tag Application in app.xaml non può essere usato per associare eventi relativi alla durata dell'app; il collegamento degli eventi come Suspending deve rientrare nell'ambito della logica di avvio nel file code-behind app.xaml.
  • L'oggetto Window è equivalente in modo meno diretto a un HWND applicazione in esecuzione da una prospettiva di programmazione Microsoft Win32. Alcune delle caratteristiche avanzate di windowing vengono definite su un oggetto separato, che puoi ottenere usando il valore della proprietà Window.CoreWindow.
  • Rispetto alle app Silverlight, il browser non funge più da host come vincolo di programmazione intermedio, in quanto l'app di Windows Store viene eseguita direttamente in Windows Runtime. Ciò rappresenta una semplificazione poiché elimina i problemi di hosting su browser ai quali era soggetto Silverlight, ad esempio la gestione degli input attraverso un livello di accesso ai programmi, l'accesso limitato allo spazio di archiviazione e un modello di sicurezza e memorizzazione nella cache orientato a Internet.
  • Nelle app Silverlight era possibile inserire parti dell'applicazione nel pacchetto di distribuzione, come parti esterne, oppure scaricare i componenti su richiesta. Questo è possibile anche in un'app di Windows Store, ma le API usate per accedere alle parti del pacchetto sono diverse. Mentre Silverlight usa Application.GetResourceStream, un'app di Windows Store usa un modello più generico, in cui il pacchetto installato è semplicemente una cartella di archiviazione. Ad esempio, puoi ottenere il valore della proprietà Package.InstalledLocation e quindi chiamare diverse API StorageFolder, la maggior parte delle quali è asincrona, per ottenere eventuali altri componenti inclusi. Per altre informazioni, vedi Creazione e recupero di risorse nelle app di Windows Store.
  • Il modello di app di Windows Runtime si basa sul concetto di funzionalità. Devi dichiarare una funzionalità nel corso del processo di sviluppo e distribuzione. Un utente potrà vedere nell'interfaccia utente di Windows Store se l'app ha richiesto una determinata funzionalità. Potresti avere la possibilità di richiedere funzionalità per accedere all'archiviazione della libreria per un utente, per usare le API webcam e così via. Per codice specifico usato in precedenza in Silverlight e WPF, anche se il codice è stato convertito correttamente a livello di sintassi, potrebbe essere comunque necessario richiedere una capacità di Windows Runtime per ottenere accesso al codice. Per altre informazioni, vedi Dichiarazioni di funzionalità delle app.
  • L'avvio di un'app direttamente da un riquadro non è l'unico modo in cui è possibile attivare un'app di Windows Store. La tua app può ad esempio supportare l'avvio tramite associazioni file, un contratto Riproduci su un altro dispositivo e così via. Per tenere conto di questo aspetto, devi rendere persistente lo stato dell'app come dati dell'app e assicurarti che l'app includa tutti i dati necessari per l'avvio in tutti i possibili scenari di attivazione. Per altre informazioni, vedi Come attivare un'app e altri argomenti in Avvio, ripresa e multitasking.

Programmazione e proiezione di tipi .NET

L'architettura di Windows Runtime si basa sul principio che gli sviluppatori possono usare vari linguaggi per accedere agli stessi concetti e funzionalità sottostanti di Windows Runtime. Un aspetto del modo in cui è possibile programmare per Windows Runtime nei vari linguaggi e allo stesso tempo mantenere alcune caratteristiche o modelli del linguaggio è la proiezione dei tipi. Nel caso dei linguaggi Microsoft .NET, gli sviluppatori hanno familiarità con il sistema di tipi .NET e con le primitive, i tipi e i concetti implementati dall'assembly .NET mscorlib.

Ecco un elenco dei tipi specificamente proiettati per .NET quando si programma per Windows Runtime. Questi tipi esistono nell'assembly mscorlib e nello spazio dei nomi System oppure vengono specificamente aggiunti a uno degli assembly WindowsRuntime inclusi come assembly di riferimento .NET per la programmazione in Windows Runtime.

  • Le interfacce di insieme comuni vengono proiettate come le interfacce di insieme note ai programmatori .NET. IVector<T> viene proiettata come IList<T>. IMap<K,V> viene proiettata come IDictionary<TKey,TValue>. I tipi enumerabili supportano la sintassi foreach e i metodi di estensione correlati tramite System.Linq. Le classi di visualizzazione correlate e le varianti di sola lettura hanno proiezioni simili. Attraverso queste proiezioni, qualunque classe di Windows Runtime che implementa un'interfaccia di insieme può supportare l'API dell'interfaccia di insieme .NET proiettata.

  • Uri viene proiettata come System.Uri. Esistono tuttavia differenze evidenti. Vedi la sezione relativa agli "URI".

  • Le "primitive" comuni vengono proiettate come il tipo mscorlib/System che gli sviluppatori conoscono dalla programmazione .NET. Ad esempio, qualsiasi codice di app che prevede un valore double può usare l'API fornita per System.Double quando si esegue la programmazione con un linguaggio .NET.

  • Le API .NET che interagiscono con il sistema dei tipi possono fare riferimento a System.Type di .NET e tu puoi usare l'operatore typeof nel codice Windows Runtime. Nota: se intendi usare l'interoperabilità o C++ per parte del tuo codice, tieni presente che C++ include un operatore typeid, che però è limitato al confronto con typeof.

  • IReference<T> viene proiettata come Nullable<T> per .NET e consente alla sintassi del linguaggio come bool? di rappresentare un valore Boolean nullable.

  • EventHandler<T> viene proiettata come System.EventHandler<TEventArgs> per .NET.

  • HResult viene proiettata come System.Exception per .NET. È anche disponibile il supporto per estrarre le informazioni del messaggio da un errore di Windows Runtime in base alla singola API, in modo da offrire agli sviluppatori .NET un eccezione tipizzata correttamente basata su System.Exception. Puoi usare try-catch e tecniche simili per la gestione delle eccezioni e potrai gestire molte delle eccezioni standard di .NET che già conosci. Per altre info, vedi Gestione delle eccezioni per app di Windows Runtime in C# o Visual Basic.

  • I modelli ICommand usano la definizione .NET (System.Windows.Input.ICommand).
  • Le interfacce usate per gli oggetti business con riconoscimento dell'associazione scritti in .NET vengono convertite quando usi l'oggetto come origine dati di Windows Runtime. Ad esempio, un'associazione può rispondere a PropertyChanged o CollectionChanged come implementato in una classe di oggetto business scritta in origine per WPF o Silverlight.

  • Molte strutture normalmente usate come tipi di valore per la programmazione XAML nell'interfaccia vengono proiettate come strutture che dispongono di metodi di utilità. Queste strutture hanno lo stesso nome e lo stesso percorso dello spazio dei nomi, ma fanno riferimento a un assembly WindowsRuntime in modo che i metodi di utilità siano supportati per .NET. Ad esempio, i programmatori .NET possono usare l'API di utilità Matrix3D, ad esempio HasInverse, oppure gli operatori predefiniti. In C++/CX è inoltre disponibile il supporto per le relative strutture tramite utilità. Il supporto viene implementato anche come proiezione, ma è più limitato.

  • Un concetto correlato è che un tipo proiettato come tipo .NET può supportare i metodi di estensione .NET. Questo consente di usare metodi di estensione .NET specificamente progettati per la programmazione di app di Windows Store. Ad esempio, un tipo .NET esistente come StreamReader può supportare metodi che usano modelli async simili a quelli presenti nelle API Windows.Storage.

  • Il tipo di base per tutti gli oggetti runtime appare come System.Object e dispone dell'API System.Object prevista, ad esempio ToString. Vi sono tuttavia alcune piccole differenze nelle implementazioni di questi metodi quando vengono eseguiti in Windows Runtime. Queste differenze sono spesso segnalate nella documentazione di riferimento .NET, in una sezione Note per Windows Runtime.
Nota  Le proiezioni dei tipi sono quelle più utili in scenari di migrazione XAML e di codice, in particolare quando devi effettuare la migrazione del code-behind di pagine XAML, oggetti business o classi logiche autonome. Per la maggior parte dei casi non ti serve sapere se un tipo del codice originale è effettivamente un tipo proiettato in Windows Runtime. I compilatori e i modelli di progetto risponderanno automaticamente nel modo corretto.

Quando usi tipi protetti, potrebbero comunque essere necessari riferimenti a spazi dei nomi per i casi in cui le proiezioni servono per il supporto del runtime, ma non fanno parte delle librerie dei framework principale .NET e non sono definite in spazi dei nomi .NET come System.Collections.Generic. Se ad esempio hai codice C# che usa la struttura Point sarà comunque necessaria un'istruzione using che fa riferimento allo spazio dei nomi Windows.Foundation, perché è così che è anche definito l'oggetto Point proiettato.

Per altre informazioni su .NET e sull'app di Windows Store scritta in C++, C# o Visual Basic, vedi Panoramica di .NET per le app di Windows Store.

Modello di programmazione generale

  • Se non esegui la programmazione con un linguaggio .NET, ma usi le estensioni del componente Visual C++ (C++/CX), molte strutture avranno una definizione di stile C di base che non supporta membri non dati.
  • Il modello di programmazione dispone di sintassi integrata per le operazioni asincrone. Le operazioni asincrone sono più prevalenti nel modello di programmazione rispetto a quanto lo fossero per WPF o Silverlight. L'intento delle API asincrone è di rinforzare modelli che impediscono il blocco non intenzionale del thread dell'interfaccia utente in un gestore di eventi o in un callback. Per altre info, vedi Guida introduttiva: Chiamata di API asincrone in C# o Visual Basic.
  • A causa di modelli asincroni o di altre attività in background non presenti nel thread dell'interfaccia utente, potrebbe essere necessario effettuare chiamate da altri thread che alla fine aggiornano il thread dell'interfaccia utente in modo asincrono. L'API usata per passare da un thread a un altro, in genere da uno in background a quello dell'interfaccia utente, è la stessa di Silverlight, ovvero DependencyObject.Dispatcher.
  • L'accesso ai file e ai supporti di archiviazione, che era possibile gestire con le API degli assembly mscorlib e system, viene ora eseguito con API di sistema dedicate, ad esempio StorageFile.
  • Se stai programmando con un linguaggio .NET, puoi anche usare la logica esistente basata su System.IO.Stream. Puoi accedere ai metodi di estensione che restituiscono un flusso da tipi analoghi di Windows Runtime, ad esempio chiamando il metodo di estensione AsStream in un'istanza di IRandomAccessStream. In un editor di codice, l'API System.IO.Stream sarà presente tra le opzioni dei menu a discesa di Microsoft IntelliSense se sono disponibili istanze di Stream ottenute da tipi di flusso/buffer correlati.

Navigazione

Il modello di navigazione di Silverlight prevedeva l'impiego di pagine XAML, indipendenti o comprese nel pacchetto, come base per l'identificazione del contenuto di destinazione della navigazione. Le app di Windows Store usano i tipi, e in particolare il tipo indicato come x:Class per una pagina XAML. Una buona strategia consiste nell'usare la funzionalità Aggiungi nuovo di Esplora soluzioni per creare nuove pagine XAML all'interno del modello di progetto dell'app di Windows Store prescelta, importare gli elementi al di sotto del livello radice della pagina Silverlight originale e risolvere gli eventuali altri problemi di conversione esistenti, quindi creare la struttura di navigazione usando un Frame nella pagina principale. In alternativa, crea un nuovo progetto usando i modelli di app Griglia o di app Doppia visualizzazione. Questi modelli includono pagine che dispongono già di una struttura di spostamento, oltre a modelli di stato di visualizzazione e logica di sospensione/ripresa. Puoi anche usare il modello Applicazione hub e la relativa strategia di navigazione. Per altre informazioni, vedi Parte 3: Navigazione, layout e visualizzazioni o Aggiunta di un modello di elemento Controllo pagina.

Windows Runtime include le classi Page e Frame nel set di controlli predefinito, mentre in Silverlight queste classi derivano dalle librerie del Software Development Kit (SDK) e devono essere distribuite. Se intendi effettuare la migrazione di XAML che contiene un elemento Page o Frame, puoi rimuovere il prefisso "sdk:" dagli elementi e il mapping xmlns per il prefisso "sdk:". Nelle pagine è possibile eseguire l'override di OnNavigatedTo o di OnNavigatedFrom se devono eseguire operazioni di pulizia durante un'azione di navigazione. Sono disponibili eventi e override anche per la classe Frame, per esempio Navigated, quindi puoi inserire la logica di navigazione in Frame e non nelle singole pagine. Inoltre, mentre l'oggetto Frame di Silverlight include semplici pulsanti di navigazione nel modello di controllo, le funzioni di navigazione di Windows Runtime sono integrate nei modelli di pagina e usano stili e modelli dedicati per i pulsanti stessi. Per altre informazioni, vedi Guida introduttiva: Navigazione tra le pagine.

Riquadri e notifiche

Le funzionalità di riquadri e notifiche prevedono vari livelli di supporto nei framework XAML precedenti, per cui non esiste una formula generale per convertirle. Per altre informazioni sull'uso di queste funzionalità nelle app di Windows Store, vedi Uso di riquadri, notifiche e notifiche di tipo avviso popup. Se l'app usa le notifiche push di Windows Phone, vedi Risorse per sviluppatori Windows Phone.

Uso di .NET Framework

Per le app di Windows Store che usano linguaggi .NET (C# o Microsoft Visual Basic), le API .NET Framework che vengono chiamate fanno parte di un profilo .NET Framework particolare. Questa relazione è illustrata in dettaglio nell'argomento Panoramica di .NET per app di Windows Store.

Funzionalità del linguaggio XAML

Per quanto riguarda le funzionalità specifiche del linguaggio stesso, XAML per Windows Runtime è molto simile a XAML per Silverlight e simile a XAML per WPF. Esistono però anche alcune differenze.

  • Invece di usare un qualificatore clr-namespace:/assembly= impostato per i riferimenti allo spazio dei nomi da codice a XAML, si usa il qualificatore using:. Gli spazi dei nomi XAML non fanno più riferimento ad assembly specifici. La qualificazione e l'inclusione di tutti gli assembly viene completamente gestita dal modello applicativo e dal modo di comporre il pacchetto dell'app.
  • Poiché non è possibile eseguire il mapping di assembly specifici, alcuni riferimenti a mscorlib che venivano usati per il supporto delle primitive Common Language Runtime smetteranno di funzionare. Puoi però usare i tipi intrinseci del linguaggio XAML, come x:String. Per altre informazioni, vedi l'argomento relativo ai tipi di dati intrinseci di XAML. Inoltre, tieni presente che molte stringhe che prima venivano archiviate come x:String in ResourceDictionary possono essere più opportunamente archiviate come stringhe in un file di risorse per il progetto. Per altre informazioni, vedi Globalizzazione dell'app.
  • XAML per Windows Runtime non supporta le estensioni markup personalizzate.
  • In casi rari, codice XAML in cui un attributo Name senza prefisso era accettabile in Silverlight potrebbe richiedere invece l'attributo x:Name.
  • In alcuni casi in cui un oggetto Setter.Property iperqualificato funziona per XAML di Silverlight non funziona con l'XAML di Windows Runtime. La maggior parte dei valori di Setter.Property deve corrispondere semplicemente al nome della proprietà di dipendenza e non tentare di qualificare il relativo proprietario. Le proprietà associate rappresentano l'eccezione, in quanto è comunque necessario qualificarne il proprietario.
  • Se intendi effettuare la migrazione di XAML da WPF, oltre alle differenze già elencate per XAML di Silverlight, tieni presente che alcuni costrutti non sono supportati in XAML per Windows Runtime. Sono inclusi: DynamicResource estensione del markup (e il comportamento di ricerca risorse sottostante), x:ClassModifier e x:Subclass, x:Array e il supporto dei generics di XAML 2009 correlati, x:Code, x:Static, x:Type usato in modo esplicito (esiste una valutazione implicita di x:Type per le proprietà che la richiedono), nodi VisualTree nei modelli e altre piccole differenze. Devi riuscire a individuare eventuali problemi di compatibilità di XAML nella fase di progettazione in base alle eccezioni di analisi XAML.

Tocco e input

  • Non esistono eventi di input specifici del mouse come MouseLeftButtonDown. Questi eventi, insieme agli eventi specifici dell'input tramite tocco, sono stati unificati negli eventi Pointer. Nella maggior parte dei casi puoi convertire l'evento mouse pertinente in PointerPressed, PointerReleased, PointerEntered o PointerExited. Per altre informazioni, vedi l'argomento relativo alla risposta all'interazione utente. Per MouseWheel, usa l'evento PointerWheelChanged. Il Delta della rotellina può essere individuato in PointerPointProperties nell'oggetto PointerPoint principale dai dati dell'evento.
  • Se gestivi manipolazioni non elaborate per abilitare azioni nei controlli e hai creato stati visivi per tale gestione, devi verificare che i controlli che usi non includano già il supporto integrato per la manipolazione o i gesti. Ad esempio per il controllo ListBox di Windows Runtime sono già abilitate diverse interazioni come transizioni del tema.
  • Per le interazioni in generale, ti consigliamo di preferire la gestione degli eventi relativi ai gesti a quella degli eventi relativi al puntatore, perché è in genere più semplice. Ad esempio, Tapped è in genere un evento migliore nel modello di eventi di Windows Runtime per le interazioni che sarebbero state gestite da un evento specifico del mouse in Silverlight.
  • È possibile abilitare o disabilitare specifiche interazioni tramite tocco elemento per elemento, usando le proprietà. Ad esempio, puoi impostare IsRightTapEnabled su false e questo elemento non darà origine a un evento RightTapped. Ciò ha lo scopo di evitare possibili problemi con il riconoscimento di gesti e manipolazioni, quando gli eventi attraversano un albero visuale di composizione controlli.
  • I tasti per gli eventi relativi ai tasti non dispongono di una separazione PlatformKeyCode /Key. Il tasto indicato nei dati dell'evento usa un'enumerazione diversa, VirtualKey. Altri dati sugli eventi correlati al tasto sono disponibili come KeyStatus.
  • L'acquisizione di puntatori da UIElement consente di acquisire più puntatori, per supportare le manipolazioni tramite tocco che avviano l'acquisizione. Per ottenere il riferimento di puntatore corretto, usa una classe dati evento correlata ai puntatori, ad esempio PointerRoutedEventArgs.
  • Le chiamate a Control.Focus devono specificare un valore di enumerazione che stabilisce che l'azione dello stato attivo è stata programmatica. Windows Runtime separa le chiamate dello stato attivo, perché gli stati visivi usano un comportamento diverso per le chiamate dello stato attivo a livello di codice. Può essere necessario aggiungere ai modelli nuovi stati visivi personalizzati per lo stato attivo non da tastiera.
  • Alcuni controlli di Windows Runtime integrano già la gestione delle manipolazioni. Ad esempio un elemento ScrollViewer gestisce internamente le interazioni con scorrimento, panoramica e zoom, in modo che il controllo restituisca la risposta appropriata per l'azione. La gestione del controllo può impedire l'attivazione di eventi del puntatore di livello inferiore. Puoi chiamare CancelDirectManipulations per ignorare questo comportamento. Tuttavia, potrebbe risultare utile rivedere la gestione complessiva degli input nei controlli. Potrebbe essere disponibile un comportamento predefinito adatto allo scenario, nel qual caso non sarebbe più necessario un gestore a livello di puntatore.

Layout/composizione di grafica ed elementi

  • Per ottimizzare al massimo l'insieme di elementi per le funzionalità del nuovo stack di grafica abbiamo eliminato alcune API/concetti che avrebbero rallentato il rendering, Gli esempi includono OpacityMask, clip non rettangolari, funzioni di semplificazione personalizzate ed effetti bitmap.
  • VideoBrush non è supportato in Windows Runtime, né in RadialGradientBrush.
  • L'API di imaging di Windows Runtime include un componente di imaging sottostante diverso e più efficiente, ovvero Windows Imaging Component (WIC). Questo componente supporta più formati di origine immagine rispetto a Silverlight o WPF. Sono disponibili anche tipi di codificatore e decodificatore di facile utilizzo e alcune API aggiuntive per la modifica delle immagine, già predefinita in WIC. Per altre informazioni, vedi lo spazio dei nomi Windows.Graphics.Imaging.
  • BitmapCache include logica sottostante diversa rispetto a Silverlight, Silverlight per Windows Phone o WPF. La cache bitmap, inoltre, può interagire con animazioni e potrebbe fare in modo che alcune animazioni vengano considerate dipendenti. Se usi UIElement.CacheMode, dovrai creare un nuovo profilo per l'app e verificare di nuovo se l'utilizzo di un'impostazione UIElement.CacheMode per parte dell'interfaccia utente sia un vantaggio a livello di prestazioni per un'app di Windows Store. Per altre info, vedi UIElement.CacheMode e DebugSettings.IsOverdrawHeatMapEnabled.
  • Per alcuni scenari in cui hai usato WriteableBitmap, ti consigliamo invece di usare RenderTargetBitmap.

Controlli

  • Le app di Windows Store e gli altri framework che usano XAML per la definizione dell'interfaccia utente dispongono degli stessi controlli di base, come Button e ListBox, e dei contenitori di layout di base come Border, Grid e StackPanel. Windows Runtime include anche molti controlli predisposti per le raccolte tra cui SemanticZoom e FlipView. Inoltre, GridView è un controllo autonomo e non più un componente usato in un controllo ListView, e l'unica vera differenza tra GridView e ListView è rappresentata dall'orientamento predominante degli elementi presentati usato da ciascun controllo. Per altre informazioni, vedi Controlli per funzione.
  • Sebbene tu possa usare lo stesso controllo usato nell'app Silverlight o WPF originale e persino eseguire la migrazione di un'intera interfaccia utente in componenti equivalenti, questo approccio non è sempre consigliato. Ed è proprio quando definisci l'interfaccia utente dell'app che potresti avere la necessità di interrompere e rivedere di nuovo le linee guida relative alla progettazione delle app di Windows Store. È ad esempio possibile che l'app originale e i controlli nella relativa interfaccia utente non siano stati progettati prima per il tocco, mentre l'app di Windows Store deve essere prima progettata per il tocco. Anche L'intera esperienza dell'interfaccia utente sarà diversa perché non hai più bisogno di ospitarla nel browser. Per altre informazioni sulla progettazione, vedi Progettazione dell'esperienza utente per le app. Per altre informazioni sulle linee guida relative all'esperienza utente per i controlli, vediIndice delle linee guida relative all'esperienza utente.

Animazioni, transizioni, stati di visualizzazione e stili

  • Windows Runtime aggiunge il concetto di animazioni preconfigurate. Possono essere usate in XAML come animazioni di transizione e animazioni di tema applicate direttamente agli elementi dell'interfaccia utente, senza che sia necessario coinvolgere le proprietà multiple di quell'elemento. Il funzionamento delle animazioni con storyboard è quasi identico. Non tutte le animazioni con storyboard, tuttavia, sono abilitate per impostazione predefinita. La disabilitazione per impostazione predefinita delle animazioni dipendenti ha lo scopo di rendere gli sviluppatori più consapevoli dei costi a livello di prestazione delle animazioni, che potrebbero influire in modo significativo sul thread principale dell'interfaccia utente. Se l'animazione non viene eseguita come previsto, prova a impostare EnableDependentAnimations su true. Esegui tuttavia questa operazione con attenzione, perché l'esecuzione delle animazioni dipendenti comporta costi a livello di prestazioni. Per altre informazioni, vedi Animazione dell'interfaccia utente, Animazioni con storyboard e Garantire la continuità delle animazioni.
  • Se disponi di prefissi "vsm:" nelle definizioni XAML degli stati visivi, rimuovi gli usi e la definizione dei prefissi. Non devi più eseguire separatamente il mapping dei prefissi degli stati visivi e degli spazi dei nomi.
  • Se converti gli stati visivi, assicurati di convertire i concetti "Mouse" in concetti "Pointer", come hai modificato la gestione degli eventi a livello di elemento. Puoi modificare i nomi degli stati visivi, oltre a determinare quali proprietà vengono modificate dallo stato. Dai un'occhiata ai dizionari di risorse XAML esistenti, ad esempio generic.xaml nella sottocartella include/winrt/xaml/design di un'installazione di Windows SDK. Potrebbero suggerire alcuni modelli da seguire per gli stati di visualizzazione e gli eventi correlati.
  • Se hai già un tema a contrasto elevato per un controllo personalizzato che hai convertito, assicurati di seguire il modello ThemeDictionaries per connettere i temi alla definizione del controllo. In particolare, desideri probabilmente supportare i temi con nome identificati nell'enumerazione HighContrastScheme. Per altre informazioni, vedi Esempio di stile a contrasto elevato XAML.
  • Se l'app supporta il cambio di tema, ti consigliamo di supportare due modelli per i controlli, uno chiaro e uno scuro. Questi temi sono già inclusi nei modelli predefiniti, ma devi aggiungere un tema a eventuali modelli personalizzati che hai importato.
  • WPF e Silverlight supportano la possibilità di utilizzare un'espressione Binding per fornire il Value di un Setter in uno Style. Windows Runtime non supporta l'uso di Binding per Setter.Value (Binding non viene valutato e Setter non ha effetto; non vengono generati errori ma non si ottiene neanche il risultato desiderato). Quando converti stili XAML da WPF o Silverlight XAML, sostituisci eventuali espressioni Binding con stringhe o oggetti che impostano valori o ne eseguono il refactoring come valori di StaticResource condivisi invece che come valori ottenuti da Binding.

Elementi multimediali

  • Le API multimediali sono simili, ma è diversa la modalità di integrazione di DRM (Digital Rights Management) con le API multimediali. A differenza di Silverlight, Windows dispone di un modello DRM modulare e la tecnologia PlayReady è una delle tante che verrebbero supportate, quindi le API sono diverse per tenere conto di un gestore della protezione dei contenuti.

  • MediaElement è per lo più la stessa, sebbene preferisca definire un nuovo modello XAML per qualsiasi modello di controllo di trasporto MediaElement precedente, per rendere l'interfaccia utente abilitata per il touch. In alternativa puoi usare AreTransportControlsEnabled per ottenere alcuni controlli per il trasporto predefiniti. Aggiunte significative di Windows Runtime alle API MediaElement consistono nella possibilità di disporre di un "poster" per il caricamento, il rilevamento e l'utilizzo di modalità di compressione di video stereo e l'aggiunta di effetti video.
  • L'acquisizione con fotocamera è concettualmente diversa da una piattaforma all'altra ed è consigliabile riscrivere il codice anziché convertire il codice se è presente questa funzionalità. Per altre informazioni, vedi Come visualizzare l'anteprima di un video da una webcam e Acquisizione di contenuti multimediali tramite l'esempio per l'acquisizione di un dispositivo. Dovrai probabilmente usare CaptureElement come superficie di visualizzazione, perché VideoBrush non è disponibile.

URI

In Windows Runtime gli URI (Uniform Resource Identifier) per la gestione dei riferimenti ai file funzionano in modo leggermente diverso. Gli URI relativi non sono supportati, almeno non a livello dei tipi di URI puri. Può sembrare che la classe .NET System.Uri offra una scelta RelativeOrAbsolute in alcune chiamate API, ma a livello pratico tutti questi URI sono assoluti e vengono valutati rispetto a concetti e percorsi quali il pacchetto dell'app, i percorsi selezionati dagli utenti, i dati delle app e così via.

Potrebbe essere necessario esaminare qualsiasi valore di proprietà che accetta URI. Non puoi utilizzare gli URI dello schema file:. È possibile che tu riesca a eseguire il porting di XAML con riferimenti URI a valori quali i file Image.Source, senza preoccuparti in alcun modo di problemi relativi a URI, e a utilizzare questo codice come nuova interfaccia utente di Windows. Questo però può dipendere da come è stata strutturata l'app originale. Quando viene specificato nel codice XAML, un URI spesso sembra un URI relativo, ma queste stringhe vengono elaborate e completate dal parser XAML prima dell'impostazione delle proprietà in fase di esecuzione. Per riprodurre lo stesso comportamento nel code-behind, usa il valore restituito FrameworkElement.BaseUri come valore del parametro baseUri nel costruttore Uri che combina un URI di base con un URI relativo. Per altre informazioni, vedi Definizione delle risorse delle app.

API di archiviazione e file

Le tecniche usate per accedere ai file e allo spazio di archiviazione in Windows Runtime sono molto diverse da quelle usate in .NET, in particolare poiché molte di queste API usano un modello e le parole chiave async/await. Per altre informazioni, vedi Accesso a file e dati.

XML e XMLDOM

L'area di .NET disponibile per un'app di Windows Store in C++, C# o Visual Basic non include alcune delle API XML DOM del framework oppure inoltra alcuni dei tipi di base allo spazio dei nomi Linq. Cerca API simili in Windows.Data.Xml.Dom e System.Xml.Linq.

HTML ospitato e affiancato

Per Silverlight l'HTML affiancato è più immediato perché il controllo Silverlight è ospitato in un elemento DOM e l'altro contenuto HTML si trova in un altro elemento DOM o in un iframe. Per WPF è probabile che tu abbia usato il controllo WebBrowser. Per un'app di Windows Store che usa XAML per l'interfaccia utente, il controllo da usare per la visualizzazione del contenuto HTML è WebView. Il modello WebView prevede che l'HTML sia visualizzato in un'area interna all'interfaccia utente generale di XAML. Il contenuto HTML visualizzato in un'app di Windows Store deve essere necessariamente esaminato per valutarne l'esperienza utente e la sicurezza. Non adattare semplicemente quanto visualizzato nel iframe di un'app di Silverlight quale Source di un controllo WebView. Dovrai anche esaminare quale logica deve rimanere come codice JavaScript per HTML anziché venire eseguita come code-behind per la pagina. Le tue decisioni dipenderanno da come Windows Runtime elabora gli eventi di interazione utente in WebView. Per altre info, vedi WebView.

Conversione di progetti

In generale, per la conversione di un intero progetto è preferibile iniziare con uno dei modelli di progetto esistenti per app di Windows Store, quindi usare la funzionalità Aggiungi esistente di Esplora soluzioni per introdurre pagine XAML e file code-behind nuovi o esistenti e infine eseguire la migrazione di specifici blocchi di codice nel codice XAML e nei file di codice. In questo modo è possibile evitare i dettagli di implementazione del framework precedente e l'infrastruttura per progetti e compilazioni che potrebbero essere casualmente presenti. Puoi usare le istruzioni using/Imports con gli spazi dei nomi "Windows" corretti, fare riferimento ai tipi di compilazione correnti e accedere al sistema di risorse .resw, poiché saranno tutti disponibili nei nuovi modelli di progetti e pagine.

Se per il progetto Silverlight hai usato il sistema di localizzazione basato su Binding, come documentato nell'argomento relativo alla procedura per rendere localizzabile il contenuto XAML, ti consigliamo di prendere in considerazione la modifica della tecnica di localizzazione, per utilizzare stringhe dichiarate nel sistema del file di indice di risorse (PRI). Il sistema di localizzazione basato su Binding continuerà a funzionare, ma non dispone del supporto per gli strumenti offerto dai file PRI e .resw, sia in Visual Studio sia per eventuali processi o strumenti di localizzazione dedicati, basati sulla metodologia di localizzazione di Visual Studio.

Se scegli di convertire interi file di codice, puoi cercare e sostituire le istruzioni using/Imports o riferimenti completi. Ad esempio, "System.Windows" deve essere sostituito con "Windows.UI.Xaml". Esistono alcune eccezioni a questa regola generale relativa alla relazione tra tipi e spazi dei nomi di Silverlight/WPF in Windows Runtime. Questi casi verranno affrontati nella documentazione delle API, nella sezione dei commenti.

Per altre informazioni sui modelli di progetto, vedi Modelli di progetto C#, VB e C++ per le app di Windows Store.

Altre risorse per la migrazione di app

Argomenti correlati

Passare da Silverlight per Windows Phone a WinRT
Risorse per sviluppatori Windows Phone
Roadmap per app di Windows Store in C# o Visual Basic
Linee guida per l'esperienza utente delle app di Windows Store
Modelli di progetto C#, VB e C++ per le app di Windows Store
Panoramica di .NET per le app di Windows Store
Supporto .NET Framework per app di Windows Store e Windows Runtime

 

 

Mostra:
© 2015 Microsoft