Thursday, 19 March 2009

Please help me give away my source code!

I have loads of great ActionScript snippets that I want to share with the Flash community. Unfortunately I cannot get code to appear in any decent way on Blogger. If anyone can help me get the cool snippet window which everyone else seems to have on wordpress to work on my blogger account, that would be sweet, and I will shower you all with great code. (well not that great, I wrote it).

Post answers and links in the comments PLLLLEEEEEEEEEEASE.

Help me Flash RSS junkies, you're my only hope.

UPDATE:
Here is a test of using http://formatmysourcecode.blogspot.com

public static function formatTime(seconds:int):String
{
seconds %= 86400;
var hours:int = seconds / 3600;
var minutes:int = (seconds / 60) - (hours*60);
var secs:int = seconds - (hours*3600) - (minutes * 60);
var timeString:String = ((hours<10)? "0"+hours : hours)+":"+((minutes<10)? "0"+minutes : minutes)+":"+((secs<10)? "0"+secs : secs);
return timeString;
}

Friday, 6 March 2009

10 reasons I prefer FlashDevelop to Eclipse and FDT

I know this is well-trodden ground (e.g. FDT Vs. FlashDevelop on flashmech), but I've finally spent some time with Eclipse and FDT, and to be honest I can't really see what the fuss is about. Of course Mac users don't really have the option of using FlashDevelop (except under emulation), but for PC users, I just don't see the advantage of Eclipse. Obviously the PowerFlasher guys have done a great job on their part, but Eclipse is just too unintuitive for me.

So here's 10 reasons I prefer FlashDevelop to Eclipse:
  1. FlashDevelop is free. FDT is quite expensive.
  2. FlashDevelop starts auto-completing as soon as you start typing. In FDT you have to type "this." to get the auto-completion menu. UPDATE: Sorry, you can also press CTRL-SPACE, but it's still an extra step.
  3. FlashDevelop automatically adds import statements. Eclipse doesn't, as far as I can see. UPDATE: I think it should have done but was badly configured on the Mac I was using.
  4. FlashDevelop's project window automatically finds new files. In Eclipse you have to add the folder manually, then tell Eclipse it's a source folder. UPDATE: Again, this was partly due to bad configuration, but Eclipse convoluted enough to let this happen easily.
  5. FlashDevelop projects can be moved around easily. Eclipse has confusing hidden project files.
  6. FlashDevelop renders fast. Text in Eclipse has a delay before formatting correctly. UPDATE: This is probably down to the beat-up old Mac I was using ;)
  7. FlashDevelop has a cute quick-find search box. I couldn't find this in Eclipse.
  8. FlashDevelop has zero learning curve - I picked it up instantly. I have wrestled with Eclipse for a week and still don't feel I've cracked it.
  9. CTRL + ENTER in FlashDevelop switches to the Flash IDE and publishes. Eclipse doesn't do this. UPDATE: Can be done with a free plug-in. Probably better to use FlexSDK and asset SWCs anyway.
  10. CTRL + the mouse wheel changes the text-size in FlashDevelop. I had to use google just to work out how to change the font size in Eclipse!
If anyone can counter any of these points it would help me a lot, as I have to use Eclipse for the next week, so please leave comments!

Monday, 2 March 2009

Flash development - are you doing it wrong?

Inspired by years of working with Flash and with other Flash developers (ninjas and newbies), here is my checklist of how to do things "the right way" in Flash and ActionScript (don't really know about Flex - you crazy guys do whatever you like!). I really want your comments on this one. Am I way off the mark? Do I go too far, or not far enough? Leave a comment please! Here they are:
  1. Don't use code for layout. If you are setting the position of all your visual elements with code, rather than using the Flash IDE, you are doing it wrong. Designers like to "nudge", "align" and "tweak" layouts, and if you have to change a number in your code and republish the swf for every nudge, then you're probably in for a long night. If you have a data-driven site (e.g. with a variable number of menu items), you may have to do some dynamic positioning, but keep it to a minimum.
  2. Don't write code on the timeline. Why? Because you can't search it, open it in an external code editor, version control it or merge it, that's why! Version control and a decent editor (ie. Flexbuilder, FDT or FlashDevelop) will save you many hours of development. These editors have great auto-completion features, and a version control system such as subversion may just save your job one day - when Flash corrupts your FLA or you accidentally overwrite your whole day's work. The only good reason to write timeline code is calling functions or dispatching events during timeline animations (e.g. dispatchEvent(KICK_BALL) when the animation of the foot reaches the ball), but again, keep it to a minimum.
  3. Write lots of small classes. When transitioning from timeline scripting to OOP, a classic mistake is to make one or two big "god" classes that control most of the functionality. If you're doing this you haven't really transitioned to object-oriented code at all. Each class should do only ONE thing, or to put it another way, there should only ever be one reason to change any of your classes. This seemed very prescriptive to me at first, and I still find it difficult, but I've learned to love it! How long should a class be? Well anything more than about 500 lines seems like it could be broken down more. In any particular project I normally have at least a few classes that are only 5-10 lines long. Think about your project as a set of self-contained components that you could re-use if you wanted to.
  4. Use ActionScript3 whenever possible! I've met a couple of people who are still defaulting to AS2 for "simple" stuff. Er, why? Better to get your head into AS3 mode as much as possible, especially on the easy stuff. How else are you going to learn? AS2 is rubbish! You may still have to use it for some banner-ad networks, etc though :(
  5. Don't use the main timeline to organise the "flow" of your site. I used to swear by this method as a way to organise my sections - creating a separate class for each screen, and putting each screen on a different frame. Move to a different frame and Flash will automatically destroy the old section and create the new one. Easy! Only problem: doesn't work in AS3! It will remove the section from the display list, but it will stay in memory, running its ENTER_FRAME, probably throwing errors, and generally doing the naughty. The solution? Create and destroy all your screens / sections from code - e.g. mainMenu = addChild(new MainMenu()); removeChild(mainMenu); mainMenu.destroy(); etc.
  6. Tidy up after yourself. Keep your FLA tidy. Name your layers, name library items sensibly and keep them organised. Delete empty/guide layers. At the end of the project, delete all your traces, unused code, and any commented out code -they will only confuse you later.
  7. Test extensively. Test driven development for a Flash developer should mean running your swf and clicking on everything really fast until it breaks, then fixing it and doing it again. The more complex the application, the more ways there are to make it do something unexpected, throw and error, or generally crap-out.
  8. Know how good you are. This one goes a few different ways. On the one hand, don't be cocky and let your ego write checks your body can't cash. Don't commit to mad schedules or deadlines. Make sure there's contingency time built into every project, because you can pretty much guarantee something will go wrong at some point. On the other hand, don't be lazy or complacent. Don't look for excuses not to change your code or design. If a colleague suggests an improvement, don't just go "No, it doesn't work like that", but think seriously about the cost/benefit of the idea. Keep improving your knowledge and learning new technologies, because if you don't, the industry will eventually leave you behind. Know what you're worth. If your boss is driving round in a sports car while you do all the hard work, you're probably doing it wrong.
  9. Don't use anything obscure. Sometimes I'll make an update to a project that was created by another developer, and I'll experience some weird behaviour, missing files or unexpected errors, and it will because the developer has chosen to use some obscure feature of ActionScript or the Flash IDE. In Flash CS3, it might be menu settings like changing the view preview quality and everything on the stage looking weird, or turning off "export hidden layers" and half your site unexpectedly disappearing. Everyone SHOULD turn OFF "Automatically declare stage instances" though, as it's very confusing to not have all your variables explicitly declared. Try not to use weird language features and optimisations, like backwards loops unless they're completely necessary. Name your functions and variables with full English words please! That includes writing "event:Event" instead of just "e:Event". How can you search through text for a one-letter variable?!
  10. Sweat the details. Polish counts for a lot in Flash sites, so the more time you can devote to little finishing touches, the better. Consider things like: fading in-and-out on page transitions rather than just jump-cutting from one page to another, adding custom options to the right-click menu, disabling the Tab key, optimising the file size and creating a decent preloader.
Hope you found something useful here - trust me, I've learnt these lessons the hard way! Leave a comment if you agree or disagree with any of them, I want to know what you guys think.