Check out our Angular Book Series.

Random Thoughts from the 360|Flex Experience

After every conference, I like to put down my thoughts about it and get a blog post out. A few weeks ago I had the pleasure of being a sponsor, presenter, and attendee at 360|Flex in Denver. The conference was great, as always, and I walked away with very positive vibes for the future of Flex. Although no one is too happy with Adobe, they are positive about Flex and the Apache foundation.

Being a Sponsor

Flextras was a sponsor of the conference this year, promoting our line of UI Components. The components are now free for production use. It is one step in our switch to advanced support. People seemed very positive about the move.

We put together My speaker ratings were kind of middle of the road, but at least most people found the session informative. Ever since the rating app moved to mobile devices; the amount of comments available have gone down tremendously, which is a bit of a bummer. I'd love feedback if you happened to have seen my presentation. I'll be giving the same presentation at D2WC next week.

The conference had a weird vibe during the Speaker Sponsor dinner. It felt a bit like a last hurrah. In some respects it was. Times are changing. Thanks to the advent of mobile devices the "it runs the same everywhere" stance is no longer guaranteed. I believe the use of Flash (or AIR) is going to be more focused; and discrete.

360|Flex MCP

For a while 360Conferences have added a "MVP" designation to certain people who have helped the conference in some manner. I got blessed this year to be one of those. John actually called me a "Business Mentor" up on stage when I was awarded my hoodie.

I was amused by this, because I don't feel like a business success. I don't feel like a failure either, but I'm chugging along having fun. DotComIt hasn't grown to where I want it to be; but I haven't had to give it up either.

John and I often bounce ideas off each other. I see it more of a peer relationship than a mentoring relationship. I don't have any magic secret business sauce.

I also got to see a lot of other friends; and that is part of the reason I love 360|Flex. Tom Ortega, asked me what my plan was. He mentioned that I always have a plan. I have no idea when I learned to start thinking two steps ahead, but he's right. I do have a plan. :-)

Welcome to 360|Stack

360|Flex started as a "cool idea" to get a bunch of Flex Developers together and has blossomed into a conference company that extends beyond just Flex. They put on a Mac development conference and a iPhone developer conference. Some of the "beyond Flex" started to trickle into 360|Flex. There have been a bunch of non-Flex related sponsors and sessions this year such as Appcelerator and Sencha.

As John said, the community around 360|Flex is about the work we're focused on doing; not a specific technology. As such the conference is being rebranded as 360|Stack. Next year will represent the full dev stack; whether that is HTML5 or Flex Development or something different.

I can't wait to see how the next year unfolds.

Is Flex Dead?

This question comes in from a reader; and to be honest I've been at a loss as to how to respond without writing a book. I finally found time to devote some time to putting down some thoughts.

I'll start by quoting the full question and then trying to answer points one by one:

As I was viewing your blog I noticed you seem very knowledgeable about Flex. I've just become aware of Flex and bought a few books then realized that Flex is dependent on Adobe Flash which has recently been dropped from Linux support which affects Android and the growing mobile market. I was wondering what your insight, I know you don't have a crystal ball, is on Flex usage and could you tell me if you think it has a future. Also, what is Flex really good at? I've not been able to find any example Flex apps out there... only Adobe Air apps. Thanks!

I'm going to answer the question in reverse order. First,

...what is Flex good at?

Flex is a Software Development Kit used for building Enterprise Applications. It provides a component set and a framework for rapid development. By making use of the Flash Player runtime; it is easy to build a consistent experience across multiple desktop browsers.

I've not been able to find any example Flex apps out there... only Adobe Air apps.

An AIR App can be a Flex app. Most Flex apps that I'm aware of are internal apps used for browser based applications in an "big business". You probably won't find too many public applications.

Now, Let's tackle this sentence; which is full of misconceptions:

I've just become aware of Flex and bought a few books then realized that Flex is dependent on Adobe Flash...

This isn't necessarily true. Flex is dependent upon Adobe Runtimes; however the browser based Flash Player is just one of them. Adobe AIR is a second runtime which you can use to build Flex applications. Adobe AIR can be used to deploy your Flex app as a desktop for Mac and Windows, or as a native mobile application on iOS, Android, or Blackberry's Playbook.

I expect that, in time, we'll be able to use Adobe AIR to create Windows Metro applications and Native Applications for the Blackberry "next" phones. More info on Adobe and its runtime commitment is in the "Roadmap for Flash Runtimes" whitepaper.

However, keep in mind that Flex is in the process of being donated to the Apache Foundation and the Apache Flex Project is in the process of creating their first release.

There is interest in decoupling Flex from the Adobe Runtimes, so that we can use the same Flex code and deploy them to other languages or platforms, such as HTML5 / JavaScript, such as Native Android, or Native iOS. I think it will be a couple of years before we start to figure out if such endeavors are going to become a reality for building Enterprise Applications. There are a lot of smart and motivated people, involved in the Apache project; and I have faith they will do great things.

...which has recently been dropped from Linux support...

Adobe has not dropped Flash Player support on Linux. However, as I understand it they will only be supporting the Flash Player on browsers which support a new plugin API that was developed in conjunction with Google. At the moment, only the Chrome browser will support the Flash Player on Linux; however if this API is implemented on other Linux browsers, it seems probable that this will also come with Flash Player support.

As I understand it, however, Adobe AIR, will not have any support on Linux moving forward. I understand a lot of developers find this troublesome because they were using Adobe AIR as part of their build and test process; which run on Linux machines. In practical terms, this has not affected any of my clients.

...which affects Android and the growing mobile market.

Adobe support for Linux is completely different than Adobe's support for Android. Adobe did cease development of the Mobile Browser Plugin for Android. But, you can still use Adobe AIR to build Native Android applications.

In terms of clients who I speak to; people are more interested in building Native Applications on devices and care less about browser based applications--which is where Flex excels. I do not know of anyone building Flash content targeted towards mobile browsers.

And finally....

tell me if you think it has a future

It's hard to say. At the moment, a lot of people I talk to are taking a wait and see attitude. They aren't ceasing Flex development or retiring their current applications. However some are halting on starting new projects with a technology that is "deemed" To be abandoned. People want to see the Apache Flex team create a formal release. They want to see the Apache Flex team prove they can move the SDK forward in a relevant manner. Once we prove that; I think things will improve in terms of corporate mindshare for Flex.

If I were to "guess" what is going to happen, I'd say that browser plugins are going to go away completely in the future. Apple started this with the iPhone; and Microsoft is going to accelerate it with Windows Metro apps. However, I believe that Adobe AIR is going to thrive; as it solves a unique problem (Cross platform deployment on mobile) which the browser based Flash Player used to solve. I anticipate that AIR may become more focused / niche than the Flash Player was; but I anticipate it will be a profitable niche.

There is potential for great things; and I believe that the potential can be realized.


Update 6/20/2013
This page has been translated into Spanish language by Maria Ramos from Webhostinghub.com.

Flash Remoting won't connect "NetConnection.Call.Failed"

I've been doing some with for the Flextras promotions around 360|Flex. As part of the promotions I am creating a customized version of my Game; strictly for Flextras. It is going to allow people to login and will keep score on our server instead of internally to the app.

Since this is a Flash app; I'm using Flash Remoting to connect to our ColdFusion server. Everything worked fine on my local machine. Everything worked fine on my development server (AKA Staging). However, my production machine was giving errors that looked like this:

faultCode: "Client.Error.MessageSend"
faultDetail: "Channel.Connect.Failed error NetConnection.Call.Failed: HTTP: Failed: url:
faultString: "Send failed"

I've tried a lot of different things including not using http instead of https. I knew that Flash Remoting was working on the production server because I had other Flex apps working without problems. So, what was the problem?

I've been working on this on and off for about five days; so tried a lot of different things. In the end I discovered two things:

  1. Make sure your Flash Remoting URL has a '/' at the end of it. 'https://www.flextras.com/flex2gateway' was not working. It appeared to add a JSessionID on it; which was causing the server to throw a 404 error; causing the whole call to fail. However, if I changed this to 'https://www.flextras.com/flex2gateway/' that problem went away.
  2. Turn off the Flash Builder Network Monitor. The Flash Builder Network monitor was intercepting the call and causing it to fail. The calls appeared to work fine from a web browser with the Flash Builder Network Monitor enabled, but not from the mobile app.

I think--but am not completely sure--part of my issues related to using HTTPS on the server instead of HTTP. That could be the reason I had issues on the production server, but not my local or staging box.

Moving your Flex Components from MXML to ActionScript 3

I wrote two articles for InsideRIA when the site was still active. I'm purging my personal digital archives and came across them. I decided to repost them here for posterity.

This article is about educating folks on how to move from MXML to ActionScript. I wrote the article in February of 2010; but it didn't get posted until later.

You can find the original on this DevelopRIA site. I remember it being slightly controversial, but I'm not sure why. Sadly the comments do not seem to be archived. Here is the article.

I often hear it said that all the cool kids write their Flex components using ActionScript without MXML. I'm not sure that I agree. MXML is great for layout purposes. It is great for building simple components quickly. The declarative syntax makes many development tasks easier, such as setting styles and adding events listeners. But, if you look closely at the Flex Framework source code or commercial grade components, such as what I build at Flextras, you'll notice they do not use MXML. Everything is built using ActionScript. Why is that?

ActionScript gives you granular control over your code. MXML is an ActionScript generation language. The Flex Framework takes your MXML and turns it into ActionScript. That means the code you write, isn't the code that is running. If coding were cooking, using MXML would be like buying a cake mix from the store. You just add water and you're ready to bake. ActionScript is akin to starting with flour and choosing your other ingredients carefully. It takes longer, it requires more thought, but the results are often worth it.

This article will show you how to move your component development from MXML to ActionScript. Along the way we'll touch on various aspects of the Flex Component Lifecycle. Often when you are building your own applications, in controlled environment, it will make more sense to build with MXML; and that is fine. But, understanding how to build from scratch using ActionScript will give you a deeper knowledge of how Flex works and help you build all your components better.

Today's Application

Today, I want you to pretend that your boss asked you to build a survey application. As with most surveys, this application includes a bunch of questions, and needs some way to collect answers. Many of those questions can be answered with a simple yes or no. In a normal situation, you would collect yes and no answers using radio buttons.

Unfortunately, and try to stretch your imagination with me on this, your boss is a bit irrational. He hates radio buttons. You're never quite sure why, but it is what it is. Instead of a radio button, he insists that you use one of those dropdown select box thingies. Fine! We can work with that. Knowing that your survey is bound to have a lot of yes and no questions, you decide to make a component out of it.

YesNoQuestion Component Version 1

Let's just jump in and create the first rendition of our component. You can use a Text component for the question, and a ComboBox for the 'dropdown select thingy'. Throw this all in an HBox and the code would look something like this:


<?xml version="1.0" encoding="utf-8"?>
<mx:HBox xmlns:mx="http://www.adobe.com/2006/mxml" width="100%" height="100%">
    <mx:Script>
        <![CDATA[
            import mx.collections.ArrayCollection;
            [Bindable]
            public var dp : ArrayCollection = new ArrayCollection([
                {label:'Yes'},
                {label:'No'}
            ]);
        ]]>

    </mx:Script>
    <mx:Text id="question" />
    
    <mx:ComboBox id="answer" dataProvider="{dp}" />
        
</mx:HBox>

We are already making our first use of ActionSCript in this otherwise MXML component. The dataProvider of the ComboBox is coded in script. It contains two objects, one for yes and one for no.

Unfortunately, this component is still lacking in functionality. When using this component, how do we specify the question text? Your developer could access "question.text", but it would be nicer if we gave them a simpler way. How do we know which answer the survey taker has chosen? We'll need to add a property to expose that value too.

Add these two variables to your ActionScript block:


[Bindable]
public var questionText : String;
            
[Bindable]
public var selectedAnswer : String;

Since the variables are public, they are easily accessible by people using our component. I call these variable properties, although I don't think that is a formal name for them. Next you'll want to tie the variables to the two components. Modify the MXML, like this:


<mx:Text id="question" text="{questionText}" />

<mx:ComboBox id="answer" dataProvider="{dp}" change="selectedAnswer = answer.selectedItem.label" />

Data Binding ties the questionText to the text display. You can use the change event to update the selectedAnswer each time you the ComboBox value changes. For all intents and purposes, this component would work for what we need it to do. It's time to test it.

To test the component, you'll need to build a simple application. I decided to build an AIR app to test, so I don't have to muck around with web server settings. From a code point of view, a web based app is almost no different; just change the WindowedApplication to an Application. This is my main application file:


<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" xmlns:MXMLToAS3="com.flextras.InsideRIA.MXMLToAS3.*">
    
<mx:VBox>
    <MXMLToAS3:YesNoQuestionV1 id="q1" questionText="Do you want to take a Survey?" />
    <mx:Text text="{q1.selectedAnswer}" />        
</mx:VBox>
    
</mx:WindowedApplication>
The code imports the package that contains the component. It creates an instance of the component, q1, and specifies the question text as a string. The code contains an additional text component instance that is bound to q1's selectedAnswer property. As we change answers to the question, we can see that the selectedAnswer property changes too. Here is the running app:

Version 2: Implementation Hiding

One of the key reasons to separate your code out into a component is so that you can hide the implementation. With a hidden implementation, you can change that implementation without changing the API and all code using the component should have no issues. The current component does not hide the implementation details, as you see here:

The question and answer field are both exposed. By creating them in MXML, they are treated as public properties. What would happen to our component if someone changed the dataProvider on the ComboBox? You want to prevent this type of meddling as much as possible.

To address this we are going to turn our MXML components for Text and YesNoQuestion into protected ActionScript variables and make use of the Flex Framework's component lifecycle createChildren() to create the components and add them to the stage.

The createChildren() method is run during the component's initial setup, and is intended to be used to create children and add it to the parent container. When dealing with ActionScript States, I'll often initialize any AddChild or RemoveChild state elements in createChildren(). I do this in the Flextras Calendar component to implement day, week, and month views. To keep the selectedAnswer variable in sync with what is going on, we were responding to the change event and setting the value. Our new approach will be the same, but we'll set up the event listener and the event handler in ActionScript, not using in-line MXML.

First, create the component variables:


protected var question : Text;
protected var answer : ComboBox;

Because these variables are protected, it means that any components that extend this component can access them, but if the new component does not extend this file, it cannot. This is our createChildren() method:


override protected function createChildren():void{
    super.createChildren();
            
    this.question = new Text();
    this.question.text = questionText;
    this.addChild(this.question);
                
    this.answer = new ComboBox();
    this.answer.dataProvider = this.dp;
    this.addChild(this.answer);
    this.answer.addEventListener(ListEvent.CHANGE, onChange);
}

createChildren() is initially defined in the UIComponent class. All Flex User Interface Components extend UIComponent, and ours is no exception, even though we are down the chain a bit. To implement it in our YesNoQuestion component, we override the method signature and call the super method. When overriding methods, it is important to call the super method. You never know what code magic may be executing higher up in the chain. Then the component creates the question Text instance and answer ComboBox instance. It sets the default value and adds it to the container.

In our MXML version, you kept the selectedAnswer in sync using the change event in MXML. In ActionScript, you'll use the same approach, but need to set up the event listener with the addEventListener() method. It specifies the type of event you are listening for, change in this case, and the function to run when that event is dispatched. Instead of using the event name, 'change', I'm referring to the event constant from the event class. Either approach should work, but referencing that constant is a bit more flexible. If the event name changes, our code does not have to. This is the listener function


protected function onChange(e:ListEvent):void{
this.selectedAnswer = this.answer.selectedItem.label;
}

The listener function accepts an event argument. The single line of code inside the method is the same that we used in-line in our MXML version.

Version 3: commitProperties()

What happens if the questionText is still an empty string when the createChildren() method is called? Our question will have nothing to display. There is nothing in our current code to update the question text if the questionText property changes. There is a solution. The Flex Framework provides the commitProperties() method to run code after all the component's properties have been set. We will make use of this method to set and update the question text whenever the value changes.

First, add the commitProperties() method into your code. We can copy and paste the line to set the question text into the body:


override protected function commitProperties():void{
    super.commitProperties();
    this.question.text = questionText;
}

The method, of course, calls its' super just as we did with createChildren(). The Flex Component Lifecycle provides us with an invalidation method named invalidateProperties(). We can call this at any time on our component and it will force the commitProperties() to run during the next render event. This is a difference between createChildren() and commitProperties(). createChildren() only runs once; while commitProperties() runs during initial setup, and then again as needed. In order to trigger the commitProperties() invalidation, we're going to replace the questionText variable property with a get/set property. Flash Builder 4 contains some code generation to do this, and the resultant code will look something like this:


private var _questionText : String;
[Bindable]
public function get questionText(): String{
    return this._questionText;
}
public function set questionText(value:String):void{
    this._questionText = value;
}

The commitProperties() method will most likely execute during the life of our application more often than when we change the questionText. To let commitProperties() know what it actually needs to do, we'll add a propertyChanged flag, like this:


private var questionTextChanged : Boolean = false;

The set method will be modified to set the flag to true and to call invalidateProperties():


public function set questionText(value:String):void{
    this._questionText = value;
    this.questionTextChanged = true;
    this.invalidateProperties()
}

The commitProperties() method will need to be revisited to check for that flag:


override protected function commitProperties():void{
    super.commitProperties();
    if(this.questionTextChanged == true){
        this.question.text = questionText;
        this.questionTextChanged = false;
    }
}

By setting up the selectedAnswer method using a variable property, users of the component can change it at will; which could leave to undesirable effects. We can replace this property with a get method. Leaving out the set method will make the value read only from the outside. This is the updated set method:


private var _selectedAnswer : String
[Bindable(event='selectedAnswerChanged')]
public function get selectedAnswer (): String{
    return this._selectedAnswer;
}

Notice that I changed the Bindable metadata tag. Instead of using its default state, I added an event. The Flex Framework knows to make properties Bindable when the set method exists, but will cause a warning if no set method exists. The solution is to specify the bindable event, and dispatch it on your own when the property changes. We can add a method for the property change:


protected function setSelectedAnswer(value:String):void{
this._selectedAnswer = value;
    this.dispatchEvent(new Event('selectedAnswerChanged'));
}

The property was being set in the onChange event handler. We have toChange that so it accesses the set method instead of the variable property directly:


protected function onChange(e:ListEvent):void{
    setSelectedAnswer(this.answer.selectedItem.label);
}

I want to point out that there is nothing code related that will prevent you from having a get method and set method with different access modifiers. But,the ASDoc tool does have a problem with it, which is why I just remove the space between the set and property name. If you don't use ASdocs, feel free to make public getters and protected setters.

To test the setting of the questionTxt, we can make some modifications to our main application file. Add in a TextInput and a button to modify the questionText on q1:


<mx:TextInput id="questionText" />
<mx:Button click="q1.questionText = questionText.text" />

Run and test the code and you'll find that we can change the question text without any issues; and the read only selectedAnswer property is still changing the main application's Text component when it changes. Things are good.

Version 4: Moving to All ActionScript

If you look at your component code, you realize most of it is ActionScript already. It is not a big leap to turn the MXML component into an all ActionScript component. The component first starts with a package definition:


package com.flextras.InsideRIA.MXMLToAS3 {

The package definition is the folder structure where the component is located. So, in my application the YesNoQuestionV4.as file is located in the MXMLToAS3 directory of the InsideRIA directory of the Flextras directory of the com directory. The com directory is located off the main source root. This piece was masked from us in the MXML alternate.

Next we put the class imports:


import mx.containers.HBox;
import mx.controls.ComboBox;
import mx.controls.Text;
import mx.collections.ArrayCollection;
import mx.events.ListEvent;

The only difference between these and the previous MXML Version is that we are importing the HBox, which our component is based off of. The imports were also in a script tag of the MXML component. In the ActionScript version, there is no script tag; in fact there are no tags at all.

Next up, comes the class definition:


public class YesNoQuestionV4 extends HBox{

Classes can use the same access modifiers that properties and methods use. Access modifiers cannot be specified when developing in MXML. Next is the class constructor:


public function YesNoQuestionV4(){
    super();
}

In this sample, the constructor does nothing other than calling its' parent's constructor. But, I'll often use it for defining default styles or performing setup of the component's states. Any code that you commonly write in response to the creationComplete event most likely belongs in the constructor; however MXML components do not support constructors.

Next comes all the ActionScript code that was in the code block from our previous MXML version. I won't replicate it for you here. Finally, the open brackets for the class and package definition close:


}
}

Even though your component is now 100% ActionScript, our main application does not have to change. In a true nod to implementation hiding, the application, or other component, that uses your components do not care whether it was implemented in ActionScript or MXML or some mix of the two.

Version 5: Extending UIComponent

In the previous versions, we were extending the HBox class. This makes our lives a bit easier, because we were able to use the HBox's inherent ability to position and layout our question Text and ComboBox components. However, the layout algorithms in some of the classes may be too complicated for your needs. Sometimes something simpler will offer better performance. For the final rendition of our YesNoQuestion, we're going to extend the UIComponent. The first line to modify is the class definition. Previously it extended HBox, now it extends the UIComponent, like this:


public class YesNoQuestionV5 extends UIComponent

That is the only line of code that needs to change, but we do need to make some additions. There are two Flex component LifeCycle methods we haven't implemented yet, measure() and updateDisplayList(). Implementing these two methods will finish our component.

The purpose of the measure() method is to decide in the ideal height and width that your component needs without showing scroll bars. A component's parent is ultimately responsible for its' size, so the measure() method is really just setting suggestions, via the measuredHeight and measuredWidth property.

This is the method:


override protected function measure():void{
super.measure();
this.measuredHeight = question.measuredHeight + answer.measuredHeight;
this.measuredWidth = question.measuredWidth + answer.measuredWidth;
}

The method overrides the parent, and calls the super version of its method. Then it calculates the measuredHeight by adding the measuredHeight and measuredWdth of each child, respectively. In most cases, the measure method just loops over the children and calculates the values similar to what we've done here.

The measure() method can, optionally, set the measuredMinWidth and measuredMinHeight properties. These properties specify how small the component can go before it stops sizing down. I did not specify those values here, but often default them to 100 just so that they have a value. I've run into odd issues when using percentage heights on components that do not specify the minimums.

The last method to implement is updateDisplayList(). updateDisplayList() is used primarily to position and size the children. However, you can also use it for other display items, such as setting styles or drawing with the graphics API. This is our updateDisplayList() method:


override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void{
    this.question.setActualSize(
this.question.getExplicitOrMeasuredWidth(),
this.question.getExplicitOrMeasuredHeight());

    this.question.move(0,0);

this.answer.setActualSize(
this.answer.getExplicitOrMeasuredWidth(),
this.answer.getExplicitOrMeasuredHeight());

    this.answer.move(this.question.width, 0);
            
}

updateDisplayList() contains to arguments, the unscaledWidth and the unscaledHeight of the component. These values are, essentially, the height and width that you want to use to size your component. To position the components, use the move method. The first one, question, is positioned at the top left corner, with an x position of 0 and a y position of 0. The answer component is positioned next to the first one, with a x position equal to the width of the question instance. The answer's y value still remains 0.

setActualSize() is used to size the components. In this case, we use the two methods: ,getExplicitoOrMeasuredWidth() and getExplicitOrMeasuredHeight(). Since we never set an explicit height or width, this sets the components to their measured height and width.

Final Code

Before you start to build your components, think for a second. Are these components that you want to optimize for reuse and use in a lot of different places, and a lot of different ways? Or are these onetime components that you want to build for your application? Even if you can build everything in ActionScript, it may not be worth your extra time. But, even with MXML components, you can still make use of the ActionScript techniques and Flex component lifecycle methods to make robust components.

For the same of completeness, the final code follows the end of this article.


package com.flextras.InsideRIA.MXMLToAS3
{
    import mx.containers.HBox;
    import mx.controls.ComboBox;
    import mx.controls.Text;
    import mx.collections.ArrayCollection;
    import mx.events.ListEvent;
    import mx.core.UIComponent;
            
    public class YesNoQuestionV5 extends UIComponent
    {
        public function YesNoQuestionV5()
        {
            super();
        }

        [Bindable]
        public var dp : ArrayCollection = new ArrayCollection([
            {label:'Yes'},
            {label:'No'}
        ]);
        
        private var _questionText : String;
        private var questionTextChanged : Boolean = false;
        [Bindable]
        public function get questionText(): String{
            return this._questionText;
        }
        public function set questionText(value:String):void{
            this._questionText = value;
            this.questionTextChanged = true;
            this.invalidateProperties()
        }
        
        private var _selectedAnswer : String
        [Bindable(event='selectedAnswerChanged')]
        public function get selectedAnswer (): String{
            return this._selectedAnswer;
        }
        
        protected function setSelectedAnswer(value:String):void{
            this._selectedAnswer = value;
            this.dispatchEvent(new Event('selectedAnswerChanged'));
        }
        
        protected var question : Text;
        protected var answer : ComboBox;
        
        override protected function commitProperties():void{
            super.commitProperties();
            if(this.questionTextChanged == true){
                this.question.text = questionText;
                this.questionTextChanged = false;
            }
        }
        
        override protected function createChildren():void{
            super.createChildren();
            
            this.question = new Text();
            this.addChild(this.question);
            
            this.answer = new ComboBox();
            this.answer.dataProvider = this.dp;
            this.addChild(this.answer);
            this.answer.addEventListener(ListEvent.CHANGE, onChange);
        }
        
        override protected function measure():void{
            super.measure();
            
            this.measuredHeight = this.question.measuredHeight + this.answer.measuredHeight;
            this.measuredWidth = this.question.measuredWidth + this.answer.measuredWidth;
        }
        
        override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void{
            this.question.setActualSize( this.question.getExplicitOrMeasuredWidth(), this.question.getExplicitOrMeasuredHeight());
            this.question.move(0,0);
            this.answer.setActualSize(this.answer.getExplicitOrMeasuredWidth(), this.answer.getExplicitOrMeasuredHeight());
            this.answer.move(this.question.width, 0);
            
        }
        
        
        protected function onChange(e:ListEvent):void{
            setSelectedAnswer(this.answer.selectedItem.label);
        }

        
    }
}

360|Flex is Coming in April

If you're scared that Flash is dead; I can understand the fears. Adobe has been stomping us into the ground as if were the ashes of a freshly smoke cigarette.

I expect 2012 will be a year of transition for Flash Platform Developers. It may be because we have bitterness towards Adobe, or that we want to "follow the jobs", or just because we love learning new stuff. We'll spend a lot of time learning new technologies, such as Objective C, Java, and HTML5.

Learning all that new stuff will make us smarter, and better, developers all around. The 360|Flex schedule is full of sessions on these alternate technologies. If you're a Flex Developer and are looking for your next steps, this is a great conference to go to.

I'll be speaking on building games with Flex, and explaining why that is probably a bad idea. There will be tons of good info you can take with you back to Enterprise apps, especially in the mobile space.

I think there is a good chance that I'll be paying the bills by Flexing long beyond 2012; but that won't stop me from learning new stuff. Swing by 360|Flex in Denver this April 15th-18th and say Hi to me.

In Defense of Flash

This is a modified version of a letter I wrote to a client to defend the choice of using Flash. This issue has come up due to some recent PR heat that Adobe is abandoning Flash. I believe that Flash and Flex were the right choice for building Enterprise applications a year ago. I believe that Flash and Flex are the right choice for building Enterprise applications today. As HTML5 tooling, frameworks, and related resources improve I will reevaluate my needs and the needs of my clients on a routine basis. I had to remove some client specific information, but the bulk of the information remains the same.

Here is the letter:

Per our recent discussion, regarding Flash and Flex, I wanted to clarify a few things to in writing. In the recent weeks, many media outlets have reported that Adobe is abandoning The Flash Platform in favor or HTML5 solutions. This represents an incomplete understanding of the facts, and I hope to clarify that here. Such a statement would be like saying Amazon.com is going to abandon selling real world goods because they released the Kindle Fire.

What is the Adobe Flash Platform?

First, for completeness, I want to clarify what Adobe's Flash Platform is. The Flash Platform consists of multiple deployment runtimes, development tools, and frameworks that are integrated across the full Adobe Creative Suite. Here is a list of some Flash Platform elements:

  1. The Flash Player: Flash Player is a browser plug-in which allows us to deploy web based applications to Windows, Mac, Linux, Android, and Blackberry.
  2. Adobe AIR: Adobe AIR is a runtime that allows us to deploy native applications to Windows, Mac, Android, iOS, and Blackberry.
  3. Flash Professional: Flash Professional is a tool for developing timeline based animations.
  4. Flash Builder: Flash Builder is an IDE to help programmer's write advanced code.
  5. Adobe Flex: Flex is the Software Development Kit that helps programmers build, debug, and deploy Enterprise applications with the Flash Platform. Flex includes a UI Component library, a SWF compiler, a command line debugger, an application profiler.

There are more aspects of the Flash Platform ecosystem, but I highlight these because they come from Adobe and are prominently used by Flash Platform developers.

We have built our applications using Adobe Flex to target the Flash Player desktop runtimes. One part of this decision is the breadth of the tooling available to us decreases the time it takes us to deliver a finished application. The ease of styling the default Flex Components also provides the applications with some cross platform elegance. They will work without change on the Windows and Mac machines used by your employees.

Is Flash Really Dead?

I want to quantify some of the press announcements over the course of the past week. The first one is that Adobe will no longer, personally, develop the Flash Player for Mobile Devices. This means that Adobe will not produce version of the Flash Player for Android, or Blackberry devices. To quote:

"We will no longer continue to develop Flash Player in the browser to work with new mobile device configurations (chipset, browser, OS version, etc.) following the upcoming release of Flash Player 11.1 for Android and BlackBerry PlayBook"

Source

If you look at my list of Flash Platform elements above, it is clear this affects a very small subset of the Flash Platform; and not one we have targeted in our development. Through Adobe's Open Screen Project, licensees are able to continue their own development of the mobile Flash Plugin. RIM has already stated they will do this for Blackberry devices. To quote:

"As an Adobe source code licensee, we will continue to work on and release our own implementations. RIM remains committed to delivering an uncompromised Web browsing experience to our customers, including native support for Adobe Flash Player"

Source

Moving forward, Adobe will focus on development of Flash Player 12 for desktops, and focus on using Flash Platform technologies to deploy Native Apps to mobile devices:

"Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores."

"We are already working on Flash Player 12 and a new round of exciting features"

Source

According to the Adobe Max 2011 keynote, the Adobe touch apps, including Photoshop touch, were built using the Flash Platform. This is the surest sign of Adobe's commitment to the Flash platform.

"You've already seen some incredible examples of applications built in Flash. What do you guys think of the touch apps that Kevin showed you yesterday? So, they were useful and usable, they had rich UI, performed really well, very engaging interfaces. What you weren't told is that almost all of those applications were actually built in Flash!"

Source ~14 minutes, 20 seconds

Flash Platform technologies are continuing to evolve and provide a strong value proposition for our current use.

What does this mean for Flex?

A big part of the work we have done together has been based on the Flex SDK, and I wanted to highlight some changes about the future of Flex. The model with which Flex is developed will change. First, Adobe is working on making Flex part of the Apache Foundation:

"Adobe is in the process of preparing two proposals for incubating Flex SDK and BlazeDS at the Apache Software Foundation."

Source

The Apache Foundation is one of the leading Open Source Foundations and the project will be managed by Adobe and some high profile Flex Community members from the Spoon.as project, an effort from the Flex development community to help improve the Flex Framework.

Continued development will take place under the open source foundation, however Adobe still plans to implement the road map they discussed at Adobe Max. This will include new components that make building applications easier, and an improved compiler that will make development easier.

Additionally, Adobe is committing to future Flash Builder improvements, with support for the future releases of the Flex SDK:

"Future versions of Adobe Flash Builder will continue to provide code editing, compilation, debugging and profiling support for Flex applications. Adobe will undertake the required work to ensure Flash Builder is compatible with future releases of Flex SDK."

Source

The future of Flex is strong.

HTML5, ColdFusion, and Silverlight

Much of the recent press talks about how Adobe is abandoning Flash in favor of HTML5 development. I believe the information above is clarification that Adobe is not abandoning Flash. However, it is undeniable that they are investing heavily in HTML5 development tools. The primary reason for this focus is mobile device support. All major mobile web browsers-Android, iOS, and Blackberry--use the same rendering engine, Webkit, therefore providing a consistent experience across mobile devices.

Adobe is undertaking some work to help bridge the gap from The Flash Platform tools to HTML5 and JavaScript. The next version of Adobe Flash Professional will have an export to HTML5 feature:

"Wallaby is the codename for an experimental technology that converts the artwork and animation contained in Adobe(r) Flash(r) Professional (FLA) files into HTML."

Source

The Flex team has an experimental Flex to HTML/JavaScript compiler that will be given to the Apache Foundation as part of the Flex code base:

"Will Adobe provide migration tools to enable existing Flex applications to be converted to HTML/JavaScript? We have undertaken some experimental work in this area, but remain unsure as to the viability of fully translating Flex-based content to HTML."

Source

HTML5 is something to watch carefully over the next 3-5 years, but it is not yet ready for Enterprise applications.

Another Adobe technology used in our projects is ColdFusion. ColdFusion is alive and well, and not affected by any of the recent announcements:

"There is no change in plan for next version of ColdFusion codenamed Zeus and we continue to go aggressively trying to make Zeus a kick ass release."

Source

"We're still here--same leadership, engineers, and sales team as before last week--and we're still selling ColdFusion 9 and working hard on the next version of ColdFusion, codenamed ColdFusion Zeus."

Source

With ColdFusion, we have nothing to worry about.

We had discussed Silverlight as a possibility, so I wanted to make you aware that many of the same issues which Flash Player experiences on Mobile devices will also be issues for Silverlight. In Windows 8, Metro style browsing will not support plugins:

"The Metro style browser in Windows 8 is as HTML5-only as possible, and plug-in free."

Source

This means that the Windows 8 Metro UI will not support Flash or Silverlight. Traditional desktop browsing will still support both, but many believe that the metro interface will be the Microsoft interface for Tablets and other mobile devices. Additionally, rumors are that Silverlight 5 will be the last release of the player:

"Several of my customer and partner contacts have told me they have heard from their own Microsoft sources over the past couple of weeks that Silverlight 5 is the last version of Silverlight that Microsoft will release."

Source

Converting existing projects to Silverlight would not solve any issues for us at this time, and may introduce other issues later.

Final Thoughts

Right now, today, I still believe that Flex is the right choice for the development we are doing together. We should continue to evaluate the state of alternate technologies on a routine basis to verify our choices. But, today I leave you with this quote

"..the performance, framework maturity and robust tooling provided by Adobe are cited as critical factors by enterprise customers as to why they continue to select Flex."

Source

Sincerely,

Jeffry Houser
DotComIt, Owner

Seven Reasons to be a Happy Flash Developer

There have been a lot of emotion in the Flex and Flash community over the past few days; regarding certain decisions that Adobe has made about Flex and Flash and their utter failure to communicate with us, the developer community. The news, and responses, have been overwhelming negative.

I grew up an eternal optimist. While I see a lot of challenge ahead, I also see a lot of opportunity.

Here are seven reasons I'm happy to be a Flash Developer today.

  1. Adobe is focusing their Flash related efforts to allow us to easily build cross platform native applications. Let's face it; on mobile devices native apps are lot cooler than browser based apps.

    "Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores."

    Source

  2. Flex being released to 3rd party open source foundation, most likely the Apache Foundation. This is kind of like the Spoon project with a +10 power up.

    "We are preparing two proposals for incubating Flex SDK and BlazeDS at the Apache Software Foundation."

    Source

    Some of the smartest community members in the Flex Community involved. As a corollary I've heard some talk of decoupling Flex from the Flash / AIR runtimes so it can cross compile to alternate technologies such as HTML and JavaScript. Apparently Adobe even has a prototype on this which will be included as part of the open source code.

  3. A lot of Adobe's Flex Roadmap discussed at Max will be implemented to completion, including the new Falcon Compiler, and some new spark components. Additionaly, Adobe will continue with Flash Builder, which is Adobe's best ActionScript editor.
  4. The next version of Flash Player will be developed on Desktops; and that is all many Enterprise Applications Need anyway.

    "We are already working on Flash Player 12 and a new round of exciting features which we expect to again advance what is possible"

    source

  5. Adobe wants to use the Flash player to continue to extend the web. Many of their innovations will be used a test bed to bring things back to formal HTML standards bodies. PixelBender turning into CSS Shaders and the poster child of this approach.

    "We will continue to leverage our experience with Flash to accelerate our work with the W3C and WebKit to bring similar capabilities to HTML5 as quickly as possible"

    Source

    This approach is good for web standards; and good for all developers. We could easily argue this is what early browser makers did, and continue to do to move forward HTML.

  6. Many of the skills we have developed using Flash Platform tools will be easily applicable to the next generation of HTML5 related tools. That can give us a head start in the job market. Adobe is going to be adding HTML5 support for many of the tools we already know, such as the Flash Professional export to HTML feature.
  7. And If all else fails, HTML approaches to cross browser development will take 2-8x longer depending on the tasks at hand. You can laugh all the way to the bank.

I don't know how this will all play out. I don't know what the future holds for me, The Flex Show, or Flextras. But, I'm cautiously optimistic about what the future holds.

How can I use the ColdFusion Builder Plugin with two versions of Flash Builder?

I have both Flash Builder 4 and Flash Builder 4.5 installed on my machine; each as the stand alone install. This allows me to slowly migrate old projects to the new IDE as I need to without blowing up the machine at once.

In addition to Flex Builder, I have ColdFusion Builder installed. ColdFusion Builder is installed as a plugin to Flash Builder 4. How do I use the plugin in Flash Builder 4.5? I was half way through a second install of the ColdFusion Builder plugin, when I decided to do some directory checking.

It turns out there is a directory named dropins in the Flash Builder 4 install:

C:\Program Files (x86)\Adobe\Adobe Flash Builder 4\dropins\

And this directory had a file named cfbuilder.link.

The file is a text file that contained:

path=C:/Program Files (x86)/Adobe/Adobe ColdFusion Builder Plugins

I believe it tells Flash Builder to look in that directory for the ColdFusion Builder plugin.

I shut down all Flash Builder 4.5 instances and moved that cfbuilder.link file from the Flash Builder 4 directory to this directory in Flash Builder 4.5:

C:\Program Files (x86)\Adobe\Adobe Flash Builder 4.5\eclipse\dropins

I relaunched Flash Builder 4.5 and had the ability to create ColdFusion projects and all that jazz. It appears everything is working as expected.

So, I'm good to go and all it took was five minutes moving a text file around.

How do you create a Status Bar in Flex?

There was a discussion over on the Adobe Flex forums regarding the support of a progress bar on Flex Mobile. I was getting flamed badly, but many friends on twitter assure me it wasn't my fault.

A progress bar is a class that to "provides a visual representation of the progress of a task over time." It is often used for preloaders, or for loading other data, such as videos or movies.

The poster insisted there were plenty of uses beyond that for a progress bar. Some of his use cases included the stats bar from a game, or display the percentage completed that a project. I didn't understand why you'd want a progress bar component for those. The purpose of a progress bar is to automatically change over time; whereas any of those options would require some external reference to change those values. A progress bar seems overkill.

At least that is how things work in my version of the world. And I said so. And the poster responded with insults; sometimes claiming that I said things I didn't say; sometimes accusing me of being flame bait.

Aside from the "controversy" of the thread, I decided to spend some time to create a status bar style component, such as what you might see in a video game. I wanted it to be a Flex component, but also be as lean as possible so it could easily translate to mobile devices. This is it:

Also check out the source code.

This StatusBar component extends the UIComponent. It has one property, highLightedPercentage. The property is used to determine how much of the component will be "highlighted". The rest of the component will be the unhighligted state.

To create the highlighted and not highlighted boxes, I used the Flash graphics API and just drew rectangles. Using the highlightedPercentage property and the unscaledWidth of updateDisplayList(), you can easily size and position the two boxes that make up our component:


var highlightedWidth : Number = unscaledWidth*highlightedPercentage*.01;
var unhighlightedWidth : Number = unscaledWidth - highlightedWidth;

this.graphics.beginFill(getStyle("highlightedColor"));
this.graphics.drawRect(0,0,highlightedWidth,unscaledHeight);
this.graphics.endFill();

this.graphics.beginFill(getStyle("unHighlightedColor"));
this.graphics.drawRect(highlightedWidth,0,unhighlightedWidth,unscaledHeight);
this.graphics.endFill();

I also added two styles to specify the color of the highlighted portion and the not highlighted portion of the status bar.

The whole process took about 20 minutes; but was very cathartic for me. I do not understand why that thread flew off the handle.

The entity name must immediately follow the '&' in the entity reference.

I was recently making a custom List Skin for a client project, and I was writing some code in the updateDisplayList() method to conditionally display the border around the list. If the list had no data, we wanted to display the border. If the list had data, we wanted the border to be hidden.

You gotta love client requests, right?

Anyway, I had code like this:


if( (this.hostComponent.dataProvider) && this.hostComponent.dataProvider.length <1)){
// do stuff
}

The first line was throwing a compiler error like this:

The entity name must immediately follow the '&' in the entity reference.

I was at a loss to solve the issue; and for a second I actually thought I had forgotten how the syntax for using "And" in an if statement. Even commenting out that line would not make the compiler error go away.

Googling the issue brought no resolution, which is why I thought I'd post the solution. Apparently in the default Flex list skin, there is no CData declaration on the script tag. As such any script you write must be XML compliant.

The solution was to add that CDATA declaration back in:


<fx:Script fb:purpose="styling">
<![CDATA[

]]>

</fx:Script>

I have no idea why the skin does not have that in by default. Flash Builder automatically adds it when you create a script tag.

More Entries

All Content Copyright 2005, 2006, 2007, 2008, 2009 Jeffry Houser. May not be reused without permission
BlogCFC was created by Raymond Camden. This blog is running version 5.9.2.002.