検索
特集

特集：Longhornアプリケーションの構築方法：FTP Online（5/6 ページ）

Microsoftからリリースされた最近のOSとは異なり、Longhornは開発者に対して明確なインパクトを提供するだろう。ここでは、簡単なLonghornアプリケーションの構築方法について学んでいく（日本語訳：澤田侑尚） 。

[Brent Rector，FTPOnline] PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ | 次のページへ

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　これまでに我々は、Longhornアプリケーションおよびコンポーネントを構築する方法について学んできた。以下では、XAMLファイルを.NETクラスに変化させるときに、ビルドシステムが何を行うのかを含め、XAMLファイルの詳細について見ていこう。

　XAMLファイルは１つのクラス宣言である。アプリケーション定義ファイルは、アプリケーションのApplicationオブジェクトのクラスを定義するXAMLファイルである。しかし一般的には、XAMLドキュメントはクラス定義を行うファイルである。XAMLファイルの定義によって生成されるクラスは、XMLドキュメントのルート要素名に関連付けられているクラスを継承する。デフォルトでは、ビルドシステムは生成されるクラス名としてXAMLベースのファイル名を使用する。

　次のステップは、アプリケーション操作のための定義ファイルの生成である。Type属性がApplicationDefinitionに設定されているItem要素は、Applicationオブジェクトを定義するXAMLファイルの名前を指定する。言いかえれば、この要素はアプリケーションに関するエントリポイントを含むXAMLファイルを指定する。Longhornプラットフォームは、このファイルに定義されるMSAvalon.Windows.Applicationを継承する型のインスタンスを生成し、アプリケーションの開始と終了および、ナビゲーションを管理させる。

　以下のXAMLファイルは、マークアップを使用してプロジェクトのApplicationオブジェクトを定義している。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　ほとんどのLonghornアプリケーションは、ナビゲーションベースのアプリケーションであるため、標準のNavigationApplicationオブジェクトを再利用することになるだろう。StartupUri属性の値を変更するだけで、ほとんどのナビゲーションベースのアプリケーションに対して、このアプリケーション定義ファイルを再利用できる。

　例えば、HelloWorldApplication.xamlファイル内に以前のアプリケーション定義を記録している状況で、前述のHelloWorld.projを使用する場合、ビルドシステムは次のクラス宣言を生成する。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　名前空間は、プロジェクトファイルのDefaultClrNameSpace宣言から得られ、宣言されたクラス名はベースファイル名と同じになる。また、宣言されたクラスは、XAMLファイルのルート要素により表現されるクラスを継承する。

コードの最適化

　次は、属性を使って生成されたコードの最適化である。XAMLファイルでルート要素を宣言するとき、ルート要素の属性を使用して生成されるクラス宣言の名前を制御できる。ここで使用できる属性には次の3種類がある。

（a）名前空間のプリフィックス定義：プリフィックスをDefinitionという名前空間に関連付ける

（b）Language属性：Definition名前空間内で定義され、XAMLファイルのインラインコードに利用されるプログラミング言語を指定する

（c）Class属性：Definition名前空間内で定義され、生成させるクラスの名前を指定する

　 なお、LanguageおよびClass属性を使うためには、Definition名前空間に対するプリフィックスの定義が必要で、伝統的なdefプリフィックスが使用される。また、指定する名前に「.」が含まれる時には、ビルドシステムはDefaultClrNameSpaceを用いた名前のプリフィックスを付けなくなる。

　例として、HelloWorldApplication.xamlファイルの内容を次のように変更してみる。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　これにより、次のようなクラスが生成される。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

同じクラスでのアプリケーションコードとマークアップを組み合わせる

　ほぼすべてのアプリケーションで、ユーザーインタフェースを指定するマークアップのほかに、ボタンクリックイベントのイベントハンドラや仮想メソッドの書き換えなど、何らかのコードを記述する必要がある。では、ナビゲーションを持たないアプリケーションの生成による、アプリケーションコードとマークアップを組み合わせる方法について考えてみよう。

　ここで私が強調したいのは、非ナビゲーションベースのアプリケーションの作成を強要する理由が、現実にはないことだ。ただし、別のページに移動することがないナビゲーションベースのアプリケーションを作成することは可能だ。このようなアプリケーションを作成するには、同じクラスにコードとマークアップを混在させなければならないので、例題としては最適である。

　非ナビゲーションベースのアプリケーションを作成するには、MSAvalon.Windows.Applicationを継承し、OnStartingUpメソッドを上書きする、カスタムクラスを定義する必要がある。アプリケーション定義ファイルはプログラムが使用するアプリケーションオブジェクトクラスを宣言する。このため、非ナビゲーションベースのアプリケーションは、上書きするOnStartingUpメソッドを同じクラスで定義する必要がある。

　非ナビゲーションベースのアプリケーションのアプリケーション構成ファイルは、次の２つの例外を除けば、ナビゲーションベースのアプリケーションの定義ファイルと同じアイテムが含まれる。

  • ルート要素は、NavigationApplicationではなくApplicationとなる
  • アプリケーション構成ファイルはアプリケーションクラスのOnStartingUpメソッドの実装を含む、または参照する必要がある

　1つのクラスを実装するためにマークアップとコードを使用する必要があるので、ソースコードファイルをXAMLファイルに関連付ける方法を説明する必要がある。

　マークアップを使用してアプリケーションの一部を開発し、従来型のプログラミング言語でアプリケーションの別の部分を開発するといったことはよくあることだ。そのため、ユーザーインタフェースの部分とロジック部分を、別のソースファイルとして分離することを強く推奨する。

　Definition名前空間で定義されたXAMLのCodeBehind要素をXAMLファイルのルート要素に追加し、コードビハインドファイルとも呼ばれるソースコードファイルの名前を指定できる。ビルドエンジンは、XAMLの宣言をマネージドクラスへとコンパイルし、コードビハインドファイルをマネージドクラス宣言にコンパイルする。ここでややこしいのは、２つのクラス定義が、同じクラスの宣言の一部であることである。

　以下は、非ナビゲーションベースのアプリケーションクラスを生成するXAML定義である

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　このアプリケーション定義ファイルに関しては、２つの注意点がある。

  • Language属性はコードビハインドファイルがC#ソースコードを含んでいることを示している
  • CodeBehind属性はソースファイルの名前がCodeBehindMySample2.xaml.csであることを示している。

　これに対応するソースビハインドファイルはコラム5のようになる。

コラム5：ソースビハインドファイルのビルド

　コードビハインドファイルのクラス宣言における、部分的なキーワードに注意してほしい。 このキーワードは、コンパイル時に、このクラス定義が同じクラスのほかの定義とマージされることを明記している。これにより、１つのクラスにおける部分的な定義を、それぞれの別のソースファイルで提供し、コンパイル時に生成されるアセンブリで、それらを１つのクラス定義にまとめることができる。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

前のページへ | 次のページへ

© Copyright 2001-2005 Fawcette Technical Publications

ページトップに戻る