UCSB CS 10 Lecture-Module #05: Elements of GUI Applets, |final|

CS 10 Lecture-Module #05:
Elements of GUI Applets, |final|

what does "GUI" mean?

pattern of GUI applet:

import ...


public class applet_name extends JApplet
             {

    declarations of variables to store what user types (in JTextFields)
        
        

    declarations of  JLabels & JTextFields
        
        

    public void init() {
        // prepare for GUI elements:
        Container container = getContentPane();
        container.setLayout(new FlowLayout());

        // allocation/arrangement JLabels, JTextFields, (etc.) :
        
        }

    public void paint(...) {
        .
        . use those variables
        .
        }

    public void actionPerformed(ActionEvent ae) {
        // code to handle what user types:
        
        }

    }

e.g. Comparison program

scenario:

applet loads
those early initializations, if any, are done
gets executed
gets executed with the initial values for things
system awaits events --

the user types in a JTextField and presses Enter or Return key
gets executed to handle this event
store in variable what user typed in

gets executed to (re-)draw things
system awaits events -- PAUSE

the user types in a JTextField and presses Enter or Return key
actionPerformed() gets executed to handle this event
store in variable what user typed in JTextField
repaint()
paint() gets executed to (re-)draw things
system awaits events -- PAUSE

the user types in a JTextField and presses Enter or Return key
.
.
.

repetition although no explicit for or while
"There is no ~~spoon~~ !

actually JLabel and JTextField variables could be initialized too

    JLabel l = new JLabel("label-text");
    JTextField t = new JTextField(init._text, #spaces);

e.g. clique program

translating a desired task into formalism -- math/program -- is standard work
here's an example
explication:
to have $k$ points,
divide the value for going all the way around:

by $k$
yielding , the angle to move between each pair of points

(you can discuss the math in this program more in discussion-sessions)

another Java feature used here (doesn't involve GUI):

|final|

final can be put in front of variable declaration (+ initialization)
specifies that this ^variable' doesn't change
in block of code where using it

since it doesn't change, instead of "variable" call it
"named constant" (or "constant-identifier" or "parameter")
standard practice: final constant-identifier-names
(if they are in fact set to explicit constant values)
e.g.:

 int X_OFFSET = 15, Y_OFFSET = 20, DIAMETER = 25;
for( int i = ; i < 15; i++ )
  g.fillOval(X_OFFSET + i*DIAMETER, Y_OFFSET, DIAMETER, DIAMETER);

also in  clique.java of GUI lecture-notes
theta doesn't change throughout  paint()
it does get a new value if  paint() is re-executed, but that's OK:
the point is that from the declaration and initialization of it,
it doesn't change until finished with it in the ^block of code'.

terminology: "block"
code enclosed in

between executions of  paint(),  theta doesn't exist
so each time it gets a new value, really it's a new  theta getting the only value it'll have while it exists.
similarly with  final int X, Y : stop existing when  for-body concludes,
recreated each time  for-body starts,
with the only values they'll have while they continue to exist (until the end of the  for-body)

using  final is nice thing you should do when possible
clarifies to reader what your code does and doesn't do
e.g. consider if code has a zillion variables which could change
versus some real variables and some constant parameter-values
also improves safety of your programming:
when you plan your program, you may assume that a certain value doesn't change
e.g. an offset-value
but programs get long, complicated, lots of operations,  ++ various places, ...
if things are screwy, when you debug, assuming that value doesn't change
may take a while to find the error
versus if you declare the value  final, the compiler will find the error for you

summary of this lecture-module

GUI: