We Keep Coding

Where should I put the Java Swing API method calls?

I've just started to learn Java Graphical Programming. And I have a question. Where should I put the Swing APIs (such at setSize, setLocation, setTitle, etc)?
In the main method or in the constructor? Some tutorials put them inside the constructor of the class that extends the JFrame, but some others put them inside the main method. Is there any difference between the two?

Overriding the paint() method

I've got a beginner question here that I was hoping someone with some Java experience could help me with. Currently taking an intro to OOP course focused on Java. My instructor is currently covering awt and swing, specifically the need to override the paint method so that graphics are redrawn when a window is resized, etc. I like to do as much outside reading as possible, and my concern is that the examples that my professor gives involve things that I've read are not best practices. To get to the point...
I understand that it's necessary to override the paint method, but I don't know the best way to do so. My professor's examples are all similar to the following:
class Example extends JFrame {
public void paint(Graphics g) {
super.paint(g);
g.drawString("Blah, blah");
}
public static void main(String[] args) {
Example a = new Example();
a.setDefaultCl...
\\Etc...
}
}
This bothers me because it doesn't seem right to include everything for the GUI in the same class as my main method. Also, I read on a different thread here that you shouldn't extend JFrame, but there wasn't an explanation as to why. My solution was to create a class handling the gui and instantiate JFrame within the constructor. However, unless I'm mistaken, doing so won't let me override the paint method. I feel compelled to extend JFrame to allow me to override paint, but again I read that was the wrong thing to do.
Any help would be sincerely appreciated, I know I can just model my code off of what he has but I really want to understand this and know the best way to handle it.

I understand that it's necessary to override the paint method
No you should not override the paint() method.
You should override the paintComponent() method of a JPanel and then add the panel to the frame.
Read the section from the Swing tutorial on Custom Painting for more information and working examples.
The tutorial will also show you how to better structure your code so that the GUI is created on the Event Dispatch Thread (EDT). The tutorial also has a section on Concurrency which will explain why this is important.

Calling drawing on JFrame from another class

I've got a class in which there is a method that draws rectangles on a JFrame. Furthermore I've got a few methods with different types of sorting. In those sorting methods I am calling the drawing method when a specified button is clicked. I would like my code to be cleaner, so I wanted to divide the class into one that is responsible for drawing things and the other one that does the sorting. I don't know how I can call the drawing method from outside the class. I wanted to use static, but I would have to make all the variables inside the method static. I also thought about making an inner class, but I will still have that one big class and it doesn't really help. What can I do?

You should only be drawing from within the paintComponents method of the container. So it doesn't make sense for some external code to initiate a call to draw stuff. If you want this external class to change what is drawn, it should pass a reference to an object implementing some understood interface that can be called by the paintComponents method.

design question for java SWING app

Note: This is for a SWING course I am taking.
I have an assignment to make a simple graphics package (draw circles, squares, etc).
I was thinking of having multiple dialog boxes for entering the shape parameters, i.e:
Point has x,y
Circle has x,y,radius
Rectangle has x,y,width,height
etc.
I was thinking of creating a super dialog class with X,Y and extending it to allow for Width,Height or Radius etc.
For example, the rectangleDialog would invoke the super constructor with the additional parameters required:
public abstract class XYDialog extends JFrame {
public XYDialog(PARAMETERS ... params) {
// build the dialog by iterating through PARAMETERS
}
}
public class RectangleDialog extends XYDialog {
public RectangleDialog() {
super(PARAMETERS.WIDTH, PARAMETERS.HEIGHT);
}
}
then the super class is responsible for building the GUI
Does this seem like a reasonable approach? Does this make sense?
Thanks

Yes, I think it's a good solution. But, as stated before, reconsider the naming of your classes. If you extend a JFrame, call it SomethingFrame. If PARAMETERS is a normal class, it should not be in capitals.
I would also suggest extending JPanel instead of JFrame, and let the one instatiating these classes determine if to put them in a JFrame or a JDialog. A JFrame creates a whole new window, and you normally only have one main window for your application, whereas dialogs and panels are created on the fly.

Standards for using inner classes for GUI?

I'm wondering about the standard practice with inner classes (in Java but I suppose it applies to all OO languages).
So I have a JFrame subclass ControllerWindow that contains a JPanel subclass MapPanel which I draw onto (so it needs to overwrite paintComponent method) and which needs to implement a mouse listener. My current solution which works is to have MapPanel in a seperate class implementing MouseListener but when I showed this to the guy who runs my course the other day he seemed to think (we have a bit of a language barrier) this should be in an inner class in ControllerWindow or at least the MouseListener should be an inner class.
So my question is what would be the standard solution here, to put a MouseListener in the inner class, the JPanel in a different inner class or still in its seperate class? The JPanel implementing MouseListener in one inner class? And why?
The most important thing to me is that it works but I'd like to know about and understand the standard practices behind these things if possible.
EDIT: Very simplified version of current code below.
class ControllerWindow extends JFrame{
...
MapPanel drawPanel = new MapPanel();
...
}
and a separate class:
class MapPanel extends JPanel implements MouseListener{
...
public void paintComponent(Graphics g){
...//fillRects etc.
}
//MouseListener methods
public void mouseReleased(MouseEvent e){
requestFocus();
...
repaint()
...
}
public void mousePressed(MouseEvent e){}
public void mouseEntered(MouseEvent e){}
public void mouseExited(MouseEvent e){}
public void mouseClicked(MouseEvent e){}
}
Also could this be a situation where it would be acceptable to put both classes in the same file? I don't envisage using MapPanel for anything other than ControllerWindow.

It is common to use anonymous inner classes as event listeners because the code is usually quite simple (so a separate class may be overkill) and keeping the handler code "close" to the code that registers the listener can improve readability for people trying to understand your code, since all code related to the event is in one place.
EDIT: This is particularly true for classes that implement only one listener method. Perhaps less true for multi-method interfaces like MouseListener, since a class that implements the full interface will be more verbose.

I think it's somewhat arbitrary how you go about it (as Tom Hawtin commented, GUI standards=mud), since you're trading off complexity in the number of classes versus complexity in a single class. If you want to produce code simply for a demonstration, a single file might be easiest. If you want code that you're going to put into production and modify/maintain over time, abstracting out into different classes is almost certainly the way you want to go.
For example, if you embed MapPanel as an inner class in ControllerWindow, and then later want to replace it with a different type of MapPanel, you've got a massive update to ControllerWindow rather than just swapping out MapPanel for a different component type.
With the MouseListener, I'd be inclined to include it in MapPanel if it's handling events specifically for that component (that is, if only the MapPanel "knows" what a click means, it should be the one to process that click). I definitely wouldn't put it in ControllerWindow, since then you're "leaking" implementation detail from MapPanel. (The only case I can think of: in addition to your MapPanel, you have multiple panels type that all need to respond to clicks in the same way, so rather than implementing in each panel you could have the ControllerWindow do it. But even then, I'm not sure the code should be in ControllerWindow).
Whether MapPanel's mouse listener is an inner class implementation of MouseListener, or whether MapPanel implements it (as in your code above) probably comes down to a question of which style you prefer.

inner class would be better if it has a simpler syntax.
button1.click( function(event){ do something x... } );
button2.click( function(event){ do something y... } );
radio2.check ( function(event){ do something z... } );
java 7 may give us something like that and change the whole situation. as it is now, using a lot of annonymous inner classes can mess up the code and make it impossible to read. you should choose whichever style that makes your code beautiful and legible.

Because of multiple event handling requirement anonymous inner classes are required. Anonymous class can be written anywhere like in a class, in a method, in the argument. Therefore to abstain from creating many classes for each listener anonymous is preferred.

I found this article useful:
http://www.retrologic.com/innerclasses.doc3.html
In general, when you need to use a method pointer; extend adapter classes as inner classes to simplify your code.