Flex 3 Runtime Shared Libraries, Interfaces, and Dynamic Instantiation

Recently I started playing with RSL’s (Runtime Shared Libraries).  Coming from a programming language where Dynamic Libraries are a common way of separating implementation from contract, and making it easier to create code that can be easily interchanged, I ran into problems with how Flex merges libraries into your code.  To me, the idea of using a separate library is to make it so that you can make changes to the library, without necessarily re-compling the entire application.

When you add a project in Flex Builder under Properties->Build Path->Library Path, by default it will merge your library project into your compiled swf.  While this can make your swf smaller, it can also create problems, such as when your using remoting.

Flex only compiles the classes that it finds links to in your application, even if those classes are in another library that you are referencing.  This causes a problem with remoting, if you don’t use a class type in your application, but that class type is returned as a Strong Type from a remoting service call, you will get a very unfriendly server error.  If you don’t use an RSL, you would need to create a dummy variable for each of those class types, which in a large application can get messy, and I think is messy.

But if you change the Link Type of the library you have added to Runtime Shared Library from Merged Into Code, and check the Automatically extract swf to deployment path checkbox, it will compile the entire library by itself and put it into your bin directory when you compile.  If its a local SWF, there is no need really to create a Digest for the SWF.

Now, you have a compiled SWF which your application references, with ALL of your classes compiled into it.  This can be leveraged in many ways.

One: It can help with Decoupling implementation from contract.  You can compile into your application (via a third library) a set of interfaces which both your application, and your RSL use.  Now, your application doesn’t care about what the actual object is, it only knows that it is using something which implements the X Interface.  In your RSL, you have a class which implements the X interface, and a factory of some kind which spits out your objects.

Two: Dynamic Instantiation.  One of the things that I have commonly done in C# applications is dynamic instantiation of objects via either a config file saying what the class of the object should be, or a database which returns the name of the class.  In Flex, this is practically impossible without using an RSL.  With using an RSL, your application references an interface (as in above), and the database returns the class name of an object that implements that interface.  Then you use flash.utils.getDefinitionByName() to get a reference to a the class TYPE, such as:

var temp:Class = flash.utils.getDefinitionByName(“MyClassName”) as Class;

Now the variable temp is a reference to the class type in which we want, and all we have to do is create an object of that type:

var IInterfaceTheClassImplements = new temp() as IInterfaceTheClassImplements;

Now you have an object which has been dynamically instantiated, from a library which you can swap out every time you create a new object.  This is useful in instance such as a builder which uses Templates.  Create an interface ITemplate, which all the templates implement, create an RSL with all of your Templates in it, and a database which returns the class names of each of the templates.  When you need to create a new template, all you need to do is recompile the RSL with the Templates, drop it in your bin folder, and update the database with the new class name.

Warning:

Remember, the reason Flex merges your code into your applications swf is to decrease the size of your swf overall, and decrease loading time.  If you create an RSL with tons of code and assets in it, you are going to significantly increase your applications loading time.

---

Possibly related posts: (automatically generated)

• Memory Profiling in Flex/AS3 and Performance Centrique Coding

~ by ninjadeveloper on July 31, 2008.