“In initializer for ‘mxmlContentFactory’, type org.swizframework.SwizConfig is not assignable to target type Array or target element type mx.core.IVisualElement”

The solution: Flex 4 introduced a new method of grouping non-visual elements together <fx:Declarations>. In Flex 4 non-visual elements such as formatters, validators, effects etc. need to be grouped within a <fx:Declarations> section. So if you’re using Flex 4 (Gumbo) your SwizConfig would look something like this:

<?xml version="1.0" encoding="utf-8"?>
<s:WindowedApplication
	xmlns:swiz="http://swiz.swizframework.org"
	xmlns:fx="http://ns.adobe.com/mxml/2009"
	xmlns:s="library://ns.adobe.com/flex/spark"
	xmlns:mx="library://ns.adobe.com/flex/halo">
 
	<fx:Declarations>
		<swiz:SwizConfig 
			viewPackages="com.myapp.views"
			eventPackages="com.myapp.events"
			strict="true"
			beanLoaders="{[Beans]}" />
	</fx:Declarations>
 
</s:WindowedApplication>

Flex Builder 3.0
http://www.adobe.com/products/flex/

Flex SDK 3.0
http://opensource.adobe.com/wiki/display/flexsdk/Flex+SDK
AIR 1.0
http://www.adobe.com/products/air/

I develop Flex and AIR applications in Flex Builder on my Macbook Pro notebook and I keep a copy of VMWare Fusion and Window XP on standby for testing.

Last week while debugging an AIR application I came across a NativeMenu problem that required me to set breakpoints inside the Windows specific section of the NativeMenu code. No problem, I fired up VMWare Fusion, started Windows XP, installed Flex Builder 3 beta 3 and imported the project from my Mac partition. It all worked very slick and I was able to debug the problem and code a solution from within Windows, all without making a copy of the code base.

It all sounds so good and efficient right?

But later as I was basking in the glory of my victory, I got to thinking…this won’t be possible once Flex Builder 3 is released because I won’t have a Windows license key for Flex Builder 3. Will I need to spend hundreds of dollars for a Windows license key just so I can debug the occasional AIR application? What about when Linux support is a reality? Hundreds more?

The short answer may be “Yes”, pony up the cash and move on ya whiner!

But there’s a larger question at the root of this issue. Does Adobe as the provider of a freely available cross-platform runtime have an obligation to it’s developers to provide an equivalent platform for developing and debugging across all the supported platforms? In my opinion they do, it’s in Adobe’s best interest long term. Being able to debug AIR applications on Windows, Mac and (looking forward) Linux will only improve the quality of AIR applications and that in-turn should promote adoption of the platorm.

Let me be clear, I’m not suggesting that Adobe give away the IDE farm, I am suggesting that Adobe needs to consider the developer faced with challenges of cross-platform debugging in AIR. How does the developer who cannot afford a Windows, Mac & Linux IDE affect the platform as a whole? In my opinion the AIR applications we create (free or not) are public ambassadors for the platform, as such we need them to be stable and performant across every platform the AIR runtime supports. To accomplish this we need reasonable access to tools for each platorm.

So here’s my suggestion Adobe, it’s simple. Make the Flex Builder Professional license cross-platform. Let your developers make a choice for cross-platform debugging.

I was reviewing Engadget’s coverage of Demo 08 this morning and I nearly fell out of my seat when I saw skyfire. skyfire is a mobile browser that claims to bring a PC browsing experience to the mobile phone for the first time.

From the skyfire site product page:

We’re talking about full-featured PC versions of your favorite web sites. Skyfire gives you speedy page loads, full audio, video, images, dynamic Flash content, advanced Ajax, Java and more – just like your PC.

Of course you know where I’m going with this, if skyfire supports Flash 9 then skyfire also supports Flex. We could be on the verge of taking our Flex apps mobile. To me this news is beyond huge! Imagine the new opportunities that would be created by full Flash/Flex in the mobile space.

At the time of writing, skyfire is in private beta and is only available for Windows mobile 5 & 6 and that only on phones with a full Qwerty keyboard. Their site says that Symbian support is coming soon. I use a Nokia E61i so I’ll have to wait for Symbian support.

You can sign-up for the private beta on the skyfire site.

Here’s a demo of skyfire in action, impressive!

PureMVC uses mediators for all communication from the model and controller to the view. Out of the box PureMVC normally creates the view mediators after creationComplete has fired and the model has been initialized. The reason for this is that mediators require a reference to a view component to work. In order to construct a mediator you first need an object or view component to pass to the constructor.

There are basically three different ways to handle this, two of which I don’t recommend using.

1. Use dummy objects to initialize mediators
If you know that your view component is not on the stage yet you could still create it’s mediator by passing a POASO (plain old actionscript object) to it’s constructor. I have two problems with this solution; One you’re unnecessarily using memory and two you have not treated the whole problem, you still need some type of event schema to reinitialize the mediator once the component has been created. I don’t recommend using this solution.

2. Use creationPolicy=”all” to avoid deferred views
By default components like ViewStack and TabNavigator on create their top level children at runtime. The remainder are created as the user navigates to them. You can use the creationPolicy=”all” attribute to override this behavior. This causes the application to create all the view components at runtime. This is a terrible idea and I cannot recommend it. What you are in effect saying to your user is “I don’t care about your memory or performance because I’m to lazy to code a decent solution” I know this is a bit dramatic but I hate when people use this attribute.

3. Use a custom Event subclass
The idea here is to create an event subclass that the application mediator or another mediator can listen for and use to create new mediators. This event class has an extra property which holds a reference to the newly created component, other mediators can use this reference to construct a mediator for the component. This approach not only keeps your memory footprint smaller but it allows you to easily create and destroy mediators. Here’s an example of an Event subclass:

You create your own constant names based on the event type you want your mediator to listen for.

[as]
package com.tomcornilliac.myproject.events
{
import flash.events.Event;

public class ComponentCreationEvent extends Event
{
// Publically accessible properties
public var component:Object;

//Constants used for routing withing PureMVC mediators
public static const SOME_EVENT:String = “gatewayCreated”;
public static const SOME_OTHER_EVENT:String = “gatewayStackCreated”;

public function ComponentCreationEvent(type:String, component:Object, bubbles:Boolean=false, cancelable:Boolean=false)
{
super(type, bubbles, cancelable);
//Probably should have a getter/setter for this property
this.component = component;
}

//You must override the clone method
override public function clone():Event
{
return new ComponentCreationEvent(type, component, bubbles, cancelable);
}
}
}
[/as]

An instance of this event is dispatched from your view component with a reference to its self. Note that “bubbles” is set to true, this is required for the event to make it up the chain to whatever mediator is listening.
[xml]

width="100%" height="100%" creationComplete="init(event)">

[Event(name="gatewayCreated", type="org.deschutes.grizzly.events.ComponentCreationEvent")]

import com.tomcornilliac.myproject.events.ComponentCreationEvent;

private function init(e:Event):void
{
dispatchEvent(new ComponentCreationEvent(ComponentCreationEvent.GATEWAY_CREATED, this, true));
}
]]>

[/xml]

The listening mediator (in this case the ApplictionMediator) will respond to the event and create and register a new mediator for the newly created view component. Now it’s important to note that while I’m using the ApplicationMediator in this example, you can use any mediator you want, so long as the event will bubble-up to it.

[as]
package com.tomcornilliac.myproject.view
{
import com.tomcornilliac.myproject.events.ComponentCreationEvent;
import com.tomcornilliac.myproject.view.components.SomeComponent;
import org.puremvc.interfaces.IMediator;
import org.puremvc.interfaces.INotification;
import org.puremvc.patterns.mediator.Mediator;

public class ApplicationMediator extends Mediator implements IMediator
{
//Canonical name of the mediator
public static const NAME:String = ‘ApplicationMediator’;

//Constructor
public function ApplicationMediator(viewComponent:Object)
{
super(viewComponent);

/**
* Setup event listeners for components created dynamically
*/
app.addEventListener(ComponentCreationEvent.SOME_EVENT, createNewMediator);
}

private function createNewMediator(e:ComponentCreationEvent):void
{
//Create the new Mediator and initialize it with the component from our event
var mediator:SomeComponentMediator = new SomeComponentMediator(e.component);
//Register the mediator with the Application Facade
facade.registerMediator(mediator)
//That’s it now your view component is hooked-up and ready to handle I/O
}

….other methods
[/as]

This technique is not only good for component creation but you could just as easily create a custom ComponentDestructionEvent and use it to remove Mediators off the stack when no longer needed.

If you would like more information about the PureMVC framework I encourage you to visit the PureMVC web site. The documentation is excellent and there’s even a training course to help you on your way.

• AIR SDK (Freely available from Adobe Labs )
• Image editing software
• Flash Authoring (only if you want to modify the default badge)
• Your favorite text editor or IDE

Put simply, the AIR install badge is a SWF that detects the presence of the AIR runtime, if the runtime is not present it downloads and installs it before it downloads and installs your AIR application. The whole experience is remarkably similar to the Flash Express Install so most users should feel comfortable with the process. If (like me) you’re curious as to how the badge functions technically you can view the ActionScript 2.0 source and Badge FLA which are included in the SRC directory of the AIR SDK

Note: At the time of writing the AIR SDK contained an outdated version of the badge. The original badge had some debug code in it and the looks were a little underwhelming (hey it’s beta!). Fortunately Adobe has already updated the badge with amongst other things, a much improved look, just like the AIR samples page. The updated badge has yet to make it into the SDK but you can download it from Adobe. I’ll be using the updated badge for this tutorial.

1. Create your background image for the badge

Create a 215px x 100px image to be used as the background for the badge. The default size for the badge is 217px x 180px, if you deviate from this you will need to adjust your image size accordingly. 

2. Configure the badge SWF

The badge accepts 5 parameters in the form of Flashvars:

1. appname: The name of your AIR application.
2. appurl: The URL to your AIR application. (http://www.mydomain.com/myAirApp.air)
3. airversion: Currently “1.0.M4″
4. buttoncolor:  Hex value of color for the Install button (default is gray)
5. messgagecolor: Hex value of the color for the text message(s) below the badge (default is black)
6. imageurl: URL of the background image(step 1) for the badgeThe badge code will end-up looking something like this:

Of course most all of you are going to want to use some type of Flash detection script. Adobe has provided one in the samples directory of the badge SDK, but I prefer the most excellent SWFObject.That’s basically it. As you can see the process for creating a badge for your AIR application is painless and unless you want to modify the stock SWF you don’t need Flash authoring. If you’re creating an AIR application for distribution I highly recommend taking time to create a badge, believe me your users will thank you.

I was wandering around Flex Builder 3 today (6/11/07) and noticed that my beta copy expires in 29 days. At the time I didn’t know whether to be excited at what the short time span implied or disappointed at the short beta. With a 30 day beta window I would hesitate to give Flex Builder 3 a serious run.

Not to fear though, if you enter your Flex Builder 2 serial it will extend your trial out another 112 days for a total of 142 days from the day you install. Just in time for beta 2 maybe?