Is there a forum for Java GUI Application Design?
Hi all,
I've used this forum a lot and found a lot of help on it for Swing usage specifics. However, whenever I ask a question about broader design or architecture of a full Swing app I get little or no response.Sadly I'm no stranger to "view 50, replies 0":o(
Either I'm asking stupid questions or I'm asking the in the wrong forum - does anyone know of a good place to ask about design/best practices for Java, GUI applications? I've seen some of the "programmer"/"developer" groups on Google Groups.
Many thanks.
Yours, hoping for at least one reply,
Chris
don't know of a forum, but this book might be worth a look http://www.amazon.com/gp/product/0471486965/sr=1-1/qid=1156361300/ref=sr_1_1/104-3520632-1054356?ie=UTF8&s=books
Thanks Michael.
I will take a look at the book.
What I'm after is examples/discussions of how to structure the underlying models for a multi-panel, mulit-window type application. More specifically I'm keen to here how others handle communication between different parts of the model and how this gets reflected back in the UI.
Essentially I think I have a lot of dumb questions that need to be shot down with "You don't want to do it like that - you do it like this" from folk who've been through the process.
> More specifically I'm
> keen to here how others handle communication between
> different parts of the model and how this gets
> reflected back in the UI.
I'm sure there's more than one way, but this works well for us. We have a class called DataChangeControl that is notified whenever an object gets updated, and it notifies everyone who is interested in this change. It has a public static method called addDataChangeListener (DataChangeListener listener, DataChangeType type, Object obj). DataChangeListener is an interface with the methods dataAdded, dataChanged, and dataRemoved. DataChangeType is an Enum that specifies what kind of object was changed, and obj carries a reference to the object that was changed. Any UI window that needs to know when something was changed by a different UI window can register itself as a DataChangeListener, and any UI frame that changes an object must inform the DataChangeControl about the change by calling DataChangeControl.dataAdded, dataChanged, or dataRemoved. So the DataChangeControl is told when a objects get updated, and it notifies all the registered listeners so their views stay current.
Thanks very much for this detailed description, it's very informative and just what I was after.
I am a little confused by you method signature for the addDataChangeListener().
addDataChangeListener (DataChangeListener listener, DataChangeType type, Object obj).
Are the params
DataChangeType type, Object obj
really in this method or are they paramters to the methods inside DataChangeListener?
i.e.
Interface DataChangeListener
dataAdded( DataChangeType type, Object obj )
dataChanged( DataChangeType type, Object obj )
dataRemoved( DataChangeType type, Object obj )
That would seem to make more sense to me but I could have missed something along the way.
Thanks again
You're right, I typed that wrong. The method signature should be addDataChangeListener(DataChangeListener lis, DataChangeType type)
When a component registers itself as a change listener, say it wants to know whenever an object of type Foo is changed, it calls DataChangeType.addDataChangeListener(this, DataChangeType.FOO). (the Enum elements coorespond to the objects we want to listen for) Then it implements the dataChanged(DataChangeType type, Object obj) method that will be called by the controller when objects of type Foo are changed. (obviously this is an interface) Whenever a component updates an object of type Foo, it calls DataChangeControl.dataChanged(DataChangeType.FOO, theFooObject), and then the controller will notify all listeners who are interested in Foo objects changing.
The DataChangeControl maintains a hashmap of <DataChangeType, List >< DataChangeListener> >. So when a new listener is added, it checks the type to see if a list is already keyed to that object type in the hashmap. If so it adds the listener to that list, if not it creates a new list in the hashmap with the type as the key. That way when an object is changed, it notifies only those listeners who are registered to listen to that type of object being changed. Hopefully that makes sense.
Oh I see. I get it.
This is really useful thanks very much for all this detail.
Many thanks.
Just out of curiosity, what happens when a UI view (or rather it's underlying model) wants to be informed of more than one type of event? Does it get multiple DataChanged() events? I assume so if it's in more than one List in the HashMap.
> Just out of curiosity, what happens when a UI view
> (or rather it's underlying model) wants to be
> informed of more than one type of event? Does it get
> multiple DataChanged() events?
Yes, the view needs to register itself once for each type of object it wants to know about. It gets an event for each object that's changed.
> Oh I see. I get it.
>
> This is really useful thanks very much for all this
> detail.
>
> Many thanks.
You're very welcome. =)
