こんにちは。
アプリケーション共同開発部 名古屋開発課の辻です。
2016 年 2 月に、Microsoft 社が Xamarin を買収したことは大きな話題となりました。
しかしながら、Xamarin でモバイルアプリケーションを作ることのメリットは何なのか、Xcode での開発と比較して不自由な部分はないのかなど、実際に触ってみないと分からない部分が多いのではないかと思います。
そこで、Xcode を用いて Objective-C や Swift で開発してきた iOS 開発者が、Xamarin.iOS を導入することで感じたことをお話ししたいと思います。
クロスプラットフォーム開発の再興
クロスプラットフォーム開発は、iOS / Android など、個別のプラットフォームに向けて開発する工数を削減することを目的として、HTML5 の普及期に盛り上がりを見せましたが、WebView ベースでは優れたユーザー体験を提供できないという問題も抱えており、ネイティブ開発を置き換えるほどにはなりませんでした。
しかしながら、Xamarin や Ruby Motion、React Native のように、ネイティブ API をブリッジすることで、ネイティブアプリと遜色ない動作を実現するフレームワークが台頭してきたことが契機となり、再びクロスプラットフォーム開発が注目を浴びています。
Xamarin.iOS と Xamarin.Forms
Xamarin では iOS アプリケーションを開発する方法として、Xamarin.iOS だけではなく Xamarin.Forms というフレームワークも提供しています。
Xamarin.Forms ついても簡単に説明しますと、XAML という XML で記述することで画面を構成し、Page という概念で扱うことで、プラットフォームへ極力依存しない仕組みとなっています。
一方、Xamarin.iOS は、C# から扱える iOS SDK の薄いラッパーという表現が近く、画面構成には、Storyboard や InterfaceBuilder で作った画面レイアウトを使うことができます。
言語こそ違いますが、iOS 開発の経験があれば、すぐに馴染むことができると思います。
Xamarin.iOS の良いところ
簡潔なシグネチャを使える
Xamarin は iOS SDK の Objective-C のメソッドを呼び出しています。
Objective-C は動的型付け言語で、オーバーロードメソッドを作成することができませんでした。このため、メソッド名は型の情報を含めたやや冗長な命名規約となっていました。
Xamarin では API をエクスポートするときに、強い型付けを持つ C# の特徴を生かした命名を採用しています。
iOS 開発でお馴染みの UITableViewCell を取得するメソッドを例に取ると、Objective-C、Swift 3、C#（Xamarin）では以下のような定義となっています。
C#（Xamarin）の API は、Swift 3 の Swifty API と呼ばれるものに近く、気持ち良くコーディングをすることができます。
また、reuseIdentifier の引数は、本来は NSString ですが、C# の System.String のまま利用できるというのも、ストレスなく開発できるポイントです。
C# らしく書けるサポートがある
iOS SDK では、Objective-C の特性を生かしたターゲット・アクションパラダイムや、デリゲートのデザインパターンが採用されています。
C# では、.NET Framework の作法の方が馴染み深いと思います。
Xamarin では、こうした言語やフレームワークの文化の違いを埋めるために、ボタンのタップ時のハンドリングを event へ翻訳したり、クラス拡張やサポートクラスを用意して C# らしく書ける工夫を凝らしています。
例えば、UITableView にリストを表示する場合、TableViewSource クラスを用いて以下のように記述できます。
class MyTableViewSource : UITableViewSource
{
public event EventHandler<TableViewSelectedArgs> Selected;
public override UITableViewCell GetCell(UITableView tableView, NSIndexPath indexPath)
{
var cell = tableView.DequeueReusableCell("cell", indexPath);
cell.TextLabel.Text = $"{indexPath.Row}";
return cell;
}
public override nint RowsInSection(UITableView tableview, nint section)
{
return 10;
}
public override void RowSelected(UITableView tableView, NSIndexPath indexPath)
{
Selected?.Invoke(this, new TableViewSelectedArgs(indexPath));
}
}
UITableViewSource クラスは UIKit には存在しないサポートクラスのひとつです。UITableViewSource と UITableViewDelegate の両方を実装した抽象クラスとなっています。
このクラスを使うことで、デリゲートパターンを意識せずに event とラムダを使って、UITableView タップ時の動作を以下のように記述することができます。
public override void ViewDidLoad()
{
base.ViewDidLoad();
var source = new MyTableViewSource();
TableView.Source = source;
source.Selected += (object sender, TableViewSelectedArgs e) =>
{
Console.WriteLine(e.IndexPath);
};
}
C# 6.0 でロジックを書ける
プラットフォームに依存しないコードは PCL（Portable Class Library）で共有することができます。
このとき、「C# でロジックを書ける」ということは、Xamarin の強みのひとつだと思います。
- エンタープライズ方面で実績のある、実用性を重視した強い型付けを持つ言語である。
- メジャーバージョン 6 で成熟しており、言語仕様の破壊的変更に振り回されることは少ない。
- LINQ によるデータ操作は強力で、コレクションだけではなく JSON や DB にも使える。
- async / await により並行プログラミングが平易に記述できる。
また、近年は RxJava や RxSwift を用いて、リアクティブプログラミングを導入することがあります。
Reactive Extensions（Rx）の概念は取っつきづらいところがありますが、MS 発祥ということもあり、躓きやすいポイントや解決法、高度なトピックスも含めて C# で書かれたドキュメントは豊富で、Rx をさらに便利にするライブラリもあります。
留意点
ネイティブの知識は必要不可欠
ネイティブ開発は、Swift / Objective-C の知識、毎年アップデートされる iOS SDK の知識が必要となり、その学習コストは決して低くはありません。
Xamarin.iOS によって、それらの知識が不要になるわけではありません。
むしろ「ネイティブでやれることならなんでもできる」自由度を持つため、それを最大限に生かすためにはネイティブに関する知識は不可欠だと言えます。
C# やコード共有のための知識も必要
C# の言語仕様、.NET Framework の作法について学ぶ必要があります。
C# は 15 年の歴史を持つ言語ですので、今となっては使わない言語機能との互換性を維持するためのプラクティスもあります。
また、Rx のパラダイムや、コードを共有するための DI（依存性の注入）パターンなど、覚えることは多くなる傾向にあると思います。
Xamarin Profiler の使えるライセンス
Xcode での Instruments に相当する、Xamarin Profiler は Visual Studio Enterprise ライセンスでしか使えません。
モバイル端末も高性能化したとはいえ、ボトルネックとなっている処理を調査したいというケースはあるので、このライセンスの壁は高いです。
Xamarin でアプリを書くということ
9 月 14 日に Xcode 8 がリリースされ、Swift 3 を使ったアプリケーションを開発できるようになりました。
今後も Swift は進化を続けていきます。モダンで生産性の高い、新しい言語は魅力的ですが、それと引き換えに現在のアプリケーションコードが陳腐化することも意味しています。
Xamarin はアプリケーションのコアロジックを、プラットフォームや言語の変化から独立させて、長期的にメンテナンス可能な状態にできることがとても魅力的だと感じています。
PCL に共通化したコードは、Xamarin.Android など他のプラットフォームでも当然利用できますし、将来的によりプラットフォーム依存を減らせる Xamarin.Forms へ移行することも可能です。
もちろん Xamarin を使い始めたというだけで、自動的にメンテナブルなコードになるわけではありません。再利用性の高いアーキテクチャに関する知識や実装テクニックを身につける必要があります。
そこには最新のプラットフォーム動向、言語のアップデートのような派手さはありませんが、先人の積み重ねた智慧があります。長期的な保守を見据えて、品質の高いコードを書くためにはどうすればよいか？という視点を持って開発に取り組むことが、Xamarin でアプリを書くことなのかなと思いました。
フェンリルではそんな Xamarin を使って仕事をしてみたい方を募集しています。名古屋だけでなく東京、大阪でも募集していますので、興味のあるかたははこちらからご応募下さい。
フェンリルのオフィシャル Twitter アカウントでは、フェンリルプロダクトの最新情報などをつぶやいています。よろしければフォローしてください！
フェンリル採用チームの Twitter アカウントです。応募前のお問い合わせや、ちょっとした相談ごとなどお気軽にどうぞ！
関連記事
