tag:robotlegs.tenderapp.com,2009-10-18:/discussions/examples/870-modules-signalsRobotlegs: Discussion 2013-04-26T14:05:58Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/264623492013-04-18T19:31:29Z2013-04-18T19:31:29ZModules & Signals<div><p>Hi compatriot :)</p>
<p>I'm curious about the memory leaks you encountered, was this
with the latest Flex SDK? Core stuff? Or the horribly written
components?</p>
<p>Just a heads-up: we're completely rewriting the
command(maps)-stuff in RL, at a first glance I don't think it will
impact your example app, since we try to change the API as little
as possible, except where it's an improvement obviously or as an
added functionality. Also, I'm rewriting the signal command map
completely, but again I don't think it will have a major impact.
There were a number of problems with the SCM though, which are
getting fixed, those <em>could</em> affect side-effects you've come
accustomed to or maybe even count on in your example. Just an FYI,
we hope to release v2 soon (don't know when, but soon) and it would
be really great to have some examples that can be immediately
presented as being definitely up-to-date.</p>
<p>As for the example, it looks good. Haven't had the time to
really tinker with it, but from a
not-superficial-but-not-entirely-thorough reading I'd say it'll be
very helpful!</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/264623492013-04-19T00:11:08Z2013-04-19T00:11:08ZModules & Signals<div><p>Heya. Looking good. BTW, is this discussion supposed to be
private? (totally fine if it is, it's just that people sometimes
make discussions private by mistake)</p>
<p>Also, I'm curious as to why you're setting the contextView like
this:</p>
<p><a href=
"https://github.com/dotdotcommadot/ModularRL/blob/master/src/ModularRL.mxml#L17">
https://github.com/dotdotcommadot/ModularRL/blob/master/src/Modular...</a></p>
<p>That was a workaround for RL1 where there was no ViewManager to
handle multiple display lists per context. Doing that in RL2
negates much of the nested context view optimisation work we've
done and isn't nicely scoped.</p>
<p>Give me a shout if you need some pointers to switch it over. I'm
on holiday at the moment, and not always online, but I'll get back
to you eventually :)</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/264623492013-04-19T10:34:05Z2013-04-19T10:34:05ZModules & Signals<div><p>Hi Guys,</p>
<p>Thank you for the quick reply!<br>
About the discussion: I put it on private by accident indeed, but I
fixed it :)</p>
<p>I've just put a running application online, published as a:</p>
<ul>
<li><a href=
"http://www.dotdotcommadot.com/modularrl/release/">release
version</a></li>
<li><a href="http://www.dotdotcommadot.com/modularrl/debug/">debug
version</a></li>
</ul>
<p>Doing this, i noticed that there is still a memory leak, but
it's more detailed then I thought it was before.<br>
Apparently, right now the application only has a severe memory leak
when it's running in <strong>debug mode in the standalone
player</strong>.<br>
Only a part of the used memory will be released after unloading a
module, and everytime the app loads the module again, more memory
will be used.<br>
You can test it yourself easily if you:</p>
<ul>
<li>download the debug version of the app <a href=
"http://www.dotdotcommadot.com/modularrl/modularrl-debug.zip">here</a></li>
<li>unzip the folder</li>
<li>open ModularRL.swf in the standalone flash player</li>
<li>click 'Load Module One'</li>
<li>click 'Unload Module'</li>
<li>load, unload, load, unload, load, unload, .... and watch the
memory growing.</li>
</ul>
<p>Do the same thing for the release version, which can be found
<a href=
"http://www.dotdotcommadot.com/modularrl/modularrl-release.zip">here</a>.<br>
You will see that here a certain amount of memory will be used, but
after 3 times loading/unloading, the memory won't get bigger.</p>
<p>As long as this only happens in the standalone player in debug
mode, I'm actually ok with this.</p>
<p>About the commands and commandmap rewrite:<br>
I'll keep an eye out on the forum!<br>
Once you guys are finished with this, I'll update this example to
the latest SDK.<br>
Thanks for the tip Camille!</p>
<p>@Shaun, about the contextView: I still use this so my popups get
mapped once they land on the stage.<br>
It works perfectly, but if you think it's a bad practice I will
update this.<br>
In fact, this app currently doesn't use any popups, so I'll just
throw it out anyways.<br>
There are enough topics on the forum on how to implement popups in
RL2, so I'll probably figure it out.</p>
<p>Ps1: I like making demos,I'm open for tips but don't think of
myself as a genius, so if you see things in my code that can be
optimized according to you guys in any way, I'm more than glad to
hear them :)<br>
Ps 2: I'm thinking about rewriting this app in MVP and MVVM as
well, since I tend to use these patterns more often than MVC.</p>
<p>grts,<br>
Hans</p></div>dotdotcommadottag:robotlegs.tenderapp.com,2009-10-18:Comment/264623492013-04-20T06:41:24Z2013-04-20T06:41:24ZModules & Signals<div><p>Hi, I had the time to take a more thorough look.</p>
<p>It's been a while since I worked with modules in RL1 and I
haven't used them in v2 yet, so all of the following comments and
suggestions could be completely
irrelevant/incorrect/nonsensical:</p>
<ol>
<li>Why do you include the MVCSBundle in both submodules? Doesn't
it defeat the purpose a bit?<br></li>
<li>Why do you map a stub mediator to the Shell?<br></li>
<li>One of the things most people struggle with is intermodular
communication, maybe a third, persistent module which communicates
with the other 2 whenever they're loaded could provide a nice
example of that? Or is it out of the scope of your example?</li>
</ol></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/264623492013-04-20T07:00:27Z2013-04-20T07:00:27ZModules & Signals<div><p>And thanks BTW, by reviewing your example I realized there's a
(potential) problem with the SwiftSuspenders Injector, if I'm not
mistaken:<br>
<a href=
"https://github.com/tschneidereit/SwiftSuspenders/issues/88">https://github.com/tschneidereit/SwiftSuspenders/issues/88</a></p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/264623492013-04-22T09:40:23Z2013-04-22T09:40:23ZModules & Signals<div><p>Hi creynders,</p>
<p>Thanks for looking at the app and your good questions.<br>
I'll try to answer them as good as I can.</p>
<ol>
<li>The MVCSBundles in the submodules was because I wanted to see
if I could use the Signals extention in a submodule, while the
extention wasn't included in the shell. I kind of left this here to
keep it "as an example", but you're completely right that this is
either irrelevant, or just not clear enough.<br>
I probably should be more careful with leaving irrelevant things in
"as an example", and just either make a new demo for this, or write
it in down the comments.<br>
I will for now just remove it, and keep the app to its
essence.<br></li>
<li>The shellMediator used to trigger a command which loaded and
unloaded the module (I used the ModuleManager to do this).<br>
I refactored this so now the Shell loads and unloads this module
with the ModuleLoader (I think it's probably OK to keep this in the
view... since it's only view functionality).<br>
I kept the ShellMediator just for uniformity throughout the
application, to make the demo clear, as one of the scopes of this
demo is "how to use the MVCS pattern". But then again, you could
say this is the same mistake as I made in point 1 hehe. But
actually, I don't think so.<br></li>
<li>Great idea, I'll add this to the example.</li>
</ol></div>dotdotcommadottag:robotlegs.tenderapp.com,2009-10-18:Comment/264623492013-04-22T10:32:49Z2013-04-22T10:32:49ZModules & Signals<div><blockquote>
<p>I kept the ShellMediator just for uniformity throughout the
application, to make the demo clear, as one of the scopes of this
demo is "how to use the MVCS pattern".</p>
</blockquote>
<p>Sure, sounds valid to me, maybe you just have to let it "do"
something, no matter how nonsensical, so it's clearly there for
educational purposes.</p>
<blockquote>
<p>Great idea, I'll add this to the example.</p>
</blockquote>
<p>Yeah, maybe you should wait a moment, I'm going to try and
rewrite the intermodular communication stuff, it's pretty ugly at
the moment.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/264623492013-04-22T16:48:17Z2013-04-22T16:50:17ZModules & Signals<div><p>I just commited a few changes:</p>
<ol>
<li>I noticed I can't just remove the custom "MVCSBundles". If I do
so, my context isn't getting triggered, right?<br>
I could replace <code><config:LogModuleBundle /></code> with
<code><mvcs:MVCSBundle/></code>, but this seems wrong as well
because I need to add the SignalCommandMapExtension to the
bundle.<br>
So I kept them here. Do you think there's a better way?<br></li>
<li>removed ShellMediator after all. There are enough MVCS examples
troughout the rest of the demo.<br></li>
<li>I added intermodular communication. although it is not a
"clean" implementation yet, I think it exposes the current issues
with this, and therefore is a good example ofa workaround.<br>
I mapped the signals to the commands, inside the ShellConfig.<br>
But I think it is a bit double: you could say the shell is not the
right place to map this, because it breaks the encapsulation. (The
shell knows about the workings of the modules, so this seems
wrong). But on the other hand, you could say that it would be
"weird" to map the addLogSignal in ModuleTwoConfig, because
ModuleTwo doesn't need to know of the AddLogCommand either.<br>
I think, if you have a look at ShellConfig, you'll see what I
mean..</li>
</ol>
<p>As always, comments are appreciated :)</p></div>dotdotcommadottag:robotlegs.tenderapp.com,2009-10-18:Comment/264623492013-04-23T09:16:20Z2013-04-23T09:16:20ZModules & Signals<div><p>As I wrote somewhere I haven't really looked into modules yet in
v2, so I'm afraid I can't really help on what exactly is required
to get them to work properly. I hope Shaun has time to drop by and
comment.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/264623492013-04-23T14:45:02Z2013-04-23T14:45:02ZModules & Signals<div><p>Hey Hans,</p>
<p>I have just a little time to make some comments regarding your
demo. I’m addressing only your gc-issues in this post.<br>
Your modules don’t get gc-ed because they never leave the
stage, and that’s because of the way you’re using skins
and css styles.<br>
The skin classes are keeping a reference to the views, i.e.
ModuleOneMainViewSkin to ModuleOneMainView and
ModuleTwoMainViewSkin to ModuleTwoMainView, because the css styles
don’t get removed when the modules are unloaded.</p>
<p>A workaround:<br>
Instead of the fx style declaration, set the style within the
constructor of the view like this:</p>
<pre>
<code>public function ModuleOneMainView()
{
setStyle("skinClass", Class(ModuleOneMainViewSkin));
}</code>
</pre>
<p>When the view gets removed from stage, the styleManager will
remove the style automatically.</p>
<p>Even with the above workaround, ModuleOne is never leaving the
stage.<br>
ModuleOneMainViewSkin contains a datagrid, which keeps the view and
the skin alive.<br>
After replacing the datagrid with a spark list, the skin and the
view get removed from stage.<br>
I’m not sure and I don’t have the time to investigate
this any further, but I think it is a (datagrid) bug.</p>
<p>In my opinion, it would be better (and easier) to use simple
components for your demo, without styles and skins. Keep the focus
on modularity.</p>
<p>Not an issue in your case, but sometimes having something like
this:</p>
<pre>
<code>view.loadUsersButton.addEventListener( MouseEvent.CLICK, onClick_loadUsersButton );</code>
</pre>
<p>in your mediator, can result in gc-issues, if you don’t
remove the event listeners.</p>
<p>A better approach would be:</p>
<pre>
<code>addViewListener(SomeEvent.SOMETHING_HAPPENED, onSomethingHappened, SomeEvent);</code>
</pre>
<p>where SomeEvent.SOMETHING_HAPPENED would be dispatched by the
view in the handler of the loadUsersButton when clicked.</p>
<p>Also not a problem in your case, but I’m just mentioning
it:<br>
Something that can help a lot when dealing with gc, especially in
case of modules, is cleaning up views before they are removed from
stage: removing all event listeners, removing child components,
setting dataproviders to null, etc. In other words, make sure to
get rid of any references that could keep your views alive.</p>
<p>That’s all for now :)<br>
Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/264623492013-04-26T14:33:58Z2013-04-26T14:33:58ZModules & Signals<div><p>Hey Hans,</p>
<p>I found some time today to take another look at your app. I also
re-read the previous posts more attentively and noticed that you
added a LogModule. So, I dl-ed the new version and while I was at
it, I finally read your README. You should have told me to RTFM
;)<br>
Indeed, having this compiler argument: -keep-all-type-selectors,
solves the issue with unloading a module’s style, and there
is no need for setting the skinClass in actionscript anymore. But,
the DataGrid issues still remain. Hopefully you’ll have more
time than me to investigate that.</p>
<p>I still think that you should concentrate only on the rl-modular
aspect in this demo, keeping it simple -> no styles or skins, no
compiler arguments...<br>
You could make another demo, expanding the simple one, which
focuses on memory/gc issues.</p>
<p>Your comments inside of ShellConfig:</p>
<blockquote>
<p>// Intermodular communication workaround // On one side, you
could say that this is actually in the wrong scope: // the shell
application shouldn't have to know about these. // on the other
side: moduleTwo shouldn't have to know about the addLogCommand
either I think, // so where else do you map the signal to the
command, instead of in the shell?</p>
</blockquote>
<p>You’re right, it’s tricky.<br>
Just thinking out loud:<br>
To me, LogModel, AddLogCommand and AddLogSignal seem to belong to
the LogModule instead of being shared, and should be mapped in
LogConfig. But, how to dispatch the signal from ModuleTwo in this
case?<br>
Maybe by having an IntermodularSignal (the name is just for the
sake of an example) mapped in the ShellConfig, which would serve as
a ‘global’ channel?<br>
Then, dipatch IntermodularSignal from ModuleTwo, or any other
module to be listened by LogModule. It would be cool if we had a
way to listen to that ‘global’ signal inside the
module, and to relay it to a ‘local’ one, i.e.
AddLogSignal, which would trigger AddLogCommand.</p>
<p>See the discussion for a similar problem with events: <a href=
"http://knowledge.robotlegs.org/discussions/robotlegs-2/931-intermodular-communication-bestpractice">
http://knowledge.robotlegs.org/discussions/robotlegs-2/931-intermod...</a></p>
<p>On another note, you certainly know that injecting models into
mediators is a disputed practice, don’t you? ;)<br>
Personally, I’m not strictly against it, sometimes it really
makes sense to do so depending on the use case, but since you want
your demo to be an ‘official’ one, or so I think, it
would be nice if you’d follow the stricter MVCS-way. The
suggestion from my previous post regarding addViewListener falls
into the same category.</p>
<p>Hopefully, you won’t take my observations the wrong way.
They aren’t meant to be destructive :)</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/264623492013-04-26T16:17:57Z2013-04-26T16:17:57ZModules & Signals<div><p>Hi Ondina,</p>
<p>thanks a lot for commenting so thoroughly; most certainly not
taken the wrong way!</p>
<ul>
<li>
<p>About the skins: The reason why I used them in this demo was to
test if it's true that it won't cause memory leaks when using '
-keep-all-type-selectors'. But now that I know the results, I think
you're right and I should remove them for clarity of the demo. Or
better: I'll change this demo to the "advanced" one, and simplify
it for the other demo.</p>
</li>
<li>
<p>You're also right about the shortcuts I took. I'll remove them,
and stick to clean MVCS.</p>
</li>
<li>
<p>I've been thinking about the intermodular issue a lot., One
other issue is that Signals don't have weak references.<br>
otherwise you could just make some sort of singleton
"GlobaSignalsMap", and listen to all of the signals on that...<br>
But as far as I got to test, components won't get GC'd when they
are still mapped to a signal.</p>
</li>
</ul>
<p>Anyway,I'll try to fix things asap, but now need to focus on a
deadline at the end of next week :)</p>
<p>Hans</p></div>dotdotcommadottag:robotlegs.tenderapp.com,2009-10-18:Comment/264623492013-04-26T16:46:31Z2013-04-26T16:46:31ZModules & Signals<div><blockquote>
<p>thanks a lot for commenting so thoroughly;</p>
</blockquote>
<p>My pleasure!</p>
<blockquote>
<p>most certainly not taken the wrong way!</p>
</blockquote>
<p>Glad to hear that.</p>
<blockquote>
<p>Or better: I'll change this demo to the "advanced" one, and
simplify it for the other demo.</p>
</blockquote>
<p>Cool:)</p>
<blockquote>
<p>One other issue is that Signals don't have weak references.
otherwise you could just make some sort of singleton
"GlobaSignalsMap", and listen to all of the signals on that...<br>
But as far as I got to test, components won't get GC'd when they
are still mapped to a signal.</p>
</blockquote>
<p>That’s also why, as much as I love signals, I use them
sparingly and with lots of care in my projects. Over the years
I’ve become quite obsessed with gc/memory leaks;)</p>
<blockquote>
<p>Anyway,I'll try to fix things asap, but now need to focus on a
deadline at the end of next week :)</p>
</blockquote>
<p>Take your time and good luck with your deadline.</p>
<p>I’ll close this thread for now. Please re-open it when and
if you want to continue the discussion or when you have new
versions of your demo.</p>
<p>Ondina</p></div>Ondina D.F.