preattached child view of mediated parent not triggering mediation

armoredblimp's Avatar

armoredblimp

27 Nov, 2013 10:26 PM

I've encountered a situation in my pure ActionScript project using the MVCSBundle where automatic mediation is not triggering.

Setup: I have a parent container view (parent), and a child default screen view (child). Both views are mediated.

Problem: When child is initially added to stage, the mediator for it does not initialize.

Simplified event flow:
- Robotlegs initializes, mediatorMap setup. - Parent object is created. - Parent mediator is initialized. - Child object is created [and added to parent object]. - Child object is added to stage. - Parent object is added to stage.

NOTE: These display object are starling objects. The flow trace was performed using Starling Event listeners, which don't have the provision to set capture phase, so Robotlegs stage listeners may be using another mechanism, grabbing the added to stage event occurrence earlier.

No child view mediator gets initialized. However, if I later remove the child view, dispose of it, then create a new child and add it the child mediator is automatically initialized as expected.

Why would mediation fail like this? What's a good workaround, if not solution?

  1. 1 Posted by armoredblimp on 28 Nov, 2013 01:17 AM

    armoredblimp's Avatar

    I created a workaround for the issue by deferring attachment of the child object until the parent fires off added to stage. There might be slight momentary visual glitch doing it this way, but that's code in my domain that I can address.

    This issue still irks me as I feel it will come up later. It makes me wonder what best practices are for automatic mediator invocation..

  2. Support Staff 2 Posted by Ondina D.F. on 28 Nov, 2013 04:55 PM

    Ondina D.F.'s Avatar

    Hello,

    I end up answering questions about Starling, but, the problem is, I have much less experience with Starling than the people asking the questions :P
    Soo, should I put some time into learning Starling? - question for myself.

    Are you using one of the available Starling extensions for robotlegs? If the answer is yes, which one?

    From what I understand while looking at some examples using a Starling extension for robotlegs, the flow should be like this:

    • in the Main class extending a regular Sprite add an event listener for ADDED_TO_STAGE
    • in the handler of ADDED_TO_STAGE:

      • create a Starling instance with a Starling root class and a stage and add a Starling event listener for CONTEXT3D_CREATE
      • create and configure a robotlegs context, which expects a non-Starling DisplayObjectContainer as the context view ( the Main class extending flash.display.Sprite)
    • in the handler of CONTEXT3D_CREATE add the Starling views to the Starling stage of the Starling root class

    Could it be that you added the ChildView to the stage before Starling was initialized, or before the robotlegs context has finished the configuration?
    Or, maybe you added ChildView to the ParentView in ParentView's constructor? The stage is null in the constructor.

    However, if I later remove the child view, dispose of it, then create a new child and add it the child mediator is automatically initialized as expected.

    Because at a later point in time the stage was available?

    I created a workaround for the issue by deferring attachment of the child object until the parent fires off added to stage.

    That's the right thing to do, in my opinion.

    It makes me wonder what best practices are for automatic mediator invocation..

    You provide robotlegs with a DisplayObjectContainer as a contextView when you create a robotlegs context.
    Behind the scenes the framework is adding event listeners for (**the flash**) Event.ADDED_TO_STAGE for the root container and for each container that is added to the root stage.
    These are the classes and extension responsible for that:

    StageObserver, ViewManager, ManualStageObserver, StageCrawlerExtension..

    ViewManager
    In Robotlegs 2, stage-event listening is centralised to a ViewManager. The ViewManager listens for views landing on the stage, and being removed from stage, and informs interested parties, such as the mediatorMap, accordingly.

    ManualStageObserverExtension
    This extension install a manual Stage Observer

    StageCrawlerExtension
    View Handlers (like the MediatorMap) handle views as they land on stage.
    This extension checks for views that might already be on the stage after context initialization and ensures that those views are handled

    Now, for a mediator to be created automatically there are only a few conditions to be met:

    • having a contextView
    • having a Context with the needed extensions installed
    • having a configuration, i.e. mapping of a view to its mediator **before"
    • adding a view to the contextView's stage

    You are right, the Starling Events are different from the flahs.event.Event. Also, Starling has its own EventDispatcher, so the robotlegs shared event dispatcher can't hear the events dispatched on the Starling one.
    The Starling extensions for robotlegs are listening for Starling events and are managing the automatic mediators creation internally.

    I'd be curious to see how you've initialized Starling, the rl-Context, how the mappings for your mediators look like, and the exact order of initialization/creation//addition of views to the stage. It would help other Starling users in the future( and me too, to answer their questions;) ), if you pasted the relevant code in here.

    Ondina

  3. 3 Posted by matej on 02 Dec, 2013 08:00 AM

    matej's Avatar

    Starling ViewMap extension doest look for children’s of display object that is added, so you have to add all your objects on added to stage if you want to mediate them. Or you can make a pull request and add that feature :)

  4. Ondina D.F. closed this discussion on 23 Dec, 2013 09:26 AM.

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