kazuk は null に触れてしまった

C# / .NET 系技術ネタ縛りでお送りしております

カテゴリーアーカイブ: WinRT

Metro Style Application 開発の為の Visual Studio Project Template(1)


Visual Studio 2012 RC には Metro Style Application のためのプロジェクトテンプレートが幾つか含まれています。

これらのプロジェクトテンプレートからプロジェクトを起こしてみての解説を2回ぐらい書きましたが、今回はこのプロジェクトテンプレートの実体がどのように定義されているか、その内容を確認するとともに今後の開発で使うプロジェクトテンプレートの準備などに焦点を当ててみたいと思います。

標準のプロジェクトテンプレートのインストール場所

Visual Studio 2010 RC においてプロジェクトテンプレートの標準のインストールパスは以下の通りです。(Windows 8 RP x64にインストールした場合)

C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ProjectTemplates\CSharp\Windows Metro style

このフォルダを開くと1041フォルダ配下に実際のプロジェクトテンプレート毎にフォルダがあり、プロジェクトテンプレートの実体が格納されています。

imageimage

このファイル群をベースに、プロジェクトテンプレートを修正してもいいですし、プロジェクトテンプレートを新規に作成してもいいでしょう。

Visual Studio SDK によるプロジェクトテンプレートの作成

プロジェクトテンプレートを作成するには簡単な方法としてはある程度作りこんだプロジェクトを元に Visual Studio から [ファイル]-[テンプレートのエクスポート]があるのですが。根がマゾいので簡単な方法は使わずにプロジェクトテンプレートを一から作成する事にしましょう。

この作業を行うには Visual Studio SDK が必要になります。

Download: Visual Studio 2012 RC SDK – Microsoft Download Center – Download Details

をインストールしてください。インストールを完了すると Visual Studio からプロジェクトの作成時に機能拡張配下からプロジェクトテンプレートが作成できるようになります。

image

今回はMetro Style Application の為のクラスライブラリを単体テストプロジェクトと共に生成し、ビルドのカスタマイズ等も(比較的)簡単にできるようビルドのカスタマイズプロジェクトも設定するという形でちょっと規模の大きいプロジェクトテンプレートを作成してみます。

Metro Style Application の為のプロジェクト要件の確認

ここで既存のプロジェクトテンプレートの内容を確認しましょう。プロジェクトテンプレートの中核を担うのは vstemplate という拡張子がついたファイルで、このファイルをもとに関連ファイルが取り込まれてプロジェクトが生成されますので Metro Style Application としての基本的な設定事項を把握しなければ話が始まりませんが、歴代の vstemplate はその詳細まで解説された事は殆ど皆無じゃないかな程度に情報量が少ないので、自分達の手元にあるVSにインストールされた vstemplateを見るのを最初にするのをおすすめです。

標準のプロジェクトテンプレートの ClassLibrary の vstemplate の内容とプロジェクトテンプレートを作成する場合の vstemplate には以下の要素に違いがある事がわかります。

<TemplateGroupID>WinRT-Managed</TemplateGroupID>
<RequiredFrameworkVersion>4.5</RequiredFrameworkVersion>
<TargetPlatformName>Windows</TargetPlatformName>
<RequiredPlatformVersion>8</RequiredPlatformVersion>
<CreateInPlace>true</CreateInPlace>

実際には当然に TemplateID などは違うのですが、そりゃテンプレートが違えばちがうわなで今回はスルーします。

TargetPlatformName や RequiredPlatformVersion 等が明らかに増えていますので、これを持つ vstemplate を作ります。

Metro Style Application の為の csproj 設定

いやー増えてますねー、Any CPU, x86, x64, ARM それぞれに Debug/Release でビルドするので当然ですが。全部ビルドしようとかすると単純に時間は20~30%増しって計算にちょっとgkbr

さて、大きな変更がありますね、vs2010までの csproj では Microsoft.CSharp.targets を見ていた物が $(MSBuildExtensionsPath)\Microsoft\WindowsXaml\v$(VisualStudioVersion)\Microsoft.Windows.UI.Xaml.CSharp.targets を見ています。

XAMLのコンパイルタスクが必要なのはわかるのですが、このターゲットの解決に Visual Studio Version が入るってことは本気に Visual Studio インストールしないと(SDKだけだと)ビルドもできないのかも。ビルドサーバを用意する上でこれはちょっと難点ですね。最低限のExpressでも入れとけばビルドできるといえばそうなのかもしれませんけど。(ビルドしかできないかもしれませんけどね)

細かい詳細は基本的には丸コピー以外の選択肢は殆ど無い気がします、各 Configuration 毎に最低限のビルドオプションを設定したうえでソースはCompile ItemGroupにというのが基本的なクラスライブラリプロジェクトの構造です。

次の段階として、関連するテストを収容するための単体テスト用プロジェクトもこのテンプレートに取り込むのですが、順番にやるのが良いでしょう、ここで一旦 (1) として区切りをつけようと思います。

(1) までのまとめ

とりあえず github に push しときました。

リポジトリはこちら https://github.com/kazuk/MetroAppBase

ここまでの内容のコミットはこちら https://github.com/kazuk/MetroAppBase/commit/28e89e2623d54991cf9bcb57ea69dc5d270f0a29

予習したい人の為に (2) で何をするかという事で MSDN ドキュメントの参照リンクなど

方法 : 複数プロジェクトのテンプレートを作成する

(2)ではMetroスタイルアプリケーションのテストプロジェクトについて調べた上で、このプロジェクトテンプレートに組み込む事でクラスライブラリを作成と同時に単体テストを活用した開発ができる様にしようと思います。

まとめでは無いこと

MS的には Visual Studio 2012から TFS Express を使ってねとか色々あるみたいなんですが、少なくともこれまで経験から 「TFS は肌に馴染みませんでした。」(いいなーと思うところも無いわけではないけど、VSが落ちるとか落ちるとか落ちるとかで寧ろ足を引っ張られる印象の方が強く)というわけでVS2012での自分の開発環境での採用は無い感じです。

VS2012世代で自分の目論む開発環境ですが、基本的には git / github をソース管理のメインに据えてこれをビルドするビルドサーバは TeamCity か Jenkins か検討中、現状は VS2012のUltimateを90日試用期間で使ってますが(OSがCP/RP/RTMと行く流れで再インストールになりながらそれぞれ最大90日使えればまぁお得!)、最終的には Premium 辺りに落ち着くんじゃないかと思っています。

ソース管理の基本が TFS から git/github になる事で自分の開発環境整備(包丁を研ぐ段階)の物が表に出せるし出てしまうので晒しでやっていこうかなとか。git/github に出してる物は MIT ライセンスのつもり(どこに書くんだろう)なのでお好きにパクッテって頂戴。

githubでの pull request とか貰った事ないので、なんか楽しい変更があれば pull request も遠慮なく。

個人事業主になりまして昼間は他のお仕事しながら夜のお勉強タイム確保+お子ちゃま台風上陸という私事もありまして一日一時間も勉強に取れないので遅々として進まずの可能性もなきにしもですが今後うん十年仕事する上での準備なので着実に書いていければなーという感じです。

広告

Metro Style Application Code Samples–XAML Data Binding Samples


Windows 8 Code Samples and Examples in C#, VB.NET, C++, JavaScript

とりあえずインストールした Visual Studio 2012 RC で Metro Style App のプロジェクトを作ると

// The Split App template is documented at http://go.microsoft.com/fwlink/?LinkId=234228

って感じでリンクされている LinkId 234228 でたどり着くサンプルギャラリー。

質はわからないけど量は十分と言っていい気がするし、一覧を眺めてみた限りでは内容も多岐にわたっている気がする。このあたりは Microsoft本気だなと思わないでもない。

日本語での情報提供は翻訳の都合で遅れるのが常なので世界についていく気なら英語だろうがコードだろうが気合で読むのみで色々見るのをおすすめ。龍に乗るなら首根っこ、尻尾掴んでも振り落とされるのが落ちだ。

というわけで、もっとも基本っぽい XAML Data Binding sample をチェックしてみるなど。コンパイル&実行は全く問題なく完了、普通に実行しながらソースを確認することをお勧めです。

チェックの目的は WPF や Silverlight との相違点等を確認しておきたいということなので、 WPF / Silverlight のソースをあまり見たことが無い人はもっとチュートリアル的な物から見たほうが良いかも。

 

Scenario1 ~ Scenario7 までの xaml と xaml.cs が本体と言っていい感じ。

Scenario1.xaml XAMLのデータバインディングの { Binding … Mode=[バインディングモード] } のバインディングモードの TwoWay, OneWay, OneTime の違いを見せようというもの。 WPF / Silverlight との違いは特に見えず。

簡単にさっくり解説すると以下の通り。

TwoWay の場合、テキストボックスに入力した内容はスライダーに反映され、スライダーの内容はテキストボックスに反映される。このような双方向のバインディングを行う場合には TwoWay を使う。もっともよく使うモードだと思う。

OneWay の場合、スライダーの操作はテキストボックスに反映されるけど、テキストボックスの修正はスライダーに反映されない。このような一方向のバインディングを行う場合には OneWay を使う。テキストボックスのような入力を受けるコントロールと結びつけると変に感じるが表示専用の物につなぎ合わせるにはこっちの方がお得というもの。

OneTime の場合、コントロールの初期化時に一発反映したら後はやらないよという物。変更前の値を表示しておきたいという用途には便利だけどそれ以外での局面では全く役に立たない系。

 

Scenario2 は IValueConverter によってスライダー値を F から SUPER STAR! の段階を示す文字列に変換してテキストボックスに変換するもの。 E への変換が無いねとか余計。

この変換は S2Formatter.cs にて宣言されている Windows.UI.Xaml.Data.IValueConverter の実装によって変換されている。

<StackPanel.Resources>
    <local:S2Formatter x:Key=”GradeConverter”/>
</StackPanel.Resources>

で S2Formatter を GradeConverter で宣言、

Text=”{Binding ElementName=sliderValueConverter, Path=Value, Mode=OneWay,
              Converter={StaticResource GradeConverter}}”

で GradeConverter を利用している。 Mode が OneWay なので S2Formatter での変換も一方向しか実装されていない。

S2Formatter.cs の実装内容はあまりマネしてほしくないところ、メソッド内のローカル変数に _ でプリフィックスをつけるとか基本として見たことのないネーミングスタイルなので注意。

 

Scenario3 は Emploee というクラスにデータバインディングするというもの。 Emploee は Scenario3.xaml.cs からMainPageのDataContextとして渡されています。

単純には DataContext に渡したオブジェクトとデータバインディングされますよという内容とみればいいでしょう。

 

Scenario4 は Team.cs で定義された Teams リストの3番目の要素にデータバインディングを行うという物。

Binding のPathシンタックスでの ‘[‘ + インデックス + ‘]’がインデックスが整数(配列ないしはリスト)、その他(コレクション)でバインディングができるという事を示しています。

 

Scenario5 は同じく Team.cs で定義された Teams リストにバインディングしますが、 Border の Background を Team のColor にバインディングすることで背景色を変えるというもの。 Text や Value 以外でもバインディングできるので、見た目をバインディングで変えられるということを示しているだけですね。

 

Scenario6 は同じく Teams にバインディングしますが、ListItem のGroupStyleを介してHeaderTemplate を与えることで、Key 要素ごとにヘッダーを表示するというもの。

var result = from t in teams
             group t by t.City into g
             orderby g.Key
             select new { Key = g.Key, Items = g };

のLINQクエリによってグループ化された物のKeyをグループヘッダーとして表示しています。LINQクエリとグループヘッダテンプレートの合わせ技でそこそこ簡単にできますよってところです。

 

Scenario7は同じくTeams にバインディングしますが、選択要素の削除を実装しています。ハンドラの実装は以下のもの。

void BtnRemoveTeam_Click(object sender, RoutedEventArgs e)
{
    if (ocTeams.Count > 0)
    {
        int index=0;
        if (lbTeams.SelectedItem != null)
            index = lbTeams.SelectedIndex;
        ocTeams.RemoveAt(index);
    }
}

データバインディングですべてが行われていますので単純にコレクションから要素を削除すれば要素が消えますってもの。

選択されてなかったら最初の要素を消すという乱暴な実装に見えますが良いんでしょうか?コピペしないでね?なサンプルは勘弁してほしいですね。

気になるところとしては

<Button x:Name=”btnRemoveTeam” Content=”Remove team”/>

と Click ハンドラの結び付け、コンストラクタで以下を書いてますが、Commandパターンとかは入ってない感じですかね?コードビハインドにコードを書きたくないタイプの人なのでこういうのがずらずらしちゃうのはちょっといやんな感じです。

btnRemoveTeam.Click += BtnRemoveTeam_Click;

 

まとめ

そんなに大きく WPF / Silverlight と異なる印象はありません。名前空間の配置など実装は当然に変わっていますが大きくは変わっていないということが解っただけでした。

テクノロジの特性なのかもしれませんが、周辺がいろいろと冗長です。XAMLなどは説明したい部分が埋没していると思われるぐらいです。何を説明しようとしているのか、それを読み取って見ないと迷子になりますのでポイントをかいつまんで読みましょう。かいつまんで読むことができる人(ポイントのわかってる人)はこのレベルのサンプルは見ないというか必要ないかもな気もしないでもないですけど。

Scenario2 で現れる IValueConverter はお察しの通り大量に書くことになるでしょう。データ値と見た目のフォーマットの変換処理はほとんどの場合 IValueConverter で実装することになります。これの実装の為の項目テンプレートが標準のプロジェクトテンプレートにはありませんので、項目テンプレートを切り出ししておく事をお勧めです。ただしこのサンプルに含まれる IValueConverter の実装は変数名のネーミングがいまいちで普通のコーディング規約にはマッチしないはずなのでもう少し良い物をベースに選ぶか納得いく形に書き換えてから、コーディングのヒントをコメントにふんだんに盛り込んだ項目テンプレートを作るのが良いでしょう。

Visual Studio 2012 にはネーミングルールによる変数名の警告や補正の仕組みは入らなかった模様、必要な人は ReSharper を入れるとルールに沿ってない場合には警告してもらえるし QuickFix で大抵はいい名前に直してもらえますのでこの機会に投資する気ならした方がいいかもしれません。(ちょっとReSharper以外に浮気しようかと思ってVSギャラリー見回してみたのですがグッとくる物は見当たらなかったです)

良いサンプルだとは思いますが、コレクションからの削除の実装が選択されていなければ先頭を消すとか鵜呑みにしてはいけない内容を多分に含んでいますのでご注意を。

Metro アプリケーションテンプレートを読み解く 「新しいアプリケーション」プロジェクトテンプレート


続いて「新しいアプリケーション」のプロジェクトテンプレートを読み解いていきましょう。

image

プロジェクトテンプレートから作成した状態で以下の通りのアプリケーションが作られます。

image

Common 配下は前回の Grid アプリケーションと一緒の気がしますね、クラスライブラリとして共有してしまえば一つ育てれば全部育つという読みは正しい気がします。

DataModel ディレクトリ自体が消えてなくなっていますが BindableBase.cs はあるわけで、好きにモデル作れって事でなくGridテンプレートでの SampleDataSource.cs は実装サンプルとしては重要です。

App.xaml / App.xaml.cs も内容に変化は有りません。

BlankPage.xaml は当然に表示する物が無いのでえらくシンプルになっていて、BlankPage.xaml.cs はLayoutAwarePage の継承ではなくなっています。どうなんでしょう、此処をLayoutAwarePage の派生にしない理由が良く解りません。

xaml 定義をPage から Common のLayoutAwarePage にするには以下、xaml.cs 側のベースクラス変更も行えば普通に動きますので基本としてやっとく方が良いんじゃないでしょうか、DataContext が基本としてDefaultViewModelで見えて ObservableDictionary になっている方が何かとコードも共通化しやすいし。

<common:LayoutAwarePage
    x:Class="FirstPlainApplication1.BlankPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:FirstPlainApplication1"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:common="using:FirstPlainApplication1.Common"
    mc:Ignorable="d">

xmlns:common での記述内容はアプリケーションの名前空間の影響を受けますが、Commonをクラスライブラリにしてしまいそれを参照すれば固定される様になりますね。

実際プロジェクトへの項目の追加で基本ページを追加すると LayoutAwarePage の派生が作られます。

image

<common:LayoutAwarePage
    x:Name="pageRoot"
    x:Class="FirstPlainApplication1.BasicPage1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:FirstPlainApplication1"
    xmlns:common="using:FirstPlainApplication1.Common"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d">

Common をクラスライブラリとして切り離すのはここでちょっと待ったがかかりますね、項目テンプレートとか全部置き換えないといけませんので。まぁ、プロジェクトテンプレート全体を自作するつもりになればたいした話ではないのですが。その気になった人は以下のフォルダの zip を色々いじってみれば良いんじゃないかな。(デフォルトのインストールの場合)

C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\VSWinExpress\ProjectTemplates\CSharp\Windows Metro style\1041

image

プロジェクトテンプレートや項目テンプレートをいじるのが新規環境に対して道具を研ぎあげるという感じの自分なので自分はきっとやりますけどね。

んで、このテンプレートそのものでは LayoutAwarePage も BindableBase も使われていませんので Common をぶちっと削除する事ができます。最少のテンプレートを目指す人はそれも良いでしょう。

使われている要素が少ないのでちょっとした事を試すには良いですが、項目テンプレートで使われている何かをサポートする為の余計なファイルが多いので初心者が道に迷う可能性多々ありな気もしないでもないです。

Metro アプリケーションテンプレート Gridアプリケーションテンプレートを読み解く


というわけで、Metro 開発始めました。 Windows 8 Consumer Preview と Visual Studio 11 Express for Windows 8 を開発環境として利用してアプリケーションを開発する上で、テンプレートから Grid Application テンプレートで開発スタートしてみたので、このテンプレートの基本構成その他読み取った物をつらつらとメモがきしてみます。

プロジェクトのファイル構成

パッと見でCommon, DataModel に多少の C# ファイルがある事のトップに XAML ファイルがあり、XAMLに関連づいた C#ファイルがあります。

image

Common/BindableBase.cs

Common の BindableBase.cs が INotifyPropertyChanged 等データバインディングの為の基本実装をしているようです。INotifyPropertyChanged の実装コードのシグネチャとしては以下のような感じ

protected bool SetProperty<T>(
ref T storage,
T value,
[
CallerMemberName] String propertyName = null)

さっそくC#の新機能が使われていますね CallerMemberName 属性で SetProperty はプロパティ名を引きとっています。

ref T storage で指定されたフィールドに value で指定された値を突っ込み OnPropertyChanged でイベントを発火するというのが基本になってます。 object.Equals で比較して変化の無い場合にはフィールド更新およびイベントの発火をショートカットする様になっています。

object.Equals で比較しているので null チェックが行われてから obj1.Equals(obj2) と同義になりますね。

object Equals( object other ) ですので、object への暗黙変換が発生し、boxing が発生するなんて細かい事に気づいてチューニングする必要は殆どありません。この程度で影響があるとしたらプロパティの連鎖更新が大量に発生する酷いモデルをあなたが作っているという事です。

酷いモデルもあるはずって事でちょっと見てみたのですが、何かがオカシイです。

image

System.Runtime.dll の System.Type をILDASM で見た所、IsClass が無いですよね。

ドキュメントを見た限りでは IsClass は存在する事になっているのですが見当たりません。

IsClass が false であれば object への暗黙変換で boxing が発生するからそれを避けるとかいうコードを書きたくてもどうにもなりません。どうにもならないので次のソースを見る事にします。

Common/BooleanNegationConverter.cs

とりあえずbool値を反転するIValueConverterですねテンプレート内の何処かで使われてる気はしません(検索でヒットせず、コメントアウトしてビルド、実行で問題無し)、うざいと思う人は消しちゃって良いでしょう。ぶっちゃけてノイズだと思います。

Common/BooleanToVisibilityConverter.cs

同じく bool 値をVisibility に変換する IValueConverterで、同様にどこも使ってません。なぜ Common に共通定義してるのか解らない物なので邪魔ならば消してしまいましょう。

Common/LayoutAwarePage.cs

テンプレート内に定義されている各 XAML ページの基本クラスになっています。

いくつかイベントハンドラーが定義されています、GoHome は Frame.CanGoBack が true の間 Frame.GoBack を繰り返すという形で実装されています。

FrameはWindows.UI.Xaml.Controls.Frameで、Metro UI Framework において進む、戻るの一連のUIの進行状況を管理する仕組みを構成しています。(しかし、MSDNのメニューシステム、なんとかならんのでしょうか、日本語でMSDN使うと翻訳できてる部分しかメニューに出てこなくてメニューが全くつながらずで困ります)

このテンプレートでのナビゲーションはこのFrameに一任されていますので正しくFrameを使う事という事が画面遷移に関しての必要事項でありテスト項目となりそうですね。

残念ながらFrameはINavigateを実装していますが、INavigate がカバーしているメソッドセットには CanGoBack や GoBack は含まれていませんのでFakeするのに多少困る面が残りそうです。

Common/RichTextCollumns.cs

Panelを派生したカスタムコントロールによって最終的な詳細ビューで使われるリッチテキスト表示を実装しています。これがここにある意味は「お前らこれぐらいのコントロール自分で書けよ、サンプルをテンプレートに入れてるんだから」って事でしょうね。

完全な表示用コントロールなのでサイズ計算ロジックの置き換えである MeasureOverride ArrangeOverride が主体で後は関連プロパティを実装しているだけですね。

サイズ計算ロジックとしては単純に LoadContent が返した内容をRichTextBlockOverflowとして見て OverflowContent があれば次のブロックを生成する事の繰り返しです。

この実装の中には仮定が含まれている事がコードの見た目で解ります。

まずRichTextBlockOverflow へのキャストです。キャストは戻り値の型が違えば失敗しますが LoadContent が帰した物をノーチェックでキャストしていますので、DataTemplate.LoadContentはRichTextBlockOverflow を返さなければなりません。

そこのところに防御的なアプローチは全く見えませんので全くの専用コントロールという事が見て取れます。

DataModel/SampleDataSource.cs

いわゆる ViewModel と Model のハイブリッドな物がここに実装されています。アプリケーションにする場合には何かしら意味のあるデータにする為にまず此処に手を入れる事になるでしょう。

Model に相当しているのは SampleDataSource クラスです、ここで他のクラスのインスタンスを単純にnew しまくってデータモデルを構成しています。何かしらのサーバないしはデータを持っている物を検索して new する様に変更すればアプリケーションは意味あるデータを表示する様になるでしょう。

SampleDataGroup と SampleDataItem が共通基底 SampleDataCommon から派生されていてそれぞれグループと要素を表現しています。

SampleDataGroup が ObservableCollection<SampleDataItem> を保持し、SampleDataItem はコンテンツとなる文字列を持っています。SampleDataCommon は共通となるタイトルやイメージを保持しているわけでそれほど面倒な構造ではありません。

SampleDataCommon が Common 配下で定義された BindableBase から派生されていますのでINotifyPropertyChanged でのプロパティ更新通知がサポートされます。

アプリケーションとしては完全な参照系なので SampleDataSource であるモデルには更新系が存在しません。サンプルとしてはいかがなものかとか言いませんよね、自分で考えやがれと突き放されただけです。

所でフォルダがDataModel で名前空間がData って気持ち悪くねぇ?気持ち悪い人はテンプレートを直しやがれが例題なのでしょうか?

App.xaml と App.xaml.cs

xaml 側は Common/StandardStyles.xaml をResourceDictionaryとして取り込んでいるほかAppName としてアプリケーション名をリソース定義しているだけです。アプリケーション固有のリソース定義したければここで好きにしやがれって事でしょう。

App.xaml.cs がアプリケーションの開始処理としての非常に重要な事を実装しています。

「コードビハインドにコードを書いたら負けだと思っている」な自分としては非常に気になるわけですが、実装内容としては OnLaunched でモデルからのデータローディング(PreviousExecutionState が Terminated であれば Suspendからの復帰も)と rootFrameの生成と初期Navigate、 OnSuspending でのアプリケーション状態の保存なわけで絶対にアプリケーション固有な領域なので致し方ないかなな気持ちもあります。

他の xaml と xaml.cs

基本的な表示等はすべて xaml側での記述になっておりxaml.csでデータをコネコネは基本しない構造になっています。xaml.cs での記述内容は OnNavigateTo で画面遷移してきた時にDataContextに結び付けられている DefaultViewModel にデータを突っ込んでいる事と Click での FrameへのNavigate 発行だけです。

思いつく例題とか

  1. Common 名前空間に含まれる実装をクラスライブラリに切り出ししなさい。

    特にBindableBase はこの先あなたのお供として延々育てていくべきコードになるでしょう。これをあなたが育て続けられる環境に移すか他のMVVMインフラを導入するかの選択時期は早々に訪れるはずです。どっちにしても作ったアプリケーション毎に微妙に異なる Commonを延々メンテナンスするのが嫌ならCommonの実装が共有できるようになっていなければなりません。
  2. SampleDataSource.cs に相当するソースを自動生成するテキストテンプレートを記述しなさい。

    1をやると意味が出ますが各種データモデルの細かい修正でプロパティの所の記述をチマチマ SetProperty 呼び出しするとか書いてると疲れますのでもっと軽い仕組みにしましょう。

    Office XML を解釈してExcel 方眼紙からデータモデルの実装が自動で起こせるとかすると Excel でプログラムが書けます(やめましょう)し、テキストテンプレートでSQL Server のスキーマを参照すればDBテーブルを射影するのに必要なデータモデルが生成できる事になります。

  3. Suspending / Lounching をちゃんとして、Suspendされて終了された時に元の場所に戻る様にしようよ。