I have four classes flight, passenger, seating chart, and waiting list. I'm trying to create a gui. I am new to swing so I dont know how it is done. should I create a separate class for a gui and build all the gui there or should I incorporate my gui code in those already existing classes? how is it implemented if there is a general guideline?
The classes that you mention are model classes; they are used to abstract the data of your system. You should never put your presentation [GUI] code in model classes. You must have separate classes/code for your presentation[GUI].
The general guideline is that :
Separate Presentation, Controller and
Model code into different classes. Use
the model-view-controller design
pattern for your system.
In all programming languages is nice to separate UI and code. It's better to understand and keeps you code clean.
Related
I am relatively new in Java. In one of my project I have three jframes. They are Menuframe,that has list of menus; LoadDatafromExcelframe, that is use to select and read data from Excel file; and ShowDataFrame, that is use to display data that I read in LoadDatafromExcelframe. Actually its part of a big project. not the whole project! At the beginning of my project I am reading Excel file and load all the data in arraylist. Till this point I am good. Now I want to click the ShowDataFrame from the menulist to display the data that I have read in the LoadDatafromExcelframe. If I can access the arraylist then I think I can move forward. My question is "How can I access arraylist from one jframe (ShowDataFrame) to another frame(LoadDatafromExcelframe)?"I am using Netbeans IDE.
private void jMenuItemShowDataActionPerformed(java.awt.event.ActionEvent evt) {
showDataFrame.setVisible(true);
}
The key issue has little to do with JFrames or Swing in fact, but is simply one of passing information from one object to another. The only way Swing gets involved is if you want to pass this information in response to an event of one sort or another.
The solution is usually one of simply giving your classes appropriate getter and setter methods, of separating out your "model", the logical portion of your program, from your "view", the GUI portion of your program, and of using some sort of listener or observer type interface (such as can be obtained via Swing event listeners) to notify one class when the other is ready to push or pull information.
More general recommendations:
Avoid making anything static that does not need to be static. That is a quick solution that usually causes more pain in the long run as it makes your code very hard to enhance later and to test.
Avoid using lots of JFrames. Most professional GUI's have but one master window, one "JFrame" if you will. Often it is better to swap views in this JFrame such as with a CardLayout or with tabbed panes if needed. Also information that needs to be obtained in another window in a modal fashion can be displayed in a modal dialog.
Get a good book on OOPs basics as it applies to Java programming, such as Bruce Eckel's "Thinking in Java".
And get a good book on use of design patterns with Java such as Head First Design Patterns. These two concepts are key to moving ahead in Java.
Avoid using code generation utilities such as NetBean's form creation utility as it shields you from learning Swing specifics, and hinders your ability to learn to create complex Swing GUI's. Sure, use these tools once your a Swing journeyman, but until then, use the Swing tutorials to learn the library and code by hand.
For more specific advice, you will need to provide more details and provide more code.
Edit 2
More advice based on your post:
In one of my project I have three jframes. They are Menuframe,that has list of menus; LoadDatafromExcelframe, that is use to select and read data from Excel file; and ShowDataFrame, that is use to display data that I read in LoadDatafromExcelframe.
This looks to be better implemented creating 3 JPanels and not 3 JFrames. Then you could display the JPanels as needed in a single JFrame using a CardLayout to help you swap them.
Actually its part of a big project. not the whole project! At the beginning of my project I am reading Excel file and load all the data in arraylist.
This ArrayList should not be "read into a JFrame" but rather the data belongs in a non-GUI class, one of your "model" classes to be exact. Then the view classes, your GUI code can ask the model for this data whenever necessary. Read up on Model-View-Control program design on this site to learn more about this useful pattern.
Till this point I am good. Now I want to click the ShowDataFrame from the menulist to display the data that I have read in the LoadDatafromExcelframe.
Here using MVC structure, one of your "view" classes, the one holding the "menulist" should notify the "control" class that your code needs the ArrayList data held by the "model" class. This could all be done by having the Control class hold references to both "model" and "view" and having the "view" class hold references to the control thus allowing communication between classes.
You can change your ArrayList in static an public in the properties of the object then just call the name of te class who contains de ArrayList and call the ArrayList and use it wherever you want.
Something like this:
JFrame1.ArrayList1.add("some stuff");
Obviously doing this in the JFrame2 class where you want to call the ArrayList
I was taught UML early on in university but all the examples were always with simple console applications. Now that I have been assigned to develop a project with a graphical interface (using Java) and was required to submit a UML model, I haven't got a clue how to go about representing the graphical frontend aspect of the application in tandem with the non graphical backend classes. I'm not quite sure where to even start.
How would you suggest I go about doing this?
Usually UI modeling involves 3 things:
How the UI looks like: this is not usually done in UML. You need a tool like Visio or Pencil to do that.
How the UI is structured: This considers how the UI is structured into classes. How these classes are related to each other (dependencies, navigation, ...). How they are related to domain classes. How they are related to the Use Cases (which ones they implement). This fits naturally in UML structural diagrams: class diagram, package diagram, component diagram, ...
How the UI behaves in runtime: How certain actions cause objects to be created and methods to be called to perform the desired actions. This fits naturally in UML behavioral diagrams : sequence diagram, communication/collaboration diagram, activity diagram.
So basically in your UML model, UI classes (Screens, Applets, Pages, ...) will appear like normal classes. This will allow UI structure and behavior to fit in your application view models.
Note that there are tools that make use of UML profiles to provide UI mocking as alternative to graphical tools like Visio. In this custom profile you may find for example stereotyped class called << screen >> and stereotyped dependency called << navigation >> to model how UI elements trigger UI navigation to other screens.
I think you need to start by asking what you want to model and then that leads to you work out whether UML is useful and if so, which parts. Start by asking who is going to use this model and for what. Model with a purpose.
If you want to model the class structure of your application, then a UML class model might be useful. But even then, are you trying to illustrate the UI classes or the information (domain) structure, or both?
If you are trying to show how the runtime interactions work, then a sequence diagram might be useful.
If it is modularisation of code and dependencies between modules, a package diagram would do this.
If you have a complex user interface program with a sophisticated component structure which you want to explain, then it's no different to server software and a component diagram would be useful.
Whenever creating a model ask why you are doing it, for whom and what they want from it. That leads you to select something useful rather than just doing "busy work".
Asides from the previous answers, a common design for UI is one of model-view-controller (MVC). Some UML tools actually have stereotypes to help you with representing these elements. The model is the data that you want to show, the view is how it is displayed, and the controller links the two, taking the input to the UI and processing it to change the display with the new data from the model.
It is also easy and useful to create sequence diagrams for a MVC system to show the actions and their effects.
I need to create a Playlist, I want to separate code/logic and GUI by using two classes:
Playlist (code/logic)
PlaylistGui (GUI)
It shall be possible to use the Playlist class standalone, e.g. in some kind of command line environment. The question now is, how would one plug both classes together, when using a GUI? My ideas until now:
Expose an observable list from the Playlist class, create a method setItemSource(Playlist source) on the PlaylistGui class
Not sure if possible in Java, just know this from .NET: Let Playlist class fire events and let PlaylistGui catch them, should lead to uncoupled code? :-)
Open for new ideas :-) Note I am using Java 7 and JavaFX, though I guess JavaFX doesn't limit possiblities, just extends them.
Events in Java:
http://castever.wordpress.com/2008/07/31/how-to-create-your-own-events-in-java/
Other alternatives are:
Java Delegates?
or both as separate processes with communication via sockets
Have a look at FXML, Controllers and the SceneBuilder tool.
I think your basic concept is sound, delegation of responsibility.
I would create an interface of the model, exposing only those methods you think that any basic controller/viewer would want. This means you can change the implementation without effecting any of the components that rely on it.
Listeners are, essentially, just a call back mechanism, where interested parties register themselves (through a common interface) to be notified when something occurs that they are interested.
Take a look at Writing Event Listeners for more information.
I would basic start out with a common library which defines the basic interfaces that all parties would need to know out (such as the PlayList and listeners).
This would allow to design 'n' implementations of the playlist based on your needs
I have a class which extends JFrame and forms the GUI of my program. I want to use the GUI for two main purposes:
I want the user to be able to input values to the program.
I want the GUI to display values created by my program.
Considering my class has a lot of GUI elements, the source file is already rather large and It does not seem like good practice to bundle all the program code in with the GUI code. I'm wondering what is the best way to structure my code? I believe there is an issue where requirement 1 creates a dependency from the GUI to the program code, and the second requirement does the opposite.
So, I want one class for my GUI which contains all my GUI related tasks. I then want another class for my program logic. I should then be able to call methods from the program logic class from the GUI and vice versa.
Sounds like you are looking for a textbook MVC (Model-View-Controller) design pattern. I recommend you google "MVC Design Pattern" for summaries and use cases. That being said, you might want to put your program logic into a "Singleton" class (again, google "Singleton Design Pattern"). A properly implemented Singleton should be accessible from any other class in your code.
Consider also a third middle class which acts solely for data storage, you put values into it for storage, and you fetch values from it for work. This now creates 3 clear segments for your code, the Data (the Model), the GUI (the View), and the logic (the Controller). Voila, you've just implemented the MVC (Model-View-Controller) design pattern...
The business logic should not depend on the GUI logic.
Have your GUI take inputs from the user. Call business logic methods with these inputs as method arguments, and use the values returned by the methods to display the result in the GUI. The GUI thus depends on the business logic, but the reverse is not true.
If the business logic must callback the GUI, it should do so via well-defined GUI-agnostic callback interfaces, or listeners. For example, you could register a ProgressListener on some business logic object, and this object would call back the progress listener. The GUI would have an implementation of the ProgressListener which would in fact update some progress bar or text area. But the business logic only depends on the interface, and not on the specific implementation.
I'm not sure there is one "best" way to structure GUI code. As a general rule though, you should follow MVC. Your program (Model) should never directly depend on your View code. What it's allowed to do is notify the controller that the model (or parts thereof) changed, and that whichever views are currently displaying said part of the model should be updated.
Swing already provides this abstraction layer for some of its types of component, most of the classes are (somewhat confusingly) suffixed with Model. A simple example you could look at would be BoundedRangeModel. There should be only one instance of such a Model for every "unit" of data your program manages, and different views displaying this data should share this instance. Your business code manages this object, and whenever this piece of data changes, the GUI is notified using it by firing off some event listeners.
if i have a class gui and a class for the logic, is holding a reference in gui to logic and logic to gui very bad?
As a general rule it is bad to have the "logic" class having knowledge of the "gui" class. The idea behind the separation is the Model/View design pattern (or Model/View/Controller). The view will need a reference to the model. Look really closely at why the model needs a reference to the view. Usually when the model needs to send information to the view event listeners are used (see javax.swing table and list models for an example).
It should be avoided.
In your GUI, you can have a reference to your Domain Logic, but you should not have a reference to your GUI in your domain logic.
Why ?
Because otherwise, you have no advantage of splitting GUI & Domain logic up in separate files. When your Logic has a dependency to your GUI, then you cannot use your Logic with another GUI.
So, you should try to avoid this dependency from your logic to your gui, or, you should make abstraction of it.
I hope i'm making myself clear here. :)
If you can avoid it, you probably should. Otherwise you might get into a lot of problems with circular dependencies later.
Do they really have to know about each other, or could you have a third "control" concept referencing the two?
The GUI probably needs to expose some kind of interface to the logic class, to have the GUI update when the logic class changes something.
The logic should not have direct knowledge of the the GUI implementation, only its interface.
The Observer Pattern is sometimes used for this.