Flex Pasta

If you’ve dealt with item renderers in any kind of complexity, you’ve probably run into scroll bars gone wild.  Problems usually start happening when you have a list based component that needs to scroll, and each item may have a variable row height.  Painful symptoms of scroll bars gone wild include: text being cut off, scrolling becoming choppy, or lots of inner scroll bars appearing and disappearing.  A really easy way to run into problems with item renderers is by using images that are loaded by a url at runtime.  Take a look at the following simple example that uses mx:List to show a description next to a dynamic image.  Try scrolling with the down arrows and scroll thumb to see the less than desirable results(note there are 4 items in the list).

There are many ways to tackle out of control item renderers.  In this case, it’s a Repeater For the Win!  Take a look at the identical application using an mx:Repeater tag instead of mx:List.  The scrolling is smooth and the down arrow works!

The draw back to using the mx:Repeater tag is that there is no item recycling.  Meaning, unlike using an item Render, which will be reused when I scroll, the mx:Repeater will draw everything at once.  For small lists, using a repeater tag should be ok, but for large data sets, a repeater tag could cause memory problems.   Also note, one other benefit to using the repeater tag in this instance is that the images are loading once.  In the first example, the item renderers are being recycled as scrolling occurs, this means the images are reloaded everytime they appear on the screen.

It’s tax season here in the US until April 15th.  I decided to get an early start.  I opened up TurboTax(tax software).  After entering some numbers, you will notice the little “Federal Refund” ticker at the top that keeps a running total of the money you will get, or owe, based on all the numbers entered.  The refund ticker also has a cool animation on it when it goes up or down.  I quickly got bored of doing my taxes and instead decided to write the little number changer component in Flex.

<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml” layout=”vertical”>
<mx:Script>
<![CDATA[
[Bindable] private var currentNumber:int = 0;
private var difference:Number;
private function buttonClick():void
{
difference = numberInput.value - currentNumber;
timer.addEventListener(TimerEvent.TIMER, timerExecute);
doTimer();
}
private var timer:Timer = new Timer(1,0);

private function doTimer():void
{

if(currentNumber<numberInput.value && difference >0)
{
if(numberInput.value-currentNumber < difference/350)
{
currentNumber = numberInput.value;
}
else
{
currentNumber+=difference/350;
timer.start();
greenGlow.play();
}
}
else if(currentNumber>numberInput.value && difference <0)
{
if(currentNumber - numberInput.value < difference/-350)
{
currentNumber = numberInput.value;
}
else
{
currentNumber-=difference/-350;
timer.start();
redGlow.play();
}
}
else
{
timer.stop();
greenGlow.stop();
redGlow.stop();
}
setColor();
}
private function setColor():void
{
var newColor:String = currentNumber>=0?’green’:'red’;
if(currentNumber==0)
newColor = ‘black’;
numberLabel.setStyle(’color’, newColor);
}
private function timerExecute(event:TimerEvent):void
{
doTimer();
}
]]>
</mx:Script>
<mx:CurrencyFormatter id=”currencyFormatter” precision=”2″ useThousandsSeparator=”true”/>
<mx:Box id=”box” borderThickness=”1″ borderStyle=”solid” backgroundColor=”#FFFFFF” borderColor=”#000000″ dropShadowEnabled=”true” width=”200″ horizontalAlign=”right”>
<mx:Label id=”numberLabel” text=”{currencyFormatter.format(currentNumber)}” fontWeight=”bold” fontSize=”22″ creationComplete=”setColor()” fontFamily=”Courier New”/>
</mx:Box>
<mx:Glow color=”red” id=”redGlow” target=”{box}” duration=”1000″/>
<mx:Glow color=”green” id=”greenGlow” target=”{box}” duration=”1000″/>
<mx:Spacer height=”100″/>
<mx:NumericStepper maximum=”10000000″ id=”numberInput” value=”20000″ minimum=”-1000000″ stepSize=”1000″/>
<mx:Button click=”buttonClick()” label=”Render”/>
</mx:Application>

It has been about a year now since Adobe announced it was open sourcing the Flex SDK, BlazeDS, and the Flex Compiler.  Today on my way home, I started thinking about improvements to the Flex Open Source Adobe that I would like to see in the future.

5.  Upgrade LCDS/BlazeDS to Java 5.

I am not sure the reasoning for having BlazeDS written in Java 1.4.  Most projects using Flex are going to use Java 1.5 since they are most likely newer software.  If for whatever reason, BlazeDS to Java 5 is not viable, at least create a separate Java 5 project that extends the BlazeDS code base.  This project could use features of Java 5 to give developers more tools.  In particular, annotations with remote objects would be a huge advantage for developers.  Bean property configuration, service method security, better enum handling, code generator support, etc would all be great.

4.   Bring the Flex Compiler Source Code out from the shadows

After attending MAX last month, I heard little about improvements to the Flex Compiler for Gumbo.  I guess the compiler isn’t the sexy part of Flex so maybe that is why.  But the compiler is just as important as the Flex SDK itself, so I would love to understand how it works.  I think the community would benefit with more exposure to the compiler code base.

3.  Make it easier to set up the Flex SDK, BlazeDS, and the Flex Compiler for local builds

The most looked at code base of the three components is probably the Flex SDK, just because we can hit F3 in eclipse and go look at the source code.  However, how many people out there(other than Adobe employees) know how to check out the source code for the Flex SDK, BlazeDS, and the Flex Compiler and then be able to make changes to the code?  I have been able to do it for the Flex SDK and BlazeDS, but it took some time(I also don’t think my config was ideal).  I spent a couple of hours trying to figure out the Flex Compiler with no luck.  I am hopefull for a little documentation for those of us out on an island trying to set it up.

2.  Improve the ability to run different versions of the Flex SDK

If you go out and download Flex Eclipse plug-in site today, you will probably get Flex version 3.2.  The rest of the development team might be using another version; say version 3.0 on the project.  Figuring it might be a good idea to have the same version of Flex as your coworkers, you visit opensource.adobe.com to download version 3.0.  The nice interface in FlexBuilder lets you have multiple Flex SDK’s installed and you can easily flip the compiler between different versions of the SDK.  One problem: Charts.  When you download the plugin, you get the charts bundled with the source code, but when you download releases from the open source page, charts are left off(I’m not sure the reason).  This means a project using charts won’t compile for you without some hacking to get it to work.

1.  Avoid using mx_internal/private in the Flex SDK

There are important instances where the private keyword is usefull(when I don’t want a subclass to override it or even be able to call it).  However, and I admit to doing this as well, we tend to use the private keyword by default when we don’t want a method to be public.  The protected keyword would be a much better option for the majority of methods in the Flex SDK.  I have found it difficult at times to extend Flex components and even BlazeDS code because the methods are private or mx_internal.   Maybe it was the intent of the authors to keep these methods private to avoid future upgrade hassles, but it can be problamtic to extend them.  My latest example of one such problem involves creating a ColumnChart.  I created the chart and had a ColumnSeries.  The chart was simple and I set the properties  labelAlign=”center” labelPosition=”outside”.  I was wanting to center the labels at the top of the bars on the outside.

As you can see in the picture, the labels are left aligned.  The as-doc states that labels on the outside can only be left aligned.  I want to try and extend column series to get the labels in the middle.  I find the method:

private function renderExternalLabels

I can’t extend it since it’s private.  Ok, so I find where renderExternalLabels method is called.

mx_internal function updateLabels()

This goes on for four or five methods before there is one that can be extended.  The point is that marking methods protected more aggressively can help everyone out who is trying to extend these components.

Those are my top five wishes for Flex Open Source.  What are your wishes?

There is no compile or run time error, but executing the following code will not work.  I knew this going in but wanted to try it just to see what happened:

<mx:TabNavigator>
      <mx:Text text=”Tab 1“/>
 </mx:TabNavigator>  

The reason it doesn’t work is because a tab navigator requires its children to be of type container.   There is a simple fix, one that requires more work

<mx:TabNavigator>
<mx:Box label=”Tab 1“>
<mx:Text text=”Everything else“/>
</mx:Box>
</mx:TabNavigator>  

I don’t want to wrap a box around all ten of my tabs!  One solution is to do the following:

1. Create a new Actionscript class called BoxText.as which extends Box.
2. Make a bindable property text:String in the Box.
3. Add an event listener for FlexEvent.CREATION_COMPLETE.
4. When creation complete occurs, simply add the text to the box.

Here is the output for BoxText.as:

package
{
import mx.containers.Box;
import mx.controls.Text;
import mx.events.FlexEvent;

public class BoxText extends Box
{
public function BoxText()
{
super();
this.addEventListener(FlexEvent.CREATION_COMPLETE, creationComplete);
}

private function creationComplete(event:FlexEvent):void
{
_text.text = text;
this.addChild(_text);
}

[Bindable]
public var text:String;
public var _text:Text;

}
}

Now I just use my component in the TabNavigator. It saves time and clutter!

<mx:TabNavigator>
<local:BoxText label=”Booyah” text=”My Text to show in the Tab“/>
</mx:TabNavigator>

Adobe opened source the Flex SDK since the 3.x release. Not only does this gives Flex developers the ability to see the source code and understand how the SDK works, but it also allows the community to provide bug fixes and enhancements. Adobe has said publicly that they would like to create sub projects from the Flex SDK that the community can contribute. The open source of the Flex SDK gives the community the fire power to submit code bug fixes. Developers should try and fix bugs in the SDK when they come across them. The following tutorial shows how to set up a Flex Project and have it build against the Flex SDK source code. These steps will allow a developer to make changes to the Flex SDK and build the project to see the changes.

1. Download and install Tortoise SVN. Tortoise is an open source subversion client that is needed to download the Flex SDK from the adobe repository.
2. Right click on a folder and click Checkout from the context menu.
3. The Toroise SVN screen should appear. Enter the URL of the repository. At the time of this being published, the URL is http://opensource.adobe.com/svn/opensource/flex/sdk/trunk.
4. Once the download of the source has completed(it takes a while!), open Eclipse.
5. Import the framework project. File > Import.
6. Press Next. Find the root directory where trunk is checked out, and enter this plus development\eclipse in the Select root directory box. This will show all of the Flex SDK projects.
7. Leave all of the projects selected and click finish.
8. Setup a linked resource variable in eclipse called FLEX_SDK and which points to the root directory of the SDK. Window > Preferences > General > Workspace > Linked Resources.
9. Enter FLEX_SDK as the name and the location where the Flex SDK is checked out. Press OK and then close the preferences window.
10. Right now the focus will be on only building the framework project. Go ahead and close the other ones. Right click on them and select close project.
11. At this point there should be no errors or warnings in the problems window. A clean might be required. Select Window > Clean and select the framework project.
12. Create a blank Flex Project. File > New Project > New Flex Project
13. Enter a project name and press Finish.
14. Now the FlexSDKTest project is setup, however, it is running against the compiled and installed version of the Flex SDK. To be able to make changes to the SDK source, the FlexSDKTest project must use the framework library project as its parent. To do this, right click on the FlexSDKTest Project and select properties, then select Flex Build Path > Library path tab.
15. Select the Flex 3 library and remove it. Click Add Project and select the framework project from the list. 16. Press the Add SWC button. Find the playerglobal.swc for the version using. The path usually is ${FLEX_SDK}/frameworks/libs/player/9/playerglobal.swc.
17. Press the OK button to close the properties window. Everything is set up to run code directly against the framework source. Just to make sure, run a simple test. Add a button to the FlexSDKTest application.
18. Open Button.as in the framework project. In the set label function, add code to the label’s value that modifies it: value = ‘I can change the SDK source code! BOOYAH!!!!’;
19. Save the file and build the projects. Run the FlexSDKTest application. The button’s label should read “I can change the SDK source code! BOOYAH!!!!”.

That’s it!! It’s off to the races for submitting enhancements and bug fixes to the Flex SDK repository. The flex bug tracking database can be found at http://bugs.adobe.com/flex/