Object-Oriented Programming (Java), Unit 17

1. Object-Oriented Programming (Java), Unit 17 Kirk Scott

7. This is the label in Wikipedia for the next picture: • Bee larvae as food in Java • What?

9. Components, Containers, and Painting • 17.1 Components and Containers • 17.2 Painting • 17.3 Dialog Boxes and String Output to a Panel

10. 17.1 Components and Containers

11. 17.1.1 System Classes for Components and Containers • Some of the classes in the API for creating graphical user interfaces:

13. 17.1.2 Top Level Containers • The JFrame, JDialog, and JApplet classes are known as top level containers. • They are the basic building blocks for graphical applications. • All of the components of a graphical application or applet have to be contained in a top level container.

14. For the graphical applications of this and the following unit, the top level container will be the JFrame. • The JPanel class will be used as a sub-container for organizing the elements in a frame. • If you have not encountered applets before, the use of the JApplet class will be introduced in Unit 21.

15. 17.1.3 The Structure of Top Level Containers • A top level container such as a JFrame has a root pane. • The root pane manages a layered pane. • The layered pane contains a content pane and the menu bar, if there is one. • The layered pane has functionality associated with keeping graphical components in order when painting them.

16. The root pane also manages a glass pane. • The glass pane “covers” the whole top level container. • It has functionality associated with receiving mouse clicks and painting over multiple components.

17. Knowing all of these relationships isn’t critically important. • However, having a rough idea of them may help you visualize what’s involved when you write graphical code • A diagram of these relationships is shown on the following overhead.

18. The Underlying Structure of a JFrame

19. 17.1.4 Simple Graphical Applications and Containment • Simple graphical applications make use of a JFrame and its content pane: • Each top level container has a content pane which is the container for the visible components. • Calling getContentPane() on a frame returns a reference to the pane. • The visible components of an application are in a containment hierarchy descending from the content pane.

20. The JFrame of an application will contain a content pane. • The content pane will then contain one or more instances of JPanel. • Then the rest of the containment hierarchy descends from those panels • A component is put into a container by calling the add() method on the container and passing the component as a parameter.

21. Menus are also important parts of many graphical applications. • They are added to the JFrame object of the application, not to the content pane. • If you refer back to the previous diagram, the menu and content pane are at the same level in the structure of the JFrame.

22. 17.1.5 The Model-View-Controller Design Pattern • A more advanced course, like CS 304, covers the topic of design patterns in detail. • The design pattern most closely associated with graphical user applications is the model-view-controller pattern. • This pattern relates to how the functionality of an application is divided up and implemented in classes.

23. The state of an object is contained in its instance variables. • This is the model. • The representation of an object on the screen is its view. • An object may be enabled to respond to user actions like mouse clicks. • This functionality is the controller.

24. A general implementation of an application will separate the model, view and controller components • The examples given in CS 202 will not make full use of this technique • However, they do not violate it • The examples are a start towards making flexible applications.

25. 17.2 Painting

26. 17.2.1 System Painting • Painting refers to the generation of graphical output by an application and its presentation on the screen. • As you will see, applications can do painting explicitly. • Graphical applications rely on characteristics of painting that the system supplies.

27. System triggered painting occurs under these three conditions: • When the component is first made visible on the screen. • When the component is resized. • When a component which was wholly or partly covered by another component is uncovered and needs to be repainted. • For system supplied components, painting is largely taken care of.

28. 17.2.2 Painting Methods • The JComponent class has several painting methods, which include paint() and paintComponent(). • The JPanel class is a subclass of JComponent and inherits these methods • Beginning with this unit, graphical applications will be created by extending the JPanel class

29. The graphical logic of the examples will be implemented by overriding the paintComponent() method in this application specific subclass of JPanel. • This is how and where applications will explicitly be coded to do their own painting.

30. Practical Considerations When Overriding the paintComponent() Method • paintComponent() is defined to take a graphics parameter. • The parameter is declared Graphics g. • The parameter should be cast to Graphics2D.

31. At the top of the overridden method this call should be made: • super.paintComponent(g2); • After this, the application specific code is written.

32. Casting to Graphics2D is just housekeeping. • This is the result of historical changes in Java. • Older versions of Java didn’t have a Graphics2D class, so applications used Graphics. • The parameter was left Graphics for backwards compatibility reasons • Newer code should use Graphics2D, but has to cast to agree with the old parameter type.

33. Calling super.paintComponent() is also a form of housekeeping, but this is something deeper. • You have seen calls to super before. • The idea is that the inherited version of the method, supplied by the system, includes a bunch of useful functionality that you don’t want to have to re-code. • You want all of that existing functionality, and you want to add to it those painting features which are specific to your application.

34. 17.2.3 The Callback Mechanism • The term “callback sequence” refers to this idea: • You write code for a method, but never call it directly • You call another method, which calls the original one that you wrote • This turns out to be a typical way of doing things in Java.

35. Painting is based on a callback mechanism. • This is probably your first exposure to the callback mechanism. • Specifically with painting, you write the paintComponent() method • However, in your code you never call this method

36. Instead, you call the repaint() method, which you inherit without overriding • The code for repaint() in the superclass contains a call to paintComponent() • Due to polymorphism and dynamic binding, when you call repaint() on an object of your class, and repaint() calls paintComponent(), your version of paintComponent() is used

37. The callback sequence doesn’t involve a call to super, but it has some similarities with that approach. • The idea is that the inherited method that you call has some useful functionality in it that you would like to use without having to re-code it. • Then the application specific functionality appears in the method that you implemented which that inherited method calls.

38. What Does repaint() Do? • repaint() makes a call to update(). • update() takes care of housekeeping. • repaint() then makes a call to the paintComponent() method of the object in question. • In your paintComponent() method, the call to super.paintComponent() causes the whole panel to be repainted • Then the application specific painting is done

39. What Does the Callback Sequence Look Like? • The sequence diagram given on the following overhead outlines the callback sequence for painting:

41. What Does the Callback Sequence Accomplish? • In an application, the callback sequence is initiated when the call to repaint() is made. • The reason for calling repaint() is that the state of some object in the program has been changed or updated. • In other words, from the model-view-controller point of view, the model has been changed. • When the model is changed, the visual representation of the model needs to be updated to reflect that change.

42. In summary, these are the things that have to be done to support painting in a simple graphical application: • Implement a paintComponent() method in a special purpose subclass of the JPanel class. • Cast the graphics parameter in paintComponent() to Graphics2D and include a call to super.paintComponent(). • Put in the painting code appropriate to the application. • Place calls to repaint() in the application at points where the state of the application has changed.

43. 17.3 Dialog Boxes and String Output to a Panel • The rest of this unit consists of three example programs, Echo1.java through Echo3.java. • The purpose of the examples is to show how to move an application from non-graphical text I/O to graphical text I/O. • The idea is this: • Up to this point, you have done I/O through MyTerminalIO or the Command Prompt (the black screen of death) • Step-by-step, graphical features are introduced in Echo1 through Echo3.

44. The information on the examples is organized as follows: • A brief introductory statement summarizing what the application does. • Screen shots illustrating what is seen when the application runs. • UML diagrams showing the components and structure of the application. • Remarks on the contents of the code. • The Java code for the application, without comments.

45. Echo1 • This program shows the use of the system supplied input dialog box. • Output is done through a MyTerminalIO object.

47. Only one object is created in the application, myterminal:

48. When using the dialog boxes, no object is created. • A static method is called on the system supplied JOptionPane class. • The showInputDialog() method always brings in a String, so if a numeric type is expected it is necessary to parse the String. • The call to exit(0) is not related to the use of the dialog boxes.  • It is included to illustrate coding an explicit end to a program.

49. import javax.swing.*; • public class Echo1 • { • public static void main(String[] args) • { • String inputString; • int inputInt; • double inputDouble; • double result; • MyTerminalIO myterminal = new MyTerminalIO(); • inputString = JOptionPane.showInputDialog("Enter a string."); • myterminal.println("Here is your string: " + inputString); • inputString = JOptionPane.showInputDialog("This time enter an • integer."); • inputInt = Integer.parseInt(inputString); • inputString = JOptionPane.showInputDialog("This time enter a • double."); • inputDouble = Double.parseDouble(inputString); • result = inputInt + inputDouble; • myterminal.println("Here is the sum of the values: " + result); • inputString = JOptionPane.showInputDialog("Enter anything to • quit."); • System.exit(0); • } • }

50. Echo2 • This program shows how to do hardcoded String output into a panel belonging to a frame in an application. • It does not literally echo.