… it`s still not quite what I dreamed of. Out of enthusiasm about the new great features I blindly tried to convert RichFLV to a browser only version.
In theory everything is there to build such powerfull browser applications now but the problem is that it seems that there is no way to get the actual filepath to the selected file just the data. I can absolutely understand this because it might be another security concern but this means that you cannot display most of the data a user selects.
For a simple image uploader this might be fine because you can easily create an image from the ByteArray with Actionscript but for example for videos or sounds this is not the case. Yeah I know you can always create a swf in memory and then pass it to a Loader instance but that`s not really cool. So if I would want to create something like RichFLV in the browser there is no way to display the video directly on the client

So please Adobe open up the NetStream Object so we can work directly with bytes on it.
Please vote for this feature here https://bugs.adobe.com/jira/browse/FP-5

I think access to the bytes of a NetStream object would also allow acces to the webcam stream and microphone right? This would be so important and open up thousands of possibilites. And it would be a perfect workaround for the security filepath problem. If we are able to actually do something with the data why would we need the filepath 😉

Just had to get this out before the feature list for FP10 is closed and we I have to wait for another 2 years

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)

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 😉

In my last post about the RichFLV AIR 1.0 update I forgot to mention the biggest new feature
You can now stitch together flv files! It`s not really implemented in the most comfortable way and the feature is not really tested but for most cases it should work.
In the file menu you`ll have a new option Import > FLV (stitch). This will import a new flv to the flv currently in RichFLV and stitch them together.
Check out this screencast to see how it works.

Again this is not deeply tested so be carefull and let me know if you run into problems. Some of my observations are:

– different fps might give audio sync problems

– different resolutions work!

– different codecs work

Let me know what results you get. This is a feature i will implement in RichFLV NextGen in a much better way so your feedback here will really help me make this cool.

Thanks

Benz

Get RichFLV for AIR 1.0  + See the new feature in action

[kml_flashembed movie=”http://www.richapps.de/files/richflv/installbage/badge.swf” height=”180″ width=”217″ fvars=”appname=RichFLV&appurl=http://www.richapps.de/files/richflv/installbadge/richflv.air&airversion=1.0.M6&buttoncolor=FF0000&messagecolor=000000&imageurl=http://www.richapps.de/files/richflv/installbadge/richflv.jpg” /]