ActionScript Snippet: Return Characters After Last . (dot) From A String

A very quick one. I needed to determine the last n characters from a URL string which points to a file (not web page) in order to return the file extension. It's quite easy in AS3, so here's the snippet in the hope that someone finds it useful. This code will return all characters after the last dot.

view plain
1var s:String = "";
2var extension:String = s.substring(s.lastIndexOf(".")+1, s.length);
3trace(extension); // traces: jpg

Acoustic Echo Cancellation Coming To Flash Player

As some of my fellow Flashers have pointed out today, there seems to (finally) be some movement on a much requested feature (with over 550 votes) for Flash: AEC Support (Advanced Echo Cancellation). It is the second most voted feature request - number one has more votes since seemingly because it has been overrun by Apple fanboys who complain about Flash's poor performance on OSX. It hasn't occurred to them that they should also talk to Apple abo.... err, ok sorry, I forgot that Apple does not enter into a dialogue with its use, let alone run a public bug base like Adobe does.

Ok, rant over, back on topic... Efficient echo cancellation is very important for online communication via FMS, and the lack of it often results in a terrible experience for the participants. Skype has had this feature for a while and that's part of the reason while the in-call performance is so much better in Skype than it is in most Flash based chat tools.

But finally, Thibault Imbert has confirmed: "Just wanted to give you a little update. It is in very good shape, we are actively working on this, and this will be fixed soon ;)"

You can of course still add your vote to the feature request.

My Email To An iPad User

As some of you know, I offer a hosted collaboration tool called Scribblar which I built using some of my favourite technologies, namely Flex and FMS. Today I sent out a newsletter announcing a new feature and I received the following email from one of my users:
"Greetings. I was hoping to use Scribblar to serve as a communication tool between two ipads. However, scribblar uses flash and ipads only use java. Is there a way around this?"

I replied as follows:

› Read Full Article

Migrating StyleManager.getStyleDeclaration (Flex 3) to IStyleManager2.getStyleDeclaration (Flex 4)

Today I was working on a Flex 3 application which I now want to compile using the Flex 4 SDK. One of the warnings that cropped up in the Flash Builder Problems panel was the following message:
3608: 'getStyleDeclaration' has been deprecated since 4.0. Please use 'IStyleManager2.getStyleDeclaration on a style manager instance'.

The line in question was the following which applies a global theme color after a color value has been loaded from a remote data source::

view plain
1StyleManager.getStyleDeclaration('global').setStyle('themeColor', '0x'+gradient_to);

It took me some time to figure out what the heck the 'use IStyleManager2.getStyleDeclaration on a style manager instance' actually meant... it was by no means a straight forward warning. After some Googling and trial and error I came up with this which seems to do the job:

view plain
1var cssDeclaration:CSSStyleDeclaration = FlexGlobals.topLevelApplication.styleManager.getStyleDeclaration('global');
2cssDeclaration.setStyle('themeColor', '0x'+gradient_to);

I'm not sure if this is the correct and/or best way to achieve the same thing but it appears to work which generally is good enough for my requirements :-)
Hope this helps someone, please leave feedback and corrections where applicable.

YouTube: 'Flash Platform Is Best For Video Distribution'

John Harding, Software Engineer at Google, has posted a lengthy article about the pros and cons of Flash video and HTML5 video support in today's browsers. It's fair to say that the post is in essence a major thumbs up to the Flash Platform. The author points out that video on the web today is much more than a simple video tag pointed at a file, but involves other considerations such as widely supported codecs, secure delivery mechanisms where required by content owners, two way video and audio for recording live via webcam as well as immersive fullscreen options.
All this is of course supported today via the Flash Player but not via HTML5, and whilst we all agree that it'd be very nice not to have to wrap a video into a SWF wrapper we must also face the reality that in many cases a simple click and play experience just doesn't cut it anymore. HTML5's video capabilities could have given Flash a run for its money about 10 years ago when Flash first started building momentum for online video delivery, but they are no match for the type of features that web users today are accustomed to and demand as standard.

Sure, of course I am biased, but I am also smart enough to know when I'm beating a dead horse, and Flash definitely is not one of those. Whilst new technologies such as HTML5 are most welcome, especially when they make a developer's life easier they also need to make sure that they don't over-promise and under-deliver. The amount of hype some companies have been able to generate around HTML5 is almost unreal, yet the follow-up on that hype remains to be seen. In the meantime I'll get back to work to make bling with Flash, clients are waiting and the biggest app store of all is still the web ;-)

How did I get here? Sorry - here's the YouTube blog post again.

VP8 Delivers Better Quality Than H.264 - But You Won't Notice It

Jan Ozer was quick on the mark to deliver a side-by-side comparison of video encoded with VP8 (the codec which Google open sourced as recently as two days ago) and H.264, the de-facto codec standard for web video and beyond.
You can check out Jan's tests here on but in summary it is safe to say that any differences in quality are negligible. What remains to be seen is of course how the same codecs perform across a range of bitrates; maybe VP8 does excel once you throw higher resolution, higher bitrate content at it? Or maybe it will distantiate itself at low bitrates?

But regardless, the mere fact that VP8 is open source now and that it is a serious contender in the codec wars that rage around the web in the past few months is a great thing. Remember that H.264 is a patent encumbered format with a patent pool overseen by an organisation called MPEG-LA, and license fees are payable for certain types of usage. It is the uncertainty about these fees and their possible future rise that give organisations like Mozilla cause for concern - and they are not alone. By open sourcing VP8 Google is obviously prepared to call the bluff of anyone who may claim to hold patents on which the VP8 codec may infringe. Now that the sources are open for anyone to see it is now possible to inspect them, and quite likely sue Google for patent infringement. Of course we don't know yet if that's the case, but I truly hope that this big questionmark will once and for all be cleared up by a court. Hopefully VP8 is either free of patent infringements or Google can strike agreements that shield anyone from being sued if they use the codec. No doubt the web would be a better place if we had a free to use, patent free, high performant codec available for everyone to use with no strings attached. Google is definitely up for it and saying: "Bring it on, whoever you are."

I'm sure Adobe is totally loving this, for various reasons :-)

The End Of Codec Woes? Google Opens VP8, Sets Up WebM

Today's definitely a big day. The Google I/O keynote is about to start but some details of what will be announced are already public on the web. In particular it is clear - as was expected - that Google has released the source code for the VP8 video codec. VP8 of course is a supposedly high quality video codec which Google now owns after its acquisition of On2.

Not stopping there, Google set up a new media file format called WebM. You heard it here first :-) I can tell you you will hear a lot more about this very soon, and for a long time to come.

So what is WebM? According to Google it is 'an open, royalty-free media file format designed for the web. WebM files consist of video streams compressed with the VP8 video codec and audio streams compressed with the Vorbis audio codec. The WebM file structure is based on the Matroska media container.' Wow. That's pretty awesome and could definitely a game changer.
WebM is also royalty free. As they explain: "Some video codecs require content distributors and manufacturers to pay patent royalties to use the intellectual property within the codec. WebM and the codecs it supports (VP8 video and Vorbis audio) require no royalty payments of any kind. You can do whatever you want with the WebM code without owing money to anybody. " Well, I think one should add that we will need to wait and see about possible patent trolls coming out of the woodwork once they had a look over the VP8 source code. At least Google is well used to fighting attacks like this so let's see how this plays out. So to sum up, WebM is 100% free (at least initially), and open-sourced under a BSD-style license.

Also interesting is the WebM supporters page. There are many well known companies and brands listed including FireFox, Opera, Android, Chrome and - wait for it - Adobe Flash Player. Wowzers. Maybe we'll hear more about this at the keynote? VP8 in Flash Player would be sweet. The keynote starts in 10 minutes (from the time I type this). One logo notably missing from the supporters page is that of Apple. But that does not mean anyone is missing them.

Announcements at Streaming Media East: Flash Access 2.0, HTTP Streaming

Adobe have made some announcements at this week's Streaming Media East Conference in New York and has some great coverage on that.

The two main topics are the announcement that Flash Access 2.0, Adobe's new flavour of DRM for Flash video, is now available. Previously known as Adobe Flash Media Rights Management Server, Flash Access 2.0 will enable publishers to encrypt content at source and deliver it securely to the end user. This is different to simply using RTMPE for encrypted streaming as not only the transmission will be encrypted but the actual content will be as well. Previously, with Adobe Flash Media Rights Management Server, this technique was only supported in AIR, Adobe's desktop runtime. But with Flash Player 10.1 it will also be supported in the browser based Player, and there are a bunch of new AS3 APIs to make this happen.

Secondly is HTTP streaming. This is also a new 10.1 feature and will allow transmission of video content over HTTP, with the difference that it is no longer a simple progressive download but will also support full seeking, live broadcasts and multi-bitrate switching. A real alternative to RTMP based streaming basically. What's more, the HTTP streaming module for on-demand streaming over standard HTTP servers will likely be free, whilst the live module looks likely to be a paid product.

As mentioned, more details are to be had in Tim's article on Flash Access and the Player roadmap as well as Troy's piece on Flash Access and HTTP Streaming.

Kevin Lynch at Web 2.0 Expo

Here's a great interview with Kevin Lynch from yesterday's Web 2.0 Expo. He talks a lot of sense, but also gets misquoted in a lot of so-called tech blogs. So instead of consuming the spin-everything-into-an-HTML5-versus-Flash posts and FUD-injected written articles I suggest you just watch this video and hear things from the horse's mouth. Good stuff Kevin.

My Letter To Apple: Objection To Section 3.3.1, Request For Exclusion

I've just sent the following to the EU Dev Support at Apple.


Dear Apple,
As a developer who has successfully used Adobe Flash CS5 to build, submit and publish iPhone applications via the App Store I am unable to agree to the new Updated Program License Agreement you wish to impose on me.

Section 3.3.1 of the agreement states:
"Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited)."

Since my application has originally been written in ActionScript it is now in violation of these terms. This brings up two questions:

› Read Full Article

Previous Entries / More Entries