「パッケージソフトウェア開発」5日目です。
近頃、パッケージソフトウェアのクライアントアプリ開発でJavaFXに触ってみたので、記事を書いてみることにしました。
Java AppletやSwing、Flexなどをちょこちょこやってきた私ですが、JavaFXで画面作って改めて思ったことを書きます。
ここ数日はアプレッソ開発部の方々が投稿されておりましたが、私は一般参加(?)ということでゆるい感じで。
JavaFXについてはJavaFX Advent Calendarにそうそうたるメンバーがエントリーされているので、そちらを。
####JavaFXで最初に気になったこと。
実際に少し画面を作ってみて早速いくつか気になりはじめました。
- FXML
FlexでMXML、SilverlightでXAML、で、こんどはFXMLかよ...
XMLはマシンが読むものであって人間の私には無理です。
またXMLで画面作るのかと、いきなりやる気をそがれました。
- FXML+CSS
FlexでMXML+CSS、SilverlightでXAML+CSS、で、こんどはFXML+CSSかよ...
またXMLタグの属性での指定と、CSSでの指定とあるのを微妙に使い分けてレイアウト調整するのかと、Flexを使ってた時の思い出が蘇りました。
あと、やっぱりCSSプロパティにいちいち”-fx-”が付く。こんな感じです→“-fx-background-color”
いやもう、普通に“background-color”と書かせて頂きたい。
- ダイアログが無い
ちょっ？えっ？無いの！?
何で無いのかは分かりませんが、ちょっとしたエラーダイアログでも自作しなければならなかったです。
他にもいろいろありますが、まずはこの辺りが気になったところです。
特に3つ目のダイアログが無いのは、GUIライブラリとしてまだ不完全なのでは？といふ不安に駆られました。
####JavaFXをしばらくやってみて。
JavaFXについては、いろいろな場でちょいちょいチラ見してはいましたが、実際やってみると基本的なところが気になってしまいました。
ただ、少しやってくうちにすぐ慣れてくるもんです。
- FXML
XMLをエディタで書くとかもう無理と思っていましたが、[Scene Builder]
(http://www.oracle.com/technetwork/java/javase/downloads/javafxscenebuilder-info-2157684.html) がいい感じだったので、生のFXMLを編集することは今のとこあまり無いです。
Flex Builder 使ってFlexの画面作ってた時はビジュアルエディタでやれることに限界があって、MXMLを直接編集したりすることが多々ありました。
Scene Builderもそんなもんだろうと思ってましたが、結構ひゅいひゅいっと画面作ってすぐにプレビューできて快適です。VBで画面を作ってた若かりし頃をちょっと思い出しました。
ただ、ボタンなどの部品を拡張しだすと話は変わってくるのかも知れません。
- FXML+CSS
これはまぁ、仕方がないことだとは重々承知してるんですが。。。
HTMLのCSSとほぼ同じにならないかなーと夢見ています。
例えば、ブラウザアプリとクライアントアプリを作る場合に、同じ製品なのでCSSでボタンなどのスタイルを共通にしたい場面とかあるなーと思います。
何か良い方法がないものか... |дﾟ)ﾁﾗｯ
- ダイアログが無い
Scene Builderで画面作るのに慣れて、ダイアログの基底クラスみたいのを作ってしまえば、特にストレスにはならないのですが、「ダイアログが無いGUIライブラリってどーなのよ」という、ちょっと上から目線の疑いの気持ちは確かにありました。
そんなことを内外でブツブツ発してしたら、著名な方々からいろいろ教えてもらいました。
ControlsFX ってのが良さげということや、8u40でダイアログが標準追加されること、この前の11月25日のJavaFX Nightでちょうどそのネタがあるよ、などなど。世の中優しい人多いす♪
####パッケージソフトウェアのクライアントとしてJavaFXを採用すべきか
さて、8u40でダイアログが標準追加されるなら、GUIライブラリとして概ね必要なものはそろったかなと思ってきました。Scene Builderで画面作るのにも慣れてきました。
JavaFXいいなー、快適に画面作れるぢゃん♪ やはりJavaFXを使うべきです。
といふ気持ちになってきました。(スレッドまわりについてなど、もうちょっとちゃんと自分で理解する必要ありそうですが...)
とは言うものの、パッケージソフトウェアに採用する技術であるので、世に出す以上はすぐには廃れないとふ条件をいくつか並べて、JavaFXを使っていくと決めた自分を正当化したいところです。
そこで、ちょっとそれっぽい理由を挙げてみます。
- Java7は2015年4月でパブリックアップデートを終了する。
Java6は2013年2月にパブリックアップデートを終了していますし、Java7についても来年、2015年4月でパブリックアップデートを終了します。
そして、Java8からはJavaFXがSwingの後継APIとして正式にGUIライブラリとなっています。
Java8をダウンロードした人の環境ではもれなくJavaFXが動きます。
これは将来性という視点でかなりの有望なのでは！な感があります。
- AIRやSilverlightは後退した。
RIA(Rich Internet Application)といふ言葉を聞かなくなりました。
ブラウザのUIはHTML+CSS+JavaScriptでの開発が主流になりました。
RIAのクライアントアプリ分野についても、2010年にSteve JobsがFlashをあれであれしたことでAIRも後退していったように思います。MSもその翌年に公開したSilverlight5が最後ぽい感じです。
AIR、Silverlight共に将来性については期待薄な状況と言って良いのではないでしょうか。
- サーバ側の実装がJavaだったら、クライアントもJavaで作りたい。
（サーバ側の実装がJavaであること前提になりますが）クライアントもJavaで作れるってやっぱり有益です。開発チームの学習コストがぐんと下がります。
- Javaだからと言ってSwingはもう嫌だ。
嫌です。
いや普通にネイティブで作ればいいぢゃん、などのツッコミはあると思いますが…
ポインタの使用などの危険な行為はお医者さんから止められているので、ここではあえて触れません。
####まとめ
情勢を鑑みるに、これから開発するパッケージソフトウェアであれば、ブラウザアプリは別として、クライアントアプリ開発にJavaFXを使うことは今は良い選択かと思います。また、Java8からは正式GUIライブラリとなっているので、すでにSwingで書かれたものをリファインするのもそろそろ検討して良いかと思います。
ただし、フロントエンドの技術についてはそのアーキテクチャごとごっそり入れ替わるというサイクルが、バックエンドに比べて非常に早いんぢゃないかなーと感じます。それはここ数年のフロントエンド技術のトレンドが目まぐるしく変化していることからも伺えます。UIデザインについてもスキューモーフィズム(skeuomorphism)中心のデザインからあっという間にフラットが主流となってしまいました。
こうなるともうリファクタリングでは追いつかず、今あるソースコードを捨てて、新たなアーキテクチャの上で動くものを最初から作ったほうが早いんぢゃないか？的なタイミングもそんなに遠くないところでやって来るかも知れません。（Flex⇒HTML5みたいな）
ということは今書いているJavaFXのソースコードだって数年後には捨てるタイミングが来るかも知れません。
あぁ、なんか悲しい。急に悲しくなってきました。
でも、別途実行環境のインストールが必要とか、UIが古くてOSのUI上で何か浮いた存在とかを、”もう作り直せないから”という理由で続けていくほうが悲しいですね。
やはり、そのタイミングが来たら捨てるべきだと思います。捨てましょう。
でもその時にソースコードとしては捨てられるけど、ナレッジとして次に活かせるソースコードであるかどうかは、すごく重要だと思います。インターフェースをシンプルに保っているとか、きちんとしたソースコードを書くことに注力していたかなどが影響するんだと思います。バージョンアップを重ねてずっと開発を継続していくパッケージソフトウェアならなおのこと、この点は重要だと思います。
しばらくはJavaFX。でも、優れたUIをユーザに提供し続けるために別の選択をする日が来るかもしれない。そのことを頭に置きつつ、目の前のことをちゃんと勉強してきちんとしたソースコード書かなきゃだなーと思いました。