GrIP-vt2010-GUI-programmering
Model‐View – Model:
data
and
its
changing
rules (“applica8on
logic”) – A
data
model
can
have
a
number
of
views and
can
a@ach
them
dynamically – Views
are
not
necessarily
graphical – The
model
is
unaware
of
the
views’
details, it
just
no8fies
them
of
changes,
and
allows the
views
to
read
the
data
Model‐View‐Controller – When
the
controller
changes
the
model,
the model
no8fies
all
its
views
to
update – Instead
of
changing
the
model,
the
controller
can ignore
or
compensate
for
user
interac8on
that
is not
consistent
with
the
model
assump8ons (possibly
warn
user) • in
an
editor,
you
can’t
move
past
the
end
of
the
text
– S
E
P
A
R
A
T
I
O
N
Cristian Bogdan – 2010-02-01
View‐Controller – A
controller
defines
a
pa@ern
of
interac8on between
a
view
and
its
model – In
the
graphical
case,
the
controller
listens
to events
(or
gets
other
forms
of
no8fica8on)
from the
view
components
and
changes
the
model according
to
the
event’s
seman8cs – The
view
needs
not
know
details
about
the controllers
a@ached
to
it – Alterna8ve
controllers
of
the
same
view
define interac8on
strategies
Observer • För
a@
implementera
MVC
används
oWa designmönstret
Observer • Tillåter
a@
e@
objekt
meddelas
om
det
gjorts en
förändring
i
e@
annat
objekt,
utan
a@ objekten
görs
starkt
knutna
8ll
varandra • Event
listeners
(delega8on)
are
an
alterna8ve to
Observer
– data
descrip8on:
MODEL – data
illustra8on:
VIEWs – interac8on:
CONTROLLERs
Observer
Observer
GrIP-vt2010-GUI-programmering
Cristian Bogdan – 2010-02-01
Observer
i
Java
Issues
with
MVC
package java.util; public interface Observer { void update(Observable o, Object arg); } public class Observable { private Observer[] arr; public void addObserver(Observer o) { arr.addElement(o); } public void notify(Object arg) { for (int i = 0; i < arr.size; i++) { arr[i].update(this, arg); } }
Det här är inte hela sanningen, men principen är densamma i den riktiga javaimplementationen!
}
• There
are
different
interpreta8ons
of
the
MVC architecture • Strictly
speaking,
in
Swing
the
controller
is
the
event dispatcher • OWen
a
view
will
have
only
one
controller,
hard
or not
useful
to
separate • But
model
and
view
separa8on
is
oWen
easily possible
and
profitable • MVC
is
implemented
oWen
in
mul8ple
layers • Video
prototype
example,
we
iden8fy
the
model
and views
Project • Implement
the
produc8on
planner • Model:
tasks,
task
planning
dates/lines,
task rules: – Tasks
can’t
collide
on
a
line
/
date
interval – When
a
task
is
planned
on
a
certain
date,
others need
may
need
to
be
moved • to
earliest
possible
dates
• Views:
task
planning
chart,
task
table
Project:
hierarchical
model • Higher
level
model:
Current
Task – Does
not
affect
the
core
applica8on
logic – But
helps
the
two
views
coordinate
• Even
higher
level
model:
the
table
model – Cell
data:
from
the
Basic
Model – Cell
selec8on:
from
Current
Task
model – See
Swing
JTable
Project:
model • Basic
Model:
tasks,
task
planning
dates/lines, task
rules: – Tasks
can’t
collide
on
a
line
/
date
interval – Move
tasks
automa8cally
to
earliest
possible dates
• Views: – task
planning
chart,
controller:
drag
and
drop – task
table,
controllers:
edi8ng,
crea8on
Swing
Separable
Model
Architecture • Varje
komponent hanterar
view/control. • Själva
utritningen
är delegerad
8ll
e@
s.k.
UI object
(för
a@
man
ska kunna
ändra
look‐and‐ feel,
t.ex.). • Varje
komponent
har
en modell
kopplad
8ll
sig. • Hierarchical
MVC • Aka:
Presenta8on‐abstrac8on‐control
(PAC)
GrIP-vt2010-GUI-programmering
Cristian Bogdan – 2010-02-01
Separable
Model
Architecture
Your
own
components
• De
flesta
komponenters
modell
har
enbart
a@
göra med
själva
gränssni@et
(t.ex.
om
en
checkbu@on
är nedtryckt
eller
ej). • Vissa
komponenters
innehåll
kan
dock
bara definieras
av
applika8onen
(t.ex.
innehållet
i
en
lista eller
tabell). • Några
faller
mi@
emellan
(t.ex.
sliders). • Man
ersä@er
en
modell
genom
a@
subklassa defaultmodellen
och
sedan
anropa
setModel()
på komponenten.
– All
Swing
components
are
“lightweight”
(drawn
in
Java), and
you
can
make
your
own. – h@p://java.sun.com/products/jfc/tsc/ar8cles/pain8ng – Old
approach:
subclassing
Canvas
Your
own
components
Fönstersystem
– for
non‐rectangular,
or
transparent
components, you
need
to
extend
Component,
Container
or JComponent
directly – implement
the
needed
processXXX
and
addXXXListener – contains()
for
non‐rectangular
shapes – Implement
isOpaque()
or
call
setOpaque()
to
tell
whether your
component
is
transparent – as
usual,
paint()
to
draw
your
own
component
shape – If
the
component
is
opaque,
paint()
will
need
to
cover
all
the area
for
which
contains()
is
true
• Implement
the
paint (Graphics g)
method • you
get
a
rectangular
shape
covering
the
others • new JComponent(){ public void paint(Graphics g){…} };
achieves
the
same,
and
more • paint()
is
called
automa8cally
by
Swing
when
the
container becomes
visible • The
Graphics
object
contains
foreground
and
background
color,
as well
as
a
clipping
rectangle,
in
case
not
the
whole
component needs
be
drawn.
Applikation Interaktionstoolkit Händelsehanterare och grafiktoolkit Operativsystem Hårdvara
Frameworks • Erfarenheten
visar
a@
det
kan
vara
knepigt
a@ hantera
toolkits. • Om
allt
är
"8llåtet"
är
det
lä@
a@
applika8oner
blir inkonsekventa
eller
ser
"fula"
ut. • E@
framework
är
en
uppsä@ning
klasser
(abstrakta och
vanliga)
som
"påtvingar"
e@
visst
sä@
a@
arbeta. • Javas
framework
för
fönsterhantering
heter
Swing. Swing
vs
IBM/Eclipse
SWT • MicrosoWs
motsvarighet
heter
MFC
(som
nu
är
på väg
a@
ersä@as
av
.NET).
MFC
vs
Borland
OWL
Frameworks Koda med klassbibliotek
Koda med framework
Min kod
Framework
Kod i klassbibliotek
Min kod, brukar kallas för callbacks.
Inversion of control (see Spring framework) Hollywood principle (we’ll call you) Template method design pattern
GrIP-vt2010-GUI-programmering
Frameworks •Ett vanligt sätt att arbeta med frameworks är att man subklassar någon form av basklass med grundfunktionalitet. grundfunktionalitet. •Sedan överlagrar man de metoder som man intresserar sig för. för. •It is often suitable that the subclass is anonymous import java.awt.*; import javax.swing.*; public class MyFrame extends JFrame { public void paint(Graphics g) { g.drawString("Hello", 10, 50); } public static void main(String[] args) { MyFrame f = new MyFrame(); } }
GUI‐byggare • OWa
integrerade
med
en
IDE,
Integrated Development
Environment • GUI:er
består
oWast
av
widgets,
samt
kod
som skickar
meddelanden
mellan
dessa • GUI‐byggare:
"rita"
gränssni@et,
kod
som
skapar widgets
och
deras
layout
genereras
automa8skt! • Sedan
lägger
man
8ll
händelselyssnare
etc.
själv,
oWa via
någon
form
av
property
inspector.
NetBeans
6.0
Cristian Bogdan – 2010-02-01
Frameworks Koda med klassbibliotek
Koda med framework
Min kod
Framework
Kod i klassbibliotek
Min kod, brukar kallas för callbacks.
•What are the most important types of Swing callbacks? - event listener methods like windowClosing() - paint() method •Other callbacks in Java? yes, finalize(), Observer’s notify() •Fundament: we implement the callbacks, but never call them. We wait for the framework to call them.
Några
GUI‐byggare: • Visual
Studio
.NET
Forms
Designer, www.microsoW.com • Borland
C++
Builder,
www.borland.com • QT
Designer,
www.trolltech.com • NetBeans,
www.netbeans.org • Olika
plug‐ins
för
Eclipse,
www.eclipse.org • Men
det
finns
många,
många
fler!
UML • Både
en
mjukvarudesignprocess
och
en
serie diagramtyper. • Utvecklades
av
företaget
Ra8onal
i
mi@en
av 90‐talet. • Är
idag
standardiserat
och
används
överallt
i industrin. • Ger
dock
mycket
begränsad
info
om
hur användargränssni@et
ska
se
ut!
GrIP-vt2010-GUI-programmering
UML:
Use
case
diagrams
Cristian Bogdan – 2010-02-01
UML:
Klassdiagram
• En
abstrak8on
av
en
eller flera
processer,
d.v.s.
e@ scenario. • Visar
aktörer
och
use cases,
d.v.s.
vad aktörerna
gör. • One
or
more
scenarios may
be
generated
from
a use
case http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/index.htm
http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/index.htm
UML:
Interak8onsdiagram
UML:
Tillståndsdiagram
• Visar
hur
meddelanden
skickas
mellan klassinstanser
i
systemet. • Ger
en
översikt
över
processer
i
systemet.
• Visar
hur
systemet
går
mellan
olika
8llstånd.
http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/index.htm http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/index.htm
UML:
Ak8vitetsdiagram • Liknar 8llståndsdiagrammet men
fokuserar
på ak8vitet
istället. • En
ak8vitet
behöver
inte vara
detsamma
som
e@ 8llstånd. • Kan
motsvara
funk8oner som
användaren ak8verar. http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/index.htm
UML:
Fysikdiagram • Används
för
a@
visa rela8onen
mellan
hård‐ och
mjukvara
i
systemet. • Kan
också
användas
för a@
visa
hur
systemet
är distribuerat
över
olika maskiner,
t.ex.
i
e@ nätverk.
http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/index.htm
GrIP-vt2010-GUI-programmering
Cristian Bogdan – 2010-02-01
Designmönster
(design
pa@erns) • Utgår
från
arkitekten
Christopher
Alexanders
arbete
på
70‐ talet • Alexander
försökte
se
mönster
i
hur
man
löst
återkommande problem
inom
arkitektur
och
skrev
en
bok
där
han
beskriver lösningarna • Alexander,
C.
(1977).
A
PaHern
Language.
Oxford
University Press • Idén
togs
upp
på
allvar
inom
systemdesign
i
mi@en
av
90‐talet • Den
mest
kända
boken
är Gamma
et
al.
(1995).
Design
PaHerns:
Elements
of
Reusable Object‐Oriented
SoNware.
Addison‐Wesley
Design
pa@erns • Par8cipants
(beskr.
av
klasser
som
ingår) • Collabora8ons
(hur
klasserna
arbetar 8llsammans) • Consequences
(av
a@
använda
mönstret) • Implementa8on • Sample
code • Known
uses • Related
pa@erns
Design
pa@erns • • • • • •
Namn
och
generell
typ Intent
(vad
den
gör) Also
Known
As Mo8va8on Applicability Structure
(e@
UML‐diagram)