Model View. View Controller. Model View Controller. Observer. GrIP-vt2010-GUI-programmering Cristian Bogdan

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 no8ﬁes them of changes, and allows the views to read the data

Model‐View‐Controller – When the controller changes the model, the model no8ﬁes 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 deﬁnes 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 no8ﬁca8on) 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 deﬁne 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 diﬀerent 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 proﬁtable • 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 aﬀect 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 ﬂesta 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 deﬁnieras 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 ﬁnns många, många ﬂer!

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 ﬂera 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)

Model View. View Controller. Model View Controller. Observer. GrIP-vt2010-GUI-programmering Cristian Bogdan

Recommend Documents