I completely agree that it has been poor communication from Adobe, especially after what they have announced at AdobeMAX this year. So, timing could have been better and the messages that they initially shared could have been better formulated. Adobe acknowledges this and have sent out their apologies for that as well. But the harm was already done. I even saw people leaving prerelease and other programs (I can’t mention by name) furious about what happened and turning their backs on Adobe entirely. I respect those decisions, but come on, is it really such a bad thing?

For those of you who are not quite up to speed on what exactly is going on at Adobe. Let me briefly state the latest developments.

Let’s start with LiveCycle. For those of you who don’t know what LiveCycle is, it is a product that allows you to define information workflows, mainly based on PDFs. So, for example, you could fill out a job application form in a PDF, digitally sign it with you eID card (in Belgium at least) and send it to a specific email address. The PDF attachment gets picked up from the mailbox and the information is extracted and put in a database. After that a “thank you” email is sent to the applicant, while in the mean time the HR manager is notified of a new application. Upon approval by the HR manager in the so called “workspace” a new PDF is sent to the unit manager, notifying him that he should interview this candidate, together with the candidate’s résumé. After the interview the unit manager can then input his findings in a evaluation form and LiveCycle will pick that up as well to put it into the database and notify the HR manager that the evaluation has been submitted. Would the candidate be rejected, the can be marked in the “workspace” again for example, an automatic email will be sent to the candidate notifying him of his rejection.

Now, this is just one example of what LiveCycle can do. Even though Adobe is shifting its focus towards other strategic solutions, they will continue to develop LiveCycle (as you can read here), invest in finding new customers and product support is still guaranteed, so you’re not left alone with your solution if you’re currently using LiveCycle.

As for dropping the Flash Player on mobile devices, I don’t think that is a bad thing. You see, if Adobe wants to keep the same version of the Flash Player on all devices (desktop, mobile, tablet) then a lot of code will have to go in checking whether or not things certain features are available. This requires a lot of effort and slows down progress on the features that matter the most. I mean, come on, when did you actually use a Flash based website on you mobile device? Either it wasn’t mobile optimized causing frustration in content that is not scaled properly, or it just was overkill for a mobile device.

Now Adobe has the opportunity to focus on the desktop platform and make full use of the GPU hardware acceleration and other cool features that require more processing power than what the other devices can offer at this moment. It is clear that Adobe wants to move in the direction of gaming with Flash, which I have been expecting for some time now.

Remember, I just said that the Flash Player will be dropped on mobile. That does not mean that the cross-device AIR solution is being dropped. On the contrary! AIR for mobile devices will continue to be developed by Adobe and is one of the key products/features they will maintain. So you don't have to worry about your cross-device development.

However, the Flex SDK is going to be put into the Apache project, bringing along a new produt name as well, since Adobe won’t own the SDK anymore. Once the incubator is accepted, the product will be called "Apache Flex". You can read all about the Apache Flex Incubator right here.

That means that from that point on the SDK will be developed and maintained by the community. That will be a good thing in the sense that probably we’ll get more features more rapidly developed. But – and there’s a big "but" in here – I do see a problem in the adopt of the Flex technology in big companies. You see, what companies want is a support contract with time frame commitment. They want a red phone to the help desk when they encounter serious problems and at the moment they are paying big money for that. Once Flex is owned by the community, Adobe probably won’t be doing anymore support, because it is now up to the community.

This lack of support is what could harm Flex in the high end business companies. But then again, this will also lead to new opportunities for companies such as multimediacollege in the sense that we can now write and publish our own training material, as well as provide support contracts for helping out companies who need assistance with some Flex problems.

So, is Flex dead? Definitely not! And it isn’t dying either. We will have a huge community supporting the development and some highly skilled developers working on the features. I wish I had some magical device that allows me to see into the future to see what will happen with Flex when it becomes completely Open Source. But for now, I’m not yet worried about it’s future…

Now, the problem with these validators is that they are geared towards validating one single visual component, such as a TextInput, TextArea, ComboBox, List etc. But what about compound components, such as a DateField combined with a TextInput field for the time? Or, as I will explain in this post, a RadioButtonGroup, which is a non-visual component, but actually comprises the different RadioButton components?

Before I go into how I solved that problem, let me explain a bit about the Flex Validator class. This is the base class for all the different validators and can only check on a field being required or not. This also means that we are going to inherit from this component to create our own validator classes. Of course, you can extend other validator classes as well, but for my purpose of checking to see if a RadioButton in the list has been selected, the Validator base class will be just fine.

<mx:Validator source="{componentToCheck}" property="propertyToCheck" 
              trigger="{componentToMonitor}" triggerEvent="eventToMonitor" 
              required="true(default)|false" 
              requiredError="errorMessage"/>

As you can see in the code sample above there are a couple of important properties in the base class we have to keep in mind when developing our own validator class. First of all, the componentToCheck will be an instance of RadioButtonGroup and the propertyToCheck will be the selection property. You can use the trigger and triggerEvent properties to determine when the validation needs to take place. Leaving out the trigger property and explicitly setting the triggerEvent to an empty string will make sure that the Flex framework will never trigger the validation by itself. That means that we have to do that manually at the exact time that we want the validation to happen.

In the code below you can clearly see the usage of these properties in both <co:RadioGroupValidator/> instances. For all good purposes I’ve also made both a Spark and Halo form to show you the RadioGroupValidator works with both Spark and Halo components.

<fx:Declarations>
	<s:RadioButtonGroup id="rbgSpark"/>
	<mx:RadioButtonGroup id="rbgHalo"/>
	<co:RadioGroupValidator id="vRbgSpark" source="{rbgSpark}" property="selection" triggerEvent=""/>
	<co:RadioGroupValidator id="vRbgHalo" source="{rbgHalo}" property="selection" triggerEvent=""/>
</fx:Declarations>
 
<s:Form defaultButton="{btnSubmitSpark}">
	<s:FormHeading label="Spark form"/>
	<s:RadioButton label="Choice 1" group="{rbgSpark}"/>
	<s:RadioButton label="Choice 2" group="{rbgSpark}"/>
	<s:RadioButton label="Choice 3" group="{rbgSpark}"/>
	<s:RadioButton label="Choice 4" group="{rbgSpark}"/>
	<s:Button id="btnSubmitSpark" label="Submit" click="sparkSubmitHandler(event)"/>
</s:Form>
 
<mx:Form defaultButton="{btnSubmitHalo}">
	<mx:FormHeading label="MX form"/>
	<mx:RadioButton label="Choice 1" group="{rbgHalo}"/>
	<mx:RadioButton label="Choice 2" group="{rbgHalo}"/>
	<mx:RadioButton label="Choice 3" group="{rbgHalo}"/>
	<mx:RadioButton label="Choice 4" group="{rbgHalo}"/>
	<mx:Button id="btnSubmitHalo" label="Submit" click="haloSubmitHandler(event)"/>
</mx:Form>

As for the RadioGroupValidator class itself, the only thing we need to do there is to override the validate method to see wether or not the validation succeeded. If the validation failed we need to loop over all the RadioButton components that belong to this group and set their errorString to the proper message, as you can see in the code below.

import mx.events.ValidationResultEvent;
import mx.validators.Validator;
 
public class RadioGroupValidator extends Validator {
	public function RadioGroupValidator() {
		super();
		requiredFieldError = "Please choose an option from the list."
	}
 
	override public function validate(value:Object=null, suppressEvents:Boolean=false):ValidationResultEvent {
		var result:ValidationResultEvent = super.validate(value, suppressEvents);
 
		for(var i:uint = 0; i < this.source.numRadioButtons; i++) {
			if(result.type == ValidationResultEvent.INVALID) { 
				this.source.getRadioButtonAt(i).errorString = result.message;
			} else {
				this.source.getRadioButtonAt(i).errorString = null;
			}
		}
 
		return result;
	}
}

Now, as you can see I’ve also set the errorString in the constructor to a specific message. This doesn’t mean that you can’t provide your own specific message anymore in the instance declaration. The reason for this is that setting a property in MXML actually uses the implicit setter method and that one is executed after the constructor has initialized the object, which means it will simply overwrite the default value.

P.S.: If you test the forms, you will see that the Spark form doesn’t show the red error indicator as well as the MX form. Maybe that’s a glitch in the framework, maybe not. I’m still hunting that little sucker down, but no luck so far. I will update this example when I solved this problem.

So far, I was quite happy with my PlayBook, but I did have some concerns regarding its functionality. For example, one of the preinstalled software was Bing maps, which uses the GPS to get a fix on your position. However, documentation on the PlayBook stated that it has a GPS on board, but I never could get a lock on any satellites, no matter which geolocation application I was trying. Even testing the GPS availabilty with an Adobe AIR application by checking the GeoLocation.isSupported property gave me a confirmation that the device has a GPS (which I was doubting after all my efforts).

Talking about AIR applications, those of you who tried to get an app on the PlayBook have noticed that up until now the operating system only supports version 2.5, whereas creating mobile AIR applications required AIR 2.6 or higher. That was a problem, but it could be fixed by adding the -forceAIRVersion 2.5 option to the BlackBerry packaging options in Flash Builder. (Or you could of course compile and create the package using the command line tools). Although being solvable, this remained an inconvenience

Now, with the latest update things have changed. First of all, I’m delighted to say that the GPS is finally working properly and I even get a lock when indoors, which cannot be said for most GPS devices. Not that I’m using it that much, since the PlayBook only has WiFi available and no 3G connectivity (well, mine doesn’t have that, but future devices could), which means you cannot use it on the road. But it’s the thought that counts…

Then I noticed the screenshot above and the fact that the operating system now supports AIR 2.7. This is awesome news, because that means that we don’t have to fiddle around with PlayBook specific packaging settings anymore. You can now simply take your AIR application and compile it both for Android and BlackBerry PlayBook without having to worry about the AIR runtime version on the devices. Well, at least until Adobe enforces another higher version of AIR for some reason. But even then, it seems that BlackBerry is keeping up with those releases pretty well.

So, to all that have been postponing BlackBerry PlayBook development using AIR and Flash Builder 4.5 because of the additional hassle you had to go through: go forth and start working on cool AIR apps!

But for now, she’s not getting hold of the device, because I want to try several things out. And one of those things is the real cross-device development using the Flash Platform. In my case, that means Flex of course. That’s what I’ve be doing for the past couple of days and I must say it’s really working once you get the procedure down. That’s the tricky bit for now, so let me take you through my struggles and maybe I can save you from making the same endeavors as I needed in order to get it working.

Setting up the development environment

This is the first part you’ll have to go through. Blackberry has issued a tablet OS SDK, which is a plugin for Flash Builder that allows you to compile applications for the PlayBook directly from within Flash Builder. While this all sounds great, the latest releases of that plugin do not support Flex Mobile applications. That means you cannot use that SDK to compile your Flex Mobile application. You can only work with ActionScript Mobile application.

A second issue is the fact that the SDK is installed on top of an existing Flex 4.5 SDK and without giving away too much information, it is not compatible with all Flex 4.5 SDKs, so compiling and packaging the application from within Flash Builder is not possible with the latest versions. Hopefully BlackBerry will release another version of their SDK this is compatible soon.

Taking these two issues into accounad the fact that as a Flex developer I want to use a Flex Mobile project, I’ll have to package the application using the command line.

Compiling and packaging the application

Since the option of compiling directly for the playbook is not possible with the latest builds, I’ve used a little shortcut to get the release build of my application. I mean, if you’re working on a Flex mobile application and you compile using Flash Builder, you can only opt for the Android APK file. There is no release build that gives you the release version of the SWF file.

So that’s exactly what I’ve done. Then I unzipped the APK file and searched for the release version of my SWF file and used that to package my BAR file. The command to do the packaging is as follows

blackberry-airpackager -package <BAR file> <application>-app.xml <application>.swf blackberry-tablet.xml <assets required by the application>

Signing the application

Once you have the BAR file ready you have come to the trickiest part: signing the application. This is best done via command line again, but hopefully this will be included in the Flash Builder plugin once it’s updated to work with the latest builds and with Flex Mobile projects.

First, you need to be registered as a vendor with BlackBerry in order to obtain you code signing key. This is done only once per developer or company, depending on how you want to register yourself. Obtaining the key is done by filling out this form.

The key you receive will be a CSJ file. It all starts with that file, because now you have to register that CSJ file as well as create a keystore to communicate with the BlackBerry signing authority. So, we’ll start by setting up that keystore, which is done via the following command

blackberry-signer -csksetup -cskpass <create a password>

Then you need to register the CSJ file by using the following command

blackberry-signer -register -csjpin <PIN> -cskpass <csk password from previous step> <CSJ file>

The last thing to get you set up is to generate a coding certificate, a .p12 file that is not unlike the certificate you create for regular AIR applications. This is done by executing the following command:

blackberry-keytool -genkeypair -keystore <certificate.p12> -storepass <create a password> -dname “cn=<company name>” -alias author

Once you have this set up, you are all set to start signing your application. When signing an application for the BlackBerry App World you actually have to sign it twice. Once for the code signing itself and a second time to add the author data to the BAR file. This can be done by executing these two statements in this particular order.

blackberry-signer -verbose -cskpass <csk password> -keystore <p12 certificate> -storepass <certificate password> <application>.bar RDK

blackberry-signer -keystore <p12 certificate> -storepass <certificate password> <application>.bar author

If you go through this signing process several times, make sure that you increase the application versionNumber in the <application>-app.xml file every single time. Otherwise you will get the error message that the application was already signed.

Deploying the application on the device

At this point your application is ready to be submitted to the BlackBerry App World. However, you might want to install it on your own device already and not wait for approval. This can be done via command line too and it can only be done with the signed BAR file. Unsigned applications can be installed using a debug token that expires after 30 days, but the following command is not suited for that type of deployment. It will only work with signed BAR files.

blackberry-deploy – installApp -device <device IP> -password <device password> <application>.bar

When you execute this command the application will be installed on your BlackBerry PlayBook and you can run it as if you installed it through the App World.

This might not be the best way to get your Flex Mobile application on the PlayBook, but it sure has worked for me and as far as I know it is the only way to do this with my current setup of Flash Builder and PlayBook SDK.

If someone has a better way of doing this, please let me know as I find this not an easy process to do (what should be) a simple task

Now we have Flash Builder 4.5 and Flash Catalyst CS5.5 and things are really shaping up. We can finally do roundtripping, even multiple times. Just look at this video in which I demonstrate exactly that and some other cool new productivity features in Flash Builder 4.5

One of the great features of mobile RIAs is the fact that you can connect your application to all kinds of different server technologies, such as PHP, Java, ColdFusion, .NET, … in exactly the same way as you would in your desktop AIR application. You can even work with the DataService component to use real-time data connections over the RTMP channel. Just think about real-time stock updates, video streaming, trader applications on mobile, collaboration across multiple devices … The sky really is the limit. Or is it?

I think all of this always sounds very nice, but people tend to forget one important thing when working on a mobile device and that is that if you’re not on a WiFi connection, your data contract can become very expensive when you use the sever connections. However, in Flex 4.5 there is a way to actually check whether you are working on your data contract or on a WiFi connection.

In the application you can access all of the device interfaces and check to see whether they are active or not. The only thing you need to know is which interface to look for. In the code below, you can see how I check for the “WiFi” and “mobile” interfaces. Based on what I find, I just check whether it is active. Remember, some people may have the possibility to work via a data contract, but didn’t sign up for it, so finding the “mobile” interface isn’t enough.

<?xml version="1.0" encoding="utf-8"?>
<s:View xmlns:fx="http://ns.adobe.com/mxml/2009" 
		xmlns:s="library://ns.adobe.com/flex/spark" 
		title="Connection Test"
		creationComplete="initView()">
 
	<fx:Script>
		<![CDATA[
			private function initView():void {
				var interfaces:Vector.<NetworkInterface> = NetworkInfo.networkInfo.findInterfaces();
 
				for(var i:uint = 0; i < interfaces.length; i++) {
					if(interfaces[i].name.toLowerCase() == "wifi" && interfaces[i].active) {
						lbl.text = "WiFi connection enabled";
						break;
					} else if(interfaces[i].name.toLowerCase() == "mobile" && interfaces[i].active) {
						lbl.text = "Mobile data connection enabled";
						break;
					}
				}
			}
 
		]]>
	</fx:Script>
 
	<s:Label id="lbl" horizontalCenter="0" verticalCenter="0"/>
</s:View>

In this example I’m simply setting the text property of a label, but you can also use this in a real world application to determine the update rate for your server data, for example.

There is one thing you should not forget to do when creating such an application. You have to set the proper permissions in the <applicationName>-app.xml file, in the android section. That section should contain the ACCESS_NETWORK_STATE and the ACCESS_WIFI_STATE permissions in order for it to work. If you don’t include this, you will get an empty Vector returned from the findInterfaces method.

<android>
    <manifestAdditions><![CDATA[
	<manifest>
		<!-- See the Adobe AIR documentation for more information about setting Google Android permissions -->
		<uses-permission android:name="android.permission.INTERNET"/>
		<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
		<uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/>
	</manifest>
]]></manifestAdditions>
  </android>

First thing to do, and this is what I always tend to do, is to export your Flash Catalyst components as a Flex library project. This allows you to get around the roundtripping issue, because this library project only contains Flash Catalyst generated components and will therefore remain compatible with Flash Catalyst when you need to alter the design at some point in the future.

Skinning your actual project is then done by linking the SWC file from the library project to your actual project and applying the proper skin to the component using the skinClass property. Now to be able to work with this properly, you’ll need to create a manifest file for that library as well. This will allow you to use only one single namespace for every component/skin in the library, even though the components/skins may reside in a number of packages.

Now, this approach will definitely work, but you still have to apply the skinClass property to every component in your application. However, you can apply all the styling on your application by defining a theme CSS that accompanies the SWC file containing the skins. Let me briefly explain this process by creating a very small example.

In this example I’m going to create a skin for a single component, namely the HSlider component. I want to make it look a little bit like the iOS slider, where you have a colored fill of the slider bar that follows the slider thumb position. To make things easier, I’m going to start out in Flash Catalyst. I simply create a new project with the default settings and I’m going to create the skin from scratch. Of course, you can certainly start out with an Illustrator or a Photoshop file. The process of creating the skin will remain exactly the same.

First I need to create the track and duplicate that layer to have the fill color as a separate item. Next, I’m creating the thumb for the slider by drawing two concentric circles with opposite gradients, one a little smaller than the other, to create a semi 3D lighting effect. The result looks like the image below.

The next step is to convert that design into a working component. Now, in Flash Catalyst, unless you’re putting components on the artboard, you actually just create some skin files. So, using the Heads-Up Display (HUD) I convert the artwork into a horizontal slider. After indicating the track and thumb, my skin file is now ready to be imported into Flash Builder.

Since I’m going to be creating a Flex theme, I don’t just save the Flash Catalyst project and open it in Flash Builder. I’m actually going to export the library components as a Flex library project (FXPL), as shown below. When you import the FXPL file into Flash Builder it will automatically create the library project for you.

If you look at the code now, you’ll see that the size of the slider skin is fixed. But since I want to create a theme that can be used in any circumstance and in any project, I need to make a few adjustments to the generated code to make the skin more dynamic. For that I’m going to make use of the [HostComponent] metadata tag. This gives me a reference to the actual component that this skin is applied to. Therefore I can get the size of that component and adjust the skin accordingly. The adjusted code for the main HSlider skin looks like this.

<?xml version="1.0" encoding="utf-8"?>
<s:Skin xmlns:s="library://ns.adobe.com/flex/spark"
		xmlns:fx="http://ns.adobe.com/mxml/2009"
		width="300" height="17">
	<fx:Metadata>[HostComponent("spark.components.HSlider")]</fx:Metadata>
	<s:states>
		<s:State name="normal"/>
		<s:State name="disabled"/>
	</s:states>
	<s:Button id="track" x="0" y="5" skinClass="components.IOSSliderTrackSkin" width="{hostComponent.width}"/>
	<s:Rect x="1" y="6" width="{thumb.x + (thumb.width / 2)}" height="6" radiusX="10">
		<s:fill>
			<s:LinearGradient rotation="90">
				<s:GradientEntry alpha="1.0" color="#009CFF" ratio="0"/>
				<s:GradientEntry alpha="1.0" color="#002FD1" ratio="1"/>
			</s:LinearGradient>
		</s:fill>
	</s:Rect>
	<s:Button id="thumb" x="134" y="0" skinClass="components.IOSSliderThumbSkin"/>
</s:Skin>

You’ll notice that I’ve bound the colored rectangle’s size to the position of the center point of the thumb. This will assure that the colored section follows the slider thumb position instead of being static and covering the whole component.
Now, the default size for the slider is 300 pixels, but if you specify another width, the component will be resized properly. I didn’t take the height into account for this simple demo, but similarly you can also adjust the height of the component according to the height specified in the application.

Next thing to do is to create a CSS file that attaches this skin to all HSlider components. This is very simple and straightforward, as you can see in the code below.

/* CSS file */
@namespace s "library://ns.adobe.com/flex/spark";
@namespace fc "http://ns.adobe.com/flashcatalyst/2009";
 
s|HSlider {
	skinClass: ClassReference("components.IOSSlider");
}

OK, so now our theme is ready to be used. There are a couple more steps to take before you an actually use it. First of all, you need to compile the library project, so you can link it to the actual project that you are going to apply the theme to. Since I’m using Flash Builder with automatic builds, this is already taken care of.

The next step is to load the CSS file into the theme selector, so you can actually apply the theme to the project using a few very simple clicks. For that, I’m going to the Design view in my project and click on the Current Theme link in the Appearance panel. This brings up the theme selector dialog.

In that dialog I’m importing the new theme by selecting the CSS file that I’ve just created and giving it a proper name. Since I’m going for an iOS look, I’ve simply named it iOS. Now, after the import, you can see the new theme displayed in the list of themes to choose from. So, obviously I choose that theme and click OK.

Now that I have the new theme applied to the project, I can simply use a HSlider component in my application and it will automatically be styled according to the settings in the them. To prove that the theme is dynamically adjustable, I’m creating a component with a width property of 500 pixels.

If you compile the application now, you would get some errors, because the skin files cannot be found. The very last thing I need to do is to link the theme’s SWC file to my project. In this example I’ve just copied the SWC file to the libs folder in my project. However, you could create a RSL (Runtime Shared Library) even to have your theme deployed separately and only once for all your projects. The big advantage is that your resulting project SWF file doesn’t get affected by the theme and when you alter your theme, you can just deploy that RSL and every project that uses that theme will automatically be updated next time it is started up.

The result is a working slider bar that has dynamic content and is styled via a Flex theme inside of Flash Builder. Just try out the example below to see the result.

One such an improvement is the fact that you can now create your own custom components with skin parts in Flash Builder and use that component in the HUD (Heads-Up Display) in Flash Catalyst. That means that you’re no longer only working from Flash Catalyst towards Flash Builder, but you can go the other way around as well. Let me show you how.

First, you need to create a Flash Catalyst Compatible Project, which is just another option from the File > New menu. In the project you have to create an ActionScript Skinnable Component, which can again be found in the File > New menu. When you do this, make sure that you have the Generate Comments option checked in the popup dialog, because it will help you a lot in creating your first components.

In the ActionScript file, you define a couple of skin states using the [SkinState] metadata tag. In this example, we are going to create an “open” and “closed” state. Then you also need to define the skin parts. This is done by using the [SkinPart] metadata tag. Optionally you can make skin parts required by defining the metadata tag as follows: [SkinPart(required:"true")]. When we define a button, text input field and a label in the skin, the resulting file will look like this.

package
{
	/* For guidance on writing an ActionScript Skinnable Component please refer to the Flex documentation: 
	www.adobe.com/go/actionscriptskinnablecomponents */
 
	import spark.components.Button;
	import spark.components.RichText;
	import spark.components.TextInput;
	import spark.components.supportClasses.SkinnableComponent;
 
 
	/* A component must identify the view states that its skin supports. 
	Use the [SkinState] metadata tag to define the view states in the component class. 
	[SkinState("normal")] */
	[SkinState("open")]
	[SkinState("closed")]
 
	public class MyCustomComponent extends SkinnableComponent
	{
		/* To declare a skin part on a component, you use the [SkinPart] metadata. 
		[SkinPart(required="true")] */
		[SkinPart(required="true")]
		public var input:TextInput;
		[SkinPart(required="true")]
		public var button:Button;
		[SkinPart(required="false")]
		public var label:RichText;
		[SkinPart(required="true")]
		public var resizeButton:Button;
 
		public function MyCustomComponent()
		{
			//TODO: implement function
			super();
		}
 
		/* Implement the getCurrentSkinState() method to set the view state of the skin class. */
		override protected function getCurrentSkinState():String
		{
			return super.getCurrentSkinState();
		} 
 
		/* Implement the partAdded() method to attach event handlers to a skin part, 
		configure a skin part, or perform other actions when a skin part is added. */	
		override protected function partAdded(partName:String, instance:Object) : void
		{
			super.partAdded(partName, instance);
		}
 
		/* Implement the partRemoved() method to remove the even handlers added in partAdded() */
		override protected function partRemoved(partName:String, instance:Object) : void
		{
			super.partRemoved(partName, instance);
		}
 
	}
}

Once you’ve completed the ActionScript Skinnable Component you then have to export the project by choosing Project > Flash Catalyst > Export Flash Catalyst Project. In Flash Catalyst you then have to open the FXP file to work on the project. Then you create some graphics to represent the component. You may end up with something like this.

The next step is where the magic happens, because when you select all of the graphics and you look in the HUD, you’ll notice that you can now convert those graphics into a Skinnable Component. This is the last option in the conversion dropdown. Once you’ve selected that option you’ll get a popup dialog which allows you to choose which component if you have more than one skinnable component available.

In this dialog you also have the option to load an FXPL library project in case the component you want is not yet loaded into the project. But since we’ve created the component inside of the project, we’re already having the component available. So, select that custom component and click OK. Once you’ve done that, you’ll notice that Flash Catalyst indicates that the component still needs some work, since you need to indicate all of the different skin parts you’ve defined earlier in Flash Builder.

Digging into the component, you’ll also notice the two skin states you’ve defined earlier on as well, which allows you to work with these different view states for your custom component. Now, assign the different skin parts and make some changes to the closed state to have two distinct states. For example, you can remove the label, resize the colored rectangle and change the label of the resize button in the closed state. Don’t forget to capture the click on the resize button to change view states at runtime.

As a final step, you just have to save the project and import it again in Flash Builder. You can overwrite the existing project now and when you run it, you’ll notice that the component is fully functioning now, as you can see below. Just hit the resize button to see it in action.

Nevertheless, they are finally coming and here’s a sneak at what that could look like (because the features are not 100% finalized yet). I’m not supposed to blog about these things, but since these are the official sneaks from Adobe, I thought I might share them with you…

This first video covers the usage of code templates. Create an HTTPService declaration in a matter of seconds with a default setting. All you have to do is customize it to suit your needs within the application. It even works in ActionScript! But I can’t help but wonder that this is quite similar to using snippets.

The second video covers the metadata code completion, something that was lacking in Flash Builder and previous Flex Builder versions as well. You had code completion on existing variables and methods. You could use the code completion feature to find a certain component to put in your MXML files, but precompiler directives such as metadata had no code completion. Well, this is apparently about to change.

The last video covers code generation from usage. This means that you can start coding stuff and when you use a function that doesn’t already exist, you can have Flash Builder generate that stub for you. The same thing can be done with generating variable declarations and even custom class generation. So, for example, when you have an instance of the Employee type, but the Employee type doesn’t exist yet, you can generate that class definition from within your code.

Although these features do not really bring anything new to Flex itself, they do help you create applications much faster. And I’ve always been a fan of getting more done in less time. Just keep an eye out for more to come on Flash Builder “Burrito”. I’m sure there will be loads more cool stuff in there when it’s released.

Adobe MAX 2010 is less than 2 months away and while I’m in full preparation for my lab sessions I though I’d give a small teaser about what you can expect from it.

The lab I’m doing is going to be about the designer-developer workflow topic, which has become quite hot since Flash Catalyst has been released. I’ll be giving a brief introduction to Flash Catalyst for those who are not yet familiar with it. After that, I’ll talk a bit about the different kinds of workflows when using Flash Builder and Flash Catalyst. And of course you will get your hands dirty on the exercises to show you some cool tips and tricks. You will also walk away with a fully working web shop component (not including payment modules of course, since that would take us too far of-topic).

There are two sessions. The first one is held on Monday, October 25 at 5.00 PM and is already almost full. The second session is on Wednesday, October 27 in the morning. I know this is the morning after the MAX awards, but if I can make it there, then so can you. So, if you haven’t already registered, you should hurry before the session runs full.