Microsoft — мировой лидер в области ПО и ИТ-услуг
184,41
рейтинг
2 апреля 2015 в 09:27

Разработка → Windows 10 для разработчиков

23 марта, стали доступны обучающие материалы по windows 10 на Channel9. В них много чего полезного, что облегчит жизнь разработчикам. Кратко опишу все эти изменения, собранные из 8-часового видеокурса. Лучше, конечно, читать и слушать в оригинале, но для тех, кому тяжело потратить 8 часов на англоязычный курс, данная статья может быть полезной.

image

Один раз скомпилировал, запустил везде


До Windows 10
Для тех, кто писал под windows phone и windows, всегда была проблема — есть как минимум 2 разных проекта, между которыми надо шарить код. Весь общий код выносился в третий проект. Неудобно до жути.
С Windows 10
Теперь, появился настоящий Universal App project. Т.е. проект теперь ровно один! Компилируем мы его один раз и получаем набор бинарных файлов, которые запустятся и на компьютере, и на телефоне под управлением windows 10.

Разные возможности устройств, но по-прежнему один бинарный файл

До Windows 10
Еще со времен WPF/Silverlight, разработчики использовали условную компиляцию (#if WPF или #IF Silverlight), для кода, который, в целом, одинаков для платформ, но с определенными различиями. Код выглядел уродливо.
Равно такие же проблемы были с Silverlight для WP vs WinRT для PW8.1 и WinRT для Windows 8.1, т.к. API несколько отличался для всех 3 типов.

В Windows 10 реализовано более элегантное, на мой взгляд, решение:
Все классы и интерфейсы присутсвуют, и ошибки компиляции не будет.
Для API специфичного для конкретного типа устройства, таких как аппаратная кнопка назад или home, в Windows Phone будет работать, а вот для Windows девайса, если ничего не менять, будет выпадать RunTime ошибка.
Т.к. исполняемый файл у нас ОДИН, то взамен условной компиляции пришла метаинформация о реализованном API для платформы.
Выглядеть это будет так:
image

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


Charm Panel умер, да здравствует SplitView

До Windows 10
На windows 8 появилась Charm Panel, которая была интересной идеей, но неподготовленному пользователю даже найти ее было непросто, а понять, что в ней можно искать функции приложения, так вообще непостижимо. В то же время, пользователи привыкли использовать на всех своих девайсах значки, похожие на выпадающие списки, в которых они привыкли искать настройки.
С Windows 10
Т.к. интерфейс Windows 10 был значительно переработан, то в итоге в появился SplitView, в который теперь рекомендовано переносить функционал, находящийся ранее в Charm Panel. Charm Panel останется в Windows 10 в виде эмуляции, но ее лучше далее не использовать.
SplitView понятнее и проще для пользователя.
image

Из этого следует, что снизится порог вхождения, увеличится visibility, а значит функционалом, заложенным в него, будут активнее пользоваться.

Relative Panel и Адаптация верстки к размеру экрана

На моей памяти, одним из факторов, замедлявшим портирование приложений с Windows Phone на Windows, а иногда просто отбивавшим всякое желание вообще этим заниматься, была проблема с разным размером экрана и ориентацией контента на экране. На телефоне человек держал телефон вертикально, и контент, как правило, скролился вниз, на компьютере (ширина экрана которого больше, чем высота) разумнее было контент скролить горизонтально.

Relative Panel

В Windows 10 добавился новый контейнер RelativePanel. Его суть заключается в том, что его дочерние элементы можно располагать друг относительно друга.
В примере показано, как, нарисовав один квадрат, второй мы ориентируем относительно первого. В данном случае - выше (Above).
image

Код
image

Таким образом, мы можем выбрать элемент-точку отсчета, и все остальные элементы располагать относительно него. Любые перемещения этого объекта, будут отражаться на позиционировании объектов, нахождение которых зависит от него. Лично по мне, это круто и снижает объем верстки, сложность падает, и жить становится легче.
Причем это относительное позиционирование работает вместе с AdaptiveTrigger и написать вот такую трансформацию становится не таким уж время затратным.
image

Как это сделать используя Blend рекомендую посмотреть в видео.
Так же рекомендую посмотреть доклад, что поменялось в части 3d трансформаций.

Взаимодействие приложений между собой

Тут надо разделить на 2 части: новая фича App Service и остальное взаимодействие
Возвращаемое значение

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

С Windows 10, приложение 1, которое вызвало другое приложение 2, может получить от него результат вызова. В этот ответ можно упаковать любые данные (главное, чтобы они были сериализуемые).

Указание вызываемого приложения

До Windows 10, когда мы из приложения 1 активировали приложение 2, мы не могли гарантировать, что будет открыто именно оно. Пользователь мог выбрать другое приложение… а оно могло не работать, могло передавать данные суперхаккерам и т.п.

С Windows 10, мы можем явно указать, какое приложение будет открыто.
image

На самом деле появилось еще несколько фичей, но их я рекомендую послушать в оригинале.

App Service

До Windows 10 приложения не могли предоставлять свой API без интерфейса другим приложениям, по сути. Были обходные пути в виде поднятия WCF сервиса и т.п., но это была скорее борьба с системой, а не ее использование.
В Windows 10 появилась такая фишка- App Service

Суть идеи: приложение может поднять внутри себя сервис и предоставлять его другим приложениям, установленным на этом же девайсе. Эта фича похожа по своей сути на backbground task, но ее можно использовать не только приложением, в котором она находится, но и другими приложениями. Тем самым, платформа нам помогает предоставлять API, а не мешает.

image

Примеры, где это можно использовать: у вас есть приложение платежной системы или сканер кодов. Вам не нужно для каждого приложения тащить все dll и писать свою реализацию. Можно написать один раз приложение, которое хорошо работает с распознаванием кодов, и всем остальным предоставляет этот функционал как сервис.
Клиент должен знать имя сервиса и PackageFamilyName для вызова и какие параметры передавать.
image


Реализация на стороне сервиса такова:
Создаем BackgroundTask и на приходящее снаружи сообщение, регистрируем обработчик.
image


В обработчике мы получаем все параметры из словаря, и на основании них выполняем нашу логику, а затем, отправляем ответ вызвавшему нас клиенту. Возвращаем мы класс ValueSet, это такой набор ключ-значение.
Код
image


За более подробным описанием отправляю Вас в вебкаст, там и про жизненный цикл расскажут, и про то, как его отлаживать (для тех, кто проводил отладку background task, все знакомо).

Web браузер и web приложения на html/js

image

Уже несколько месяцев много говорится о новом браузере Spartan, и приложения на html/js будут использовать новый движок рендеринга этого браузера и получат кучу плюшек от этого. Более детально надо читать про сам браузер Spartan, поэтому расскажу о Hosted Web Apps.

Изменение в Hosted Web App
Лично я не назвал бы это приложением во многих случаях, т.к. если у вас уже есть веб сайт, то вы ссылку на него заворачиваете в ваше приложение, которое открывает внутри себя сайт в браузере.
Приложение, по сути, представляет из себя манифест, набор картинок для плиток и браузер.
image
image


В приложении можно задать ограничения на то, какие URI разрешены, а какие нет. Тем самым вы ограничиваете пользователя от ухода с вашего сайта, через ваше же приложения серфить по просторам интернета.
Пример задания ограничения на uri
image

Что же изменилось? Теперь нам не нужен WebView, мы указываем стартовую страницу прямо в манифесте приложения.
Вы можете интегрировать приложение с native API платформы, той же самой Cortana, но это опционально. В JavaScript вашего сайта вы проверяете, присутствует ли API windows в текущем контексте приложения или нет. Если присутствует, вы можете использовать это API:

image

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

В статью не было включено следующее:
  • Я не стал описывать идеологию изменений в windows 10. Она предельно проста — единый windows, и это хорошо описано много раз до меня.
  • Мое личное мнение: нам на просторах бывшего СССР не очень актуальны карты Bing (причины, я думаю, понятны всем).
  • Также я не стал пересказывать, что стало легче работать с рукописным вводом, т.к. теперь есть контрол для этого. Это очень круто, но очень специфично.


P.S. Если вы хотите помочь улучшить статью — можно предлогать ваши правки через github.
Автор: @SychevIgor
Microsoft
рейтинг 184,41
Microsoft — мировой лидер в области ПО и ИТ-услуг

Комментарии (37)

  • +2
    Много времени в дороге, хороший инет и желание покопаться в новом дают хорошие результаты!
    Игорь, берите меня к себе! =)
  • +7
    Опять эксперименты, над пользователями и разработчиками.
    • 0
      Если честно, то для разработчиков я пока вижу в основном плюсы и всего 2 минуса:
      Конечно неудобство, что charm panel будет эмулироваться и ее функции теперь рекомендуют выносить в SplitView, но это не такая уж сложная задача по разработке, а пользователям явно привычнее.

      Миграция уже написанного кода, в universal app займет какое-то время, но тут все зависеть будет от того, как написаны приложения.
      Но тут я бы подождал и ближе к релизу посмотрел на инструменты по миграции и guideline на эту тему, т.к. сейчас пока рано говорить об этом ответственно.
      • 0
        В результате получается что одно из приложений просто прийдется выкинуть, Вин8 или телефонное.
        • 0
          Если у Вас будет одно приложение, которое работает на обоих устройствах, то на мой взгляд это не потеря, а приобретение(xbox пока оставим за скобками).

          • +1
            Я не говорю что это минус. Это наоборот плюс. У нас просто на работе недавно стояла задача по адаптирования телефонного аппа к универсал 8.1. Но с выходом sdk win 10 я убедил что это будет пустая трата времени и телефонный код потом просто выкинем и потратим время
            • 0
              Меня смутило слово «выкинуть»- это слово с не позитивной окраской, и близко по сути к слову- «потеря» в моем понимании.

              В докладе про портирование приложения для WP на Silverlight говорится — придется переписать на WinRT. По этому, если Ваше приложение не на WinRT было, то портирование на Universal 8.1 все таки смысл имеет, как промежуточный шаг. Если оно уже было на WinRT, то тут целесообразность ниже, но остается т.к. при переписывании, вы унифицируете код.

              Хотя давайте будем реалистами- win10 еще не вышла, она в preview сейчас. Пользователи тоже не мгновенно перейдут, так что полгода-год приложение для WP 8.1 вполне могло бы поработать.
              • 0
                Так а смысл переводить SL Windows Phone на Windows Phone RT, когда уже через полгода можно будет обновляться?
                Потому как при переходе на 10 потом прийдеться эту работу скорее всего выбросить.
                Я когда проводил инвестигейт нашего приложения на возможность портирования на 10. Взял проект под вин 8.1 и сконвертил на 10. Весь код с 8.1 и Shared Project заработал, но вот то что осталось в WP 8.1 реально можно просто выбросить, а заниматься адаптированием Вин 10 под телефон
                • 0
                  Почему сразу выбросить?

                  Если у вас сейчас есть Win8.1 и WP SL проекты одного и того же приложения, то скорее всего есть код, который написан дважды, но чуть-чуть по разному. Портируя WP SL на WP RT вы унифицируете код с версией для Win8.1.

                  В будущем, когда понадобится портировать на Win10 это будет сделать легче имея общий код на WinRT нежели 2 разных кода.
                  Все сведется к мержу UI. Логику скорее всего уже не придется трогать.

                  По крайней мере в моем случае оказалось именно так.
                  • 0
                    Или в будущем можно просто забыть про WP SL, а проект на Win 8.1 мигрировать на 10 и все. Естественно вью прийдется поправить
                    • 0
                      Если выкинуть WP SL, то о поддержке WP до 10 можно забыть. У вас останется только 10. Как показывает практика обновления оси распространяются не очень быстро. В результате часть пользователей окажется недовольной.

                      Поддерживать одновременно и WP RT 8.1 и WP10 легче чем WP SL и WP10. Именно поэтому надо переходить на WP RT 8.1. У вас будет больше времени для поддержания приложения как для старых пользователей, так и для новых.

                      Другой вопрос в том, почему это не было сделано год назад? Ведь очевидно было, что от SL придется отказаться. О рекомендации писать универсальные приложения ведь не только сейчас заговорили.
                      • 0
                        Год назад на конференции Build была фраза- We Respect Your investments про SL приложения. Однако, эту фразу все поняли по разному.
                      • 0
                        Почему не перешли год назад с СЛ по РТ по той же причине как вы написали выше, о переходе на 8.1 можно забыть про пользователей пока они не обновятся.
                        И сейчас такая же ситуация. Если у вас конечно 90% кода легко выносится в Shared Library конечно вам повезло, а вот если вин8 и ВП приложения были АБСОЛЮТНО разными, как же их тогда мигрировать на WP RT без боли и затрат огромного количества времени?
                        • 0
                          Я портировал свое приложение в несколько этапов. Сначала выделил все что можно в PCL сборку. Рядом появились сборки с платформа-зависимым кодом. По сути все что было в такой платформа-зависимой сборке, это реализация определенных интерфейсов. Приложение для конкретной платформы линкует как PCL сборку, так и спец. сборку для конкретной платформы.

                          Таком образом мне удалось перенести более 90-95%. Это было сделано год назад. Так как уже тогда было очевидно куда все катится. При этом я мог поддерживать как старый код, так и новый. Без боли.

                          Переход на 10 для меня сейчас означает переписать только View и реализовать несколько платформа-зависимых интерфейсов. С реализацией интерфейсов все прошло чуть более чем идеально — реализация от Win RT с заменой #if на использование ApiMetadata. Вот где действительно придется попотеть, так это с View, т.к. меняются подходы к UI.

                          В общем, мой посыл такой: «Проблемы нет. Возможность подготовиться была. Надо было ею пользоваться».

                          И еще, есть такая мысль (не моя), что переходить надо всегда и сразу. Иначе потом перейти придется, но будет больно.
            • 0
              А мне сейчас надо переносить WP SL на WinRT. С выходом десятки в поддержке получится 3 версии приложения, WP 8, WinRT 8.1, Win 10. Многовато.
              • 0
                На конфернеции #msdevtour они пока (по крайней мере в Санкт-Петербурге) не имеют права рассказывать до //build/ ничего про UAP. Однако они крайне рекомендовали уже сейчас (ага, спустя год после прошлого билда) переносить приложения на универсальную платформу WinRT 8.1, дабы проще было перенести его потом на UAP.

                С другой стороны соглашусь, поддержка трех платформ в течении полугода — года (если не больше, учитывая специфику обновления мобильной операционки) после выхода Windows 10, должна быть адом.
              • 0
                А нужен ли вам сейчас перенос с SL на RT?
                WP8, Win8.1 ближайшие полгода только саппорт, а параллельно делать версию для 10 и выпускать ее когда будет готова. Пользователи приложения обновившиеся до 10 получат новую версию на 10, те которые еще не обновились будут пользоваться старым приложением, но без новых каких-то фич.
                • 0
                  У нас 20% пользователей на WP 8, оставлять платформы без сопровождения нельзя. Но с другой стороны нужно SensorCore, хочется D2D и Band.
      • –4
        Очень любопытно, так называемые универсальные приложения когда нибудь заработают под Android и Ios?
        • 0
          Вы немного не так поняли слово «универсальные».
          • –5
            Спасибо, ваш ответ довольно исчерпывающий. Однако лично я даже не посмотрю на разработки «универсальных» приложений до тех пор, пока платформа windows phone не займет хотя бы 30% рынка или пока они не появятся на android. До этого момента, как бы круто не выглядели новые технологии, они бессмысленны.
            • +2
              А мне нравится пользоваться WP. И я хочу научиться программировать под эту платформу. Удачи мне!
            • +1
              Замкнутый круг — пока лично Вы не посмотрите на эту платформу, платформа вряд ли займет 30 процентов рынка.
              С другой стороны, разве Вы не хотите увеличить аудиторию своего приложения? Тут вам сразу предлагают увеличить аудиторию примерно на 1,5 миллиарда пользователей (Это все пользователи Win7, Win8, Win8.1, WinPhone8, WinPhone8.1, которые получат право БЕСПЛАТНО перейти на Windows 10 в течении одного года).

              И еще один момент. Есть такая штука, как Xamarin, и именно 2015 студия предлагает установить Xamarin-расширение (Да, майки сознательно пошли на сотрудничество с этими ребятами, кстати, там же еще и Apache Cordova), которое позволит не только писать приложения на C# для Android и iOS, но и писать почти «универсальные» приложения для всех платформ — Win10, Android, iOS и все в ОДНОМ проекте. Более того, эта штука позволяет писать НАТИВНЫЕ интерфейсы и вообще приложения для iOS и Android.

              В придачу со всем этим в студии есть эмулятор Андроида (для чего не нужен тот мощный сдк), а при наличии OS X, еще и запустит на оной эмулятор для iOS.
              • 0
                Еще себе отвечу.

                Есть еще Qt 5, как всем уже давно известно, на нем можно разрабатывать приложения для не только для десктопов и мака, но и для мобильных платформ. В том числе для Windows Phone 8 и Windows Runtime.

                Более того, я уверен на много процентов (пруф), что они не оставят в стороне поддержку Windows Universal Application Platform. Чем Вам не «универсальные» приложения под все платформы?!
              • –2
                Простите но ведь есть для этого инструменты, которые являются истинно кросс платформенными пример htnl5 + js + cordova. На них конечно не сделаешь, какой нибудь архиватор, но для типичных приложений самое то.

                >> Замкнутый круг — пока лично Вы

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

                >> Есть такая штука, как Xamarin

                Хамарин убогий, и тоже не кросс платформенный, используя его вам по прежнему нужно иметь разные версии кода, под разные ОС. Тогда уж лучше вспомнить о qt.

    • 0
      А вы знаете другой способ получить проверить новые знания, опыт и как результат более удобный продукт?
      Поделитесь, а то народ не в курсе. Мучают и разработчиков и пользователей…
      • 0
        Да чего там, каждый новый год по новой платформе, слабо совместимой с предыдущей, это видимо и есть «Защита инвестиций», не так ли.
        • 0
          Платформа Windows Runtime стала доступна для промышленной разработки в 2012 году. Начиная с 2011 года, уже можно было смотреть на то, как она реализована и как писать приложения для платформы.
          Ошибкой Microsoft был выпуск Windows Phone 8 без поддержки полноценной разработки Windows Runtime приложений.
          Да и про слабую совместимость Win10 с Win8.1 не согласен. Загляните в метаданные доступные в Windows 10. Большая часть классов и интерфейсов осталась на своём месте.
        • 0
          Конечно. Это защита инвестиций майкрософт в своё бизнес.
        • 0
          Ну так вы определитесь, вам «защита» или развитие.
          Вас же никто палками не загоняет.
          Вон Java хорошо «защищает инвестиции».
          И программисты вынуждены писать километры бойлерплейта из года в год.
          Не прошло и ста лет, как вышла наконец-то Java 8 которая хоть чуток поправила ситуацию.
          Тут еще посмотреть, где большее издевательство)

          А понятие «слабо совместимо» оно очень растяжимо.
          Пишите правильно приложения и тогда для вас не будет большой проблемой апгрейдить его в соответсвии с реалиями рынка.
  • +2
    Спасибо за обзор!
  • –1
    del
  • 0
    Если я правильно понимаю, бинарников может быть до трёх (по количеству платформ — x86, x64, ARM). А вот app bundle, в который заворачиваются бинарники, будет действительно один. Поправите меня?
    • 0
      Есть ещё вариант Any CPU. Да и если хорошо порыться, можно увидеть поддержку ARM64. В подтверждении моих слов можете проверить наличие папки «C:\Program Files (x86)\Windows Kits\10\bin\arm64» после установки набора разработчика. Очень надеюсь, что они добавят поддержку платформы и разработки в финальный релиз.
      Ну и судя по https://msdn.microsoft.com/library/windows/apps/dn894631.aspx можно предположить, что будет возможность делать приложения только под отдельную платформу. Допускаю, что дадут возможность делать разные бинарники под разные платформы, а затем как-то их связывать магазине(это лишь моё предположение).
  • +1
    Я не ощутил плюсов W8 как пользователь, не заработал толком ничего на 8.1 как разработчик и чего теперь должен ждать от W10? Новых фич? Кнопки Пуск? Потери совместимости с старыми фичами? А где же миллиард юзеров в маркете, почему нет рекламы от крупнейших провайдеров, в конце концов, где же носимые устройства вместо десктопов на этих ОС, кроме мертворожденных RT и десятка планшетов с Atom, слабее, чем в нетбуках?
  • 0
    Вопрос по первой картинке: а что такое Windows On Devices? Embeded что ли? Тогда не понятно, ветка эмбедет и так копилировалась одинакого десктопным операционкам, линия должна совмещаться с линией Windows 8.

    И если на XBox будет архитектура схожая с десктопом, в чём будет разница между компами и приставками? Или это как Macintosh, перехавший на х86 системы?
    • 0
      Надо бы найти эксперта по xbox…
      На сколько я помню, xbox очень сильно по железу отличалось и по архитектуре- что-то в hyper-v запускалось и еще какие-то различия в этом роде.
      Хороший доклад был на build 2014 channel9.msdn.com/Events/Build/2014/2-651 на 20- 24 минуте есть обяснение разницы в архитектуре xbox

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка