Мои первые советы по XAML для универсальной платформы Windows

Я недавно познакомился с технологиями пользовательского интерфейса от Microsoft. Я никогда не использовал Windows Framework (WPF) поверх .net и никогда не использовал Silverlight в Интернете. В прошлом году я впервые попробовал эти инструменты через фреймворк XAML, который является частью “Универсальной платформы Windows” (UWP) – то есть слоя пользовательского интерфейса Windows 10 (и Win8). XAML постоянно развивался со времен WPF, и потребовалось некоторое время, чтобы действительно понять различные основные эпохи этой технологии, тем более что в UWP-версии XAML убраны некоторые старые синтаксисы во имя эффективности на мобильных платформах, лучшей проверки ошибок во время компиляции, а также читабельности кода и простоты использования. Технология достаточно старая, поэтому большая часть поисковых запросов Google и результатов StackOverflow неприменима на современной платформе UWP.

Мои советы

Итак, какими были несколько моих первых уроков при использовании XAML на UWP?

Предпочитайте x:Bind привязке

Основная причина: x:Bind дает вам проверки во время компиляции и лучшую производительность. Имейте в виду небольшие различия:

• OneTime binding по умолчанию вместо OneWay binding
• Путь привязки – это элемент каркаса (элемент управления), а не DataContext (модель представления).

Отзывчивый дизайн

Комбинация VisualState и AdaptiveTriggers – это довольно мощный способ скрывать/показывать, перемещать или изменять размер различных частей пользовательского интерфейса. Единственное неудобство заключается в том, что вы не можете изменить стиль в ответ на изменение размера окна (или другой триггер), а только явно изменить свойства каждого отдельного элемента управления. Я попробовал одно обходное решение: создать фиктивный ViewModel DependencyProperty, который обновляется триггером, а затем привязать стили к этому свойству. Это работает, но не может быть предварительно просмотрено в XAML Designer, что мне показалось полезным. Вместо этого я создал фиктивный невидимый элемент управления, настроил триггеры на изменение этого элемента управления, а затем привязал стили к свойствам невидимого элемента управления. Это работает как “вживую”, так и в XAML Designer, даже обновляется вживую при изменении разрешения целевого устройства XAML Designer. Я нашел эту ссылку полезной по этому вопросу.

Выражения в вызовах x:Bind

В Windows Anniversary Edition (осень 2016 года) компания Microsoft добавила несколько новых замечательных возможностей, которые позволяют использовать действительно красивый и чистый синтаксис в XAML без использования конвертеров. Теперь вы можете сделать следующее при условии, что ваш класс ViewModel реализует функции xAnd и xMult:

Обратите внимание на несколько моментов:

• несмотря на наличие только булевых свойств ViewModel, мы можем выполнить над ними булевую операцию и автоматически преобразовать булевый результат в тип Visibility без каких-либо конвертеров. Всегда предпочитайте выражения x:Bind конвертерам.
• Вы можете писать одно- или многооперационные функции. (В Visual Studio 2015, XAML D
• Code-behind (исходный текст XAML View на C++ или C#) должен быть последним средством. Уже достаточно сложно следить за XAML-файлом и ViewModel; закапывание логики в View еще больше разделяет внимание читателя. Бывают ситуации, когда что-то является частью “View”, а не ViewModel: например, свойство, которое не имеет никакого отношения к модели и существует только для того, чтобы обеспечить реализацию XAML – например, свойство расстояния между элементами управления или что-то подобное. Это, пожалуй, единственный случай, когда код View-behind может иметь смысл. Но даже там – если вы можете сделать это в XAML, это обычно лучше.
• Используйте XAML Designer

XAML Designer – встроенный в Visual Studio визуальный редактор XAML – давно не пользовался особой любовью. Многие вещи сломаны, и он не может обрабатывать некоторые полезные вещи. И если вы не приложите усилий для правильной настройки XAML, страница/контрол может быть абсолютно нечитаемой. Почему стоит предпочесть XAML Designer?

Время компиляции для XAML – особенно если речь идет о генерации кода на C++ – просто зверское. Вы можете выполнять итерации намного быстрее, если избежите компиляции.

XAML Designer может сделать много отзывчивого дизайна, даже не выполняя сборку.

Это гораздо более быстрый способ изучить XAML и даже изучить события/свойства, о которых вы не знали.

Как сделать XAML Designer более удобным в использовании:

• Убедитесь, что ваш UserControl имеет настройки d:DesignWidth и d:DesignHeight.
• Убедитесь, что ViewModel имеет конструктор по умолчанию с нулевыми параметрами.
• Привязывайте ViewModel к DataContext в XAML, а не в code-behind. например,

Используйте AdaptiveTriggers для отзывчивого дизайна, а не логику ViewModel или View

• Добавьте FallbackValues для x:Binds, которые XAML Designer не может понять. Они будут использоваться только во время проектирования.
• Не пытайтесь получить “реальные” данные во время проектирования через d:DesignInstance; это не работает с 64-битным приложением или с x:Bind. (Теоретически, вы должны быть в состоянии написать
• Используйте Commands, получайте отключение бесплатно
• Зачем использовать Commands в качестве механизма для XAML/View для изменения состояния модели представления? Во-первых, это зачастую меньше кода: XAML может напрямую связываться со свойством команды модели представления, вместо того, чтобы XAML имел событие щелчка, а кодебайнд события щелчка представления затем изменял модель представления. Но также: вы можете настроить его таким образом, что когда команда “не может быть выполнена”, пользовательский интерфейс будет автоматически становиться серым и предотвращать нажатие. Детали: