View
217
Download
2
Tags:
Embed Size (px)
Citation preview
CSPP 533
Instructor: Tom Hayes [email protected] 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 Get hands dirtyo Programs to show off
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
Course Project
Graphical “windows” interface to Linux file system Open-ended Minimum requirements TBA
Final Exam
Probably about 1 ½ hours, during one of the last couple lectures Mostly theoretical Will cover concepts from class and the reading
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
GUI version
Code is in 3 files now:SquarePuzzle.java (application)SquarePuzzleDisplay.java SquarePuzzleApp.java
(presentation/translation)
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)
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
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.
PTA: components
Presentation What the user interacts with directly.
Translation Controls the behavior of the program
in response to user actions.
Application Core functionality
Presentation-Translation- App
PresUser Trans App MachineI/O
event method
invocation
method
invocation
value
returned
Note: Other arrow-labels are possible
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.
Diagrams for FSA’s
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
start
Yes MaybeNo
S2E3
E2
E5
E4
E1
FSA for tennis scorekeeping
40-15
40-0
30-0
0-15
0-0
15-30
0-30
0-40
15-0
15-15
30-15
B WINS
A WINS
Adv B
Adv A
15-40
Deucestart
A
B
A
A
A
A
A
A
A
A
A
A
A
A
A
A
B
B
B
B
B
BB
B
B
B
B
B
B
B
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
UI design issues I
Mental processing requirements learning time concentration required user errors (minimize)
Allocation of functions user program other programs
UI design issues II
Mental models of system operation user expectations interface consistency
may limit extensibility physical analogies
continuous representation reversibility event-driven style
UI design issues III
Evolving user sophistication Choice vs. Confusion Multiple paths Customization
Varied User Environments Multiple Languages Cultural References Special User Needs/Handicaps
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
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)
Java GUI Components
Sun’s Visual Index to Components Window: JFrame, JPanel, LayoutManager, JDialog Menu: JMenuBar, JMenu, JMenuItem Button: JButton Display: JLabel
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.
Swing Component Hierarchy
JComponent
AbstractButton
JButton
JTextComponent
Object
Component
Container
JMenu
JMenuItem JToggleButtonJPanel
JFrame
Frame
Window
Dialog
JDialog
JFrame
Good parent class for an app. By default, hides on close. Must override to destroy. Primary sub-parts: Titlebar, Menubar, ContentPane
JDialog
OptionPane subclass is handy, disposable. Design choices: Modal or not? Also: Is this dialog necessary or annoying? (Quit? Are you sure? Really?)
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.
listeners
ClockApplication
incHour/Minute/Second
tim
calsetHour/Minute/Second
Object
getHour/Minute/Second
val
int
listener
listener
ActionEvent “tick”
“tick”
removeActionListener
addActionListener
ClockPresentation
JPanel
hourButton
minButton
secButton listeners (ClockTranslators)
ActionEvent “increment”
valsetHour/Minute/Second
ClockPresentation translator
removeActionListener
addActionListener listener
listener