If you see this message:

SWC file failed to load. Any component dependent on this SWC file will not be displayed in the Design Mode.

The SWC may have failed to load because of:

*  Incompatible definitions caused by usage of a different SDK version

*  Missing referred class definitions

Switching my SDK from 4.5.1 to 4.5 was a suitable workaround. In my case, my custom mobile skins library depends on sdks\4.5.0\frameworks\themes\Mobile\mobile.swc which didn’t want to play nice with 4.5.1 apparently.

Although the swc file size has grown from 28K to 66K, Swiz still provides punch-packing architecture conveniences that border on alchemy.

Swiz Config

The configuration has been simplified and improved:

<fx:Declarations>
<swiz:Swiz id="mySwiz">
<swiz:config>
<swiz:SwizConfig id="mySwizConfig"
eventPackages="com.package.events"
viewPackages="com.package.views"
defaultFaultHandler="{genericFault}"/>
</swiz:config>
<swiz:beanProviders>
<config:Beans/>
</swiz:beanProviders>
</swiz:Swiz>
</fx:Declarations>

You can now declare your eventPackages and viewPackages paths.

eventPackages - If you point eventPackages=’com.package.events’, then you can simply reference any event in that package with Class.CONSTANT in the Mediate’s “event” attribute. This allows you to set the actual string value in your Event Class to what ever you want.
Mediator looks like this: [Mediate( event="MyEvent.SUBMIT")]
Event constant can look like this: public static const MyEvent.SUBMIT:String = ‘whateva’;

viewPackages - This is an option but will speed up the processing of the display classes.

Beans File

The Beans file looks similar but now is wrapped in a BeanProvider tag:

<swiz:BeanProvider xmlns:swiz="http://swiz.swizframework.org"
xmlns:controller="com.jci.h2o.controllers.*"
xmlns:delegates="com.jci.h2o.delegates.*">
<fx:Declarations>
<controller:MyController id="myController" />
<delegates:MockDelegate id="mockDelegate" />
</fx:Declarations>
</swiz:BeanProvider>

Swiz Events

[Dispatcher]
public var dispatcher : IEventDispatcher;

• No longer do you use Swiz.dispatchEvent instead create a [Dispatcher] and call dispatcher.dispatchEvent and dispatch a standard Flex Event (yay!)
• On Event Classes that are to be dispatched by Swiz, set bubbles=true so that the event will bubble up the display list, allowing Swiz to listen
• [Dispatch] allows you to “technically” dispatch events from non-visual components ( somehow it’s always worked with 0.6.4 although it was not supposed to ).

Dependency Injection

• [Autowire] metadata is no longer used to inject dependencies – instead use [Inject]
• Inject any individual property of a Bean by specifying the source. ( Injecting an entire bean (or Injection by Name) using the “source” attribute has been available for some time however, I believe Injection of bean properties is new ).

Injection by Type

[Inject]
public var userService : UserService;    // Injection by Type

- or -

Injection by Name

[Bindable]
[Inject( source="userController" )]    // Injection by Name

- or -

Injection by property

[Bindable]
[Inject( source="userController.currentUser" )]    // Injection by property

Two way Binding

Very cool. Two way binding is supported via the Inject’s twoWay attribute.

[Bindable]
[Inject( source="userModel.currentUser", twoWay="true" )]
public var currentUser:User;

Mediate Multiple Events from a Single Method

Booyah!!

[Mediate( event="UserEvent.ADD_USER", properties="user" )]
[Mediate( event="UserEvent.EDIT_USER", properties="user" )]
[Mediate( event="UserEvent.DELETE_USER", properties="user" )]
public function mediateUserEvents( user:User ):void
{
// do stuff
}

- or -

[Mediate( event="UserEvent.*", properties="user" )]
public function mediateUserEvents( user:User ):void
{
  // do stuff
}

Service Helper

Service Helper is similar to AbstractController, however there is a really cool feature where you can pass an array of parameters that are then passed to your result handler eliminating the need to create an extra private var to hold the value from the service caller method over to the result handler.

public function fetchUserRoles( user:User ):void
{
sh.executeServiceCall( ro.getUserRoles( user.id ), getUserRoles_result, getUserRoles_fault, [ user ] );
}
protected function fetchUserRoles_result( data:Object, user:User ):void
{
user.roles = data.result;
}

Post Construct

[PostConstruct] methods are invoked after all dependencies are injected – for example – setting up a default user after the bean is created.

[PostConstruct]
public function createDefaultUser() : void
{
currentUser = new User();
}

Resources

New Swiz Website:
http://swizframework.org

The Swiz wiki is very well done. I suggest reading the entire user guide on the wiki:
http://swizframework.jira.com/wiki/display/SWIZ/Home

Brian Kotek has put together a nice demo to explore the new features of Swiz here:
http://swizframework.jira.com/wiki/display/SWIZ/Quick+Start

Michael Schmalle has gone a little deeper here:
http://blog.teotigraphix.com/2010/05/21/flex-swiz-1-0rc-demo-under-the-hood/

Region Drill Map – illustrates how to group states into regions, display sales per region and zoom-drill into regions and states.

Radar Region Map – makes practical use of a radar map to display and compare region sales.

Stacked Drill Pie – illustrates how to drill into stacked column chart and display the results as a pie chart.

Wedged Stack – psychedelic use the Axiis wedge as a 2 layer pie chart.

Error 105

I created an AIR app that would support my own File Type extension (mime type). In the fileType’s ‘name’ node, I put ‘My Custom App’. Seemed reasonable since the template comments stated ‘The name that the system displays for the registered file type. Required.‘

Turns out that the ‘name’ needs to be space-free and separated by dots:

<name>My.Custom.App</name>

Error 104

In the case of the 104 Error, I uncommented the ‘contentType’ and entered the mime type (which was text/xml in my case).

<contenttype>text/xml</contenttype>

Hope this saves someone some time and aggravation.

After trying every possible ‘selected’ or ‘active’ CSS tag know to man (actually to Flex), and tracking down every possible path of  inheritance, I embraced one of my coding standards: counter-intuitive measures often prevail over reasonable assumptions.

To my dismay, disabledColor was the ticket. It has nothing to do with the selected state and unlike textRolloverColor and textSelectedColor, it has no mention of ‘text’!

So if I had been smart enough to assume that a selected button is actually disabled, I would have been fine. So when you want to dress up your selected button in your LinkBar/ToggleButtonBar with all kinds of nice-nices, just remember that LinkBar and ToggleButtonBar buttons operate like politicians – just because you’ve been selected does not imply that you’re enabled.

LinkButton
{
textRollOverColor: #006699;
textSelectedColor: #003366;
/* Yes, this one controls the selected button's text color */
disabledColor: #0099cc;

/*Use DownSkin for Disabled to simulate Active/Selected Button */
disabledSkin: Embed(source="theme1.swf", symbol="LinkButton_downSkin");
downSkin: Embed(source="theme1.swf", symbol="LinkButton_downSkin");
overSkin: Embed(source="theme1.swf", symbol="LinkButton_overSkin");
upSkin: Embed(source="theme1.swf", symbol="LinkButton_upSkin");
font-size: 14;
font-weight: bold;
}

We have created two Eclipse/Flex Builder workspaces. Workspace “A” contains our Library Projects that are tested one at time with a “test harness” or “thin-client”. Since only a few Library Projects are open at any given time, builds are peppy.

Workspace “B” is where our main application lives. Instead of pointing the main application to all 10 Library Projects via App Properties > Flex Build Path > Library Path > Project, we point to src directory of each Library Project via  App Properties > Flex Build Path > Library Path > Source Path.

This has improved compile times significantly: from over 2 minutes down to about 5 seconds. Very nice. And if you use the “Linked Resources” feature of eclipse (ours is ‘FLEX_SERVER_ROOT’), there are no path conflict issues in a collaborative environment.

For those of you who haven’t migrated to the tiny six leg creature to do your compiles and prefer using Flex Builder or Eclipse Flex Builder plugin for the job, this a great way to get huge compile-time performance improvements with very little effort. Additionally, the two workspaces gives you the ability to build modular application components as a swc and improved compile times by accessing the swc’s source path.

A quick google search presented me with the following description:

16824 Invalid update descriptor. subErrorID may provide more information.

Although vague, it did lead me to the solution. In my haste to test the updater, I simply copied and pasted the  app_1.0.air file and renamed it to app_1.1. Then I set the updater.xml file’s <version> tag to ’1.1′ pointed the <url> tag to the new ‘app_1.1.air’ file.

The problem occurs when AIR downloads the app_1.1.air file and inspects the <version> tag in it’s app-app.xml file. AIR did not like the fact that version number still remained at ’1′ when it was looking for ’1.1′.  A quick update to 1.1 in the version tag, and upload the new build and problem solved.

If I didn’t want to create a new build, I could have simply renamed app_1.1.air to app_1.1.zip, open the zip file, edit the app-app.xml file and named the file back to app_1.1.air.

Chalk it up to another copy and paste error of a different kind. I hope this saves someone a little time.