Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Separate GUI Code from Back End Code

 
John Storta Jr.
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1561
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


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
Posts: 1561
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic