Flex 4 SDK released {Gumbo to follow}

So flex 4 is out as an alpha release and promises better developer-designer workflow. Gumbo, or Flex builder 4 will be available shortly {read more on whats new in Gumbo}.

According to Matt Chotin this will be achieved through the use of a design tool called “Thermo”, better known as flash catalyst (on adobe wiki) which would allow the designer to “design” the interface graphics and layout using their favourite graphics editor such as Photoshop or Illustrator and import the graphics into catalyst which would then be used to prepare components from the design. Basic interactivity and component definitions can be added by the designer. Furthermore, the SDK also promises better integration of bitmap resources within the application. So that completes 2 stages of the process UI design and Interaction.

The catalyst data is sent over to the developer who can embed business logic into the interactions. Now this requires the use of additional components which are exposed in Flex 4. Sound exciting? Its a mixed feeling in my case. Skinning applications will be a lot easier for one. But from an architecture perspective, this could mean a nightmare, seeing the way Flex Builder 3 auto generates code.

For those of you trying to work on I18N enabled apps, don’t despair because the RTL text issue has been addressed in this release. However, this is only applicable to apps running Flex 4 on Flashplayer 10.

There seems to be a lot of stress on graphic and designer-developer productivity but Adobe seems to be missing out the core theme which is to work on a simplified micro-architecture for better code management and scalability. In my opinion, this shold have been top priority, now that Flex is making its way into large scale RIA’s.

Links for more info:

• Flash catalyst
• Flashplayer 10
• Flex 4 SDK
• Ryan Stewart interview with Matt Chotin about Flex 4
• Flex 4 documentation

SWFLoader quirks

Two issues regarding the SWFLoader / Image component are highlighted here. One of which has already been floating around forums with no concrete solution.

1. Image resizing: While resizing images in both components if the iamge size is too large to be accomodated in the conrtol’s display area and scaleContent is enabled, using horizontalAlign and verticalAlign properties displace the image from its expected location. Workaround/hack: check the contentWidth / contentHeight after loading the image through code. You’re out of luck if you’re trying to do this through MXML alone.

2. No control over audio: After unloading a swf with embedded video the audio channel continues playing. Using flash.media.SoundMixer.stopAll() might do the trick but only if the loader and the loaded swf belong ot the same security sandbox. For a swf loaded from filesystem loading a remote swf, it fails miserably. Thanks to no control over the loaded content when using the SWFLoaded and Image components there’s little that can be done to avoid this. Workaround/hack: use a Loader object to load the swf if you’re willing to give up the ease of component usage. Not sure as to whether it completely resolves the problem. Adobe is still silent about it … I’m off to look for a registered bug report.

HTML <img> Bug confirmed in mx:Text component

Just in case you haven’t read my initial post where I unearthed a “quirk” in the mx:Text component in flex, have a look at this post. Adobe’s dev team has confirmed the bug and have been able to successfully reproduce it as well. For a glimpse into what goes wrong have a look at the following image.

Updates on this issue are available here.

Well atleast now you won’t have to fret about it until Adobe comes up with a solution.

I did come across a more complete component for HTML display within flex by Drumbeat Insight. Unfortunatly the component is no longer free, and the $149 proce tag may put any developer off unless you can get your organization to pay for it.