Flex API contest extended

The guys with the Flex 360 conference have extended the deadline for their Flex API contest, so that participants for Europe can sign in as well, The new deadline is 4th of April, the friday before the conference begins. See more information on this here and here.

Also, there’s almost a month to go until the conference. From the Romanian side of Flex I and Mihai Corlan will participate, with two sessions – Mihai with Developing Data-intensive Flex applications and me with a session on Flex and (web) services. I will mostly talk about SOAP services, but won’t ignore REST ones. As part of what I will present  at Flex 360 I’ve started a series of articles on the blog – the first one is already live and presents a sample application that searches videos using web services. So let me know in the comments if I’m off track or not.,

Advertisements

FlexCamp is upon us

Today at Adobe Romania takes place the FlexCamp Bucharest. It’s a conference about Flex which had already sold out in the first three weeks from its announcements.

I will hold a camp session showing off the improvements we have added into Flex Builder in terms of web services – the introspection wizard which generates strong typed classes for both the operations, types and even request / result wrappers.

If you already registered and received an invitation, I’m looking forward to meet you there. Otherwise (or if you simply cannot come) the entire camp is broadcasted live over Acrobat Connect. Recordings of the presentations will also be made available afterwards. You can watch the live camp session on Connect at this address: http://my.adobe.acrobat.com/flexro.

Now back to adding the finishing touches on the presentation.

Silverlight 1.0 is out the door with a surprise

Yesterday Microsoft launched Silverlight 1.0. Officially it is supported by Microsoft on Windows and Mac. So if you’re running on Linux, tough luck. Or is it?

Along the lines of what seems to be an ongoing internal disagreement on how to treat open-source, the developer division seems to be the one that opens up first – they signed a collaboration document with the Moonlight team, promising to share test suites, specification and in-depth documentation to make the Mono version of the plug-in as good as possible. There are also hints that it will be supported by Microsoft, although indirectly through Novell. Microsoft will provide the binary codecs to use with the plug-in. Novell will distribute Moonlight, as said in a recent blog post.

Moonlight is the current implementation of the Silverlight plug-in, made available by the same guys that make Mono, the .NET for Linux. Currently they also work for Novell, so an agreement with Microsoft could be at least guessed. Since it aims to dethrone Flash, the logical move would be to attack it on all platforms, but Microsoft has not released any projects for Linux (per my knowledge). But it does have a prior agreement with Novell, so this is not so unexpected.

It will be interesting to see how will the Linux version stack up against the “originals” – the Mac and Windows plug-ins. Regardless of the results this agreement remains a good sign, a sign that Microsoft can change. And allthough they have us (and most probably themselves) confused about what they’re doing, I can only hope that the developers’ division ideas on Open-Source software gains momentum and adoption inside the behemoth.

For those who want to try out the current implementation of Moonlight, you can see the build instructions here.

New Flex Module is out

A new version of the Flex Module for Apache and IIS has been released on labs late last week. It includes several important changes:

1. A zip folder with instructions for manual installations has been added to help users running Unixes without X and users with more weird configurations with which the installer couldn’t cope

2. Major speed increase. This is the biggest stuff yet, as it now uses a caching slots mechanism to keep the latest 5 compiled mxmls in memory. Incremental compilation times bumped down to under a second (for the FlexStore sample application). Due to the need for the browser to render and display the flash it still shows as almost 2 seconds. But it’s way faster than the previous release.

3. Fixed some bugs and compiled the entire server on Java 1.4. So now the JRE/JDK 1.4 will be enough to work on.

4. Added Vista / IIS7 / Apache support, and Ubuntu 7.04/Apache. Added Mac/PPC support.

5. Fixed some issues with Windows / Apache 1.3.7 (the java virtual machine refused to start when invoked by the module).

6. Fixed Content-Length value  – in some casse, on Windows the pipe from the compilation server to the Apache module added some junk characters, causing the page to never stop loading. Now we check for specific markers before setting the final value on the content length.

You can also find the release notes on the project’s wiki page, over on Adobe Labs. One thing to note though: if you already have a previous version installed, do a full uninstall and then put in the new version.

Flex Module for Apache and IIS is out the door ..

And into labs. Last night Adobe launched on Labs another tool to help developers create Flex Applications free and easy, an the Operating System of choice. I’ve talked before how you can create Flex Applications using only Vim (or any other text editor for that matter), the free Flex 2 SDK and the command line. Now I can strip the command line off that list. No more write > shell > compile > copy > preview in browser once this baby is installed.

So what does it do?

It installs snugly next to your free copy of the SDK (or brings its own one with it if you need it) and plugs itself into Apache (my choice) or IIS. Then all you have to do is point your browser to a mxml file (like http://localhost/flex_app/index.mxml 🙂 ) and it will do all the heavy lifting. You’ll get a swf wrapped by some basic html.

So, if you think it may be interesting for you, grab your copy here (free as in beer of course).

So if you were wondering why I had to poke around Apache modules, now you know 😉

How do you create a new Apache module?

Maybe this exists well documented somewhere – I couldn’t find it. This last month I had to do some work which involved creating an Apache module from scratch. For Linux and MacOSX creating a module is pretty easy – Apache even lends a hand via the APXS tools. On windows there’s a totally different problem. This is why I will try to write here how to create a module.

Hypothesis: We want an Apache 2.x module written in C++ which will respond to certain requests – let’s say .doc files – with a standard text. This is a very easy scenario, but one on which we can build later on.

Part 1 – creating the module on Linux/MacOSX:

This is the easy part. It only takes a few steps to get it done:

  1. Make sure you have the apache2 and apache2-dev packages installed. On Ubuntu/Debian you can find these packages in the Synaptic Package Manager. On Red Hat / Fedora Core systems you can find rpm’s online. On MacOSX simply install the developer tools.
  2. Check that you have apxs available. Try typing apxs in a terminal. If the required packages are installed you should get a help page.
  3. Let’s create the module files. Go to a folder – e.g. /home/my_user and create the enclosing module dir:
    $> mkdir modules
  4. Now apxs/apxs2 already comes into play. One of the flags (-g) can generate a default module template. Let’s do this now. Switch folder with the newly created one and call apxs:
    $> cd modules
    $> apxs2 -g -n doc
    or $>apxs -g -n doc
  5. The -n argument sets the newly generated module name, In this case it is mod_doc. The -g tells apxs to create a new template module.
  6. The default template generates code for a module that implements a custom request handler – just what we need. We could already test the created module and we would get an answer, but it’s not needed right now – it will just print out The sample page from mod_doc. Instead let’s modify the response. Find the line with the above text and change it into whatever you want – let’s say: You are not allowed to download docs! . Save the file and close it.
  7. Almost there now: we need to turn the .c into an Apache loadable .so. Open a terminal in the modules/doc folder and type:
    sudo apxs2 -c -i mod_doc.c
  8. You must use sudo in order for the apxs tool to be able to copy the compiled .so into Apache’s modules folder. If you don’t get an error it’s one step to the finish.
  9. Let’s tell Apache what to use to handle .doc files. Open httpd.conf (location varies depending on your distro) and add these lines at the end:
    LoadModule doc_module modules/mod_doc.so
    AddHandler doc .doc
  10. Now restart Apache and request a doc file through the browser. Instead of a download prompt you will get the HTML text added above.

In the next post, Part 2 – modules on Windows with Visual C++ 2005 Express Edition.

FABridge & memory …

One of the biggest changes in the latest FABridge release is the addition of memory management mechanisms. If until now everything that was passed from ActionScript to JavaScript via the bridge stayed in memory until the page was reloaded, this is true no more. now various objects behave differently with their allocated memory, depending on their origin and purpose.

The mechanism behind the memory management functions is basic reference counting, without cycle handling. This is enough because both ActionScript and JavaScript already have their garbage collection schemes in place, so all that was needed was a way to remove object references from the bridge structures. And this has been put in place. If you don’t care about the memory you are using, then you can develop applications almost just like now (there’s a single thing to chase here). If you do care, the bridge offers the tools to help:

  • Increasing the reference count for an object: object.addRef() or the more arcane FABridge.addRef(object). Useful when an object is destroyed automatically but you still need it. (Special hint here for those who do not care about memory – you still need to do this, or you’ll end up with stale references).
  • Decreasing the reference count for an object object.release() or FABridge.release(object). Do this when you care about memory and want to clear out old objects. If the reference count has been artificially increased above 1, this call will not destroy the object. If it is already 1, the object will be destroyed immediately.
  • FABridge.releaseNamedASObject(object) -immediately destroy the object passed as argument, regardless of its reference count.

As you can see a lot has been going on when it comes to memory, with emphasis on helping the user and keeping it simple. These changes mean that now some objects clean themselves up when they are no longer needed, but not all. And as such, if you want to avoid errors triggered by null object references you should understand what is kept and what not.

The following rules apply:

  1. Objects created explicitly by the user from JavaScript are not removed from the bridge automatically.
  2. Objects creates as the result of an ActionScript function call and returned to the user in JavaScript are kept. Their intended purpose is not obvious, so we cannot remove them automatically.
  3. New objects created in ActionScript after being passed as arguments to function / method calls from JavaScript are not automatically destroyed.
  4. Events and other objects created automatically in ActionScript and passed to a handler function in Javascript only live for the life of their dispatch function. Outside its scope, the object reference no longer exists.

One of the most basic examples which will appeal to both developers which care and which don’t care about memory is the case when you add an event handler from JavaScript and need to delay an execution via a setTimeOut call, like here:

….
var flexapp = FABridge.flash.root;
flexapp.myButton.addEventListener(“click”,jsDispatchFunction);
…..
function jsDispatchFunction(event) {
setTimeout(function() {doSomethingLater(event);},10);
}
…..
function doSomethingLater(event) {
alert(event.getKind());
}

This snippet of code, as it is right now will fail, because once the direct dispatch function ends, the event object is destroyed. Thus, the doSomethingLater function will throw an error. If you add a line inside the jsDispatchFunction, like this

event.addRef()

will fix everything.

And this is it for this post, for it is already too long!