tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/664-mediating-a-non-displayobjectRobotlegs: Discussion 2018-10-18T16:35:31Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/100323372011-09-17T22:45:23Z2011-09-17T22:45:23ZMediating a non-displayObject<div><p>Rather than extending Actor, make your MediaPlayer a property of
an Actor - then you can use the Actor just as you would use a
mediator - to relay events back and forth. The only difference is
that you'll need to use a [postConstruct] tag on your own
'onRegister' function. You even get access to an eventMap in the
Actor class - so in all other respects it's very similar.</p>
<p>hth,</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/100323372011-09-17T22:50:29Z2011-09-17T22:50:29ZMediating a non-displayObject<div><p>Hi Kyle,</p>
<p>you can access the context's event bus by simply adding an
injection for it:</p>
<p>[Inject] public var eventBus : IEventDispatcher;</p>
<p>Then you need to construct the MediaPlayer using the injector,
or use<br>
injector.injectInto(mediaPlayerInstance);</p>
<p>Depending on how exactly your MediaPlayer is used, you might
also<br>
consider not making it listen to application events itself.
Instead,<br>
you could make it available for injection and map commands to
the<br>
events of interest. In these commands, you inject the MediaPlayer
and<br>
invoke the desired functionality through a public API. That way,
your<br>
MediaPlayer would behave pretty similarly to a model, from an<br>
application architecture point of view.</p>
<p>cheers,<br>
till</p></div>Till Schneidereittag:robotlegs.tenderapp.com,2009-10-18:Comment/100323372011-09-18T15:54:32Z2011-09-18T15:54:32ZMediating a non-displayObject<div><p>Hey Stray,<br>
The reason I wanted to use inheritance for my mediaPlayer is so I
could have direct access to the public API provided by the parent
class. By making it a public property of an actor, I would lose
this direct access to the API. It is a bit of a strange scenario I
suppose. I'd like the mediaPlayer to respond to context events,
dispatch events back into the context, but also allow for direct
access so that commands can make calls to its' API. Does that make
sense at all, or am I trying to cross two different development
paths here?</p>
<p>To explain a bit further:<br>
At startup, a command fires off that creates the MediaPlayer
instance, then stores it in a model. When, for example, a play
event gets fired off from another actor in the application, I'd
like to be able to have the MediaPlayer respond directly to the
event, calling it's own play() method. Alternately, I'd like a
command to also be able to access the model, get reference to the
MediaPlayer instance, then calls methods on it (i.e.
model.mediaPlayer.play() ).</p>
<p>I'd prefer not to solely have to use commands as I would have to
create a LOT of commands to map all of these properties, and it
seems a bit overkill as all the commands would do is essentially
proxy the event to the MediaPlayer.</p>
<p>Any further thoughts are appreciated as always!</p>
<p>-Kyle</p></div>Kyletag:robotlegs.tenderapp.com,2009-10-18:Comment/100323372011-09-18T15:57:24Z2011-09-18T15:57:24ZMediating a non-displayObject<div><p>Hey Till,<br>
Thanks for the response! Can you please check out my response to
Stray above (explains the scenario a bit more )?</p>
<p>Basically though, at startup, a command fires off that creates
the MediaPlayer instance, then stores it in a model. So the
MediaPlayer object can then be accessed by commands that inject the
model, alternately, however, I'd like to be able to have the
MediaPlayer listen for and dispatch commands (mostly to save myself
having to create a ton of commands).</p>
<p>Thanks!</p>
<p>-Kyle</p></div>Kyletag:robotlegs.tenderapp.com,2009-10-18:Comment/100323372011-09-18T16:14:04Z2011-09-18T16:14:04ZMediating a non-displayObject<div><p>Hi Kyle,</p>
<p>I don't see how you would lose access to the API - the Actor
would simply act as a mediator for your class - responding to
events as you described.</p>
<p>Have another think, and if you need a step-by-step of how to
implement it then some sample code we can spin off from would be
useful :)</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/100323372011-09-18T16:18:25Z2011-09-18T16:18:25ZMediating a non-displayObject<div><p>Hi Kyle,</p>
<p>just as Stray, I don't see a fundamental problem with using an
actor<br>
as sort of a mediator.</p>
<p>But again: If you want to directly expose the event bus to
your<br>
MediaPlayer, you can always do that by injecting it into the
player.<br>
Or, you can of course also set it manually during
instantiation.</p></div>Till Schneidereittag:robotlegs.tenderapp.com,2009-10-18:Comment/100323372011-09-18T17:04:33Z2011-09-18T17:04:33ZMediating a non-displayObject<div><p>Hey guys,<br>
Thanks for the info. I think that extending Actor makes sense, I'm
just a bit confused on how exactly to go about this implementation.
I extend Actor, but how/where/when do I go about adding my
listeners (i.e. at what point do I know I have access to the event
bus)? Also, how do I go about dispatching events back out into the
context?</p>
<p>Thanks!</p>
<p>-Kyle</p></div>Kyletag:robotlegs.tenderapp.com,2009-10-18:Comment/100323372011-09-18T17:10:47Z2011-09-18T17:10:47ZMediating a non-displayObject<div><p>Hi Kyle,</p>
<p>You can use the [postConstruct] tag on any public function, and
it will run as soon as the eventDispatcher (and any other
injections such as your mediaPlayer) has been injected.</p>
<p>So - make your own onRegister function, tag it with
[postConstruct] and away you go...</p>
<p>Then use the eventMap property of the Actor, just exactly as you
would with the mediator. In essence it's identical.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/100323372011-09-18T17:15:51Z2011-09-18T17:15:51ZMediating a non-displayObject<div><p>That is just plain sexy! haha! I'll give it a go, but that
sounds like it should work perfectly!</p></div>Kyletag:robotlegs.tenderapp.com,2009-10-18:Comment/100323372011-09-18T17:37:10Z2011-09-18T17:38:07ZMediating a non-displayObject<div><p>OK guys,<br>
So below I've pasted a a basic outline of my class.</p>
<p>// START // public class MyMediaPlayer extends Actor<br>
{</p>
<pre>
<code>[Inject]
public var eventBus:IEventDispatcher;
public var mediaPlayer:MediaPlayer;
public function MinexaMediaPlayer()
{
super();
mediaPlayer = new MediaPlayer();
}
[postConstruct]
private function onRegister():void
{
// MEDIAPLAYER LISTENERS
mediaPlayer.addEventListener(PlaybackEvent.PLAY, handlePlaybackEvent);
// CONTEXT LISTENERS
eventMap.mapListener( eventBus, MyCustomContextEvent.MY_EVENT, handleMyCustomContextEvent);
}</code>
</pre>
<p>}</p>
<p>// END //</p>
<p>I think the structure is solid, the only piece I'm not sure of
is how to go about injecting the MyMediaPlayer instance into the
context. I've tried using the following (per Till's
suggestion):</p>
<p>// START //</p>
<p>injector.injectInto( myMediaPlayer );</p>
<p>// END //</p>
<p>The onRegister() method that I've marked with [postConstruct]
doesn't seem to fire though..</p>
<p>I'm sure there's something simple I'm missing here...</p>
<p>Thanks!</p>
<p>-Kyle</p></div>Kyletag:robotlegs.tenderapp.com,2009-10-18:Comment/100323372011-09-18T18:04:01Z2011-09-18T18:04:01ZMediating a non-displayObject<div><p>Hey Kyle,</p>
<p>you've almost everything right. The only problem that's left is
that<br>
metadata iscase-sensitive, so it has to be [PostConstruct], with
an<br>
upper "P".</p>
<p>Also, note that when extending actor, you don't need to inject
the<br>
eventBus - it's already injected into the base-class:<br>
<a href=
"https://github.com/robotlegs/robotlegs-framework/blob/master/src/org/robotlegs/mvcs/Actor.as">
https://github.com/robotlegs/robotlegs-framework/blob/master/src/or...</a></p>
<p>Thus, you can listen to framework-events using the event map
and<br>
dispatch them using the dispatch method provided by Actor.</p>
<p>cheers,<br>
till</p></div>Till Schneidereittag:robotlegs.tenderapp.com,2009-10-18:Comment/100323372011-09-18T18:14:13Z2011-09-18T18:14:13ZMediating a non-displayObject<div><p>Oops! Yes, PostConstruct not postConstruct - thanks Till :)</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/100323372011-09-18T18:30:03Z2011-09-18T18:30:03ZMediating a non-displayObject<div><p>Guys,<br>
Thanks so much for all your help! I was able to get things working
successfully! One important thing to note:</p>
<p>When using [PostConstruct] (CAPITAL P haha), the method needs to
be public in order for the injector to call it. Might be a small
gotcha for anyone tryin to implement this.</p>
<p>Also, is the [PostConstruct] and other more advanced framework
usage documented somewhere?</p>
<p>Thanks again!</p>
<p>-Kyle</p></div>Kyletag:robotlegs.tenderapp.com,2009-10-18:Comment/100323372011-09-18T18:38:04Z2011-09-18T18:38:04ZMediating a non-displayObject<div><p>Great to hear that everything's working now.</p>
<p>The [PostConstruct]-method needing to be public is due to
restrictions<br>
in AS3's reflection capabilities and there's nothing we can do
about<br>
that, unfortunately. The same is true for every other type of
metadata<br>
- you just can't get to it for methods in the private or protected
namespace. (In case of PostConstruct, though, it makes sense:
The<br>
method really is called from the outside and you'd want to be able
to<br>
call it manually during unit testing, for example.)</p>
<p>As for documentation: Metadata-support is provided by
Swiftsuspenders,<br>
which has a rather dense README on github:<br>
<a href=
"https://github.com/tschneidereit/SwiftSuspenders/#readme">https://github.com/tschneidereit/SwiftSuspenders/#readme</a></p>
<p>I know that the documentation is not as accessible as it could
be.<br>
Changing that is of high priority for Swiftsuspenders 2.</p></div>Till Schneidereittag:robotlegs.tenderapp.com,2009-10-18:Comment/100323372011-09-19T01:11:12Z2011-09-19T01:11:12ZMediating a non-displayObject<div><p>This might also be a nice addition to the discussion: <a href=
"http://knowledge.robotlegs.org/discussions/solutions/9-mediate-non-visual-view-components">
Mediate non-visual view components</a></p></div>Abel de Beertag:robotlegs.tenderapp.com,2009-10-18:Comment/100323372011-09-19T02:44:58Z2011-09-19T02:44:58ZMediating a non-displayObject<div><p>Great info. in that post as well Stray, thanks!</p></div>Kyle