Windows RT глазами разработчика

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

Еще в 2010 г. в одном из интервью во время конференции Gartner Symposium/ITXPO глава Microsoft Стив Балмер признался, что следующая версия Windows — наиболее рискованный продукт компании. В то время еще мало было известно о новой ОС, но сейчас, спустя два года, когда Windows 8 со всеми ее неоднозначными нововведениями представлена широкой публике, эти слова обретают особый смысл. И в данном контексте нельзя не упомянуть такой смелый шаг компании как намеренный перевод нового интерфейса в разряд основного — хочешь того или нет, но даже чтобы открыть привычный рабочий стол, необходимо начать с Modern UI (так теперь политкорректно называется Metro). Сюда же следует добавить и исчезновение кнопки «Пуск», которая вместе с панелью задач была, пожалуй, самым ценным нововведением пользовательского интерфейса Windows 95 и надолго стала визитной карточной этого семейства ОС.

Наиболее заметным и обсуждаемым новшеством является плиточный интерфейс ОС, который, тем не менее, всего лишь вершина айсберга — самые важные изменения как всегда «под капотом» и, только познакомившись с ними непосредственно, можно понять их масштаб и степень риска, который взяла на себя Microsoft. Фактически Windows 8 представляет собой комбинацию двух достаточно независимых ОС — старой Windows x32/x64, доступной только на процессорах архитектуры Intel, и новой Windows RT, которая дополнительно может работать и на процессорах архитектуры ARM. Тот факт, что первая намеренно отодвинута на задний план, а все маркетинговые ресурсы брошены на раскрутку второй, недвусмысленно намекает, на что именно сделана главная ставка.

У столь кардинальных перемен нашлось немного критиков, но если оценка рыночных перспектив новых ОС выходит за рамки этой статьи, то на причинах изменения подходов к разработке хотелось бы остановиться подробнее.

Обратная сторона обратной совместимости

Начать следует, пожалуй, с того, что Microsoft, позиционируя Windows как массовую ОС для ПК, развивала ее и предоставляла возможности для разработки приложений в соответствии с запросами времени, но при этом уделяла поистине фанатичное внимание вопросам обратной совместимости — в каждой новой версии Windows должны были работать все приложения, созданные для всех предыдущих, включая и предшественницу DOS. На первых порах становления Windows, основной проблемой была функциональность создаваемых решений, и разработчики ОС делали со своей стороны все возможное, в том числе и допускали практически неограниченные изменения самой операционной системы. Однако такая вседозволенность вылилась в проблемы со стабильностью — нормально функционирующая из коробки ОС после установки некоторого количества приложений превращалась в непригодную для использования среду. Это было особенно характерно для Windows 3.x, 95, 98, Me. Ответом на данный вызов стала линейка ОС на базе Windows NT, при разработке которой все силы были брошены на повышение надежности, — изменения коснулись файловой системы, ядра, разграничения адресного пространства приложений и т.д. Тем не менее, общая свобода разработчиков в отношении взаимодействия с ОС сильно не пострадала, а сдерживать их фантазии было практически нечем. С одной стороны, это давало неограниченные возможности для модификаций ОС в соответствии с разнообразными запросами пользователей, а с другой — предоставляло те же возможности создателям вредоносного кода, что в эпоху Интернета оказалось особенно опасным. Последней каплей в переполненную чашу подобного рода проблем стало, пожалуй, распространение уязвимостей через дыры в стороннем ПО, к которому создатель ОС не имеет никакого отношения.

Интересно, что заботясь об обратной совместимости, Microsoft принципиально не изменяла API Windows более четверти века — он ведет свою родословную еще с Windows 1.0, когда разработчикам был представлен основанный на использовании процедурных вызовов языка C интерфейс взаимодействия с ОС. Хотя Microsoft впоследствии предложила множество дополнительных API, в частности, Component Object Model (COM) и его производные (OLE, ActiveX, COM+, DCOM), все они в конечном итоге были основаны на классическом Windows API, который даже в эпоху тотального доминирования ООП оставался процедурным. Конечно, средства разработки прошли большой путь за это время, и процесс создания GUI при помощи WPF и Visual Studio для Windows 7 кардинально отличается от того, каким он был во времена самых первых версий Windows и Windows 3.1, для которой в 1993 г. Microsoft выпустила компилятор C/C++ 7.0 с весьма прогрессивной на то время объектно-ориентированной библиотекой MFC. Однако даже с WPF, когда у разработчика возникает потребность в задании некоторых свойств окна, он вынужден обращаться к низкоуровневым функциям WinApi, предварительно импортировав их из соответствующей системной DLL и передав в качестве параметра системную ссылку на окно — точно так же, как это делалось двадцать лет назад.

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

Учитывая вышесказанное, позволим взять на себя ответственность заявить, что наиболее принципиальным нововведением Windows 8 является компонент, представляющий по сути новую ОС под именем Windows RT, в которой для разработчика особенно интересен не столько непривычный интерфейс, сколько принципиально новый API разработки приложений (а также подход к их распространению).

Visual Studio 2012

Свежая версия Visual Studio 2012 подоспела как раз к выходу Windows RT — и это совсем не случайно, поскольку в настоящее время для нее нет альтернативы в качестве среды разработки приложений для новой ОС.

В Microsoft заявляют, что текущее обновление Visual Studio — одно из наиболее масштабных за всю историю существования данной IDE. Догадаться об этом можно и без лишних слов, достаточно лишь взглянуть на среду разработки сразу же после ее запуска — интерфейс обновлен столь значительно, что с первого взгляда узнать Visual Studio будет непросто. Похоже, что по части интерфейса разработчики команды Visual Studio решили освежить все, к чему можно было добраться: начиная от логотипа и заканчивая буквами в названиях меню — теперь они все заглавные. К счастью, освежение явно выполнялось в соответствии с принципом «не навреди» и после непродолжительного периода адаптации опытный пользователь Visual Studio, вероятнее всего, снова почувствует себя вполне комфортно, поскольку все наиболее важные элементы остались на старых местах и функциональных отличий от предыдущей версии не так много, как может показаться на первый взгляд (кстати, прежний вид главного меню также можно вернуть, для этого следует изменить настройку в системном реестре). Однако, нововведения в IDE не ограничиваются только внешнем видом, она порадует заметно улучшенной эргономикой — к примеру, одно из усовершенствований позволяет вызвать нужную команду меню, набирая ее название в специальном поле ввода в верхней правой части экрана, что избавляет от необходимости вспоминать ее точное месторасположение и перебирать многочисленные элементы иерархии.

Visual Studio 2012 значительно преобразилась в части интерфейса и прибавила в эргономике

Что касается более глубоких изменений, то их также предостаточно и в основном они связаны именно с поддержкой Windows RT. В первую очередь стоит упомянуть новую версию .NET Framework 4.5, которая содержит эволюционные изменения, самое важное из которых — именно обеспечение поддержи новой ОС. Также в комплекте с IDE поставляется Windows RT SDK, который включает шаблоны проектов, объединенных общим названием «Windows Store». Шаблоны позволяют создать приложение с заданным расположением элементов управления, что избавляет разработчика от необходимости самому заниматься решением некоторых задач, требующих квалификации дизайнера. В SDK входит и симулятор планшета Windows RT, притом именно симулятор, а не эмулятор, поскольку он не воспроизводит программную платформу полностью, как, например, полноценный эмулятор Windows Phone, а всего лишь представляет собой некую прослойку между IDE и реальной Windows RT, облегчающую отладку приложения (это же объясняет, почему его невозможно запустить, например, на Windows 7). Симулятор позволяет полноценно протестировать и отладить планшетное приложение на обычном настольном ПК, не оснащенном ни сенсорным дисплеем, ни дополнительными датчиками, например GPS. Отметим оригинальную реализацию возможности имитации жестов pinch to zoom — касание двумя пальцами имитируется нажатием клавиши мыши, а расстояние между ними «изменяется» прокручиванием колесика.

Симулятор Windows RT, запущенный из VS 2012 в режиме отладки

Отметим, что в комплекте с Visual Studio поставляются и дополнительные инструменты, в частности, Expression Blend, который теперь позволяет разрабатывать XAML- и HTML-интерфейсы для Windows RT. Также следует упомянуть, что для работы Visual Studio требуется «полноценная» Windows 8, поскольку функционирование IDE в Windows RT не предусмотрено.

Windows RT API

Устройство интерфейса программирования Windows RT API покажется новым только для тех разработчиков, которые не следили за платформой Windows Phone. Для тех же, кому известны подробности устройства последней, многое покажется знакомым. Действительно, несмотря на отсутствие упоминаний о Silverlight, процесс создания приложений для Windows RT во многом повторяет смартфонную платформу. Если в качества языка программирования используется C#, то за исключением очевидных отличий, вроде поддержки других размеров и разрешений экрана, многие составляющие приложения, в частности, язык описания интерфейса XAML, элементы управления, классы, эффекты и анимация, механизм организации многостраничных приложений, асинхронное использование сети, поддержка Push, если и не идентичны, то похожи настолько, что любой Windows Phone разработчик будет готов создавать Windows RT приложения с минимальными затратами времени на адаптацию. Также Windows RT с Windows Phone роднит и еще одна особенность: приложения исполняются в изолированной «песочнице» с ограниченным доступом к системным ресурсам, в особенности, к файловой системе.

Тем не менее, команда разработчиков Windows 8 не ограничилась заимствованием идей у своего смартфонного подразделения, а существенно развила их, представив API, структуру которого демонстрирует следующая схема.

Архитектура API Windows RT предусматривает два принципиально различных стека технологий

Как видно из рисунка, интересной особенностью нового API является поддержка двух принципиально разных стеков технологий:

• традиционного для Windows-разработчиков, основанного на языках программирования C++/C#/VB и языке разметки интерфейса XAML;

• совершенно нового для настольной ОС от Microsoft, но, тем не менее, привычного для миллионов веб-разработчиков, на основе JavaScript и HTML/CSS.

Что касается первого варианта, то как мы уже успели отметить, этот набор технологий и инструментальных средств опробован на Windows Phone, а еще ранее — в WPF и Silverlight. И пусть ничто из упомянутого в предыдущем предложении не получило особой популярности на рынке, инвестиции в разработку и продвижение не пропади даром — они обеспечили технологиям внушительную обкатку и их появление в Windows RT никак нельзя назвать дебютом. Соответственно, и разработка приложений с их помощью мало в чем отличается от создания приложений для Windows Phone или Silverlight, потому детально на ней останавливаться не будем. Отметим лишь, что XAML, как инструмент для построения интерфейса, весьма хорош, поскольку обеспечивает большую свободу в представлении элементов управления и отображения данных, и изначально ориентирован на возможность использования с экранами различного разрешения, что особенно актуально в настоящее время. Управляемые языки C# и Visual Basic в особом представлении не нуждаются, тем более — классический C++. Предположительно, первые два будут использоваться для проектов общего назначения, а последний — там, где необходима повышенная производительность кода, в частности, в играх, тем более, что API DirectX доступен в настоящее время исключительно через C++.

Веб-технологии в настольной ОС

Внимание привлекает именно вторая группа технологий, предусматривающая применение для разработки настольных приложений инструментария, характерного для Веба, — доселе Microsoft ничего подобного не предлагала, несмотря на многолетний опыт создания инструментальных средств для веб-приложений и вполне уверенные рыночные позиции IIS и ASP.NET.

Итак, веб-технологии для настольной Windows в понимании Microsoft — это HTML/CSS для визуального представления и JavaScript для обеспечения программной логики. Исходный код форм приложения представляет собой полноценные HTML5-файлы со всеми присущими им атрибутами — внешним тегом DOCTYPE, тегами head и body, тегом заголовка документа, мета-тегами, ссылками на используемые скрипты и таблицы стилей. Доступные для использования элементы управления повторяют список элементов HTML5. Разумеется, для того, чтобы форма приложения выглядела и работала так же, как и остальные приложения Windows RT, при создании проекта автоматически подключаются определенные библиотеки JavaScript-кода, которые, собственно, и реализуют доступ к API, а также набор CSS-стилей, отвечающих за визуальное представление. Исполняется JavaScript под управлением движка Charka, разрабатываемого изначально для Internet Explorer 9. Его особенность состоит в предкомпиляции кода, соответственно, можно надеяться, что большого проигрыша в производительности по сравнению с традиционными средствами разработки не будет.

Один из наиболее существенных недочетов Visual Studio 2012 при создании приложения этого типа состоит в том, что IDE не предусматривает возможности визуального редактирования или даже просмотра страницы в WYSIWYG режиме — для этих целей предлагается использовать Expression Blend. Это тем более удивительно, что в составе Visual Studio давно имеется прекрасный WYSIWIG-редактор HTML-кода, используемый для проектов ASP.NET. Хочется верить, что причина подобного решения кроется исключительно в недостатке времени на реализацию данной функциональности, но никак не потому, что в Microsoft посчитали ее ненужной.

Один из наиболее существенных недостатков Visual Studio 2012 — отсутствие WYSIWYG-редактора HTML-кода при создании Windows RT приложений

Также следует обратить внимание на тот не совсем очевидный факт, что использование JavaScript/HTML не означает кроссплатформенности создаваемого решения. Открыть в браузере приложение для Windows RT не получится, равно как невозможно и запустить предназначенный для браузера веб-сайт в качестве приложения Windows RT. Однако это не какое-то принципиальное ограничение, просто чтобы проделать подобный «фокус» потребуется определенная адаптация проекта, и вполне вероятно, что вскоре появятся инструменты от сторонних разработчиков или от самой Microsoft, облегчающие подобную задачу. Но в любом случае следует отметить, что создание приложений-компаньонов для сайтов и веб-сервисов, которые являются обычным делом в мобильном мире, теперь существенно облегчается, и они, помимо прочего, смогут разделять существенную долю исходного кода с веб-сайтами.

Несмотря на некоторый скептицизм в отношении самой идеи переноса веб-инструментов на настольную платформу, следует признать, что разработчикам из Microsoft удалось достичь столь органичной интеграции JavaScript/HTML/CSS в Windows RT, что конечные пользователи ни по внешнему виду, ни по каким-либо другим признакам не смогут распознать, с помощью какого из стеков созданы приложения Windows RT. Таким образом, приложения на JavaScript/HTML/CSS в данной случае также следует считать нативными — в самом прямом смысле.

Распространение приложений через Windows Store

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

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

Сложно дать однозначную оценку влиянию, который окажет магазин Windows Store на рынок приложений для ОС Microsoft, но позволим себе пока отозваться о нем положительно — ввиду общей текущей ситуации на рынке ПО для Windows, когда многие небольшие независимые разработчики были вынуждены либо свернуть деятельность, либо перейти на другие платформы из-за падения покупательской активности, что вызвано множеством факторов, и не в последнюю очередь тем, что подобная практика постепенно становится общепринятой.

Заключение

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

Очевидно, что Modern UI в силу особенностей сенсорного экранного интерфейса, а также намеренных ограничений на одновременный вывод нескольких окон не сможет заменить в профессиональной сфере привычный многооконный интерфейс Windows, ориентированный на управление мышью и клавиатурой. Соответственно, можно допустить, что в следующей версии ОС (а может быть и в штатном обновлении нынешней) Microsoft предоставит сторонним разработчикам возможность создавать приложения для режима Рабочего стола Windows RT. В таком случае можно ожидать, что API и среда разработки будут максимально близки тем, что представлены сейчас для Windows RT. Также вполне вероятно, что появятся и инструментальные средства от сторонних поставщиков, что увеличит возможности выбора для разработчиков, хотя сами приложения уже никогда не будут иметь в рамках ОС той свободы, которая у них была во всех предыдущих версиях Windows.

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

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365