Windowsストアアプリにおける グリッドアプリケーションについて

「Windowsストアアプリにおける グリッドアプリケーションについて」という記事を8回に渡って記載してきました。このページは、各記事に対する索引として記載します。 Windowsストアアプリにおける グリッドアプリケーションについて(1) この記事では、ページ・ナビゲーションの基本構造とDefaultViewModel、LoadStateメソッドなどを解説しています。 Windowsストアアプリにおける グリッドアプリケーションについて(2) この記事は、1回目の続きでGroupedItemPageの構造を取り扱っています。GridViewやListViewコントロールでレイアウトが構成されている点と、ビューの切り替えをVisualStateManagerを使っていることを解説しています。 Windowsストアアプリにおける グリッドアプリケーションについて(3) この記事では、データバインドの理解を深めるためにデータソースを解説しています。 Windowsストアアプリにおける グリッドアプリケーションについて(4) この記事では、データソースが理解できた上でGroupedItemPageの残りの解説を行っています。この4回までを理解することで、GroupedItemPageの構造を完全に把握したと言えるでしょう。 Windowsストアアプリにおける グリッドアプリケーションについて(5) この記事では、セクションに相当するGroupDetailPageを解説しています。 Windowsストアアプリにおける グリッドアプリケーションについて(6) この記事では、詳細に相当するItemDetailPageを解説しています。 Windowsストアアプリにおける グリッドアプリケーションについて(7) この記事では、グリッドアプリケーションのカスタマイズする時に注意すべき事項を解説しています。 Windowsストアアプリにおける グリッドアプリケーションについて(8) この記事は、このシリーズの最終回としてS.Somasegarの記事である「Building an End-to-End Windows Store App」を題材にして、具体的にどのようにグリッドアプリケーションをカスタマイズしてRSSリーダーを作成するかということを解説しています。 Visual Studioが提供するWindows ストア アプリのテンプレートは、空のアプリケーション以外は理解するまでに時間がかかります。この理由は、テンプレートと言いながら、サンプルアプリケーションを如何に効率良く作れるかという観点も含めたサンプル アプリケーションになっているからです。この記事は、これらのテンプレートの理解を助けることを目的として記載しました。 是非、皆さんもWindows ストアアプリにチャレンジしてみて下さい。

0

Windowsストアアプリにおける グリッドアプリケーションについて(8)

前回まででグリッドアプリケーションの基本構造と良く行われるであろうカスタマイズ方法を説明しました。今回は、カスタマイズの具体例としてSomasegarのBlogで取り上げられていた「Build and End-toEnd Windows Store App」シリーズを補足します。 Building an End-to-End Windows Store App – Part 1 Building an End-to-End Windows Store App – Part 2:Integrating Cloud Services Part2は、ローミングまでを取り上げます。 この記事を補足した方が良いと考えた理由は、作業が進むにつれて詳細を説明するのではなく、抜粋で解説しているからです。この理由から、正しく理解していないと、コードのコピー/ペーストでは動くものにならない可能性が高いので、初心者にはハードルが高いと考えたからです。以降で、それぞれのフェースに沿って補足していきます。 Getting Data この解説で気になったのが、データソースを取得するコードなどが気になりましたので、少し詳細に解説します。 記載されていませんが、最初に考えないといけないのはサンプルデータの問題です。この記事では、SampleDataSourceのコンストラクタ内に記載されているサンプルデータを削除していると考えるべきです。サンプルデータを削除した場合の問題は、デザイナーでのデザインがし難いということです。この問題を回避するために、サンプルデータをデザイン時のみに作成するように変更すべきでしょう。具体的には、以下のようにします。 public SampleDataSource() { if (Windows.ApplicationModel.DesignMode.DesignModeEnabled) { CreateSampleData(); } } void CreateSampleData(){        // ここにサンプルデータのコードをコピーします }                      このようにすることで、デザイン用のサンプルデータを維持しながら、実行時にはサンプルデータを作成しなくなることは既に説明した通りです。 次に気になっているのが、以下のコードになります。 public static readonly ObservableCollection<SampleDataGroup> AllGroups…

0

Windowsストアアプリにおける グリッドアプリケーションについて(7)

少し時間があきましたが、今回はグリッドアプリケーションを使った場合にどのようにカスタマイズするかということを説明します。最初に、開発体験テンプレートをご存じな方も多いことと思います。このテンプレート集のNewReaderのReadme.txtにカスタマイズのポイントが記載されているので、その中から抜粋したものを以下に示します。 (0) アプリの名前 (2) ブランディング (3) プライバシーポリシー (4) package.appxmanifest 最初にブランディングを説明します。ブランディングに関係する事項として、以下のようなことを考慮する必要があります。 バックグラウンド 背景色や画像など アイコン デザイン ロゴ(150×150)、ワイドロゴ(310×150)、小さいロゴ(30×30)、バッジロゴ(24×24)、スプラッシュスクリーン(620×300)、ストアロゴ(50×50) 特にブランディングは重要で、作成したアプリが容易に識別できるようにするためにも必須となります。また、アプリ内の各種のページ設計などを含めて統一感を持ってデザインすることが重要となり、これらの統一がアプリの印象を利用者に認識してもらうのに役立ちます。 このブランディングを考える上で、最初に取り組むのが背景色の変更だと思います。Windows ストア アプリのテンプレートでは、テーマという機能が含まれておりデフォルトのテーマは「Dark」となっています。これをSDKサンプルのように白を基調としたテーマにするには、App.xamlに「RequestedTheme」属性を記述します。 <Application ・・・・・ RequestedTheme = “Light” ・・・・・ >   アプリの名前を変更するのも忘れないようにしましょう。アプリの名前は、App.xamlに「AppName」というキーを持つリソースとして定義されています。 プライバシーポリシーは、ネットワーク通信を行うアプリでは必須となります。Windows 8 アプリの認定の要件 (Windows)の要件4.1.1に「ユーザーの IP アドレスなどの個人情報をアプリで収集または送信する場合は、」とあり、収集するかしないは別として通信を行う場合は通信インフラストラクチャーがIPアドレスを送信します。この理由から、プライバシーポリシーを用意することが必須となります。特に、Visual Studioで作成した新規プロジェクトではデフォルトで「インターネット」が有効になっているので、注意しましょう。用意するプライバシーポリシーは、以下の2ヶ所への明示が必須となります。 アプリ内でプライバシーポリシーを表示できるようにする。 アプリで表示するページでも良いですし、Webサイトへのリンクでも構いません。 ストアのアプリ紹介ページからプライバシーポリシーを表示できるようにする。 プライバシーポリシーを掲示しているWebサイトのリンクを用意する必要があります。 Package.appmanifestは、特に以下の点を正しく設定します。 アプリケーション UI タブ 表示名:必ずデフォルトの名前から変更します。アプリケーションの名前で、タイルなどに表示されます。長い場合は、短い名前も適切に設定します。 説明 各種ロゴと背景色。特にスプラッシュスクリーンの背景色は、アプリ全体の背景色と統一感を持って設定します。 パッケージ化 タブ パッケージ表示名:必ずデフォルトの名前から変更します。 パッケージ名:変更しても良いでしょうし、デフォルトのGUIDにしておいても構いません。 パッケージ名やパッケージ表示名は、意図的にデフォルトの値にしておくこともあります。これは、セキュリティ上の理由です。Windows ストアアプリは、インストール自体がパッケージ名単位で行われます。逆を言えば、パッケージ名が理解しやすいと、カジュアルハックがし易いとも言えます。カジュアルハックと言っても、パッケージのローカルストア(ユーザー プロファイルの中にあります)をWindows エクスプローラーなどで覗いたりという意味です。パッケージ名を変更することは、一見しただけでアプリとの関連付けを連想させないためだけに、アプリと関係の無いパッケージ名やパッケージ表示名にしておくという程度の効果しかありません。この理由は、タスクマネージャーなどを使うことで、パッケージ名を利用者が知ることができるからです。 ここまで説明してきたのは、NewReaderテンプレートのReadme.txtに基づいています。新規のグリッドアプリケーションを自分で作成した場合は、データソースの変更が最初に行うステップとなります。以下に記載するのは、必ずではありませんが、このような考え方でNewsReaderはデータソースをカスタマイズしたと理解して頂ければ結構です。…

0

Windowsストアアプリにおける グリッドアプリケーションについて(6)

前回にGroupDetailPageの説明を行いました。今回は、最後のItemDetailPageの説明を行います。最初に、ItemDetailPageがナビゲーションを使って呼び出されることから、LoadStateメソッドを以下に示します。 protected override void LoadState(Object navigationParameter, Dictionary<String, Object> pageState) { // 保存されたページの状態で、表示する最初のアイテムをオーバーライドすることを許可します if (pageState != null && pageState.ContainsKey(“SelectedItem”)) { navigationParameter = pageState[“SelectedItem”]; } // TODO: 問題のドメインでサンプル データを置き換えるのに適したデータ モデルを作成します var item = SampleDataSource.GetItem((String)navigationParameter); this.DefaultViewModel[“Group”] = item.Group; this.DefaultViewModel[“Items”] = item.Group.Items; this.flipView.SelectedItem = item; } navigationParameterに、SampleDataItem.UniqueIdが格納されていて、SampleDataSourceの静的メソッドであるGetItemメソッドを呼び出しています。このメソッドにより、目的のSampleDataItemのインスタンスを取得して、DefaultViewModelのGroupキーとItemsキー、FilvepViewのSelectedItemを設定しています。CollectionViewSourceの定義は、GroupDetailPage.xamlと同一になっており、レイアウトのルートとなるGridに対するDataContextやd:DataContextもGroupDetailPage.xamlと同-です。 異なるのは、詳細情報をFlipViewコントロールで行っていることです。 FlipViewコントロールは、コレクションの要素を右端と左端の矢印によってナビゲーションすることができます。従って、FlipViewコントロールを使うのはコレクションの要素を列挙するような用途に向いているということになります。それでは、ItemDetailPage.xamlのFlipViewの定義を以下に示します。 <!– このページの残りは 1 つの大きな FlipView です。ここには、一度に 1 つのアイテムの詳細が表示され、ユーザーは選択されたグループ内のすべてのアイテムを見ることが できます –>…

0

Windowsストアアプリにおける グリッドアプリケーションについて(5)

前回まででGroupedItemPageの説明が終了したので、今回はGroupDetailPageの説明を行います。最初に、GroupedItemsPage.HeaderClickで説明したナビゲーションで呼び出されるLoadStateメソッドを見てみましょう。 protected override void LoadState(Object navigationParameter, Dictionary<String, Object> pageState) { // TODO: 問題のドメインでサンプル データを置き換えるのに適したデータ モデルを作成します var group = SampleDataSource.GetGroup((String)navigationParameter); this.DefaultViewModel[“Group”] = group; this.DefaultViewModel[“Items”] = group.Items; }         navigationParameterに、SampleDataGroup.UniqueIdが格納されていて、SampleDataSourceの静的メソッドであるGetGroupメソッドを呼び出しています。このメソッドにより、目的のSampleDataGroupのインスタンスを取得して、DefaultViewModelのGroupキーとItemsキーを設定しています。今までの説明を読んできた人には理解できると思いますが、GroupキーとItemsキーの設定を確認するために、GroupDetailPage.xamlのCollectionViewSourceとGridViewを見ていきます。最初に、CollectionViewSourceを以下に示します。 <CollectionViewSource x:Name=”itemsViewSource” Source=”{Binding Items}” d:Source= “{Binding AllGroups[0].Items, Source={d:DesignInstance Type=data:SampleDataSource, IsDesignTimeCreatable=True}}”/> Source属性に記述されている「Items」がDefaultViewModelのキーであり、d:Source属性に記述されているSampleDataSource.AllGroups[0]がデザイン時のデータソースになります。デザイン時は、AllGroupsプロパティが返すコレクションの最初の要素をバインドしています。次に、GridViewとListViewの定義を以下に示します。 <Grid Style='{StaticResource LayoutRootStyle}’ DataContext='{Binding Group}’ d:DataContext='{Binding AllGroups[0], Source={d:DesignInstance Type=data:SampleDataSource, IsDesignTimeCreatable=True}}’> <Grid.RowDefinitions> <RowDefinition Height=’140’/> <RowDefinition Height=’*’/> </Grid.RowDefinitions>…

0

Windowsストアアプリにおける グリッドアプリケーションについて(4)

前回にデータソースの説明をしました。SampleDataSourceの構造が理解できましたので、改めてGroupedItemPage.xaml.csのLoadStateのコードを振り返ります。 protected override void LoadState( Object navigationParameter, Dictionary<String, Object> pageState) { // TODO: 問題のドメインでサンプル データを置き換えるのに適したデータ モデルを作成します var sampleDataGroups = SampleDataSource.GetGroups( (String)navigationParameter); this.DefaultViewModel[“Groups”] = sampleDataGroups; } SampleDataSource.GetGroupsメソッドは、静的メソッドになっていますから、呼び出されるとメンバー変数の_sampleDataSourceのAllGroupsプロパティの値を返します。そして、 _sampleDataSourceメンバー変数は静的変数となっており、SampleDataSourceクラスのインスタンスを保持しています。_sampleDataSourceメンバー変数が静的変数となっている点が重要です。何故なら、静的変数はアプリケーションドメイン単位に保持されますから、異なるページのインスタンスへナビゲーションしたとしても_sampleDataSourceは、同一のインスタンスを保持し続けるからです(要は、キャッシュの効果があるのです)。 また、AllGroupsメソッドは引数が”AllGroups”であることが要求されますので、このパラメータがどのように渡されるかを確認するためにApp.xaml.cs の OnLaunchedイベントハンドラーを以下に示します。 /// <summary> /// アプリケーションがエンド ユーザーによって正常に起動されたときに呼び出されます。他のエントリ ポイントは、 /// アプリケーションが特定のファイルを開くために呼び出されたときに /// 検索結果やその他の情報を表示するために使用されます。 /// </summary> /// <param name=”args”>起動要求とプロセスの詳細を表示します。</param> protected override async void OnLaunched(LaunchActivatedEventArgs args) { Frame rootFrame =…

0

Windowsストアアプリにおける グリッドアプリケーションについて(3)

前回にLayoutAwarePage.StartLayoutUpdateメソッドが、Loadedイベントで呼び出されることを説明しました。このメソッドは、以下の定義になっていました。。 public void StartLayoutUpdates(object sender, RoutedEventArgs e) { var control = sender as Control; if (control == null) return; if (this._layoutAwareControls == null) { // 更新の対象となるコントロールがある場合、ビューステートの変更の待機を開始します Window.Current.SizeChanged += this.WindowSizeChanged; this._layoutAwareControls = new List(); } this._layoutAwareControls.Add(control); // コントロールの最初の表示状態を設定します VisualStateManager.GoToState(control,       DetermineVisualState(ApplicationView.Value), false); } ここで気を付けておくべきことは、「_layoutAwareControls」というメンバー変数です。この変数は「List<Control>」型になっており、LayoutAwarePageクラスがLoadedイベントにより登録されます。これは、LayoutAwarePageがPageクラスを継承しており、Pageクラスが UserControl を継承し、UserControlが Controlクラスから派生しているためです。この機能により、LayoutAwarePageクラスを継承したGroupedItemsPage.xamlで定義されたVisualStateManagerのVisualStateが呼び出されるようになっているのです。 この特徴を理解しておくことは、とても重要です。何故なら、ユーザーコントロールを自作して組み合わせる場合に、LoadedとUnLoadedイベントで「StartLayoutUpdatesメソッドとStopLayoutUpdatesメソッド」を呼び出すように設定することで、ユーザーコントロール内に記述したVisualStateManagerの定義が呼び出されるようになるからです。実際に、グリッドアプリケーションのItemDetailPage.xamlではUserControlを定義してLoadedとUnLoadedイベントハンドラーを設定しています。 GroupedItemsPageクラスで次に説明することは、データソースについてです。データソースの説明に入る前に、GroupedItemsPage.xamlのCollectionViewSourceの定義を以下に再掲します。 <CollectionViewSource x:Name=”groupedItemsViewSource” Source=”{Binding Groups}” IsSourceGrouped=”true” ItemsPath=”TopItems” d:Source= “{Binding…

0

Windowsストアアプリにおける グリッドアプリケーションについて(2)

前回は、GroupedItemsPageのLoadStateメソッドまでを説明しました。今回は、GroupedItemsPageのビューに関して説明します。ビューとしては、前回に説明したようにGridViewコントロールとListViewコントロールの2つを用意しています。最初に、GridViewコントロールの定義とデザイン画面を以下に示します。 <!– ほとんどのビューステートで使用される水平スクロール グリッド–> <GridView x:Name=”itemGridView” AutomationProperties.AutomationId=”ItemGridView” AutomationProperties.Name=”Grouped Items” Grid.RowSpan=”2″ Padding=”116,137,40,46″ ItemsSource=”{Binding Source={StaticResource groupedItemsViewSource}}” ItemTemplate=”{StaticResource Standard250x250ItemTemplate}” SelectionMode=”None” IsSwipeEnabled=”false” IsItemClickEnabled=”True” ItemClick=”ItemView_ItemClick”> <GridView.ItemsPanel> <ItemsPanelTemplate> <VirtualizingStackPanel Orientation=”Horizontal”/> </ItemsPanelTemplate> </GridView.ItemsPanel> <GridView.GroupStyle> <GroupStyle> <GroupStyle.HeaderTemplate> <DataTemplate> <Grid Margin=”1,0,0,6″> <Button AutomationProperties.Name=”Group Title” Click=”Header_Click” Style='{StaticResource TextPrimaryButtonStyle}’ > <!– 以下 省略 –> </Grid> </DataTemplate> </GroupStyle.HeaderTemplate> <GroupStyle.Panel> <ItemsPanelTemplate> <VariableSizedWrapGrid Orientation=’Vertical’ Margin=’0,0,80,0’/> </ItemsPanelTemplate> </GroupStyle.Panel> </GroupStyle> </GridView.GroupStyle>…

0

Windowsストアアプリにおける グリッドアプリケーションについて(1)

久し振りのエントリーになります。これから、何回かに渡ってVisual Studio 2012に含まれる Windows ストア アプリケーションのグリッド アプリケーション テンプレートを紐解いて行きます。 グリッド アプリケーションのナビゲーションは、以下に示すように3階層になっています。 ナビゲーションに含まるXAMLページは、以下のようになっています。 GroupedItemsPage.xaml ハブとなるページで、GridViewコントロールとListViewコントロールを持ちます。 GroupDetailPage.xaml セクションとなるページで、GridViewコントロールとListViewコントロールを持ちます。 ItemDetailPage.xaml 詳細となるページで、FlipViewコントロールを持ちます。 また、各ページとLayoutAwarePageクラスの関係は、以下のようになっています。 各ページは、LayoutAwarePageという抽象クラスを継承した構造になっています。このことから、明確になることが1つあります。それは、新しいページを作成した場合は、必ずLayoutAwarePageクラスを継承するようにした方が良いということです。具体的には、検索コントラクトで追加されるSearchResultsPage.xamlなどです。この理由は、LayoutAwarePageを説明していくことで解説をしていきます。 それでは、GroupedItemPage.xaml にある、LayoutAwrePageの定義を見ていきます。 <common:LayoutAwarePage x:Name=”pageRoot” x:Class=”App6.GroupedItemsPage” DataContext=”{Binding DefaultViewModel, RelativeSource={RelativeSource Self}}” xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation” xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml” xmlns:local=”using:App6″ xmlns:data=”using:App6.Data” xmlns:common=”using:App6.Common” xmlns:d=”http://schemas.microsoft.com/expression/blend/2008″ xmlns:mc=”http://schemas.openxmlformats.org/markup-compatibility/2006″ mc:Ignorable=”d”> <Page.Resources> <!– このページで表示されるグループ化されたアイテムのコレクションは、グループ内のアイテムを 仮想化できないため、完全なアイテム リストのサブセットにバインドされます –> <CollectionViewSource x:Name=”groupedItemsViewSource” Source=”{Binding Groups}” IsSourceGrouped=”true” ItemsPath=”TopItems” d:Source=”{Binding AllGroups, Source={d:DesignInstance Type=data:SampleDataSource, IsDesignTimeCreatable=True}}”/> </Page.Resources> この定義で注目したいのが、「DataContext=”{Binding…

0

WDD でお話するまでの経緯とデモ内容のフォロー

WDDのアプリのライフサイクルと実行環境に、多くの方が参加していただきまして有難うございました。少し、時間が延びましたが、本当に有難うございました。今回は、この時にお話しできなかった話題と準備作業の舞台裏を記載します。資料の作成を始めたのは3月からなのですが、デモの準備をしながら資料の見直しやサンプルの作り直しなどを何度も行っていました。大体の準備ができたのが4/13で、翌週に最終チェックと環境整備を行っていました。私がデモで使用したPCは、自前のHP TouchSmart tx2なのですが、この時に結局3回ほどインストールを行っていました。この理由は、マルチタッチのドライバーです。タッチパネルがN-Trig製なのですが、HPから提供されているDuoSenseはWindows 8にインストールすることができません。ドライバーインストールを様々な方法で試した結果、シングルタッチでは動作していましたが、やはりマルチタッチにしたいということから再インストールを実施したのです。このPC特有かも知れませんが、DuoSenseのインストール方法を以下に記載します。 Windows 7 環境でマルチタッチを有効にする(DuoSenseをインストール)。 Windows 8 CPをアップグレードインストールします。 N-Trigが公開しているベータードライバーをインストールします。 マルチタッチが動作しない場合は、再起動してみる。 上記の方法で私の環境では動作していますが、デバイスマネージャーには「N-Trig device Not Win8 supported upgrade it」と表示されています。この表示は、N-TrigのNtrigDigi.infファイルに記載されていまして、ドライバーインストール時に何かの条件に一致するとこのようになるようです。 WDDでお見せしたデモアプリが、どのような動きをしていたかを以下に記載します。 アクティベーションのデモアプリの状態には、実行していない(Not Running)、実行中(Running)、一時停止(Suspending)があります。また、以前の実行状態には、終了(Not Running)と強制終了(Terminat)があります。この状態に応じて、タイルのバッジにグリフ(アイコンのような図形です)を表示するというものでした。強制終了(OSが終了させる)した場合に、入力した内容を保存して、次に起動した場合に読み込むという動作もお見せしました。これは、強制終了する場合に、必ずSuspendingイベントが発生することを確認するためのものでした。 ライブタイルのデモタイルを更新するためのタイルAPIを使って、更新することと、ローカルキューを介した更新をお見せしました。また、バッジを数字(1から99)で更新することもお見せしました。ここで説明が不足していたのは、タイルを更新してからアプリが終了した場合のタイルがどうなるかという点です。このケースでは、更新したタイルの中身(タイル自体やバッジ)は残ります。つまり、ライブタイルで更新した内容はアプリのインスタンスとは別にシステム側で管理されているということになります。残ったタイルの更新内容を消去するには、タイルAPIを使って更新内容を空にするなどの操作が必要になります。従って、ライブタイルを使用する場合は、有効期限を忘れずに設定するのが良いと私は考えています。 スプラッシュスクリーンのデモスプラッシュ スクリーンは、パッケージマニフェストに指定した画像がシステムによって自動的に表示されます。アプリの初期化に15秒以上かかる場合に、強制終了となります。このような場合に行うのが、自前でスプラッシュスクリーンを表示することです。アプリの初期化の終了とは、CPの場合はActivateイベントを抜けるタイミングとなります。スプラッシュ スクリーンAPIを使用することで、スプラッシュスクリーンに指定した画像の表示位置やサイズなどの情報を取得できます。取得した情報を使って、自前のスプラッシュスクリーンとして表示する画像などの位置を調整します。デモでは、意図的に背景色を変えていました。これは、指定した画像ではなく自前で用意したことを明示するための処置でした。実際のアプリで、このようなことをしてはいけません。 バックグラウンド オーディオのデモバックグラウンド タスクの利用例として、バックグラウンド オーディオを動作させるデモを行いました。バックグラウンド オーディオを実現するには、パッケージ マニフェストへのバックグラウンド タスクの定義(タスクタイプにオーディオ、スタートページを設定)とコントロールのAudioCategoryの設定とWindows.Media.MediaControlに対するイベントハンドラーの実装を行う必要があります。 バックグラウンド タスクには、タスクを動作させるためのホストプログラムが必要になります。ホストプログラムには、アプリ自身とbackgroundTaskHost.exeの2種類があります。バックグラウンド オーディオは、アプリ自身をホストとしてSystem Control Device の通知を処理するという種類のバックグラウンド タスクになります。そして、バックグラウンド タスクのSDKサンプルからも理解することができますが、backgroundTaskHost.exeがホストできるタスクは、C#、VBやC++で作成したWindowsランタイム コンポーネントだけになります。つまり、JavaScriptで記述したバックグラウンド タスクをホストするには、アプリ自身がホストするしかないということです。これが、SDKサンプルにJavaScript + C# というサンプルが含まれている理由となります。この辺りを時間切れで、WDDでお話しすることはできませんでした。

0