Java - Performing Large Graphic Projects

To get right right to my question.

How do you carry out large-scale graphic projects. I have not done any major GUI projects in Java yet, but what I'm working on has become pretty fast and pretty big, and now I'm stuck in a huge pile of code that is really annoying and confusing.

Since I came from the field of web development, I use the framework of MVC, so I have 3 packages in my projects. A model where I store classes that interact with whit or db files. Views where I store my classes for forms or GUI and Controller packages where I save most of my logic.

I was told to separate my logic, as well as keep actions in one class and listeners in another class, but I have no idea how to relate all this.

So far, I have only 1 controller class, where I execute all the methods regarding what happens in the GUI after it is called.

package pft.controller; import java.io.IOException; import java.util.logging.Level; import java.util.logging.Logger; import javax.swing.JLabel; import javax.swing.JComboBox; import javax.swing.JTree; import java.awt.event.*; import javax.swing.JProgressBar; import pft.view.Invoke_GUI; import pft.model.Events; import pft.model.Parse; public class Tower_Controller { public Tower_Controller() { } //Global variables String isSelected = null; int hasModules = 0; int cap = 0; int cpu = 0; int shield = 0; int armor = 0; public void setName(String name){ this.isSelected = name; } public String getName(){ return this.isSelected; } public void setCap(int cap){ this.cap = cap; } public int getCap(){ return this.cap; } public void setCpu(int cpu){ this.cpu = cpu; } public int getCpu(){ return this.cpu; } public void setShield(int shield){ this.shield = shield; } public int getShield(){ return this.shield; } public void setArmor(int armor){ this.armor = armor; } public int getArmor(){ return this.armor; } public void invoke() throws IOException { Invoke_GUI runnable = new Invoke_GUI(); final JLabel tower_name = runnable.tower_name; final JComboBox tower_select = runnable.tower_select; final JTree module_browser = runnable.module_browser; final JTree selected_modules = runnable.selected_modules; final JProgressBar cap_bar = runnable.cap_bar; final JProgressBar cpu_bar = runnable.cpu_bar; final JLabel em_res = runnable.em; final JLabel th_res = runnable.thermic; final JLabel ki_res = runnable.kinetic; final JLabel ex_res = runnable.explosive; setTowerName(tower_name, tower_select); removeTower(tower_name); runnable.setVisible(true); } public void removeTower(final JLabel tower_name) { tower_name.addMouseListener(new MouseListener() { @Override public void mouseClicked(MouseEvent e) { if (hasModules == 1 & isSelected != null) { Events evt = new Events(); evt.towerHasModules(); } else if (isSelected == null) { } else { tower_name.setText("No Control Tower selected"); isSelected = null; } } @Override public void mousePressed(MouseEvent e) { } @Override public void mouseReleased(MouseEvent e) { } @Override public void mouseEntered(MouseEvent e) { } @Override public void mouseExited(MouseEvent e) { } }); } public void updateVariables(String name) throws IOException{ Parse tower = new Parse(); String data[] = tower.towerData(name); Integer x = Integer.valueOf(data[1]).intValue(); setCap(x); } public void setTowerName(final JLabel tower_name, final JComboBox tower_select) { tower_select.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { if (isSelected != null) { Events evt = new Events(); evt.towerSelected(isSelected); } else { tower_name.setText(tower_select.getSelectedItem().toString()); setName(tower_name.toString()); try { updateVariables(tower_name.toString()); } catch (IOException ex) { Logger.getLogger(Tower_Controller.class.getName()).log(Level.SEVERE, null, ex); } } } }); } } 

There are many tutorials and examples on how to make a small, usually one Java GUI class, but there are no tutorials or examples on how to execute projects that are more than one class.

Thanks in advance for your help and advice.

+8
java user-interface swing
source share
3 answers

Here is my advice for developing Swing as a whole. It discusses the importance of using controllers to overcome the needs of model presentation and interaction.

GUI Guidelines for Swings

Project Last Swing. I created an MVC structure that used Spring to determine the program model and controllers, and then used annotations in the controller to connect events sent by the view to the controller methods. The view had access to the event manager, which was the event bus, and events sent over the bus, called methods on the controller, via annotations. This allowed any controller to respond to events from the view. Since the controller became too large, it was very easy to reorganize each set of methods into a different controller, and the view or model should not have changed.

The beauty of the event bus could be divided into a model, so the model could send asynchronous events, which the Controller could register as well. It looked something like this:

 public class SomeController { private AuthenticationModel authenticationModel; private LoginService loginService; private MyApp view; @Listener( event = "login" ) public void login( LoginEvent event ) { view.showWaitDialog(); loginService.login( event.getUserName(), event.getPassword() ) .onResult( new Callback<User>() { public void onResult( User user ) { authenticationModel.setUser( user ); view.hideWaitDialog(); view.showStartScreen(user); } }); } } 

Once this structure was in place, it was amazing how fast we could do everything. And that was pretty good, since we added features. I made my share of the major Swing projects (3 to date), and this architecture was of great importance.

+6
source share

The easiest way to scale the GUI is to make everything loosely coupled. Events (Swing and your own) are the best way to do this. If a class does not create or demonstrate a GUI element, it should not know or care about anything else in the user interface.

The controller must continue to do what it should do - trigger events in response to other events. But these events should be application level events, determined by the needs of your application. The controller should not directly manipulate GUI elements. Instead, you should create components (perhaps just subclasses of JWhatever) that register with the controller as being interested in events.

For example, create the TowerEventListener interface using the nameChanged() function. The controller also has a changeTowerName() function, which, when called, updates the model (Tower class), then calls nameChanged() for all registered TowerEventListeners .

Then create a TowerRenamer class, for example, subclasses of JDialog (i.e. a popup) that includes a text box and an OK button along with a link to the controller. When the user clicks OK, Controller.changeTowerName() called. Other parts of your GUI that register as TowerEventListeners will receive the event and update as necessary (possibly by updating JLabel in the user interface).

Please note: if your needs are simple enough, you can simply use PropertyChangeEvents and not worry about the interface structure of the entire event. PropertyChangeSupport can be used by the controller to notify about events.

+3
source share

In addition to the great advice already provided, I would recommend reading some of Trygve Reenskaug wrote and / or written on the MVC page . He was there during the development of this architectural style in the late 70s. His two-page technical report entitled Models - Views - Controllers of December 1979 provides the most concise description of the model, view, and controller.

It should be especially noted that representations are both observers and model manipulators. The controller is primarily involved in organizing (connecting) views and translating user input into interaction with the model. Some MVC infrastructures have a controller that passes data from the model to the view - this is simply wrong. In a document published earlier in 1979, the concept of an editor was included as part of interconnected views. The editor was dropped; its functionality has been moved to both the controller and the view.

Another article that describes well how to apply this guide, Burbeck How to use Model-View-Controller . It is written using Smalltalk, so it cannot be easily translated into Java, but this is a good description of how to apply the manual.

I think that the most important thing is to take into account that the original MVC style was created for user interfaces that included more than one view (s) of the same model. This works really well for user interfaces, but it doesn't translate very well into the world of web services. Using MVC for a graphical interface allows you to really see and understand the power of this style.

+2
source share

All Articles