Panoramica di XAML

Questo articolo presenta il linguaggio XAML e concetti XAML agli sviluppatori di app di Windows Runtime e descrive i diversi modi possibili per dichiarare oggetti e impostare attributi in XAML per la creazione di app di Windows Runtime.

Che cos'è XAML?

XAML (Extensible Application Markup Language) è un linguaggio dichiarativo. In particolare, XAML può inizializzare gli oggetti e impostare le proprietà degli oggetti usando una struttura del linguaggio che mostra relazioni gerarchiche tra più oggetti e una convenzione di tipo di supporto che supporta l'estensione dei tipi. È possibile creare elementi dell'interfaccia utente visibili nel markup XAML dichiarativo. È quindi possibile associare un file code-behind separato per ogni file XAML in grado di rispondere agli eventi e modificare gli oggetti dichiarati originariamente in XAML.

Il linguaggio XAML supporta l'interscambio di origini tra diversi strumenti e ruoli nel processo di sviluppo, ad esempio lo scambio di origini XAML tra gli strumenti di progettazione e un ambiente di sviluppo interattivo (IDE) o tra sviluppatori primari e sviluppatori di localizzazione. Usando XAML come formato di interscambio, i ruoli della finestra di progettazione e i ruoli di sviluppatore possono essere mantenuti separati o riuniti e i progettisti e gli sviluppatori possono scorrere durante la produzione di un'app.

Quando vengono visualizzati come parte dei progetti di app di Windows Runtime, i file XAML sono file XML con estensione .xaml.

Sintassi XAML di base

XAML ha una sintassi di base basata su XML. Per definizione, XAML valido deve essere anche XML valido. Ma XAML ha anche concetti di sintassi assegnati a un significato diverso e più completo, pur essendo ancora validi in XML in base alla specifica XML 1.0. Ad esempio, XAML supporta la sintassi degli elementi di proprietà, in cui i valori delle proprietà possono essere impostati all'interno di elementi anziché come valori stringa negli attributi o come contenuto. Per il codice XML normale, un elemento della proprietà XAML è un elemento con un punto nel nome, pertanto è valido per XML normale, ma non ha lo stesso significato.

XAML e Visual Studio

Microsoft Visual Studio consente di produrre una sintassi XAML valida, sia nell'editor di testo XAML che nell'area di progettazione XAML più orientata graficamente. Quando si scrive XAML per l'app usando Visual Studio, non ci si deve preoccupare troppo della sintassi con ogni sequenza di tasti. IDE incoraggia la sintassi XAML valida fornendo suggerimenti per il completamento automatico, visualizzando suggerimenti negli elenchi e negli elenchi a discesa di Microsoft IntelliSense, mostrando le librerie degli elementi dell'interfaccia utente nella finestra della casella degli strumenti o altre tecniche. Se si tratta della prima esperienza con XAML, potrebbe comunque essere utile conoscere le regole di sintassi e in particolare la terminologia usata a volte per descrivere le restrizioni o le scelte quando si descrive la sintassi XAML in riferimento o altri argomenti. I punti dettagliati della sintassi XAML sono trattati in un argomento separato, guida alla sintassi XAML.

Spazi dei nomi XAML

Nella programmazione generale, uno spazio dei nomi è un concetto di organizzazione che determina come vengono interpretati gli identificatori per le entità di programmazione. Usando gli spazi dei nomi, un framework di programmazione può separare gli identificatori dichiarati dall'utente da identificatori dichiarati dal framework, disambiguare gli identificatori tramite qualifiche dello spazio dei nomi, applicare regole per i nomi di ambito e così via. XAML ha il proprio concetto di spazio dei nomi XAML che serve a questo scopo per il linguaggio XAML. Ecco come XAML applica ed estende i concetti relativi allo spazio dei nomi del linguaggio XML:

• XAML usa i xmln dell'attributo XML riservati per le dichiarazioni dello spazio dei nomi. Il valore dell'attributo è in genere un URI (Uniform Resource Identifier), che è una convenzione ereditata da XML.
• XAML usa prefissi nelle dichiarazioni per dichiarare gli spazi dei nomi non predefiniti e i prefissi negli elementi e negli attributi fanno riferimento a tale spazio dei nomi.
• XAML ha un concetto di spazio dei nomi predefinito, ovvero lo spazio dei nomi usato quando non esiste alcun prefisso in un utilizzo o una dichiarazione. Lo spazio dei nomi predefinito può essere definito in modo diverso per ogni framework di programmazione XAML.
• Le definizioni dello spazio dei nomi ereditano in un file o un costrutto XAML dall'elemento padre all'elemento figlio. Ad esempio, se si definisce uno spazio dei nomi nell'elemento radice di un file XAML, tutti gli elementi all'interno del file ereditano tale definizione dello spazio dei nomi. Se un elemento più avanti nella pagina ridefinisce lo spazio dei nomi, i discendenti dell'elemento ereditano la nuova definizione.
• Gli attributi di un elemento ereditano gli spazi dei nomi dell'elemento. È piuttosto insolito vedere i prefissi sugli attributi XAML.

Un file XAML dichiara quasi sempre uno spazio dei nomi XAML predefinito nel relativo elemento radice. Lo spazio dei nomi XAML predefinito definisce gli elementi che si possono dichiarare senza qualificarli con un prefisso. Per i progetti di app di Windows Runtime tipici, questo spazio dei nomi predefinito contiene tutto il vocabolario XAML predefinito per Windows Runtime usato per le definizioni dell'interfaccia utente: controlli predefiniti, elementi di testo, grafica XAML e animazioni, associazione dati e tipi di supporto per stili e così via. La maggior parte del codice XAML che verrà scritto per le app di Windows Runtime sarà quindi in grado di evitare di usare spazi dei nomi e prefissi XAML quando si fa riferimento a elementi comuni dell'interfaccia utente.

Ecco un frammento di codice che mostra una radice creata dal modello Page della pagina iniziale per un'app (che mostra solo il tag di apertura e semplificato). Dichiara lo spazio dei nomi predefinito e anche lo spazio dei nomi x (che verrà illustrato di seguito).

<Page
    x:Class="Application1.BlankPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>

Spazio dei nomi XAML in linguaggio XAML

Uno spazio dei nomi XAML specifico dichiarato in quasi tutti i file XAML di Windows Runtime è lo spazio dei nomi del linguaggio XAML. Questo spazio dei nomi include elementi e concetti definiti dalla specifica del linguaggio XAML. Per convenzione, lo spazio dei nomi XAML del linguaggio XAML viene mappato al prefisso "x". I modelli di progetto e file predefiniti per i progetti di app Windows Runtime definiscono sempre sia lo spazio dei nomi XAML predefinito (senza prefisso, solo xmlns=) che lo spazio dei nomi XAML in linguaggio XAML (prefisso "x") come parte dell'elemento radice.

Lo spazio dei nomi XAML per il linguaggio "x" prefix/XAML contiene diversi costrutti di programmazione che verranno usati frequentemente in XAML. Ecco i più comuni:

Termine	Descrizione
x:Key	Imposta una chiave univoca definita dall'utente per ogni risorsa in un codice XAML ResourceDictionary. La stringa del token della chiave è l'argomento per l'estensione di markup StaticResource e questa chiave viene usata in un secondo momento per recuperare la risorsa XAML da un altro utilizzo XAML altrove nel codice XAML dell'app.
x:Class	Specifica lo spazio dei nomi codice e il nome della classe codice che offre il code-behind per una pagina XAML. Questo assegna un nome alla classe creata o aggiunta dalle azioni di compilazione durante la compilazione dell'app. Queste azioni di compilazione supportano il compilatore di markup XAML e combinano il markup e il code-behind quando l'app viene compilata. È necessario avere una classe di questo tipo per supportare il code-behind per una pagina XAML. Window.Content nel modello di attivazione di Windows Runtime predefinito.
x:Name	Specifica il nome di un oggetto di runtime per l'istanza presente nel codice della fase di esecuzione dopo l'elaborazione di un elemento definito in XAML. Si può pensare di impostare x:Name in XAML come dichiarare una variabile denominata nel codice. Come si apprenderà più avanti, questo è esattamente ciò che accade quando il codice XAML viene caricato come componente di un'app di Windows Runtime. NotaName è una proprietà simile nel framework, ma non tutti gli elementi la supportano. Usare x:Name per l'identificazione degli elementi ogni volta che FrameworkElement.Name non è supportato in tale tipo di elemento.
x:Uid	Identifica gli elementi che devono usare risorse localizzate per alcuni dei relativi valori di proprietà. Per altre info su come usare x:Uid, vedere Avvio rapido: Traduzione delle risorse dell'interfaccia utente.
Tipi di dati intrinseci XAML	Questi tipi possono specificare valori per i tipi valore semplici quando è necessario per un attributo o una risorsa. Questi tipi intrinseci corrispondono ai tipi valore semplici definiti in genere come parte delle definizioni intrinseche di ogni linguaggio di programmazione. Ad esempio, potrebbe essere necessario un oggetto che rappresenta un valore booleano true da usare in uno ObjectAnimationUsingKeyFrames stato di visualizzazione con storyboard. Per tale valore in XAML, si userà il tipo intrinseco x:Boolean come elemento dell'oggetto, come illustrato di seguito: <x:Boolean>True</x:Boolean>

Esistono altri costrutti di programmazione nello spazio dei nomi XAML del linguaggio XAML, ma non sono altrettanto comuni.

Mapping di tipi personalizzati agli spazi dei nomi XAML

Uno degli aspetti più potenti di XAML come linguaggio è che è facile estendere il vocabolario XAML per le app di Windows Runtime. Si possono definire tipi personalizzati nel linguaggio di programmazione dell'app e quindi fare riferimento ai tipi personalizzati nel markup XAML. Il supporto per l'estensione tramite tipi personalizzati è fondamentalmente integrato per il funzionamento del linguaggio XAML. I framework o gli sviluppatori di app sono responsabili della creazione degli oggetti di backup a cui fa riferimento XAML. Né i framework né gli sviluppatori di app sono vincolati dalle specifiche di ciò che gli oggetti nei loro vocabolari rappresentano o fanno oltre le regole di sintassi XAML di base. Ci sono alcune aspettative sulle operazioni che devono essere eseguite dai tipi di spazio dei nomi XAML in linguaggio XAML, ma Windows Runtime offre tutto il supporto necessario.

Se si usa XAML per i tipi provenienti da librerie diverse dalle librerie di base e dai metadati di Windows Runtime, si deve dichiarare ed eseguire il mapping di uno spazio dei nomi XAML con un prefisso. Usare tale prefisso negli utilizzi degli elementi per fare riferimento ai tipi definiti nella libreria. I mapping dei prefissi vengono dichiarati come attributi xmlns, in genere in un elemento radice insieme alle altre definizioni dello spazio dei nomi XAML.

Per creare una definizione dello spazio dei nomi personalizzata che faccia riferimento a tipi personalizzati, specificare prima la parola chiave xmlns:, quindi il prefisso desiderato. Il valore di tale attributo deve contenere la parola chiave using: come prima parte del valore. Il resto del valore è un token stringa che fa riferimento allo spazio dei nomi di backup del codice specifico che contiene i tipi personalizzati, in base al nome.

Il prefisso definisce il token di markup usato per fare riferimento allo spazio dei nomi XAML nel resto del markup nel file XAML. Un carattere due punti (:) passa tra il prefisso e l'entità a cui fare riferimento all'interno dello spazio dei nomi XAML.

Ad esempio, la sintassi dell'attributo per eseguire il mapping di un prefisso myTypes allo spazio dei nomi myCompany.myTypes è: xmlns:myTypes="using:myCompany.myTypes" e l'utilizzo di un elemento rappresentativo è: <myTypes:CustomButton/>

Per altre info sul mapping degli spazi dei nomi XAML per i tipi personalizzati, incluse considerazioni speciali per le estensioni del componente Visual C++ (C++/CX), vedere Spazi dei nomi XAML e mapping degli spazi dei nomi.

Altri spazi dei nomi XAML

Spesso vengono visualizzati file XAML che definiscono i prefissi "d" (per lo spazio dei nomi della finestra di progettazione) e "mc" (per la compatibilità del markup). In genere, questi sono per il supporto dell'infrastruttura o per abilitare scenari in uno strumento in fase di progettazione. Per altre info, vedere la sezione "Altri spazi dei nomi XAML" dell'argomento Spazi dei nomi XAML.

Estensioni di markup

Le estensioni di markup sono un concetto di linguaggio XAML che viene spesso usato nell'implementazione XAML di Windows Runtime. Le estensioni di markup spesso rappresentano un tipo di "collegamento" che consente a un file XAML di accedere a un valore o a un comportamento che non dichiara semplicemente elementi in base ai tipi di supporto. Alcune estensioni di markup possono impostare proprietà con stringhe semplici o con elementi annidati aggiuntivi, con l'obiettivo di slining della sintassi o del factoring tra file XAML diversi.

Nella sintassi degli attributi XAML le parentesi graffe "{" e "}" indicano un utilizzo dell'estensione di markup XAML. Questo uso indica all'elaborazione XAML che, diversamente dal solito, i valori degli attributi di treating non devono essere considerati valori di stringa letterale o valori direttamente convertibili in stringa. Un parser XAML chiama invece il codice che fornisce il comportamento per tale estensione di markup e tale codice fornisce un oggetto o un risultato di comportamento alternativo necessario al parser XAML. Le estensioni di markup possono avere argomenti, che seguono il nome dell'estensione di markup e sono contenuti anche all'interno delle parentesi graffe. In genere, un'estensione di markup valutata fornisce un valore restituito dall'oggetto. Durante l'analisi, tale valore restituito viene inserito nella posizione nell'albero di oggetti in cui l'utilizzo dell'estensione di markup si trovava nel codice XAML di origine.

XAML di Windows Runtime supporta queste estensioni di markup definite nello spazio dei nomi XAML predefinito e sono riconosciute dal parser XAML di Windows Runtime:

• {x:Bind}: supporta il data binding, che rinvia la valutazione delle proprietà fino alla fase di esecuzione eseguendo codice speciale, generato in fase di compilazione. Questa estensione di markup supporta un'ampia gamma di argomenti.
• {Binding}: supporta il data binding, che rinvia la valutazione delle proprietà fino alla fase di esecuzione eseguendo l'ispezione degli oggetti di runtime per utilizzo generico. Questa estensione di markup supporta un'ampia gamma di argomenti.
• {StaticResource}: supporta il riferimento ai valori delle risorse definiti in un oggetto ResourceDictionary. Queste risorse possono trovarsi in un file XAML diverso, ma devono essere individuabili dal parser XAML in fase di caricamento. L'argomento di un utilizzo {StaticResource} identifica la chiave (il nome) per una risorsa con chiave in un oggetto ResourceDictionary.
• {ThemeResource}: simile a {StaticResource} ma può rispondere alle modifiche del tema di runtime. {ThemeResource} viene visualizzato molto spesso nei modelli XAML predefiniti di Windows Runtime, perché la maggior parte di questi modelli è progettata per la compatibilità con l'utente che cambia il tema mentre l'app è in esecuzione.
• {TemplateBinding}: un caso speciale di {Binding} che supporta i modelli di controllo in XAML e l'utilizzo finale in fase di esecuzione.
• {RelativeSource}: abilita una particolare forma di associazione di modelli in cui i valori provengono dall'elemento padre basato su modelli.
• {CustomResource}: per scenari avanzati di ricerca delle risorse.

Windows Runtime supporta anche l'estensione di markup {x:Null}. Questa opzione viene usata per impostare i valori Nullable su Null in XAML. Ad esempio, è possibile usarlo in un modello di controllo per un oggetto CheckBox, che interpreta null come stato di controllo indeterminato (attivando lo stato di visualizzazione "Indeterminate").

Un'estensione di markup restituisce in genere un'istanza esistente da un'altra parte dell'oggetto grafico per l'app o rinvia un valore per l'esecuzione. Poiché è possibile usare un'estensione di markup come valore dell'attributo ed è l'utilizzo tipico, spesso vengono visualizzate estensioni di markup che forniscono valori per le proprietà di tipo riferimento che potrebbero altrimenti richiedere una sintassi di un elemento di proprietà.

Ecco ad esempio la sintassi per fare riferimento a un oggetto riutilizzabile Style da ResourceDictionary: <Button Style="{StaticResource SearchButtonStyle}"/>. Un Style è un tipo di riferimento, non un valore semplice, quindi senza l'utilizzo {StaticResource}, è necessario un <Button.Style> elemento della proprietà e una <Style> definizione all'interno di esso per impostare la proprietà FrameworkElement.Style.

Usando le estensioni di markup, ogni proprietà impostabile in XAML può essere impostata nella sintassi degli attributi. È possibile usare la sintassi degli attributi per fornire valori di riferimento per una proprietà anche se in caso contrario non supporta una sintassi dell'attributo per la creazione diretta di istanze di oggetti. In alternativa, è possibile abilitare un comportamento specifico che sgonfia il requisito generale che le proprietà XAML vengano riempite dai tipi valore o dai nuovi tipi di riferimento creati.

Per illustrare, l'esempio XAML successivo imposta il valore della FrameworkElement.Style proprietà di un Border usando la sintassi degli attributi. La proprietà FrameworkElement.Style accetta un'istanza della classe Windows.UI.Xaml.Style, un tipo di riferimento che per impostazione predefinita non è stato possibile creare usando una stringa di sintassi per attributi. Tuttavia, in questo caso l'attributo fa riferimento a una particolare estensione di markup, StaticResource. Quando quell'estensione di markup viene elaborata, restituisce un riferimento a un elemento Stile del quale in precedenza è stata definita un'istanza come risorsa con chiave in un dizionario di risorse.

<Canvas.Resources>
  <Style TargetType="Border" x:Key="PageBackground">
    <Setter Property="BorderBrush" Value="Blue"/>
    <Setter Property="BorderThickness" Value="5"/>
  </Style>
</Canvas.Resources>
...
<Border Style="{StaticResource PageBackground}">
  ...
</Border>

È possibile annidare le estensioni di markup. L'estensione di markup più interna viene valutata per prima.

A causa delle estensioni di markup, è necessaria una sintassi speciale per un valore letterale "{" in un attributo. Per maggiori informazioni, vedere guida alla sintassi XAML.

Eventi

XAML è un linguaggio dichiarativo per gli oggetti e le relative proprietà, ma include anche una sintassi per associare gestori eventi agli oggetti nel markup. La sintassi degli eventi XAML può quindi integrare gli eventi dichiarati da XAML tramite il modello di programmazione Windows Runtime. Specificare il nome dell'evento come nome di attributo nell'oggetto in cui viene gestito l'evento. Per il valore dell'attributo, specificare il nome di una funzione del gestore eventi definita nel codice. Il processore XAML usa questo nome per creare una rappresentazione del delegato nell'albero degli oggetti caricati e aggiunge il gestore specificato a un elenco di gestori interno. Quasi tutte le app di Windows Runtime sono definite da origini di markup e code-behind.

Ecco un semplice esempio. La classe Button supporta un evento denominato Click. È possibile scrivere un gestore per Click che esegue il codice che deve essere richiamato dopo che l'utente fa clic sul pulsante. In XAML si specifica Click come attributo nel pulsante. Per il valore dell'attributo, specificare una stringa che corrisponde al nome del metodo del gestore.

<Button Click="showUpdatesButton_Click">Show updates</Button>

Quando si esegue la compilazione, il compilatore prevede ora che nel file code-behind sia definito un metodo denominato showUpdatesButton_Click nello spazio dei nomi dichiarato nel valore x:Class della pagina XAML. Inoltre, tale metodo deve soddisfare il contratto delegato per l'evento Click. Ad esempio:

namespace App1
{
    public sealed partial class MainPage: Page {
        ...
        private void showUpdatesButton_Click (object sender, RoutedEventArgs e) {
            //your code
        }
    }
}

' Namespace included at project level
Public NotInheritable Class MainPage
    Inherits Page
        ...
        Private Sub showUpdatesButton_Click (sender As Object, e As RoutedEventArgs e)
            ' your code
        End Sub
    ...
End Class

namespace winrt::App1::implementation
{
    struct MainPage : MainPageT<MainPage>
    {
        ...
        void showUpdatesButton_Click(Windows::Foundation::IInspectable const&, Windows::UI::Xaml::RoutedEventArgs const&);
    };
}

// .h
namespace App1
{
    public ref class MainPage sealed {
        ...
    private:
        void showUpdatesButton_Click(Object^ sender, RoutedEventArgs^ e);
    };
}

All'interno di un progetto, il codice XAML viene scritto come file con estensione .xaml e si usa il linguaggio preferito (C#, Visual Basic, C++/CX) per scrivere un file code-behind. Durante la compilazione dal markup di un file XAML come parte di un'aione compilata per il progetto, il percorso del file code-behind XAML per ogni pagina XAML viene identificato specificando uno spazio dei nomi e una classe come attributo x:Class dell'elemento radice della pagina XAML. Per altre info sul funzionamento di questi meccanismi in XAML e sul modo in cui sono correlati ai modelli di programmazione e di applicazione, vedere Panoramica degli eventi e degli eventi indirizzati.

Nota

Per C++/CX sono presenti due file code-behind: uno è un'intestazione (.xaml.h) e l'altra è implementazione (.xaml.cpp). L'implementazione fa riferimento all'intestazione ed è tecnicamente l'intestazione che rappresenta il punto di ingresso per la connessione code-behind.

Dizionari di risorse

La creazione di un oggetto ResourceDictionary è un'attività comune che viene in genere eseguita creando un dizionario risorse come area di una pagina XAML o un file XAML separato. I dizionari risorse e come usarli sono un'area concettuale più ampia che non rientra nell'ambito di questo argomento. Per altre informazioni vedere Riferimenti a ResourceDictionary e risorse XAML.

XAML e XML

Il linguaggio XAML è fondamentalmente basato sul linguaggio XML. XAML estende in modo significativo il codice XML. In particolare tratta il concetto di schema in modo molto diverso a causa della relazione con il concetto di tipo di supporto e aggiunge elementi del linguaggio come membri associati ed estensioni di markup. xml:lang è valido in XAML, ma influenza il runtime anziché il comportamento di analisi ed è in genere aliasato a una proprietà a livello di framework. Per altre informazioni, vedi FrameworkElement.Language. xml:base è valido nel markup, ma i parser lo ignorano. xml:space è valido, ma è rilevante solo per gli scenari descritti nell'argomento XAML e spazi vuoti. L'attributo di codifica è valido in XAML. Sono supportate solo le codifiche UTF-8 e UTF-16. La codifica UTF-32 non è supportata.

Distinzione tra maiuscole e minuscole in XAML

Nel linguaggio XAML viene fatta distinzione tra maiuscole e minuscole. Si tratta di un'altra conseguenza dell'uso di XAML basato su XML, che fa distinzione tra maiuscole e minuscole. I nomi degli elementi e degli attributi XAML fanno distinzione tra maiuscole e minuscole. Il valore di un attributo fa potenzialmente distinzione tra maiuscole e minuscole; questo dipende dalla modalità di gestione del valore dell'attributo per proprietà specifiche. Ad esempio, se il valore dell'attributo dichiara un nome membro di un'enumerazione, il comportamento predefinito che converte una stringa di nome membro per restituire il valore del membro di enumerazione non fa distinzione tra maiuscole e minuscole. Al contrario, il valore della proprietà Name e i metodi di utilità per l'utilizzo di oggetti in base al nome dichiarato dalla proprietà Name, considerano la stringa del nome come distinzione tra maiuscole e minuscole.

Ambiti dei nomi XAML

Il linguaggio XAML definisce un concetto di ambito dei nomi XAML. Il concetto di ambito dei nomi XAML influisce sul modo in cui i processori XAML devono considerare il valore di x:Name o Name applicati agli elementi XAML, in particolare gli ambiti in cui i nomi devono essere considerati identificatori univoci. Gli ambiti dei nomi XAML sono trattati in modo più dettagliato in un argomento separato; vedere Ambiti dei nomi XAML.

Ruolo di XAML nel processo di sviluppo

XAML svolge diversi ruoli importanti nel processo di sviluppo dell'app.

• XAML è il formato principale per dichiarare l'interfaccia utente e gli elementi di un'app nell'interfaccia utente, se si sta programmando con C#, Visual Basic o C++/CX. In genere almeno un file XAML nel progetto rappresenta una metafora della pagina nell'app per l'interfaccia utente inizialmente visualizzata. Altri file XAML potrebbero dichiarare pagine aggiuntive per l'interfaccia utente di spostamento. Altri file XAML possono dichiarare risorse, ad esempio modelli o stili.
• Usare il formato XAML per dichiarare stili e modelli applicati ai controlli e all'interfaccia utente per un'app.
• È possibile usare stili e modelli per la creazione di modelli di controlli esistenti o se si definisce un controllo che fornisce un modello predefinito come parte di un pacchetto di controlli. Quando lo usi per definire stili e modelli, il codice XAML pertinente viene spesso dichiarato come file XAML discreto con una radice ResourceDictionary.
• XAML è il formato comune per il supporto della finestra di progettazione per la creazione dell'interfaccia utente e lo scambio della progettazione dell'interfaccia utente tra app di progettazione diverse. In particolare, XAML per l'app può essere interscambiato tra diversi strumenti di progettazione XAML (o finestre di progettazione all'interno degli strumenti).
• Diverse altre tecnologie definiscono anche l'interfaccia utente di base in XAML. In relazione con XAML di Windows Presentation Foundation (WPF) e XAML di Microsoft Silverlight, XAML per Windows Runtime usare lo stesso URI per lo spazio dei nomi XAML predefinito condiviso. Il vocabolario XAML per Windows Runtime si sovrappone in modo significativo al vocabolario XAML per l'interfaccia utente usata anche da Silverlight e in misura leggermente inferiore da WPF. XAML promuove quindi un percorso di migrazione efficiente per l'interfaccia utente originariamente definito per le tecnologie precursori che usavano anche XAML.
• XAML definisce l'aspetto visivo di un'interfaccia utente e un file code-behind associato definisce la logica. È possibile modificare la progettazione dell'interfaccia utente senza apportare modifiche alla logica nel code-behind. XAML semplifica il flusso di lavoro tra progettisti e sviluppatori.
• Grazie alla ricchezza della finestra di progettazione visiva e del supporto dell'area di progettazione per il linguaggio XAML, XAML supporta la creazione rapida di prototipi dell'interfaccia utente nelle fasi di sviluppo iniziali.

A seconda del proprio ruolo nel processo di sviluppo, è possibile che non si interagisca molto con XAML. Il grado di interazione con i file XAML dipende anche dall'ambiente di sviluppo in uso, dal fatto che si usino funzionalità interattive dell'ambiente di progettazione, ad esempio strumenti e editor di proprietà, nonché l'ambito e lo scopo dell'app di Windows Runtime. Tuttavia, è probabile che durante lo sviluppo dell'app, si modificherà un file XAML a livello di elemento usando un editor di testo o XML. Usando queste informazioni, si può modificare in modo sicuro XAML in una rappresentazione di testo o XML e mantenere la validità delle dichiarazioni e dello scopo del file XAML quando viene utilizzato dagli strumenti, dalle operazioni di compilazione del markup o dalla fase di runtime dell'app di Windows Runtime.

Ottimizzare il codice XAML per le prestazioni di caricamento

Ecco alcuni suggerimenti per definire gli elementi dell'interfaccia utente in XAML usando le procedure consigliate per le prestazioni. Molti di questi suggerimenti si riferiscono all'uso delle risorse XAML, ma sono elencati qui nella panoramica generale di XAML per praticità. Per altre informazioni sulle risorse XAML, vedere Riferimenti a ResourceDictionary e risorse XAML. Per altri suggerimenti sulle prestazioni, tra cui XAML che illustra appositamente alcune delle procedure di prestazioni non ottimali da evitare nel codice XAML, vedere Ottimizzare il markup XAML.

• Se usi spesso lo stesso pennello di colore nel codice XAML, definire una risorsa SolidColorBrush anziché usare un colore denominato come valore di attributo ogni volta.
• Se si usa la stessa risorsa in più pagine dell'interfaccia utente, è consigliabile definirla in Resources anziché in ogni pagina. Viceversa, se una sola pagina usa una risorsa, non definirla in Application.Resources e definirla solo per la pagina che lo richiede. Questo è utile sia per il factoring XAML durante la progettazione dell'app che per le prestazioni durante l'analisi XAML.
• Per le risorse incluse nei pacchetti dell'app, verificare la presenza di risorse inutilizzate (una risorsa con una chiave, ma non esiste alcun riferimento StaticResource nell'app che la usa). Rimuovere questi elementi dal codice XAML prima di rilasciare l'app.
• Se si usano file XAML separati che forniscono risorse di progettazione (MergedDictionaries), prendere in considerazione la possibilità di commentare o rimuovere risorse inutilizzate da questi file. Anche se si ha un punto di partenza XAML condiviso che si sta usando in più di un'app o che fornisce risorse comuni per tutta l'app, è ancora l'app che crea pacchetti ogni volta le risorse XAML e potenzialmente deve caricarle.
• Non definire elementi dell'interfaccia utente non necessari per la composizione e usare i modelli di controllo predefiniti quando possibile (questi modelli sono già stati testati e verificati per le prestazioni di caricamento).
• Usare contenitori come Border invece di ridisegnare deliberatamente gli elementi dell'interfaccia utente. Fondamentalmente, non disegnare lo stesso pixel più volte. Per altre info su overdraw e su come testarlo, vedere DebugSettings.IsOverdrawHeatMapEnabled.
• Usare i modelli di elementi predefiniti per ListView o GridView. Questi presentano una logica speciale del relatore che risolve i problemi di prestazioni durante la compilazione della struttura ad albero visuale per un numero elevato di elementi di elenco.

Eseguire il debug di XAML

Poiché XAML è un linguaggio di markup, alcune delle strategie tipiche per il debug in Microsoft Visual Studio non sono disponibili. Ad esempio, non è possibile impostare un punto di interruzione all'interno di un file XAML. Esistono tuttavia altre tecniche che consentono di eseguire il debug dei problemi relativi alle definizioni dell'interfaccia utente o ad altri markup XAML durante lo sviluppo dell'app.

Quando si verificano problemi con un file XAML, il risultato più tipico è che alcuni sistemi o l'app genereranno un'eccezione di analisi XAML. Ogni volta che si verifica un'eccezione di analisi XAML, il codice XAML caricato dal parser XAML non è riuscito a creare un albero di oggetti valido. In alcuni casi, ad esempio quando XAML rappresenta la prima "pagina" dell'applicazione caricata come oggetto visivo radice, l'eccezione di analisi XAML non è recuperabile.

XAML viene spesso modificato all'interno di un IDE, ad esempio Visual Studio e una delle relative aree di progettazione XAML. Visual Studio può spesso fornire la convalida in fase di progettazione e il controllo degli errori di un'origine XAML durante la modifica. Ad esempio, potrebbe essere visualizzato "squiggles" nell'editor di testo XAML non appena si digita un valore di attributo non valido e non sarà nemmeno necessario attendere che un passaggio di compilazione XAML verifichi che qualcosa non sia corretto con la definizione dell'interfaccia utente.

Una volta effettivamente eseguita l'app, se eventuali errori di analisi XAML non sono stati rilevati in fase di progettazione, questi vengono segnalati da Common Language Runtime (CLR) come XamlParseException. Per altre informazioni su ciò che si potrebbe essere in grado di eseguire per un'eccezione XamlParseException in fase di esecuzione, vedere Gestione delle eccezioni per le app di Windows Runtime in C# o Visual Basic.

Nota

Le app che usano C++/CX per il codice non ottengono l'eccezione XamlParseException specifica. Tuttavia, il messaggio nell'eccezione chiarisce che l'origine dell'errore è correlata a XAML e include informazioni di contesto come i numeri di riga in un file XAML, proprio come XamlParseException.

Per altre info sul debug di un'app di Windows Runtime, vedere Avviare una sessione di debug.