Xamarin開発でMvvmCrossとF#使って開発してるのでその辺もろもろと

1. XamarinとMvvmCrossとF#と

2. 自分について
宮坂雅彦
@omanuke
主に株式会社トレードワークスという会社で金融向け
のソフトを作成
F#大好き
でもモナドとかよくわかってない

3. アジェンダ
• 今回やってるものサラッと説明。
• MvvmCross使ってみてあれこれ。
• F#のおすすめ。
• HTML5とのソース共有
• 独自レイアウトツールについてさらっと。
• Xamarinについて所感。

4. 今回やってるもの構成
• サーバーはWebAPI
• VM以上をF#で作成
• C#でアプリケーションスタートアップと
UI周り
• フレームワークとしてMvvmCross
• ViewのレイアウトはAutoLayoutが糞っ
ぽい難しいのでXAMLライクな独自レ
イアウトツール作成
サーバーWebAPI
サービス
ViewModel
UIViewController
レイアウト
MvvmCross
AppDelegate
F#
C#

5. Xamarin
• C#でiOS/Androidなど含めクロスプラットフォーム開発でき
る環境
• ベースはMono。元MonoTouch・MonoDroidといわれてい
たもの。
• ネイティブアプリを開発できる。iOSはAOTコンパイル。
AndoirdではJIT。
• Mac向けもある。まだ成熟してないらしい…
• MSもがっつり協力してる模様

6. MvvmCross
• iOS、Android、WindowsPhone、WindowsStoreApp、WPF
など様々なプラットフォームに対応したMVVMフレームワーク。
• バインディングの他、サービスの登録、それをDI的に使うなど
アプリケーションフレームワーク的な仕組みも。
• ネイティブな機能を抽象的に扱えるプラグイン機能なども(使っ
てないのでよくわかりません)。

7. MvvmCrossを使う上で調べたところ
• アプリケーション全体の構成
• バインディングどこまでできるのか
• サービスの登録や利用、DI機能あるのか
• ナビゲーション含む画面の単位とVMとの関係
• それに絡んでタブビューでどう使えるのか
• Viewの中に子ViewなどVMとバインディングしつつ部品化で
きるのか
• コレクションの表示はどうなるのか

8. アプリケーション全体の構成
• MvxApplication-PCL側でServiceの
登録やStartup画面登録など。
• Setup-NativeUI側でMvxApplication
の初期化など含むもろもろの初期化。
それらのカスタマイズフック。
• AｐｐDelegateなどからSetup.Initialize
呼び出してIMvxAppStartをResolveし
てStart。
MvxApplication
登録
Start時に
生成
RootVM
Setup
AppDelegate
RootView
Controller
Start
Initialize
VM元に
生成

9. バインディングどこまでできるのか
• INotifyPropertyChangedでのプロパティバインディングとその
Converterによる変換。
• コマンドバインディング。
• ObservableCollection使ってのコレクションのバインディング。
• UIButtonのTitleなどプロパティじゃないものにもできる拡張あ
り。
• VMの中のVMなどネストしたVMに対してプロパティパス指定
してバインド(一昨日知りました(-_-;))。

10. サービスの登録や利用、DI機能あるのか
• Mvx.RegisterSingleton<IHoge>(()=>new Hoge())などある
インターフェースに対する具象クラスを登録して、使うときに
Resolveしてひっぱってこれる。
• 開発時やテスト時にサーバーにリクエストするものの代わりに
モックをRegistしとくなど。
• Mvx.Resolve<IHoge>としてひっぱってきたりコンストラクタイ
ンジェクションなどでDIすることもできます（ほかのパラメータ
渡したいときはInitメソッド使う）

11. ナビゲーション含む画面の単位とVMの関係
• VMが画面1ページとしか表示出来ないのなら色々めんどくさいと
思っていたけれど、VMからUIViewController引っ張って何とでも
なりそう。
• VMとUIViewControllerを結び付ける手段はネーミングコンベン
ションやらその型のViewModelプロパティを定義するなど色々。
• Mvx.Resolve<IMvxTouchViewCreator>.CreateView(viewMode
l) as MvxViewControllerでVMより該当のUIViewControllerを
ひっぱる。
• 普通のUIViewControllerとMvｘViewControllerの混在とか問題な
い（はず）。

12. タブビューでどう使うのか
• タブのサンプルあるのでそれもとに解決。さっきのVMから
ViewControllerを引っ張る方法はそれからソース追っかけて
探したはず…
• ざっくりいうとタブとして表示したい画面のもととなるVMをどっ
かから引っ張ってきてそれ元にViewController作って
UITabBarControllerのViewControllersにセットするなど。
• これ含めハンバーガーメニューなどのやり方のサンプルなど
もググれば出てくるはず。

13. Viewの中に子ViewなどVMとバインディングしつつ
部品化できるのか
• さっきも言ってたようにできる。VMの中にVMネストもできるので部
品化も可。
• UI側は各VMに対応したViewControllerを定義して小分けするも
よし、親のViewControllerだけ定義して子のVMにバインドするも
よし。プロパティパスだけ合えばおけー。
• 各VMに対応したViewController作るなら各々のViewController
の中でBindingSetを定義して使用。
• 今回諸事情でネストした各VMに対応するViewをUIViewとする必
要があったため、ルートのBindingSetをUIViewに渡してプロパ
ティパス合わせて使用してる。VMの階層構造とUIの階層構造は
関係ない。

14. コレクションの表示はどうなるのか
MvxTableViewCell
• MvxViewModel継承したものがはいってるObservableCollection
をMvxTableViewSourceおよびその派生クラスを介して
MvxTableViewCell継承したものに結び付けてバインドできる。
• GetCellあたりでVMに応じたCellの作成を振り分けることで
DataTemplate的なことができる（はず）。
• VMに応じて高さが可変なCellはDelayでBindされるのとHeightを
返すタイミングが合わず自前でVMのないように応じた高さを計算
してかえさないといけなかったような気がします…（結局試してな
いかも）

15. MvvmCrossのよいところ
• 一通り、アプリケーションのコードを共有する仕組みはある。
• 一番使われてる?
• ドキュメント・サンプルが充実してる。動画もあるんですが、だ
るくて見てません…
• カメラや地図などネイティブの機能を抽象的に使えるプラグイ
ン機能もあるのでプラットフォーム展開したい人は便利そう
（使ってないのでよくわかりません）

16. MvvmCrossの悪いところ
• ビヘイビアとかない？のでXAMLer的には不満?
• iOSではバインディングとかC#で書かないと。
• バインディングの記法がやたらありませんかね…Tibetとか
Swissとか。歴史的な経緯?
• XamarinFormsとかまともになってくるといらない子になる?
• まだUnifiedAPIに対応してない?ので来年2月のアプリ登録が
64bit必須になるのに対応できるのか不安・・・

17. F#についてざっくり
• MS製の.NET向け関数型言語
• OCamlライクな文法
• 静的型付け
• 関数型とオブジェクト指向のハイブリッド
• デフォルトイミュータブルだが副作用を許容
• Actorや非同期処理など組み込み
• モナド的な仕組みもある(ComputationExpressions)

18. F#の良いところ
• モデルの定義や業務ロジックを書きやすい。
• コード量少なく、バグも少ない。
• 非同期処理や入力待ちなどが混在する状態遷移をそのまま
記述可。
• javascript化してスマホやWebもワンソース化。
• Xamarinの中の人も推してくれてる。

19. モデルの定義や業務ロジックを書きやすい
• 代数データ型（Discriminated Union)、レコード型、タプルなど
を使ってモデルの定義をクラスだけで表すよりもわかりやすく
記述できる。
• それに対する処理もパターンマッチを分かりやすく書ける。
• 処理も型推論使ってコンパクトに書ける。C#だとタプル使おう
とすると泣ける。
• 数値に単位をつけてより厳密に扱える仕組みもある。
• F#はとても良い業務記述言語です。

20. コード量少なく、バグも少ない
• 先ほどのコンパクトなモデル記述や型推論、関数の合成など
を使うことで、無駄な記述のない密度の高いコードが書ける。
• 同じロジックを書いた場合、C#の30%ぐらいの量になるかと。
• ヌルリを起こさない仕組みなどが最初からあり、デフォルト状
態変更ができないので、バグの原因となる副作用があるコー
ドの箇所が特定される->副作用あることに意識的になる。
• C#でも副作用のないコードはかけるけどやはり書きにくい。
C#はデフォルト副作用あり。F#はなし。

23. 非同期処理や入力待ちなどが混在する状態
遷移をそのまま記述可
• asynchronous workflowsという仕組みを利用。await/async
みたいなもの。
• Aからあるイベントが起きたらBという状態に遷移して、そこで
あるイベント起きたらCに遷移したりAに戻るなどの状態遷移
をA,B,Cを対応したコードブロックとしてそのままかける。C#だ
と末尾再帰ができないのでスタックオーバーフロー起こす。
• UIのイベント待ちやサービスに対する非同期なリクエストなど
もシームレスに書ける。

24. 非同期処理や入力待ちなどが混在する状態
遷移をそのまま記述可２

25. 非同期処理や入力待ちなどが混在する状態
遷移をそのまま記述可３
• 遷移する際に値を引き渡せるので状態の更新間違いなどが
入りこむ余地がない。
• try-catch(with)の中でも使えます。
• 詳しくはこちらでC# とF# のAsync: C# の非同期の落とし穴
• asynchronous workflowはasync/awaitと違い.NET2.0ター
ゲットでも使えます。

26. javascript化してスマホやWebもワンソース化
• WebSharper
F#で使える、AltJS。オプソにもなってるけど商用利用は有料。
ほんとはAltJSというよりもWebサーバーとのやり取りも一緒に書け
る開発環境らしい。
気持ち開発者少ないような…日本人でまともに使ってる人他にいる
のか不安(；´∀｀)

27. javascript化してスマホやWebもワンソース化２
• 今回株式・FXなどのリアルタイムチャートをワンソース化した。
• F#といえども数千行あったのでjavascriptで書きなおすとかだ
るい->WebSharperでコードの共有かにチャレンジ。
• ロジックなどはほぼそのままで描画する部分などプラット
フォームで違うところを抽象化して使用->95%をコード共有し
た（気がする）
• 出力されるコードも追いやすいのでデバッグなどで困ることも
ほとんどなかった。

28. javascript化してスマホやWebもワンソース化３
• とはいえ、それなりにめんどくさいですよ
と。
• 色々なものが使えない。string.Format的
なのも使えないので泣ける。
• javascript化するところは属性をつけない
といけなかったり#if#elseなどで記述分け
しないといけなかったりでコードが汚く…
• けどものによっては十分にやる価値あり。
使える範囲
フル.NET
PCL
WebSharper

29. Xamarinの中の人も推してくれてる
• F#だけでiOSアプリ作れるな
ど一級市民扱い。
• Sketchesも使えるようになっ
たらしい(beta?)リンク。
• いまだにWinRT用のライブラ
リすら作らせてくれないMS
の中の人よりもF#好きなん
じゃないか疑惑。

30. F#の悪いところ
• いうてもF#使える人が少ない…
• PCLとして満足に使えるようになったのも去年。それまでは
MSのコンパイラ自体PCLコードをうまく吐けなかったとかどう
とか。色々プロファイルに対応してないなど。
• PCL側がF#だとVSでないとデバッグしにくい。XSだとF#側に
入ってくれない（最近試してません）
• この間までF#のPCLプロジェクト、XSでビルドできず。最近で
きるようになったけど、実行すると全く動かず。バイトコードが
違うのかしら…

31. 独自レイアウトツール
• AutoLayout、説明を見てもどうみても糞っぽ難しい。
• 前に作ったレイアウトライブラリがあったのでそれを使って独
自レイアウトライブラリ作成。
• XAMLライクな記述。
– Grid
– StackPanel（的なもの）
– Margin,HorizontalAlignment,VerticalAignment
– コントロールの作成、プロパティの設定。
– Style

32. 独自レイアウトツール２

33. 独自レイアウトツール３
• ファイル更新検知してレイアウトを反映するようにした。
– シミュレータで実アプリを動かしながら編集して即反映できるので結
構便利。
• 実行時に値によって別のレイアウトに差し替えるなどもできる。
ViewState的な?UIView.Animationの中でやればいい感じに
アニメしてくれる。
• XamarinFormsがよくなったらこれもいらなくなるかと思いつつ、
動かしながらいじれるのは便利かとも思ってます。

34. Xamarin所感
• まだツールなど怪しいところもある。
– 去年の今頃はひどかった・・・ベータのある特定のバージョンじゃな
いとVSと連携できないなど。うかつにあげると環境が壊れる。
– 今も自分の環境ではVS->XS怪しい
• VSからだと実機デプロイができない。XSからでしのぐ。
• DebugSessionの開始時、一回は必ず失敗する。続けるとデバッグできる。
– 細かいがエディタも怪しい動きをすることが…特にXMLをコピペする
と前後の行が表示上ずれる。
– でも最近は大分安定してきた感…

35. Xamarin所感２
• けど実行自体は安定している。
– いままで怪しい動きしてたのは実機デプロイ時にリフレクションだけ
で使ってたコードが削られてすっ飛んでたときぐらい。
• って書いてるそばから実機ではデザインが反映されない事象発生(；´∀｀)こ
れから調べる。
– それも実機上でデバッグしてとかで追えた気がする（古いことなので
忘れました…）
– プロファイラとかもあるのでいろいろ調べられるかも（まだ使ってませ
ん）リンク
– スピードも特に問題ないような。ネイティブだともっと早いのかもです
が比較してません。

36. Xamarin所感３
• とりあえずクロスプラットフォーム開発ツールとしてとても実用
的なので、iOS,Androidに席巻されてもF#,C#の人もこれから
しばらく困らなそう。
• AndroidWearとかAppleWatchとかWearableにも対応してく
れる模様。
• 関係ないですが、サーバー側も.NETオプソ化されたのでます
ますF#,C#の人生きていくのに困らなくなりそうですね。