Category: Flex

I always make these more complicated than they need to be, but it’s so much fun, I can’t help it. Regardless, here is an example of 2 login forms built in Flex 2. One uses simple states to represent the main, logging in, and error states that a typical login form can show. The second one does the exact same thing, based on almost the exact some code, but has the addition of transitions. Where “states” are changes to the component when it is a different circumstance, “transitions” are changes between those states. A Flex component that has states, but no transitions immediately changes from one state to the next visually. If you add transitions, you have control over how a state changes from one to the next.

Both examples below are simple. If you click submit, it’ll disable the fields, and then go to an error state. After 2 seconds, it’ll reset. If you fill in something for the username and password fields, it’ll go to a success state instead of an error state instead. The top one uses state tags inside an MXML component. The bottom does the same with the addition of transition tags to animate between those states.

As mentioned, the code base is exactly the same with 3 modifications between Login.mxml, and Login2.mxml.

1. I removed the setting of the border color to red from the error state tag, and put it in the transition instead since I wanted timing control of when it turned red.
2. The logging in state in Login2.mxml adds a SWFLoader that loads an animation.
3. The Login2.mxml doesn’t reset itself 2 seconds after the error state is shown. Instead, I have the ending of the transition call a function to do it instead. This gives the transition enough time to finish before a new state is shown.

We had to use ViewStacks or destroy & create this stuff manually, with no DisplayList mind you, in Flex 1/1.5. The ability to have the same component represent its state declaratively as well as have control over how those states change is awesome! In an ideal world, you can comment out the transition tags, and the component will still work just fine; it’ll just have abrupt changes. To me, if you get a proper designer / information architect involved, the experience in having appropriate transitions to guide the users attention vs. abrupt GUI changes without them is night and day.

Why blur things out? Degrade importance, and allow the depth of field effect to allow the user to focus on the most forefront content.

Why show loading animations? To build the user’s confidence that the application is “doing something” vs. appearing broken.

There are various proven tested techniques you can implement, none of which I probably show correctly.

Login Form State & Transitions Example – View Source | ZIP

Being anonymous is l@m3. Besides, cflex.net is getting hammered. lol, 404!

1. At what stage of technology selection does Flex play in your immediate team?

– Fully committed

2. How long have you been using Flex?

– 2 years+

3. What would you consider your expertise level?

– Advanced

4. Outside of Flex, what have been and continue to be your primary technologies?

– PHP
– Flash

5. Do you use the Flex Data Services (FDS) product?

– No

6. When it comes to Flex, what did you used to struggle with, that you no longer have problems with?

– Dynamic layout. Using declaritive layout in Flex with it’s built-in LayoutManager saves me oodles of time when doing GUI’s. CSS inheritance helps too.

7. When it comes to Flex, what are you currently struggling with, or wish were improved, made better, had more of, etc…

– Integration of Flash designs.

8. How many years have you been programming in general?

– 6-10 years

9. How many developers are in your immediate team?

– n/a – unemployed (if I was, 1-5)

10. How many employees are at your company?

– n/a – (if I was employed 101-150)

11. Has Flex been adopted by your entire company/top level business unit as a primary technology?

– Yes

12. What prevents your company from taking things further with Flex?

– Nothing, we’re 100% Flex or bust!

Gent pinged me on AIM.

“How do I get a ComboBox prompt?”

“Use the ComboBox prompt property.”

“Yeah, but it leaves once you select an item.”

“Put the prompt as the first item in the dataProvider.”

“Can’t do that for this context.”

“Make a custom list that has a prompt above it, and replace ComboBox’ dropdown with your new list.”

“I can’t, I’m about to go pimpin’ on a Friday night, and your not, so code it, sucka!”

“Pssff, you wish you had this grill. Fine…”

So, I attempted to do so in 2 hours, and gave up. Here are my results. Basically, you put a Label above the List. You then extend ComboBox to override the drop down factory so it uses your List instead. The only uncool part is you have to extend ListBase; kind of frustrating when I’m implementing all those interfaces, only to be forced into an inheritance tree… bleh! Extending ComboBox is a pain in the neck because everything is private; frustrating. Anyway, definitely not production code, but should get you started.

After talking to her majesty, there is actually a usability issue with drop downs on web pages in that, once you select an item, you can no longer “de-select” an item by selecting the prompt again if one doesn’t exist. Therefore, I stick to my original suggestion; throw the prompt item in the dataProvider instead.

Permanent ComboBox Prompt – View Source | ZIP

I had 2 days with the help of another developer to re-skin an existing Flex 2 app recently. It was nice to put a lot of my Flex 2 CSS practices to the test. What worked, and what didn’t?

What Didn’t

It was really hard to get multiple developers working on re-skinning. Every time I’d find a task, I could do it faster in the time it’d take me to articulate the requirements and/or send an email. Furthermore, most of the styles & image skins were defined in the CSS. While I do pride myself on having a pimp diff tool, it’s still a pain in the neck to “discuss” the CSS style changes with another developer during the diffing. I had a non-negotiable 2 day deadline. The last thing I want to do is discuss the theory behind borderStyle: solid over IM when I could be working.

Styles that were custom, such as .musicPlayerTitle, weren’t always that specific. Sometimes, title specific styles (stuff for text) were re-used by things that had nothing to do with a music player. While it’s nice to have re-use, this was confusing, and sometimes editing a style would adversely affect something you had no clue on; aka, spaghetti code, meet spaghetti styles. The real code wasn’t spaghetti styles; we quickly fixed the 2 I found.

Not everything was done in CSS. This was the worst offender, and I didn’t have time to clean it up. Thankfully, I was sequestered in my own branch of CVS, so no one (except my trusty co-worker) could see the nastiness. There were just a few, but enough to tick me off. Some controls had styles applied on their controls. Some had images in line in code that should of been put in the CSS. So, instead of re-skinning, I spent some time re-factoring & basically cleaning up stuff to at least be remotely consistent. My guess is, these were done to solve layout problems, and later weren’t ported to CSS. One in particular I created, which means I was lazy, and didn’t re-factor it into styles. Oops, I’m fired.

No control styles. The main thing I espouse is to style the component class vs. making a style, and applying it to an instance. While there were a few MX components done this way, there were no custom written components done this way. Therefore, I had to hunt down the View in question, where it was used, and find the style name, then go back to the CSS to change it. Pain in the neck.

Design View. Still worthless. Good to “dig down” to the control I need via double-clicking, but useless as a designer via styling/skinning.

What Did

There was a lot of CSS. This bode well, meaning the original developers (me included for part of it), had pretty much adopted the standard of all styling information goes in CSS. Except for 3 minor controls/screens, this went well. I could pretty much ensure the separate CSS file I created (a copy of the original) could remain as the top left tab in Eclipse all day as I changed styles.

Most styles did stay true to their name. Even if both used the same 4 styles with the exact same values, they still were applicable to their control. While the CSS became really big because of this, it couldn’t be helped frankly because the design didn’t really have a lot of UI re-use. Consistent naming went far in making this a straight forward process to update. There is no point in creating a custom, re-usable control if you are only going to re-use it once. Instead, we just had a lot of styles applied to the same MX List control. Designer’s fault, not ours.

A side benefit of having custom styles was that, on the 2nd day, I was able to start getting help from another developer. There were a lot of dialogues that a lot were styled via CSS. Since those styles were custom, it wasn’t that painful to merge since they were way at the bottom of the CSS file. We just announced it over IM, and I’d spent 2 minutes updating and merging.

Conclusions

I have a new respect for custom styles. I used to bash them, but now understand if the designer doesn’t give you a design that makes good use of re-use, you have no choice and this is the best way to do things cleanly. Regardless, the lack of component skinned styles was unacceptable , and I added a few. Flex 2 does a good job with a style inheritance, so you can be sure anything you use in your component will adopt the main styles. In the end, this greatly reduces the size of your CSS file, allows you to make application wide style / skin changes from just one file quickly, and allows those not familiar with Flex GUI to change the CSS.

Definitions

Override style:

Application
{
        color: 0x333333;
        background-color: 0xFFFFFF;
}

Component style:

MyComponent
{
        text-decoration: underline;
        color: 0x0000FF;
}

Custom style:

.mainLabel
{
        font-weight: "bold";
        font-family: "Verdana";
        font-size: 16px;
}