nuits.jp blog

C#, Xamarin, WPFを中心に書いています。Microsoft MVP for Visual Studio and Development Technologies。なお掲載内容は個人の見解であり、所属する企業を代表するものではありません。

KAMISHIBAIセルフ プロモーション:一貫性を保ったイベント通知

f:id:nuitsjp:20170813232926p:plain

先日これまでのXamarin.Formsの経験や、PrismのPageNavigationServiceへの貢献を通して得たノウハウを整理して形にした、KAMISHIBAI for Xamarin.Formsをリリースしました。 前述のエントリーや、Github上のドキュメントでもKAMISHIBAIのメリットについては述べているのですが、少しずつ掘り下げて解説したいと思います。 まずは

  • 一貫性を保ったイベント通知

について説明したいと思います。これはXamarin.Formsを素でつかっていると非常に面倒な領域です。つぎの図を見てください。

f:id:nuitsjp:20170813233720p:plain

KAMISHIBAIではPageの状態遷移に伴ってつぎのようなイベントが発行されます。

イベント 想定する実装内容 パラメーター
OnInitialize リソースの初期化処理など
OnLoaded OnUnloadedで非活性化されるリソースの活性化 ×
OnUnloaded リソースの非活性化 ×
OnClosed リソースの解放 ×

これらのイベント通知があらゆるPageの状態遷移で保たれていることが、KAMISHIBAIの強みの一つです。
どういう事かというと、通常だと実現困難な次のようなケースでも、一貫して振る舞うということです。

  1. NavigationPageのNavigationBarやスワイプ、物理バックボタンによる戻る処理
  2. TabbedPageの選択Tabの変更
  3. CarouselPageの表示Pageの変更
  4. ModalStackの物理バックボタンによる戻る処理

これらを見ると、画面遷移イベントだけではない(INavigationが絡まないものはNavigationじゃないという意見もあるので)ため、画面遷移イベントというよりは、Page状態変更イベントといった方が良いでしょう。

1.~3.については、PageをPushする際にBehaviorを外部からインジェクションするという、私が勝手に「Injection Behavior of outside」と呼んでいるパターンを利用して実現しています。このあたりのコードです。

NavigationPage、TabbedPage、CarouselPageにはそれぞれ専用のBehaviorをインジェクションしています。例えばNavigationPageではPoppedイベントをハンドルして適切に処理するNavigationPageBehaviorをインジェクションしています。

また4.については、ApplicationのPopModalイベントをここらへんでハンドルして処理しています。

これらはほぼXamarin.Forms.INavigationを薄くラップするNavigatorクラスを中心に実現していますので、MVVM系の機能を利用せずとも、Navigatorクラス(とApplicationService)だけ利用するという選択肢もありです。これら(と周辺クラス群)が

  • 一貫性を保ったイベント通知
  • 複合Pageへの再帰的なイベント通知
  • 型安全な遷移パラメーター

を実現しているので、KAMISHIBAIの実装技術的な方面ではほぼ全てと言って良いでしょう。

このあたりの強い一貫性を保ったイベント通知は、アプリケーション構築の強い味方になると信じています。