2018年1月3日水曜日

App を Windows Timeline に対応させる 1/2

まとめ

  • Windows Timeline は対応が簡単な割に得られる物が大きい
  • ただ、アプリにより向き不向きがある

Windows Timeline、最近のWindows 10 Insider Preview で使えるようになりました。UWP App をこのWindows Timelineに対応させる開発者向けガイドも出ています。今回自分のApp を対応させる機会があり、作業量が少ない割には効果が大きかったので紹介しようという趣旨の記事です。



Windows Timeline とは


Windows 10 の次期大規模更新(RS4?)に入ると言われている新機能です。2018年1月時点では Insider Preview Build 17063 で使うことが可能です。アプリではWebブラウザ Edge、フォト等が対応しています。宣伝になりますが、拙作の画像掲示板ブラウザ F10 も対応しています。

F10 Image bbs browser
https://www.microsoft.com/store/apps/9nblggh1ntrd

なお、API 自体はWindows 10 Fall Creators Update (FCU) から入っており、SDKもFCUレベルの16299から既に対応しています。このため、現時点でもWindows Timeline 対応アプリをビルドし、ストアに上げることが可能になっています。


Windows Timeline
タスクバー左から3番目のアイコン、またはWin+Tabで表示されます


※以降、仕組みについては推測込みです。ウソが混じっているかもしれません。またIP 17063 の動作を元に書いているため、今後変わるかもしれません。


対応に必要な作業と得られる効果


仕組み・方法を説明する前に、得られる効果を書きましょう。Timeline に対応するためにアプリ側でやる事は主に二つで、


  • 適切なタイミングでUserActivityをOSに投げる
  • Protocol Activation …Uriを使った起動・アクティベーションに対応する


前者はかなり楽に済みます。後者は…アプリに依るのですが、いわゆるブラウザ系、URLのように文字列一本でアプリの状態を記述できる場合は楽に対応できるのではと思います。ここは後でまた触れます。

これらを行うだけで、アプリの操作履歴の同期がデバイス間で、OS組み込みの洗練されたUIで可能になります。PC+ノート+タブレット…PC複数持ちが当たり前の昨今、簡単に作業状態をデバイス間で引き継げるのは使ってみると大変に便利です。

この操作履歴の同期、Timeline無しで自分でやるのは結構手間でして…

  • Roaming Folder を使ってデバイス間で同期する…Appの履歴DBから一部をRoamingFolderに書き出し、変更を検知してDBに取り込む等
  • Project Romeを使う…リモートデバイスを列挙し履歴データを送受信する仕掛けをRemote AppServiceで作る

等を行う事になります。どちらもある程度安定動作させるにはそこそこ工数がかかります。拙作のブラウザ F10ではこの両方を実装してあるのですが、それに比べると今回のUserActivity を使ったWindows Timeline への対応は圧倒的に簡単、そしてユーザビリティは優れています。お得過ぎる。


右上の検索ボックスからインクリメンタルサーチが出来ます。便利。
検索対象になるのはVisualElements.Title と Appの名前で、AdaptiveCardの中は見てくれないようです。
この例ではVisualElements.Titleにスレ名+板名+BBS名をまとめて登録していますが、表示しているのはAdaptiveCard になっています。


同じMicrosoft Account を使うデバイスにFall Creators Update のシステムが居る場合、
UserActivityはこのようにActionCenter上に表示されます。
クリックするとTimeline同様にAppが起動します。
FCUから登録したUserActivityは、他の17063 システムのTimeline上に表示されます。


他のデバイスで登録されたUserActivityは、右上にそのデバイス名が表示されます。



Windows Timeline の仕組み


アプリケーションはOSに対し、自分の状態を「UserActivity」という単位で投げます。
OSはそのアプリ毎の「UserActivity」を時系列に並べて表示します。それが「Windows Timeline」です。

ユーザーがWindows Timeline 上のタイルをクリックすると、OS はUserActivity内のプロパティ ActivateUri をパラメータにしてアプリを起動又はアクティベートします。

UserActivityを「どのタイミングで」OSに投げるかはアプリ設計者に任されています。Webブラウザなら新しいタブを開いた、Officeならドキュメントを開いた、という操作の節目でUserActivityを発行するものが多いようです。

OSは、この投げられたUserActivity を一台のローカルマシンだけではなく同じMicrosoft Account でログインしている複数のシステムで共有します。この同期、Project Rome と呼ばれる Microsoft Graph ベースの仕組みを使っているようです。このため、Microsoft Graph に対してRESTで直接叩く事により、プラットフォーム非依存で使う事が可能…というように見えます(ただ、Timeline の「表示」自体は別にアプリが必要でしょう。Android ならば Microsoft Launcher あたりが適任っぽいですが。また、Rome系のAPIはGraph上だとBeta扱いのが多いので使っていいのか少し微妙)。


UserActivity 


UserActivity、色々プロパティはついているのですが、まずは一発表示してみたい時に必須なのは以下二つです。


  • UserActivity.ActivationUri … Appをアクティベートするときに使うUri
  • UserActivity.VisualElements.Title 名前 表示・検索に使われます(後述のAdaptiveCardを使う場合表示はそちらになる)


ActivationUri は一番大事なもので、ユーザーがTimeline 上のタイルをクリックするとOSはこれを使ってAppを起動します。

UWP Appでは、App 毎に独自のActivation Protocol をOSに登録することが出来ます。
例えばF10 が入っている環境ですと、Win+Rの名前をつけて実行、で

ddlgf10://a.4cdn.org/a/thread/166549698.json&view=post

とするとF10が起動し、そのスレが開きます。
これは、

  1. OSは ddlgf10:// をプロトコルとして認識し、(AppxManifestで指定する)
  2. パラメータをF10に渡し、
  3. F10 はOnActivate でそれを受け取り処理する(というコードを自分で書く)

という仕組みになっています。Windows Timeline はこのActivationUriを含むオブジェクトUserActivity を折々のタイミングでOSが記憶し、リストとして表示するという仕掛けになります。


Timeline への向き・不向き


上で説明したように、このTimeline の核は


  • アプリの状態…アプリが使うリソースも含めて…が、一行のUri で示される


事にあります。これが出来ないアプリの場合、あまり役に立てる事ができないです。

例を挙げると、

・F10 の場合… これはブラウザアプリです。Web上の画像掲示板のスレッドを取得し、XAMLでレンダリングします。
このため、アプリの状態は「表示するスレのURL」+「F10上の表示形式オプション」で完全に記述することが可能です。
そしてこれは、システムユニークでは無く…どのシステムでも共通に(ネットに繋がれば)使用可能です。リソースはネット上のスレだからです。

・画像ブラウザの場合
例えばピクチャライブラリ上の画像 hoge.jpg を表示する場合を考えます。これをURLとして持ち、UserActivityとして登録する事は可能でしょう。ただ、このリソースはローカル…このデバイス上でのみ参照可能であるため、他のデバイス上でUserActivity をWindows Timeline に表示する意味がありません。
こういう場合、Timeline 上に表示するActivity としては不適切かもしれません。
逆にリソースがクラウド上にある場合…例えば画像がOneDrive上にある場合はTimelineで扱うにはピッタリでしょう。
他にもブックリーダー等、OneDriveとTimelineとの食い合わせはかなり良いです。OneDrive上の本のUri+リーダーでの読書位置、を合わせた物をUriとしてUserActivityに入れれば、かなり良い感じになりそうです。

・ゲーム
ゲームの場合、状態をマシンAからBにポンと渡して引き続き遊べるのは魅力かもしれません。ただ、状態の区切りをどこに置くかという問題と、状態をUriとして一本にシリアライズできるのかという。Uri が長さどれくらいまで行けるのかはわかりませんが、あまり無理はしない方がいい気はします。

次の記事では、F10 を Windows Timeline 対応させた実作業の様子をコード例を挙げて書いてみます。

2018年1月1日月曜日

あけましておめでとうございます

あけましておめでとうございます。
本年も宜しくお願い致します。

…この記事、あけおめの体で去年を振り返ろうという趣旨です。
昨年のトピックを発生順に並べてみますと…

Xamarin に手を出した  (2月)


Xamarin.Android を使ったApp Wheel World Clock for Android をリリースできました。
http://ddlgjp.blogspot.jp/2017/05/wheel-world-clock-android.html
元々はWin8/WinPhone8.1, UWP用に出していたアプリです。
F10 for Xamarin.Forms ...は少し動いた所で手が止まっています。無念。

Win10 Mobileを諦めた (4月)


Windows 10 Mobile について
http://ddlgjp.blogspot.jp/2017/04/windows-10-mobile.html
ムリダナ

Microsoft MVP for Windows Development を受賞した (6月)


(*´▽`*)ウラー 
http://ddlgjp.blogspot.jp/2017/06/microsoft-mvp-for-windows-development.html
受賞のベネフィット、特典には色々あるのですが、今の所一番楽しいのはMVP専用のメーリングリストです。濃い話がドコドコ流れてきてとても良いです。


ただ、後半は個人的な事、家族の事(故郷の父に介護が必要になるという…都会に出て働いてるおじさんなら誰もが通ると聞いてはいましたが私にも来ました。今は落ち着いておりますが)もあり、中々開発活動に力を入れられなかったなという所があります。

今年は…まずは3月にRedmond・Bellevue で開かれるMVP Global Summit に出られるのが楽しみです。また、Xamarin.Formsと.NET Core, serverでも遊びたいナーと思っています。

2017年11月18日土曜日

Microsoft Docs を寄ってたかって直す

UWP App を開発していると、UWP やWinRT API のドキュメントをMicrosoft のWebから検索し調べるのは必須の作業になります。そのドキュメントが腐っていてつい舌打ちしてしまう事は無いでしょうか?チッ……僕は良くあります。

しかし今では、名も知らぬ誰かを呪う前に有効な選択肢があります。GitHub でPull Requestを送り、自分でドキュメントを修正する事が可能になってきています。
最近この修正を行う機会があり、案外ラクにできたので…その手順を簡単に説明する事で、Microsoft Docs を直す人が増えるとイイナーという趣旨の記事です。


はじめに


Microsoft Docs へのContribution についてのドキュメントは
https://docs.microsoft.com/ja-jp/contribute/
に完備されています。判らない事は全部こちらに載っているはずです。ただ完全過ぎて全部読むのも大変なので、適度に端折っているのが今回の記事になります。


  • 最初に、GitHub のアカウントが必要です。
  • やり取りは英語になります。


※この記事、以降GitHub に慣れている人には今更な話が多いです。


Microsoft Docs の文書を表示する


この1年程で、これまでMSDN Documents として整備されていた文書の大部分は新サイト Microsoft Docs に移行しています。


Microsoft Docs トップページ


コンテンツ自体はMarkdown(のGitHub拡張)で記述されており、GitHubで管理されています。そして、一部の文書についてはユーザーがPull Request(以降PR、変更要求)を送ることが可能になっています。

そういった文書は、画面の右カラムに「Edit」ボタンがついています。文書によっては右カラムでは無く、真ん中のコンテンツエリアのセクション毎に「Edit」ボタンがついている物もあります。

このEdit ボタンをクリックすると、GitHub上の当該コンテンツのページに飛びます(ボタンの名前に反して、この時点では表示だけで編集は始まりません。気軽にポチっていいです)。このボタンが表示されていない場合、現在の所その文書にPRを送ることはできません。後で触れます。


Edit ボタンが右カラムに表示されている例
ちなみにウィンドウをもう少し狭くすると左上に移動します
Acrylic material


セクション毎にEdit ボタンが表示される例
Windows.ApplicationModel.Core.CoreApplication



GitHub 上での作業


ソースの表示


Microsoft Docs 上の文書に対応する、GitHub 上のソースが表示されます。


GitHub 上の Acrylic ソース


編集


編集を始めるには、右上の鉛筆アイコンをクリックします。
GitHubのMarkdown エディタが表示され、編集が可能になります。
画面上部に説明が出ているように、この編集作業は作業者(あなた)のリポジトリの中に作成されるブランチ(この画像の例ではMicrosoft/windows-uwp)に対して行われます。
プレビューで確認しつつポチポチ書きましょう。


Markdown エディタ
タブ切り替えでプレビューを表示できます



編集が終わったら画面の一番下までスクロールします。
Propose file change のフォームに変更のタイトルと説明を書きます。ボタンをクリックすると、Create Pull Request の画面に飛びます。

ファイル変更の提案
簡潔なタイトルと内容の説明を書きます



Pull Request の作成


先ほど行った編集前・後の比較が表示されます。諸々確認の上で覚悟が出来たらCreate Pull Request ボタンを押して作成です。
このタイミングで、

  • 自動的に自分のリポジトリ内にブランチが作成(フォーク)され、
  • そこで編集が反映され、
  • その差分がPull RequestとしてMicrosoft側に送信

と物事が一気に進みます。今迄は基本自分の中だけでの作業でしたが、ここでポチっとした以降は担当者に通知が飛び、他の人との共同作業になります。

なお、簡単な編集・修正では、基本的にはこのリポジトリ上での自動フォークを使ってほしいようです。普通にローカルにブランチ作って編集してSyncして…というのはまだあんまりのようです。


Pull Request作成画面



Pull Request の処理


以降は、処理が進む様子をPull Request のページで確認します。

基本的には、


  • 共通のレビュー担当者がPRの書式等をざっくり確認し、
  • 次にそのドキュメントの担当が中身を確認し、
  • OKならマージされて完了!

という流れです。大体数日から1週間~10日くらいで終わる感じです。また、マージされてから実際のMicrosoft Docs のWeb側に反映されるにはさらに数時間掛かります。


PRの処理フロー
これは以前に私が上げた、Acrylicのページのカラーブラシの名前間違ってるから直したよというPRです



編集できる文書・できない文書


上でも触れましたが、Edit ボタンが表示されていない文書にPR を送ることはできません。
2017年11月現在では、UWP App、WinRT APIについてはen-us 、英語ページはほぼ全てEdit ボタンがあり、PRを送ることができます。しかし日本語ページは全て未対応です。

これは文書のジャンルによって状況が違います。例えば .NET や Outlook では、日本語に対する修正も可能になっています。


Outlook では日本語直してキャンペーン中だそうです。
https://www.facebook.com/MVPAwardProgram.JP/posts/1476999755669677

日本語のちゃんとした説明もあります。人力翻訳には温かみがある…
https://github.com/OfficeDev/outlook-dev-docs.ja-jp/blob/live/CONTRIBUTING.md


なお、編集できる・できないについて特にまとまったディレクトリ等があるわけでは無く、その文書にEdit ボタンがあるかどうかで判断して下さい、という事のようです。





2017年11月14日火曜日

F10 updates for Win10 Fall Creators Update

F10 image bbs browser を更新しました。
現時点での最新版は 11月12日リリースの ver 1.5.400 / 1.4.400 になります。

F10 image bbs browser
https://www.microsoft.com/store/apps/9nblggh1ntrd

なお、F10 のVersion 1.1, 1.2, 1.3, ... は それぞれ Win10 のバージョンに対応しており、お使いのWin10 バージョンに合わせてダウンロード・インストールされます。

  • F10 v1.1.x - Win10 1507
  • F10 v1.2.x - Win10 1511 (November Update)
  • F10 v1.3.x - Win10 1607 (Anniversary Update)
  • F10 v1.4.x - Win10 1703 (Creators Update)
  • F10 v1.5.x - Win10 1709 (Fall Creators Update)

コマンドライン起動のサポート / Support Command-Line Activation


コマンドライン・又は「名前を指定して実行(Win+R)」からF10 を直接起動できます。


  • F10 <enter> - launch F10
  • F10 2chan/img - launch F10 and open img
  • F10 futaba/may - launch F10 and open may
  • F10 4chan/a - launch F10 and open /a/


To open the board by parameter, the board should be added as favorites at first.
パラメータで指定できるのは、お気に入りに登録している板です。
既にF10 が起動している場合はここで指定したカタログ表示に切り替わります。

なお、FCU でのコマンドライン起動サポートについては当ブログで記事にしています。

Fall CU - コマンドライン・Win+Rからの UWP App起動
https://ddlgjp.blogspot.jp/2017/11/fall-cu-uwp-app.html





起動の高速化 / Speed up startup time


以下の変更により、起動が少し早くなりました。ただv1.4 - Creators Update だと最後の効果が無いため、良く判らないかもしれません。





メールアドレスの表示 / Showing mail address at posts view


レスにメールアドレスが設定してあった場合、表示します。
何で今まで入れていなかったのか今となっては定かではないです。

Fluent Design のサポート


v1.5 はFCUのAPIを使った上品な実装です。
v1.4 は今まで通り、直接Visual Layerをいじる実装です。


Wheel World Clock updates for Win10 Fall Creators Update

世界時計アプリ Wheel World Clock を Windows 10 Fall Creators Update(以下FCU) に合わせて更新しました。
Wheel World Clock は以下のシステムでお使い頂けます。今回はWin10 FCU用のみの更新です。


  • Windows 8.1
  • Windows Phone 8.1
  • Windows 10 PC, Mobile, HoloLens, etc
  • Android 5.0 以上



Wheel World Clock for Windows
http://apps.microsoft.com/windows/app/wheel-world-clock/1e591002-4ffa-4d49-b8e7-4d82f1211d16

Wheel World Clock for Android
https://play.google.com/store/apps/details?id=com.ddlg.wwcd


コマンドライン起動のサポート / Support Command-Line Activation


コマンドライン・又は「名前を指定して実行(Win+R)」で「WWC」<Enter>で起動します。


実はAcrylicも有効なのですが透明度が低いので
言われてもよくわからない



2017年11月5日日曜日

Fall CU - スプラッシュスクリーンをすっとばして起動速度を上げる

意識低めのFall Creators Update ガイド二つ目です。
FCUから、スプラッシュスクリーンの表示設定にAttirbute「optional」が追加になりました。

Windows Platform Uservoice の意見が採用された(貴重な)例でもあります。

Splash screen for UWP apps should be optional
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/9333255-splash-screen-for-uwp-apps-should-be-optional

使い方はとても簡単で、Package.appxmanifest のスプラッシュスクリーン定義でOptional="true"とするだけです。
参考のために、Package.appxmanifest の例を下に示します。24行目がそれです。

丁寧に言うと、

  1. AppのMinVersion を 16299(FCU)以降に設定する
  2. Package.appxmanifest のPackage Element にネームスペース xmlns:uap5="http://schemas.microsoft.com/appx/manifest/uap/windows10/5" を追加する
  3. エレメント uap:SplashScreen に 属性 Optional="true" を追加する

です。

Optional="true" の効果


注意したいのは、これは「スプラッシュスクリーンをOFFにする」機能では無いことです。スプラッシュスクリーンを「Optional に」するよ!という機能です。
どういうことかというと…
アプリケーションの初期化が終わった時点でスプラッシュスクリーンが即閉じる、という動作になります(なのでスプラッシュスクリーンは「オプショナルな」動作だという事なのでしょう)。
このため、optional="true"であっても…アプリの初期化自体がモタモタしていると結局スプラッシュスクリーンはたっぷり表示されてしまいます。

「初期化」とはどのフェーズを言うのか…経験的には、「このスプラッシュスクリーンの扱いに関しては」App.xaml.csのアプリケーションクラスを抜けてページ表示に行った所で終わり、という感じに見えます(仕様で出ているかもしれませんが調べきれていないです、すみません)。一旦ページ表示まで行くと、例えばPage の OnNavigatedTo で幾ら時間がかかったところで今回のスプラッシュスクリーン表示には影響しません。

実例を動画で示します。


このアプリはVisual Studio 2017 のUWP Blankテンプレートほぼそのままです。
左から

  1. UWP App 既定(optional=false)
  2. optional=true
  3. optional=true, ただしApp.xaml.cs のOnLaunchedでディレイ1秒追加

です。
1) 一番左は、おそらくWindows 標準の電卓と同じ動作に見えます。Blank テンプレートそのままで初期化に時間大してかかっていないので、この状態でもスプラッシュスクリーン表示は一瞬で終わります。
2) は今回のoptional=true の場合です。即App画面に行っているのが分かります。
3) はtrueだけどウェイト1秒入っている場合です。この場合スプラッシュスクリーンはきっちりその分表示され続けるため、optional=trueの意味が全く無いという悲しい結果になっています。


※ 動画は TechSmith Camtasia で作っています。Microsoft MVP 特典として使わせてもらっています。こういった説明、チュートリアル用のスクリーンキャプチャからの動画作成には超便利です。アリガトウ(*´▽`*)




Fall CU - コマンドライン・Win+R からのUWP App 起動

Windows 10 Fall Creators Update (以下FCU)から、UWP App 側に少し変更を入れることでコンソールからUWP App の起動が可能になりました。
Package.appxmanifest で定義するエイリアス名での起動、またパラメータ・カレントディレクトリのパスの取得ができます。




コンソールから起動と言われても…そんなに使わないんじゃん?僕らヤングはGUI世代じゃん?と思われるかもですが、実は「ファイル名を指定して実行」でも使う事が可能です。
Win+R、で名前入れればApp一発起動!というのは割と魅力と思うのですがどうでしょう?
あそこは履歴も残るので個人的にはスタートメニュー本体より使用頻度が高いです。


みんな大好きWin+R
ちなみにdevmgmt.mscはデバイスマネージャ、
appwiz.cplはアプリケーションの追加と削除



使い方

ここでは、 Visual Studio 2017 でUWP App をBlank テンプレートから作り始めた想定でコンソールからの起動を追加してみます。

1 プロジェクトのMinVersion を16299以上に設定する





 今回の機能はFall CU以降のみで使える機能です。MinVersionをFCU, 16299 に設定する必要があります。

2 Package.appxmanifest でアプリケーションのエイリアス名・エントリポイントを設定する



※今回の内容はVisual Studio のマニフェスト デザイナからは設定できません。ソリューション エクスプローラー上で Pacakge.appxmanifest を右クリック → 「コードを表示」 からXML を直で編集します。

Package.appxmanifest を全部貼りました。一部切り出されてもエレメントの関係が分かりづらいので。
まず、一番上のPacakge エレメントにネームスペースuap5 を追加します。 xmlns:uap5="http://schemas.microsoft.com/appx/manifest/uap/windows10/5" です。
次、下の方のApplication エレメント を探します。この子要素にExtensions を追加し、その中に今回のuap5:Extension Category="windows.appExecutionAlias" を追加します。26~37行です。

  • Executable は、このアプリの実行ファイル名…普通はプロジェクトのアセンブリ名です。
  • EntryPoint は、このアプリのアプリケーションクラス名です。テンプレそのままだと大体「アプリ名.app」ですね。
  • uap5:AppExecutionAlias Alias は エイリアス名です。ここで「App1.exe」とすると、Win+Rやコンソールでは「App1」で起動します。また、このエイリアス名はuap:AppExecutionAlias の中で複数指定できます。


3 App.xaml.cs にコマンドライン起動の受けを追加



ここまでで、「起動」はするようになります。ただ、スプラッシュスクリーンで止まってしまいます。
これは、まだコンソール起動時のハンドラを書いていないためです。



App.xaml.cs に、この OnActivated を追加します。
UWP App ではApp起動時 OnLaunched にまず飛んでくるのはご存知と思います。ただこれは「通常起動」…スタートメニューからポチっと起動した場合の話です。

そうでは無い各種起動はOnActivated で扱います。今回のCommandlineやCortanaのVoiceCommandのような別口…裏口?起動は全部こちらに書きます。

上のコードにあるように、

  • Arguments ... 起動時に渡されたパラメータ文字列
  • CurrentDirectoryPath ... 起動時のカレントディレクトリ(後述)
  • ExitCode ... 呼び側に渡す終了コード

等を使用・設定できます。
Arguments は、そのとおりパラメータなのですが…一つ注意として、おしりに必ずスペースが一つ入ります。"abc" と渡すと、Argumentsに入ってくるのは"abc "です。
ExitCode は呼び側に即返ります。以下のスクリーンキャプチャは、上のExitCodeのコメントを外した上で.cmd から起動し、ErrorLevelを表示している例です。

最後に、渡されたパラメータを表示するためにMain.Xaml と Main.xaml.cs をちょっと弄りましょう。


これで完成です(*´▽`*)!
コマンドラインやWin+Rから起動してみてください。
また、すでに起動している所にもう一度実行しても表示が更新されるはずです。OnActivated は起動・アクティベートどちらでも通り、どちらもOnNavigatedToを通すのでこうなっています。



古の%ErrorLevel%とかそういう世界



「カレントディレクトリ」?


少し気を付けたいのは、取得できる「カレントディレクトリ」のパス名です。
例えばコンソールでc:\hogehoge に居る場合にアプリを起動すると「c:\hogehoge」が返ります。
じゃあそのディレクトリ内のファイルをFindFirstで列挙して云々、とついやりたくなるのが人情ですが…
UWP App の場合、それは基本出来ません。

UWP App の場合、Appがアクセスできるのは
  • App固有のフォルダ
  • ユーザーがFolderPickerで指定したフォルダ
  • その他Manifestで指定された特定のフォルダ

のみである!という鉄の掟があります。App Container のサンドボックスですね。
このため、文字列でフォルダの名前を渡されてもあんまり使いどころがありません。
他のWin32 Appにパススルーで渡すとかその程度でしょうか。