Killing Views
emb
What is the best way to handle killing views that aren't in use? I am currently creating the views in a command and injecting them in my mediators. I'm guessing the best rout would be to have a kill command which would then remove it from the contextView, but there the created view sits in the create command. Would love to hear how others are handling it.
Thanks!
Comments are currently closed for this discussion. You can start a new one.
Support Staff 2 Posted by Shaun Smith on 04 Mar, 2010 11:30 PM
// In a view public function remove():void { // This would be for a plain ol' DisplayObject view if ( parent.contains(this) ) parent.removeChild(this); }That way the view can remove itself, or be told to do so from the mediator (which in turn could be listening to the context's event dispatcher).
3 Posted by emb on 04 Mar, 2010 11:34 PM
At that point won't it still be sitting in memory due to it being created in the command. It is more of a resources issue than just the removal from the display list.
Support Staff 4 Posted by Shaun Smith on 04 Mar, 2010 11:52 PM
Nope, commands are short-lived objects - after execution nothing holds onto them, so they become free for GC (along with their references: properties and local variables alike).
Ideally, nothing other than a mediator should have a reference to it's view. By default Robotlegs will automatically release the mediator when it's view component leaves the stage. You can hook into the mediator's onRemove() method to do any additional cleanup before the entire system lets go of it.
5 Posted by emb on 05 Mar, 2010 12:12 AM
That is beyond fantastic! I am absolutely in love with robotlegs.
Thanks so much for your help!
Support Staff 6 Posted by Shaun Smith on 05 Mar, 2010 12:15 AM
Hey, no problem, glad to be of assistance :)
7 Posted by Stray on 05 Mar, 2010 09:58 AM
I've heard rumours that the RL team actually wear their pants on the outside...
8 Posted by Jonny Reeves on 05 Mar, 2010 01:03 PM
Just to jump in on this discussion
There is one small hiccup with hooking into the Mediator's onRemove() method and thats where your View registers an eventListener on the stage.
By the time your view's dispose() method is called; it has already been removed from the DisplayList and therefore won't be able to remove the eventListener which references the stage.
Possible ways to get around this would be to use a weak reference for the stage listener (a bit icky imho) or to override the preRemove() method in the Mediator and call view.dispose() there instead (again; I doubt the RL chaps would really want you doing this).
any thoughts?
Support Staff 9 Posted by Shaun Smith on 05 Mar, 2010 01:39 PM
If the stage listener is registered by the view internally, then you can do that kind of cleanup in the view itself:
// In a view public function remove():void { if ( parent.contains(this) ) { // remove stage listener here // .. parent.removeChild(this); } }If the listener is set up in the mediator via the eventMap, then you don't need to worry about it as the eventMap cleans up all listeners when the mediator is removed.
10 Posted by Matan Uberstein on 13 Mar, 2010 08:18 PM
Will the a Mediator instance be disposed if you have event listeners attached to function inside the mediator and you don't remove the listener?
e.g. You inject your view, you
addEventListeneron the view insideonRegisterand the handler function is inside the mediator. Later the view is removed from stage, mediator callsonRemove, but you don't remove the listener.And does the
eventMapautomatically unmap the listeners mapped on disposal of the mediator? Or do you have to unmap it manually?Support Staff 11 Posted by Joel Hooks on 13 Mar, 2010 08:20 PM
If you use the eventMap the listeners will be unregistered. If you use addEventListener you will need to override onRemove and remove the listeners manually.
12 Posted by Matan Uberstein on 13 Mar, 2010 08:24 PM
Hey Joel,
I though so, can I:
eventMap.mapListener(view, SomeEvent.TYPE, handler, SomeEvent);and the listener will be removed automatically?
Support Staff 13 Posted by Joel Hooks on 13 Mar, 2010 08:26 PM
http://github.com/robotlegs/robotlegs-framework/blob/master/src/org...
Yup
14 Posted by Matan Uberstein on 13 Mar, 2010 08:30 PM
Awesome, it never occurred to me until now, now I have about a 100 places to go and modify code... But! It's for the best, better that going everywhere and overriding onRemove and copying my view's listener statements and changing them to remove.
Thanks,
Joel
15 Posted by eco_bach on 15 Mar, 2010 02:46 PM
I know common knowledge to most, but from my experience with projects such as kiosk apps that will be running continuously, always better to avoid removing objects from the display list unless necessary.
better to simply set visibility to false.
16 Posted by Matan Uberstein on 15 Mar, 2010 02:52 PM
I like giving the system as much free memory as possible, it's essential when building games or websites.
17 Posted by emb on 15 Mar, 2010 03:02 PM
You will also see issues if the kiosk is being built on a low end system like celeron or atom. If you have a beast of a box running it, you'd prob be fine but otherwise you've got to kill those views! =P
Stray closed this discussion on 11 Feb, 2011 11:32 PM.