Windows Phone Silverlight XAML と UI を UWP に移植する

前のトピックは、トラブルシューティングでした。

宣言型 XAML マークアップの形式で UI を定義する方法は、Windows Phone Silverlight からユニバーサル Windows プラットフォーム (UWP) アプリに非常によく変換されます。 システム リソース キー参照を更新し、要素の型名を変更し、"clr-namespace" を "using" に変更すると、マークアップの大きなセクションに互換性があることがわかります。 プレゼンテーション レイヤーの命令型コード (ビュー モデル、UI 要素を操作するコード) の多くは、移植も簡単です。

XAML マークアップの最初の外観

前のトピックでは、XAML ファイルと分離コード ファイルを新しい Windows 10 Visual Studio プロジェクトにコピーする方法について説明しました。 Visual Studio XAML デザイナーで強調表示されている最初の問題の 1 つは、XAML ファイルのルートにある PhoneApplicationPage 要素がユニバーサル Windows プラットフォーム (UWP) プロジェクトに対して有効でないことです。 前のトピックでは、Windows 10 プロジェクトの作成時に Visual Studio によって生成された XAML ファイルのコピーを保存しました。 そのバージョンの MainPage.xaml を開くと、ルートにあるのが 型のページであり、これは Windows.UI.Xaml.Controls 名前空間に含まれています。 そのため、すべての <phone:PhoneApplicationPage> 要素を <Page> に変更し (プロパティ要素の構文を忘れないでください)、xmlns:phone 宣言を削除できます。

Windows Phone Silverlight 型に対応する UWP の種類を見つけるためのより一般的なアプローチについては、「名前空間とクラスマッピング参照してください。

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>

命令型コード

ビュー モデルは、UI 型を参照する命令型コードがある 1 つの場所です。 別の場所としては、UI 要素を直接操作するコードビハインド ファイルがあります。 たとえば、次のようなコード行がまだコンパイルされていない場合があります。

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

BitmapImage は Windows Phone Silverlight の System.Windows.Media.Imaging 名前空間にあり、同じファイルの using ディレクティブを 使用すると、上記のスニペットのように、名前空間の修飾なしで BitmapImage を使用できます。 このような場合は、Visual Studio で型名 (BitmapImage) を右クリックし、コンテキスト メニューの Resolve コマンドを使用して、新しい名前空間ディレクティブをファイルに追加できます。 この場合、Windows.UI.Xaml.Media.Imaging 名前空間が追加されます。これは、型が UWP 内に存在する場所です。 System.Windows.Media.Imaging using ディレクティブを削除することで、上記のスニペットのようなコードを移植するために必要なことはすべて完了します。 完了すると、すべての Windows Phone Silverlight 名前空間が削除されます。

このような単純なケースでは、古い名前空間の型を新しい名前空間の同じ型にマッピングする場合は、Visual Studio の Find and Replace コマンドを使用してソース コードを一括変更できます。 Resolve コマンドは、型の新しい名前空間を検出する優れた方法です。 別の例として、すべての "System.Windows" を "Windows.UI.Xaml" に置き換えることができます。 これは、本質的にその名前空間を参照するすべての using ディレクティブと完全修飾型名を転送します。

すべての古い using ディレクティブが削除され、新しいディレクティブが追加されたら、Visual Studio の Organize Usings コマンドを使用して、ディレクティブを並べ替え、未使用のディレクティブを削除できます。

場合によっては、命令型コードの修正は、パラメーターの型を変更するのと同じくらい軽微な場合があります。 それ以外の場合は、Windows ランタイム 8.x アプリ用の .NET API の代わりに Windows ランタイム API を使用する必要があります。 サポートされている API を特定するには、この移植ガイドの残りの部分を、.NET for Windows Runtime 8.x アプリの概要 と Windows ランタイム リファレンスと組み合わせて使用します。

また、プロジェクトがビルドされるステージに進むだけの場合は、重要でないコードをコメントまたはスタブアウトできます。 次に、一度に 1 つの問題を繰り返し、ビルドとランタイムの問題が解決され、ポートが完了するまで、このセクション (および前のトピック: トラブルシューティング) の次のトピックを参照してください。

アダプティブ/レスポンシブ UI

Windows 10 アプリは、さまざまなデバイス (それぞれ独自の画面サイズと解像度を持つ) で実行できるため、アプリを移植するための最小限の手順を超えたい場合は、それらのデバイスで最適に表示されるように UI を調整する必要があります。 アダプティブ Visual State Manager 機能を使用すると、ウィンドウ サイズを動的に検出し、それに応じてレイアウトを変更できます。その方法の例については、「Bookstore2 ケース スタディ」の「アダプティブ UI 」セクションを参照してください。

アラームとリマインダー

Alarm または Reminder クラスを使用するコードは、バックグラウンド タスクを作成して登録し、関連する時刻にトーストを表示するために、BackgroundTaskBuilder クラスを使用するように移植する必要があります。 「バックグラウンド処理」 および「トースト」を参照してください。

アニメーション

キーフレーム アニメーションや from/to アニメーションの推奨される代替手段として、UWP アニメーション ライブラリは UWP アプリで使用できます。 これらのアニメーションは、スムーズに実行し、見栄えよく、組み込みのアプリと同様に Windows と統合されたようにアプリを表示するように設計および調整されています。 「クイック スタート: ライブラリ アニメーションを使用して UI をアニメーション化する」参照してください。

UWP アプリでキーフレーム アニメーションを使用する場合、またはアニメーションとの間でアニメーションを使用する場合は、新しいプラットフォームで導入された独立したアニメーションと依存するアニメーションの違いを理解することをお勧めします。 「アニメーションとメディアを最適化する」を参照してください。 UI スレッドで実行されるアニメーション (レイアウト プロパティをアニメーション化するアニメーションなど) は依存アニメーションと呼ばれ、新しいプラットフォームで実行する場合、2 つのいずれかを実行しない限り効果はありません。 RenderTransformなど、さまざまなプロパティをアニメーション化するように再ターゲットを設定して、独立させることができます。 または、アニメーション要素に EnableDependentAnimation="True" を設定して、スムーズに実行されることを保証できないアニメーションを実行する意図を確認することもできます。 Blend for Visual Studio を使用して新しいアニメーションを作成する場合、そのプロパティは必要に応じて設定されます。

戻るボタンの処理

Windows 10 アプリでは、1 つの方法で戻るボタンを処理でき、すべてのデバイスで動作します。 モバイルデバイスでは、ボタンはデバイスのタッチセンサーのボタンとして、またはシェル内のボタンとして提供されます。 デスクトップ デバイスでは、アプリ内でバック ナビゲーションが可能な場合は常にアプリのクロムにボタンを追加します。これは、ウィンドウ化されたアプリのタイトル バーまたは タブレット モード (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();
        }
    }

また、プログラムによってアプリを終了するための、すべてのデバイス ファミリに対する 1 つのアプローチもあります。

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

{x:Bind} を使用したバインドとコンパイル済みバインド

バインドのトピックには、次のものが含まれます。

• UI 要素を "data" にバインドする (つまり、ビュー モデルのプロパティとコマンドに)
• UI 要素を別の UI 要素にバインドする
• 監視可能なビュー モデルを記述する (つまり、プロパティ値が変更されたとき、およびコマンドの可用性が変更されたときに通知を生成します)

これらの側面の大部分は引き続きサポートされていますが、名前空間の違いがあります。 たとえば、System.Windows.Data.Binding は Windows.UI.Xaml.Data.Bindingにマップされ、System.ComponentModel.INotifyPropertyChanged は Windows.UI.Xaml.Data.INotifyPropertyChangedにマップされ、および System.Collections.Specialized.INotifyCollectionChanged は Windows.UI.Xaml.Interop.INotifyCollectionChangedにマップされます。

Windows Phone Silverlight アプリ バーとアプリ バー ボタンは、UWP アプリのようにバインドできません。 アプリ バーとそのボタンを構築し、プロパティとローカライズされた文字列にバインドし、それらのイベントを処理する命令型コードがある場合があります。 その場合は、命令型コードをプロパティとコマンドにバインドされた宣言型マークアップに置き換え、静的リソース参照に置き換えることで、アプリの安全性と保守性を向上させるオプションが追加されました。 Visual Studio または Blend for Visual Studio を使用すると、他の XAML 要素と同様に、UWP アプリ バー ボタンをバインドしてスタイルを設定できます。 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 アプリでは、ms-appx URI スキーム使用します。 コードの残りの部分を同じ状態に保つために、System.Uri コンストラクターの別のオーバーロードを使用して、ms-appx URI スキームをベース 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 名前空間で定義されたコントロールを使用します。 UWP の XAML コントロールのアーキテクチャと設計は、Windows Phone Silverlight コントロールとほぼ同じです。 ただし、使用可能なコントロールのセットを改善し、Windows アプリと統合するために、いくつかの変更が行われています。 具体的な例を次に示します。

注 PointerOver の表示状態は、Windows 10 アプリのカスタム スタイル/テンプレートには関係しますが、Windows Phone Silverlight アプリでは関連しません。 使用しているシステム リソース キー、使用されている一式の表示状態の変更、Windows 10 の既定のスタイル/テンプレートに対するパフォーマンスの向上など、既存のカスタム スタイル/テンプレートが Windows 10 アプリに適さない理由は他にもあります。 Windows 10 用のコントロールの既定のテンプレートの新しいコピーを編集してから、スタイルとテンプレートのカスタマイズを再適用することをお勧めします。

UWP コントロールの詳細については、「Controls by function」、「Controls list」、「Guidelines for controls」を参照してください。

Windows 10 のデザイン言語

Windows Phone Silverlight アプリと Windows 10 アプリでは、設計言語にいくつかの違いがあります。 詳細については、「デザイン参照してください。 デザイン言語の変更にもかかわらず、私たちの設計原則は一貫しています:細部に注意を向けますが、常にクロムではなくコンテンツに焦点を当て、視覚的要素を激しく減らし、デジタルドメインに対して本物のままで、シンプルに努めます。特に文字体裁で視覚的階層を使用する。グリッド上のデザイン。そして流動的なアニメーションであなたの経験を生き生きとさせる。

ローカリゼーションとグローバリゼーション

ローカライズされた文字列の場合は、UWP アプリ プロジェクトで Windows Phone Silverlight プロジェクトの .resx ファイルを再利用できます。 ファイルをコピーしてプロジェクトに追加し、Resources.resw に名前を変更して、検索メカニズムが既定で見つけられるようにします。 ビルド アクション PRIResource を し、[出力ディレクトリにコピー] [をコピーしない] に設定します。 その後、XAML 要素で x:Uid 属性を指定することで、マークアップで文字列を使用できます。 「クイック スタート: 文字列リソースの使用」を参照してください。

Windows Phone Silverlight アプリでは、CultureInfo クラスを使用して、アプリのグローバル化に役立ちます。 UWP アプリは MRT (モダン リソース テクノロジ) を使用します。これにより、実行時と Visual Studio デザイン サーフェイスの両方で、アプリ リソース (ローカライズ、スケール、テーマ) の動的な読み込みが可能になります。 詳細については、「ファイル、データ、グローバリゼーションに関するガイドライン を参照してください。」と言っています。

ResourceContext.QualifierValues トピックでは、デバイス ファミリリソースの選択係数に基づいてデバイス ファミリ固有のリソースを読み込む方法について説明します。

メディアとグラフィックス

UWP メディアとグラフィックスについて読む際には、Windows の設計原則によって、グラフィックの複雑さや乱雑さなど、余分なものの激しい削減が促進されることを念頭に置きます。 Windows のデザインは、クリーンで明確なビジュアル、文字体裁、モーションに代表されます。 アプリが同じ原則に従っている場合は、組み込みのアプリのように見えます。

Windows Phone Silverlight には、UWP には存在しない RadialGradientBrush 型がありますが、他の ブラシ 型は存在します。 場合によっては、ビットマップで同様の効果を得ることができます。 Microsoft DirectX および XAML C++ UWP では、Direct2D を使用して放射状グラデーション ブラシ を作成 。

Windows Phone Silverlight には System.Windows.UIElement.OpacityMask プロパティがありますが、そのプロパティは UWP UIElement 型のメンバーではありません。 場合によっては、ビットマップで同様の効果を得ることができます。 また、Microsoft DirectX および XAML C++ UWP アプリで、Direct2D で不透明度マスク を作成 。 ただし、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 のサイズを複数指定することもできます。 その詳細と、幅の変更 および 高さの変更 については、このトピック内にある 表示、有効ピクセル、表示距離、および倍率 を参照してください。

ビットマップの明るいテーマ形式と濃色テーマの形式に違いがある場合に適したより一般的なアプローチは、2 つのイメージ アセットを使用することです。1 つはダーク フォアグラウンド (ライト テーマの場合) と明るい前景 (ダーク テーマの場合) です。 このビットマップ アセットのセットに名前を付ける方法の詳細については、「言語、スケール、およびその他の修飾子のに合わせてリソースを調整する」を参照してください。 イメージ ファイルのセットに正しい名前が付けられたら、次のようにルート名を使用して抽象ファイルを参照できます。

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

Windows Phone Silverlight では、UIElement.Clip プロパティは、Geometry で表現できる任意の図形にすることができ、通常は、StreamGeometry ミニ言語の XAML マークアップでシリアル化されます。 UWP では、Clip プロパティの型は RectangleGeometryであるため、四角形領域のみをクリップできます。 ミニ言語を使用して四角形を定義できるようにすると、制限が大きすぎます。 そのため、マークアップにクリッピング領域を移植するには、Clip 属性構文を置き換え、次のようなプロパティ要素構文にします。

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

注意してください。Microsoft DirectX および XAML C++ UWP アプリでは、任意のジオメトリを レイヤーのマスクとして Direct2Dで使用できます。

ナビゲーション

Windows Phone Silverlight アプリのページに移動するときは、Uri (Uniform Resource Identifier) アドレス指定スキームを使用します。

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

UWP アプリでは、Frame.Navigate メソッドを呼び出し、コピー先ページの型を指定します (ページの XAML マークアップ定義の x:Class 属性によって定義されます)。

    // 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 ナビゲーション手法であるため、URI に基づいていない UWP ナビゲーションには適用されません。 URI マッピングは、URI 文字列を使用してターゲット ページを識別する、弱く型指定された性質に対応して存在します。これにより、ページが別のフォルダーに移動し、別の相対パスに移動すると、脆弱性と保守性の問題が発生します。 UWP アプリでは、型ベースのナビゲーションが使用されます。これは厳密に型指定され、コンパイラによってチェックされ、URI マッピングで解決される問題はありません。 フラグメント ナビゲーションのユース ケースは、特定のコンテキストをターゲット ページに渡して、ページがコンテンツの特定のフラグメントをスクロールして表示したり、表示したりできるようにするためです。 Navigate メソッドを呼び出すときにナビゲーション パラメーターを渡すことで、同じ目標を達成できます。

詳細については、「ナビゲーション」を参照してください。

リソース キーリファレンス

デザイン言語は Windows 10 向けに進化し、その結果、特定のシステム スタイルが変更され、多くのシステム リソース キーが削除または名前変更されました。 Visual Studio の XAML マークアップ エディターでは、解決できないリソース キーへの参照が強調表示されます。 たとえば、XAML マークアップ エディターは、赤い波線で PhoneTextNormalStyle スタイル キーへの参照に下線を引きます。 これが修正されない場合、エミュレーターまたはデバイスにデプロイしようとすると、アプリはすぐに終了します。 そのため、XAML マークアップの正確性に対応することが重要です。 Visual Studio は、このような問題をキャッチするための優れたツールであることがわかります。

また、以下 テキストを参照してください。

ステータス バー (システム トレイ)

システム トレイ (shell:SystemTray.IsVisibleを持つ XAML マークアップで設定) がステータス バーと呼ばれるようになり、既定で表示されるようになりました。 命令型コードでその可視性を制御するには、Windows.UI.ViewManagement.StatusBar.ShowAsync メソッドと HideAsync メソッドを呼び出します。

テキスト

テキスト (または文字体裁) は UWP アプリの重要な側面であり、移植中に、ビューの視覚的なデザインを見直して、新しいデザイン言語と調和するようにすることができます。 次の図を使用して、使用可能な UWP TextBlock システム スタイルを見つけます。 使用した Windows Phone Silverlight スタイルに対応するものを見つけます。 または、独自のユニバーサル スタイルを作成し、Windows Phone Silverlight システム スタイルのプロパティをそれらのスタイルにコピーすることもできます。

Windows 10 アプリ用システムテキストブロックスタイル

Windows Phone Silverlight アプリでは、既定のフォント ファミリは Segoe WP です。 Windows 10 アプリでは、既定のフォント ファミリは Segoe UI です。 その結果、アプリのフォント メトリックが異なる場合があります。 Windows Phone Silverlight テキストの外観を再現する場合は、LineHeight や LineStackingStrategyなどのプロパティを使用して独自のメトリックを設定できます。 詳細については、「フォントのガイドライン」および「UWP アプリのデザイン」を参照してください。

テーマの変更

Windows Phone Silverlight アプリの場合、既定のテーマは既定では濃色です。 Windows 10 デバイスの場合、既定のテーマは変更されましたが、App.xaml で要求されたテーマを宣言することで使用されるテーマを制御できます。 たとえば、すべてのデバイスでダーク テーマを使用するには、ルート Application 要素に RequestedTheme="Dark" を追加します。

タイル

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 アプリは、UI 要素のサイズとレイアウトを実際の物理サイズやデバイスの解像度から抽象化する方法が異なります。 Windows Phone Silverlight アプリでは、ビュー ピクセルを使用してこれを行います。 Windows 10 では、ビュー ピクセルの概念が有効ピクセルの概念に絞り込まれます。 その用語の説明、意味、および提供される追加の価値を次に示します。

「解像度」という用語は、一般的に考えられているように、ピクセル数ではなく、ピクセル密度の尺度を指します。 "有効解像度" とは、画像やグリフを構成する物理ピクセルが、視認距離とデバイスの物理ピクセルサイズ（物理ピクセルサイズの逆数であるピクセル密度）に応じてどのように目に映るかを指します。 効果的な解決は、ユーザー中心であるため、エクスペリエンスを構築するのに適したメトリックです。 すべての要素を理解し、UI 要素のサイズを制御することで、ユーザーのエクスペリエンスを適切なものにすることができます。

Windows Phone Silverlight アプリでは、画面に含まれる物理ピクセル数やピクセル密度や物理サイズに関係なく、すべての電話画面は、例外なく 480 ビュー ピクセル幅になります。 つまり、 を持つ Width="48" 要素は、Windows Phone Silverlight アプリを実行できる電話の画面の幅の 10 分の 1 になります。

Windows 10 アプリでは、すべてのデバイスが有効ピクセル幅の固定数であるわけではありません 。 UWP アプリを実行できるさまざまなデバイスを考えると、これはおそらく明白です。 異なるデバイスは、最小のデバイスの場合は 320 epx から、控えめなサイズのモニターでは 1024 epx まで、はるかに高い幅まで、有効ピクセルの幅が異なります。 必要な操作は、常に自動サイズの要素と動的レイアウト パネルを引き続き使用することです。 また、XAML マークアップで UI 要素のプロパティを固定サイズに設定する場合もあります。 スケール ファクターは、実行されているデバイスとユーザーが行った表示設定に応じて、アプリに自動的に適用されます。 また、そのスケール ファクターは、固定サイズの UI 要素を保持するのに役立ち、さまざまな画面サイズにわたってユーザーに対して、より小さいサイズのタッチ (および読み取り) ターゲットを表示します。 また、動的レイアウトと共に、UI は単に異なるデバイスで光学式にスケーリングされるだけではなく、適切な量のコンテンツを使用可能な領域に収めるために必要な処理を行います。

480 は以前は電話サイズの画面の表示ピクセルの固定幅であり、その値は通常有効ピクセルで小さくなりました。そのため、経験則として、Windows Phone Silverlight アプリマークアップのディメンションに 0.8 の係数を掛けます。

アプリがすべてのディスプレイで最適なエクスペリエンスを得ることができるように、各ビットマップアセットをさまざまなサイズで作成し、それぞれが特定のスケール ファクターに適していることをお勧めします。 資産を 100%スケール、200%スケール、および 400%スケール (その優先順位で) 指定すると、ほとんどの場合、中間スケール ファクターで優れた結果が得られます。

注 何らかの理由で複数のサイズのアセットを作成できない場合は、100%スケールアセットを作成します。 Microsoft Visual Studio では、UWP アプリの既定のプロジェクト テンプレートでは、ブランド化アセット (タイル イメージとロゴ) は 1 つのサイズで提供されますが、100%スケールではありません。 独自のアプリのアセットを作成するときは、このセクションのガイダンスに従って、100%、200%、400% サイズを指定し、アセット パックを使用します。

複雑なアートワークがある場合は、さらに多くのサイズでアセットを提供することができます。 ベクター アートから始める場合は、どのスケール ファクターでも、比較的簡単に高品質のアセットを生成できます。

すべてのスケール ファクターをサポートすることはお勧めしませんが、Windows 10 アプリのスケール ファクターの完全な一覧は、100%、125%、150%、200%、250%、300%、400%です。 指定した場合、ストアはデバイスごとに適切なサイズの資産を選択し、それらの資産のみがダウンロードされます。 ストアは、デバイスの DPI に基づいてダウンロードする資産を選択します。

詳細については、「レスポンシブ デザイン 101 for UWP アプリ」を参照してください。

ウィンドウ サイズ

UWP アプリでは、命令型コードを使用して最小サイズ (幅と高さの両方) を指定できます。 既定の最小サイズは 500 x 320epx で、許容される最小サイズも最小です。 許容される最大最小サイズは 500 x 500epx です。

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

次のトピックは、I/O、デバイス、アプリ モデルのための の移植です。

関連トピック

• 名前空間とクラスマッピング