professional java user interfaces phần 10 pptx

572 An Example Ad-Hoc Component 3:12 PM 9 March 2006 c16.fm 1.0 Try launching the executable sandbox.jar file, and have fun with the actual program. An example interaction Suppose the user has already performed some manipulations on the objects shown in Figure 16.2. First undo the rotation on the bitmap using the contextual menu, as in Figure 16.3. Note that in the interaction example the clipboard is not used – that is, nothing was cut or copied, so the paste command remains disabled. New lines are added just like objects of the type ‘image,’ by clicking on the rele- vant tool button, then clicking in the sandbox area where the new line is to be placed. Double-clicking on a line allows its control points to be edited, as shown in Figure 16.4. Control points are moved by dragging them with the mouse. Line editing mode is disabled by selecting another object, or by clicking somewhere else on the sandbox area. To add new control points to a line when in edit mode, the mouse right button and the control key are used together. Figure 16.3 Undoing a rotation (Liquid) c16.fm Page 572 Thursday, March 9, 2006 3:12 PM The Sandbox architecture 573 3:12 PM 9 March 2006 c16.fm 1.0 16.3 The Sandbox architecture Now we can look at the implementation of the Sandbox component. Chapter 2 introduced the OOUI approach, mentioning its usefulness both as a means for designing the GUI, as well as a way to organize the resulting implemen- tation. The OOUI approach can be used as a fully-fledged composable unit strategy 2 . The software design discussed here is arranged around the development of the ad-hoc component using a top down, functional partition. Figure 16.5 shows an initial high-level division of the software design. A common approach in many architectures is to separate the domain definition from the application logic – that is, the functionalities made up of simpler, low-level features that expose the domain to users 3 . An e-mail inbox, for example, represents the generic domain of an archive of e-mails. Possible actions in such a domain depend on the purpose of the application. For example, an inbox component could be used in a customer- care application in which customer complaints are filed with e-mails that can Figure 16.4 Modifying the control points of a poly-line (Liquid) 2. See Chapter 7. 3. From a GUI design viewpoint this reminds us of functional user interfaces – that is, appli- cation GUIs designed around a set of functions. c16.fm Page 573 Thursday, March 9, 2006 3:12 PM 574 An Example Ad-Hoc Component 3:12 PM 9 March 2006 c16.fm 1.0 sorted by specific heuristics to extract a tentative subject, category, urgency, and so on. By implication, we are differentiating our ad-hoc component and the set of elementary functions it provides for interaction with the rest of the world from the commands a user will employ to interact with it. Following this decomposition, we will build our component around a set of generic, low-level functionalities that in turn will be used by other specialized code that packs them into higher-level, useful commands for user interaction. Figure 16.6 shows a possible refinement of the initial decomposition of Figure 16.5. The most important part is the ad-hoc component itself, which interacts with the control subsystem that is responsible for maintaining the coherency of the whole GUI. The third division accounts for the commands issued by the user, each part being composed from several Java classes. This high-level functional division focuses only on the more important portions of the implementation, and inten- tionally omits auxiliary code. The GUI will be designed by refining the simple functional organization shown in Figure 16.6 iteratively. This decomposition takes advantage of the peculiarity of the application, that of an ad-hoc component as the center of the application, but can be applied to the development of any GUI. Figure 16.5 An initial high-level functional decomposition Figure 16.6 Refining the functional decomposition c16.fm Page 574 Thursday, March 9, 2006 3:12 PM The Sandbox component 575 3:12 PM 9 March 2006 c16.fm 1.0 It would be nice to create a flexible, highly expandable framework, but the key issue here is to provide a simple, lightweight design. Features that are desirable, such as allowing for runtime palette loading – loading new graphical objects from a file and using them without having to reinstall a new version of the application – can be left for future versions. 16.4 The Sandbox component First we concentrate on building the ad-hoc component, the core of the applica- tion, beginning software design refinement from the ad-hoc component. Top-down refinement of functional organization Conceptually the Sandbox component is a container of graphical objects. Both the objects and the container itself can issue commands by means of contextual menus. This functionality can be modeled using the Commandable interface from Chapter 15. An initial refinement of the software design for the ad-hoc component in Figure 16.6 is shown in Figure 16.7. So far there is the visual container, which we’ll implement as a Java class called SandboxPanel , and the objects it contains that are manipulated by the user. Different objects will extend a base class, AbstractSymbol . Organizing object communication How should we organize the communication between the container and its objects? One of our requirements is to guarantee flexibility to the ad-hoc component in terms of new object classes that can be used. A clean way to obtain this is to dele- gate responsibility to the objects themselves. The container merely holds objects Figure 16.7 From the component to an initial high-level class diagram c16.fm Page 575 Thursday, March 9, 2006 3:12 PM 576 An Example Ad-Hoc Component 3:12 PM 9 March 2006 c16.fm 1.0 and performs some common operations on them. Objects are responsible for drawing themselves on screen, for interacting with the user, and so on. This approach offers a great deal of flexibility, allowing for the use of different object types without impacting the container. The container needs access to objects to draw them on the screen. Objects in turn now have many responsibilities delegated to them, rather than keeping them all centralized. Following this strategy, mouse input events, for example, need to be re-issued to the relevant objects, so that the objects themselves can consume the mouse event as required, transparently to the container and to other classes. Objects are black boxes as far as the other classes are concerned – the essence of object-oriented programming. Suppose that an object is modified and the changes are committed. The container needs to be notified so that it can refresh the screen to show the changes. Decou- pling responsibilities at design time is always a great idea, but generally it needs extra care when it comes to runtime object communication. One possible solution is to adopt the Observable pattern (Gamma et al. 1994). This makes the design more modular – components interested in object behavior just register themselves as observers – and allows for future expansion, with more sophisticated events being distributed by more complex objects, while keeping the overall design simple. When we need to make the director class communicate with objects, we can then just add it as another listener without making any change to the class structure. Figure 16.8 shows this arrangement. Instead of creating our own event classes, we adopt the Observer / Observable mechanism implemented in the java.util package. This decision has the prac- tical drawback that the Observable class must be extended, instead of an interface for objects to be observed, but this is not a problem. Figure 16.8 Making objects communicate with their container c16.fm Page 576 Thursday, March 9, 2006 3:12 PM The Sandbox component 577 3:12 PM 9 March 2006 c16.fm 1.0 Using the Observer design pattern simplifies class coupling enormously. A class interested in object behavior registers itself as an Observer . This application has two classes that are interested in monitoring object behavior: • The graphic container – when an object changes, it is time to refresh the screen. • The director, which manages the coordination among interacting objects. We could have mimicked the Swing API, for example for screen area invalidation, but we prefer to explore and illustrate alternative mechanisms. We avoid an MVC architecture for our ad-hoc component to show that similar designs can solve the same problems. We don’t need the flexibility of multiple views of the same model, and such a complex arrangement might make it difficult to focus on the important ideas. The SandboxPanel class The SandboxPanel class is the graphical container of AbstractSymbol instances. It is implemented as a specialization of the JPanel class, as shown in Figure 16.9. The SandboxPanel class is responsible for showing objects to the user and making them available for direct manipulation. Apart from this, the graphical container is Figure 16.9 The SandboxPanel class c16.fm Page 577 Thursday, March 9, 2006 3:12 PM 578 An Example Ad-Hoc Component 3:12 PM 9 March 2006 c16.fm 1.0 essentially a passive object, manipulated by the director class. To ease the interac- tion between the two classes we allow the graphical container to invoke the director directly. Objects are drawn on the screen by means of the paint() method, which has been customized to support our logical model. Interested users can find more informa- tion on the paint() method in (Fowler 2000). The container scans the ordered list of objects, drawing each of them by invoking their draw() method. The order of the list defines the graphical layering of the objects, so that the method putInFront() simply moves the given object to the end of the ordered list, ensuring that it will be painted last and thus lie graphically ‘above’ all the others. The graphical container provides other methods for manip- ulating objects, such as remove() for eliminating an object. Another duty of the container is to capture user input by means of mouse event listeners, decode it, and submit it to interested components. The mouseClicked() method handles the following events: • It adds new objects to the graphical container. • It manages double clicks for placing objects into edit mode. • It handles contextual menu pop-up. • It selects objects. • It issues events to the object itself. The mouseDragged method simply reissues the event to the relevant object, so that the object can manage the event accordingly. Following a top-down approach, we now turn to the objects themselves. At this level of detail we manage the AbstractSymbol class as the most general class representing any object able to be added to the container. Now we refine the part of the ad-hoc component that represents objects. The features implemented in this example are chosen for illustrative reasons, and the application has been simplified in a variety of ways. Only single selection is available, for example, so its clipboard can contain only one object at a time. This avoids the implementation of multiple-selection interaction with the mouse, dragging a rectangle on the screen or holding the shift key while selecting more objects. This could be implemented easily using an array of objects in the clip- board. In addition, only two object types are implemented, but the design can allow for a much larger object palette. The number of different object classes is limited to focus on the more interesting aspects. There are no save or load features, although they could be added relatively easily by means of serialization extended to all the involved classes. There is no way to delete all the objects at once, or to create a new, blank sandbox. c16.fm Page 578 Thursday, March 9, 2006 3:12 PM The Sandbox component 579 3:12 PM 9 March 2006 c16.fm 1.0 Graphical objects The AbstractSymbol class is the most generic object to be contained and manip- ulated by the Sandbox component. It represents the behavior of any object that can be added to the framework, and is shown in Figure 16.10. Users can select an object, move it within the container, and open it for editing by double-clicking on it. These features translate into three properties of the AbstractSymbol class shown in Figure 16.10, respectively: selected , editMode , and location . There are a small number of methods that apply to any object, both for convenience: •The initializeAt() method for creating an object at a given point •The contains() method, which verifies whether a given point lies within that object area and for interacting with the rest of the world: •The processMouseEvent() method manages mouse input •The getContextualMenuItems() method implements the Commandable interface for publishing user commands). Finally, we need a clone() method for creating new objects. Figure 16.10 The AbstractSymbol class c16.fm Page 579 Thursday, March 9, 2006 3:12 PM 580 An Example Ad-Hoc Component 3:12 PM 9 March 2006 c16.fm 1.0 From a practical viewpoint, the contains() method is used for picking an object, given its screen coordinates. This method in turn uses getRectBounds() , so that simple-shaped object classes don’t have to implement the contains() method. This is helpful for objects that have a rectangular shape. For other objects types, it will be necessary to override the contains() method. When the user clicks on an object to select it, the container class scans the list of all objects to find the first one whose contains() method returns true. Note that the first one in the list will also appear to the user as the visually top-most one. In real applications when several dozen or more different objects can be employed in the same palette, it is crucial to design the object class hierarchy carefully, both to maximize code reuse among different object classes, and to keep the design easy to maintain and expand in the future. Such considerations are out of our scope here, but (Marinilli 2000) gives more details. The BitmapSymbol class implementation The bitmap object represents an image in the container, as shown in Figure 16.1 on page 570. The BitmapSymbol class implements this simple type of object. The class is shown in Figure 16.11. Figure 16.11 The BitmapSymbol class c16.fm Page 580 Thursday, March 9, 2006 3:12 PM The Sandbox component 581 3:12 PM 9 March 2006 c16.fm 1.0 The bitmap object exposes the following two commands to the user via the getContextualMenuItems() method of the Commandable interface: • Rotate the object, performed by the rotate() method. • Change the bitmap image, implemented by the ChangeImage action class. This is described in The Actions class on page 584. A default image is used when creating a new bitmap object – see the related code in the BitmapSymbol class. The draw method is invoked to paint an object onto the screen. The image is rotated at the current rotation angle, depending on the rotate commands previ- ously performed on the object. The setImage() accessory method implementation is worth mentioning. After updating the internal data with the new bitmap image, the method invokes the observer/observable mechanism. This will invoke all its listeners, giving them a chance to react to the event. The director checks for logical – business domain – coherence, while the graphical container repaints itself, refreshing the screen with the new object image. Open-ended communication via events The BitmapSymbol class is very simple and doesn’t use all the flexibility the design allows. The sequence diagram in Figure 16.12 shows a representation of the PoliLine class’ mouseEvent() implementation. SandboxPanel aSymbol processes the event processMouseEvent(me) a new MouseEvent me is sent to the component processes the event internally, without the container knowing Swing framework Figure 16.12 Objects independently process mouse events c16.fm Page 581 Thursday, March 9, 2006 3:12 PM [...]... can be common among developers building adhoc components 3:12 PM 9 March 2006 c16.fm 1.0 A A Questionnaire for Evaluating Java User Interfaces A Questionnaire for Evaluating Java User Interfaces This questionnaire can be used as an acceptance test at the end of a test session with users, or for a first-cut usability evaluation It should not be used as a substitute for usability tests Section A: Your... subclass It is interesting to contrast the concept of a JHotdraw tool with the way in which user input is handled in the Sandbox application Basically, a tool defines a modality of the drawing view as perceived by the user Tools are activated when the user clicks on a button in the palette, and deactivated when the user clicks on another button While active, a tool consumes all input events captured by... ougtside of user control – and it often tends to happen during delicate, complex, and memoryconsuming operations It may therefore disrupt the user s work, and will certainly creates a vaguely unpleasant feeling A better solution from a usability viewpoint is to leave the user in control of the application This can be done by checking memory occupancy before issuing an undoable command This allows users to... Look and feel design guidelines, for example those for Java and Apple Macintosh, explicitly dictate that every command has a ‘cancel’ option This type of preemptive control can be achieved as shown in the following simplified code extract: if (Runtime.getRuntime().freeMemory() . poly-line (Liquid) 2. See Chapter 7. 3. From a GUI design viewpoint this reminds us of functional user interfaces – that is, appli- cation GUIs designed around a set of functions. c16.fm Page 573. the whole GUI. The third division accounts for the commands issued by the user, each part being composed from several Java classes. This high-level functional division focuses only on the more. is the visual container, which we’ll implement as a Java class called SandboxPanel , and the objects it contains that are manipulated by the user. Different objects will extend a base class, AbstractSymbol . Organizing