AC3: UI Software Architecture

The goal of this activity is to explore the main structuring patterns of GUI software: the view hierarchy, the observer pattern, and model-view-controller.

1 The View Hierarchy of Firefox

This exercise requires Mozilla Firefox, with the DOM Inspector installed.

One of the neat features of Firefox is its DOM Inspector, which allows you to browse through the Document Object Model (DOM) of a web page. The DOM is a tree corresponding to the parsed HTML of the web page. It is, in fact, a view hierarchy (plus some other stuff thrown in that usually doesn't appear in view hierarchies in other GUI toolkits, such as script code and comments).

Visit a web page and pop up the DOM Inspector.. Use Ctrl-Shift-I or Tools/DOM Inspector to pop it up. Drill down into the BODY element and click around a little. Notice that when you select a node in the Inspector, its bounding box in the web page is highlighted with a flashing red border. That shows you the area of the screen covered by that view.

Even cooler, the Firefox DOM Inspector can also display the view hierarchy for the whole Firefox window, not just the web page it's showing. In the Inspector, use File/Inspect a Window to inspect the whole browser window whose web page you were just looking at. Drill down into window, and find the statusbar element near the end of the list. Click on statusbar, and you should see it highlighted in the browser window.

Here are a few things to explore:

• Click on the toolbar listed just above the statusbar (its id is FindToolbar). Why doesn't anything highlight in the window? Make it appear by using Edit/Find, and then explore it in the Inspector.
• Find the Firefox menubar, and something called "toolboxspring" inside it. What is this for?
• Rename the File menu to Fool.
• Make sure the bookmark toolbar is visible (View/Toolbars/Bookmarks), and use Search/Select Element By Click to locate it.
• Put a new bookmark on the toolbar (e.g. by dragging and dropping from the address bar), and watch what happens to its children in the Inspector.

What are the container elements? What are the primitive elements? Primitive elements are actually hard to find! Even a node like a textbox or a label, which in other toolkits would be a leaf of the view hierarchy, appears to have children. What do you think is going on here?

2 Model-View-Controller

Design models (identifying key methods and events) for these user interfaces:

• A tic-tac-toe game.
• A listbox.
• In an address book program, the dialog box designed for editing the attributes of a person, like their name, email, and phone.

The last case is somewhat interesting, because the dialog box may need nothing but standard widgets -- textboxes, listboxes, checkboxes, etc. -- which are already tiny MVC patterns. So do we need a separate model representing a person for this interface? Can't the person be represented implicitly, by the values stored in all those widgets? Sometimes yes, sometimes no. Think about the tradeoffs.

3 An MVC Example

This exercise uses the simple AddressBook program shown on the right. (Note that this is by no means a usable address book interface. We're more interested in the software architecture than in the interface design for this exercise.)

Run AddressBook.jar, and explore its source code to answer the questions below.

• Identify the model classes and their corresponding view classes.
• Open a second window using the New Window button. Click the Add button in one window repeatedly to change the model. Trace through the code to see how clicking on the Add button affects the display of the other window.
• What model interface does AddressBook implement? Why might that be a problem? Think about decoupling the model from the view, and switching to different views or even different GUI toolkits.
• Notice that the Person class has no way to send events. Show why that's a problem, by putting the interface into a state where a view is inconsistent with its model.

4 Observer Pattern Pitfalls

Event-based programming can be tricky. This exercise explores some of the pitfalls by asking you to find bugs in a feature of the AddressBook program.

Run the AddressBook, and press Add several times to add blank entries to the address book. Press List to get back to the list. The Cleanup button is supposed to remove all these blank entries, but when you press it, it only removes one entry and then throws an exception. (To see the exception, run the jar from your command prompt.)

Explore the three implementations of the Cleanup button found in AddressBook.java:

• removeEmptyPeople1() is the implementation that caused the crash you just saw. What's wrong with it? (This is a more general Java mistake, but it's related to one of the observer pitfalls we discussed in class.)
• removeEmptyPeople2() is another implementation that tries to fix that problem, but it crashes too. What's wrong with it -- what pitfall is involved here?
• removeEmptyPeople3() does it right. But suppose instead that removeEmptyPeople() saved up all the events and fired them all at once at the end. What would go wrong?