2 Day Flex Re-skin

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;
}

2 Replies to “2 Day Flex Re-skin”

  1. Right on Jesse! I talked a bit about the Style inheritence orders during my MAX sessions. They sure make applying app, section, or instance styles a lot easier once you get the hang of them

    – Inline (eg: setStyle() method)
    – Class selector (styleName property)
    – Type selector
    – Parent chain/container
    – global selector

Comments are closed.