02-04-2011 08:52 AM
I know this is probably a pure AS3 question, but as the goal is PlayBook-related I'm asking here.
Is it possible to "lazy-load" ActionScript3 code? (This would be like what you'd call dynamically linking some library, rather than statically linking it.)
In the Python world, the "import" statements are actually true statements, processed at run-time to load (and even on-the-fly compile if necessary) other modules. You can even put "import" inside functions, so they are executed well after the application loads, even doing so only if a rarely-used feature is invoked.
Is this also possible with AS3? (I admit I haven't even tried doing "import" in a function.) If it is, does it work the same way, where the imported code is not even loaded from the SWF (or wherever it may be) until the import statement executes?
One use case would be to allow a very large app to begin executing, perhaps displaying a custom splash screen, while it continues loading modules "in the background". They alluded to doing this in some video (first WebWorks webcast?) where they mentioned that the custom splash screen image in your blackberry-tablet.xml file "could even be integrated into the app". That makes no sense to me unless some form of lazy-loading were available.
Solved! Go to Solution.
02-04-2011 10:48 AM
02-04-2011 10:57 AM
(Is "Modules" supposed to be a link in your message? It's underlined, but not linked.)
Which "Modules" are you talking about? The mx.modules.Module class? I'm still pretty fuzzy on which parts of the mx.* namespace are pure AS3 and independent of the whole MX framework (or whatever it is), but the docs say that's the "base class for MXML-based dynamically-loadable modules". I don't use any of that MXML jazz, just pure AS3 code, so it sounds like it might not work for me.
02-04-2011 11:12 AM
The number of imports shouldn't really affect your start up time, it's mainly what is executing at the same time as you're trying to startup.
So, to do lazy loading, you just delay instanciation of your main classes.
My standard approach I use on both Android and Playbook, is that my main Startup uses setTimeout to wait 1 full second before actually launching the app.
02-04-2011 11:15 AM
mx library does not equate to MXML. Any mx class can be used as pure AS3. All my module work is done in AS3 (ModuleManager, IModule, Module, etc.). "mx" is just a namespace from when Macromedia had Flash. I have one project that uses all the "mx" struture, but there is not a line of MXML to be found anywhere. You should be OK. Additionally, the actual Module can be all AS3 code.
I typically bold and underline class names to make it easier to read and find.
All MXML code gets converted over to AS3 during compile anyway. MXML just makes it easier to layout a GUI. I just use it for that, but some use MXML for services as well.
02-04-2011 11:17 AM
Thanks Shawn (and John). I think my Python worldview messed up my thinking on imports, as I was picturing them as actual executable statements. If they're just basically signals to the compiler, to let it map short class names to the full version, then I can see they play no role in loading time as they likely don't even generate actual bytecode.
So basically the loading time depends on the size of the SWF (hand-wavingishly), but that's presumably only a fraction of a second. Startup time for the app, however, depends on what you do in the main class constructor and (obviously) things called directly from it, so you want to minimize that.
Is it safe to say that the app's stage will be visible immediately after the main class constructor completes and returns? So if you want the splash screen to continue while you "build up" the rest of your app, you would basically just add a Bitmap with the same splash image, and do everything else as a result of the setTimeout() call... that seems simple enough.
02-04-2011 11:29 AM
You could minimize any allocation in the constructor of the root Sprite except for showing a splash screen and making the stage visible. Then add a Timer for 1/2 second to then begin executing other code that might build up the rest of your application. If you have a lot of things to build or interface to the Net, then those callbacks provide some delay in the execution of the iniitial condition of the app. In one of may apps that gets some state from the web get executed one the app is up and then finishes its iniitial condition from the inherit delay of using URLLoader.
Hope that helps in some way.
02-04-2011 11:33 AM
Kudos to both of you for the suggestions about the splash-screen use case I described, and for clarifying imports. I accepted John's first response as the solution, as it directly addresses the question in the subject.
07-24-2011 02:18 PM
I just wanted to simplify what you guys are saying to see if I'm correct because this is what I was trying to do it seems. So basicaly if you want to make a loader for your application the only reason you may want to is for local content of app with a timer event because module load at start with imports used and images may interfere with with those load times, any more code for a real load class your probly not helping load time. If your looking at loading outside content (from web server) to use the QNXStageWebView class?
Still a bit new to all this but I am getting a grip of everything I think.