1 / 37

CSPP 533

CSPP 533. Instructor: Tom Hayes hayest@cs.uchicago.edu Course web page: http://www.cs.uchicago.edu/~hayest/cspp535 Course mailing list: cspp535@cs Course directory: /stage/classes/current/cspp535. Course Goals. What makes a good interface Best practices for writing one

taber
Download Presentation

CSPP 533

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSPP 533 • Instructor: Tom Hayes hayest@cs.uchicago.edu • Course web page: http://www.cs.uchicago.edu/~hayest/cspp535 • Course mailing list: cspp535@cs • Course directory: /stage/classes/current/cspp535

  2. Course Goals • What makes a good interface • Best practices for writing one • Get hands dirty • Programs to show off

  3. Textbooks • A Java GUI Programmer’s Primer by Fintan Culwin

  4. Assignments • Posted on the course web site. • Due on the specified date. • Changes & clarifications announced on course mailing list • Mostly programming assignments: electronic submission • Some written assignments: due in class

  5. Course Project • Graphical “windows” interface to Linux file system • Open-ended • Minimum requirements TBA

  6. Final Exam • Probably about 1 ½ hours, during one of the last couple lectures • Mostly theoretical • Will cover concepts from class and the reading

  7. Why UI? • Software does not exist in a vacuum • Productivity • Ease of use • Salability

  8. Why this course? • Want good UI • Hard to write good UI • Good way to gain expertise in OO design and execution • Hone project management skills

  9. Example: SquarePuzzle • A simple application program: SquarePuzzle.java • Text-based interface

  10. GUI version • Code is in 3 files now: SquarePuzzle.java (application) SquarePuzzleDisplay.java SquarePuzzleApp.java (presentation/ translation)

  11. SquarePuzzle.java API

  12. GUI Design • Object-Oriented (OO) approach • Modularity • Clear Division of Code into Pieces (Modules) • Encapsulation • Modules can’t play with each others privates • Abstraction • Simple, consistent Interfaces, complex, changeable Implementation • Inheritance (Design Hierarchies)

  13. GUI Design II • Front End (UI) must be separate from Back End (Application) • Flexibility (upgrades, extensions, ports) • Maintainability • Elegance • Natural choice of modules • User view: form vs. functionality • Cleaner code

  14. GUI Design III Take this one step further: • Presentation, Translation, Application • Object-Oriented approach leads us to think of the front-end components as objects, to which functionality is attached. • Form (Presentation) vs. functionality (Translation) within the UI.

  15. PTA: components • Presentation • What the user interacts with directly. • Translation • Controls the behavior of the program in response to user actions. • Application • Core functionality

  16. Presentation-Translation- App Pres Trans App event method invocation Machine User I/O method invocation value returned Note: Other arrow-labels are possible

  17. Finite State Automata (FSA’s) • A model of computing in which the machine (or automaton) has finitely many states. At any given time it is in exactly one state. Each possible input event causes the machine to change states in a fashion which depends only on its current state.

  18. Diagrams for FSA’s start • States are labeled boxes/ovals. • Input Events are labeled arrows. • Arrow points from old state to new. (These may be the same) • One arrow out from every state in which the event can occur. • Start is indicated by black circle. • End states have no arrows out. S1 E1 E2 E3 S2 E4 Yes No Maybe E5

  19. FSA for tennis scorekeeping A WINS A 40-0 A A B A 30-0 40-15 B A B A 30-15 15-0 Adv A B B A A A start B 15-15 Deuce 0-0 B A B B A 15-30 A Adv B 0-15 B A A B 15-40 0-30 B B A B 0-40 B B WINS

  20. State Transition Diagrams • A visualization tool for programming. • Like diagram for FSA except • “States” do not completely describe the state of the machine • Events may cause different state changes depending on additional conditions • Events may have side effects • Similar to old-style flow-charts

  21. UI design issues I • Mental processing requirements • learning time • concentration required • user errors (minimize) • Allocation of functions • user • program • other programs

  22. UI design issues II • Mental models of system operation • user expectations • interface consistency • may limit extensibility • physical analogies • continuous representation • reversibility • event-driven style

  23. UI design issues III • Evolving user sophistication • Choice vs. Confusion • Multiple paths • Customization • Varied User Environments • Multiple Languages • Cultural References • Special User Needs/Handicaps

  24. Start of Lecture 2 Material • Events (intro, SUN) • Event Listeners (more advanced, SUN)

  25. Event passing model • Three key players: • Event generators • Events • Event listeners (a.k.a. event handlers) • More flexible than message-passing via method invocation. • One-to-many (broadcast) • Many-to-one (can do this with method invocation) • Combinations of the above

  26. Events and GUI’s • Multiple views of information can be simultaneously updated • Easy to support multiple input paths (different ways for user to achieve same result)

  27. Java GUI Components • Sun’s Visual Index to Components • Window: JFrame, JPanel, LayoutManager, JDialog • Menu: JMenuBar, JMenu, JMenuItem • Button: JButton • Display: JLabel

  28. Guide to Components • Title link takes you to Sun’s “how-to” page for each component. This contains links to the component API, demo code, and related pages. • My additional comments and links are below.

  29. Swing Component Hierarchy Object Component Window Container Dialog Frame JComponent JDialog JFrame JTextComponent AbstractButton JButton JMenuItem JToggleButton JPanel JMenu

  30. JFrame • Good parent class for an app. • By default, hides on close. Must override to destroy. • Primary sub-parts: Titlebar, Menubar, ContentPane

  31. JDialog • OptionPane subclass is handy, disposable. • Design choices: Modal or not? Also: Is this dialog necessary or annoying? (Quit? Are you sure? Really?)

  32. LayoutManager • Controls how Components are added to a Container. This should be used for almost all positioning needs. • FlowLayout is default. GridLayout also very easy to use. BorderLayout, CardLayout, GridBagLayout more complex but sometimes useful. • Nest Panels inside one another to achieve complex layout effects.

  33. After all that… • How to make a combination component/applet/application.

  34. JFrame MyClock MyClock app main pres trans

  35. Object ClockApplication incHour/Minute/Second cal setHour/Minute/Second val getHour/Minute/Second int “tick” listener addActionListener removeActionListener listener tim listeners ActionEvent “tick”

  36. JPanel ClockPresentation translator ClockPresentation setHour/Minute/Second val listener addActionListener listener removeActionListener hourButton ActionEvent “increment” minButton secButton listeners (ClockTranslators)

  37. Object ClockTranslator clockapp ClockTranslator app clockpres pres actionPerformed ActionEvent e

More Related