AndroidをC#に移植したXobotOS
Xamarinが設立されてからそろそろ1年が経とうとしています（ついでにMono for Androidのバージョン1.0が出てから1年と1ヶ月くらいです）。その間にXamarinはエンジニアを揃え、ドキュメントチームを編成し、QAチームを再編成し、オンラインセミナーを行えるような体制を整えてきたわけです。これだけやってまだ1年とか…まあわたしがjoinしたのは8月ですけど。*1
そんなわけで、設立1周年を記念して(?)、Xamarinからでっかい釣り餌、AndroidをC#に移植したリサーチプロジェクトXobotOSがリリースされました。
http://blog.xamarin.com/2012/05/01/android-in-c-sharp/
これは、アプリケーションがDalvik VM (zygoteプロセス）上のAndroidフレームワークの上で動作しているMono for Androidとはまったく違うものです。OSはLinuxで、基本的なアプリケーションのライフサイクルはAndroidと同じだけど、それを動かしているのはDalvikではなくmono VMということになります。Androidの仕組みは、よくこんな図面で説明されますが、
XobotOSは、この図面のAndroid RuntimeやApplication Framework（とそれより上）をC#のコードで換骨奪胎したものと言えるでしょう。
じゃあJavaで書かれたAndroidのフレームワークはどうやって動いているのか?というと、SharpenというJava-to-C#のトランスレータを利用して、AOSPのソースコードの一部をC#に変換したものをビルドして動かしているようです*2。Sharpenは元々はXamarinで作られたものではないのですが、MonoDevelopでgitサポートを統合するにあたってJGitをソースコード変換してNGitをビルドするために改良を加えたもので、Sharpenは、iPadで電子回路を設計しようと思ったことのある人なら一度は見たことがあるんじゃないかと思われるiCircuitの開発でも使われています。今回、XobotOSを開発するにあたって、このSharpenに、さらに今回大幅に改良が加えられたようです。その成果はXobotOSのソースコードの中に含まれています。
https://github.com/xamarin/XobotOS
現在のXobotOSでは、既にAndroidのレイアウトエンジンとコントロールのレンダリングがC#だけで行えているところまで出来ているようです。（画像はgithubのリポジトリから適当に引っ張ってきました）
今回のblog postでは、パフォーマンス比較もいくつか出ていますが、monoがえらく速いです。
ちなみに、じゃあメモリ消費はどうなのか、ですが、3年前にandroidmonoの開発者（CyanogenModの開発者というのが表の顔でしょうか）がdalvikとmonoの比較記事を書いています。
Xamarinは既存のモバイルプラットフォームをターゲットに商売しているので、XobotOSの開発にリソースを投入するようなことは出来ないわけですが、けっこう面白いものを作れるんじゃないか?というのが、今回の発表ということになります。今回の成果の一部は、今後のMono for Androidにも組み込まれていくかもしれません。既にSkiaのC#バインディングなんかはあるようです。
XobotOSのアイディアは、もともと1年前にXamarin設立後初めて行われた社内ミーティングの時に出てきたものでした*3。1年前というと、まだHoneycombのソースコードがずっと非公開で、2.3でようやくNativeActivityが公開されたものの、そのアプリケーションライフサイクルがJavaから抜け出せていなくて残念なものになっていた、という状態だったように思います*4。それを見て、もうJavaベースのフレームワークをC#に置き換えちゃえばいいんじゃね?みたいな話をしていたのでした。数日後にMonospace conferenceが開かれましたが、そこでも「mono phoneはいつ出るんだ?ｗ」みたいな質問がシメのスピーチの時に出ていたのを思い出します。
…というわけで、なかなか面白い発表だったと思いますがどうでしょう? これだけやってまだ1年なので、次の1年はどうなるのか、まだまだ楽しみです。
news links
PS Suite SDK public betaでC# 4.0 dynamicを使う
昨日ついにPlayStation Suite (PSS) SDKが公開ベータになりましたね。
http://www.playstation.com/pss/developer/index_j.html
昨日はそのタイミングで行われたSCEのAndroidの会のイベントでの話を聞きに行っていました。
http://atnd.org/events/27043?updated_at=1332783364
その内容は id:nakamura001:20120419:1334857193 が詳しいのでそこを見てくださいということにして。
わたしの理解している範囲では、PSSで動いているのは、MonoTouchやMono for Androidと同等の.NET 2.1もどきのランタイムということになります。ランタイムは「もどき」ってほどでもないかな。クラスライブラリは、たとえばXPathNavigatorやXmlSerializerが使える程度には.NET 2.1「ではない」です。これはMTやMfAと同じ匂いがあります。
さて、Mono for Android 4.1にDLRサポートを追加したのはわたしなので、同じ事をPSSでもやってみました。PSSがサポートしているのはC# 4.0相当のコンパイラとそれに対応するCoreCLR相当のクラスライブラリということになり、昨日のイベントでもSCEの方が質問にそう答えていましたが、実はコンパイラの実装であるmcsがC# 4.0をサポートしているだけではdynamic型は使えません。なぜかというと…
- mcsは、dynamicを使ったコードをコンパイルする際には、Microsoft.CSharp.dllの参照があることを要求します（System.Core.dllを参照に追加してSystem.Linqをusing文でインポートしないとLINQ構文が使えないことと似たような構図です）。
- そして、monoのMicrosoft.CSharp.dllは、内部的にはMono.CSharp.dllというC#コンパイラの実体を要求します。
- さらに、System.Core.dllに含まれるExpression TreeのAPIに、DLRをサポートするためのコードが含まれていなければなりません。
これらはどれも現在のPSSには含まれていません。つまり、現在のPSSではC# 4.0相当のコンパイラがあっても、C# 4.0のdynamicは使えないんですね。
今回はこれを無理やり使えるようにします。やることは簡単です。
- mono本体(git master or mono-2-10)をmonodroidのライブラリビルドのオプション --with-monodroid=yes でビルドする。--with-moonlightや--with-monotouchはダメ（これらはdynamicをサポートしません）。
- 出来上がったmcs/class/lib/monodroid に含まれるSystem.Core.dll, Microsoft.CSharp.dll, Mono.CSharp.dll を、PSS Studioのアプリケーション プロジェクトで参照に追加する。PSS SDKに含まれるSystem.Core.dllは参照しない(!)
これだけで、PSSアプリケーション プロジェクトでもdynamicが使えるようになります。仕組みとしては、（確認はしていませんが）mcsは、Microsoft.CSharp.dllの参照の有無を見て、dynamicサポートの状態を切り替えるので、これだけでdynamicが有効になる、というわけです。
id:atsushieno:20120406:p1 でも書きましたが、MfA 4.1のサンプルにはdynamicコードの例として、Microsoftが最近公開したaspnetwebstackから引っ張ってきたSystem.Json.dllに含まれるJsonValue.AsDynamic()を使ったものが含まれています。このソースをPSSライブラリプロジェクトに取り込んで、コンパイルオプションにMONODROIDを設定すれば、PSSでもビルドできて、dynamicなJSONが使えるようになります。
ただ、上記エントリでも言及しましたが、dynamicコードはコストを伴うものだということは理解しておいてください。これを実際にやって動かしてみると、デフォルトの空っぽに近い状態では軽快に動作しているように見えるPSSでも、決して軽くはありません。
ちなみに、mono-reactiveに含まれる System.Reactive.Android.csproj と同じ構成で、PSS向けにSystem.Reactive.dllをビルドして使うこともできます。PSSのクロスプラットフォーム性を実感してくださいｗ
Windows Developer Days 2012
4/24-4/25のWDDですが、参加費ろくまんえんと聞いて今回はスルーしてもいいかなと思っていたのですが、ひょんなことから参加できることになったので、遊びに行こうと思います（特に自分がしゃべるイベントはありません）。
Windows 8はVirtualBoxがお気に召さなくてインストールできず、ネイティブで入れようとしたらパーティションの問い合わせとかが何も無くてこわくて入れていないので（多分このままだとリリースが出てもインストールしない）、Metroまわりはたまに他人の実機で見ているだけの状態でよく分かっていません。それでWinRTも半ば他人事になっているので、この機に色々眺めておこうかなあと思っています。そんなわけで、今まで自分が参加していた時に聞いていたようなのとは全然違うセッションばかり聴いていると思います。
ともあれ、そんなわけで当日は無駄にふらふらしていると思いますので、見かけたら声かけてやってください。
MfA session at 4/7 プログラミング生放送（プロ生）終了
先日書いていたとおり4/7はプロ生でMono for Androidのネタをしゃべってきました。gihyo.jpにレポートが上がっているようです。
http://gihyo.jp/news/report/2012/04/1301
地味ですが当日発表した資料はこちらにあります（当日twitterでしゃべる前に流したやつと同じです）
http://dl.dropbox.com/u/493047/2012/04/MonoforAndroid20120407.pdf
今回はMono for Androidについて話をするのは約半年ぶりということで、大まかな紹介をmonoのレベルから始めてサンプルを動かして内部解剖の話をする、でも基本的にMfAと関係ない話はしない、という構成にしました。id:atsushieno:20120321:p1 でも事前にさらっと書きましたが、わたくし基本的に「ユーザー向け」の話で終わらせない主義なので（マーケティングの仕事でしゃべっているわけでもありませんし）、MfAには関心が無かった／無いがAndroidの話としては興味がある、という人にも刺激になるよう、今後も似たような機会があれば話に盛り込んでいくつもりです。これをやると「難しくて全然わからんかった」という反応と「これは面白かった」みたいな反応がだいたい同じくらい見られて、概ね期待通りになります（今回はアンケートの回答を見せてもらえたのですが、そんな感じでした）。
デモはネットワークが不調だったり前日にやった時には引っかからなかったような問題を踏んだりと、個人的に踏んだり蹴ったりな失敗例だったのですが、サンプルは公開リポジトリにあるのでソレを見てみてください。MfA 4.1は前日リリースでしたが、UI designerはリリース前日版というわけではなかったし、当然ながら中の人特権で最新版で準備していたので、そういう問題ではありませんでした。（スライドの中身未発表のネタじゃねーか!どうすんだよ!?っていうプレッシャーはありましたが…）
ちなみに最後に出てきたおまけの話ですが、基本的に4月いっぱいが期間ということになります。
懇親会でもmonoの勉強会的なことをやってほしいという話をいただいたのですが、自分でイベント立てて予約とって人集めてとかもう本当に面倒で仕方ないので…勉強会をやるのでしゃべったり参加したりしてほしいということがありましたら少人数とか非公開とかでも気軽に行きますので声をかけてください(!?)
ふっかつ
前回書いたプロ生の後風邪引いたりちょっとやっつけコードを書いていたり日々外出したりですっかり忘れていましたが遅くなってしまいましたが、いくつかネタを書いていきます。
Mono for Android 4.1 released
前回の4.0リリースから4ヶ月もかかってしまいましたが*1、Mono for Androidの最新版がリリースされました。
http://docs.xamarin.com/android/Releases/Mono_For_Android_4/Mono_for_Android_4.1.0
Alpha版チャネルへの配信になるので、MonoDevelopならアップデートのチェックダイアログで、VSならMono for Androidの設定で、アップグレードのチャネルをAlphaにしないと出てきません。
今回のリリースの変更点は、リリースノートから引っ張ってくるとこんな感じです（バグフィックスを除く）:
- Java binding library project
- 縮小したデバッグ共有ランタイム
- VS addinのユーザビリティ改善: デバイス選択ツールバー, non-modal deployment, まとめられたlogcat
- MonoDevelopのpublisher dialog
- ICS/Honeycombテンプレート、Fragmentテンプレート
- APIの改善
Javaバインディングが簡単に使えるようになったのは大きいと思います。本来はMono.Android.dllを生成するために使用しているツールでしたが、いろいろ手を加えて外部ライブラリに対応出来るようにしようと始めて最初に出来たのが前回のリリースにあったmaps.jarのバインディング、そして今回のcompatibility libraryのバインディングということになります。ソレとは別にadmob, svg-android, facebook sdkその他いろいろ試してみました（この辺はプレビューブランチのmonodroid-samplesに含まれています）。
facebook sdkは少々事情が特殊で、これはAndroid Library Projectとして配布されているものなので、単なるJarのバインディングではない、リソースの集合も含めたビルド生成物をzipにまとめた上でdllにバンドルするという、トリッキーな仕組みを実装しました。Library projectのビルド出力（binフォルダ以下）をzipにまとめてLibraryProjectZipとしてbinding library projectに追加すると、リソースもまとめて面倒みます。あるいは、ビルド済みandroid library projectのproject.propertiesを追加すると、そこから勝手にファイルを引っ張ってきます(!)。つうかJavaユーザーの人たちも配布がめんどくさいとか言っているようなので、GoogleはLibrary Projectのアウトプットを1つのjarにまとめるようにすべき。
今回のExportAttributeサポートで、APIまわりの制約でJavaでしか出来なかったことがけっこう出来るようになりました。Parcelable.CREATORとandroid:onClickとjava.io.SerializableとWebView.addJavascriptInterface()が使えるようになったのは確認しています。他にも特定のJavaコードを要求するような機能があれば、それもサポートできているかもしれません。
ちなみに、Parcelableサポートまわりを確認しているときに、aidlからC#コードを生成するツールも作ったのですが、やっつけでブラッシュアップする時間も無かったので今回のリリースには含まれていません（というか需要があるのか分からないので今後もどうするか…）。
dynamicが使えるようになったのは、人によっては嬉しいかもしれません。ただ、Microsoft.CSharp.dllとMono.CSharp.dllへの参照が増えてコードサイズが増えて、しかも動的型解決は軽いとは言えないので、使いどころには気をつけた方が良いでしょう。最近Microsoftがリリースしたaspnetwebstackに含まれていたSystem.JsonにあったJsonValue.AsDynamic()を使ったサンプルを書いてみましたが（どこかで見たような例!）、ロード完了するまで割と時間がかかります。
そんなわけで、今回のリリースの新機能の多くはわたしがやっつけていたのですが、無事出てきて安心しました。
ちなみに明日のプロ生勉強会でこの辺の話をする予定はほとんどありません(!)。これまでMono for Androidを使っていたという人にしかおいしくないと思うので…UI designerの話などはちょろっとする予定です。時間があったらぜひ遊びに来て下さい。
追記: Android Designer betaとMfA 4.1の関係ですが、designer betaはMonoDevelopのalphaバージョンとして捉えてもらえれば良いと思います。MonoDevelopをアップデートするとdesigner betaは消えてしまいますが、MfA 4.1にアップデートしてもdesignerは動作するはずです。
*1:2月にリリースと言われていた頃にメンバーの休暇が重なり、3月になるとドキュメントチームがMonoTouch 5.2で手一杯という状況に押しやられ…
WP7でiso2022jp / MS932 (sjis) / MS51932 (euc-jp)を使う
WP7ではUnicode以外のエンコーディングがほとんど?全く?使えないみたいですね。
id:ch3cooh393:20120209:1328742115 - Windows PhoneでShift-JISやEUC-JPの文字列を扱う
そんでJpEncodingというプロジェクトがあって、こういうのは前向きに使ってもらえればいいと思うのですが、コメントされているように、確かにDictionaryに変換テーブルを突っ込んでやるのはちょっと効率悪いです。
そんなわけで普通にmonoのMS932実装を引っ張ってくればいいんじゃん?あっちは変換テーブルリソースだし、と思って提案したわけですが、スルーされてしまい、怒り心頭ryなので、たまたま今日Silverlightを悼む囲む会でWindowsをいじっていたので、移植してみました。内職なんかしているはずがない!
http://dl.dropbox.com/u/493047/2012/03/I18N.CJK.WP7.zip
たいへん古ーいコードなので確かJIS X 0213まわりが怪しかったような気がしますが、本家ソースはここにもあります（たぶんcjk.tableを再生成する必要がある場合には必要）。誰か気が向いたら修正を送っていただければと思います(!)
最後に老婆心ながら書いておきますが、コードの欠点の指摘を人格非難と取り違えてはいけません。やっつけ仕事にはやっつけ仕事の価値（スピード）があります。
