2010/2/16
元ネタは「アドビ、スマートフォン向け「AIR」をリリースへ–まず「Android」から」
前々から、Adobe関連のサイトでは言っていたことなので、それほど、記事の内容としてはびっくりするようなことでもないし、
新しいことでもないのだが、改めてAIRというものを考えるいい起点だと思うので、取り上げてみた。
そもそも、私がAIRという技術に目をつけたのは、ある失敗（だと思う）したという思いがあったためだ。
私は2005年にあるASPの立上げを行った。そこで、リッチクライアントという技術を採用することを決めた。
おんなじような要件がある会社はFlashを採用していたが、私は当時、FlashもActionScriptも知らないし、
何より、ローカルPCにある資源を活用できないという点が気に入らなかった。
まあ、ASPにも関わらず、ブラウザベースではないというあたりは、かなり斬新ではなかったのではないかとおもう。
（ちなみに今もそのサービスは稼働している。）
そして、採用したのが、EclipseのRCPだ。
そこで感じたのが、WEBシステムとクライアントシステムの文化（ノウハウ）の違いだ。
とくに、一番の問題と感じたのが「圧倒的な自由度」だろう。（WEBに比べてという意味）
WEBといういわば、バッチ的なプログラムでよかった。
HTMLとSQLと言語（ロジック）というように、レイヤーが３つにわかれており、さらに通信という手段は選択できないに等しい。
でも、通常のクライアントアプリはちがう。
どこで、どのような手段で通信するかも、どうレイヤーを分けるかも、ルールベースでの抽象論的なものであり、
WEBのような超えられない（超えてはいけない）壁のように立ちはだかる制限はない。
これが、たまらなく、きついのだ。ルールが保てない。
つまり、設計の品質が保てない。
AIR（とその周辺）は、それに比べれば、つよい制約があるから素晴らしい。
アニメーション(Flash)・画面(MXML)・デザイン(CSS)、ロジック（ActionScript)・・・・
１つのアプリを作るのに、いろいろな言語を覚えなくてはいけないのはWEBと同じだ。
そして、ほとんどのアプリ（サービス）が、ブラウザベースのアプリにちょっと気持ちをたしたレベルで満足できるのである。
そのレベルのアプリケーションプラットフォームを求めていた。
これは、かつて、WEBアプリ = JAVAというような感じになったのに近くないだろうか？
サーバ＝JAVA
クライアント=???
と。
そしてそのクライアントとして、新しく、しかも影響力がつよくあらわれてきたのが、SmartPhoneだ。
ビジネスツールとして考えれば、携帯のアプリがあればいいのはわかっていたが、それを行うコストが高すぎた。
しかし、SmartPhoneという今までよりももっとPCに近い、「携帯」が普及しはじめたことで、そのコストも下がってくる。
そして、何より、携帯ならではのデバイスと連携するための手段が必要になるのでブラウザの制限の外に出る必要があるのだ。
サーバで生じた、ある制限のもとでの共通プラットフォームが、PCに広まりきらないうちに、携帯（SmartPhone)に来てもおかしくはないのではないかと思っている。
その候補として、iPhoneは「携帯アプリ」としてその火つけをしてくれたが、iPhoneを離れて、
オフィスでMacが使われるようになるとは思えない。
HTML5が、クライアントツールのデファクトとなってしまうのも、役割がおかしい。
（もし、そうなれば、今度はWEBブラウザの代わりと、機能限定版のHTMLが必要になってしまう。依然としてたんなるViewerレベルでしか機能しないツールは必要なのだ。）
AIRが本気になって、SmartPhoneにおけるプラットフォームとして機能するのであれば、AIRは非常に魅力的で、将来性が高まってくるのではないだろうか？
Posted in 
