Manual TearDown

dan's Avatar

dan

23 Aug, 2014 12:19 AM

Some background... I have a module loaded by a parent application that is used like a class factory. This parent application doesn't properly tell me when to tear down my application and I want to be a 'good citizen'. Currently my view components are removed from stage and my mediators destroy themselves just fine.

Now, to be a 'good citizen', I'd like to clean up further and tear down my context etc once all of my views are destroyed. My question here is where I can start to monitor the mediatorMap list of mediator instances? Basically, I thought to begin tear down when I see all mediator instances destroyed.

If this isn't so easy... I could also override the Mediator base class and keep a count there, thoughts?

  1. Support Staff 1 Posted by Ondina D.F. on 25 Aug, 2014 05:30 PM

    Ondina D.F.'s Avatar

    Hey Dan,

    There has to be some sort of communication between the parent app and yours.
    How does the parent application use your module?
    Is there a contextView added to the stage of the parent application?
    If not, how do you know when to create a robotlegs context? Through an API? Is your 'class factory' creating the context and your views?
    Are you keeping a dictionary of views in your class factory?

    Oh, wait! I'm having a déjà vu moment :) Your use case sounds familiar to me. Isn't it the same as in this thread ? :
    http://knowledge.robotlegs.org/discussions/questions/7928-using-rob...
    I'll probably have to read through the entire discussion again, to fully understand the scenario.

    Currently, the classes under the mediatorMap package aren't exposing an API for getting a list of mapped mediators, so, personally, I don't know how you could use them for your purpose.

    You could, however, create your own dictionary (or a collection of your choice), like the one inside of MediatorFactory. Each time a mediator is created (initialize()), you also add it to the dictionary, for example via an event->command->model->dictionary.
    Each time a mediator gets destroyed, you can dispatch an event from within its destroy() method to let another command access your model->dictionary.
    The model deletes the mediator from the dictionary, and when the dictionary is empty it dispatches an event for which your context has added a listener, so it can destroy itself: context.destroy().
    You can simplify the workflow as you wish or need, if you don't like the long event->command->model path.

    Does that help?

  2. 2 Posted by dan on 25 Aug, 2014 05:46 PM

    dan's Avatar

    Yup---thats my thread ;-)

    Thanks for the example. This is the direction I was intending to go. The parent application has several entry points into my application (right click context menu, click through to top level view, or a user's bookmark to a specific view of about 10), I've got the entry points covered and the context view is presently the top level application.

    So for tear down, I'll do what you've suggested and when the view count falls to zero, I'll wait a minute or so and then destroy the context.

  3. dan closed this discussion on 25 Aug, 2014 05:46 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