CS11 – Advanced Java Winter 2011-2012 Lecture 5User-Interface Architecture n Model-View-Controller (MVC) q A very powerful design pattern for creating user interfaces n Separate GUI applications into three components: n Model q The actual data that is being displayed and manipulated via the user interface n View q The visual representation, displayed in the user interface n Controller q Receives user inputs from the UI, and manipulates the model and the view appropriatelyModel-View-Controller Pattern n Frequently represented like this: n The View “observes” the Model q View receives “data changed” notifications from model q View manages UI; updates display when model changes q Most efficient when model indicates exactly what changed Model View Controller method calls eventsModel-View-Controller Pattern (2) n The Controller receives input events from the View q e.g. “user pressed a button” or “user selected a list-item” q Controller then makes changes to Model, or to View, depending on user input Model View ControllerBenefits of MVC n Much cleaner UI architecture! q Don’t mix model, view, and controller code together q Much easier to change/add features later n Very easy to add new views q Views simply register to receive “model changed” events n Can’t always use MVC approach q Requires extra code to make model “observable” q Sometimes model isn’t complex enough to warrant the extra effort q For generic, extensible user interfaces, use MVC approach! View View Model Controller ViewSwing and MVC n Many Swing classes follow Model-View-Controller pattern n Example: javax.swing.JList q public JList(ListModel dataModel) q JList component is a view into a list of data, exposed via the ListModel interface q User can interact with the view n View fires ListSelectionEvent objects n You can provide the Model yourself q Implement the ListModel interface n You also provide the ControllerListModel Interface n ListModel is a simple interface: Object getElementAt(int index) int getSize() void addListDataListener(ListDataListener l) void removeListDataListener(ListDataListener l) n ListDataListener interface allows view to know when model’s data changes void intervalAdded(ListDataEvent e) void intervalRemoved(ListDataEvent e) void contentsChanged(ListDataEvent e) q Model fires these list-data events q View updates its appearance; resyncs UI with model stateListModel Implementations n Most Swing apps don’t need sophisticated models n Swing has default impls. of model interfaces q Provide code to fire events based on model changes q Programmer only has to specify what is being stored n javax.swing.DefaultListModel q Provides API similar to java.util.Vector or java.util.List q Store Object values at specific indexes in the model q toString() method is used to display each object’s value q When data changes, fires events that JList receivesJList Diagram n Model-View-Controller components of JList: n JList observes ListDataModel via events n Controller gets user input via list-selection events n Controller manipulates both JList and ListDataModel based on user input, etc. ListDataModel (fires ListChangeEvents) Controller (your app) (provides ListSelectionListener) JList (provides ListDataListener) ListSelectionEventsNew Concept: Observable Objects! n So far, only UI components fire events q e.g. when user does something n Can also make data objects that fire events when their data changes n Called the Observer pattern q Also known as Publish-Subscribe (or “pubsub” for short) n Observable data object publishes change-notifications n Interested observers subscribe to these notificationsObserver Pattern in Java n Java provides two utility types for this pattern n java.util.Observable base-class n addObserver(Observer o) n boolean hasChanged() n notifyObservers(Object arg) q A data object can derive from Observer q Argument to notifyObservers() can specify exactly what changed n java.util.Observer interface n void update(Observable o, Object arg) q An observer can implement this interface, then register on one or more Observable objects q Use Observable and argument to know what happenedProblems with Java Observable… n A few big limitations of Observable L n It’s a base-class, not an interface q If your data-object needs to derive from something else, you can’t use these classes q No multiple-inheritance in Java q When you design classes like this, prefer interfaces to base-classes! n Effective Java, Item 16 for more details on this! n Only have one notification method, with an Object argument! q No type constraints on argument… q Can’t provide multiple methods that handle different kinds of data-change events (e.g. data-added, data-removed, …)Swing and Observer Patterns n Lists, trees, tables all use MVC pattern q All have observable models q Models and their observers are specified using interfaces q (None of them use java.util.Observable…) n You can emulate this pattern too. q FooModel n The data model interface q FooDataEvent (a subclass of java.util.Event) n Describes some change in the Foo model n Different event-types specify different kinds of changes q FooDataListener (a subinterface of java.util.EventListener) n Observers of FooModel implement this interface n Provide several interface methods, for different data changesControllers n Application’s Controller handles events from View q (possibly also events from other sources…) q Updates Model (and possibly Views) based on user input n Controller needs access to the Model and the Views n For large apps, controller can be a separate top-level class q References to Model and Views are passed to Controller n For small apps, controller can be an inner class that implements UI event-listener interfaces q Can access enclosing class’ fields and methods q Can operate on Model and View(s)