tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/140-best-practice-for-callbacksRobotlegs: Discussion 2018-10-18T16:35:11Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/15518842010-04-28T13:38:38Z2010-06-27T20:26:49ZBest Practice for callbacks?<div><p>ok for the first, i got it, sorry. The previous post was talking
about "Model" as in the model managers.</p>
<p>Can anyone please tell me if this makes sense?</p>
<p>Command<br></p>
<pre>
<code> [Inject]
public var service:IService;
[Inject]
public var event:Event;
override public function execute():void {
service.execute(event.payload,callBack);
}
public function callBack(results:Object):void { ..
//process results
//dispatch further events from here
}</code>
</pre>
<p>And in the service side (IService)<br></p>
<pre>
<code> public function execute(someobject:Object,callback:Function):void {
//call a remote service
//add result handler
token = service.send();
token.callBack = callBack;
}
private function onResult(event:ResultEvent):void {
var token:AsyncToken = event.token;
token.callBack(event.result);
}</code>
</pre>
<p>This actually worked, but it feels so so to me. Is that Command
object kept in memory now?</p></div>Raed Atouitag:robotlegs.tenderapp.com,2009-10-18:Comment/15518842010-04-28T13:54:20Z2010-04-28T13:54:20ZBest Practice for callbacks?<div><p>That makes sense. The Command object will be kept in memory as
long as you keep a reference to the token/callback (I can't tell if
the token in Service#execute() is held on to after the result is
issued or not).</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/15518842010-04-28T14:03:41Z2010-06-27T20:26:49ZBest Practice for callbacks?<div><p>thank you for you reply.</p>
<p>I guess i failed to mention that the results in the callback are
passed to the Model.<br>
Ideally, after the results are returned to the command, processed
and passed to the Model, i want to dispose of the command
entirely.<br>
so would the AsyncCommand alleviate this problem of memory
references?</p>
<p>Raed</p></div>Raed Atouitag:robotlegs.tenderapp.com,2009-10-18:Comment/15518842010-04-28T20:58:58Z2010-04-28T20:58:58ZBest Practice for callbacks?<div><p>You don't need an AsyncCommand in your particular case, as the
callback reference will keep the Command alive until you let go of
it. As far as I can see, your Command should be free for GC as soon
as the callback is executed.</p>
<p>You can step through it like this:</p>
<ol>
<li>Command is executed, passes callback reference to
service.<br></li>
<li>Service holds on to callback reference (and thus the Command
instance) by adding it to a token.<br></li>
<li>Service result handler fires, executes the callback, and lets
go of the token (and thus the callback, and thus the Command
instance).</li>
</ol>
<p>As long as you aren't holding on to that token (or the callback)
there will be no references left that point to the Command
instance. It should be free for GC, and removed when the Flash
Player needs more memory (or whenever it feels like it - it's not
predictable).</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/15518842010-04-29T04:21:48Z2010-06-27T20:26:49ZBest Practice for callbacks?<div><p>yes, the GC is not predictable, but that approach should be fine
as long as the commands get discarded.</p>
<p>thank you so much for responding and you can close this thread
now</p>
<p>Raed</p></div>Raed Atoui