Now I am working on Flex 4 with AS3. In most of time I am using the addEventListener.
This listener default arguments are type:String, listener:Function, useCapture:Boolean = false, priority:int = 0, useWeakReference:Boolean = false. But most of the developers doesn't consider the last 3 arguments. But I want to know the uses of these 3 arguments?
Anyone call tell me answer?
Most of the times those three last parameters aren't necessary, because it's usually better to use a programming pattern to manage dependencies rather than leaving it to hard-to-debug spaghetti code that goes through many other classes.
Yet, there is a purpose for them and they can come in very handy:
useCapture - To register a listener with an event target’s ancestor for the capture phase of an event
dispatch, we set addEventListener( )’s third parameter, useCapture, to true, as in:
theAncestor.addEventListener(myEvent, MyListener, true);
The code causes MyListener( ) to be executed whenever AS3 dispatches myEvent targeted at one of theAncestor’s descendants before that descendant receives notification of the event.
priority - if you add more than one event listener to an object, the one that has higher priority will be triggered first. If you add two or more listeners with same priority, the one that was added first will trigger first. Just imagine that upon creating an object you've added an event listener, but later on you need to add another one and you want that new one to run first. Registering it with higher priority should do the trick.
weakReference - this is not a commonly used one, because Flash's garbage collector can run any time or even never. The problem is that regardless of any use of weak references, an object may continue to dispatch and listen to events until it gets garbage collected.
By default, an object that registers a listener
for a given event maintains a reference to that listener until it is explicitly unregistered
for that event—even when no other references to the listener remain in the program.
By setting the value to true the object will lose the reference to the listener when the object is eligible for garbage collection.
It's used to prevent memory leaks, but useWeakReference only has an effect when the listener object has a shorter lifetime than the dispatcher. It's a good idea to understand how to use it, but in practice I avoid it and simply write a method in my class that would remove all the added listeners.
Related
Usually when dispatching an Event (or custom Event) I use this:
function fireEvent():void {
dispatchEvent(new Event(Event.COMPLETE));
}
Is better use a single object to dispatch an event every time? Can I do this?
var myEvent:Event = new Event(Event.COMPLETE);
function fireEvent():void {
dispatchEvent(myEvent);
}
It would be a way better (eg create event pools) if it works. Unfortunately AS3 does some internal magic with event object during event flow which makes objects only one time usable (Sorry, by some reason I can't find proof quickly).
You can easily get confirmation by dispatching event second time, your listeners will not be triggered (may be it's true only for bubbling feature, not remember exactly), so you have to create a new instance of event object for every dispatchEvent call.
It doesn't worth it even if pooling works, I presume. Creating event objects isn't expensive in astionscript, adding event listeners is. You'd better put this effort on managing listeners and handlers which could easily become the performance buttleneck.
I'm having difficulty with the last piece in the puzzle on AS3 events.
I understand target classes inherit from EventDispatch or implement IEventDispatch and can register (amongst other methods) event listeners.
However what do the target classes register with? If an Event happens, how does AS3 know to pass the Event to the target classes?
Regards,
shwell.
Read this article about event phases and it will make more sense:
http://livedocs.adobe.com/flex/3/html/help.html?content=events_02.html
Hope this helps. Have a great day.
You can look at how starling event works
starling even dispatcher
When a displayObject bubbles an event, it will check if the parent of the displayObject exist and add the parent to bubbleList if exist util the ancestor of displayObject is null.
The following code is in starling eventDispatcher
var element:DisplayObject = this as DisplayObject;
var chain:Vector.<EventDispatcher> = new <EventDispatcher>[element];
while ((element = element.parent) != null)
chain[int(length++)] = element;
In AS3, EventDispatcher is an implementation of the observer design pattern. This class implement the addEventLister, removeEventListener, dispatchEvent' andhasEventListener` methods. Internally, it also maintains a dictionary or similar data structure that contains the events which are currently being listened for, and a list of methods which have to be called when the event is dispatched. Something like this -
{"event1": [method7, method5, method3], "event2": [method3, method2], "event3": [method1]};
When addEventListener is called on an object, it creates a new key for the event in question and adds the method reference to its associated value list.
When dispatchEvent is called on the class, it fetches all the methods associated with the event and calls the methods attached with it. Each method is called with an instance of the Event class or its subclasses.
Removing an event listener obviously does the opposite of what adding does.
I guess you're missing of addEventListener() mechanics. This thing has a global side effect on event engine, registering a callback function along with caller this value to provide correct context of a fired event, with possible update of event.localX and event.localY properties by calling globalToLocal() either statically or dynamically, as the event bubbles up and down.
If you are, like me, confused about how does Flash player determine the target of an event - there is an internal "focus" pointer that determines which component of the SWF has keyboard focus, and that one is used to target keyboard events. For mouse events, most likely Flash engine calls getObjectsUnderPoint() to query for topmost IEventDispatcher compatible objects (not all of the DisplayObjects can process events), and that one is sent a mouse event, with the previous event's target to receive a say MouseEvent.ROLL_OUT or MouseEvent.MOUSE_OUT if the target has been changed. For other events, most likely the entire display list can react.
For objects in the display list, the following excerpt from Adobe is the answer "When Adobe® Flash® Player dispatches an Event object, that Event object makes a roundtrip journey from the root of the display list to the target node, checking each node for registered listeners.".
For non display objects, AS3 run time maintains a dictionary of all AS3 events containing bound variables. The bound variables are a reference to the event listeners.
My application needs to notify UI that sound playback is finished. To accomplish that is attaches listener to the SOUND_COMPLETE event of a SoundChannel object.
Should I remove my SOUND_COMPLETE event listener after event processing is done?
private function playbackCompleteHandler(event:Event):void {
// Notify UI that playback is done etc
channel.removeEventListener(Event.SOUND_COMPLETE, playbackCompleteHandler);
}
Everyone says that we should always remove event listeners so that GC could properly collect objects ('channel' object in this case). But it seems that Adobe doesn't do that in the official documentation [1][2]
[1] http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/media/SoundChannel.html
[2] http://help.adobe.com/en_US/as3/dev/WS5b3ccc516d4fbf351e63e3d118a9b90204-7d21.html
Dispatcher holds listeners, so, if your dispatcher is long-living(like Application), you should use weak listeners:
channel.removeEventListener(Event.SOUND_COMPLETE, playbackCompleteHandler,false,0, true)
last true allows your objects to be freed.
If you don't need your temporary objects to process dispatcher's events after you loose all references to temporary objects and until they are collected, you shall remove listeners
Otherwise(when dispatchers are short-living), there is no need to care about listeners: if you are listening to something temporary, it will die without any problems.
It seems that your case is the last one, so it's better not to pollute code with meaningless lines.
You're question states my answer for this
Everyone says that we should always remove event listeners so that GC
could properly collect objects
If you are no longer keeping an instance of the Sound object around; then remove the event listener. If you will still be using the Sound object; then there is no need to remove the listener.
My problem is basically as follows. There is an instance of a class extending EventDispatcher. Everything goes well when I add event listener to the object like this:
myObject.addEventListener('eventName', someFunction, false, 0, false);
But something changes when event listener is added by a weak reference:
myObject.addEventListener('eventName', someFunction, false, 0, true);
Now someFunction is not called even though the line containing dispatchEvent('eventName') is being executed just like before (and there is an external reference to myObject as well).
The application I’m developing is quite complex so, unfortunately, I can’t post the exact code.
You are misunderstaning how GC works, I think. Using a weak reference will not pin down myObject. It could (possibly, not necessarily) prevent the scope in which the handler is declared to be collected (as long as myObject itself is alive). Hence, the callback itself could be collected, causing it not to be executed. It seems this is the case here, according to your description.
So your goal is to avoid that the scope declaring someFunction is collected. One way could be actually using a hard ref (if you ask me, weak refs are a bad idea, anyway). There may be others, but I don't know how your app is structured, so I can't say much.
Edit to address a comment.
GC wise, event handling is not different from the general case. When you add a listener, you're passing a reference to the dispatcher (the reference is the scope that in which the listener is declared). The dispatches stores this reference so it can execute the callback when neccesary. It's really not that different from this:
myObject.keepThisReference = someFunction;
Now, myObejct has a reference to someFunction. So, as long as myObject is alive, someFunction will be alive too (unless you set someFunction as a weak ref).
So, to answer the question in your comment (an object is not referenced anywhere else but has an event listener attached), given this scenario:
myObject.addEventListener('someEvent',someFunction);
If myObject doesn't have any other reference and goes out of scope, it is collectable.
If there's no other link to myObject, then it'll get collected when the function that you're in goes out of scope. Either change the code so it's not a weak listener, or make sure there's a reference to myObject somewhere else in the code
In actionscript 3, I dynamically create objects to which I add EventListeners. These objects are added to arrays and might be removed again later. And others might be added later again. Each time I create an object, I add these EventListeners to them. However, is it necessary to remove these event listeners too, when deleting these objects? What happens when I lose all references to an object but don't delete these EventListeners? Do they stay somewhere in the memory, unreachable and unusuable, or does the GC clean them up?
Yes, you have to remove event listeners if you are not using weak references. GC won't clean up an object if there is a reference to it, and registering event listeners do create a reference to the object unless you set the useWeakReference parameter (the 5th parameter to the addEventListener method) to true while registering the event listener. Weak references won't be counted by the garbage collector.
//Using strong reference: needs to be removed by calling removeEventListener
sprite.addEventListener(Event.TYPE, listenerFunction, useCaptureBool, 0, false);
//Using a weak reference: no need to call removeEventListener
sprite.addEventListener(Event.TYPE, listenerFunction, useCaptureBool, 0, true);
When you have event listeners on an object you won't ever loose all references to it, so it'll stay in memory indefinitely. You need to make sure you always remove any listeners you set. You can set them using weak references, but that's not really a solution, it's better to remove them explicitly.