Java FX 8 (3D表示基礎とサブ画面と画面遷移改良)

最近始めたJava FX 8の練習ですが、
今回は、前回の「画面遷移」及び「テキストエフェクト」の練習コードを発展させた形にしようと思います。
前回はこちら→Java FX 8 (画面遷移とテキストエフェクト)
また、同じ画面では芸が無いので・・・
「3D表示」
こちらも同時に行っていきます。
画面遷移については、下図の状態遷移図を参照ください。とはいえ、前回と変わっておらず、画面1→画面2→画面3→画面1(へ戻る)となっています。
2014-06-08_Practice04_StateChartDiagram


ファイル構成


(PracticeFxMain.javaはこちらを参照下さい)

まずは、ApplicationRoot.javaから。”結論から言う”という事に近いですが、前回とは比べるまでもなく、「各画面の定義、処理が消えた」部分に目が行きやすいのではと。

次は、「各画面を定義する為の抽象クラス」を作成します。
共通で使えるメソッド、どの画面クラスのインスタンスを生成するかを気にしなくてすむメソッド等を用意しています。クラスの関係図は後述のクラス図をご参照ください。

上記Componentクラスを継承して作成した画面定義クラス群です。

最後の第3画面では、「画面分割」及び「3D表示」を行ってみました。
基本的に、グラフィック系(2D, 3D)では、Sceneインスタンス上でないと表示が不可です。
そこで、注目すべきは「SubSceneクラス」が使われている部分。
AnchorPaneへNodeとして3D部のSubSceneインスタンス、UI部のGroupインスタンスを登録する形で実現しています。


実行結果
・第1画面
2014-06-08_Practice04_result1
・第2画面
2014-06-08_Practice04_result2
・第3画面
2014-06-08_Practice04_result3


今回のクラス図。
2014-06-08_Practice04_ClassDiagram
ここでのポイントは画面遷移のさせ方と、3D表示だ。
画面遷移の改良点としては、各画面の内容が各々のクラス内に収まっている事画面遷移情報をApplicationの本体で定義できるが、「クラスの中身を気にする必要が無い」事
3D表示については、実行結果を見ての通り、球(表面の鏡面加工設定済み)と各種光源を当てている、簡単な表示をさせています。
座標の表記に注意してください。
APIドキュメントはこちらから → Java FX javadoc

Java FX 8 (画面遷移とテキストエフェクト)

最近始めたJava FX 8の練習です。
今回は「画面遷移」と「テキストエフェクト」をやってみます。
前回同様、FXML、CSSといったリソースを使わず、ロジックのみで実現します。
なので、Eclipseで実行しようとする場合、Java SE 8 とXtextが適用されていれば、通常のJavaプロジェクトで動作します。


ファイル構成

  • consol/PracticeFxMain.java
  • gui/ApplicationRoot.java


実行結果は下記の通り。

1枚目の画面

1枚目の画面


2枚目の画面

2枚目の画面


3枚目の画面

3枚目の画面


プログラムコードを見ての通り、この状態では、各部品はもとより、「画面毎」のプログラムの結合度が非常に強いです。
Swingであれば、Abstractクラスを各部品を用意する事で、イベントリスナーの処理を部品ごとのクラス内に収める事が可能でした。
参考にどうぞ→Java GUI プログラミング Tips

FXMLリソースを使用すると、各イベントハンドラのリンク、部品やSceneのリンクが用意に記述可能なため、
手っ取り早く整理されたプログラムにするには、FXMLを使用するのが近道だと思われる。

次の課題は、各部品のイベント処理と継承関係の整理に取り組みたいと思う。

Java GUI プログラミング Tips

備忘録兼ねて。

Javaの参考書やサンプルプログラミングは、
幾手数多出ており、一通りの事を実現するには十分と言える。

しかし・・・Javaはかねてより
”GUIプログラミングが苦手”
と言われてきている。
そのためか、サンプルプログラムを見ると、
Frame周り含めて、ごちゃごちゃとしたソースである事が多い。

絶対それじゃないと出来ないなんて事無いぞ!

というわけで、
もうちょっと「部品ごとにプログラムを纏める」事、「分離する」事について、
サンプル交えて紹介したいと思う。

ポイントは下記の3つだ。

  1. なんちゃらListenerをimplementsしたクラスなら、ぶっちゃけ何でも良し
  2. 部品のオブジェクトは、直接使わず、継承する(簡易的な使い方なら無視でもOK。JOptionPaneとか特に)
  3. 「似た動き」をするオブジェクトは基底クラスを用意する

ファイル数は増えるかもしれないが、
1ファイル毎のコード量が激減するため、見通しも良くなる。
オブジェクト指向ならではの動きを利用するといった形だ。
Visual StudioのMFC等で自動出力されるテンプレートとも似た形である。

では、実際に上記のポイントを押さえて「分離」をしてみよう。
本来であれば、クラス図も併用して示すべきではあるが・・・
冒頭で示したJavaSampクラスから、3クラス作成し、
合計で4クラスとなった。見易さが向上したと感じてもらえればありがたい。
(折りたたんでます。下記クリックで展開します)

  1. JavaSamp.java:フレーム部分、メインメソッド
  2. AButton.java:ボタン部品の基底クラス
  3. Button1.java:ボタン1クラス(extends AButton)
  4. Button2.java:ボタン2クラス(extends AButton)

何にせよ、
フレーム部分のプログラムコードからListenerやイベント処理が消えたのが
お分かりいただけるだろうか?
部品である、ボタンの処理はボタンに・・・
という形でGUIのオブジェクト内で纏める事が出来た。

実をいうと、フレーム部分も
「部品の定義」と「デザイン(配置)の定義」を継承なりなんなりで分離が可能だ。
是非とも一考して挑戦してみて欲しい。