MacBook + Snow Leopard での Android 開発環境の構築

MacBook + Snow Leopard は、今のところ Android プラットフォームの開発環境として公式にはサポートされていない。

Android プラットフォームではなく、Android アプリケーションの開発環境としてはどうだろうか？Android アプリケーションの開発環境としてはサポートされている。

しかし、アプリケーションのコードに JDK 5 と JDK 6 で非互換なところがあると、ビルドできなかったりする。Android プラットフォームでは JDK 5 のみサポートされていて、JDK 6 でビルドしようとしてもはじかれてしまう。

というわけで、Android アプリケーションを開発するときも JDK 5 を使った方がいいと思われる。ただし、JDK 5 は最新の デスクトップ OS から外されていて代わりに JDK 6 が入っていることが多い。Snow Leopard、Ubuntu 10.4 なんかがそうである。

Snow Leopard や Ubuntu 10.4 に JDK 5 を導入する方法は、以下に詳しく紹介されている。

JDK 5 を導入しておくと、Snow Leopard、 Ubuntu 10.4 双方で Android プラットフォームとアプリケーションの開発環境を構築してそれぞれをビルドすることができた。Windows でも Cygwin を使えば Android プラットフォームの開発環境としても利用できるのかもしれないが厳しそうだ。残念でならない。

話は変わるが OS は増える一方で PC 意外ではスマートフォンも OS が多様化しているのでクライアントアプリケーション開発者の苦労はまだまだ続きそうである。クライアントアプリケーション開発者は、マルチプラットフォーム対応を求められることが増えてきていると思うが、そうなったときは Intel Mac が一番いろんな環境をのせられるので気に入っている。というか、Mac が他のハードウェアに載せられない。近頃 Virtual Box が Virtual Mac on Mac を実現しているので、ソースコードにちょっと手を加えてやれば、Virtual Mac on Windows、Virtual Mac on Linux も実現できるのだろうが、法的に怒られるということだろう。

私はソケット通信、それに SSL を被せた通信プログラムを書くことが多い。ソケットでよくやるのが非ブロッキング処理だが、Java 5 ではこれに対応していて驚いた。Java の世界は基本的にスレッドを起こしてブロッキング、というイメージを私は強く持っているのだ。

Android でも使えるようだ。

いわゆる select() である。Java の実装がどうなっているかは知らないが、select() を使うかプラットフォームに合わせた実装をしているかのどちらかだと思う。Linux なら epoll()、BSD なら kqueue()、Windows なら WaitForMultipleObjects()、これ以外の POSIX 互換環境なら select() といった具合だ。これらはイベント通知機能と呼ばれるらしい。

そして、ソケット通信、SSL、非ブロッキング処理という組み合わせで気をつけないといけないのが、SSL レベルでのデータの読みこぼしである。OpenSSL でいえば SSL_pending() だ。イベント通知機能を使って受信を検出してから SSL_read() を一度実行しただけでは OpenSSL が受信できているデータをすべて読み出せるとは限らない。よって、イベント通知機能で受信を検出できない限り SSL_read() を実行しない、という風にコードを書いてしまうと次にデータが受信されるまで無駄にプログラムがねんねしてしまう。この辺は、仙石さんの記事が詳しく、しかも分かりやすい。

Java でソケット通信、SSL、非ブロッキング処理という組み合わせでコードを書くときは同様の問題が起こりそうである。幸い、Android では NDK を使えば OpenSSL が利用できるので悩むことはない。

どんどん話がずれていくが、C 最高、ということだ。

Delphi ( Object Pascal ) にはじまり、JavaScript、ActionScript、C++、Java、C#、Python、Ruby、Objective-C といろんな言語をかじってきたが、C が一番おかしなことになりにくい。最初は何もないが、先達の資産を一番活かせる。どんな環境でもほぼ間違いなくビルド・実行できる。オブジェクト指向も表現できる。コンパイルエラーが分かりやすい。複雑な GUI アプリケーションや Web アプリケーションには向かないが、それ意外の部分で何かコードを書くとき、私は可能な限り C を選択するだろう。シンプルが一番だ。