soledad penadés

repeat 4[fd 100 rt 90]

As I found about the news, I spent some time yesterday having a look at the project's files. It's always interesting to have a look at the internals of the software for curious-like-a-cat people like me… but honestly, I'd rather have the Flash player open sourced. That would help to fix, or at least to explain, those absurd issues one finds from time to time when working with Flash.

Even worse: each new version of Flash player introduces slightly different issues. Or bugs, if you prefer. For example, the latest one (9.0.115) has a funky way of playing sound files. If the sample is 44KHz, everything is fine. But if you had a one minute sample with a different rate (say, 22KHz), you can't simply say go to the second 30 and play, because it will instead go to the second 60 (and hence, finish playing!).

And yes, the issue tracker is now accessible to the general public and so you can directly report these odd behaviours directly to Adobe. See here, here and here for some flash.media.Sound errors already reported.

I'm sure if more people could have a look at the player source, these oddities would be fixed way earlier, or at least they wouldn't be released to the general public with a major bug like that one introduced so lightly.

It would also make easier to have updated versions of the Flash player in platforms which currently are always a step behind, because they need to wait for Adobe to release them, or do not have support at all, like Linux PowerPC (at least, it hadn't, last time I tried).

Unfortunately I have the feeling this won't happen any time soon. With DRM dangerously approaching the path of the player it would be quite surprising to have the source code so that everybody could find work-arounds to those restrictions if they feel like. And it would destroy Adobe's monopoly too, of course. Which I guess they prefer not to happen.

Since I don't have Flash Develop on my mac mini but I have plenty of space because I upgraded its hard disk, I thought it was a good moment to install Eclipse and use it at least for ActionScript3 — although I'm quite tempted of doing the same for PHP stuff; the PHP Development Tools (PDT) plugin for Eclipse is gorgeous.

Anyway, I headed to Eclipse's website, downloaded the package, uncompressed to my /Applications folder. It worked, cool. I downloaded the Flex builder plug in, ran the installation program and discovered to my horror that instead of creating its own folder in the destination folder, it indeed used the destination folder for filling it with its myriad of files. Riiiiiight! There was an Uninstall Flex Builder Plugin.app file somewhere — I saw that!

So I clicked it, waited for the uninstaller to finish… all good, my ~/Applications folder was clean again. Then I clicked again on the Flex Plug in installer and it asked me for my Eclipse folder… and I couldn't find it! Where is it!? Yes: if you uninstall the plugin, it uninstalls everything, including Eclipse.

Luckily I hadn't done anything interesting and in addition I think that the preferences are stored outside the Eclipse folder (somewhere in ~/Library probably). But this is just and plainly wrong, Adobe guys!

I might use Eclipse for something else than Flex, you need to understand it!

I have been a bit disconnected from the Flash scene for a while and it's changed quite a lot! So I thought I may share with you my discoverings while I'm getting updated on the latest news.

There's this new thing called Flex. From what I understand, it will allow you to build entire interactive applications which run both on server and client side, using Flash for the interface.

Roughly, the interesting part here is that not all the processing is ran in the server, but also the client's computer is used to run the application. So, things such as updating graphs are made in the client side, with the data that the server sends you, allowing the server to save processing power and bandwidth.

The interface is specified with an XML based language and the application logic is written with ActionScript2; you can do it with the official Flex editor (even in WYSIWYG mode) or with your favourite IDE with custom XML language schemas support (one example: Eclipse). Then, you drop your code in the Flex server, and it will serve the appropiate interface data to the client depending on their actions.

This concept reminds me a lot to the first .net demonstrations I saw: you write code once and it will be served to the user through the .net server, which will determine the appropiate html and javascript stuff to be sent to the clients depending on their browser capabilities. The problem were the browsers' implementations and their support of javascript. Each time I asked the speakers about this, they never knew what to reply. Such an embarrassing question…

In that, Flex has already won the battle. As it uses the flash player to run in the client, they can guarantee a more or less known scenario and then the developers can build an application knowing for sure that it will always work, and there won't be weird implementations of one javascript method on certain browsers, etc.

It also reminds me to the AJAX approach: do not reload the whole page, send only the useful data, and redraw whatever is needed on the client side. The weak points of AJAX are still the different browsers' implementations, and rich media inabilities: graphics would be great, if all browsers implemented SVG properly. And unfortunately, browsers are unable to play sounds just by using html/javascript: as far as I know, when someone needs to play a sound nowadays, they end using a Flash object to play it (and yes, I'm ignoring the MIDI at all).

The advantage of AJAX versus Flex is that you don't need all the human and technical infrastructure that a Flex server requires. It is way cheaper to start building things with the Ajax philosophy (see ruby on rails), and honestly, most of the applications don't really need to have fancy 3d realtime graphics with motion blur and stereo surround sound.

Conclussion? Flex looks promising but it has its own application field, which can fulfill very appropiately. For relatively low-demanding requirements applications, there are other solutions which can work (and are working, indeed) pretty well.

Of course I might have misunderstood something. If there's something you feel is wrong please do not hesitate to leave a comment and I'll correct it.

Extra final bonus

Finally, if you are really curious and want to know some hidden and technical details about how the flash player is implemented -which is what at the end is going to affect everybody: you and your users- take a look at kaourantin.net. That's the blog of one of the engineers at Macromedia/Adobe developing the Flash player. He will get you informed about the changes they make and, from time to time, those little secrets that might explain certain flash oddities.