Home → Problems →

Managing synchronized view animations

• Edit

Michael Wills

22 Feb, 2010 05:55 PM

Is there a "best practice" for managing synchronized animations across different views in response to UI actions? Currently (using signals + RL). My first thought was to have the separate mediators listen for the signal which is doable of course. But the cleanest way I have thought of so far is to:

• views expose an API for animations that need to be done, i.e. animateIn, animateOut, going to a different state, etc.
• mediators expose an API that calls the API on the views i.e. animateIn, animateOut, toList, toDetail
• command listens for a specific signal that then calls the animation functions on the mediators

So the UI triggers a signal (or an event that goes to the mediator that dispatches the signal), the command then triggers the animations on all the views needed for that particular sequence.

This is essentially managing the UI "state" for the app overall from a command as opposed to having each mediator listen for the various signals.

1. Support Staff 1 Posted by Joel Hooks on 26 Feb, 2010 02:15 AM

   

   I don't think you actually need the commands to reach into the mediators (duplicating your API). Mediators can listen for the events and handle it themselves. Would that work?

   • Edit

2. 2 Posted by Michael Wills on 26 Feb, 2010 04:14 AM

   

   It would and does, just a little trickier to manage the synch when there are delays and such simply because the code is in several places. I was wondering if there is a "best practice" for this sort of thing. RL rocks BTW. :)

   • Edit

3. Support Staff 3 Posted by Joel Hooks on 26 Feb, 2010 04:25 AM

   

   I think you are in uncharted waters unfortunately. Certainly no best practice for it. Using the mediators as you are would be as close as I could get. I'm interested in how you solve it though. Seems a command could trigger a signal that fires in mediators so they react on the same frame.

   [Inject] moveToStateX:StateXSignal;

   Mr Penner suggested a Signals based StateMachine. That'd fit this scenario rather well I think.
   

   • Edit

4. 4 Posted by Michael Wills on 26 Feb, 2010 05:36 AM

   

   I do that on a smaller level, i.e. within components and views, but I hadn't worked it out to a clean abstraction such as that. And it does make sense. Thanks!

   • Edit

5. 5 Posted by Michael Wills on 26 Feb, 2010 11:50 PM

   

   Trying to work out a context wide StateMachine but no matter how I slice it in my mind, I end up needing to keep a registry of active views one way or another. Otherwise I have to add view name strings so I can get to them by using something like the following.

   if( contextView.getChildByName( MyComponent.VIEW_NAME ) )
   {
       view:MyComponent = contextView.getChildByName( MyComponent.VIEW_NAME)); //set to .name in instance
       view.doAnimation();
       //or if the mediator is needed
       //mediatorMap.retrieveMediator(view);
   }
   

   That only works for single instances of views which is fine because for this app there is only one view/mediator instantiated of each class. I am trying to think of a way to do it that keeps it clean and doesn't require VIEW_NAME and such. I guess the only way is in the mediator's onRegister, register it with the state machine for manipulation there.

   Is that the right idea?

   And out of curiosity, is there a way for [Inject] to return a null if the item isn't instantiated? So if a view/mediator isn't yet created I could still:

   [Inject] public var myMediator:MyMediator; //not yet instantiated as the corresponding view hasn't been added to the stage yet

   without getting the "missing a rule to handle..." or would that be a Bad Idea?

   [edit] I've been able to come back to this now and yeah I'll just register the views I need to sync in a state machine. And I found this as well:

   http://github.com/cassiozen/AS3-State-Machine

   It's pretty nifty. I've been doing a manual version of that sort of thing for quite a while now.

   [edit] So adding this state machine in is very nice. And finding the bit about injecting contextView into your actors really helped. And suddenly it all just got a whole lot cleaner... thanks much for the suggestion!

   • Edit

6. Support Staff 6 Posted by Till Schneidere... on 01 Mar, 2010 11:16 AM

   

   Just a quick response to your question about optional injections:
   You can use method injection and define a default value for your
   parameter. That way, the injector won't throw an error if no mapping
   is found for the parameter's type:
   [Inject]
   public function setMyMediator(mediator : MyMediator = null) : void
   {
     //bla
   }

   • Edit

7. 7 Posted by Michael Wills on 23 Mar, 2010 03:22 AM

   

   I hadn't even thought about the possibility of injecting methods... hmm... so instead of using [Inject] public var myWhatever, it is also possible to do [Inject] public function myMethod( myWhatever:Class = default )

   Is this specific to mediators or would this work anywhere an inject occurs? I have been using Signals with Robotlegs and I have wondered about option injection for SignalCommands mapped to a signal.

   Thanks for the tip.

   • Edit

8. Stray closed this discussion on 10 Feb, 2011 05:04 PM.