第1回 イントロダクション

この連載では、WPFとXamarin.Formsを用いて、以下のプラットフォームのアプリケーションを制作しようと試みます。

プラットフォーム 利用するフレームワーク 開発に利用するOS 実行に利用するOS
Windows Desktop WPF Windows Windows
UWP Xamarin.Forms Windows Windows
Mac Xamarin.Forms Mac Mac
Android Xamarin.Forms Windows Windows
iOS Xamarin.Forms Windows Mac

※別途、Visual Studio 2015 Community Update 2以上、Xamarin Studio Community for Macが必要です
※WindowsとMacを同一ルータで接続することができる環境が必要です

この連載は、Xamarin.Formsに興味のある人を対象にします。

Xamarin.Formsとは、C#でスマートフォン・デスクトップアプリケーションを簡単に制作することができるフレームワークです。
また、WPFとは、C#でWindows上で動作するソフトウェアを制作するためのフレームワークです。
一見別物に見えますが、実は、この2つを併用することで、強力なクロスプラットフォーム制作環境が実現できるのです。Windows、Android、iOSで共通のアプリを開発する時、HTML5の次くらいに現実的な選択肢です。

クロスプラットフォームと聞いて、皆様はJavaやQtを思い浮かべるかもしれません。
しかし、JavaはiOSでは動作しません(RoboVMは終了しました)。世界で唯一とはいえ、iOSが市場の半数を占める日本でJavaでのスマートフォンアプリ開発は多少敬遠するものです。ただし、デスクトップ専用として見るなら、まず最初に検討すべき強力なクロスプラットフォーム開発言語であることを補足します。
Qtは、たしかにスマートフォンに対応はしていますが、APIが充実しているか多少怪しい上に、iOSでは静的コンパイルが必須です。無償版QtはLGPLですので、iOSでアプリを出す以上、必然的にGPLになります。ということは、iOSアプリのソースは全てGPLになり、同じロジックを共有しているWindowsやAndroidのアプリのソースも全て連鎖的に公開しなければいけないことになり、無償版ではプロプライエタリなソフトウェアの開発には不向きです。そもそも、GPLライセンスとApp Storeの利用規約には矛盾があり、App StoreではGPLアプリケーションは扱えないとの指摘があります。このことを鑑みても、動作環境にiOSを含む以上、Qtを使うなら年間50万円を支払う義務があると見ていいでしょう。
これら2つは、すべてのプラットフォームにおいて共通に利用できる、独自のAPIを提供します。かつ、プラットフォーム特有の機能の利用には、面倒な手続きを経なければいけません。プラットフォーム特有の機能を利用したい時、例えばJavaは自分でC言語を使って別途コードをコンパイルしなければいけませんし、Qtも同様です。(すべての問題の根源はiOSにあるとも言えますし、iOSを無視する限りこの2つは選択肢に残り続けます)

そこで、Xamarinが登場しました。Xamarinは、C#と.NET FrameworkをMac、Linuxだけでなく、Android、iOSにも持ち込み、少なくともビジネスロジックを共通化させることを実現しました。しかし、UIのコードまでは共通化しておらず、MVCのうちVとC両方をプラットフォームごとに書き分ける必要がありました。
Xamarinは、Xamarin.Formsを発表しました。それは、異なるプラットフォームで同一のViewを書くことができ、前述のJavaやQtと同様、すべてのプラットフォームで同じ画面を表示させるために独自のAPIを提供します。ただし、その雰囲気は異なります。JavaやQtは「俺が全部やってやるよ」というやり方だったのに対して、Xamarin.Formsは「最低限の機能は提供するけどあとはお前らでなんとかしろ」というやり方です。
そもそも、異なるプラットフォームでは、提供する機能も異なります。カメラなど似ている機能もありますが、Xamarin.Formsは、それら機能の最大公約数を提供することを選択したのです。すなわち、iOSで使えるけどAndroidでは使えないよ、そのような機能はXamarin.Formsでは基本的に提供しません。そのかわり、それぞれのプラットフォーム固有のコードを簡単に書くための方法を提供しました。別途DLLをコンパイル?そんな必要はありません。プロジェクトの一部として直接組み込めばいいのです。なのでデバッグも比較的簡単です。これが、JavaやQtとの大きな違いです。まず、前提条件が違うのです。
また、Xamarin.FormsはXAMLを提供します。これはMVVMを促進するものです。MVCは、ビューとコントローラの密結合が前提です。それに対してMVVMは、結果としてビューとコントローラが密結合を持ちません。つまり、プラットフォームごとにビューモデルを用意する必要がなくなります。正しいMVVMで設計することで、Xamarin.Formsにおけるプラットフォームごとのコードの記述量を減らすことができます。
これによって、JavaやQtと比べて大変ではあるものの、強力なクロスプラットフォームアプリの開発を実現することに成功しました。

本連載の主体はXamarin.Formsであり、WPFはあくまで説明の補助、引き立て役として登場します。要するに、まずWPFで機能を作ってみて、これと同じことがXamarin.Formsでできるか?検討するスタイルになります。

というのも、Xamarin.Formsは、その強力さにもかかわらず、特にUWPとMacでバグが多く、いまだ不安定なライブラリであるからです。(※ただし、Xamarin.FormsのMacは本記事執筆時点(2016年9月23日)で、ソースコードが公開されているだけで、まだXamarin.Forms最新プレビュー版のリリースノートに記載すらありません。Macが不安定なのは当たり前として、不安定なまま正式版リリースまでしたUWPお前は許さない絶対許さない地獄に落としてやる)
あまつさえ、AndroidやiOSでさえも、前述の通り最低限のコントロールしか提供されておらず、本格的なアプリケーションを制作するには、今もなおカスタムレンダラーが必須です。図形描画など一部の機能では、共通の機能があるはずなのにXamarin.FormsでAPIが提供されていないなんていうことも起きています。
しかし、それを差し引いても、Xamarin.Formsは、スマートフォンアプリの制作にあたって、最も有効な選択肢の1つです。それを踏まえた上でスマートフォンのアプリが実装できるか検討し、おまけ程度にUWPやMacについても検討します。

この連載で制作するアプリケーションは、基本的にMVVMです。WPFでMVVMではなくMVCをやった人もいるかもしれませんので、念のためMVVMを初めて使うタイミングで、MVVMについても簡単に説明します。詳細な説明は、別のサイトなどを参照して下さい。
また、別途C#の知識を要求します。言語の知識ならば、C#入門未確認飛行が大変詳しいです。これらのサイトでは、明らかに中級者向けの機能も解説していますが、わからなかったところは困ったときに見る程度で大丈夫でしょう。

次回は、5つのプラットフォームで、「Hello, WPF」「Hello, Xamarin.Forms」アプリをビルドしてみます。