Archive for the Flex Builder Category

Framework RSL’s in Flex Builder vs Flash Builder, Performance and Important Info

Posted in Flash Builder, Flex 4, Flex Builder, Flex/AIR with tags , , , , , , , on April 8, 2010 by devgirl

If you are running multiple Flex applications on a server you should seriously consider using Flex Framework RSLs (runtime shared libraries) to reduce redundancy by eliminating the loading of the same core framework libraries used by all applications. The result could be a reduction in the size of your application SWF file to 1/10th of the original size! I recently implemented this approach for Tour de Flex since each of our hosted samples is its own application and would ultimately contain a large amount of code shared by all the other samples. I saw the size of the swf’s for the samples go from 572k to 57k just by making one small change, removing the core Flex Framework RSL’s from the resulting swf.

The good news is, in Flex 4 previously optimized core framework RSL’s are enabled by default and dynamically linked at runtime (versus compiled into the code via the ‘merged into code’ option). This option is specified in the project properties under Flex Build Path. Under the Library Path tab there you will see a Framework linkage selection that should look like the screenshot below and use runtime shared libraries by default. If it does not show that as the default, you can also select Runtime Shared Libraries from the drop-down list to ensure they are used.

Using Flex Builder you will see that the default option is set to Merged into Code, such as the following:

It’s important to understand what is happening here whether you are using Flex Builder or Flash Builder. Obviously with Flex Builder you will need to modify that option if you want to take advantage of the performance gain of having those libraries externalized. However even with Flash Builder and using Flex 4 it’s important to note what is happening, because though the RSL’s are enabled by default, the default configuration settings currently create a copy of the RSL locally for each of the different SWZ files (the extension of the core framework RSL). This means that when you export your release build for your application (File -> Export -> Release Build) you will have a copy of the each of those 6 .swz files created ranging from 60kb to 620kb. The 6 .swz files (release build number will vary) are:

  • framework_4.0.0.14159.swz
  • osmf_flex.
  • rpc_4.0.0.14159.swz
  • spark_4.0.0.14159.swz
  • sparkskins_4.0.0.14159.swz
  • textLayout_1.0.0.595.swz

This may not be a big deal, but in the case of Tour de Flex samples there was no reason to have a copy of these files for every single sample on our server. I thought it would be useful to share this in case others were faced with this same issue or wondering what the heck all those .swz files were in their release directory. If you want to make a change to how this works, you can change your Flex configuration file to point to a different location for the runtime shared libraries other than creating them locally. There are two XML tags that specify an RSL location in the configuration file for each of the shared libraries. The first one points to the official Adobe path where they are located and you should leave that one as is. The 2nd one specifies the failover URL that you would want to change to point to a single location on a server somewhere for instance. For Tour de Flex I modified each of the failover URL paths in the configuration file to point to our Tour de Flex server that had all of those SWZ files (RSL’s) in one location. Then when I compiled each sample (or any application for that matter once these settings are changed, so be careful) it would no longer generate those local .swz files.

Here’s an example of one of the six default RSL path settings from the flex-config.xml file that comes with the Flex 4 SDK. The flex-config.xml file is the Flex configuration file and located on Mac for instance at /Applications/Adobe Flash Builder 4/sdks/4.0.0/frameworks/flex-config.xml:

	 <!-- Spark SWC-->

with these settings you will see the RSL files generated in the local bin-release directory when the application is built for release.

In the case of Tour de Flex, I changed that 2nd tag to point to our TDF Server location. For example:

        <!-- Spark SWC-->

When Flash Builder was then restarted with these settings and a sample recompiled, the local SWZ files were no longer output in the local release directory. IMPORTANT NOTE: if you keep Flash Builder open while you modify your flex-config.xml file you must restart it to pick up the changes. You also may need to delete the bin-release folder of your project first before seeing the change from recompiling.

There is also an option in Flash Builder that will create local copies of the runtime shared libraries in your bin-debug folder by default. If you look at the same Build Path -> Library Path settings in the Flash Builder screenshot above (1st screenshot), notice the checkbox for ‘Use local runtime shared libraries when debugging’, you will see that same set of files (but .swf) generated in your bin-debug output. When you uncheck this box they will not be generated. I thought it would be useful to point this out as well.

The last thing I want to note is that you can also use command line compile to change the option of where to load the RSL file from. Loads of information on how to do that, as well as more information on Framework RSL’s in general can be found here.


The Making of an Eclipse Plug-in – Part 1

Posted in Eclipse, Flex, Flex Builder, Flex/AIR, Java with tags , , , , , , , , on May 4, 2009 by devgirl

I recently had the opportunity to write my first Eclipse plug-in as part of Tour de Flex for Adobe. We had a pretty short deadline for the project and I was a bit hesitant about entering the world of SWT and JFace without previous experience. I did have a good amount of experience coding in Java Swing/AWT previously, but it had been awhile and I had been coding UI’s in Flex/AIR with Java on the server side most recently. Moving back to this “widget-world” was certainly different! I discovered very quickly how spoiled I had been in the Flex/AIR world 😉 I ran into a few kinks along the way in my development that I believe could have easily been avoided and saved me oodles of time had I been able to find some quick information on the web. So now that I have been through the painful task of figuring out how to code, build, package and test an Eclipse plug-in, I decided to write a series of posts to explain the steps I took in creating my plug-in as a sort of quick reference and cut to the chase, as I found myself sifting through a lot of information to find the nuggets I needed.

Before I begin, there are two books I found particularly useful in tackling this project. They are:

Eclipse Building Commercial-Quality Plug-ins
The Definitive Guide to SWT and JFace

The View

An Eclipse ‘View’ is basically any of the UI tabs within your Eclipse environment, so for instance your Project Explorer, the Console, or the Problems window, that you can drag around to customize your environment. My Tour de Flex plug-in was all contained within one view, so the main things I needed to figure out were all the events and behaviors around showing, closing and sizing a custom Eclipse View panel. A screenshot of my Tour de Flex plug-in view is shown below.


And by the way, if you don’t know about Tour de Flex or what the plug-in does, I HIGHLY recommend checking it out! Tour de Flex is a great tool for developers, full of code samples that showcase the language and how to use it. The plug-in can run in either FlexBuilder or Eclipse, and allows you to search code samples provided by Tour de Flex. Double-clicking on a search result will open the Tour de Flex AIR app right to that particular code sample where you can then find out more info or copy/paste code right into your IDE. Instructions for downloading the Tour de Flex plug-in and more information about this useful application can be found here.

Coding a Sample View

Fortunately Eclipse makes it pretty easy to get started in building a plug-in via a wizard. Using this wizard ensures the necessary base packages needed for a view are included, and includes some sample code to help get you started. To use this in Eclipse, click File | New | Project, and then find the Plug-in Development folder and select ‘Plug-in Project’ from the drop-down menu.


You will then be prompted with the following screen, where you will enter the project name and location desired and leave the default selections unless you need to change the required Eclipse base version etc and hit ‘Next’.


The next button will take you to the ‘Plug-in Content’ dialog, where you will stick to defaults once again (except name changes as desired), and leave the default boxes checked. From here you will again click the ‘Next’ button.


On the following screen select the ‘Plug-in with a view’ option and go through the resulting panels indicating any names changes you might want for your plug-in, otherwise sticking with defaults. For the viewer type, you have two options which apply to the sample code that is contained within your view. You can choose a Table View or Tree View, and this will depend on your own personal view needs. In my case I used the table view and modified it as needed. Lastly hit ‘Finish’ and you will see a new project created with various files and folders needed for your plug-in. Screen shots of those wizard dialogs are shown below for my sample:


To see what the sample plug-in you just created looks like, or to test any plug-in for that matter, you can right click on the project in the Package Explorer and select the ‘Run as… Eclipse Application’. This will actually open a new running instance of Eclipse with your plug-in activated in that instance. Another way to test/run it is from the ‘Overview’ page of the plug-in that was created, under the ‘Testing’ section, via the option that says ‘Launch an Eclipse Application’. This page is your entry into all of your plug-in settings, and you will see tabs at the bottom that allow you to flip through each page of settings. More about these settings and how to use them will be explained in Part 2 of this series.


So now that we know how to launch an Eclipse application for testing our plug-in, we need to go into that instance to find our new view. Once in the test Eclipse instance, go to the ‘Window’ menu and find the ‘Show View’ option. This will bring up a list of all the view categories, and you should now see your new category in the list, and under it your sample view. Once you find your newly created view, select it and hit the ‘OK’ button.


The new sample view will be opened immediately for you to see with a basic table as shown in the screenshot below.


Congratulations! You have just learned how to create your first basic plug-in! In Part 2 I will take a deeper dive into the files that were generated as a result of the above, discuss some caveats to watch out for during coding, and also take a closer look at the plug-in settings tabs.