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

Transkript

1 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 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 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 data descrip8on: MODEL data illustra8on: VIEWs interac8on: CONTROLLERs 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 Observer Observer

2 package java.util; Observer i Java 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! Issues with MVC 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: 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 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 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 andfeel, t.ex.). Varje komponent har en modell kopplad 8ll sig. Hierarchical MVC Aka: Presenta8on abstrac8on control (PAC)

3 Separable Model Architecture De flesta komponenters modell har enbart göra med själva (t.ex. om en ä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. Your own components 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 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. Your own components 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 Fönstersystem Applikation Interaktionstoolkit Händelsehanterare och grafiktoolkit Operativsystem Hårdvara 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 Koda med klassbibliotek Min kod Kod i klassbibliotek Koda med framework Framework Min kod, brukar kallas för callbacks. Inversion of control (see Spring framework) Hollywood principle (we ll call you) Template method design pattern

4 Ett vanligt sätt att arbeta med frameworks är att man subklassar någon form av basklass med grundfunktionalitet. Sedan överlagrar man de metoder som man intresserar sig 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(); Koda med klassbibliotek Min kod Kod i klassbibliotek Koda med framework Framework 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. 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. Några GUI byggare: Visual Studio.NET Forms Designer, Borland C++ Builder, QT Designer, NetBeans, Olika plug ins för Eclipse, Men det finns många, många fler! NetBeans 6.0 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!

5 UML: Use case diagrams UML: Klassdiagram En abstrak8on av en eller flera processer, d.v.s. 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 UML: Interak8onsdiagram Visar hur meddelanden skickas mellan klassinstanser i systemet. Ger en översikt över processer i systemet. UML: Tillståndsdiagram Visar hur systemet går mellan olika 8llstånd. 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. Används för a@ visa rela8onen mellan hårdoch mjukvara i systemet. Kan också användas för a@ visa hur systemet är distribuerat över olika maskiner, t.ex. i e@ nätverk. UML: Fysikdiagram

6 Designmönster (design 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 Namn och generell typ Intent (vad den gör) Also Known As Mo8va8on Applicability Structure (e@ UML diagram) 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