All right so we're at the stage now where
we've created our first project, we've
configured it to work with either JDK
we've or JDK 11 so let's start talking more
about JavaFX.
So JavaFX was designed with the MVC
or Model-View-Controller pattern in mind.
In a nutshell this pattern keeps the code
that handles an application's data
separate from the UI code. Because of
this, when we're using the MVC pattern,
we shouldn't mix the code that deals
with the UI and the code that
manipulates the application data in the
same class. The controller is sort of
a middleman between the UI and the data.
Now when working with Java effects the
model corresponds to the application's
data model, the view is the FXML and the
controller is the code that determines
what happens when the user interacts
with the UI. Essentially the controller
handles events which we'll cover in a
later video. Now that's a bit of a
simplification of the MVC pattern but
it's enough for us to understand why
IntelliJ generates a controller dot Java
file for us. If I open up the project,
you can see we've got a controller, a Main
sample dot FXML as well. I'm gonna close
down the module-info.java because we
won't be needing that anymore and just a
note to keep in mind that Java effects
doesn't actually enforce the MVC pattern
but it is a good practice to follow.
So for this simple hello world
application that we are going to generate
there isn't any data. Also the code generated
by IntelliJ doesn't create any Java
effects UI controls apart from the usual
Windows controls, the minimize, maximize
and close there's nothing to interact
with and so therefore if we have a look
at the control of a Java file
it's actually empty. But going back to the
main dot Java file the structure should
look familiar because it's still a Java
class just like any other. Firstly they
were on line 9. We can see that the class
extends application. An application
actually comes from javafx dot
application. JavaFX applications must
have a class that extends this
application class and this class will be
the entry point for the application. The
application class manages the
lifecycle of a JavaFX application.
The methods in the application class that
we really care most about are the init
method,
the start method and the stop method. When
we run the application, application dot
launch will be called from the main
method. This method launches the JavaFX
application and doesn't return until the
application has exited. When a Java
FX application is launched the
init method runs first. In the application
class, this method is empty so unless we
override it, it won't do anything. The
start method runs right after the init
method. We have to override this class
because start is an abstract method
in the application class. We create the UI
in the start method as you'll see in a
moment.
Now when the application finishes which
usually happens because the users closed
the applications main window, the stop
method runs just like the init
method. This method is empty in the application
class so unless we override it, it won't
do anything. So to start off though let's
start looking at this start method that
IntelliJ generated starting on line 12.
This method takes a stage parameter as
you can see. So a stage is a top-level
JavaFX container that extends
the window class so essentially it's a main
window . The JavaFX runtime constructs
the initial stage and passes it into the
start method. We can't create other
stages but most applications will only
have one top-level window. Too many
windows can lead to a bad user
experience. In this version of Java
FX, dialogues are presented within a
stage but we don't explicitly create the
stage. We use the dialog class which
wraps the dialogue into a stage forest.
The Java FX developers have said
that in a future version of Java FX
they may provide a lightweight container
for dialogues rather than using a stage.
So note that the dialog class was
introduced in Java version 8u40.
Before then, creating dialogues was a
real pain.
So we'll probably use the dialog class
at some point but if anyone's got a
problem compiling classes that reference
dialogue most likely it'll be because
they're using a JDK version earlier
than supported, the dialog class
which was again, version 8. But in this case
if you're using JDK 11 you really shouldn't
have any problems. Alright so that's
the first law, talking about the method
signature, the parameter
state, the next line of code line 13 that
loads the UI from the FXML file. So it's
probably a good opportunity now to have
a look at this FXML file and this
is the sample dot FXML file. So FXML
is a flavor of XML. If you're familiar with
the AirDraw UI programming, FXML
will be old hat to you. But in this
particular application this default one,
all we have is a grid pane which is one
of the JavaFX layouts. The FX colon
controller attribute tells the runtime
which class is the controller for this
window. You can see there, there's package
name and dot class name so sample being
the package name controller being our
controller class. The GridPane doesn't
have any child elements and so when we
run the application as you saw it in a
previous video, the window's going to be
empty and it's empty here now.
Now depending on your version of the
JDK, you'll find that there's probably a few
leftover imports that aren't used .
For some reason, they're generated with those
unnecessary imports. Right now we only
need the GridPane import but later
on we'll be using a label as well
but I'll leave them there for now but you
could actually delete them if you wanted
to. So going back to Main dot Java, when we
load the ethics of a file which we do on
line 13 all of the UI objects defined in
the file are constructed so we'll come
back to the parent root part of the code
in a moment but moving on to line 14,
we set the title of the stage. Since the
window class is the parent of the stage
class and as we learned previously the
stage is the top-level Java FX
container this essentially means
that the window title will be set to in this
case "Hello World".
In line 15, we're setting the stage as
Scene. If you haven't already guessed, the
Java FX developers we're going for a
theater metaphor. Each stage requires a
scene and backing each scene is a scene
graph a tree which each node corresponds
to a UI control or an area of the scene,
for example a rectangle. So let's take
a look at this line, line 15 in more detail.
When we load at the FXML we assign it
to a variable of type parent
with the name root. The parent class
descends directly from the node class
which is in taking this from the Java
dot the base class for scene graph nodes.
Nodes that descend from parent can
have children in the scene graph. Now for the
Hello World application, the top level
and in fact only node is the GridPane.
So the GridPane node will be the root
of the scene graph and that's what was
returned from the FXMLLoader dot
load call on line 13. When we construct
the scene we have to pass in the root of
the scene graph that will back the scene
which we do here. We're also setting
the width and height of the scene which in
turn will become the width and height
of the main window. So why do we have to
have a scene at a stage? Well let's go
back to the theater metaphor and imagine
that you're watching a play. The curtain
rises and we watched the first scene
then the curtain falls
stagehands run around and change the
furniture and backdrop and then the
curtain rises again. We may see
a different looking set of different
actors but it's still the same stage.
So if you go back to JavaFX remember
that a stage corresponds to a top level
UI container like a window and a
scene is backed by a scene graph
which contains the UI nodes. If you want to
change what's shown in a stage,
the window all we have to do is change the
scene, the UI. We don't have to construct
a new stage object. In practice we would
load a different FXML file into a
new scene and then call stage dot set scene.
For example if we had a wizard so we
want the user to step through using next
and previous buttons, we could use the
same window stage and just change the
scene everytime they clicked next
or previous or when we wanted to change
parts of the UI in response to a user
action we don't have to remove UI
components or make them invisible
and add new ones, we just switch the scene.
Sometimes it makes more sense to just hide
a few controls or something like that
but other times switching the entire
scene is the better option. It will
depend on what you want to do.
Essentially those scenes make it easy
to reuse a container. Alright so back to our
Main Java class, at this point we've
instantiated all the UI objects
associated with our scene and we've set
the stage so we're ready now to show the
UI and we do this by calling the show
method on our stage and we're doing that
on line 16. From the code of the FXML
file we know that when we run the
application we should see an empty
window with a title Hello World. So we'll
just run the application again and
confirm that. No surprises, empty window
and we can see Hello World is the title
on the top of the window. So as you can
see the stage cast provides all the
window decorations such as close,
resize and the minimize button. All right
so that's a bit of an overview of how
Java FX works. Let's finish the video
here and in the next one we're going to
start making some modifications to our
application. We're going to change the
title and look at how to code some of
this stuff manually as opposed to
getting it done automatically for us. So
we'll see you in the next video.