Conversione del codice XAML e dell'interfaccia utente di Windows Phone Silverlight alla piattaforma UWP

  • Articolo

L'argomento precedente è Risoluzione dei problemi.

La pratica di definire l'interfaccia utente sotto forma di markup XAML dichiarativo traduce molto bene da Windows Phone Silverlight alle app piattaforma UWP (Universal Windows Platform). Si scoprirà che le sezioni di grandi dimensioni del markup sono compatibili dopo aver aggiornato i riferimenti alla chiave di risorsa di sistema, modificato alcuni nomi dei tipi di elemento e modificato "clr-namespace" in "using". Gran parte del codice imperativo nel livello presentazione, ovvero modelli di visualizzazione e codice che modifica gli elementi dell'interfaccia utente, sarà semplice da convertire.

Un primo sguardo al markup XAML

L'argomento precedente illustra come copiare i file XAML e code-behind nel nuovo progetto di Windows 10 Visual Studio. Uno dei primi problemi che si potrebbero notare nella finestra di progettazione XAML di Visual Studio è che l'elemento PhoneApplicationPage nella radice del file XAML non è valido per un progetto di piattaforma UWP (Universal Windows Platform). Nell'argomento precedente è stata salvata una copia dei file XAML generati da Visual Studio al momento della creazione del progetto Windows 10. Se si apre quella versione di MainPage.xaml, si vedrà che nella radice è il tipo Page, che si trova nello spazio dei nomi Windows.UI.Xaml.Controls. È quindi possibile modificare tutti gli <phone:PhoneApplicationPage> elementi in <Page> (non dimenticare la sintassi degli elementi di proprietà) ed è possibile eliminare la dichiarazione xmlns:phone.

Per un approccio più generale alla ricerca del tipo UWP che corrisponde a un tipo Windows Phone Silverlight, è possibile fare riferimento ai mapping di spazi dei nomi e classi.

Dichiarazioni di prefisso dello spazio dei nomi XAML

Se si usano istanze di tipi personalizzati nelle visualizzazioni, ad esempio un'istanza del modello di visualizzazione o un convertitore di valori, si avranno dichiarazioni di prefisso dello spazio dei nomi XAML nel markup XAML. La sintassi di questi elementi differisce tra Windows Telefono Silverlight e la piattaforma UWP. Di seguito sono riportati alcuni esempi.

    xmlns:ContosoTradingCore="clr-namespace:ContosoTradingCore;assembly=ContosoTradingCore"
    xmlns:ContosoTradingLocal="clr-namespace:ContosoTradingLocal"

Modificare "clr-namespace" in "using" ed eliminare qualsiasi token di assembly e punto e virgola (l'assembly verrà dedotto). Il risultato è simile al seguente:

    xmlns:ContosoTradingCore="using:ContosoTradingCore"
    xmlns:ContosoTradingLocal="using:ContosoTradingLocal"

È possibile avere una risorsa il cui tipo è definito dal sistema:

    xmlns:System="clr-namespace:System;assembly=mscorlib"
    /* ... */
    <System:Double x:Key="FontSizeLarge">40</System:Double>

Nella piattaforma UWP omettere la dichiarazione di prefisso "System" e usare invece il prefisso "x" già dichiarato:

    <x:Double x:Key="FontSizeLarge">40</x:Double>

Codice imperativo

I modelli di visualizzazione sono un'unica posizione in cui è presente codice imperativo che fa riferimento ai tipi di interfaccia utente. Un'altra posizione è qualsiasi file code-behind che modifica direttamente gli elementi dell'interfaccia utente. Ad esempio, è possibile che una riga di codice simile a questa non venga ancora compilata:

    return new BitmapImage(new Uri(this.CoverImagePath, UriKind.Relative));

BitmapImage si trova nello spazio dei nomi System.Windows.Media.Imaging in Windows Phone Silverlight e una direttiva using nello stesso file consente di usare BitmapImage senza qualifica dello spazio dei nomi come nel frammento precedente. In questo caso, è possibile fare clic con il pulsante destro del mouse sul nome del tipo (BitmapImage) in Visual Studio e usare il comando Risolvi nel menu di scelta rapida per aggiungere una nuova direttiva dello spazio dei nomi al file. In questo caso, viene aggiunto lo spazio dei nomi Windows.UI.Xaml.Media.Imaging, che è la posizione in cui si trova il tipo nella piattaforma UWP. È possibile rimuovere la direttiva using System.Windows.Media.Imaging e sarà tutto necessario per convertire il codice come nel frammento precedente. Al termine, verranno rimossi tutti gli spazi dei nomi di Windows Phone Silverlight.

In casi semplici come questo, in cui si esegue il mapping dei tipi in uno spazio dei nomi precedente agli stessi tipi in uno nuovo, è possibile usare il comando Trova e sostituisci di Visual Studio per apportare modifiche in blocco al codice sorgente. Il comando Resolve è un ottimo modo per individuare il nuovo spazio dei nomi di un tipo. Come altro esempio, si possono sostituire tutti i "System.Windows" con "Windows.UI.Xaml". In pratica, verranno convertite tutte le direttive using e tutti i nomi di tipo completi che fanno riferimento a tale spazio dei nomi.

Dopo aver rimosso tutte le direttive using precedenti e quelle nuove aggiunte, è possibile usare il comando Organize using di Visual Studio per ordinare le direttive e rimuovere quelle inutilizzate.

In alcuni casi, la correzione del codice imperativo sarà minore come la modifica del tipo di un parametro. In altri casi, sarà necessario usare le API di Windows Runtime anziché le API .NET per le app di Windows Runtime 8.x. Per identificare le API supportate, usare il resto di questa guida alla conversione in combinazione con .NET per le app di Windows Runtime 8.x e le informazioni di riferimento di Windows Runtime.

E, se si vuole solo passare alla fase in cui viene compilato il progetto, è possibile impostare come commento o stub qualsiasi codice non essenziale. Eseguire quindi l'iterazione di un problema alla volta e fare riferimento agli argomenti seguenti in questa sezione (e all'argomento precedente: Risoluzione dei problemi), fino a quando non vengono risolti eventuali problemi di compilazione e runtime e la porta è stata completata.

Interfaccia utente adattiva/reattiva

Poiché l'app Windows 10 può essere eseguita su un'ampia gamma di dispositivi, ognuna con dimensioni e risoluzione dello schermo, è consigliabile superare i passaggi minimi per convertire l'app e personalizzare l'interfaccia utente in modo da avere un aspetto ottimale su tali dispositivi. È possibile usare la funzionalità Visual State Manager adattiva per rilevare dinamicamente le dimensioni della finestra e modificare il layout in risposta e un esempio di come eseguire questa operazione è illustrata nella sezione Interfaccia utente adattiva nell'argomento Case study bookstore2.

Allarmi e promemoria

Il codice che usa le classi Alarm o Reminder deve essere convertito per usare la classe BackgroundTaskBuilder per creare e registrare un'attività in background e visualizzare un avviso popup nel momento pertinente. Vedere Elaborazione in background e Avvisi popup.

Animazione

Come alternativa preferita alle animazioni con fotogrammi chiave e da/a, la libreria di animazioni UWP è disponibile per le app UWP. Queste animazioni sono state progettate e ottimizzate per essere eseguite senza problemi, per avere un aspetto ottimale e per rendere la tua app come integrata con Windows, come fanno le app predefinite. Vedere Guida introduttiva: Animazione dell'interfaccia utente tramite animazioni di libreria.

Se si usano animazioni basate su fotogrammi chiave o da/a nelle app UWP, si potrebbe voler comprendere la distinzione tra animazioni indipendenti e dipendenti introdotte dalla nuova piattaforma. Vedere Ottimizzare animazioni e contenuti multimediali. Le animazioni eseguite sul thread dell'interfaccia utente (quelle che animano le proprietà del layout, ad esempio) sono note come animazioni dipendenti e, quando vengono eseguite nella nuova piattaforma, non avranno alcun effetto a meno che non si esegua una delle due operazioni. È possibile riassegnare loro le destinazioni per animare proprietà diverse, ad esempio RenderTransform, rendendole quindi indipendenti. Oppure si può impostare EnableDependentAnimation="True" sull'elemento di animazione per confermare la tua intenzione di eseguire un'animazione che non può essere garantita per l'esecuzione senza problemi. Se si usa Blend per Visual Studio per creare nuove animazioni, tale proprietà verrà impostata per l'utente, se necessario.

Gestione dei pulsanti Indietro

In un'app di Windows 10 si può usare un unico approccio per gestire il pulsante Indietro e funziona su tutti i dispositivi. Nei dispositivi mobili, il pulsante viene fornito automaticamente come pulsante di capacità nel dispositivo o come pulsante nella shell. In un dispositivo desktop aggiungere un pulsante al riquadro dell'app ogni volta che è possibile spostarsi indietro all'interno dell'app e questo viene visualizzato nella barra del titolo per le app finestra o nella barra delle applicazioni per la modalità Tablet (solo Windows 10). L'evento pulsante Indietro è un concetto universale per tutte le famiglie di dispositivi e i pulsanti implementati nell'hardware o nel software generano lo stesso evento BackRequested.

L'esempio seguente funziona per tutte le famiglie di dispositivi ed è utile per i casi in cui la stessa elaborazione si applica a tutte le pagine e dove non è necessario confermare lo spostamento (ad esempio, per avvisare le modifiche non salvate).

   // app.xaml.cs

    protected override void OnLaunched(LaunchActivatedEventArgs e)
    {
        [...]

        Windows.UI.Core.SystemNavigationManager.GetForCurrentView().BackRequested += App_BackRequested;
        rootFrame.Navigated += RootFrame_Navigated;
    }

    private void RootFrame_Navigated(object sender, NavigationEventArgs e)
    {
        Frame rootFrame = Window.Current.Content as Frame;

        // Note: On device families that have no title bar, setting AppViewBackButtonVisibility can safely execute 
        // but it will have no effect. Such device families provide a back button UI for you.
        if (rootFrame.CanGoBack)
        {
            Windows.UI.Core.SystemNavigationManager.GetForCurrentView().AppViewBackButtonVisibility = 
                Windows.UI.Core.AppViewBackButtonVisibility.Visible;
        }
        else
        {
            Windows.UI.Core.SystemNavigationManager.GetForCurrentView().AppViewBackButtonVisibility = 
                Windows.UI.Core.AppViewBackButtonVisibility.Collapsed;
        }
    }

    private void App_BackRequested(object sender, Windows.UI.Core.BackRequestedEventArgs e)
    {
        Frame rootFrame = Window.Current.Content as Frame;

        if (rootFrame.CanGoBack)
        {
            rootFrame.GoBack();
        }
    }

Esiste anche un unico approccio per tutte le famiglie di dispositivi per uscire dall'app a livello di codice.

   Windows.UI.Xaml.Application.Current.Exit();

Binding e associazioni compilate con {x:Bind}

L'argomento dell'associazione include:

  • Associazione di un elemento dell'interfaccia utente a "dati", ovvero alle proprietà e ai comandi di un modello di visualizzazione.
  • Associazione di un elemento dell'interfaccia utente a un altro elemento dell'interfaccia utente
  • Scrittura di un modello di visualizzazione osservabile, ovvero genera notifiche quando un valore di proprietà cambia e quando cambia la disponibilità di un comando.

Tutti questi aspetti sono in gran parte supportati, ma esistono differenze tra gli spazi dei nomi. Ad esempio, System.Windows.Data.Binding esegue il mapping a Windows.UI.Xaml.Data.Binding, System.ComponentModel.INotifyPropertyChanged esegue il mapping a Windows.UI.Xaml.Data.INotifyPropertyChanged e System.Collections.Specialized.INotifyPropertyChanged esegue il mapping a Windows.UI.Xaml.Interop.INotifyCollectionChanged.

Le barre dell'app Windows Phone Silverlight e i pulsanti della barra dell'app non possono essere associati come in un'app UWP. Si potrebbe avere codice imperativo che costruisce la barra dell'app e i relativi pulsanti, li associa alle proprietà e alle stringhe localizzate e gestisce i relativi eventi. In questo caso, è ora possibile convertire il codice imperativo sostituendolo con markup dichiarativo associato a proprietà e comandi e con riferimenti alle risorse statiche, rendendo così l'app in modo incrementale più sicura e gestibile. Si può usare Visual Studio o Blend per Visual Studio per associare e applicare lo stile ai pulsanti della barra dell'app UWP esattamente come qualsiasi altro elemento XAML. Si noti che in un'app UWP i nomi dei tipi usati sono CommandBar e AppBarButton.

Le funzionalità correlate all'associazione delle app UWP presentano attualmente le limitazioni seguenti:

Anche se le stesse funzionalità di associazione sono ancora ampiamente supportate, Windows 10 offre la possibilità di un meccanismo di associazione nuovo e più efficiente denominato binding compilati, che usano l'estensione di markup {x:Bind}. Vedere Data Binding: aumentare le prestazioni delle app tramite nuovi miglioramenti al data binding XAML e l'esempio x:Bind.

Associazione di un'immagine a un modello di visualizzazione

È possibile associare la proprietà Image.Source a qualsiasi proprietà di un modello di visualizzazione di tipo ImageSource. Ecco un'implementazione tipica di tale proprietà in un'app di Windows Phone Silverlight:

    // this.BookCoverImagePath contains a path of the form "/Assets/CoverImages/one.png".
    return new BitmapImage(new Uri(this.CoverImagePath, UriKind.Relative));

In un'app UWP si usa lo schema URI ms-appx. Per mantenere invariato il resto del codice, è possibile usare un overload diverso del costruttore System.Uri per inserire lo schema URI ms-appx in un URI di base e accodare il resto del percorso. nel modo seguente:

    // this.BookCoverImagePath contains a path of the form "/Assets/CoverImages/one.png".
    return new BitmapImage(new Uri(new Uri("ms-appx://"), this.CoverImagePath));

In questo modo, il resto del modello di visualizzazione, i valori del percorso nella proprietà del percorso immagine e i binding nel markup XAML possono rimanere tutti identici.

Controlli/stili e modelli di controllo

Le app Windows Phone Silverlight usano i controlli definiti in Microsoft.Phone.Controls lo spazio dei nomi e lo spazio dei nomi System.Windows.Controls. Le app UWP XAML usano i controlli definiti nello spazio dei nomi Windows.UI.Xaml.Controls. L'architettura e la progettazione di controlli XAML nella piattaforma UWP sono praticamente uguali ai controlli di Windows Phone Silverlight. Tuttavia, sono state apportate alcune modifiche per migliorare il set di controlli disponibili e unificarli con le app di Windows. Ecco alcuni esempi specifici.

Nome controllo Modifica
ApplicationBar Proprietà Page.TopAppBar.
ApplicationBarIconButton L'equivalente UWP è la proprietà Glyph. PrimaryCommands è la proprietà content di CommandBar. Il parser XAML interpreta il codice XML interno di un elemento come valore della relativa proprietà di contenuto.
ApplicationBarMenuItem L'equivalente UWP è AppBarButton.Label impostato sul testo della voce di menu.
ContextMenu (in Windows Phone Toolkit) Per un'unica selezione a comparsa, usare Flyout.
Classe ControlTiltEffect.TiltEffect Le animazioni della libreria di animazioni UWP sono integrate negli stili predefiniti dei controlli comuni. Vedere l'animazione delle azioni del puntatore.
LongListSelector con dati raggruppati Le funzioni LongListSelector di Windows Phone Silverlight in due modi, che possono essere usati in concerto. In primo luogo, è in grado di visualizzare i dati raggruppati in base a una chiave, ad esempio un elenco di nomi raggruppati per lettera iniziale. In secondo luogo, è in grado di "ingrandire" tra due visualizzazioni semantiche: l'elenco raggruppato di elementi (ad esempio, nomi) e un elenco solo delle chiavi di gruppo stesse (ad esempio, lettere iniziali). Con la piattaforma UWP è possibile visualizzare i dati raggruppati con le Linee guida per i controlli elenco e visualizzazione griglia.
LongListSelector con dati flat Per motivi di prestazioni, nel caso di elenchi molto lunghi, è consigliabile LongListSelector anziché una casella di riepilogo di Windows Phone Silverlight anche per i dati flat e non raggruppati. In un'app UWP, GridView è preferibile per elenchi lunghi di elementi, indipendentemente dal fatto che i dati siano utilizzabili per il raggruppamento.
Panorama Il controllo Panorama di Windows Phone Silverlight esegue il mapping alle linee guida per i controlli hub nelle app e nelle linee guida di Windows Runtime 8.x per il controllo hub.
Si noti che un controllo Panorama esegue il wrapping dall'ultima sezione alla prima e l'immagine di sfondo si sposta in parallasse rispetto alle sezioni. Le sezioni dell'hub non eseguono il wrapping e l'opzione parallasse non viene usata.
Pivot L'equivalente UWP del controllo Pivot di Windows Phone Silverlight è Windows.UI.Xaml.Controls.Pivot. È disponibile per tutte le famiglie di dispositivi.

Nota Lo stato di visualizzazione PointerOver è rilevante negli stili o nei modelli personalizzati nelle app di Windows 10, ma non nelle app di Windows Phone Silverlight. Esistono altri motivi per cui gli stili/modelli personalizzati esistenti potrebbero non essere appropriati per le app di Windows 10, incluse le chiavi delle risorse di sistema in uso, le modifiche ai set di stati di visualizzazione usati e i miglioramenti delle prestazioni apportati agli stili/modelli predefiniti di Windows 10. Si consiglia di modificare una nuova copia del modello predefinito di un controllo per Windows 10 e quindi riapplicare lo stile e la personalizzazione del modello.

Per altre info sui controlli delle app UWP, vedere Controlli per funzione, Elenco controlli e Linee guida per i controlli.

Linguaggio di progettazione in Windows 10

Esistono alcune differenze nel linguaggio di progettazione tra le app di Windows Phone Silverlight e le app di Windows 10. Per tutti i dettagli, vedere Progettazione. Nonostante i cambiamenti del linguaggio di progettazione, i nostri principi di progettazione rimangono coerenti: essere attenti ai dettagli, ma sempre cercare semplicità concentrandosi su contenuti non chrome, riducendo ferocemente gli elementi visivi e rimanendo autenticati nel dominio digitale; usare la gerarchia visiva soprattutto con tipografia; progettazione su una griglia; e portare le tue esperienze in vita con animazioni fluide.

Localizzazione e globalizzazione

Per le stringhe localizzate, si può riutilizzare il file .resx dal progetto di Windows Phone Silverlight nel progetto di app UWP. Copiare il file, aggiungerlo al progetto e rinominarlo in Resources.resw in modo che il meccanismo di ricerca lo trovi per impostazione predefinita. Impostare Azione di compilazione su PRIResource e Copia nella directory di output su Non copiare. Si possono quindi usare le stringhe nel markup specificando l'attributo x:Uid negli elementi XAML. Vedere Avvio rapido: Uso delle risorse stringa.

Le app di Windows Phone Silverlight usano la classe CultureInfo per globalizzare un'app. Le app UWP usano MRT (Modern Resource Technology), che consente il caricamento dinamico delle risorse dell'app (localizzazione, scalabilità e tema) sia in fase di esecuzione che nell'area di progettazione di Visual Studio. Per altre informazioni, vedere Linee guida per file, dati e globalizzazione.

L'argomento ResourceContext.QualifierValues descrive come caricare le risorse specifiche della famiglia di dispositivi in base al fattore di selezione delle risorse della famiglia di dispositivi.

Elementi multimediali e grafici

Mentre si leggono i contenuti multimediali e la grafica UWP, tenere presente che i principi di progettazione di Windows incoraggiano una feroce riduzione di qualsiasi elemento superfluo, tra cui complessità grafica e confusione. La progettazione di Windows è tipificata da oggetti visivi puliti e chiari, tipografici e in movimento. Se l'app segue gli stessi principi, sembrerà più simile alle app predefinite.

Windows Phone Silverlight ha un RadialGradientBrush che non è presente nella piattaforma UWP, anche se altri tipi sonoBrush. In alcuni casi, sarà possibile ottenere un effetto simile con una bitmap. Tenere presente che si può creare un pennello sfumatura radiale con Direct2D in una piattaforma UWP C++ Microsoft DirectX e XAML C++.

Windows Phone Silverlight ha la proprietà System.Windows.UIElement.OpacityMask ma tale proprietà non è un membro del tipo UIElement UWP. In alcuni casi, sarà possibile ottenere un effetto simile con una bitmap. E si può creare una maschera di opacità con Direct2D in un'app UWP Microsoft DirectX e XAML C++. Tuttavia, un caso d'uso comune per OpacityMask consiste nell'usare una singola bitmap che si adatta ai temi chiari e scuri. Per la grafica vettoriale, è possibile usare pennelli di sistema con riconoscimento del tema (ad esempio i grafici a torta illustrati di seguito). Tuttavia, per rendere una bitmap compatibile con il tema (ad esempio i segni di spunta illustrati di seguito), richiede un approccio diverso.

a theme-aware bitmap

In un'app di Windows Phone Silverlight, la tecnica consiste nell'usare una maschera alfa (sotto forma di bitmap) come OpacityMask per un rettangolo riempito con il pennello in primo piano:

    <Rectangle Fill="{StaticResource PhoneForegroundBrush}" Width="26" Height="26">
        <Rectangle.OpacityMask>
            <ImageBrush ImageSource="/Assets/wpsl_check.png"/>
        </Rectangle.OpacityMask>
    </Rectangle>

Il modo più semplice per convertirlo in un'app UWP consiste nell'usare BitmapIcon, come illustrato di seguito:

    <BitmapIcon UriSource="Assets/winrt_check.png" Width="21" Height="21"/>

In questo caso, winrt_check.png è una maschera alfa sotto forma di bitmap esattamente come wpsl_check.png e potrebbe essere molto bene lo stesso file. Tuttavia, è possibile specificare diverse dimensioni di winrt_check.png da usare per diversi fattori di ridimensionamento. Per altre info su questo e per una spiegazione delle modifiche apportate ai valori Width e Height, vedere Visualizzazione o pixel effettivi, distanza di visualizzazione e fattori di scala in questo argomento.

Un approccio più generico, appropriato se esistono differenze tra la forma del tema chiaro e scuro di una bitmap, consiste nell'usare due asset di immagine, uno con un primo piano scuro (per il tema chiaro) e uno con un primo piano chiaro (per il tema scuro). Per altri dettagli su come assegnare un nome a questo set di asset bitmap, vedere Personalizzare le risorse per linguaggio, scalabilità e altri qualificatori. Una volta che un set di file immagine è denominato correttamente, è possibile farvi riferimento nell'astrazione, usando il nome radice, come illustrato di seguito:

    <Image Source="Assets/winrt_check.png" Stretch="None"/>

In Windows Phone Silverlight, la proprietà UIElement.Clip può essere qualsiasi forma che puoi esprimere con un oggetto Geometry ed è in genere serializzata nel markup XAML nel mini-linguaggio StreamGeometry. Nella piattaforma UWP il tipo della proprietà Clip è RectangleGeometry, quindi puoi ritagliarne solo un'area rettangolare Consentire la definizione di un rettangolo usando il mini-linguaggio sarebbe troppo permissivo. Quindi, per convertire un'area di ritaglio nel markup, sostituire la sintassi dell'attributo Clip e impostarla in sintassi degli elementi di proprietà simile alla seguente:

    <UIElement.Clip>
        <RectangleGeometry Rect="10 10 50 50"/>
    </UIElement.Clip>

Tenere presente che si può usare una geometria arbitraria come maschera in un livello con Direct2D in un'app UWP Microsoft DirectX e XAML C++.

Quando si passa a una pagina in un'app di Windows Phone Silverlight, si usa uno schema di indirizzamento URI (Uniform Resource Identifier):

    NavigationService.Navigate(new Uri("/AnotherPage.xaml", UriKind.Relative)/*, navigationState*/);

In un'app UWP chiamare il metodo Frame.Navigate e si specifica il tipo della pagina di destinazione (come definito dall'attributo x:Class della definizione di markup XAML della pagina):

    // In a page:
    this.Frame.Navigate(typeof(AnotherPage)/*, parameter*/);

    // In a view model, perhaps inside an ICommand implementation:
    var rootFrame = Windows.UI.Xaml.Window.Current.Content as Windows.UI.Xaml.Controls.Frame;
    rootFrame.Navigate(typeof(AnotherPage)/*, parameter*/);

Definire la pagina di avvio per un'app di Windows Phone Silverlight in WMAppManifest.xml:

    <DefaultTask Name="_default" NavigationPage="MainPage.xaml" />

In un'app UWP si usa il codice imperativo per definire la pagina di avvio. Ecco alcuni codici di App.xaml.cs che illustrano come:

    if (!rootFrame.Navigate(typeof(MainPage), e.Arguments))

Il mapping URI e lo spostamento tra frammenti sono tecniche di spostamento URI e pertanto non sono applicabili alla navigazione UWP, che non è basata sugli URI. Il mapping URI esiste in risposta alla natura debole di identificazione di una pagina di destinazione con una stringa URI, che causa problemi di fragilità e manutenibilità se la pagina viene spostata in una cartella diversa e quindi in un percorso relativo diverso. Le app UWP usano la navigazione basata sui tipi, fortemente tipizzata e controllata dal compilatore e non presenta il problema risolto dal mapping URI. Il caso d'uso per la navigazione nel frammento consiste nel passare un contesto alla pagina di destinazione in modo che la pagina possa causare lo scorrimento di un particolare frammento del contenuto nella visualizzazione o in caso contrario visualizzato. Lo stesso obiettivo può essere raggiunto passando un parametro di navigazione quando si chiama il metodo Navigate.

Per altre informazioni, vedere Navigazione.

Riferimento alla chiave risorse

Il linguaggio di progettazione si è evoluto per Windows 10 e di conseguenza alcuni stili di sistema sono stati modificati e molte chiavi di risorse di sistema sono state rimosse o rinominate. L'editor di markup XAML in Visual Studio evidenzia i riferimenti alle chiavi di risorsa che non possono essere risolte. Ad esempio, l'editor di markup XAML sottolinea un riferimento alla chiave PhoneTextNormalStyle di stile con una sottolineatura ondulata rossa. Se questa operazione non è corretta, l'app terminerà immediatamente quando si tenta di distribuirlo nell'emulatore o nel dispositivo. È quindi importante partecipare alla correttezza del markup XAML. Visual Studio sarà uno strumento ideale per rilevare questi problemi.

Vedere anche Testo, di seguito.

Barra di stato (barra di sistema)

L'area di notifica (impostata nel markup XAML con shell:SystemTray.IsVisible) è ora denominata barra di stato ed è visualizzata per impostazione predefinita. È possibile controllarne la visibilità nel codice imperativo chiamando i metodiWindows.UI.ViewManagement.StatusBar.ShowAsync e HideAsync.

Testo

Testo (o tipografia) è un aspetto importante di un'app UWP e, durante la conversione, potresti voler rivedere le progettazioni visive delle visualizzazioni in modo che siano in armonia con il nuovo linguaggio di progettazione. Usare queste illustrazioni per trovare gli stili di sistema TextBlock UWP disponibili. Trovare quelli che corrispondono agli stili Windows Phone Silverlight usati. In alternativa, è possibile creare stili universali personalizzati e copiare le proprietà dagli stili di sistema Windows Phone Silverlight in quelli.

system textblock styles for windows 10 apps

Stili TextBlock di sistema per le app di Windows 10

In un'app di Windows Phone Silverlight, la famiglia di caratteri predefinita è Segoe WP. In un'app di Windows 10 la famiglia di caratteri predefinita è Segoe UI. Di conseguenza, le metriche dei tipi di carattere nell'app potrebbero avere un aspetto diverso. Se si vuole riprodurre l'aspetto del testo di Windows Phone Silverlight, si possono impostare metriche personalizzate usando proprietà come LineHeight e LineStackingStrategy. Per altre info, vedere Linee guida per i tipi di carattere e Progettare app UWP.

Modifiche al tema

Per un'app di Windows Phone Silverlight, il tema predefinito è scuro per impostazione predefinita. Per i dispositivi Windows 10, il tema predefinito è cambiato, ma puoi controllare il tema usato dichiarando un tema richiesto in App.xaml. Ad esempio, per usare un tema scuro in tutti i dispositivi, aggiungere RequestedTheme="Dark" all'elemento radice Application.

Sezioni

I riquadri per le app UWP hanno comportamenti simili ai riquadri animati per le app di Windows Phone Silverlight, anche se esistono alcune differenze. Ad esempio, codice che chiama il metodo Microsoft.Phone.Shell.ShellTile.Create per creare riquadri secondari deve essere convertito per chiamare SecondaryTile.RequestCreateAsync. Di seguito è riportato un esempio precedente e successivo, prima la versione di Windows Phone Silverlight:

    var tileData = new IconicTileData()
    {
        Title = this.selectedBookSku.Title,
        WideContent1 = this.selectedBookSku.Title,
        WideContent2 = this.selectedBookSku.Author,
        SmallIconImage = this.SmallIconImageAsUri,
        IconImage = this.IconImageAsUri
    };

    ShellTile.Create(this.selectedBookSku.NavigationUri, tileData, true);

E l'equivalente UWP:

    var tile = new SecondaryTile(
        this.selectedBookSku.Title.Replace(" ", string.Empty),
        this.selectedBookSku.Title,
        this.selectedBookSku.ArgumentString,
        this.IconImageAsUri,
        TileSize.Square150x150);

    await tile.RequestCreateAsync();

Codice che aggiorna un riquadro con il metodo Microsoft.Phone.Shell.ShellTile.Update o la classe Microsoft.Phone.Shell.ShellTileSchedule, deve essere convertito per usare le classi TileUpdateManager, TileUpdater, TileNotification e/o ScheduledTileNotification.

Per altre info su riquadri, avvisi popup, badge, banner e notifiche, vedere Creazione di riquadri e Lavorare con riquadri, badge e notifiche popup. Per informazioni specifiche sulle dimensioni degli asset visivi usati per i riquadri UWP, vedere Asset visivi riquadro e avviso popup.

Avviso popup

Codice che visualizza un avviso popup con la classe Microsoft.Phone.Shell.ShellToast deve essere convertito per usare le classi ToastNotificationManager, ToastNotifier, ToastNotification e/o ScheduledToastNotification. Si noti che nei dispositivi mobili, il termine rivolto all'utente per "avviso popup" è "banner".

Vedere Uso di riquadri, notifiche e notifiche di tipo avviso popup.

Pixel di visualizzazione o effettivi, distanza di visualizzazione e fattori di scala

Le app di Windows Phone Silverlight e le app di Windows 10 differiscono in modo da astrarre le dimensioni e il layout degli elementi dell'interfaccia utente dalla dimensione fisica effettiva e dalla risoluzione dei dispositivi. A tale scopo, un'app di Windows Phone Silverlight usa i pixel di visualizzazione. Con Windows 10, il concetto di pixel di visualizzazione è stato perfezionato in quello dei pixel effettivi. Ecco una spiegazione di questo termine, del significato e del valore aggiuntivo offerto.

Il termine "risoluzione" si riferisce a una misura della densità di pixel e non, come si pensa comunemente, numero di pixel. "Risoluzione efficace" è il modo in cui i pixel fisici che compongono un'immagine o un glifo risolvono nell'occhio le differenze nella distanza di visualizzazione e le dimensioni fisiche del pixel del dispositivo (densità di pixel è il reciproco delle dimensioni dei pixel fisici). La risoluzione efficace è una buona metrica per creare un'esperienza in quanto è incentrata sull'utente. Comprendendo tutti i fattori e controllando le dimensioni degli elementi dell'interfaccia utente, puoi rendere l'esperienza dell'utente un'esperienza ottimale.

Per un'app di Windows Phone Silverlight, tutte le schermate del telefono hanno una larghezza di 480 pixel di visualizzazione, senza eccezione, indipendentemente dal numero di pixel fisici dello schermo, né dalla densità dei pixel o dalle dimensioni fisiche. Ciò significa che un elemento Image con Width="48" sarà esattamente un decimo della larghezza dello schermo di qualsiasi telefono in grado di eseguire l'app Windows Phone Silverlight.

Per un'app di Windows 10, non è il caso che tutti i dispositivi siano larghi un numero fisso di pixel effettivi. Questo è probabilmente ovvio, data l'ampia gamma di dispositivi su cui un'app UWP può essere eseguita. I diversi dispositivi sono un numero diverso di pixel effettivi di larghezza, che vanno da 320 epx per i dispositivi più piccoli, a 1024 epx per un monitor di dimensioni modeste e molto oltre a larghezze molto più elevate. Tutto quello che si deve fare è continuare a usare elementi di dimensioni automatica e pannelli di layout dinamico come sempre. Ci saranno anche alcuni casi in cui imposti le proprietà degli elementi dell'interfaccia utente su una dimensione fissa nel markup XAML. Un fattore di scala viene applicato automaticamente all'app a seconda del dispositivo in cui viene eseguito e delle impostazioni di visualizzazione effettuate dall'utente. E questo fattore di scala serve a mantenere qualsiasi elemento dell'interfaccia utente con dimensioni fisse che presentano un tocco di dimensioni più o meno costanti (e lettura) per l'utente in un'ampia gamma di dimensioni dello schermo. E insieme al layout dinamico l'interfaccia utente non si limita a ridimensionare otticamente su dispositivi diversi, ma eseguirà ciò che è necessario per adattare la quantità appropriata di contenuto nello spazio disponibile.

Poiché 480 era in precedenza la larghezza fissa in pixel di visualizzazione per uno schermo di dimensioni del telefono e tale valore è ora in genere più piccolo in pixel effettivi, una regola di identificazione generale consiste nel moltiplicare qualsiasi dimensione nel markup dell'app di Windows Phone Silverlight per un fattore pari a 0,8.

In modo che l'app abbia l'esperienza migliore in tutti i display, consigliamo di creare ogni asset bitmap in un intervallo di dimensioni, ognuno adatto a un fattore di scala specifico. Fornire asset su scala 100%, 200%-scale e 400%-scale (in tale ordine di priorità) darà risultati eccellenti nella maggior parte dei casi a tutti i fattori di scala intermedi.

Nota Se, per qualsiasi motivo, non è possibile creare asset con più di una dimensione, quindi creare asset con scalabilità pari al 100%. In Microsoft Visual Studio, il modello di progetto predefinito per le app UWP fornisce asset di personalizzazione (immagini e logo dei riquadri) in una sola dimensione, ma non sono 100%-scale. Quando si creano asset per la propria app, seguire le indicazioni riportate in questa sezione e fornire dimensioni del 100%, del 200% e del 400% e usare i pacchetti di asset.

Se si ha un'opera d'arte complessa, si potrebbe voler fornire gli asset in dimensioni ancora più elevate. Se si inizia con l'arte vettoriale, è relativamente facile generare asset di alta qualità in qualsiasi fattore di scala.

Sconsigliamo di provare a supportare tutti i fattori di scala, ma l'elenco completo dei fattori di scala per le app di Windows 10 è 100%, 125%, 150%, 200%, 250%, 300% e 400%. Se li si fornisce, lo Store sceglierà gli asset di dimensioni corrette per ogni dispositivo e verranno scaricati solo gli asset. Lo Store seleziona gli asset da scaricare in base alla DPI del dispositivo.

Per altre informazioni, vedere Tutto sul responsive design 101 per app UWP.

Dimensioni finestra

Nell'app UWP si può specificare una dimensione minima (larghezza e altezza) con codice imperativo. La dimensione minima predefinita è 500x320epx ed è anche la dimensione minima minima più piccola accettata. La dimensione minima massima accettata è 500x500epx.

   Windows.UI.ViewManagement.ApplicationView.GetForCurrentView().SetPreferredMinSize
        (new Size { Width = 500, Height = 500 });

L'argomento successivo è Conversione per I/O, dispositivo e modello di app.