While still a work in progress, a new set of features will exist for text layout in Flex 4/Flash 10. The package name for the text layout library is flashx.*, which is a shift from traditional Flex packages, but it looks like it will be open source. Here is a demo with a simple slider that changes the width of the first column and the text automatically lays itself out across multiple components. While I couldn’t get it to work yet(still beta), the final product will allow html formatting(actually a limited number of html tags). For applications that are heavy on content related material, it will be huge that text can be strung across multiple components from one string variable. The string will automatically re-size and position itself dynamically. Now while I am not doing these features justice, here is a small example of the layout.
Progress Bars via the mx:ProgressBar tag are easy to use in Flex. Unlike some kind of progress bars that can drive anyone insane….
Flex progress bars are easy to implement and great for usability. When there is a long database query or chance for network latency, a progress bar is always a good idea to keep the user informed that something is happening. Those with an artistic ability can create a custom progress image to use on a progress bar, but if not, the built in one is still a viable option. There are two main types of progress bars included in the Flex SDK. Ones that use percentages to show completeness and ones that use an indeterminate/unknown to give the user indication of activity. Both are implemented in the mx:ProgressBar tag/class.
The percentage progress bar is used directly with the mode property, which has three options, event, polled, and manual. This is used in conjunction with the source property which the progress bar can use to automatically update the progress bar.
Up until the other day, when using modal and/or pop up windows in Flex, I have always instantiated them in Actionscript. Since I use relative layout, I couldn’t really add an mxml component that would be a modal without it being drawn on the screen. The advantages of declaring a modal in mxml would be:
- Taking advantage of mx:Metadata tags that allow me to invoke methods when events occur without manually adding listeners
- Automatic binding the same way my other components work
- Less code; by declaring the pop up window in mxml, I don’t have to invoke a method that creates an instance of the pop-up
Here is how you can declare a modal/popup window in mxml:
<mx:ArrayCollection id=”modals”>
<MyPopupWindowComponent id=”modal1″ someBindings=”{bindingAVariable}” anEventThisComponentDispatchesInMetaData=”doSomething(event)”/>
</mx:ArrayCollection>
Now when you want to open the modal, just do PopupManager.addPopup(modal1,true,DisplayObject(Application.application));
This allows you to use the ease and power of bindings/metadata in modal windows.
A while back I did a post on the choppiness of mx:List scrolling and a mx:Repeater work around FTW(For the Win). Well in Flex 4, the List component will be FTW out of the box!!! Meaning, smooth scrolling item renderers!! It looks like the Flex SDK team has spent some time improving the quality, scrolling, and layout of item renderers. Here side by side are the examples from a Flex 3 List compared to the same code in a Flex 4 List. Check out the difference!
Flex 3 List with Image Scrolling
Flex 4 List with Image Scrolling
The Flex development landscape has many frameworks for creating scalable, enterprise RIA applications. The two major players, in my opinion, are Cairngorm and Mate. Both frameworks offer a solid approach to an enterprise RIA. Having used both Cairngorm and Mate in enterprise Java applications, Mate is the better option for small and large projects(in my opinion). Cairngorm uses a singleton pattern that makes it hard to use modules and requires significant more overhead in compile times, SWF size, and speed of development. Mate on the other hand uses an injection approach which is easy and fast to create, maintain, and debug applications. I am not saying you are going wrong by using Cairngorm, but my first choice is Mate.
Cairngorm development dead; Mate booming
Cairngorm was purchased by Adobe and eventually open sourced. Since being opened source in an SVN repository in July 2008, Cairngorm has had a total of 0 new releases, 15 total commits and no commits since November 2008. The last code release of cairngorm has not been since Flex 2. Mate on the other hand is also open source. Mate had 17 new releases in the last year alone with hundreds of commits to its repository. No other Flex framework out there that I have seen has this amount of activity.
Mate and the Bus Factor
There are a few downsides to Mate that don’t having anything to do with the code. The bus factor. Mate is run by a few people at asfusion. They do a great job at updating the forums, providing documentation, and doing presentations at various Flex events across the country. However, if they decide to change careers or just get overwhelmed maintaining Mate, there may be no one there to step in to keep the framework going. I would like to see Mate gain wider support with its code base, with more people committing code and making decisions for the framework’s direction.
A 1.0 release of Mate is also desirable. The code is quite stable, but a 1.0 release would give a safer feeling to enterprise projects using it.
Support Both or Support None
Adobe bought Cairngorm several years ago. This was a good idea to help with the development of Flex RIAs. Now the Flex SDK and Cairngorm are open source. This completely changes the game. It appears no one is working on Cairngorm or looking for enhancements for things like modules. There also appears to be no community involvement for this project. At what point does Adobe change its direction for a framework? Will Cairngorm still be the Adobe framework of choice 5 years from now? Flex 4 is the time to make the change. One option is to offer both Cairngorm and Mate as preferred frameworks for Flex. But then the question is, who maintains these frameworks? A second option would to be supporting no one framework. This way the community can drive the direction of RIA development by using the best available framework. It has worked over the years with Struts, Spring, Hibernate, Apache, etc.
By supporting just one framework, the door for innovation of frameworks is closed. The Flex SDK continuosly improves and excites the community. Allowing the community to improve the frameworks would be a great step foward.