Trace:
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
jvx:reference [2020/06/24 15:37] cduncan […and why do I need to handle them?] |
jvx:reference [2020/06/24 15:47] (current) cduncan [Fire away!] |
||
|---|---|---|---|
| Line 1765: | Line 1765: | ||
| ===== Terminology ===== | ===== Terminology ===== | ||
| - | For [[https://sourceforge.net/projects/jvx/|JVx]] the following terminology applies: An event is a property of an object, you can register listeners on that event which will get invoked if the event is dispatched (fired). Every event consists of the ''%%EventHandler%%'' which allows to register, remove and manage the listeners and also dispatches the events, meaning invoking the listeners and notifying them that the event occurred. There is no single underlying listener interface. | + | For [[https://sourceforge.net/projects/jvx/|JVx]] the following terminology applies: an event is a property of an object. You can register listeners on that event that will get invoked if the event is dispatched (fired). Every event consists of the ''%%EventHandler%%'', which allows ypi to register, remove, and manage the listeners and also dispatches the events, meaning it invokes the listeners and notifies them that the event occurred. There is no single underlying listener interface. |
| - | Within the [[https://sourceforge.net/projects/jvx/|JVx]] framework, every event-property of an object does start with the prefix “event” to make it easily searchable and identifiable. But enough dry talk, let’s get started. | + | Within the [[https://sourceforge.net/projects/jvx/|JVx]] framework, every event property of an object starts with the prefix “event” to make it easily searchable and identifiable. But enough dry talk, let’s get started. |
| - | ===== Attaching listeners ===== | + | ===== Attaching Listeners ===== |
| We will now look at all the ways on how to attach a listener to an event. | We will now look at all the ways on how to attach a listener to an event. | ||
| Line 1775: | Line 1775: | ||
| ==== Class ==== | ==== Class ==== | ||
| - | The easiest way to get notified of events is to attach a class (which is implementing the listener interface) to an event as listener, like this: | + | The easiest way to get notified of events is to attach a class (that is implementing the listener interface) to an event as listener, like this: |
| <code java> | <code java> | ||
| Line 1800: | Line 1800: | ||
| } | } | ||
| </code> | </code> | ||
| - | ==== Inlined class ==== | + | ==== Inlined Class ==== |
| - | Of course we can inline this listener class: | + | Of course, we can inline this listener class: |
| <code java> | <code java> | ||
| Line 1825: | Line 1825: | ||
| } | } | ||
| </code> | </code> | ||
| - | ==== JVx style ==== | + | ==== JVx Style ==== |
| - | So far, so normal. But in [[https://sourceforge.net/projects/jvx/|JVx]] we have support to attach listeners based on reflection, like this: | + | So far, so good. However, in [[https://sourceforge.net/projects/jvx/|JVx]] we have support to attach listeners based on reflection, like this: |
| <code java> | <code java> | ||
| Line 1849: | Line 1849: | ||
| } | } | ||
| </code> | </code> | ||
| - | What is happening here is that, internally, a listener is created which references the given object and the named method. This allows to easily add and remove listeners from events and keeping the classes clean by allowing to have all related event listeners in one place and without additional class definitions. | + | What is happening here is that, internally, a listener is created that references the given object and the named method. This allows us to easily add and remove listeners from events and keeps the classes clean by allowing us to have all related event listeners in one place without additional class definitions. |
| ==== Lambdas ==== | ==== Lambdas ==== | ||
| - | Yet there is more, we can of course attach [[https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html|lambdas]] to the events as listeners, too: | + | Yet there is more. We can, of course, attach [[https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html|lambdas]] to the events as listeners too: |
| <code java> | <code java> | ||
| Line 1870: | Line 1870: | ||
| } | } | ||
| </code> | </code> | ||
| - | ==== Method references ==== | + | ==== Method References ==== |
| - | And last but not least, thanks to the new capabilities of Java 1.8, we can also use [[https://docs.oracle.com/javase/tutorial/java/javaOO/methodreferences.html|method references]]: | + | Lastly, thanks to the new capabilities of Java 1.8, we can also use [[https://docs.oracle.com/javase/tutorial/java/javaOO/methodreferences.html|method references]]: |
| <code java> | <code java> | ||
| Line 1894: | Line 1894: | ||
| } | } | ||
| </code> | </code> | ||
| - | ===== Parameters or no parameters? To throw or not to throw? ===== | + | ===== Parameters or No Parameters? To Throw or Not to Throw? ===== |
| - | By default we actually support two different classes of listeners, the specified event/listener interface itself, and ''%%javax.rad.util.IRunnable%%''. Which means that you can also attach methods which do not have any parameters, like this: | + | By default we actually support two different classes of listeners, the specified event/listener interface itself and ''%%javax.rad.util.IRunnable%%''. This means you can also attach methods that do not have any parameters, like this: |
| <code java> | <code java> | ||
| Line 1924: | Line 1924: | ||
| } | } | ||
| </code> | </code> | ||
| - | Additionally, all listeners and ''%%IRunnable%%'' itself do support to throw ''%%Throwable%%'', which is then handled inside the ''%%EventHandler%%''. So you are very flexible when it comes to what methods you can attach and use as listeners. | + | Additionally, all listeners and ''%%IRunnable%%'' itself support throwing ''%%Throwable%%'', which is then handled inside the ''%%EventHandler%%''. As you can see, you are very flexible when it comes to what methods you can attach and use as listeners. |
| - | ===== Creating your own events ===== | + | ===== Creating Your Own Events ===== |
| You can, of course, create your own ''%%EventHandler%%''s and listeners to create your own events. All you need are two classes, an extension of EventHandler and a listener interface. | You can, of course, create your own ''%%EventHandler%%''s and listeners to create your own events. All you need are two classes, an extension of EventHandler and a listener interface. | ||
| Line 1954: | Line 1954: | ||
| event.dispatchEvent("Adam"); | event.dispatchEvent("Adam"); | ||
| </code> | </code> | ||
| - | ===== More methods! ===== | + | ===== Additional Methods ===== |
| - | You can also use an interface for listeners which has multiple methods, specifying in the constructor which method to invoke: | + | You can also use an interface for listeners that has multiple methods, specifying in the constructor which method to invoke: |
| <code java> | <code java> | ||
| Line 1974: | Line 1974: | ||
| } | } | ||
| </code> | </code> | ||
| - | Now every time the event is dispatched, the ''%%somethingOtherHappened%%'' method will be invoked. Anyway, don’t use this. The upside of having a “simple” listener interface with just one method is that it allows to use lambdas with it. A listener interface with multiple methods won’t allow this. | + | Now every time the event is dispatched, the ''%%somethingOtherHappened%%'' method will be invoked. However, don’t use this. The upside of having a “simple” listener interface with just one method is that it allows us to use lambdas with it. A listener interface with multiple methods won’t allow this. |
| In [[https://sourceforge.net/projects/jvx/|JVx]] [[http://blog.sibvisions.com/2015/01/28/jvx-and-java-8-events-and-lambdas/|we reduced our listener interfaces to just one method (in a backward compatible way)]] to make sure all events can be used with lambdas. | In [[https://sourceforge.net/projects/jvx/|JVx]] [[http://blog.sibvisions.com/2015/01/28/jvx-and-java-8-events-and-lambdas/|we reduced our listener interfaces to just one method (in a backward compatible way)]] to make sure all events can be used with lambdas. | ||
| - | ===== Fire away! ===== | + | ===== Fire Away! ===== |
| - | That’s it for this short reference sheet, that is how our event system can and should be used. Of course, there is much more to it under the hood, for example listeners being wrapped in proxy classes, reflection used for invoking methods and some more stuff. If you feel adventurous, be my guest and have a good look at the internals of ''%%EventHandler%%'', it is quite an interesting read. | + | That’s it for this short reference sheet. This is how our event system can and should be used. Of course, there is much more to it under the hood (for example, listeners being wrapped in proxy classes, reflection used for invoking methods, etc.). If you feel adventurous, be my guest and have a good look at the internals of ''%%EventHandler%%''. It is quite an interesting read! |