Derrick Grigg - RIA Developer

Flex Spark List with custom scroll bar and itemrenderer

Tue, 06 Jul 2010 13:09:29 -0600

I recently had a request for some help on skinning a Flex 4 Spark List with a custom scroll bar and item renderers. Even though the skinning process has gotten much easier with Flex 4 and the Spark components there is still a learning curve and a few things that are either learned through a lot of trial and error or by having someone point it out to you. Hopefully with this post I will be able to save some other Flex developers the "trial and error" route.

This is the comp of the list that needed to get created. Nothing to complicated at first glance, the standard Spark scroll bar needs to get replaced and a custom itemrenderer will be needed for the list.

So how does one go about turning the image above into a functioning Spark List, follow along.

Step 1 - Prep the skin pieces

The scroll bar track and thumb from the comp need to be turned into assets that we can use in the Spark skin. The itemrenderer can be completely done with code. If you are familiar with Photoshop turn off the surrounding layers, select the thumb and track, respectively, and then do a 'copy merged' and paste each as a new image. Save them as transparent PNG's that can be embedded into the Flex swf.

Step 2 - Create the Spark Skins

Three skins will be required for this task, one for the thumb, the track and the vertical scroll bar (right click, view source on the swf at the bottom to view all the source code).

The track and thumb skins simply embed the pngs that we created in step 1.

The track skin:


<s:BitmapImage source="@Embed('assets/scroll-track.png', scaleGridLeft='2', scaleGridTop='5', scaleGridRight='12', scaleGridBottom='275')" 
				   left="0"  top="0" right="0" bottom="0" />

And the thumb skin:


<s:BitmapImage source="@Embed('assets/scroll-thumb.png', scaleGridLeft='1', scaleGridTop='5', scaleGridRight='13', scaleGridBottom='97')" 
				   left="0"  top="0" bottom="0" right="0" />

In both cases we use the scale nine attributes to make sure the graphic scales cleanly in the horizontal and vertical directions.

The scroll bar skin sets the skins class for the track and thumb buttons to the new skins we have created.


<s:Button id="track" top="0" bottom="0" right="0"  width="15"
		  focusEnabled="false"
		  skinClass="com.dgrigg.skins.VScrollBarTrackSkin" />

<s:Button id="thumb" width="14"
		  focusEnabled="false" visible.inactive="false"
		  skinClass="com.dgrigg.skins.VScrollBarThumbSkin"   />

That's it for skin creation.

Step 3 - Styling via CSS

Once the skins are created the next step is creating a css file to get the List component to look the way we want. Using css selectors we can tell the List to use the new skin class we have created for the vertical scroll bar on the list. The 'fixedThumbSize' style tells the scroll bar if it should adjust the size of the thumb based on the list length. In this case we want the thumb to always be the same size so it gets set to 'true'. We have also used CSS to turn off the horiztontal scroll bar, sometimes with custom item renderers the horizontal scroll bar will make an appearance when you don't want it to.

s|List 
{
	contentBackgroundAlpha:.5; 
	contentBackgroundColor: #000000;
	borderColor:#000000;
}

s|List #scroller 
{
	horizontalScrollPolicy: off;
}

s|List s|VScrollBar {
	skinClass: ClassReference("com.dgrigg.skins.VScrollBarSkin");
	fixedThumbSize:true;
}

Remember to load the style sheet into the main application class and the new pimped list is ready to go.

Step 4 - ItemRenderer creation

The final step in bring the comp to life is creating the ItemRenderer. Fortunately Flex 4 has made this very easy. Navigate to the package you want to create the renderer in and then right click and select 'New/MXML Item Renderer'. A basic item renderer will be created that you can begin working with. Here is the code for the item renderer we will be using.


<?xml version="1.0" encoding="utf-8"?>
<s:ItemRenderer xmlns:fx="http://ns.adobe.com/mxml/2009" 
			xmlns:s="library://ns.adobe.com/flex/spark" 
			xmlns:mx="library://ns.adobe.com/flex/mx" 
			autoDrawBackground="false" height="85" width="385">
<fx:Script>
	<![CDATA[
		
		override public function set data(value:Object):void 
		{
			super.data = value;
			
			if (value)
			{
				titleLbl.text = data.title;
				contentLbl.text = data.text;
				titleLbl.visible = true;
				contentLbl.visible = true;
				readLbl.visible = true;
			}
			else
			{
				titleLbl.text = "";
				contentLbl.text = "";
				titleLbl.visible = false;
				contentLbl.visible = false;
				readLbl.visible = false;
			}
			
		}
	]]>
</fx:Script>
<s:states>
	<s:State name="normal" />
	<s:State name="hovered" />
	<s:State name="selected" />
</s:states>

<s:Rect left="0" right="0" top="0" bottom="0">
	<s:fill>
		<s:SolidColor color.selected="0x383c40" color.normal="0x23252a" color.hovered="0x383c40"
					  alpha.selected="0.8" alpha.hovered="0.5" alpha.normal="0.8" />
	</s:fill>
</s:Rect>

<s:Label id="titleLbl" 
		 x="15" y="15" 
		 width="370" color="0xffffff"/>

<s:Label id="contentLbl" 
		 x="15" y="30" 
		 width="370" height="30" 
		 color="0xeeeeee" fontSize="11"  />

<s:Label id="readLbl" 
		 x="15" y="65" 
		 color="0x336699" color.selected="0xCCCCCC" 
		 text="READ MORE" fontSize="11"/>

<s:Line left="0" right="0" bottom="0" width="1">
	<s:stroke>
		<s:SolidColorStroke color="0x000000"/>
	</s:stroke>
</s:Line>

</s:ItemRenderer>

A few things to note in the itemrenderer code. First, the 'autoDrawBackground' attribute on the ItemRenderer base class is set to 'false'. This turns off the selected/rollover/hover background that normally gets drawn and displayed. The s:Rect instance is used with the state selectors on the color attribute to create custom rollover color/alpha combinations. The normal list will allow you to change the color but you can't tweak the alpha so this is your best option. Second, the 'set data' method was overwritten in order to set the values of the various labels. This is a must step for pretty much any custom item renderer. The overwritten method does a small check to see if the incoming value exists, if not the labels get hidden. This is always a good practice to prevent empty rows from appearing in the list.

Wrap up

That's it. A custom scroll bar and item renderer in four steps. No rocket science, just a little Flex know how. You can view the source code here.

And this is the final product, not bad.

Editable ItemRenderer for Flex 4 Spark List

Fri, 25 Jun 2010 09:40:22 -0600

One of the nice features of the Flex mx:List component is that you can set the renderers to be editable without having to create a new itemrenderer. With the Spark List (s:List) that option is no longer available. Fortunately it is quite easy to create a custom editable itemrenderer for the List.

Select an item in the left column and change the value, you can see the change events being traced out. Right click to view the source code.

There are three steps making an editable itemrenderer for the Spark List component.

First

Create a custom itemrenderer with a TextInput and a Label.

 <?xml version="1.0" encoding="utf-8"?>
 <s:ItemRenderer xmlns:fx="http://ns.adobe.com/mxml/2009" 
             xmlns:s="library://ns.adobe.com/flex/spark" 
             xmlns:mx="library://ns.adobe.com/flex/mx" 
             autoDrawBackground="true">
 
    
    <s:Label id="labelDisplay" 
           text="{data.label}"   
           top="7" bottom="5" left="5" right="3"/>
    
    <s:TextInput id="inputTxt"  
              visible="false"  
              top="1"  bottom="1" left="1" right="0"/>
    
 </s:ItemRenderer>

Second

In order to toggle between the read and write states we need to add a click handler to the label and focusOut handler to the text input. You will notice that I simply set the respecitive components to either visible or not instead of uses the spark states. Using the spark states would require extending the list component to include an editHover state and for this example I wanted to keep things simple.

 <fx:Script>
   <![CDATA[
 	 import spark.components.supportClasses.ListBase;
 	 
 	 private function onChange(event:Event):void 
 	 {
 		isEdit(false);
 		
 	 }
 	 
 	 private function onEdit(event:Event):void 
 	 {
 		inputTxt.text = data.label;
 		isEdit(true);
 		//set cursor postion to end
 		inputTxt.selectRange(inputTxt.text.length,inputTxt.text.length+1);
 		inputTxt.setFocus();
 	 }
 	 
 	 private function isEdit(value:Boolean):void 
 	 {
 		labelDisplay.visible = !value;
 		inputTxt.visible =  value;
 	 }
 	 
   
   ]]>
 </fx:Script>
 
 
 <s:Label id="labelDisplay" 
 	  text="{data.label}"   
 	  click="onEdit(event)" 
 	  top="7" bottom="5" left="5" right="3"/>
 
 <s:TextInput id="inputTxt"  
 		 visible="false"  
 		 focusOut="onChange(event)"
 		 top="1"  bottom="1" left="1" right="0"/>

Third

This is the not so obvious step. You need to manually dispatch an event through the List's dataProvider in order to notify the List and anything else that is using the data source that it's contents have changed.

private function onChange(event:Event):void 
 {
 
 var oldValue:String = labelDisplay.text;
 
 if (oldValue != inputTxt.text)
 {
    data.label = inputTxt.text;
    labelDisplay.text = inputTxt.text;
    
    
    //dispatch the data update event
    var list:ListBase = this.owner as ListBase;
    list.dataProvider.itemUpdated(data, 'label', oldValue, inputTxt.text); 
 }
 isEdit(false);
 
 }

And that's it. A basic editable list itemrenderer for the Spark List in 3 easy steps. Right click on the swf to see the source code.

Developing Flash and Flex applications for Android

Wed, 23 Jun 2010 11:21:44 -0600

Since Apple kiboshed Adobe's hopes of iPhones running Flash content, Android (Google) has stepped up and offered Flash and Flex developers a mobile platform to development and deliver content on. This has come as great news to Flash platform developers who want the opportunity to dive into the mobile environment. Many Flash (and Flex) developers I have spoken to about mobile development are still unsure about what it will take to deliver Flash player based content and applications to mobile devices.

The good news is the development and delivery process is almost identical to the current process. Use Flash or Flash Builder to create a swf file and then either deploy that to a website, to be served up via an HTML page or wrap it with the AIR runtime and packge it for installation on an Android phone as an native Android installer. Really the only difference in developing for the Android platform is the extra step required to create an '.apk' file if you want to create a stand alone application.

The bad news is the environment that the content and applications are running in is quite different from anything the vast majority of Flash platform developers have worked in. The screen is small, the bulk of user interactions are touch based, the screen can easily be rotated and tilted, the user is often quickly looking at the screen while interacting with the environment around them (ie texting and walking at the same time) and the processor doesn't have the juice most modern desktops and laptops have. This means that while the swf delivery and development process is quite familar the UI and UX development is anything but. Add in the processing constraints and most Flash platform developers will quickly realize there is a significant learning curve to developing Flash and Flex content for Android (and mobile in general) devices.

So what are the key areas developers need to be aware of?

Screen size
User interaction
Device capabilities
Performance

1. Size, it really does matter

Below are two screen shots of the same Flash application running on a Google Nexus One and a normal desktop computer. The application is 480 x 800. The first image shows the screen as seen on a normal desktop computer with the screen resolution set at 1280 x 1024 (fairly standard desktop resolution). The second image shows the same screen scaled to the physical size as seen on the Nexus screen. It might seem obvious that the mobile screen will be smaller than the desktop screen but watch how screen resolution affects something that is the "same" size.

Desktop screen shot

Android (Nexus One) screen shot

As you can see there is a huge difference in the physical size of the two screens even though the application is viewed at 480 x 800 pixels on both devices. Mobile devices have much higher screen resolutions than normal computers, 240dpi vs 72dpi. As you can see from the images above this makes a huge difference.

For mobile applications this has two very big implications.

First a smaller screen with a much higher resolution means you have much less physical real estate to work with when laying out the user interface. Designers need to be acutely aware of this when creating screens and views. Add in the fact the users are often quickly glancing at the screen which means screens can not afford any clutter and designers have a difficult task in packing a lot of meaningful content into a very small area.

Second, since everything appears much smaller on mobile screens things like text and UI controls (button, checkboxes, etc) need to made larger for readability and clickability (if a beer company can use drinkability I can use clickability). On a mobile device the main pointer is the finger tip which is a lot larger and less precise than a mouse pointer. In a desktop application the typical button size is around 25 pixels in height, on a mobile device 60 pixels is the norm, anything smaller than that and it becomes very challenging to click the button you want.

I couldn't help but be reminded of this Simpson's clip after my first experiments building a Flash application for the Android.

This leads to my second point.

2. User interaction, it's all about the finger

Apple and the iPhone ushered in a whole new era of computer interaction. Sure 'touch' has been around for a long time, but it was Apple who made it mainstream. Point and click are things of the past, now it's point, flip, swipe, pinch, wipe. Sounds more like a heated game of rock-paper-scissors. The great news for Flash platform developers is that AS3 has full gesture support built in and ready to be used. Events are dispatched for a multitude of user gestures including tapping, swiping and rotating. AS3 also supports multi touch for instances where multiple touch points need to be tracked.

This is a whole new territory for Flash and Flex developers, we generally just interact with the mouse and keyboard, a few of us (myself included) have developed for larger touch screens, but not small mobile screens. Fortunately there is some good information to be found on designing for human interaction. Google has provided some guidelines for user interface design and Apple has some really good (and thorough) documentation on Human Interface design.

This is an area that will make or break an application. It won't matter how great the apps processes information or what information it displays or what it allows users to do, if the control is non-intutive and confusing users will drop it faster than a hot potato (and they may just throw their phone).

3. Device Capabilities, the swiss army knives of personal computing

Most mobile devices have as many sensors and media inputs as swiss army knives have blades. There are GPS sensors, accelerometers, touch screens, cameras, microphones, video cameras, scroll balls, the list goes on. The trick for developers is figuring out how to leverage the various sensor inputs (and outputs) to create unique and pleasant user experiences.

For the Flash and Flex developer most (if not all) of these sensors will be available to AIR based applications and most of them will be available to browser based swfs. This an area where Flash applications will really be able to shine. Flash has supported camera and video input for a long time, working with these types of media inputs should be second nature to many Flash platform developers. Some of the other sensor inputs are new (ie accelerometer, microphone and gps) but Flash has the advantage of being able to access and use them, sorry HTML5 and javascript.

Personally I think Flash is uniquely positioned to offer mobile users amazing experiences based on the capabilities of the devices. Flash has been used for years to create amazing, immersive, media rich user experiences. With increased ways to receive and provide feedback between the user and device who knows what applications will start to look like and how they will function.

4. Performance, where the rubber meets the road

Performance, performance, performance. This is "allegedly" why Apple doesn't offer Flash on the iPhone/iPad. I don't buy it. I have seen Flash running on Android devices first hand, both in the browser and as stand alone applications and trust me it runs perfectly. Adobe has worked very closely with mobile manufacturers to provide hardware acceleration, reduce battery usage and deliver maximum performance with the upcoming Flash 10.1 release.

The critical issue for developers is to remember they are developing for devices that don't have the same processing resources of typical desktop and laptop computers. Special attention needs to be paid to optimizing performance as much as possible. Grant Skinner has a great presentation on Flash performance, where gains can be found and where trouble lurks. Garbage collection, green threading, blitting and generics are all areas that AS3 developers should understand in order to optimize and maximize the performance Flash can deliver.

The old computer mantra is "garbage in ...garbage out". If your application runs slow, freezes or crashes, don't blame the device, virtual machine, Adobe, Google, Android or your mother, first look at your code. This is where the majority of backlash against Flash performance should really be pointed. It's not the Flash plugin and runtime, it's the fact that anyone can "develop" a Flash application and many people that do, don't understand the performance and memory implications of what they are doing. With the ability to release Flash applications and content to mobile devices, Flash will be under increased scrutiny, do the community a favor and write clean, efficient code.

Where to next?

Who knows? The mobile environment is like the internet was 10-15 years ago, the wild wild west. A lot of really cool things will get made and a lot of dogs will come and go. The only thing I am sure of is that the Flash platform will have a large place in how applications and content get developed, deployed and used. It's an exciting time for Flash platform developers, especially after all the HTML5/Apple rhetoric. Get a mobile device, get some neat ideas or find someone who has them and build something amazing, I know I will be.

Flash is dead? Long live Flash!

Thu, 03 Jun 2010 19:50:34 -0600

There has been a ton of hype, speculation and news recently regarding Flash's impending demise. I won't go into the details because it's been hashed over repeatedly and I really don't feel like beating a dead horse.

As a Flash and Flex developer I have a huge vested interest in where the Flash platform goes and whether or not it survives. I stumbled across this video interview with Jesse Freeman (aka the Flash Bum) where he talks about his take on Flash's future (skip to 10:20).

Personally I think Jesse is mostly correct. Mobile is critical to Flash's future success and it must keep evolving.

The world is moving to a constantly connected, mobile environment where devices quite different from the traditional desktop/laptop will rule. As someone who has been involved with early development using Flash and Flex technology on mobile devices I can say Adobe has done a good job with their recent push to get Flash running on devices (1000% better than anything Flashlite was), but there is still a lot of work to do. I'm excited and encouraged by the work they have done with industry leaders in the mobile arena via the Open Screen Project and I honestly believe Flash will be a large player in mobile development for the same reason it currently is in the desktop/laptop environment, they give developers a consistent platform to deliver applications and content with across devices, something no other company or open source initiative offers.

For Flash to succeed Adobe needs to keep the platform evolving. I have worked with Flash (and Actionscript) since Flash 4 was around, over ten years ago. Today's Flash is lightyears ahead of anything it was ten years ago. It has evolved from a simple animation program to something you can create complex websites and internet applications with. Actionscript is now on it's third major revision and approaches more traditional languages like C and Java in terms of usefulness and potential. As a developer (in any language) if you sit down and objectively consider what is possible to run in almost any browser today through the Flash plugin it is almost mind blowing the functionality and performance that can be delivered. Things that were only possible a few short years ago in full blown, heavy client applications that needed to be installed on a computer can now be delivered rapidly through the browser, anytime, anywhere.

Jesse seemed a little pessimistic about Adobe's ability to keep Flash/Actionscript from becoming stagnant and going the way of the Doodoo bird. I'm more optomistic, having seen where Flash, and more importantly Actionscript, was, where it is, and where it's heading. I think if anything, Adobe will put more focus on Flash and continue to rapidly push it ahead of competing technologies like Silverlight and to a lesser extend HTML5. Actionscript, as it becomes more rounded and powerful, will become more mainstream and entrenched, much like Java has from it's early days.

In closing, I could list out many of the things you can do with Flash/Flex/Actionscript but the video below does a nice succinct job and paints a better picture than anything I could say.

Updates to Skinnable Minimal Components

Wed, 12 May 2010 09:14:14 -0600

After a short holiday I have made some updates to the Skinnable Minimal Components. The ComboBox, List, TextArea, HScrollBar and VScrollBar can now all be skinned. You can find the source code on GitHub. I have not had time to create embedded image and drawing api versions of the skins but you can see the basic skinnable versions below.

The following Minimal Components can now be skinned:

CheckBox
ComboBox
HSlider/VSlider
HScrollBar/VScrollBar
Label
List
PushButton
Text
TextArea

More to come.

Alpha Release of Skinnable Minimal Components

Wed, 28 Apr 2010 12:12:28 -0600

If anyone has used Minimal Components by Keith Peters you know what a great set of componets they are. The only knock against them was the fact they could not be skinned. Until now.

In order to make the components more flexible from a visual standpoint yet retain the minimal footprint I have developed a basic set of classes for drawing shapes and fills and the required logic to handle skinning was added. If you have worked with Flex 4 or Degrafa it should be quite obvious, after looking at the source code, how the components and skins interact and how skins are created. Using either programmatic (ie drawing api) or embedded images you can now easily skin the Minimal Components to your heart's desire.

The demo has three sets of the same components. The first set uses the standard components. The second set is skinned with programmatic skins and the third uses embedded pngs. This demo is super light, even with embedded graphics it weights in at 52kb, compare that to well over 500kb for a comparable Flex app.

The main push to add skinning was Adobe's entrance into the mobile development space. Being involved in the pre release programs for the iPhone and Android packagers it was quickly apparent to any Flex developer involved that Flex is totally not suitable for mobile app development. Note that I said Flex, not Flash. It's just too heavy and processor intensive. This posses a huge dilema for developers accustomed to having a good set of UI components to build with, for now there is nothing to build with. Components would need to be built from scratch. That's a huge non starter for most developers.

Adobe is working to address this with the Slider framework however until that is ready for showtime Flex and Flash developers wanting a decent component set to build mobile apps with are left hung out to dry. Minimal Components seemed like a perfect fit. There are a lot of them, 32 by my count, they are very lightweight and very efficient (all a testament to Keith's skill). The only thing they needed was an easy way to skin them and to separate the view from the core component logic. That's were I focused my energy.

They are still a work in progress. All the necessary work to handle skinning and associating components and skins has been done. Now the work involves refactoring each component (creating a default skin and removing the drawing logic from the component). Currently the Label, PushButton, Text, HSlider and VSlider have been done (as you can see in the demo). All the other components will get converted. Once all the components are skinnable the next major step is adding gesture support.

If you would like to try out the new skinnable version you can find the source code on GitHub. These are still alpha so I'm sure some issues will be uncovered however I want to get this out in the public domain, especially for other Flex and Flash mobile app devs.

Try them out and let me know what you think.

When Flex goes on a SlimFast diet

Mon, 12 Apr 2010 13:33:23 -0600

While digging around looking for some info on Keith Peters Minimal Comps I stumbled across a great post by Ryan Campbell on creating pure Actionscript projects using MXML. Actionscript projects using MXML??? yes that's right. Using MXML markup you can create classes without all the Flex overhead. This means you get the benefit of clean easy to read MXML without the bulk of Flex. I will admit, I was completely blown away. I love programming in Flex, I find it much easier and quicker to layout components and views using MXML but I'm often conflicted when I factor in the size advantage a plain Actionscript project has over a Flex project. Now you can have the best of both worlds.

Here is what the mxml looks like.

<?xml version="1.0" encoding="utf-8"?>
 <comp:Container xmlns:fx="http://ns.adobe.com/mxml/2009"  
             xmlns:comp="com.dgrigg.components.*" 
             xmlns:text="flash.text.*"
             width="250" height="200" 
             color="0xdddddd">
    <fx:Script>
       <![CDATA[
          [Bindable]
          public var text:String = 'Click block to change color';
          
          private function onClick(event:MouseEvent):void 
          {
             var target:Component = event.target as Component
             target.color = Math.random()* 16581375;
             
             text = 'Color: #' + target.color.toString(16);
          }
       ]]>
    </fx:Script>
       <text:TextField id="tf" 
                   x="20" width="200" height="200" 
                   text="{text}"/>
    
       <comp:Component id="comp1" 
                   x="20" y="20" width="200" height="20" 
                   click="onClick(event)"/>
    
       <comp:Component id="comp2" 
                   x="20" y="50" width="200" height="40" 
                   click="onClick(event)"/>
    
       <comp:Component id="comp3" 
                   x="20" y="100" width="200" height="60" 
                   click="onClick(event)"/>
    
 </comp:Container>

I looks just like a Flex MXML class but when compiled it's 12kb vs 532kb (debug version) and 8kb vs 235kb (non-debug version). Wow. If I add the [Bindable] tag, as you can see in the example it adds about 4-6 kb to the non Flex version.

Soure code.

Creating a project to do this is super easy. In Flash Builder (Flex Builder) create a new AS3 Project. After the setup is done

go to the project properties
select Actionscript Build Path
select Library path
Add SWC
Browse to the 'framework.swc' in the Flex SDK dir you are using (ie /flex_sdk_4.1.0.14965/frameworks/libs) and select it.

Now you are ready to go. To create a new MXML class you may need to a create new File instead of create new MXML component. Just make sure you use the MXML file extension and declare the 'fx' namespace

xmlns:fx="http://ns.adobe.com/mxml/2009"

One of the really nice features of coding this way is you can setup event listeners in the MXML just like in Flex, you don't need to type out addEventListener(onEvent, Event.TYPE) blah blah each time.

As I start working on some projects using this method I'm sure I will be posting some more information. The next step is building out a full blown app with RobotLegs and hopefully Degrafa for the skinning.

Flex Spark application background alpha

Thu, 25 Mar 2010 07:32:21 -0600

Sometimes when creating a web based Flex application you want the background to be transparent or semi-transparent. In Flex 3 this involved two steps, setting the 'backgroundGradientAlphas' property on the mx:Application to [0,0] or something less than 1 and setting the 'wmode' on the swf to 'transparent'. Now with Flex 4 (Spark) it's not quite so easy, there is no 'backgroundGradientAlphas' style on the s:Application.

If you want background alpha on the new Spark Application component you need to create a custom skin and a style to the spark:Application. It's surprisingly easy and I actually like this method because it gives the developer much more freedom in how they would like to implement background transparency.

Step 1: modify the default application. Add a new style property using the fx:Metadata tags and tell the application to use the new skin class you are about to create with the 'skinClass' attribute.

 <?xml version="1.0" encoding="utf-8"?>
 <s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" 
 			   xmlns:s="library://ns.adobe.com/flex/spark" 
 			   xmlns:mx="library://ns.adobe.com/flex/mx"
 			   skinClass="com.dgrigg.skins.ApplicationSkin" 
 			   backgroundColor="0xFFFFFF" 
 			   backgroundAlpha="0"
 			   width="100%"
 			   height="100%">
 	<fx:Metadata>
 		[Style(name="backgroundAlpha",type="Number",default="0")]
 	</fx:Metadata>
 </s:Application>

Step 2: set the new 'backgroundAlpha' style value to whatever you want in the s:Application declaration using the 'backgroundAlpha' attribute (see above).

Step 3: create a new version of the default spark.skins.spark.ApplicationSkin class and change the following section from this:

 <s:Rect id="backgroundRect" left="0" right="0" top="0" bottom="0"  >
 	<s:fill>
 		<s:SolidColor color="{getStyle('backgroundColor')}" />
 	</s:fill>
 </s:Rect>

to this:

 <s:Rect id="backgroundRect" left="0" right="0" top="0" bottom="0"  >
 	<s:fill>
 		<s:SolidColor color="{getStyle('backgroundColor')}" 
 		alpha="{getStyle('backgroundAlpha')}" />
 	</s:fill>
 </s:Rect>

And remember to set the wmode to transparent on object/embed tag. The great part about using a custom skin is you are free to implement a background alpha however you wish, you can do a plain alpha fill, or you could do something more exotic like a radial or linear alpha fill.

Spark NavigatorContent gotcha

Mon, 22 Mar 2010 14:58:01 -0600

The release of Flash Builder 4 and the new Spark components means most Flex developers will be going through the process of discovering what has changed from Flex 3 to Flex 4. For the most part the changes are pretty well documented and with a little trial and error things that used to work and now don't can be easily adjusted to work again. Over the next few months as I work on a few projects using Flash Builder 4 and Flex 4 with the new Spark components I will be sharing my experiences, the tricks I learn and how to avoid the pitfalls I will undoubtably find myself in.

One of the first pitfalls I have run across is using the MX navigator containers (ie ViewStack, TabNavigator, etc). The Spark component set has no corresponding components and due to differences in the Spark containers you can not simply add a Spark group to a navigator container like you can an MX container. You need to wrap the Spark component(s) in a NavigatorContent instance first. It's a little cumbersome but I have found that if the view you are creating will only be used in a navigator container then it's easiest to simply have you component/view extend the NavigatorContent class.

There are some basic demos here and here on how to use the NavigatorContent in a navigation container. The problem I ran into was with the creation policy. As you likely know navigation containers have a creationPolicy property that determines when the children get created. Ideally you use the default setting which means the children only get created as needed. The issue I had was in Flex 3 you could have a creationComplete event listener on the navigator children and it would only fire once the container was displayed. In the function called from the event you could access any of the container's children as you knew at that point they had all been created.

Unfortunately in Flex 4 with the Spark components this no longer holds true. When you use the NavigatorContent class the creationComplete event is dispatched immediately when the navigation container (ie ViewStack is added to the stage) however if the creationPolicy is not set to all, the actual children on the NavigatorContent have not yet been created and you end up with RTE's when referencing the children. To prevent this from happening you need to listener to a new event, the 'contentCreationComplete' event which only fires once the NavigatorContent becomes visible.

You can quickly see in the demo below how the two differ (right click to view the source).

The MX Views only fire the 'creationComplete' when the view is displayed. At that point any children of the view can be accessed. The Spark views however, all fire the 'creationComplete' when they are first added to the ViewStack. At that point accessing any child object of the view will throw an error. It's after the 'contentCreationComplete' that you can access children of the Spark view. It's a little semantic difference, but it's a huge headache the first time you run across it.

Stand up, make a sign and take a stand!

Tue, 16 Mar 2010 12:17:26 -0600

If you live in Massachusetts and are concerned about the education system you should visit Standforchildren.org . It's not very often I work with non-profit organizations however this was a really neat project to be involved with. Stand For Children wanted to get the message across to legislators in Massachusetts and across the US that childrens' needs and rights regarding public education need to be heard.

The team at Stand For Children wanted people to actively create, post and share virtual signs about their stand for the public education system. Brian from the The ID Corp came up with a great concept and using some Flash and PHP magic I was able to execute it.

Living in Canada it's an entirely different situation with public education. I was shocked to find out just how different (and not for the better) the US public education system is. Stand for Children has a great team and I hope this campaign and more like it will help pave the way for a more promising future for America's youth.

So go ahead. Take a stand.