1. Touch interface support

Despite what Apple says, flash applications that were designed to work with rollovers work really well when used on a touch based interface. (see video here). Apple neglects to mention that rollovers are super common with HTML/js sites now and none of the mobile web browsers handle them particularly well. In addition, Flash ships with a full API for multi-touch that developers can use. HTML5 multi-touch support is still being worked out and is in very early stages of being implemented.

2. More Audio Codecs

Flash supports ADPCM, HE-AAC, MP3, WAV, Nellymoser, and Speex codecs. HTML5 defines an audio tag and leaves it up to the browser to decide what Codecs to support. Where does that leave you? As of this writing, Firefox will be supporting OGG and WAV, Chrome supporting OGG and MP3, IE supporting MP3 and AAC. To build a site with HTML5 you will have to choose your codecs carefully and make sure that users are using a compatible browser. As an aside, it is also possible to write pure AS3 decoders, so there is an OGG vorbis player written completely in Flash.

3. More Video Codecs

A lot like the story with audio, Flash supports multiple video codecs (On2 VP6, Sorenson Spark, and H.264). HTML5 leaves it up to the browser to support codecs so as a developer you have to know what browser your user is using and choose an appropriate codec. Encoding your video twice once for Firefox and once for IE is going to be painful. Even sites that are moving to HTML5/H.264 are using Flash as a fallback for browsers that don’t support H.264.

4. Color Correction

This doesn’t mean a whole ton to me, and might not to you, but there are people out there for which color correction is a very big deal. If you were building a workflow application for professional photographers for instance, having built in color correction could make a ton of difference.

5. Manipulate Binary Data

Actionscript 3 is capable of manipulating raw binary data. This enables you to do things like extend it to handle more file formats, network protocols, or media codecs. Javascript cannot yet handle binary data and I don’t see a proposal anywhere that would enable it to do so.

6. Peer-2-Peer

P2P is in the HTML5 spec but as of this writing isn’t implemented in any browsers. Flash supports P2P out of the box with frameworks to assist in helping you build applications that use it. P2P enables you to have end users send data to each other without a need for a central server. For example, if you had a video chat service, you wouldn’t want every user to stream their video to a central server to be connected. The load on your central server would be huge. You would instead have users that are communicating with each other connect directly to each other to transfer the video.

7. Binary Network Sockets

Like P2P, Web Sockets will take care of most of your networking needs, but it can’t handle binary data (or work over UDP). This limits the type of applications you can write. Also, as of this writing, Web Sockets is only implemented in Google Chrome.

8. Use the Webcam or Microphone

The Device APIs and Policy Working Group is supposed to be working on a recommendation for this, but there goal is to deliver a standard by Mid 2011. Once that is complete, browser makers can begin conform to this standard. If you want an application where users record photos, audio, or video – Flash is still your best choice.

9. Video Streaming

This one seems to confuse a lot of people that I talk to because they don’t realize that Flash has two mechanisms to service Video/Audio. You can host your media on a plain old web server and have it play as it downloads, or you can host it with an RTMP server and have it stream to the user. Streaming allows you to do things like bitrate adjustments (adjusting quality depending on the user’s speed) and jump around in a file. For example, when you click in the middle of a 2 hour long movie on HULU, the player jumps right to that point and starts playing. If you had this long movie hosted on a normal web server for download you would have to wait until the entire video up to that point has been downloaded.

HTML5 only defines the HTTP download type as part of the standard. There are specs out there for getting progressive streaming working with HTML5 but they aren’t all completely implemented and aren’t part of the core HTML5 standard.

10. Media Digital Rights Management

There are tons of different solutions out there for better protecting your content with Flash. I haven’t yet seen any DRM methods that work with HTML5. When I bring this up with discussions I get an earful about how DRM is evil and who cares if it isn’t supported. I tend to agree that DRM has issues and I’m not thrilled to have to use it, but try telling that to your boss who owns the content. Wether we like it or not, DRM is a requirement for many people who are serving up the content wether we object to it or not.

11. Built in Accessibility support

Developers often overlook accessibility but anyone who has worked on a site for a large corporation knows that this is a real concern since having a website that is not usable by disabled users opens them up to lawsuits. Flash supports Microsoft’s Active Accessibility (MSAA) API. As well as TimedText closed captioning for video subtitles.

Critics have rightly complained that this support only works on windows but the number of screen readers on OSX and Linux is limited and less standardized, so I see Adobe’s choice here.

I don’t see any mention of Accessibility in any of the HTML5 proposals. (let me know if it is there). I’m sure it will be trivial to write javascript that parses TimedText and syncs it with video but I would really have liked to see something about CC in the specs.

12. Massive community supported library set

This is an area where HTML5/javascript is catching up, but it is still a long way off. The flash community is massive and has tons of open source libraries for building almost anything you can imagine.

13. Full screen mode

Late Entry: 5/27/2010
HTML5 prohibits browsers from making any way to programmatically enter full screen mode. It allows browsers to provide a way to view video full screen but not other elements. With Flash a user click action can trigger full screen of any content. While some talk, legitimately, about security concerns – this feature is used successfully by many sites out there to deliver a better user experience. Full screen mode is used not just for video viewing, but for Kiosks, presentations, and many multimedia rich sites I’ve seen. I have also not heard of any nefarious sites in the wild using full screen to try to trick users. The combination of click to activate and escape to exit seem to do a pretty good job of offering an okay balance of security and utility.

There you have it

There you have it, 12 things I can think of that continue to make Flash the right choice for many projects. I’m going to keep the list titled 10 because some people will complain that #12 isn’t a feature of the platform and who makes lists of 11 things.

For the record, I’m not an HTML5 hater. I use whatever technology is best for any given job. I look forward to more standards, more openness, and more cool new tech. On those fronts HTML5 is looking more awesome by the day, but if I want to write an app now and now next year, it isn’t the right choice for everything.

Features:

• Very Simple
• Allows you to set min and max values for height and width
• Holding shift key keeps aspect ratio

You currently have to do the cropping on your own, either in flash or server side. I will followup later with examples of how to do that.

To embed this into you application, all you have to do is:

import com.wirelust.imagecrop.ImageCrop;
import com.wirelust.imagecrop.CropBox;
 
private var imageCrop:ImageCrop = new ImageCrop();
private function onCreationComplete():void {
	imageCrop.loadImage("demo1.jpg");
	
	// imageBox is an mx:HBox in my mxml
	imageBox.addChild(imageCrop);
	
	var crop:CropBox = imageCrop.cropBox;
	
	// Set up the initial crop
	crop.cropX = 178;
	crop.cropY = 187;
	crop.cropWidth = 249;
	crop.cropHeight = 219;
}

You can then listen for CropBox.EVENT_CHANGED to get the dimensions of the box as it changes:

private function onCreationComplete():void {
	// snipped ...
	
	crop.addEventListener(CropBox.EVENT_CHANGED, onCropChanged);
}
private function onCropChanged(event:Event):void {
	if (imageCrop.cropBox != null) {
		xValue.text = imageCrop.cropBox.cropX.toString();
		yValue.text = imageCrop.cropBox.cropY.toString();
		widthValue.text = imageCrop.cropBox.cropWidth.toString();
		heightValue.text = imageCrop.cropBox.cropHeight.toString();
	}
}

Files

 Download source code

Here is the code to generate the above sample:

import com.wirelust.waveform.Waveform;
import flash.media.Microphone;
 
private var wave:Waveform = new Waveform();
private var mic:Microphone;
 
private function init():void {
	wave.height = 50;
	wave.width = 450;
	wave.y = this.height/2 - wave.height/2;
	wave.x = this.width/2 - wave.width/2;
	this.addChild(wave);
	
	mic = Microphone.getMicrophone();
	mic.setUseEchoSuppression(false);
	
	// loopback is required so we can get the activity level and create the waveform. - so stupid
	mic.setLoopBack(true);
	
	// turn off the volume for the loopback
	var mySoundTransform:SoundTransform = new SoundTransform();
	mySoundTransform.volume = 0;
	mic.soundTransform = mySoundTransform;
	
	this.addEventListener(Event.ENTER_FRAME, onFrameEnter);
}
 
private function onFrameEnter(event:Event):void {
	if (mic != null && !mic.muted) {
		wave.add(mic.activityLevel);
		wave.invalidateDisplayList();
	}
}

And for the Waform class:

import flash.display.*;
import flash.events.*;
import flash.geom.Matrix;
 
import mx.core.*;
import mx.graphics.IFill;
import mx.graphics.IStroke;
import mx.graphics.SolidColor;
import mx.graphics.Stroke;
 
public class Waveform extends UIComponent {
	private var levels:Array = new Array();
	public var color:uint = 0x000000;
	public var borderColor:uint = 0xCCCCCC;
	public var borderWidth:uint = 1;
	public var autoScale:Boolean = true;
	
	public function Waveform() {
	}
	
	public function add(level:Number):void {
		// trim the levels so we don't keep eating up memory
		while(levels.length > this.width) {
			levels.shift();
		}
		levels.push(level);
	}
	
	override protected function updateDisplayList(param1:Number, param2:Number) : void {
		var scaleFactor:Number = 1;
		// autoscale will find the highest volume and scale all lines in the display accordingly.
		if (autoScale) {
			var highestLevel:Number = 0;
			for (var i:uint=0; i<levels.length; i++) {
				if (levels[i] > highestLevel) {
					highestLevel = levels[i];
				}
			}
			scaleFactor = height/2/highestLevel;
		}
 
		super.updateDisplayList(param1, param2);
		graphics.clear();
		graphics.lineStyle(1, color, 1, true, LineScaleMode.NORMAL);
		var lineX:uint = 0;
		for (var j:uint=0; j<levels.length; j++) {
			graphics.moveTo(lineX, this.height/2 - (levels[j] * scaleFactor));
			graphics.lineTo(lineX, this.height/2 + (levels[j] * scaleFactor));
			lineX++;
		}
		
		if (borderWidth > 0) {
			graphics.lineStyle(borderWidth, borderColor, 1, true, LineScaleMode.NORMAL);
			graphics.drawRect(0, 0, this.width, this.height);
		}
	}
}
}

Files

 Download source code

One tricky thing about FZip is that when running in Flash Player it requires your zip files to have an adler32 checksum for each file in order to work. This is normally fixed with a work around python script provided with FZip.

The python script is easy and all, but why not figure out how to do it in pure AS3 with more standard zip files?

The checksum is needed because AS3′s ByteArray only supports ZLib when running in Flash Player. In AIR it supports deflate which is what zip files use by default. I would be really curious to hear from Adobe why they chose not to support deflate since you need deflate for Zlib to work anyway.

I decided to implement inflate in as3 but I didn’t want to do it with new code so I looked for FOSS projects to port. JZlib was a good choice because Java is similar to AS3 and it didn’t rely on any external system calls.

This port supports everything in JZlib so you can use it for any inflate or deflate operations you might need.

To use with FZip

I used this library in FZip so it no longer requires that zip files be converted before use. It is tested to be working with the OSX cli zip command. It doesn’t work with OSX finder zip compression because of another issue.

• Download Modified FZip Source
• Download as3zlib
• Google Code Home for as3zlib
• View FZip decompress example

In FZipFile.as:

protected function parseContent(data:IDataInput):void {
	if(_compressionMethod === COMPRESSION_DEFLATED && !_encrypted) {
		if(HAS_INFLATE) {
			// Adobe Air supports inflate decompression.
			// If we got here, this is an Air application
			// and we can decompress without using the Adler32 hack
			// so we just write out the raw deflate compressed file
			data.readBytes(_content, 0, _sizeCompressed);
		} else if(_hasAdler32) {
			// Add zlib header
			// CMF (compression method and info)
			_content.writeByte(0x78);
			// FLG (compression level, preset dict, checkbits)
			var flg:uint = (~_deflateSpeedOption << 6) & 0xc0;
			flg += 31 - (((0x78 << 8) | flg) % 31);
			_content.writeByte(flg);
			// Add raw deflate-compressed file
			data.readBytes(_content, 2, _sizeCompressed);
			// Add adler32 checksum
			_content.position = _content.length;
			_content.writeUnsignedInt(_adler32);
		} else {
			data.readBytes(_content, 0, _sizeCompressed);
 
			//throw new Error("Adler32 checksum not found.");
		}
		isCompressed = true;
	} else if(_compressionMethod == COMPRESSION_NONE) {
		data.readBytes(_content, 0, _sizeCompressed);
		isCompressed = false;
	} else {
		throw new Error("Compression method " + _compressionMethod + " is not supported.");
	}
	_content.position = 0;
}
 
protected function uncompress():void {
	if(isCompressed && _content.length > 0) {
		_content.position = 0;
		if(HAS_INFLATE) {
			_content.uncompress.apply(_content, ["deflate"]);
		} else if(_hasAdler32) {
			_content.uncompress();
		} else {
			var uncompr:ByteArray = new ByteArray();
			var d_stream:ZStream=new ZStream();
			d_stream.next_in = _content;
			d_stream.next_in_index = 0;
			d_stream.next_out = uncompr;
			d_stream.next_out_index = 0;
			
			var err:int = d_stream.inflateInitWithNoWrap(true);
			while(d_stream.total_in <= _content.length && i<=_content.length*4) {
				d_stream.avail_in=d_stream.avail_out=10;
			
				err=d_stream.inflate(JZlib.Z_NO_FLUSH);
				if(err == JZlib.Z_STREAM_END) {
					System.println("decompress success:" + this.filename);
					break;
				} else if (err == JZlib.Z_STREAM_ERROR) {
					System.println("stream error:" + this.filename + " " + d_stream.msg);
					break;
				} else if (err == JZlib.Z_DATA_ERROR) {
					System.println("data error:" + this.filename + " " + d_stream.msg);
					break;
				//} else {
				//	System.println("status:" + this.filename + " " + err);
				}				
			}
			err=d_stream.inflateEnd();
 
			_content = uncompr;			
		}
		_content.position = 0;
		isCompressed = false;
	}
}

*** UPDATE 2/9/2010: Thanks to Kathrin Furtlehner for sending me a test case for a bug where it wasn’t extracting the full file when dealing with longer strings. I updated the patched FZip archive to reflect the fix.

I came into an instance yesterday where I needed to do some bitwise work in actionscript. The code was reading a bytestream from a binary file and converting to an array of numbers. Since this project was ported from Java (by someone else), a simple operation was overlooked. It was taking the binary number and converting it to a signed short. Since actionscript doesn’t have the same casting mechanisms conversion isn’t as straight forward in java.

In java the operation looked like this:

//  binary: 1111 1111 1111 0001
int hexValue = 0xFFF1;
 
short value = (short)(hexValue);
// value = -15 

Since short in java is always stored with a signed bit, the cast appropriately set the value at -15.

The way this was translated into Actionscript looked liked this:

//  binary: 1111 1111 1111 0001
var hexValue:int = 0xFFF1;
 
var value:int = int(hexValue);
// value = 65521  // Wrong! 

Actionscript has no concept of casting for primitives so the int(hexValue) doesn’t do anything at all.

Here is the workaround I came up with, I suspect there is a shorter way to get the same result but I can’t think of one right now.

//  binary: 1111 1111 1111 0001
var hexValue:int = 0xFFF1;
 
// get everything except the signed bit "111 1111 1111 0001"
var unsignedValue:Number = (hexValue & 0x7FFF);  
// unsignedValue now equals 32,753
 
var signedValue:Number = unsignedValue;
 
// if the signed flag is set, flip the value
if ((hexValue >> 15) == 1) {
    signedValue = unsignedValue - 0x8000;   // 0x800 =  32,768 (maximum 15 bit number)
}
 
// signedValue = -15 

Looking for an alternative, I started taking a look at Font Reader which is a port of a project called Typecast I saw a few years back.

Anyway. Long story short, I’ve been up all night playing around with and extending Font Reader (for my current project, but also because it’s fun to play with).

The version that is posted on the site uses a custom written path renderer which seems to have some bugs. In particular it seems to clip at the end of a logical path segment.

The custom objects were very close to the new stuff in the Flex 4 gumbo stuff from Adobe, so I was able to easily swap them out and use the Adobe classes instead. Since that was so easy, I started working on getting editable point handles so I can start editing the paths within the application. I have this about 75% done, but I can’t help quell that feeling that there must be a reusable class out there someone else wrote. Anyone know of one?

Here’s a screen shot of my current working build for comparison:

If I get this working by next week, I’ll post the code.