Josh Talks Flash

Open Source Flex Component: HeatMap

Over the last week, I’ve been working on a new Flex component, a heatmap! For those unfamiliar, a heatmap is a form of data visualization that uses color on a two-dimensional plane to compare values. Most recently, in the Flex community, heatmaps have been made famous by Universal Mind’s Spatial Key application. After seeing that go live, I knew people would be interested in an open source heatmap component for Flex, so I put one together and dropped it on Esria’s open source and community site.

Overall, I found the process of building this component very straightforward. There are many similarities to my treemap component, but the heatmap is a bit simpler in many regards. One thing I particularly enjoyed about building the heatmap was that it required some pretty heavy optimization. Since it could potentially display massive data sets, manipulating the data provider and extracting the required numbers needs to be fast. I spent a lot of time diving into Flex Builder’s profiler. By the way, Jun Heider’s profiler session at 360Flex has some great info that helped me understand the profiler’s numbers better. I highly recommend checking it out.

In particular, I made a few good optimizations in some functions that could potentially run hundreds of thousands to even millions of times when preparing the data (basically, sorting a huge list of items). First, I made sure to access member variables directly. Usually, I’ll just use the public getter if it’s available, but it actually became a bottleneck when Array.sort() needed make such a huge number of function calls. Next, since a sort function potentially has to access the same value over and over again, I set up Dictionary-based caches to retrieve an item’s position and weight without having to recalculate these values every time. Personally, I’ve always been a little wary of the Dictionary type, but lookups proved to be very fast. Finally, though it didn’t necessarily have the same impact as the other optimizations, I drew the heatmap using a Bitmap rather than a Graphics object.

In addition to raw code execution speed, I included a couple other features to aid in performance. First, a sampleSize property lets you use every nth item in the data provider instead of every item. This won’t provide a complete picture of the data, obviously, but it will certain speed up the analysis by using a subset. Additionally, you can specify a weightField or a weightFunction. Normally, every item has a weight value of 1 used to determine the color of a region. Differing weight values can allow for more complex data, certainly, but it can also be used to combine multiple points together to form a smaller data set. For example, if you are using a region size of 30 pixels, you can combine all the items in the same region together since the heatmap won’t need more per-pixel position data. If your raw data has an item for every pixel in that 30×30 region, you’ll reduce the number of items in that region from 900 to just 1, but still have the same overall weight for that region. That can be a huge performance increase when you consider that this sort of reduction might be happening in every region on the heatmap. Moreover, by doing this on the backend, you’ll send fewer bytes to the client. Reduced bandwidth usage is always helpful.

The source code for the Flex HeatMap component is available under an MIT license. Be sure to check out the HeatMap API documentation and look at the examples to get started.

by Josh Tynjala | 7 comments

Introducing RokTok, a Flex mashup featuring particle systems, last.fm and Twitter!

Now that I’m settling in as the new R&D guy at Esria, it’s time to start showing people some of the cool stuff I’m doing. Part of my job is to work with and evaluate new technology, libraries, and tools. The best way to do that, in my opinion, is to use them by building “real-world” applications. So, in order to begin playing around with the Mate framework and the Flint particle system library, I decided to build an app that I call RokTok. This fun Flex app combines the top musical artists on Last.fm with the community conversations on Twitter.

I started peeking into the Mate framework just before 360Flex, and it looked pretty cool. I got the chance to see Laura Arguello’s Mate session at the conference, and afterwards I had no doubt that this framework was worth a deeper look.

Mate works a bit differently than the traditional Flex frameworks like Cairngorm, and that’s exactly what I like about it. Most of your work with Mate will be in an EventMap, an MXML tag-based event wiring system. Personally, I think this is a great way to utilize Flex’s native markup language and binding system, and to keep much of the framework code in one place. To me, it felt like I spent less time making the framework do its thing because I wasn’t creating half a dozen different classes to get one minor action to happen, yet it still felt organized. On the other hand, I could tell that larger applications with many events being handled in one place could lead to a large and unwieldly event map. Thankfully, there’s nothing stopping developers from breaking up event maps into multiple parts with only related events appearing in the same maps. Still, though, some developers may find that Mate works best for smaller applications that could still use a framework.

I love particle systems, and I’ve done several little experiments with them in the past. RokTok will be the first time I’ve been able to use them as part of an app, and making them visualize data seemed like a great way to do it. Many folks first head to Flare for data visualization in Flash Player, but I recently discovered the Flint particle system library for AS3. It’s obviously geared specifically toward particle systems, but in that area, this library definitely shines. I found the API extremely intuitive and extensible (good architecture, yay!), and it was super easy to integrate it into a Flex application.

Having designed my own particle systems in the past, and having trouble making them easily customizable, I was excited to see the approach Flint took for extensibility. Using Initializers and Actions to define behavior, Flint makes altering the way particles interact possible through small pieces that are easy to write and reuse. Having a decent collection of Actions that already come with the library and cover many of the most obvious behaviors certainly helps too. If you check out the source code for RokTok, you’ll see a few extensions I made in the com.flextoolbox.flint.* package.

I had way too much fun building RokTok as one of my first Esria R&D projects. If you’re interested in how it was built, check out the source code. It is released under an MIT-style open source license. Stay tuned because I’ve got a lot more cool stuff planned for my R&D and community efforts at Esria.

by Josh Tynjala | 5 comments

How will ECMAScript “Harmony” affect ActionScript 3?

I’ve been contracting for Yahoo! recently and I overheard Douglas Crockford talking about the ECMAScript “Oslo meeting” with a co-worker. I only heard snippets of the conversation, but I remember wondering what the heck he was talking about because it sounded very strange. Today, the topics of that conversation became public. First, I saw a thread titled Harmony on the ES3.x mailing list, started by Crockford:

It was decided at the Oslo meeting that the project formerly known as ES4 is no more. Instead, there will be a new project, Harmony, which will be the work of a unified working group.

For a bit of background, the group working on ECMAScript 4 split in two last year. Some folks (Microsoft and Yahoo! among them) felt that ES4 wasn’t going in the right direction for the web, and they wanted to start smaller with an ES3.1. Other folks, like Mozilla and Adobe, had pretty strongly committed to ES4.

John Resig just posted a more thorough explanation of what happened at the ECMAScript Oslo meeting, and Brendan Eich wrote about it on the ES4 mailing list. I encourage you to read these posts because they’re very interesting. To summarize, though, the split working groups are coming back together. They’ve committed to completing ES3.1 first and will begin re-planning features for a new version of ES4. From what I can gather, the ES3.1 group had started making changes that weren’t fully compatible with ES4, and if the two versions were finished out of sync, there would have been major problems. Some of ES4’s existing plans will be dropped completely (packages and namespaces among them) and others will be given a stronger bond to the features in ES3.1.

Overall, I think this is a good strategy, considering the alternative. When I first heard about the conflict between the two separate developing versions, I worried if it would cause the improvement of client-side, browser programming to completely stall for a while. At least now I know that everyone seems to be moving forward again, in “harmony” (to steal their term).

This is all well and good, but it leaves us asking one important question: What happens to the existing version of ActionScript 3.0? Adobe very conservatively implemented features from the ES4 specification, knowing that changes could be made to the draft spec, but unfortunately they still ended up implementing features that will no longer appear in ES “Harmony”. As I mentioned above, packages and namespaces are out, according to Resig’s post. Will Adobe continue working on AS3 with the features it already has? Will they continue to implement more from the scrapped ES4 spec? Or, will they actually remove features to stay compatible with the latest changes to ECMAScript? One could argue that they did it once already by removing private constructors that were available in AS2.

I imagine this will be a hard problem for Adobe to solve. They’ve stated previously that they want ActionScript to be compatible with an industry-standard language. If they remove features, I know many developers will have some not-so-happy opinions to share. On the other hand, I personally like that Adobe wants to use a standardized language. Like their recent contributions to open source, it’s a sign that they “get it”. To get a little off subject, I’d love to see multiple languages able to target the bytecode used by Tamarin/AVM2, and it’s certainly possible (look at HaXe), so maybe the possibilities are more flexible than we might initially expect.

If anyone from Adobe can comment, I’d appreciate it. If not, I hope you can share something with us soon.

Update: You might want to read what Hank Williams thinks of these changes and how they will affect Adobe. Well written.

Update 2: Additionally, a couple of days after this surprising revalation, Arun Ranganathan wrote an excellent and more mellow summary of the Oslo meeting and Harmony on the Mozilla Standards blog. What’s most interesting, in my opinion, is that Arun’s position is that the upcoming Harmonized ES4 may not be that different from AS3, and any differences are minor enough to be considered Adobe extensions. Fascinating!

by Josh Tynjala | 18 comments

SimpleAS3: An ActionScript Framework for Designers, Animators, and Part-time Coders

Recently, Colin Moock, author of Essential ActionScript 3.0 and a well-respected leader in the Flash community, presented The Charges Against ActionScript 3.0. A few of the problems he describes apply to everyone who targets Flash Player, such as the difficulty even hardcore developers seem to face when dealing with the garbage collector. However, many of the issues come from the perspective of designers, animators, and other part-time coders. These soldiers of Flash Player have been building rich content and thriving for years, but many are frustrated with the myriad of changes ActionScript 3.0 brings to the table.

AS3 is more like traditional programming languages, and it has a stronger focus on object-oriented programming (OOP). Many users preferred the more flexible scripting focus of earlier versions of this language, and some find OOP much more difficult to grasp. On the other hand, a lot of folks have simply become frustrated that AS3 often requires much more code for things that were easy in AS2. With my new framework, SimpleAS3, I hope to address many of these issues and give the "everyday Flasher" (as Moock names them) a way to use AS3 in a more familiar and flexible manner.

Below, I'll cover a few specific things that SimpleAS3 makes easier. Be sure to read the SimpleAS3 documentation to learn everything that this library can do because I can't possibly describe it all in one blog post.

ActionScript 3.0 is Strict

The AS3 compiler is very strict compared to AS2. For instance, since the parent property on display objects is typed as DisplayObjectContainer, developers must often cast it as a different type to get around the fact that DisplayObjectContainer is sealed. This makes a very common method of communicating between MovieClips in AS2 far more difficult in AS3.

SimpleAS3 simply turns off AS3's Strict Mode. This compiler feature is fully supported by Flash CS3, but many people who might want to use it don't know it even exists. With Strict Mode off, Flash CS3 is much more accepting of dynamic property access, so it makes AS3 coding feel much less restricted. On the downside, just like AS2, simple typos can lead to errors that might be difficult to find. However, since many AS2 coders are used to that already, it's often an acceptable tradeoff.

Listening to Events

In some ways, events in AS2 were a bit easier to use. In others, AS3 made some very useful improvements. While developing SimpleAS3, I wanted to keep the more powerful event system of AS3 intact while making it look a bit more like AS2. What I ended up with is a little bit different than both, but certainly not too difficult to grasp.

As you can see, adding an event listener is a little faster, since I brought back the old onEventName syntax. This was achieved by adding the event functions to class prototypes. Yes, those still exist in AS3, which may surprise some people. Additionally, for many events to which you don't intend to stop listening, it's often easier to simply use an anonymous event handler function. You'll also notice that I ignored the event parameter. Thanks to Strict Mode being turned off, function arguments become a bit more flexible.

If I wanted to follow best practices a bit more closely, I might consider rewriting the code above to look something like this:

Though I use regular AS3 in my own projects, I enjoyed playing with the event shortcuts so much while I was testing SimpleAS3 that I sometimes have to stop myself from typing onClick() instead of making a proper addEventListener() call.

Loading Assets at Runtime

SimpleAS3 makes loading things like SWFs, images, and XML files at runtime very easy. For images and SWFs, a new function named loadChild() has been added to all display objects. In many ways, it is similar to loadMovie() in AS2. In one function call, you pass in a URL, set a name, and optionally set up listeners for the complete, progress, and IO error events. A Loader is automatically created for you and added to the display list.

Similarly, a new global function loadXML() makes it easy to read an XML file. Again, it's just one function call.

In future versions, I hope to add more shortcut functions for loading assets at runtime. I'd love to hear what sorts of data people load most commonly and how they think it could be easier.

I have a feeling this framework may be a bit controversial, especially since my regular audience on this blog is developer-centric. However, like Colin Moock, I think that the part-time coder is an important member of Flash Player's target audience, and I want to see these folks continue to thrive on the types of projects they enjoy creating. Those aren't necessarily the same sort of projects developers like me build, so it makes sense that our tools may be a bit different. In other words, not everyone needs the power of the Flex framework nor all the best practices that should be followed when building enterprise-scale RIAs.

I encourage you to leave feedback in the comments below, or to comment on the Future Plans section of the Wiki I've set up on Google Code. I'm planning to get a better support and feedback system set up soon, but this should give everyone a good place to start if they have questions or comments. Of course, if you're interested in learning more about SimpleAS3, please check out the documentation and download SimpleAS3 to give it a try. The MXP installer requires Adobe Extension Manager.

Note: I'll be on vacation over the weekend and speaking at 360Flex San Jose next week, so I may not be able to respond to or approve comments immediately. I'll try to address issues and questions as quickly as my schedule permits during this time. I love feedback, especially on an experimental project like this one, so please share any thoughts you have.

by Josh Tynjala | 8 comments