ホーム >> 左脳Script >> 徒然 >> 今更 Flex 始めてみる?!

今更 Flex 始めてみる?!


Adobe AIR を始め、アプリを作るなら、Action Script 3 だけでは効率が悪いと感じてきた。

flex_Demo.PNG Flex を使えば、U/I コントロールを自作する必要が無いからだ。Flash を始めた頃に Action Script 3 だけで頑張った事も、もう昔の話、といっていいのだろうか?

いやいや、自力でコントロールを作るのも無駄ではない。スキンを指定するだけでは実現できないデザイン案だって、必ず存在するのだ。

と、考えつつも、Flex の手軽さはなかなかの物でもある。

アプリケーション デザイン?!

AIRアプリケーション開発の入門記事を読むと、そのチュートリアルで大抵が Flex 、又は、「HTML + JavaScript」を使った簡単な方法でプロジェクトを作る事から始めている。

たったコレだけのコードでハローワールドの文字が表示できました」と言わんばかりに。

「いや、実際そうなのだが。」などと思った人は、古いプログラミング環境の常識に囚われているのかもしれない。
と、思ったので、自分の記憶を辿りつつ書き連ねてみた。


ハローワールド

ただ「こんにちわこんにちわ!僕~」と表示させる為には、まずウィンドウを適切な大きさで作成しなければならない。GUI環境でのアプリケーションは、その「どんなアプリケーションでも必ず?通らなければいけないお約束の部分」が、余りに大きすぎるのだ。

Windows のアプリケーションを、Win32API だけで作った事があるような人は判るかもしれない。文字表示どころか、何もしないウィンドウを造るだけで、数キロのコードを書かなければならなかったからだ。

コレを知らない人は、よく売り文句とされている「たったコレだけのコードで~」の文句がどれだけ素晴らしい事と言っているのか判らないのではないだろうか。


手動デザイン

今でこそ、開発アプリケーションには、アプリケーションのウィンドウデザイン機能が付いている。

しかし、10年も遡るとそれも珍しく、作成者はコードで全てを制御しなければならなかった。
当時は、ダイアログのようにウィンドウサイズを変更できない事が多く、多様なコントロールが載ったウィンドウデザインは稀だった。作るのが大変だったからである。
なにしろ、決め打ちでコントロールを配置するものだから、「OSシステムのフォントを変更し文字のサイズが変わる」ような場合、アプリケーションの画面はとんでもない?事になってしまう事しばしば。
ウィンドウサイズが固定なのもあって、「文字がコントロールをはみ出して読めない押せない」などは序の口、最悪は「キャンセルボタン」等の作業進行ボタンが画面に表示されず、実行や中断すら出来ない状態になるアプリもあった(※1)のだ。

MSDN の開発指針に「コントロールのサイズには余裕を持て」だかそんな感じの文章があったような気もするが、一体どれほどの開発者がそれに従っていたのだろうか。


自動整列機能

それでもこの当時、アプリケーション画面のデザインツールは存在した。
が、配置は決め打ちで、今のような「ウィンドウサイズに追従する自動整列機能」はとてもじゃないが存在しなかった。

デザインツールも最初に出たときは画期的であったが、そのうち「ボタンとボタンの端を綺麗にそろえて」とか「このコントロールはウィンドウサイズに追従して大きさを変えられるように」とか、だんだん要求がアプリケーションの本機能を外れ(※2)細かくなった。

そのような、アプリ固有の機能によらない「どんなアプリでも同じような要求をされるような事」だったからだろうか、「コントロールの自動整列機能」が開発ソフトやライブラリに含まれるようになってきた。当初は開発ツールが工期短縮の目玉機能として謳っている物が多かったが、そのうちどのソフトにも搭載されるようになって、これを前面に押し出す事もなくなった。

最初は、配置や調整がグリッド単位で出来る程度であったが、近くの「コントロールに端を合わせる」とか、関連の深いコントロールを集めてグルーピングをしたり。
そのうち、ウィンドウサイズに追従してコントロールを移動するようになり、グルーピングの概念はコンテナとかパネルとか言葉を変え、上下左右にアンカーを指定できるようになったり。

U/I デザイナーツールも、この10年で、随分と進化?したと思う。


AIR の「HTML + JsvaScript 」による開発

自動整列機能を含め「どんなアプリでも普通に作ると同じになる U/I のきまり事にあたる部分」の作成作業が便利になる一方、人の横着神経は留まるところを知らず(笑)、どんどん「楽に楽に、とにかく楽な方法へ」と進化し続けてきている。

そういう意味で、HTML のアイテム(コントロール以外にも、画像などを、コンテンツとなりうるパーツ全て)自動整列機能は、魅力的な機能だったのではないだろうか。
元々は、どんなウィンドウの大きさでも、それなりの配置でそれなりの見てくれになるように作られた機能だったが、この機能がアプリ作成に取り入れられるようになってきたのだ。

そして、その最たる例が「HTML + JavaScript だけでアプリケーションが作成できる」AIR というわけだ。


細かな設定もやろうとすれば出来るだろうが、作成者が(デザインするに当って)これだけタッチする箇所が少ないものは、今までそれほど無かった気がする。(※3)

ウィンドウフォームデザインに関して言えば、これが今後の主流になるのではないかとさえ思えてくる。本当に面倒だった頃を知らない若い?技術者には「昔はこうだった...」と説教したくなる(※4)ほどだ。

ソレくらい楽なのだ。いや、楽になったのだ。昔と比べて。


楽になった分どうしているのか?

ツールの進化、マシン性能の向上、で生産性は大幅に上がっている。ハズなのだが、当然、やっている作業が昔のままな訳はなく。環境の進化ほど、ビジネスの速度は上がっていないというか、よくある文明のハッテン度合いの Log曲線 を見ている(成長の加速度の加速度はマイナス)ような今。

最近の、雨後の竹の子状態にも落ち着きが見え始めた?Webサービスやら、アジャイルやらの影響で、簡単に物を作れる事が持て囃されている。が、生産性や即時性が向上しても、成長Log曲線の上へ出ることはなく、「上への広がり」より「横への広がり」を始める時代に差し掛かっているのではないだろうか?

個人的には、そろそろ、唯一無二より多様性が見直されるんじゃないか(※5)と密かに期待している。

それでも、時代に乗り遅れないよう、AIRアプリケーション開発をメモしていこうと思う今日この頃。




最後、話を広げすぎた。収集が付かなくなった。ちょっと反省している。


細部解説

  1. 大抵は開発言語圏が違うものを無理やり起動させた時の現象だったが、システムフォント変更下の環境では、その限りではなかった。
  2. 同じようなアプリケーションの乱立時代だった?!。結局、使い勝手で勝負する時代だったようにも思う。
    そんな時代だったからか、上司や顧客の「重箱の隅にもならないような箇所」を突かれ、対応を迫られた者も多いのではないだろうか。 これが、昨今のソフトウェア作業者の弁解能力を飛躍的に押し上げるようになった根本的な理由なのではないかとも思えてくる。
  3. 正直、この時期は、開発ツールをとっかえひっかえ検証するような事を一切していなかったので、記憶があやふやだったりする。
  4. こんな文章を書いている自分に、改めてオッサンになったなぁと言う実感をしていたりする。 実際、大した経験も無いが時間を経て自分の見て来た物を、 文章に纏めるだけでも感慨深くなってしまうのはどういうことなのか?!
  5. 資本主義より民主主義。アメリカ風よりイギリス風。・・・なにか違う?



トラックバック(0)

トラックバックURL: http://n-yagi.0r2.net/sanoupulurun/mt-tb.cgi/236

コメントする

ホーム >> 左脳Script >> 徒然 >> 今更 Flex 始めてみる?!

アーカイブ

このブログ記事について

このページは、n-yagiが2009年11月19日 11:43に書いたブログ記事です。

ひとつ前のブログ記事は「AIR 始めました。」です。

次のブログ記事は「Flex カスタムコンポーネントを AS3 で作るには」です。

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

Creative Commons License
このブログはクリエイティブ・コモンズでライセンスされています。