Перенос WINDOWS Phone Silverlight XAML и пользовательского интерфейса в 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, вы увидите, что в корне находится страница типа, которая находится в пространстве имен 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, чтобы внести массовые изменения в исходный код. Команда Resolve — отличный способ обнаружения нового пространства имен типа. В другом примере можно заменить все "System.Windows" на "Windows.UI.Xaml". Это будет по сути переносить все директивы using и все полные имена типов, ссылающиеся на это пространство имен.

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

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

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

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

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

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

Код с помощью классов "Тревога " или "Напоминания " должен быть перенесен для использования класса 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 отсутствует.
• Класс Binding не включает расширенные свойства форматирования, доступные в 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. Ниже приведены конкретные примеры.

Обратите внимание , что визуальное состояние 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, хотя и другие типы кистей. В некоторых случаях вы сможете получить аналогичный эффект с растровым изображением. Обратите внимание, что можно создать радиальную градиентную кисть с помощью 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 может быть любой фигурой, которую можно выразить с помощью геометрии и обычно сериализуется в разметке XAML в мини-языке StreamGeometry . В UWP тип свойства Clip — 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 в них.

Стили 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.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 пикселей, без исключения, независимо от того, сколько физических пикселей экран имеет, ни то, что его плотность пикселей или физический размер. Это означает, что элемент Image с 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%-масштабируются. При создании ресурсов для собственного приложения следуйте инструкциям в этом разделе и предоставьте 100%, 200 %, а также 400 % размеров и используйте пакеты ресурсов.

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

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

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

Размер окна

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

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

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

См. также

• Сопоставления пространства имен и классов