Ariel Sommeria .com

I was doing some wishful thinking about generating todos from code comments in Flex Builder over at Ted’s Blog and someone helpfully pointed me to someone who has the job for me. Here’s a plugin for Flex builder that does exactly that.

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

Share the love!

in French here

I’ve just found this website that has the dubious honour of being delicately entrancing and beautifully crafted, and at the same time one of the worst examples of Unnavigatable Flash Crap.

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

I haven’t been posting much recently because I’ve busy with Silex. It has been well worth the trouble because Silex is project of the month on Sourceforge!
Read all about it here : http://sourceforge.net/community/june-project-of-the-month/

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.

I recently discovered that Flash 10 for Firefox on Mac OS has some pretty serious redraw problems. This is a pretty small subset of users, but nonetheless troubling. One of the main selling points of Flash, and maybe the main reason why I got interested in the platform in the first place is the idea that developers don’t have to deal with the mess that is cross-browser development. For those of you unfamiliar with the situation, development in HTML means toiling away to get your design look halfway decent in your browser of choice, and then seeing it look completely crappy in other browsers.With Flash, supposedly no more such problems!

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

I now have some serious bragging rights and geek cred, I gave  my very first interview, and the blog I gave it to has Flex in its name.

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

Thanks to Sravan at Flex888!

Ariel

While working on IFrame integration for pearltrees I came across a pretty unfathomable bug that I haven’t seen documented elsewhere, so I thought I’d post about it here. Zooming in Firefox messes up IFrame positioning. Furthermore, Firefox remembers zooming for each individual page, so if perchance you zoomed in the application by accident, things will be permanently messed for that url. What it looked like at the offset was that on one computer only the Iframe would spill out of its bounds. Changing the name of the html file would somehow solve the problem. Once I’d identified the problem, here’s how I solved it. The fix only works if the host Flash application uses “noscale”, and would need to be slightly adapted if the application didn’t take the whole window. The main IFrame management code is inspired from this.

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

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 has been open source for a while now, so you might wonder why there doesn’t seem to be more external, community-driven extensions to the library. It seems that the only source contributors are Adobe employees. I’ll pass on the theories on why Adobe might want to keep it this way. The purpose of this post is to look at why from a strictly technical point of view it’s really discouraging to try to extend the library. I’ve tried, and these are the problems I’ve run into.

• 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.

Ok, you have to write a class for a Flex project, so do you use MXML or Actionscript? What I’ve often seen in Flex projects is MXML everywhere, even when a simple Actionscript class would have done the trick, hence this post. I understand the urge to use MXML, but there are a few caveats that make it a deal-breaker that I’m going to look at here.

– no parameters in the constructor. When you design a class, parameters in the constructor indicate the parameters without which the class cannot function. As far as I know, there is no other way to push this information towards the person integrating the class, except maybe with a doc that won’t be read unless you twist their arm. What is also nice about parameters in the constructor is that you don’t have to worry about them being set, because they are available for the whole lifespan of the class.

– Limited inheritance. If you created an MXML file and want to add elements in a sub-class, you can’t. Not only that but it doesn’t break at compile-time but at run-time with an incomprehensible debug message.
– increased compilation time. Remember, MXML is converted to Actionscript. So it takes longer to compile. As a side note, the generated Actionscript is really ugly, but that would be for another post.

– no internal classes for MXML files. Ok, this is nitpicking, but when you gotta do it, you gotta do it and you can’t.

After all that, the one place where I feel MXML shines and is really justified is when you need to do some floating layouts with boxes. I’ve tried doing it in Actionscript and it’s just completely unreadable compared to MXML.

So in conclusion, my rule of thumb is the following: If it doesn’t at least have 2 levels of imbrication of boxes, it’s probably better to go straight to Actionscript.

As I develop and compile large projects, I appreciate having a powerful computer. The trouble is, I don’t see the problems that people with lesser computers have with my app. On my computer what can be a minor annoyance due to a momentary overload of the application can bring somebody else’s computer to a grinding halt.

To test my application in these situations I either need another computer or to keep my current one very busy with something else so that it feels just the same. So I wrote this quick tool that I call the Flash Stresser.

The Flash Stresser is a graphical component with as many components as you want moving in random directions. It comes with a default of 5 objects, which won’t make much difference in your application. If you want though set it to 500 or 5000, hit “enter”, and watch your application slow down.

Try it here. View source is enabled. I’ve included a quick something to measure the framerate too. I ripped that off some blog that I can’t find again, so if you know please tell me and I’ll give due credit.