Panoramica su XAML

Panoramica su XAML

[ Questo articolo è rivolto agli sviluppatori per Windows 8.x e Windows Phone 8.x che realizzano app di Windows Runtime. Gli sviluppatori che usano Windows 10 possono vedere Documentazione aggiornata ]

In questo argomento presentiamo il linguaggio XAML e i relativi concetti agli sviluppatori di app di Windows Runtime e descriviamo i diversi modi in cui dichiarare oggetti e impostare attributi in XAML per la creazione di app di Windows Runtime.

Che cos'è XAML?

XAML, acronimo di eXtensible Application Markup Language, è un linguaggio dichiarativo. In particolare, XAML consente di inizializzare oggetti e impostarne le proprietà, mediante una struttura di linguaggio che mostra le relazioni gerarchiche tra più oggetti e una convenzione dei tipi di supporto che supporta l'estensione dei tipi. Nel markup XAML dichiarativo puoi creare elementi dell'interfaccia utente visibili. Puoi quindi associare un file code-behind distinto a ogni file XAML per rispondere agli eventi e modificare gli oggetti originariamente dichiarati in XAML.

Il linguaggio XAML supporta lo scambio di origini tra strumenti e ruoli diversi durante il processo di sviluppo, ad esempio lo scambio di origini XAML tra strumenti di progettazione e un IDE oppure tra sviluppatori principali e sviluppatori addetti alla localizzazione. Usando XAML come formato di scambio, è possibile separare o unire i ruoli di progettista e sviluppatore, che possono alternarsi durante la produzione di un'app.

Quando li vedi come parte dei progetti di app di Windows Runtime, i file XAML sono file XML con l'estensione del nome di file .xaml.

Sintassi XAML di base

La sintassi di base del linguaggio XAML ha le sue radici nel linguaggio XML. Per definizione, codice XAML valido deve essere valido anche in XML. Ma ad alcuni concetti sintattici del linguaggio XAML è assegnato un significato diverso e più completo, pur rimanendo validi in XML secondo la specifica XML 1.0. Ad esempio, XAML supporta la sintassi degli elementi di proprietà, in base alla quale i valori di proprietà possono essere impostati negli elementi anziché come valori stringa negli attributi o come contenuto. Per il normale linguaggio XML, un elemento di proprietà XAML è un elemento con un punto nel nome, perciò è valido in XML ma non ha lo stesso significato.

XAML e Microsoft 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 alla grafica. Perciò, quando usi il linguaggio XAML per la tua app con Visual Studio, non preoccuparti continuamente della sintassi. L'IDE facilita la scrittura di sintassi XAML valida fornendo suggerimenti di completamento automatico, mostrando suggerimenti negli elenchi e nelle caselle a discesa di Microsoft IntelliSense, visualizzando librerie di elementi dell'interfaccia utente nella casella degli strumenti o usando altre tecniche. Se questa è la tua prima esperienza con XAML, può risultare comunque utile conoscere le regole sintattiche e in particolare la terminologia usata a volte per descrivere le restrizioni o le opzioni della sintassi XAML negli argomenti di riferimento o in altri argomenti. Questi dettagli sono approfonditi in un argomento separato, Guida alla sintassi XAML di base.

Spazi dei nomi XAML

Nella programmazione generale, uno spazio dei nomi è un concetto di organizzazione che determina il modo in cui vengono interpretati gli identificatori per le entità di programmazione. Grazie all'uso degli spazi dei nomi, un framework di programmazione può separare gli identificatori dichiarati dall'utente dagli identificatori dichiarati dal framework, eliminare le ambiguità degli identificatori tramite le qualifiche dello spazio dei nomi, applicare le regole per la definizione dei nomi e così via. Per XAML esiste il concetto di spazio dei nomi XAML per gli scopi del linguaggio XAML. Ecco come XAML applica ed estende i concetti dello spazio dei nomi del linguaggio XML:

  • XAML usa l'attributo xmlns riservato a XML per le dichiarazioni dello spazio dei nomi. Il valore dell'attributo è in genere un URI (Uniform Resource Identifier), ovvero una convenzione ereditata da XML.
  • XAML usa prefissi nelle dichiarazioni per dichiarare spazi dei nomi non predefiniti e le sintassi dei prefissi in elementi e attributi per fare riferimento a tale spazio dei nomi.
  • In XAML esiste il concetto di spazio dei nomi predefinito, ovvero lo spazio dei nomi usato quando non esiste alcun prefisso in una sintassi o una dichiarazione. Lo spazio dei nomi predefinito può essere definito in modo diverso per ogni framework di programmazione XAML.
  • In un file o costrutto XAML le definizioni dello spazio dei nomi vengono ereditate dall'elemento padre all'elemento figlio. Se definisci uno spazio dei nomi nell'elemento radice di un file XAML, ad esempio, tutti gli elementi in tale file ereditano quella definizione dello spazio dei nomi. Se un elemento più avanti nella pagina ridefinisce lo spazio dei nomi, i discendenti di tale elemento ereditano la nuova definizione.
  • Gli attributi di un elemento ereditano gli spazi dei nomi dell'elemento. È abbastanza insolito vedere dei prefissi negli 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 puoi 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 incorporato per Windows Runtime usato per le definizioni dell'interfaccia utente: i controlli predefiniti, gli elementi di testo, la grafica e le animazioni XAML, i tipi di supporto per data binding e stili, e così via. La maggior parte del codice XAML che scriverai per le app di Windows Runtime sarà quindi in grado di evitare l'uso di prefissi e spazi dei nomi XAML per fare riferimento a elementi comuni dell'interfaccia utente.

Ecco un frammento che mostra una radice Page creata da modello della pagina iniziale di un'app (si tratta di un esempio semplificato che mostra solo il tag di apertura). Dichiara lo spazio dei nomi predefinito e anche lo spazio dei nomi x (che verrà spiegato in 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 del linguaggio XAML

Un particolare spazio dei nomi XAML dichiarato in quasi ogni file XAML per Windows Runtime è lo spazio dei nomi XAML. Questo spazio dei nomi include gli elementi e i concetti definiti dal linguaggio XAML, in base alla relativa specifica. Per convenzione, lo spazio dei nomi XAML del linguaggio XAML è mappato al prefisso "x". I modelli predefiniti di progetti e file per i progetti di app di Windows Runtime definiscono sempre sia lo spazio dei nomi XAML predefinito (senza prefisso, solo xmlns=) che lo spazio dei nomi XAML del linguaggio XAML (prefisso "x") all'interno dell'elemento radice.

Lo spazio dei nomi XAML del linguaggio XAML con prefisso "x" contiene diversi costrutti di programmazione di uso frequente nel codice XAML. Ecco i più comuni:

TermineDescrizione

x:Key

Imposta una chiave univoca definita dall'utente per ogni risorsa in un ResourceDictionary XAML. La stringa token della chiave è l'argomento per l'estensione di markup StaticResource e potrai usare questa chiave in seguito per recuperare la risorsa XAML da un'altra sintassi XAML in altre posizioni nel codice XAML dell'app.

x:Class

Specifica lo spazio dei nomi e il nome della classe del codice per la classe che fornisce il code-behind per una pagina XAML. Questo costrutto assegna un nome alla classe creata o unita dalle azioni di compilazione al momento della compilazione dell'app. Queste azioni di compilazione supportano il compilatore di markup XAML e combinano il markup e il code-behind durante la compilazione dell'app. Devi avere una classe di questo tipo per il supporto del code-behind per una pagina XAML. x:Class è anche necessario per fare in modo che il tuo contenuto XAML venga inizializzato come Window.Content nel modello di attivazione di Windows Runtime predefinito.

x:Name

Specifica il nome di un oggetto runtime per l'istanza presente nel codice runtime dopo l'elaborazione dell'elemento oggetto definito in XAML. L'impostazione di x:Name in XAML può essere paragonata alla dichiarazione di una variabile denominata nel codice. Come scoprirai più avanti, questo è esattamente quello che accade quando il codice XAML viene caricato come componente di un'app di Windows Runtime.

Nota  FrameworkElement.Name è una proprietà simile nel framework, ma non tutti gli elementi la supportano. Puoi quindi usare x:Name per l'identificazione dell'elemento, in tutti i casi in cui la proprietà FrameworkElement.Name non è supportata per il tipo di elemento.
 

x:Uid

Indica gli elementi che devono usare risorse localizzate per alcuni valori di proprietà. Per altre informazioni su come usare x:Uid, vedi Guida introduttiva: Traduzione delle risorse dell'interfaccia utente.

Tipi intrinseci XAML

Questi tipi possono specificare valori per i tipi di valore semplici, quando ciò è necessario per un attributo o una risorsa. Questi tipi intrinseci corrispondono a tipi di valore semplici, normalmente definiti come parte delle definizioni intrinseche di ogni linguaggio di programmazione. Ad esempio, potresti avere bisogno di un oggetto che rappresenta un valore Boolean true da usare in uno stato di visualizzazione con storyboard ObjectAnimationUsingKeyFrames. Per tale valore in XAML, potresti usare il tipo intrinseco x:Boolean come l'elemento oggetto, come in questo esempio: <x:Boolean>True</x:Boolean>

 

Gli altri costrutti di programmazione dello spazio dei nomi XAML del linguaggio XAML non sono molto diffusi. Per altre informazioni, vedi Caratteristiche del linguaggio dello spazio dei nomi XAML (x:).

Mapping dei tipi personalizzati agli spazi dei nomi XAML

Uno degli aspetti più potenti del linguaggio XAML è la facilità con cui è possibile estendere il vocabolario XAML per le tue app di Windows Runtime. Puoi definire tipi personalizzati nel linguaggio di programmazione della tua app e quindi fare riferimento a questi tipi personalizzati nel markup XAML. Il supporto per l'estensione tramite tipi personalizzati è fondamentalmente integrato nella modalità di funzionamento del linguaggio XAML. Gli sviluppatori di framework o app hanno la responsabilità di creare gli oggetti di supporto a cui fa riferimento XAML. Sia gli sviluppatori di framework che quelli di app non sono vincolati da specifiche per quanto riguarda ciò che rappresentano o fanno gli oggetti nei loro vocabolari, se non per le regole di base della sintassi XAML. Esistono naturalmente alcune aspettative per quanto riguarda le funzioni dei tipi di spazi dei nomi XAML nel linguaggio XAML, ma Windows Runtime offre tutto il supporto necessario.

Se usi XAML per tipi provenienti da librerie diverse dai metadati e dalle librerie principali di Windows Runtime, devi dichiarare e mappare uno spazio dei nomi XAML con un prefisso. Usa il prefisso nelle sintassi degli elementi per fare riferimento ai tipi definiti nella tua libreria. Puoi dichiarare i mapping dei prefissi come attributi xmlns, in genere in un elemento radice insieme ad altre definizione degli spazi dei nomi XAML.

Per creare una definizione di spazio dei nomi che faccia riferimento ai tipi personalizzati, devi innanzitutto specificare la parola chiave xmlns:, quindi il prefisso che vuoi usare. La prima parte del valore dell'attributo deve contenere la parola chiave using:. La parte restante del valore è un token stringa che fa riferimento allo spazio dei nomi che supporta il codice specifico che contiene i tipi personalizzati, in base al nome.

Il prefisso definisce il token del markup utilizzato per fare riferimento allo spazio dei nomi XAML nella parte rimanente del markup all'interno del file XAML. Un carattere di due punti (:) deve essere inserito tra il prefisso e l'entità a cui fare riferimento nell'ambito dello spazio dei nomi XAML.

Ad esempio, la sintassi di attributo per eseguire il mapping di un prefisso myTypes allo spazio dei nomi myCompany.myTypes è: xmlns:myTypes="using:myCompany.myTypes", e un uso rappresentativo dell'elemento è: <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), vedi Mapping di spazi dei nomi XAML e dello spazio dei nomi.

Altri spazi dei nomi XAML

Nei file XAML sono spesso definiti i prefissi "d" (per lo spazio dei nomi della finestra di progettazione) e "mc" (per la compatibilità dei markup). In genere questi sono utili per il supporto dell'infrastruttura o per consentire scenari specifici in uno strumento di progettazione. Per altre informazioni, vedi la sezione "Altri spazi dei nomi XAML" dell'argomento relativo agli spazi dei nomi XAML.

Estensioni del markup

Le estensioni del markup sono un concetto del linguaggio XAML usato spesso nell'implementazione di XAML per Windows Runtime. Le estensioni di markup spesso rappresentano un tipo di "scelta rapida" che consente ai file XAML di accedere a un valore o un comportamento diverso da una semplice dichiarazione degli elementi basata sui tipi di supporto. Alcune estensioni di markup possono impostare proprietà con stringhe semplici o con elementi ulteriormente nidificati, con lo scopo di semplificare la sintassi o la suddivisione tra file XAML diversi.

Nella sintassi dell'attributo XAML, le parentesi graffe "{" e "}" indicano un utilizzo di estensione di markup XAML. In questo modo viene indicato di non trattare i valori degli attributi come stringa letterale o come valore direttamente convertibile in stringa nell'elaborazione XAML. Al contrario, un parser XAML chiama il codice che fornisce il comportamento per la specifica estensione del markup e tale codice fornisce un oggetto o un comportamento alternativo come risultato necessario per il parser XAML. Le estensioni di markup possono avere argomenti, che seguono il nome dell'estensione e sono anch'essi racchiusi tra parentesi graffe. In genere, la valutazione di un'estensione di markup restituisce un oggetto. Durante l'analisi, tale valore restituito viene inserito in una posizione nell'albero degli oggetti in cui si trovava l'utilizzo dell'estensione di markup nel codice XAML di origine.

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

  • Binding: supporta l'associazione dati, che posticipa un valore di proprietà finché non viene interpretato in un contesto dati che esiste solo in fase di esecuzione. Questa estensione di markup supporta un'ampia gamma di argomenti. Per altre informazioni, vedi Estensione di markup Binding.
  • StaticResource: supporta il riferimento a valori di risorsa definiti in un oggetto ResourceDictionary. Queste risorse possono trovarsi in un file XAML diverso, ma devono essere fondamentalmente accessibili per il parser XAML in fase di caricamento. L'argomento per l'utilizzo {StaticResource} identifica la chiave (il nome) per una risorsa con chiave in un ResourceDictionary.
  • ThemeResource: simile a StaticResource, ma è in grado di rispondere ai cambiamenti di tema in fase di esecuzione. ThemeResource compare piuttosto spesso nei modelli XAML predefiniti di Windows Runtime, perché la maggior parte di questi modelli è progettata per essere compatibile con il fatto che l'utente cambi il tema mentre l'app è in esecuzione.
  • TemplateBinding: caso speciale di Binding che supporta modelli di controllo in XAML e l'eventuale uso di questi in fase di esecuzione.
  • RelativeSource: abilita una particolare forma di binding dei modelli, nella quale i valori provengono dal padre basato su modello.
  • CustomResource: per gli scenari avanzati di ricerca risorse.

Windows Runtime supporta anche l'estensione di markup x:Null, che puoi usare per impostare valori Nullable su null in XAML. Ad esempio, potresti usare questa estensione in un modello di controllo per una CheckBox, che interpreta null come stato indeterminato della selezione, attivando lo stato di visualizzazione "Indeterminato".

Le estensioni di markup in genere restituiscono un'istanza esistente da un'altra parte dell'oggetto grafico per l'app oppure posticipano il valore alla fase di esecuzione. Dato che un'estensione di markup può essere usata come valore di attributo, che è l'uso che se ne fa di solito, si trovano spesso estensioni di markup che forniscono valori per proprietà di tipo riferimento che altrimenti avrebbero potuto richiedere una sintassi di elemento di proprietà.

Ad esempio, ecco la sintassi che consente di fare riferimento a uno Style riutilizzabile da un ResourceDictionary: <Button Style="{StaticResource SearchButtonStyle}"/>. Uno Style è un tipo di riferimento, non un semplice valore, quindi non usando {StaticResource}, avresti avuto bisogno di un elemento della proprietà <Button.Style> e di una definizione di <Style> al suo interno per impostare la proprietà FrameworkElement.Style.

Mediante l'uso di estensioni di markup, ogni proprietà impostabile in XAML è potenzialmente impostabile nella sintassi degli attributi. Puoi usare la sintassi degli attributi per fornire valori di riferimento per una proprietà, anche se questa non supporta altrimenti la sintassi degli attributi per la creazione diretta di istanze di oggetti. Oppure puoi consentire un comportamento specifico che posticipa l'applicazione del requisito generale in base al quale le proprietà XAML devono essere compilate con tipi di valore o con nuovi tipi di riferimento creati.

Per illustrare il concetto, nel prossimo esempio di XAML il valore della proprietà Style di un oggetto Border viene impostato con la sintassi degli attributi. La proprietà Style accetta un'istanza della classe Style, un tipo di riferimento che per impostazione predefinita non sarebbe stato possibile creare tramite una stringa di sintassi degli attributi. Ma in questo caso l'attributo fa riferimento a una specifica estensione del markup, StaticResource. Quando viene elaborata, l'estensione del markup restituisce un riferimento a un elemento Style definito in precedenza 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>

Per argomenti di riferimento che descrivono le estensioni di markup disponibili in XAML per Windows Runtime, vedi Estensioni dello spazio dei nomi di Windows Runtime o Caratteristiche del linguaggio dello spazio dei nomi XAML (x:).

Le estensioni del markup possono essere annidate. Quella più interna viene valutata per prima.

A causa delle estensioni di markup, per specificare un valore letterale "{" in un attributo è necessaria una sintassi speciale. Per altre informazioni, vedi Guida alla sintassi XAML di base.

Eventi

XAML è un linguaggio dichiarativo per gli oggetti e le relative proprietà, ma include anche una sintassi per associare gestori eventi a oggetti nel markup. La sintassi degli eventi XAML può quindi integrare gli eventi dichiarati da XAML tramite il modello di programmazione di Windows Runtime. Il nome dell'evento deve essere specificato come nome di attributo nell'oggetto in cui l'evento viene gestito. Per il valore dell'attributo, specifica 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 di oggetti caricato e aggiunge il gestore specificato a un elenco interno di gestori. La maggior parte delle app di Windows Runtime viene definita da origini sia di markup che di code-behind.

Ecco un semplice esempio. La classe Button supporta un evento di nome Click. Per l'evento Click è possibile scrivere un gestore per eseguire il codice che verrebbe richiamato quando un utente fa clic sull'oggetto Button. In XAML devi specificare Click come attributo di Button. Come valore dell'attributo devi fornire una stringa costituita dal nome di metodo del gestore.


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

Al momento della compilazione, il compilatore si aspetta di trovare un metodo di nome showUpdatesButton_Click, definito nel file code-behind, nello spazio dei nomi dichiarato nel valore x:Class della pagina XAML. Il metodo deve anche rispettare il contratto di delega per l'evento Click. Ad esempio:


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

All'interno di un progetto, il codice XAML viene scritto in un file .xaml, mentre per scrivere un file code-behind puoi usare il linguaggio che preferisci (C#, Visual Basic, C++/CX). Quando un file XAML viene compilato dal markup come parte di un'azione di compilazione, 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 informazioni sul funzionamento di questi meccanismi in XAML e sulla correlazione con i modelli di programmazione e delle applicazioni, vedi Panoramica su eventi ed eventi indirizzati.

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

Dizionario risorse

La creazione di un ResourceDictionary è un'attività frequente che viene di solito eseguita mediante la creazione di un dizionario risorse come area di una pagina XAML o come file XAML separato. I dizionari risorse e l'uso di questi formano un'area concettuale più ampia che esula dall'ambito di questo argomento. Per altre informazioni, vedi Riferimenti a ResourceDictionary e risorse XAML.

XAML e XML

Il linguaggio XAML è fondamentalmente basato sul linguaggio XML, anche se lo estende in modo significativo. In particolare, implica un trattamento piuttosto diverso del concetto di schema, dovuto alla relazione con il concetto di tipo di supporto, e l'aggiunta di elementi del linguaggio come membri associati ed estensioni del markup. xml:lang è valido in XAML, ma influisce sul comportamento del runtime invece che del parser e ha in genere come alias una proprietà a livello di framework. Per altre info, vedi FrameworkElement.Language. xml:base è valido nel markup, ma viene ignorato dai parser. xml:space è valido, ma è appropriato solo per gli scenari descritti nell'argomento XAML e spazi vuoti. L'attributo encoding è 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 del fatto che XAML è basato su XML, in cui viene fatta questa distinzione. Per i nomi degli elementi e degli attributi XAML viene fatta distinzione tra maiuscole e minuscole. Per il valore di un attributo, questa distinzione dipende dal modo in cui l'attributo viene gestito per specifiche proprietà. Se ad esempio il valore dell'attributo dichiara il nome di un membro per un'enumerazione, il comportamento predefinito di conversione del tipo in una stringa di un nome di membro per restituire il valore del membro dell'enumerazione non prevede la distinzione tra maiuscole e minuscole. Il valore della proprietà Name e i metodi di utilità per l'uso di oggetti in base al nome dichiarato dalla proprietà Name prevedono invece la distinzione tra maiuscole e minuscole nella stringa del nome.

Ambiti dei nomi XAML

Il linguaggio XAML definisce un concetto di ambito dei nomi XAML. Questo concetto influisce sul modo in cui i processori XAML devono trattare il valore di x:Name o Name applicato a elementi XAML, in particolare gli ambiti in cui i nomi devono essere necessariamente identificatori univoci. Gli ambiti dei nomi XAML vengono trattati in maggior dettaglio in un altro argomento. Vedi Ambiti dei nomi XAML.

Ruolo di XAML nel processo di sviluppo

XAML gioca diversi ruoli importanti nel processo di sviluppo delle app.

  • XAML è il formato principale per dichiarare l'interfaccia utente di un'app e gli elementi appartenenti a tale interfaccia utente, se programmi in C#, Visual Basic o C++/CX. In genere, almeno un file XAML del progetto rappresenta una metafora di pagina dell'app per l'interfaccia utente visualizzata inizialmente. Altri file XAML possono dichiarare pagine aggiuntive per l'interfaccia utente di esplorazione, mentre altri possono dichiarare risorse, ad esempio modelli o stili.
  • Il formato XAML viene usato per dichiarare stili e modelli applicati ai controlli e all'interfaccia utente di un'app.
  • Potresti usare stili e modelli sia per creare modelli di controlli esistenti oppure se definisci un controllo che fornisce un modello predefinito nell'ambito di un pacchetto di controlli. Se definisci stili e modelli, il codice XAML appropriato viene spesso dichiarato come file XAML distinto con una radice ResourceDictionary.
  • XAML è il formato comune per il supporto nella creazione dell'interfaccia utente delle app e nello scambio della progettazione dell'interfaccia utente tra app create con strumenti di progettazione diversi. In particolare, il codice XAML per l'app può essere scambiato tra strumenti di progettazione XAML diversi o finestre di progettazione diverse all'interno degli strumenti.
  • Diverse altre tecnologie definiscono l'interfaccia utente di base in XAML. Rispetto a XAML per Windows Presentation Foundation (WPF) e XAML per Microsoft Silverlight, il linguaggio XAML per Windows Runtime usa lo stesso URI per lo spazio dei nomi XAML predefinito condiviso. Il vocabolario XAML per Windows Runtime si sovrappone in larga misura al vocabolario XAML per l'interfaccia utente usato anche da Silverlight e in misura minore da WPF. Pertanto, XAML favorisce un percorso di migrazione efficiente per l'interfaccia utente definita originariamente per tecnologie precedenti basate anch'esse su XAML.
  • XAML definisce l'aspetto visivo di un'interfaccia utente, mentre un file code-behind associato ne definisce la logica. Puoi adattare 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 al supporto dell'area di progettazione, XAML supporta la creazione rapida di prototipi di interfaccia utente nelle prime fasi di sviluppo.

A seconda del ruolo che ricopri nel processo di sviluppo, potresti interagire poco con XAML. Il livello di interazione con i file XAML dipende anche dall'ambiente di sviluppo in uso, dall'impiego o meno di funzionalità interattive dell'ambiente di progettazione, come caselle degli strumenti e editor di proprietà, e dall'ambito e dallo scopo della tua app di Windows Runtime. Nonostante ciò, è probabile che durante lo sviluppo dell'app tu debba modificare un file XAML a livello di elemento tramite un editor di testo o XML. Con queste informazioni potrai modificare in sicurezza il codice XAML in una rappresentazione di testo o XML senza alterare la validità delle dichiarazioni e dello scopo del file XAML usato da strumenti, operazioni di compilazione del markup o nella fase di esecuzione della tua app di Windows Runtime.

Ottimizza le prestazioni di caricamento del codice XAML

Ecco alcuni suggerimenti per definire gli elementi dell'interfaccia utente in XAML utilizzando le procedure consigliate per le prestazioni. Molti di questi suggerimenti implicano l'uso di risorse XAML, ma sono elencati in questa panoramica generale su XAML per motivi di praticità. Per altre informazioni, vedi Riferimenti a ResourceDictionary e risorse XAML. Per altri suggerimenti sulle prestazioni, incluso XAML che in particolare presenta alcune procedure inefficaci per le prestazioni che dovresti evitare nel tuo XAML, vedi Ottimizzare il caricamento di XAML.

  • Se nel codice XAML utilizzi spesso lo stesso pennello di colore, definisci un oggetto SolidColorBrush come risorsa, anziché specificare ogni volta un nome di colore come valore per un attributo.
  • Se utilizzi la stessa risorsa in più di una pagina dell'interfaccia utente, è consigliabile definirla in Application.Resources anziché in ogni singola pagina. Viceversa, se una determinata risorsa viene utilizzata in una sola pagina, non definirla in Application.Resources ma solo nella pagina che la richiede. Rappresenta una scelta valida sia per il factoring del codice XAML durante la progettazione dell'app che per le prestazioni durante l'analisi XAML.
  • Per le risorse incluse nei pacchetti di app, individua quelle che non vengono usate, ovvero che dispongono di una chiave ma per cui nell'app non è presente alcun riferimento StaticResource che le usa. Rimuovi questi file da XAML prima di rilasciare l'app.
  • Se utilizzi file XAML separati che forniscono risorse di progettazione (MergedDictionaries), è consigliabile impostare tali risorse inutilizzate come commento o rimuoverle dai file. Anche se il tuo punto di partenza è uno XAML condiviso che usi in più di un'app o che fornisce risorse comuni a tutte le app, è comunque l'app che crea i pacchetti con le risorse XAML ogni volta e che, potenzialmente, deve caricarle.
  • Non definire elementi di interfaccia utente non necessari per la composizione e usa i modelli di controllo predefiniti quando possibile (tali modelli sono già stati testati e verificati per quanto riguarda le prestazioni di caricamento).
  • Usa contenitori come Border, anziché sovrapporre intenzionalmente gli elementi dell'interfaccia utente. In pratica, non disegnare lo stesso pixel più volte. Per altre informazioni sulla sovrapposizione e sulle relative modalità di test, vedi DebugSettings.IsOverdrawHeatMapEnabled.
  • Usa i modelli di elementi predefiniti per ListView o GridView. Questi modelli includono una logica speciale Presenter che risolvere i problemi di prestazioni durante la compilazione della struttura ad albero visuale per numeri elevati di elementi di elenco.

Debug di XAML

Poiché XAML è un linguaggio di markup, alcune delle tipiche strategie di debug di Visual Studio non risultano disponibili. Non è possibile, ad esempio, impostare un punto di interruzione all'interno di un file XAML. Tuttavia, esistono altre tecniche che possono essere utili per eseguire il debug dei problemi relativi alle definizioni dell'interfaccia utente o ad altro markup XAML mentre continui a sviluppare la tua app.

In presenza di problemi relativi a un file XAML, tipicamente alcuni sistema o l'app stessa genereranno un'eccezione di analisi XAML. Quando 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 il codice XAML rappresenta la prima "pagina" dell'applicazione caricata come Visual radice, l'eccezione di analisi XAML è irreversibile.

XAML viene spesso modificato all'interno di un IDE, ad esempio Visual Studio, e di una delle relative aree di progettazione. Visual Studio può spesso offrire la convalida in fase di progettazione e il controllo degli errori di un codice sorgente XAML mentre apporti le tue modifiche. Potrebbe, ad esempio, visualizzare sottolineature ondulate nell'editor di testo XAML non appena digiti un valore di attributo errato. In questo caso, non dovrai neanche attendere un passaggio di compilazione XAML per capire che la definizione dell'interfaccia utente contiene qualche errore.

Una volta avviata l'esecuzione dell'app, se alcuni errori di analisi XAML non sono stati rilevati durante la progettazione, tali errori verranno segnalati dal CLR (Common Language Runtime) come XamlParseException. Per altre informazioni sulle eventuali operazioni da eseguire in caso di XamlParseException di runtime, vedi 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 ricevono l'eccezione specifica XamlParseException. Il messaggio nell'eccezione chiarisce però che l'origine dell'errore è correlata a XAML e include info di contesto come i numeri di riga in un file XAML, proprio come XamlParseException.
 

Per altre informazioni sul debug di un'app di Windows Runtime, vedi Avviare una sessione di debug.

Argomenti correlati

Guida alla sintassi XAML di base
Panoramica delle proprietà di dipendenza
Riferimenti a ResourceDictionary e risorse XAML
Estensioni dello spazio dei nomi di Windows Runtime
Mapping di spazi dei nomi XAML e dello spazio dei nomi
Caratteristiche del linguaggio dello spazio dei nomi XAML (x:)
Guida introduttiva: Creazione di un'interfaccia utente con XAML
Esempio di risorse dell'applicazione e localizzazione
Animazioni con storyboard

 

 

Mostra:
© 2017 Microsoft