After the dust of HTML5 vs Flash settles, key sites for delivering video while recognising the importance of HTML5 are now publicly endorsing Adobe Flash as the primary vehicle for consuming video on the web. In a new blog post YouTube cite Quality of Service, Syndication, Fullscreen and encoding formats as the main reasons that Flash should continue to dominate Video on the web with HTML5 being a fallback for devices not yet set up for Flash (such as iPad).
Elsewhere Longtail, makers of the near ubiqidous JW Player, are making very similar noises. This is not the end for HTML5 video, but it places it firmly behind Flash for the forseeable future and we can only expect Adobe to continue leading the innovation.
It also includes updates to the BBC’s Media Player and the iPlayer desktop AIR app (which goes to version 2.0). Perhaps the best feature in the new desktop is the ability to subscribe to series which automatically download as long as the app is running and being able to download ondemand content before its broadcasts. Downloaders will be able to watch as soon as its finished on the Box in the same way anyone streaming from the website has done in the current v2.
To get the full picture of all the updates and features watch Anthony Rose’s blog for more details
Previously I took you through some of my thinking and decisions as I created this LinkedList implementation. In this post I’ll give you the final unit tested source along with the unit tests and give you the results of a performance test using Grant SkinnersPerfomanceTest framework
Originally this was a fun challenge for myself, but has come to underline the importance of test driven development. Two iterations of looking at the code still did not flush out all of the bugs. I’ve now fully unit tested the class using FlexUnit 4 and believe it to be working correctly now (thanks to Nicholas Dunbar for some suggestions on the removeItem method).
One of the original reasons for investigating a LinkedList was the claim that they can be much faster than native flash Arrays, so I set myself the challenge of writing one that implements the key Array class members introduced with AS3 (such as every, filter etc), to see how such a data structure could perform against an Array doing what its best at.
A while back Grant Skinner released a performance test tool geared towards treating performance testing in a similar vein to unit testing called PerformanceTest. I figured this would be a good chance for me to have a goog reason to have a play and see what its like.
After 20 minutes of playing (the docs and samples are quite limited – to be fair Grant says as much when blogging about it) I’d pretty much figured out how to put something together that would make my tests atomic and portable.
To begin with I expected it to be something similar to unit testing where you have a TestRunner, with one or more TestSuites, which in turn have one or more TestCases. However, it transpires that PerformanceTest is somewhat flatter than that. You do have one or more TestSuites, though there is no formal TestRunner as such, and it is the TestSuites themselves which implement the methods to test rather than defining a list of TestCases. That said, once understanding the drive behind the framework its clear following such a methodololgy would be a needless distraction for what is in fact a nice tool. Simple is good.
One small bug bear for me is that the TestSuite constructor params are named the same as its protected properties, which normally means that you have to explicitly use the “this” operator to let the compiler know you mean the class member and not the parameter. However, it did not transpire to be an issue as all the params are optional so a subclass need not implement them or make a call to super() when inheriting and if directly composing the TestSuite class the problem is hidden away anyway. If you download the source below you’ll see I opted for subclassing.
The results of the performance test show that my implementation of a LinkedList is on average a little under 3 times slower than the corresponding methods on the Array class. The data below is the result of 5 interations of each TestCase which in turn conducts 10 loops of each MethodTest. Each MethodTest is operating on an Array/LinkedList with a length of 1000 elements. Heres the data:
While this does seem to show that LinkedLists (at least my implementation anyway) do not perform as well as Arrays in the latest VM. It is something of an unfair test comparing a LinkedLists performance with methods intended for use on an Array. LinkedLists are much better where there are many dimensions to the data structure. Where searching a multidimensional Array of unknown depth will quickly require recursion, its quite a trivial matter to traverse a multidimensional LinkedList linearly with a single loop. Its just about using such tools most appropriately for the problem you are trying to solve.
Interestingly the LinkedList’s memory usage was comparable or better than the Array class in the new AS3 methods (filter, forEach, every, some and map). Over the lifetime of a application runtime such additional memory usage will cost a little more in CPU as the garbage collector runs more often, though this is likely to be negligible.
Heres the final LinkedList implementation (the splice method needed the most work):
In my first post on this subject I discussed the pros and cons of using an interface for typing list elements versus using a concrete class. I opted for a interface for greater flexibility and argued that a concrete link node class could implement the interface and overcome the drawbacks of just using an interface.
Today I created a concrete class for just that pupose. The class LinkNode implements ILinkElement and ensures that its possible to have the same object in 2 or more lists without the lists becoming entangled. Removing this risk allowed me to finish adding support for two more of the Array class methods on the LinkedList class; “filter” and “map”. I also went back and completely rewrote the “splice” method after realising I had not matched the Array classes corresponding methods behaviour correclty (or anywhere near it). For consistency I have also updated the class such that any method that returns a new LinkedList always uses the concrete LinkNode class for each item in the list.
In the first part I had a disclaimer saying that I hadnt yet even compiled the code let alone tested it. I have now compiled the classes (there were a couple of typos), but I have not yet tested in anyway so the same disclaimer stands! If / when I find the time I’ll follow up with a final part which provides tested code and benchmarks versus the corresponding Array class member functions.
Linked List implementations are not new in AS3, but I hadn’t got one yet in my library and using them came up at work so I figured I use Bank Holiday Friday to whip one up.
To make it a little more fun I decided to try and mimc as many of the Array class member methods that were added with AS3 (forEach, some, every and the like), plus other more standard methods.
Before starting I had to chose between an interface which defined the required methods for getting and setting link references and a concrete class which had to define a property for referencing the payload of link node (ie the object that needs linking). I opted for an interface to reduce the overhead of one extra object in memory for each linked element, but this method does preclude linking primitive types without first extending them to add the interface.
I quickly realised that array methods that return a new array without modifying the original would not make much sense with a linked list whose items implement an interface. The link nodes in each list are the actual object being referenced across both lists, so the links between items could actually also link across lists, effectively joining the two lists together.
That said theres nothing to prevent a concrete Link class implementing the interface and adding the object property to work round this and benefit from both approaches. The remaining array methods could then take items of the concrete type as params where possible/necessary.
Heres the interface:
…and heres the linked list:
Disclaimer: This was just a bit of Bank Holiday fun, I havnt even compiled this code, let alone tested it. Expect bugs. I’ll follow up in another post with the more final code / extra methods. Feel free to test and suggest fixes.
Wisdom seems to have it that in general Singletons are mostly bad. The actual usecase where you need “one and only one” instance in an application are few are far between. The web is awash with opinion about the pros and cons of using Signletons, that is not my aim here.
This post is aimed at anyone who has built up a library of code over a number of projects and have some useful logic wrapped up in Sinlgeton classes which are being used as the only instance in those apps.
I have a particular Singleton that I have used in quite a few apps and its always been the case that one instance per app is exactly what I needed. In a new project I’m working on I released that I’d like to use the class, but I have clear divisions in my app that would logically take one instance of their own of the class curretly wrapped by the Singleton pattern.
My options here were:
Option A: Rewrite the class as a non-Singleton and face having to refactor my other applications to work with the new way when I come to make a new release.
Option B: Duplicate the logic into another non-Singleton class so I dont break the compiles of my other apps.
Option C: None of the above.
Option A is a pain but at least I could address compile issues on a per case basis when I make new builds, though it will be a somewhat tedious process, and in some cases I actually really do want “one and only one” so the Singleton really makes sense. Option B, would grate… seriously, I would continue to feel sullied until the situation was rectified
So onto Option C. A very simple idea occured to me. What if my Singleton’s default behaviour was to return the one and only instance, but the class could be updated to generate more than one named instance if required. This way all my old apps would go on using the Singleton instance and my new app could instantiate the multiple named instances required without breaking things or duplicating code.
Heres an example:
As you can see the default behaviour of the getInstance() method is to return the Singleton instance, but now the class will also maintain a hash map of other named instances requested via the optional identifier parameter. The class now become something of a self instantiating Factory, but still encapsulates access to the instances.
