友人に「AIRってどうなの?」「いま一つはやらないね」と言われる。

原因はいくつか考えられる。
ちなみに、ここで「WEBアプリ」と記述するが、これはブラウザ上で動くアプリ(サイトともいう)

まずは、WEBアプリの代替としての可能性。

  • 1)AIRで作られていても、WEBアプリでもあまり関係がない場合には、WEBアプリのほうが有利。
  • 2)ブラウザ上でHTMLベースでしか知らないエンジニアにクライアントサイドでのプログラムはハードルが高い。
  • 3)非同期処理対応

1)は、そもそもの必要性の問題だ。
ブランド戦略として、違いを出すためクライアント化するような場合があっても、
機能として必要か?と言われれば疑問がある場合がある。
しかも、ほとんどの人にとってデータの取得元はネットだ。
したがって、オンラインを前提とするならば、AIRである必要性はここではあまりなくなってくる。
さらにGoogle GEARなどローカルのストレージまで持ち始めている。これではますますその必要性が薄くなる。

2)これはJavaScriptでもAjaxなどのライブラリを記述する人はほとんどいない。
したがって、WEBアプリだろうと、AIRであろうとどちらでもライブラリがなければ作れないのだ。
その意味では、両方ともそろっていると思われる。
では、なぜ2で言ったようにハードルが高いのかといえば、AIRでやるからにはAIRの特徴、
つまりクライアントアプリとしての特徴が必要になってしまう。ここでハードルを越えられない可能性が高い。

3)非同期処理というのは、WEBアプリではあまりなじみがない。もちろん最近のAjaxなどを使えば非同期処理があるが、
それでもすべてライブラリでやっているのでその中身や対応すらしないということもあるだろう。
それに、非同期処理という概念がまったくなくてもWEBアプリは作れる。

次にクライアントアプリを作っていた人がRIAアプリを作りたい場合

  • 1)処理が遅い(ネイティブに近い処理をしようとするとやはり遅い)
  • 2)制限が多い(自分のIPアドレスがとれないとか・・・)
  • 3)非同期処理対応

1)は、UIに関してではない。ファイル操作や、ソケットなどを見るとやはり遅さを感じる。
計測したわけではないので正確ではないかもしれないがそう感じる。

2)これはしょうがない。これをなくしてしまえばただのクライアントアプリだ。
Cでも、Javaでも使えばAIRでできることはほとんどすべてできる。ただ大変なだけだ。
でも、発想が途切れてしまうことはある。あー、あとこれだけできれば・・・・という感じだ。

3)さて、非同期処理はWEBアプリにもあるが、これは私個人になってしまうかもしれないが、
スレッドなどを使って自分でその必要性があるならば非同期処理を使える。
したがって、自分でその処理がどのようにふるまうのか定義できるのが普通の中で、
これができないといわれると困る。
非同期処理の中から非同期処理が発生してしまうとちょっと厄介だ。
これは簡単にできることが大変になってしまうので、ちょっと嫌悪感が出てしまう。

さて、ここまで見れば、やはりAIRは必要ないじゃないか?ということになってしまう。
結局、コウモリのような存在かもしれない。(鳥でもなく、動物でもない)

では、AIRという位置づけは意味があるのか?
と考えたときにプラスの面を見てみる。

それは、AIRだから画期的というよりも、今ある問題の1つの解決策という見方をしたほうがいいかもしれない。
では今ある問題とは・・・

1)多様なブラウザへの対応困難
ブラウザがOS化しようとしている。HTMLというレベルでは問題なかったが、今後ますます独自性がでることだろう。
そうなると、アプリを作るとなるといろいろなブラウザに対応する必要があるかもしれない。
AIRであれば簡単だ。AIR対応です。で終了だ。
ただ、ここでの問題は本質的にはAIRでも解決していない。IEでも対応してよ。ってなったらとか?
IE8限定。とか言ってしまえば問題は解決できるじゃないか?
でも、それは技術的問題。本質は、人間側の問題。
「ブラウザ上で動きます」→「他のブラウザは大丈夫」→「セキュリティとかでバージョンが上がるけど、それも大丈夫」
って話になるが、「AIRはクライアントのOS上で動きます。」は、そんな質問が他から出てくることもない。
OSの依存を解決するということで流行ったのがJavaとするならば、
ブラウザの依存を解決するのがAIRだと思えばわかりやすいかもしれない。

2)高機能のブラウザしかない状態は今後もあり続けることができるのか?
GoogleのChrome、Firefoxをはじめ現在ブラウザは高機能だ。IEも十二分に高機能だ。
昔はJavaScriptは禁止といわれた時代もあったが今では、当たり前だ。
さて、これほど高機能になってきたのはサイトがアプリの要素をもち始めたからだ。
しかも、無料だ。これは一見いいようにも見えるが、なぜ無料かといえば、広告があるからだ。
しかも、その広告を出す技術は高機能になり、行動追跡などをおこないそれらの情報は外に流れている。

ブラウザが高機能になったためにいろいろなことができてしまう時代になった。
さらに悪意があればもっともっといろいろなことができる。

そのために、いろいろと企業ではできないようにすることも必要になってしまう。
今、クライアントOS上ではできないように、できないようにと動き始めている。
ブラウザがOS化してしまえば、次はブラウザの番になるだろう。

こう考えれば、単なるメディアでなく機能を提供しようとすると、
インターネットは使いたい。でも、ブラウザ上のルールに縛られるとできない。
じゃ、やっぱり別環境だよね。
というのは不思議ではない考えだ。

作られたアプリが数年動くのであれば、今後どのようになっていくかわからないブラウザアプリはその点で危険だ。
その点、1社のコントロールのもとにあるAIRはその点では安心できる。
私が経験したもので、お客にあるものを導入する際につらいのが「ルールですから」の一言で取りやめになるケース。
たとえば、「JavaScriptは不許可」なんてルールがあったらWEBアプリは動かない。
そのアプリのときだけ「JavaScriptはON」なんて例外は許されないのだ。

まあ、AIRの場合にはそのアプリを導入できるというルールを突破しなけれならないが、
他との依存度が低いので、説得させるのにおかしなルールが入り込んでくるリスクは低いだろう。

3)クライアントアプリのデザインは大変
これは技術的な話になってしまうが、クライアントアプリを作る時にそのデザインは大変だ。
デザインというのは、見栄え(色づかい、ボタンの形)などもそうだが、レイアウトも大変なのだ。
VBアプリで、画面を小さくしても中のレイアウトは変わらずただ見えなくなるだけとかがあるが、
これはHTMLで標準としてできていることもクライアントアプリで実現するには難しいことがある。
しかし、これではあまりにしょぼいではないか?
また、HTMLである程度はデザインと機能の分担が分かれたのは、CSSという簡単なルールがあるおかげだ。
(それでも”ある程度”というレベルだ)
AIRという技術はデザイナよりのプラットフォーム(Flash)から出てきたということは、
デザイナがその制約がわかりやすいということだ。技術者なんて、それに合わせて覚えればいいのだ。
デザイナの気分を理解し、説得させるよりは技術をおぼえるほうが手軽だとは個人的に思う。

まあ、こう見ればASPなどで機能を提供している会社はもっとAIRで機能を提供してもいいのだはないだろうか?
と思う。でもまだブラウザ版も必要になってしまうのが現状だろうから、
それでもAIRしか提供しない思い切りのよさを示せるか、とか、そこまで開発が回らないなどの問題があるだろう。

後はクライアントアプリとしての特徴を出しつつ、WEBの便利さを継承できるか?
というサービスを考えられるか?

ということになるだろう。

したがって、AIRを普及させるためには、まずクライアント型RIA(Rich Internet Application)が必要だという考えが浸透することが一番大切だということになる。
それはもしかしたら、Ajaxが浸透したようにキラーアプリケーションで浸透するかもしれないし、
上で書いた用にセキュリティなどの要因かもしれないが、それはまだまったくわからない。

追加)

あとは、「エンタメ」という領域でいえば、「Flash」でできることをAIRでやる必要性があるのは、
ブラウザの画面をいっぱいにする程のコンテンツでもないが、使っている人の身近においてほしいという場合だろう。
単純にファンの作成などといった場合には、ちょっとした気配りができるツールができるとうれしい。
でも、やはりブラウザをいっぱいするほどの力はない。

こうなると、その環境は十分に普及しているか?ということが大変重要になってくる。
AIRはそういった時に十分なのか?それは提供者の規模にもよるのでわからないが、まだ広まっているとは言えないだろう。
(デスクトップガジェットというもの自体が広まってるとは言えない気がする。)

したがって、この分野でいえば強力なプロバイダが使うか使わないか?という決断になるわけだが、
決断するにはその理由が必要なわけで、そのために、AIRがAIRであることの意味として普及するためには
上のようなことが広まる必要性があると思う。
その結果として、強力なプロバイダが採用ということになるのであろう。

お仕事のご依頼・相談を承ります
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら

Leave a Reply

お仕事のご依頼・相談
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら
ソフトウェア&ライブラリ




ライブラリ
airxmail(en)
AIR版メール送受信ライブラリ
airxzip
AIR版ZIP圧縮・解凍ライブラリ
執筆書籍
本、雑誌等

WEB記事:CodeZine
執筆記事はこちら
カレンダー
2009年8月
« 7月   9月 »
 12
3456789
10111213141516
17181920212223
24252627282930
31  

カスタム検索
RSS
Add to Google < !–adsense–>
アーカイブ
カテゴリ
にほんブログ村 IT技術ブログへ