2009年3月アーカイブ

 whonyは「Wassr用のP3が欲しい!」という動機で開発を始めたけれど、実装がAdobe Flex+Adobe AIRなのには理由がある。

 その理由は、

  • Adobe Flexによる本格的なWebアプリケーションの実践
  • Adobe AIRの実力の計測
  • Adobe FlexでFlashと反対の方向性の簡素なGUIの実装実験
 以上の3点。

 そして分かった事は、

  • Adobe FlexもAdobe AIRもまだまだ発展途上(コンパイラの最適化がいまひとつだったりバグがあったり)
  • ActionScript3のイベントモデルはメモリリークを起こしやすい(removeEventListener()の呼び忘れ)
  • Adobe Flexのコントロールコンポーネントは拡張し辛い(内部が密結合すぎる)
  • Adobe AIRはマルチプラットフォームは信用してはいけない(MacOSだけ、Linuxだけの不具合があったりする)
  • Adobe FlexはあくまでFlashの延長であり、簡素なGUIを実装しようとすると逆に手間がかかる
  • Flex BuilderによるAdobe AIRアプリケーションの作成は非常に簡単
 以上の6点。

 つまり、P3のようなJavaで作られたソフトウェアの真似は致命的に向いていないという事。

 そして、Adobe Flex+Adobe AIRで作るのであれば気に留めておくべき事は、

  • 速度に拘るのであれば他を当たるべき。 どうしてもAdobe Flexでやりたいなら最適化は自前でやる必要がある (http://actionscript.g.hatena.ne.jp/ConquestArrow/20070621/1182359767)
  • addEventListener()は使わないで済むようレームワークを実装すべき。 もしくはそうめんを使う(http://www.libspark.org/htdocs/as3/thread-files/document/)
  • コントロールを拡張したい場合、低機能であれば自前で別コンポーネントを作るべき。 あくまで継承したいのであれば、MXMLではなくActionScriptで作りcommitProperties()とupdateDisplayList()とmeasure()を適切にoverrideする
  • プラットフォームに依存する不具合は、自前で実装するかライブラリを使う
  • 簡素なコントロールを使いたいなら自前で実装。 もしくはせっかくのFlashなのだから表現力を活かすべき
 以上の5点。 要するに、

「あくまで発展途上という事を意識すべき」

 と、いうこと。

 Adobe Flexはオープンソース化され開発が加速しているが、バグの元締めである肝心のFlash Player APIライブラリがクローズドソースなので不具合の解消は鈍足。 いいかげん公開してほしい。
 ただ、不具合の多くは実装で回避できたり別に拘らなくても良いような些細なものだったりするので、臨機応変に対処できるならば何とかなる。

 Flash特有の表現力を用いてWebアプリケーションを作りたいのであれば、決して悪い選択では無いと思われる。


 以上、次回はコントロールの拡張におけるTips。

このアーカイブについて

このページには、2009年3月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2009年1月です。

次のアーカイブは2010年12月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。