I’m happy to announce that Teoti Graphix, LLC will be offering spark framework navigators. Through the over 5 years of flex component development, this widget set was the most fun to create (to this point).

As a component developer since the beginning of flex, I have always found it hard to create rich components due to the fact the component’s view was always coupled to the component controller (the component class). With the Spark framework, all this has changed and the horizons are limitless.

Component development pattern

There is a consistent pattern you will see in all of our component releases.

• All front facing classes IE TabNavigator will include the default skin in it’s Type style declaration. This means if you don’t want it linked, subclass the TabNavigatorBase and implement your own default component. Note: In the future we may change this to default theme SWCs but for now this is how it works
• All components follow the base class -> MXML pattern that Adobe has set. After creating a lot of Spark components, I find this very legitimate.
• All components have a core Skin, most of our more multi-placement composite holding component’s implement a default LayoutBase skin layout.
• All component skins are simplified. This means some use of abstractions regarding border and state borders. For those designers that use tools to create skins, this will not affect you, just create another version of the skin implementing the SkinParts and do your fxg or layered skin graphic elements.
• Since we offer commercial components that will be used by many levels of developers, styles will be part of the components that will offer dynamic presentation whenever possible.
• Last but not least, anything that can be a skin or renderer is.

The Navigator Widget Toolkit

The navigator toolkit includes;

Components

• ViewStack
• TabNavigator
• TabBar
• TabButton
• Accordion, AccordionHeader
• SimpleBar
• SimpleTitleBar

Skins

• ViewStackSkin
• TabNavigatorSkin
• TabBarSkin, TabTopSkin, TabBottomSkin, TabLeftSkin, TabRightSkin
• AccordionSkin, AccordionHeaderSkin
• SimpleBorderSkin

Layouts

• ViewStackLayout
• TabNavigatorSkinLayout
• HorizontalButtonBarLayout
• VerticalButtonBarLayout
• AccordionSkinLayout
• AccordionSkinLayoutAnimated

VeiwStack

The ViewStack can be hooked up to any ISelectableList implementation such as the spark ButtonBar.

Along with this easy plugin functionality, a simple rotated ButtonBar works in a normal layout also.

The ViewStack also comes with the additional functionality of;

• selectedIndex
• selectedChild which must implement INavigatorContent
• resizeToContent works just like the Halo navigator’s, the navigator is resized when the selectedIndex changes

TabNavigator

The TabNavigator inherits all the ViewStack functionality and adds a TabBar.

The TabNavigator also come with the additional functionality of;

• tabBarPlacement (top, right, bottom and left)
• tabClosePolicy; default close button implementation in the TabButton (on,off,rollover,selected,disabled);
• A CHANGING event that is cancelable with selectedIndex is set
• Drag and Drop support out of the box (rearrange tabs or drag into another navigator)

The image below shows the top tabBar placement.

The image below shows the right tabBar placement.

The image below shows the bottom tabBar placement.

The image below shows the left tabBar placement.

The image below shows the closePolicy of disabled.

There is so much more to talk about this component but I will save that for later.

Also note, with all tabBar placements, additional configurations include tabOffset, tabBar vertical and horizontal align and corner radii.

Accordion

The Accordion works just like the Halo version. Main differences include;

• Instead of reimplementing the ViewStack class like the Halo Accordion, this component subclasses ViewStackBase.
• The Accordion offers the direction property to allow for vertical and horizontal layout states.
• Inherits all ISelectableList functionality from the ViewStackBase class.
• Is completely skinnable.
• All aspects of layout are swappable.
• The AccordionHeader skin is direction aware, this means you can swap out any header and base it’s presentation of the current direction of the Accordion.

The image below shows the vertical layout direction.

The image below shows the horizontal layout direction.

Conclusion

This is a very fun time for flex component development and our company is here to save you development time and money!

This set is scheduled for release just prior to Flex 4’s official release.

Version 1.0 limitations;

• History management is not enabled.
• Deferred instantiation is not enabled. (this has to do with SkinnableContainer, we are working on it)
• The Accordion animated layout is still beta.

Thanks,

Mike

After doing some more research, it is apparent there is a split in this new approach to skinning in Flex 4 Spark.

• Companies have designers that use tools to create a full MXML (flat) tree that implements a Component’s skin part API.
• Companies have designers give assets such as images and behaviors to developers, developers touch the code, not designers.

With this split it is easy to see why some devs like the Spark skinning implementation and others are having a hard time with the copy and paste.

I am in no way saying the copy and paste is wrong, against OOP or whatever other reason. I’m saying that this new skin implementation depends on tools. I guess this is the changing of tides and more editing programs getting into the mix.

Alternatives

This one I have been racking my brain on for a while; Anything a component developer that sells encapsulated pieces of behavior(components) creates, the component needs to work in a design view tool. Else we are marketing our components to a seemingly diminishing breed of company, the developer controls the code company. Another example of this is someone tweaking the MXML in a code editor.

What this means is, the alternatives shrink in value due to the fact anything that I could come up with is dynamic, which means it is not “flat” like an MXML skin, thus a designer has no access to.

Matt Chotin put it frankly in a blog comment; Halo failed because designers could not tweak the skins (ProgrammaticSkin) in the design view of a tool.

What does this mean?

Essentially, a component developer cannot create a BorderSkin that is a subclass of a Group (implementing a subset of border and background styles) that can then be reused in an actual Skin subclass. If you define styles that could be plugged into the composite BorderSkin, a tool like catalyst cannot read and display the composite border correctly. Plus with Flash Builder’s design view, forget it.

To make matters worse, how would you allow the designer to “apply” the styles you defined for the composite BorderSkin in their implementation of the parent Skin class?

Conclusion of Take 1

For me, it’s easy to create tight component API’s that allow a greater abstraction of widgets application developers use in their code everyday. We have had hundreds of happy customers with our past Flex2/3 line of components.

The new challenge for my company is realizing the need of the current motivations.

It’s hard for a component developer that sees abstractions in a component such as the spark.components.Panel to take it, slice and dice it to more of a composite approach (titlebar, content, statusbar). Make available a TitleBar and StatusBar component, when the Panel exemplifies what Adobe wants designers to get their hands on, one big chunk of view code in a tree, in the same file.

It’s easy to take and build sub components, skin them and make them work. The problem I am finding is how to I get the TitleContainer that holds these sub components to play nice with design tools.

Mike

Comments are appreciated.

Time to start writing about components again. For those who have not had much experience with the older Halo component framework, Spark may not seem alien since it’s what you stepped up to. Coming from 5 years of flex component development, the Spark component framework is creating a lot of garbage regarding skins.

This whole copy and paste skin thing has got to stop! Well, maybe not stop but needs alternatives, and that is where a component developer comes in. Our new products coming for Flex 4 target this very issue and many more.

Maybe you are a developer coming from Halo and liked some of it’s more simple style apis to get things done quickly. Maybe you just want a choice to do it one way or another and not always have to right click and select “Copy new skin“.

Whatever the case may be, stay tuned, the Window Widget Tool Kit is our first offering coming soon and I’ll start talking about it’s benefits.

Mike

If there are those of you who have followed me since 2005-2006 and Flex, you know that I was a major contributor to the Flex community. Let’s say I have the top 10 all time poster position on flexcoders.

Image source; Doug McCune – Data Visualization Engineer

This year feels a bit like 2006, new things around the corner and much to talk about. I’m getting back into the community and want dialog with friends and colleagues.

We will deliver some fantastic frameworks this year as the Spark framework really has opened up a lot of play room for component developers. I also welcome competition, since that is what purifies the waters.

We have almost 4 years of blog archives that we need to transfer to this blog, which is going to happen soon.

Other than that, have a great 2010.

Mike