This should be easy but somehow isn’t. As I understand the upcoming Flash Builder will ease some of the pain. In the meantime, I’ve spent quite a bit of time figuring out how to get things going with a minimum of a code and a maximum of help from the IDE. The best method for this is for the designer to do his work in Flash, and export all his elements in a Flash library. You may have seen these around, their file extension is .SWC. These files are actually zips which contain 2 things : the actual resources, like a SWF, and a catalog file describing what is inside.

If you import this SWC file in Flex, the Flex compiler has access to the exported objects contained in it, and they show up in the auto-complete dialog. If for example the Flash designer exports a  « Banner » clip, then you can use Banner directly in Flex. The main  problem is that you can’t include these in your typical Flex visual object. If you try to add the banner to a Flex object using the addChild method as you would with another Flex object, you will get the following compiler error :

TypeError: Error #1034: Type Coercion failed: cannot convert InscriptionTitre@d1ba4c1 to mx.core.IUIComponent.

There is however a workaround for this. You have to use a Flex object as a wrapper. The one I’ve found that works the best is mx.controls.Image. In MXML you would do the following :

<mx:Image source=”{Banner}”/>

Image recognises Banner as a static resource, instanciates it and shows it. That’s already a nice start. But what if you to do something which needs some interaction ? Suppose you have an animated banner, and you don’t want the animation to start straight away, but only when you call the play() method on it. Let’s call this AnimatedBanner. This code won’t cut it :

<mx:Image source=”{AnimatedBanner}”/>

This fails you because you don’t have a pointer to the AnimatedBanner instance. So what you can do is the following :

private var _animatedBanner :AnimatedBanner ;

In your MXML :

<mx :Image id= « animatedBannerWrapper»/>

In your init function :

_animatedBanner = new AnimatedBanner() ;

animatedBannerWrapper.source  = _animatedBanner ;

Voila !

In this way, when you are good and ready, you can call _animatedBanner.play() ;

There are a couple more issues that could use addressing in a follow up post, but that should get you started.

As a case study, let’s look at the Flex UIComponent. Ok it’s called UIComponent. Fair enough that’s a pretty good name. UI says user interface. It could be GUI which would be more precise, but as everything in Flash/Flex is geared towards graphics this can be forgiven. Component says that it isn’t just eye candy and that there is some functionality  behind it,  and is purposely vague, which is ok as it’s a base class.

Now let’s look at a few member functions and properties. The first thing that strikes you when you look at the doc is how many there are. That’s already a bad sign. I don’t think even the guy who wrote it knows everything that’s in it.

Next, there’s a whole lot of properties that have the word width in it. Width is a good fit for UIComponent, it feels like it belongs there. The obvious advantage of this is that when you look for the « width » property, it’s where you expect it to be. But how about the following :

ExplicitMaxWidth, explicitMinWidth, explicitWidth, maxWidth, measuredMinWidth, measuredWidth, minWidth, percentWidth. Does this not strike you as a bit too much ? Couldn’t there be some more elegant way to access all this width goodness ?

But my favorite is the following : determineTextFormatFromStyles. Why is that even in there ? Surely this could be in another class, maybe dedicated to styles or something ?

I’ll stop there. These are just a few examples of UIComponent overstepping its bounds. From a pretty clear cut idea and a good name for a class and concept the Flex team has somehow turned it into a monster with over 9000 lines of code. Maybe if they’d thought things through out loud things wouldn’t have got so far out of control.

http://www.richinternet.de/blog/index.cfm?entry=911D4B57-0F0D-5A73-AF6F4D4D04099757

Share the love!

in French here

http://www.ark-plus.com/#/En/main/

It takes a lot from dontclick.it, which I’m a big fan of. At the end of my visit, engrossed in drawing shapes and zooming around in their virtual environment thingy, I have no clue what the website is about or what they are selling.

thanks to hebiflux for the link.

in French here

For those of you new to Silex, it’s a Flash based CMS. I could go on about what makes it so cool, but the best is to have a look for yourself : http://silex-ria.org/

Finally, if you’re interested in participating, let me know! We need developers of course, but if you want to help with a community in your country, or do some design, we could use the help.

OK, so I’m complaining, but in most cases Flash does what it says on the tin and does a good job of keeping Flash version problems out of your face. But obviously here there has been some slip ups. Maybe the team has gotten sloppy? Any feedback on what’s going on is welcome.

This post is available in French here

http://www.flex888.com/1108/pearltrees-a-novel-approach-to-web.html

Thanks to Sravan at Flex888!

Ariel

The first step is to detect zooming. I drew inspiration from this post to write the following:

In the loading file I added a simple function to get the browser width:

function getInnerWidth(){

return innerWidth;

}

Using this function and the stage width I can deduce the zoom factor and apply it to my IFrame to size and position it :

/**

* Adjust frame position to match the exposed area in the application.

*

*/

public function moveIFrame(): void{

var localPt:Point = new Point(0, 0);

var globalPt:Point = this.localToGlobal(localPt);

var innerWidth:Number = ExternalInterface.call(“getInnerWidth”);

var browserScaling:Number = 1;

if(innerWidth > 0){

browserScaling = innerWidth / Application.application.width;

}

ExternalInterface.call(“moveIFrame”, frameId, iframeId, globalPt.x * browserScaling, globalPt.y * browserScaling, this.width * browserScaling, this.height * browserScaling);

}

Finally, when should this resizing occur? On loading, obviously, but also when the user resizes during the session. So in the Iframe constructor I added the following callback that can be called from Javascript:

ExternalInterface.addCallback(“refreshIFrame”, moveIFrame);

Then I added the following event listener on the body element of the HTML container:

onresize=”document.getElementById(’Main’).refreshIFrame()”

Voilà! On the fly adaptation to a user zoom when using an Iframe in Flex. Added points would be for re-dimensioning the Iframe during the mouse scroll, but at least for now this is more than enough for my purposes.

Update: Of course, talk is nice, a working example is appreciated. Here we go

]]> http://arielsommeria.com/blog/2009/04/22/firefoxs-zoom-messes-up-iframes-with-flex-heres-the-fix/feed/ 9 http://arielsommeria.com/blog/2009/04/22/firefoxs-zoom-messes-up-iframes-with-flex-heres-the-fix/ http://feedproxy.google.com/~r/arielsommeria/blog/~3/Twd2uLmtjHg/ http://arielsommeria.com/blog/2009/04/08/celebrate-request-for-commentrfc-culture/#comments Wed, 08 Apr 2009 08:37:58 +0000 admin http://arielsommeria.com/blog/?p=113 The first RFC(Request For Comment) was written 40 years ago today, and the NYTimes has a piece on it here. I like RFCs, not particularly that they make pleasant reading, but that they are a great design methodology. It’s about saying” hey kids, I think there’s a technical need here, and here’s how we can address it. If anyone feels they can improve, let me know, and we can maybe work something out. Feel free to roll your own!”. It clearly knocks the socks off death by committee which comes up with monsters like MPEG, USB, 1394… It’s also one of the roots of open source. I’ve personally slogged at implementing a protocol so that one toy could be compatible with another, and I have the RFCs to thank.

Happy birthday RFCs! Here’s a pearltree collecting a few RFCs that I find of interest.
RFC


Hit the link, press play, navigate the map, and please leave a comment!

• Flex classes are huge. Adobe seems to have taken the « everything but the kitchen sink » approach to designing Flex, so you end up with huge blobs of code with tuff and features and whatnots that have nothing to do with the class’s purpose. So obviously a big class is harder to read and extend.

• mx_internal. Everywhere you look in Flex classes you find variables that are part of the namespace mx_internal. Since this isn’t documented, it’s anybody’s guess why the more traditional private, internal, protected and public declarations aren’t enough. The thing is you actually can use mx_internal objects, you just have to know how to. So what it the intention? Don’t use mx_internal in your derived classes unless you’re really hardcore? I’m baffled, so if anyone has an explanation please leave it in the comments.

• Using private instead of protected. Sometimes you need access to a variable from your subclass and it’s been declared private. This happens quite often. So you end up copying the class into your workspace to modify it instead of extending it as you should.

• This isn’t so common as mx_internal, but still annoys. Instead of using a class reference, Flex sometimes uses a path reference to a file. « include “../core/Version.as”; ». Looks crappy, right? Yeah, it is. Suppose you’ve copied the class locally, as mentioned above. The path reference won’t work, and you need to jump through even more hoops to get the job done.

That wraps it up for now. To get a good exapmple of everything I mentioned, take a look at the mx.effects.effectClasses.MoveInstance class. It does a good job, but is long, unreadable and unextendable. Don’t get me wrong, I still like Flex otherwise I wouldn’t work with it and post about it, but sometimes it gets me down.