Hey Everybody! I am having a difficult time with the concept of listeners. I can code a listener and it will work properly, but still I don't get it conceptually. Could someone point me to a decent reference that might explain the concept instead of the code? Also, do you know if I can create a listener for a browser window that is not opened via Java code? This is not urgent, but it is driving me bonkers! Thanks, Lisa M.
A listener is an "interested party." It is a contract that says "I care when X happens, so please notify me by calling my XHappened method." A doorbell is a SomebodysAtTheDoorListener. People who want to deliver a package come up and call the doorbellPressed(DoorbellEvent) method. The DoorbellEvent object contains useful info like the time the doorbell was pressed, whether it's the front or back door, etc. A telephone ringer is a SomebodyWantsToTalkToYouListener. You register this listener with the phone company by plugging it in -- you're calling addSomebodyWantsToTalkToYouListener() on the phone network. When somebody wants to talk to you, they tell the phone company, and the phone company calls your phoneIsRinging(PhoneEvent) method. The PhoneEvent object contains Caller ID info. Did this help?
I don't know if any of those resources get beyond the mechanics to some of the reasons for having listeners. In some earlier languages like Visual Basic and PowerBuilder you could draw a button on a screen. Then in the development tool click on the button and up comes an editor for code that happens when the user clicks the button. People put hundreds of lines of code in there. Now that code belongs to the button. That turned out to not be a very good place for it, because you might want to do exactly the same thing for a menu selection. Like MS Word has a Save button on the toolbar and a File-Save option on the menu. It was common to see very ugly tricks like the menu code simulates clicking the button. Yuck. Smarter developers put the hundreds of lines of code in another object, and had both the button and the menu call the other object. Write it once, use it twice, much goodness ensues. Listeners take that smarter idea a little further. I can make that other object a listener to both the button and the menu. This is better than adding code to both the button and the menu because the button has no knowledge of or dependency on the listeners. And there simply is no place to put the hundreds of lines of code on the button, clearly signaling that we thought that was a bad idea all along. It is possible to write bad listeners, still. But it is also possible to develop wonderful architectures like Model View Controller that cleanly separate responsibilities, decoupled by listening to messages instead of direct method calls. Hope that was useful!
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
One way to ensure that an object A can "talk" to another object B -- that is, that A can call a method on B -- is to ensure that A has a "handle" on B. That is, A can have B as one of A's attributes; A can be passed B as an argument to one of A's methods; and so forth. By way of analogy, if A and B were people, A would have B's phone number so that A could call B directly. Another way of getting a communication to occur from A to B is to declare B to be a listener to A. Then, when A "talks", its "message" is carried to B -- broadcast, actually, to ALL objects that have registered to listen to A -- by the JVM. By way of analogy, if A and B were people, A would lean out the window and yell something, and only interested parties would listen. Let us know how you are doing!