XAML でリキッド レイアウト

リキッド レイアウト (liquid layout) とは、表示領域のサイズによって動的に表示方法が最適化されるようなレイアウトを指します。

もしレイアウトについてとくに意識せずに固定サイズのアプリケーションを実装してしまうと、
ウィンドウのサイズが小さい場合には一部のコンテンツが隠れたり、
逆にウィンドウのサイズが大きい場合には空白ができたりしてしまいます。

ディスプレイの解像度の制限やユーザーによるウィンドウのサイズ変更など、
表示領域のサイズの連続的な変化に対応しなければなりません。

以下では、XAML 系アプリケーションでリキッド レイアウトを実現するためのパターンと実装例を紹介します。

(1) Grid

Grid では、ColumnDefinitions プロパティおよび RowDefinitions プロパティにより、各行・列の幅を指定できます。
固定値のほか、他の行・列との相対値 (1:2 にする場合など) や内部のコンテンツの幅 (Auto) も指定できます。

(2) ScrollViewer

ScrollViewer を利用すれば、スクロールにより全体を表示させることができます。
コレクション データを扱う場合は、ScrollViewer と WrapPanel を組み合わせて使うとよいでしょう。
ちなみに ScrollViewer は、既定で縦スクロールバーが有効、横スクロールバーが無効に設定されています。

(3) Viewbox

Viewbox は、表示領域に合わせて内部のコンテンツを伸縮させることにより、元のレイアウトを保持します。
最も手っ取り早い方法かもしれません。

(4) 最大値・最小値の指定

Viewbox のような伸縮させるコントロールでは、既定では無制限にコンテンツが拡大・縮小してしまいます。
したがって、サイズの最大値・最小値を指定する方法も有効です。

 

これらのパターンを実装する例として、次の WPF アプリケーションを作成しました。

(全体のソースコードは GitHub の LayoutWpf にあります。)

 

ここでは 4 つの表示領域があり、
左上はとくに何も対策しない例、右上は ScrollViewer を使う例、
左下は Viewbox を使う例、右下は Viewbox の横幅に最大値を指定する例です。

各領域では、内部のコンテンツとしてコレクション データを ItemsControl で表示させています。
この ItemsControl の ItemsPanel を WrapPanel に設定しています。

また、この 4 つの表示領域は 2×2 の Grid 上にあり、行も列も 1:1 に分割されています。

このアプリケーションを起動するとこうなります。

起動時の状態

 

ウィンドウのサイズを小さくします。
左上および右上では WrapPanel の列の数が減りますが、
左上では、下部を表示することができません。右上では、スクロールすれば残りが表示されます。
左下と右下では Viewbox に合わせてコンテンツが縮小されます。

小さくした状態

 

今度は、ウィンドウのサイズを大きくします。
左上および右上では WrapPanel の列の数が増えています。
左下では Viewbox に合わせてコンテンツが拡大されるのに対し、右下では Viewbox が一定以上は大きくなりません。

大きくした状態

 

作成したサンプル
LayoutWpf (GitHub)

参照
Grid クラス
ScrollViewer クラス
Viewbox クラス

広告

プロパティ変更とエラー情報の通知 (概念編)

先にプロパティ変更とエラー情報の通知 (実装編) を投稿しましたが、
今回は通知のプログラミング手法について概念的に考えてみます。

まず、従来のいわゆる手続き的なプログラミング手法の場合で、次のようなコードがあったとします。

try
{
    // ある処理を実行する

    // ある処理の実行が完了した場合の処理
}
catch (Exception) // エラーが発生する
{
    // エラーが発生した場合の処理
}

この手続きの中に現れる処理を、観測者と被観測者の 2 つのオブジェクトに役割を分担させるように変更します。
そのためには、被観測者側のコードを次のようにします。

try
{
    // ある処理を実行する

    // ある処理の実行が完了したことを観測者に通知する (通知後の処理は観測者が知っている)
}
catch (Exception) // エラーが発生する
{
    // エラーが発生したことを観測者に通知する (通知後の処理は観測者が知っている)
}

ある処理を被観測者側で実行し、それが完了したら観測者に通知します。
観測者はその通知をトリガーとして何らかの処理を実行します。

これが Observer パターンで、この Wikipedia に載っている図と同様にクラス図を作ると次のようになります。

Observer パターン

 

通知後の処理を関数として渡せるようにするには、プログラミング インターフェイスを次のように変形します。

Observer パターン

 

.NET の場合、イベントを利用することができます。

Observer パターン

 

.NET ではとくに、データのエンティティなどに適用できるインターフェイスとして
INotifyPropertyChanged, INotifyDataErrorInfo が用意されており、
XAML 系テクノロジのデータ バインディングでは、これらを利用してプレゼンテーション層とモデル層における関心事を分離します。
つまり、アプリの本質的なロジックをモデル層に集中させ、プレゼンテーション層は同期的に追従して UI を更新する、
といったプログラミング スタイルを実現できます。

なお、プログラミング インターフェイスの変更については、
Reactive Extensionsの概要と利用方法にも同様の議論が記載されています。

参照
プロパティ変更とエラー情報の通知 (実装編)
Observer パターン
Reactive Extensionsの概要と利用方法

プロパティ変更とエラー情報の通知 (実装編)

XAML 系テクノロジにおけるデータ バインディングは、
プレゼンテーション層とモデル層の間のデータ同期を自動化するプログラミング モデルを実現するための仕組みです。
バインディング ソース (主にモデル層のデータ) では、オブジェクト内で変化が起こった場合にそのことを通知します。

これは Observer パターンの活用例の 1 つです。
Observer パターンについては、プロパティ変更とエラー情報の通知 (概念編) に書きました。

以下では、主に MSDN ライブラリの資料をもとに、バインディング ソースを実装する際の注意点をまとめました。
大きく、プロパティ変更通知とエラー情報通知に分けられます。

 

■ プロパティ変更通知

オブジェクトのプロパティの値が変更される・されたことを通知するには、
INotifyPropertyChanging インターフェイス (プロパティ変更前) および
INotifyPropertyChanged インターフェイス (プロパティ変更後) を実装します。
INotifyPropertyChanging インターフェイスの実装は省略されることもあります。

これらのインターフェイスでは PropertyChanging イベントおよび PropertyChanged イベントを実装することになりますが、
イベント引数の PropertyName には、変更されたプロパティの名前を指定します。
ここで null または空文字列を指定すれば、オブジェクトのすべてのプロパティが変更されたという意味になります。
ただし、実際には null はあまり使わず、空文字列を使うことが多いようです。

以前は、プロパティ内でこれを実装するためにプロパティ名の文字列をコードに埋め込んでいましたが、
.NET Framework 4.5 または Windows ストアでは CallerMemberName 属性を利用することで回避できます。

public class Person : INotifyPropertyChanged
{
    private string name;

    public string Name
    {
        get { return name; }
        set
        {
            if (name == value) return;
            name = value;
            NotifyPropertyChanged();
        }
    }

    public event PropertyChangedEventHandler PropertyChanged = (o, e) => { };

    public void NotifyPropertyChanged([CallerMemberName]string propertyName = "")
    {
        PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }
}

 

⋄ コレクション変更通知

コレクションが変更されたことを通知するには、INotifyCollectionChanged インターフェイスを実装します。
自分で実装しなくても、ObservableCollection<T> クラスを利用すればほぼ十分です。

 

■ エラー情報通知

オブジェクトの中でエラーが発生したことを通知するには、INotifyDataErrorInfo インターフェイスを実装します。
主に、ユーザーからの入力値を検証する場合などに利用されます。
INotifyDataErrorInfo インターフェイスは Silverlight で先に登場しており、解説もこちらのほうが詳しく記載されています。

なお、以前から IDataErrorInfo インターフェイスがありましたが、
これは古い形式で、通知イベントが発生する形式にはなっていません。今後は使われなくなるでしょう。

さて、以下は INotifyDataErrorInfo インターフェイスの実装方法です。

内部でエラーが発生したら、例えば変数などにエラー情報をキャッシュしておき、ErrorsChanged イベントを発生させます。
プロパティ変更通知のときと同様、ErrorsChanged イベントの引数にはプロパティ名を渡します。
ここで null または空文字列を指定すれば、オブジェクトのレベルでエラーが発生したという意味になります。

そして GetErrors メソッドで、実際のエラーのコレクションを取得できるようにします。

HasErrors プロパティでは、エンティティ レベルにもプロパティ レベルにもエラーが存在しない場合に false を返します。
ただし、標準のバインディング エンジンに利用されることはないようです。
通常は、プロパティ名を指定できる ErrorsChanged イベントと GetErrors メソッドを使います。

INotifyDataErrorInfo.ErrorsChanged イベントの説明には、ErrorsChanged イベントを UI スレッドで発生させる、
と書かれていますが、Binding オブジェクトでデータ バインディングを設定してある場合には
UI スレッドでデータ ソースの値が取得されるため、UI スレッドでなくてもとくに問題はなさそうです。

以下は、その他の注意点です。

・GetErrors メソッドで INotifyCollectionChanged が実装されたコレクションを返す場合であっても、
    ErrorsChanged イベントを発生させる。
・GetErrors の戻り値の各アイテムに対して ToString メソッドを呼び出したらエラー メッセージを取得できる。
    例えば、ValidationResult オブジェクトを利用する。

 

INotifyDataErrorInfo インターフェイスの実装方法については以上ですが、
標準のバインディング エンジンの中核である Binding オブジェクトの設定の注意についても記述しておきます。

・ValidatesOnNotifyDataErrors プロパティ : INotifyDataErrorInfo のエラー検知をする場合。
・ValidatesOnDataErrors プロパティ : IDataErrorInfo のエラー検知をする場合。通常は使いません。
・ValidatesOnExceptions プロパティ : 例外を検知する場合。
・NotifyOnValidationError プロパティ : エラーを検知したときに、WPF の場合は UI 要素の Validation.Error 添付イベントを、
    Silverlight の場合は UI 要素の BindingValidationError イベントを発生させる。

これらのプロパティの既定値は、ValidatesOnNotifyDataErrors のみ true で、その他はすべて false です。
Silverlight の ValidationSummary などの一部のコントロールを利用する場合、
NotifyOnValidationError プロパティを true にします。

 

プラットフォーム
.NET Framework
Silverlight
Windows Phone
Windows ストア
Portable Class Library

参照
プロパティ変更とエラー情報の通知 (概念編)
INotifyPropertyChanged インターフェイス
INotifyCollectionChanged インターフェイス
INotifyDataErrorInfo インターフェイス
弱いイベント パターン