[YahooFinance(tickerSymbol="ADBE", days="60")]
public var adobeStocks:IList;

When you annotate the list variable with that metadata the YahooFinanceProcessor gets notified to process it and for the case above fetches the Adobe stock data for the last 60 days. The result is a list of objects which contain a date and a price. You can then bind this list to a chart é voilá, your chart shows live fetched data without writing any code (ok, except declaring the variable).

Here the full source of the view component:

<?xml version="1.0" encoding="utf-8"?>
<s:Group xmlns:fx="http://ns.adobe.com/mxml/2009" 
		 xmlns:s="library://ns.adobe.com/flex/spark" 
		 xmlns:mx="library://ns.adobe.com/flex/mx">
 
	<fx:Script>
		<![CDATA[
			import mx.collections.IList;
 
			[Bindable]
			[YahooFinance(tickerSymbol="ADBE", days="60")]
			public var adobeStocks:IList;
 
			[Bindable]
			[YahooFinance(tickerSymbol="MSFT", days="60")]
			public var microsoftStocks:IList;
		]]>
	</fx:Script>
 
	<s:layout>
		<s:VerticalLayout/>
	</s:layout>
 
	<s:Label text="Stock Prices last 60 days" />
	<mx:LineChart id="chart" width="100%" height="100%" showDataTips="true" dataProvider="{adobeStocks}">
		<mx:horizontalAxis>
			<mx:CategoryAxis categoryField="date" title="Time" />
		</mx:horizontalAxis>
		<mx:verticalAxis>
			<mx:LinearAxis title="Price" baseAtZero="false" />
		</mx:verticalAxis>
 
		<mx:series>
			<mx:LineSeries dataProvider="{microsoftStocks}" displayName="Microsoft" xField="date" yField="price" />
			<mx:LineSeries dataProvider="{adobeStocks}" displayName="Adobe" xField="date" yField="price" />
		</mx:series>
	</mx:LineChart>
	<mx:Legend dataProvider="{chart}" />
 
</s:Group>

The result looks like this:

When you have a look at the source of the YahooFinaceProcessor you see how easy it is to build.

The example also shows how to use the MediateSignalProcessor build by Sam Ahn.
There are also a bunch of other custom metadata processors on the way like the ResourceProcessor also by Sam.
Note that I had to add -keep-as3-metadata+=YahooFinance which you have to do for any new metadata you introduce.

Source and Download

• Get source from GitHub
• Download Flex 4 SWC from GitHub
• API Documentation
• Swiz Desktop includes côdeazur AIR Remote Updater

Define the SwizUpdateBean in your Swiz BeanLoader:

<desktop:SwizUpdateBean xmlns:desktop="com.soenkerohde.desktop.*"
	id="swizUpdateBean"
	updateUrl="http://yourdomain.com/YourApp.air"
	autoCheckUpdate="true" autoStartUpdate="true" />

We have set the update URL and the flag to automatically check for an update and automatically download and invoke the update when a newer version is online.
However you may only want to use this in a very early stage of your development to simply ensure that the user always get’s the latest version. The user experience is a bit odd though since the user get’s no visual feedback at all and might be upset when the app closes, updates and restarts itself.

Control Update
A controller can add event listeners to the SwizUpdateBean to get notified when the update phase change so you get a point to interact. You can autowire the bean also against a setter which gives you the possibility to add event listeners:

package com.soenkerohde.example {
 
	import com.soenkerohde.example.UpdateWindow;
	import com.soenkerohde.desktop.ISwizUpdateBean;
	import com.soenkerohde.desktop.event.OnlineEvent;
	import com.soenkerohde.desktop.event.UpdateEvent;
 
	import org.swizframework.Swiz;
 
	import spark.components.Window;
 
	public class UpdateController {
 
		[Autowire]
		public function set updateBean( bean : ISwizUpdateBean ) : void {
			bean.addEventListener( UpdateEvent.VERSION_INFO, versionInfoHandler, false, 0, true );
			bean.addEventListener( UpdateEvent.UPDATE, updateHandler, false, 0, true );
			bean.addEventListener( OnlineEvent.CHANGE, onlineHandler, false, 0, true );
		}
 
		protected function versionInfoHandler( event : UpdateEvent ) : void {
			// when locale and remote version are different show update window
			if ( event.updateInfo.localVersion != event.updateInfo.remoteVersion ) {
				var updateWindow:Window = new UpdateWindow();
				Swiz.registerWindow( updateWindow );
				updateWindow.open();
				updateWindow.move( 50, 50 );
			}
		}
 
		protected function updateHandler( event : UpdateEvent ) : void {
			// prevent automatic update and wait for user to invoke
			event.preventDefault();
		}
 
		protected function onlineHandler( event : OnlineEvent ) : void {
			var online:Boolean = event.online;
			// TODO handle online status
		}
 
	}
}

Visual Feedback
Since the SwizUpdateBean is loaded in the BeanLoader we can autowire it into any view. The SwizUpdateBean implements the ISwizUpdateBean so we can autowire the interface by type without caring about the id. The ISwizUpdateBean has a getter for updateInfo which is a bindable getter for detailed update status information. In the example below we autowire it by property. We could also access it from the swizUpdateBean.updateInfo but I like it more as an extra member variable.

UpdateInfo gives you access to:

• localVersion
• remoteVersion
• percent
• bytesLoaded
• bytesTotal
• kiloBytePerSecond (we calculate the connection speed of the user)
• timeRemaing (the time in seconds we have calculated remains to download the update)
• updateFilePath (the path to the downloaded update file)

<s:Window width="240" height="210"
		  xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark"
		  xmlns:mx="library://ns.adobe.com/flex/halo" title="Update" alwaysInFront="true" resizable="false" showStatusBar="false">
 
	<s:layout>
		<s:BasicLayout />
	</s:layout>
 
	<fx:Script>
		<![CDATA[
			import flash.events.MouseEvent;
			import com.soenkerohde.desktop.ISwizUpdateBean;
			import com.soenkerohde.desktop.info.IUpdateInfo;
 
			[Bindable]
			[Autowire(bean="swizUpdateBean", property="updateInfo")]
			public var updateInfo:IUpdateInfo;
 
			[Bindable]
			[Autowire]
			public var swizUpdateBean:ISwizUpdateBean;
 
			protected function clickHandler( event : MouseEvent ) : void {
				swizUpdateBean.executeUpdate( false )
			}
		]]>
	</fx:Script>
 
	<s:VGroup horizontalCenter="0">
		<mx:Form verticalGap="0">
			<mx:FormItem label="Your Version:">
				<s:Label text="{updateInfo.localVersion}" />
			</mx:FormItem>
			<mx:FormItem label="New Version:">
				<s:Label text="{updateInfo.remoteVersion}" />
			</mx:FormItem>
		</mx:Form>
 
		<s:Label text="Progress: {updateInfo.bytesLoaded}/{updateInfo.bytesTotal} Bytes" />
		<mx:ProgressBar indeterminate="false" label="Remaining: {updateInfo.timeRemaining} sec with {updateInfo.kiloBytePerSecond} KB/s" mode="polled"
						source="{updateInfo}" />
 
	</s:VGroup>
 
	<s:Button bottom="10"
			  horizontalCenter="0" label="Update and Restart" enabled="{updateInfo.complete}" click="clickHandler(event)" />
 
</s:Window>

You see how easy it is to implement the ProgressBar. Because the updateInfo object has a getter for bytesLoaded and bytesTotal we only have to set the mode to “polled” and can set the object itself as the source of the ProgressBar.

Feedback appreciated or just fork the project on GitHub if you want to extend it.

Source and Download

• Source on GitHub
• Download SWC
• API docs

Usage

Add FGATracker to your BeanLoader:

<ga:FGATracker id="fgaTracker"
	   account="GOOGLE ANALYTICS ID" xmlns:ga="com.soenkerohde.ga.*" />

Dispatch TrackPageEvent or TrackActionEvent:

From a view class (set bubbles=true):

dispatchEvent( new TrackPageEvent( TrackPageEvent.PAGE, "/pagename", true ) );
dispatchEvent( new TrackActionEvent( TrackActionEvent.ACTION "category", "action", "label", NaN, true ) );

From a non-view class:

_dispatcher.dispatchEvent( new TrackPageEvent( TrackPageEvent.PAGE, "/pagename" ) );

You can get a reference if your class implements the IDispatcherBean interface:

private var _dispatcher:IEventDispatcher;
public function set dispatcher(dispatcher:IEventDispatcher):void
{
	_dispatcher  = dispatcher;
}

Disclaimer
Swiz does not require or encourage code behind, just that we decided to support this rare use case for the sake of flexibility.

In this first version Autowire view works only for accessors what should be the common usecase meaning you can autowire a setter with the [Autowire(view=true)] metadata above the setter:

[Autowire(view="true")]
public function set myView(view:MyView):void
{
	//...
}

The setter is invoked when the view is added to the stage and has dispatched the creationComplete event meaning all elements in the view are created and can be accessed. Since all MXML members are public this gives you quite some power but use it wisely to not introduce unnecessary coupling. Because a view is not a bean you have no bean attribute in the Autowire metadata but you autowire by type.

Example handling NativeDragEvent in an AIR app:

This code to handle drag-n-drop usually ends up in the Script block because you have to add the event listeners for dragEnter and dragDrop on for instance a Canvas. One could of course dispatch this further with custom events to a controller which could do the logic but I think letting a class directly add the event listeners could save this extra code:

package example.ctrl
{
	import example.model.SomeModel;
	import example.view.DragView;
 
	import flash.desktop.ClipboardFormats;
	import flash.events.NativeDragEvent;
	import flash.filesystem.File;
 
	import mx.core.IUIComponent;
	import mx.managers.DragManager;
 
	public class DragController
	{
 
		[Autowire]
		public var someModel:SomeModel;
 
		[Autowire(view="true")]
		public function set dragView(view:DragView):void
		{
			if(!view.hasEventListener(NativeDragEvent.NATIVE_DRAG_ENTER))
				view.addEventListener(NativeDragEvent.NATIVE_DRAG_ENTER, dragEnterHandler, false, 0, true);
			if(!view.hasEventListener(NativeDragEvent.NATIVE_DRAG_DROP))
				view.addEventListener(NativeDragEvent.NATIVE_DRAG_DROP, dragDropHandler, false, 0, true);
		}
 
		public function DragController()
		{
		}
 
		protected function getFilesFromDragEvent(e:NativeDragEvent):Array
		{
			if(e.clipboard.hasFormat(ClipboardFormats.FILE_LIST_FORMAT))
			{
				var files:Array = e.clipboard.getData(ClipboardFormats.FILE_LIST_FORMAT) as Array;
				return files;
			}
			return null;
		}
 
		protected function dragEnterHandler(e:NativeDragEvent):void
		{
			var files:Array = getFilesFromDragEvent(e);
			if(files != null && files.length == 1)
			{
				DragManager.acceptDragDrop(e.currentTarget as IUIComponent);
			}
		}
 
		protected function dragDropHandler(e:NativeDragEvent):void
		{
			var files:Array = getFilesFromDragEvent(e);
			if(files != null && files.length == 1)
			{
				var f:File = files[0] as File;
				// notify your model that a file is dragged on the view
				someModel.addFile(f);
			}
		}
 
	}
}

Autowire view can give you more flexibility but for sure more responsibility so take care! So ask yourself twice if you are using the right approach when introducing Autowire view. However, if you have interesting scenarios where you can apply a decent pattern with this approach please share it.

Important

• In some scenarios I have seen that the setter is called twice so you maybe want to add an initView flag. Have to figure out if this is caused by the way Flex works or if this is a Swiz bug.
• Be always sure to add event listeners with a weak reference to enable garbage collection when the view is removed
• When you store a reference of the view be sure to release it when the view is removed to enable garbage collection
• Autowire view is considered to be used for custom components and I have not tried what happens when you autowire a Canvas or a Button or whatever

This release makes Swiz faster, more flexible and even easier to use:

• Support for mediating bubbled event
• Added view attribute in Mediate tag
• Autowire views with view attribute in Autowire tag
• Ignoring view classes with underscore for performance optimization
• Added viewPackages for performance optimization
• Added eventPackages for shorter notation in strict mode
• SwizConfig for Swiz MXML declaration
• Generic fault handler for executeServiceCall
• Autowire bean properties with new property attribute
• Prototype supports class reference and constructor arguments

Swiz got a new member Ben Clinkinbeard who contributed some really cool stuff which makes mediating events more flexible and removed the Swiz dependency from the view because they can now bubble and lot’s of other stuff. Awesome to have Ben on board!

So here a quick overview for each new feature/improvement:

Support for mediating bubbled event

Events don’t have to be dispatched with the central event dispatcher anymore. So when you have a view instead of:

Swiz.dispatchEvent(new FooEvent(FooEvent.CHANGE))

you can do:

dispatchEvent(new FooEvent(FooEvent.CHANGE))

When you want to use this approach you have to

• enable the feature with Swiz.setMediateBubbledEvents(true) or via SwizConfig
• set the bubble flag of the event to “true”
• override clone method of the event

So the view has no Swiz import statement anymore and in fact doesn’t know anything about Swiz except to autowire models.

Added view attribute in Mediate tag

A dynamic mediator can now listen for view specific events. In the following example the dynamic mediator only listens for events dispatches by the view class “MyView”:

[Mediate(event="SomEvent.FOO", view="MyView")]

This is also extremely helpful to code more generic itemRenderers.

Autowire views with view attribute in Autowire tag

You can now autowire views into any bean with:

[Autowire(view="true")]
public function set myView(view:MyView):void
{...}

The setter is invoked when the view is added to the stage and has fired its creationComplete event so you can access all members of the view which in MXML are all public scope.
For more details and an example read my post here.

Ignoring view classes with underscore for performance optimization

This is an internal performance optimization where you as a developer don’t have to change anything except you have view classes with an underscore in the classname.
In Swiz 0.6 view classes with “_” are ignored for dependency injection because these are internal classes like skin classes, cursors or internal non-custom item renderers. Because these kind of classes won’t contain any metadata we can safely ignore them which improves the runtime performance significantly.

Added viewPackages for performance optimization

For further optimization beyond already ignoring underscore classes you can now define one or multiple view packages. If you set this property only views in these packages will get autowired.
You can set the viewPackage with

Swiz.addViewPackage("com.domain.project.view")

or with the new SwizConfig.

Added eventPackages for shorter notation in strict mode

When you are using Swiz in strict mode you can now define eventPackages to have a shorter notation of the event. I already blogged about this feature here.

SwizConfig for Swiz MXML declaration

Instead of adding an event listener for the Application/WindowedApplication preInitialize event and the calling Swiz.loadBeans besides configuring Swiz you can now use the new SwizConfig class in MXML. The markup for an AIR app then looks like this:

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
 
	<mx:Script>
		<![CDATA[
			import mx.rpc.events.FaultEvent;
			import mx.logging.LogEventLevel;
 
			private function genericFault(fe:FaultEvent):void
			{
				// TODO handle fault
			}
 
		]]>
	</mx:Script>
 
	<mx:TraceTarget fieldSeparator="->" includeLevel="true" includeCategory="true" includeTime="true" />
 
	<swizframework:SwizConfig xmlns:swizframework="org.swizframework.*"
		strict="true"
		mediateBubbledEvents="true"
		eventPackages="example.event"
		viewPackages="example.view"
		beanLoaders="{[Beans]}"
		serviceCallFaultHandler="{genericFault}"
		logEventLevel="{LogEventLevel.WARN}"
		/>
 
	<view:SwizConfigTestView xmlns:view="example.view.*" width="100%" height="100%" />
 
</mx:WindowedApplication>

The SwizConfig itself will listen for the preInitialize event of the application and configure Swiz.

Generic fault handler for executeServiceCall

When you use Swiz.executeServiceCall or subclass AbstractController and call executeService call you can leave out the fault handler. When a fault comes up Swiz currently shows an Alert window with the fault details. You can override this like in the SwizConfig example above.

Autowire bean properties with new property attribute

You can now autowire bean members instead of the bean itself. So instead of:

[Bindable][Autowire]
public var someModel:SomeModel;
 
<mx:List dataProvider="{someModel.someList}" />

you can use:

[Bindable][Autowire(bean="someModel", property="someList")]
public var someList:ICollectionView;
 
<mx:List dataProvider="{someList}" />

Prototype supports class reference and constructor arguments

Prototype (see old post here) now support constructor arguments and you can declare a class reference instead of the full qualified class name.
Example:

<factory:Prototype xmlns:factory="org.swizframework.factory.*"
	classReference="{SomeClass}" constructorArguments="{['foo', 'bar']}" />

There will come a lot of new blog posts regarding each new feature soon but I hope this has given an overview about what’s new in 0.6. Besides that we try to add more documentation and example projects.