マルチデバイスアプリ開発プラットフォームの選定

Xamarin対Cordova考察と、Evolve 2014で感じたXamarin.Formsのメリット／デメリット

Mobile Cordova Xamarin Xamarin.Forms

2014年10月27日

スマートフォンなどのクロスプラットフォーム開発では、どの技術を使うべきか？ Xamarin Evolve 2014への参加経験を踏まえて、Xamarin.Forms採用を検討する際のポイントを考察する。

岸 勝

　Xamarinを開発ツールとして採用するアプリ開発者としての視点はいくつかあるだろう*1。例えば、

• C#を使って開発することによる生産性
• ネイティブアプリとしてコンパイルされることによる高パフォーマンス
• クロスプラットフォーム開発環境による複数のOS（iOS／Android／Windows）用のアプリの同時開発

などである。どれか1つでも、対象となるアプリと、その開発の要件に適合していて、他の開発ツールとの優位性を見いだせれば採用となる。

　私の場合は、現在開発対象のアプリとして前述の全ての観点が重要であり、複数のツールについて検討を行った結果、2つの候補が残ることとなった。今回の記事では、その検討過程についてはスコープ外として割愛させていただくこととする。候補のうち、1つは、今回の記事で紹介するXamarinで、もう1つはCordova（PhoneGap）である。

Xamarin vs. Cordova

　XamarinとCordovaでは、開発環境や動作環境が大きく異なる。これについても今回の記事では詳細を割愛するが、C# 対 HTML5＋JavaScript、ネイティブアプリ 対 Webブラウザアプリの構図である。一般的な話とはなるが、両者の構図についてそれぞれ簡単に説明する。

対極的な、両技術の特徴で検討する

　C# 対 HTML5＋JavaScriptの構図では、もちろんプログラミング言語に対する個人的な趣味・好みや、開発プロジェクトが抱えるリソースの事情にも左右されるが、どちらもオブジェクト指向の高級言語であり、プログラム開発生産性は高い。現在、私が抱えている開発チームでは、C#開発経験者が多いため、単純な言語比較の観点ではC#に分がある。一方、機能実装の観点では、Xamarinは標準でツールキットが公開する、カメラやGPSなどローカルデバイスへのアクセスなどを含む全てのAPIをC#のクラスから利用可能となっているのに対して、Cordovaではローカルデバイスへのアクセスを行う場合、ネイティブコードとJavaScript間の値の受け渡しを意識しなければならず、コードが複雑になりがちであり、C#に軍配が上がる。

　次に、ネイティブアプリ 対 Webブラウザアプリの構図では、Xamarinのネイティブアプリがパフォーマンスや、ローカルデバイスアクセスへのアクセス部分の開発効率で上回ると評価できるが、Cordovaもハイブリッド開発環境の特徴を生かし、パフォーマンスやローカルデバイスアアクセスでの劣位を克服しつつある状況である。また、ネイティブアプリの場合は、「アプリをインストールする」というセットアップの前段があるのに対して、Webブラウザアプリでは、基本的にはユーザーによるインストール無しに、標準で搭載されているブラウザーからアプリを利用できる手軽さがある。

　この2つの構図に対する評価段階では、どちらか一方に評価が大きく偏ることはなかった。そこで、クロスラットフォームに関する観点で、さらに両者の評価を行った。

クロスラットフォーム開発の対応度で検討する

　Xamarin.FormsがサポートされるXamarin 3.0前までは、GUI部分をプラットフォームごとに開発することが前提のXamarinに対して、HTML5でブラウザアプリとしてのコードを共通化するCordovaでは、最終的なコード共通化可能な割合においてCordovaに軍配が上がっていた。しかし、Xamarin 3.0でのXamarin.Formsの追加により、Xamarinも「GUIコードがOSごと」の前提を離れ、コード共通化の道が開かれた。

　Xamarin.Formsは2014年5月のリリースから間もないため、その機能や可能性など、未知の部分も多いが、このXamarin.Formsが、クロスプラットフォーム開発ツールとしてのXamarinの価値を左右し、さらにはXamarinそのものの方向性を左右すると私は考えている。

■

　そこで本稿では、このXamarin.Formsを使用することによる、GUI部分のクラスプラットフォームアプリ化と、Xamarin.Formsを使用するメリット／デメリットについて説明する。

【コラム】Xamarin Evolve 2014で感じたXamarin.Formsの人気度

　Xamarin.Formsについての説明に入る前に、まずXamarin Evolve 2014*2で得られた、Xamarin.Formsに対する参加者の反応について触れたいと思う。

• *2　筆者は、2014年10月8日～10日に開催された、このカンファレンスに参加し、その経験を踏まえて本稿を書いた。当日のカンファレンス内容がレポートされた「Xamarin Evolve 2014： スマートフォンの世界と、開発者の裾野を広げるXamarin」という記事もあるので、併せて参照してほしい。

　Xamarin.Formsについては、Xamarin 3.0の目玉機能としてリリースされただけに、既存ユーザー、新規ユーザーを問わず、そのインパクトは強く、多くの関心が寄せられている。このことを裏付けるように、私が参加した今回のXamarin Evolve 2014でのXamarin.Formsのセッションは、用意された座席をオーバーする聴講者が集まり、会場の壁際や、床に座り込んで聴講するこをを余儀なくされたセッションもあった。今回のXamarin Evolve 2014では、全69セッションのうち、Xamarin.Formsをメインテーマにしたセッションが6つ開催され、私の知る限り、どれも多くの聴講者を集めていた。

　また、今回のEvolve参加者全員に、Charles Petzold（チャールズ・ペゾルド）著*3の『Creating Mobile Apps with Xamarin.Forms』のプレビュー版*4が配布された。正式出版は、2015年春を予定しているとのことである。正式出版品は配布されたプレビューの6章、約270ページから、さらに倍程度のボリュームになる見込みとのことである。この配布されたプレビュー版には、まだ少し目を通した程度であるが、サンプルなどを含めて分かりやすく記述されており、正式版ではXamarin.Formsを使用したアプリ開発のバイブルとなることが予想される。

Xamarin Evolve 2014のレジストでもらった3点セット

• *3　『Programming Windows』というWindows開発のバイブル本を、Windows登場時から執筆し続けている有名人。2014年8月からXamarin社のフルタイムの社員になったことでも話題を呼んだ。
• *4　現在、この本（英語プレビュー版）の電子書籍が、KindleやMicrosoft Pressで、無料で購入／ダウンロードできる。

Xamarin.Formsのメリット／デメリット

　Xamarin.Formsを使用した、クロスプラットフォームアプリのコーディングには、大きく分けてAPI実装とXAML実装が存在する。XAML実装の場合も、コードビハインドを極力少なくする実装と、コードビハインドに頼る実装では異なるが、今回の記事では、GUIコントロールの配置をXAMLで記述するものは全てXAML型のアプリに分類する。

Xamarin.Formsのサンプルで、その実力を確かめる

　まずは、Xamarin.Formsのセッションで、Petzold氏がDEMO（デモ）したサンプルを紹介する。

　このサンプルは、Xamarin.FormsのAPIを利用して、いかにインタラクティブな画面を容易に提供できるかを紹介するために披露されたDEMOである。UIコントロール自身が持つ、プロパティやメソッドを利用することにより、表現豊かな表示を容易に実現できている。このDEMOアプリは動作がユニークで、会場でも参加者の賛同が大きかった。

　このサンプルは、Xamarin.Forms標準のボタンコントロールのクリックイベント内で、コントロールのAPIを使用してコントロール自身の属性を動的に変更するGUIアプリである。実際のXamarin.Formsを使用したアプリの実装イメージとパフォーマンスを確認する上で参考になると思われるので、ここで紹介する。

　会場でのDEMOは、MacBook（ノートPC）上で、iPhoneシミュレーターを動作させて行われた。

　まずは、新規ソリューションを「Xamarin Forms Portable」テンプレートから作成する。その後に、Xamarin.Formsパッケージ（現在、1.2.3.6257）の更新を適用する（次の画面を参照）。

新規ソリューションへの更新パッケージの適用

このように表示されていれば、［Xamarin.Forms (1.2.3.6257 available)］を右クリックして、表示されるコンテキストメニューの［更新］を実行する。

　次に、（通常のクラス作成のテンプレートを使って）ContentPageから派生させた新たなページ（下記のコード例では「coolButtonPage」）を作成し、アプリ（＝App.csファイル）のGetMainPage()メソッド内で、このページをnewするようにする。そのコンストラクター内で、ボタンを1つ生成し、そのボタンのクリックイベントを追加する。

　そのクリックイベントのハンドラー（＝上記のOnButtonClickedに対応する実際のメソッド）として、ボタンを操作するための下記のコードを追加する。

　私自身も、このDEMOアプリの動作に興味を持ったため、さっそくこのコードを、そのまま私の開発環境である、Windows 7のPC、Xamarin Android Playerで実行させてみた。コンパイル自身は何の問題もなかったが、動作は、会場のDEMOとは異なる動きをした。そこで、デバッグを行ったところ、TranslateTo()メソッドが期待される動作をしていなかった。簡単に調べたところでは、TranlateTo()は単独では機能するものの、RotateTo()を実行後には正常に動作しなくなっているようであった。また、iOS環境では「アンカーの位置（＝AnchorX／AnchorYプロパティ）によって座標軸の起点の影響がない」のに対して、Android環境では「アンカーの位置によって座標軸の起点が変更される」という点が異なっていた（※私はiOS動作環境を持っていないので、DEMOとの動作の違いからの推測）。

　そこで、TranslateTo()をLayoutTo()で置き換え、座標の軸基準の違いを変更したコードを紹介する。

　この両者の動作の違いは、単なるバグの部類で、Xamarin.Formsとしての過渡期的な状態なのであろう（と信じたい）。ただ、ここで言えることは、いずれにしても「Xamarin.Formsがクロスプラットフォーム環境で完全な互換性を与えてくれるかどうか」は自分で検証するまでは分分からないということだ。無論、現在はXamarin.Formsがリリースされてからの期間が短いため、今後、このような単純なバグは解消されていくであろう。だがやはり、「自分のXamarin.Formsコードがクロスプラットフォームで同様に動作するか」のリスクを負うことは、ある程度覚悟して使用すべきであろう。

　先に述べたように、Xamarin.Formsは、APIでの記述とXAMLでの記述の2種類がある。どちらで記述すべきかは、現時点ではコードの記述者に委ねられるレベルであると思っている。ただ、XAMLで記述されている方が、そのままテキストを見た場合でも、全体の構造をつかみやすい。

Xamarin.Forms対応のXAMLエディターについて

　また、私の個人的な意見であるが、今後、Xamarin.Formsのエディタ―などのツール類が整備されるとすれば、XAML形式のものが標準となるであろう。そして、これは私の希望であるが、Microsoft Expression Blendに相当するXamarin.Forms対応のXAMLエディターなど、XAMLコードをビジュアルに効率よく作成するツールが早期にリリースされることを期待している。そうした、未来への期待を込めた部分も含めると、現状でもXAMLでの実装を検討することをお勧めしたい。

Xamarin.Forms対応のコントロールについて

　現在のXamarin.Formsで提供されているコントロールは、比較的単機能なものだけである。具体的には下記のリンク先を参照してほしい。

• Xamarin.Forms Control Gallery | Xamarin（英語）

　ただ、今回のXamarin Evolve 2014のKeynoteセッションでも発表されたが、6社の.NETメジャーコンポーネントベンダー（Syncfusion／Telerik／Steema／ComponentOne（GrapeCity）／DevExpress／Infragistics）と提携し、これらのベンダーから、140を超えるXamarin.Forms対応コントロールが出されている。この中には、多機能でビジュアルなチャートコントロールが含まれており、Xamarin.FormsでリッチなGUI開発が可能となっている。追加費用が必要になるのは不本意だが、これによりビジュアルなページが作成可能になると考える。

■

　今回のXamarin Evolve 2014の現地参加を通して「Xamarin.Formsのメリット／デメリットの総括」として得られた感触は、Xamarin.Formsを利用したクロスプラットフォームアプリ開発は、十分に可能であり、現状のXamarin.Formsに多少の機能不足や品質不足があったとしても、ユーザーの強い関心と要求に後押しされ、急激に拡張と改善が行われていくことが十分に期待できるということだ。ネイティブによるハイパフォーマンスなXamarinアプリを、高い生産効率で開発可能という特徴を維持しつつ、クロスプラットフォームを実現できることを考えれば、Xamarin.Formsを使用したアプリ開発はベストな選択肢と言えるだろう。ただし、現時点での選択には、複雑なGUIを必要とせず、クロスプラットフォーム環境での同一動作に対する不具合があるリスクを負えることが前提となる。

Xamarin Evolve 2014の注目ポイント

　「Xamarin Evolve 2014レポート： スマートフォンの世界と、開発者の裾野を広げるXamarin」という記事でも、カンファレンスの全体の内容が紹介されているが、本稿でも特に注目してほしい点について簡単に紹介する。

新機能 ―― Keynoteセッション

　カンファレンス開始の10月8日（水）に、最初に開催されたKeynoteセッションでは、Xamarin Platformとして、下記の3つの新機能が発表された。

1. Xamarin Android Player（高パフォーマンスAndroidシミュレーター）
2. Sketches（コーディング効率向上機能）
3. Profiler（解析ツール）

　上記の新機能の情報については、Xamarin正規販売代理店であるエクセルソフトのサイトにすでに情報がアップロードされているので、そちらを参照されたい。

• Xamarin Platform Preview (Android Player, Sketches, Profiler) : XLsoft エクセルソフト

Xamarin Studioの能力 ―― Become a Xamarin Studio Expertセッション

　このセッションでは、Xamarin Studioの便利な使い方についての紹介があった。私はWindowsユーザーであるため、通常のIDEとしてはVisual Studioを利用しており、Xamarin Studioを使用する機会の方が少ない。そのため、Xamarin Studioはほとんどインストールされたときのオプションのままで使用していた。また、使い方そのものも通常のテキストエディターで行える程度の使用方法でしか使っていなかった。

　今回、このセッションでいくつかの機能が紹介されて、開発作業のみであれば、Xamarin Studioに十分な機能があるのではないかと感じたので、その一部を簡単に紹介する。Xamarin Evolveのセッションの中には、こうした身近な気付きを与えてくれるものもあり、思いがけぬ収穫が得られることもある。

1複数行の同時編集 ―― コードエディター機能

　ブロック選択機能を使うことで、複数行の同時編集が行える。まず、Altキーを押した状態で、同時編集を行いたい行の先頭をブロックで選択する（図参照）。その状態で、キーボード操作を行うと、複数行に対して同時に操作が可能である。以下の図の例では、複数行に対して、同時に“this.”という文字入力を行っている。

複数行をブロック選択した状態で、“this.”と入力

▼

ブロック選択していた全ての行に、“this.”が同時入力される

複数行の同時編集

2［テキストエディタ］オプション機能

　メニューバーにおける［ツール］メニューの［オプション］選択により起動できるダイアログでは、さまざまな機能の選択とカスタマイズが可能だが、セッションの中では、［テキストエディタ］の［マーカーとルーラ］オプションについて紹介があった。デフォルトでは、ほとんどのチェックボックスがOFF状態であるが、ONにして使用すると便利なものが少なくない。例えば、［現在の行を強調表示する］、［列ルーラを表示］、［Highlight identifier references］、［Show indentation guides］などはぜひ試してみていただきたい。

テキストエディター機能設定

【コラム】アトランタ、会場の雰囲気、参加者 ―― Xamarin Evolve その他の所感

　今回、Xamarin Evolve 2014が開催された米国アトランタは、多くの日本人にとってあまりなじみがないのではないだろうか。私自身も今回の渡航に当たり、自宅周辺の本屋でアメリカの旅行ガイドブックをあさったが、アトランタに触れている本は限られていた。そこで、アトランタという町を少しだけご紹介しよう。

　アトランタは、北米の東海岸に位置し、ニューヨーク、フロリダなどの都市と同一の時刻エリアに含まれている、東海岸から少し内陸に入った土地である。日系企業が多く進出している町ではあるが、日本人観光客は多くないため、街中で日本人を見かけることはあまりない。知らない人も多いが、アトランタは、デルタ航空の本社があることと、コカコーラ本社があることで有名である。

　先に話したデルタ航空については、このアトランタ空港を発着する便の実に6割強がデルタ航空機であり、アトランタ国際空港の近くには、“Delta Flight Museum”というデルタ航空にまつわる情報が展示されている施設もある。空港はデルタ航空のハブ空港となっており、空港そのものがデルタ航空とその他航空会社という雰囲気で運行されている。

　また、アトランタはジョージア州にあり、あの缶コーヒーのジョージアでも有名なコカコーラの本社が存在し、こちらも“World of Coca-Cola”というミュージアムが存在する。こちらには、私も今回実際に行ってみた。私たちになじみの深いコーラであるから、皆さんにもぜひともご紹介したい。

ワールド・オブ・コカコーラ

　このコカコーラミュージアムでは、コカコーラにまつわる歴史やさまざまな情報がアトラクション形式で展示されており、子供から大人まで幅広く楽しめる施設となっている。ツアーの最後に全世界のコカコーラ製品、実に数十種類のフリードリンクがサービスされる。コーラ好きの読者におかれては、ぜひとも訪れて全種類制覇を目指していただきたい。

　今回のXamarin Evolve 2014は、トレーニング2日間とカンファレンス3日間で構成されており、トレーニングからの参加者が600名強、カンファレンスからの参加者は約1300名強で、世界各国からの参加者が参集した。日本からの参加者は私を含めて2名で、若干寂しい数値である。総参加者実績数は、実に昨年の2013開催の倍に相当し、Xamarinがモバイル端末の開発ツールとして世界的に広がりを見せていることを裏付けている。

Keynoteセッション会場入りを待つ参加者

　会場となったHyatt Regency Atlantaはダウンタウンの中心に位置し、交通や観光の拠点として申し分ない。

会場として使用されたHyatt Regency Atlanta

　今回、会場として使用されたのは、B1F、B2Fのカンファレンス会場、全5会場であった（各会場でのセッションの内容については、公式サイトを参照していただきたい）。

地下（B1／B2）会場への入り口

　今回の開催では、この5会場以外のミーティングルームを使用して、希望者に対してザマリン（Xamarin）社員との個別のミーティングが実施された。また、この個別ミーティング以外にも、常にザマリン社員がフロアに待機しており、個別の質問や、相談に対応していた。この中には、Xamarin日本人社員1名（＝『インサイドXamarin』の筆者）も参加しており、日本人の参加者が日本語でサポートを受けることもできた。私自身も、今回この方には大変お世話になった。来年のEvolveの体制については確約できないが、英語は少し苦手という日本人の方も、参加していただければ、大きな成果を得られることは間違いない。

メイン会場とそのスクリーン

Keynoteセッションで登壇中のミゲル・デ・イカザ氏

• この記事の連載 INDEX 連載 RSS