Поделиться через


Перенос Windows Phone Silverlight XAML и UI в UWP

Предыдущий раздел был посвящен устранению неполадок.

Практика определения пользовательского интерфейса в виде декларативной разметки XAML очень хорошо преобразуется из Windows Phone Silverlight в приложения универсальной платформы Windows (UWP). Вы обнаружите, что большие разделы вашей разметки совместимы после того, как вы обновите ссылки на ключи системных ресурсов, измените имена типов элементов и измените пространства имен с clr-namespace на using. Большая часть императивного кода на уровне презентации — модели представления и код, который управляет элементами пользовательского интерфейса, также будет простым для порта.

Первый взгляд на разметку XAML

В предыдущем разделе показано, как скопировать файлы XAML и кода программной части в новый проект Visual Studio для Windows 10. Одна из первых проблем, которые вы можете заметить в конструкторе XAML Visual Studio, заключается в том, что элемент PhoneApplicationPage в корне файла XAML не является допустимым для проекта универсальной платформы Windows (UWP). В предыдущем разделе вы сохранили копию ФАЙЛОВ XAML, созданных Visual Studio при создании проекта Windows 10. Если открыть эту версию MainPage.xaml, вы увидите, что в корневом каталоге находится тип page, который находится в пространстве имен Windows.UI.Xaml.Controls. Таким образом, можно изменить все элементы <phone:PhoneApplicationPage> на <Page> (не забывайте синтаксис элемента свойства) и удалить объявление xmlns:phone.

Для более общего подхода к поиску типа UWP, соответствующего типу Windows Phone Silverlight, можно ознакомиться с сопоставлениями пространств имен и классов.

Объявления префикса пространства имен XAML

Если в ваших представлениях используются экземпляры пользовательских типов (возможно, экземпляр модели представления или преобразователь значений), то в разметке XAML вы объявите префиксы пространства имен XAML. Синтаксис этих функций отличается от Windows Phone Silverlight и UWP. Ниже приведены некоторые примеры.

    xmlns:ContosoTradingCore="clr-namespace:ContosoTradingCore;assembly=ContosoTradingCore"
    xmlns:ContosoTradingLocal="clr-namespace:ContosoTradingLocal"

Измените "clr-namespace" на "using" и удалите любой маркер сборки и точку с запятой (сборка будет выводиться). Результат выглядит следующим образом:

    xmlns:ContosoTradingCore="using:ContosoTradingCore"
    xmlns:ContosoTradingLocal="using:ContosoTradingLocal"

У вас может быть ресурс, тип которого определен системой:

    xmlns:System="clr-namespace:System;assembly=mscorlib"
    /* ... */
    <System:Double x:Key="FontSizeLarge">40</System:Double>

В UWP опустите объявление префикса System и вместо этого используйте уже объявленный префикс "x":

    <x:Double x:Key="FontSizeLarge">40</x:Double>

Императивный код

Модели представления — это одно место, где есть императивный код, который ссылается на типы пользовательского интерфейса. Другим местом являются любые файлы кода за пользовательским интерфейсом, которые непосредственно управляют элементами пользовательского интерфейса. Например, можно найти, что строка кода, как это, еще не компилируется:

    return new BitmapImage(new Uri(this.CoverImagePath, UriKind.Relative));

BitmapImage находится в пространстве имен System.Windows.Media.Imaging в Windows Phone Silverlight, а директива using в том же файле позволяет использовать BitmapImage без квалификации пространства имен, как в фрагменте выше. В таком случае можно щелкнуть правой кнопкой мыши имя типа (BitmapImage) в Visual Studio и использовать команду Разрешить в контекстном меню, чтобы добавить в файл новую директиву пространства имен. В этом случае добавляется пространство имен Windows.UI.Xaml.Media.Imaging, в котором в UWP находится этот тип. Вы можете удалить system.Windows.Media.Imaging с помощью директивы, и это будет все, что нужно для переноса кода, как в приведенном выше фрагменте кода. Когда вы закончите, вы удалите все пространства имен Windows Phone Silverlight.

В таких простых случаях, когда вы сопоставляете типы в старом пространстве имен с теми же типами в новом, вы можете использовать команду Visual Studio "Поиск и замена", чтобы массово изменить исходный код. Команда Решение — это отличный способ обнаружения нового пространства имен для типа. В другом примере можно заменить все "System.Windows" на "Windows.UI.Xaml". Это будет по сути переносить все директивы using и все полные имена типов, ссылающиеся на это пространство имен.

После удаления всех старых директив using и добавления новых, вы можете использовать команду Visual Studio "Упорядочение директив using" для сортировки директив и удаления неиспользуемых.

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

Если вы просто хотите добраться до стадии, когда ваш проект собирается, вы можете закомментировать или убрать любой несущественный код. Затем повторяйте процесс, одну проблему за раз, и обратитесь к следующим разделам (и предыдущему разделу: Устранение неполадок) до тех пор, пока не будут устранены все проблемы сборки и выполнения и ваш порт не будет завершен.

Адаптивный/отзывчивый пользовательский интерфейс

Так как ваше приложение Windows 10 может работать на потенциально широком диапазоне устройств ( каждый из которых имеет собственный размер экрана и разрешение), вы хотите перейти за рамки минимальных шагов для переноса приложения, и вы хотите настроить пользовательский интерфейс, чтобы выглядеть лучше всего на этих устройствах. Функцию адаптивного диспетчера визуальных состояний можно использовать для динамического обнаружения размера окна и изменения макета в ответ, и пример того, как это сделать, показан в разделе Адаптивный пользовательский интерфейс в теме "Пример использования Bookstore2".

Оповещения и напоминания

Код, использующий классы Alarm или Reminder, следует перенести для использования класса BackgroundTaskBuilder, чтобы создать и зарегистрировать фоновую задачу и отображать всплывающее уведомление в нужное время. См. фоновой обработки и toasts.

Мультипликация

В качестве предпочтительной альтернативы анимациям ключевых кадров и анимациям "от/до", библиотека анимаций UWP доступна для приложений UWP. Эти анимации были разработаны и настроены для плавной работы, привлекательного внешнего вида и для того, чтобы ваше приложение выглядело интегрированным с Windows, так же, как и встроенные приложения. Смотрите Быстрый старт: Анимация вашего пользовательского интерфейса с помощью анимаций библиотеки.

Если вы используете в ваших приложениях UWP анимации ключевых кадров или анимации от/до, тогда вам стоит понять различие между независимыми и зависимыми анимациями, которые представила новая платформа. См. Оптимизация анимаций и мультимедиа. Анимации, которые выполняются в потоке пользовательского интерфейса (например, те, которые анимируют свойства макета), называются зависимыми анимациями, и при запуске на новой платформе они не будут влиять, если вы не сделаете одно из двух действий. Их можно перенацелить, чтобы анимировать различные свойства, например RenderTransform, тем самым делая их независимыми. Вы также можете задать EnableDependentAnimation="True" на элементе анимации, чтобы подтвердить намерение запустить анимацию, которая не может быть гарантированно выполнена гладко. Если вы используете Blend для Visual Studio для создания новых анимаций, это свойство будет задано для вас по необходимости.

Обработка кнопки "Назад"

В приложении Windows 10 можно использовать один подход к обработке кнопки "Назад", и он будет работать на всех устройствах. На мобильных устройствах кнопка предоставляется в виде сенсорной кнопки на устройстве или как кнопка в оболочке. На настольном устройстве вы добавляете кнопку к интерфейсу приложения, когда возможна навигация назад в приложении; это отображается в строке заголовка для оконных приложений или на панели задач для режима планшета (только для Windows 10). Событие кнопки "Назад" является универсальной концепцией для всех семейств устройств, и кнопки, реализованные в оборудовании или программном обеспечении, генерируют одинаковое событие BackRequested .

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

   // app.xaml.cs

    protected override void OnLaunched(LaunchActivatedEventArgs e)
    {
        [...]

        Windows.UI.Core.SystemNavigationManager.GetForCurrentView().BackRequested += App_BackRequested;
        rootFrame.Navigated += RootFrame_Navigated;
    }

    private void RootFrame_Navigated(object sender, NavigationEventArgs e)
    {
        Frame rootFrame = Window.Current.Content as Frame;

        // Note: On device families that have no title bar, setting AppViewBackButtonVisibility can safely execute 
        // but it will have no effect. Such device families provide a back button UI for you.
        if (rootFrame.CanGoBack)
        {
            Windows.UI.Core.SystemNavigationManager.GetForCurrentView().AppViewBackButtonVisibility = 
                Windows.UI.Core.AppViewBackButtonVisibility.Visible;
        }
        else
        {
            Windows.UI.Core.SystemNavigationManager.GetForCurrentView().AppViewBackButtonVisibility = 
                Windows.UI.Core.AppViewBackButtonVisibility.Collapsed;
        }
    }

    private void App_BackRequested(object sender, Windows.UI.Core.BackRequestedEventArgs e)
    {
        Frame rootFrame = Window.Current.Content as Frame;

        if (rootFrame.CanGoBack)
        {
            rootFrame.GoBack();
        }
    }

Существует также единый подход ко всем семействам устройств для программного выхода из приложения.

   Windows.UI.Xaml.Application.Current.Exit();

Привязка и скомпилированные привязки с использованием {x:Bind}

Тема привязки включает в себя:

  • Привязка элемента пользовательского интерфейса к данным (т. е. к свойствам и командам модели представления)
  • Привязка элемента пользовательского интерфейса к другому элементу пользовательского интерфейса
  • Написание модели представления, наблюдаемой (т. е. вызывает уведомления при изменении значения свойства и при изменении доступности команды)

Несмотря на то, что все эти аспекты в значительной степени всё ещё поддерживаются, существуют различия в пространствах имён. Например, System.Windows.Data.Binding сопоставляется с Windows.UI.Xaml.Data.Binding, System.ComponentModel.INotifyPropertyChanged Windows.UI.Xaml.Data. INotifyPropertyChangedи System.Collections.Specialized.INotifyPropertyChanged сопоставляется с Windows.UI.Xaml.Interop.INotifyCollectionChanged.

Панели приложений Windows Phone Silverlight и кнопки панели приложений не могут быть привязаны, как они могут быть в приложении UWP. У вас может быть императивный код, который создает панель приложения и ее кнопки, привязывает их к свойствам и локализованным строкам и обрабатывает их события. Если да, теперь у вас есть возможность перенести этот императивный код, заменив его декларативной разметкой, привязанной к свойствам и командам, и со статическими ссылками на ресурсы, что делает приложение постепенно более безопасным и более поддерживаемым. Вы можете использовать Visual Studio или Blend для Visual Studio для привязки и стиля кнопок панели приложений UWP так же, как и любой другой элемент XAML. Обратите внимание, что в приложении UWP имена типов, которые вы используете, CommandBar и AppBarButton.

Функции, связанные с привязкой приложений UWP, в настоящее время имеют следующие ограничения:

  • Нет встроенной поддержки проверки ввода данных и интерфейсов IDataErrorInfo и INotifyDataErrorInfo.
  • Класс привязки не включает расширенные свойства форматирования, которые доступны в Windows Phone Silverlight. Однако вы по-прежнему можете реализовать IValueConverter для предоставления настраиваемого форматирования.
  • Методы IValueConverter принимают языковые строки в качестве параметров вместо объектов CultureInfo.
  • Класс CollectionViewSource не обеспечивает встроенную поддержку сортировки и фильтрации, а группирование работает по-разному. Дополнительные сведения см. в разделе о привязке данных в углублённом формате и в примере привязки данных .

Хотя те же функции привязки по-прежнему поддерживаются в значительной степени, Windows 10 предлагает возможность нового и более производительного механизма привязки, называемого скомпилированных привязок, которые используют расширение разметки {x:Bind}. См. статью "Привязка данных: повышение производительности приложений с помощью новых улучшений привязки данных XAML" и пример x:Bind.

Привязка изображения к модели представления

Свойство image.Source можно привязать к любому свойству модели представления, которая имеет тип ImageSource. Ниже приведена типичная реализация такого свойства в приложении Windows Phone Silverlight:

    // this.BookCoverImagePath contains a path of the form "/Assets/CoverImages/one.png".
    return new BitmapImage(new Uri(this.CoverImagePath, UriKind.Relative));

В приложении UWP вы используете схему URI ms-appx. Чтобы вы могли сохранить остальную часть вашего кода неизменной, можно использовать другую перегрузку конструктора System.Uri, чтобы поместить схему URI ms-appx в базовый URI и присоединить остальную часть пути к нему. Типа того:

    // this.BookCoverImagePath contains a path of the form "/Assets/CoverImages/one.png".
    return new BitmapImage(new Uri(new Uri("ms-appx://"), this.CoverImagePath));

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

Элементы управления и стили и шаблоны элементов управления

Приложения Windows Phone Silverlight используют элементы управления , определенные в пространстве имен Microsoft.Phone.Controls и в пространстве имен System.Windows.Controls. Приложения XAML UWP используют элементы управления, определенные в пространстве имен Windows.UI.Xaml.Controls. Архитектура и дизайн элементов управления XAML в UWP практически совпадают с элементами управления Windows Phone Silverlight. Но некоторые изменения были внесены для улучшения набора доступных элементов управления и объединения их с приложениями Windows. Ниже приведены конкретные примеры.

Имя элемента управления Изменение
Панель приложений Свойство Page.TopAppBar.
КнопкаИконкаПанелиПриложения Эквивалент UWP — это свойство глифа. PrimaryCommands — это свойство содержимого CommandBar. Средство синтаксического анализа XAML интерпретирует внутренний XML-файл элемента как значение его свойства содержимого.
ЭлементМенюПанелиПриложения Эквивалент UWP — это когда AppBarButton.Label установлен в качестве текста пункта меню.
ContextMenu (в наборе средств Windows Phone) Для всплывающего меню с единственным выбором используйте Flyout.
Класс ControlTiltEffect.TiltEffect Анимации из библиотеки анимаций UWP встроены в стили стандартных элементов управления. См. Анимация действий указателя.
LongListSelector с группированными данными Windows Phone Silverlight LongListSelector функционирует двумя способами, которые можно использовать в сочетании. Во-первых, он может отображать данные, сгруппированные по ключу, например список имен, сгруппированных по первоначальной букве. Во-вторых, он может переключаться между двумя семантическими представлениями: сгруппированным списком элементов (например, имена) и списком только ключей группы (например, начальные буквы). С помощью UWP вы можете отобразить сгруппированные данные, следуя руководствам по элементам управления списка и представления сетки.
LongListSelector с неструктурированными данными По причинам производительности в случае длинных списков мы рекомендуем использовать LongListSelector вместо списка Windows Phone Silverlight, даже для простых данных. В приложении UWP GridView предпочтительнее для длинных списков элементов независимо от того, подходят ли данные для группировки.
Панорама Элемент управления Windows Phone Silverlight Panorama сопоставляется с рекомендациями для элементов управления хабом в приложениях для среды выполнения Windows 8.x и рекомендациями по элементу управления хабом.
Обратите внимание, что элемент управления Panorama переходит от последнего раздела к первому, а его фоновое изображение перемещается с эффектом параллакса относительно разделов. разделы центра не обтекают, а параллакс не используется.
Стержень Эквивалент управления UWP для Windows Phone Silverlight Pivot — это Windows.UI.Xaml.Controls.Pivot. Он доступен для всех семейств устройств.

Примечание визуальное состояние PointerOver относится к пользовательским стилям и шаблонам в приложениях Windows 10, но не в приложениях Silverlight для Windows Phone. Существуют и другие причины, по которым существующие пользовательские стили и шаблоны могут не соответствовать приложениям Windows 10, включая ключи системных ресурсов, которые вы используете, изменения наборов используемых визуальных состояний и улучшения производительности, внесенные в стили и шаблоны Windows 10 по умолчанию. Рекомендуется изменить новую копию шаблона элемента управления по умолчанию для Windows 10, а затем повторно применить к ней настройки стиля и шаблона.

Дополнительные сведения об элементах управления UWP см. в разделах Элементы управления по функциям, Список элементов управленияи Руководства по элементам управления.

Язык разработки в Windows 10

Существуют некоторые различия в языке дизайна между приложениями Windows Phone Silverlight и приложениями Windows 10. Дополнительные сведения см. в разделе Дизайн. Несмотря на изменения языка дизайна, наши принципы проектирования остаются неизменными: внимательно следите за деталями, но всегда стремитесь к простоте, сосредотачиваясь на содержимом, а не на визуальной оболочке, стремительно уменьшая визуальные элементы и оставаясь аутентичным в цифровой среде; используйте визуальную иерархию, особенно в типографике; проектируйте по сетке; и оживите свои проекты с помощью плавных анимаций.

Локализация и глобализация

Для локализованных строк можно повторно использовать RESX-файл из проекта Windows Phone Silverlight в проекте приложения UWP. Скопируйте файл, добавьте его в проект и переименуйте в Resources.resw, чтобы механизм подстановки мог находить его по умолчанию. Установите действие сборки на PRIResource и копирование в выходной каталог на Не копировать. Затем можно использовать строки в разметке, указав атрибут x:Uid в элементах XAML. См. Краткое руководство: Использование строковых ресурсов.

Приложения Windows Phone Silverlight используют класс CultureInfo для глобализации приложения. Приложения UWP используют MRT (современная технология ресурсов), что обеспечивает динамическую загрузку ресурсов приложения (локализации, масштабирования и темы) как во время выполнения, так и в области конструктора Visual Studio. Дополнительные сведения см. в руководстве по файлам, данным и глобализации.

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

Мультимедиа и графики

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

Windows Phone Silverlight имеет тип RadialGradientBrush, которого нет в UWP, хотя другие типы Brush присутствуют. В некоторых случаях вы сможете получить аналогичный эффект с растровым изображением. Обратите внимание, что вы можете создать радиальную градиентную кисть с помощью Direct2D в Microsoft DirectX и XAML C++ UWP.

Windows Phone Silverlight имеет свойство System.Windows.UIElement.OpacityMask, но это свойство не является членом типа UWP UIElement. В некоторых случаях вы сможете получить аналогичный эффект с растровым изображением. Кроме того, вы можете создать маску непрозрачности с помощью Direct2D в приложении Microsoft DirectX и XAML C++ UWP. Но распространенный вариант использования для OpacityMask заключается в использовании одного растрового изображения, который адаптируется как к светлым, так и темным темам. Для векторной графики можно использовать системные кисти, учитывающие тему (например, ниже показанные круговые диаграммы). Но, чтобы сделать растровое изображение с учетом темы (например, флажки, показанные ниже), требует другого подхода.

растр, учитывающий тему

В приложении Windows Phone Silverlight метод заключается в использовании альфа-маски (в виде растрового изображения) в качестве OpacityMask для прямоугольника, заполненного кистью переднего плана.

    <Rectangle Fill="{StaticResource PhoneForegroundBrush}" Width="26" Height="26">
        <Rectangle.OpacityMask>
            <ImageBrush ImageSource="/Assets/wpsl_check.png"/>
        </Rectangle.OpacityMask>
    </Rectangle>

Самый простой способ перенести это в приложение UWP — использовать BitmapIcon, как показано ниже.

    <BitmapIcon UriSource="Assets/winrt_check.png" Width="21" Height="21"/>

Вот winrt_check.png является альфа-маской в виде растрового изображения так же, как и wpsl_check.png, и это вполне может быть тот же файл. Однако может потребоваться предоставить несколько различных размеров winrt_check.png для различных факторов масштабирования. Дополнительные сведения об этом и описание изменений ширины и значения высоты см. в разделе Просмотр или действующие пиксели, расстояние просмотра и коэффициенты масштабирования в этом разделе.

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

    <Image Source="Assets/winrt_check.png" Stretch="None"/>

В Windows Phone Silverlight свойство UIElement.Clip может быть любой формой, которую можно выразить с помощью Geometry, и обычно сериализуется в разметке XAML с использованием миниязыка StreamGeometry. В UWP тип свойства клипа является rectangleGeometry, поэтому вы можете обрезать только прямоугольную область. Разрешение определения прямоугольника с помощью мини-языка было бы слишком разрешительным. Таким образом, чтобы перенести область вырезки в разметке, замените синтаксис атрибута Clip и сделайте его синтаксисом элемента свойства следующим образом:

    <UIElement.Clip>
        <RectangleGeometry Rect="10 10 50 50"/>
    </UIElement.Clip>

Обратите внимание, что вы можете использовать произвольные геометрии в качестве маски на уровне с Direct2D в приложении Microsoft DirectX и XAML C++ UWP.

При переходе на страницу в приложении Windows Phone Silverlight используется схема адресации универсального идентификатора ресурса (URI):

    NavigationService.Navigate(new Uri("/AnotherPage.xaml", UriKind.Relative)/*, navigationState*/);

В приложении UWP вызовите метод Frame.Navigate и укажите тип целевой страницы (как определено атрибутом x:Class определения разметки XAML страницы):

    // In a page:
    this.Frame.Navigate(typeof(AnotherPage)/*, parameter*/);

    // In a view model, perhaps inside an ICommand implementation:
    var rootFrame = Windows.UI.Xaml.Window.Current.Content as Windows.UI.Xaml.Controls.Frame;
    rootFrame.Navigate(typeof(AnotherPage)/*, parameter*/);

Вы определяете начальную страницу для приложения Windows Phone Silverlight в WMAppManifest.xml:

    <DefaultTask Name="_default" NavigationPage="MainPage.xaml" />

В приложении UWP используется императивный код для определения начальной страницы. Ниже приведен некоторый код из App.xaml.cs, который иллюстрирует, как:

    if (!rootFrame.Navigate(typeof(MainPage), e.Arguments))

Сопоставление URI и навигация фрагментов — это методы навигации URI, поэтому они не применимы к навигации UWP, которая не основана на URI. Сопоставление URI осуществляется в ответ на проблему слабой типизации при идентификации целевой страницы через строку URI. Это может привести к проблемам хрупкости и трудностям в поддержке, если страница перемещается в другую папку и, таким образом, к иному относительному пути. Приложения UWP используют навигацию на основе типов, которая строго типизирована и проверяется компилятором, и не имеет проблемы, которую решает сопоставление URI. Вариант использования навигации по фрагментам заключается в передаче некоторого контекста на целевую страницу, чтобы страница могла прокрутить определенный фрагмент содержимого в область видимости или была отображена другим образом. Ту же цель можно достичь, передав параметр навигации при вызове метода Navigate.

Дополнительные сведения см. в навигации .

Справочник по ключу ресурса

Язык разработки развивался для Windows 10 и, следовательно, некоторые системные стили изменились, и многие системные ключи ресурсов были удалены или переименованы. Редактор разметки XAML в Visual Studio выделяет ссылки на ключи ресурсов, которые не могут быть разрешены. Например, редактор разметки XAML будет подчеркивать ссылку на ключ стиля PhoneTextNormalStyle с красной волнистой линией. Если это не исправлено, приложение немедленно завершится при попытке развернуть его в эмуляторе или устройстве. Поэтому важно учитывать правильность разметки XAML. И вы найдете, что Visual Studio — отличный инструмент для обнаружения таких проблем.

Кроме того, см. также текстаниже.

Строка состояния (системная область)

Системная область (заданная в разметке XAML с shell:SystemTray.IsVisible) теперь называется строкой состояния и отображается по умолчанию. Вы можете управлять видимостью в императивном коде, вызвав методы Windows.UI.ViewManagement.StatusBar.ShowAsync и HideAsync.

Текст

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

стили системного текстового блокировщика для приложений windows 10

Стили System TextBlock для приложений Windows 10

В приложении Windows Phone Silverlight семейство шрифтов по умолчанию — Segoe WP. В приложении Windows 10 семейство шрифтов по умолчанию — segoe UI. В результате метрики шрифтов в приложении могут выглядеть иначе. Если вы хотите воспроизвести внешний вид текста Windows Phone Silverlight, можно задать собственные метрики с помощью таких свойств, как LineHeight и LineStackingStrategy. Для получения дополнительной информации см. руководство по шрифтам и конструированию приложений UWP .

Изменения темы

Для приложения Windows Phone Silverlight тема по умолчанию темна. Для устройств с Windows 10 тема по умолчанию изменилась, но вы можете управлять темой, используемой путем объявления запрошенной темы в App.xaml. Например, чтобы использовать темную тему на всех устройствах, добавьте RequestedTheme="Dark" в корневой элемент Application.

Плитки

Плитки для приложений UWP имеют поведение, аналогичное динамическим плиткам для приложений Windows Phone Silverlight, хотя существуют некоторые различия. Например, код, вызывающий метод Microsoft.Phone.Shell.ShellTile.Create для создания вторичных плиток, необходимо изменить так, чтобы вызов происходил через SecondaryTile.RequestCreateAsync. Приведен пример до и после, сначала версия Windows Phone Silverlight:

    var tileData = new IconicTileData()
    {
        Title = this.selectedBookSku.Title,
        WideContent1 = this.selectedBookSku.Title,
        WideContent2 = this.selectedBookSku.Author,
        SmallIconImage = this.SmallIconImageAsUri,
        IconImage = this.IconImageAsUri
    };

    ShellTile.Create(this.selectedBookSku.NavigationUri, tileData, true);

И эквивалент UWP:

    var tile = new SecondaryTile(
        this.selectedBookSku.Title.Replace(" ", string.Empty),
        this.selectedBookSku.Title,
        this.selectedBookSku.ArgumentString,
        this.IconImageAsUri,
        TileSize.Square150x150);

    await tile.RequestCreateAsync();

Код, который обновляет плитку с помощью метода Microsoft.Phone.Shell.ShellTile.Update, или класс Microsoft.Phone.Shell.ShellTileSchedule следует перенести для использования классовTileUpdateManager, TileUpdater, TileNotificationи/или ScheduledTileNotification.

Дополнительные сведения о плитках, всплывающих уведомлениях, значках, баннерах и уведомлениях см. в разделе Создание плиток и Работа с плитками, значками и всплывающими уведомлениями. Сведения о размерах визуальных ресурсов, используемых для плиток UWP, см. в разделе плитки и всплывающих визуальных ресурсов.

Тосты

Код, который отображает всплывающее уведомление с классом Microsoft.Phone.Shell.ShellToast, должен быть перенесен для использования классов ToastNotificationManager, ToastNotifier, ToastNotificationи/или ScheduledToastNotification. Обратите внимание, что на мобильных устройствах потребительский термин "toast" называется "баннер".

См. Работа с плитками, индикаторами событий и всплывающими уведомлениями.

Вид или эффективные пиксели, расстояние до экрана и коэффициенты масштабирования

Приложения Windows Phone Silverlight и приложения Windows 10 отличаются тем, как они абстрагируют размер и макет элементов пользовательского интерфейса от фактического физического размера и разрешения устройств. Для этого приложение Windows Phone Silverlight использует экранные пиксели. В Windows 10 концепция отображаемых пикселей превратилась в концепцию эффективных пикселей. Вот объяснение этого термина, то, что это означает, и дополнительное значение, которое он предлагает.

Термин "разрешение" относится к измерению плотности пикселей, а не, как обычно считается, число пикселей. "Эффективное разрешение" — это способ, при котором физические пиксели, составляющие изображение или глиф, становятся видимыми глазу с учетом различий в расстоянии просмотра и физическом размере пикселя устройства (плотность пикселей, являющаяся обратной величиной размера физического пикселя). Эффективное разрешение — это хорошая метрика для создания взаимодействия, так как она ориентирована на пользователя. Понимая все факторы и контролируя размер элементов пользовательского интерфейса, вы можете сделать взаимодействие пользователя хорошим.

Для приложения Windows Phone Silverlight все экраны телефонов рассматриваются как имеющие ширину в 480 виртуальных пикселей, без исключения, независимо от того, сколько физических пикселей на экране, какая его плотность пикселей или физический размер. Это означает, что элемент изображения с Width="48" будет составлять ровно одну десятую ширины экрана любого телефона, который может запускать приложение Windows Phone Silverlight.

В приложении Windows 10 не случае, когда все устройства имеют фиксированное количество эффективных пикселей. Это, вероятно, очевидно, учитывая широкий спектр устройств, на которых может работать приложение UWP. Разные устройства имеют различное число эффективных пикселей в ширину, начиная от 320 epx для наименьших устройств, до 1024 epx для монитора со скромным размером и много больше для более широких экранов. Все, что вам нужно сделать, — продолжать использовать автоматически масштабируемые элементы и динамические панели макета, как вы всегда это делали. Кроме того, в некоторых случаях свойства элементов пользовательского интерфейса будут иметь фиксированный размер в разметке XAML. Коэффициент масштабирования автоматически применяется к приложению в зависимости от того, на каком устройстве он работает, и параметры отображения, сделанные пользователем. И этот коэффициент масштабирования служит для того, чтобы любой элемент пользовательского интерфейса с фиксированным размером сохранял более или менее постоянный размер сенсорной и зрительной области для пользователя на различных экранах. И вместе с динамическим макетом пользовательский интерфейс не просто оптически масштабируется на разных устройствах, он будет автоматически адаптироваться, чтобы вместить соответствующий объем содержимого в доступное пространство.

Поскольку 480 ранее была фиксированной шириной в пикселях представления для экрана размера телефона, и в настоящее время это значение обычно меньше в эффективных пикселях, эмпирическое правило заключается в том, чтобы умножить любое измерение в разметке приложений Windows Phone Silverlight на коэффициент 0,8.

Чтобы приложение было лучше всего на всех дисплеях, рекомендуется создать каждый растровый ресурс в диапазоне размеров, каждый из которых подходит для определенного коэффициента масштабирования. Предоставление ресурсов в 100%-scale, 200%-scale и 400%-scale (в этом порядке приоритета) даст вам отличные результаты в большинстве случаев во всех промежуточных коэффициентах масштабирования.

Примечание Если по какой-либо причине невозможно создать ресурсы в нескольких размерах, создайте 100 ресурсов в масштабе%. В Microsoft Visual Studio шаблон проекта по умолчанию для приложений UWP предоставляет ресурсы фирменной символики (изображения плиток и логотипы) только в одном размере, но не 100%-scale. При создании ресурсов для собственного приложения следуйте инструкциям в этом разделе и предоставьте 100%, 200%и 400% размеров и используйте пакеты ресурсов.

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

Мы не рекомендуем поддерживать все факторы масштабирования, но полный список факторов масштабирования для приложений Windows 10 — 100%, 125%, 150%, 200%, 250%, 300%и 400%. Если вы предоставите их, Магазин выберет ресурсы правильного размера для каждого устройства, и загрузятся только они. Магазин выбирает ресурсы для скачивания на основе DPI устройства.

Дополнительные сведения см. в разделе Адаптивный дизайн 101 для приложений UWP.

Размер окна

В приложении UWP можно указать минимальный размер (ширину и высоту) с помощью императивного кода. Минимальный размер по умолчанию составляет 500x320epx, и это также самый маленький минимальный размер, принятый. Максимальный минимальный размер, принятый, составляет 500x500epx.

   Windows.UI.ViewManagement.ApplicationView.GetForCurrentView().SetPreferredMinSize
        (new Size { Width = 500, Height = 500 });

Следующая тема: Портирование для ввода-вывода, устройства и модели приложений.