Useful Flash Tracer Class

Let’s be honest, Flash’s trace functionality is pretty substandard. It provides no useful information besides what you’ve asked it to output. Unlike something like HaXe, you cannot extend it or extract anything from it that really helps you debug your code and when you’ve got a lot of traces in your application or project, it becomes messy and incredibly hard to manage. A while back I created and we’ve since been using a utility class that makes tracing much more user friendly and provides some additional information and functionality that would seem obvious to have in the first place. Additionally, it was important to me to have something that is lightweight and easy to use, with no need to install anything extra – just a class/swc for inclusion in your project, and no additional dependencies.

Firstly, you are able to toggle all of your traces on or off in a single line of code – no need for additional compiler settings. Secondly, the traces that are output include both the name of the class that has made the trace call as well as the line number it happened. This is hugely beneficial, particularly when you are working on a big project with a lot of traces dotted throughout your code. You’ll immediately be able to distinguish your different trace statements and can head to the exact line that you made the call, and if you want to remove the trace statement, you know exactly where to find it. Third, it provides the option of adding in a timestamp to your traces. This aids in keeping track of when things happen and what amount of time has elapsed between different calls to the trace function. Lastly, the traces can be toggled on and off at runtime, which can be very useful when you need to deploy a debug version to a live environment, but don’t want your traces showing up to inspectors like Flash Tracer and the like, unless you’ve specified it to do so.

The class is very easy to use. To initialise it, simply call its static function “init” (most likely in your document or preloader class), and specify whether you want traces on/off, an optional timestamp flag, and optionally set the stage for keyboard capture:

Tracer.init(true, true, stage);

After this, you can just make calls to the static method ‘out’ to output trace statements:

Tracer.out("This is a trace");

If you have specified the third parameter, stage, in the init function, you can toggle the debug mode on and off by pressing the keys of the word “debug”.

Source code and SWC can be got here.

Flash today

Flash has always had its naysayers. I have been a developer for many years now with a strong focus on flash, and have repeatedly had to defend myself against the onslaught of anti-flash sentiments. Many have been valid, and many have been based on an expression of other things entirely. With the history of flash starting in the animation timeline and silly gotoAndPlay scripts that were used to make some incredible shockers, it’s no wonder that it had such a bad rep to shake off. These days, however, the language is robust and its features are many, the community is huge, the spread is wide and the results are truly amazing. But still we have to fight, and after the recent developments over at Apple, even more so now than ever. But the question is not really about fighting for Flash, it’s about why we should have to fight for Flash.

Apple’s non-Flash stance has been around for a while, but most people were convinced that they would one day open up full support for Flash. With the release of the IPad and it’s demonstration displaying huge craters of non-Flash bits of web, it has become pretty clear that this is not to be. Steve Jobs has made his position pretty clear and developers and digital agencies are left with some serious decisions to make. Strictly speaking, whether Flash is dying or not shouldn’t be much of a concern. Many users aren’t interested in what technology they view their content on, as long as it delivers it well and in an interesting way. As far as I’m concerned, bar a few ideological points it is not important for me whether I need to develop in Ruby, PHP, Flash, Silverlight, HTML5, Objective-C or whatever else. I have some preferences about some languages, but often find I like some languages for certain aspects. Because of this, if Flash were truly dying, it would be a simple matter – move on to the next thing.

The major issue in the current climate is that Flash isn’t dying, or at least it isn’t doing so any time soon. Previously, with the fight between Silverlight and Flash, there wasn’t too much going on, because it was simply a matter of installing the right plugin and you could view your content on either platform, so if an agency focused on Silverlight, no problem, if they focused on Flash, no problem, if they focused on Unity, no problem. The user experience would be much the same. And as it stands right now, Adobe’s CTO Kevin Lynch, mentions that Flash’s latest player will deploy to many devices including “Google’s Android, RIM’s Blackberry, Nokia, Palm Pre and many others across form factors including not only smartphones but also tablets, netbooks, and internet-connected TVs”, and its lack of presence on Apple devices is because Adobe has “not had the required cooperation from Apple to make this happen”, but they “are ready to enable Flash in the browser on these devices if and when Apple chooses to allow that for its users”. With Apple’s active stance against Flash-support, the situation is now different to before. Agencies cannot ignore the fact that the content they deliver to their client’s userbase might not be viewable if they focus on a single target. This isn’t entirely new, and agencies have often had fallbacks in the event of their content not being viewable in a particular way, but the impetus for this has been raised quite a bit now.

The way I see it, it is just a great big pain that we are now forced into specific platforms. With Flash still going very strong, and with its much superior capabilities to HTML5 as well as being a much nicer language than something like Javascript, it still offers some of the best ways for us to deliver content to users. So we will keep using it. But with its blatant ommission from certain platforms like the IPhone and the IPad, we are now forced to duplicate our development practices simply so we can satisfy a market that predominantly doesn’t care or know whether they view their content on Flash or not. And this is all because Apple is following in the footsteps of Microsoft and closing the doors to everything else. I find this utterly annoying. The unfortunate outcome of this is that it will cost more to have your content delivered to your user base, because it needs to be developed and targeted to multiple platforms.

As it goes, though, I am still very excited to be developing for new platforms and in new languages. I just wish Apple didn’t compromise their users and complicate developers’ lives by preventing certain things from working on their devices – it just doesn’t feel great. But their choices won’t be affecting things too much for quite some time. Flash still dominates and is a remarkable, certainly among the best, tool for delivering rich interactive experiences, whilst Apple’s devices are not ubiquitous enough to be a true Flashkiller, as quite a few have ventured to say. Many markets in the world have hardly any Apple devices, so for now, Flash development can carry on as per usual.