Applets, Graphics, GUIs, Events, and Other Cool Stuff

1
Applets, Graphics, GUIs, Events, and Other Cool
Stuff

• First point these are all different things
• you can write Applets that don't involve graphics
  or a GUI
• you can write graphic applications that aren't
  applets and don't involve a GUI
• you can write a GUI application but not in an
  Applet context
• etc.
• but you usually don't
• General order of understanding things
• what and why is an Applet
• how do we do "static" graphics in an Applet
  context
• how do we do "dynamic" rendering (make things
  change)
• how do we handle user input (GUIs, controls, and
  events)

2
Applets versus Applications

• Any program (Java or otherwise) has to run in
  some "execution container"
• for applications this is the operating system
• for applets this is a browser or applet viewer
• The execution container does a number of things
• "launches" the application
• opens streams to the "outside world"
• console window to do textual input and output
• a graphics pane in the windowing system that will
  allow you to do graphical input and output
• access to the file system
• access to other streams like IP ports to
  communicate with other processes, other machines,
  other sites, etc.

3
Applets versus Applications (cont.)

• The first technical difference is in the
  container Windows versus Internet Explorer (or
  actually Operating System versus Applet Viewer)
• The intent is that code for the applet is fetched
  from a remote machine (web server) then executed
  in a container on a local machine.
• therefore security is an issue
• therefore applets are prohibited from doing
  things that your Java applications can do
• Applet restrictions
• Applets loaded over the net are prevented from
  reading and writing files on the client file
  system
• Applets loaded over the net cannot make network
  connections except to the originating host.
• Applets loaded over the net are prevented from
  starting other programs on the client.
• Applets loaded over the net are not allowed to
  load libraries
• Applets loaded over the net are not allowed to
  define native method calls. If an applet could
  define native method calls, that would give the
  applet direct access to the underlying computer.

4
Just About the Simplest Applet

• Things to notice
• extending Applet
• its "main" method is paint(Graphics g) rather
  than main(String args)
• the Graphics object is a lot like System.out
  except it supports graphical operations rather
  than text writes
• so how do we run it, in a browser or elsewhere
• what else can we do with the Graphics object?
• what about properties like text font and color,
  background color

import java.applet.Applet import
java.awt.Graphics public class HelloWorld
extends Applet public void paint(Graphics
g) g.drawString("Hello world!", 50, 25)

5
Running a Java Applet

• First step is easy compile the applet
• Next build the corresponding HTML file (most
  easily in the same folder as the class)
• Running the applet
• from appletviewer directly
• from a browser
• from an IDE
• Note to self remember the silly version
  mismatch problem!
• javac HelloWorld.java target 1.1

A Simple Program
Here is the output of my
program
WIDTH500 HEIGHT500
6
Extending the Applet's Functionality

• The Graphics object seems to be our one portal to
  the outside world, so what else can we do with it
  besides write a string to an (x,y) position?
• Let's look at the Java documentation, and settle
  on something easy like fillOval
• and how do we set the current color?
• and how do we change the font?
• and what about the background color?

7
Drawing Images

• This is an easy way to render cool stuff
• There are two easy steps
• make the image available to the graphics object
• getImage(getDocumentBase(), "lucy.jpg")
• ask the graphics object to draw the image (just
  like an oval)
• g.drawImage(lucy, 200, 200, this)
• The moral imperative for the init() method

8
Accepting User Input (GUIs)

• Our old friend the Scanner was responsible for
  communicating information from the user to the
  application
• the user's only way of communicating was to type
  into a DOS window, which the user found tedious
• In the world of graphical user interfaces (GUIs)
  the user can communicate information to the
  applet in a number of ways
• typing into a text box
• pushing a button
• selecting a radio button
• But always keep in mind that this is just another
  way of moving information from the "outside
  world" to the application
• Let's try a simple example by pushing a button
  the user says "I am tired of the background color
  and want it changed"
• how to render the button to the window
• how to know when it has been pressed
• how to respond to a button pressed

9
Controls

• Controls is the name for "things that can appear
  in the GUI that the user can do something to, and
  when s/he does, the application that controls the
  GUI should take some action"
• Common controls are
• text box or area user gets to type stuff
• buttons user gets to push it
• radio buttons user gets to select exactly one
• check boxes user gets to check one or more
• Extreme coolness Java has libraries that do the
  heavy lifting
• render a text area on the graphics object
• allow the user to type stuff
• takes care of backspacing, cutting and pasting,
  etc
• notifies you when the user has "finished"
• Equally but not so overtly cool for push
  buttons Java can
• render the button on the graphics object, just
  like an oval
• let you know when the button has been pushed
  (this is an "event")

10
Adding the Control to the Graphics Object

• Controls persist across multiple paint()
  operations, so their definitions should go in the
  init() method
• Button changeColors is a variable in the
  Applet
• changeColors new Button("NEW COLOR!") happens
  in the init() method
• and we also need to add the button to the applet
• add(changeColors)
• Now we have a button on the pallet, but nobody is
  listening when the button gets pushed.

11
Responding to Events

• All inputs from the user (currently in the form
  of pushing a button) are generically known as
  "events"
• pushing a button
• tabbing out of a text field
• checking a box
• moving the mouse over some control
• pressing a particular key
• Objects created by the Applet (including the
  Applet itself) can register "interest" in certain
  events
• an object can say "let me know if somebody pushes
  the 'change color' button)
• So the first step is to register an
  "actionListener" for the button push
• implicitly, any other event like pressing a key
  or clicking elsewhere will be ignored, because
  nobody has registered an interest
• the application itself can be an actionListener,
  but to do so it needs to implement the interface
  ActionListener

12
Action (Event) Listeners

• In order to be an ActionListener for some
  control, an object needs to implement the
  ActionListener interface
• which means it needs to have a method of this
  form
• public void actionPerformed(ActionEvent e)
• that means for example that the Applet can be the
  object that is notified when the "change color"
  button is pushed
• because we can say changeColors.addActionListener(
  this)
• which means that the Applet's actionPerformed
  method will be called every time the button is
  pushed
• First let's add that structure (making the Applet
  the listener for button pushes)
• what is different about the world now?
• first let actionPerformed change the background
  color
• but why isn't the window pane being updated?
• Now we need to force the Applet to re-draw itself
  in order to reflect the change
• And one last trick just for fun each time there
  is a button push, cycle through some list of
  background colors

13
The Final Frontier Asynchronous Events

• So far we know how to
• write to a graphics object associated with an
  applet
• put controls on the graphics object to accept
  user input
• change the graphics objects appropriately based
  on the input
• What happens when the world changes, but not due
  to user input?
• the most obvious and common example is either a
  counter or the current time
• Working with the current time, let's start with
  the idea that we already know how to put the
  current time up on the applet's graphic pane
• Now the only question is how do we generate
  "events" that will cause us to repaint() the
  applet every so often to reflect the updated time
• Task 1 put the current time up on the applet
• notice that when the applet needs to repaint
  itself the time is updated
• that means all we have to do is figure out how to
  force the applet to repaint itself every second
  or so

14
Threads

• Threads are little processes that run in the
  background, and aren't necessarily associated
  with any I/O streams
• What we want is a thread that will "wake up"
  every half second or so, tell the applet to
  repaint itself, then go back to sleep
• It's mind blowing, but the same Applet object can
  act as
• the Applet, which is displaying graphical
  information on the window
• the ActionListener, which is responding to mouse
  clicks
• the clock thread, which is waking up every half
  second or so and reminding itself to repaint
• In order to do so we need to
• declare a new Thread that can run independent of
  the main applet
• Thread clockThread new Thread(this)
• implement the run() method that will sleep for ½
  second, then wake up and repaint the applet
• start the clock thread when the applet begins
  (clockThread.start())
• make sure the application implements the method
  public destroy(), which is called when the applet
  is terminated. Otherwise the thread keeps running