Caliburn.Microフレームワークを使用した軽量WP7アプリケーション開発（パート1）

こんにちは



名前が示唆するように、この記事はCaliburn.Microフレームワークについて啓発されます。 このフレームワークをWP7プラットフォームの開発者に使用すると、有用な情報、それが解決するタスク、その長所と短所を提供できることを示します。



しかし、この記事全体で答えようとする最も重要な質問は、WP7のかなり確立された王国で、何らかのフレームワークの形で別の中間層が必要な理由です。



このトピックに興味があるなら、猫へようこそ。

準備する

この記事の資料は、主に既にWP7開発に精通している人々に興味があると思います。 したがって、VSなどでプロジェクトを作成する方法については説明しませんが、すでにこれを知っているか、他の多くのオープンソースから学ぶことができると仮定します。



独立した実験には、次のものが必要です。

1. VS 2010 SP1
2. Windows Phone SDK 7.1
3. Caliburn.Micro

テストに使用するWindows Phoneアプリケーションプロジェクトを作成します。

序文ではなくMVVMまたはChapter

WP7アプリケーションは、一連の画面/ページ（Windows Phoneページ）で構成され、これらの画面は、DB内のレコードなどのデータを表します。 問題は、このデータとUI要素を画面上で接続する方法です。



ADグループのユーザーのリストを表示するとします。 画面タイトルはグループの名前になり、本文にはユーザーのリストを含むリストボックスがあります。 これはどのように行うことができますか？ シンプルだが最良の解決策は、ページの本文（* .xaml.cs）に何かを書くことです：

// PageTitle - TextBlock PageTitle.Text = GroupConnector(GroupId).Name; // Users - ListBox Users.ItemsSource = GroupConnector(GroupId).Users;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは機能しますが、このアプローチには多くの欠点があります。それらのいくつかを次に示します。

1. 設計と保守が難しい。 コードとUI要素は密接に関連しているため、開発プロセスが複雑になります。 UIとその配信コードを同期するには追加のリソースが必要です。 また、このようなコードは、特にこの例のように2つではなく多くの要素を含む場合、部外者が受け入れるのは困難です。
2. ひどく並列化。 つまり 使用しているデータを知っているプログラマーは、既成のUI実装がなければコードのパフォーマンスをチェックできません。 UIと機能コードの作成にさまざまな人が関与している場合、この問題はさらに悪化します。
3. 単体テストを書くのは難しいです。 UI要素に関連付けられたコードは、単体テストが難しいため、 xamlとその周りのインフラストラクチャ全体が必要です。ユニットテストが別のプロジェクトにある場合やUIの準備がまだ整っていない場合（TDD準拠の場合）、高速ではなく、問題があります。

上記の問題を解決するには、 Model-View-ViewModelパターンを使用します。 彼については多くのことが書かれているので、詳細については触れません。 詳細については、このアプローチについて読むことができます。たとえば、 ここまたはハブラーで少し



つまり、MVVMアプローチの意味は、Viewをプレゼンテーションから爆発させることです。 つまり 適切に設計されたシステムでは、最終的なUIがどのように見えても、ビューは変更されません。 特定の実装に関連付けられていないデータの高レベルのビューを反映します。



WP7アプリケーションを開発するとき、MVVMアプローチはどこでも使用されます。 独自の決定を下すものもあれば、フレームワーク（ PrismやMVVM Light Toolkitなど ）の形で既製の開発を使用するものもあります。 Caliburn.Microはまさにそのようなフレームワークです。 つまり これは、一連の素敵なパンを使用したMVVMアプローチの実装です。

はじめに

さて、プロジェクトを作成し、必要なCM（以降、Caliburn.Microを毎回書かないようにこのショートカットを使用します）ライブラリをプラグインしましょう。 これを行うには：

1. プロジェクト内にフォルダーCaliburnMicro（または他の名前）を作成し、そこにファイルCaliburn.Micro.dll 、 Caliburn.Micro.Extensions.dllおよびSystem.Windows.Interactivity.dllをCMディストリビューション（bin \ WP71 \ Release）からコピーします。
2. 参照に新しいファイルを追加します。

CMを機能させるには、 アプリケーションアプリケーションのメインクラスにBootstrapperをインストールする必要があります。 このラッパーは、アプリケーション状態のすべての変更（アクティブ化、非アクティブ化、遷移など）を担当し、最も重要なこととして、ViewModelクラスのすべてをここで説明しますが、これについては後で詳しく説明します。



SampleBootstrapperクラスであるPhoneBootstrapperの 下位クラスを作成して、プロジェクトに追加しましょう。

 public class SampleBootstrapper : PhoneBootstrapper { private PhoneContainer _container; protected override void Configure() { _container = new PhoneContainer(RootFrame); _container.RegisterPhoneServices(); AddCustomConventions(); } private static void AddCustomConventions(){} protected override object GetInstance(Type service, string key) { return _container.GetInstance(service, key); } protected override IEnumerable<object> GetAllInstances(Type service) { return _container.GetAllInstances(service); } protected override void BuildUp(object instance) { _container.BuildUp(instance); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このクラスを混乱させないでください;それ以降はConfigureメソッドのみが必要になります。



次に、 SampleBootstrapperを使用する必要があることをアプリケーションに伝える必要があります。 これを行うには、 App.xamlファイルを編集して、Bootstrapperへのリンク以外のすべてを削除する必要があります。

 <Application x:Class="CaliburnMicroSamples.App" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:CaliburnMicroSamples="clr-namespace:CaliburnMicroSamples"> <Application.Resources> <CaliburnMicroSamples:SampleBootstrapper x:Key="bootstrapper" /> </Application.Resources> </Application>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

なぜなら Launching 、 Activatedなどのイベント処理がSampleBootstrapperを引き継ぐようになったので 、以前にこれに関与した古いメソッドをApp.xaml.csから削除できます。 つまり Appクラスはよりシンプルになります。

 public partial class App { public App() { InitializeComponent(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてが以前のように見える場合、つまり、コンパイルして実行します CMに関連する変更の前に、つまり、アプリケーションがクラッシュした場合、すべてを正しく実行し、さらに先に進むことができることを意味します。その後、ミスが発生し、次の実験を続行する前に修正する必要があります。

最初のViewModel

サードパーティのフレームワークとViewModelを使用せずに、このViewModelは次のように作成されます。 ViewModelを実装するクラスが作成され、それへのリンクがPhoneApplicationPageページala内のDataContextに渡されます。

 DataContext = ViewModelsConstructor.GetViewModel(this);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

xamlでも同じことができます。 これはすべて、ViewModelおよびView要素（UIコントロール）のバインディングが機能するために必要です。



CMでは、このアプローチは少し異なります。 コンテキストを独自に設定する必要はありません。フレームワークを使用します。 また、一般にDataContextおよび* .xaml.csファイルを使用する必要はありません。これにより、特にViewやxamlからさらに離れて、理想的なMVVMにさらに近づくことができます。 CMは宣言型アプローチを使用してVM（ViewModel）を記述しますが、これについては後で説明します。



アプリケーションの作成後、デフォルト画面のMainPageがすでにあります。 CMを使用してViewModelを実装するクラスを作成してみましょう。 これを行うには、 xaml拡張子を持つファイルの名前と同じ名前でクラスを作成し、 ViewModelの最後に（つまりMainPageViewModelクラス）、同じ名前の別のファイルに配置し、 ScreenクラスCMから継承します（すべてこのクラスに既にカプセル化されています現在のページを操作するためのメソッドですが、これについては後で説明します）。 つまり クラスは次のようになります。

 public class MainPageViewModel : Screen { public MainPageViewModel() { } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後にやるべきことは、Bootstrapper'eにVMを登録することです。 これを行うには、 SampleBootstrapperクラスのConfigureメソッドで、次のコードを追加します。

 _container.PerRequest<MainPageViewModel>();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そしてそれだけです！ ViewModelが作成され、作成時にCMによってMainPageページにリンクされます。 PerRequestは、MainPageページが要求されるたびにMainPageViewModelクラスが作成されることを意味します。 Singletonメソッドを使用する場合、MainPageViewModelクラスは後続のすべてのリクエストで再利用します。



バインディングプロパティの動作を見てみましょう。 これを行うには、VMクラスにPageTitleプロパティを追加し、「 サンプルページ 」などの値を割り当てます。

 public class MainPageViewModel : Screen { public string PageTitle { get; set; } public MainPageViewModel() { PageTitle = "sample app"; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、アプリケーションを実行します。 ページタイトルが変更されました！ これは、CMがViewModelとViewの関係に関するすべての質問を受け取り、PageTitleプロパティをその名前でリンクしたためです（xamlでも呼び出されます）。



Text="{Binding PageTitle, Mode=TwoWay}"



直接リンク命令（ala Text="{Binding PageTitle, Mode=TwoWay}"



）を介したおなじみのバインディングも機能しますが、それなしでははるかに簡単であることを認めText="{Binding PageTitle, Mode=TwoWay}"



。



これはかなり単純な例でした。この点については、より複雑なバインディングオプションとCM機能については後で説明しますが、今のところは続行します。

ナビゲーション

ADのユーザーとグループの例を覚えていますか？ グループに関する情報を表示するために、グループが何であるかに関する情報をどこかに送信する必要があると仮定することは論理的です。 簡単にするために、それを彼女の名前にします。 これはもちろんVMの「どこか」です。なぜなら、 彼女は、必要なデータをビューに返すために、このグループが何であるかを知る必要があります。



この問題を解決する標準的な方法は、パラメーターを使用したナビゲーションです。 つまり このような画面（この場合はユーザーのリスト）に移動したいと言い、パラメーターとしてグループ識別子を渡します。 通常、これは次のように行われます。

 NavigationService.Navigate(new Uri("/GroupPage.xaml?name=Administrators", UriKind.Relative));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、GroupPage.xamlページのOnNavigatedToで、このパラメーターは構築によって取得されます。

 var name = NavigationContext.QueryString["name"];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、モデルを実装するクラスに（たとえば、コンストラクターを介して）渡され、次にDataContextに渡されます。



同意してください。そのような単純なタスクの最も美しい解決策ではありません。



もう1つの一般的な方法は、 PhoneApplicationService.Current.Stateを使用して共有データを交換することです。

 PhoneApplicationService.Current.State["name"] = "Administrators";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または、単にApplicationクラス内のグローバル変数を介して、そのインスタンスの利点をApplication.Currentを介してどこからでも取得できます 。



一般的に、これはすべて非常に曲がっています。 最後の2つの例は、特にこれを行う標準的な方法がある場合に、画面間でデータ共有を使用するのはばかげているため、良くありません。 最初の例は、途中でタイプミスをするのが非常に簡単であるため悪いです。この値を（多くの場合はさらに悪いことに）NavigationContextから引き出し、その後すべてをどこかに転送する「殻」も満足できません。



そして、CMでそれを行う方法は次のとおりです。

 _navigationService.UriFor<GroupPageViewModel>() .WithParam(x => x.Name, "Administrators") .Navigate();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GroupPageViewModel -MainPageViewModelと同様に、パブリックプロパティNameを使用して作成されたVM。

 public class GroupPageViewModel : Screen { public string Name { get; set; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

_navigationServiceは、 INavigationServiceを実装するオブジェクトです。これは、 Screenクラスから継承され、 画面間を移動するために使用されるVM内で取得できます。 WithParamメソッドを使用すると、宛先ページでVMプロパティを設定できます。 INavigationServiceは、標準のNavigationServiceのラッパーです。これには、すべての機能が含まれており、追加機能が追加されています。



MainPageViewModelクラスのINavigationServiceインスタンスを取得する方法は次のとおりです。CMはINavigationServiceオブジェクトをMainPageViewModelコンストラクターに渡すだけです。

 public class MainPageViewModel : Screen { private INavigationService _navigationService; public string PageTitle { get; set; } public MainPageViewModel(INavigationService navigationService) { PageTitle = "sample app"; _navigationService = navigationService; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

利点は明らかです：

1. 開発者がVMにパラメーターを渡すために記述する必要があるコードはほとんどありません。
2. なぜなら INavigationServiceは宛先VMクラスによって特化されており、パラメーターはこのクラスに関連して設定されます。これらのパラメーターを設定するときにミス/シールを行うことは不可能です。 このようなコードは単にコンパイルされません。
3. なぜなら インターフェイスが送信されると、INavigationServiceの動作が十分に濡れます。これは、単体テストを記述するときに非常に便利です。
4. コードはUIから完全に解放されています。

短所：

1. 複合型をこの方法で渡すことはできません。 ここには魔法はありません、CMはWP7にないことを行うことができません。 独自の機能に基づいています。 実装は、NavigationServiceの標準実装（最初の例の実装）に基づいています。 ただし、シリアル化を使用してCMソースを少し調整すると、これを回避できます。

INotifyPropertyChanged

ADからユーザーを離れ、別の例を示します。 メールプログラムがあり、そのページの1つに、未読メッセージのバッジがある利用可能なメールボックスのリストがあるとします。



前の例との主な違いは、データが静的ではなく、時間の経過とともに変化する可能性があることです（未読メッセージのカウンター）。 つまり 未読メッセージの数に責任があるプロパティがあると想像する場合、それが変更されたことをViewに通知するメカニズムが必要です。 この目的のために、通知メカニズムはINotifyPropertyChangedインターフェイスの実装に基づいて使用されます。 このアプローチを実装する標準的な方法は次のとおりです。

 public class MailboxPageViewModel : INotifyPropertyChanged { private int _unreadCount; public int UnreadCount { get { return _unreadCount; } set { _unreadCount = value; NotifyPropertyChanged("UnreadCount"); } } public event PropertyChangedEventHandler PropertyChanged; public void NotifyPropertyChanged(string propertyName) { if (PropertyChanged != null) PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、 UnreadCountプロパティが変更されると 、イベントPropertyChangedがここで 通知されます。これにより、値のViewが再読み取りされます。



このコードには2つの欠点があります。

1. プロパティ名は名前で設定され、これにはエラーが伴います。
2. UIスレッドからではなくプロパティを更新すると、無効なクロススレッドアクセス例外でアプリケーションがクラッシュします。

1つ目はExpressionを使用して解決され、2つ目はDispatcher.CheckAccess（）を介して現在のスレッドで操作を実行する可能性をチェックし、操作を実行できない場合は既にUIスレッドで再起動します。 難しいことではありませんが、それでも私の自転車、特にCMではそれについて考えました。 上記の例を置き換えるコードは次のとおりです。

 public class MailboxPageViewModel : Screen { private int _unreadCount; public int UnreadCount { get { return _unreadCount; } set { _unreadCount = value; NotifyOfPropertyChange(() => UnreadCount); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

CMメソッドのNotifyOfPropertyChangeは、説明されている問題を解決し、「すぐに使用可能」です。



CMでは、INotifyPropertyChangedを実装し、オブジェクトのコレクションを保存するために使用されるObservableCollectionクラスの別のクラスの非UIスレッドからのアクセスに関する同様の問題を解決するBindableCollectionクラスも見つけることができます。 つまり BindableCollectionを使用する場合、コレクションメソッドがどのストリームで呼び出されるかを心配する必要はありません。

墓石

開発者がWP7用のアプリケーションを作成する際に抱える問題の1つは、 Tombstoneの状態を終了した後にアプリケーションの状態を復元する必要があることです。



WP7では、 PhoneApplicationService.State 、 IsolatedStorage、およびその他のソリューションがこれに使用されます。 追加のラッパーなしで作業することはそれほど便利ではありません。 CMはエレガントなソリューションを提供します。 VMデータを廃棄標識で保護したい場合は、VMという名前と終了ストレージのクラスを作成するだけです。 ユーザーのリストを持つこの例のクラスは、 GroupPageViewModelStorageと呼ばれ、 次のようになります。

 public class GroupPageViewModelStorage : StorageHandler<GroupPageViewModel> { public override void Configure() { Property(x => x.Name) .InPhoneState() .RestoreAfterActivation(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

StorageHandlerは、VM内にデータを保存するための戦略を実装するCMクラスです。 この例では、PhoneApplicationService.State内にNameプロパティを保存し、ページのアクティブ化とともにデータを復元する必要があると言います。



なぜなら CMは何も知らず、モデルに保存されているデータを知ることができないため、それらは個別に保存する必要があります。 これを行うには、適切なBootstapperメソッド（起動、終了、非アクティブ化など）内にアプリケーションのロジックに一致する必要なシリアル化/逆シリアル化コードを追加します。

最初の部分の終わり

ここで、私はこの記事が最初に思っていたよりも多くなっていること、そしてもっともっと書く必要があることに気付きました。 これは入門的なレビュー記事としては十分すぎるため、2つの部分に分けることにしました。



続行するには...