I'm developing a desktop app in java for a school project and I want to know how should I be designing the code of the GUI, specially because I will later have to run JUnit and functional tests on the app. I know it kinda sounds like an opinion-based question, but all I'm not asking for the "best" method, I just want to be pointed to a specific design pattern that can fit the need of my app.
To elaborate a little more on the type of application, it's "stage based", one button leads to a different section of the app. One main window, only error or warning popups (only one frame).
My current approach so far:
So far I've designed 3 different JPanel classes using eclipse's WindowBuilder (main menu, admin menu and user menu) and a AppGUI class that creates and empty frame with a CardLayout layout and fills it with one of the 3 panels (starts with main menu). Then the buttons on such panels point to the next panel. (Example, main menu -> user menu -> create profile)
The panels need to communicate with the AppGUI instance in order to execute the panel changes and later on, the functionality that the other options will have. To do this, I've been passing the AppGUI instance as a parameter to the panels on initialization and storing it inside each panel (I first thought of having a singleton AppGUI and have static reference to it, but I later on read that it's bad practice, specially for later mock testing).
Also I'd like to have the logic for the application on different classes other than the GUI classes and I'm not sure if passing the AppGUI as parameter to every method out there is good practice or not
In conclusion, it would be great if someone could point me to a specific design pattern for this kind of GUI, thanks in advance!
I would suggest the Model View Controller (MVC) pattern.
The idea of MVC is that the models (your app logic), the views (UI elements), and the controllers all work together. The models and the views are completely independent of each other i.e. you don't pass a model class object to a view class object or vice versa. The models and the views should talk to the controllers and the controllers makes all the decisions.
Controllers
They contain your app's UI logic, like how to layout the views. They are notified by the model once in a while (e.g. some data have changed!). They are also notified by the views (e.g. the user pressed a button!). And controllers need to respond to these notifications. For example, when the user pressed a button, the controller might tell another view to show, or tell the model to do some calculations or some other stuff. In your case, your controller is most likely to have all the ActionListener for the buttons and text boxes on the UI.
Models
They contain your app's logic. Try to design your model to be UI independent as much as possible. If designed correctly, your model should still work without the UI i.e. you should be able to make a command line version of your app without changing the model. For example, if you are making a calculator, the model should do the actual calculation.
Views
Most of the time, you don't need to worry about this part because swing already provides you with lots of view classes, such as JButton, JPanel, JTextArea etc. If you happen to be creating your own views, remember that it should not contain anything related to the model i.e. the view should work fine with a different model.
You can always search for more info on the web.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm developing an application which displays images, and plays sounds from a database. I'm trying to decide whether or not to use a separate JFrame to add images to the database from the GUI.
I'm just wondering whether it is good practice to use multiple JFrame windows?
I'm just wondering whether it is good practice to use multiple JFrames?
Bad (bad, bad) practice.
User unfriendly: The user sees multiple icons in their task bar when expecting to see only one. Plus the side effects of the coding problems..
A nightmare to code and maintain:
A modal dialog offers the easy opportunity to focus attention on the content of that dialog - choose/fix/cancel this, then proceed. Multiple frames do not.
A dialog (or floating tool-bar) with a parent will come to front when the parent is clicked on - you'd have to implement that in frames if that was the desired behavior.
There are any number of ways of displaying many elements in one GUI, e.g.:
CardLayout (short demo.). Good for:
Showing wizard like dialogs.
Displaying list, tree etc. selections for items that have an associated component.
Flipping between no component and visible component.
JInternalFrame/JDesktopPane typically used for an MDI.
JTabbedPane for groups of components.
JSplitPane A way to display two components of which the importance between one or the other (the size) varies according to what the user is doing.
JLayeredPane far many well ..layered components.
JToolBar typically contains groups of actions or controls. Can be dragged around the GUI, or off it entirely according to user need. As mentioned above, will minimize/restore according to the parent doing so.
As items in a JList (simple example below).
As nodes in a JTree.
Nested layouts.
But if those strategies do not work for a particular use-case, try the following. Establish a single main JFrame, then have JDialog or JOptionPane instances appear for the rest of the free-floating elements, using the frame as the parent for the dialogs.
Many images
In this case where the multiple elements are images, it would be better to use either of the following instead:
A single JLabel (centered in a scroll pane) to display whichever image the user is interested in at that moment. As seen in ImageViewer.
A single row JList. As seen in this answer. The 'single row' part of that only works if they are all the same dimensions. Alternately, if you are prepared to scale the images on the fly, and they are all the same aspect ratio (e.g. 4:3 or 16:9).
The multiple JFrame approach has been something I've implemented since I began programming Swing apps. For the most part, I did it in the beginning because I didn't know any better. However, as I matured in my experience and knowledge as a developer and as began to read and absorb the opinions of so many more experienced Java devs online, I made an attempt to shift away from the multiple JFrame approach (both in current projects and future projects) only to be met with... get this... resistance from my clients! As I began implementing modal dialogs to control "child" windows and JInternalFrames for separate components, my clients began to complain! I was quite surprised, as I was doing what I thought was best-practice! But, as they say, "A happy wife is a happy life." Same goes for your clients. Of course, I am a contractor so my end-users have direct access to me, the developer, which is obviously not a common scenario.
So, I'm going to explain the benefits of the multiple JFrame approach, as well as myth-bust some of the cons that others have presented.
Ultimate flexibility in layout - By allowing separate JFrames, you give your end-user the ability to spread out and control what's on his/her screen. The concept feels "open" and non-constricting. You lose this when you go towards one big JFrame and a bunch of JInternalFrames.
Works well for very modularized applications - In my case, most of my applications have 3 - 5 big "modules" that really have nothing to do with each other whatsoever. For instance, one module might be a sales dashboard and one might be an accounting dashboard. They don't talk to each other or anything. However, the executive might want to open both and them being separate frames on the taskbar makes his life easier.
Makes it easy for end-users to reference outside material - Once, I had this situation: My app had a "data viewer," from which you could click "Add New" and it would open a data entry screen. Initially, both were JFrames. However, I wanted the data entry screen to be a JDialog whose parent was the data viewer. I made the change, and immediately I received a call from an end-user who relied heavily on the fact that he could minimize or close the viewer and keep the editor open while he referenced another part of the program (or a website, I don't remember). He's not on a multi-monitor, so he needed the entry dialog to be first and something else to be second, with the data viewer completely hidden. This was impossible with a JDialog and certainly would've been impossible with a JInternalFrame as well. I begrudgingly changed it back to being separate JFrames for his sanity, but it taught me an important lesson.
Myth: Hard to code - This is not true in my experience. I don't see why it would be any easier to create a JInternalFrame than a JFrame. In fact, in my experience, JInternalFrames offer much less flexibility. I have developed a systematic way of handling the opening & closing of JFrames in my apps that really works well. I control the frame almost completely from within the frame's code itself; the creation of the new frame, SwingWorkers that control the retrieval of data on background threads and the GUI code on EDT, restoring/bringing to front the frame if the user tries to open it twice, etc. All you need to open my JFrames is call a public static method open() and the open method, combined with a windowClosing() event handles the rest (is the frame already open? is it not open, but loading? etc.) I made this approach a template so it's not difficult to implement for each frame.
Myth/Unproven: Resource Heavy - I'd like to see some facts behind this speculative statement. Although, perhaps, you could say a JFrame needs more space than a JInternalFrame, even if you open up 100 JFrames, how many more resources would you really be consuming? If your concern is memory leaks because of resources: calling dispose() frees all resources used by the frame for garbage collection (and, again I say, a JInternalFrame should invoke exactly the same concern).
I've written a lot and I feel like I could write more. Anyways, I hope I don't get down-voted simply because it's an unpopular opinion. The question is clearly a valuable one and I hope I've provided a valuable answer, even if it isn't the common opinion.
A great example of multiple frames/single document per frame (SDI) vs single frame/multiple documents per frame (MDI) is Microsoft Excel. Some of MDI benefits:
it is possible to have a few windows in non rectangular shape - so they don't hide desktop or other window from another process (e.g. web browser)
it is possible to open a window from another process over one Excel window while writing in second Excel window - with MDI, trying to write in one of internal windows will give focus to the entire Excel window, hence hiding window from another process
it is possible to have different documents on different screens, which is especially useful when screens do not have the same resolution
SDI (Single-Document Interface, i.e., every window can only have a single document):
MDI (Multiple-Document Interface, i.e., every window can have multiple documents):
I'd like to counter the "not user friendly" argument with an example that I have just been involved with.
In our application we have a main window where the users run various 'programs' as separate tabs. As much as possible we have tried to keep our application to this single window.
One of the 'programs' they run presents a list of reports that have been generated by the system, and the user can click on an icon on each line to pop open a report viewer dialog. This viewer is showing the equivalent of the portrait/landscape A4 page(s) of the report, so the users like this window to be quite big, almost filling their screens.
A few months ago we started getting requests from our customers to make these report viewer windows modeless, so that they could have multiple reports open at the same time.
For some time I resisted this request as I did not think this was a good solution. However, my mind was changed when I found out how the users were getting around this 'deficiency' of our system.
They were opening a viewer, using the 'Save As' facility to save the report as a PDF to a specific directory, using Acrobat Reader to open the PDF file, and then they would do the same with the next report. They would have multiple Acrobat Readers running with the various report outputs that they wanted to look at.
So I relented and made the viewer modeless. This means that each viewer has a task-bar icon.
When the latest version was released to them last week, the overwhelming response from them is that they LOVE it. It's been one of our most popular recent enhancements to the system.
So you go ahead and tell your users that what they want is bad, but ultimately it won't do you any favours.
SOME NOTES:
It seems to be best practice to use JDialog's for these modeless windows
Use the constructors that use the new ModalityType rather than the boolean modal argument. This is what gives these dialogs the task-bar icon.
For modeless dialogs, pass a null parent to the constructor, but locate them relative to their 'parent' window.
Version 6 of Java on Windows has a bug which means that your main window can become 'always on top' without you telling it. Upgrade to version 7 to fix this
Make an jInternalFrame into main frame and make it invisible. Then you can use it for further events.
jInternalFrame.setSize(300,150);
jInternalFrame.setVisible(true);
It's been a while since the last time i touch swing but in general is a bad practice to do this. Some of the main disadvantages that comes to mind:
It's more expensive: you will have to allocate way more resources to draw a JFrame that other kind of window container, such as Dialog or JInternalFrame.
Not user friendly: It is not easy to navigate into a bunch of JFrame stuck together, it will look like your application is a set of applications inconsistent and poorly design.
It's easy to use JInternalFrame This is kind of retorical, now it's way easier and other people smarter ( or with more spare time) than us have already think through the Desktop and JInternalFrame pattern, so I would recommend to use it.
Bad practice definitely. One reason is that it is not very 'user-friendly' for the fact that every JFrame shows a new taskbar icon. Controlling multiple JFrames will have you ripping your hair out.
Personally, I would use ONE JFrame for your kind of application. Methods of displaying multiple things is up to you, there are many. Canvases, JInternalFrame, CardLayout, even JPanels possibly.
Multiple JFrame objects = Pain, trouble, and problems.
I think using multiple Jframes is not a good idea.
Instead we can use JPanels more than one or more JPanel in the same JFrame.
Also we can switch between this JPanels. So it gives us freedom to display more than on thing in the JFrame.
For each JPanel we can design different things and all this JPanel can be displayed on the single JFrameone at a time.
To switch between this JPanels use JMenuBar with JMenuItems for each JPanelor 'JButtonfor eachJPanel`.
More than one JFrame is not a good practice, but there is nothing wrong if we want more than one JFrame.
But its better to change one JFrame for our different needs rather than having multiple JFrames.
If the frames are going to be the same size, why not create the frame and pass the frame then as a reference to it instead.
When you have passed the frame you can then decide how to populate it. It would be like having a method for calculating the average of a set of figures. Would you create the method over and over again?
It is not a good practice but even though you wish to use it you can use the singleton pattern as its good. I have used the singleton patterns in most of my project its good.
How do buttons in software written in Java work?
For example the above screenshot: when the user clicks different buttons, different algorithms are run on user-inputted data (it's a data analysis application) and the output is displayed. Just getting started writing Java GUI's though, it all seems like magic to me -- is there one ActionListener for every pane? Does it listen for different ActionCommands of the different buttons and execute the algorithm right within the actionPerformed() method (it seems a little nonintuitive to me to execute an algorithm in a method independent of data...i.e. the button doesn't know what data it's dealing with?). So far, all the action listener tutorials I've read online have merely printed something when the button is pressed...
What's the general structure for connecting button, actionlisteners, and actual actions performed in the background?
Thanks in advance.
The usual way is to have one action listener per button. The Statistics panel has access (via one of its fields), to the data it needs to read and modify). So, the handling of the first button in this panel could look like:
private void initButtonListeners() {
this.averageDegreeButton.addActionListener(new ActionListener() {
#Override
public void actionPerformed(ActionEvent e) {
computeAverageDegree();
}
}
// other buttons...
}
And the computeAverageDegree() method could look like
private void computeAverageDegree() {
double result = this.statistics.computeAverageDegree();
this.averageDegreeLabel.setText(formatDoubleToString(result));
}
My personal preference is to do almost nothing in the UI, but move it all to the model/controller side (not sure what the best name is as it is seldom pure MVC).
I think that everything you do in the UI should be doable through the API as well. Benefits are easier testing, redesign of the UI is possible without messing up your logic, easy to perform the heavy work on background threads, ... .
A good read describing this is the Humble Dialog article. Not really Swing specific, but applicable to all sort of UI's.
To answer your questions:
is there one ActionListener for every pane?
No, typically you have an Action (or ActionListener) for each button. I prefer to use Action instances as they are far more reusable then the typical anonymous ActionListener (and easier to test as well)
Does it listen for different ActionCommands of the different buttons and execute the algorithm right within the actionPerformed() method
Certainly not. Doing heavy calculations in that method will block the Swing UI thread (the Event Dispatch Thread), which results in a non-responsive UI while the calculations are ongoing. Showing progress becomes also impossible. Calculations are typically done on a worker thread, launched when your Action is triggered (for example using a SwingWorker). This is explained in the Concurrency in Swing tutorial.
it seems a little nonintuitive to me to execute an algorithm in a method independent of data...i.e. the button doesn't know what data it's dealing with?
The button should not know about the data. The data is typically stored in the model. The UI is only displaying it, but does not contain it (unless it is input just provided by the user). The button should just know what to call on the model. The model does whatever it has to do and fires an event. The UI picks up that event and updates itself.
At least, that is how Swing is designed (for example JTable and its TableModel). I so no good reason to not follow that model when making your own Swing UI's
If I have a massive Swing component in my application which takes a long time to initialize, and want to display this component in different places in my GUI at the same time, how would I preferably do this?
The GUI user must be able to interact with the different copies of the component
(they could, for example, work as mirrors).
Let's assume that one might want to display copies of this component dynamically, depending on the input of the GUI user (that is, we do not want pre-loading of many copies of the same component).
You need to change your components to access data in a model-view like fashion. Each component would need to point to the same model that would server up the data and do the intensive task once rather than multiple times.
Also, initialization is slowing the GUI, then it sounds like you need a splash screen or a progress bar and the task moved off the EDT.
Is there any way that you could pull the heavy-duty initialization code out, maybe into a '...Factory' class?
I would create a one instance of the component (let's say HeavyComponent) and a custom class extending e.g. JPanel and referencing the component. Let's name it MyContainer. On paintComponent() of the MyContainer I would draw original component into a BufferedImage or use heavyComponentReference.paint(g).
Then on click by the MyContainer I would swap the component replacing the panel with real instance of HeavyComponent and placing in the old location of the HeavyComponent new instance of MyContainer.
display this component in different
places in my GUI at the same time ...
without having to create a new copy of
the same component ... user must be able to interact with the different copies
No way.
I am trying to understand and practice the MVC-pattern to improve my development. So I started refactoring an application I once wrote and have progressed so far. It is completely clear how my model looks like and also the view is ready so far. But now I am searching for a good practice to design my controller layer.
I have created a view that's split up in different main components. Let me give you a short example:
There are 3 Panels that group specific components:
"FilePanel", holding a JTextField and two JButtons
"DataPanel", holding all components neccessary to display some data and some JButtons
"CalendarPanel", showing some calendar-sheets
These three Panels are each in a separate class and afterwards instantiated and arranged in a GUI-class.
No the actual question. As I separate the Panels, how should I build the controllers? Should each panel get its own controller class (FileController, DataController, CalendarController)? Or should there just be one controller class for the whole view?
If I create one controller class for each panel, how do can I achieve that the controllers communicate with each other? Example: If a button is clicked in "FilePanel", how do I notify "DataPanel" about this?
Could you give me some examples of best practice?
Are the Panels fundamentally separate?
NO: The set of panels is fundamentally one state. For example the panels represent a console showing different aspects of the same items under control. The user selects an item and all the other panels update to show views of the item. In this case one Controller is enough.
YES: That is can each of them move through various states independendently? This is the kind of realtionship you might have in a "Portal" style application. The user can work in each Panel pretty independently - extreme example, two separate side-by-side browser panes in one overall viewer. It's the kind of effect you get in Composite Applications where the user has windows open on different back-end systems. Sometimes user actions in one window cause things to happen in another window, but generally they run separately. In this case we have can have separate controllers each responsible for the state of a Panel. They can communicate with each other by event handling mechanisms. User clicks in File Panel, View contacts its controlled, which issues a "File Selected" event, whose payload is the id of the file. Note that the "click" event is translated into a non-ui specific event.
By having separate controllers we decouple the details of the current set of panels. Addind a new panel requires only that the new controller registers for events.