in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 44 45 46 47 48 49 < 50 > 51 52 53 54 55 56 .. 166 >> Next

01 package org.javapitfalls.item16;
03 import java.awt.*;
04 import java.awt.event.*;
06 class CustomButton2 extends Button
07 {
Listing 16.2
When setSize() Won't Work 125
08: public CustomButton2(String title)
09: {
10: super(title);
11: System.out.println("Size of button is : " + this.getSize());
12: }
14: public Dimension getMinimumSize()
15: { return new Dimension(100,100); }
17: public Dimension getPreferredSize()
18: { return getMinimumSize(); }
19: }
21: public class GoodSetSize extends Frame
22: {
23: TextArea status;
25: public GoodSetSize()
26: {
27: super("Good Set Size");
29: setLayout(new GridLayout(2,0));
30: Panel p = new Panel();
31: CustomButton2 button = new CustomButton2("Press Me");
32: p.add(button);
33: add(p);
34: status = new TextArea(3,50);
35: status.append("Button size before display: " +
button. getSize() + "\n");
36: add(status);
37: addWindowListener(new WindowAdapter()
38: {
39: public void windowClosing(WindowEvent we)
40: { System.exit(1); }
41: });
42: setLocation(100,100);
43: pack();
44: setVisible(true);
45: status.append("Button size after display: " +
button. getSize());
46: }
48: public static void main(String args [])
49: {
50: new GoodSetSize();
51: }
52: }
Listing 16.2 (continued)
126 Item 17
1^ Good Set Size ^- |n|x|
Press Me
Button size before display: java.awt.Dimension[width=0,height=0] ?
Button size after display: java.awt.Dimension[width=100,height=100]
Figure 16.2 Run of GoodSetSize.class.
Running results in Figure 16.2.
It is interesting to note that our solution to setting the size of a component involved not using the setSize() method. This pitfall is caused by the design complexity of a cross-platform user interface and a developer's unfamiliarity with the chain of events necessary to display and resize an interface. Unfortunately, the supplied documentation of setSize() fails to suggest these prerequisites.
This solution also highlights the importance of properly naming methods and parameters. Should you use setSize() when you only need to set some internal values that may or may not be used by your display mechanisms? A better choice would be setInternalValues(), which at least clearly warns a developer of the limited guarantee this method offers.
Item 17: When Posting to a URL Won't6
Now that the Simple Object Access Protocol (SOAP) and other variants of XML Remote Procedure Calls (RPC) are becoming popular, posting to a Uniform Resource Locator (URL) will be a more common and more important operation. While implementing a standalone SOAP server, I stumbled across multiple pitfalls associated with posting to a URL; starting with the nonintuitive design of the URL-related classes and ending with specific usability pitfalls in the URLConnection class.
Connecting via HTTP with the Classes
To perform a Hypertext Transfer Protocol (HTTP) post operation on a URL, you would hope to find a simple HttpClient class to do the work, but after scanning the package, you would come up empty. There are several open-source HTTP clients available, and we examine one of them after examining the built-in classes. As an aside, it is interesting to note that there is an HttpClient in the package that is shipped with the JDK (and used by HttpURLConnection) but not part of the
6 This pitfall was first published by JavaWorld ( in the article, "Dodge the traps hiding in the URLConnection Class", March 2001 ( /javaworld/jw-03-2001/jw-0323-traps.html?)and is reprinted here with permission. The pitfall has been updated from reader feedback.
When Posting to a URL Won't 127
public API. Instead, the URL classes were designed to be extremely generic and take advantage of dynamic class loading of both protocols and content handlers. Before we jump into the specific problems with posting, let's examine the overall structure of the classes we will be using (either directly or indirectly). Figure 17.1 is a UML diagram (created with ArgoUML downloadable from of the URL-related classes in the package and their relationships to each other. For brevity, the diagram only shows key methods and does not show any data members.
The main class this pitfall centers around is the URLConnection class; however, you cannot instantiate that class directly (it is abstract) but only get a reference to a specific subclass of URLConnection via the URL class. If you think that Figure 17.1 is complex, I would agree. The general sequence of events works like this: A static URL commonly specifies the location of some content and the protocol needed to access it. The first time the URL class is used, a URLStreamHandlerFactory Singleton is created. This factory will generate the appropriate URLStreamHandler that understands the access protocol specified in the URL. The URLStreamHandler will instantiate the appropriate URLConnection class that will then open a connection to the URL and instantiate the appropriate ContentHandler to handle the content at the URL. So, now that we know the general model, what is the problem? The chief problem is that these classes lack a clear conceptual model by trying to be overly generic. Donald Norman's book The Design of Everyday Things states that one of the primary principles of good design is a good conceptual model that allows us to "predict the effects of our actions."7 Here are some problems with the conceptual model of these classes:
Previous << 1 .. 44 45 46 47 48 49 < 50 > 51 52 53 54 55 56 .. 166 >> Next