Приложения хвар
WPF также позволяет строить приложения, которые могут размещаться внутри веб-браузера. Такая разновидность приложений WPF называется браузерными приложениями XAML, или ХВАР. Согласно этой модели, конечный пользователь переходит по заданному URL-адресу, указывающему на приложение ХВАР (которое представляет собой коллекцию объектов Page), затем прозрачно загружает и устанавливает его на локальной машине. В отличие от традиционной установки исполняемого приложения с помощью ClickOnce, программа ХВАР располагается непосредственно в браузере и принимает встроенную систему навигации браузера.
Преимущество технологии ХВАР состоит в том, она позволяет создавать сложные пользовательские интерфейсы, которые являются более выразительными, чем типичная веб-страница, построенная с помощью HTML и JavaScript. Объект Page в WPF может использовать те же службы, что и настольное приложение WPF, включая анимации, двух и трехмерную графику, темы и т.п. По сути, веб-браузер в данном случае — просто контейнер объектов Page, а не средство отображения веб-страниц ASP.NET.
Однако, учитывая, что объекты Page развертываются на удаленном веб-сервере, приложения ХВАР можно легко сопровождать в разных версиях и обновлять без необходимости поставки исполняемых сборок на пользовательские настольные машины. Подобно традиционному веб-приложению, объекты Page можно легко обновлять на веб-сервере, и пользователь всегда будет получать самую актуальную версию, обращаясь по заданному URL-адресу.
Возможным недостатком этой разновидности программ WPF является то, что ХВАР могут работать только внутри веб-браузеров Microsoft Explorer или Firefox. При развертывании такого приложения в корпоративной сети компании совместимость браузеров не должна быть проблемой, так как системные администраторы могут просто диктовать выбор браузера, обязательного для установки на пользовательских машинах. Однако, открывая доступ к ХВАР-приложению внешнему миру, невозможно гарантировать, что каждый пользователь будет работать с браузером Internet Explorer или Firefox, а потому некоторые из них просто не смогут его просмотреть.
Другая проблема состоит в том, что машина, которая выполняет ХВАР-приложение, должна иметь локальную установку платформы .NET, поскольку объекты Page пользуются теми же сборками .NET, что и традиционные приложения. Учитывая это, ХВАР-приложения ограничены только средами Windows и не могут просматриваться на системах, работающих под управлением Mac OS или Linux.
Независимость от разрешения
Традиционные Windows-приложения связаны определенными предположениями относительно разрешения экрана. Обычно разработчики рассчитывают на стандартное разрешение монитора (вроде 1024x768 пикселей) и проектируют свои окна с учетом этого, стараясь обеспечить разумное поведение при изменении размеров в большую и меньшую сторону.
Проблема в том, что пользовательский интерфейс в традиционных Windows-приложениях не является масштабируемым. В результате, если вы используете монитор с высоким разрешением, который располагает пиксели более плотно, окно приложения становится меньше и читать текст в нем труднее. Эта проблема особенно актуальна для новых мониторов, которые имеют высокую плотность пикселей и соответственно работают с более высоким разрешением.
Например, легче встретить мониторы (особенно на портативных компьютерах), которые имеют плотность пикселей в 120 dpi или 144 dpi (точек на дюйм), чем более традиционные 96 dpi. При их встроенном разрешении эти мониторы располагают пиксели более плотно, создавая напрягающие глаз мелкие элементы управления и текст. В идеале приложения должны использовать более высокую плотность пикселей, чтобы отобразить больше деталей. Например, монитор с высоким разрешением может отображать одинакового размера значки панели инструментов, но использовать дополнительные пиксели для отображения мелкой графики. Подобным образом можно сохранить некоторую базовую компоновку, но обеспечить более высокую четкость деталей.
По разным причинам такое решение было невозможно в прошлом. Хотя можно изменять размер графического содержимого, нарисованного в GDI/GDI+, компонент User32 (который генерирует визуальное представление распространенных элементов управления) не поддерживает реального масштабирования.
WPF не страдает от этой проблемы, потому что самостоятельно визуализирует все элементы пользовательского интерфейса — от простых фигур до таких распространенных элементов управления, как кнопки. В результате если вы создаете кнопку шириной в 1 дюйм на обычном мониторе, она останется шириной в 1 дюйм и на мониторе с высоким разрешением. WPF просто визуализирует ее более детализировано, с большим количеством пикселей.
Так выглядит картина в целом, но нужно уточнить еще несколько деталей. Самое важное, что следует осознать — WPF базирует свое масштабирование на системной установке DPI, а не на DPI физического дисплейного устройства. Это совершенно логично — в конце концов, если вы отображаете приложение на 100-дюймовом проекторе, то, скорее всего, отойдете подальше на несколько шагов и будете ожидать увидеть огромную версию окон. Конечно, не желательно, чтобы WPF масштабировал приложение, уменьшая его до "нормального" размера. Аналогично, если вы используете портативный компьютер с дисплеем высокого разрешения, то хотите увидеть несколько уменьшенные окна; это цена, которую приходится платить за то, чтобы уместить всю информацию на маленьком экране. Более того, у разных пользователей разные предпочтения на этот счет. Некоторым нужны расширенные подробности, в то время как другие хотят увидеть больше содержимого.
Так каким же образом WPF определяет, насколько большим должно быть окно приложения? Краткий ответ состоит в том, что при вычислении размеров WPF использует системную установку DPI. Но чтобы понять, как это в действительности работает, необходимо более детально ознакомиться с системой измерений WPF.