Flexアプリケーション作成でよくある10の間違い

作者 Jon Rose, 翻訳者 金森 諭 投稿日 2008年4月24日 午前12時2分

コミュニティ

Java

トピック

RIA,

リッチクライアント/デスクトップ,

Webフレームワーク,

Web 2.0

タグ

Apollo,

Flex,

Adobe,

Adobe Integrated Runtime,

Flash

この記事ではAdobeのJames Ward氏(source)がこの記事(参考記事)とは別のFlexに関するトップ10を教えてくれる。Flexはオープンソースのアプリケーション開発環境で、Flash Playerを使ったウェブのリッチインターネットアプリケーション（RIA）を作ることができ、またAdobe AIRを使えばデスクトップで動くアプリケーションも作れる。総合的に見てFlexは使いやすくパワフルなフレームワークだが、今回はFlexアプリケーションを作る時によくある間違いに注目してみよう。


Flexを初めて知る人はInfoQの最近の記事Adobe Flex Basics(参考記事)を読んでもらえばこのフレームワークについての簡潔な概要を知ることができる。さて、10の間違いを挙げよう。

1.  RIAフレームワークをWeb 1.0アプリケーションを作るのに使ってしまう（新しいテクノロジなのに以前と変わらないアプリケーションを作る）
    Web1.0アプリケーションからRIA開発への変化における一番の難題の一つは、考え方を変えることを学ぶことだ。 Flexの進んだコンポーネントライブラリは開発を容易にするが、これは数年前にはできなかったことだ。古い考え方のせいでしばしばFlexはその力を発揮できず、旧来のWeb 1.0アプリケーションを作るために使われていることもよくある。
   
   Web 2.0アプリケーションを作るというのは、ウェブページの一部を更新したり角を丸くしたりするだけではない。たとえば、ユーザが理解しやすいように情報を視覚化するのにはベクターグラフィックを使ったり、高度なコントロールコンポーネントを使うことでリッチアプリケーションの高度なアプリケーションフローを実現できたりする。Stephan Janssen氏はこの種の悩みについて最近InfoQ.comで議論している(source)。

   Javaデベロッパにとってオブジェクト指向のActionScriptとUIマークアップ言語を習得するのは全く簡単なことです。しかし（Javaの）デベロッパにとって壁となるのは、RIAテクノロジにはデベロッパのスキルだけでなくデザイナのスキルも必要とされることです。

2. ブラウザで標準となっているユーザエクスペリエンスを無視する
    Flexはユーザエクスペリエンスを向上させる優れたプラットフォームを提供するが、ユーザが慣れ親しんだバックボタンやブックマーク、オートコンプリートといったものを踏襲することもまた重要だ。
   
   Flex 3にはFlashでもバックボタンやブックマークの機能を提供できるように新しいディープリンク機能が含まれている。これについてはlabs.adobe.com(サイト・英語)に詳しい情報がある。オートコンプリートを実現するコンポーネントも多く公開されている。Adobe ExchangeからはAutoComplete Inputコンポーネント(サイト・英語)が入手できる。
   
3.  コンテナ（GUIコンポーネントを配置するオブジェクト）を多く使っているせいでアプリケーションが遅い
   Flash PlayerではHTMLのDocument Object Model（DOM)に似た階層的なディスプレイオブジェクトのグラフが使われている。コンテナが入れ子になって階層の深いところにあると描画に時間がかかるようになる。AdobeのFlex Developer CenterにはFlexのパフォーマンスに関するベストプラクティスが載っているが、そこではコンテナの使用方法についても詳しく説明されている。
   

    コンテナを無作為に使ってしまうことは、Flexのパフォーマンスを最も下げる原因になります。多くのコンテナを何重にも入れ子にするとアプリケーションのパフォーマンスを妨げてしまいます。これはFlexデベロッパが突き当たる一番のパフォーマンスの壁なのですが、幸運なことに、これは100パーセント回避可能な問題です。

4. 最適化されたプロトコルでなくXMLでデータ転送しているせいでアプリケーションが遅い
   FlexではFlexクライアントアプリケーションとサーバ間のデータ転送にAMF3やXML、SOAP、ノーマルなHTTPリクエストといったいくつかの選択肢が用意されている。Ward氏は自身のパフォーマンス調査アプリケーション(source)を使って、これらの技術とパフォーマンスのベンチマークテストを行っている。
   
   これから始める新しいプロジェクトでJavaをバックエンドに使うものがあるなら、BlazeDSを採用することを考慮すべきだ。BlazeDSはAdobeが最近オープンソース化したData Services製品(参考記事)で、AMF3プロトコルを使っている。AMFはバイナリ転送プロトコルで、Javaで扱うことが簡単にでき、XMLより大幅なパフォーマンス向上が得られる。主要なバックエンド技術に対してならオープンソースのAMF実装が揃っている。
   
   もしBlazeDSが選択肢でないなら、Hessian(参考記事・英語)が選択肢となりえるだろう。HessianのバイナリのウェブサービスプロトコルはActionScript/Flexをサポートしている。
   
5. Flex開発者を雇おうとする
   今のところ熟練したFlex開発者を見つけるのはかなり難しい。適応カーブでFlexが今位置しているのはJavaが90年代後半にいたポイントだ。 Flex開発者の需要は供給を上回っていて、このことが熟練したFlex開発者を見つけるのを難しくしている。しかしこのことはJavaの開発者にとって自分のスキルを広げ、新しく楽しめる技術に取り組む絶好の機会でもある。多くの企業はJavaで多くの経験を積んだFlex開発者や、数週間だけの Flex開発も行えるウェブアプリケーション開発者を求めている。それにウェブやGUIのプログラムに慣れている開発者にとってはFlexの言語および APIの学習はたやすいはずだ。
   
6.  アニメーションを使いすぎる
    Flash を使えばアニメーションやエフェクトを簡単に扱える。しかしアプリケーションを開発する時には、アニメーションにそれなりの意味と状況を伝える機能があるようにしないといけない。そうしなければ、ユーザはいらいらするだろう。アニメーションを行うタイミングも重要だ。インタラクションデザインをする人ならいつアニメーションをして、いつしてはいけないかをアドバイスしてくれるだろうし、最も良いアニメーションの種類や長さ、最も人を安心させるアニメーションについてもアドバイスをくれるだろう。
   
    laair.orgにアニメーションの使用に関する良い記事がある(サイト・英語)。
   

   ほとんどのアニメーションは長すぎです。長くて遅くて退屈でやりすぎです。きちんと加減してほしいものです。しかしこのような経験をする中で、馬鹿げたアニメーションが終わる待つくらいなら何か他のことをするという自分の性格を知ったのは新しい発見でした。
   
   私がアニメーションを非難していると誤解しないでください。私が非難しているのは、その目的の割りには長すぎて時間を無駄にさせるアニメーションだけです。全てのアニメーションの本質には目的があります。自分の使っているアニメーションの目的を見極め、状況に合わせて使うようにしましょう。

7. 社内の仕組みを整えない
   他のソフトウェアプロジェクト同様、自分たちのFlexアプリケーションについて社内の仕組みを整えることは重要なことだ。
   
   今日、その企業にとって重要なプロジェクトのほとんどにおいて、テストドリブン開発（TDD）は基本的なルールの一つになっている。Flexの単体テストを支援するのにはFlexUnitフレームワーク(source)がある。AdobeのDeveloper ConnectionではNeil Webb氏がFlex開発におけるTDDとFlexUnitの利用について議論をしている(source)。さらにコードカバレッジレポートについてはFlexcover(source)が利用可能だ。
   
   複数の開発者が参加して複数のアプリケーションを作ることに関しては、継続的インテグレーション (CI、変更を検知してビルドなどを自動的に行う)(source)が実績のあるプラクティスだ。Javaアプリケーションと同じように、Flexアプリケーションに対するCI用のAntおよびMavenのプラグインが利用可能だ。
   
8. フレームワーク全体を利用していない
   Flexにはアプリケーションで利用することを考えるべき多くの機能が選択肢として用意されている。例えば、アプリケーションサイズを小さくするのに役立つRuntime Shared Libraries（RSL(source)がある。
   

   共有で使われるファイルなどをアプリケーションの実体であるSWFファイルとは別のファイルにすることで、アプリケーションのサイズを小さくできます。これらの共有ファイルはクライアント側で別々にダウンロードしてキャッシュされますが、一つのクライアント上にある複数のFlexアプリケーションが同じ共有ファイルを使う場合には、そのアプリケーションのいずれかで1回だけダウンロードすれば、他のアプリケーションでも利用できます。このような共有ファイルをRuntime Shared Librariesと呼んでいます。
   

   フレームワークの機能であまり使われてないものにはアクセシビリティのビルドイン機能がある。Adobeのlivedocs(source)にアクセシビリティ機能について詳しい情報が載っている。アクセシビリティのビルドイン以外に、このフレームワークはローカリゼーションの機能(source)も提供している。最新のFlex 3フレームワークの機能については、AdobeのGetting Started(source)をチェックしてみるといい。

9. DataGridで複雑なrenderを使っているせいで遅い
   Flex のDataGridで使うitemRendererはそのまま使うには良く最適化された作りになっている。3番目の間違いで、何重にも入れ子になったコンテナによるパフォーマンスへの影響を述べたが、DataGridのitemRendererはFlexでコンテナが入れ子になりやすい箇所だ。 DataGridで描画されるアイテムの数は表示されている行数と列数を掛けた数になる。そのためカスタマイズしたDataGridやListでも itemRenderは高いレベルで最適化されていないといけない。アイテムの描画に複雑なロジックが必要な時は、UIComponent（あるいはもっと低レベルのクラス）を使い、目的のセルにそれをマニュアルで配置するのが一番良い方法だ。
   
10. オフラインアプリケーションとして動作させることを考えていない
    これまでのRIAのモデルというのはブラウザ内での動作を想定していた。しかしAdobe AIR(source)やGoogle Gears(source)のようなテクノロジを使うとアプリケーションをオフラインで実行できるようになる。ユーザがオフラインでの使用を望んだ時のためにオフライン向けアーキテクチャも考えておかないと、オフラインの機能が使えるようにアプリケーションを変更するのはかなり難しいことになってしまう。特にウェブアプリケーションではビジネスロジックがサーバ側にあるのを、オフラインのRIAではクライアント側に持ってくる必要がある。そのため、アプリケーションがオフラインとオンラインの両方で動かせるように、予めビジネスロジックをどのように配置するアーキテクチャがいいかを考えて設計する必要がある。

Flexについてより知りたい人は、InfoQに掲載されている他の記事(参考記事リンク)も読んでほしい。

• 次へ >