I wanted to ask for a tip. How would you struct your application if you had a JFrame with many JPanels which have like ten JTextFields Labels, and an Edit Button.
Would you put all the code in the JFrame or would you extend from JPanel and include all of them in the JFrame?
What about the buttons? I want to use the MVC pattern, how would you handle the actionlisteners? Are each of them an own controller or would you use only one controller for all of them?
I think it's first of all a question of style and personal preference. It also depends on what your application should do and how.
If your JPanels all are very similar in a certain way it would probably make sense to extend from JPanel. For example if every panel had 10 Buttons where Button 1 does always action xyz() for its corresponding model-object (especially when this object is the same for all buttons of 1 JPanel) and Button 2 does abc() ...
If the JPanels are not strongly correlated in such a way I would place my code rather in the JFrame or in a third Object which sets the whole GUI up from outside.
It's similar with the actionlisteners. If you have very few actions I would probably go for just one controller-object for ease of use (not many files). If you have a lot of different actions I would group similar actions into one controller-object per group of actions.
That said it probably is best to start with a simple approach (YAGNI) where you do everything from the JFrame / third object and have one actionlistener and then refactor when you feel that splitting things up gives you a cleaner or more flexible design.
Related
I have two frames, Frame A and Frame B. Now, how the frame A will know when a button on Frame B is pressed?
It won't. I would consider a design pattern such as mvc: http://tomdalling.com/blog/software-design/model-view-controller-explained/
You need to have some sort of background construction to allow for the jFrames to communicate. MVC allows changes in the information for one jFrame to affect another. It's a little conceptually complex but appears to be a generally accepted form for creating user interfaces. There are a lot of resources out there to help you learn the correct form
We are going to use Swing for our next project which will be a lightweight desktop app.
I've been reading the Swing tutorials on Oracle's website and have started to get the hang of it.
I was told that instead of switching JFrame I need to work within one JFrame and switch JPanels.
My questions to you would be the following.
Can I create the JPanel designs (or their templates) in design mode (WYSIWYG editor) and call jframe.setContentPane(nameOfJPanel) or do I do them programatically in code?
Secondly, how do I structure my code... If I dynamically add new JPanels and bind their events to an event handler.. all my logic and code will be in one HUGE class with tens of methods. I just don't know how to proceed and nowhere can I find an example with multiple (more than 6 let's say) panels on the internet.
To WYSIWYG or not WYSIWYG
This is a debatable question at the best of times.
I encourage all my junior developers to start out hand coding UIs as it teaches them important basics about how to use layout managers and how to handle compound layouts.
This tends to take longer as you need to verify the layout with each change.
I personally use the form editor in Netbeans for most of my general work, but will hand tweak UI's
Structure
Think about boundaries of responsibility, reuse and reduce strategies.
What you don't want is some huge master class that does EVERYTHING. It will be difficult to maintain and update (I live with this horror every day).
Instead, identify the distinct areas of responsibility and either use getters and setters or models to move the data around the application. The more you can decouple your code, the easier it will be to update and modify.
Identify like work and model it as interfaces and abstract classes where you can. Basically where ever you start thinking about coping code is probably a good indication that your design is off and you should consider implementing abstract classes to cover the overlap.
Take advantage of the Action API for replicating commonly used concepts (copy and paste is an example of this. You would want menu items, possible toolbar items and maybe even popup items, these can all be handled by the same Action class).
Separate the data from view. As I said before, take advantage of models. The data shouldn't care how it is collected or modified, only that it can be. Equally, the view shouldn't care about how the data is managed, only that it is.
If possible, define interfaces between the separate areas of your application. This way you can further decouple of the application and no one part becomes reliant on any one implementation (hello my world :P)
Don't be tempted to simply dig through a component hierarchy to gain access to that field, it will produce a nightmare if you need to change the code!!
The JFrame will be the main window of your app and the panels will be the brick composing it.
You should create each panel in its own class and you can arrange them by functionality in packages. You'll have panels for holding content of logical part of your application and panels that contains real stuff.
A logical panel could be the main view and the menu bar. An application panel would be a form, a menu, a canvas...
You'll have to put application panels inside logical panel and to change the content of the logical in response to users actions.
You should study how layouts work in order to compose the view inside the JFrame and to layout components inside panels.
For example the BorderLayout is a classic when defining the main area of an application:
- menu and toolbar on top
- browser on the left
- status bar at the bottom
- main panel on the center
You can use WYSIWYG editor, but avoid doing all design inside the same class. Else you'll have an horrible HUGE class. Create your panels in separate classes and compose them in your main view.
You can use empty panels as placeholder to help you create the structure of your application.
You'll have to bind your domain data to the view in order to not mix the two layer.
Bind means that you will write a way to go from a java bean to a form and the reverse.
Basic binding is handwritten, but some tools exists to do that.
If it is a small application, it is maybe better for you to handwrite everything.
Building a Swing application can be very tricky (you'll have to know about the event dispatch thread, layout management, event management, widgets (label are trivial, but JTable can be very complicated to handle);
I'll recommend to find a book about the topic, and to find some open source swing application in order to study how it structured, before you start your project.
This is how I organize my code:
class Panel1 extends JPanel{
//code for panel1 and its Components
}
class Panel2 extends JPanel{
//code for panel2 and its components
}
// and it follows.
class ApplicationFrame extends JFrame{
/// LOGIC to switch between panels
}
class Main{
//contains main() function
}
Any HAND-CRAFTED GUI code, is better than a COMPUTER GENERATED WYSIWYG -APP Code.
I am building a graphical user interface in Java and I was wondering if anyone can give me some directions.
Specifically, When clicking on a button in this GUI a big JDialog (it's a class that extends a JDialog) opens up for the user to enter some information, see some information, click on some things etc.
This class has multiple JLabels and other components in it. My question is how would one create such an instance? Right now I have everything in the constructor, making it a 500(!) lines constructor. There has to be an alternative to that!
The constructor is about 300 lines of code of components placement and settings for them and another 200 lines for the listeners give or take.
Also another question that comes in mind is that right now I open this window from another class by calling
MyClassExtendsJDIalog temp = new MyClassExtendsJDIalog();
but I don't use this "temp" variable at all in the class that I create it, as the constructor of "temp" does EVERYTHING. It seems like I am, again, doing something the wrong way.
Thanks for reading this.
If you want split up the code to make it more readable and manageable you can allways group the fields into subclasses of JPanel, i.e. Panel1, Panel2 etc and then just add those in the JDialog subclass constructor. But setting up a GUI in swing takes a lot of lines, yes...
as for the temp variable not being used, I'm guessing you call show() in the constructor?
Normally I would not do that, but instead call it in the code creating the dialog, ie.
MyDialog dialog = new MyDialog();
dialog.setVisible(true);
Without seeing your code it's difficult to give you specific tips on how to improve your code and design.
I agree, ~500 lines in your constructor intuitively feels like a problem. At a minimum, you might want to defer some of that work until after the instance has been created. Moving this into a init() method (or series of methods) is one approach.
You also might want to consider designing your class such that it contains a JDialog instead of extending one (See Composition over inheritance for a discussion on this topic) I suspect otherwise you are conflating the concerns of several classes.
Finally, you might want to review the Java Swing Tutorial for general tips and techniques for creating Swing based user interfaces.
Yes you are doing something wrong, but you are in good (or bad) company.
You should apply the rules of good OO design and clean code to your swing classes as to anything else.
What exactly you can do is hard to tell without looking at the 300+ lines of code (and I really don't want to see the ;-) but here are somethings that are probably applicable.
My main design rule is the Single Responsibilite Principle. According to your description (and my guesswork), you are doing the following in your constructor:
* creating (including configuring) components
* placing them in some kind of layout
* registering Listeners
* implementing Listners
These are 4 completely different concerns.
After some heavy refactoring you might end up with something like this:
You might want to have a factory that creates your components.
You might have a Layouter class that takes a component or a group of components (like label plus matching textbox) and places them on a panel.
You might have a class takes components (and maybe models or whatever) and wires them together using Listeners.
And a class that gets passed all this uses it in a suitable way and spits out a JDialog with the panel with all your components on.
Note: Idealy nothing extends JDialog anymore. You should only extend Janything if you intend to build a new Swing component.
This example is using Scala but it still should offer some inspiration: http://blog.schauderhaft.de/2011/06/26/clean-code-with-swing-and-scala/
I have about 3 frames in my java swing application. What it the correct way how to handle with these frames? I mean some pattern or something else. Now I have always one class which represent frame and one class for panel which is main in this frame. Now I have defined frames as static variable and when I wanna hide them I call
classname.frameName.setVisible(false);
is this the correct solution?
Besides the (excellent) suggestions of a CardLayout or JFrame with multiple JDialog instances, here are some other strategies which might work singly or in combination, to collapse a variety of content panes into a single frame.
JDesktopPane/JInternalFames (Tut.).
JSplitPane (Tut.).
JTabbedPane (Tut.).
JLayeredPane, if you're feeling brave (Tut.).
JToolBar - floatable if needed (Tut.).
Different constraints of a JPanel in a nested layout.
There are probably more..
Of course, as Adamski pointed out, there are some further quirks to consider..
What if each frame has JMenuBars or JMenus?
Possibly combine them as sub-menus.
Take a look at a decent docking framework such as MyDoggy. This allows you to display all three components in a single JFrame, but is very flexible in that you can view the data side-by-side, resize and maximise components.
This design seems flawed. Instead of having multiple containers, you should use an appropriate layout manager. In this case, I recommend using CardLayout. This way, you would have a single container with multiple exchangeable views.
Controlling frames through static references seems to be a very fragile solution. What if the reference is null? What if the frame isn't in a completed state when setVisible() is called on it?
It would probably be a better idea to separate this logic out into a separate class and either have the frames register themselves to it , or construct everything up front.
I have developed my Java code in Netbeans, and now I want to develop the GUI for my application.
The application communicates with a server, so it's going to have a login frame for sure. After that there will be a main frame. From the main frame the user can choose where to go and as you can understand there will be a lot of frames.
I have already developed a version of the application where there are a lot of frames and using the "setVisible()", but I want something better looking. I want a stable frame and inside it, changing the panels or something similar.
How would I do this?
You might use JInternalFrames if you like them, or simply use a main panel with a CardLayout, and display the appropriate card depending on the clicked menu item, or the selected JTree node (as it's done in Windows Explorer and similar applications).
Use the Swing tutorial to get you started.
You can, at any time, make any Container object a JFrame's ContentPane. You can also add and remove Containers from any other Container. If you want a user to be able to jump to any of a dozen panels at any time, CardLayout, as suggested in another answer, is easily the best route. If, however, you intend to lead the user along a somewhat controlled path, you can start with a login JPanel. When that's done, you can create the next panel (a JPanel or something else), add it, and dispose of the first one. And so on until the user exits.
If the transition from one panel to another affects nothing else in the program besides the two panels and the parent Container (JFrame or descendant), this is probably the way to go. If a bunch of other places in the program need to know about the change, you'll want a more centralized mechanism, maybe using CardLayout.