Fixing this is trivial.

Simply edit the embed code and change the width property to the actual width of your video. For the height property, you have to add 42 pixels (the height of the control bar at the bottom of the video) to the height of your video.

That's it! Embed your video using the new dimensions and it will play back at its native size and look gorgeous.

I can access T-Mobile UK WiFi HotSpots with my T-Mobile Mobile Broadband account (I have a 3G USB stick) but I find the signing in process rather painful. It goes something like this:

I have to remember my phone number (I never call my USB Stick so I've never memorized it) and type in my crazy long password (which I have, apparently memorized). This means that I bring up dashboard, copy my phone number from a sticky note, paste it into the form and then type my password and remember to tick the checkbox so that I agree to T-Mobile's terms and conditions for the millionth time.

Needless to say, this gets old fast.

So, I took a little time out and built a little AIR app to automate the process. You can install it using the AIR badge (works on Mac, Windows, and Linux), above, and you can see it in action in the screencast below.

I hope someone else out there finds it useful and T-Mobile, if you're listening, get in touch with me at aral@aralbalkan.com if you'd me to make an app like this for you guys.

Update: Exactly 11 minutes after I tweeted about this, Nate Beck from T-Mobile US contacted me and, before the night is over, the app is getting prepped for an internal demo at T-Mobile US next week.

Moral of the story? Never underestimate the power of the Twitternets or the importance of apps, even simple ones, that improve user experience. :)

Dear Flex community and Flex engineering team, I have a challenge for you: let's make Flex 4 migration a one-step process.

Yesterday, I documented the trouble I had in porting my Flex 3 app to Flex 4 and I blamed the move from the Fx prefix to namespaces for my woes. As some of you have pointed out, some of my woes were exacerbated because I was migrating from an earlier version of the Flex 4 Alpha SDK to the latest version. This is true. However, it is also true that Flex 3 to Flex 4 migration is not trivial and will require changes to existing code, libraries, and skins, especially concerning the introduction of namespaces in CSS.

My inner engineer understands that namespaces are the most elegant long-term solution. It doesn't help that my inner engineer is feuding loudly with my inner agile development evangelist (who is appalled at the sacrifice of short-term simplicity in favor of long-term design) and at my inner user experience designer who cannot help but look at the issue from the perspective of the end user.

That said, if we can agree on a set of core facts regarding this change in Flex 4, maybe we can take some positive action to lessen its impact:

1. The introduction of language and library namespaces in Flex 4 adds additional complexity to the framework.
2. The introduction of CSS namespaces may require previous code, components, and skins to be reworked when migrating from Flex 3 to Flex 4 apps. This is an undesirable, manual, and potentially error-prone process that should, if possible, be automated.
3. Developers coming from non-namespaced environments will need a gentle introduction to namespaces, especially the relationship between language and library namespaces.

Given these, I'm issuing a challenge to the Flex community and the Flex engineering team:

Flex 3 to Flex 4 migration should be an automatic, one-step process. Ideally, there Should Exist (tm) an open-source script that migrates Flex 3 projects to Flex 4. This should also be used by Flex Builder to make it trivial for developers to upgrade their Flex 3 projects to Flex 4 without manual intervention.

So, what do you guys think? Who wants to take this on?

If you guys and gals agree that migrating to Flex 4 should be this simple, we need the following:

1. A volunteer to spearhead the project: the volunteer should set up a project in GitHub (SVN is so last half-hour) and be prepared to put in the hours to coordinate with the other developers, etc.
2. Volunteers to work on the project
3. Buy-in/participation/support from Adobe so that the solution that's built will also be part of Flex Builder

Flex 4 is going to be a revolutionary release that, for the most part, makes Flex even easier to use. I am already in love with the new states feature, I love the new Gumbonents (Gumbo components), and the new keyframe animations, just to name a few new features that I've used recently. My one worry is that a manual migration process that affects existing code, libraries, and skins will overshadow these improvements and affect the adoption and transition to Flex 4. We can fix this by making Flex 4 migration a one-step process.

So, who's in?

Thoughts? Comments? Suggestions? Leave a comment!

Please also note what I mean by "migration" (from the comments):

I don’t consider simply compiling a Flex 3 app to constitute Flex 4 migration … If you’re migrating to Flex 4, you are most likely doing it in order to take advantage of Flex 4 features and thus you will want to layer in and/or transition to Spark components at some point and that’s when you will require more extensive namespace changes to your entire codebase. (And you real apps have dozens, if not hundreds of source files, libraries, skins, etc., all of which have to be reviewed and possibly updated.) That’s the use case that I feel we must make as painless as possible.

Having an easy migration path from Flex 3 to 4 will benefit all concerned and I cannot see how trying to make that process simpler (via an effort such as the 1-step migration challenge, etc.) is a bad thing.

Original post follows…

I just upgraded a simple app I wrote yesterday from an earlier version of Flex 4 (Gumbo) to the latest SDK and I got hit with the Fx prefix to namespace changes. Needless to say, I'm not impressed at all.

With the Fx prefix, I could easily layer Gumbo functionality into my existing apps and easily mix Spark and Halo without changing existing code or libraries. This ability is now gone.

I had to go through both my code and third-party libraries to add namespaces and I even had to alter the CSS. Previously, I had no such headaches and everything Just Worked (tm). Mixing Flex 3 and 4 was a joy. Not any longer.

This is a huge step backwards for anyone wanting to migrate existing Flex 3 apps to Flex 4 or reuse components. It makes the transition to Flex 4 and the creation of hybrid Flex 3/4 apps a real pain. It’s the triumph of formalism over pragmatism and the platform will suffer as a result.

And this namespace soup is going to make it all the more confusing for people new to the Flex platform to make sense of things.

Flex and similar technologies are commodities and compete in a supply market. The simpler things are, the more people will use them, and the higher the chances of the platform surviving and flourishing. Simplicity, user experience (yeah, even for a framework/platform) are key.

This namespace change adds lots of complexity for very little gain. It may satisfy the formalists who are probably as we speak trying to find a way to incorporate XSLT into the Flex workflow somehow and whose wet dreams would be a shift from ActionScript to Java for the platform but I hope that everyone involved understands the ramifications this move will have on developers who are new to the platform (so is that mx: again? No? fx: ... oh but that tag is s: and oh, that’s the language namespace but that’s a library... what again? huh? Just a sec, I think SilverLight was easier...) as well as for people migrating and transitioning existing Flex 3 applications.

Flex gods, please reconsider.

Update: As some of you have pointed out, my experience was exacerbated because I was porting from a previous version of Flex 4 to the latest Flex 4 SDK. You're right that this made my porting experience more difficult than a straight Flex 3 to Flex 4 port would have been since I had removed namespaces on all mx and Spark (previously Fx) components. However, I stand by my core point which is that the introduction of these language and library namespaces, along with namespaces in CSS makes it more difficult than necessary to port apps and will be more confusing for developers who are new to the platform.

A number of you have pointed out that the Fx prefix was not a long-term solution and that we would be faced with a similar choice for Flex 5. I don't feel that that's accurate. Flex 5 could keep using the Fx prefix for new components as I don't see such a radical overhaul of the component system occurring in the next version.

And while it's true that we already have namespaces, we've now introduced two framework-level namespaces and separated library namespaces and also introduced namespaces into CSS. Basically, we've introduced a lot of complexity for what I would argue is very little gain.

I'm sure tooling will take care of some of this complexity (and that should work in Adobe's favor and translate to more Flex Builder licenses sold even though they were not the ones to instigate this change). However, when you have to rely on tooling perhaps the problem is that the underlying technology is too complex. There is something sublimely beautiful about not needing any tooling whatsoever in Python, for example, that speaks volumes about the elegance of the language. Let's just say that I don't believe Flex would be in this namespace soup if Guido were calling the shots.

That said, Flex is still the most elegant rich-client technology I know. Yes, I love the tools in Cocoa and Objective-C is quite a marvelous achievement when you consider the limitations of C that they had to work with but there are also up-and-coming contenders ranging from Nokia's Qt to Unity 3D that are vying for the limited attentions of developers in a supply market. Simplicity is a key factor in differentiating your platform and wooing developers.

Simplicity is not something to be ashamed of. It does not make your Code Fu any less if you have simple tools and languages to work with. It just makes you all the more productive and lets you concentrate on crafting that most important part of your application: the user experience.

Flex is simple. We should try our utmost to at least preserve this simplicity, if not to take it a step further in each release.

Flex Fail Whale from Twitter Fail Whale by Yiying Lu

Here's a simple snippet to illustrate:

<WindowedApplication xmlns="http://ns.adobe.com/mxml/2009"
    width="416" height="285"
    explicitWidth="416" explicitHeight="285"
    minWidth="416" minHeight="285" 
 
    ...
 
    width.headLess="110" height.headLess="198"
    explicitWidth.stateName="110" explicitHeight.headLess="198"
    minWidth.headLess="110" minHeight.headLess="198"
>
<transitions>
    <Transition>
        <Resize duration="500" target="{this}" easingFunction="Quadratic.easeOut"/>
    </Transition>
</transitions>
 
<states>
    <State name="aliveAndWell"/>
    <State name="headLess"/>
</states>
 
...
 
<Script>
    <![CDATA[
		import mx.effects.easing.Quadratic;
 
        private function offWithHisHead()
        {
            currentState = "headLess";
        }
 
        // etc.
    ]]>
</Script>
 
...
 
</WindowedApplication>
 

A few days ago I stumbled upon Swiz, which bills itself as the "brutally simple micro-architecture for Rich Internet Application development with Adobe Flex." If the term micro-architecture or the buzzword Rich Internet Application haven't scared you off yet, read on, because it really is a lovely little framework.

Swiz is a lightweight framework for Flex (and ActionScript) that lets you separate your business and presentation logic and implement a loosely-coupled event-based architecture in your applications. I've purposefully stayed away from using the terms Inversion of Control (IoC) and Dependency Injection (DI), even though Swiz is, at its core, an IoC framework that lets you carry out DI. The reason? I feel people get too caught up on the fancy names and either get scared off or end up blindly implementing patterns and frameworks without really understanding what they're doing or why they're doing it. Thankfully, Swiz is simple enough that you can actually understand what it does and why it does what it does. And, it doesn't pigeonhole you into a color-by-numbers straitjacket or suffocate you under a mountain of boilerplate code like some other frameworks.

This blog post is not meant to be an introduction to Swiz. For that, read the Getting Started guide, watch the introductory video by Swiz creator Chris Scott from his presentation at 360Flex last year, and read the Swiz posts on Sönke's blog and those on Chris's blog.

Instead of an introduction, I want to document how I'm using Swiz and the modifications I've made to it in hopes that they might help other developers and possibly spark conversation on future features.

Open a window, let some AIR in

(Sorry, I couldn't resist!)

I ran into a couple of issues with Swiz when I finally got the chance to play with it yesterday. First off, I couldn't get the autowiring to work with new Window instances in AIR. Googling around, I found that this was a known issue and that Sönke had already applied a fix in the form of a registerWindow() method that you call before opening your window. The fix, however, didn't work for me without an additional little patch to manually force the autowiring on the Window class itself. So my registerWindow() method ended up looking like this:

public function registerWindow(window:IEventDispatcher):void
{
    window.addEventListener(Event.ADDED_TO_STAGE, handleAutowireEvent, true);
    window.addEventListener(Event.REMOVED_FROM_STAGE, handleAutowireEvent, true);
    autowire(window);
}

With that little change, my new Window instances get autowired correctly.

Wrrooom, wrrrrooom!

I also saw that the autowiring code was causing quite a bit of performance slow-down. So I decided that autowiring should be opt-in. I modified the framework so that only classes that have a public autowire property declared are autowired. I usually declare this in my classes like this:

public var autowire:Boolean = true;

I could have made it so that I used a metadata tag instead but the whole idea was to stay away from the overhead of describeType. (I'm not sure what additional overhead describeType's XML conversion adds on to the internal describeTypeJSON method but I have a feeling it's quite substantial. If so, it would probably be nice to have a method to just return metadata for a given class — in the spirit of getQualifiedClassName — to make it more performant to parse metadata at runtime.)

So my handleAutowireEvent() method in the Swiz class looks like this now:

private function handleAutowireEvent(e:Event):void {
	// Autowiring is strictly opt-in for performance/efficiency, and
	// having an explicit flag in the class should make your intent clearer.
	if (e.target.hasOwnProperty("autowire")) {
		autowire(e.target);
	}
}

Similarly, the handleRemoveEvent() method simplifies to:

private function handleRemoveEvent(e:Event):void {
	if (e.target.hasOwnProperty("autowire")) {
		_beanFactory.unwire(e.target);
	}
}

The performance increase has been striking: the overhead of Swiz, with this change, is entirely negligible whereas before I was experiencing a doubling in the initialization time of my app.

In case you make the same changes, you should also update registerWindow() (hey, every cycle counts right? Or something like that!):

public function registerWindow(window:Window):void
{
    window.addEventListener(Event.ADDED_TO_STAGE, handleAutowireEvent, true);
    window.addEventListener(Event.REMOVED_FROM_STAGE, handleRemoveEvent, true);
 
	// Fire the autowire manually for the window itself.
	if (window.hasOwnProperty("autowire")) {
		autowire(window);
	}
}

Flex Framework? How about ActionScript and Flex Framework?

I'm also using Swiz quite differently to how it was originally intended. Originally, you're supposed to declare your beans (beans? What are we Java?) in MXML. I found this unnecessarily limiting. So I declare my beans (or components; since neither ActionScript nor Flash are a type of coffee) in ActionScript. And, although I'm using Swiz on a Flex app currently, I don't see any reason off the top of my head why you couldn't use it in ActionScript-only projects too.

Here's a sample Beans class in ActionScript showing you how it's done:

package com.mydomain.myawesomeapp
{
	import org.swizframework.util.BeanLoader;
 
	import com.mydomain.myawesomeapp.SomeController;
	import com.mydomain.myawesomeapp.SomeService;
 
	public class Beans extends BeanLoader
	{
	        // Simply instantiate and return an instance...
		public function get someController():SomeController {
			return new SomeController();
		}
		public function set messageController(o:*):void {};
 
              // ... or do some configuration beforehand
		public function get someService():SomeService {
			var someService:SomeService = new SomeService();
			someService.configureSomething("like", "totally", "cool");
			return someService;
		}
		public function set twitter(o:*):void {};
 
		public function Beans() {
			super();
		}
	}
}

So, basically, what we're doing is mimicking the methods in the ActionScript class that would have been generated from the MXML (or, more precisely, giving Swiz exactly what it's looking for in the BeanLoader, which are readwrite accessors; this is why we need the setter even though it doesn't do anything.)

And, finally, a gotcha that I find myself falling into: Remember to make anything you're going to [Autowire] or [Mediate] public. This means the properties that will receive the class instances and the event handlers. Since you'll be used to automatically making these private, take extra care!

In closing

Swiz is a lovely, lightweight framework that I'm really enjoying working with. It also has a small but active community and some good developers behind it. Play around with it, why don't 'cha and let me know what you think of it in the comments!

For example, if your main MXML file is Main.mxml and your code-behind class is MainClass.as, Flex Builder gets confused and thinks that there should be two application configuration files (one for the MXML file and one for the AS file.) If your app.xml file is named Main-app.xml, you'll get an error along the lines of Adobe AIR application is missing the corresponding MainClass-app.xml.

The workaround is simple, just move your code-behind class off of the root package. e.g., put it in com.mydomain.myapp.view.

-managers flash.fonts.AFEFontManager

If you do, remove it! That's the culprit right there! :)

Otherwise, check that you're doing everything correctly -- your embed code should look something like this:

<Style>
    @font-face {
	    src: url("fonts/ACaslonPro-Regular.otf");
	    fontFamily: "AdobeCaslonAIR";
	    cff: true;
	}
 
	.myBeautifulTextArea {
	    fontFamily: "AdobeCaslonAIR";
		fontLookup: "embeddedCFF";
		fontSize: 20;
	}
</Style>
<FxTextArea id="myBeautifulTextArea"/>
 

Hope this helps save a little hair on your head (and, as always, if you find something that's just not working, create a fresh new project in Flex Builder and test out just that feature and then compare it to your main app — i.e., spike it!)

The fix, as provided by Mike Schiff, has been implemented in the SDK but until it is released you can extend mx:Text and implement it in your own projects:

<mx:Text xmlns:mx="http://www.adobe.com/2006/mxml">
	<mx:Script>
		<![CDATA[
			override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void {
				super.updateDisplayList(unscaledWidth, unscaledHeight);
				textField.wordWrap = textField.wordWrap || (Math.floor(measuredWidth) != Math.floor(width));
			}
		]]>
	</mx:Script>
</mx:Text>

Today is Flash on Twitter Day. Your mission: get at least 1 Flasher to join Twitter & tweet. Pls. retweet. #fotd (retweet this!)

Your mission, should you choose to accept it, is to get at least one Flasher/Flexer/ActionScripter on Twitter (and they've gotta tweet). Then, introduce us to your new recruit using the #fotd hashtag so that the Flash community can welcome them (that's a d at the end, unlike the conference).

And, finally, ask them to recruit a Flasher too (recursive real-life algorithms FTW!)

(Want to help spread the word? Retweet this now or reblog it!)