Compartir a través de


Introducción a XAML

En este artículo se presentan los conceptos del lenguaje XAML y XAML a la audiencia de desarrolladores de aplicaciones de Windows Runtime y se describen las distintas formas de declarar objetos y establecer atributos en XAML, ya que se usa para crear una aplicación de Windows Runtime.

¿Qué es XAML?

Extensible Application Markup Language (XAML) es un lenguaje declarativo. En concreto, XAML puede inicializar objetos y establecer propiedades de objetos mediante una estructura de lenguaje que muestra relaciones jerárquicas entre varios objetos y una convención de tipo de respaldo que admite la extensión de tipos. Puedes crear elementos de interfaz de usuario visibles en el marcado XAML declarativo. A continuación, puedes asociar un archivo de código subyacente independiente para cada archivo XAML que pueda responder a eventos y manipular los objetos que declares originalmente en XAML.

El lenguaje XAML admite el intercambio de orígenes entre diferentes herramientas y roles en el proceso de desarrollo, como intercambiar orígenes XAML entre herramientas de diseño y un entorno de desarrollo interactivo (IDE) o entre desarrolladores principales y desarrolladores de localización. El uso de XAML como formato de intercambio, los roles de diseñador y los roles de desarrollador se pueden mantener separados o reunidos, y los diseñadores y desarrolladores pueden iterar durante la producción de una aplicación.

Cuando los ves como parte de los proyectos de aplicación de Windows Runtime, los archivos XAML son archivos XML con la extensión de nombre de archivo .xaml.

Sintaxis XAML básica

XAML tiene una sintaxis básica que se basa en XML. Por definición, xaml válido también debe ser XML válido. Pero XAML también tiene conceptos de sintaxis que se asignan un significado diferente y más completo mientras siguen siendo válidos en XML según la especificación XML 1.0. Por ejemplo, XAML admite la sintaxis del elemento de propiedad, donde los valores de propiedad se pueden establecer dentro de elementos en lugar de como valores de cadena en atributos o como contenido. Para XML normal, un elemento de propiedad XAML es un elemento con un punto en su nombre, por lo que es válido para XML sin formato, pero no tiene el mismo significado.

XAML y Visual Studio

Microsoft Visual Studio te ayuda a generar sintaxis XAML válida, tanto en el editor de texto XAML como en la superficie de diseño XAML más orientada gráficamente. Al escribir XAML para la aplicación mediante Visual Studio, no te preocupes demasiado por la sintaxis con cada pulsación de tecla. El IDE fomenta la sintaxis XAML válida proporcionando sugerencias de autocompletar, mostrando sugerencias en listas y listas de Microsoft IntelliSense y listas desplegables, mostrando bibliotecas de elementos de interfaz de usuario en la ventana Cuadro de herramientas u otras técnicas. Si esta es tu primera experiencia con XAML, puede ser útil conocer las reglas de sintaxis y, especialmente, la terminología que a veces se usa para describir las restricciones o opciones al describir la sintaxis XAML en referencia u otros temas. Los puntos correctos de sintaxis XAML se tratan en un tema independiente, guía de sintaxis XAML.

Espacios de nombres de XAML

En general, un espacio de nombres es un concepto de organización que determina cómo se interpretan los identificadores de las entidades de programación. Mediante el uso de espacios de nombres, un marco de programación puede separar los identificadores declarados por el usuario de los identificadores declarados por el marco, desambiguar los identificadores mediante calificaciones de espacio de nombres, aplicar reglas para los nombres de ámbito, etc. XAML tiene su propio concepto de espacio de nombres XAML que sirve para este propósito para el lenguaje XAML. Este es el modo en que XAML se aplica y amplía los conceptos del espacio de nombres del lenguaje XML:

  • XAML usa los xmlns de atributo XML reservados para las declaraciones de espacio de nombres. El valor del atributo suele ser un identificador uniforme de recursos (URI), que es una convención heredada de XML.
  • XAML usa prefijos en declaraciones para declarar espacios de nombres no predeterminados y usos de prefijos en elementos y atributos hacen referencia a ese espacio de nombres.
  • XAML tiene un concepto de espacio de nombres predeterminado, que es el espacio de nombres que se usa cuando no existe ningún prefijo en una declaración o uso. El espacio de nombres predeterminado se puede definir de forma diferente para cada marco de programación XAML.
  • Namespace definiciones heredan en un archivo XAML o construcción, del elemento primario al elemento secundario. Por ejemplo, si defines un espacio de nombres en el elemento raíz de un archivo XAML, todos los elementos de ese archivo heredan esa definición de espacio de nombres. Si un elemento más allá de la página vuelve a definir el espacio de nombres, los descendientes de ese elemento heredan la nueva definición.
  • Los atributos de un elemento heredan los espacios de nombres del elemento. Es bastante raro ver prefijos en atributos XAML.

Un archivo XAML casi siempre declara un espacio de nombres XAML predeterminado en su elemento raíz. El espacio de nombres XAML predeterminado define qué elementos puedes declarar sin calificarlos por un prefijo. Para los proyectos típicos de aplicaciones de Windows Runtime, este espacio de nombres predeterminado contiene todo el vocabulario XAML integrado para Windows Runtime que se usa para las definiciones de interfaz de usuario: los controles predeterminados, los elementos de texto, los gráficos XAML y las animaciones, el enlace de datos y los tipos de compatibilidad de estilos, etc. La mayoría de los XAML que escribirás para las aplicaciones de Windows Runtime podrán evitar el uso de espacios de nombres y prefijos XAML al hacer referencia a elementos comunes de la interfaz de usuario.

Este es un fragmento de código que muestra una raíz creada por Page la plantilla de la página inicial de una aplicación (que muestra solo la etiqueta de apertura y simplificada). Declara el espacio de nombres predeterminado y también el espacio de nombres x (que explicaremos a continuación).

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

El espacio de nombres XAML del lenguaje XAML

Un espacio de nombres XAML determinado que se declara en casi todos los archivos XAML de Windows Runtime es el espacio de nombres del lenguaje XAML. Este espacio de nombres incluye elementos y conceptos definidos por la especificación del lenguaje XAML. Por convención, el espacio de nombres XAML del lenguaje XAML se asigna al prefijo "x". Las plantillas predeterminadas de proyecto y archivo para los proyectos de aplicaciones de Windows Runtime siempre definen el espacio de nombres XAML predeterminado (sin prefijo, solo xmlns=) y el espacio de nombres XAML del lenguaje XAML (prefijo "x") como parte del elemento raíz.

El prefijo "x" o el espacio de nombres XAML del lenguaje XAML contiene varias construcciones de programación que usas a menudo en tu XAML. Estas son algunas de las más habituales:

Término Descripción
x:Key Establece una clave única definida por el usuario para cada recurso de un XAML ResourceDictionary. La cadena de token de la clave es el argumento de la extensión de marcado StaticResource y usas esta clave más adelante para recuperar el recurso XAML de otro uso XAML en otra parte del XAML de la aplicación.
x:Class Especifica el espacio de nombres de código y el nombre de clase de código para la clase que proporciona código subyacente para una página XAML. Esto asigna un nombre a la clase creada o unida por las acciones de compilación al compilar la aplicación. Estas acciones de compilación admiten el compilador de marcado XAML y combinan el marcado y el código subyacente cuando se compila la aplicación. Debes tener una clase de este tipo para admitir código subyacente para una página XAML. Window.Content en el modelo de activación predeterminado de Windows Runtime.
x:Name Especifica un nombre de objeto en tiempo de ejecución para la instancia que existe en el código en tiempo de ejecución después de procesar un elemento de objeto definido en XAML. Puedes pensar en establecer x:Name en XAML como declarar una variable con nombre en el código. Como aprenderás más adelante, eso es exactamente lo que sucede cuando tu XAML se carga como componente de una aplicación de Windows Runtime.
Nota Name es una propiedad similar en el marco de trabajo, pero no todos los elementos lo admiten. Use x:Name para la identificación de elementos siempre que no se admita FrameworkElement.Name en ese tipo de elemento.
x:Uid Identifica los elementos que deben usar recursos localizados para algunos de sus valores de propiedad. Para obtener más información sobre cómo usar x:Uid, consulte Inicio rápido: Traducción de recursos de interfaz de usuario.
Tipos de datos intrínsecos de XAML Estos tipos pueden especificar valores para tipos de valor simples cuando es necesario para un atributo o recurso. Estos tipos intrínsecos corresponden a los tipos de valor simples que normalmente se definen como parte de las definiciones intrínsecas de cada lenguaje de programación. Por ejemplo, es posible que necesite un objeto que represente un valor booleano verdadero para usarlo en un ObjectAnimationUsingKeyFrames estado visual con guion gráfico. Para ese valor en XAML, usarías el tipo intrínseco x:Boolean como elemento de objeto, como este: <x:Boolean>True</x:Boolean>

Existen otras construcciones de programación en el espacio de nombres XAML del lenguaje XAML, pero no son tan comunes.

Asignación de tipos personalizados a espacios de nombres XAML

Uno de los aspectos más eficaces de XAML como lenguaje es que es fácil ampliar el vocabulario XAML para las aplicaciones de Windows Runtime. Puedes definir tus propios tipos personalizados en el lenguaje de programación de la aplicación y, a continuación, hacer referencia a los tipos personalizados en el marcado XAML. La compatibilidad con la extensión a través de tipos personalizados es fundamentalmente integrada para cómo funciona el lenguaje XAML. Los marcos o desarrolladores de aplicaciones son responsables de crear los objetos de respaldo a los que hace referencia XAML. Ni los marcos ni el desarrollador de aplicaciones están enlazados por especificaciones de lo que representan o hacen los objetos de sus vocabularios más allá de las reglas básicas de sintaxis XAML. (Hay algunas expectativas de lo que deben hacer los tipos de espacio de nombres XAML del lenguaje XAML, pero Windows Runtime proporciona toda la compatibilidad necesaria).

Si usas XAML para tipos que proceden de bibliotecas distintas de las bibliotecas principales y metadatos de Windows Runtime, debes declarar y asignar un espacio de nombres XAML con un prefijo. Use ese prefijo en usos de elementos para hacer referencia a los tipos definidos en la biblioteca. Las asignaciones de prefijo se declaran como atributos xmlns , normalmente en un elemento raíz junto con las otras definiciones de espacio de nombres XAML.

Para crear su propia definición de espacio de nombres que haga referencia a tipos personalizados, especifique primero la palabra clave xmlns:y, a continuación, el prefijo que desee. El valor de ese atributo debe contener la palabra clave using: como primera parte del valor. El resto del valor es un token de cadena que hace referencia al espacio de nombres específico de respaldo de código que contiene los tipos personalizados, por nombre.

El prefijo define el token de marcado que se usa para hacer referencia a ese espacio de nombres XAML en el resto del marcado en ese archivo XAML. Carácter de dos puntos (:) va entre el prefijo y la entidad a la que se va a hacer referencia dentro del espacio de nombres XAML.

Por ejemplo, la sintaxis del atributo para asignar un prefijo myTypes al espacio de nombres myCompany.myTypes es: xmlns:myTypes="using:myCompany.myTypes"y un uso de elemento representativo es: <myTypes:CustomButton/>

Para obtener más información sobre la asignación de espacios de nombres XAML para tipos personalizados, incluidas consideraciones especiales para las extensiones de componentes de Visual C++ (C++/CX), consulta Espacios de nombres XAML y asignación de espacios de nombres.

Otros espacios de nombres XAML

A menudo se ven archivos XAML que definen los prefijos "d" (para el espacio de nombres del diseñador) y "mc" (para la compatibilidad de marcado). Por lo general, estos son para la compatibilidad con la infraestructura o para habilitar escenarios en una herramienta en tiempo de diseño. Para obtener más información, consulta la sección "Otros espacios de nombres XAML" del tema Espacios de nombres XAML.

Extensiones de marcado

Las extensiones de marcado son un concepto de lenguaje XAML que a menudo se usa en la implementación xaml de Windows Runtime. Las extensiones de marcado a menudo representan algún tipo de "acceso directo" que permite a un archivo XAML tener acceso a un valor o comportamiento que no simplemente declara elementos basados en tipos de respaldo. Algunas extensiones de marcado pueden establecer propiedades con cadenas sin formato o con elementos anidados adicionales, con el objetivo de simplificar la sintaxis o la factorización entre diferentes archivos XAML.

En la sintaxis de atributo XAML, las llaves "{" y "}" indican un uso de la extensión de marcado XAML. Este uso dirige el procesamiento XAML a escapar del tratamiento general de los valores de atributo como una cadena literal o un valor convertible directamente a cadenas. En su lugar, un analizador XAML llama al código que proporciona comportamiento para esa extensión de marcado concreta y ese código proporciona un objeto o resultado de comportamiento alternativo que necesita el analizador XAML. Las extensiones de marcado pueden tener argumentos, que siguen el nombre de la extensión de marcado y también se encuentran dentro de las llaves. Normalmente, una extensión de marcado evaluada proporciona un valor devuelto de objeto. Durante el análisis, ese valor devuelto se inserta en la posición del árbol de objetos donde el uso de la extensión de marcado estaba en el XAML de origen.

XAML de Windows Runtime admite estas extensiones de marcado definidas en el espacio de nombres XAML predeterminado y que el analizador XAML de Windows Runtime entiende:

  • {x:Bind}: admite el enlace de datos, que aplaza la evaluación de propiedades hasta el tiempo de ejecución mediante la ejecución de código de propósito especial, que genera en tiempo de compilación. Esta extensión de marcado admite una amplia gama de argumentos.
  • {Binding}: admite el enlace de datos, que aplaza la evaluación de propiedades hasta el tiempo de ejecución mediante la ejecución de la inspección de objetos en tiempo de ejecución de uso general. Esta extensión de marcado admite una amplia gama de argumentos.
  • {StaticResource}: admite la referencia a valores de recursos definidos en un ResourceDictionary. Estos recursos pueden estar en un archivo XAML diferente, pero en última instancia el analizador XAML lo puede encontrar en tiempo de carga. El argumento de un {StaticResource} uso identifica la clave (el nombre) de un recurso con clave en .ResourceDictionary
  • {ThemeResource}: similar a {StaticResource} pero puede responder a los cambios de tema en tiempo de ejecución. {ThemeResource} aparece con bastante frecuencia en las plantillas XAML predeterminadas de Windows Runtime, ya que la mayoría de estas plantillas están diseñadas para que el usuario cambie el tema mientras se ejecuta la aplicación.
  • {TemplateBinding}: un caso especial de {Binding} que admite plantillas de control en XAML y su uso final en tiempo de ejecución.
  • {RelativeSource}: habilita una forma determinada de enlace de plantilla donde los valores proceden del elemento primario con plantilla.
  • {CustomResource}: para escenarios de búsqueda de recursos avanzados.

Windows Runtime también admite la extensión de marcado {x:Null}. Se usa para establecer valores que aceptan valores NULL en NULL en XAML. Por ejemplo, puede usarlo en una plantilla de control para , CheckBoxque interpreta null como un estado de comprobación indeterminado (desencadenando el estado visual "Indeterminado").

Normalmente, una extensión de marcado devuelve una instancia existente de alguna otra parte del gráfico de objetos de la aplicación o aplaza un valor en tiempo de ejecución. Dado que puede usar una extensión de marcado como un valor de atributo y ese es el uso típico, a menudo verá que las extensiones de marcado proporcionan valores para las propiedades de tipo de referencia que, de lo contrario, podrían haber requerido una sintaxis de elemento de propiedad.

Por ejemplo, esta es la sintaxis para hacer referencia a una reutilizable Style desde : ResourceDictionary<Button Style="{StaticResource SearchButtonStyle}"/>. Un Style es un tipo de referencia, no un valor simple, por lo que sin el {StaticResource} uso, habría necesario un <Button.Style> elemento de propiedad y una <Style> definición dentro de él para establecer la FrameworkElement.Style propiedad.

Mediante el uso de extensiones de marcado, todas las propiedades que se pueden establecer en XAML pueden establecerse en la sintaxis de atributo. Puede usar la sintaxis de atributo para proporcionar valores de referencia para una propiedad aunque no admita una sintaxis de atributo para la creación de instancias directas de objetos. O bien, puedes habilitar un comportamiento específico que aplaza el requisito general de que las propiedades XAML se rellenen por tipos de valor o por tipos de referencia recién creados.

Para ilustrarlo, el siguiente ejemplo XAML establece el valor de la FrameworkElement.Style propiedad de un Border mediante la sintaxis de atributo . La FrameworkElement.Style propiedad toma una instancia de la Windows.UI.Xaml.Style clase , un tipo de referencia que de forma predeterminada no se pudo crear mediante una cadena de sintaxis de atributo. Pero en este caso, el atributo hace referencia a una extensión de marcado determinada, StaticResource. Cuando se procesa esa extensión de marcado, devuelve una referencia a un elemento Style que se definió anteriormente como un recurso con claves en un diccionario de recursos.

<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>

Puede anidar extensiones de marcado. Primero se evalúa la extensión de marcado más interna.

Debido a las extensiones de marcado, necesita una sintaxis especial para un valor literal "{" en un atributo. Para obtener más información, consulta la guía de sintaxis XAML.

Eventos

XAML es un lenguaje declarativo para los objetos y sus propiedades, pero también incluye una sintaxis para adjuntar controladores de eventos a objetos en el marcado. A continuación, la sintaxis de eventos XAML puede integrar los eventos declarados por XAML a través del modelo de programación de Windows Runtime. Especifique el nombre del evento como un nombre de atributo en el objeto donde se controla el evento. Para el valor del atributo, especifique el nombre de una función de controlador de eventos que defina en el código. El procesador XAML usa este nombre para crear una representación de delegado en el árbol de objetos cargado y agrega el controlador especificado a una lista de controladores interna. Casi todas las aplicaciones de Windows Runtime se definen mediante el marcado y los orígenes de código subyacente.

Este es un ejemplo sencillo. La Button clase admite un evento denominado Click. Puede escribir un controlador para Click que ejecuta código que se debe invocar después de que el usuario haga clic en el botón. En XAML, especificas Click como un atributo en el botón. Para el valor del atributo, proporcione una cadena que sea el nombre del método del controlador.

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

Al compilar, el compilador espera que ahora haya un método denominado showUpdatesButton_Click definido en el archivo de código subyacente, en el espacio de nombres declarado en el valor x:Class de la página XAML. Además, ese método debe satisfacer el contrato delegado para el Click evento. Por ejemplo:

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);
    };
}

Dentro de un proyecto, el XAML se escribe como un archivo .xaml y usas el lenguaje que prefieras (C#, Visual Basic, C++/CX) para escribir un archivo de código subyacente. Cuando un archivo XAML se compila como parte de una acción de compilación para el proyecto, la ubicación del archivo de código subyacente XAML para cada página XAML se identifica especificando un espacio de nombres y una clase como el atributo x:Class del elemento raíz de la página XAML. Para obtener más información sobre cómo funcionan estos mecanismos en XAML y cómo se relacionan con los modelos de programación y aplicación, consulta Información general sobre eventos y eventos enrutados.

Nota:

Para C++/CX hay dos archivos de código subyacente: uno es un encabezado (.xaml.h) y el otro es la implementación (.xaml.cpp). La implementación hace referencia al encabezado y técnicamente es el encabezado que representa el punto de entrada de la conexión de código subyacente.

Diccionarios de recursos

La creación de una ResourceDictionary es una tarea común que normalmente se realiza mediante la creación de un diccionario de recursos como un área de una página XAML o un archivo XAML independiente. Los diccionarios de recursos y cómo usarlos son un área conceptual más grande que está fuera del ámbito de este tema. Para obtener más información, consulta Referencias a recursos ResourceDictionary y XAML.

XAML y XML

El lenguaje XAML se basa fundamentalmente en el lenguaje XML. Pero XAML amplía XML significativamente. En particular, trata el concepto de esquema de forma bastante diferente debido a su relación con el concepto de tipo de respaldo, y agrega elementos de lenguaje como miembros adjuntos y extensiones de marcado. xml:lang es válido en XAML, pero influye en el tiempo de ejecución en lugar de analizar el comportamiento y normalmente se aplica un alias a una propiedad de nivel de marco. Para obtener más información, consulte FrameworkElement.Language. xml:base es válido en el marcado, pero los analizadores lo omiten. xml:space es válido, pero solo es relevante para escenarios descritos en el tema XAML y espacio en blanco. El atributo de codificación es válido en XAML. Solo se admiten codificaciones UTF-8 y UTF-16. No se admite la codificación UTF-32.

Distinción entre mayúsculas y minúsculas en XAML

XAML distingue mayúsculas de minúsculas. Esta es otra consecuencia de que XAML se basa en XML, que distingue mayúsculas de minúsculas. Los nombres de los elementos y atributos XAML distinguen mayúsculas de minúsculas. El valor de un atributo distingue mayúsculas de minúsculas; esto depende de cómo se controla el valor del atributo para determinadas propiedades. Por ejemplo, si el valor de atributo declara un nombre de miembro de una enumeración, el comportamiento integrado que convierte un tipo convierte una cadena de nombre de miembro para devolver el valor del miembro de enumeración no distingue mayúsculas de minúsculas. En cambio, el valor de la propiedad Name y los métodos de utilidad para trabajar con objetos basados en el nombre que declara la propiedad Name , trate la cadena de nombre como distingue mayúsculas de minúsculas.

Ámbitos de nombres XAML

El lenguaje XAML define un concepto de ámbito de nombres XAML. El concepto de ámbito de nombres XAML influye en cómo los procesadores XAML deben tratar el valor de x:Name o Name aplicados a elementos XAML, especialmente los ámbitos en los que se debe confiar en los nombres como identificadores únicos. Los ámbitos de nombres XAML se tratan con más detalle en un tema independiente; consulta Ámbitos de nombres XAML.

El rol de XAML en el proceso de desarrollo

XAML desempeña varios roles importantes en el proceso de desarrollo de aplicaciones.

  • XAML es el formato principal para declarar la interfaz de usuario y los elementos de una aplicación en esa interfaz de usuario, si estás programando con C#, Visual Basic o C++/CX. Normalmente, al menos un archivo XAML del proyecto representa una metáfora de página en la aplicación para la interfaz de usuario mostrada inicialmente. Es posible que otros archivos XAML declaren páginas adicionales para la interfaz de usuario de navegación. Otros archivos XAML pueden declarar recursos, como plantillas o estilos.
  • Usas el formato XAML para declarar estilos y plantillas aplicados a controles y interfaz de usuario para una aplicación.
  • Puede usar estilos y plantillas para crear plantillas de controles existentes o si define un control que proporciona una plantilla predeterminada como parte de un paquete de control. Cuando se usa para definir estilos y plantillas, el XAML correspondiente se declara a menudo como un archivo XAML discreto con una ResourceDictionary raíz.
  • XAML es el formato común para la compatibilidad del diseñador con la creación de la interfaz de usuario de la aplicación e intercambio del diseño de la interfaz de usuario entre diferentes aplicaciones de diseñador. En particular, XAML para la aplicación se puede intercambiar entre diferentes herramientas de diseño XAML (o ventanas de diseño dentro de las herramientas).
  • Otras tecnologías también definen la interfaz de usuario básica en XAML. En relación con XAML de Windows Presentation Foundation (WPF) y XAML de Microsoft Silverlight, el XAML para Windows Runtime usa el mismo URI para su espacio de nombres XAML predeterminado compartido. El vocabulario XAML para Windows Runtime se superpone significativamente con el vocabulario XAML-for-UI también usado por Silverlight y en una medida ligeramente menor por WPF. Por lo tanto, XAML promueve una ruta de migración eficaz para la interfaz de usuario definida originalmente para tecnologías precursoras que también usaban XAML.
  • XAML define la apariencia visual de una interfaz de usuario y un archivo de código subyacente asociado define la lógica. Puede ajustar el diseño de la interfaz de usuario sin realizar cambios en la lógica en el código subyacente. XAML simplifica el flujo de trabajo entre diseñadores y desarrolladores.
  • Debido a la riqueza del diseñador visual y la compatibilidad con la superficie de diseño para el lenguaje XAML, XAML admite la creación rápida de prototipos de interfaz de usuario en las primeras fases de desarrollo.

Dependiendo de su propio rol en el proceso de desarrollo, es posible que no interactúe con XAML mucho. El grado en que interactúas con archivos XAML también depende del entorno de desarrollo que uses, tanto si usas características de entorno de diseño interactivos como cuadros de herramientas y editores de propiedades, como el ámbito y el propósito de tu aplicación de Windows Runtime. Sin embargo, es probable que durante el desarrollo de la aplicación, edite un archivo XAML en el nivel de elemento mediante un editor XML o texto. Con esta información, puedes editar XAML con confianza en una representación XML o texto y mantener la validez de las declaraciones y propósitos de ese archivo XAML cuando las herramientas lo consumen, las operaciones de compilación de marcado o la fase en tiempo de ejecución de la aplicación de Windows Runtime.

Optimización de XAML para el rendimiento de carga

Estas son algunas sugerencias para definir elementos de interfaz de usuario en XAML mediante procedimientos recomendados para el rendimiento. Muchas de estas sugerencias se relacionan con el uso de recursos XAML, pero se enumeran aquí en la introducción general de XAML para mayor comodidad. Para obtener más información sobre los recursos XAML, consulta Referencias a recursos XAML y ResourceDictionary. Para obtener más sugerencias sobre el rendimiento, incluido XAML que demuestra específicamente algunos de los procedimientos de rendimiento deficientes que debes evitar en tu XAML, consulta Optimizar el marcado XAML.

  • Si usas el mismo pincel de color a menudo en tu XAML, define como SolidColorBrush un recurso en lugar de usar un color con nombre como un valor de atributo cada vez.
  • Si usa el mismo recurso en más de una página de interfaz de usuario, considere la posibilidad de definirlo en en Resources lugar de en cada página. Por el contrario, si solo una página usa un recurso, no la defina en Application.Resources y, en su lugar, defina solo para la página que la necesita. Esto es bueno para factorización XAML al diseñar la aplicación y para el rendimiento durante el análisis de XAML.
  • En el caso de los recursos que empaqueta la aplicación, compruebe si hay recursos no utilizados (un recurso que tiene una clave, pero no hay ninguna referencia staticResource en la aplicación que la use). Quítelos del XAML antes de liberar la aplicación.
  • Si usas archivos XAML independientes que proporcionan recursos de diseño (MergedDictionaries), considera la posibilidad de comentar o quitar recursos sin usar de estos archivos. Incluso si tienes un punto de partida XAML compartido que estás usando en más de una aplicación o que proporciona recursos comunes para toda la aplicación, sigue siendo la aplicación que empaqueta los recursos XAML cada vez y, posiblemente, tiene que cargarlos.
  • No defina los elementos de la interfaz de usuario que no necesite para la composición y use las plantillas de control predeterminadas siempre que sea posible (estas plantillas ya se han probado y comprobado para el rendimiento de la carga).
  • Use contenedores como Border , por ejemplo, en lugar de sobredraws deliberados de elementos de la interfaz de usuario. Básicamente, no dibuje el mismo píxel varias veces. Para obtener más información sobre el sobredraw y cómo probarla, consulta DebugSettings.IsOverdrawHeatMapEnabled.
  • Use las plantillas de elementos predeterminadas para ListView o GridView; tienen lógica especial del moderador que resuelve los problemas de rendimiento al compilar el árbol visual para un gran número de elementos de lista.

Depuración de XAML

Dado que XAML es un lenguaje de marcado, algunas de las estrategias típicas para la depuración en Microsoft Visual Studio no están disponibles. Por ejemplo, no hay ninguna manera de establecer un punto de interrupción dentro de un archivo XAML. Sin embargo, hay otras técnicas que pueden ayudarte a depurar problemas con definiciones de interfaz de usuario u otro marcado XAML mientras sigues desarrollando la aplicación.

Cuando hay problemas con un archivo XAML, el resultado más típico es que algún sistema o la aplicación producirán una excepción de análisis XAML. Siempre que haya una excepción de análisis XAML, el XAML cargado por el analizador XAML no pudo crear un árbol de objetos válido. En algunos casos, como cuando el XAML representa la primera "página" de la aplicación que se carga como objeto visual raíz, la excepción de análisis XAML no se puede recuperar.

XAML se edita a menudo dentro de un IDE como Visual Studio y una de sus superficies de diseño XAML. Visual Studio a menudo puede proporcionar validación en tiempo de diseño y comprobación de errores de un origen XAML mientras lo edita. Por ejemplo, podría mostrar "subrayados ondulados" en el editor de texto XAML tan pronto como escriba un valor de atributo incorrecto y ni siquiera tendrá que esperar a que se pase una compilación XAML para ver que algo está mal con la definición de la interfaz de usuario.

Una vez que la aplicación se ejecuta realmente, si se han detectado errores de análisis XAML en tiempo de diseño, common Language Runtime (CLR) notifica estos errores como xamlParseException. Para obtener más información sobre lo que podrías hacer para una XamlParseException en tiempo de ejecución, consulta Control de excepciones para aplicaciones de Windows Runtime en C# o Visual Basic.

Nota:

Las aplicaciones que usan C++/CX para el código no obtienen la excepción XamlParseException específica. Pero el mensaje de la excepción aclara que el origen del error está relacionado con XAML e incluye información de contexto como números de línea en un archivo XAML, al igual que lo hace XamlParseException .

Para obtener más información sobre la depuración de una aplicación de Windows Runtime, consulta Iniciar una sesión de depuración.