Май 2015 г.

Том 30, выпуск 5

Windows 10 - Введение в создание приложений для устройств под управлением Windows 10

Jerry Nixon | Май 2015

Продукты и технологии:

Windows, Windows Phone, Xbox, XAML

В статье рассматриваются:

• дорога к единой операционной системе Windows;
• что должно выполняться на каждом устройстве;
• как адаптировать ваш интерфейс к экранам разных размеров;
• как адаптировать ваш код к разным устройствам;
• что нужно для успеха любого Windows-приложения.

Исходный код можно скачать по ссылке

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

На уровне ОС это означает наличие единой, удобной в сопровождении и гибкой кодовой базы. Разработчикам предоставляется унифицированная, надежная поверхность API на каждом устройстве с Windows — от IoT-устройств (Internet of Things), таких как Raspberry Pi, до смартфонов, Xbox, планшетов, Surface Hub, лэптопов, ПК и других (например, Microsoft HoloLens). Как показано на рис. 1, это реализация обещанной в Windows 10 концепции «написано один раз — работает везде» на платформе универсальных приложений (universal application platform, UAP).

Рис. 1. UAP поддерживает приложения на всех семействах устройств с Windows

Экскурсия по Windows 10

К слиянию разных версий Windows стало долгожданным событием. В 2011 году у Microsoft было три платформы с тремя ОС. Версия для ПК и серверная ОС была основана на кодовой базе Windows NT, версия для смартфонов — Windows Phone, наследница Windows CE с поверхностными сходствами с Windows NT, но другой кодовой базой. ОС для Xbox 360 была Windows NT, но являлась ее ответвлением десятилетней давности, настолько отличающимся от текущей Windows NT, что ее тоже можно было считать другой кодовой базой.

Windows 10 стала компактной, где одна базовая ОС выполняется на каждом семействе устройств.

В то время Microsoft работала над созданием Internet Explorer, общего для каждой платформы. Тогда не было ни Windows Core, ни платформы Windows, ни UAP. Реализация Internet Explorer в перечисленных выше трех операционных системах была успешной, но потребовала значительных инженерных усилий.

С появлением Windows Phone 8 ядро Windows NT заменило Windows CE на смартфонах. Это был еще один важный шаг на пути к единой кодовой базе. Windows, Windows Phone и Xbox 360 — все они использовали одно и то же ядро, хотя у каждой из этих ОС по-прежнему были уникальные кодовые базы. В 2013 году был выпущен Xbox One, а вместе с ним и базовая часть ОС, общая с Windows 8. Microsoft была уже настолько близка к единой кодовой базе, что это можно было почувствовать, но все еще обслуживала три разные ОС.

Windows 10 стала шансом свести эту тройку воедино и объединить инженерные усилия. Однако параллельно этому новые области применения технологий вызвали спрос на добавление поддержки большего количества устройств с Windows: IoT, Microsoft HoloLens, Surface Hub и будущие члены семейства устройств с Windows. Windows 10 нужно было превратиться в одну ОС не только для Windows, Phone и Xbox, но и для каждой из будущих платформ.

И Microsoft добилась этого. Windows 10 стала компактной, где одна базовая ОС выполняется на каждом семействе устройств. Это было вовсе не так просто, как написать диалог File | Save As. Умные люди упорно трудились, чтобы создать инженерное чудо в невероятно жесткие сроки. Windows 10 — это единая кодовая база, необходимая для поддержки UAP. Отныне каждый продукт Microsoft будет разрабатываться на одной основе, заложенной в Windows 10.

Единство, а не единообразие Объединение кодовых баз в одну основную ОС не означает, что на разных устройствах будет один UI. В Windows Phone имеется удобный, популярный среди пользователей интерфейс, с которым можно работать одной рукой и который значительно отличается от интерфейса Xbox. То же самое относится и к Surface Hub, Microsoft HoloLens, Raspberry Pi. Эти устройства предоставляют большую часть своей функциональности через собственные уникальные пользовательские среды. Тем не менее, ОС со своими библиотеками, исполняющей средой и инфраструктурами одна и та же. Также одинаковы аппаратная и прикладная платформы. Однако UI и функциональность оболочек различаются и оптимизированы под модели использования каждого устройства.

Теоретически, можно было бы загрузить эту базовую ОС и даже запустить приложения, но никто делать этого не станет, потому что это просто строительный блок. Для корректной поддержки каждого форм-фактора в базовую ОС добавляются аппаратно-зависимые компоненты оболочки, такие как меню Start, специфическая поддержка HID и любые другие элементы, необходимые для использования специфичного устройства функционала. Эти дополнительные компоненты опираются на базовую ОС, образуя другие SKU операционной системы, которые вы видите как продукты Microsoft, например Windows, Server, Xbox и HoloLens.

Одна платформа приложений Здесь вы можете подшутить над своими друзьями. Скажите им, что вы собираетесь использовать последние инновации Microsoft в области разработки приложений, но не будете ориентироваться на Windows 10. Как? Очень просто: следующее поколение Windows-приложений не будет ориентироваться на операционную систему. Вместо этого они будут разрабатываться под прикладную платформу (платформу приложений). В Windows UAP является согласованной моделью приложений и поверхностью API, гарантированно доступной на каждом устройстве с Windows.

UAP — это не исполняющая среда. Windows-приложение, даже написанное на управляемом языке (вроде Visual Basic или C#), компилируется под «железо», как и любое другое приложение. Оно не выполняется в исполняющей среде. Эта среда ему не нужна. UAP является поверхностью API для всех устройств, поэтому ориентация на UAP означает ориентацию на конкретный набор и версию API.

Стоит отметить, что вы создаете Windows-приложения и игры с помощью инструментария и технологий, с которыми вы уже знакомы. Windows-приложения, написанные на управляемых языках, по-прежнему используют Microsoft .NET Framework, которая сама по себе является не более чем набором интерфейсов, базовых классов и вспомогательных методов. Подмножество полной .NET Framework, применяемой в управляемых приложениях, которое ориентировано на UAP, называется .NET Core. В дополнение к этому большинство API, используемых в приложениях, ориентированных на UAP, находится в Windows Runtime, которая проецируется на каждый язык — не только на управляемые языки.

Дело не только в XAML В этой статье будет продемонстрировано XAML-приложение, но DirectX- и JavaScript-приложения (веб-приложения Windows) тоже поддерживаются UAP — так же, как они поддерживались в Windows 8. XAML важен для многих платформ Microsoft: Windows Presentation Foundation (WPF), Silverlight в браузере и в Windows Phone, а теперь и на платформе Windows UI (проект которой начинался под кодовым названием «Jupiter»).

Microsoft Office 2016 теперь является семейством UAP-приложений. Какую технологию UI они используют? XAML. Ввиду этого платформа XAML богата разнообразным функционалом и элементами управления, которые Microsoft и сторонние разработчики, например вы, могут использовать в своих Windows-приложениях.

Если говорить о XAML, то здесь Microsoft вне конкуренции.

В настольной оболочке Windows появилось много новых средств наподобие меню Start и Action Center. Какую технологию UI они используют? XAML. Ввиду этого платформа XAML является в высшей степени производительной, обеспечивая визуализацию за доли секунды.

Если говорить о XAML, то здесь Microsoft вне конкуренции. Многие важные приложения ОС вроде Photos и MSN-приложений, таких как Health & Fitness, полагаются на XAML-платформу UI, обеспечивающую ту же богатую функциональность, которую каждый разработчик может задействовать в своих Windows-приложениях. Кроме того, вы можете сделать все, что видите в приложениях от Microsoft. Не только область поверхности API одинакова для всех, одинакова и XAML-платформа UI.

Ценность для разработчиков ПО Не достаточно написать приложение, которое может работать на каждом устройстве. Чтобы дать реальную выгоду пользователям, ваше Windows-приложение должно чем-то выделяться на разных устройствах. Благодаря расширяемости UAP в единый двоичный файл, выполняемый на каждом устройстве, можно включать специфичный для конкретного устройства код.

С помощью UAP вы получите не только единый двоичный файл, но и единый магазин приложений (Store) для всех устройств — смартфонов, планшетов, настольных ПК и даже Xbox. Это не только упрощает пользовательскую среду, но и облегчает зарабатывание денег, а также сводит к минимуму показатели для отслеживания успеха приложения на рынке.

Один магазин и одна платформа позволяют вам должным образом развертывать ресурсы. То есть ресурсы, предназначенные для Xbox, не попадут на смартфон. Кроме того, в UAP сохранена имеющаяся в Windows 8 возможность упаковки ресурсов, ориентированных на конкретные разрешения экранов и масштаб.

Стоит отметить, что вы создаете Windows-приложения и игры с помощью инструментария и технологий, с которыми вы уже знакомы.

Как всегда, вы сохраняете полный контроль. Хотя UAP поддерживает все устройства с Windows, это не означает, что и вы должны делать то же самое. Вы выбираете семейство устройств, которое будет поддерживаться вашим Windows-приложением. Ваше Windows-приложение может быть предназначено только для смартфонов или только для Xbox, или только для HoloLens — это ваше дело. Windows Store гарантирует, что приложение будет доставляться на выбранное вами семейство устройств.

Для разработчика ценность не просто в более широком охвате устройств, но и в том, что становится легче создавать и распространять приложения. Вы имеете дело с одним набором инструментов, включая Visual Studio и Blend for Visual Studio, которые вам уже известны и которые давно вами любимы, с привычным набором языков, в том числе JavaScript, Visual Basic или C# (.NET Framework) и C++/CX. В общем, вы и ваша группа создаете Windows-приложения, используя то, что уже знаете.

Продумывать нужно многое

Большие возможности налагают большую ответственность. UAP позволяет Windows-приложениям работать на любом типе устройства с Windows. Это потрясающе, но здесь следует пояснить, что не на каждом устройстве пользовательская среда (UX) одинакова. А значит, хотя вы используете многие из тех же методов адаптивного веб-дизайна (responsive Web design, RWD), что и в своих веб-приложениях, нужно продумать, как рабочий процесс вашего Windows-приложения будет подстраиваться под разные типы устройств, предназначенных для разных применений. UAP может лишь обеспечить поддержку разных устройств, а создание специфической UX целиком возлагается на разработчика и дизайнера.

Microsoft предоставляет богатый инструментарий, помогающий создавать адаптивные Windows-приложения. Visual Studio может имитировать при разработке соотношение сторон, размеры и масштаб экрана нужного устройства. Visual Studio также может имитировать (а иногда и эмулировать) конкретные устройства, даже если у вас их нет. Это позволяет тестировать Windows-приложения и подстраивать их UX.

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

Важно отметить, что создание Windows-приложения, которое рассчитано на несколько устройств, не означает необходимости написания кода до наименьшего общего знаменателя. Проверки в период выполнения (с использованием классов из пространства имен Windows.Foundation.Metadata.ApiInformation) обеспечивают включение аппаратно-зависимых возможностей, которые позволяют вашим приложениям создавать наилучшую UX на каждом устройстве. Новые средства и комбинированные элементы управления (converged controls) являются строительными блоками, о которых вы так давно мечтали.

Анатомия Windows-приложения

Теперь рассмотрим важные методы создания Windows-приложения, которое будет выполняться на устройстве любого семейства. Мы предполагаем, что вы знакомы с XAML-разработкой приложений под Windows 8.1 Windows Runtime (WinRT). Windows-приложения являются их эволюционным развитием. Вы найдете множество обучающих ресурсов в Microsoft Virtual Academy (aka.ms/w8learn). В этой статье мы сосредоточимся на новых средствах в UAP для выполнения Windows-приложений на разных семействах устройств.

В Visual Studio 2015 под узлом Templates/Visual C#/Windows Universal в диалоге New Project есть несколько шаблонов проектов: Blank App, Class Library и Windows Runtime Component. Вы используете шаблон Blank App, чтобы создать Windows-приложение. Шаблоны Class Library и Windows Runtime Component позволяют инкапсулировать UI и логику для повторного использования в других проектах. Class Library поддерживает приложения, не рассчитанные на UAP, но ограничивается управляемыми языками, а Windows Runtime Component можно использовать между языками (включая JavaScript и C++/CX), хотя при этом вы должны соблюдать правила, которые ограничивают открытую поверхность API.

Для нашего примера выберите Blank App, как показано на рис. 2.

Рис. 2. По умолчанию Windows-приложения теперь используют пустой шаблон

Где все остальные шаблоны? Возьмем тот же шаблон Hub App, который поставлялся с Windows 8. Многие разработчики пользовались им. И многие копировали его. Теперь центральную роль играет шаблон Blank App, помогая разработчикам создавать визуально согласованные, но разные интерфейсы на данной платформе. В Visual Studio Gallery уже начали появляться шаблоны, созданные сообществом, в том числе Template10, написанный авторами этой статьи.

Hello World! Вы создали свое первое Windows-приложение. Хотя UI пуст, приложение уже сейчас можно запустить на любом устройстве с Windows. Solution Explorer в Visual Studio раскрывает, насколько элементарно базовое Windows-приложение: единственный проект с App.xaml и один файл MainPage.xaml для начального UI.

Выше решение включает другие привычные вспомогательные файлы. Package.appxmanifest объявляет возможности, которые приложение запросит от устройства пользователя, например определение местонахождения пользователя, доступ к камере и файловой системе. XML-схема была расширена, но в целом почти та же, что и appxmanifest для универсальных приложений Windows 8.1.

Где два главных проекта? Универсальные приложения Windows 8 требовали главных проектов (head projects, или heads) как для Phone, так и для Windows. UAP не требует нескольких главных проектов. Вместо этого вы адаптируете свои интерфейсы под устройство, на котором выполняется ваше Windows-приложение. Тем не менее, вы, безусловно, можете создать решение на основе нескольких главных проектов, если этого требует рабочий процесс в вашей группе. Оба подхода поддерживаются в равной мере.

Включение контента Открыв MainPage.xaml, вы увидите, что работать с XAML в Visual Studio теперь комфортнее. Дизайнер стал быстрее и предлагает больший функционал, улучшена возможность имитации соотношения сторон и масштаба экрана, расширен сам инструментарий. Теперь добавим немного XAML, как показано на рис. 3. (Благодарим за этот пример нашего коллегу, Дэвида Кроуфорда [David Crawford].)

Рис. 3. RelativePanel позволяет легко размечать UI

<Grid Background="{StaticResource EggshellBrush}">
  <RelativePanel x:Name="PromoArea">
    <Image x:Name="BannerImage" HorizontalAlignment="Right"
           Height="280" Stretch="UniformToFill"
           Source="Assets/clouds.png"
           RelativePanel.AlignRightWithPanel="True"/>
    <Grid x:Name="BannerText" Margin="24"
          Background="{StaticResource BlueBrush}">
      <StackPanel Margin="12" HorizontalAlignment="Stretch">
        <TextBlock x:Name="Headline" Text="Come fly with us"
                   Margin="0,-32,0,0" FontSize="48"
                   Foreground="{StaticResource EggshellBrush}"
                   FontFamily="{StaticResource LustScriptFont}"
                   />
        <TextBlock x:Name="Subtitle" FontSize="21.333"
                   Foreground="{StaticResource EggshellBrush}"
                   FontFamily="{StaticResource
                     DomusTitlingFont}">
          <Run Text="Fly return to London"/>
            <LineBreak/>
          <Run Text="For only $800"/>
        </TextBlock>
      </StackPanel>
    </Grid>
  </RelativePanel>
</Grid>

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

Добавление некоторых ресурсов XAML ссылается на три файла, добавленные нами в папку Assets: на файл изображения (Clouds.png) и два пользовательских шрифта (DomusTitlingFont.ttf и LustScriptFont.ttf). Ресурсы шрифтов и пользовательской кисти (Brush) объявляются в App.xaml:

<Application.Resources>
  <SolidColorBrush x:Key="BlueBrush" Color="#FF1C90D1"/>
  <SolidColorBrush x:Key="EggshellBrush" Color="#FFFAFFF7"/>
  <FontFamily x:Key="LustScriptFont">
    Assets/Fonts/LustScriptDisplay.otf#Lust Script Display
  </FontFamily>
  <FontFamily x:Key="DomusTitlingFont">
    Assets/Fonts/DomusTitling.otf#Domus Titling
  </FontFamily>
</Application.Resources>

Все эти файлы включены в пакет исходного кода, сопутствующий этой статье.

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

Выполнение на устройствах UI формируется в MainPage.xaml. Чтобы запустить приложение, можно выбрать целевое устройство в раскрывающемся списке Visual Studio. Обратите внимание на то, что в него включены Windows Simulator (для тестирования сенсорного ввода), Local Machine, Remote Machine (для тестирования на ARM) и Device (аппаратное обеспечение настоящего смартфона). Эмуляторы смартфонов находятся в том же списке. Выберите запуск в Local Machine, а впоследствии один из эмуляторов Phone, чтобы посмотреть, как ваше Windows-приложение работает на различных устройствах безо всякой специальной компиляции под них.

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

Вероятно, вы заметили, что выполнение Windows-приложения в Local Machine, т. е. на настольном ПК, позволяет использовать окна, а не полный экран, как в Windows 8. Дело в том, что вы выполняете свое приложение на настольном SKU Windows 10. Мобильный SKU Windows 10 по-прежнему запускает Windows-приложения как полноэкранные, чтобы облегчить сенсорную навигацию. Но настольный SKU Windows 10 также будет запускать Windows-приложения как полноэкранные, если вы выберете поддержку сенсорного ввода через интерфейс Continuum на планшете или на трансформируемом лэптопе (convertible laptop).

Адаптивные интерфейсы Хотя Windows-приложение работает на обоих устройствах, при более близком изучении становится понятным, что UI не особо годится для экранов меньших размеров на смартфонах. Текст заголовка слишком крупный для малого экрана и обрезан. Это начало более долгого пути в тестировании и улучшении UX на разнообразных устройствах для данного Windows-приложения.

Мы будем изменять разметку заголовка, обнаружив более узкий экран смартфона. Однако важно понимать, что распознается не сам смартфон, а ширина экрана. Заметьте, что для распознавания смартфона никакого API не предусмотрено. Тем не менее, если ваш дизайн требует операций, выполняемых одной рукой, которые специфичны для смартфонов и малых планшетов, то вы можете проверять размер физического устройства по диагонали в пользовательском триггере Visual State (эта тематика в данной статье не рассматривается).

Visual States не являются чем-то новым в XAML. Visual State Manager позволяет разработчикам и дизайнерам определять разные визуальные состояния (т. е. разные разметки экранов) и переключаться между ними в период выполнения. В UAP введено такое новшество, как Visual State Adaptive Triggers. Они избавляют от программного подхода к переключению визуальных состояний. Вместо этого вы объявляете в XAML, когда некое визуальное состояние должно быть видимо, а остальное проделает нижележащая платформа.

Теперь модифицируем XAML в MainPage.XAML, как показано на рис. 4.

Рис. 4. XAML теперь поддерживает объявление правил для адаптации интерфейса

<Grid Background="{StaticResource EggshellBrush}">

  <VisualStateManager.VisualStateGroups>
    <VisualStateGroup x:Name="WindowStates">
      <VisualState x:Name="NarrowState">
        <VisualState.StateTriggers>
          <AdaptiveTrigger MinWindowWidth="1"/>
        </VisualState.StateTriggers>
        <VisualState.Setters>
          <Setter Target="BannerImage.Height" Value="120"/>
          <Setter Target="BannerText.(RelativePanel.Below)"
                  Value="BannerImage"/>
          <Setter Target="BannerText.Width" Value="660"/>
          <Setter Target="BannerText.Margin" Value="0,0,0,24"/>
          <Setter Target="Headline.FontSize" Value="28"/>
          <Setter Target="Subtitle.FontSize" Value="12"/>
        </VisualState.Setters>
      </VisualState>
      <VisualState x:Name="MediumState">
        <VisualState.StateTriggers>
          <AdaptiveTrigger MinWindowWidth="660"/>
        </VisualState.StateTriggers>
        <VisualState.Setters>
          <Setter Target="BannerImage.Height" Value="180" />
          <Setter Target=
                  "BannerText.(RelativePanel.AlignTopWith)"
                  Value="BannerImage"/>
          <Setter Target="Headline.FontSize" Value="28"/>
          <Setter Target="Subtitle.FontSize" Value="14"/>
        </VisualState.Setters>
      </VisualState>
      <VisualState x:Name="WideState">
        <VisualState.StateTriggers>
          <AdaptiveTrigger MinWindowWidth="1000"/>
        </VisualState.StateTriggers>
        <VisualState.Setters>
          <Setter Target=
                  "BannerText.(RelativePanel.AlignTopWith)"
                  Value="BannerImage"/>
        </VisualState.Setters>
      </VisualState>
    </VisualStateGroup>
  </VisualStateManager.VisualStateGroups>

  <RelativePanel...

На рис. 4 объявлено три визуальных состояния: NarrowState, WideState и MediumState. Каждое из них соответствует разным диапазонам ширины экрана. Вы можете свободно создавать столько визуальных состояний, сколько вам нужно, чтобы поддерживать ваши целевые семейства устройств. Имя, используемое для каждого визуального состояния не имеет значения.

В этом XAML также демонстрируются Visual State Setters, которые являются новинкой в UAP и позволяют вам задавать дискретное значение свойства без издержек раскадровки анимации. Здесь мы используем аксессоры set (setters) для изменения относительной позиции дочернего элемента в RelativePanel, устанавливая присоединенное свойство RelativePanel в дочерних элементах, а также изменяем высоту BannerImage и FontSize текстовых элементов. После подготовки визуальных состояний интерфейс адаптируется под более узкие экраны. Запустите приложение и посмотрите сами!

На рис. 5 показано, как UI адаптируется под изменения ширины экрана. В вашем Windows-приложении вы можете использовать преимущества триггеров визуального состояния, чтобы подгонять элементы любым наиболее подходящим образом.

Рис. 5. Адаптация к изменениях в ширине экрана

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

Адаптивный код UI адаптируется под разные экраны, но устройства различаются не только размерами экранов. Например, в смартфонах есть аппаратные кнопки, такие как Back и Camera, которые, возможно, отсутствуют на другой платформе, например на ПК. UAP по умолчанию предоставляет большую часть поверхности API, необходимой Windows-приложениям, но специфичная для конкретных устройств функциональность раскрывается только с помощью Extension SDK, которые вы добавляете в свои проекты как внешние сборки (рис. 6). Они обеспечивают более широкий набор аппаратно-зависимой функциональности, не мешая выполнению вашего приложения на устройствах других типов.

Рис. 6. Добавление расширения не сложнее добавления ссылки

Два наиболее распространенных Extension SDK — это расширения Desktop и Mobile, которые обеспечивают функциональность, уникальную для соответствующих Windows SKU. Например, расширение Mobile предоставляет API, необходимые для использования аппаратной кнопки Camera.

Windows Mobile SKU может работать на смартфонах и малых планшетах. Однако не все планшеты (и даже не все смартфоны) имеют аппаратную кнопку Camera. Extension SDK обеспечивают поддержку кнопок такого рода, но создать ее на устройстве никак не могут. В итоге при выполнении вы должны проверять возможности устройства, прежде чем вызывать тот или иной функционал в Extension SDK.

Как и платформенные Extension SDK наподобие Mobile и Desktop, которые открывают возможности устройств для Windows-приложений, пользовательские Extension SDK добавляют поддержку дополнительных компонентов вроде Kinect for Windows или стороннего аппаратного обеспечения. Они тоже не препятствуют выполнению вашего приложения на устройствах других типов.

Два наиболее распространенных Extension SDK — это расширения Desktop и Mobile, которые обеспечивают функциональность, уникальную для соответствующих Windows SKU.

Как проверить возможности устройства? Использовать методы класса Windows.Foundation.Metadata.ApiInformation, которые возвращают простое булево значение, если какой-то тип или метод поддерживается на текущем устройстве. Вы можете разрешить Windows-приложению задействовать кнопку Camera с помощью такого кода:

if (Windows.Foundation.Metadata.ApiInformation.IsTypePresent(
  "Windows.Phone.UI.Input.HardwareButtons"))
{
  Windows.Phone.UI.Input.HardwareButtons.CameraPressed +=
    HardwareButtons_CameraPressed;
}

Здесь обратите внимание на то, что коду Windows.Phone.UI.Input.HardwareButtons разрешается выполнение, только если на устройстве используется Extension SDK. В отличие от выражений условной компиляции проверка на аппаратные возможности не приводит к генерации нескольких двоичных файлов. То есть вы можете корректно расширять или сокращать функционал UX в соответствии с возможностями текущего устройства. Это эффективный подход, позволяющий иметь дело лишь с одним двоичным файлом, создавать безграничную вариативность и выжимать максимум возможного из Windows-приложений на разных семействах устройств.

Заключение

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

Создание Windows-приложения означает, что оно может работать на любом устройстве с Windows. В этой бочке меда есть ложка дегтя: UAP может выполнять ваше приложение, но лишь разработчики и дизайнеры могут адаптировать UI и код под специфику конкретных семейств устройств для формирования лучшей из возможных UX. Если вы хотите создавать отдельные двоичные файлы, специфичные для конкретных устройств, то можете делать и так. Но, если вы предпочитаете создать Windows-приложение, которое поддерживает несколько типов устройств, весь инструментарий и инфраструктура уже есть — все готово к тому, чтобы вы могли добиться успеха.

Jerry Nixon — разработчик-идеолог в Microsoft из Колорадо. Обучает и рассказывает на различных мероприятиях о разработке для Windows, смартфонов и настольных ПК. Его карьера началась с выпуском Microsoft SQL Server 6.5, которая предоставляла решения, ориентированные на данные, в те времена, когда понятие «разработчик баз данных» было новым. Получил благодарность от командования ВМС за работу в области безопасности, которая предшествовала его деятельности над «стартап»-проектом, который впоследствии вырос в Microsoft CRM. В течение 15 лет создавал мобильные решения, ориентированные на технологии Microsoft. Сегодня часто выступает с презентациями по XAML и всему, что связано с мобильными технологиями, на различных мероприятиях, в сообществах и университетах, а основную часть свободного времени тратит на воспитание трех своих дочерей.

Andy Wigley — разработчик-идеолог в Microsoft из Великобритании. Перешел в Microsoft в 2012 г., а до этого работал в качестве консультанта и был известным членом сообщества разработчиков мобильных приложений. Гордится тем, что уже десять лет подряд получает звание Microsoft Most Valuable Professional (MVP). Хорошо известен своими популярными видеороликами Windows Phone JumpStart, доступными на channel9.msdn.com, и счастлив работать совместно с Джерри Никсоном над продолжением серии видеороликов по разработке Windows-приложений.