UX/UI

サイズ変更できるウィンドウを使うと、アプリの使用方法をユーザーがより細かく制御できるようになります。新しい機能を使うと、アプリのタイルの可能性がさらに広がります。また、検索、共有、チャームの更新によって、より全体を通して一貫性のあるユーザー エクスペリエンスが実現します。

Windows 8.1 の新機能または更新された機能

サイズ変更できるウィンドウ

[アプリケーション ビュー複数のビュープロジェクション マネージャーのサンプルを今すぐ入手する]

Windows 8.1 では、ウィンドウのサイズと位置のいくつかが変更されています。Windows 8.1 用のアプリを開発する際には、次の点に注意してください。

  • Windows 8.1 には、固定幅のビュー状態がありません。ユーザーはアプリのサイズを連続的に最小幅まで調節することができるようになりました。(アプリの既定の最小幅は 500 ピクセルです)。このため、アプリのスナップされたビュー状態とページ横幅に合わせたビュー状態は廃止されました。代わりに、最小幅までのあらゆるサイズで機能と外観が正しく維持されるように、アプリを設計する必要があります。

      Windows 8 のスナップされたビューの幅は 320 ピクセルでした。 既定の最小幅 (500 ピクセル) は、Windows 8 のスナップされたビューの幅より大きくなります。
  • サイズが小さい方がアプリが正しく動作するため、ユーザーに対して画面にアプリを保持するように促すのであれば、最小幅を 320 ピクセルに変更することもできます。

  • ユーザーは 2 つ以上のアプリを同時に画面に表示することができます。このため、アプリは画面の左端や右端に接することなく、他の 2 つのアプリの間に表示されることもあります。

  • 1 つのアプリから複数のウィンドウを同時に表示することができます。

  • アプリは別のアプリを起動できます。あるアプリが別のアプリを起動すると、通常は、十分な空間がある場合、2 つのアプリが均等に画面を分割します。これを変更して、起動したアプリの画面を元のアプリよりも広くしたり、狭くしたり、元のアプリを覆い隠したりすることができます。既定の動作を変更するには、DesiredRemainingView プロパティを使います。

Windows 8 の場合と同様に、アプリは画面の高さいっぱいになる必要があります。アプリの最小の高さは 768 ピクセルです。

アプリの既定最小幅と狭い最小幅のピクセル要件

サイズ変更できるウィンドウの設計ガイドライン

Windows 8.1 用アプリの設計時には、次の点に注意してください。

  • アプリのレイアウトとすべてのコントロールを最小サイズまで縮小できるようにします。特に、アプリのサイズによって次のコントロールが受ける影響について考慮します。

  • 大画面の領域を効果的に使い、自動的に再配置されるレイアウトでアプリを設計します。大きな空白の領域を残さないようにします。

  • 最小幅を 320 ピクセルに変更する場合は、幅が狭いとき (幅が 320 ピクセルから 500 ピクセルの場合) に次の方法でアプリが調整されるようにしておきます。

他にも、幅を 320 ピクセルに変更するウィンドウ縦長のウィンドウのレイアウト サンプルが用意されています。アプリのサイズに関係なくアプリでチャームを使う方法について詳しくは、「すべての画面で機能するチャーム」をご覧ください。

最小幅の設定

アプリの最小幅を既定の 500 ピクセル以外に変更するには、アプリ マニフェストで ApplicationView 要素の MinWidth 属性を指定します。


<Application>
   <VisualElements>
      <ApplicationView MinWidth=”width320” />
   </VisualElements>
</Application>


アプリ マニフェスト ファイルについて詳しくは、「アプリ パッケージ マニフェスト」をご覧ください。

ApplicationView クラスの更新

Windows 8.1 では、Windows.UI.ViewManagement 名前空間に次の新しい列挙体が含まれています。

また、ApplicationView クラスには次の新しいプロパティが追加されました。

ApplicationView には次の新しいメソッドも追加されました。

Windows 8.1 では、次のメンバーは推奨されなくなりました。

  • ApplicationView.Value - アプリの状態として固定幅のビュー状態がなくなったため、無効です。代わりに、アプリ ウィンドウの方向を取得するには Orientation プロパティ、アプリの位置を取得するには AdjacentToLeftDisplayEdge プロパティ、AdjacentToRightDisplayEdge プロパティ、IsFullScreen プロパティを使うことができます。

  • ApplicationView.TryUnsnap メソッド - アプリの状態として特定のスナップされた状態がなくなり、既定の最小幅が 500 ピクセルであるため、無効です。

  • ApplicationViewState - アプリのサイズを継続的に調節することができるようになり、固定幅のビュー状態がなくなったため、無効です。

タイルの更新

[アプリのタイルとバッジセカンダリ タイルのサンプルを今すぐ入手する]

Windows 8.1 では、タイルとその操作方法に次の変更が導入されています。

新しいタイル サイズ

Windows 8 では、次の 2 つのタイル サイズがありました。

  • 正方形タイル (1x の表示スケール プラトーで 150×150 ピクセル)
  • ワイド タイル (1x スケール プラトーで 310×150)

Windows 8.1 では、次の 2 つのタイル サイズが追加されています。

  • 小さいタイル (1x スケール プラトーで 70×70)
  • 大きいタイル (1x スケール プラトーで 310×310)

4 種類のテンプレートのうち 3 種類が正方形になったため、Windows 8 で "正方形" タイル (1x スケール プラトーで 150×150) と呼ばれていたものが、"普通サイズ" タイルという名前になりました。テンプレートの種類としては、小さいタイル、普通サイズのタイル、ワイド タイル、大きいタイルがあります。4 種類すべての例を次に示します。

スタート画面に表示された 4 種類すべてのタイル サイズの例

普通サイズのタイル 1 つ分の場所に、小さいタイル 4 つを収めることができます。小さいタイルでは、ライブ タイル通知がサポートされませんが、バッジはサポートされます。大きいタイル 1 つに対して、ワイド タイル 2 つ分のスペースが必要です。大きいタイルでは、Windows 8 のタイル サイズと同じように、ライブ タイル通知がサポートされます。

タイル テンプレートの新しい命名規則

新しいタイル サイズの追加に伴い、タイル テンプレートに関する Windows 8 の命名規則が更新されました。新しい命名規則では、1× 表示スケール プラトーでの絶対ピクセル サイズが使用されています。4 つのタイル サイズは次のように新しい名前に割り当てられており、各カテゴリには多数のテンプレートがあります。

  • 小さいタイル = Square70x70
  • 普通サイズのタイル = Square150x150
  • ワイド タイル = Wide310x150
  • 大きいタイル = Square310x310

同様に、SmallLogo 属性は、アプリ マニフェスト内で Square30x30Logo という名前になっています。

新しい命名規則に従い、既にあるタイル テンプレートの名前はすべて変更されています。

以前の名前新しい名前
TileSquare*TileSquare150x150*TileSquareImage (以前の名前) / TileSquare150x150Image (新しい名前)
TileWidexxxTileWide310x150xxxTileWideImageAndText01 (以前の名前) / TileWide310x150ImageAndText01 (新しい名前)

 

互換性のために、以前の名前は引き続き使用できます。ただし、新規の開発では新しい名前を使うようにしてください。

アプリ マニフェスト内のタイル関連の変更

アプリのプライマリ タイルの既定のプロパティ (サポートされるサイズ、表示名、タイル色) は、アプリ マニフェストで宣言します。

新しいタイル サイズの選択

Windows 8 では、アプリ マニフェストでワイド タイル アセットを指定することによって、アプリでのワイド タイルのサポートを選択しました。Windows 8.1 では、マニフェストで大きいタイルのアセットを指定することによって、大きい (Square310x310) タイルのサポートを選択します。

  アプリでは、大きいタイルをサポートできるのは、ワイド タイルをサポートしている場合のみです。

普通サイズ (Square150x150) と小さい (Square70x70) タイルは、すべてのアプリでサポートされます。マニフェストで小さいタイルのアセットを指定することもできます。アプリで、独自の拡大縮小処理または別のアセットの使用によって、小さいタイルの画像が提供されない場合、Windows 8.1 によって自動的に普通サイズのタイルの画像が縮小されます。

Windows 8 の場合と同様、サポートする各タイル サイズに対して、各スケール プラトー (0.8x、1x、1.4x、1.8x) 用のアセットを別々に用意することをお勧めします。これによってタイルのスケーリングを回避し、常に鮮明にタイルを表示することができます。また、高い水準でアクセシビリティをサポートするために、ハイ コントラスト テーマの画像アセットを使用することもできます。

タイル サイズに応じたアプリ名の表示

Windows 8 では、アプリ マニフェストを使って、どのタイル サイズでアプリ名を表示するかを指定しました。Windows 8.1 でも同じように指定できますが、新しい形式も追加されています。ただし、小さい (Square70x70) タイル サイズにはアプリ名を表示できません。

ピン留め用の既定サイズの宣言

Windows 8 では、アプリがワイド タイルをサポートしている場合はワイド タイルでスタート画面にピン留めされ、それ以外の場合は普通サイズのタイルでピン留めされました。Windows 8.1 では、必要に応じてこの動作をオーバーライドし、既定のピン留め用サイズとして普通サイズのタイルまたはワイド タイルを宣言できます (小さいタイルまたは大きいタイルは指定できません)。ただし Windows 8.1 では、アプリをインストールしても自動的にスタート画面にピン留めされないので注意が必要です。アプリは [すべてのアプリ] ビューに表示されます。ユーザーはここで、アプリをスタート画面にピン留めすることを明示的に指定する必要があります。

アプリ マニフェストのスキーマの変更

これまでに説明した新しい機能を宣言するスキーマ要素を含めるために、マニフェストに追加の名前空間 ""http://schemas.microsoft.com/appx/2013/manifest"" を指定します。次の例は、マニフェストに含まれる、新しい属性と名前が変更された属性の一部を示しています。DefaultTile 要素に含まれる大きいタイルのアセットでは、優先する既定サイズも明示的に宣言されています。また、大きいタイルではなく普通サイズのタイルとワイド タイルのみにアプリ名を表示することが指定されています。



<Package 
    xmlns="http://schemas.microsoft.com/appx/2010/manifest" 
    xmlns:wb="http://schemas.microsoft.com/appx/2013/manifest">
    
...

<wb:VisualElements 
    DisplayName="Your app name" 
    Description="App description" 
    BackgroundColor="#464646" 
    ForegroundText="light" 
    ToastCapable="true" 
    Square150x150Logo="Assets\Medium150x150Tile.png" 
    Square30x30Logo="Assets\APVLogo.png">
    
    <wb:DefaultTile 
        Square70x70Logo="Assets\Small70x70Tile.png" 
        Wide310x150Logo="Assets\Wide310x150Tile.png" 
        Square310x310Logo="Assets\Large310x310Tile.png" 
        ShortName="App" 
        DefaultSize="square150x150Logo">
        
        <wb:ShowNameOnTiles>
            <wb:ShowOn Tile="square150x150Logo"/>
            <wb:ShowOn Tile="wide310x150Logo"/> 
        </wb:ShowNameOnTiles>
    </wb:DefaultTile>
    
    <wb:LockScreen 
        Notification="badgeAndTileText" 
        BadgeLogo="Assets\badge.png"/>
    
    <wb:SplashScreen Image="Assets\SplashScreen.png"/>
</wb:VisualElements>

タイル通知の変更

タイル通知を送る場合、アプリは Windows 8.1 または Windows 8 での実行中に通知を受信できる点に注意が必要です。既にあるテンプレートに対する新しい名前を認識できるのは Windows 8.1 だけであるため、fallback 属性がスキーマに追加されました。fallback 属性を含めておくと、Windows 8 システムで通知が受信された場合に備えて、通知のペイロードで Windows 8.1 テンプレートと共に Windows 8 テンプレートを指定できます。新しいテンプレートの名前と fallback 属性を使うには、次に示すように、visual 要素に新しい version 属性を含めて値を 2 に設定します。



<tile>
  <visual version="2">
    <binding template="TileSquare150x150Image" fallback="TileSquareImage" branding="None">
      <image id="1" src="Assets/Images/w6.png"/>
    </binding>
    <binding template="TileWide310x150Image" fallback="TileWideImage" branding="None">
      <image id="1" src="Assets/Images/sq5.png"/>
    </binding>
    <binding template="TileSquare310x310Image" branding="None">
      <image id="1" src="Assets/Images/sq6.png"/>
    </binding>
  </visual>
</tile>

大きいタイルは Windows 8 になかったため、大きいタイルで fallback 属性を使うことはできません。Windows 8 通知は変更することなく Windows 8.1 でも正常に動作しますが、大きいタイルを対象にすることはできません。

  ペイロードに含まれる大きい (Square310x310) タイル テンプレートは、バインド リストの最後に指定する必要があります。Windows 8 システムは、テンプレートまたはフォールバック名で認識できないバインドを検出すると、通知の解析を停止します。このため、310×310 のバインドを検出すると常に停止するということになります。

通知キュー用タイル サイズの指定

Windows 8 では、通知キューを有効にすると、普通サイズのタイルとワイド タイルの両方で有効になりました。Windows 8.1 では、特定のタイル サイズに対する通知キューを有効にするための TileUpdater クラスが追加されています。

セカンダリ タイル用の新しいタイル サイズと代替ロゴ

Windows 8.1 では、ユーザーは、コンテンツをセカンダリ タイルとしてピン留めするときに表示されるポップアップで、セカンダリ タイルの使用可能なすべてのサイズと外観を確認して、いずれかを選ぶことができます。セカンダリ タイルは、アプリのタイルでサポートされるタイルのサイズをすべてサポートできます。セカンダリ タイルに対して特定の小さいタイル用画像を指定しなかった場合、Windows 8.1 では、正方形タイルの画像が縮小されて使われます。

既定のセカンダリ タイル用画像に加えて、タイル サイズごとに 3 つの代替バージョン (合計で最大 12 バージョン) を指定できます。また、AlternateVisualElements メソッドを使って、ロゴをサポートする各タイル サイズ (正方形、ワイド、大) に、小さい代替ロゴを指定することもできます。

セカンダリ タイルの並べ替え順序でのより正確なふりがな文字列のサポート

日本語など文字ベースの言語では、UI での並べ替え順序が、アプリの表示名を構成する文字のふりがなに基づいています。このふりがなは、表示名とは別の文字列です。ユーザーは、セカンダリ タイルをピン留めするときに、ピン留めのポップアップでタイルの表示名を指定できますが、ふりがなを指定することはできません。ふりがなについては Windows による推測が行われますが、その推測が正しくないこともあります。

一方、アプリが提供するカスタム コントロールでユーザーによって定義される場合があるため、アプリでは正しいふりがなが認識されていることがあります。この場合 Windows 8.1 では、新しい SecondaryTile.PhoneticName プロパティを使ってアプリがその文字列を Windows に渡すことができます。このふりがなの文字列は、セカンダリ タイルの既定の表示名に関連付けられます。このため、ユーザーがピン留めのポップアップで表示名を変更すると、ふりがながシステムによって推測されます。

検索の更新

[SearchBox コントロールのサンプルを今すぐ入手する]

Windows 8.1 では、検索結果を提供するための新しい検索ボックス コントロールとして Windows.UI.Xaml.Controls.SearchBox (XAML を使うアプリ用) と WinJS.UI.SearchBox (JavaScript を使うアプリ用) が導入されています。

アプリでは、マークアップ内の要素として検索ボックスを含めることができるようになりました。新しいコントロールでは、テンプレートとスタイルの使用が全面的にサポートされています。

Windows 8.1 では、アプリの検索エクスペリエンスが全面的にアプリによって制御されます。 検索ボックスは、ユーザーのニーズに応じたエクスペリエンスをアプリで提供できるように、エクスペリエンスを強化し大幅なカスタマイズを可能にする検索コントラクトと統合されています。

検索ボックスでは、アプリから提供される検索候補および検索結果とアプリ固有の検索履歴がサポートされ、タッチ、キーボード、マウスによる操作が完全にサポートされます。

検索ボックスのレイアウトは次のようになります。

Windows ストア アプリのアプリ内検索ボックス コントロール

検索ボックス コントロールに表示された検索結果の例を次に示します。

検索ボックスでの "MSFT" に対する結果例

検索ボックス コントロールでは、入力方式エディター (IME) 統合がサポートされています。

IME が統合されたアプリ内検索コントロール

候補は、ユーザーが IME に入力する文字ごとに更新されます。部分的なふりがな入力に基づく漢字 (表意文字) も候補に含まれます。 IME 候補の UI によって、検索候補ポップアップが隠れることはありません。 検索ボックスでは、テキスト ボックス、IME 候補リスト、検索候補をキーボード入力で移動できます。

共有の変更

[コンテンツ共有ソースコンテンツ共有ターゲットのサンプルを今すぐ入手する]

Windows 8.1 では、アプリ内での共有エクスペリエンスと共有コントラクトの使用方法が次のように変更されています。

DataPackage への新しいデータ形式の追加

Windows 8.1 では、共有コントラクトのソース アプリは、共有されているコンテンツに戻る複数の方法を提供することができます。 Windows 8.1 では、Uri 形式が DataPackage 内の新しい 2 つのデータ形式に分割されており、厳密に型指定された 4 つの新しいプロパティが DataPackagePropertySet で導入されています。DataPackage では、Uri 形式が推奨されなくなっており、WebLink 形式と ApplicationLink 形式に置き換えられています。

WebLink は、ユーザーが何も選択していない場合に共有されます。このためソース アプリは、表示されたコンテンツを選択されたもの (デフォルト) として共有します。この形式を設定することで、ソース アプリは Uniform Resource Identifier (URI) として現在のページのコンテンツを共有します。 共有リンクは、ユーザーが閲覧している Web ページを参照します。つまり、この形式の先頭は常に http または https になります。

ApplicationLink も、ユーザーが何も選択していない場合に共有されます。このためソース アプリは、表示されたコンテンツの暗黙の選択を共有します。この形式を設定することで、ソース アプリは URI として現在のページのコンテンツを共有します。共有 URI には、ソース アプリが処理するスキームがあります。この URI プロトコルに対応していれば、ソース アプリは、ユーザーが現在閲覧しているものと同じコンテンツを表示します。この形式は、アプリのプロトコルを使用してコンテンツに戻る方法を提供することで、共有コンテンツを表します。

WebLinkApplicationLink は、固有の形式ではありません。WebLink は Web 上のコンテンツに、ApplicationLink はアプリ内のコンテンツにリンクします。たとえば、ニュース リーダー アプリの場合は、両方の形式のコンテンツが存在することが考えられます。URI は、アプリ内の記事に戻るためまたは Web サイト内の同じ記事に戻るために使用します。ターゲット アプリは、URI の処理方法を選択します。たとえば、メール アプリの場合、リンクをインターネットに送信し、Windows 以外のシステムから使用できるように、WebLink 形式を使うことが考えられます。一方、リーダー アプリの場合は、ソース アプリを再アクティブ化し、元のコンテンツに戻れるように、ApplicationLink 形式を使うことが考えられます。

ContentSourceWebLink は、共有コンテンツ用に使うコンパニオン プロパティです。これは、共有されているコンテンツの Web リンクがアプリから提供される場合に共有されます。ユーザーが明示的な選択を行った場合、WebLink 形式にデータは設定されません。WebLink 形式の値がユーザーの選択内容と同じではないためです。この情報が設定されている場合、Web ページがユーザーの選択であるという意味ではなく、コンテンツが Web ページからのものであることを意味します。

ContentSourceApplicationLink は、共有コンテンツ用に使う 2 番目のコンパニオン プロパティです。これは、アプリ内で現在表示されているコンテンツに戻ることに意味があるとアプリで判断された場合に共有されます。ユーザーが選択を行った場合、ApplicationLink 形式にデータは設定されません。この場合、ApplicationLink 形式の値がユーザーの選択内容と同じではないためです。この情報が設定されている場合、アプリへのディープ リンクがユーザーの選択を表しているという意味ではなく、コンテンツが Web ページからのものであることを意味します。

たとえば、ユーザーがリーダー アプリで記事を閲覧しているとします。ユーザーは引用文を選択して OneNote と共有します。この引用文の出典として記事を示すときに、リーダー アプリでは WebLink 形式または ApplicationLink 形式を使いません。記事は、共有する引用文と等価ではないためです。そこで代わりに、ContentSourceWebLink プロパティと ContentSourceApplicationLink プロパティを使います。OneNote では、ソース属性と共に、選択されたテキストが追加されます。その後でユーザーは、OneNote で引用文を読み、リーダー アプリまたは Web ページに戻って引用文の周囲のコンテキストを読むことができます。

共有の応答性の向上

Windows 8.1 では、共有コントラクトを使うアプリでは、共有ペインをプログラムで閉じることで応答性を向上できます。

共有ペインを閉じるには、新しい DismissUI メソッドを呼び出します。DismissUI を呼び出すことは、共有ペインの外側をタップして閉じることに似ています。共有操作に長い時間がかかる場合は、アプリの実行が続行されます。長時間の操作でなければ、10 秒間の実行後に終了されます。

ターゲット アプリは現在、画面から外に移動することはできません。このため、共有操作が開始したときに、操作の完了をユーザーが待つ間、(処理を完了するために他のユーザー操作が必要ない場合も) アプリで進行状況インジケーターを表示するのが一般的です。実際には、ユーザーはポップアップを軽いタップで安全に閉じることができますが、共有操作の完了前に閉じるとデータが失われると思い、ポップアップを閉じたくないと考えるユーザーが少なくありません。DismissUI を使うと、アプリがポップアップを自動的に閉じることができます。

パッケージ ファミリ名

Windows 8.1 では、共有コントラクトのソース アプリがターゲット アプリにパッケージ ファミリ名を渡すことができます。これによりターゲット アプリは、ApplicationLink で指定されたアプリを起動する際に、フォールバック エクスペリエンスを提供することができます。

パッケージ ファミリ名は、アプリ パッケージの一意の識別子です。ソース アプリがこの識別子をターゲット アプリに渡すと、ターゲット アプリは指定された ApplicationLink を使って LaunchUriAsync メソッドを呼び出すことにより、フォールバック エクスペリエンスを提供することができます。たとえばユーザーがアプリをアンインストールしたため、またはアプリがインストールされていない別のデバイスに URI がローミングされたために、URI スキームが処理されない場合、Windows ストア内でアプリを検索するようにユーザーに求めるダイアログ ボックスが表示されます。このとき、既定では、必要なアプリではなくストアのページが表示されます。LaunchUriAsync に渡す LauncherOptions オブジェクトにパッケージ ファミリ名を含めた場合、特定のアプリのインストールを求めるメッセージがユーザーに表示され、ストア内のアプリの内容ページが開きます。

推奨されなくなった Uri 形式

前に述べたように、Windows 8.1 では、Uri 形式が DataPackage 内の新しい 2 つのデータ形式に分割されており、厳密に型指定された 4 つの新しいプロパティが DataPackagePropertySet で導入されています。DataPackage では、Uri 形式が推奨されなくなっており、WebLink 形式と ApplicationLink 形式に置き換えられています。Uri 形式は、WebLink 形式のエイリアスとして残されています。

すべての画面で機能するチャーム

Windows 8 では、画面に複数のアプリが表示されているときにユーザーがチャームを起動すると、画面上のスペースを最も多く使っているアプリに対してチャームが表示されました。 Windows 8.1 では、画面上にアプリがいくつあるかどうか、または複数の画面があるかどうかに関係なく、ユーザーが最後に操作したアプリに対してチャームが表示されます。たとえば、ユーザーが設定チャームを選択した場合は、最後に使用されたアプリの設定ポップアップが表示されます。

アプリを設計する際は、アプリのサイズに関係なく、チャームに対応するように設計してください。特に、設定ポップアップの幅は、アプリの現在の幅以下である必要があります。

ユーザーやイベントと統合するアプリの作成

[Contact manager APIAppointments API連絡先に関連する操作の処理のサンプルを今すぐ入手する]

Windows 8.1 では、ユーザーやイベントの強みをアプリに活かすことができます。アプリのユーザーが知り合いに関する情報をアプリ内から検索できるようにすることも、メッセージング、メール、通話、ビデオ通話などの通信エクスペリエンスの統合によって人々とのつながりを実現することもできます。また、カレンダーの予定を迅速に確認できたり、好みのカレンダーにイベントを追加できることで、ユーザーがアプリ内に留まるようになります。

アプリでユーザーの連絡先カードを表示し、イベントを管理するには、次の新しい API を使います。

  • ShowContactCard メソッド

    アプリがオペレーティング システムにユーザーの連絡先を照会し、ユーザーの連絡先データを連絡先カードに表示できます。

  • AppointmentsProvider 名前空間

    予定プロバイダーがやり取りするアクティブ化を通じて、予定の追加要求、置き換え要求、削除要求をサポートします。

  • AppointmentManager クラス

    アプリがユーザーの予定プロバイダーとやり取りして、イベントの追加、置き換え、削除を行うことができます。また、予定プロバイダーのプライマリ UI を表示できます。

  • Activation 名前空間

    アプリが Windows によってサポートされる新しい予定プロバイダーと連絡先コントラクトのアクティブ化パラメーターを処理することができます。

音声合成

[音声合成のサンプルを今すぐ入手する]

Windows 8.1 では、音声合成を Windows ストア アプリでサポートする Windows.Media.SpeechSynthesis API が導入されています。音声合成は、TTS (text-to-speech) としても知られています。

音声合成は、ユーザーに入力を求める場合、アプリ通知やメッセージ ダイアログを強調する場合、手順を示す場合 (道路案内ナビゲーションなど) や、テキストやメールの内容、RSS フィード、書籍、検索結果などの読み上げの用途に使うことができます。

Windows 8.1 には、ボイスと呼ばれる複数の音声合成エンジンが含まれています。各ボイスには、Microsoft David (en-US、男性)、Microsoft Zira (en-US、女性)、Microsoft Hazel (en-UK、女性) などのフレンドリ名があり、これらはアプリ内で指定することも、[言語] コントロール パネルからユーザーが選ぶこともできます。

Windows 8.1 でサポートされる音声合成機能を使うと、次のことが可能になります。

  • スピーチ シンセサイザーを特定の性別、ボイス、言語に設定する。

  • 現在のボイスの既定の特性とプロパティを使って、プレーンテキストの文字列から音声出力を生成する。

  • Speech Synthesis Markup Language (SSML) を含む文字列から音声出力を生成することにより、ボイスの特性、発音、音量、音程、速度や加速、強勢などをカスタマイズする。

  • ランダム アクセス ストリームに対して、音声合成エンジンによって生成されたオーディオ データの読み取りと書き込みを行う。

プレーンテキストからの音声の生成

この例では、Windows ストア アプリが SpeechSynthesizer オブジェクトを使ってオーディオ ストリームを作成し、プレーンテキストの文字列に基づいて音声を生成する方法を示します。


// The media object for controlling and playing audio.
MediaElement mediaElement = this.media;

// The object for controlling the speech-synthesis engine (voice).
var synth = new Windows.Media.SpeechSynthesis.SpeechSynthesizer();

// Generate the audio stream from plain text.
SpeechSynthesisStream stream = await synth.SynthesizeTextToStreamAsync("Hello World");

// Send the stream to the media object.
mediaElement.SetSource(stream, stream.ContentType);
mediaElement.Play();

Speech Synthesis Markup Language (SSML) からの音声出力の生成

次の例では、Windows ストア アプリが SpeechSynthesizer オブジェクトを使ってオーディオ ストリームを作成し、SSML テキストの文字列に基づいて音声を生成する方法を示します。


// The string to speak with SSML customizations.
string Ssml =
    @"<speak version='1.0' " +
    "xmlns='http://www.w3.org/2001/10/synthesis' xml:lang='en-US'>" +
    "Hello <prosody contour='(0%,+80Hz) (10%,+80%) (40%,+80Hz)'>World</prosody> " + 
    "<break time='500ms' />" +
    "Goodbye <prosody rate='slow' contour='(0%,+20Hz) (10%,+30%) (40%,+10Hz)'>World</prosody>" +
    "</speak>";

// The media object for controlling and playing audio.
MediaElement mediaElement = this.media;

// The object for controlling the speech-synthesis engine (voice).
var synth = new Windows.Media.SpeechSynthesis.SpeechSynthesizer();

// Generate the audio stream from SSML.
SpeechSynthesisStream stream = await synth.synthesizeSsmlToStreamAsync(Ssml);

// Send the stream to the media object.
mediaElement.SetSource(stream, stream.ContentType);
mediaElement.Play();

バックグラウンド タスク管理を更新する方法

[バックグラウンド タスクのサンプルを今すぐ入手する]

Windows 8.1 では、バックグラウンド タスクに次のような新機能が追加されました。

通知の停止時間とバックグラウンド タスク

通知の停止時間は Windows 8.1 の新機能で、ユーザーが通知を受けたくないときに 1 日のうちの特定の時間を指定できます。 この機能により、Windows ストア アプリに関連付けられた大部分のバックグラウンド タスクも停止されます。ユーザーへの妨害を防ぎ、デバイスのコネクト スタンバイ有効期間を拡大する可能性があります。

システムが通知の停止時間に入ると、バックグラウンド タスクはキューに入れられ、通知の停止時間が終わるまで保留されます。 システムが通知の停止時間に入ると、現在実行されているバックグラウンド タスクは取り消されます。

通知の停止時間が終わると、バックグラウンド タスクは再開を許可されます。 各バックグラウンド タスクは、通知の停止時間が終わる前に、ランダムな間隔で再開します。これにより、システム リソースとリモート サーバー リソースに不必要な負荷をかけないように、すべてのバックグラウンド タスクが同時に再開しないようにします。システムは、指定された通知の停止時間が終わるまで通知をトリガーしません。

通知の停止時間には既定で許可されている 2 つの例外があります。それは、新しいロック画面での通話機能をサポートしているアプリから受けた電話の着信と、既定の指定されたアラーム アプリでユーザーが設定したアラームです。アプリがロック画面での通話機能をサポートし、IncomingCall が TRUE に設定されている場合は、バックグラウンド タスクが実行され、通知が配信されます。既定の指定されたアラーム アプリでユーザーが設定したアラームからの通知は、通知の停止時間中も配信されます。

通知の停止時間は、既定では深夜 0 時から午前 6 時に有効になりますが、着信は許可されます。 ユーザーは、[PC 設定の変更] の [アプリ] セクションの [通知] タブで、これらの設定を変更したり、通知の停止時間を無効にすることができます。 通知の停止時間はすべてのシステムで利用できます。

アイドル タスクの取り消し

バックグラウンド タスク リソースの制約に加え、Windows バックグラウンド タスク インフラストラクチャは、アイドル状態またはハング状態のバックグラウンド タスクを検出します。最短時間内に最小限の CPU またはネットワーク リソース クォータを使用しなかった場合 (システムの状態によって異なる)、バックグラウンド タスクはアイドル状態またはハング状態と見なされます。アイドル状態またはハング状態のバックグラウンド タスクが検出されると、キャンセル通知が送信され、バックグラウンド タスクを中止して閉じることができます。バックグラウンド タスクが 5 秒以内に中止され閉じられない場合、アプリは応答なしと見なされ、システムによって強制終了されます。

Windows 8.1 では、アイドル状態またはハング状態のバックグラウンド タスクのためにアプリを終了することを避け、常にキャンセル ハンドラーを関連付けて適切に取り消すようにしてください。詳細とコード スニペットについては、「アイドル状態またはハング状態のバックグラウンド タスクを処理する方法」を参照してください。

バックグラウンド タスクの作業コストのヒント

Windows 8.1 では、リソースの使用可能性に関するバックグラウンド タスクへのヒントが提供されます。バックグラウンド タスクがアクティブにされると、ヒントを利用して、どのくらいの作業が必要かを調べることができます。低、中、高の 3 つのリソース状態が報告されます。詳しくは、「BackgroundWorkCost」および「BackgroundWorkCostValue」をご覧ください。

バックグラウンド タスクの PowerShell コマンドレット

開発者は新しい AppBackgroundTask PowerShell コマンドと新しい BackgroundTasksManager コマンドレット デザイナー モジュールを使用して、実行中のバックグラウンド タスクを取得できます。これは、バックグラウンド タスクの実装とデバッグを行うときに非常に便利です。詳しくは、「バックグラウンド タスクの PowerShell コマンドレット」をご覧ください。

ロック画面でのアラーム アプリのサポート

[アラーム通知のサンプルを今すぐ入手する]

Windows 8.1 では、ロック画面スロットの 1 つがアラーム アプリ用に使われます。アラーム アプリは、AlarmApplicationManager クラスを使って、システム アラーム アプリになる許可をユーザーに求めます。ユーザーがその要求を許可した場合 (または、ユーザーがコントロール パネルを使ってアプリをアラーム スロットに配置した場合)、アプリはスロットに配置され、システム アラーム アプリになります。システム アラーム アプリによって発生するアラーム通知は、1 秒以内の精度でユーザーに表示されます。アラーム スロットに配置されたアプリのみがアラーム通知を生成できます。他のアプリによって生成されたアラーム通知は、通常の通知として処理されます。

アラーム通知をスケジュールするには、commands 要素を使ってトースト通知を作成します。アラーム サウンドを指定するには、audio 要素を使います。アラーム サウンドは、システムがミュートされている場合でも、通知が生成されると再生されます。

作業項目のスケジュール設定の更新

CoreDispatcher (Windows::UI::Core:CoreDispatcher) API を使うと、作業項目のスケジュール設定における優先順位を詳しく制御できるようになりました。

Windows 8.1 では、作業ディスパッチの優先順位が次の順序になっています。

  1. SendMessage (優先順位が最も高い)
  2. CoreDispatcherPriority.High
  3. CoreDispatcherPriority.Normal (ウィンドウ メッセージとコンポーネント オブジェクト モデル (COM) 呼び出しが含まれる)
  4. すべてのデバイス入力メッセージ
  5. CoreDispatcherPriority.Low
  6. CoreDispatcherPriority.Idle (優先順位が最も低い、バックグラウンド タスクに使用)
タスクの優先順位を変更するには、CoreDispatcher 型で次の新しいメンバーを使います。
  • CoreDispatcher::ShouldYield メソッド (2 つのオーバーロード) — 指定された優先順位以上の項目がタスク キューにある場合、呼び出し元が譲歩する必要があるかどうかを照会します。

  • CoreDispatcher::CurrentPriority プロパティ —CoreDispatcher が最後に処理したタスクの現在の優先順位を取得または設定します。アプリが特定の優先順位の作業を処理中に、これより優先度の高い作業が発生した場合に、このプロパティを設定します。これによって、現在のタスクの優先順位が上昇し、ShouldYield からの結果がより正確になります。

 

 

表示:
© 2015 Microsoft