前回の記事からの続き。(あまり続いてないけど)
AIRに関する質問を出来る良い機会(北海道WEBコンFESTA2008)があるので、AIR絡みの思いをまとめてみようと思う。
前提
おいらAIRアプリは作ったことはありません。
Flexアプリなら作ったことはあって、ドキュメントなどもそれなりに読んでいるけど、Flexも完璧って感じじゃなくて、それなりって感じです。
AIRは作ってみたいと思って勉強しようとは思うんだけど、イマイチ使いどころがわからなくて、使ってない感じ。市販の書籍も手に取って見てみたけど、こんなんじゃ金は払えないよ、って感じ。
Adobe - ADOBE AIR コンテスト2008受賞作品 とか見ても、へーすごいねー、こんなことできるんだねー、でもなんでAIR?と思っちゃう。別の技術ベースの方が楽じゃないかい?とか。
たとえば、おいらが一番使っているAIRアプリはMockups なんだけど、これも別にAIRじゃなくてよくね?って思う。
やっぱりAIRじゃなきゃ出来ない優勢エリアってのが少ないんじゃないかなぁ。と思いつつ、もっと突っ込んで優勢エリアを見つけようというほど、勢いがある訳じゃない。そんな感じ。
AIR絡みの突っ込みどころをまとめてみた
まずAIRを使ってみて思うこと
- 本格的な事や複雑なことには向かない。あくまでHTML+スクリプトの延長というイメージで、Web上で出来たことをクライアントサイドでもできるようにしたようなイメージ。
- ちょっと本格的なことをやろうとすると、ケアンゴームのようなフレームワークを使いたくなるんだけど、デファクトスタンダードが無いし、小規模と大規模の中間で使うようなフレームワークも無いように思う。(大抵ケアンゴームだとおおげさ過ぎる)
- メモリ管理甘くない? メモリ大食いだったり、よくCPUパワーをごっそり持って行かれる(まぁAIRアプリ作った人の責任もあるんだろうけど)
- 勉強しようと思っても、あまり日本語の情報が無いように思える。特にAIR絡みの書籍についてはFlex本をちょっと書き直したって程度で、よさそうな本が無い。(まぁFlexの本もないんだが) 結局、どこを見るのが良い?
- クライアントOSがWindowsの場合、Windowsネイティブアプリと比べて有利な点はどこ? Webアプリの技術やソースが使えるところだけ?
- マイクロソフトのアップデート用技術なみに、自動アップデートができるような仕組みは無いのか?(おいらの知識では、Webページまで見に行って、アップデート可能なパッケージを再度ダウンロードして実行しなければならない。これは(手間としては多少楽なものの)OS上のアプリが少なくなってWebアプリが多くなった原因の一つだと思うんだけど、現状のままでは数年前に逆戻りになると思う。これでは本格的なAIRアプリは出てこないんじゃないかな。(過去に何度も突っ込まれてると思うので)良い方法があるのかも知れないけど)
- まだ日本語処理が甘い感じ。入力ボックスにフォーカスは当たってACSIIは入力できるんだけど、マルチバイト(変換前のカナとか)は表示できず、変換も出来ない。でも、マルチバイト文字をペーストして入力することは出来るなど。(Macだけの問題なのかな? サイト上のFlashでもたまに起きるし)
- リッチUIと実現できる技術としてみると、1年前ならFlexが圧倒的にリッチだったんだけど、今ならjQueryとかExtJSとかのAjaxライブラリ使っても(多少の差はあれど)おおよそ同程度のシステムが組めるんじゃない? だったらFlashとしての縛り(Flashの埋め込みエリア外基本的に触れないなど)がある分、Ajax極めた方が応用できそうじゃない?(とちょっとだけ思っている) これによりFlexの重要度が相対的に低下し、それにつられてAIRの重要度も(おいらの中では)下がってきた。
大半愚痴だな。
AIRの感想じゃなくて、Flexの感想も混じるけど、おいら的には同じ事かな。
ちょっと古いけど、たしかにこんな感じもする。
AS3/Flex2 を使い始めて約半年 - 8時40分が超えられない - subtech
質問も用意しておこう
- Flashベースの場合、ちょっと複雑なことをしようとしたら、ブログラマは相当泣けるはず。せっかくAdobe(旧マクロメディア)純正で色々なことが出来るライブラリやサービスが出来てきたのに、プログラミング環境が悪いためプログラマ人口が増えない。だからFlexやそれを進化させたAIRが出てきたんだと思うけど、この予想は正しい?
- 今のadobeさんの考え方だと、メディアやコンテンツの制御にはFlashを使って、複雑な事をしたいならFlexを使うという棲み分けだと思うけど、この棲み分けはずっと変わらない? どちらかに統一されるということはありえる?
- Flexベースの場合、クライアント側のMVCがうまく分けれない。MXMLがviewというのは良いんだけど、controllerとmodelはどういう風に表現すべきなのかがいまいち。ツールというレベルではなく、ちゃんとある程度のアプリケーションを作ろうとした時に、特にイベントを自分で管理するのが非常に苦痛。これを回避する手助けをするのはフレームワークの役目だと思うのですが、ケアンゴームは大げさだし他のフレームワークもいまいちっぽい。主流がない。小規模〜大規模まで使えるものが見つからない。たぶんこの状況をAdobeさんは真っ先に感じて、ケアンゴームの開発者を抱き入れたと思うのですが、その後のアクションが続いていないように感じます。Adobeとしては「こういう風に書けば、もしくはこのフレームワークを使えば効率的に書ける」といったような指標はあるんでしょうか?
- SQLiteなどのクライアントサイドDBへのアクセスは、現在非同期のみサポートしているようですが、これは同期しないと制御が非常に面倒です。たとえば、複数のテーブルに整合性を持ったデータを書き込んで、トランザクションも使いたい場合など。なんとかならないでしょうか?
- AIRを勉強したい人が読むべきサイトや本は? Adobeさんの公式ドキュメントが一番って話もあるけど、ぶっちゃけ何がオススメ?
- AIR絡みの今後のリリーススケジュールで、公表してもよいものは?
- Adobeさんの考える、windowsネイティブアプリと、AIRアプリと、シルバーライトアプリの使い分けは?
AIRで作ると何が嬉しいのか?
てか、やろうと思えばAIR上で3Dグラフィックから音声合成までなんでもできるんだろうけど、技術の方向性として、どういう分野であれば使いやすいか、他の技術との使い分けとしてはどこか? という話なのかな。
自分の気持ちをぶっちゃけると、windows上だけで動けば良くて資源または表現的パフォーマンスが高い物を作りたければvisual studioで作るべきだと思うし、過去にVBなどで作っていた物をWebベースクライアントなどと絡ませるならAIRよりシルバーライトだと思うし、それ以外の分野でやっとどれで作るのがいい?という比較の土俵に上がると思っている。(MacやLinuxはすべてのエンドユーザまでリーチしないので考慮しない。この辺の人は不便なら自分で作るし)
じゃあ、AIR優勢なのはどのエリア?という話になるけど、比較的リッチな資源を持っているLinux上の業務系エリア(タッチパネルモノとか?)か、既にWeb上で動いているブラウザ(Ajax)+サーバサイド+DBの三層構造システムの、ブラウザ層をAIRに置き換えるエリアぐらいしかないんじゃないかなぁ。
AIRを使うときの大前提
Web上のサーバサイドプログラムやサーバサイドストレージをベースとして、そのフロントエンドをAIRにするような使い方じゃなければ、AIRである必要がないと思う。(特にサーバサイドサービスをHUBとしたクライアント同士のデータ同期は、他に競合技術がないぐらい優れていると思う)
たとえば、クライアントサイドで完結(クライアントアプリ同士で完結)するようなシステムの場合、AIRではなくC#.Net(とかそれぞれのOSのネイティブ)で作った方が良いと思う。
AIRを業務系(組み込み系?)で使う
最近の組み込み系はLinuxが増えてきているし、Atomなどの高性能低消費電力CPUも出てきているし、なにより要求が高度化してきているので、限られた用途ではいいんじゃないかと思う。
Linux上の組み込み系を考えると、普通コスト面から資源ミニマム+ストレージレスで組む方が多いと思うんだけど、AIRランタイムが動くようなスペックを持っているLinux系業務用マシンって限られているよね。プログラマがもうちょっと頑張ればもっとCPUとかメモリ押さえれるじゃん(もっと安価なマシンでいいじゃん)みたいな。
でも、今のタイミングならAIRも不可能じゃない。今ならSSD もあるしね。
このエリアでは新機能追加や仕様がコロコロ変わって、頻繁にアップデートが必要なもの(某笑顔動画視聴専用マシンとか?)に適しているかな。
特に表現力が高いから、ヒューマンインターフェイスとしてはいいんじゃないかと思う。
資源管理をもうちょっとまじめにやらないとダメだとは思うけど。
AIRをWebシステムのフロントエンド置き換えとして使う
Web上の既存三層構造のフロントエンドをAIRに置き換えて何が嬉しいか、という話になると思うんだけど、やはりネットワークが無くても動くところだろうね。
HTML+CSS+AjaxベースだけでAIRアプリも作れるけど、これだとネットワークありきになりがちなので、AIR版作って何が嬉しいの?って話になると思う。ブックマークとか、URLをアイコン化して置いておけばいいじゃんみたいな。
その点FlexベースのAIRアプリならFlexの中だけで色々できるので、サーバ側へのリクエストをローカルにキャッシュしておいて、ネットワークに繋がったら一気に送るような使い方ができるから、レジ&会計システムなどクライアント側で動き続けることが何より大事という場合に逝けるかも。SQLite使ってキューを作れば比較的簡単に実装できるし。
予約システムのように、クライアント側予約状況(対面または電話で予約受付)と、サーバ側予約状況(ブラウザなどでの予約受付)に整合性を確保するような用途は向かない(というか、何をしても無理)だと思うけど。
これも、業務用とか、特定サービスの差別化の一環みたいな使い方になるのかなぁ。
AIRをリアルタイムコミニュケーション向けに使う
忘れてたけど、Flashベースであれば、音声や動画絡みのリアルタイム同期アプリも面白いかもね。てか、上で述べた用途より面白そうだし、Flashベースじゃなきゃ(安価に)実現出来ない。わかりやすいのはマシェリとかああいうビデオチャット系かな。
未だ遠隔会議って実用的じゃないけど、実際に今おいらが打ち合わせに困っているように、需要が無くなった訳じゃなくて、使い勝手とコストのバランスが悪いのが原因だと思うので、ちゃんとしたUIを備えたアプリがあって、タッチパネルモノが流行ってきたときには結構使えるんじゃないかなぁと思う。
これは、音声や動画や文字情報(や一部グラフィック)を特定のユーザで共有できる技術ベースが既に(有償・無償含めて)存在するから現実的なんだけど、高機能&大雑把過ぎて、おいらの知る限りでは、ちょっと扱いに癖があるのでノウハウが必要だと思う。細かい制御が出来ないイメージ。
ビデオ会議+チャット+ファイル送信して開いてもらうぐらいならSkypeで十分なので、もっともっとリッチアプリじゃないと相手にされないとも思う。もしくは、ユーザ限定とか課金前提とか、Skypeでは想定してない使い方or細かい制御が必要な場合とか。(まぁ、今までの遠隔会議システムがドコでコケたか考えないうちは作っちゃダメ)
そいえば、FlashからUSB接続のライブカメラなどを使うとき、セキュリティ設定を変更する必要があるんだけど、Webベースではこれが障壁になってあまり使われてない感が強かった。AIRの場合この辺どうなんだろう? 緩くなったのかな?
まとめ
独断と偏見でまとめると
- クライアント&サーバ型アーキテクチャでは無い場合、他の競合技術もよく検討する。(てかこの場合AIRの優位点は少ない)
- HTML+AjaxベースでAIRアプリを作ってもあまり嬉しくない。(てか嬉しいエリアが少ない)
- FlexベースでAIRを作ると、それなりにうれしい事ができる。てか実はAIRは、Flexという技術の適用範囲を広げるために(市場ニーズから生まれたのではなく)技術主導で生まれたモノだと思う。
- AIRを使って嬉しい適用エリアは、「ブラウザ上で動いていたFlexアプリをネットワークが無くてもある程度使えるようにしたい場合」と、「windowsに対応していない機材上で頻繁にアップデートが必要な場合」と、「リアルタイムコミニュケーション系システム」の3エリアかな。
ってことになった。
北海道WEBコンFESTA2008のワークショップでは、これ以上飛躍したアイデアは出るかな?
0 件のコメント:
コメントを投稿