Flex/Flash/Actionscript

Monkey Patching FlexSprite to list all event listeners on any Flex component

A while back Ben Clinkinbeard asked a question on flexcoders saying “Am I the only one who wishes EventDispatcher exposed its listeners?” The fundamental issue was that he wanted to get a list of all the event listeners that had been added to a given component.

The approach: using FlexSprite
Someone suggested monkey patching UIComponent to add this functionality, since each UIComponent gets notified each time a call to addEventListener is called, and you could keep track of the references locally. The thing is, monkey patching UIComponent is kind of a pain in the ass since it’s such a big class. When you monkey patch a class you basically need a complete copy of the whole class in your code so you don’t lose the functionality of that class. It’s perfectly doable with UIComponent, but gets kinda nasty.

So I was looking for an alternative and realized that the beautifully small FlexSprite class, which is the lowest level class you can get source code for (everything above it like Sprite, etc is built into the player). FlexSprite is under 100 lines of code and almost all of that is comments. When you get down to it there’s only a constructor and a single method in FlexSprite. So that makes it super duper easy to monkey patch the bastard. To refresh everyone’s memory the inheritance goes: Sprite -> FlexSprite -> UIComponent.

So if you’re trying to add in functionality that will trickle down into every component in the Flex framework, and you don’t need stuff specific to UIComponent, then the easiest way is to monkey patch FlexSprite.

The result
The good news: you can get a list of every event listener that is currently added to any component (at least anything that inherits from FlexSprite). This list will tell you the main details of the listeners, like type (ie “change”, “click”, etc), priority, useCapture, and useWeakReference. You also get the time when the listener was added (which is stored using getTimer to indicate the number of milliseconds since the app launched).

So now anything that inherits from FlexSprite (every display object in the Flex framework) has the following additional property and methods:

  • eventListeners – returns an Array of every event listener currently registered with the component. The Array contains ListenerTracker objects, which is a new class that simply holds the details of the listeners (like priority, etc).
  • removeEventListeners(type:String) – this will remove all event listeners for a given event type. You don’t have to have the reference to the actual listener function to remove it.
  • removeAllEventListeners() – removes all event listeners of all types. This completely wipes out all event listeners for the component all at once.

Here’s a very simple demo application that simply adds a button via MXML and shows all the event listeners on that button in a DataGrid. You can click the bottom button to remove all the listeners on the top button, which will effectively disable all interaction with the button, which should make sense.

This movie requires Flash Player 9.

Simple example | source

The bad news: so you get the function that was added as the listener, but you can’t get anything useful out of this, like the actual function name in the code. You also can’t get the name or reference of the object that contains the function, or that made the call to addEventListener. So that blows.

UPDATE: We can actually get the name of the class that called addEventListener(), the method name where it was called, and the exact line number. See my post about a sneaky trick to do this.

Basically you can see how many listeners of each type (and priority, etc) there are and you can remove any individual ones (or all of them at once). But we are not being able to get much information about a Function object itself. In the addEventListener function we get passed a Function, but you can’t get any more information about that object (see the listener column in the above example, it just shows the “function Function () {}” string, which doesn’t help at all). I’ve tried using describeType() on the Function and everything else I could think of but couldn’t figure out how to get any additional useful information about a function. If anyone has any ideas shoot me an email to let me know.

A cooler example
So I remembered seeing a pretty badass Flex library that let you explore all the properties and styles of any ui components in your application. I went back and found it, it’s called flexspy and is a project hosted on Google code created by Arnaud Pichery. So that’s cool, you drop the FlexSpy swc into your app and suddenly you get access to this cool real-time property and style inspector. (BTW, FlexSpy is licensed under the Do What the Fuck You Want To Public License, ha, awesome)

So I went and extended the FlexSpy component and added my own Event Listeners tab to the main inspectors. Now when you launch my version of FlexSpy you can see all the event listeners on whatever component you select. Dope. I added in buttons to let you remove any individual listeners, or all the listeners for any particular component. Here’s a screenshot, and the links to the example app and the source (view source is also enabled on the app).

screenshot0021.jpg

Enhanced FlexSpy demo | source

Standard
Flex/Flash/Actionscript

Followup about Flex Panel bug

I want to start off with a quick recap of the current status of the bug I wrote about a few days ago. The Flex 3 Panel bug that resulted in the content of a Panel overlapping the title bar of the Panel has been fixed. The fix will be in the final Flex 3 release. The bug report that shows this status is here: Issue 11279, which is now marked as a resolved bug. I want to point out that I was told (with proof) that Adobe recently started re-investigating this bug on their own about a week before I posted my rant (although that was never exlained in the bug database).

I also want to take a second to address what was seen as me being an asshole with what Matt Chotin called my “strongly worded criticism.” 🙂 I also received another email from a Flex team member with a similar sentiment letting me know that I may have been a bit harsh and that I need to remember that the engineers working on the framework are good guys trying to do the best job they can for us (the customers). I’ve met Matt personally a few times, and I deeply respect him and all the Adobe engineers working on Flex. I didn’t mean my little rant to come off as a personal attack on anyone, although I realize that since I was targeting a very specific bug that that means it falls under the responsibility of a few individuals. My harshness was a result of frustration and a misunderstanding of Adobe’s perspective, there was never meant to be any direct blame placed on individual engineers. And so with that, here’s my olive branch:

921-i_love_you_teddy_bear.jpgDear Flex team, I love you all. Your work is greatly appreciated. You make it possible for me and many other people to do work that we love. You’ve delivered a fantastic product and the overall intelligence of the team shows through in the great code base of the Flex SDK. Keep doing your jobs. Even though I may criticize, I mean it with love and respect.

OK, everyone feeling all warm and fuzzy inside? Cool, let’s all get back to work.

Matt Chotin addresses what to do if you run into similar issues like this Panel bug, where you don’t feel the Flex team addressed the issue adequately. He mentions that you will be able to vote on closed bugs in the future, so once that is in place you can still vote on a bug even if it has been marked as NAB, and the Flex team will be able to see which ones have the most community involvement. Until then your options seem to be leaving comments on the closed bug (which in this case meant 4 or 5 independent bug reports of the same issue) and emailing the Flex team, which I think means email Matt, since I can imagine that they don’t want all the engineers dealing with trivial requests from the community all day long.

That said, I’m not sure if I had dealt with the bug differently (ie simply posted a comment and emailed Matt) that it would have gotten fixed so immediately. While I understand that internally Adobe was re-investigating this bug, my hunch is that without the public bitching there would not have been a fix committed for the final Flex 3 release (feel free to correct me if I’m wrong). A single comment on a bug report and an email to Matt likely would have gotten it on the radar (although it already was), but I’m guessing we wouldn’t have seen such immediate action. So perhaps I should have phrased my previous post in a better way, and simply called attention to the bug to try to get others to comment on it so they would reopen. But I think there is certainly a place for publicly posting issues like this, since it’s an effective way to rally the troops and clearly articulate the issue (what was I going to do, write a 2,000 word comment in the bug database?). So in the future I’ll try to be a tiny bit more diplomatic with how I write posts like that.

So thank you Adobe for the quick action in response to this issue.

Standard
Flex/Flash/Actionscript

Calling bullshit on a “resolved” Flex bug

When Flex 3 was first released in beta you may have noticed a bug having to do with the Panel component when you set borderStyle to anything other than “default” (which funny enough, isn’t even a code-hinted option in Flex Builder). The issue was that the Flex 3 SDK laid out the Panel contents on top of the title bar, so the content ended up overlaid on the title and it would generally look like total crap. Basically if you had a Flex application that used the solid (or inset or outset) borderStyle on Panel to style your application, suddenly when you upgraded to Flex 3 your app looked really bad. Since Alert and TitleWindow extend Panel this affects those components too. You may have seen things in your app that looked like this:

firefoxscreensnapz026.jpg

Yeah, that sucks.

So I figured this was one of those bugs that would get reported quickly (it did) and fixed quickly (it did not and will not). There are 4 duplicate reports of this issue in Adobe’s bug tracking system, the first one was reported June 13, 2007. Here are the 4 issue reports:

They’re all the same thing, and they each have example screenshots or SWF files that show how bad the resulting bug looks.

The bugs have all been marked as Not a Bug. And this is the explanation for this resolution:

After some back and forth discussion, Glenn and I have decided that Panel will no longer support any borderStyle besides “default”. The reason is that in order to support the other borderStyles, we would have to put in the hacks that were in Panel back in. This would make it more difficult to skin Panel using graphical skins.

Panel will support other borderStyles when using the backwards compatibility flag. In addition, it will be possible to use a combination of explicit heights/widths and absolute positioning to replicate most of the old behavior for alternate borderStyles.

PanelSkin’s implementation of alternate borderStyles will be mostly working, but won’t layout the header and control bar in the correct locations, nor will it size the Panel to be large enough. We need to document these issues.

In the release notes there will be a line that reads:

Release Note: Panel only officially supports the “default” borderStyle. If you use an unsupported borderStyle, use padding values or absolute positioning to place your content in the correct place.

I call bullshit. This is not an acceptable resolution.

Why bullshit? Let me count the ways.

  1. You should never be able to make a Panel that has the content overlaid on top of the title bar. That is fundamentally against the definition of what a Panel is. A Panel has a title bar ABOVE the content area. ALWAYS. If the content area overlaps on top of the title bar then something is wrong. If the answer is that Panel will not layout the contents correctly unless the borderStyle is default, then you should not be able to set it to anything other than default (which is not a good resolution either, but at least it wouldn’t produce such crappy looking Panels).
  2. This worked very well before, was there ever a single person who complained that the Panel didn’t lay out its contents correctly? It did exactly what it was supposed to do, which is to lay out the content below the title bar.
  3. The default Panel skin gets old quickly, and we want to change up the look of the Panel. Used to be that you could just set borderStyle to solid and make some nice looking Panels that didn’t have that same opaque content area with semi-transparent border look. Now those decent looking Panels you styled in your old app are harder to make.
  4. I don’t buy the argument that “The reason is that in order to support the other borderStyles, we would have to put in the hacks that were in Panel back in. This would make it more difficult to skin Panel using graphical skins.” I guess the issue is with graphical skins as opposed to programmatic skins. PanelSkin returns border metrics that are used to layout the Panel’s contents (ie place them below the title bar by checking the headerHeight of the Panel). That code seems kinda hacky to me already, it means that the layout of the children in Panel is determined by a programmatic skin. But if PanelSkin is returning the border metrics used in Panel to layout the children then it could easily do so for the other border styles too. This would at least solve the problem when using the default PanelSkin (which must be the bulk of what people do). Maybe I don’t understand the issue with graphical skins, but let’s say you’re using some graphical skin to skin Panel, when would you ever want your Panel to have the content area overlap the title bar? Never. I just don’t get it.
  5. The “solution” for people that want to use the “unsupported” border styles is to set the paddingTop style to be the same or greater than your headerHeight, which will force the content to be placed below the header. But wtf kind of solution is that? We have headerHeight for a reason, and that reason is so the content gets placed below headerHeight pixels from the top. This just sounds like an answer of “well, you can hack your way around it, so that’s good enough.”

So basically I’m just bitching, because this bug will likely just stay “resolved” and be released in Flex 3 when it ships with a little release note to warn people to not do what they will invariably try to do. I don’t know if there is a formal thing I should do to try to get someone at Adobe to reconsider, the bug was filed 4 times and all are marked resolved. I assume if I submit a new one it will be marked as a duplicate and resolved. Sigh.

Oh, and Flex for Dummies will have a sentence similar to this:

WARNING: If you set a Panel’s borderStyle style to anything other than default then you must also set the paddingTop style to at least be as many pixels high as your title bar. The default implementation of Panel with borderStyle set to anything other than default sucks.

Standard
Flex/Flash/Actionscript

Writing Flex for Dummies!

I’m happy to announce that together with Deepa Subramaniam I’m writing Flex 3.0 for Dummies! We’ve begun writing and the tentative publication timeframe is “late spring/early summer” of 2008. The book will be published by Wiley and is the first Flex book in the For Dummies series. This is our first full-length book writing experience, and I’m both excited and nervous to take on the project. As things progress I’ll try to document the writing process here on my blog a bit. The book will be a beginner’s guide to learning Flex, and we hope it will fill an important gap in the currently available learning resources. We’re trying to make it easier than ever for new developers to jump into Flex.

For a little fun, here’s a random collection of Dummies books you can toss around:

This movie requires Flash Player 9.
Standard
Flex/Flash/Actionscript

The making of TileUI

I’ve posted a video that shows the progress that I made during the first 12 days of working on TileUI. For about the first 2 weeks I saved a snapshot of the progress I had made (I tried to save a snapshot each day, but I missed a few). The video below is a combined video of each of these, it starts at day 1 and goes through day 12.

I stopped taking daily snapshots (and I stopped making much progress) after the first two weeks because I started working on a contracting gig. I’ve gotten much further with the software now (as the previous AIR demo video shows). But I’m not making the day to day advances like I did the first few days (man, if only I could be unemployed forever).

Here’s a quick breakdown of how things went:

Day 1: Learn Actionscript Physics Engine. By the end of the day I had a decent physics simulation running that allowed me to throw around particles. Prior to this project I had never worked with APE, it’s a solid physics engine (my only complaint is how CPU intensive it is).

Day 2: Learn PaperVision 3D. Combine PaperVision with APE. Prior to this I hadn’t played with PV3D and I figured it was about time I learn. By the end of the day I had figured out the basics of PV3D and managed to map APE particles to 3D tiles in PV3D. Damn, these libraries are good.

Day 3: I got the tiles to display images. And I got the basic selection system working where you can lasso a set of tiles and they get grouped. The group was just a messy group of tiles, but it was a start.

Day 4: Added Flickr support to load tiles straight from Flickr. Added dynamic sizing of tiles.

Day 6: Made grouping tiles put them into 3D stacks. Added double clicking tiles to do something based on the tile content, ie open larger Flickr image. (I don’t remember why I don’t have a day 5 or 8 snapshot)

Day 7: Improved Flickr support, ability to page through results, load multiple search results, etc. Added spiral stack.

Day 9: Added the menu system. Added the twist menu item to twist a stacked pile. Allowed breaking piles you made.

Day 10: Added the fan layout method.

Day 11: Added the grid layout method.

Day 12
: Added the leafing layout method.

So what?
I thought this was cool because it shows a) how awesome and fast developing in Flex/AS3 is and b) how badass open source community libraries for Flex are. I was able to grab these open source libraries and within a few days have something pretty sweet to show for it. A big thanks to everyone behind the PaperVision project, and to Alec Cove for the APE engine. You guys make this stuff easy.

At last count I am using 10 different open source libraries in the TileUI project in one way or another.

Standard
Flex/Flash/Actionscript

ImageSnapshot class in Flex 3 SDK

There are a few new graphics classes in the Flex 3 SDK that make it easier to create image snapshots of Flex UI components. The ImageSnapshot class provides some static methods for creating snapshots of components and encoding them as PNG or JPEG images. In addition to the ImageSnapshot class, we also get the PNGEncoder, JPEGEncoder, Base64Encoder, and Base64Decoder, which were all previously in the as3corelib project.

mx.graphics.codec.JPEGEncoder
mx.graphics.codec.PNGEncoder

The JPEGEncoder and PNGEncoder classes were in the as3corelib project prior to Flex 3. They have since been rolled into the main Flex framework. Nice! They’re pretty straightforward, and they’ve been around for awhile in the as3corelib project, so they shouldn’t need much explanation.

mx.graphics.codec.IImageEncoder

The IImageEncoder interface defines an interface for a class that encodes a BitmapData object or the raw bytes of a Bitmap into a new encoded ByteArray. The two classes that implement this interface are PNGEncoder and JPEGEncoder. If you were to write your own image encoders you could implement this interface and then you could pass your custom encoder to ImageSnapshot.captureImage() (read below for more on that).

mx.graphics.ImageSnapshot

The ImageSnapshot class is a new addition to the Flex SDK that simplifies the process of capturing an image from a Flex UI control. This is a task that is often performed, I can think of a bunch of examples right off the top of my head where I’ve had to do this. A live reflection class is one candidate to use this new helper class. I have a feeling a big use of this class is going to be saving image snapshots to the user’s computer in an AIR application. And another use-case that I recently dealt with is converting a Flex UI component to a Base 64 encoded image (see my previous post).

When I needed to get a Base64-encoded string of a given Flex UI component I did something like this:


private function getBase64String(component:UIComponent):String) {
	var bitmapData:BitmapData = new BitmapData(component.width, component.height, true, 0xffffff);
	bitmapData.draw(component);

	var bytes:ByteArray = PNGEncoder.encode(bitmapData);

	var b64encoder:Base64Encoder = new Base64Encoder();
	b64encoder.encodeBytes(bytes);

	var b64String:String = b64encoder.flush();
	
	return b64String;
}

But now we have a much easier way. The ImageSnapshot class has a few static methods that we can use. We get:

captureBitmapData
This is the utility function that returns a BitmapData object. This basically saves us a line of code and simplifies the call. Dimensions are capped at 2880 pixels for each side.

captureImage
This returns an ImageSnapshot object. That doesn’t get us all that much, but there are a few pretty cool things. We can pass captureImage a parameter that tells it how to encode the image. PNGEncoder and JPEGEncoder have been rolled into the framework now, so we can pass in either of those and it will encode the image as a PNG or a JPEG.

Once we get the ImageSnapshot object that the static method returns then we can access the byte data of the encoded image with the data property. Then we could pass the JPEG or PNG encoded image to a server to save the file, or if you’re writing an AIR application you could save the file to the hard drive (or drop it onto the clipboard).

encodeImageAsBase64
This function takes an ImageSnapshot object and encodes it as a Base 64 string. Easy enough.

So to go back to the sample code above, now we can generate a Base 64 encoded string like this:


private function getBase64String(component:UIComponent):String) {
	var snapshot:ImageSnapshot = ImageSnapshot.captureImage(component);
	var b64String:String = ImageSnapshot.encodeImageAsBase64(snapshot);

	return b64String;
}

and if you’re too good for three lines of code:


private function getBase64String(component:UIComponent):String) {
	return ImageSnapshot.encodeImageAsBase64(ImageSnapshot.captureImage(component));
}

Bypassing the 2,880 pixel limit
Flash Player has a limitation of only allowing a single bitmap object to have a max width or height of 2,880 pixels. I’ve never run into this problem, but I guess people with massive monitors can have a problem. The ImageSnapshot class does some fancy footwork in the captureImage method that allows you to generate an encoded JPEG or PNG snapshot that is larger than 2,880 pixels. Basically it creates multiple BitmapData objects and stitches them together to form one final ByteArray. Look at the source code for ImageSnapshot and check out the captureAll method.

This gets around the 2,880 pixel limit, but there’s a 256 meg size limit on a single ByteArray object. From the documentation in the ImageSnapshot class: “This ByteArray is limited to around 256MB so scaled images with an area equivalent to about 8192×8192 will result in out of memory errors.”

So nothing groundbreaking here, but we get to save some boilerplate code that we used to have to write to generate a BitmapData object from a Flex UI object, or to generate the bytes of an encoded JPEG or PNG image. I’m guessing a big reason for Adobe including this in Flex 3 is to make it easier to save JPEG or PNG snapshots of charts in an AIR application.

Standard
Flex/Flash/Actionscript

Compare Flex SDK version 2.0.1 with version 3

UPDATE: Well shit, turns out that posting the source of the almost-open-source-but-not-quite-yet Flex SDK is a no-no for now. I assume once the Flex 3 SDK officially goes open source this will be OK, but for now I’ve been asked by Adobe to take it down. As you say master.

I’ve set up a project using Trac (if you don’t know what trac is read here) that allows you to compare the source code of the new beta release of the Flex 3 SDK with the previous Flex SDK 2.0.1 version. This lets you browse all the changes that were made and visually see the differences. I find this very useful when trying to analyze the new release and figure out what the new additions and changes are.

Here’s a link to the main Trac website.

You can view the entire changeset from version 2.0.1 to version 3 here. (Warning: it’s pretty big so it might take a bit to load).

If anyone from Adobe doesn’t like this and wants me to take it down just let me know. I think it’s valuable for the development community, but if you’ve got a legal fever and the only remedy is to yell at me, then I’ll remove it. Email me here: doug@dougmccune.com.

Standard
Flex/Flash/Actionscript

My thoughts on Flex 3 features – Part 3

This post discusses the features Ted Patrick blogged on Wednesday: the Advanced DataGrid component, Deep Linking, Resource Bundles for localization, and the Flex Component Kit for Flash CS3.

Advanced DataGrid (I would’ve called it SuperDataGrid)
This is basically what the community has come to call a “TreeGrid”, plus the addition of more control over the headers, and summary rows and cells. It’s certainly a component that has has been asked for like mad. I’ve seen a few versions of a TreeGrid component out there (like the one in FlexLib). As far as I know this component’s a hard one to get right, I know the FlexLib version has quite a few issues, so it’s good to see that Adobe’s been working on a solid version themselves. I’ll be interested to dive in and see how they did it (ie I assume DataGrid as the base, but do they use the Tree control? or did they cook up an independent Tree control for use within the DataGrid? Is the original DataGrid component untouched?). I’ve never seen anyone add summary rows to the DataGrid component, but I’ve heard people request this a lot, so I’m sure this will get a lot of use as well.

I’ve said before that the DataGrid stuff doesn’t get me excited. This is a component lots of people have wanted, so that’s cool, and I bet I’ll find a use for it (like in my AS code analyzer app for sure), but if this never existed I wouldn’t cry myself to sleep. It’s a cool and requested component, but I mean, that’s what we get for UI components? Two layout components and a better DataGrid? I know a couple people on the SDK team, they’re smart, they can make really cool shit (I mean, the Flex 2 SDK was frickin amazing). This is what they’ve been spending their time on since the release of the Flex 2 SDK? Bugfixes and a DataGrid? Being a component developer on the Flex 2 SDK seems like it would’ve rocked. Flex 3 SDK? mm, not so much.

Granted, we’ve had some good components come out of Adobe (or Adobe Consulting) since the release of Flex 2, like the Scheduling Framework, Auto-complete TextInput, Docking Toolbar. And Ely Greenfield has put out mindblowing stuff. So in my ideal bountiful-component world? Take Ely and get him working with Alex Uhlmann and the rest of the Adobe Consulting peeps to crank out components. The amount of stuff they could put out in a year would be amazing. Ely, you hear that? Enough management and planning, stop writing specs, take a pay cut and demotion and start writing code again!

Deep Linking
That’s cool, I don’t know if any of the apps I write will use deep linking, but it’s good that it’s available and easy to use. But most of the discussion around deep linking is about SEO. An important part of deep linking support is that Flex/Flash apps need the ability to present multiple unique URLs to search engines for them to index. The inclusion of deep linking on its own doesn’t address the SEO issue. So just because you might be able to have unique URLs for the different parts of your Flex app doesn’t mean that Google is going to include your URLs in its index. Now I’m not saying that Adobe doesn’t know this, that link at the beginning of the paragraph is Matt Chotin asking the Flex community if deep-linking on its own, without SEO, is still valuable. So clearly Adobe has decided that even though there is still no solution for SEO with Flex apps, they’re going to support deep linking. That’s good and all, but what would have made this a show-stopper is if the announcement was that Adobe had worked with Google to make Flex apps indexable. Now that would be impressive.

Resource Bundles and Runtime Localization
I know this has been often asked for. Basically at every public Q&A session with people on the Flex team that I’ve ever been to (Apollo Camp, 360 Flex, some of the silvafug meetings) someone has asked about localization and multiple language support. So the demand is clearly out there. I don’t have any experience trying to make apps that support multiple languages (what, not everyone speaks English? really?). So I can’t say that this eases a distinct pain of mine, but I know it’s important to a lot of people, so kudos to Adobe for getting it rolled out. It doesn’t make Flex 3 stand out in my book, but I know this feature alone will make the upgrade worthwhile for some.

Flex Component Kit for Flash CS3
This was sort of mentioned in Ted’s previous post when he talked about skinning integration with other CS3 apps. I haven’t tried this out, and I actually have a pretty pessimistic view whenever I hear talk about cross-product integration. But if this works I will probably do a lot more skinning in Flash. A personal aside, I started working with Flash before I started working with Illustrator. I’m not a great graphic designer, but I enjoy design and skinning and all that. I actually like the simplicity of the Flash vector drawing tools. When I skin apps (or even make t-shirts, or stickers, or whatever) I often draw my graphics directly in Flash. Illustrator lovers will probably gasp at the fact that I like drawing in Flash more, but hey, I’m a simple guy. So since most of the vector graphics work I do is already in Flash, that means I can designs skins using the app I’m most comfortably drawing with (as opposed to Fireworks). I don’t do enough skinning work to make this too important, but if the Flex Component Kit works well (I haven’t tried it yet) then this might be pretty sweet for me.

Summary
This feature set is all about the Advanced DataGrid component. This is a component a lot of people have wanted. But I’m about as excited about this one as I was about the original DataGrid or Tree components in the original Flex 2 SDK (that is to say, not excited much at all). I think the main reason I’m so down on the Advanced DataGrid is because I saw Flex 3 as an opportunity for a whole set of new component toys to play with. And so I wonder how the same team of programmers who put together the first Flex 2 SDK can put out an update that includes a whopping 1 new UI component and 2 layout components. This does not include updates to the charting components that will also be included, I have no idea what those will be, maybe I’ll be blown away (although I’m only expecting minor updates to existing charting components).

The announcement that Ted made today about Flex Framework caching on the client is more exciting to me than this feature set. I’ll try to write up my thoughts on that tomorrow when I get time. I think it’s an important feature (although not as important as the Profiler). But I’ve never seen the 500-700k footprint of a Flex app be a show stopper. But anything to get that large SWF size down will give Flex haters a bit less to argue about.

Standard