Flex Pasta

Were you at Adobe MAX this year?  Jim Corbett presented on “The Searchable SWF File”.  Google and Adobe came together to create Ichabod, a virtual user that can read a flash movie just as a user would and then index the swf just like an html page.   It appears that the searching of SWF files is still in the early stages, but I thought I would give it a try.  I have a SWF file that has embeded html text in an mx:Text tag.  I want to see if Google can find the inner text and have it appear in search results.

Here is the SWF file:  mx.controls.DataGrid

Now let’s check the results at Google

First, all swf files on this site:

Second, all swf files on this site with a keyword of “Column”:

Third, search the web for mx.controls.DataGrid

Let’s see what happens!

I recently had a request for a heat map created in Flex to display a state by state color coding based on a particular metric.  A coworker and I set out to create the heat map in Flex.   Here is an example heat map: a color coding breakdown of Flex developers working in a particular state.  This heat map shows the number of Flex developers by state(the data is not accurate).

Before I could make a heat map, I needed some mapping api to create a basic map.   I picked Yahoo! Maps because it is easy to understand and has good examples(everyone keeps asking…why not use Google?).  Yahoo! has some nice examples.  One that caught my eye was the Polyline Overlays example.  In Yahoo!’s api, the ability exists to draw a custom poly line over the map.  The code is pretty simple.  You supply the polyline an array of latitude and longitude points the map api graphs the line for you.

_polyline = new PolylineOverlay(0xFF0000, 0.85, 4);
_yahooMap.overlayManager.addOverlay(_polyline);

// disable the mouse so we can still click and drag the map when the mouse is over the polyline
_polyline.mouseEnabled=false;

// set the fill color and fill alpha of the overlay
_polyline.hasFill = true;
_polyline.fillColor = 0xFFFFFF;
_polyline.fillAlpha = 0.60;

// pass latlon values into the polyline data provider to draw the overlay.
_polyline.dataProvider = [new LatLon(47.610015,-122.187029), new LatLon(37.371612,-122.038258), new LatLon(40.714550,-74.007124)];

To make the heat map, I would need the Lat/Lon points for the borders of each state in the US.   To do this, you need a file that contains all of the lat/lons for the borders of each state.  The U.S. Census provides us with a wide library of shape files to download.  If you have downloaded shape zip files, you might be wondering what the heck to do with this binary looking .shp file.  A non-GIS person myself, I had no idea.  Thankfully, a coworker found a flash based application that reads in shape files, renders them on the screen, and allows you to scale down the map to make it less data intensive.  Afterall, there are a lot of nooks and crannies to all the United “States”(10 MB initially in lat/lon data).  And we don’t need it to be exact when we draw the polyline for the heat map, so we scaled the file down to about 80%.  Then you will want to convert the shape files to xml.  Once you have loaded the xml in Flex, you can just convert the data by state into an array.  Then just create a Polyline Overlay for each state with a different fill color.  Now you have a basic heat map in Flex!

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?