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

by Josh Tynjala

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.

Start the Discussion

Monday, September 8th, 2008

How will ECMAScript "Harmony" affect ActionScript 3?

by Josh Tynjala

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!

21 comments

Wednesday, August 13th, 2008

AdvancED Flex Application Development offers a unique perspective

by Josh Tynjala

Unlike other Flex books, AdvancED Flex Application Development: Building Rich Media X by R Blank, Hasan Otuome, Omar Gonzalez, and Chris Charlton (enough authors, guys?) doesn’t cover Flex with a lot of little examples that introduce the features of Flex to newbies. Instead, the authors present a bit about Flex through a look at an application they built called Rich Media X. Rather than cover all the same-old, same-old Flex basics, this book covers the process of building the application and many of the considerations they had to make during the process. I think it’s great that Flex books are starting to move into a wider variety of material, and I hope this is the first of many.

What’s most interesting in this book, in my opinion, is the section on planning. Every Java head (and probably his mother too) knows all about requirements and design documents. In the Flash world, a lot of coders don’t have any experience with this sort of traditional software engineering stuff. It was great to see the authors spend time talking about finding requirements, determining how much time they had available (and inevitably, what needed to wait until a future version), and things like wireframes and various other diagrams. I honestly wished they’d spent another chapter or two on this subject. I think the Flex development community would benefit from a more engineering-focused book that has an ActionScript twist.

One thing I didn’t like was the actual application the authors presented. Rich Media X is more of a distributed set of applications that Adobe User Groups can opt-into individually, and it’s very different than the traditional Flex app. While it’s good to show that Flex can do crazy and interesting stuff, the subject of this book is very abstract compared to most Flash and Flex books. Combine that with an app that requires a reader to wrap her head around its very purpose and you have a very confusing read. I found myself switching contexts too often. They’d slip in a chapter on how to specifically do something like styling in Flex, and suddenly everything would change as I learned about installing Drupal or what makes a good advertising platform. Not to say that learning about Drupal is a bad thing. In fact, I think the topic of technology integration with Flex made the book a little more interesting.

At the end, there was a “Special Topics” section that covered what I assume were chapters that the authors didn’t know how to integrate with the main content. A chapter on SEO was nice, especially the mention of Ted Patrick’s XSL-based Flex SEO system. On the other hand, the tip of using CSS-hidden HTML content for search engines to crawl was misleading since Google penalizes that behavior. The next chapters about how to build an audio visualizer and what’s new in Flex 3 didn’t fit in at all. The tendency for authors and publishers to say “oh, a new version came out, let’s make sure we add a chapter that covers the new features” is getting old. Either integrate it into the main book’s content, or in the case of this book, don’t include it at all because the topic of the rest of the book wasn’t an overview of the previous version.

Ultimately, while I had some gripes with AdvancED Flex Application Development: Building Rich Media X, it was a nice change of pace for me. I like when tech books experiment with the normal format because I generally hate tech books. This one looked at Flex from the perspective of how to build a big application instead of how to start using Flex. That’s awesome. Personally, I think it tried to fit in a bit too many subjects at once, and maybe some more focus would have made it better. Check it out if the regular “getting started” development book isn’t your style.

Start the Discussion

Sunday, August 3rd, 2008

Bug when creating CS3 UIComponents in Document Class constructor

by Josh Tynjala

Under one specific condition, a Flash CS3 component will not draw for the first time until after it has been displayed to the user. Generally, that’s not a problem, but there are times when it becomes noticeable. The following report demonstrates an obscure bug that most component developers working with the CS3 UIComponent architecture won’t encounter. However, it becomes more visible with specific types of components, such the the Layout Containers in the Yahoo! Astra components for Flash CS3.

A quick background explanation to get everyone up to speed. The CS3 UIComponents rely on the stage’s “render” event as part of the validation model. Basically, a component will wait until just before Flash Player displays something new to screen before running its main drawing code. This ensures that developers can set many properties at once without redrawing every single time. The render event provides a “last chance” place for code to run.

The Bug: No Event.RENDER for first frame

When a SWF first starts up, the document class constructor is run. Imagine that you want to create an application with a layout container, like the Astra VBoxPane, to arrange your controls. You insantiate the VBoxPane and add it to the display list. Next, you create several controls and add them to the VBoxPane. Very standard stuff, and you put all this code into the document class constructor.

When you run your SWF, sometimes you notice a very strange issue on the edge of your vision. For a very brief moment (if you blink, you’ll miss it), all the controls in the VBoxPane are stuck in the top-left corner at x=0, y=0. You don’t see it happen every time, though. Maybe it’s your monitor’s refresh rate. Maybe the browser just doesn’t allow Flash Player to draw itself right away, but it definitely happens sometimes.

The problem I discovered is this: Event.RENDER doesn’t get fired before the very first frame is drawn when you start up your SWF. The first time you can receive Event.RENDER is after the first time Event.ENTER_FRAME is fired. For reference, the enterFrame event is a lot like RENDER. It’s the very first code that gets run after Flash Player draws to screen. When the SWF starts up, the document class constructor code gets run, then Flash Player draws itself, Event.ENTER_FRAME is fired, and then Event.RENDER is finally fired the first time before frame two. In the case of our VBoxPane, all of its children are on the display list and visible to the user when the first frame is drawn because we added them to the display list, but the component never had a chance to position them!

The Workaround: A simple drawNow()

If you’re using any of the Astra layout containers, and you encounter this problem, there’s an easy fix. In your document class constructor, after you create the layout container and add its children, call drawNow(). This will force the container to draw immediately. Since we’re still in the constructor, it’s before the first frame is displayed to the user, and all the controls should be laid out properly.

I should note, most developers using the CS3 components never have to touch drawNow(). It’s most useful to custom component developers who want to put components inside other components. It ensures that the child components draw properly. While a bit of a pain, that’s a very different thing than the bug I’m reporting here.

Test case: Some simple code to see this problem.

As part of my investigation, I created some simple code to demonstrate the bug. This is code I’m submitting to Adobe in a bug report. It contains trace() statements that show the difference between the expected order of operations and the actual order.

First, a document class that instantiates a component:

package
{
	import flash.display.Sprite;
	import flash.events.Event;

	public class UIComponentFirstRedraw extends Sprite
	{
		public function UIComponentFirstRedraw()
		{
			super();

			var test:TestComponent = new TestComponent();
			this.addChild(test);

			this.addEventListener(Event.ENTER_FRAME, enterFrameHandler);

			//the trace calls demonstrate the actual order of operations
			//numbering indiciates the expected order.
			trace("1. END OF DOCUMENT CLASS CONSTRUCTOR");
		}

		private function enterFrameHandler(event:Event):void
		{
			this.removeEventListener(Event.ENTER_FRAME, enterFrameHandler);
			trace("3. ENTERING FIRST FRAME. COMPONENT IS NOW VISIBLE TO USER.");
		}

	}
}

And the simple component that is created in the document class constructor:

package
{
	import fl.core.UIComponent;

	public class TestComponent extends UIComponent
	{
		public function TestComponent()
		{
			super();
		}

		private var drawnOnce:Boolean = false;

		override protected function draw():void
		{
			super.draw();

			if(!this.drawnOnce)
			{
				this.drawnOnce = true;
				trace("2. THE COMPONENT IS DRAWING FOR THE FIRST TIME! I SURE HOPE IT ISN'T VISIBLE YET!");
			}

		}

	}
}

For the next version of Astra, I plan to work around the bug in a different way so that developers don’t need to call drawNow() manually. However, it is a hack that involves visibility changes, and I definitely want to see this bug fixed in UIComponent in the future.

Start the Discussion

Wednesday, July 16th, 2008

Foundation Flex for Designers has a misleading title

by Josh Tynjala

Friends of ED markets its books with the slogan Design to Designer. When I read Foundation Flex for Designers by Greg Goralski and LordAlex Leon, I wondered who gave this book the wrong title because it didn’t quite fit that philosophy. A better name might have been Foundation Design Tools for Flex Developers because I don’t think the book’s target audience will find it very appealing. Instead, maybe a developer might be able to pick up a few skills to use when he doesn’t have a designer on hand. Either way, I think the book as a whole could use some rethinking.

A design major was my second choice in university. I ultimately become a software engineer, but I’d like to think I have at least a little insight into what makes a good book for designers. When I put my design hat on, I want to learn from looking at things that are designed well. Inspire me while you teach me the basics. Unfortunately, this book doesn’t offer anything like that for me. Almost every screenshot displays what some of my co-workers call “programmer art”. Even worse, many still have “a blue-gray background and silver-skinned components”. That’s exactly what the description on the back says the book is trying to prevent. It also claims to help the reader create “an application that is both visually stunning and beautifully functional”. With big goals like that, some very strong designs featured in every example should have been a high priority. At the very least, every example should have been fully skinned so that they looked nothing like Flex’s defaults.

It’s common for book authors and documentation writers to ignore best practices when demonstrating how to do something specific with technology. People want simple examples, and it can be hard to do things “right” when there are many more ways to get the point across that take a shortcut or two. I’m against this practice of taking shortcuts because I believe every line of code (or every pixel of your design, for that matter) will teach your reader something, and its not always something you intended. Someone who has no basis for judging good code will believe all your code is perfect because you’re supposed to be the expert.

An example of skipped best practices appears in chapter 3 where the authors create a “personal website” with Flex. Where should I begin? First and foremost, this website consists of mostly text and and a few static images. No real rich interactions provide a justification for using Flex (or even using Flash Player!). The chapter’s purpose was to teach the reader how to use states. Personally, I think a view stack would have been better for the use-case presented in the example. In short, everything about this example would have been better in HTML. Something smaller, perhaps more of a component with advanced options, would have provided a better example of states.

One interesting detail about the design of the book itself bothered me: All the sample code is displayed through screenshots from Flex Builder. In other words, a ton of text in this book is displayed as images. Sadly, this makes all the code slightly blurry because the regular book text is printed at a much higher quality. Additionally, for some particularly long lines of code, rather than breaking each statement across multiple lines, they simple scaled some of the screenshots down to smaller size. This makes the text absolutely tiny. Anyone with poor vision will only get frustrated trying to read the many of the MXML samples.

In most chapters, the examples are presented through simple Flex applications. Unfortunately, I believe this pulls the focus of the book away from design and the tools available for designers targeting Flex, and it presents a lot of ActionScript that doesn’t influence the design in any way. Friends of ED, O’Reilly, and other publishing companies already have entire books introducing ActionScript. It seems to me that most of the code should be skipped to really focus on things designers can do to enhance rich applications. More time could have been spent on building content in Flash CS3 or other designer-friendly apps and bringing those designs over to Flex Builder. Similarly, some tricks for making skins completely transform components in new ways would really energize the Flex community. I remember the first time I learned how to exploit background images combined with padding in CSS to add icons and other flare to HTML. For something so simple, I was excited because it was looking at a problem from a direction I would never have considered. Nothing like the CSS design revolution of the HTML world has influenced Flex yet. Projects like Degrafa are starting to change things, but the book provides no evidence of this project’s interesting new take on Flex design.

I can’t recommend Foundation Flex for Designers. With the focus of design inherent in the title, I expected some real new approaches to design for Flex that would provide ways to skin components that aren’t immediately obvious (and maybe even do things in ways that Adobe didn’t expect). Instead, I got a rehash of the same old stuff that appears in other Flash and Flex books. All the Flex and ActionScript basics are available in book form now. Publishers need to begin branching out to more specialized areas. Most disturbing, for me, is the fact that the skin designs presented in the book are so poor that it seems difficult for even an experienced designer to pick up Flex-related skills. I see many readers spending their entire time critiquing the ugly screenshots instead of reading and learning.

Start the Discussion

Tuesday, July 1st, 2008

iPod Classic Usability and Quality Concerns

by Josh Tynjala

In 2004, I became the proud owner of a third-generation iPod. It changed the way I listened to music. I had every MP3 from my computer at my finger tips. The user interface (both hardware and software) was simple and easy to use. The iPod was the first Apple product that I enjoyed. It probably played a big part in why I’m a Mac user today.

I’m a big fan of waiting to upgrade a product until there’s a good reason to do so. I definitely won’t buy a new cell phone every year, and I’m generally only an early-adopter when a product is particularly revolutionary. At the time, the iPod had already gone though a couple revisions, but this was the first one that really caught my eye (and it was around this time that it was starting to pick up real steam in the market). It wasn’t a brick, it had more hard drive space, and the controls had improved some. Some may remember the battery-life troubles of those early versions too. I actually had to replace the battery twice and get a new hard drive too. Certainly, the iPod wasn’t without its flaws back then, but this version had the polish to keep me satisfied for several years.

After witnessing some of my co-workers marvel at this piece of ancient technology (which was still running strong a couple years after the previously-mentioned repairs), and finding myself unable to find a decent set of speakers compatible with the older dock connector, I decided it was finally time to get a newer model. Of course, I had always been excited to get some of the features added to the newer generations. I saw the color screens on my friends’ iPods and felt a bit of jealously. My own iPod’s screen was smaller and only one color. I liked the new wheel design without the separate buttons for play/pause, menu, and next/previous. The longer battery life was going to be great. In short, I was making a mental laundry list of features that would someday add up to a convincing argument to get a newer version.

During a visit to the Apple Store a couple months ago, I knew it was finally time, and I bought the Sixth-generation iPod “Classic”. While I dig the smaller Nano, it still doesn’t provide the hard drive size I need. I was tempted to try out the iPod Touch, but I didn’t like the higher price. I’ve been using it quite a bit since I bought it, maybe even more than my old iPod. I discovered some very obvious changes to this newer model that just feel wrong and leave me thinking it’s a partial downgrade.

The Wheel

The first thing that felt a little off to me was the sensitivity of the wheel. At times, it’s just too fast. It takes only the tiniest touch to go from one band to the very next on the Artist menu. I frequently find myself having to scroll back and forth several times to ensure that it picks the correct artist when I’m scrolling. My hands are smaller than those the average guy, so you can’t argue that I have fat fingers. It happened on very rare occasions with my old iPod, but I keep noticing this again and again with my new one. Slow down!

There’s a new scrolling feature that seems cool at first, but fails to be usable very quickly. As you scroll through the list, it may suddenly show a letter of the alphabet in the middle of the screen. At that point, you stop scrolling artist by artist (or album by album, whatever the menu may be), and it will begin jumping to the next letter rather than individual items on the list. The first thought that ran through my head was “Cool! That’ll save tons of time.” I imagine everyone else thinks the same thing. Unfortunately, it doesn’t save any time for me.

Much like with the previous sensitivity issue, I discovered myself scrolling way too far. Then I needed to scroll back the other direction. In other words, it’s probably great if you’re going from C to W, but not so much with smaller jumps. In many cases, I’ve had it suddenly change to letter scrolling when I’m only a few items away from my intended choice. Ugh. What’s interesting about this one is that I remember my old iPod scrolled faster depending on how fast I spun my finger on the wheel. That felt intuitive. The sudden appearance of a letter and a completely different scrolling speed means that my brain can’t switch contexts fast enough and I always need to correct myself when it scrolls too far.

Oddly enough, sometimes scrolling can be completely unresponsive too. I’ll spin the wheel half a dozen times to change the volume before it reacts. My old iPod didn’t have that problem. To me, this is a major decline in product quality, and its absolutely the worst of the problems I’ve encountered with the newer model. It seems to happen mostly when I first start playing a song. I’ve considered what might cause this behavior, and I have three possible explanations.

The iPod may have some software or hardware that is still being initialized in the background, so the CPU is overworked. I’m very likely to tweak my volume setting immediately when I begin listening to the iPod. I listen to the iPod in two main locations: in my car or with headphones. Both require very different volume levels. Seeing as I’ve just started using the iPod when this happens, it has my entire metal focus, so it needs to work well. I don’t care if it takes longer to get everything running, don’t degrade my experience once I can interact with a device.
Compared to my old iPod, more data appears on screen when a song is playing. I suspect that it’s working very hard to display the album artwork. The main evidence is that the image doesn’t appear right away when the song changes. It’s just the standard placeholder graphic for a moment. For a small device, I wouldn’t be surprised if decoding a JPG were a little difficult.
On my MacBook Pro, there’s a setting for the touch pad to ignore “accidental” presses. I’d be willing to bet that Apple uses the same technology for both devices. There is no such setting for the iPod. If this is the cause of the unresponsive interface, I can’t do anything to correct it like I’d be able to on my laptop.

Regardless of the reason for unresponsive scrolling, whether it be technical or by design, the device shouldn’t feel like it is lagging so far behind my input.

The Screen

I remember hearing that a certain generation of iPods had especially poor screens. They were prone to scratches and Apple almost immediately released an updated design with special protrusions mean to protect the screen. My new iPod already has two very noticeable scratches on the screen and no special protected protrusions to prevent such damage. They’re ugly, and now I’m annoyed every time I look at my iPod.

My old iPod had many superficial scratches, sure, but it felt more like standard wear and tear than this nasty multi-colored scar. Personally, I refuse to buy a special case for any of my devices. Some scuffs or nicks are okay with me. All the cell phones I’ve owned, my old iPod, the old portable CD players I used to use, and everything other portable device that comes to mind has survived my daily life with nothing I’d call “damage”. Sure, my iPod is still usable, but it clearly isn’t as durable as my old one. I accidently dropped my old iPod a couple times, including on pavement once. It looks a little worn, but like I said, that’s fine. My new iPod has been set down gently in the same place every day, and it goes into the same otherwise-empty pockets as the old one. I haven’t dropped it. I can’t even explain what caused the scratches.

Random Stuff

When I don’t interact with the iPod for a minute or so, the screen changes. Rather than showing me the currently playing song like it did a moment ago, it provides me with the current time. Now, I might be strange, but I listen to a lot of new music on my iPod. Sometimes, if I buy a new album or download a new promo song, I might not recognize what’s playing. Before, with my old iPod, I could generally just peek down at the screen to see what’s playing. If it was too dark, I could touch the wheel and the backlight would pop on.

Now, as I mentioned, there’s a clock. I’m required to touch the wheel to see the song information. When I do, it still shows the clock for a moment once the backlight turns on. That’s two short moments where I could have already gotten the information I needed with my old iPod. To go a step further with my annoyance at this feature, I’d like to point out that I own a watch and a cell phone. They both tell me the time already. I don’t need three clocks on me at all times. With my old iPod, Apple provided a setting to let the iPod track the time or not. This time around, I get the time no matter what. It’s a minor annoyance, these are really starting to add up.

One last thing. I can’t turn the volume down to zero. Every audio device I’ve owned could be turned down all the way. Now, one might argue that turning it all the way down rather than just pausing it is silly. I agree. However, twice now, I’ve turned it all the way down and I wanted it to be quieter. I had to turn it off because the volume was distracting rather than providing the subtle ambiance that I desired.

Conclusion

For years, I was a happy iPod owner. Even when I had trouble with my old iPod, I felt more worried about not having music to listen to at work than feeling like I could have purchased a better device. Unfortunately for me (and maybe Apple too), the problems I described above don’t make me want to go out and buy a new music player today. I can live with them. However, when the time comes again to buy a new device, I’m far more likely to look at the competition than I was before. Last time, I knew I was getting another iPod. There was no question about it. Next time, I’ll be spending a little extra time checking out what else is available.

My problems with the iPod can be partially attributed to one problem that exists throughout the world of computers and electronics. You can start out by inventing an amazing product, but over time, as you add more features that weren’t needed immediately, the product can become bloated. Worse, in my opinion, the existing features might be change in a bad way. This problem can sometimes happen when users stubbornly refuse to accept changes. Other times, it could be that you’re just adding or changing features because you need to create a new version to sell. Personally, I think the standard “classic” iPod has reached this point. There’s little that can be done to improve it now, but Apple keeps churning out new features or changing features without improving them much, if at all. It adds up, and only with a major upgrade skipping several versions (like mine), do some of these problems become obvious.

Start the Discussion

Monday, June 16th, 2008

Style system bug in Flash CS3 UIComponents

by Josh Tynjala

The following bug requires a bit of explanation. I’ll start by describing how Flash CS3′s UIComponent framework handles styles. The style system is pretty complex, so it helps to review this functionality first. Then I will describe what’s wrong with the implementation and how it leads to a particularly annoying bug that affects custom component developers. Finally, I’ll include a specific use-case for why this bug needs to be fixed.

I’m posting this to my blog so that other developers can find it. I spent a couple hours trying to figure out why I couldn’t redefine the textFormat style in my custom component. Hopefully this will help anyone facing the same problem. For the record, I’ve also submitted this bug to Adobe.

Flash CS3′s UIComponent framework defines styles using three levels of importance:

Instance styles apply to a single, specific instance of a component. If you call setStyle() on a component, an instance style will be defined or changed.
Shared styles apply to all components of the same class. If you call StyleManager.setComponentStyle(), a shared style will be defined or changed. Components use shared styles to define their default style values.
Global styles apply to all components controlled by the style system. If you call StyleManager.setStyle(), a global style will be defined or changed.

The order of importance for these style levels is as follows:

Instance styles are the most important. If a component has an instance style defined, it will take precedence over both shared styles and global styles.
Global styles are less important than instance styles, but more important than shared styles.
Shared styles are the least important.

You can see how this works by looking at the getSharedStyle() method of StyleManager. It first checks to see if an instance style is defined and uses that value if it isn’t null. Next, it checks for a global style. Finally, it checks for a shared style.

private static function getSharedStyle(instance:UIComponent,name:String):Object {
	var classDef:Class = getClassDef(instance);
	var inst:StyleManager = getInstance();
	// first check component styles:
	var style:Object = inst.classToStylesDict[classDef][name];
	if (style != null) { return style; }
	// then check global styles:
	style = inst.globalStyles[name];

	if (style != null) { return style; }
	// finally return the default component style:
	return inst.classToDefaultStylesDict[classDef][name];
}

Overall, this makes sense. It allows each component class to include default style values through shared styles. If a developer wants to universally change a style that is defined by many components, such as changing the font used by all controls in an application, a global style may be set. This will override the defaults set in shared styles. Finally, a single instance of a component can be made to look slightly different than everything by setting an instance style.

The Bug

Notice the very last line of the constructor defined for StyleManager. Some global styles are defined immediately when StyleManager is initialized.

public function StyleManager() {
	styleToClassesHash = {};
	classToInstancesDict = new Dictionary(true);
	classToStylesDict = new Dictionary(true);
	classToDefaultStylesDict = new Dictionary(true)
	globalStyles = UIComponent.getStyleDefinition();
}

Remember the order of style precendence?

Instance
Global
Shared

These global styles will always take precedence over shared styles. To review, shared styles are the mechanism for setting default style values. As a custom component developer, when I want a different default value than one of these forced global styles, I’m can’t do it properly.

There are actually three workarounds. The very last one is probably best because it doesn’t change the existing behavior.

Use StyleManager.setStyle() to replace the global style with your own value. This is just plain bad because it changes the defaults for every component in the application and not just your custom component.
Create a new style with a different name. This leaves the original style in place, though, so it’s will make the API and documentation messy unless you hide the original somehow.
In the custom component’s constructor, use setStyle() to define the default value as an instance style. It will be more important than the global styles. However, StyleManager.setComponentStyle() won’t work because the instance style will take precedence. That function didn’t work with a global style defined either, though, so it’s not really a problem.

The fix is simple. In the StyleManager constructor, just set global styles to an empty object.

globalStyles = {};

There’s simply no reason to have any global values pre-defined in the framework. They should all be shared styles so that developers have more flexibility. Technically, they already are shared! All implementations of getStyleDefinition() use the inheritance chain to set up their default styles values. Button adds to LabelButton’s shared styles, which adds to BaseButton’s shared styles, and finally to UIComponent’s shared styles. In other words, most component implementations already access UIComponent.getStyleDefinition() to define defaults, so these styles will be shared from the start.

A quick, and obvious, use case

One of the global styles created by this bug is textFormat, which defines the default TextFormat object to be applied to text that appears in a control. I cannot override the default formatting of text in my custom components. If I want my component's defaults to define a text format with a larger font size (or make it bold, italic, or even a different color!), I can't do it without one of the workarounds I mentioned above.

Adobe's own Flex framework actually has this same use case and implements it as well. The Button component in Flex has bold text by default. Most other components (TextInput, for example) do not use bold text. It's an important customization option that the core Flash CS3 components don't use, which is why the developers probably didn't notice it. However, a look at the other major AS3 component architecture shows that it's a valid need.

6 comments

Wednesday, June 4th, 2008

Open Source Flex Component: TreeMap 2.0 (Beta)

by Josh Tynjala

After quite a bit of work, I’m relieved to present a beta release for the next version of my TreeMap component for Flex. It took me a while, but I reworked much of the core item renderer code to optimize performance, improve maintenance tasks, and generally make it a better component for everyone to use. For full details, visit the TreeMap project page and grab the new build from the downloads section. The package is marked 2.0.0 BETA.

One of the features I’d like to highlight is the new header renderer. The most obvious change is the new zoom button. Because the headers may be selected (when the branchesSelectable property is set to true), a separate zoom button is needed to differentiate these actions. Additionally, you might notice another interesting change in the example linked below. Choose the “Slice-and-Dice” layout, and you’ll see that some of the headers have a little arrow after any text that gets truncated. Roll the mouse over the header, and it will grow with animation to its optimal size, revealing the full text and the zoom button. A drop shadow makes it pop out a bit to help differentiate the header from the surrounding component. With particularly complex data providers, this feature helps usability enormously because the headers often become very small, which hides parts of the text and the icons on the zoom buttons too.

As with all beta software, a word of warning. This component is not completely tested, the documentation is obviously incomplete, and you should use this in production apps at your own risk. I did my best to get everything stable, but obviously, this is the very first release of some new code, so I know there will be bugs. If you’re feeling adventurous, though, I hope it works well for you. Should you see any strange behavior, please file a bug report so that I can make the next release better! If you have any questions, send them to the new flextreemap discussion group I set up recently so that others can learn too.

11 comments

Monday, May 26th, 2008

Hey Yahoo!, so long and thanks for all the Flash!

by Josh Tynjala

Some personal news for you all. Today’s my last day at Yahoo!. I’ve had an awesome time building cool Flash and Flex components and I’m honored to have been able to shape the best practices and directions taken with ActionScript here under the purple banner. Contributing to the Astra and YUI libraries and helping to expand and improve the Flash Developer Center has been a lot of fun. I’m excited to continue watching what new and interesting open source projects come out of the talented minds at Yahoo! long after I’m gone.

Where am I going now? Next week, I’ll start working full time with Clint and Ben and all the great folks at ESRIA. Besides coding in the trenches on various projects there, I plan to continue contributing to the open source Flash and Flex community as much as possible. Keep your eyes on my blog for more details as I get settled in. I have some cool ideas for applications, components, libraries, and all sorts of fun stuff. ESRIA digs my community contributions, and I’ll definitely have a lot more time to work on a wide range of interesting projects thanks to their support. I’m excited!

5 comments

Friday, May 16th, 2008

What's Up with Flash Player 10, Doc?

by Josh Tynjala

But seriously, where are the docs and compiler support for the new and exciting beta of Flash Player 10? I watched the video, and I looked at what is probably the only Flash 10 SWF on the web from the demo page on Adobe Labs. What else can I do? I couldn’t seem to get the the “Download Source” buttons to work at all, and now I’m getting frustrated! There’s a new Flash Player, and I want to play! I need API docs and a new playerglobal.swc to do it. Let me write some code and run it, damnit!

Yours truly,
Every Flash developer on the planet

UPDATE: Targeting Flash Player 10 Beta with Flex SDK 3.0.x

UPDATE 2: Lee Brimelow made a Video Tutorial on Compiling for Flash Player 10

UPDATE 3: Download the Flash Player 10 API Documentation. Courtesy of Lee Brimelow again.

7 comments

Wednesday, May 14th, 2008

Pages: Prev 1 2 3 4 5 6 7 8 9 10 ...18 19 20 Next