« 二時間かけて長文書いたのに...消えた！そんな時は、BlogWrite | メイン | Movable Type 3.3 Beta 1 日本語版 と BlogWrite »
2006年06月01日
クロスプラットフォームでのアプリケーション開発のまとめ
アプリケーションを開発、頒布していると、たまにMac版はありませんか？とかLinux版は？といったお声をいただきます。ですが、現実は中々難しい所があって、往々にしてそれぞれのOSにあわせて一から作り直すぐらいの労力がかかります。
しかし、やはり多環境向けのソフトウェア提供というニーズは以前からあり、特に最近になって要望が増えている気がします。そこで、最近の状況をちょっと調査してみました。ここでは、Windows、Mac、Linux上でのGUIアプリケーションについてのみ扱います。フォームがあってボタンをクリックしたりして操作するアプリケーションのことです。
wine - Linuxなどの環境で、Win32アプリケーションを動かす。Win32API互換を目指している。
BlogWriteを含む一般的なWindowsアプリケーションは、Windowsに用意されているWin32APIを直接・間接的に叩いて動作します。wineはそのWin32API環境を用意することによってLinux上などでWindowsアプリケーションを動かすものです。
wineの完成度はかなり高いのですが、Win32APIすべてに対応しているわけではなく、対応されていない部分も多いです。ですが、試しにシンプルなアプリケーションを作って、wineで動かして見たら、ちょっと見た目が崩れる所もありましたが普通に動きました。動かない代表的な例として、IEコンポーネント（MSHTML）を利用したアプリケーション（BlogWrite含む）は使えません。WinInet（インターネット通信）周りも動作がかなり微妙。その他地雷多数あり。
結局、一部のアプリケーションしか完全には動かないのと、wineで動かす事を考慮に入れつつ開発しなければならないという制約が出てきてしまいます。その上、wineで動かしても、ネイティブな環境の動作や見た目（テーマや外観）からするととても違和感があります。MacOSX上でWiindowsアプリが動いている感じ。最近出たLinux向けPicasaなんかはかなりの出来だけれどもやっぱり一部機能は削ってあるようですね。
上記の制約をクリアすれば、とりあえず動作させることは可能ですが、ちょっとした修正で動くものでない限り、あえてwineを選択するのは現状ではお勧め出来ない感じがします。
Java - かつてwrite once run anywhereと喧伝されたが...
Javaで開発されたアプリケーションは、
１）大きなJavaランタイムをダウンロードして入れなきゃ動かない。
２）GUIアプリは動作が重い（ネイティブウィジェット使っても）。
３）見た目に違和感がある。
４）Javaランタイムのバージョン違いで動かなくなるとか、
５）他
など、色々あって、Javaで作られた一般向けデスクトップアプリケーションにはほとんどお目にかかったことがありません。というかよく使われるJavaアプリでは開発用のIDE、eclipseぐらいしか個人的には聞かないかも...。
.NET/mono - マイクロソフトが推し進めるJava対抗路線。複数言語による共通ランタイムによるアプリケーション実行環境。
伏兵。もしかしたら将来的に、一番可能性があるかもしれない。けれども...
現状では、.NETを利用する意義はほとんどない感じです。.NET上じゃないと出来ない事っていっても特にない（文字コード周りがすっきりしているのが一番の利点、とかぐらい？）ですし...。（もっともVB6とかで業務アプリ等を使っているなら.NETに限らずどれかに移行した方が良いけれど...。）
１）.NETランタイムをダウンロードしてインストールしなければならない。
２）ネイティブのアプリケーションと比較してやっぱり動作がもっさり。
上記二つは時間が解決する感じです。次期WindowsのVistaが出てくる頃には、上記の問題は無くなっているとなると、複数言語で共同開発出来るのと、ランタイムさえあれば何所でも動くという利点が急に光って見えてきます。
そこで登場するのが、monoです。monoはNovellが中心となって勧めている、Linux（＋MacOSX）環境での.NET環境（ランタイム）で、既に最近のLinuxでは実用的に使われています。例えばSuSEでは、デフォルトでmonoが入っていてパッケージ管理やらデジカメ画像管理ソフトや音楽プレーヤ等々mono上作られて動くアプリケーションが幾つもバンドルされています。
つまり、純.NET向けのアプリケーションであれば、今後WindowsとLinux環境（あとMacもか...）で違和感なく簡単に動作するようになる可能性大、と個人的に感じました。但しmonoが頑張ってくれれば、の話です。現状、GUIデザイナーの出来がまだまだなのと、Windows.Formsの扱いや複数言語のサポートなど、まだまだの所があります。あとIEコンポーネントの代わりにMozillaエンジンをどれだけシームレスに扱えるのかとか個人的に興味あり。
ただ、速度や機能を求めて.NET外のネイティブ機能を利用したくなるものですが、それをしたとたんクロスプラットフォーム性がなくなるという制約もありますが、ある程度は仕方が無なくて、コンパイラスイッチみたいなので対応するしかないのかなと。
Linux上でのRAD環境が無いと言っていい現状、monoとmonodevelopによってLiunx上でのアプリケーション開発容易になるというキラーアプリな感じ...。ただ、現状各環境に合わせたUIの切り分けがイマイチはっきりと見えないのが残念。
Python - 地味に使われてたりする
Pythonには元々GUIライブラリというかウィジェットは無い感じなのだけど、好きに選んで利用出来るというもので、幾つか個人的にも使ってた事もあるクロスプラットフォームのJuiceとかPythonで作られてました。ただやっぱり各プラットフォーム毎に作リ直す作業は膨大なもの。
あと、個人的には..Pythonという言語的には好きな系統なのだけれども...Delphiの洗練されたコンポーネント指向の開発に慣れているとあえて手を出しにくい感じが...。
Delphi/Kylix
元々本命と目されていた？Delphi言語によるクロスプラットフォーム向けの開発ですが...ボーランドがLinux上でのKylixというIDEの開発をパタっと止めてしまっていて頓挫中。物凄く可能性があるんですけどねぇ。
Delphiという言語＋VCL（ビジュアルコンポーネントライブラリ）は、Cの柔軟性と、C++のオブジェクト指向と、VBのコンポーネント指向を合わせた感じの開発言語、IDE、ライブラリ環境です。ただ、最近ボーランドによる、Delphi Studio等IDE関連の再編でゴタゴタしています。いっそのこと、NovellあたりがKylixだけでも買収して欲しいなとか密かに希望してたりします。
一応、Delphi互換のフリーの実装として、Lazarusなんてのもあります。Linux上では元祖RAD環境と言って良いかもしれません。Write once compile everywhereって事で、とりあえず、Mac、Windowsでも動くようです。でもKylixの方が良かったと個人的に思うのでまだ手は出してません。Lazarusもやっぱり動きの速いLinux環境に対応していくのに苦労している感じです。
Xul - Mozillaのツールキット
FireFoxとかのやつ。XULrunnerを使えば単体で動くクロスプラットフォームのアプリケーションが作れる、らしいですが、本格的なのは微妙かもしれません。詳しくは触っていないのですが...。
以上、クロスプラットフォーム向けのアプリケーション開発の現状簡単なまとめでした。
一言でいうと、ずいぶん進んだけれど、まだあと一歩かなという所のようです。ただ、実感したのがLinuxの勢いです。個人的にはとても注目していますが、逆に進歩が早すぎて逆に対応が難しかったりします。Macも旧Mac9からMacOSXで*nix系に移行して直ぐにIntelのCPUに移行したりで大変そうです。そんな中で、意外に.NET/monoが色々な違いを吸収できる可能性が一番大きいのでは、と感じました。もっとも余裕であと数年は必要かと思いますが..。
そんなこんなで、もしかしたら仮想PC、特にVmwareやXenなどを使って、OSの中で異なるOSを動かすという形が一般的になって一気に解決してしまうかも知れませんね。vmwareの完成度はもうまったく素晴らしい出来で、Linux上でWindowsを動かすなんて事が簡単に出来ます。まったくもって、どう転ぶのか分かりません。
左の画像は、SuSE Linux上でSuSE LinuxとWindows 2000が同時に動いている所。複数のバージョンのWindowsを動かして動作テストや英語版を入れて国際版の開発、はたまた仮想ネットワークを作って負荷試験など色々使えそうです。一昔前は何台も実際のPCを使ってテストしたものですが...便利になったものです。
投稿者 BlogWrite担当 : 2006年06月01日 03:11
トラックバック
このエントリーのトラックバックURL:
http://www.witha.jp/b/mt-tb-hate-spam.cgi/378
このリストは、次のエントリーを参照しています: クロスプラットフォームでのアプリケーション開発のまとめ:
» デスクトップアプリケーション from デスクトップアプリケーション
バタフライ・ストローク キャラクターズ [Tools] ブログ編集ツール「Windows Live Writer」β版 YahooとMSがマイクロフォーマ... [続きを読む]
トラックバック時刻: 2006年08月18日 22:22
コメント
.NET上でP/Invokeなどでプラットフォーム固有機能を動かす場合にはコンパイラオプションを使ってというのはあまり、よくないと思います。この辺はJavaでも共通して言えることですが基本的にはプラットフォームに依存する部分はクラスにくくりだし、そのクラスの外部仕様をインターフェイスを用いて定義する。そうすると、クラスをリフレクションを使って遅延バインディングできるようになります。
遅延バインディングしないと、依存部分を収容したクラスとアプリケーション本体がタイトにつながってしまうので再コンパイル以外に構成を変更できなくなってしまいます。そこから先はプラグイン的に自分のインストールされたところから適切なものを探すような格好にするか、構成を何らかの設定ファイルにおいておいて、いわゆるDIコンテナなどの方法論を使うことになるでしょう。
ただ、Seesaa2などの既存のDIフレームワークは宿命的に仕様が膨れ上がる傾向にありますし、クライアントアプリケーションというかWindows Formsなアプリケーション向けには別の実装がいるように思います。Kazzzの「JとNの狭間で」 に書かれている内容の受け売りになっちゃいますけど、DIコンテナを開発されている方ってどちらかというとWebアプリケーションを想定して設計・実装する傾向がありますから。
アプリケーションの起動速度そのものはデスクトップの.NET Frameworkではngenを使って事前にネイティブコードを生成することでかなり軽減できます。アプリケーションならばインストーラ内でngenを使ってインストール時にネイティブコードを生成しておくのもよい方法でしょう。
投稿者 G.O.R.N : 2006年07月09日 12:28