[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ajug-members]: Sharing data among Swing windows



John,
One final note: If you are planning to use "double check locking" be aware
that it does not work for JDK < 1.5. So if you deploying on 1.4 or 1.3 you
would have to use a variation of the double check locking:
http://www.javaworld.com/javaworld/jw-05-2001/jw-0525-double.html

Two things:
	1. if you singleton resource is used only by the swing thread, the you are
fine. No double check locking is required. However if you singleton is used
by other threads (background workers, renderer or others) then you would
have to used double check locking.
	2. I would not deploy Swing application on 1.3 if I have the choice. 1.4 is
much improved in the swing area.

- stefan

|-----Original Message-----
|From: Burr Sutter [mailto:sutter@bravepoint.com]
|Sent: Monday, May 31, 2004 1:41 PM
|To: ajug-members@ajug.org
|Subject: RE: [ajug-members]: Sharing data among Swing windows
|
|
|You described singleton fairly well.
|Here is a link to an article on that one.
|http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html
|It is very useful for keeping up with "global" data.  I believe it's scope
|is limited to the classloader and you normally use the default one
|making it
|JVM global.  I've not tested it with multiple classloaders.
|
|For constants use static final variables.
|
|For "properties" that can change dynamically at runtime and have an impact
|on other running programs I've used the "observer" pattern.
|Article on that topic:
|http://www.javaworld.com/columns/jw-java-design-patterns-index.shtml
|
|You can combine the singleton and the "subject" (aka event source, message
|generator) of the observer to make changes to global data broadcast to all
|active windows.
|
|I've had user requirements to allow windows to be dynamically linked.
|Something like a customer inquiry screen allows the user to find a specific
|customer record.  Selecting a customer dynamically syncs up with the order
|history and accounts receivable screens running in the background.
|
|Burr
|
|-----Original Message-----
|From: John Wells [mailto:jb@sourceillustrated.com]
|Sent: Monday, May 31, 2004 11:25 AM
|To: ajug-members@ajug.org
|Cc: ajug-members@ajug.org
|Subject: RE: [ajug-members]: Sharing data among Swing windows
|
|Stefan Baramov said:
|> John,
|>
|> You can use Singleton [GoF95] to share global objects. Luckily,
|Swing is a
|> single threaded so you would not need to synchronize your global objects.
|> Another useful pattern is the Madiator [GoF95]. You can read about these
|> patterns in books such as "Patterns in Java" , ISBN 0-471-25839-3
|>
|
|Ah, ok...so let me make sure I follow.  Taking my example, I could create
|a Connector class that implemented the Singleton pattern and would handle
|requests from various Swing windows.  The Connector class would maintain
|one static field that contained a static instantiation of itself and that
|its constructors could check to see if it was already instantiated.  If it
|was, then return a reference to that static field, else, instantiate,
|store a ref in that static field, and then return a reference.
|
|Is that on correct?
|
|What about application contants such as log file name, common directory
|paths, etc.  Would it be best to create an AppConfiguration class (also
|implementing the Singleton pattern), have it abstract out the method by
|which you store the common data (properties file, etc), and have all of
|your other classes (windows) query it for the info?
|
|Thanks for your continued help.
|
|John
|
|