2014年12月30日TweetPocket2014年の非ゲームアプリのマルチプラットフォーム対応の大本命はXamarinだったと思う。Xamarinのアプローチにはとても共感できる。2014年僕がXamarinを選択することはなかった。各OS用のUIを共通のコードで実装するというTitaniumのアプローチは結果的にうまくいかなかったと思う。一つのコードで、各OSのUI思想を尊重した一貫性のあるUIが実現できれば理想的だが、現実的には思想あるいは仕組みの差を統括的に埋めるのには限界がある。結果、各OSごとに意図通りに動かない箇所を見つけては対応する、という作業に追われることになる。その部分がブラックボックス化されていて影響範囲が不明瞭だと、デベロッパーにとってその作業は苦痛なものとなる。この部分に十分な労力がかけられていないアプリは、ユーザとして使っていると操作性が悪くストレスを感じることが多い。僕はこのアプローチが好きではない。UI部分は共通化しないという方針Xamarinを使ったアプリ開発で共通化されるのはUIより下の層のみであり、UI層は各プラットフォーム毎にそれぞれ実装することになる。このアプローチでは、コード量は最小ではなくなるが、構造的に無理のないUI開発が可能で、デベロッパーの意図した操作性を実現しやすくなる。このアプローチ自体にはとても共感できる。Android対応できるようになった。マルチプラットフォーム対応アプリ開発環境の中で、このアプローチが採用されるようになってきたのは、良いことだと思う。サードパーティライブラリの問題XamarinはIDEも良くできているし、Monoの信頼性もUnityの実績を見る限り問題がないと見て良いだろう。Xamarinの採用にはまだいくつか問題がある。Development上の記事は2013年の記事だが、コードの再利用性の問題や第三の学習曲線の問題など、Xamarinを使う上での問題点がわかりやすくまとめられている。これらの点に加え、僕が今年Xamarinの使用を見送った理由には「サードパーティライブラリを使えない」という点がある。Android側のUIを作るときにはottoやButterKnifeを使いたいし、画像処理アプリならGPUImageなどのライブラリを使いたい。ビジネスロジックの実装を共通化できたとしても、外部ライブラリでまかなえていた部分を自前で用意しなければいけなくなる、というマイナスは結構大きい。今後の期待Ruby(あるいはRails)におけるGemsのように、Xamarin用のライブラリさえ充実してくれば、Xamarinの強みは一気に強くなる。実際、ButterKnifeの思想をもとに作られたCheeseKnifeなど、ネイティブライブラリ同等の機能を提供するXamarin用ライブラリも登場してきているが、まだまだ数は十分ではない。来年、ライブラリが充実してきタイミングで、Xamarinを使ったアプリを実際にリリースしてみたい。コメントをキャンセルメールアドレスが公開されることはありません。*ウェブサイトご意見、ご感想をお願いします。その2ARを学ぶ10連休。折り返し地点までの記録。その110連休に改めてARを勉強することにした。1日目から3日目まで。