Ever since the AdvancedDataGrid joined the SDK it has been a bit of a love hate relationship. The great features the grid brought were essential for many projects and usually centerpieces in an application’s functionality. But the shocking part was the amount of bugs and lines of code(30,000+ lines…yikes!) that still plagues it. Doug McCune wrote a great posting on the AdvancedDataGrid and the lines of code it has, not to mention the 415 line method! The functionality of the AdvancedDataGrid is complex, so before I pile on with everyone else, let’s just point out that 1) It’s complex, 2) Sometimes lot’s of hands in the cookie jar can result in a lot of crumbs, 3) Writing code that the whole community can see instantly isn’t always easy. The mistake with the advanced data grid was probably at the beginning. Based on comparisons with the DataGrid classes, it appears most of the code was copied from DataGrid to the AdvancedDataGrid and then pieced together. I am always against large code copies, because this scenario almost always is the outcome: Bugy software that is overly complex to maintain and a nightmare to consider rewriting.
Worst pain ever sound bite The Simpsons sound bites
What is the solution for the AdvancedDataGrid?
It needs to be rewritten. Matt Chotin(SDK PM) wrote a posting about the status of the AdvancedDataGrid and Data Visualization. Not exactly thrilling news as it doesn’t look like any major enhancements to DataGrid and AdvancedDataGrid will happen until Flex 5, but I understand why the spark architecture has taken priority.
Here are the 3 main things I hope get corrected in a rewritten AdvancedDataGrid:
- Comments. There is very little commenting. I open the AdvanceDataGridBaseEx class and the comment for this class is: “The AdvancedDataGridBaseEx class is a base class of the AdvancedDataGrid control. This class contains code that provides functionality similar to the DataGrid control.” That is the description for all 8,000 lines. Based on reading this I have no idea what AdvancedDataGrid is doing extending it, and why it extends AdvancedDataGridBase. The Flex SDK should take a page from the Java SDK and write lengthy descriptions for each class. Take for example java.util.HashMap at 1,000 lines of code. Paragraphs of comments just documenting what the class does, and comments on every variable and method. While most of the Flex SDK does have good documentation, class documentation in the spark architecture has been drastically improved. Good docs are needed even more for the complicated code!
- Smaller methods and better utilization of the protected keyword. 415 lines is a ton. This isn’t the first time I’ve seen this sized method. One of the biggest hardships is when there is a bug or slight tweak needed to a component. The code is not able to be overriden or is buried in a giant 415 line method which is impossible to override anyway.
- Use Helper classes. The AdvancedDataGrid will have a large amount of code(not 30,000 large, but large). Instead of having a class that extends a base class that extends another base class that extends another base class, let’s use helper classes that group common functionality together. For example, for the advanceddatagrid, create a helper class called KeyBoardUtil. One method can handle cell navigation, a second tree navigation, and so on. It isn’t always easy to do this because of all the moving parts. By cutting out key pieces of functionality, such as keyboard controls, code readability is improved, blocks of code are smaller, methods can be better tested, and code can be reused. Helper classes help define exactly what parameters are needed for the functionality and provide a clear goal as to what in return the helper functionality will modify.
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