The game is on: Parleys to switch from Flex to JavaFX to GWT to Flex to JavaFX to GWT to JavaFX…

… to Flex (had to make sure it ends on Flex ;-)) We`ll see who`ll win the game. This is actually a really cool use case. Stephan Janssen my current client is actually crazy enough to let develop three versions (if you count the current Ajax version it`s 4) of his famous parleys website. I`m currently developing the Flex and AIR version of it and I`m certainly biased as to which version i`ll prefer but from a technology point this is a really cool approach. I mean everyone is telling us that their technology is the best. Sun with JavaFX (mhhh), Google with GWT (mhhh) Adobe with Flex (yeah baby!) and now taking away all biased opinions we`ll actually be able to judge about the result rather some marketing material. We`ll see the exact same app build on top of those three technologies. I must admit that sometimes I have a hard time when my client pings me saying that there is a new feature in the JavaFX version that really rocks. But at the same time it motivates me to make the Flex version even better. I`m right in the war! And at the same time it`s also for me a great opportunity to compare those different approaches. But for all you Adobe people out there be warned you might be in the pole position now but others are catching up – well i believe it will stay like this for a looooong time 😉

The moment JavaFX and GWT are at the level of Flex/AIR Adobe will also have made some steps – that`s what I`m counting on and I hope that challenges like these will also motivate them to push even harder (also I think they are curretly doing agreat job at this :-))

We`re not quite ready to judge about the different versions yet as all of them are not ready. Currently you can see these versions:

– old Ajax version which http://www.parleys.com

– Flex beta client (http://www.parleys.com/display/V21Beta/Home#page=Home)

– Flex AIR client (you can get it through the Flex client or download here )

I`ll post my views about this here as the development continues and make sure to post things that are only possible with one or the other technology as for me this is the most interesting part.
I`ll just start with some hints for Adobe what i think might become a downer for the Flex/AIR version :-)
http://bugs.adobe.com/jira/browse/SDK-14245 (vote,vote,vote!!!)
http://bugs.adobe.com/jira/browse/SDK-12874
– allow the socket class to listen on ports to allow p2p functionality!!!
– Allow access of bytes from NetStream and Sound Objects
– Screensharing for at least all Media Server users

These are all things where maybe the JavaFX version will have advatages but mhhh maybe when they finally (if ever) finish JavaFX we`ll have this in Flex too 😉

Hey Adobe,Sun,Google this is not a game it`s a war let`s flood us developers with features :-)

Some interesting thoughts about this here.

Doing partial/resumable uploads with AIR

This post by Ryan Stewart motivated me for a little example with sockets in AIR. I wanted a way to upload files to a server with the possibility to interrupt uploads at any time and pick them up later.
So to do this I thought it would be cool if it works like streaming video to the client but just the other way around. I developed a mini protocol to do this. It works like this:

1. Client (AIR app) establishes a socket connection to Server (Java based in my case)

2. If connection is succesful client send a request which looks like this: 1 byte = operation type 1, length of the body, filename to upload as UTF bytes

3. Server checks if the file with the given filename already exists if so it responds with 1byte = operation type 1, a long (64bit) value which is the size of the file on the server or 0 if it does not yet exist.
4. Client send a package from the file starting at the size of the file on the server: operation type = 2 (1byte), length of body = length of the package, bytes of the package

and so on and so on… You get the idea.

With this mechanism the upload can be interupted and picked up any time. The client and the server always know what`s happening and were the bytes belomg to.

Warning! This is a very very over symplified, incomplete example. No real error handling, no handling for multiple clients, security?…
It`s just a prove of concept. I`m not a java developer and only hacked this together very quickly. The source is really ugly and normally I would not post something like this but as I always promise to clean up everything and post later (and rarely do ;-)) i just post them here so you can get the idea and build something sophisticated out of it.

Here is a screencast that shows the app in action.

Get the sources (again really dirty sources only use for inspiration)

Don`t even think about buying Flex Builder standard edition!

I was just working on some performance improvements for parleys while I encountered a big memory leak.
If you run into problems like these (and you will sooner or later :-)) Flex Builder professional saves your day. The profiler alone is worth every extra penny.
Not only should you take care to use weak references with listeners but also watch for your Bindings. If you use the Binding tag their is no way to remove the reference and therefore your objects will never be ready for garbage collection. So i get used to replace my binding tags to ChangeWatchers which gives me the ability to unwatch them.   With the profiler it`s really easy to find and fix performance and memory issues like these. I was able to reduce the memory usage by 2/3 in 30 min of work.
These otpimisations are not yet in the current parleys beta version (will be next week) – so watch out for the difference :-)

So please do yourself a favor and don`t be stingy – get yourself the full monty and buy Flex Builder Pro!
Espacially if you`re a dirty hacker like me Flex BuilderPro will help you improve your skills 😉