Omówienie języka XAML

W tym artykule przedstawiono język XAML i pojęcia XAML dla odbiorców deweloperów aplikacji Środowiska uruchomieniowego systemu Windows oraz opisano różne sposoby deklarowania obiektów i ustawiania atrybutów w języku XAML, ponieważ jest on używany do tworzenia aplikacji środowiska uruchomieniowego systemu Windows.

Co to jest XAML?

Extensible Application Markup Language (XAML) to język deklaratywny. W szczególności język XAML może inicjować obiekty i ustawiać właściwości obiektów przy użyciu struktury języka, która pokazuje hierarchiczne relacje między wieloma obiektami i konwencją typu zapasowego, która obsługuje rozszerzenia typów. Widoczne elementy interfejsu użytkownika można utworzyć w deklaratywnych znacznikach XAML. Następnie można skojarzyć oddzielny plik z kodem dla każdego pliku XAML, który może reagować na zdarzenia i manipulować obiektami, które zostały pierwotnie zadeklarowane w języku XAML.

Język XAML obsługuje wymianę źródeł między różnymi narzędziami i rolami w procesie programowania, takich jak wymiana źródeł XAML między narzędziami projektowymi a interaktywnym środowiskiem projektowym (IDE) lub między deweloperami podstawowymi i deweloperami lokalizacji. Używając języka XAML jako formatu wymiany, role projektanta i role dewelopera mogą być oddzielone lub połączone, a projektanci i deweloperzy mogą iterować podczas produkcji aplikacji.

Gdy są one widoczne jako część projektów aplikacji środowiska uruchomieniowego systemu Windows, pliki XAML są plikami XML z rozszerzeniem nazwy pliku xaml.

Podstawowa składnia XAML

Język XAML ma podstawową składnię, która opiera się na kodzie XML. Z definicji prawidłowy kod XAML musi być również prawidłowym kodem XML. Jednak język XAML ma również pojęcia składni, które są przypisane do innego i bardziej kompletnego znaczenia, ale nadal są prawidłowe w formacie XML zgodnie ze specyfikacją XML 1.0. Na przykład język XAML obsługuje składnię elementu właściwości, gdzie wartości właściwości można ustawiać w elementach, a nie jako wartości ciągu w atrybutach lub jako zawartość. W przypadku zwykłego kodu XML element właściwości XAML jest elementem z kropką w nazwie, dlatego jest prawidłowy dla zwykłego kodu XML, ale nie ma tego samego znaczenia.

XAML i Visual Studio

Program Microsoft Visual Studio ułatwia tworzenie prawidłowej składni XAML, zarówno w edytorze tekstów XAML, jak i w bardziej zorientowanej graficznie powierzchni projektowej XAML. Podczas pisania kodu XAML dla aplikacji przy użyciu programu Visual Studio nie martw się zbytnio o składnię przy każdym naciśnięciu. Środowisko IDE zachęca do prawidłowej składni XAML, udostępniając wskazówki dotyczące autouzupełniania, pokazując sugestie w listach IntelliSense firmy Microsoft i rozwijanych menu, prezentując biblioteki elementów interfejsu użytkownika w oknie Przybornik oraz wykorzystując inne techniki. Jeśli jest to twoje pierwsze doświadczenie z językiem XAML, warto znać reguły składni, a zwłaszcza terminologię, która jest czasami używana do opisywania ograniczeń lub wyborów podczas opisywania składni XAML w dokumentacji lub innych tematach. Szczegółowe punkty składni XAML zostały omówione w osobnym temacie— przewodnik po składni języka XAML.

Przestrzenie nazw XAML

Ogólnie rzecz biorąc, przestrzeń nazw to koncepcja organizacyjna, która określa, w jaki sposób są interpretowane identyfikatory jednostek programowania. Korzystając z przestrzeni nazw, platforma programowania może oddzielić identyfikatory zadeklarowane przez użytkownika od identyfikatorów zadeklarowanych przez platformę, uściślać identyfikatory za pomocą kwalifikacji przestrzeni nazw, wymuszać reguły określania zakresu nazw itd. Język XAML ma własną koncepcję przestrzeni nazw XAML, która służy do tego celu dla języka XAML. Oto jak język XAML stosuje i rozszerza pojęcia dotyczące przestrzeni nazw języka XML:

• Język XAML używa zarezerwowanego atrybutu XML xmlns do deklaracji przestrzeni nazw. Wartość atrybutu jest zazwyczaj identyfikatorem URI (Uniform Resource Identifier), który jest konwencją dziedziczona z kodu XML.
• Język XAML używa prefiksów w deklaracjach do deklarowania przestrzeni nazw innych niż domyślne, a użycie prefiksów w elementach i atrybutach odwołuje się do tej przestrzeni nazw.
• Język XAML ma pojęcie domyślnej przestrzeni nazw, którą wykorzystuje się, gdy brak jest prefiksu w użyciu lub deklaracji. Domyślną przestrzeń nazw można zdefiniować inaczej dla każdej platformy programowania XAML.
• Definicje przestrzeni nazw dziedziczą w ramach pliku lub struktury XAML od elementu nadrzędnego do elementu podrzędnego. Jeśli na przykład zdefiniujesz przestrzeń nazw w elemecie głównym pliku XAML, wszystkie elementy w tym pliku dziedziczą tę definicję przestrzeni nazw. Jeśli element dalej na stronie ponownie definiuje przestrzeń nazw, obiekty podrzędne tego elementu dziedziczą nową definicję.
• Atrybuty elementu dziedziczą przestrzenie nazw elementu. Rzadko widzimy prefiksy przy atrybutach XAML.

Plik XAML prawie zawsze deklaruje domyślną przestrzeń nazw XAML w swoim elemercie głównym. Domyślna przestrzeń nazw XAML definiuje, które elementy można zadeklarować bez kwalifikowania ich przez prefiks. W przypadku typowych projektów aplikacji Środowiska uruchomieniowego systemu Windows ta domyślna przestrzeń nazw zawiera wszystkie wbudowane słownictwo XAML dla środowiska uruchomieniowego systemu Windows, które jest używane w definicjach interfejsu użytkownika: domyślne kontrolki, elementy tekstowe, grafika XAML i animacje, powiązania danych i typy obsługi stylów itd. Większość kodu XAML, który napiszesz dla aplikacji środowiska uruchomieniowego systemu Windows, będzie w stanie uniknąć używania przestrzeni nazw I prefiksów XAML podczas odwoływania się do typowych elementów interfejsu użytkownika.

Oto fragment kodu przedstawiający utworzony przez szablon korzeń strony początkowej aplikacji (pokazujący tylko tag otwierający i uproszczony). Deklaruje domyślną przestrzeń nazw oraz przestrzeń nazw x (co wyjaśnimy dalej).

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

Przestrzeń nazw języka XAML

Jedna konkretna przestrzeń nazw XAML, zadeklarowana w prawie każdym pliku XAML środowiska uruchomieniowego systemu Windows, to przestrzeń nazw języka XAML. Ta przestrzeń nazw zawiera elementy i pojęcia zdefiniowane przez specyfikację języka XAML. Zgodnie z konwencją przestrzeń nazw języka XAML jest mapowana na prefiks "x". Domyślne szablony projektów i plików dla projektów aplikacji Środowiska uruchomieniowego systemu Windows zawsze definiują domyślną przestrzeń nazw XAML (bez prefiksu, tylko xmlns=) i przestrzeń nazw XAML języka XAML (prefiks "x") jako część elementu głównego.

Przestrzeń nazw XAML języka XAML z prefiksem "x" zawiera kilka konstrukcji programistycznych, które są często używane w XAML. Oto najczęstsze z nich:

Istnieją inne konstrukcje programowania w przestrzeni nazw XAML języka XAML, ale nie są tak powszechne.

Mapowanie typów niestandardowych na przestrzenie nazw XAML

Jednym z najbardziej zaawansowanych aspektów języka XAML jest to, że łatwo rozszerzyć słownictwo XAML dla aplikacji środowiska uruchomieniowego systemu Windows. Możesz zdefiniować własne typy niestandardowe w języku programowania swojej aplikacji i następnie odnosić się do nich w znacznikach XAML. Obsługa rozszerzeń za pomocą typów niestandardowych jest zasadniczo wbudowana w sposób działania języka XAML. Frameworki lub deweloperzy aplikacji są odpowiedzialni za tworzenie obiektów wspierających, do których odwołuje się XAML. Ani struktury, ani deweloper aplikacji nie są związani ze specyfikacjami dotyczącymi tego, co obiekty w ich słownikach reprezentują lub robią, poza podstawowymi zasadami składni XAML. Chociaż istnieją oczekiwania dotyczące tego, co powinny robić typy w przestrzeni nazw XAML, środowisko uruchomieniowe systemu Windows zapewnia całą niezbędną obsługę.

Jeśli używasz języka XAML dla typów pochodzących z bibliotek innych niż podstawowe biblioteki i metadane środowiska uruchomieniowego systemu Windows, musisz zadeklarować i zamapować przestrzeń nazw XAML z prefiksem. Użyj tego prefiksu w użyciu elementów, aby odwołać się do typów zdefiniowanych w bibliotece. Mapowania prefiksów są deklarowane jako atrybuty xmlns , zazwyczaj w elemecie głównym wraz z innymi definicjami przestrzeni nazw XAML.

Aby utworzyć własną definicję przestrzeni nazw odwołującą się do typów niestandardowych, należy najpierw określić słowo kluczowe xmlns:, a następnie odpowiedni prefiks. Wartość tego atrybutu musi zawierać słowo kluczowe using: jako pierwszą część wartości. Pozostała część wartości to token ciągu, który odwołuje się do określonej przestrzeni nazw powiązanej z kodem, zawierającej niestandardowe typy według nazwy.

Prefiks definiuje token znaczników używany do odwoływania się do tej przestrzeni nazw XAML w pozostałej części kodu znaczników w tym pliku XAML. Znak dwukropka (:) przechodzi między prefiksem a jednostką, do których ma się odwoływać w przestrzeni nazw XAML.

Na przykład składnia atrybutu do mapowania prefiksu myTypes na przestrzeń nazw myCompany.myTypes to: , a reprezentatywne użycie elementu to: xmlns:myTypes="using:myCompany.myTypes"<myTypes:CustomButton/>

Aby uzyskać więcej informacji na temat mapowania przestrzeni nazw XAML dla typów niestandardowych, w tym specjalnych zagadnień dotyczących rozszerzeń składników visual C++ (C++/CX), zobacz Przestrzenie nazw XAML i mapowanie przestrzeni nazw.

Inne przestrzenie nazw XAML

Często można zobaczyć pliki XAML definiujące prefiksy "d" (dla przestrzeni nazw projektanta) i "mc" (w celu zapewnienia zgodności ze znacznikami). Ogólnie rzecz biorąc, są one przeznaczone do obsługi infrastruktury lub do tworzenia scenariuszy w narzędziu projektowym. Aby uzyskać więcej informacji, zobacz sekcję "Inne przestrzenie nazw XAML" w temacie Przestrzenie nazw XAML.

Rozszerzenia znaczników

Rozszerzenia znaczników to koncepcja języka XAML, która jest często używana w implementacji XAML środowiska uruchomieniowego systemu Windows. Rozszerzenia znaczników często reprezentują jakiś "skrót", który umożliwia plikowi XAML dostęp do wartości lub zachowania, które nie polega tylko na deklarowaniu elementów na podstawie typów bazowych. Niektóre rozszerzenia znaczników mogą ustawiać właściwości przy użyciu zwykłych ciągów lub dodatkowych zagnieżdżonych elementów, co ma na celu usprawnienie składni lub refaktoryzację między różnymi plikami XAML.

W składni atrybutów XAML nawiasy klamrowe "{" i "}" wskazują użycie rozszerzenia znaczników XAML. To użycie kieruje proces przetwarzania XAML do unikania ogólnego podejścia, które traktuje wartości atrybutów jako ciągi dosłowne lub jako wartości bezpośrednio konwertowalne na ciąg. Zamiast tego analizator XAML wywołuje kod, który zapewnia zachowanie dla tego konkretnego rozszerzenia znaczników, a ten kod udostępnia alternatywny obiekt lub wynik zachowania, którego potrzebuje analizator XAML. Rozszerzenia znaczników mogą mieć argumenty, które są zgodne z nazwą rozszerzenia znaczników, a także znajdują się w nawiasach klamrowych. Zazwyczaj oceniane rozszerzenie znaczników zapewnia wartość zwracaną przez obiekt. Podczas analizowania ta wartość zwrotna jest wstawiana do pozycji w drzewie obiektów, gdzie użycie rozszerzenia znaczników miało miejsce w źródłowym kodzie XAML.

Środowisko uruchomieniowe Windows XAML obsługuje te rozszerzenia znaczników, które są zdefiniowane w domyślnej przestrzeni nazw XAML i rozumiane przez analizator XAML środowiska uruchomieniowego Windows.

• {x:Bind}: obsługuje powiązanie danych, które odkłada ocenę właściwości do czasu wykonywania programu, poprzez wykonanie specjalnego kodu przeznaczenia, który jest generowany w czasie kompilacji. To rozszerzenie znaczników obsługuje szeroką gamę argumentów.
• {Binding}: obsługuje powiązanie danych, które odkłada ocenę właściwości do czasu wykonania przez użycie inspekcji obiektów środowiska uruchomieniowego ogólnego zastosowania. To rozszerzenie znaczników obsługuje szeroką gamę argumentów.
• {StaticResource}: obsługuje odwoływanie się do wartości zasobów zdefiniowanych w elemencie ResourceDictionary. Te zasoby mogą znajdować się w innym pliku XAML, ale ostatecznie muszą być znajdowane przez analizator XAML w czasie ładowania. Argument {StaticResource} użycia identyfikuje klucz (nazwę) dla zasobu z kluczem w elemencie ResourceDictionary.
• {ThemeResource}: podobny do {StaticResource}, ale może reagować na zmiany motywu czasu wykonywania. Element {ThemeResource} jest często wyświetlany w domyślnych szablonach XAML środowiska uruchomieniowego systemu Windows, ponieważ większość tych szablonów jest przeznaczona do zapewnienia zgodności z użytkownikiem przełączającym motyw podczas działania aplikacji.
• {TemplateBinding}: specjalny przypadek elementu {Binding} , który obsługuje szablony kontrolek w języku XAML i ich ostateczne użycie w czasie wykonywania.
• {RelativeSource}: włącza określoną formę powiązania szablonu, w której wartości pochodzą z szablonowego elementu nadrzędnego.
• {CustomResource}: w przypadku zaawansowanych scenariuszy wyszukiwania zasobów.

Środowisko uruchomieniowe systemu Windows obsługuje również rozszerzenie znaczników {x:Null}. Służy do ustawiania wartości null na null w języku XAML. Możesz na przykład użyć tego w szablonie kontrolki dla CheckBox, która interpretuje null jako nieokreślony stan zaznaczenia (wyzwalając stan wizualny "Nieokreślony").

Rozszerzenie znaczników zazwyczaj zwraca istniejące wystąpienie z innej części grafu obiektów w aplikacji lub odkłada wartość do czasu wykonania. Ponieważ można użyć rozszerzenia znaczników jako wartości atrybutu, a jest to typowe zastosowanie, często widzi się rozszerzenie znaczników dostarczające wartości dla właściwości typu referencyjnego, które w przeciwnym razie wymagałyby składni elementu właściwości.

Na przykład poniżej przedstawiono składnię odwoływania się do stylu wielokrotnego użytku z klasy ResourceDictionary: <Button Style="{StaticResource SearchButtonStyle}"/>. Styl jest typem odwołania, a nie prostą wartością, więc bez {StaticResource} użycia potrzebny <Button.Style> byłby element właściwości i <Style> definicja w niej, aby ustawić właściwość FrameworkElement.Style.

Przy użyciu rozszerzeń znaczników każda właściwość ustawiana w języku XAML jest potencjalnie ustawiana w składni atrybutów. Składnia atrybutów umożliwia podanie wartości referencyjnych dla właściwości, nawet jeśli nie obsługuje składni atrybutu dla bezpośredniej instancji obiektu. Możesz też włączyć określone zachowanie, które odchyla ogólne wymaganie, aby właściwości XAML były wypełniane przez typy wartości lub nowo utworzone typy odwołań.

Aby zilustrować, następny przykład XAML ustawia wartość właściwości FrameworkElement.Styleobramowania przy użyciu składni atrybutu. Właściwość FrameworkElement.Style przyjmuje wystąpienie klasy Style , czyli typ odwołania, którego domyślnie nie można utworzyć przy użyciu ciągu składni atrybutu. Jednak w tym przypadku atrybut odwołuje się do określonego rozszerzenia znaczników StaticResource. Po przetworzeniu tego rozszerzenia znaczników zwraca odwołanie do elementu Style zdefiniowanego wcześniej jako zasób klucza w słowniku zasobów.

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

Rozszerzenia znaczników można zagnieżdżać. Najwewnętrzniejsze rozszerzenie znaczników jest oceniane najpierw.

Ze względu na rozszerzenia znaczników, potrzebna jest specjalna składnia, aby umieścić dosłowną wartość "{" w atrybucie. Aby uzyskać więcej informacji, zobacz Przewodnik składni języka XAML.

Events

XAML to język deklaratywny dla obiektów i ich właściwości, ale zawiera również składnię dołączania programów obsługi zdarzeń do obiektów w znacznikach. Składnia zdarzeń XAML może następnie zintegrować zdarzenia zadeklarowane przez XAML za pośrednictwem modelu programowania środowiska uruchomieniowego systemu Windows. Należy określić nazwę zdarzenia jako nazwę atrybutu w obiekcie, w którym jest obsługiwane zdarzenie. Dla wartości atrybutu należy określić nazwę funkcji obsługi zdarzeń definiowanej w kodzie. Procesor XAML używa tej nazwy do utworzenia reprezentacji delegata w załadowanym drzewie obiektów i dodaje określoną procedurę obsługi do wewnętrznej listy procedur obsługi. Prawie wszystkie aplikacje środowiska uruchomieniowego systemu Windows są definiowane zarówno przez źródła znaczników, jak i kod w tle.

Oto prosty przykład. Klasa Button obsługuje zdarzenie o nazwie Click. Możesz napisać procedurę obsługi kliknięcia , która uruchamia kod, który powinien być wywoływany po kliknięciu przycisku przez użytkownika. W XAML należy określić Click jako atrybut dla przycisku. Dla wartości atrybutu podaj ciąg, który jest nazwą metody programu obsługi.

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

Po skompilowaniu kompilator oczekuje teraz, że w pliku kodu-behind będzie zdefiniowana metoda o nazwie showUpdatesButton_Click, zlokalizowana w przestrzeni nazw zadeklarowanej w wartości x:Class strony XAML. Ponadto metoda ta musi spełniać wymogi kontraktu delegata na zdarzenie Click. Przykład:

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

W ramach projektu kod XAML jest zapisywany jako plik .xaml, a ty używasz preferowanego języka (C#, Visual Basic, C++/CX), aby napisać plik z kodem zaplecza. Gdy plik XAML jest kompilowany jako część procesu kompilacji projektu, lokalizacja pliku code-behind XAML dla każdej strony XAML jest identyfikowana poprzez określenie przestrzeni nazw i klasy jako atrybutu x:Class elementu głównego w stronie XAML. Aby uzyskać więcej informacji na temat sposobu działania tych mechanizmów w języku XAML i ich powiązania z modelami programowania i aplikacji, zobacz Omówienie zdarzeń i zdarzeń kierowanych.

Słowniki zasobów

Tworzenie elementu ResourceDictionary to typowe zadanie, które jest zwykle wykonywane przez utworzenie słownika zasobów jako obszaru strony XAML lub oddzielnego pliku XAML. Słowniki zasobów i sposób ich używania to większy obszar koncepcyjny, który znajduje się poza zakresem tego tematu. Aby uzyskać więcej informacji, zobacz ResourceDictionary i odniesienia do zasobów XAML.

XAML i XML

Język XAML jest zasadniczo oparty na języku XML. Jednak język XAML znacznie rozszerza kod XML. W szczególności traktuje koncepcję schematu zupełnie inaczej ze względu na jego relację z koncepcją typu bazowego i dodaje elementy języka, takie jak załączone członki i rozszerzenia składni. xml:lang jest prawidłowy w języku XAML, ale wpływa na środowisko uruchomieniowe zamiast analizować zachowanie i zazwyczaj jest aliasowany do właściwości na poziomie platformy. Aby uzyskać więcej informacji, zobacz FrameworkElement.Language. xml:base jest prawidłowy w znacznikach, ale analizatory go ignorują. xml:space jest prawidłowy, ale dotyczy tylko scenariuszy opisanych w temacie XAML i białych znaków . Atrybut kodowania jest prawidłowy w języku XAML. Obsługiwane są tylko kodowania UTF-8 i UTF-16. Kodowanie UTF-32 nie jest obsługiwane.

Czułość wielkości liter w języku XAML

W języku XAML jest uwzględniana wielkość liter. Jest to kolejna konsekwencja tego, że XAML jest oparty na XML, który jest wrażliwy na wielkość liter. Nazwy elementów i atrybutów XAML są rozróżnialne pod względem wielkości liter. Wartość atrybutu może być wrażliwa na wielkość liter; to zależy od tego, jak wartości atrybutów są obsługiwane przez określone właściwości. Na przykład, jeśli wartość atrybutu deklaruje nazwę elementu członkowskiego wyliczenia, wbudowane zachowanie, które dokonuje konwersji typu ciągu znaków z nazwą elementu w celu zwrócenia wartości członka wyliczenia, nie rozróżnia wielkości liter. Natomiast wartość właściwości Name i metody pomocnicze do pracy z obiektami na podstawie nazwy zadeklarowanej przez właściwość Name traktują ciąg nazwy jako rozróżniający wielkość liter.

Zakresy nazw XAML

Język XAML definiuje pojęcie zakresu nazw XAML. Koncepcja zakresu nazw XAML wpływa na sposób, w jaki procesory XAML powinny traktować wartość x:Name lub Name zastosowane do elementów XAML, szczególnie zakresy, w których nazwy powinny być oparte na unikatowych identyfikatorach. Zakresy nazw XAML zostały szczegółowo omówione w osobnym temacie; zobacz Zakresy nazw XAML.

Rola XAML w procesie programowania

Język XAML odgrywa kilka ważnych ról w procesie tworzenia aplikacji.

• XAML to podstawowy format deklarowania interfejsu użytkownika i elementów aplikacji w tym interfejsie użytkownika, jeśli programujesz przy użyciu języka C#, Visual Basic lub C++/CX. Zazwyczaj co najmniej jeden plik XAML w projekcie reprezentuje metaforę strony w aplikacji dla początkowo wyświetlanego interfejsu użytkownika. Dodatkowe pliki XAML mogą definiować dodatkowe strony dla interfejsu użytkownika nawigacyjnego. Inne pliki XAML mogą deklarować zasoby, takie jak szablony lub style.
• Format XAML służy do deklarowania stylów i szablonów zastosowanych do kontrolek i interfejsu użytkownika aplikacji.
• Możesz użyć stylów i szablonów do tworzenia szablonów istniejących kontrolek lub jeśli zdefiniujesz kontrolkę, która dostarcza szablon domyślny jako część pakietu kontrolnego. Jeśli używasz go do definiowania stylów i szablonów, odpowiedni kod XAML jest często deklarowany jako dyskretny plik XAML z katalogiem głównym ResourceDictionary .
• XAML jest typowym formatem obsługi projektanta tworzenia interfejsu użytkownika aplikacji i wymiany projektu interfejsu użytkownika między różnymi aplikacjami projektanta. W szczególności język XAML dla aplikacji może być wymieniany między różnymi narzędziami projektowymi XAML (lub oknami projektowymi w narzędziach).
• Kilka innych technologii definiuje również podstawowy interfejs użytkownika w języku XAML. W odniesieniu do XAML dla Windows Presentation Foundation (WPF) i Microsoft Silverlight XAML, XAML dla środowiska uruchomieniowego Windows używa tego samego identyfikatora URI dla wspólnej domyślnej przestrzeni nazw XAML. Słownictwo XAML dla środowiska uruchomieniowego systemu Windows znacznie nakłada się na słownictwo XAML-for-UI używane również przez program Silverlight i w nieco mniejszym stopniu przez WPF. W związku z tym XAML promuje efektywną ścieżkę migracji interfejsu użytkownika pierwotnie zdefiniowaną dla technologii prekursorów, które również używały języka XAML.
• Język XAML definiuje wygląd wizualny interfejsu użytkownika, a skojarzony plik z kodem definiuje logikę. Projekt interfejsu użytkownika można dostosować bez wprowadzania zmian w logice w kodzie. Język XAML upraszcza przepływ pracy między projektantami i deweloperami.
• Ze względu na bogactwo projektanta wizualnego i obsługę powierzchni projektowej dla języka XAML język XAML obsługuje szybkie tworzenie prototypów interfejsu użytkownika we wczesnych fazach programowania.

W zależności od własnej roli w procesie programowania możesz nie korzystać z kodu XAML. Stopień interakcji z plikami XAML zależy również od używanego środowiska programistycznego, niezależnie od tego, czy używasz interaktywnych funkcji środowiska projektowego, takich jak przyborniki i edytory właściwości, oraz zakres i cel aplikacji Środowiska uruchomieniowego systemu Windows. Niemniej jednak prawdopodobnie podczas opracowywania aplikacji będziesz edytować plik XAML na poziomie elementu przy użyciu tekstu lub edytora XML. Korzystając z tych informacji, możesz bezpiecznie edytować kod XAML w reprezentacji tekstowej lub XML i zachować ważność deklaracji i przeznaczenia tego pliku XAML, gdy jest używany przez narzędzia, operacje kompilowania znaczników lub fazę czasu wykonywania aplikacji środowiska uruchomieniowego systemu Windows.

Optymalizowanie kodu XAML pod kątem wydajności ładowania

Poniżej przedstawiono kilka wskazówek dotyczących definiowania elementów interfejsu użytkownika w języku XAML przy użyciu najlepszych rozwiązań dotyczących wydajności. Wiele z tych wskazówek odnosi się do korzystania z zasobów XAML, ale są wymienione tutaj w ogólnym omówieniu języka XAML dla wygody. Aby uzyskać więcej informacji na temat zasobów XAML, zobacz ResourceDictionary i odwołania do zasobów XAML. Aby uzyskać więcej wskazówek dotyczących wydajności, w tym XAML, który celowo demonstruje niektóre niewłaściwe praktyki wydajnościowe, których należy unikać podczas pracy z XAML, zobacz Optymalizowanie znaczników XAML.

• Jeśli używasz tego samego pędzla kolorów często w języku XAML, zdefiniuj element SolidColorBrush jako zasób, zamiast używać nazwanego koloru jako wartości atrybutu za każdym razem.
• Jeśli używasz tego samego zasobu na więcej niż jednej stronie interfejsu użytkownika, rozważ zdefiniowanie go w obszarze Application.Resources , a nie na każdej stronie. Z drugiej strony, jeśli tylko jedna strona używa zasobu, nie zdefiniuj go w obszarze Application.Resources i zamiast tego zdefiniuj ją tylko dla strony, która jej potrzebuje. Jest to dobre zarówno w przypadku faktoringu XAML podczas projektowania aplikacji, jak i wydajności podczas analizowania kodu XAML.
• W przypadku zasobów zawartych w pakietach aplikacji należy sprawdzić nieużywane zasoby (zasoby, które mają klucz, ale w aplikacji nie ma odwołania do StaticResource). Usuń je z kodu XAML przed wydaniem aplikacji.
• Jeśli używasz oddzielnych plików XAML, które udostępniają zasoby projektowe (MergedDictionaries), rozważ komentarz lub usunięcie nieużywanych zasobów z tych plików. Nawet jeśli masz współużytkowany punkt wyjścia XAML używany w więcej niż jednej aplikacji lub udostępnia wspólne zasoby dla całej aplikacji, nadal aplikacja pakuje zasoby XAML za każdym razem i potencjalnie musi je załadować.
• Nie należy definiować elementów interfejsu użytkownika, których nie potrzebujesz do tworzenia, i używaj domyślnych szablonów kontrolek, jeśli to możliwe (te szablony zostały już przetestowane i zweryfikowane pod kątem wydajności ładowania).
• Używaj kontenerów, takich jak Obramowanie , a nie celowe przerysowywanie elementów interfejsu użytkownika. Zasadniczo nie rysuj tego samego piksela wiele razy. Aby uzyskać więcej informacji o przerysowaniu i sposobie jego testowania, zobacz DebugSettings.IsOverdrawHeatMapEnabled.
• Użyj domyślnych szablonów elementów dla ListView lub GridView; mają one specjalną logikę Presentera, która rozwiązuje problemy z wydajnością podczas budowania drzewa wizualnego dla dużej liczby elementów na liście.

Debugowanie kodu XAML

Ponieważ język XAML jest językiem znaczników, niektóre typowe strategie debugowania w programie Microsoft Visual Studio nie są dostępne. Na przykład nie ma możliwości ustawienia punktu przerwania w pliku XAML. Istnieją jednak inne techniki, które mogą ułatwić debugowanie problemów z definicjami interfejsu użytkownika lub innymi znacznikami XAML podczas opracowywania aplikacji.

Jeśli występują problemy z plikiem XAML, najbardziej typowym wynikiem jest to, że jakiś system lub aplikacja zgłosi wyjątek analizy XAML. Za każdym razem, gdy wystąpi wyjątek analizy XAML, kod XAML załadowany przez analizator XAML nie może utworzyć prawidłowego drzewa obiektów. W niektórych przypadkach, takich jak gdy kod XAML reprezentuje pierwszą "stronę" aplikacji, która jest ładowana jako wizualizacja główna, wyjątek analizy XAML nie jest możliwy do odzyskania.

Język XAML jest często edytowany w IDE, takim jak Visual Studio, na jednym z jego projektowych interfejsów XAML. Program Visual Studio często umożliwia walidację i sprawdzanie błędów kodu XAML w czasie projektowania podczas jego edytowania. Na przykład może być wyświetlany komunikat "squiggles" w edytorze tekstów XAML, gdy tylko wpiszesz nieprawidłową wartość atrybutu, a nawet nie będzie trzeba czekać na przekazanie kompilacji XAML, aby zobaczyć, że coś jest nie tak z definicją interfejsu użytkownika.

Po uruchomieniu aplikacji, jeśli jakiekolwiek błędy analizy XAML nie zostały wykryte w czasie projektowania, są one zgłaszane przez środowisko uruchomieniowe języka wspólnego (CLR) jako XamlParseException. Aby uzyskać więcej informacji na temat tego, co można zrobić podczas wystąpienia błędu XamlParseException, zobacz Obsługa wyjątków w aplikacjach Windows Runtime w języku C# lub Visual Basic.

Aby uzyskać więcej informacji na temat debugowania aplikacji środowiska uruchomieniowego systemu Windows, zobacz Uruchamianie sesji debugowania.