Hi,

Have you ever felt like you were a dog chasing it’s tail when programming? One of the main things I have learned from creating Flex applications is create and destroy.

Creation ::

You create a plan on paper and map out what happens to who and where. Then you go to implement it and you start getting creative. You find easier ways to do things and end up having some extra classes, events that dispatch a little different then intended and methods that abstract and encapsulate even better.

How do we now test what we did not imply?

Destroying ::

This is my favorite part of the iterative process. When you create applications, the best way to make them better is by destroying the very art you sought after.

What do I mean, well I am sure some of you know that by breaking apart an application and purposely killing it, you find it’s weaknesses and fix them.

To the beginner, you strive for perfection, which through experience you will never get with software. What I strive for is near perfection. Through years of painstaking meticulous actions, I have learned to let go and kick the table hard to see if the cards fall down. If, they don’t your good to go.

Sometimes this process can be more methodical than I make it out to be. But, to those wondering if snapping an application in half for the fun of it is healthy, I recommend doing it.

Yes, there is UnitTests and other things. Sometimes we don’t have these tools and good ole remolding of the clay is a perfect solution for any doubts you may have about a ‘finished’ product.

Peace, Mike

Hi,

I have had a couple questions and off line chats with some fellow component developers, some questions were raised about invalidation. Specifically,

invalidateProperties()
invalidateSize()
invalidateDisplayList()

I was about to answer the question in a comment but, thought I could put a little more effort into a post.

Ok, for those that like to read…

In my last article a decade or so ago I talked about commitProperties(). I also referred to it as a component’s state queue or something like that. Well it turns out that confused some people because they thought I was talking about the UIComponent.currentState property.

Realign,

commitProperties() is the back bone of the components model. There, how about that.

measure() is the back bone of a components dimensions and position.

updateDisplayList() is the back bone of a component’s look and feel.

This is where the invalidation methods come into play. The brain in a human is a wonderful thing, it lets us talk, classify, listen etc(our human properties). The brain also measures itself constantly while walking, jumping and laughing(our human measurements) The brain also gives us our identity through what we choose to wear, how we do our hair(human look and feel).

Stack all these weird analogies together and you have one crazy component called the human system. Yes, that’s right, we are a organic component, very abstractly.

Now back to invalidation. If you closed your eyes, took a snap shot of what you heard, what you see, how you feel, how big you fell and where you were, this would be your state. Imagine living in that snap shot state for infinity… haha Don’t think so, now take that same thought and apply it to a flex component.

Would you want your component to live in a state of unchanging indifference? Of course not!!!

Enter…

invalidateProperties()
invalidateSize()
invalidateDisplayList()

So we have the brain that takes messages from everything, every human interface possible(eyes, ears, mouth, nose, etc) and changes your internal state instantly to feel something else. Well, man, your brain just called an invalidation method it has stored within itself!

When you call an invalidation method, it allows time for all the other senses to link up and sync up. Can you smell 10 things at once, or does you smell happen linearly within 1 millisecond?

The same applies to Flex, life doesn’t just happen all at once and things definatly don’t change all at once. But, one thing is for sure, things change in groups.

So each invalidation method of Flex changes a part of it’s back bone to adjust to the new stimuli.

The invalidateThis() method is like breathing in and the commitSomething() is the breathing out. It also coincides with frame passes of the player to allow the player to use processor cycles efficiently(allows the player to take a breath).

If you want to change your component’s internal model state, call invalidateProperties(), flag it and catch the actual implementation of that model change in the component’s breathing out method of commitProperties().

If you want to change your component’s internal dimension state, call invalidateSize(), flag it and catch the actual implementation of that size change in the component’s breathing out method of measure().

If you want to change your component’s internal look and feel, call invalidateDisplayList(), flag it and catch the actual implementation of that look and feel in the component’s breathing out method of updateDisplayList().

These 6 methods ARE VITAL to any successful components that are to be considered ‘professional’.

Once you get the hang of this, you can start creating your own sub ecosystems within your own framework using more aggregate invalidation and validation.

Thats all folks, back to a secret AIR project I am finishing up for component developers that hate how default styles work in Flex.

Peace, Mike

Hi,

I am starting a series on the flex framework from a component developers point of view ( after much experience). Expect useful articles from a professional and experienced component developer.

Some of you may know what I am talking about others might learn something.

I see some things in a different light now that I have been developing components for a year and a half.

Flex offers a unique way of validating your component when performance is a necessity.

• component property state
• component measurement
• component layout

AKA;

• commitProperties() [This issue]
• measure()
• updateDisplayList()


Properties

Properties in your component hold it's current state. When we talk about state in this respect we are referring to changes made from it's default base state. The default state is what the component's class defines as it's starting point.

In the code above, we set the private variable _moveEnabled to false. We have now set the default move enabled state of the component.

Updating Properties

There is now a way to set the base state but, as you can see the access is private, only for this classes eyes. We now need to create a point at which a developer can change the component's move enabled state.

Enter public properties;

This code is the hallmark of the public property API. Most of your properties will and/or should look like this. Notice some thing we have done;

• Created a place to hold the default state and updated state.
• Created a boolean flag to let all classes below that this state is changing.
• Created a simple access point publicly for the private internal state.
• Created a public place to change the state.
  • For performance, check that we are not already setting a current state with the same value. (this might differ depending on implementation)
  • Set our state changing flag so subclasses are aware our state is changing.
  • Invalidate the component's properties, get a call to commitProperties() on the next validation pass.
  • For bindable properties, dispatch an event to let listeners know we are changing state.

Below is an algorithm my framework follows and I have found it to be extremely successful in creating tighter performance and easier subclassing.

In the above code sample, although we are making a method call here, the performance savings down the road outweigh this one call.

Simply, the above algorithm does this;

• In component state validation.
• Call any super state changes. (this order could be reversed depending on the component's needs)
• If our move enabled state is changing
• Commit that change right now.
• The move enabled state has now changed, switch our move enabled state flag to false.

Note :: With components you create, you will know that in the commitProperties() method that you call commitMoveEnabled(), this is the only place you will call that method. All subclasses rely on the timing of this call. Which in most cases works perfect.

When you subclass this component, your whole move enabled protected commit API is shared. You then have the ability to aggregate private and protected delegation in a logical order starting from the first class that defined the state property.

Some subclasses might just completely override the commitMoveEnabled() method and not even call super. Some classes that define this commit method might actually supply 2 sub commit methods inside this commit method for subclasses to override on a more granular level.

Notice in the code above, you now can subclass this class and override this method completely if you do not want the skins to be updated at this time.

In this subclass, you have not sacrificed the algorithm of the superclass.

Well, that is all for today. I have a bunch more to elaborate and continue with, but that is for the rest of the week.

In my commercial components, I may not release the code but, I want future customers to realize that my API is a new type of SWC. In this new world, you can subclass a component without screwing up it's parent. Plus, all methods that can extend your new product with are there for the taking.

Peace, Mike

Hello,

From the world of Teoti Graphix comes the Flex look and feel revolution. We are really trying to help developers create original looking applications on the developer front of "Look and Feel". Our latest little gem is the EyeDropperFX component that allows you to use an eye drop sampler in your Flex applications.

We have also just released the FSCollectionFX1 set that has a gradient border and border button class that allow for multiple corner radii, border gradients and fully adjustable highlights. The set also contains a new ColorList, ColorPicker, GroupContainers, Container Watermarking and Form controls.

The information pages can be found here;

Product Pages ::

• FSCollectionFX1
• EyeDropperFX

EyeDropperFX

• Online Help Book(wiki)
• ASDoc Documentation
• Technical Forum
• Ask Before You Buy

FSCollectionFX1

• Online Help Book(wiki)
• ASDoc Documentation
• Technical Forum
• Ask Before You Buy

All these components come with solid support; including asdoc documentation, wiki and dedicated forum support. Each component also comes zipped and ready for archive import into Flex Builder 2 to get you off to a running start with working examples out of the box(zip file).

There are also dedicated issue/feature request areas on the site as well for our customers.

Check out a few screen shot;

EyeDropperFX

This image shows the EyeDropperFX toggle button implemented in the PopUpInfo mxml component that is included with the product.

FSCollectionFX1

Set1 Installation Guide

PackageA (Background Look & Feel)

Watermarking of any container that uses the borderSkin style.

Robust gradient and button borders/skins.

PackageB (Color Pallet)

Stylable color swatches, border thickness, border color and square or stretch layout.

An enhanced color picker to accommodate object/xml color pallets.

PackageC (Form Controls and Containers)

GroupContainerFX borderStyle - solid, inset, outset.

GroupNavigatorFX example using a ViewStack that has 3 child views and uses effects in transition.

Form Controls

Custom Form class inheriting the GroupContainerFX class.

Custom form heading control with title, titleIcon, subTitle, border, verticalAlign, titleStyleName and subTitleStyleName.

Form separator with icon, label, vertical and horizontal align and border.

And to top it all off, a customized UnderlineLinkButton.

Value

By purchasing valuable components for pennies on your development costs, you get support, faster development and original looks for your next Flex application.

We have a lot more planned for Flex Components, it's just the beginning.

Hey,

While I am at it before I get lost again, check these two screen shots out of my mdi pane.

Here we have a fully dragable tab pane. You can set the position of the tab bar to all positions, top, left, right, bottom. Full flow layout implemented.

You can drag a tab out and into a new window, shift tabs, or even create an new divider that holds the new tab pane with the single tab in it. More later.

Here the effect has run and all of the tabs have turned into WindowFX's! Animation and everything. It uses a proxy so the animation looks goods. Performance is greate, becasue that tab content is actually windows in disguise.

As I said, this was a tid bit since I was hooked into the blog.

Peace, Mike