Vivisecting Media

Adobe MAX 2008: The Future of Flex Builder (Part Two)

December 10th, 2008 Posted in ActionScript, Flex Development, MAX 2008, Rich Internet Applications, web integration

In my previous post, I introduced the “Future of Flex Builder” session I attended at Adobe MAX North America, how the Flex Builder team is approaching new feature development and looked at the two main Design Fidelity features they are adding to Flex Builder.

Adobe MAX 2008: The Future of Flex Builder (Part One)

In this post I will be delving deeper into the new/updated feature set that focuses on the aspect of the “Test & Tune” workflow. Test & tune is the day-to-day development workflow that we are all used to: Navigating our projects, creating new code, documenting, re-factoring, debugging and testing. A lot of these features may seem small but they provide a lot of power and can drastically improve development time and ease frustration that we experience during the development cycle.

Package Explorer

The first test & tune feature I want to examine is the new Package Explorer. Some of you may be thinking to yourself that Flex Builder already has a Package Explorer and wondering why this is a new feature. Well, to be exact, Flex Builder 3 does not have a true Package Explorer, what it has is the “Flex Navigator” which is really just a folder browser. When we use the Flex Navigator we often treat it like a package explorer since ActionScript packages are just folder hierarchies and this is what is represented within the Flex Navigator. The new Package Explorer merges the functionality of the Flex Code Outline panel and the Flex Navigator into one view.

Take a look at the screen cap, first you will notice that the MXML root file is now in a (default package) node within the explorer. From there you can then expand the MXML file data to look at the Classes contained and the properties of the class. Next, you can see that the default view makes the hierarchy a flat layout. For example, the package “com.developmentarc.test” is listed all in one line which means you don’t have to expand to view the structure to access a deep package like you would in the Flex Navigator. If you don’t like the flat layout you can change the settings of the Package Explorer to create the more traditional parent/child structure.

Finally, look at the Flex 4 SWC package in the screen cap. The Flex SDK version for the project is now shown in the Package Explorer. Not only is it shown but you can expand the SWCs to see the content structure, classes and properties contained within. In the screen cap I am exploring the Array in the playerglobal.swc file. This SWC exploration also works with 3rd party SWCs, not just the Flex 4 SDK. These all may seem like small changes, but it makes exploration, creation and modification of existing projects much easier. This also allows for Java Eclipse users to experience a much more familiar view when developing Flex Applications. Good stuff.

Event Auto-generation

During development, creating event bindings and method handlers such as the Mouse click event, is a common task. The event auto-generation is a short cut feature in Design View that allows a developer to quickly generate an event handler for a component. The example they used in the session was adding an event handler for a Button’s click event. From design view the developer would click on the generate handler button next to the on click event field:

When the user clicks this button, the handler function is generated in an <Script> block within the MXML file and the method is then assigned to the Button’s click property. My personal feelings about this feature is that it is helpful for initial development and/or learning of the Flex event handling model, but for complex development I am hesitant to see this as a go to feature. For one, the feature automatically adds the script to the current MXML file. On larger projects I typically avoid having scripts in MXML, this is especially true when following the code-behind pattern. I also feel this is going against the proposed workflow model that Adobe is pushing for Flash Catalyst and Flex Builder integration since your MXML is becoming more layout-centric with Classes for logic.

Overall, its a helpful feature and it makes prototyping, initial development and demoing a lot easier. We will see how this feature matures and how it is adopted by developers in the future.

ASDoc

ASDoc-ing is the process of adding specially formatted comments to your code that enables the ASDoc tool to generate documentation from the code and formatted comments. ASDoc is just like JavaDoc and has been evolving and maturing the the first release of Flex. One feature that has been part of Eclipse’s Java development suite is the ability to see inline contextual JavaDoc notes for specific Classes, properties and/or methods. The next version of Flex Builder supports the same kind of in-context doc hinting for code that has been properly ASDoc-ed.

When a user hovers over a method, property or class in either ActionScript or MXML the ASDoc tooltip will display showing the contextual docs for the specified attribute. In the screenshot above, I am hovering over the “left” attribute of an <FxButton> tag. Notice that the displayed doc notes are only for the “left” property. If I rolled over <FxButton portion of the tag you would see the ASDoc content for just FxButton. Not only can you view content inline, there is now a ASDoc panel that can be added to you workspace layout. This panel automatically updates when you click on a property, method, class, tag or attribute. This way you can have the view up and accessing ASDoc content without having to wait for the rollover event.

The ASDoc feature also works within your own code. For example, if you are developing a custom Class and provide properly formatted ASDocs in the Class, the ASDoc window/tooltip will show your ASDoc notes whenever you reference your Class in the application. The Flex team is also working on a new SWC format nicknamed “Fat SWC”. This Fat SWC will now include all ASDoc notes that are provided in the source code for the SWC compilation. This means that when you use a “Fat SWC” in your project, you will get ASDoc hints for any of the Classes, properties, methods, tags or tag attributes that are contained within the SWC.

New Re-factoring Features

There are two new re-factoring features that were demonstrated during the session, both of which help automate tasks that developers do on a weekly, if not daily basis. The first feature is the ability to auto-generate a getter/setter pair from an existing property.

To use this feature you first select, or apply cursor focus, the property that you want to convert to a getter/setter pair. You can then either right click > source > Generate Getter Setter… or you can choose the Source > Generate Getter Setter… menu option. This brings up the above options dialog where you can decide if the existing property should become private, what the new name of the property should become (it defaults to a single underscore prefix), the name of the exposed get / set method, should it create both the get and set method, or just one or the other and finally where the new methods should be added.

This is one of those at first glance small yet super powerful features. During development there are many times where you need to convert a basic public property to a get/set pair and this helps write the code quickly and elegantly. One other cool thing to note about this feature is its ability to remember your preferred prefix. As I mentioned earlier, the default is a single underscore prefix for the private method. I personally prefer a double underscore prefix for my get/set value properties and when I added that additional underscore Flex Builder remembered this and kept the double underscore when I used the re-factor function again. Very, very cool.

The second re-factoring feature, isn’t really new, its just a lot more complete. When re-factoring the code-base, one of the biggest challenges is the process of moving Classes around to new packages. This may occur for all kinds of different reasons: better project organization, company name changes, project changes, etc. etc. Eclipse (which Flex Builder is built upon) supports the move option, yet in the current release this would just move the resource to the new folder and not update the Class’ package structure and linkage throughout the workspace. If you used the rename function, Flex Builder would handle all the updating for you, so it always felt as if the functionality was half-complete.

Well, now move is finally fully supported. This is great news for those of us that have had to spend five minutes moving resources and then the next hour fixing the compiler errors. Typically the process was move the resource, build the project, look for errors, updating bad references, re-build the project, looking for bad references, rinse and repeat. This can get really ugly when you have 800+ classes (which I have had in the past) and you are doing a massive project re-structure. Not fun, let me tell ya. When you choose to move an asset you get to choose what package to move it to and Flex Builder handles updating all the linkage references and package declarations.

One thing to note, in the current preview build of Flex Builder the package has to exist before you move the resource to it. If I recall, David Zuckerman mentioned that this will change in the future. Even if it doesn’t this is a great feature, one that I want NOW. It would have been soooo nice yesterday when I had to move a ton of MXML classes around and re-link them throughout the project, oh well.

Code Templates

Code templates are more or less self exactly what they sound like. A code template is similar to an email signature in that it provides the ability to auto-fill predefined content when a new MXML, ActionScript or CSS file is created. In a way, we have already been using Code Templates when we generate a new ActionScript class. The provided package structure, class declaration and constructor are all generated by the Code Template engine. The difference is that in the next version of Flex Builder this will all be exposed to you and fully modifiable.

Are you working on a MIT or other licensed project? You can now add the license block to the template code and any new file will have the proper structure. You can predefine code blocks, ASDoc blocks, code layout and preferred structures all within the code templates. You can also use variables that set time, file path, names, etc. into the template. On top of that you can export your created templates, pass them around and have others import the template into their Flex Builder. This is great if you work with multiple developers and want to create better coding standards or if you want to create company or open source project specific structures. Again, a simple yet very powerful feature that is being exposed to us.

Code Navigation

The last Test & Tune feature I am going to talk about in this post is code navigation. Code navigation shows a developer in code view what methods are overrides and implementations of interfaces. It also allows for quick navigation up to the parent reference when the triangle icon is clicked.

This is a nice feature because in the past you had to look at the Interface itself to determine what methods are implemented in the current class related. Overriding was generally easy to see at a glance because of the override keyword but getting to the parent method instance was not so easy. This feature enables both code readability and better navigation within the application.

Well, that is all for now. I have three more topics to write about, two more test & tune and then a look at the new Data service support. I will save those for the final post.