Most of this actually is related to Mobile development with AIR, considering there isn’t a bunch of desktop development focus in the SDK.

Adobe released an early version of Flex 4.5 (Flex Her0) just before Adobe MAX last year, and tons of people grabbed it and started writing mobile apps with it.
Since then, quite a bit has changed both in common functionality, and under-the-hood things like List scrolling.

I couldn’t find any clear documentation about migrating your applications, so I figured I’d try to throw together as much information as I could think of.

I will be updating this frequently as I find more changes or caveats while converting my apps, or from what I hear from others.

Quick Map

So before I start, I’m going to try and attempt doing a quick mapping of some classes you might have used in 4.5 MAX Preview, and what their current counterparts are:

Preview Current
MobileApplication ViewNavigatorApplication
TabbedMobileApplication TabbedViewNavigatorApplication
MobileItemRenderer LabelItemRenderer
MobileIconItemRenderer IconItemRenderer
Label (non HTML) StyleableTextField
RichText (needing HTML) StyleableTextField

Some Different Approaches

There’s also a few different approaches we must take when developing for 4.5 final, which I’ll try to cover as much as I know.

Back in the 3.x and 4.0 days, we’d typically do camel case definitions of styles in metadata, and when accessing via setStyle() or getStyle(). However, in a stylesheet, we’d define the properties as hyphenated values, and not camel case. For me personally, this was irritating, frustrating, and downright weird. Worry no more! This has been changed! In CSS in Flex 4.5 we now should ALWAYS use camel case, all around.

The View class is what we use for components handled by ViewNavigator. Before, these extended Group, but now they extend SkinnableComponent.
This means a few things:

  • You can easily skin Views, just as you would a custom component.
  • There isn’t a layout by default since it’s expected to be skinned (this is typical of SkinnableComponent implementations).
  • In the 4.5 final, the defaults.css for the Mobile Theme applies a white background.

This part is a tad fuzzy for me, as I didn’t get into skinning a whole bunch early on. The gist is there’s a few methods added to the component lifecycle that abstract implementation a tad bit further, in order to make compounded components (ones that build on another) simpler to implement.
Quickly referencing, there’s only a select few to worry about:

  • layoutContents(unscaledWidth, unscaledHeight) – An isolated method to merely layout the contents of your component. Simple enough!
  • drawBackground(unscaledWidth, unscaledHeight) – Again, a basic method merely targeted at drawing the background. No default implementation!
  • setElementPosition(element, x, y) – In the early days it was positionPart(); clearly a more common naming convention with setElement*. This handles ILayoutElement, IFlexDisplayObject, and lazy DisplayObject implementations.
  • setElementSize(element, w, h) – Should be self explanatory now, former method was resizePart().
  • commitCurrentState() – When a skin’s state is updated, it will immediately call this method; apply any visual changes in this method based on the state.

Some interesting methods to take a look at:

  • applyColorTransform(displayObject, originalColor, tintColor) – In order to quickly “theme” your components, you can utilize this method to do a color transform for you. This is akin to the themeColor or chromColor styles.
  • hasState(stateName) – By default, MobileSkin always returns true, as there isn’t a state listing like in SparkSkins. If you want to throw an error to a developer, override and return false for states you know you don’t implement. Typically this is only useful for when you extend a skin and want to avoid handling a state.

I’m hoping it has been beaten into your skull already, but you should be writing your skins in PURE AS3… I’ll be honest, I break this rule too, but haven’t compared with a pure AS3 implementation to know if the performance is really as much as they say it is. Maybe that’ll be my next experiment 😉

Backwards compatibility:


Some Tricks

Here’s a few tricks I’ve found while trying to migrate my application:

  • There is no quick way to fix the CSS to go from hyphenated to camel case. I’m considering writing a quick javascript or Flex app to handle this for me. I just spent like 30 minutes going through ALL my CSS, and it wasn’t fun!
    • Use REGEX search to help identify items needing change quicker: \-.?
    • Be sure to limit searches to “Enclosing Projects,” and limit file types to *.css for faster and more accurate searching!
  • Views now  have a backgroundColor of #FFFFFF applied to them. I was expecting to see my application background, so I had to set backgroundAlpha to 0.
  • ActionBar components are given an ID. Because of this, CSS must be applied slightly different than desired/expected:
    • ActionBar #titleDisplay – set fontSize for header here. Setting on ActionBar is futile!
    • ActionBar Group#navigationGroup Button
      • ActionBar Group#navigationGroup Button.myStyle – for a unique style for a button
    • ActionBar Group#actionGroup Button

External Links: