Killing Views

emb's Avatar

emb

04 Mar, 2010 10:12 PM

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!

  1. Support Staff 2 Posted by Shaun Smith on 04 Mar, 2010 11:30 PM

    Shaun Smith's Avatar
    // In a view
    public function remove():void
    {
        // This would be for a plain ol' DisplayObject view
        if ( parent.contains(this) ) parent.removeChild(this);
    }
    
    // In a mediator
    view.remove();
    

    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).

  2. 3 Posted by emb on 04 Mar, 2010 11:34 PM

    emb's Avatar

    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.

  3. Support Staff 4 Posted by Shaun Smith on 04 Mar, 2010 11:52 PM

    Shaun Smith's Avatar

    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.

  4. 5 Posted by emb on 05 Mar, 2010 12:12 AM

    emb's Avatar

    That is beyond fantastic! I am absolutely in love with robotlegs.

    Thanks so much for your help!

  5. Support Staff 6 Posted by Shaun Smith on 05 Mar, 2010 12:15 AM

    Shaun Smith's Avatar

    Hey, no problem, glad to be of assistance :)

  6. 7 Posted by Stray on 05 Mar, 2010 09:58 AM

    Stray's Avatar

    I've heard rumours that the RL team actually wear their pants on the outside...

  7. 8 Posted by Jonny Reeves on 05 Mar, 2010 01:03 PM

    Jonny Reeves's Avatar

    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?

  8. Support Staff 9 Posted by Shaun Smith on 05 Mar, 2010 01:39 PM

    Shaun Smith's Avatar

    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.

  9. 10 Posted by Matan Uberstein on 13 Mar, 2010 08:18 PM

    Matan Uberstein's Avatar

    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 addEventListener on the view inside onRegister and the handler function is inside the mediator. Later the view is removed from stage, mediator calls onRemove, but you don't remove the listener.

    And does the eventMap automatically unmap the listeners mapped on disposal of the mediator? Or do you have to unmap it manually?

  10. Support Staff 11 Posted by Joel Hooks on 13 Mar, 2010 08:20 PM

    Joel Hooks's Avatar

    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.

  11. 12 Posted by Matan Uberstein on 13 Mar, 2010 08:24 PM

    Matan Uberstein's Avatar

    Hey Joel,

    I though so, can I:

    eventMap.mapListener(view, SomeEvent.TYPE, handler, SomeEvent);

    and the listener will be removed automatically?

  12. Support Staff 13 Posted by Joel Hooks on 13 Mar, 2010 08:26 PM

    Joel Hooks's Avatar
  13. 14 Posted by Matan Uberstein on 13 Mar, 2010 08:30 PM

    Matan Uberstein's Avatar

    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

  14. 15 Posted by eco_bach on 15 Mar, 2010 02:46 PM

    eco_bach's Avatar

    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.

  15. 16 Posted by Matan Uberstein on 15 Mar, 2010 02:52 PM

    Matan Uberstein's Avatar

    I like giving the system as much free memory as possible, it's essential when building games or websites.

  16. 17 Posted by emb on 15 Mar, 2010 03:02 PM

    emb's Avatar

    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

  17. Stray closed this discussion on 11 Feb, 2011 11:32 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac