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

Advertisement

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!

A new version of FABridge is out

… quite some time now actually (from last Tuesday). In case you don’t know already, the Flex-AJAX Bridge (or the much shorter name FABridge) is a library that allows developers integrate Flex applications with JavaScript code. It is a way to access and use Flex components directly from JavaScript code, without duplicating functionality. It allows accessing objects and functions in the target flash movie on the page, and even registering JavaScript functions as event listeners for flash events.

Getting started …

To make a Flex app available for JavaScript integration via the FABridge you will have to place the FABridge.as file in your project and add a component tag in the application, like this:

<bridge:FABridge bridgeName="flash" id="flash" />

Next make sure you give all of the visual components that you want to access from JavaScript an unique ID (this is something you should do all the time though).

Let’s make it clear, and use an example: we want to have for this demo a Flex component which displays a ‘Hello world’ text and a button which refreshes it. On the JavaScript side we’ll simply have a text box where you can type the message you want displayed in the Flash movie. Also, to showcase event handling, when the refresh button is clicked, a JS alert box will pop up. This is how the end page will look like this:

FABridge sample preview

First step – building the Flex component. It’s quite easy actually:

  1. To create a simple application just like this fire up your text editor of choice (yeah, you heard me right, no need for Flex Builder here) and paste the following code in:
    <?xml version="1.0" encoding="utf-8"?><mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
    layout="absolute" width="220" height="220">
    
    <bridge:FABridge bridgeName="flash" id="flash" />
    
    <mx:Label x="10" y="25" text="Hello world!" width="157" height="26"
    fontSize="12" fontFamily="Arial" id="myLabel"/>
    
    <mx:Button x="59.5" y="80" label="Refresh" id="myButton"
    click="myLabel.text='Hello world reloaded!'"/>
    
    </mx:Application>
  2. Now save the new file – let’s say helloworld.mxml.
  3. Now copy the FABridge.as file from the src folder within the zip you’ve downloaded from here into a folder called bridge on the same level as your mxml file.
  4. Now open a command prompt and browse to the location of your project. Once there call the mxml compiler – mxmlc.exe. You can find it in the bin folder of your Flex SDK installation.
  5. At this point you should have a swf file named helloworld.swf in the same folder as your mxml application.

Step 2 – write the HTML page – it’s just as easy:

  1. Fire up that preferred editor again. Punch in the HTML to create the text box and to load the swf file.
  2. To enable the web page to interact with the embedded Flex application you will have to add an import for the FABridge.js:
    <script src="javascript/FABridge.js"></script>
  3. To pass the text in the input text box to the flash movie we need to write a JavaScript function – relax, it’s easy, two rows are enough:
    function setText()
    {
       var flexApp = FABridge.flash.root();
       flexApp.getMyLabel().setText(jsMessage.value);
    }
  4. Now add the function call to the blur event of the text box and it’s done. Once you type and tab out of the text box, the message will appear inside the Flash movie, just like this:
    Messages from JavaScript
  5. For the last touch, let’s register a JavaScript function as an event handler for when the flash button is pressed – this will take some more code, about 4 lines πŸ™‚
    function initListener()
    {
       var initCallback = function()
    {
       var flexApp = FABridge.flash.root();
       flexApp.getMyButton().addEventListener("click",textChanged);
    }
       FABridge.addInitializationCallback("flash",initCallback);
    }function textChanged(event)
    {
       alert("The text has been reset from Flash");
    }
  6. The textChanged function contains the code which gets executed when the button is pressed. You can do whatever you want in this function. The first function should be called by the body’s onload event and will register an event handler on the Flex button – when clicked, trigger the JS function.

With this simple example, you can see how the FABridge makes Flash – JavaScript communication easier. With just a few lines of code you can control a Flex component without going through the ExternalInterface hassle. You can download the sample application created in this example here.

Now that you know what FABridge does, next post will be about the changes in the latest version. Until then, have fun mixing Flex and AJAX!

The virtual office

I’ve read before some posts on this topic – mostly on Lifehacker, as an informative tidbit. And lately I have had the opportunity to put that into practice for a small project on which some friends are starting work (no, I won’t expose it yet πŸ™‚ ). They are a small team – only three people, but which do not work, or sometime even live in the same area. So the web is the greatest medium to work on, and it provides all the tools to keep the project going:

  • Nothing works if the team cannot communicate in an efficient manner. This is where Gmail comes in – you can access it from anywhere via web (or a POP account if you really are an Outlook/ Thunderbird addict) and it allows you to keep track of conversations in an orderly fashion.
  • Instant messaging – however fun e-mailing is, if you get to have 3-4 e-mails back and forth on a single topic, you’d better get on Yahoo! Messenger and talk it out. It can sort some very nasty misunderstandings.
  • Phone – talking is even better. Team members can keep in touch via classic phone (mobile mostly) or Skype -VoIP at its finest.
  • Source control -subversion is my favourite candidate. However I could not setup a private SVN server for this particular project, so I searched a little on the web and found some free (as in beer) SVN servers. The choice fell on Assembla.com. They allow you to have whatever project you wish – including private ones (unlike Google code where you MUST have an open-source project), no space limit and some other interesting tools.
  • Bug tracking – this is important especially when you finish the first10 lines of code (and added the first 30 bugs πŸ˜€ ). It will let other team-mates check your code and submit their findings/ideas. Assembla came in handy here too, as it provides Trac – a way to add tickets for your bugs. You can even assign them to a team-member, pick milestones and such.
  • Collaboration – this is easy: wiki, wiki and more wiki. Also on Assembla, integrated with Trac.
  • Project management- this area is not very well covered since the project is small. Since it only required a basic roadmap, the features in Trac were sufficient.

What I am curious now is what other virtual office setups are used? Perhaps some comments will clear this out (hint hint πŸ˜‰ )