So here you are, at flexiblefactory, want to get in touch? tomatflexiblefactorydotcodotuk.
So here you are, at flexiblefactory, want to get in touch? tomatflexiblefactorydotcodotuk.
Some of our readers might have noticed a slightly downbeat tone to our recent posts, especially concerning everyone’s favourite web player! Here’s a more positive post to put the record straight.
Things have been a little quiet here at FlexibleFactory over the last year or so because the team have been busy with the launch of our new website over at TunaMedia Ltd.
Although we’ve kept the Flash content fairly discreet, it really deserves pride of place on the site. Without the Flash Player, this project would not have been possible. Even though we’ve been through a bumpy ride together, now that everything on the site is (quite literally) singing in harmony it gives me great pleasure to introduce you to radiotuna.com. Search thousands of free online radio stations by artist or genre… we’re pretty sure you’ll like it!
…and, despite the bumps and bruises, we still love you, Flash!
You can play streaming mp3 audio in Flash player using the Sound object. However, there are some serious problems with this, which I feel we should make clear, since Chris’s recent
outburst post did not really explain the core problem which we still face, which we have worked around in a rather unsatisfactory way. The solution works but still suffers from some unfortunate problems which become apparent on lower spec machines (and by this I mean Pentium 4 generation machines).
First and foremost, and this applies to both the AS2 + AS3 Sound objects, playing streaming audio has the effect of consuming an ever growing amount of memory. The memory allocated to the audio which has been played already is never deallocated, other than by stopping the stream. For this reason, all Flash based stream players will either bring the machine to its knees in a short time, or will require a regular covert reconnect every 10-20 minutes, which obviously causes a glitch in the music, however cleverly it is done (we do make a great effort to do it as subtly as possible).
We originally set out to write the Flash part of radiotuna.com in AS3. However, the AS3 Sound object behaves rather differently to the old AS2 Sound object: To be precise, it does not deal with mid-stream bitrate changes. This means that should the bitrate change during the course of playing the stream (which it frequently does with internet radio broadcasts, usually after an intro, or during a ‘jingle’), the sound goes very very BAD. It either sounds like its speeded up, or broken up in to chunks, since its using the bitrate declared at the start of the stream and ignoring the bitrate change embedded in the stream. This was completely unacceptable, since so many radio stations change bitrate after an initial jingle.
The old AS2 Sound object deals correctly with bitrate changes, and for this reason we chose to rewrite the stream player part of the site in AS2. However, what soon became apparent was that along with the rising memory usage, we were now seeing a linear rise in processor usage as the stream progressed, meaning that on a Pentium 4 machine the single processor was at 100% within 10-20 minutes depending on the bitrate. This of course made the machine unresponsive, again completely unacceptable. The solution of course is the same, but a sad state of affairs nonetheless.
Hopefully Adobe can address these serious problems, even if it means working with the browser vendors on how never-ending downloads are managed between browser and player.
I too would like this and other bugs in the Flash player ironed out as a priority, before introducing any more new features. New features are great, and I am particularly impressed with the iPhone announcement, but one reason I am writing this post is that since compiling for iPhone will only be for AS3, our solution will not apply. Adobe, please make sure that the AS3 Sound object respects midstream bitrate changes in future releases, and when compiled for iPhone.
After saying yesterday that Silverlight 3 has Cleartype, I must now point out that while this is true, after looking at a few samples today, as well as this font rendering comparison, the quality of rendering is not on a par with the standard Windows Cleartype that we are used to. (winforms text in the link above)
This is really disappointing. While its a significant improvement over 2.0, it still has that fuzzy, projected look to it, that to me, and others makes applications feel ‘foreign’ or even ‘fake.’
In the Flash world, we suffered terrible text rendering until the introduction of Saffron a few years ago, which is actually rather good, and although not native, has a crisp and even feel to it.
I honestly think that the lack of native widgets and text rendering has been a major barrier to the psychological acceptance of Flash/Silverlight/Java based applications as ‘real’. Remember the clunky old Swing components, and how they made you feel that ‘this is not the real thing’.
Of course, if it’s even better than ‘the real thing’ that’s great, but the difficulty of achieving this with a one-size fits all approach should not be underestimated.
As children, we learn to distinguish toys from real tools by their appearance, and this may account for the lack of credibility that non-native (looking) applications have. An enormous effort has been made to get native UI into Java, so I can’t be the only one who thinks this. However, I certainly don’t agree with Jeff’s preference for IE7, a program that, to me, is an abomination, and only exists to test the patience of web developers.
A couple of years ago I had the dubious pleasure of working with WSSE and the as3corelib library which implements some of the required functionality for communicating with WSSE enhanced web services in AS3. I was accessing a .NET application which exposed such web services and ‘consuming’ them with Flex. After hacking the code in this library a little so that it actually did what I needed (generating WSSE security headers for the SOAP messages), it turned out something was very much amiss. All the data getting sent looked good, but requests were rejected with an ‘InvalidSecurityToken’ or somesuch exception. After a lot of detective work, it turned out that this bug was squarely to blame.
In getUsernameToken, the nonce is base64-encoded. This encoded value is
then used in determining the password digest. This is not according to the
WS-Security UsernameToken specification: the password digest is based on
the unencoded nonce value.
Now the fix for this is truly trivial, moving a single line of code in
getUsernameToken , however I would forgive anyone facing this problem for simply giving up, the problem is so obscure (and unlikely).
var password64:String = getBase64Digest(nonce, created, password);
nonce = base64Encode(nonce);
Original incorrect code
nonce = base64Encode(nonce);
var password64:String = getBase64Digest(nonce,created,password);
TWO YEARS have passed since this bug was reported. It’s status is still ‘New’. It still doesn’t even have an owner. There is a patch for it though, which was submitted more than six months ago now, but still not has found its way into the trunk.
I bring this up now because I recently had the pleasure of sharing this esoteric information with another developer who was facing similar issues.
The thing is, how did this code ever end up being published? It is simply wrong. Have any of the orginal developers actually tested this code against a real implementation of WSSE? I don’t see how it could ever have worked, or how it ended up being published, and with the fix yet to be rolled into the trunk, every developer who has ever called the
getUsernameToken method must be scratching their head.
Of course, I know that bugs can and do find their way into release software, it’s a fact of life. Hey, maybe it was a slip of the mouse at the last minute But show stopping bugs that are still there two years after they are reported, I cannot understand.
If you ever work with this library, do read http://code.google.com/p/as3corelib/issues/list because other issues that may also impact on WSSE also have fixes attached there.
As a long time Flash/.NET programmer, Silverlight has always been of interest to me. However, apart from a little pong game we made when it was still WPFE, I’ve never taken the trouble to delve into this new tech too deeply. The main reason has always been that these things tend to be both frustrating and disappointing in their first couple of years of life. APIs change and break your code, and essential features are broken or missing. All in all, developing with a mature platform is much more satisfying and rewarding.
For Silverlight, it was the lack of support for dynamic bitmaps, and the appallingly bad font rendering that screamed ‘Not ready!’ through versions 1 and 2. The look of the text reminded me of Linux windowing systems before they recently got their act together.
People did come up with some ingenious hacks for the bitmap problem, but really you don’t want to have to do this sort of thing. And as this quote from the Silverlight forums sums up, crappy font rendering is not an option if Silverlight is ever going to compete with Flash.
Fonts look like crap in Silverlight. Doesn’t matter what font I use, if I embed it or what, they look like crap. Even companies like DevExpress, Telerik and Componentone’s samples for their new controls look like crap because of the fonts.
This is just imbarrassingly bad. Is there a way to make them look like they should? Is this going to be fixed?
It sure should be fixed for the final version, cause otherwise Adobe and company are going to laugh you out of the room.
Looks like old Silverpants is starting to get with the program. Maybe I should too.
I like to keep my PC in good working condition. This means limiting the number of startup items and shell menu items that invariably sneak onto one’s PC when installing software from less reputable manufacturers.
If I want a toolbar, I’ll install it, thanks. If I want extra shell items hooked into my rightclick menus, I’d like to ask for them. I certainly don’t want some management buffoon deciding that the best way to up the number of installs of their pet project is by sneaking it in like a trojan on the back of some other product.
I installed the trial version of Illustrator the other day on my PC. Now I have something called AdobeDriveCS4 appearing in my right-click Explorer menus. I don’t want it. I didn’t ask for it. Adobe didn’t tell me it was going to be installed and now it’s there slowing down my machine. No worries… I’ll just uninstall it, right? Nope, there’s no uninstaller available, nor do Adobe publicise how one might get rid of this sneaky trojan.
The thing is, I’d quite like to carry on using Illustrator, and I don’t even know if uninstalling it will get rid of the parasite programs that hide within its monster 1GB (1GB???) installer.
Adobe… this sucks. The public decided a long long time ago that this is a bad idea. How long will it take for your management to catch up with us?
I’ll certainly think twice before I absent mindedly install any other Adobe products.
For the record:
Windows 64bit removal
regsvr32 /u "C:\Program Files (x86)\Common Files\Adobe\Adobe Drive CS4\ADFSMenu.dll"
Windows 32bit removal
regsvr32 /u "C:\Program Files\Common Files\Adobe\Adobe Drive CS4\ADFSMenu.dll"
Let’s have a page telling this, or even better the option not to install it in the first place. Adobe, if you really, really must install such crap then at least have the decency to provide an uninstaller.
The pity is, I don’t even know what Drive CS4 is. Now I guess I never will.
Just for a bit of fun, a Pixel Bender powered Mandelbrot set. Not great since the Flash player can’t run Pixel Bender loops. Oh well. We can manage a few iterations by unrolling the loop. However, adding too many causes the thing to slow to a crawl even on the heftiest machine. Click to zoom. Requires Flash player 10. [kml_flashembed movie="http://www.flexiblefactory.co.uk/MandelbrotShader.swf" height="160" width="160" /]
I posted this on StackOverflow.com, but maybe one of out readers knows the answer…
Quite simple really:
var req:URLRequest=new URLRequest();
var header:URLRequestHeader=new URLRequestHeader("my-bespoke-header","1");
Yet, if I inspect the traffic with WireShark, the my-bespoke-header is not being sent. If I change to URLRequestMethod.POST and append some data to req.data, then the header is sent, but the receiving application requires a GET not a POST.
The documentation mentions a blacklist of headers that will not get sent. my-bespoke-header is not one of these. It’s possibly worth mentioning that the originating request is from a different port on the same domain. Nothing is reported in the policyfile log, so it seems unlikely, but is this something that can be remedied by force loading a crossdomain.xml with a allow-http-request-headers-from despite the fact that this is not a crossdomain issue? Or is it simply an undocumented feature of the Flash Player that it can only send custom headers with a POST request?
We’ve been looking into some inconsistent behaviour across platforms when making socket connections. An application that works fine in Windows and OSX fails for no apparent reason when running on Linux platforms. After running a WireShark network capture, we established that, after correctly fetching a socket policy from port 843 of the remote host, the data sent to the target port was corrupted when using Linux Flash Player.
It turns out that the culprit is the Linux implementation of
Socket.writeMultiByte, at least certainly when using the “us-ascii” encoding (it’s late and we can’t be bothered to test other encodings).
So, the line:
socket.writeMultiByte("GET somepath HTTP/1.0 \r\n","us-ascii");
fails completely, with garbage getting written to the socket.
We’ve written a naive (and appropriately named) replacement which works for what we’re doing, but doesn’t handle encodings.
private function writeBetterMultiByte2(msg:String):void
It appears that we’re not the only ones having trouble with writeMultiByte, but this time it’s with
ByteArray.writeMultiByte . Something seems quite broken here.