Flex a Spoon, Flash some AIR, and stick around for a while

Hoyt’s last Chicago Flex preso and Labriola’s SpoonProject

Kevin Hoyt and Michael Labriola both were the guest speakers at our CFUG meetup (www.chicagoflex.org).  The great news is that this was the first time either of them had spoken together in the same room at the same time.  The sad news is, this will be the last time both of them will be together at CFUG to ever talk about Flex again.

If you are interested in watching the near 2-hour discussion, please go here: https://experts.adobeconnect.com/_a204547676/p7xqmnpakcd/?launcher=false&fcsContent=true&pbMode=normal

Otherwise:

First off, I want to discuss a few things that I feel will help clarify where I am coming from.  Often times I have discussions with multiple clients about what Flash is, how Flex fits in, and we can accomplish with AIR.  For this post (which is long – way too long perhaps, but long enough to see the point), I am going to just quickly reference and review, then I will discuss: Adobe’s PR (the reason for this meetup and me asking Michael and Kevin to come and talk); Adobe’s strengths, position, and vision for the future; The Spoon Project; Spoons opportunities and dilemmas; and my own 2 cents.

What is Flash?

Plain-speak: A plugin.  Want more information, check here: http://en.wikipedia.org/wiki/Flashplayer.  It is Adobe’s bread and butter when it comes to content management regarding video and video games.  More on that later.  For now, know that it is a highly evolved virtual machine (VM) that can execute code (AS3) for a rich and interactive experience.

What is Flex?

Plain-speak: A framework built on top of Actionscript 3.  It is a powerful tool for building applications, especially enterprise apps.  It has a terrific life cycle, amazing APIs, and is several years ahead of any other technology for delivering secure, robust, and data-driven applications

What is AIR?

Plain-speak: A desktop version of the web browser version of the flashplayer.  It has some much cooler APIs than the standard flashplayer, and because it isn’t sandboxed by the browser, you get a few other neat things.  Still, it’s mainly a desktop version of the browser version.

So?

Adobe’s PR (fubarred, snafu, or intended)

Adobe is great at one thing, making tools for creative people to create things.  In my experience as a developer, consultant, analyst, and everything else, I’ve learned that when it comes to businesses and software development, you get one of two things: an agency approach, or an enterprise approach.

As a quick definition, and agency approach is the short term.  These are products that don’t have much shelf life, are short lived in the wild, and even if they win an award will fade into obscurity soon.  The enterprise approach is the opposite.  While enterprise apps are notoriously slow to come to fruition, they last (what seems) forever.  Normally they are a 5-10 year package that sells for a large amount, and comes with upgrades, new features, and snazzy options as the life of the product wears on.

In the world of Adobe, Adobe has no clue how to deal with the enterprise.  They can only see one thing, and that is the bleeding edge.  As a four-plus billion dollar ($4,000,000,000+) a year company, Adobe makes most of it’s money on creative tools.  This means Creative Suite, Photoshop, and a few other choice applications is where Adobe makes its money.  It does it by selling tools, or packages of tools, to companies and users.  Since the inception of Flex, Adobe has never really figured out how to make money off of it.  Flex uses the flashplayer and AIR, but AIR and the flashplayer don’t need Flex.  In fact, one of the biggest complaints of Flex is the bloat it brings with its myriad libraries, download times can be severely impacted. Not to mention the speed of an application because it is using the Flex messaging framework.  These have been, and will be, hotly contested for some time to come. 

Regardless, Adobe never made (“real”) money by creating the framework.  It did make some money by consulting on projects, but the 25+ team members it has allocated to the sdk never generated revenue (unlike the large group of folks who work on Photoshop or AfterEffects, whose products do make money).  Flashbuilder does generate some revenue, but not at the same volume as the other products.  Adobe looks to start projects that can generate at least a hundred million dollars ($100,000,000) a year, and Flex never even came close.  Sure it might be a multi-million dollar venture, but is that worth the resources when those resources could be dedicated to a larger project and make more money somewhere else?  Adobe says, “Nope.”

So Adobe made the bold move and told the world it is no longer interested in developing Flash for mobile (completely unrelated to Flex), and making Flex completely open source, giving it, and its support to the Apache Foundation (http://blogs.adobe.com/flex/2011/11/your-questions-about-flex.html).  Make no mistake about it, Adobe will support the flash player, especially for the desktop, and it WILL support AIR.  AIR makes the flashplayer available everywhere that isn’t a browser, so video content and games have a way to live on.  And Adobe keeps its cash cow.

And don’t worry, Flex isn’t going anywhere too quickly, but we’ll get there in a bit.

The message from Adobe is messy, sloppy, poorly handled, but think of it like teenage angst, where the person has lost control of their emotions, and finally just said, “Enough! Enough! We can’t have it our way, we don’t want it any way!”  Adobe has not been able to capitalize on innovations that are not tools “creative” people need. 

Adobe’s position (including Natobi/PhoneGap)

So what does Adobe want to do going forward?  For starters, they have their Interactive Developer Evangelist team spearheading a PR campaign to tell all developers that HTML is the future.  Their message has become pretty consistent, with their twitter feeds basically dropping any mention of Flex.  They seem to ignore everything Flex, and stick with the standards of the future.  Let’s not get caught u p in rhetoric. Adobe is not interested in maintaining Flex any longer than it has to.  Flex is a dead weight to the hipster, creative, entrepreneurial type.  And Adobe cannot wait to release itself from that death grip.  To prove that it is over Flex, it bought Natobi, Typekit (http://blog.typekit.com/2011/10/03/adobe-acquires-typekit/), Efficient Frontier (), and a few other online real estate properties, pointing towards a desire to enter and again dominate the tool making process for online advertising (because the flashplayer hasn’t been there for the last decade).  From the 8/18/11 anouncement, Adobe is building up to be the leader of “…Content Authoring and Digital Marketing.” 

Enterprise applications are not either of those.

Adobe bought Natobi because Natobi created PhoneGap.  PhoneGap is a software application that essentially turns any application you create into an HTML5/JS/CSS application, wraps it in a pseudo-browser, and deploys like a native app.  So, for example, on iOS this is a standalone instance of Safari running on your device, and it appears to be a standalone, native app, but you are only seeing Safari rendering web pages that are considered the app.  The library works quite well, and for all intents and purposes, it acts just as good as a native application.  Adobe supports it and suggests you use it as well.  For them, this is the bleeding edge of technology, pushing mobile application development.

There is no Spoon?

During the 2011 Flex|360 conference in Denver, it was announced that the Spoon Project was taking off.  If you don’t know what Spoon is, read here: http://www.spoon.as/

Short take – it’s meant to help the Flex development team fix bugs faster.  It’s got an architecture of people and processes to resolve conflicts and promote fixes faster than Adobe’s Jira and engineers could handle. Spoon has PR, it has volunteers, it has a lot!

Spoon’s dilemma

It might actually conflict with the Apache Software Foundation (ASF).  This is not detailed out yet, and Spoon, Adobe, and ASF have some work to do to hammer out the details.  There are a lot of license agreements, IP rights, and whatever else a lawyer wants to earn fees to help disentangle Adobe from the Flex framework.  Spoon might be a problem only because it is a separate entity ready to run and fix problems, and Adobe is saying, “Actually, let’s let the big boys handle this.  We’re gonna give it to ASF, and see that they take good care.”  Nothing is set in stone yet, and Spoon may or may not be involved.  That is to be determined.

Future

If there’s anything that is certain right now, the Flash player and AIR are going to continuously be improved upon, upgraded, and pushed out to be as ubiquitous, easy to use, easy to get, and easy to update.  Adobe has a lot at stake to make sure these tools remain potent sources of DRM content providers, and will keep them up to date.  But Adobe also wants users to buy their products if they are making cutting edge products.  The amazing thing about HTML advertising is that you can’t disable it without disabling your browser.  With Flash, there were plugin disablers galore that allow users the ability to block any flash-related medium trying to load on your computer.  However, now with the advent of video and canvas in HTML5, unless you disable javascript on your browser, you can’t stop the ads from coming.  It is a marketers wet dream to know that’s where we’re going.  And guess what, Adobe is looking to blaze the trail by providing you with the latest and greatest tools to make them.  Adobe is not promising Apps, they are promising rich web pages, rich ads, rich user experiences.  It is cutting edge, but not anything with a long tail.  Flex is a long-tailed beast.

And just for a quick summation, here's Peter Elst's post about the exact same subject:

http://www.peterelst.com/blog/2011/12/13/flex-summit-updates-on-the-open-source-strategy-and-runtimes/

The Flex Summit has had some interesting notes and should help provide information about the future of this industry!

Balanced decision on the future of Flex

Essentially, Adobe has come to the realization that the world does not
want plug-ins on mobile devices.  Unfortunately Adobe has done a
terrible job communicating what their intention is, and the initial
feeling many Flash/Flex users and developers had bordered on
pandemonium.  But this announcement is actually great news.  Adobe did
a poor PR job, so here's a post that really clarifies the good from
the bad: http://david.realeyes.com/?p=214.  And Adobe about their
strategy: http://www.adobe.com/devnet/flashplatform/articles/recent-updates.html

These are long posts, so if you don't have time, here's my summary:

First and foremost, Flash was never really viable on mobile devices.
The actual Flash player has always been clunky, resource intensive,
and just buggy on mobile.  It was created for a world of users that
had a mouse and could interact with the screen via a cursor.  On
mobile devices this is different, and the rules of
human-computer-interaction have changed.  That said, Adobe won't put
resources into something that isn't meant for mobile.

Second, Adobe is finally giving us (developers) the ability to fix
Flex faster than Adobe could.  Since Flex 1.0, Adobe has controlled
the entire update and release process of Flex, often times ignoring
blatant problems and publishing updates with a strange sense of
priority.  As an open source technology, the community of developers
gets to enhance it, much like Sun made Java open source, and aids
development, but doesn't control where it goes.  The community gets to
enhance a mature technology and improve on it, with resources from
Adobe and the rest of the world.  Adobe is finally making good on its
original promise from years ago to make Flex truly open source.

Third, the Flash player for the desktop will continue development
because it is viable, extremely robust, ubiquitous, and provides a
uniform experience regardless of which platform you are on.

Fourth, for mobile development, Adobe stands behind AIR and the
continued improvement and development of this tool.

I am not urging anyone to simply take the path of one technology over
another.  HTML5 is definitely here to stay, but its tools, frameworks,
and community are very immature compared to the Flash platform.
Conversely, native development is expensive in time and resources, and
both paths cost a lot in regards to testing every browser on every
device and OS.

There are arguments for why companies should begin acquiring and/or
developing talent in native and web-based technologies, but these are
bets being made for a future that might pan out one direction or
another.  I think it is beneficial to all companies that have used
Flash in the past to realize that not much has changed or will change.
 Flex is an awesome enterprise development tool that can be used to
rapidly build projects.  Flash and AIR are great resources with an
excellent community.  Adobe just needed to openly realize that Flash
on a mobile device wasn't realistic, and that the community will
benefit more by having Flex be truly open sourced.

For the future of your projects, I truly believe Flex is very strong,
secure, and viable.  The wariness of Adobe's commitment is
understandable.  Regardless, Flex isn't going anywhere, and will be
here (specifically in the enterprise) for many years to come.

Dynamically loading audio from different locations in ApplicationStorageDirectory

Similar to my last post about getting data from different locations, this time, instead of trying to load images, i'm trying to load audio clips.  It took a little bit of finagling, but I finally have it.  Just a quick bit of back story, I am downloading a zip file and unzipping contents into my app storage directory in folders.  If I reference the directory, I need to adjust the file.nativePath for that.  Enough talk, here's the code:

_file.nativePath     = _file.nativePath + _audio;
                req                 = new URLRequest(_file.url);
                s                     = new Sound(req,context);

over and over I tried to just make the URLRequest be the _file.nativePath + _audio and kept getting the most awful Error #2032 Stream Error (which explains nothing and is not helpful).  Finally I came across a forum post that explained that the URLRequest needs the _file.url, otherwise it appends this app:/ to my string, which bombs out.  So i can adjust the nativepath, and then use the url.  ta-da!!!

Loading images from applicationStorageDirectory in Flex Mobile

I have to say, without a doubt, this was one of the most confounding things I've worked on in a long, long, long time. In a project for my client, I have to be able to store zip files filled w/ media assets, then be able to load audio or pictures at runtime.

 Sounds easy, right? Wrong :(

 Loading a picture has never been this painful in my life. It turns out, I can add the image to the stage (which for some reason is not respecting my skin, contentgroup, or vertical layout settings). Regardless, I can finally load any stored image via this "not-so" simple routine.  One caveat I have is, I am downloading images in zip format, and using a utility to unpackage them into the storage directory in folders.  originally I though that would be a problem, but it turns out, because I can update the file.nativePath with the new folder, this works just fine.

var fl:File = File.applicationStorageDirectory;

fl.nativePath = fl.nativePath + _image;

var bytes:ByteArray = new ByteArray();

var filestream:FileStream = new FileStream();

try{

filestream.open(fl, FileMode.READ);

filestream.readBytes(bytes, 0, filestream.bytesAvailable);

filestream.close();

loader = new Loader();

loader.contentLoaderInfo.addEventListener(Event.COMPLETE, showPic);

loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, onError);

loader.loadBytes(bytes);

}catch (e){

trace("xml badly formed");

}

and in my showPic method:

loader.contentLoaderInfo.removeEventListener(Event.COMPLETE, showPic);

var bitmapData:BitmapData = new BitmapData(loader.content.width,loader.content.height, true, 0x000000);

bitmapData.draw(loader.content, new Matrix(),null,null,null,true);

img.source = new Bitmap(bitmapData);

Honestly, painful, but it gets the job done.  Now to load audio dynamically from saved files is another story for another post:)

Datefields before Flex 4.5

So I wanted to take advantage of the custom skinning I had already done for a datechooser, and apply that to my new datefield without making a copy of all the skin classes.  Turns out, this is relatively easy, if you know what to look for.  Code below:

1. Extend datefield
2. set the dropdownFactory in the constructor to an IFactory var
3. then in css, set your custom datefielddatechooser's settings (which may be identical or different to your own datechooser custom skins)
4. and finally, in css (or wherever else you set your styles), for the extended datefield, set the dateChooserStyleName to null...i.e. ClassReference(null)

You do these steps, and you'll have your custom skins show up on the drop down of the datefield...a PITA and Flex 4.0/4.1 problem, so maybe it's no longer mx in 4.5 (but I can't find it anywhere in spark, so maybe it's still stuck in MX hell?).  Anyways, as promised, here are some code examples, if my sytnaxhighlighter doesn't eat them.

DateFieldBase.as

package com.lordB8r.view.component.controls.datefield{

import flash.events.Event;
import mx.controls.DateField;
import mx.core.ClassFactory;
import mx.core.IFactory;

public class DateFieldBase extends DateField{
private _dateChooser:IFactory = new ClassFactory(DateFieldDateChooserBase);

public function DateFieldBase(){
super();
this.dropdownFactory = _dateChooser;
}
}

DateFieldDateChooserBase.as:

package view.component.datefield.datechooser{
 import mx.controls.DateChooser;
 
 import view.component.datechooser.skins.CommonsDateChooserNextMonthSkin;
 import view.component.datechooser.skins.CommonsDateChooserPrevMonthSkin;
 import view.component.datechooser.skins.CommonsDateChooserRollOverIndicatorSkin;
 import view.component.datechooser.skins.CommonsDateChooserSelectionIndicatorSkin;
 import view.component.datechooser.skins.CommonsDateChooserTodayIndicatorSkin;
 
 [Style(name="highlightFillColors",  type="Array", arrayType="uint")]

 public class DateFieldDateChooserBase extends DateChooser{
  public function DateFieldDateChooserBase(){
   super();
   setStyle("nextMonthSkin",    nextMonthSkin);
   setStyle("prevMonthSkin",    prevMonthSkin);
   setStyle("rollOverIndicatorSkin",  rollOverIndicatorSkin);
   setStyle("selectionIndicatorSkin",  selectionIndicatorSkin);
   setStyle("todayIndicatorSkin",   todayIndicatorSkin);
  }
  
  protected function get nextMonthSkin():Class{
   return CommonsDateChooserNextMonthSkin;
  }
  protected function get prevMonthSkin():Class{
   return CommonsDateChooserPrevMonthSkin;
  }
  protected function get rollOverIndicatorSkin():Class{
   return CommonsDateChooserRollOverIndicatorSkin;
  }
  protected function get selectionIndicatorSkin():Class{
   return CommonsDateChooserSelectionIndicatorSkin;
  }
  protected function get todayIndicatorSkin():Class{
   return CommonsDateChooserTodayIndicatorSkin;
  }
 }
}

CSS:

datefield|DateFieldBase{
date-chooser-style-name: ClassReference(null);
}


datechooser|DateFieldDateChooserBase{
headerColors: #e2e6eb,  #f4f5f7; 
todayColor: #818181;
rollOverColor: #b2e1ff;
selectionColor: #7fceff;
color:   #373830;
borderColor:  #b7babc;
headerStyleName:"mydateChooserHeaderStyle";   
weekDayStyleName:"mydateChooserWeekDayStyle";   
todayStyleName:"mydateChooserTodayStyle";
}

.mydateChooserHeaderStyle {
color:         #373830;
font-weight:      bold;
}
.mydateChooserWeekDayStyle {
color:         #373830;
font-weight:      bold;
}
.mydateChooserTodayStyle {
color:         #ffffff;
fontWeight:       normal;
fontStyle:        normal;
textDecoration:      none;
border-visible:      false;
}

DateChooser

Adding Rollover/rollout halos to Flex 4 skins

So in my current project, I'm working on skinning several controls in Flex 4. One of the issues that I'm coming across is the desire to have the rollover halo effect that used to be in Flex 3. I was getting css styles from the Flex Style Explorer developed several years ago by the Adobe Consulting team.  Now, don't get me wrong, that explorer has saved me many sleepless nights. However those styles no longer apply in Flex 4.  The main reason is that some components no longer extend from button that used to normally extend from button.

ButtonBase.as is fascinating, and a great place to read up and understand the most basic principles of skinning and the skin UIComponent that is attached to the Button.  Flex 4 is wonderful, and I really, really, really enjoy the maintainability of skinning components in this framework much more than the previous framework.

Anyways, the point of this post is to quickly show you how you can take advantage of skin parts, and pre-existing components, to extend your components and get effects that you thought were lost in the transition to Flex 4.

Anyways, if you haven't seen, I think (but can't remember right now) I did a post on passing CSS styles into Flex 4 skins via custom components.  Regardless, you can easily add rollover effects to standard components with a few steps.

1. Create a new component that extends skinnableComponent

public class ComboBoxBase extends SkinnableComponent{

In that component, add a skinPart.  For more information about skin parts, see Ryan Stewarts quick blog about it here.  That got me going further

[SkinPart(required="true")]

public var cbo:ComboBox;  

Create a new skin that extends from skinnableComponent

<s:Skin xmlns:fx="http://ns.adobe.com/mxml/2009" 

xmlns:s="library://ns.adobe.com/flex/spark" 

xmlns:mx="library://ns.adobe.com/flex/mx">

<!-- host component -->

<fx:Metadata>

[HostComponent("spark.components.supportClasses.SkinnableComponent")]

</fx:Metadata>

Add the states you want (mine were hover, hoverNormal, normal)

<s:states>

<s:State name="normal"/>

<s:State name="hover"/>

<s:State name="hoverNormal"/>

</s:states>

Add to the skin the control you want to have a halo around

<s:ComboBox id="cbo" width="100%" height="100%"/>

notice that the combobox here has the exact same ID as in the component class (that is important!)

Add a rect before (or after - depending on the effect you want) with a solidStroke.

<s:Rect left="-1" right="-1" top="-1" bottom="-1" radiusX="3" > 

<s:stroke>

<s:SolidColorStroke color="0x0000ff" alpha.normal="0" alpha="1"/>

</s:stroke>

</s:Rect>

I put my rectangle afterwards, and you can specify radiusX and many other items using script or CSS.

In the custom component, override the partAdded and add some eventlisteners for mouseEvent.ROLL_OVER/ROLL_OUT. (and don't forget to remove them, otherwise some other person might get angry).

override protected function partAdded(partName:String, instance:Object):void{

super.partAdded(partName, instance);   

if(instance == cbo){

cbo.addEventListener(MouseEvent.ROLL_OUT, haloEffect);

cbo.addEventListener(MouseEvent.ROLL_OVER,  haloEffect);

}

}  

override protected function partRemoved(partName:String, instance:Object):void{

super.partRemoved(partName, instance);

if(instance == cbo){

cbo.removeEventListener(MouseEvent.ROLL_OUT,  haloEffect);

cbo.removeEventListener(MouseEvent.ROLL_OVER,  haloEffect);

}

}

In your event handler, change the skin.currentState to the new state that you setup in your skin.

protected function haloEffect(me:MouseEvent):void{

if(me.type == MouseEvent.ROLL_OVER){

//stateChanged('normal','hoverNormal',false);

this.skin.currentState = 'hoverNormal';

}

else{

//stateChanged('hoverNormal', 'normal', false);

this.skin.currentState = 'normal'

}

}

And finally, don't forget to add your skin to your component via setStyle('skinClass', skinClass):

public function ComboBoxBase(){

super();

setStyle('skinClass', skinClass);

}

protected function get skinClass():Class{

return ComboboxSkin;

}

And there you have it, a fully haloed Flex 4 component, that you dind't have to do a lot to get...if enough folks want to see the code files, I'll try to find a way to get Blogger to let me post those as well.  Hope this helps someone else

(ps - i apologize for any code syntaxHighlighting formatting problems...I've spent too much time trying to figure out how to do this right now, but if it is really causing someone headaches, please let me know, and I'll spend some more time cleaning it up.  Thanks!)

Custom skinning mx tabnavigator tabbars in Flex 4.1 (pre-4.5 mx style)

For anyone who doesn't care about my explanation and just wants code, please see the bottom of the post.

The annoying part about this post is that it probably won't matter for anyone using Flex 4.5 or later, but if you are using Flex SDK 4.0 or 4.1, this might just help you.  I've been working on skinning a tab navigator, and in the process, kept running into roadblocks, especially when I wanted the skin to respect a new state.  Long story short, skinstates in MX components were not behaving correctly, and skinning a Flex 3 component with a flex 4 mxml skin, expecting states to help me change views, wasn't working.

I tried to invalidateSkinState, but that's not a feature of Flex 3, and I tried to overwrite the Tabbar and Tab, but that become a bloody mess because of all the needed inheritance.  The best answer to solve the riddle came here from Ivan Latysh, who succinctly says, "doc's are lying".  Hellz yes they are.  The docs only tell me to use the css (it doesn't mention that the framework actually comes with two).  The biggest problem I was having was just getting the skinning rectangles to respect their selected/non-selected states.  They wouldn't.  The couldn't. because when I traced down to it, tab navigator doesn't fire off a StateChangeEvent for anything other than "up" (*disclaimer: myriad reasons might be at fault, including my own customizations of my setup, but for sake of argument, I couldn't skin a tabbar as part of a tabnavigator [separate components wouldn't work because by the time I was brought in on the project, the logic was heavily embedded for the tab navigator]).

Because I can't have the tabnavigator separated, I needed to figure out how to skin it appropriately to recognize the events and the actions.  Justin, aka Saturnboy has an amazing post on pushing component events into skins here.  So did WebDevGirl and James Whitakker.  And this stackoverflow post helped, but still, I still find the right info.  The tabbar refused to accept anything for mouse over events, and the only thing I could eventually figure out was that the component wasn't applying state events to the tabbar.

If this is the case, then it's a bug in 4.1.

But here's my solution, because I wanted to set everything in my library to respect the classes, and then styles could be overwritten in later CSS files (this tabnavigator was actually part of my core library, and I needed it to have the default skins to be adjusted by later users.

up-skin: ClassReference("lordB8r.view.component.navigableContainer.skin.CustomTabNavigatorSkin");

over-skin: ClassReference("lordB8r.view.component.navigableContainer.skin.CustomTabNavigatorSkin");

down-skin: ClassReference("lordB8r.view.component.navigableContainer.skin.CustomTabNavigatorSkin");

selected-over-skin: ClassReference("lordB8r.view.component.navigableContainer.skin.CustomTabNavigatorSkinSelectedTab");

selected-down-skin: ClassReference("lordB8r.view.component.navigableContainer.skin.CustomTabNavigatorSkinSelectedTab");

selected-up-skin:   ClassReference("lordB8r.view.component.navigableContainer.skin.CustomTabNavigatorSkinSelectedTab");

However, if I want the original skins from the mx component, and have those skins and their faculties recognized, use this to override the default skins that I was trying to set styles to:

skin: ClassReference("mx.skins.halo.TabSkin");

border-skin: ClassReference("mx.skins.halo.HaloBorder");

border-side: "left, top, bottom";

The main purpose of this blog post is to point out that even though the styling that I wanted to use in Flex 4.1 on an MX component should have allowed me to create a custom skin (albeit in AS3 or MXML), and apply to the class, I couldn't do it because the component was reverting everything back to 1 class and not passing state events into the component (the only event I could capture was "UP", which was not very helpful.

Anyways, I do believe the tabnavigator is now a Spark component, and this headhache should evaporate with Flex 4.5, however, if you are stuck on a 4.0 or 4.1 project, and need to apply skins to the tabbar, this should at least show you that the skins themselves aren't very good for listening for events, so either override them completely, or use the original skin, and use original stylings for mx components (and just override in the css - apparently doing so at the component creation point doesn't seem to help ;p )