連載のおまけ: Xamarin.Android ARTのJNI実装とICSのメモリ管理

まさかの4分割となってしまった某連載のAndroidの回ですが、4回目の分についてはいくつか補遺を書いていたのでした。分割を口実にちまちまと1週間ごとに補足を載せるつもりだったのですが、2回目以降は一括で処理されてしまったので、ここにおまけとして載せておきます。

まずJava Interopアーキテクチャのセクションではこちら:

コラム: ARTランタイムにおけるJNIの実装の違い

Xamarin.Androidバージョン4.12には、ARTランタイムにおける動作にかかる修正が加えられている。ARTにおけるJNIの仮想メソッド呼び出しの実装が、Dalvikのものとは完全に互換になっていなかったというバグがあり、また他にもGCにおけるグローバル参照の扱いにバグがあったことを受けて、いくつかの回避コードが追加されている。まだ、これらの問題に起因して、挙動が想定外になっている可能性はある。

 

それとGCまわりのセクションでこちら:

 

コラム: Android 4.0 のメモリ管理仕様の変更

Android 4.0(Ice Cream Sandwich)がリリースされた時、Xamarin.Android開発チームは、それまでのXamarin.AndroidでビルドされたアプリケーションがAndroid 4.0環境でクラッシュすることを発見した。その原因は、Android 4.0で導入されたASLR(アドレス空間配置のランダム化)の導入と、JNIにおけるローカル参照・グローバル参照の実装の変更にあった。それまでAndroidのアプリケーションはアプリケーション内で固定アドレスにロードされており、Dalvik VMで一旦確保されたメモリのアドレスは変更されず、ローカル参照とグローバル参照も一致していたのが、Android 4.0から「まともに」区別されるようになったのである。現在のXamarin.Androidでは、もちろん当時のようなクラッシュは発生しない。AndroidJavaライブラリの実装でも、ObjectクラスのhashCode()メソッドの実装を眺めてみると面白いだろう。

…まあどちらも小ネタでした。

Xummit、Xamarin at BUILD、Roslyn、そして.NET Foundation、すまべん関東

Xummit

どうも、先々週にXummitと称する全社ミーティングに参加してからすっかり直す気のない時差ぼけにやられていますが、辛うじて生きているatsushienoです。入った時は15人くらいしかいなかったのが、いつの間にか150人とかになっててもう覚えきれん…

Xamarinは、普段は100人くらいの米国メンバーと、50人くらいの米国外メンバーで(現状です。2〜3ヶ月前までは100人くらいだったので、あんまし参考になる数字じゃないです)仕事をしていて、米国メンバーも約半分がボストン、約半分がサンフランシスコ、残りが米国各地ということで、全員が顔を合わせる機会は、この全社ミーティングと自社イベントであるところのXamarin Evolve(今年も10月にやります)しかないわけです。われわれ米国オフィス外メンバーは自宅で仕事するわけですね。そんなわけで、全社ミーティングは主に顔合わせとミーティングの場となります。

今年は特に会社の成長が著しかったこともあって、社内のチームを紹介する場でもありました。それでセールスチームはこんなメンバーでこんな仕事をしているよ、とか、マーケティングチームはこんなことやってるよ、みたいな話が、全社員向けになされる(!)わけです。でフツーに考えたらつまらんわけですが、これが割と面白いんですね。日本だとちょっと想像できないですが、自分たちのチームメンバーをとにかく褒める。全社向けセッションだけど自分のチームメンバーにひたすらthank youって言っている。いいモチベーション作りになっているんだと思います。

Xamarin @ //Build

さてさて、先週はMicrosoftBUILDカンファレンスでいろいろ話題を提供した1週間でした。Xamarinの中の人としては、特にMiguelが2日目に行ったセッションが大盛況でナニヨリでした。channel9に動画が公開されているので、見ていないという人はこちらからどうぞ。割とがっつりライブコーディングしていて、参考になると思います。しれっとVS版iOS designerとか見せたりしたりな(!)

Go Mobile with C# and Xamarin | Build 2014 | Channel 9

このBUILDにおいては、Microsoftからいくつか重要なアナウンスメントやリリースが発表されたわけですが、特にMono/Xamarin方面で大きい話題が2つありました。(他の話題、たとえばWindows 8.1とかTypeScript 1.0リリースとかAzureまわりは関係ないのでパス)

opensourced Roslyn

1つはRoslynのオープンソース公開です。<del>vaporwareからの</del>素晴らしい進歩ですね。わたしは見ていなかったのですが、BUILDではリアルタイムでcodeplexのプロジェクトを公開していたそうで、現場の興奮が想像できます。MonoDevelopでは既にNRefactoryを使用していて、そのCSharpサポートではMono.CSharpが利用されていて、われわれのC#コンパイラは最初からC#で書かれていて、完成度は既にかなり高く、C#に関してはNRefactoryとRoslynの機能は(少なくとも直前のバージョンまででは)ほぼ同様…といった状況から、MonoDevelopがRoslynに切り替えることで得られるメリットはあまり無いと思います。ですが、MonoDevelopハカーはRoslynの公開を歓迎し、NRefactoryベースのコードを(一部かもしれませんが)Roslynに切り替えるつもりであることを公表しています。まあ、NRefactoryの開発はそれなりに大変なので、ほぼ目的のかぶるコードを重複して開発する意味はあまり無いということでしょう。

Roslynはコンパイラ インフラストラクチャであって、われわれとしては同様にC#コンパイラそのもの(mcs)も置き換えることが出来るとは言えそうですが、聞くところによるとRoslynベースのコンパイラはまだコンパイル速度がかなり遅いそうなので、少なくともまだしばらくは置き換えられなそうです。

まあそんなわけで、個人的にRoslynが公開されたことで変わる部分はそんなに無いと認識しているのですが、ひとつ大きな可能性が広がったのはVB.netですね(!)。これまで完全にクローズドで開発されていて、Monoでも開発が止まっていたものが、これでVBコードの利用可能性が広がっただけでなく、language serviceまで公開されたことで、MonoDevelopのプロジェクトとして高度な補完機能やリファクタリング機能も実現できることになるんじゃないかと期待できます。まあこれは個人の感想であって、MonoコミュニティがVBを発展させるかどうかは分かりません(個人的にも使っていないので特にVBサポートを発展させたいという意思はありません)。

.NET Foundation

さて、もうひとつの重要な発表は、.NET Foundationの公開です。.NETベースのオープンソース開発のコミュニティの基盤となるべく設立されたようです。MicrosoftとXamarinが主にコードを提供していますね。現状ではMicrosoftが大量にコードを提供していると言えるでしょう。とはいえ、割と小規模なライブラリも含まれているようですし、.NETのオープンソースコードを公開していれば、普通に参加できるんじゃないでしょうかね(!) 個人の参加を受け付けているかはわかりませんが、詳しくは連絡してくれと書いてあるので、そうしてみるといいと思います。

MiguelはNovell時代からしばしばMonoのfoundationみたいなものが必要だと言っていたのですが、.NETベースのオープンソースを支援するための基盤として設立された(であろう)これは、それに近い存在と言えるかもしれません(まあ、Monoのfoundationとしては、うちの社外でMonoの基盤を積極的に開発する、GNOME FoundationにおけるSunやRed Hatみたいなプレイヤーを念頭に置いていたんじゃないかとは思いますが)。

ともあれ、Microsoftがさらにオープンソースにコミットしてきていることは間違いなく、今後も.NETはオープンな方向にシフトしていくと期待して良さそうです。あとはもっとLinux/BSD方面のプレイヤーが出てくればなあと個人的に思いますが(Xamarinにはあんまし期待してない)、難しいところかも。

すまべん関東「Xamarin 2.0であそぼう!」

さてそんなわけでここ2週間ばかりは謎の熱狂と時差ぼけで朦朧と過ごしていたわけですが、そろそろ意識を取り戻して4月は日本でばたばたと過ごそうと思います(今年そろそろ5週間目くらい)。

まず、4/19(土)にすまべん関東「Xamarin 2.0であそぼう!」というイベントがありまして、そこでXamarin Studioについて1コマぶんセッションを担当します。XSの開発にはタッチしていないのにXSについて語る…というのは昨年にも台湾のCOSCUP 2013でやらかしてきたわけですが、今回はVSから離れられないWindows厨の皆さん向けの内容にしようと思っています。

以前に書いてきた勉強会資料やC#エディタの解説なども話の中に取り込みますが、コードエディタとは何ぞや?的な講学的アプローチは措いておいて、機能紹介などを中心にしようと思います。

まだ残席はありそうなので、興味のある方はぜひおいで下さい。あめいさん @amay077 のReactiveUIのセッションとか、伊勢さん @iseebi のMvvmCrossのセッションとか、だいぶ最先端のトピックが並んでいて、この密度のイベントはこれからもなかなか無いんじゃないかと思います。普段アプリケーション開発に着手できずにこの辺を眺めているだけで終わっているわたしとしても、とても楽しみです。

後は、あまり関係ないですが、monoコミュニティの友人がしゃべりに来るUnite Japan 2014にもちょろっと顔を出すつもりです。普通に仕事日なので、2日間の参加は厳しく、火曜だけになると思いますが、万が一見かけたら適当に声かけてみて下さい。

連載のおまけ: モバイル・フレームワークにデスクトップAPIを「取り戻す」

Xamarinの話を書くはずなのに未だにモバイル製品の話が一向に出てこない某連載なのですが、今回ちょっと検証する時間がとれなくて削ったネタを書いておきます。まさかのLinq to SQLです。以下、最後の段落に続くはずだったネタとして見て下さい。

--

前述の通り、モバイル環境で利用できるAPIが少ないのは、「Silverlightに含まれていなかったから」であり、自前でビルド出来るものは、自分で追加することができる。その意味で、既にソースコードが揃っているmonoのクラスライブラリは、再利用性が高い。


たとえば、MonoのLinq to SQLの実装は、内部的にはDbLinqと呼ばれる外部プロジェクトを取り込んでおり、このプロジェクトはSQL Server専用だったはずの同APIに、さまざまなデータベースのプロバイダーAPIを実装しており、本家Linq to SQLよりもはるかに汎用性が高く、SQLiteもサポートしている。(ただし、monoのビルドでは、MONO_STRICTというオプションが設定されており、SqlClient以外のデータ・プロバイダーは除外されてしまう。)

monoを`--with-monodroid=yes`でconfigureしてビルドした後、`mcs/class/System.Data.Linq`ディレクトリに移動して`make PROFILE=monodroid`を実行すると、(2013年末の時点では)2つだけ、Consoleに色を設定しようとするコードだけがビルドエラーとなる。これを`#if !MONODROID`のようにコメントアウトすると、ビルドは通り、Android用のSystem.Data.Linq.dllが出来てしまう。(ちなみにLinq to SQLはExpression Treeを使用するので、iOSでは動作しないだろう。)

もちろん、これはたまたまLinq to SQLの依存ライブラリが少なく、依存関係も小さかったから実現したのであって、多くのアセンブリではこのテクニックは通用しない。ASP.NETなどは到底不可能だろう。

Xamarin StudioやVisual Studioのプロジェクトとして新規作成して、そこにソースコードを追加しても良いだろう。この場合は、各アセンブリのディレクトリにある`{アセンブリ名}.dll.sources`というファイルの各行を読み取って、<Compile Include='...' /> という内容に変換した上で、プロジェクトの.csprojファイルに追加するハックがお手軽だ。(ちなみにSystem.Data.Linq.dllでは`MONO_STRICT`をビルド時に定義していないと失敗する。)

monoについて割と新し目 or 割と詳し目の記事を書きました

もうそろそろ旧暦で1年が終わろうとしていて、年の瀬が近づいているのを感じる日々です。

さて、先週から2回に分けてmonoに関する記事を書きました。本当は1回で終わるはずだったのですが、長すぎたので分割されています。1回目がmonoの成り立ちとビルド(まあこれはほとんど説明していません)、それとC#コンパイラについて、2回目がmonoランタイムとクラスライブラリについてです。

実のところmonoについては1回で終わらせるようなものではないと思っているのですが、どうやらXamarinのプロダクト関係の一連の長いシリーズの一部であるようで*1、じっくり書いていたらmonoだけで終わって話にならないようなので、1回(というか結局2回)だけです。

一連の話の対象がXamarinのプロダクト関係ということで、そこに関わらない話は含まれていません。というのは少々ウソがあって、C#コンパイラについてはほぼ無関係な話がちょっと入ってます。ランタイムの各要素はモバイル製品やIDEまわりで意味のある話になりますし、クラスライブラリの話はモバイル製品に持ち込むためにバグフィックスや実装の追加を行ってテストを実行するための必要最小限の部分だけを押さえた感じです。

実のところもう1回、半分くらいmonoまわりの話として書いてある記事があるのですが、それはモバイルAPIまわりの話なので、正直あんましmonoと関係ないので、monoに関心のある人向けの内容にはなっていないかもしれません。

あと、最近ほとんどmonoについて書くことが無かったので、さり気なく開発チームで共有されている小ネタが微粒子レベルで存在しているかもしれません。そのうちNET_2_0はなくなりますよとか。

まあいずれにしろ、今回はほぼmono記事へのポインタということで、詳しくはリンク先の記事を見て下さい。

ちなみに、もう2,3ヶ月後に、MonoDevelopに関する記事も書いて出すつもりです。

*1:連載のタイトルは昔なつかしい無関係な連載のパクリなのですが、同サイト側でつけていただいた見出しのようなものがインパクトを総ざらいしていて、結果的に全く存在感が無く空振り感ありますネ

Xamarinの2年半を振り返る

Xamarin Advent Calendar 24日目のエントリーです。クリスマスイヴということで、少しふんわりした振り返り話を書きましょう。

今さら書くこともないでしょうが、わたしはXamarinの中の人をやっています。もともとはMonoの中の人なわけで、Xamarinの中の人としてのポジションでは正直個人的には大したことはやっていません(いやそれはmonoでもか)。特に最近はAndroidの仕事も放置して、今さらMSBuild.exeの実装を勝手にやっているわけでして、いつクビになってもおかしくない仕事ぶりであります。Xamarinとしての仕事は、もう少しネイティブ寄りの開発をさせてくれるかLinux版を出すかしてくれたらやる気3-5倍くらいでコミットするのになぁといった感じでくすぶっています。

まあ戯言はおいといて、今回はわたしからの〆エントリということで(てか2日しか書いていないのですが)、とりあえずゆるい内容として、非技術的な側面から、Xamarinが発足から今までどんな歴史を辿ってきたのか、今どんな会社になっているのか、ざっくり書ける範囲で書こうと思います。一応、書いて問題ないであろう範囲で…

Xamarinは設立2年半の若い会社です。どんくらい若いかというと、3x歳(隠した)のわたしがかなり高齢の部類に属するくらいです。CEOのNat Friedmanは今年で36歳、CTOのMiguel de Icazaも今年41歳で、この業界ではそれほど若くないと思いますが(!)、彼らは15年くらい前にHelix Code(後のXimian)というLinuxデスクトップ開発の会社を設立していたわけで、起業家としては二度目の挑戦ということになります。

Xamarinのスタートラインはたいへん厳しいものでした。Monoチームは解体され、しかも全員が即座にNovellもといAttachmateからレイオフされたわけではありませんでした。国にもよりますが、欧州の労働者保護はそれなりに手厚く、会社都合のレイオフに3ヶ月〜半年を要するメンバーもいました。幸いなことに(?)日本には支社がありましたが*1、そもそも自国法人が無いメンバーもいましたし。そんなわけで、レイオフ後わずか1週間で設立されたXamarinに参加できたメンバーは多くありませんでした。

それでも米国のメンバーは比較的容易に参加できたわけですが、ここで難題が立ち塞がります。Novell時代に開発したMonoTouchとMono for Android(それぞれ当時の名称)はAttachmateに著作権が残っていて、Xamarinではフルスクラッチでこれらを再実装するところから始めなければなりませんでした。Xamarinでは実際にそのようなフルスクラッチ開発が始まったわけですが、フルスクラッチでやる以上、同じ製品の開発メンバーを投入するわけにはいきませんでした。ここでメンバーの総入れ替えが発生します。ここで製品開発に割り当てられたのは、解体されたMoonlightチームでした(今でもiOS方面は彼らが主力です)。メンバーが半々になって、それぞれiOSAndroidに割り当てられました。両方に参加していてMonoMacの基盤も作ったスーパーハッカーがいました。彼はどうすればいいのでしょうか? …無理です。どう考えても無理。彼は日本の某社に転職してしまいました*2。そもそもろくに準備期間もないままに設立したばかりのXamarinには、当然ながら米国の従業員に十分な給料を確保できる保証はありませんでした。家庭持ちのメンバーには安定した職が必要です。同様の理由で、Xamarinにjoinしないことを決めたメンバーが少なからずいました。

絶望的に見えたXamarinのスタートアップですが、1ヶ月ほど経って状況が好転に向かいます。まずNatがMiguelと手を組んでCEOとして参加することが決まります。NatはNovellを途中で辞めた後、旅人として夫婦で世界を放浪していたのですが(それをちょくちょくblogに書いていて、ちょくちょく見ていたのを覚えています)、Miguelが一人では抱えきれない難題を何とか処理するべく彼に相談したのを機に、経営者としてこの業界に戻ってくることにしたわけです。あの2人がまたタッグを組む! 希望が見えてきました。彼は参加するなりその交渉能力を多分に発揮して、2ヶ月のうちに資金調達とAttachmateとの提携・ライセンス供与まで漕ぎ着けます。わたしは実のところNatとの繋がりは皆無だったのですが、実に短期間のうちに、彼がいかに優れた経営者であるかを見せつけられました。わたしがこの時点で参加できると判断したのも自然なことだったでしょう。

この時点でXamarinのメンバーはおよそ20人(この写真の頃ですね)。Natに「厳しいスタートアップだね」と言ったら「いや、うちはすごく恵まれている。どのスタートアップもエンジニアを集めるのがすごく大変なんだ。その点うちは既に腕の確かなハッカーがたくさんいるからね。」と返されたのを覚えています。わたしは「最初からこれだけのメンバーを食わせなきゃいけないなんて無理ゲーすぐるしマイナススタートなんじゃないか…」としか思っていなかったので、その視点にはハッとさせられたものでした。

Natはその後も矢継ぎ早に経営策を立てていきます。Novell時代にMonoチームに全く存在しなかったマーケティングチームとセールスチームを発足させ(この辺はNovell時代にうちのチームが自由に出来なくてもどかしく思っていた部分でもあります)、ボストンのオフィスを開発拠点として据え置いたまま、サンフランシスコに新しくオフィスを設立します(今はこちらにも開発メンバーはいるのですが)。

一方でNatは製品開発にも新しい風を送り込みます。製品に大きく欠落していたドキュメントを重視し、担当のチームを作って新しいメンバーを多数投入しました。MonoプロジェクトとXamarin製品の各サイトに大きな落差があるのは、彼らドキュメントチームの仕事の成果です。Gtkの世界でガチガチに作られたMonoDevelopのユーザビリティを改善するべく、専任のUIデザイナーを雇って、さまざまな改善を施しました。設立初期に大技なhackとして作り上げられていたライセンス処理も、よりプロフェッショナルな製品らしく動作するよう、多大な実装作業が行われました。

この頃の人数は既にだいたい60人くらいでしょうか(この写真の頃です。設立1年目頃に、ひっそりとXobotOSなどというものを作り上げて公開したりなどしている裏では、さまざまな改善策が行われていたわけです。

今年の冬の終わりに行われたリリース "Xamarin 2.0" は、それら全てのピースが出揃って、初めて大々的に行われました。この頃はいろいろ展開が早くて、ライセンスまわりなどはわたしも実際に出てくるまで具体的に把握していなかったものでした。

Xamarin 2.0は、そのリリース単体では終わりません。もうひとつ、マーケティングチームが仕掛けた大きなイベントがありました。Xamarin Evolveです。当初は「この規模の会社で自社イベントを大々的にやって成功するのか…?」と半信半疑というか2信8疑くらいだったのですが、Xamarin 2.0のリリースからほど無い時期に、新製品の機能を中のメンバーが詳しく紹介するということになり、さらにMicrosoftからもHanselmanが来てメイントラックでセッションをもつということで*3、蓋を開けてみるとそこには600人以上もの参加者に来てもらえました。えらい数ですね。もちろん、それまでオンラインでしか知ることのなかったユーザー・ハッカーの著名人の多くとも顔合わせ出来たのでした。イベントの〆にNatが「来年もまたやったら来るかい?」と爆弾を投げ込んだ時の歓声は、もう半年くらいは忘れられません。

Evolveまでの怒涛の流れが一段落ついたところで、しばらく静かになっていましたが、その間にコンサルティングパートナーやリセラーの拡大などを経て(わたしは純粋に開発メンバーなので関与していないのですが、日本でもComponentSource, XLsoftといったパートナーが登場しました)、Xamarinはどんどん拡大していきました。現在は既に100人を突破しています*4。開発面では、Android 4.3やiOS7といった、プラットフォームの新リリースへの追従というかたちで、着実に行われてきました。

そして先月、今年の最後に打ち上げられたのが、MicrosoftのVisual Studio 2013リリースに合わせて発表された、Microsoftとのパートナーシップです。それに合わせて、Xamarin製品も地味に色々なリフレッシュが、主にIDE方面で施されました。ここ2年くらいの間に、Microsoft技術はかなりオープンソースの方向に舵を切っていて、XamarinでもReactive Extensionsの統合やF# プロジェクトモデルのサポートなど、いろいろ取り込んでいるものがあります。Monoがオープンソース.NETの代表であった時代は過去のものとなり、Microsoftが自ら様々なコンポーネントをオープンに公開している時代になった、とわたしは思っています。クローズドソースのライブラリでも、ポータブルクラスライブラリ (PCL)が無償公開*5され、Microsoft.Bclパッケージのライセンスにあった悪名高い「Windowsでのみ使用できます」条項も削除され、Xamarin製品と組み合わせても使えるようになりました。

今回の発表を受けて、日本でもXamarinをいろいろ紹介してくれる人が出てきたり、使ってみてくれる人がいたりと、Xamarinまわりはなかなかエキサイティングで希望の見える存在になっていると思います(しばらく前に.NETがthe dying platformなどと言われたりしていましたが*6、そこでもXamarinが救世主扱いされていましたね)。

…というわけで、Xamarinの2年半振り返りエントリーでした。明日でXamarin Advent Calendarもまさかの(こら)完走ですね…! 大半をドライブしていたあめいさんに敬意を表してたすきを渡したいと思います。

*1:あ、ちなみにわたしはサクッと会社から提示された退職条件に同意して辞めていますw Mono以外の仕事で残るというのはやっぱり考えられなかったので

*2:そういえばMonoを製品に組み込んでいる会社が日本にもあったような気がしますね…

*3:ちなみにわたしは全然彼の話を聞いたことがなかったわけですが、当日は笑いまくりでした

*4:まだこの人数で全員集合したことはないので、写真もありません

*5:オープンソースではなくあくまで無償なんですねー。ここは今後の課題です。何しろOSSプロジェクトが無制約に参照できないので

*6:そんなことは無い気がしますが、Windows本体のシェアが減っているのでそのインパクトはあるかも

XamarinでAndroidオープンソースライブラリ徹底活用

はてなダイアリーに書くのがたいへんひさしぶりな気がしますが(あ、はてだじゃなかった)、Xamarin Advent Calendar 8日目のエントリーになります。8日目にして初めて登場です。いやわたし別件で毎日書きたくて走らせているネタがあるので他所までは手が出せず…

さて、ここ1ヶ月ばかりMicrosoftとXamarinの提携があって、XamarinまわりのセッションをC#/.NET界隈のいろんなところで聴けるようになったみたいで、わたしとしては自分でその手のものをやる必要が無くなって、ますます身軽になったキモチでいっぱいでございます。

まあ戯言はそのくらいにして、今日はライトな話を書こうと思います。まあわたしはAndroid担当なので、Androidまわりの話です。実のところテキスト量はパないのですが、技術的に掘り下げた話はほとんど無いので、気軽に読めると思います。

最近「Androidオープンソースライブラリ徹底活用」という書籍が発行されました。 素晴らしい。何が素晴らしいって全部オープンソースのライブラリが対象なんですねコレ。

Androidオープンソースライブラリ徹底活用

Androidオープンソースライブラリ徹底活用

 

AndroidSDKJavaですが、Java向けのライブラリが直ちに再利用できるかというと、必ずしもそういうことはなくて、むしろAndroidフレームワークに特化したものを使うことが多いでしょう。この本も主にそういったライブラリを紹介することを主眼に置かれているものだと思います*1

さてXamarin.AndroidC#の世界なので、この種のJavaで書かれたAndroidライブラリがJavaベースのAndroidアプリを作るようにそのまま使えるわけではありません。んが、Xamarin.Androidには既存のJavaライブラリをそのまま取り込んで使える「Javaバインディングライブラリ」の機能があります。これを使うと、Mono.Android.dllというAndroidフレームワークに対応する.NETのライブラリがAndroidフレームワークにシームレスにアクセスできるのと同じように、既存のJavaライブラリを「あたかも.NETのAPIであるかのように」使用することができるわけです。

便利ですね。便利ですが、簡単に出来るとは限りません。使うのはそれなりに簡単ですが、巷にあふれるXMLスキーマからxsd.exeで簡単にXMLシリアライズできるクラスを生成できないのと同様、JavaライブラリからのC#へのマッピングは、ある程度の知識が要求されます。いやJavaC#の違いに起因する癖を知ってしまえば出来ることが多いですが…

ともあれ、今回はその詳細の説明はしません(それは機会があればまた書きます)。この新刊では、50以上もあるオープンソース ライブラリの使い方を説明されているようです。その多くは割とポピュラーなもので(まあそうでなければ書籍化も難しいでしょう)、実のところXamarinおよびユーザーコミュニティでも、それらのライブラリを使えるようにしている人たちがそれなりにいます。

というわけで、今回はこの本で紹介されているライブラリに相当するJavaバインディングライブラリ、があるもの、をずらっと並べていきたいと思います!

(アリモノだけを並べます。今バインディングが無いものはN/Aと書いておきます。)

Chapter 01  UI関連ライブラリ

01-01   android-support-v4

http://components.xamarin.com/view/xamandroidsupportv4-18
これは、android-support-v4パッケージのrev.18に対応するものです。supportパッケージのrevisionはチマチマと上がっていって、バージョン間の互換性はそこはかとなく失われていくので、どうやらrevisionごとにパッケージしていく方針にしたようです。(わたしは実のところそれは気に入らず、Android SDKのライフサイクルを理解していないやり方だ、と主張しているのですが。)

01-02   ActionBarSherlock

https://github.com/xamarin/monodroid-samples/tree/master/ActionBarSherlock

ABSのバインディングはもちろんあります。

01-03   Android-PullToRefresh

https://github.com/xamarin/monodroid-samples/tree/master/ActionBarPullToRefresh
Android-PullToRefreshライブラリはメンテナンスされていないので、代わりにActionBar-PullToRefresh https://github.com/chrisbanes/ActionBar-PullToRefresh を使った方が良いのではないかと思います(がもしかしたらこっちを推奨できない理由が何かあるのかも)。そのActionBarPullToRefreshのバインディングはこちらにあります。

01-04   SlidingMenu

https://github.com/xamarin/monodroid-samples/tree/master/SlidingMenu
このバインディングもこちらにあります。monodroid-samplesにはわれわれがportしたサンプルがさり気なくいろいろあります。

01-05   SwipeListView
N/A
01-06   MultiChoiceAdapter
N/A
01-07   StickyListHeaders

https://github.com/jamesmontemagno/XamDroid.StickyListHeaders
        コミュニティによるバインディングがあります。

    01-08   android page curl
N/A
01-09   ViewPagerIndicator

https://github.com/xamarin/monodroid-samples/tree/master/ViewPagerIndicatorBinding
Xamarinのサンプルとしてあります。

01-10   NewQuickAction
N/A
01-11   Android ViewBadger
N/A
01-12   Android ProgressFragment
N/A
01-13   HoloEverywhere
N/A
01-14   HoloColorPicker
N/A
01-15   aFileChooser
N/A
01-16   Android Validator
N/A
01-17   PhotoView
N/A
01-18   ImageLayout
N/A
01-19   StyledDialogs
N/A

Chapter 02  画像処理ライブラリ

02-01   GPUImage for Android
N/A
02-02   ZXing

http://components.xamarin.com/view/zxing.net.mobile/
ZXingのライブラリは、かなり初期の時点でXamarinのコンポーネントストアに登録されていたものです。

02-03   svg-android

https://github.com/xamarin/monodroid-samples/tree/master/SvgAndroid

実はバインディング ライブラリのサンプル第1号として使いました。

02-04   android gifview
N/A

Chapter 03  ネットワーク関連ライブラリ

03-01   Asynchronous Http Client for Android
N/A ... System.Net.HttpClientを使えればいいものでしょうかね?
03-02   Volley
N/A ... (同上)
03-03   Universal Image Loader for Android
http://forums.xamarin.com/discussion/1156/adding-android-universal-image-loader-libraryバインディング プロジェクトに必要なファイルの内容があります
03-04   Scribe
N/A ... Xamarin.Authを使えば良いと思います。

Chapter 04  データ処理ライブラリ

04-01   JsonPullParser
N/A
04-02   Gson
N/A ... .NETなのでさすがにバインドする意味がないように思います。protobuf, msgpackなど.NET互換のシリアライザを使うのが吉でしょう。(それだけじゃない? 使ったことがないのでわかりません)
04-03   dom4j
N/A ... Linq to XMLなどがあるので、それを使えば良いでしょう。
04-04   jsoup
N/A ... SgmlReaderなどを使えばXMLライブラリで操作できるでしょう。

Chapter 05  データベースライブラリ

05-01   greenDAO
N/A ... 1年前のスレッドですが「XamarinでORM何がいい?」 http://forums.xamarin.com/discussion/421/orm-selection
05-02   ActiveAndroid
N/A ... (同上)
05-03   SQLCipher for Android

https://components.xamarin.com/view/sqlcipher-for-xamarin/
これもかなり初期からコンポーネントストアに存在していました。

Chapter 06  設定系ライブラリ

06-01   UnifiedPreference
N/A
06-02   DateTimePicker
N/A

Chapter 07  地図ライブラリ

07-01   Polaris2
N/A

Chapter 08  ログライブラリ

08-01   android-logging-log4j
N/A ...「log4netはXamarinで使える?」 http://forums.xamarin.com/discussion/3070/log4net-usage
08-02   ACRA
N/A ... 実は昔自分で試しに作ったことがあるんですが(動いたような気がする)、ソースがどこかに消えてしまいました…

Chapter 09  テストライブラリ

09-01   Robotium

公開していませんが昔作ったのでMetadata.xmlの内容だけ置いておきます。

<metadata>
  <attr path="/api/package[@name='com.jayway.android.robotium.solo']" name="managedName">Com.Jayway.Android.Robotium.SoloNS</attr>
  <remove-node path="/api/package[@name='com.jayway.android.robotium.solo']/class[@name='Solo']/method[@name='finalize']" />
</metadata>
09-02   FEST Android
N/A ... XamarinはJUnitを提供しない(NUnitLiteを提供している)ので、これをバインドする意味は無いでしょう。
09-03   Mockito
N/A ... XamarinはJUnitを提供しない(NUnitLiteを提供している)ので、これをバインドする意味は無いでしょう。NUnitにはNUnit.Mocksがあります。
09-04   Robolectric
N/A ... Robolectricは開発ホスト側ライブラリなので、Androidバインディングにはなりません。

Chapter 10  デバッグライブラリ

10-01   smali
Xamarin.Androidアプリにはdexファイルが含まれるので、それを解析することは出来ます。解析すれば、大半のJavaコードはJNI経由でmonoのAPIを呼び出しているだけであることが分かるでしょう。.NET部分の.dllはXamarin Studio (MonoDevelop)のdisassemblerで普通に解読できます。
10-02   dex2jar
これもXamarinアプリに含まれるdexに対して使えます。

Chapter 11  アニメーションライブラリ

11-01   NineOldAndroids
https://github.com/xamarin/monodroid-samples/tree/master/NineOldAndroids
11-02   ListViewAnimations
N/A

Chapter 12  グラフ描画ライブラリ

12-01   HoloGraphLibrary
N/A

Chapter 13  コード最適化ライブラリ

13-01   AndroidAnnotations
Android Annotationsは半ばEclipseのbuilderフックであり、MonoDevelopで使えるわけでもなく、バインディングを作る意味はほぼ無いでしょう。そもそもAndroid Annotationsで得られるメリットの大半は、XamarinではAttributeで実現しているものであり(ActivityAttributeを付けたら勝手にAndroidManifest.xmlに追加されるなど)、特にこのライブラリを使用する意味はないと思います。
13-02   Android Query
N/A
13-03   RoboGuice
N/A ... 実はこれ、長いことわたしがバインディング プロジェクトまわりの仕事をしていた時に、ターゲットにしていたもののひとつだったのですが、当時は「.NETのライブラリにあるものはバインドしない」方針のもと、Java.Util系のコレクション類が大量にMono.Android.dllから削られていて、存在しないクラスに対してバインドすることは出来ないので失敗、みたいなことになっていました。最近は試していないのでもしかしたらうまく出来るかもしれません。(やって意味があるのかはわかりませんが。)
13-04   Butter Knife
N/A ... 初めて知りましたがイイですねコレ。ちょっとこういうのをサポートする仕組みを導入したいかも。

Chapter 14  通知ライブラリ

14-01   Crouton
N/A

Chapter 15  Web APIライブラリ

15-01   Twitter4j
N/A ... Twitterを操作する.NET APIはきっとあるでしょう。Windows Phoneで動くコードなら動くはず。
15-02   Evernote SDK for Android
https://github.com/evernote/evernote-sdk-csharp があって、Windows Phone 7で動くようなので、きっとXamarinでも動くでしょう。
15-03   flickrj-android
https://flickrnet.codeplex.com/ が使えることでしょう。

…ふう。大量にあるので、だんだん途中から説明が手抜きになっていくのが見て取れますが()、ともあれXamarinに移行してもそれなりにライブラリが使いまわせそうだ、ということが説明できたかと思います。

↑でN/Aになっているものは、一部は原理的に無理なもの(RobolectricとかAndroid Annotationsとか)や困難なもの(大量のAPIマッピング補正作業を必要とするもの)もありますが、大半は「誰も試していない」になると思います。なので、簡単に追加できるかもしれませんし、難しいかもしれません。いずれにしろ、この種のJavaバインディングのライブラリは、それなりに増えていくことでしょう*2

最近では、component storeの他に、NuGetパッケージとして発表するというルートもあるので、その方面でライブラリを探すことも可能だろうと思います。NuGetなら審査もありませんし、気軽な発表はやりやすいですね。

さて、そんなわけでそろそろ8日目のエントリーは終わりにしたいと思います。

*1:まだ現物を見ていないので想像で…

*2:作業する人が少なくなればバージョンアップに伴って減るかもしれませんがw

Xamarin7月リリースについて

リリースされてから5日ほど経って書いているわけですが、しれっと7月のXamarinリリースについて書こうと思います。

今回のリリースは、7/22-7/25に行われたmonkeyspaceカンファレンスに合わせるかたちで行われたもので、つまりそれなりに予定されていたものです。7月リリースの目玉としては、Mono 3.xのバージョンが(ベータではない)3.2で正式版となって、それに対応したバージョンとなったというのが大きいです。

Mono 3.2の要点は↓のような感じです:

  • ガベージコレクターがデフォルトでsgenになりました*1。それに加えてGCの停止時間を抑える low pause mode と、nursery collectionに加齢情報を使用して一定の水準に達した時点でのみメジャーヒープへのコピーを行う promotion-age が追加されたようです。この辺は環境変数MONO_GC_PARAMSで調整できます。
  • C# 5.0のasync/awaitと、関連するライブラリAPIが正式版として追加されました*2
  • 他にもNaClでmonoを動かすためのパッチがGoogleから継続的に流れて来ては取り込まれており、mono 3.2ではarm64サポートが含まれています。あと、3.0以降の変更としては、OS X Maverickが台無しにしてくれたビルドもちゃんと動くようになっています。

本当はここにPCLが入るはずだったのですが【禁則事項です】によりmonodevelopでビルド出来ない問題が出ていて、そのうち何かしらのかたちで(古いコードに戻したりなど)修正バージョンが出ると思います。

Xamarin.iOS、Xamarin.Androidとも、このMono 3.xを使うようになり、C# 5.0のサポートと、System.Net.Httpなどのasyncライブラリが使えるようになりました。(4月からAlpha/beta channelでは提供されていたので、特別に新しいわけではないのですが。)

XiOS, XAとも、F#プロジェクトを正式にサポートするようになりました。Xamarin Studioでこれらを使用するためには、Xamarinから公開されているわけではないF# addinと、Xamarinから公開されているF# iOS/Android addinをインストールする必要があります。

XiOSはインクリメンタル ビルドをサポートするようになり、必要最小限のビルドのみを経てデプロイされるようになりました(このためのオプションを有効にしておく必要があります)。ビルド時間がだいぶ短縮されるようになったはずです。

XiOSはgeneric structsをより幅広くAOTできるようになりました。monoランタイムでgeneric structを使用できなかったのは、ひとえにAppleの動的コード生成禁止制約によるものですが、これを回避するために、一定サイズの構造体用メモリを確保するかたちにすることで、generic structにおいても動的にコードを生成せずgeneric sharingを実現できるようになりました。結果的に無駄なメモリが消費されることになるわけですが、全く使えないよりはずっとマシでしょう。

XiOSはiOS 7とそのSDKが公開されてすぐに対応しています。

XAはより多くのAndroid/Java APIにアクセスできるようになりました。これは既存のJavaライブラリのバインディングdllを作成する時に、XAがバインドしていないAPIがあるせいで不完全なバインディングしか作成できない問題が少なからず生じていたことから、本来使う必要が全くないAPIであっても削らずに公開したほうが良い、という判断の変更によるものです。

ちなみに7月リリースの公開作業の最中にAndroid 4.3が公開されたおかげで先週は対応作業に追われてたいへん忙しかったのですが、遠からずXAの対応版が出るのではないかと思います。しれっとbionicのbsearchがmanpagesに合わないNetBSDベースの実装に変わって現状4.3では何も動きません(使い方次第ですが、NDKでbsearchを使っている直接/間接的に使っているコードは死ぬかもしれません)。

XiOS, XAとは別に、モバイルAPIの大きな動きとして、Xamarin.Mobileのライブラリがオープンソースで公開されました。

わたしは実のところまだ使ったことがないのですが、主にXamarin APIと.NETをWindowsで使いこなしているハッカーが書いているライブラリで、きっと参考になると思います。

7月リリースの内容は、とりあえずこんなところです。

*1:どうでもいいのですが、うちのGCハカーに「日本人は何でも3,4文字のカタカナにするからgarbage collectionもガベコレなんだぜ」って言ったら無駄にウケてしまい、以来彼はことあるごとにgabe-kore, gabe-koreと言うようになってしまったのですが、Xamarinオフィスに遊びに来た日本人ご一行様にその話をしたら「いやジーシーでしょう」と一蹴されてかなしい思いをしました。dʒíːʃíːじゃなくてdʒíːsíːですからね…!(何)

*2:前々からアルファ版で使えてはいたので、個人的には全く新しいニュースではないですが