Installing Flash Player 10 Debug on 64bit Ubuntu

I just finished installing the Flash Player 10 debugger on my 64bit Ubuntu machine. All props go to "Me and Ubuntu," with the article located here:
http://meandubuntu.wordpress.com/2008/08/20/flash-10-rc-on-ubuntu-amd64/

It involves using nspluginwrapper and some other libraries to emulate a 32bit environment for Flash Player to run in. Totally rad.

[AS3] Flex Unit 4

I just wired up the latest version of Flex Unit 4 and it is impressive to say the least. For the last week or so, I've been messing around with the version that ships with Flash Builder 4, but I wanted to get up with the latest because of all of the awesome goodies it comes with.

The thing I am really excited about is the new metadata-driven model. It's almost as convenient to use as JUnit (but it still has a few things to improve upon). Finally, we're able to have annotated test cases and test suites and thus are not forced to extend a class or implement an interface. All test-related configuration is done at runtime by the framework and via introspection. A great article that got me started can be found here on InsideRIA.

The framework seems incredibly intelligent. You can even specify if you expect a method to throw an error with a simple metadata parameter. If the test method does not throw that error, it is considered a failed test. I haven't found anything about the actual framework that I don't like. It is a huge improvement over previous versions of Flex Unit and a good step toward standardizing unit testing across platforms.

One cool thing that I found inside of Flash Builder 4 is how easy it makes it to run Flex Unit tests. By right clicking on an Actionscript/MXML file, you can choose to "Execute FlexUnit Tests...", which I really like. The downside to this is that Flash Builder 4 currently prefers an older version of Flex Unit, and encourages you to manually extend a class and follow test naming conventions etc. The upside to running Flex Unit tests inside of Flash Builder 4 is that it will actually show your test results within Eclipse.

This alone is a feature that's been missing for an extremely long time. Being able to run unit tests within your IDE is a huge productivity boost. Having to manually launch a SWF that displays its test results within itself is at least a few extra steps that bog down one's workflow. Unfortunately, since I'm using Flex Unit 4 rather than the Flex Unit that ships with Flash Builder 4, I have to launch my tests and compile them separately, but at least we're now moving in the right direction. Once you understand the flow of working with a LocalConnection, passing data from Flash to, let's say, Java, really isn't that hard. All you need is to master the AMF encoding, and the LocalConnection protocol, both of which have been done. Then, you connect both ends together, pass some nice data objects about test results back and forth, and when the tests are done, call flash.system.System.exit(0) to kill the Flash Player instance.

All of this could be done relatively easy through the use of an Ant task, making the tests completely automated. I prefer building my applications with Ant, since I can use Ant on any platform and at any time and get the same results. Making a project portable is what separates it from the pack. It's easy to throw together a sloppy project that will only compile in a very specific configuration and setup, but with the right planning, you can have a nice project which builds in Ant, anywhere.

Anyway, I digress. Flex Unit 4 is definitely worth checking out. Go out there and start messing with it!Technorati Tags: as3, flex, flash, unit testing, testing, ant

Ubuntu 64: Running Flex Builder

I can't claim any credit on this one, but I got Flex Builder working on my new Jaunty distribution! I initially thought I should get myself a 64bit version of Eclipse and try to install Flex Builder over it, but that didn't work.

Evidently, the solution is to get a 32bit JRE and get that running, then to modify Eclipse's startup files to point to the 32bit JRE. Everything works great! I was basically able to copy and paste my old Ganymede from a 32bit OS to a 64bit one, with only a few modifications. Pretty dang cool. Anyway, here's where the credit is due: http://rachaelandtom.info/content/running-32bit-eclipse-64bit-linux

As far as running a 32bit Flash Debug player, I haven't given that the time to work on getting that to work. I'm for the moment satisfied to just have Flash Player work regardless. The 64bit standard player is working great for me, I haven't had too many problems with it. Here's hoping that I won't have to get a 32bit Firefox to run the Flash 10 Debug Player :)

Pros and Cons of a Singlethreaded AVM

I've been doing a lot of thinking lately about the Actionscript Virtual Machine (AVM). I know not too many developers concern themselves with diving deep into what makes Flash Player work, but I think it's important to understand the platform on which we stand and rely.

In a lot of ways, AVM is like JVM (Java Virtual Machine), and in a lot of ways, AVM is nothing like JVM. Perhaps the biggest difference is in threads. JVM is entirely multithreaded. As a Java developer, you could basically create an infinite loop creating an infinite number of threads of execution just as fast as your computer could handle it. You can also build applications that do everything synchronously, from opening server sockets and waiting for connections, opening/reading/writing to and from files, to just about anything imaginable. You can also do things asynchronously in Java, so you have the best of both worlds. AVM is explicitly single-threaded. Though AVM may run multiple threads in the background to give you the result you see, you as a developer have one and only thread to work with in development.

This is good and bad. The pros of a singlethreaded VM are as follows:

• Developers don't have to worry about threads, synchronization, and infinite loops. As soon as you introduce threads into a language, you as a developer have a lot more to worry about. For example, if you have two threads working on the same object at the same time, you could easily throw some variables off with one thread while the other is expecting a different result.
  
  IE: Thread 1 is looking at an Object (which is typed as Object) and is casting it as a Number to perform some addition function on it. Thread 2, which is executing at the same time, grabs the Object and performs a subtraction function on it. Thread 1 applies the addition function it was planning on doing, and a crazy result is received. You as a developer are weeping in your chair wondering what the heck just happened.
  
  
• Since there's only one thread, all operations taking a long (or indefinite) time are forced to be asynchronous. Meet the AVM Event flow system. Honestly, for a single-threaded VM, AVM really is powerful with its event system. Following the Observer design pattern, the event system makes it extremely easy for any developer to trigger asynchronous events at any time.
  

The significant cons of a single-threaded are as follows:

• There is little spreading of damage as far as performance is concerned. If the main thread is running slowly, the whole program is running slowly. In a single-threaded VM you can't just create a thread to handle some intensive process while the main thread does nothing.
  
  
• There is little spreading of damage as far as errors are concerned. The single-threaded AVM handles errors similarly yet different as compared to the JVM. Because of the one and only one thread that is running, developers must be careful to NEVER EVER LET AN ERROR BUBBLE TO THE TOP. If an error makes it all the way to the top to be displayed as a message in the debug player, it is an extremely bad thing for the application. I've had many bad things happen when errors are thrown. You could have an event listener for the ENTER_FRAME event break if an error happens at just the right time in just the right place. Even worse, if the error is in the ENTER_FRAME handler, performance will go down the drain. By multithreading a VM, you're typically going to have to use a lot more try..catch...finally blocks, which is good practice. Oh, and did I mention that if an error happens at runtime, it breaks whatever is next in its execution path? If you have code similar to this:
  

  this.doSomething();
  this.doSomethingElse();

  
  ...and an error is thrown in the doSomething() method, the doSomethingElse() method may never get called, throwing off your entire application.
  
  
• You can't do things synchronously. Honestly, some times it's just easier to call File.open() then File.write() rather than construct a file object, add an event listener, try File.open(), then when it's finally loaded, do what you want with it.
  
  
• A single-threaded VM doesn't have multiple threads :)
  

Although AVM2 is great and performs well for a single-threaded VM, it is quite clear that much better performance can be achieved through a mulit-threaded VM. However, it's definitely apparent there are a few problems for developers in switching over to a multithreaded VM. Hopefully we'll be able to see a multithreaded AVM (AVM3?) for harnessing even more power from the Flash Platform soon... maybe even in the next release of Actionscript.

What I'm looking for in AS4

Not that you asked, or that you care, but I think somebody needs to post a wish list for AS4 as far as the language construct is concerned. AS3, being a huge step away from scripting and into the world of development, was kind of like man's first steps on the moon. We did it, now what? It's time to colonize, conquer, dominate, install weapons systems... now that the moon is ours :)

Anyways, what I'm saying is that AS3 was a deep jump into uncharted territory for most of us in the Flash community and many of us ran dizzily in circles at the release of something so foreign to the Flash Platform (and many of us still are). Now that enough of us have made the jump from scripting to developing, I believe Adobe needs to "solid up" Flash Player with more Java-like constructs. I mean, AS3 is supposed to be an object-oriented language, yet we don't have abstract methods, abstract classes, and a few general OOP must-haves. Yes, we can create semi-abstract classes by naming conventions and by throwing errors by hand, but come on! Nobody likes to develop abstract classes in AS3, though they're pretty much a necessity in true OOP.

I digress, there's just so much on my mind. I'll now get started on what this post is really about, AS4 and what we need from it.

1. Language Addition - Generics:
   Generics, or parameterized types, are one of the coolest things to ever happen. Even Flash Player 10 is going to support some form of generics through the Vector type. Adobe has noted that when using the Vector over an Array, there is a 40%+ performance increase. Though we now, or soon, have this kewl 'generic-ish' type, we're only seeing the tip of the iceberg. We need a "java.collections.*" equivalent for Flash Player. The Java Collection implementations are some of the coolest thing in all languages, allowing for extremely efficient and simple manipulation of groups of values. It also forces even greater strict-typing, rather than the Array and Object classes. While I totally understand the need to have intrisnic classes like Object and Array, we greatly sacrifice type-saftey with them. A collections API would eliminate the lack of type-safety within Flash Player for the most part. If we don't see this in AS4, we have every reason to be upset. I also feel the need to mention this: though FP10 has Vector&ltObject>, there are no means by which to develop your own parameterized types as in Java. Now, I don't know of too many developers that create their own parameterized types just for kicks, and I myself have never had the need to create my own generic class, but we need this ability. Who knows, somebody in the community could come up with something extremely useful in a generics class, maybe for a 3D engine or a framework.
   
   
2. Language Addition - Abstract Classes/Methods
   WE NEED ABSTRACT CLASSES! As an OOP/Design Pattern enthusiast, I am really feeling the need for abstract types. I can't vouch for performance or any other benefits to abstract classes, but in design patterns, abstract classes are key. As it stands in AS3, the creation of abstract types is pretty limited. There are workarounds to doing it, of course, but still. We greatly need abstract types. Even if it won't affect you on a day to day basis as a developer, this is core to an OOP language.
   
   
3. Language Addition - Memory Management
   Now I'm no C/C++ guy (yet) but AS3 and FP9 definitely have some problems with memory management that make it excruciatingly difficult to manage memory, make sure objects are REALLY deleted, etc. I know that AS3, like Java, run off of a VM and have a garbage collector, and by definition, the VM should take care of itself. However, that doesn't mean memory optimization has to be painful if not a downright nightmare as it is currently! I don't know how it would work or what exactly to suggest that Adobe should do, but we need some tools to track event listeners and object references, as well as add a finalize() method to the Object class and its descendants as per Java. The event system in FP should be optimized to be weaker as well. *Note: Yes, I know about the useWeakReference field in addEventListener. I nearly always set it to true, and yet I have noticed that some objects simply won't let go and be destroyed.
   
   
4. Language Addition - Annotations
   Yeah, FP does have compiler meta-tags, but we as developers should be able to develop our own. I mean, Flex is a framework right? A framework should basically just run off of a platform and have no special requirements, yet Flex requires a special unique compiler and defines its own meta tags such as [Bindable]. If Flex can bind data that easily, why can't we do it in strict AS3 without the Flex compiler?
   
   
5. Player Standard - Ubiquity
   With the advent of FP10, we now have a bunch of GPU effects, Pixel Bender, 3D drawTriangles functionality, etc. However, these features are only supported on certain processors with certain graphics cards. Isn't the purpose of Flash to provide a platform-independent runtime? This sounds an awful lot like Adobe is pushing Flash away from being the same on every OS and configuration to being a specialty runtime for certain CPUs and GPUs. This doesn't make any sense, why enable a feature that's not consistent on every computer? How do we use Pixel Bender? How do we know our target audience will have X processor and Y video card? Does anyone else see the problem in this?
   
   
6. API Rework - Text API
   The flash.text package serves as a great starting point, but definitely leaves one wanting for more. The HTML reading capabilities of Flash Player have always been pretty weak. I think that Flash Player should have default support for reading all standard HTML tags the way that a browser would read them. What I'm hinting at is cross HTML/FP tag reading. If <img> does one thing in a browser, it should do the same thing in Flash. In FP9, <img> inserts a new Loader object with the url ready to load, but it inserts it on a new line. In a browser, this isn't so, it only puts it on a new line if necessary. I've built a few chat applications where I had to use smilies and this makes it a nightmare. Whenever a user inserts a smiley, it automatically puts it on a new line. Text-wrapping around images has also been problematic.

Well, these are just a few things I'd love to see in AS4. Oh, by the way, does anyone know the status on AS4? I know that Tamarin was abandoned by Mozilla, but do we know what Adobe's up to? FP10 is being released soon and we're all stoked about it, but there is definitely a future for Flash beyond 10, and we should start pushing for features now rather than later!