it-swarm.com.ru

Как Windows 8 Runtime (WinRT / приложения Магазина Windows / универсальное приложение Windows 10) сравнивается с Silverlight и WPF?

Я пытаюсь осмыслить новую среду выполнения Windows 8, которая используется для создания приложений в стиле Metro . Я знаю, что вы можете использовать его с XAML , и он основан на .NET, поэтому C # и VB.NET можно использовать для написания приложений, но тогда, похоже, что-то связано с HTML, CSS, DOM и JavaScript.

Может ли кто-нибудь объяснить, что это такое, в нескольких абзацах, в терминах, понятных программисту .NET UI? (Я упускаю что-то "ключевое", что необходимо, чтобы понять это.)


Мы все знаем, что WPF, Silverlight , Windows Forms и т.д. Будут работать под Windows 8 (и Windows 10), по крайней мере, в системах Intel, поэтому, пожалуйста, не Скажи мне, что...

350
Ian Ringrose

На самом низком уровне WinRT является объектной моделью, определенной на уровне ABI. Он использует COM в качестве базы (поэтому каждый объект WinRT реализует IUnknown и выполняет пересчет) и строит оттуда. Он добавляет довольно много новых концепций по сравнению с COM старых, большинство из которых приходят непосредственно из .NET - например, объектная модель WinRT имеет делегатов, а события выполняются в .NET-стиле (с делегатами и добавлением/удалением подписчика). методы, по одному на событие), а не старая COM-модель источников и приемников событий. Из других примечательных вещей WinRT также имеет параметризованные ("универсальные") интерфейсы.

Еще одно большое изменение заключается в том, что для всех компонентов WinRT доступны метаданные, как и для сборок .NET. В COM у вас вроде это было с typelibs, но не у каждого компонента COM они были. Для WinRT метаданные содержатся в файлах .winmd - загляните внутрь "C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata \" в Developer Preview. Если вы поэкспериментируете, то увидите, что это на самом деле сборки CLI без кода, а только таблицы метаданных. Вы можете открыть их с ILDASM, на самом деле. Обратите внимание, это не означает, что WinRT управляется сам - он просто повторно использует формат файла.

Затем существует ряд библиотек, реализованных в рамках этой объектной модели - определение интерфейсов и классов WinRT. Снова, посмотрите на папку Windows Metadata, упомянутую выше, чтобы увидеть, что там; или просто запустите Object Browser в VS и выберите "Windows 8.0" в средстве выбора фреймворка, чтобы увидеть, что описано. Там много всего, и это касается не только пользовательского интерфейса - вы также получаете пространства имен, такие как Windows.Data.Json, или Windows.Graphics.Printing, или Windows.Networking.Sockets.

Затем вы получаете несколько библиотек, которые конкретно работают с пользовательским интерфейсом - в основном это будут различные пространства имен под Windows.UI или Windows.UI.Xaml. Многие из них очень похожи на пространства имен WPF/Silverlight - например, Windows.UI.Xaml.Controls близко соответствует System.Windows.Controls; то же самое для Windows.UI.Xaml.Documents и т. д.

Теперь .NET имеет возможность напрямую ссылаться на компоненты WinRT, как если бы они были сборками .NET. Это работает не так, как COM Interop - вам не нужны промежуточные артефакты, такие как сборки взаимодействия, вы просто /r .winmd-файл, и все типы и их члены в его метаданных становятся видимыми для вас, как если бы они были объектами .NET. Обратите внимание, что библиотеки WinRT сами по себе являются полностью нативными (и поэтому нативным программам на C++, использующим WinRT, вообще не требуется CLR) - волшебство, позволяющее выставить все эти вещи как управляемые, находится внутри самой CLR и является довольно низким уровнем. Если вы ildasm .NET-программы, которая ссылается на .winmd, вы увидите, что на самом деле она выглядит как внешняя ссылка на сборку - здесь нет хитрости в ручном обмане, таком как встраивание типов.

Это также не тупое отображение - CLR пытается адаптировать типы WinRT к их эквивалентам, где это возможно. Так, например GUID, даты и URI становятся System.Guid, System.DateTime и System.Uri соответственно; Интерфейсы коллекции WinRT, такие как IIterable<T> и IVector<T>, становятся IEnumerable<T> и IList<T>; и так далее. Это происходит в обоих направлениях - если у вас есть объект .NET, который реализует IEnumerable<T>, и передаете его обратно в WinRT, он будет выглядеть как IIterable<T>.

В конечном итоге это означает, что ваши приложения .NET Metro получают доступ к подмножеству существующих стандартных библиотек .NET, а также (родным) библиотекам WinRT, некоторые из которых, в частности Windows.UI, очень похожи на Silverlight с точки зрения API. , У вас все еще есть XAML для определения вашего пользовательского интерфейса, и вы все еще работаете с теми же базовыми понятиями, что и в Silverlight - привязки данных, ресурсы, стили, шаблоны и т.д. Во многих случаях можно портировать приложение Silverlight просто с помощью using новых пространств имен и несколько мест в коде, где был скорректирован API.

Сам WinRT не имеет ничего общего с HTML и CSS, и он имеет отношение к JavaScript только в том смысле, что он также там представлен, подобно тому, как это делается для .NET. Вам не нужно иметь дело с HTML/CSS/JS, когда вы используете библиотеки WinRT UI в своем приложении .NET Metro (ну, я думаю, если вы действительно этого хотите, вы можете разместить элемент управления WebView ...). Все ваши навыки .NET и Silverlight остаются очень важными в этой модели программирования.

476
Pavel Minaev

Из ключевой заметки Build :

Keynote stack

Они предоставляют общие API как для приложений HTML/CSS/JavaScript, так и для приложений C #/XAML. Будут использоваться C # и XAML, но это не будет точно WPF или Silverlight.

65
RandomEngy

Ключевая идея заключается в том, что сейчас есть два пути разработки - Desktop и Metro.

  • На рабочем столе живут старые приложения.
  • Новый класс приложений, Metro-приложения, может быть создан несколькими способами, в том числе с помощью VB.NET, C # или C++. Эти три языковых опции могут использовать XAML для создания пользовательского интерфейса. Альтернативой является использование JavaScript/HTML5/CSS для разработки как пользовательского интерфейса, так и кода приложения.

Некоторые важные моменты:

  • Windows 8 выглядит как расширенная ОС для мобильных телефонов.
  • В Metro нет перекрывающихся окон верхнего уровня, как и на мобильном телефоне. Если вам нужно приложение в стиле MDI, вам нужно оставаться на рабочем столе.
  • Приложения в стиле Metro автоматически приостанавливаются, когда их не видно. Это было сделано для продления срока службы батареи. Это означает, что для многих существующих настольных приложений, которые выполняют фоновую обработку, даже если пользователь не взаимодействует с ними, перенос в Metro невозможен.
  • ARM версия Windows 8 не будет поддерживать настольные приложения. Так что, если вы хотите написать приложение и хотите, чтобы оно работало на любой версии Windows, тогда это должно быть приложение Metro.
36
dodgy_coder

Есть модифицированная версия архитектуры, которая, несомненно, поможет вам понять, где именно находятся вещи. Один из ниндзя Telerik поболтал с командой CLR и изменил картинку:

Windows 8 Platform and Tools (including the CLR)

Здесь вы можете увидеть, где стоит CLR. .NET Framework теперь имеет два профиля

1- .NET Metro профиль (CLR, который имеет дело с приложением Metro)

2- Профиль клиента .NET (среда выполнения CLR для приложений на C # и VB.NET)

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

23
vendettamit

Много подробностей от Microsoft здесь .

Среда выполнения Windows предоставляется с использованием метаданных API (файлы .winmd). Это тот же формат, который используется в .NET Framework (Ecma-335). Базовый бинарный контракт упрощает доступ к API среды выполнения Windows непосредственно на выбранном вами языке разработки. Форма и структура API среды выполнения Windows могут быть понятны как статическим языкам, таким как C #, так и динамическим языкам, таким как JavaScript. IntelliSense доступен в JavaScript, C #, Visual Basic и C++.

Короче говоря, Windows Runtime - это новый набор библиотек, представляющих функциональность Windows и доступных для JavaScript/C #/VB/C++. Каждый язык был сделан, чтобы понимать и иметь возможность называть их напрямую, вместо того, чтобы проходить через какой-то громоподобный слой.

Silverlight и WPF - это разновидности XAML, которые работают на CLR. Помимо других функций, среда выполнения Windows предоставляет версию XAML, очень похожую на Silverlight, но делает это естественным образом, а не через CLR. Доступ к нему можно получить как из CLR, так и из C++.

16
Steve Rowe