Введение

Качество программного обеспечения зависит от широкого круга факторов: внешнего вида программы, ее способности взаимодействия с человеком, информационного содержимого, быстродействия и др. Чтобы создать хорошее программное обеспечение, нужны специалисты с различными навыками: художник-дизайнер для разработки запоминающегося визуального оформления, архитектор для организации информации, определения приоритетов и взаимосвязей содержимого и разработчик, способный объединить визуальное оформление с содержимым и серверными системами. Вряд ли один человек способен качественно справиться со всеми этими задачами. Поэтому для разработки программного обеспечения часто требуется объединить усилия сотрудников, выполняющих разные роли. В целом роли можно подразделить на разработчиков (включая архитекторов, программистов, инженеров-тестировщиков и т. д.) и дизайнеров (занимающихся созданием графики, интерактивных возможностей, визуальных эффектов и прочее).

Идея свести вместе дизайнеров и разработчиков для создания ПО не нова, однако их совместная работа никогда не отличалась эффективностью. В новой платформе пользовательского интерфейса Windows Presentation Foundation (WPF)¹, разработанной корпорацией Microsoft, упор делается на взаимодействие этих двух ролей, что ведет к принципиально новому способу создания программного обеспечения. Об этом свидетельствуют отчеты аналитиков² и решения, выводимые на рынок в настоящее время³.

Так в чем же отличие платформы Microsoft?⁴

• Для удобства интеграции, исключения неопределенности и сокращения избыточной работы при взаимодействии этих ролей корпорация Microsoft разработала новый язык разметки для представления интерфейсов пользователя. Этот язык получил название XAML (Extensible Application Markup Language — расширяемый язык разметки приложений).
• Помимо общего языка описания интерфейса пользователя Microsoft разработала новый набор средств, оптимизированных для конкретных задач, выполняемых каждой ролью в процессе создания приложений. Большая часть этих новых средств входит в состав решений Expression Studio и Visual Studio 2008.

Объединение новой платформы с новыми инструментами позволяет организовать в рамках проектов создания программного обеспечения такие процессы совместной работы, которые, в конечном счете, ведут к повышению производительности, сокращению времени вывода продуктов на рынок и созданию безукоризненного дизайна. В статье представлен анализ этого утверждения, чтобы показать теоретические и практические способы реализации возможностей данной новой «итерации».

Статья основана на результатах исследований и практическом опыте авторов. Исследования проводились с участием множества организаций, работающих в настоящее время с WPF. Их мнения приводятся в разных частях документа. Кроме того, были опрошены сами члены групп разработки продуктов семейства Expression, не только потому, что они обладают обширными знаниями о платформе и инструментах, но и потому, что сами эти продукты построены с помощью платформы WPF.

Как организована статья

В этой статье немало информации, которая может в разной степени заинтересовать аудиторию. Она затрагивает несколько тем и преследует несколько целей. Выбирайте разделы, которые представляют интерес именно для вас.

Раздел «Революция XAML» предназначен для тех, кто не знаком с этой платформой и хочет понять причины появления новой «итерации». Он в большей степени посвящен технологическим вопросам и объясняет, почему язык XAML обеспечивает новые возможности совместной работы разработчиков и дизайнеров.

В следующих двух разделах, посвященных ролям и инструментам, приводится краткое описание рабочего процесса в целом. Эти разделы стоит посмотреть тем, кто занимается руководством и координацией проекта. Также они будут интересны для самих дизайнеров и разработчиков, поскольку в них содержатся подробные сведения о том, как может измениться их повседневная работа благодаря новой платформе и инструментам.

Заключительные два раздела ориентированы на дизайнеров и разработчиков. В них содержатся практические советы и рекомендации для тех, кто готов работать с новой платформой. Эти разделы больше заинтересуют рядовых членов производственной цепочки.

Замечания по поводу Silverlight

Кросс-платформенный подключаемый модуль Microsoft Silverlight, предназначенный для создания многофункциональных интерактивных веб-сайтов, также использует язык XAML. Многие из инструментов, описываемых в данной статье, создают разметку XAML, которую можно использовать в приложениях Silverlight. По ряду причин технология Silverlight, несмотря на множество общих моментов, в статье не рассматривается. Во-первых, многие инструменты для создания проектов Silverlight все еще находятся на стадии альфа- и бета-версий, хотя уже выпущена официальная версия Silverlight 1.0. Во-вторых, данная статья посвящена разработке многофункциональных приложений для настольных компьютеров. Отличия веб-приложений достаточно существенны, так что они требуют отдельного рассмотрения в будущей статье.

Революция XAML

Ключом к реализации слаженной совместной работы разработчиков и дизайнеров над приложениями WPF служит язык XAML. Однако добиться эффективности совместной работы позволяет не сам язык XAML, а лежащая в его основе платформа WPF, доступ к которой осуществляется с помощью XAML. Поэтому важно понять, как работает XAML, как используется WPF в XAML, а также архитектуру системы в целом. Зачем применять язык разметки? В чем отличие XAML от других языков разметки? Ответы на эти вопросы дают почву для новых размышлений и более глубокого понимания возможностей этой платформы.

Зачем использовать язык разметки?

Для описания интерфейсов пользователя сейчас применяется несколько языков разметки: HTML, XUL, SVG, WordML и др.⁵ Эти языки, особенно HTML, служат убедительным доказательством успешного использования разметки для отображения интерфейса пользователя. Языки разметки на основе XML хорошо подходят для представления иерархических отношений и отношений типа «родительский — дочерний — одноуровневый» в интерфейсах пользователя.

Ключ к успеху синтаксиса разметки — в его понятности как для человека, так и для компьютера. На этот важный момент следует обратить внимание, поскольку он говорит о доступности языка разметки, особенно по сравнению с процедурными языками программирования. Есть немало людей без опыта написания программного обеспечения, которых не пугает синтаксис языка HTML, например. Однако возможность понимать разметку сама по себе необязательна, хоть и желательна. Синтаксис разметки генерируется соответствующими инструментами. Например, ключевым фактором широкого распространения языка HTML стали WYSIWYG-редакторы.

Язык XAML также понятен и человеку, и компьютеру. При этом он позволяет легко переключаться между инструментом и текстовым редактором — это преимущество не следует преуменьшать.

В чем отличие XAML от других языков разметки?

XAML не только поддерживает большую часть функциональности существующих языков разметки, в нем также появились новые функции и возможности, недоступные в других технологиях. Превосходство языка XAML достигается в трех ключевых областях: выразительность, полнота и расширяемость.

Выразительность

XAML обладает широкими возможностями. В нем поддерживаются все необходимые элементы управления (кнопки, списки и т. д.), функции макета (панели, сетки и т. д.) и текстовые функции (шрифты, форматирование и т. д.). Следующий пример (страница с одной кнопкой) наглядно демонстрирует сходство HTML и XAML.

<html xmlns="http://www.w3.org/1999/xhtml" > <body> <input type="button" value="Click Me" /> </body> </html>
<Page xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"> <Button Width="100" Height="50" Content="Click Me" /> </Page>

Страница с кнопкой. Синтаксис HTML в верхней строке, синтаксис XAML в нижней.

Язык XAML может представлять не только элементы управления, текст и макет. В нем также предусмотрен полный синтаксис для представления низкоуровневой векторной графики для описания форм, контуров, градиентов и т. д. Синтаксис низкоуровневого представления схож с языками описания векторной графики, что упрощает миграцию кода, написанного на таких языках.

<rect x="1" y="1" width="398" height="398" fill="none" /> <path d-"M 100 100 L 200 100 L 200 300 z" fill="#A3A993" stroke="A8806C" stroke-width="3" />
<Canvas xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation" Width="398" Height="398"> <Path Data="M100, 100L200,100 200, 300z" Fill="#A3A993" Stroke="#A8806C" StrokeThickness="3" /> </Canvas>

Векторное представление треугольника. Синтаксис SVG сверху, синтаксис XAML снизу.

Возможности языка выходят за рамки представления двумерной графики в трехмерную. В языке XAML встроена поддержка представления трехмерных сцен, включая камеры, освещение, матричные преобразования и сетки.

Полнота

Язык XAML может представлять не только визуальное оформление. Он позволяет реализовать мощные возможности платформы WPF. К самым важным областям, в которых XAML позволяет улучшить совместную работу дизайнеров и разработчиков, относятся стили, триггеры, шаблоны элементов управления, шаблоны данных, привязки данных и анимация.

• Стили. Стили — признанный способ отделить содержимое от его внешнего вида. Платформа WPF не только поддерживает определение стилей с помощью XAML. Связывание стилей с триггерами и шаблонами увеличивает гибкость создания расширенных интерфейсов пользователя, при этом содержимое остается отделенным от своего внешнего вида.
• Шаблоны. В платформе WPF предусмотрены два типа шаблонов:
  • шаблоны элементов управления позволяют дизайнеру полностью переопределять визуальные элементы управления, не изменяя его основного поведения;
  • шаблоны данных позволяют дизайнеру создавать наборы визуальных элементов для представления определенных типов данных, не определяя пользовательские элементы управления для связывания данных и интерфейса пользователя.
• Привязка данных. В платформе WPF привязки данных используются повсеместно. Благодаря возможности расширения XAML привязка данных может быть доступна из разметки (и таких инструментов, как Expression Blend), что упрощает дизайнеру связывание основных привязок между интерфейсом пользователя и бизнес-объектами или данными XML.
• Анимация. Платформа WPF включает очень мощную систему анимации, представление которой может осуществляться и инициироваться с помощью XAML. Благодаря этому дизайнер может создавать взаимодействия для пользовательских событий (например, эффект подсвечивания кнопки при наведении мыши) без необходимости написания кода.

Все эти возможности XAML реализуются с помощью соответствующих инструментов, так что детали реализации XAML остаются скрытыми.

Расширяемость

С формальной точки зрения XAML — язык скорее не программирования, а сериализации и инициализации платформы .NET. Поэтому на языке XAML можно представлять не только возможности платформы WPF, но и любые пользовательские элементы управления, новые виды анимации и т. д., а также любые графы объектов .NET. В некотором смысле XAML можно считать кодом, представленным в виде XML⁶.

Разделение обязанностей дизайнера и разработчика

Побочным результатом выразительности и полноты XAML стало реальное отделение интерфейса пользователя от бизнес-логики. Разработчики могут работать с файлами XAML, подготовленными дизайнерами, без потери точности и повреждения артефактов. В то же время разработчики получили возможность создавать интерфейсы пользователя, поведения и анимации и даже связывать базовые привязки интерфейса пользователя и данных.

Роли и рабочий процесс

Появление XAML разрушило стену, разделявшую дизайнеров и разработчиков. В результате возникли новые формы совместной работы. Послушаем мнения дизайнера и разработчика.

«Достоинство XAML в том, что дизайнеры могут работать вместе с разработчиками. Большую часть времени я работаю отдельно над собственными проектами Blend, но с разработчиками взаимодействую постоянно. Это очень похоже на игру в теннис: перекидываем проекты туда-сюда. При каждом обмене узнаешь немного больше об инструменте и общих перспективах. В результате выигрывают и проект, и конечные пользователи» – Калани Кордус (Kalani Kordus), дизайнер, Yahoo.

«XAML стирает барьеры между дизайнерами и разработчиками — нам больше не нужно работать в жестких рамках «замороженного» дизайна. Это больше похоже на «снежную кашу». После определения базового визуального языка остальная часть дизайна может оставаться подвижной до последнего момента, что не оказывает практически никакого влияния на мою работу. Нам не удалось бы добиться этого с другими технологиями, поскольку они просто не поддерживают быстрые параллельные итерации с представлением и кодом» – Ли Бреннер (Lee Brenner), разработчик, frog design.

В конечном счете, новые возможности совместной работы означают, что итерации проекта могут стать намного более гибкими. Больше нет улицы с односторонним движением, когда изменение последующей спецификации требует радикальной переработки всего приложения. Это открывает новые возможности совместной работы дизайнеров с разработчиками, что позволяет установить своего рода диалог, способствующий творческому подходу.

Чтобы освоиться в новой ситуации, рассмотрим последствия применения XAML для дизайнеров и разработчиков⁷. Затем поговорим о рабочем процессе с участием этих двух ролей.

Последствия для дизайнера

Самым большим изменением для дизайнеров будет то, что их проекты фактически станут частью решения, а сами они смогут значительно приблизиться к процессу разработки программного обеспечения. Больше не будет трансляции, сидения за плечом разработчика, объяснения концепции и контроля над реализацией этой концепции в коде. Это открывает невероятные возможности для дизайнера: его работа вливается в рабочий процесс. Как уже говорилось, при необходимости последующих изменений можно будет вовлечь дизайнера в рабочий процесс и внести изменения без ущерба для проекта.

В новой модели совместной работы прототипы дизайнера могут быть действующими и функциональными. При использовании новых инструментов, таких как Expression Blend, дизайнеру не нужен разработчик для создания макета концепции. Дизайнер может подключать все возможные виды взаимодействия, от нажатия кнопки до загрузки изображений и событий изменения размера. Это позволяет создавать относительно сложные прототипы без привлечения разработчиков, что повышает производительность.

После создания и утверждения такие прототипы, скорее всего, будут использоваться в самом конечном продукте, перестав быть побочным результатом дизайнерского процесса. Роберт Татл (Robert Tuttle) из компании frog design рассказывает: «От 50 до 100 % наших прототипов, создаваемых на начальных стадиях проекта, были промежуточными. При разработке на платформе WPF число таких прототипов сократилось до 20 %».

Следует отметить еще один важный момент. Поскольку дизайнеры тесно вовлечены в процесс разработки ПО, они должны хорошо осознавать последствия своей работы с программистской точки зрения. Рассмотрим классические принципы разработки программного обеспечения: производительность, удобство сопровождения, управление версиями, контроль качества, устойчивость и т. д. Работа дизайнеров может повлиять на любую из этих областей, поэтому им необходима подготовка для понимания последствий своего участия в процессе разработки. Используя для генерации разметки XAML программные инструменты, дизайнеры могут создать решение, требующее усовершенствований с точки зрения разработчика ПО. Понимание последствий использования таких инструментов необходимо. Конкретные рекомендации по этим вопросам приведены в третьем разделе данной статьи.

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

Последствия для разработчиков

С появлением XAML позиции разработчиков изменяются. Так как разметка XAML очень выразительна и легко генерируется программными инструментами, ориентированными на дизайнеров, большая часть работы по созданию интерфейса пользователя, которая раньше выполнялась разработчиками, может перейти в руки дизайнеров. Это может существенно разгрузить разработчиков и дать им возможность сосредоточиться на других аспектах разработки. Однако при этом разработчик может частично утратить контроль.

Другое изменение для разработчика, связанное с XAML, заключается в необходимости тщательно структурировать проекты для оптимизации рабочего процесса. Такие задачи, как создание предварительного проекта, настройка структур каталогов, ресурсов, модулей и т. д., будут играть значительно более важную роль. Большая часть преимуществ, которых можно достичь благодаря XAML, зависит от заблаговременного планирования проекта, существенная часть которого попадает в руки разработчика.

Из этого утверждения следует, что разработчики также должны понимать XAML. При проведении исследования в рамках написания данной статьи все пришли к единому мнению, что свободное владение языком XAML — необходимое условие для разработчиков, работающих с платформой WPF. Кен Азума (Ken Azuma), ведущий архитектор интерфейсов из компании 2nd Factory и автор книги о решении Expression Blend, заметил: «По мере усложнения проектов необходимо внимательнее относиться к самому XAML». Вероятнее всего, большая часть разметки будет создана дизайнером с помощью инструментов, однако разработчик должен понимать особенности того, что эти средства создают. Кроме того, на разработчика может быть возложена обязанность интеграции и структурирования различных ресурсов, созданных инструментами, что делает понимание XAML обязательным. Суть разработки на платформе WPF в том, что XAML — не просто часть реализации. Если полагаться исключительно на инструменты и не понимать того, что они создают, это может негативно отразиться на последующих результатах.

Две (или больше) хозяйки на одной кухне: роли и обязанности

Мы уже говорили, что идея нового вида совместной работы в том, чтобы теснее вовлечь дизайнера в разработку и напрямую использовать результаты его работы в приложении. Поэтому важно организовать процесс внедрения этих результатов. Невозможно рекомендовать единую модель команды для всех проектов, поскольку в каждом из них количественный состав команды, квалификация участников и знания новой технологии могут различаться. Как показал наш опыт в первых проектах, есть два типичных подхода к управлению этим процессом. В первой модели («дизайнер — интегратор — разработчик») в разработку программного обеспечения вводится новая роль интегратора. В его обязанностях — интеграция и оптимизация элементов визуального дизайна в рамках проекта. Во второй модели («дизайнер — разработчик») новая роль не вводится, однако предполагается, что при явном разграничении обязанностей и хороших коммуникациях дизайнеры и разработчики смогут работать параллельно и объединять в приложении элементы визуального дизайна и функциональность. У каждой из этих моделей свои преимущества и недостатки. Кроме того, возможны различные модификации каждой модели в зависимости от уровня квалификации команды.

Хотя различия квалификации в разных командах не позволяют рекомендовать единую модель, для всех моделей можно дать один совет: четко определить ответственных за каждую задачу или конечный результат. Рассмотрим подробнее эти модели команд и порядок распределения ответственности.

Модель «дизайнер — интегратор — разработчик»

Некоторые считают, что в процессе разработки программного обеспечения XAML требует выделения новой роли между дизайнером и разработчиком. Наиболее прагматичное название для новой роли, интегратор, было предложено компанией IdentityMine, приложившей немало усилий в этой области. Пол Александр (Paul Alexander), руководитель технической программы в IdentityMine, отметил: «Интегратор понимает потребности разработчика. При этом он помогает дизайнеру сохранить изначальную привлекательность пользовательского интерфейса приложения. Кроме того, он проверяет возможность реализации концепций в коде с точки зрения разработчика»⁸.

Идеальный интегратор — человек с дизайнерской жилкой и хорошим знанием и пониманием WPF и XAML. Интегратор становится ответственным за XAML и взаимодействие между дизайнером и разработчиком, занимаясь также файлами XAML. В обязанности интегратора входят структурирование и модуляризация XAML при необходимости. Поэтому интегратор должен быть экспертом в области XAML и при этом разбираться в таких концепциях WPF, как наследование, стили и поиск ресурсов.

Одно из преимуществ наличия интегратора заключается в некотором облегчении труда дизайнера и разработчика. При наличии интегратора группе дизайна не требуется переходить на XAML, чтобы эффективно внедрить результаты работы в проект. Дизайнеры, которые не хотят изучать новые инструменты или просто не имеют достаточно времени при сжатых сроках, смогут работать с хорошо знакомыми инструментами (например, Adobe Illustrator) и экспортировать результаты работы в формате XAML. Затем интегратор внесет необходимые изменения для интеграции в проект этого файла XAML. Аналогично, интегратор выступает в роли буфера для разработчиков, которые не хотят беспокоиться о влиянии XAML на код. В краткосрочных проектах опытный интегратор может очень быстро внедрять все визуальные элементы в проект и попутно обучать дизайнеров и разработчиков.

С другой стороны, следует отметить потенциальные недостатки роли интегратора. Прежде всего, понимание XAML необходимо всем членам команды, а не только интегратору, который становится «звеном потенциального разрыва». Кроме того, в больших проектах интегратор может застопорить процесс из-за итеративной природы дизайна — едва ли можно сразу создать объект, не «полируя» и не дорабатывая его. Передача материалов между дизайнером и интегратором может повторяться слишком часто, что приведет к излишней нагрузке. Кроме того, интегратор может неумышленно изменить исходную концепцию дизайнера при доводке XAML для интеграции в проект. Наконец, управлять несколькими интеграторами в больших проектах достаточно трудно, поскольку при пересечении сфер их деятельности увеличивается нагрузка на дизайнеров и разработчиков.

Каждый проект и каждая команда в некотором роде уникальны. Очень трудно сказать, является ли интегратор ключевым фактором успеха нового рабочего процесса с использованием XAML. Но рассказать об этой роли как о возможности для тех, кто начинает новый проект, необходимо.

Модель «дизайнер — разработчик»

В модели «дизайнер — разработчик» отсутствует новая роль, однако в ней требуется организовать процессы по внедрению графических и интерактивных элементов в проект. Применяются два основных подхода, используемых дизайнерами и разработчиками для оптимизации рабочего процесса: модель «сбора урожая» и модель совместной работы.

Модель «сбора урожая»

Первая методика предполагает, что разработчик «собирает» результаты работы дизайнера и интегрирует их. В этом сценарии дизайнеры создают объекты, которые будут использоваться непосредственно в проекте. При этом они, вероятно, не будут помещать файлы в хранилище управления исходным кодом или самостоятельно компилировать и выполнять готовое приложение. Они будут работать с небольшими изолированными проектами, а затем разработчик будет агрегировать или переносить их объекты в фактический проект. По сути, эта модель предполагает передачу результатов от дизайнеров разработчикам.

В рамках этой модели уровень участия дизайнеров зависит от их умения работать со средствами WPF. Например, дизайнер может передавать графические ресурсы, экспортированные из инструмента, либо создавать анимации, стили и шаблоны WPF, которые будут внедрены в проект разработчиком. Поэтому в рамках этого процесса дизайнер может хорошо владеть возможностями WPF, но все равно оставаться немного в стороне от проекта.

Преимущество данной модели в том, что дизайнеры непосредственно участвуют в проекте, но не обязаны понимать, как их работа отразится на общем результате. К недостаткам можно отнести то, что дизайнер отдален от проекта, поэтому при итерациях требуется процедура передачи.

Модель совместной работы

Другой вариант для дизайнера — непосредственная работа над проектом. В этом случае все изменения, сделанные дизайнером, немедленно становятся частью проекта. Фактически дизайнер занимается разработкой решения вместе с разработчиками. Он может помещать файлы XAML в хранилище управления исходным кодом, компилировать и запускать приложение. Такой оптимизированный подход обеспечивает эффективное выполнение итераций. Для многих проектов, особенно более масштабных, высший уровень совместной работы выглядит именно так. В сущности, это долгосрочная цель эволюции любой модели. По мере накопления дизайнерами опыта и уверенности в работе с платформой они все активнее участвуют в проекте в целом, что способствует оптимизации процесса.

По большому счету два эти варианта различаются границей между дизайнером и разработчиком. Однако непреложного правила по демаркации такой границы нет. На практике она все чаще оказывается размытой, поскольку в отрасли программного обеспечения появляется все больше и больше дизайнеров, способных программировать, и разработчиков, способных работать с графикой и дизайном. И все же, независимо от уровня квалификации, граница между ролями в проекте должна быть четко проведена. Необходимо понять, кто отвечает за XAML. При этом еще один важный аспект — стратегия упаковки и передачи ресурсов, рассмотренная в разделе советов и рекомендаций.

Инструменты

Код XAML можно редактировать в текстовом редакторе, однако эффективнее создавать интерфейс пользователя с помощью средств быстрой разработки приложений. Поскольку язык XAML основан на XML, существует множество инструментов, которые поддерживают редактирование или экспорт XAML. В этой статье мы не будет рассматривать все инструменты, представленные на рынке, а сосредоточимся только на самых популярных. Инструменты были разбиты на три категории: 1) инструменты, которые генерируют XAML; 2) инструменты, которые экспортируют XAML; 3) WYSIWYG-редакторы XAML.

Инструменты со встроенной поддержкой XAML

Такие инструменты включают рабочую область конструирования, генерирующую XAML. Это двусторонние средства (изменения дизайна отражаются в XAML и наоборот).

Expression Blend

Expression Blend — это интерактивный инструмент разработки приложений на основе XAML. Blend позволяет воспользоваться всеми мощными возможностями XAML: макетом, графическими элементами, элементами управления, шаблонами и стилями, анимацией, привязкой данных и основными трехмерными функциями. С Blend работают дизайнеры, дизайнеры интерактивных компонентов и разработчики. Дизайнеры создают в Blend визуальные элементы, стили, шаблоны и анимации, а также выполняют другие задачи, связанные с оформлением внешнего вида приложения. Разработчики также много работают с Blend над интерфейсом пользователя, однако они, скорее, сочетают эту работу с отладкой и редактированием кода в Visual Studio.

Visual Studio 2008

Visual Studio 2008 содержит визуальный редактор для создания приложений WPF⁹, включающий отличный текстовый редактор XAML с технологией IntelliSense, мощные функции создания макета и навигации по документам, а также модель размещения и расширения для элементов управления сторонних разработчиков. Однако в этом решении нет визуального редактора стилей, шаблонов и анимации. В Blend и Visual Studio используется одна система проектов. Оба продукта выполняют сериализацию XAML. Поэтому возможен бесперебойный обмен данными между двумя этими инструментами.

Инструменты, поддерживающие экспорт в формате XAML

Такие инструменты и подключаемые модули могут экспортировать XAML, но не обладают встроенной поддержкой работы с ним. Они не могут работать непосредственно с разметкой XAML или импортировать XAML, поэтому реализуется односторонняя передача данных из такого инструмента в проект¹⁰.

Microsoft Expression Design

Expression Design — это векторное средство для создания элементов графического дизайна. Приложение Design может выполнять экспорт XAML и растровых изображений. В Expression Design дизайнер не ограничен созданием графических элементов, которые могут быть представлены в XAML. Он может создавать визуальные элементы и преобразовывать элементы, не поддерживаемые в XAML, в растровый формат. Однако есть несколько элементов, которые нельзя экспортировать в формате XAML и преобразовать в растровый формат. К ним относятся режимы смешения и текст на контуре.

Adobe Illustrator

Векторный графический редактор Illustrator очень популярен. Многие дизайнеры хорошо знакомы с этим инструментом. Они привыкли создавать интерфейс пользователя в Illustrator, а затем экспортировать его в формате XAML. Существует два способа создания кода XAML с помощью Illustrator:

1. Использовать подключаемый модуль для экспорта XAML из Illustrator¹¹.
2. Использовать Expression Design для импорта AI-файлов, которые затем можно экспортировать в формате XAML.

Некоторые визуальные элементы, созданные в Adobe Illustrator, невозможно преобразовать в формат XAML. В частности, в Adobe Illustrator не следует использовать эффекты и фильтры.

Трехмерные инструменты, поддерживающие экспорт в формате XAML

В платформе WPF предусмотрена поддержка трехмерной графики, а в Expression Blend поддерживаются базовые операции с трехмерными сценами, однако инструменты корпорации Microsoft в настоящее время не поддерживают создание трехмерных моделей. Тем не менее, предлагается несколько конвертеров для преобразования трехмерных ресурсов в формат XAML. Их описание можно найти на следующей странице: https://blogs.msdn.com/mswanson/articles/WPFToolsAndControls.aspx. Кроме того, Expression Blend может непосредственно импортировать файлы OBJ.

Эти трехмерные конвертеры, так же как Expression Design и Adobe Illustrator, являются односторонними инструментами и тоже могут приводить к потере точности при преобразовании в формат XAML.

WYSIWYG-редакторы XAML

WYSIWYG-редакторы XAML играют ключевую роль в разработке приложений WPF. Самые популярные из них — XAMLPad, XAMLCrunch и Kaxaml¹². В этих небольших бесплатных служебных приложениях в том или ином виде реализуется разделенное представление: на одной половине экрана можно вводить код XAML, а на другой видеть визуальное представление XAML. В Visual Studio 2008 и Blend 2 будет внедрено такое разделенное представление, что, по-видимому, сократит число пользователей упрощенных редакторов. Однако иногда может оказаться полезным использовать именно их.

Сводная таблица

В таблице ниже представлено сравнение функций различных инструментов, за исключением WYSIWYG-редакторов.

	Expression Design	Expression Blend	Visual Studio 2008	Adobe Illustrator
Макет	Статический, абсолютное позиционирование	Динамический	Динамический	Статический, абсолютное позиционирование
Стили	Нет	Визуальный редактор	Нет	Нет
Шаблоны	Нет	Визуальный редактор	Нет	Нет
Ресурсы	Возможность экспорта	Визуальный редактор	Нет	Нет
Поддержка кода	Нет	Простой редактор	Расширенная, IntelliSense	Нет
Двусторонняя передача XAML	Односторонняя	Да	Да	Односторонняя
Экспорт XAML	Ограниченные возможности для исключения потерь	Да	Да	С потерями. У инструмента больше возможностей, чем у WPF
Анимация	Нет	Визуальный редактор	Только редактор XAML	Нет

Рекомендации для дизайнеров

Дизайнерам очень легко приступить к работе с WPF: инструменты похожи на используемые ими, можно легко перетаскивать визуальные элементы и создавать впечатляющий интерфейс пользователя. Однако при этом конечное приложение может работать не оптимально или быть неоптимизированным с точки зрения сопровождения. Следующие рекомендации возникли в результате анализа реальных проектов.

Экономичный дизайн

Дизайнеры печатных материалов при создании работ стремятся сократить стоимость печати с помощью снижения цветности, выбора шрифтов, размера и детализации изображений. Дизайнеры приложений также должны учитывать необходимость снижения стоимости при разработке приложений WPF. Понимание «стоимости» всех визуальных элементов дизайна очень важно для создания «ответственных» приложений, которые потребляют не слишком много ресурсов (памяти и процессора). Стоимость визуализации должна поддерживать баланс между потребностями целевой аудитории и возможностями оборудования, на котором будет выполняться приложение. Ниже приведено несколько примеров областей, где бюджетирование может оказаться полезным.

• Во время выполнения рисунки XAML создают набор объектов, представляющих примитивы векторной графики. Некоторые преимущества этой модели заключаются в том, что векторные рисунки можно масштабировать в соответствии с разрешением дисплея, а графические примитивы можно загружать для обработки в графический процессор (также называемый видеокартой). Недостаток связан с тем, что излишняя детализация графики во время выполнения может приводить к созданию большого количества объектов и ресурсов. Потребление ресурсов (памяти, процессора) может вырасти по сравнению с растровыми изображениями. Для подробной графики с множеством объектов, которыми не требуется управлять программным способом, целесообразнее создать растровое изображение или особое векторное изображение типа DrawingImage¹³, поддерживаемое в WPF. С растровыми изображениями теряются векторные возможности масштабирования для различных разрешений, однако эту проблему можно обойти, создав несколько изображений для разных разрешений. Объекты DrawingImage являются векторными и масштабируются для любого разрешения.
• Одна из самых замечательных особенностей WPF — возможность использования в приложениях настоящего трехмерного графического движка. Однако из-за оптимизированной архитектуры режима отображения получение ресурсов из других трехмерных программ в WPF может приводить к некоторым проблемам. Во-первых, трехмерный движок WPF 3-D потребляет больше ресурсов по сравнению с такими, как, например, DirectX и OpenGL. Поэтому следует ограничивать трехмерную графику и свести к минимуму число вершин и источников света, особенно точечных. Тем не менее, насчитывается множество впечатляющих примеров успешной реализации трехмерной графики в проектах WPF. При условии тестирования на целевом оборудовании и экономного подхода к дизайну трехмерность может придать приложению эффектное визуальное оформление¹⁴.
• Объекты BitmapEffects в WPF потребляют очень много ресурсов. Дизайнеры используют эти объекты из-за визуальных эффектов. Однако их следует использовать с осторожностью, поскольку обработка всего задействованного содержимого выполняется без аппаратного ускорения. Есть приемы, позволяющие добиться аналогичных эффектов без потери производительности. Если эффект статический (например, тень от элемента с постоянным размером), можно имитировать его с помощью приемов рисования. Если эффект динамический, с помощью разработчика можно кэшировать изображение после применения эффекта с помощью интерфейсов API для работы с растровыми изображениями, например RenderTargetBitmap.

Выше описаны три известные области, которые могут негативно отразиться на успешности приложения, но это не исчерпывающий список. Основной вывод в том, что дизайнер должен знать о влиянии дизайна на производительность приложения. Исключить проблемы производительности на ранних этапах значительно проще, чем устранять их после.

Повторное использование

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

• Повторное использование элемента увеличивает производительность, а не создает несколько элементов одного типа. Например, повторное использование кисти для рисования нескольких элементов может существенно повысить производительность приложения. Повторное использование элементов также позволяет повысить производительность работы с Blend и конструктором Visual Studio 2008, поскольку на этапе разработки требуется загружать меньше элементов.
• Повторное использование сокращает объем кода XAML, а значит, упрощает сопровождение. Например, при повторном использовании кистей, стилей и шаблонов создается единое место для внесения изменений, влияющих на внешний вид приложения.

Ресурсы обеспечивают наилучший способ повторного использования. В XAML поддерживаются словари ресурсов, которые выступают как контейнеры свойств для любых ресурсов, которые нужно совместно использовать в разных элементах. В решениях Expression Blend и Visual Studio предусмотрена встроенная поддержка словарей ресурсов и множество возможностей для упаковки элементов в виде ресурсов. Кроме того, Expression Design позволяет экспортировать элементы в виде ресурсов с помощью выбора варианта формата документа в функции экспорта¹⁵.

Однонаправленные инструменты

При использовании однонаправленных инструментов и средств экспорта, таких как Expression Design или Adobe Illustrator, необходимо проявлять внимательность при последующих итерациях, чтобы реализовать преимущества совместной работы. Не рекомендуется вносить изменения непосредственно в объекты XAML после их экспорта. Сохранение XAML в неизменном виде позволит экспортировать эти объекты XAML и интегрировать их в проект с минимальными усилиями.

Рассмотрим следующий сценарий. Дизайнер создает кнопку с помощью инструмента и экспортирует ее в формате XAML. Затем разработчик изменяет экспортированный файл XAML, например, меняет имя элемента. Допустим, что затем принимается решение изменить цвет кнопки. Если дизайнер изменит цвет в однонаправленном инструменте, в экспортированном файле XAML не будет учитываться изменение имени, сделанное разработчиком. Кнопка не будет работать в проекте. Потребуется доработка кода XAML разработчиком. В результате итерация не будет оптимальной.

Во избежание такой проблемы необходимо с особой тщательностью интегрировать файлы XAML, экспортированные из дизайнерских инструментов. Существует несколько приемов, позволяющих минимизировать опасность повреждения XAML при повторном экспорте:

• Используйте функцию блокировки в Blend. Блокировка родительского узла XAML в приложении Expression Blend уменьшает вероятность непредумышленного изменения элементов.
• Добавляйте подробные комментарии непосредственно в код XAML. Эти комментарии должны четко выделять место, в которое помещен импортированный код XAML.
• Добавляйте экспортированный файл XAML в проект в виде словаря ресурсов. Если установлен четкий порядок, в рамках которого все словари ресурсов создаются в результате экспорта элементов из дизайнерских инструментов, разработчики не смогут изменить ресурсы, а значит, и повредить что-либо.

Группировка объектов

Многие из создаваемых дизайнерами элементов можно сгруппировать в виде логической сущности, или объекта. Если такая группировка происходит в самом начале проекта, она ускорит интеграцию в процессе разработки. Рассмотрим шаблон эллиптической кнопки, созданный с помощью Expression Design (см. рисунок ниже). Он состоит из двух эллипсов и некоторого содержимого внутри. Если его экспортировать в виде объекта с надлежащей группировкой, вся кнопка становится объектом, допускающим повторное использование. Однако если объект не сгруппирован, будут экспортированы три разных элемента. Очевидно, что сгруппированную версию проще переносить как единый объект.

В приложениях Expression Design и Expression Blend предусмотрена возможность создавать группы элементов, которые можно повторно использовать в виде объектов.

Понимание платформы

Дизайнеры, которые хотят активнее участвовать в процессе, должны лучше знать, как работает платформа WPF.

Логические единицы измерения, не зависящие от разрешения

Платформа WPF не зависит от разрешения. Для задания размера элементов в ней используются логические единицы измерения. Логическая единица в WPF равна 1/96 дюйма. Ширина некоторого прямоугольника будет всегда равна точно 3 дюймам независимо от разрешения системы, будь оно равно 96 точек на дюйм, 144 точки на дюйм или др. При работе в Blend или Visual Studio 2008 преобразования между логическими и физическими единицами измерения незаметны, поскольку у всех элементов один масштаб. Однако при импорте содержимого (например, растровых изображений) будет выполняться некоторое масштабирование, чтобы обеспечить независимость от разрешения в WPF. Ниже перечислены типы взаимодействий.

Например, если импортировать в приложениях Expression Blend и Expression Design растровое изображение, созданное с разрешением 72 пикселя на дюйм и имеющее ширину 216 пикселей, приложение Blend увеличит масштаб изображения на 4/3 (или 96/72). Это объясняется следующим. Ширина изображения была 3 дюйма (216/72), поэтому приложение Blend изменяет его масштаб так, чтобы размер изображения в WPF по-прежнему был равен 3 дюймам. Если изображение было создано при разрешении 144 пикселя на дюйм, приложение Blend уменьшит его масштаб на 2/3 (96/144).

Аналогичное масштабирование происходит и в приложении Expression Design при открытии файла Adobe Illustrator, в котором в качестве единицы измерения используются пиксели. Если файл Illustrator определен в точках, он не масштабируется (поскольку точки не зависят от разрешения).

Динамический макет и модель содержимого

В приложении WPF возможны три основных варианта макета:

1. Статический макет, в котором для всех элементов задано абсолютное положение и их размер не изменяется.
2. Динамический макет, в котором размер всех элементов интерфейса пользователя может меняться, чтобы использовать свободное место.
3. Комбинация этих двух макетов.

Большинство односторонних инструментов, поддерживающих экспорт в формате XAML, работают с абсолютными координатами (статический макет). Для работы с динамическими макетами требуется инструмент со встроенной поддержкой XAML, такой как Blend или Visual Studio 2008.

При работе с макетом пригодится знание модели содержимого в WPF. У некоторых элементов управления WPF может быть один (и только один) дочерний элемент, у других — несколько. Для некоторых элементов, способных иметь несколько дочерних, допускается перекрытие этих элементов, для других — нет. Эти требования могут показаться громоздкими, но для дизайнеров их можно обобщить в следующих правилах.

• В стандартной конфигурации применяются два элемента управления, дочерние элементы которых могут перекрываться (что позволяет создавать эффекты наложения): Canvas и Grid.
• В элементе Canvas для размещения дочерних элементов используются абсолютные координаты. Дочерние элементы могут налагаться друг на друга. Дочерний элемент с наибольшим значением свойства ZIndex будет на переднем плане. Если значение двух дочерних элементов одинаковое (ZIndex), на переднем плане будет находиться элемент, который рисуется последним.
• В элементе Grid можно использовать абсолютные координаты, если задать поля, или относительные, если задать выравнивание, растягивание и поля.
• Любые другие элементы, способные иметь в содержимом один дочерний элемент, могут содержать элемент Grid, элемент Canvas или любой другой элемент, что обеспечивает гибкие возможности создания наложений.

Один из способов реализовать некоторые возможности динамического макета в макете, созданном в абсолютных координатах, — масштабирование интерфейса пользователя. Это можно сделать двумя способами: 1) с помощью элемента управления WPF Viewbox и 2) путем применения к элементу интерфейса масштабирования, которое затрагивает все его содержимое (или дочерние элементы).

Шаблоны и стили

WPF позволяет отделить бизнес-логику (поведение) от внешнего вида элемента управления с помощью шаблона, определяющего визуальный состав элемента.

Например, для кнопки стандартный шаблон элемента управления — ContentPresenter в элементе ButtonChrome.

<ControlTemplate TargetType="{x:TypeButton}"> <Microsoft_Windows_Themes:ButtonChrome ...> <ContentPresenter ... /> </Microsoft_Windows_Themes:ButtonChrome> </ControlTemplate>

Кнопка, построенная на основе стандартной темы Windows.

Если нужна эллиптическая кнопка, можно заменить ButtonChrome на Grid и эллипс в качестве фона.

<ControlTemplate TargetType="{x:TypeButton}"> <Grid ... > <Ellipse .../> <ContentPresenter ../> </Grid> </ControlTemplate>

Пользовательская кнопка.

Шаблоны элементов управления позволяют дизайнеру создать кнопку практически любого вида путем замены внутренних визуальных элементов кнопки. Следует заметить, что замена шаблона не изменяет поведения. Кнопка будет так же реагировать на щелчки и наведение указателя мыши. Для этого не потребуется никакой дополнительной работы.

После определения основы (визуальных элементов) элемента управления в шаблоне можно воспользоваться поддержкой стилей в WPF для настройки внешнего вида элемента. С помощью стилей можно создать повторно используемую группу параметров (или атрибутов) и связать ее с элементом интерфейса пользователя для настройки его внешнего вида.

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

Существует множество других особенностей совместного использования шаблонов и стилей, не рассмотренных в данной статье, но требующих внимания дизайнеров и разработчиков. Шаблоны и стили — основные средства разделения интерфейса пользователя и кода, которые помогают реализовать новую модель совместной работы. Благодаря шаблонам элементов управления, шаблонам данных, стилям и словарям ресурсов разработчики могут сосредоточиться на логике (поведении), а дизайнеры — на визуальном оформлении (интерфейс пользователя).

Анимации WPF

В платформе WPF используется хронологическая, а не покадровая анимация. Это делает конечный продукт более последовательным. Если в хронологической анимации секунда — это четко определенная единица времени, то в покадровой анимации 30 кадров могут отображаться за полторы секунды или за одну в зависимости от быстродействия системы. К недостаткам относится чуть большая сложность создания и визуализации анимации, а также состояний до и после отображения анимации. С помощью приложения Blend можно создавать анимацию и просматривать ее, однако для относительной анимации визуализировать начальную и конечную точки трудно. Для решения этой проблемы можно задать начальную точку анимации (0:0:0) и просмотреть ее, а после завершения разработки — удалить эту начальную точку, чтобы сделать анимацию относительной.

Рекомендации для разработчиков

Новый процесс взаимодействия разработчиков и дизайнеров основан на расширении совместной работы этих ролей. Если разработчики оптимизируют код и процесс, дизайнеры столкнутся с меньшим количеством проблем при работе с инструментами.

Использование приложения Blend

Ключевой фактор оптимизации для дизайнера — приложение Blend. Его использование и возможность открывать проекты в Blend позволяют дизайнерам тесно участвовать в процессе разработки. Если проекты нельзя открывать в приложении Blend, дизайнеры фактически исключаются из процесса, поскольку они больше не могут просматривать проекты на этапе дизайна. Чтобы посмотреть изменения, необходимо перекомпилировать проект и снова запустить приложение. Робби Ингебретсен (Robby Ingebretsen) из компании IdentityMine говорит: «Если проект невозможно посмотреть в Blend, работа над ним выполняется в цикле „небольшое изменение, компиляция, запуск“, а не путем последовательных небольших изменений».

В связи с этим, если у разработчика есть выбор: создавать что-либо на XAML или в коде, обычно рекомендуется использовать XAML при условии, что создаваемый элемент (например, анимация) потребует доработки или доделки дизайнером в Blend. Работа с XAML создает дополнительные сложности для разработчика, но в конечном итоге это окупается за счет повышения производительности и творческого подхода. Если некоторый элемент можно открыть в дизайнерском инструменте, с ним может поработать еще один человек. А если он изолирован в коде, у дизайнера нет к нему прямого доступа.

Хороший пример того, насколько полезна возможность открывать проекты в приложении Blend, дала сама команда разработчиков Blend. Самуэль Ван (Samuel Wan), руководитель программы Expression Blend, заметил: «Сам Blend и обложку для Design мы создавали с помощью Blend. Возможность немедленно получать визуальную обратную связь в инструменте просто бесценна. В случае с Design нам удалось переработать внешний вид созданного восемь лет назад продукта в считаные месяцы».

Понимание особенностей Blend

У приложения Blend есть несколько особенностей, которые должен понимать разработчик. При разработке сцены в Blend в память загружаются все элементы, на которые есть ссылки в такой сцене (элементы управления, векторы, растровые изображения, видео и т. д.), и выполняется их код инициализации. Это означает, что если код инициализации выдает ошибку, то это приведет к ошибке в инструменте и невозможности загрузки такого элемента управления. В худшем случае на поверхность разработки не будет загружена вся сцена. Вот типичный пример. Разработчик создает пользовательский элемент управления для отображения какой-либо информации, например сведений о пациенте. В коде инициализации элемента управления разработчик выполняет анализ контекста данных, чтобы определить имя и фамилию пациента. Если элемент управления загружается в рабочую область конструирования Blend без контекста данных, происходит ошибка в коде анализа и приложение Blend не загружает этот пользовательский элемент управления.

Чтобы избежать таких проблем, в инструментах WPF в пространстве имен Microsoft.Windows.Design предусмотрены интерфейсы API этапа разработки для проверки выполнения в конструкторе. С помощью этих интерфейсов можно проверить среду разработки и выполнить другой код, чтобы предотвратить ошибки в элементе управления.

Предварительная подготовка данных

В силу различности всех приложений данная рекомендация имеет относительный характер. Однако многие приложения отображают или получают информацию, хранящуюся в виде данных. В XAML предусмотрены отличные возможности для работы с данными, такие как привязки данных, шаблоны данных и т. д. Единственная проблема в том, что данные должны быть уже определены, когда дизайнер приступает к работе со своими инструментами. Это позволит инструментам автоматически генерировать код на основании схемы данных.

Например, приложение Blend поддерживает создание шаблонов данных с помощью простой операции перетаскивания схемы данных (объект CLR или схема XML). Если данные и схема будут подготовлены до того, как дизайнер приступит к разработке макета интерфейса пользователя, это сэкономит время и дизайнера, и разработчика. Таким образом, дизайнер будет не только создавать макет интерфейса пользователя, но и привязывать интерфейс к схеме бизнес-объекта, освобождая разработчика от этого занятия в будущем. Использование схемы с самого начала также освобождает дизайнера от последующей модификации дизайна в случае изменения модели данных.

Использование единой системы именования, структурирования и документирования файлов XAML

Еще один ключевой фактор управления файлами XAML связан с выбором соглашения об именовании элементов. Проекты становятся все сложнее, поэтому единое соглашение об именовании поможет находить элементы и понимать их назначение. Перемещаться по большим необработанным файлам XAML может быть трудно. Разработчик будет вынужден связывать события на основании имен, созданных дизайнером. Использование соглашений об именовании уменьшает остроту этой проблемы. Эта область хорошо знакома разработчикам, но может быть неизвестна некоторым дизайнерам. Дизайнеры, работающие с XAML, должны соблюдать соглашения об именовании для удобства поддержки на последующих этапах. Они также должны понимать, что нельзя изменять имя элемента, поскольку в коде могут быть ссылки на элемент по такому имени.

Замечание об именах. При присвоении имени объекта (x:Name ="" или Name="") компилятор XAML создает переменную, являющуюся членом класса в коде программной части. В большинстве сценариев это очень полезно для разработчика и, как правило, не требует много ресурсов во время выполнения (несколько байтов памяти и пара инструкций кода инициализации). Просто следует учитывать еще одну ссылку на объект. При загрузке или выгрузке именованных объектов во время выполнения потребуется присвоить такой созданной переменной значение null, чтобы сборщик мусора очистил память для нее, когда класс все еще находится в памяти.

Размер файла XAML может быть очень большим, что затруднит его читаемость и сопровождение. Это может стать особенно проблематичным, если требуется вручную изменить код XAML. В приложении Blend предусмотрена полезная функция View XAML («Перейти к XAML»), которая позволяет перейти к нужному месту в коде XAML из представления в визуальном дереве.

Эта функция облегчает, но не решает полностью проблему разрастания файлов XAML. Иногда бывает трудно найти шаблоны или ресурсы в файле XAML. Решением, особенно для больших проектов, может стать разбиение файлов XAML на модули. Важный момент для модуляризации файлов XAML — понимание назначения различных частей файлов XAML. Пол Стоувел (Paul Stovell)¹⁶ разбивает файлы XAML на две категории: функциональные файлы XAML и файлы ресурсов XAML. Функциональные файлы XAML включают элементы верхнего уровня, такие как Window, Page или UserControl. Файлы ресурсов XAML разделяются на две подкатегории: файлы универсальных ресурсов XAML, которые содержат ресурсы, используемые в масштабах всего приложения (например, ресурсы Brush и Style), и файлы специальных ресурсов XAML, которые содержат ресурсы для конкретных экземпляров элементов Window, Control или Page (например, трехмерная геометрия). Стоувел приводит пример приложения с предлагаемой структурой каталогов, с которым стоит ознакомиться.

Выбор кода программной части

Платформа WPF позволяет вводить в файл XAML встроенный код, однако делать это не рекомендуется и, более того, стоит избегать любой ценой. Размещение кода в файле XAML нарушает принцип разделения кода и XAML, что делает сопровождение приложения нелегкой задачей. Другой, более тонкий, вопрос связан с тем, инициализировать ли обработчики событий в файлах XAML или в коде. Если инициализация всех обработчиков событий происходит в коде, проект становится понятнее, а обработчики событий не разбросаны по файлу XAML. Однако если все обработчики событий находятся в коде, то дизайнер взаимодействий не может эффективно работать в приложении Blend с проектом и различными возможными состояниями приложения. Если разрешить использовать обработчики событий в XAML, проект будет более доступным в приложении Blend, однако при сопровождении приложения возникнут проблемы из-за того, что обработчики событий определены в различных местах.

Архитектура платформы

Эта статья разрослась бы до размера монографии, если бы мы подробно остановились на шаблонах, стилях, словарях ресурсов, командах, привязках данных, свойствах зависимости и триггерах. Все эти элементы представлены в платформе WPF и поддерживаются в XAML, то есть дизайнеры могут с ними легко работать и получать доступ к ним с помощью приложения Blend. Есть хорошее эмпирическое наблюдение: если вы программируете логику интерфейса пользователя, то, вероятно, не используете в полной мере привязки данных, триггеры и шаблоны. Как уже говорилось ранее, XAML — это невероятно выразительный, полный и расширяемый язык создания интерфейсов пользователя. Он дает дизайнеру возможность создавать интерфейс пользователя и реализовать взаимодействие приложения, оставляя разработчику такие задачи, как создание бизнес-логики и пользовательских элементов управления, разработка компонентов и предоставление моделей данных.

Использование инструмента SNOOP для доработки XAML во время выполнения

Одна из проблем, связанных с использованием инструментов для создания интерфейсов пользователя, состоит в том, что не все состояния приложения можно представить на этапе дизайна. Немало состояний, в которых приложение может находиться только во время выполнения. Возможности дизайнера или разработчика по работе с такой частью приложения ограниченны. К счастью, замечательное средство SNOOP¹⁷ позволяет изменять значения свойств интерфейса во время выполнения.

Дизайнер из группы Expression Арон Ясински (Aaron Jasinski), работавший над созданием интерфейса пользователя и стилей для приложений Expression Blend и Expression Design, отметил, что во многих случаях этот инструмент оказывал неоценимую помощь при доработке интерфейса. Дизайнер может посмотреть, как будет выглядеть приложение, и изменить свойства. Затем он решает, внедрить ли изменения в код. Приложение SNOOP не обладает всеми возможностями полного дизайнерского инструмента, но чрезвычайно полезно для модификации интерфейса при выполнении.

Благодарности

Эта статья не появилась бы без помощи многих людей. Выражаем благодарность Тиму Эйдлину (Tim Aidlin) за подготовку графики, многочисленным рецензентам, предоставившим бесценные отзывы, и компаниям, первым начавшим работу с платформой, чей опыт помог нам в написании статьи.

Сноски

1. Общие сведения о платформе WPF см. в статье https://msdn2.microsoft.com/ru-ru/library/aa970268.aspx.
2. См. документ компании Burton Group «XAML: успехи декларативного программирования в .NET 3.0» (http://www.burtongroup.com/Research/PublicDocument.aspx?cid=885) (EN) и документ компании Forrester «Почему платформа Windows Presentation Foundation будет доминировать при разработке для толстых клиентов» (http://www.forrester.com/Research/Document/Excerpt/0,7211,38241,00.html) (EN).
3. Список примеров внедрения WPF и решений Expression см. на сайтах https://www.microsoft.com/casestudies и http://www.windowsclient.net.
4. Дополнительные сведения об Expression Studio см. на сайте https://www.microsoft.com/expression.
5. Список синтаксисов разметки интерфейса пользователя см. в статье http://en.wikipedia.org/wiki/User_interface_markup_language.
6. Для сценариев, в которых сериализации и инициализации объектов может быть недостаточно, в XAML поддерживаются «расширения разметки», позволяющие создавать поведения, связанные с сериализуемыми объектам. Таким образом, в WPF реализуются расширенные привязки данных и поиск ресурсов.
7. Отметим, что дизайнерам и разработчикам придется предварительно изучить инструменты и платформу. Без этого невозможно добиться повышения эффективности рабочего процесса.
8. Этот дизайнер носит псевдоним Cider. Есть версия этого инструмента для Visual Studio 2005, однако она не поддерживается и доступна только в виде CTP-версии.
9. Различные конвертеры (HTML, Flash и др.) не рассматриваются.
10. В настоящее время предлагаются два подключаемых модуля для Illustrator, которые можно найти по следующей ссылке: https://blogs.msdn.com/mswanson/articles/WPFToolsAndControls.aspx.
11. XAMLPad входит в состав Windows SDK. XAMLCrunch можно загрузить по следующей ссылке: https://windowsclient.net/downloads/folders/controlgallery/entry2314.aspx. KaXAML можно найти по следующей ссылке: http://www.kaxaml.com/.
12. См. документ https://msdn2.microsoft.com/en-us/library/system.windows.media.drawingimage.aspx.
13. Некоторые полезные советы по использованию трехмерных элементов в WPF см. в документе https://blogs.msdn.com/wpfsdk/archive/2007/01/15/maximizing-wpf-3d-performance-on-tier-2-hardware.aspx.
14. Когда необходимо выбрать, экспортировать ли XAML непосредственно из Adobe Illustrator или импортировать файлы в Expression Design, а затем экспортировать XAML, один из аргументов в пользу Expression Design — встроенная поддержка экспорта словарей ресурсов.

<<< Предыдущая

Следующая >>>