海色日報でタグ「adobe flex」が付けられているもの

クリップボード01.jpgクリップボード02.jpg

 なけなしの収入をはたいてXperia arcを購入したので、さっそくAdobe AIR for Androidで作ってみました。
作った物は「音声を指定位置から再生する機能」が付与されているだけのごく単純なアラームアプリ。

 分かった事は、

  • 単純なアプリケーションであれば、少なくともXperia arc上での実行速度は問題ない
  • PC向けのAdobe AIRアプリケーションのコードぼそのままで問題なく動く
  • UIライブラリ「MadComponents」を試してみたが、意外と使い易い

 正直、かなりの好感触。

 実行速度については充分な検証が必要だけれども、ActionScriptは物理演算ライブラリが充実しているので、Adobe AIRで作る事で少なくともPCとAndroid端末間でのソーシャルアプリの移植が容易になりそう。

 これでAdobe AIR for iOSが期待通りの物であるならさらにAndroid端末とiPhone間でのソーシャルアプリの移植が楽になり、事実上ソーシャルアプリのマルチプラットフォーム化が可能に。 これからに是非期待したい。
 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。