先日これまでのXamarin.Formsの経験や、PrismのPageNavigationServiceへの貢献を通して得たノウハウを整理して形にした、KAMISHIBAI for Xamarin.Formsをリリースしました。 前述のエントリーや、Github上のドキュメントでもKAMISHIBAIのメリットについては述べているのですが、少しずつ掘り下げて解説したいと思います。 まずは
- 一貫性を保ったイベント通知
について説明したいと思います。これはXamarin.Formsを素でつかっていると非常に面倒な領域です。つぎの図を見てください。
KAMISHIBAIではPageの状態遷移に伴ってつぎのようなイベントが発行されます。
| イベント | 想定する実装内容 | パラメーター |
|---|---|---|
| OnInitialize | リソースの初期化処理など | 〇 |
| OnLoaded | OnUnloadedで非活性化されるリソースの活性化 | × |
| OnUnloaded | リソースの非活性化 | × |
| OnClosed | リソースの解放 | × |
これらのイベント通知があらゆるPageの状態遷移で保たれていることが、KAMISHIBAIの強みの一つです。
どういう事かというと、通常だと実現困難な次のようなケースでも、一貫して振る舞うということです。
- NavigationPageのNavigationBarやスワイプ、物理バックボタンによる戻る処理
- TabbedPageの選択Tabの変更
- CarouselPageの表示Pageの変更
- 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の実装技術的な方面ではほぼ全てと言って良いでしょう。
このあたりの強い一貫性を保ったイベント通知は、アプリケーション構築の強い味方になると信じています。
