Give us a call 203-379-0773
Check out our Angular Book Series.

How does one Flex Component talk to another Flex Component?

I think there is one question that has come up hundreds of times on Stack Overflow. The question is "How does one Flex Component call a method in another Flex Component?" or some variation thereof. Sometimes people want to access something in the main application, sometimes they want to access something inside an itemRenderer, other times they want to access another child of a ViewStack. No matter the purpose, I feel it is time I create the most detailed answer to the question I can.

The Setup

First let's pretend you have a setup like this:

Click the image to see a larger version.

Something like this would not be uncommon in an application you were building with Flex. At the root of everything in a Flex Application is your main Application file, usually extending s:Application or mx:Application.

Inside the application contains two main components, ComponentA and ComponentB. These could represent two separate pieces of the app and are never showed together at the same time. Or they could represent two different components that are both shown at the same time and make up a single screen.

Inside Component A, is a ViewStack with three children. ComponentB contains a list class, which could be a List or a DataGrid or something else. The List class uses an itemRenderer. Many beginner developers make the mistake of thinking that the itemRenderer represents a single component; however a new instance of the itemRenderer is created for every item displayed in the list. It is an important distinction that many people do not understand.

The implementation of an application like this could be done across many different files or it could be done in a single MXML file. When creating a single MXML file, the parent child relationship can be hidden from the beginner, because it looks like the main application is the parent of every child. It is important to remember the true component hierarchy when thinking about how components should interact with each other.

Events Communicate Up

Many questions relate to executing a method in their parent from a child. For example, what if you want to change the selectedIndex of the ViewStack from within Child1? Perhaps you're building a multi-step process and the user just clicked a 'next' button. Or perhaps the user was viewing data in a DataGrid and clicked an 'edit' or 'more details' button that is supposed to open up a new screen with additional information. All these are valid use cases. So, how do you do it?

From an encapsulation stand point, a component should never try to execute methods in its parent. Doing so gives the component a dependency upon the parent; thus minimizing reuse. The child component cannot then be used as the child of a component other than the parent

The solution for a component to tell its parent to do something is to use events. An event is dispatched from the component to its parent. The parent will listen to events from its child and execute handler methods to perform some functionality. Flex makes use of this model all over the place such as the click on a button or the input of keystrokes into a TextInput.

The code isn't that difficult. First create an event class:

var myEvent = new Event('myEventType');

And then dispatch the event:

dispatchEvent(myEvent);

If you need to send custom data with your event; you can create your own event class to do so; but I decided to keep such details out of this article. For bonus points you can use metadata to define your event as part of the class. This is primarily used for code hinting within an IDE and does not affect things at runtime. This is sample event metadata:

[Event(name="myEventType", type="flash.events.Event")]

You can put that metdata before the class definition if you have an ActionScript class; or as part of the fx:Metadata tag in an MXML class.

Dispatching the event is only the first step, though. The parent is going to have to add an event listener to it. In MXML this is easy, as the event will show up as if it were a property on the component, like this:

<ns1:Child1 myEventType="myEventHandler(event)" />

If you want the above method to work, you'll need to add in the event metadata. However, if for some reason you don't want to create event metadata, you can also add listeners in ActionScript. You use the addEventLIstener method on the instance of your component. The instance is named by using the id tag in MXML or the variable name in ActionScript:

myChild1.addEventListener('myEventType',myEventHandler);

Either method for adding an event listener will call a method, known as the event handler:

protected function myEventHandler(myEventHandler:Event):void{
// do stuff here
}

Events are the proper way that a component can communicate with its parent. If the component is on the display list; the events can also bubble. Using our example, if myChild1 dispatches the myEventType; first the ViewStack event handlers will execute. If ComponentA added a listener on the ViewStack for the myEventType event; that will execute next. If the main application had an event listener on ComponentA for the myEventType, that event handler will execute next.

Event bubbling is the proper way for a renderer to communicate with the parent of its List. Dispatch an event from the renderer, make sure it bubbles by setting the bubble property of the event's constructor to true, and then listen for the event on the List.

Inside the renderer, you create the event, with the bubble flag to true and dispatch it normally:

var myEvent = new Event('myEventType', true);
dispatchEvent(myEvent);

In ComponentB you can add an event listener to your List class:

List.addEventListener('myEventType', myEventHandler);

You won't be able to add the event listener in MXML unless you extend the list class to include custom metadata as we showed above. But, even without metadata the event will still bubble and the event listeners will still execute.

Methods Communicate Down

Events are how a component should communicate up to its parents. But, how does a parent communicate down to its children? There are two different ways, either by executing a public method on the child or by changing properties on the child. Public methods and properties make up the API which a component expects its parents to use to control its behavior.

Creating a public method is no different than creating an event listener, like we did above. It just uses a different access modifier, specifying public instead of protected:

public function myMethod(argument:ArgumentType):void{
// do stuff here
}

You can specify as many arguments as are needed to perform the method functionality. A good example of this is the addEventListener method. That is a method built into Flash's architecture, but you can write your own methods using the approach above to perform your own functionality. The Flextras Calendar component, for example, has a method to change the view between month, week, and year.

A component would call this method on the instance of the component, specified by the MXML ID. So, if the ViewStack component wanted to call myMethod on the Child2 it would do this:

myChild2Instance.myMethod(myArgument);

Methods can return things by specifying the return type in the method signature. Our example above specifies the return type as void, which means the method doesn't return anything. Here is another method which returns a Boolean value:

public function myMethod(argument:ArgumentType):Boolean{
// do stuff here
// return result
return true;
}

The code you put inside the method, the arguments you choose, and the return value will all depend upon the functionality you want to achieve in the method.

Properties Communicate Down

Changing properties values are the second way that a parent can communicate with its child. As one example, a component's position in the display list is defined with the properties X and Y. The labelField on a list, or the selectedIndex property on a ViewStack are other examples of properties. Properties are implemented as public variables within a component.

They can be implemented with a simple variable definition:

public var myProperty :MyType;

This is the easiest way to create a property on a component. You can also create properties using a special set of methods, named get and set methods. If you want to perform other functionality when setting, or retrieving the value of your variable, then getter and setters are what you need. This is a common implementation:

private var _myProperty :MyType
public function getmyProperty():MyType){
return _myProperty;
}

public function set myProperty(value:MyType):void{
_myProperty = value;
}

The simple public variable becomes private; and the API for setting or retrieving these methods lie within the get and set methods which access the private value. It is very common in the Flex Framework for a set method to be used to dispatch a change event for the component. If you want a property to be read only, you can leave out the set method.

Whether implemented as simple variables, or with get/set methods, properties are accessed identically from the component trying to change the property. For example if ComponentB wants to set the selectedIndex on the List it would do this:

list.selectedIndex = 1;

It doesn't matter how the list has implemented the property for selectedIndex. This is a form of encapsulation I call implementation hiding. One component does not need to know how another is implemented. It should only communicate with it through its public API. The API is defined through documented properties, methods, and events.

Other Thoughts

Components that are on the same level of each other, such as Child1 and Child 2 should not communicate directly with each other. The proper way to have Child1 affect Child2 is to dispatch an event from Child1; have your ViewStack component listen to the event and call a method, or property, on Child 2.

There are other methods for sharing data between components, such as using Dependency Injection to share class instances between components. Another may be to use a Singleton class. Many frameworks exist to help with these things, but it is beyond the scope of this article. Your key takeaway from this article is that the use of events, properties, and methods can help you create robust, reusable components within your application.

Flextras Components Go Open Source

I sent this out to folks on the Flextras Newsletter a bit earlier in the month, but here comes a formal blog announcement.

Flextras Components Go Full Open Source

You can get the most recent source code for all our components, under an Apache License, from the Flextras GitHub account. This includes our Calendar, the Flex AutoComplete component, and the mobile component set. The Mobile Component set includes a Flex mobile DropDownList, a mobile AutoComplete, and a handful of other components.

If you don't want to build the source yourself, binary builds are still available for download the Flextras web site, along with our documentation and samples.

What about Flextras Customers?

If you're already a Flextras customer, you'll still be eligible for complimentary support, as we have always provided. If you're not a Flextras customer yet, we will be more than happy to provide you with support at a cost. This can be done on an hourly basis, or through extended consulting engagements depending on your need.

Final Thoughts

I've spent the past five years of my time devoted to Flextras and being part of the Flex Development Community. It would be fantastic to see lots of people do great things with my component legacy.

If you want to say thanks, or if you need help, be sure to contact us. We'd love to hear from you and will be here when you need us.

Check out the Flextras AutoComplete KickStarter

Did you ever wish that the Flex Framework had a native Autocomplete Component? Do you wish you had easier access to the source of the Flextras AutoComplete? Do you want to help make those things happen?

Now you have a chance to answer all three questions as a yes.

We have launched a KickStarter campaign to do just that. If funded, we are going to expand the API of our Spark AutoComplete and donate all the code to Apache Flex.

This is an experimental approach to funding our love for creating Flex components. If you like the idea, then go check out the Kickstarter and let's make this happen.

How to Build Apache Flex 4.8 from the Source

I have exciting news today. Since the last Flextras newsletter, the Apache Flex team has released Apache Flex 4.8. This is the first Flex release under Apache, and it feels good that we're finally here. Apache Flex 4.8 is a parity release to Adobe Flex 4.6. That means you won't find any new features or bug fixes, but it was primary there for the Apache Flex team to get an understanding of how things work in the Apache world; and how to get a release out the door.

Formally a release under the Apache Flex project can only be source code. Binary distributions are provided as a convenience, but not required. Today I'm going to show you how to get the source out of SVN, and then how to build Apache Flex. I've done all these steps on Windows 7; however they should be similar on other operating systems.

Get the Source

The first thing you'll need to do is get the source code. You can do that from the Apache Flex Download page. Or you can use your favorite SVN Client to check out of the trunk.

For the purposes of this sample, I used SmartSVN to download the current trunk branch.

Install the Prerequisites

In the trunk directory you'll find RELEASE-NOTES and a README file. I suggest you open them in your favorite text editor and read them. Read the README twice because that has the bulk of the details on how to build Apache Flex. The first step is to install the required prerequisites. As a developer, you'll probably already have a lot of these installed, but I'll go through the complete list just in case:
  • Java SDK: To build Apache Flex, you'll need to install Java SDK 5 or 6. Java 7 is not supported at this time. I downloaded Java SDK 5 from the Oracle site, but had to create an account to do so. Honestly I was surprised this wasn't already on my machine.
  • Apache ANT: ANT is a build automation tool. You can download binary distributions from the Apache ANT web site. ANT does not have a formal install process, so I just unzipped the binary and was good to go. An ANT version number is not specified, but I installed ANT 1.8.4
  • Cygwin : You can get a Cygwin installer from the Cygwin web site. I don't fully understand what it is used for, after installing it I never had to reference it directly again. It is worth noting that the install process strongly recommends against having a space in the name of Cygwin path, which means I decided not to put it in the standard "Program Files" directory. The install process for Cygwin felt like a package manager, similar to installing the Android SDK.
    I chose to use all defaults in the install process.
  • Adobe AIR Integration Kit: Due to various licensing and IP issues, the Apache Foundation isn't allowed to distribute everything that is needed. This item and the next four are Adobe specific dependencies you'll have to get yourself. The Adobe AIR Integration kit link is easily found in the read me. A Mac version is here.
  • Adobe Flash Player Content Debugger: The current release of the Flex SDK is written for Flash Player 11.1, and you'll need the 11.1 content debugger. The read me will point you to here to get the latest. Unfortunately, the latest is not 11.1. Click the "Older Versions of Adobe Flash Player" link, and then download the 11.1 version. The next step confused me a bit. You'll want to use the Flash Player debugger included in that zip. Put the file (flashplayer11_1r102_63_win_debug_32bit.exe) in a directory named 11.1 .
  • Adobe Pixel Bender Toolkit: The Adobe Pixel Bender Toolkit can be used from here on a PC or here on a Mac. On my PC, I just unzipped the zip, and ran the set-up executable inside the unzipped directory.
  • Adobe Flash Player: You'll need the playerglobal.swc for the 11.1 version of the Flash Player. A direct download is included from the playerglobal.swc . This file must be put in a 11.1 directory and renamed to playerglobal.swc.
  • Adobe Extension Manager CS5: The Adobe Extension Manager is only needed if you are going to creating, or testing changes to the flash-integration SWC. You can download the extension manager from here. Installation is a matter of opening the zip file and running the set-up file inside the directory. The Mac version can be found here.

Take some time to run through the pre-requisites and make sure everything is installed and ready. Next, you'll have to set up some environment variables.

Setting Environment Variables

This section will explain how to set the environment variables to point to the appropriate directory locations. There are two new environment variables you'll have to create as Windows environment variables, and the rest can be set up in a properties file. I'll cover both separately.

If you've never had to do it before, I found this great tutorial for setting up Environment variables on Windows 7. There are two environment variables you have to set up:

  • JAVA_HOME: JAVA_HOME should point to the root install directory of you Java SDK. For me, it was this: "C:\Program Files (x86)\Java\jdk1.5.0_22\" .
  • ANT_HOME: The ANT_HOME variable points to the directory where you unzipped Apache ANT. For me this was "C:\Program Files (x86)\Apache Software Foundation\apache-ant-1.8.4 " . There is no custom install process for Apache ANT, so your directory location may be different.

While you're setting up environment variables, be sure to update your path. In the path variable, you'll want to add the bin directory for the ANT_HOME and JAVA_HOME. Add this at the end of your path statement.

;%ANT_HOME%\bin;%JAVA_HOME%\bin

This may be a good time to reboot your machine as an easy way to get the new environment variables to take effect.

The rest of the environment variables you need to specify are not Windows environment variables, but rather values you need to set in a config file. Copy the env-template.properties file, in your trunk directory, to env.properties and then open it in a text editor. This file is fairly well documented, so I suggest reading through it to understand all the setting all the relevant environment variables. When setting the path variables, on Windows, I forgot to double escape my '\' inside the file. Be sure you don't make the same mistake. These are the variables:

  • AIR_HOME: The AIR_HOME variable points to the directory where you unzipped the Adobe AIR Integration Kit. On my machine it was something like "C:\\Projects\\ApacheFlex\\Development\\ Dependencies\\AIRIntegrationKit\\AdobeAIRSDK"
  • FLASHPLAYER_DEBUGGER : The Flash Player Debugger value points to the location of the content debugger. I specified this as the full path to the debugging player file. "C:\\Projects\\ApacheFlex\\Development\\ Dependencies\\ContentDebugger\\11.1\\flashplayer11_1r102_63_win_debug_32bit.exe"
  • PLAYERGLOBAL_HOME : The PLAYERGLOBAL_HOME variable points to root location of your playerglobal.swc directory. Inside this directory, you'll have the version number, in our case 11.1, and inside that the file named playerglobal.swc. My location was "C:\\Projects\\ApacheFlex\\Development\\ Dependencies\\PlayerGlobal"
  • PIXELBENDER_HOME : The PIXELBENDER_HOME value should point to the install directory of the Pixel Bender toolkit. My location was "C:\\Program Files (x86)\\Adobe\\Adobe Utilities - CS5.5\\Pixel Bender Toolkit 2.6"
  • ADOBE_EXTENSION_MANAGER: The ADOBE_EXTENSION_MANAGER value points to the exe behind Adobe's CS Extension Manager. My location was "C:\\Program Files (x86)\\Adobe\\Adobe Extension Manager CS5\\Adobe Extension Manager CS5.exe"

Once you have the environment variables all set up, you're prepared to start building.

Running the Build

It's time to run an ant script and build Apache Flex from the source code. Open up a command prompt and point it to you're the directory you checked out. In Windows 7 you can select a directory in Windows Explorer, press the shift key and the right mouse Button then the value "open command window here" will be available from the context menu. Select it to open the command window. Once at the command window, type

Ant main

If everything is good, you should start building. The build is not completely automatic. First, it'll ask you to accept the Mozilla Public License in order to download and use the Adobe Text Layout Framework.


Press Y to accept and the build will continue. Then you'll be asked to accept the same license in order to use Adobe's Open Source Media Framework.


Press Y to accept and the build will continue. The next thing you must accept relates to font support; and makes use of some jars from the Adobe Flex SDK.


Review, and accept the license agreement as appropriate. The build should complete after that. The full build process will probably take between 5 and 10 minutes depending on how long it takes to download some various remote parts from relevant servers.

Congratulations, you've just built Apache Flex.

Using Apache Flex with Flash Builder

Now that you've built it, you'll probably want to use Apache Flex with Flash Builder, IntelliJ or some other IDE in order to create your applications. My primary IDE is Flash Builder, so I'll talk a little about that. Flash Builder expects certain files to be in certain places; and in our default build those files are not in the places they need to be.

There are a few options to solve this dilemma. One is to use the IDE Packager application. It is an AIR App created by an Apache Flex Contributor to do the heavy work for us. This packager is in beta and not part of the official release, but I've heard many positive things about using it. The new option is to use this batch file which will merge an Adobe Flex 4.6 installation with Apache Flex 4.8 in order to create a Flash Builder compatible build. A final option is to move files around manually. Documentation on what needs to be placed where is found in the IDE directory of the trunk.

I'm not going to go over any of these items in complete detail in this newsletter, as I'm already a bit long.

Final Thoughts

For future Apache Flex releases, I'd love to see it become as easy to use as adding a SWC into a library path for an ActionScript project. Unfortunately, we're not there yet. But, the Apache Flex 4.8 release is a strong start to Flex's continued relevance as part of the Apache Foundation.

The Most Succesful Worst Year of my Life

I wrote this up for the January version of the Flextras newsletter and am reposting it here:

I often like to take the January newsletter to reflect on the Business of Flextras over the past year, and take a look forward to the New Year. So much has happened in the last quarter; I'm not sure where to start. I'm calling 2011 the most successful worst year of my life.

I want to start by offering a heartfelt thanks to the customers of all aspects of the DotComIt business including those of you who purchased Flextras components, listened to The Flex Show, and let us service you as consulting clients.

Long live Apache Flex

On December 30th; the Apache Foundation accepted Flex as a podling project. There are >30 initial contributors on the Apache Flex project including myself.

As I understand it; a podling project means that Apache thinks that the Flex community has what it takes to become a formal Apache project and is giving us the chance. Now it is up to us, the Flex Community, to prove we can make it happen. At some point after the next release of Flex; Apache will promote us to a non-podling project.

For the first time in Flex's existence, features in the next version of Flex will not be decided solely based on what Adobe needs to do to sell more tools. This can have huge, positive, implications on the work we do every day. Check out our second Flex Show Roundtable for more information on this.

If the donation of Flex to Apache was announced at Max; it may have received a standing ovation from many Flex Developers. However, since the announcement came haphazardly on the back of the discontinuation of the Mobile Flash Player, this caused a lot of stir in the developer community, and with the clients that pay our bills and salaries.

However, after some time to reflect, it seems that companies are taking a pragmatic approach. They aren't abandoning their ongoing Flex projects; nor are they investing in re-writing their existing Flex projects to some other technology. Right now, today, there is no better solution for lots of Enterprise development. Flex is still the most productive way to build applications that can be deployed to multiple operating systems and devices.

However, for Enterprise companies to continue to view Flex as a viable development option, Flex cannot stagnate. I plan to help my fellow Apache Flex contributors, and the Flex community prove to the folks with the money that Flex can thrive separate from Adobe.

Where does Flextras fit in the Apache world?

I'm not sure what this all means for Flextras, yet. Flextras has been a labor of love, and not my most profitable venture. I'm pleased with what we've accomplished in the three years since we launched. I see significant opportunity, yet also significant challenges in growing Flextras to where I want it to be. This year will see Flextras morph a bit, but it is a gradual progression we've been working on for a bit.

Flextras launched in January 2009 with a single component, the DataSorter, a Netflix style queue component. We followed that with the AutoComplete and Calendar components.

2011 saw the release of our Spark based AutoComplete and the Mobile Component set. We have lots of updates planned for the mobile stuff. Let us know what you'd like to see. This is our first attempt at selling a package instead of individual components.

Here are some of the numbers we use to gauge Flextras success:

  • Over 1300 new people have signed up on our web site, and close to 400 of them signed up for this mailing list. That seems to be a pretty good metric for interest; and it is a 26% increase over the year. Someone is interested in what we offer.
  • In 2010, we made 35 sales and in 2011 we were on track to top that, but unfortunately we fell short. Traditionally, we have made almost 20% of our sales in December, but, this year you could hear the crickets. We attribute that to Adobe's recent changes regarding Flex.
  • As a corollary of the previous two stats; our conversion rates from registration to paying customer are a failure.  We'll need to work on that.
  • Despite having similar number of sales in the previous two years; the income generated from Flextras decreased by about ~35%. I believe the discrepancy is due in part to the fact that the Mobile Components set is priced 30% lower than our other components. If December sales had not tapered off; I think the two years would be similar. Releasing a free version of our AutoComplete is another factor involved here.

As we move to the world of Apache Flex, I believe that Flextras will be able to carve out a business niche and plan to work on making that happen during 2012.

What Next

Scott Adams (The Dilbert Guy) had a great post earlier this year about creating systems in which the ideal outcome can happen instead of trying to establish specific goals. I hope this year I can develop systems that will keep me moving forward on doing the stuff I love to do.

Personally, my only New Year's resolution is to swear like I'm in a Disney movie. I plan to make "Oh Bother" my new catchphrase. I wish you all a healthy and fruitful 2012.

How do I stop my DropDownList from Scrolling Horizontally?

Every month I write a newsletter to people who signed up for the Flextras/DotComIt mailing list. Sometimes I repost such things here. This is the most recent Flextras Newsletter that went out to our subscriber base.

A customer customer was using our Flex Mobile DropDownList. He had an issue that when he deployed the component onto a mobile device, the drop down would scroll left and right, which made for a very strange user experience.

This is actually a "feature" that we inherit from the Flex non-mobile DropDownList.

First, check out this sample that demonstrates the issue. The first DropDownList scrolls horizontally, while the second does not.

The fix was a lot easier than I thought it would be. You just have to set the horizontalScrollPolicy on the DropDownList to off. This property is inherited by the List in the drop down:

<flextras:DropDownList id="ddlMobile2" horizontalScrollPolicy="off" />

It's that simple, as you see in the second drop down from the sample. Check out the full source code for the sample.

The same approach should work for the non-mobile Flex DropDownList.

Why can't I access mobile skins in my Flex Library Project?

I'm working on a version of the Flextras AutoCompletComboBox for mobile devices. Many if you may have seen me demoing an early version of that at the 360|Flex conference. With the formal release of Flex 4.5 on the horizon, I came across a problem.

When trying to create a Flash Builder Library Project that supported mobile components, I could not access mobile skins. This seemed odd to me; as I could access them in a Flash Builder Mobile project. As best I could tell the list of SDK SWCs was identical. After some digging, I think I found the issue and a possible solution.

The Issue

One of the things I've done to prep the AutoComplete component for mobile usage is to create a custom, mobile optimized skin. Our AutoComplete is a composite of Skin Parts which do have mobile support, such as the Button, TextInput, and List. I wanted to apply the mobile skins for those components to the default AutoCompleteComboBox skin. Unfortunately, this gave compiler errors for trying to access undefined classes.

I believe the issue relates to where the mobile component skins are stored. They are compiled into a specific theme class; which is not automatically applied to mobile library projects. I suspect in many use cases, you wouldn't want to apply a theme to a Flex Library that may be overwritten when a real project is compiled. However, with the new Spark Architecture; where skins are classes [not necessarily just CSS and assets] it seems that referencing skin classes inside a library project seems more likely.

The Solution

The fix I found was to add add the mobile theme SWC to the library path. Details are here:

  1. Bring up project properties -> Flex Library Build Path -> Library Path
  2. Click "Add SWC" button
  3. Enter "C:\Program Files (x86)\Adobe\Adobe Flash Builder 4.5\sdks\4.5.0\frameworks\themes\Mobile\mobile.swc" and click okay.
  4. Click Okay on the dialog window
  5. click okay in project properties

I still get compiler warnings, which is undesirable, but it's better the compiler errors that do not allow me to create a SWC at all.

The full details of my work around are in this bug post. Please vote for it; as that will raise its awareness in Adobe. I believe the more people who vote, the more likely it is to be fixed.

The Flextras Max Wrapup

This is a modified version of the Flextras/DotComIt monthly newsletter for November. IF you're in the New York Area, be sure to see Jeffry Houser's presentation at Flex Camp Wall Street on the Halo and Spark component architectures. ( Jeffry Houser, that's me ).

Another year, another Max.

I was gifted with a press pass to Adobe Max again this year and was able to make it at the last minute. I thought I'd share some of my experiences from the conference, and the takeaways.

The Year of Mobile, The year of multi screen.

It seems like for many years, Adobe has stated that that "This year will be the year of mobile." Every year it feels like they've made the same promise, and then fallen flat on the promise for one reason or another. This year, I never heard one person claim that this is the year of mobile.

Adobe has stopped playing the mobile card and has instead turned their talk to multi-screen development. The multi-screen concept means building an application and deploying it to multiple sized screens, such as your smart phone, your tablet, your TV, and your computer. AIR for Android is released and you can build Flash applications using Flash Professional and early releases of Flash Builder and Hero. I'll write more on Flex Mobile in future newsletter, and Flextras Friday Lunch episodes.

In addition to AIR for Android, Adobe had demos of the Blackberry Playbook, AIR running on set top boxes such as Google TV, and a few samples covered their iPhone packager.

Swag Galore

Adobe and their partners were being very generous at Max this year. All attendees got a Droid 2 from Motorola, and a Google TV box from Logitech. If you went to a certain lab, you got an AIR based set top box for TV Development. There were certain private parties that gave more swag and I was able to pick up a Blackerry smart phone and a voucher for a free playbook. Adobe Max has never been a swag heavy conference, so, this year's about face was a nice surprise. It helps to boost my device lab for future development purposes, or perhaps a screencast series on Flex Mobile development.

What Was Missing?

One person was noticeably absent from the Max keynotes, and that was CEO Shantanu Narayen. It seems like a few years back when Bruce Chizen was stepping down as CEO, he barely made a splash at the keynote instead letting Shanatanu run the show. This year Kevin Lynch stepped up his game, while Shantanu had no presence. Is this a sign of things to come? I have to wonder.

A Final thought on Sessions

I've spoken about the Adobe Message and the swag, but I want to leave you with some time to think about the sessions. Normally I don't learn well in a class room type setting. I need to do something to pick up information. This year was an exception. I sat through many mobile related sessions and soaked up a lot of new knowledge about mobile development and optimization. I expect this will serve me well as we move into the new era of application development.

So, what have you been up to?

Flextras Sends Unemployed Developers to 360|Flex

This is an abbreviated version of the monthly Flextras newsletter, championing my favorite Flex conference, 360|Flex. I'd thought I'd share some of the reasons why you need to be in DC the third week in September.

  1. Free Tickets for Unemployed Developers: We have partnered with the 360|Flex folk to offer free tickets for unemployed developers. You just have to tell us why you want to learn Flex. More information is here on the 360|Flex web site, or go right to the entry form.
  2. Over 40 sessions: You'll get forty-three unique sessions put on by forty of the greatest coders in the Flex Community. One of the great things about 360|Flex speakers is their experiences coding in the trenches. You won't find presenters regurgitating documentation at you. You'll learn for the battle scars of your peers.
  3. DotComIt is a Sponsor: Flextras will have a sponsorship table, and The Flex Show will be conducting on-site interviews during the conference. If you want to chat in person about Flex Components, podcasting, or any of the other stuff we do find me!
  4. Hallway Conversations: 360|Flex events draw about 400 attendees; which means there are plenty of people to talk to and plenty to talk about. Mobile development? Spark components? Flex Hero? The air will tingle with these topics and entice you to join it.
  5. Two Sessions from Jeffry Houser: I'll be giving two sessions at 360|Flex. One will be an introductory presentation to building Flex components. The second will be on using iCal feeds in Flex. I was asked to do the iCal presentation because the organizers thought it would be good to show that Flex intergates with things other than LiveCycle and ColdFusion. My intent is to use no slides in the iCal presentation. You can heckle me live as I write code before your very eyes.
  6. Hands On: The Sunday before the conference includes a full day of hands on sessions. Bring your own laptop and learn about AIR for Android, RobotLegs, and of course the famous Flex 101 track. It's a perfect way to get your feet wet in the Flex Development world.
  7. Party Every Night: After a busy day of learning, you need to unwind, right? There is no better way to geek it out than at a 360|Flex party. They'll have beer, food, and Guitar Hero. On one night they'll even have a performance with The Compilers and The Flex Gangster. I'll be MCing the event and interviewing folks between sessions, so it should be an eclectic mix of music and mayhem
  8. Get a Discount: Did I mention the special discount code for my newsletter readers? Too bad you aren't on it. But, you can sign up by creating an account at the www.flextras.com web site. You can however still help me out by If you order from registering here and giving me some karma points.
  9. Free Flex Show USB Drives: I'll be giving away a handful of Flex Show USB Drives at the Flextras booth. This includes a full hour of screencasts on Flex 4 component development.
  10. Best Flex Conference: 360|Flex is the best Flex Conference out there. These guys have put on seven major Flex conferences over the past four years. You can come out knowing that things will be moving like a well oiled machine.

I love 360|Flex because it gives me the opportunity to connect with old friends and make some new ones. Register, then come to the event, find me, and then stop by and say Hi! I look forward to meeting you.

Why won't my ASdocs Copy?

This post comes from the monthly Flextras newsletter. While we were finishing up the Flextras Calendar, we wrote over 27 pages of ASDocs. I was presented with an interesting issue with ASDocs.

What are ASDocs?

ASDocs, if you're unaware, are special blocks of code you write in your Flex files that can be run through a command line utility to generate an API Reference. The API References you use for the Flex Framework are generated by the ASDocs tool, for example.

ASdocs look like this one, from the changeMonth method of the Flextras Calendar:

/**
* A method to change the month based on the specified increment.
* You can use a negative value to go back in time or a positive value
* to go forward.
* Only has an effect if in the MONTH_VIEW state.
*
* @param value The increment value used to change the month; the
* default is 1.
*
* @see #MONTH_VIEW
*/

The ASDoc are placed before elements in your files, such as properties or method and when you run the ASDoc tool it picks up the text and adds it to the generated ASDocs files.

In the ASDocs segment above you see two ASDoc tags, @param and @see. These tags give special instructions to ASDocs. The @see tags add links to other elements of the API, other classes, or even URL links. The @param tag defines the parameter to a method, and they are given a special place in the ASDoc output.

The @copy tag?

Our Calendar supports most elements of the List class API and the DateChooser API. The Calendar extends ListBase, so most of the properties are inherited. The DateChooser properties, such as firstDayOfWeek, monthNames, or dayNames are implemented as if they were brand new.

We thought instead of writing new documentation for these properties, we could use another ASDoc tag--@copy--to just copy the documentation from the DateChooser class into the Calendar class. The code looked like this:

/**
* @copy mx.controls.DateChooser#firstDayOfWeek
*/

This seemed logical to us, but for some reason the ASdocs wouldn't copy; and the documentation in our generated file was blank for those copied properties. What was the problem?

It turns out that the DateChooser is never used anywhere in our Calendar. As such, the Flex Compiler will automatically optimize the class right out of the SWC file. This is good because it keeps file size low and you do not have to distribute unnecessary classes. Unfortunately, it seems to the ASDoc appears to use the same approach. DateChooser wasn't in the API, so therefore the ASDoc utility couldn't find the DateChooser code in order to copy the appropriate ASDocs from one place to another.

The Solution Part 1!

One solution, and I hated doing this, was to create a dummy variable of the DateChooser type:

private var temp : DateChooser;

Then all was well and the properties would get documented as expected. I don't like this because it artificially inflates the size of the SWC. Thankfully there is a better solution.

The Solution Part 2!

The ASDoc command line tool supports many of the same command line arguments that the Flex compiler supports. We can use the include-libraries argument and point it at the framework SWC. This will make all classes in the framework available to the ASDoc compiler whether or not they are used.

For practical purposes, you want limit your use of this argument when creating swfs for wide release. But, none of that matters when generating ASDocs.

Conclusion!

Did I mention that the Flextras Calendar is out? It supports Flex 3 and Flex 4 and you can download a free developer edition to test it out.

More Entries