Archive for Flex Builder
CSS Changes in Flex 4
Posted by: | CommentsI recently purchased the book Adobe Flash Builder 4 and Flex 4 by David Gassner and will be publishing a complete review when I’m done with the book. I’m going through it looking for the coverage I feel would be most helpful for those experienced with Flex 3. Even more specifically, those like myself, who have been so busy with contracting work (because Flash is dead of course, and the only way to make a living as a contractor anymore is with HTML5 and CSS3) that they were only able to sample Gumbo during its development.
One such topic, which I happen to be going through now, are the additions to Flex 4’s CSS implementation over Flex 3. This information is available in a number of other places, so this post is more to help me internalize it than to be groundbreaking to everyone else.
1. CSS Namespaces
In order to support type selectors with the same name, CSS namespaces have been introduced. In Flash Builder selecting New->CSS File will show you what the syntax for declaring a CSS namespace is.
@namespace s "library://ns.adobe.com/flex/spark"; @namespace mx "library://ns.adobe.com/flex/mx";
If you’re not going to be using both Spark and Aeon/Halo in your application, you can declare the “default” namespace by omitting the prefix. Namespaces are used as follows:
s|Label { }
mx|Label { }
The lack of any white space between the namespace and the bar, and between the bar and the type selector is significant. Don’t include any white space there. Namespaces will need to be declared even for your custom components (I have a feeling this is going to get messy, but it’s for a good cause.)
2. Descendant Selectors
If you run into a situation where you want to use type selectors, but only when it is used in a particular container, you can use the descendant selectors. You can use them with your custom containers as well. The following declaration will affect all RichText editors contained within a Group:
s|Group s|RichText { color: #0000AA; }
This is another feature that could get out of hand, so use it wisely. Also don’t confuse this with declaring multiple type selectors on the same line, separating them with commas. Like this:
s|Group, s|RichText { color: #0000AA; }
3. ID Selectors
The ID selectors are similar to style name selectors. Recall with a style name selector, the CSS declaration has a name beginning with a ‘.’ and in the MXML declaration of the component you can use styleName="smallText", or something like that.
To use the ID selector, the styleName in the CSS is set to the id of the component you’re styling, prefixed with the # symbol. Like this:
<!-- The MXML Component --> <s:Label id="labelA" />
/* The CSS declaration */
#labelA { color: 0xFF00FF; }
Be sure you set the id explicitly in the MXML– this will not work if you have declared the component in ActionScript.
And that concludes my synopsis of the most important additions to CSS in Flex 4.
Book Review: Creating Visual Experiences with Flex 3.0
Posted by: | CommentsCreating Visual Experiences with Flex 3.0 by Juan Sanchez and Andy McIntosh was nothing like I expected. I’ve been working closely (well, more closely than I’d like, anyway) with some interaction designers, and subconsciously I was expecting it to be more along those lines. Fortunately for me it turned out much differently.
Sanchez and McIntosh cover a variety of topics, ranging from the very basic (creating CSS in design view) to the more advanced (programmatic skinning). They all pertain to realizing the vision you have for your application. It won’t make you a better designer, but it does go through a lot of tools you can use to make your Flex application look how you want it to.
In my opinion, one of the coolest features of the book is Appendix A. Skinning and Styling Diagrams. They illustrate all of the common Flex components and label all of the styles and skins on those components. If someone were to build an application that was a meshing of these diagrams with the Flex Style Explorer… that would be one awesome app. At any rate, it has become a useful reference (especially since I haven’t seen it duplicated online). The Filters Cheat Sheet, or Appendix B, looks pretty cool too, although I haven’t done a whole lot with filters in a project yet.
Aside from their “intro to RIAs”, I think the main thing I liked about the book was that it was written with the assumption the reader already had a basic understanding of Flex. An “advanced” Flex book, if you will. And the content and walk throughs were very clear, I didn’t have any problem going through the exercises.
I definitely give this book 5 stars. I recommend it to anyone who: is beyond the basics of Flex; is sick of Halo; doesn’t think styling wastes CPU cycles; or all three.
Flex Item Renderers : Extending UIComponent
Posted by: | CommentsI’ve taken a step that I’ve been wanting to do for quite some time, extending UIComponent. Sometimes I think it’s amazing that I’ve made it this long without having to do it.
I’m working on a project right where I’m using an ItemRenderer in a List control (nothing new) but there may be up to 100 of these renderers on screen at any given point, and even more on a large monitor. I tried the quick and dirty method of extending HBox and adding labels and such, and I’ve finally seen firsthand what others have described about bloated item renderers. It took about 8 seconds to render the screen on my development machine (which is a pretty powerful computer). I decided that was unacceptable and that I finally needed to dig in.
There are quite a few good resources I made use of, some of them more complete than others. The first thing I did was read the Adobe documentation (Creating and Extending Flex 3 Components, PDF), specifically Chapter 9 (Advanced Visual Components in ActionScript). It was a bit overwhelming at first, but as soon as I sat down to write some code it started making more sense.
I’m going to document a few of the things I discovered (many of these apply only because I was creating a list item renderer).
First, it’s pointless to do much initialization in the createChildren method. My component consisted of a checkbox, an image, and a bunch of UITextFields (based on the recommendations from others). I was able to set some styles on the image and the checkbox, but no method of setting styles on the text fields seemed to be effective in the createChildren method. This point merits its own post. For the text fields, all I did was create and add.
Second, commitProperties is where I handled setting my data and my visual styles on the text fields. The documentation on commitProperties seemed a bit scattered, and it actually took me some time to arrive at this conclusion. I had the impression that some of this, particularly styling should be taken care of in the updateDisplayList method. I tried with no success, possibly because I was still trying to call setStyle on my UITextFields (see comment about meriting its own post above). I ended up just setting the sizes and placement in updateDisplayList (which is mentioned in all the documentation).
Third, invalidateProperties and invalidateList (for ArrayCollection, etc) are useful for refreshing the renderers. I tried a few convoluted methods of getting the screen to refresh programmatically, most of which worked and none of which I was pleased with, before I stumbled upon the invalidateList method.
Fourth, in trying to change the styles of my UITextFields, I independently discovered that it’s good to go to the code (the framework code) when trying to figure something out.
That sums up my first experience, in a nutshell, with extending UIComponent. I’m excited about trying another one, which I am sure will go over a lot more smoothly. I didn’t need to override measure() in this one, my next subproject will be working on a component that will help me remove the mystery from it.
Simple Flex Builder Performance Tip
Posted by: | CommentsI wanted to put this little tidbit out for boosting Flex Builder’s performance on all platforms. I was ecstatic when I got my new desktop this past June (quad-core, 12MB cache, etc., etc.) and the build process flew. It was awesome (see complaints in previous post about my laptop seeming like a dinosaur in comparison), but as time went by it started getting more and more sluggish about building my apps.
There wasn’t any apparent explanation (except for maybe the fact that I was running Windows Vista with only 8GB of RAM) so it was a little disheartening. On the other hand I wasn’t seeing any performance decreases in any of my other “benchmark” apps (JBoss 4.2 startup in 10 seconds, NetBeans startup in 15 seconds, Photoshop CS3 in 8 seconds) so I got a little suspicious.
I did a little searching around and ran a few experiments, and came to realize that the more projects I had open, the longer it would take to build any one of them. When I started closing the projects, there was a corresponding increase in performance. This information allowed me to focus my search efforts and sure enough, Flex Builder will process every open project to see if it needs to be recompiled, and in the process compile the project you’re interested in.
So close some of those projects (right-click, or in case of a Mac two-finger-tap, and close).
