External Preloader; more complex cases

In my previous post I spoke about what would be my optimal external preloader, but I really covered only simple examples. In relations to external preloaders, there are 2 cases where it gets more complex. First, when you want to time you preloader's animation with your main content's animation and second, when you use FlashVars (variables passed from the HMTL to the SWF).

Timing a preloader animation with the main content animation

Sometimes you don't want to start the loaded content as soon as it's been loaded.  You want to leave time for the preloader's exit animation to end or you want to morph your preloader with the main content to have some sort of contunuity. In those cases, the external preloader has to call a method of the main content. That sounds simple but it actually isn't. If you try to call a method directly like we used to do in ActionScript 2 the compiler will complain because it doesn't know if the loaded content will have such a method. In order to solve this problem you will have to use interfaces. You can get more information about interfaces on this previous post of mine. Now that the loaded content is typed to an interface you will be able to call it's method and the synchronization between the preloader and the content will be good.

Using FlashVars

FlashVars are really usefull and a lot of times you might end up using them. The problem is that contrarily to ActionScript 2, in AS3 the root variable will refer to this SWF's root, not to the entire applicatio's root. So from the loaded content you don't have access to the FlashVars. You solve this problem the same way as we solved the preceding problem: by using an interface. In the first case, we mostly would have called a method without parameters like init() or something like that, but in this case the parameters will be the FlashVars. You might want to pass the root.loaderInfo.parameters.YOUR_VAR_NAME as a parameter or you might want to do some checking as to know if the parameter was passed or not. In your interface you will have to write down all the parameters you want to pass and what type (String, int, Number, etc) they are. Here is an example of how you could do it.

Here is the interface:

Actionscript:
  1. package com.zedia.interfaces{
  2.   public interface IMain{
  3.     function init(flashvars1:String, flashvars2:Number):void;
  4.   }
  5. }

Here is some of the code of that the preloader could contain:

Actionscript:
  1. import com.zedia.interfaces.IMain;
  2.  
  3. var mainContent:IMain;
  4. function onLoadComplete(event:Event):void{ // this would be the function that the loader would call when the loading is completed
  5.   mainContent = IMain(loader.content);
  6.   addChild(Sprite(mainContent) );
  7.   mainContent.init( String(root.loaderInfo.parameters.flashvars1),Number(root.loaderInfo.parameters.flashvars2) )
  8. }

Here is some code of the loaded content:

Actionscript:
  1. package{
  2.   import com.zedia.interfaces.IMain;
  3.  
  4.   public class Main extends Sprite implements IMain{
  5.     public function init(flashvars1:String, flashvars2:Number):void{
  6.       //do something with the FlashVars
  7.     }
  8.   }
  9. }

As you can see in the preloader's ActionScript, in order to add the content to the stage, you first have to cast it to Sprite. You will have to do this when you will want to have access to Sprite properties like x and y. I admit this is a down side of using interfaces but at the same time it solved both the problems of timing an animation and passing FlashVars to the loaded content.

2 Responses to “External Preloader; more complex cases”

  1. Tyler Egeto Says:

    Good post. It brings up one of my biggest irritations with Flash, interfaces allow us to give an object multiple data types (super powerful) but once we store it, it “forgets” that it actually belongs to both, as shown in your example where it needs to be re-type cast to access all the the methods/properties available on it. I’m sure there are low level issues with it, but I would love for that to change.

  2. zedia.net Says:

    Ya when you use both an extends statement and an implement statement, if you cast your object as the interface, the object doesn’t know that it extends something so you have to type-cast it all the time. I don’t know how this is handled in other programming languages.

Leave a Reply


Close
E-mail It