Статьи

Физические игры: многоцелевой Windows 8 + Windows Phone 7

Март 17, 2019
С тех пор, как Windows 8 и ее интерфейс Metro были открыты, разработчики задавались вопросом, насколько просто или сложно будет точно перенести ранее разработанное приложение Windows Phone на Windows 8. Это руководство, созданное посвящено переносу некоторых 2D-приложений для физики на предварительная бета-версия Windows 8 должна дать вам хорошее представление о том, чего вам стоит ожидать. 

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: ЭТОТ БЛОГ ПОСТ ОБСУЖДАЕТ РАЗРАБОТКУ ПОД ПРЕДВАРИТЕЛЬНОЙ ВЕРСИЕЙ WINDOWS 8! Вещи могут и будут меняться в будущем.

 

Одна, казалось бы, простая цель, которую я поставил перед собой, — перенести мои приложения для 2D-физики, работающие на Windows Phone 7 и Silverlight, на Windows 8. Поскольку во многих моих играх используется векторная графика, они могут чисто масштабироваться в зависимости от устройства, на котором были развернуты.

 

Проект Physics Helper XAML, который теперь поддерживает разработку как для Windows 8 Metro, так и для Windows Phone 7 с использованием единого набора файлов и логики разработки XAML.

 

[ГЛАВНАЯ
] [
СКАЧАТЬ
] [
ДОКУМЕНТАЦИЯ
]

 

Многоцелевой WP7 + Windows 8 Metro

 

Вы бы подумали, что это будет просто, верно? Я имею в виду, что обе платформы являются свойствами одной компании, и вы используете Visual Studio для создания приложений для них обеих. И когда был выпущен WP7, это был простой способ портировать веб-приложения Silverlight на телефон — в некоторых случаях вам даже не нужно было перекомпилировать свои сборки!

 

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

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

 

  • Для ссылки на внешнюю библиотеку в XAML нам нужно использовать атрибут xmlns . WP7 и Win8 / Metro обрабатывают это по-разному прямо сейчас (надеюсь, это будет исправлено в будущем!)

    WP7 и Silverlight выглядят так:
    xmlns: xx = «clr-namespace: xx»

    В то время как Win8 / Metro выглядит следующим образом:
    это было проблемой в моих приложениях, потому что я хотел сохранить один набор ресурсов для обеих платформ. Мое решение состояло в том, чтобы создать утилиту с именем CleanUsingXmlns, которую можно добавить на шаг предварительной сборки ваших проектов для изменения. Обратите внимание, что CleanUsingXmlns был собран очень быстро и не является самым элегантным решением, но он выполняет свою работу.

    Чтобы использовать CleanUsingXmlns, перейдите на вкладку «События сборки» и добавьте вызов утилите в формате:

 

CleanUsingXmlns [addusing|removeusing] [folder] [namespace1,namespace2]

… где [addusing] добавит предложение using для Metro, а [removeusing] добавит синтаксис пространства имен clr для WP7 и Silverlight. [папка] — это каталог, содержащий файлы XAML, которые вы хотите добавить, а [namespaceX] — это список пространств имен, которые вы хотите использовать для замены.

Например, демонстрационные проекты Metro содержат следующие этапы предварительной сборки, чтобы добавить предложение «using» в файлы XAML:

 

 

$(ProjectDir)..\..\CleanUsingXmlns\bin\Debug\CleanUsingXmlns addusing 
$(ProjectDir) Demo.Advanced,Spritehand

  • Изменения в пространстве имен
    Иногда вам интересно, пытаются ли архитекторы Microsoft просто нажимать на ваши кнопки, понимаете, о чем я? Возьмем, к примеру, перетасовку всех пространств имен Silverlight, которые мы знаем и любим. Это заставляет нас писать код, подобный следующему, когда мы пытаемся многоцелевой:

 

#if METRO
    using System.Threading.Tasks;
    using Windows.Foundation;
    using Windows.UI.Xaml;
    using Windows.UI.Xaml.Controls;
    using Windows.UI.Xaml.Input;
    using Windows.UI.Xaml.Media;
    using Windows.UI.Xaml.Media.Animation;
    using Windows.UI.Xaml.Shapes;
#else    
    using System.Windows;
    using System.Windows.Controls;
    using System.Windows.Documents;
    using System.Windows.Ink;
    using System.Windows.Input;
    using System.Windows.Media;
    using System.Windows.Media.Animation;
    using System.Windows.Media.Imaging;
#endif

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

Что подводит меня к моей последней ноте:


  • Если вы оказываетесь похожим на меня, пытаясь создать проект, нацеленный как на Win8 / Metro, так и на Windows Phone / Silverlight, одной из важных стратегий является нацеливание на самый низкий общий профиль.     В этом случае этот самый низкий профиль — Метро. Таким образом, у вас гораздо меньше шансов внедрить неподдерживаемые API в ваш код.

    Эта таблица из конференции BUILD дает хороший обзор размера трех профилей .NET: <

Вывод

Хотя это и не так просто, как вы могли бы ожидать, безусловно, можно создавать приложения с одним набором файлов дизайна и кода, которые предназначены для нескольких целей WP7 и Win8 / Metro. Помните, что это предварительная бета-версия Windows 8, и, возможно, эта история улучшится в бета-версии.

Если вы заинтересованы в создании собственных 2D-приложений для физики для WP7 и Win8 / Metro, посмотрите XAML-проект Physics Helper на codeplex.

Источник: http://www.andybeaulieu.com/Home/tabid/67/EntryID/222/Default.aspx

34
Share: