If you have modules that are to be shared and not unloaded, load them into
the same ApplicationDomain as the main app.
Then if you have a table of button bar buttons mapped to urls, you should be
able to set the moduleloader's url. If you rely on ready events, you
shouldn't need to count on unload events, which you won't get for the 3
Hi thanks for the reply here too
I agree it totally makes sense if I do not unload modules to load them in the same application domain and not as a child. This way I wouldn't have to worry about the singletons I could have forgotten to initialize in the main application If my logic is correct. But still is it wrong to leave them in a child ApplicationDomain since I will still have modules I will need to unload and I would still have to be careful about the singleton managers?
Note: have in mind I am trying to separate the module's from the main application, so the application won't use any classes defined in the modules since it won't be aware of what's in what module.
Yes, I do have a buttonBar buttons which map to module urls.
Ok I will try to setup my questions in a few very simple example applications, it would be easier for you to understand what's confusing me.
http://filip.nedyalkov.net/moduleLoaderTesting2/ - view source enabled - look at testing3.mxml
In the button bar change handler I have:
moduleURL = buttonBar.
moduleLoader.url = moduleURL;
and I listen to the moduleLoader unload event.
On the Unload Current Module Button I have: moduleLoader.unloadModule();
Ok what is confusing me is this: When I start switching between module1 and module2 do they automatically get unloaded because I recall reading that changing the moduleLoader.url property doesn't unload the module just releases it? Also I'm getting the unload event shoot very strange because if I am on module1 and then click on module2 it doesn't shoot that module1 was unloaded, it doesn't do anything. As soon as I click back on module1 then it shoot unloaded (you can see that in my example in the text area).
Another strange thing is that while doing this, everytime you click on module1 or module2 they get transferred over the network I can see that in mozilla firebug. Now if I am on module1 and click the Unload Current Module button the module really gets unloaded and then the unload event is correct and shoot when it's supposed to shoot. Now if you click on module2 and then come back to module1 it will get loaded again, but now it will be put in memory, it won't shoot unload event any more and it won't get transferred over the network when I switch the modules? Why is that ? All I did was unloading the module once and it changes everything.
So I hope you undertstand this cause I have no idea is this supposed to work this way? Would you be so kind to explain me this behaviour ?
I would recommend using ModuleManager to load the 3 shared modules right
after the main app loads. Then use a shared ModuleLoader driven by the
You will need to track which modules should actually be unloaded.
ModuleLoader just deferences them.
that's exactly what I am trying to do. But before I get there I need to understand how the moduleLoader works right ?
Could you please answer me these questions of my previous post which are on the problems that you can see on the online example I've specially prepared for you:
1) Why does changing the moduleLoader.url property doesn't immediately call the unload event on the module that was loaded ?
Note: you can see that from clicking on the "no module" button in my example which sets moduleLoader.url = ""; The "UNLOAD HANDLER" should be displayed in the text area but it isn't (well it is but when you click back on the module you just unloaded which makes no sense) - check the source code is very simple.
Also I did some testing with the profiler, I can confirm that even if there is no unload event dispatched, the profiler shows that the module has been unloaded.
2) Why when I manualy call moduleLoader.unloadModule() on a module, after that changing the moduleLoader.url property would cause it to load the manually unloaded module once and then put into memery and not loaded over the network again?
Note: Again you can try that with the online example from the previous post.
Please share your opinion on these 2 cases, cause I plan to put them as bug reports and some confirmation my thinking is right would be nice.
I hope you don't skip my questions this time sry if I write too much, I just try to explain better.
I haven't had time to run your code.
ModuleLoader appears to release, not unload, modules. While the instance of
the module class might be gone, the module SWF itself is probably still
around. In fact, I believe there is a weak reference cache in case the
module gets requested again right away.
All SWF requests are made via http or https and browser caching rules apply.
But the weak reference cache in ModuleManager may be why you are not seeing
another network fetch.
I understand the caching of the swf, what I don't understand is the wrong unload event dispatching when chaning moduleLoader.url and the changing of the moduleLoader behaviour after a module has been unloaded with unloadModule() - before:getting the swf from the network, after: from memory.
I can wait, when you have the time check out my example, it's just a few simple lines of code and it will take you like one min to test what I imply i see as a problem or strange behavior. Otherwise we are circling around the problem just wasting time.
P.S. If the module loader just releases the module when changing url (I can confirm I see that in the source code of moduleLoader), why is the unload event dispatched? And at the wrong time... again in my example, that's my 1st question from the previous post.
OK after looking at the source code for ModuleManager and ModuleLoader I finally figured out the 2 problems I found.
Probably I will post a bug report or to be more accurate an incorrect functioning for the ModuleLoader and ModuleManager but as for now I can tell you 2 things for the guys that have the same problems:
1) don't count on unload event unless you invoke it with unloadModule();
2) If you want to make sure a module is completely unloaded, which includes the references that the ModuleLoader creates in the ModuleManager, always call moduleInfo.release() method after the unload() method or unloadModule(). Even if you use ModuleLoader you can use the moduleInfo instance that comes from the unload moduleEvent and call release(). This way you will prevent the module from being unwillingly stuck into memory after the second load.
Cheers and good luck.
I tried out your sample code. One usability issue you have run into is
setting the module url to an empty string in an attempt to unload it. This instead causes the ModuleLoader to attempt to load a module that does not exist. This, of course,
generates an error that causes the ModuleLoader to unload the existing module. Try setting the module url to null instead of an empty string and see if that makes more sense:
I've written a bug for the usability issue: https://bugs.adobe.com/jira/browse/SDK-28274. It should it fixed in the next couple of weeks.
That fully explains the 2 problems I had. I really wasn't sure that this is the problem since I didn't dig up to the SWFLoader when I was checking the source code. I stoped when I found out that the failed attempt to ressurect the module produces the unload event when I switched from module1 to the empty string and back to the module1. So now I see the real reason.
Thanks for helping me out put this into a more clear example to put as a bug.
I tried with null before I tried with an empty string but didn't see the unload event properly dispatched again so I guess they both work the same. I left it empty string in the example since in the docs it says that setting the url to an empty string should unload the module.
Thank you very much again, really appreciated!
Darrell, one more thing, what do you think about about the stuck in memory due to not removing reference when calling the unloadModule() method. It is caused because when you call unloadModule it calls unload on the moduleInfo but does NOT call release(). I think that's a bug because then the calculation of the actual references will be wrong by +1 each time you call the unloadModule().
If I am correct you can add this to the bug issue since it's easy to fix too.. just adding moduleInfo.release() along with the unload().
So what do you think ?
Yes, please write up the +1 reference issue as well.
I see you modified http://bugs.adobe.com/jira/browse/SDK-28274 to add your issue. The original issue in the bug has nothing to do with the +1 issue you added to the bug. One bug should only have one issue. Please write up a separate bug and attach the sample code you provided in this thread. The way things currently stand, no one will be able to reproduce the +1 issue by looking at SDK-28274 (and it will not get addressed).
Ok, got it, thanks for the tip!
I saw that the issue 1st issue is now fixed. Does that mean that it will be fixed in the next sdk release which is now Flex Hero? And also I couldn't find when is the official release of the Flex Hero, I mean what date?
Yes, the fix will be in Flex Hero. Hero will be released sometime in 2011.
could you please take a look at these 2 threads I've posted:
It will take you very little time, just try out my examples and see if you can tell me should I post them as bugs or not. If you can't tell and have not much time to look more into them, just let me know I will post them as bugs anyway. Thanks.
I took a look at them.