I have a few questions about Java swing GUI, FYI this is my first time using a GUI so I really don't know much about this stuff
I have code that is basically a user class with name and number attributes which I plan to use as a login page. So what I did was create a new GUI class for this user class completely separate from the user class (as in one class for functions and another for the GUI). Was this wrong? as in should I have placed the user methods and the GUI in one class?
I have 2 GUIs, a welcome GUI and a login GUI. How do I ensure that one leads to the next? I tried to make the welcome frame invisible (the login frame is made visible in its own GUI) but that didn't work.
The login GUI is similar to the one above and has frame.setVisible(true);
1- I have a code that is basically a user class with name and number
attributes which I plan to use as a login page, so what I did was
create a new GUI class for this user class completely separate from
the user class (as in one class for functions and another for the GUI)
, was this wrong? as in should I have placed the user methods and the
GUI in one class?
A common concept in UI development is "model-view-controller" (don't worry about controller just yet). This means that your "data" is modelled in some way (ie User) and your "view" (UI) takes that model and makes decisions about how the model should be presented to the user. It also helps manage the interaction between the user and the model.
So, yes, keeping your "data" independent from your "ui" is the right strategy. Always remember, it's the UI's responsibility to determine "how" the data is formatted, the model is just a means to manage the data in some meaningful way.
2- I have 2 GUIs, a welcome GUI and a login GUI, how do I ensure that
one leads to the next? I tried to make the welcome frame invisible(the
login frame is made visible in its own GUI) but that didn't work
This is a little broader in concept. Typically, we might recommend using a CardLayout to "flip" between views, but this would assume you want to revisit those views at some point.
On a more "abstract" point of view, you would use some kind of "controller" to make decisions about what should happen based on the current state.
This means, if "welcome" has not been presented, you'd present the "welcome" view. When the user is ready to move beyond it, "welcome" would notify the "controller" and the controller would then decide what to do next.
ie. Do you have previously saved credentials or not? If so, you could auto login the user and move on, otherwise you'd need to present the "login" view in order to get the credentials and allow the controller(s) to authenticate the user.
This moves you onto the "observer pattern" (aka listeners), where an interest party registers interest in been notified when some state has changed.
When trying to design these kind of systems, always be asking yourself some basic questions
Just how much do I need to expose to other parts of the program? ie You're welcome view doesn't need to know about the login view, as it could do things to the login view which are out side of it's scope of responsibility
How hard or how much work would I need to do to change any part of it?! So you get the welcome screen to open the login screen, but now you want to add in "auto login", just how much work are you going to have to go to make that work? Would it have been easier if the welcome and login views were independent of each other and controlled through some other mechanism?
Take a look at Java and GUI - Where do ActionListeners belong according to MVC pattern? for simple implementation example
Related
How do I get the same name after a successful login?
I have user class that set user.setName after verifying the user name and password from text file in login JFrame and user.getName in other frame to greet user in the main menu.
There's lots of different ways to do it, but basically it boils down to Passing Information to a Method or a Constructor.
One thing you should do is to try and decouple the process. Your "main menu" doesn't care where or how the user name is generated/gained, it only needs it. Equally, your login process doesn't care what happens after the user is validated.
To that end, you should take the time to understand the model-view-controller paradigm, you will see it a lot and will help you solve similar questions.
Basically, a "controller" will display the login view, the login view will gather the credentials and the this information will be feed back through the model for validation. When successful, the controller can pass control on to the next controller which will actually display the "main menu", providing the login model as part of the information.
Again the "how" depends a lot on the overall solution, but you want to get to the point where you have the ability to change either or both the main menu and login windows and it won't have any affect on the other
You can also have a look at:
Open JFrame, only after successfull login verification with database. Using Eclipse?
Java and GUI - Where do ActionListeners belong according to MVC pattern?
Open a JPanel after pressing a button in a JFrame
for more details and ideas
I'm currently building an application that will require many different 'states' e.g. A screen for a user to log-in, a welcome page etc.
I want to design this application with MVC in mind but being somewhat of a newbie when it comes to MVC so I'm not sure what the best way to handle the multiple states would be.
What I have done in the past is use one big controller which changes the content of a JFrame, for example the user would click a button on a particular view (which is just a JPanel with various components), which would notify the controller and if necessary the controller would switch the current JPanel on the JFrame. E.g. the user clicks the login button and the controller removes the login JPanel and switches it with the welcome page. This of course means that the single controller must keep instances of these different views and the single controller eventually becomes very large due to interacting with all the different views.
So my question is how can I implement something similar to what I described above but with a greater separation of concerns?
P.S I've looked into using Card layout but I don't feel it provides enough separation when building a large application.
I have an application that is a Maths Game for kids. Since I'm in college, I've usually only had a god object for all my past projects but for this applciation I've split my code into multiple classes:
MathsGame.java: main class which initialises components and constructs and controls the UI.
DiffScreen.java: contains methods for use on the difficulty selection screen.
GameScreen.java: contains methods for use on the game screen.
EndGameScreen.java: contains methods for use on the end game screen.
MigJPanel.java: extends JPanel and sets layout to MigLayout and adds a matte border.
Each screen that the 3 XScreen classes control is simply an instance of MigJPanel and screens are switched to using a CardPanel container JPanel.
I'm wondering how I can divide my code to each class so that they are properly abstracted but I'm not entirely sure how to approach this.
Should my 3 screen classes be extending from my MigJPanel so these then can be instantiated?
So instead of having my DiffScreen, GameScreen, and EndGameScreen classes solely containing methods related to each screen which are then called from MathsGame, each screen will control itself within its own class.
If yes to the previous question, should the UI components for each screen be made inside that screen's class?
At the moment, all components for each of the three screens are created in my MathsGame constructor. This makes the connection between a screen and the class which 'controls' (I use this word very lightly at the moment) it even further apart. So each screen is just an instance of MigJPanel whose components are constructed in MathsGame. The only relation the EndGameScreen class—for example—has to the End Game screen is that when the MathsGame causes the End Game Screen to be displayed, anything done there makes a method in EndGameScreen be called from MathsGame.
I hope I explained myself well. If not, leave a comment and I'll clarify. Any help would be greatly appreciated!
Yes
Yes.
Focus on self containment and maintain areas of responsibility. It is the responsibility of each UI screen to manage it's content, no one else, in fact, you should guard against allowing unrestricted modification to these components and provide access only through managed methods indirectly (setters and getters), which allow the modification of the properties you want to be changed, and not simply providing the component via a getter, this prevents problems with people removing components you don't want removed, for example.
You could also use interfaces to maintain common functionality if required, so if the MathsGame really only wants to deal with a certain amount of the information/functionality, you can use an interface that all the other screens use which will simplify the process, as the MathsGame only needs to know about the class that implement the interface and not EVERY thing else that might be going on...as a suggestion..
Also, where should I put the code for switching between screens?
From my perspective, it's the responsibility of the MathsGame game to determine when and to which screen should be shown. What I would normally do, is provide some kind of notification process that the current screen can ask the MathsGame to switch screens, maybe via a listener or other agreeded interface. This would mean that each screen would need reference to MathsGame.
Instead of passing it (MathsGame) directly, I'd create an interface that MathsGame would implement (say NavigationController), which defined the calls/contract that each sub screen could use (nextScreen/previousScreen) for example.
Take a look at Model-View-Controller for more ideas
This is my first java swing application and I have some questions about the organization.
I need to create a application that after log in redirect the user to (let's call it) "Normal user page", "Admin Page" or "Super user page". After reading some articles I figured out that java swing applications, use one JFrame and panels to hide or show content (some thing like single page application).
My questions are now:
Do I need to create 4 "main classes" (log in, normal user, admin, super) and each one extends one jframe because they are particularly different applications and this jframes have their own classes (panles), with them I hide/show content on them
OR, Log in is my main Jframe and after log in i show a different panel (normal user, admin or super) in a different window or dialog, and they have their panels to hide show content
When my first questions is right is this a good folder structure:
Folder app: Log in, normal, admin, super user class(frame)
Folder noram user: classes/panels related to him
.
.
.
Thanks in advance :))
Questions/Answers:
Do I need to create 4 "main classes" (log in, normal user, admin, super) and each one extends one jframe because they are particularly different applications and this jframes have their own classes (panles), with them I hide/show content on them
If you're creating a decent Swing GUI, likely none of your classes will extend JFrame, and in fact it is rare that you'll ever want to do this. More commonly your GUI classes will be geared towards creating JPanels, which can then be placed into JFrames or JDialogs, or JTabbedPanes, or swapped via CardLayouts, wherever needed. This will greatly increase the flexibility of your GUI coding.
You will likely have one master View class/JPanel, and could swap its content with other sub-view classes that will correspond to the different states of your non-GUI model class, whether it would be a normal user, admin, or super user.
OR, Log in is my main Jframe and after log in i show a different panel (normal user, admin or super) in a different window or dialog, and they have their panels to hide show content
I usually use a dialog to log in such as a JDialog, and then after verifying credentials, show the main GUI, again with the correct view sub-type based on the state of the model.
When my first questions is right is this a good folder structure:
Folder app: Log in, normal, admin, super user class(frame) Folder noram user: classes/panels related to him . .
Much more important I think is to separate your packages into model, view, control, and main. Then you could use sub-packages for the various sub-portions of your program.
I strongly urge you to read up on Model-View-Control pattern of GUI structure, and then study up on the many useful variants of this.
I have 5 JFrames in my application and I want the values from all 5 JFrames to be sent to a single JFrame. And it is a process where I have to go one frame to another and the value entered previously should not be lost and must be visible at the end of the process.
Easy example is,
I key in my name in the first frame,
then I key in my Address in the second frame,
then my mobile number in the third frame
and so on till the last frame where I want my keyed in details in the previous forms to be in the final frame to display my data in JTextfields. Is this possible? Because if it is a single form, I know how to do it. But when it is multiple forms in this situation I am lost. Please help.
This has nothing to do with Swing or JFrames and all to do with the general issue of getting information from one object into another. Yes it's possible -- give the classes that you wish to extract information from "getter" methods, and then call them when you want the information. If you want to gather this information in an event-dependent fashion, then you will need to have one class listening for state changes brought on by events in the other classes. A PropertyChangeListener can work well for this.
Or if you use modal JDialog windows instead of JFrames, you will always be notified when the dialog has returned and is no longer visible, since the calling code's program flow resumes from right after where it told the dialog to become visible.
Next we can discuss whether having 5 separate JFrames is a good idea or not. I'm guessing you know my opinion on this, else I wouldn't have mentioned the subject.