This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Swing / AWT / SWT and the fly likes Separate GUI Code from Back End Code Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Separate GUI Code from Back End Code" Watch "Separate GUI Code from Back End Code" New topic
Author

Separate GUI Code from Back End Code

John Storta Jr.
Greenhorn

Joined: Jul 26, 2009
Posts: 29
I am pretty new to Swing development and I am running into a problem getting my head around something.

I can write the GUI interface just fine. I can create the action listeners and have the app do what I want. I can even use SwingWorker to run some processing in the background and update the Swing fields as it progresses using the publish and process methods.

The problem I am having is that I do not like having my processing code within the GUI class. I want to try and keep them separate.

Here is a stream-lined example of what I am doing now.



This code borrows heavily from the example in the Sun Tutorial regarding SwingWorker.

The app works fine and does what I am trying to do, but I do not like embedding all of that back end code (StopWatch & StopWatchTask) within the Swing class. I would like to be able to have my extended JFrame class simply draw the interface and manage the events, but place the actual code for the StopWatch in a separate .java files. Separate the Model from the View and Controller and all that.

I did some reading on PropertyChangeListeners and setting up beans to fire PropertyChangeEvents, but I have not been able to make it work. I am willing to proceed down that road, but I wanted to see if this is truly the best option for accomplishing what I want to do. This seems like something that would be fairly common and would have an easier solution.

Just looking for some guidance.

Thanks,
John S.
pete stein
Bartender

Joined: Feb 23, 2007
Posts: 1561
You have set before you an admirable task, one that I'm trying to learn how to do myself. At this stage what I usually do as a first iteration is separate the model out into its own class, fix errors, and try to add interfaces. Something like this as a first approximation:








John Storta Jr.
Greenhorn

Joined: Jul 26, 2009
Posts: 29


That was exactly what I was looking for. Interfaces are one of those things that I tend to not think of, but they come in so handy. I had toyed with the idea of having StopWatchTask take a JFrame as a constructor argument, but still thought it was too connected to the GUI. It never even crossed my mind to use an interface as the argument so that it can be associated with any sort of display class.

I must learn to use interfaces more effectively.

Thank you so much for taking the time to get me on the right track.


John S.
pete stein
Bartender

Joined: Feb 23, 2007
Posts: 1561
You're welcome.

OK, here's my next iteration where I try to extract the control out of the view. I'm not so sure about whether this is the correct way to do this or not, so please take it with a grain of salt. Corrections and comments are most welcome!

StopwMain.java


TimerViewable.java


StopwView.java


StopwControl.java


StopWatchTask.java


StopWatch

John Storta Jr.
Greenhorn

Joined: Jul 26, 2009
Posts: 29
I cannot say if it is 'correct', but I like it. It separates everything out nicely and keeps each class down to a manageable length. Each class then has a very specific function.

The only minor part that took me a couple reads to get my head around was this part in the StopwMain class.

It seemed cumbersome to declare the view and controller and then have to assign the view to the controller and use two controller methods to configure the view. It is nice having them split out, but at the same time the two classes are so dependent on each other, it results in this kind of required information exchange. I suppose that is the big issue with MVC coding. Trying to separate everything without obfuscating it too much.

Though I blame my slow-moving brain cells more than the code itself for the time it took me to grasp that piece.

I need to read up on Action and AbstractAction. I like that approach better than defining ActionPerformed with an endless if...else construct.

Thanks,
John S.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Separate GUI Code from Back End Code
 
Similar Threads
Updating GUI properties
throw out-of-memory error
Implementing Comparable Interface with TreeSets
Programming Class
Repainting JPanel