• Post Reply Bookmark Topic Watch Topic
  • New Topic

Synchronized display of volatile data.

 
Schuyler Goting
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is there a good (read: efficient && simple) way to set up variable monitoring?
As in, consider a situation where you have a single variable (or set of variables), and each one can be updated by multiple sources. As an example, lets say we have a currentlySelectedObject, which can be updated by clicking on the object on the screen, clicking the "next" button, hitting "tab," or turning "scan" mode on, and having a timer change the selected object every second. Future upgrades to the system plan on having other, currently unknown ways to select objects.
Now, let's say you have multiple monitoring objects which always want to know what's selected, but how many, or even what they are, you can't say before hand. (they will be added and removed as some higher power sees fit) -- first, the JTextArea description of the selected object. Second, the TTextField name of the selected object. Third, a locator in another component that needs to know the position of the selected object. As well as many other objects asking for different information bout the object. This gets especially severe when objects both update the selected object AND want to know about it, as it can easily get into infinite loops.
Now, what would be great is to do one of the following:
1. Set up an "event" system, such that every time any value in the currentlySelectedObject changed, an event was sent out to everyone who registered as a listener. -- Is this possible? What's a good way to set it up? I can think of some hacks that would manage a similar idea, but they feel inefficient and silly to me.
2. Set up the same event system type of thing, but instead of listening to the entire object, which would result in thousands of events being called informing the "object name" JTextField that the object's position had changed, which it wouldn't care about, you could listen to certain fields. Is this the same as before, only requiring one listener/etc deal for each field, which would also require seperate classes for each event type?
As it is in my current system, each object that changes the selectedObject values needs to call its own setValue function (setValueFromSelector(), setValueFromClick(), etc...), to avoid the looping. (it's not actually set up exactly like that, but you get the idea.)
What's a standard way of dealing with this kind of thing? Is it a common problem? Does it have a good solution?
Thanks.
--Sky.
[ August 07, 2003: Message edited by: Schuyler Goting ]
 
Nathan Pruett
Bartender
Posts: 4121
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For the events I would use PropertyChangeEvents, since it is really generic and easily does what you want. (i.e. some objects register with the whole object, some only register for specific changes) Here is a tutorial on how to use PropertyChangeEvents.

For the other problem of having a "currently selected object" that may be changed, or that might have multiple selections. You don't want to have every listener register and de-register as listeners every time this changes. I would use some kind of delegation. Make a class that sits between the listeners and the "selectable" objects. We'll call it the SelectableManager. When selectable objects become "selected" they register with the SelectableMananger, and as part of this the SelectableManager becomes a PropertyChangeListener for the selectable object and adds the selectable object to an internal Vector or ArrayList. In addition the listener classes only register with the SelectableManager, not each selectable object. When a new selectable object gets selected and added to the SelectionManager the SelectionManager throws a PropertyChangeEvent stating that a new selectable was added. Now come the delegation part. When a selectable object registered with the SelectionManager throws a PropertyChangeEvent, the SelectionManager gets it because it is registered as a PropertyChangeListener on the selectable object. Then the SelectionManager turns around and sends this same PropertyChangeEvent to all the listeners that have registered with it. This way listeners get PropertyChangeEvents from only the "selected" objects, and don't have to worry about changing who they're listening to all the time. They just register with the SelectionManager and he takes care of it.

I think this is a pretty good description in words of the design that will help you, but if you need some code or some further explanation of this, just post back.
 
Schuyler Goting
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, that was everything I needed. Thank you very much.
--Sky.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!