昨年11月29日に、FlexSDKのバージョンが4.6にアップデートされました。
http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+4.6
FlexSDKが4.xになって以降、はっきりいって使い物になりませんでしたね。
バグだらけで。
Flex3.5とか3.6のほうが、全然マシでした。
よくもまァAdobeはこんなバグだらけの状態で、FlashBuilder4！とか意気揚々と出したものだと思いましたよ。
ドロップダウンリストの値をActionScript側でまともに取得できなかったり、テキストボックスやテキストエリアにmaxCharsプロパティ（最大入力字数）を設定すると、また同じくActionScriptで全角文字を取得できなかったり…。
そーいえば、DataGridもなんかイマイチでした。
そんな状態でお客様にアプリを作って納品できるわけがない！
折角懸命にmxmlやActionScriptを学んでAdobe信奉者になってきたのに、おいこのやろォ！と思ってきましたが………。
ようやく、4.6になってようやく落ち着いてきたかな、と思います。
いやしかし、これからFlexを学ぶヒトはいるのでしょうか。
んー、デスクトップアプリをAirで作るのはアリかもですが、携帯の方面はAdobeはこれ以上バージョンアップしない！と宣言しちゃいましたしね。
WEBでリッチアプリケーションを作る代表格であったFlex、今や仕様が固まりつつあるHTML5＋JQueryに押されてます、iPhoneがFlashに対応しないがためが最大の理由でしょう。
次期WindowsであるWindows8 の MetroUI版IE10 では、バッテリーやセキュリティ確保のためとかいって、Flashは動かないようですし。
実際Flashはエネルギーを浪費するのでしょうね。
作ったアプリは、結構メモリも使ってるみたいです。
がしかし！！！
しかしですよッツ！！！
特にWEBでリッチインターネットアプリケーションを開発する際、動きのあるWEBアプリを作るとき、今後ずっとJavaScriptベースで進んでいいのでしょうか！？
これは、プログラマー視点・開発者視点・あるいは保守視点からして、断じてNo！といいたい。
HTML5、これはすばらしい技術だと思います。
デザインを体系的に形作るCSSも、旧来の技術ですが問題ないと思います。
しかしJavaScriptは、大規模アプリケーションを開発するには不向きだと思うのです。
オブジェクト指向ではないからです。
大規模な開発では、もはやオブジェクト指向でないと、メンテナンスが容易ではありません。
小規模な、ちょっとした動きをJavaScriptやJQueryで実装するのはいいと思いますが、たとえば100画面のWEBアプリケーションを体系的・構造的に作ろうとした場合、JavaScriptではいろいろな書き方ができてしまったり、オブジェクト指向的に書こうとすると長文になったりするので、後で理解しづらいモノになってしまうのです。
JQueryの場合、駆使すればメンテナンスしやすいものになるかもしれませんが、結構独特な書き方なので、後でこれらが何をやっているかが理解しにくいのではないかと思っています。
やりたいことをネットで検索してコピペしてイチから作っていくのにはいいですが、それでも長い構文になったとき、果たして理解できるものになるのか…。
そしてここで言いたい。
だから、企業システムなどエンタープライズ分野にリッチインターネットアプリケーションを投入しづらい状況になっているのではないか、と。
ようやくここで推したい、エンタープライズ分野にFlashを！
Flash画面をFlexで作るには、画面の構造をmxmlというxmlのタグ形式で記述し、動きをActionScriptで記述して、コンパイルします。
mxmlのタグの種類はhtmlと異なり、かなり種類が多く、プロパティも豊富です。
タブやツリー、ダイアログ画面など、htmlにはないコンポーネントがたくさん標準で用意されています。
htmlでもできますが、なんかCSSや画像を駆使して、それっぽく見せるのに自前でがんばって工夫しなければなりません。
mxmlの場合は部品として扱えるので、ソースを見たとき、あ、これはタブだな、これはツリーだな、と一瞬で判断つきます。
メンテナンス上、htmlと比較したこのアドバンテージは強力なはず！
そして、きちんとオブジェクト指向になっているActionScript。
やりたいことを抽象化やカプセル化を意識してできるようになっています。
勿論継承もできます。
継承がすごいと思ったのは、画面のコンポーネントの機能を継承して、別に自前のコンポーネントを作れるところです。
なんとmxmlのタグだけで、継承を利用して自前のコンポーネントが作れます。
たとえば、あるボタンをクリックしたら小画面が開くようなコンポーネントを、１セットの部品として作り、ほかの画面でもその部品を流用したい場合は、ボタンクラスを継承したクラスを作って、その中で小画面を開く処理を入れるような構造にします。
小画面の縦横の大きさや、あるいは小画面の表示内容自体をプロパティにしておけば、汎用性は広がります。
こうやって書くと実現が面倒に感じるかもしれませんが、mxmlやActionScriptは最初から継承を意識されてるので、出来上がったタグやコードは、実に理解しやすいものです。
HTML5にはあまり精通してませんが、JQueryなどと合わせても、ここまでできるのかどうか…。
mxmlとActionScriptを軸にしたFlexは、大規模なリッチインターネットアプリケーションを開発する上で、開発者・保守者にとって、言語の特性からして、最も有効な選択肢だと思っています。
だから、私はもっともっとAdobeにがんばってほしい！
もっとFlashを最適化して、性能を上げ、セキュリティに突っ込みどころがないように仕上げ、他を寄せ付けない存在にまで昇華してほしい！
「え？なにこの軽さ。こんな軽いのにこんな使いかっていいの！？」って驚かせてほしい！
言語としての土台はすばらしいのに。
方向は間違ってないよAdobe！
HTML5が出てきたから、AppleがiPhoneに対応しないからといって、あきらめなさんな。
FlexSDKの開発要員を強化して。
携帯、やればいいじゃん！捨てるなんてもったいない！
Flexでw3c標準に採用されるんだくらいな勢いで行け！Adobe！！
酒
monipet
動物病院の犬猫の見守りをサポート
病院を離れる夜間でも安心
ASSE/CORPA
センサー、IoT、ビッグデータを活用して新たな価値を創造
「できたらいいな」を「できる」に
OSGi対応 ECHONET Lite ミドルウェア
短納期HEMS開発をサポート！
GuruPlug
カードサイズ スマートサーバ
株式会社ジェイエスピー
横浜に拠点を置くソフトウェア開発・システム開発・
製品開発(monipet)、それに農業も手がけるIT企業
http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+4.6
FlexSDKが4.xになって以降、はっきりいって使い物になりませんでしたね。
バグだらけで。
Flex3.5とか3.6のほうが、全然マシでした。
よくもまァAdobeはこんなバグだらけの状態で、FlashBuilder4！とか意気揚々と出したものだと思いましたよ。
ドロップダウンリストの値をActionScript側でまともに取得できなかったり、テキストボックスやテキストエリアにmaxCharsプロパティ（最大入力字数）を設定すると、また同じくActionScriptで全角文字を取得できなかったり…。
そーいえば、DataGridもなんかイマイチでした。
そんな状態でお客様にアプリを作って納品できるわけがない！
折角懸命にmxmlやActionScriptを学んでAdobe信奉者になってきたのに、おいこのやろォ！と思ってきましたが………。
ようやく、4.6になってようやく落ち着いてきたかな、と思います。
いやしかし、これからFlexを学ぶヒトはいるのでしょうか。
んー、デスクトップアプリをAirで作るのはアリかもですが、携帯の方面はAdobeはこれ以上バージョンアップしない！と宣言しちゃいましたしね。
WEBでリッチアプリケーションを作る代表格であったFlex、今や仕様が固まりつつあるHTML5＋JQueryに押されてます、iPhoneがFlashに対応しないがためが最大の理由でしょう。
次期WindowsであるWindows8 の MetroUI版IE10 では、バッテリーやセキュリティ確保のためとかいって、Flashは動かないようですし。
実際Flashはエネルギーを浪費するのでしょうね。
作ったアプリは、結構メモリも使ってるみたいです。
がしかし！！！
しかしですよッツ！！！
特にWEBでリッチインターネットアプリケーションを開発する際、動きのあるWEBアプリを作るとき、今後ずっとJavaScriptベースで進んでいいのでしょうか！？
これは、プログラマー視点・開発者視点・あるいは保守視点からして、断じてNo！といいたい。
HTML5、これはすばらしい技術だと思います。
デザインを体系的に形作るCSSも、旧来の技術ですが問題ないと思います。
しかしJavaScriptは、大規模アプリケーションを開発するには不向きだと思うのです。
オブジェクト指向ではないからです。
大規模な開発では、もはやオブジェクト指向でないと、メンテナンスが容易ではありません。
小規模な、ちょっとした動きをJavaScriptやJQueryで実装するのはいいと思いますが、たとえば100画面のWEBアプリケーションを体系的・構造的に作ろうとした場合、JavaScriptではいろいろな書き方ができてしまったり、オブジェクト指向的に書こうとすると長文になったりするので、後で理解しづらいモノになってしまうのです。
JQueryの場合、駆使すればメンテナンスしやすいものになるかもしれませんが、結構独特な書き方なので、後でこれらが何をやっているかが理解しにくいのではないかと思っています。
やりたいことをネットで検索してコピペしてイチから作っていくのにはいいですが、それでも長い構文になったとき、果たして理解できるものになるのか…。
そしてここで言いたい。
だから、企業システムなどエンタープライズ分野にリッチインターネットアプリケーションを投入しづらい状況になっているのではないか、と。
ようやくここで推したい、エンタープライズ分野にFlashを！
Flash画面をFlexで作るには、画面の構造をmxmlというxmlのタグ形式で記述し、動きをActionScriptで記述して、コンパイルします。
mxmlのタグの種類はhtmlと異なり、かなり種類が多く、プロパティも豊富です。
タブやツリー、ダイアログ画面など、htmlにはないコンポーネントがたくさん標準で用意されています。
htmlでもできますが、なんかCSSや画像を駆使して、それっぽく見せるのに自前でがんばって工夫しなければなりません。
mxmlの場合は部品として扱えるので、ソースを見たとき、あ、これはタブだな、これはツリーだな、と一瞬で判断つきます。
メンテナンス上、htmlと比較したこのアドバンテージは強力なはず！
そして、きちんとオブジェクト指向になっているActionScript。
やりたいことを抽象化やカプセル化を意識してできるようになっています。
勿論継承もできます。
継承がすごいと思ったのは、画面のコンポーネントの機能を継承して、別に自前のコンポーネントを作れるところです。
なんとmxmlのタグだけで、継承を利用して自前のコンポーネントが作れます。
たとえば、あるボタンをクリックしたら小画面が開くようなコンポーネントを、１セットの部品として作り、ほかの画面でもその部品を流用したい場合は、ボタンクラスを継承したクラスを作って、その中で小画面を開く処理を入れるような構造にします。
小画面の縦横の大きさや、あるいは小画面の表示内容自体をプロパティにしておけば、汎用性は広がります。
こうやって書くと実現が面倒に感じるかもしれませんが、mxmlやActionScriptは最初から継承を意識されてるので、出来上がったタグやコードは、実に理解しやすいものです。
HTML5にはあまり精通してませんが、JQueryなどと合わせても、ここまでできるのかどうか…。
mxmlとActionScriptを軸にしたFlexは、大規模なリッチインターネットアプリケーションを開発する上で、開発者・保守者にとって、言語の特性からして、最も有効な選択肢だと思っています。
だから、私はもっともっとAdobeにがんばってほしい！
もっとFlashを最適化して、性能を上げ、セキュリティに突っ込みどころがないように仕上げ、他を寄せ付けない存在にまで昇華してほしい！
「え？なにこの軽さ。こんな軽いのにこんな使いかっていいの！？」って驚かせてほしい！
言語としての土台はすばらしいのに。
方向は間違ってないよAdobe！
HTML5が出てきたから、AppleがiPhoneに対応しないからといって、あきらめなさんな。
FlexSDKの開発要員を強化して。
携帯、やればいいじゃん！捨てるなんてもったいない！
Flexでw3c標準に採用されるんだくらいな勢いで行け！Adobe！！
酒
monipet
動物病院の犬猫の見守りをサポート
病院を離れる夜間でも安心
ASSE/CORPA
センサー、IoT、ビッグデータを活用して新たな価値を創造
「できたらいいな」を「できる」に
OSGi対応 ECHONET Lite ミドルウェア
短納期HEMS開発をサポート！
GuruPlug
カードサイズ スマートサーバ
株式会社ジェイエスピー
横浜に拠点を置くソフトウェア開発・システム開発・
製品開発(monipet)、それに農業も手がけるIT企業
アクセス
トータル
ランキング
