Windows — внезапно 10, часть 3: новые универсальные приложения для платформы WinRT
Часть 3: новые универсальные приложения для платформы WinRT На нашем сайте уже вышел обзор основных нововведений в первой предварительной версии Windows 10. Рекомендуем ознакомиться с ним перед тем, как приступать к этому материалу. Также рекомендуем прочесть первую и вторую части этой статьи.
Разговор о Windows 10 (начатый в первой и второй частях) выглядит неполным без обсуждения универсальных приложений, которые были представлены Microsoft весной, вместе с анонсом Windows Phone 8.1. В Windows Phone 8.1 Microsoft перешла с преимущественного использования Silverlight на стандартные API WinRT, т. е. в смартфонах теперь практически такая же платформа, как и WinRT (платформа для новых приложений) в Windows 8/10. Новый руководитель Microsoft, Сатья Наделла, и вовсе обещает нам единую платформу для приложений, работающую на любых устройствах «начиная от датчиков и кончая серверами». В общем, давайте поговорим о технических особенностях универсальных приложений и платформы WinRT, на которой они работают.
В этом материале я специально избегаю вопросов «Зачем это сделано?», «Почему так?» и «А как оно в сравнении с Win32?». Если нужен отдельный материал по этим вопросам — пишите в комментариях, постараюсь написать.
Универсальные приложения Итак, а что же поменялось с приходом универсальных приложений? Как обычно, жизнь немного упростилась. Хотя, строго говоря, концепция универсального приложения важна в первую очередь для разработчиков. Объясню почему.
В Windows Phone 8.1 Microsoft привела платформу к «общему знаменателю» с WinRT. Раньше Windows Phone во многом строилась на Silverlight, теперь — перешла на API WinRT. Грубо говоря, раньше разработчикам приходилось писать два приложения под две разные платформы, даже если работали они одинаково. Microsoft, правда, еще в Windows Phone 8 обещала, что «достаточно просто перекомпилировать», но… Теперь разработчик может делать единый проект для смартфонов и больших устройств (планшетов, ноутбуков и ПК), в среде разработки Visual Studio появился соответствующий шаблон.
Проект состоит из трех видов компонентов: общие для обеих платформ (заработает и там, и там), только для смартфонов или только для компьютеров и планшетов. Теперь, раз Windows Phone тоже работает на API WinRT, большая часть кода будет одинаково работать на всех устройствах. То есть большую часть приложения достаточно написать один раз. Остается небольшое количество ресурсов, которые все-таки специфичны для одной из платформ. Ну и, разумеется, интерфейс будет разный.
Правда, в конце все равно получается две сборки приложения — одна для смартфонов, другая для планшетов и ПК. Но в магазине они будут отображаться как единое приложение, иметь единый идентификатор — просто скачиваться будет версия под конкретное устройство. Это и называется «Единый магазин». Приобретая приложение для одной из платформ, покупатель может бесплатно установить его и на другую. Об этом мы подробнее поговорим ниже.
Сейчас в Windows Phone 8.1 сохраняется и совместимость со старыми приложениями, но новые уже лучше писать с расчетом на API WinRT и, соответственно, сразу на обе платформы. Кстати говоря, конвертация в универсальное приложение в новой версии среды разработки делается относительно просто.
Таким образом, теперь разработчикам стало проще: фактически, они делают одно приложение, дальше проводят некоторую адаптацию (тот же разный интерфейс) и получают приложение, которое работает на обеих платформах — и смартфонах, и ПК с планшетами. А раз делать стало проще — больше шанс, что приложение под смартфоны Windows Phone сделают «заодно».
Пользователям новый тип приложения как таковой никаких новых преимуществ не принесет. Хотя владельцы одновременно и компьютера, и смартфона на Windows Phone 8.1 могут получить определенные выгоды — и приложений станет больше, и скачивать их проще, и платить меньше.
Тем не менее, по совокупности концепция универсальных приложений и новые идеи Windows 10 вносят в концепцию приложений WinRT много изменений.
Как работают универсальные приложения WinRT Техническая часть: как работает платформа WinRT Углубляться в техническую основу WinRT не очень хочется, это слишком узкоспециальная тема, интересная разработчикам и программистам, к которым я не отношусь. Впрочем, они уже все изучили и без меня. Поэтому поговорим об общих особенностях платформы, которые влияют на создание приложений.
Хотя WinRT — это единая среда, она позволяет писать код на совершенно разных языках и в рамках совершенно разных концепций. Как говаривал Джеймс Бонд: «Смешать, не взбалтывать». Так же поступили с WinRT. Платформой поддерживаются фреймворки XAML, HTML и DirectX, что дает возможность создавать код в:
С++ (с дополнениями Metro Extentions) C#, vb.NET — с разметкой XAML HTML5 и Javascript — с дополнениями для WinRT API Причем части, написанные с помощью разных фреймворков и на разных языках, могут уживаться и в рамках одного приложения. В нем можно создавать универсальные параметры, которые будут действовать для всех частей, написанных на разных языках. Microsoft рассматривает это как достоинство: мол, разработчикам, хорошо знающим какой-то один язык, не нужно переучиваться, а можно использовать накопленные знания и опыт —, а также накопленный код.
В отличие от других платформ, WinRT (на это намекает присутствие С++) работает не только с высокоуровневым интерпретируемым кодом, но и с нативным, что позволяет добиться гораздо более высокой скорости. Сама среда, кстати говоря, написана по большей части на С++ (для сравнения, Win32 — на С).
WinRT позволяет работать на аппаратных платформах х86 и ARM.
Работа приложений WinRT в системе Одно из основных различий между WinRT и Win32 — схема работы приложений. В соответствии с современными тенденциями (и в разительном контрасте с тем, как это устроено в традиционной Windows), каждое приложение WinRT работает в своем контейнере (т. е. «песочнице»). В WinRT можно запускать только приложения, имеющие цифровую подпись, а устанавливать их разрешено только из магазина приложений Microsoft. Плюсы и минусы такой схемы выходят за рамки этого материала, поэтому ограничимся только особенностями для приложений.
Во-первых, покупка приложений привязывается не к устройству, а к учетной записи. Магазин помнит о факте оплаты, то есть купив приложение один раз, можно устанавливать его на все свои устройства. В случае с универсальным приложением в этот список включаются и смартфоны: хотя физически контейнер разный, но магазин рассматривает его как одно и то же приложение с версиями под разные платформы (одинаковый идентификатор), и второй раз платить не нужно. В теории разработчики могут отказаться от этой схемы и брать деньги за обе версии, но их всячески убеждают, что это неправильно.
Во-вторых, обновление приложений также идет централизованно, через магазин. Это серьезно упрощает жизнь и пользователю (один раз нажал на кнопочку, все само скачалось и установилось), и разработчику. Теперь не нужно городить огород с механизмами обновления в приложении (либо, еще хуже, делать отдельный резидентный модуль, который будет сидеть в системе постоянно), держать ресурс, откуда обновления можно скачать, и т. д.
В-третьих, удаление приложения. Раз приложения WinRT существуют в контейнере, то и удаляются они путем удаления контейнера. Они не оставляют мусора в системе, и этот мусор не приводит к деградации ее производительности, что частенько случается с Windows.
API WinRT Но самая главная особенность работы приложений WinRT — это ограничения по взаимодействию приложения с системой и приложений между собой. Универсальные приложения WinRT могут общаться между собой или обращаться к системе только через системные механизмы и в рамках тех средств (API), которые им предоставляет сама система. Приложение WinRT не может получать прямой доступ к системным компонентам или аппаратным устройствам. Работа с накопителем тоже очень ограничена: приложение может записывать данные только в определенные пользовательские папки (документы, картинки и пр.), но и там есть дополнительные ограничения.
Основной минус такой схемы работы — приложение может только то, что разрешит ему система, и только так, как это реализовано в API. Сделать что-либо вне очерченных рамок невозможно, обходных путей тоже нет. Если нужна какая-то другая функциональность — надо ждать, пока Microsoft сделает соответствующий API. Можно упомянуть и неизбежное падение производительности за счет появления дополнительных посредников, которые тоже тратят ресурсы процессора.
Основной плюс — разумеется, в безопасности и стабильности системы. Если система контролирует все взаимодействие приложений на соответствие жестким правилам, значит, возможностей у приложения сделать что-либо не то с системой (случайно или намеренно) будет гораздо меньше.
Кроме того, универсальные приложения в WinRT получили дополнительные возможности. Например, схемы взаимодействия между приложениями теперь унифицированы и доступны системе благодаря универсальным требованиям. Системный поиск может работать с контентом внутри приложений, т. к. нужные механизмы реализованы в приложении. А приложение может обращаться к другим приложениям по четкой процедуре, нет былого зоопарка уникальных несовместимых вариантов. Например, можно интегрировать лайки с фейсбука, поделиться фото из инстаграма и пр. Другой вопрос, что сейчас это пока не всегда работает, но…
Очень многие стандартные функции реализованы напрямую в системе, и разработчикам не нужно каждый раз изобретать их — достаточно вызвать стандартный системный вариант. Например, вывод на экран уведомлений — теперь это делается через системную службу. Или, например, возможность синхронизации настроек приложений, расположенных в папке настроек, между всеми устройствами пользователя — это тоже встроенная возможность системы.
Наконец, API WinRT постоянно развиваются, и разработчикам становятся доступны новые возможности. Особенно ярко это видно на примере развития Windows Phone 7–8. Пример, может, не совсем корректный, учитывая отказ Microsoft от обновления устройств, но зато наглядный. На сегодня WinRT уже включает в себя некоторые API из Win32, COM, .NET, и Microsoft планирует внедрять поддержку других существующих API. Это, помимо всего прочего, дает возможность использовать код, ориентированный на работу с этими API. Кстати говоря, это работает в обе стороны: некоторые возможности API WinRT (например, обращение к датчикам) доступны и для десктопных приложений.
Практический пример: работа с датчиками В качестве примера того, как система организует взаимодействие приложений и устройств, можно посмотреть на работу Windows с датчиками.
В Windows 8 появилась новая схема работы с датчиками. Во-первых, есть требования Microsoft в отношении портативных устройств с Windows 8, какие датчики обязательно должны быть в системе, а какие — опционально (например, GPS обязателен, только если устройство имеет интерфейс WWAN, в остальных случаях его установка остается на усмотрение производителя устройства). Система может эмулировать показания некоторых отсутствующих датчиков за счет имеющихся. Во-вторых, система имеет специальный универсальный фреймворк, который отдает приложениям определенные данные в определенных форматах. Приложениям не нужно напрямую работать с аппаратными датчиками, не нужно знать, с какой именно моделью какого производителя они имеют дело, какие данные и как она отдает. Приложение просто получает нужные ему данные в нужном формате, остальное берет на себя система.
Чтобы понять, насколько это упрощает жизнь, вспомним традиционный путь взаимодействия приложения и периферийного устройства — того же модуля GPS. У нас есть устройство, есть драйвер, который снимает данные с устройства и отдает их системе, есть ПО, которое интерпретирует эти данные и приводит их в читаемый вид, далее — основное ПО, которое с ними работает. В худшем случае разработчику приходится проходить все шаги: писать собственный драйвер, который снимет информацию с устройства, разбираться в том, что́ именно устройство ему дало, интерпретировать эти данные — и лишь потом собственно работать с ними. Первая проблема сейчас более-менее решена: для распространенных устройств есть драйвера либо производителя, либо Microsoft. Однако драйвер не всегда снимает следующую проблему — интерпретацию данных. Поэтому десктопные приложения Windows практически всегда должны знать, с каким устройством работают, т. к. разные устройства имеют разные форматы данных, часто несовместимые (если вы натыкаетесь в настройках приложения на пункт «выберите устройство», то это оно). Датчики, например, дают данные, которые нуждаются в поправке (скажем, компас показывает на магнитный полюс, а акселерометр учитывает еще и магнитное поле Земли). Все это обязательно нужно учитывать при работе с датчиком напрямую. Так что разработчику придется протестировать «знакомые» устройства в разных условиях, чтобы гарантировать совместимость: понять, какие данные и куда они отдают, с какими погрешностями и ошибками и пр. Это колоссальный объем работы, особенно если на рынке много железок.
В Windows 8 система производит все коррекции сама и выдает уже чистые данные. А приложение получает от системы через API сразу готовую информацию в нужном формате. Разработчику не нужно знать, как работает драйвер, проверять свое ПО на совместимость с этими драйверами и выдаваемыми ими данными и пр. Удобно? Не то слово.
У работы через API есть и ряд других достоинств. Например, асинхронное взаимодействие (когда отсутствие или задержка в получении нужных данных не тормозит приложение в целом) или отсутствие конкуренции при доступе к оборудованию (данными из API могут одновременно пользоваться несколько приложений, тогда как при прямом доступе к оборудованию — только одно).
Наконец, важный для мобильных устройств аспект — энергоэффективность. Например, приложение может постоянно требовать от GPS новые данные, т. е. он будет все время активно работать. А это довольно прожорливая штука, которая способна быстро высадить батарею. В этой ситуации система может отключать GPS для экономии энергии — например, если устройство перешло в режим ожидания или находится на одном месте — в этом случае отслеживать положение можно через гораздо более экономный акселерометр. Если положение изменится, GPS можно подключить обратно.
В общем, работа с датчиками является хорошей иллюстрацией плюсов и минусов API. Повышается безопасность: теперь за вашей спиной вирус не получит доступ к данным GPS — т. к. ПО нужно получить прямое разрешение пользователя на доступ к нему. Он также не сможет получить прямой доступ к оборудованию и использовать его каким-нибудь нестандартным способом или вывести из строя (а в Windows такое вполне возможно). Повышается энергоэффективность (теперь приложение не высадит батарейку за счет того, что постоянно дергает GPS. Это касается и другого оборудования). Повышается отзывчивость, благодаря возможности эмулировать координаты до момента, когда GPS активируется и найдет спутники. Наконец, повышается простота работы: раз получить данные с GPS так просто и больше не нужно бороться с устройствами и драйверами, разработчики могут делать разные простые программы с этой функциональностью (взрывной рост количества приложений типа «найди друзей на карте» — хороший тому пример).
Минусы тоже очевидны: у разработчиков больше нет прежней свободы, они скованы рамками API. Например, чипсет GPS может отдавать не только координаты, но и высоту над уровнем моря или скорость. Но т. к. в системном API это не реализовано, то этих данных вы никогда не получите. Это касается и всего остального: получить от системы можно только тот ответ, на который она заранее запрограммирована. Больше не получится реализовать никакие нестандартные сценарии, а ведь именно благодаря им (точнее, благодаря гибкости) Windows стала так популярна.
Интерфейс универсальных приложений — новая концепция Microsoft для Windows 10 Вокруг интерфейса Windows 8 и так сломано слишком много копий, не будем увеличивать их количество. Сейчас Microsoft пытается исправить ситуацию, новшества интерфейса Windows 10 обсуждались в предыдущих частях этого материала. А мы давайте сосредоточимся на интерфейсе приложений.
С технической точки зрения у нового интерфейса WinRT есть несколько новых интересных особенностей. Например, аппаратное ускорение отрисовки интерфейса, позволяющее разгрузить процессор. Собственно, оно появилось еще в Windows 7 — это компонент Direct2D, который заменяет GDI+. Только в Windows 7 разработчиков не заставишь его использовать. Кто хотел, реализовал, кому было лень — не стал…, а в WinRT аппаратное ускорение задействовано всегда. Кстати, там не только аппаратное ускорение — например, система может не перерисовывать статичные участки интерфейса. Также можно упомянуть, что Microsoft заставила-таки разработчиков использовать пропорциональные интерфейсы, которые при масштабировании не разъезжаются. В приложениях под десктоп все не так — там интерфейсы доброй половины приложений написаны через пень-колоду и не выдерживают масштабирования окна программы. Но это мелочи по сравнению с концептуальными особенностями.
При разработке интерфейса Windows 8 Microsoft слишком хотелось сделать решение для планшетов с их небольшими экранами и управлением пальцем, а интересы и приоритеты пользователей ноутбуков и компьютеров (т. е. подавляющего большинства) задвинули в дальний угол. Поэтому изначально интерфейс приложений WinRT должен был быть: а) полноэкранным; б) адаптивным. Однако при столкновении с реальностью выяснилось, что на экране с диагональю 24–27 дюймов полноэкранный калькулятор смотрится несколько… странно. То же и с адаптивностью: вряд ли можно создать такой интерфейс, который будет одинаково хорошо смотреться и на 27-дюймовом настольном мониторе, и на 10-дюймовом планшете. А теперь в парадигму включены еще и смартфоны, где и разрешение, и размер, и даже ориентация экрана — все отличается!
Поэтому сейчас Microsoft предлагает новую концепцию интерфейса для универсальных приложений WinRT. Ее суть, если я правильно понял, в том, что интерфейс приложения должен учитывать класс устройства, то есть параметры экрана (размер, ориентацию и пр.) и некоторые другие особенности (не удивлюсь, если это будет позиционирование, т. е. интерфейсы будут разными для домашних и рабочих систем). В зависимости от этого может меняться внешний вид интерфейса. объем выводимой на экран информации и схема взаимодействия с пользователем. Наиболее очевидный пример, о котором мы говорим в этом материале — смартфон, интерфейс для которого явно должен быть другим, чем интерфейс, например, планшета.
В Microsoft сейчас говорят, что хотят максимально учитывать интересы владельцев ноутбуков и ПК, и это уже самым драматическим образом сказалось на универсальных приложениях WinRT: теперь они открываются на десктопе, да еще и в окне — прям как старые добрые десктопные приложения под Win32. Правда, этим шагом Microsoft здорово подставила разработчиков: они-то верили старым учебникам и считали, что даже при разделении экрана между двумя приложениями по горизонтали, по вертикали они имеют в своем распоряжении всю высоту экрана. А тут внезапно планы поменялись…
Но простая логика подсказывает, что разделения «либо смартфон, либо планшет+ноутбук+ПК» вряд ли будет достаточно. Там более, что интерфейс Windows 8 не учитывал особенности работы с ПК, так интерфейс Windows 10 не учитывает особенности работы с планшетами. Поэтому явно напрашивается третий, промежуточный вариант между интерфейсом для смартфонов и десктопным интерфейсом текущей предварительной версии Windows 10. Каким он будет — пока непонятно, причем, судя по всему, непонятно даже Microsoft.
Таким образом, универсальные приложения должны одинаково работать на любом устройстве с платформой WinRT, однако их интерфейс может различаться в зависимости от класса устройства, размера экрана и других параметров. С одной стороны, делать несколько интерфейсов — дополнительная работа. С другой — такой подход позволяет обеспечить большее удобство работы с приложением на любом устройстве.
Итоги Итак, что нам дает концепция универсального приложения? Самое очевидное: она позволяет расширить парк доступных устройств, включив в них еще и смартфоны. Теперь разработчик может сделать, а пользователь поставить одно и то же приложение на любое домашнее устройство, которое у него может быть.
Жизнь становится проще для разработчика: не нужно делать две отдельные версии приложения для разных платформ. Жизнь становится проще для пользователя: понравившееся приложение можно установить и на компьютере дома, и на смартфоне, который берешь с собой. Да и количество приложений, особенно для Windows Phone, должно вырасти — ведь теперь гораздо проще писать приложения для смартфонов на Windows Phone «заодно».
Другое дело, что сейчас не очень понятно, что вообще будет с универсальными приложениями. Как ни крути, в Windows 8 они занимали центральное место и избежать их использования было сложновато. В предварительных версиях Windows 10 их роль гораздо скромнее и пользователь, который не хочет их видеть, может полностью отказаться от них и остаться в рамках старой системы Win32. Это может нанести серьезный удар по их и так не особо высокой популярности и расстроить разработчиков. Хотя с окончательными выводами стоит подождать до выхода более-менее финальных версий Windows 10, когда станет понятно, чего ожидать от новой системы.
Полный текст статьи читайте на iXBT
