Xamarin.Forms(以下 XF とします)を本格的に開発に導入してみようと思ってるんだけど、その時のプロジェクト(アセンブリ)構成はこんな感じかな、というのを考えてみた。

コンセプト

  • XF を使う理由は、Viewのワンソース化よりも DataBinding機構が使えること
  • いざという時逃げられるように XF への依存を最小限にする
  • iOS/Android 対応アプリ開発のこと、他は知らん
  • MVVM で PCL で、PCL のところを最大化する

プロジェクト構成図

 角丸四角形がプロジェクトを、矢印は依存を示す。

左から説明。

XF.Android, XF.iOS, XF.Core

 Xamarin.Forms ソリューションを作成するとテンプレで作られるプロジェクト群。
 XF.Core でプラットフォームに依存しないView(ボタンとか)を、XF.Android/XF.iOS でプラットフォーム固有のView(スライドメニューとかNotificationなど)を提供する。
 これらは BindableProperty を介して ViewModel とデータバインディングする。
 XF は他に、ServiceLocator や MessageCenter を提供するが、それらは使用しない(ロックインを防ぐため)
 結局この案では、「XF=View層のみ」となる。

App.Core

 アプリのView以外の共通部分のプロジェクト。ViewModel と Model を含む。
 ViewModel から View へシグナルを送るために “XFではない” Messengerを使う。(MvvmLight とか Prism とかから引っこ抜いてくればいいかな?)
 Model にはビジネスロジックのみを記述し、通信処理やデータI/Oなどのプラットフォーム共通なAPIはModelから直接使い、プラットフォーム固有の機能は、ServiceInterface を使う。
 ServiceInteface は、ServiceLocator によって App.Android/iOS から実体が Inject される。ServiceLocator は “XFではない”…以下略
 Rx を使うので、たぶん Model のメソッドの返り値は全部 IObservable になります。

App.Android, App.iOS

 プラットフォーム固有のAPI層。例えば GPS とか、アプリ連携とか、アイテム課金とか。ServiceInterface に定義されている Interface を実装するところ。

懸案

  • PUSH通知受信とか、本来は Platform Specific APIs で担当したいが、プラットフォームの都合で、View で受信しなければならない機能の落としどころ。
  • App.core をもっと分割した方がよい「ViewModelからAPI呼ばないよね?」とか「App.AndroidからModelにアクセスできるのがイヤ」とかを厳格に制限しようと思ったら分割した方が良さそう。
  • Model から左側を全部 IObservable 化しようと思っているが、Callback→Observable変換をModelでやるか、API層でやるか。"ビジネス"ロジックではないので、右側かな。
  • XF.Core にどれだけ詰め込むか。画面レイアウトもXFでできるだけ頑張る、画面遷移フレームワークもXFで用意する、か?Sketches がどこまで活用できるか?

さて、どんなもんでしょ?

Xamarin
Android
iOS

published

Ads

Read more!

amay077

Microsoft MVP(Xamarin). フルリモートワーカー. Geospatial Mobile app developer. Love C#.

amay077 amay077