Out With the Old : Tips for ActionScript to HTML5 Migration   2 comments

Over the last few years I have found myself doing the same thing that many legacy Actionscript Developers have been doing. I cringed as Apple single highhandedly hammered the final nail into the coffin of a language that I knew like the back of my hand; a language that I loved to work with and knew all the pitfalls and complexities. And then I recoiled as Adobe themselves started digging the hole (with their disbanding of Flash Player on all mobile platforms). There is no doubt that having your tech fall from favour is not an easy thing to watch or endure. Panic sets in, egos fly, scrambling begins.

Nevertheless. We are developers and we know how to adapt to the next technology- that being HTML5. But where to begin…what are the differences?

Does this sound like you? Never fear! The skills you learned using ActionScript will be put to excellent use. Here are some tips to keep in mind that I discovered while doing the migration:

  • Javascript and Actionscript are both based off the same standard that everyone loves, ECMAScript…so your syntax will not change. In fact, I have worked on migration projects which consisted of mainly copying large blocks of Actionscript into a JS file and running it🙂
  • Having said that, there are some differences. Javascript doesn’t support classes per say (it is a prototype based language), but you can think of them the same way. Instead of developing custom classes, you develop custom objects (which are written like functions) that you can instantiate to your heart’s content in the same manner as classes. When teaching Javascript to my students I usually have them assume they are classes in the beginning stages of learning to make the learning curve less steep.
  • There are hacky ways (but at least it is possible!) to mimic most of the object oriented techniques you are use to using such as class variables, overloading, etc.
  • Javascript is not strictly typed like Actionscript which is the biggest difference, but it is highly recommended that you declare all variables anyways to avoid variables living in the global scope by accident (taking up resources) – you will be tempted to put everything in the global scope in Javascript since it is so easy to do so – resist! In fact, if you want to force yourself, look into the Module design pattern (check out http://www.yuiblog.com/blog/2007/06/12/module-pattern/)
  • You can still construct and dispatch custom events in Javascript; a technique that was invaluable in Actionscript particularly for game development. See http://www.kaizou.org/2010/03/generating-custom-javascript-events/
  • In terms of graphics, say good bye to Movieclip and SimpleButton objects. You are going to need to look into either using bitmap blitting (painting?) from spritesheets to a canvas element or drawing your graphics on the fly through code (Scalable Vector Graphics)
  • Your Flash IDE isn’t going to collect dust though! It is still the best tool for generating your spritesheets (game animations). It is almost as if Flash has gone full circle back to being predominately a really good and versatile animation tool. Look into http://transport.to/spritesheet/ which is an AIR app that will take movieclips setup with linkages in a SWF and output spritesheet images.
  • The engine that runs Javascript in modern browsers is not the powerhouse that the Flash Player is – learn to code your game/app so it runs efficiently. Check out these great articles on code optimization: http://jonraasch.com/blog/10-javascript-performance-boosting-tips-from-nicholas-zakas and http://www.developer.nokia.com/Community/Wiki/JavaScript_Performance_Best_Practices
  • There are loads of great frameworks to help you out – look into the createJS suite (http://www.createjs.com) which is written by Grant Skinner (an Actionscript junkie himself) and team. They have re-introduced all the familiar concepts of Actionscript into Javascript such as DisplayObject, Shape, and Stage. Not only that but this framework takes care of a lot of the nasty details of preloading assets and spritesheet rendering to a target canvas (see point above) so you can get right into building that game or application.
  • Compress your code – since javascript is an interpretted language. I once read that even comments in your code can slow it down – not sure of the truth in that, but better safe than sorry. Check out http://jscompress.com/
  • Test often and on many different browsers. We have been spoiled by the consistency of the flash player runtime across all browsers. Javascript does not enjoy such luxuries so you want to make sure your code works correctly in all your targeted browsers and platforms while you code, not during beta testing.

After spending the better part of two years exploring HTML5, I can say that I have cut the cord to Adobe Flash…migration isn’t easy, but a necessary evil and hopefully this list will help some of you get started and moving in the right direction.

Posted June 6, 2013 by morrowsp in Uncategorized

AIR Mobile Game Development : 14 crucial tricks I wish I knew earlier   2 comments

I have just spent the last year and half developing my first mobile game entitled “Nano!”. It’s a silly little game about the internal war that goes on within our insides between white blood cells and bacteria/viruses. But this posting is not about the game, but about what I learned from it. I was looking through my list of resource links and realized that I tapped into the knowledge of tons of different articles and online resources to get to this point in the development. In order to make sense of the amount of stuff I’ve learned I wanted to compile it all into a single document…and why not share it? So, the following is a list of tricks about mobile game development using Adobe AIR (that I wish I knew when I started!):

1) Code optimization is key

There are loads of articles on the web concerning this topic, and rightfully so since it is the most important. The truth is that the AIR platform is not native to any mobile platform and thus does not run as speedy as we are use to seeing it run on desktop computers. This has sparked a programming renaissance in my mind where you have no choice but to program as elegantly and efficiently as possible. I don’t consider myself a sloppy coder, but all us programmers tend to get accustomed to the luxury of power and speed that our desktops provide. I’ll get into many of the details of how to optimize AIR games as I move further through the list.

2) Bitmaps are back in / Vectors are out

Which brings me to the most important topic. As mentioned, mobile devices don’t have the processing power that we are use to – and vectors are just too intensive for them to handle while maintaining a decent frame rate.  When I first developed Nano! I went about it the usual way, leveraging all the power of the Actionscript API that I have been accustomed to which included using display objects. When I ported my game onto a mobile platform I died a little inside as I watched it sluggishly achieve only twelve frames per second of the targeted twenty four. [Insert crying here] There is nothing worse than debugging game frame rate issues.

White Blood Cell Sprite SheetThe solution was to kick it back to the old school method of Bitmap Blitting. This is a process of which you archive all the animation frames of all your game elements (or sprites) into giant images called sprite sheets. When your game starts up you then splice it up into smaller bitmap images (one for each frame) and cache it into some sort of data structure. You then setup ONE giant bitmap and drop it on the stage via the familiar addChild(). I like to refer to this bitmap as the “stage bitmap”. When a sprite needs to appear and be animated onto the stage you then copy (see copyPixels() method) the smaller bitmap from the cache onto the stage bitmap at the desired location. It is kinda like painting each individual frame of each game element onto a giant canvas that makes up the stage of your game. Of course, you do this on every frame, changing what bitmaps you copy to the stage bitmap on each frame to create your animation. This technique takes a large amount of setup, but if you develop a good robust system to handle it you can use it for all animation throughout the game – and possible for future games as well!

Check out these great articles on the topic:

You can easily convert movieclips into sprite sheets using this tool:

3) Say good-bye to hitTestObject() and other display object methods

Obviously having the visual display of your entire game now being handled by a single bitmap puts an ActionScript developer into an uncomfortable position. Because each game element isn’t represented by a display object on the stage, many of the techniques/methods we love no longer apply; the most prevalent being collision detection. Once again mobile application development has forced us to revert back to the golden age of game development where you need to rely on other techniques to carry out your collision detection; usually involving a whole lot of math (don’t panic!). For Nano! I was able to get my collision detection working effectively using the radius testing technique, but bitmaps themselves do have the ability to detect collisions with other bitmaps in Actionscript. however, in my experience I found it too taxing and slow; especially if you use a single stage bitmap as mentioned above.

Check out these great articles on the topic:

4) Don’t rotate or scale bitmaps

White Blood Cell Move ClipIt is expensive. If you need a sprite on your stage bitmap to rotate then you are pretty much forced into making a really big- ass sprite sheet with all the animations at all the required rotations. For Nano! my white blood cells contained a 12 frame “moving” animation. But I also needed the white blood cells to be able to rotate. That’s a whopping 12 x 360 = 4320 little frames on a single sprite sheet. Not going to happen. Not only will it eat up a huge portion of the memory of the mobile device (another thing they are limited on) but will also make the startup of your game be painfully slow as you blit each little frame of the giant sprite sheet. The solution is to compromise but not make it obvious to your player that you compromised. I setup my white blood cell to rotate every ten degrees instead which gives us a sprite sheet with a reasonable 12 x 36 = 432 frames (see image).

5) Pick your processor

On mobile devices you can have your game use the GPU or the CPU. In my experience, the GPU will take care of anti-aliasing your stage bitmap and make everything look nicer, however it doesn’t handle the “crunch work” that most games require as well as the CPU. I actually flip-flopped between the two throughout the development of Nano! but finally settled on the CPU. Regardless of the processor your choose, you are going to need to keep a close eye on frame rate. Be sure to display the current frame rate on the stage while testing so you can see any fluctuations. A great reference for this is http://active.tutsplus.com/tutorials/actionscript/quick-tip-how-to-build-a-frame-rate-counter-in-actionscript-3-0/

6) Object Pooling

I’m a sucker for internal structure when it comes to programming, and building a game is no different. Despite the fact that my game no longer has display objects for each game element does not mean that I abandon object oriented design altogether. In Nano! I still constructed an object for each game element to keep track of its behaviour, status, etc. The only difference is that I didn’t add the object itself to the displaylist. But all this construction of objects during game play is expensive. So how do you get around that?

The solution is to construct all your objects at game start up and then recycle them during the game. This is what object pooling is all about. You create a pool of objects before the game even starts and then when the game is running you merely pull objects out of the pool, use them in the game, and then return them when you are done. As a result no objects are constructed (or destroyed) during game time and this ultimately improves the performance (drastically in my experience).

Check out these great articles on the topic:

7) Event listeners are evil

As it turns out the glorious event model of Actionscript 3.0 is a pig when it comes to resources and processing. If you implement the bitmap blitting approach I suggested in trick #2 you should only need one enterFrame event listener (I always call it the “game loop”) to refresh the stage bitmap and possible a small number of event listeners to handle user interaction. Gone are the days of having each object have its own enterFrame event listener to keep track of its own behaviour. The code design was nice, but it is just too heavy.

8) Avoid the beloved timer

They are resource pigs as well. Use your single enterFrame event and counters to create the same functionality.

9) Manage that Memory

Make sure you clean up ALL references to all objects that need to be garbage collected. If you implement object pooling there will be less of this to do🙂

10) Have your game take a breather

Multitasking is king on mobile devices. Phones ring, emails are received, etc…there are lots of things to pull a user away from your game. You need to take the time to ensure that your game will pause as well as throttle down its frame rate (to lessen battery consumption) when it is minimized. The AIR framework provides some events and methods  (Event.ACTIVATE / Event.DEACTIVATE) to do this but there could also be some approaches in your target device’s API that are specific to that device.

11) Textfields are like turtles

They creep along. Avoid using them at all costs. One tactic is to use bitmaps of individual letters (or numbers in terms of a scoreboard, for instance) and blit them to the main stage bitmap in the correct order much like the rest of your game elements. For Nano! I ended up building a little method that takes the score stored in a variable and positions and blits the bitmaps for each number in the correct order on the main stage bitmap to create the visual reading for the user. This is, incidentally, how scores were displayed in games back in the beginning of it all🙂

12) Understand the Elastic Racetrack

The Elastic Racetrack

Image from the article ‘Elastic Racetrack’ for Flash 9 and AVM2 by Sean Christmann

ActionScript is not multi-threaded so we are stuck with all the code and rendering for each frame to be done within the time limit of the frame. If our game’s frame rate is set to 24 fps then all the code in your enterFrame event handler (and method calls) needs to be completed as well as all the required rendering onto the main stage bitmap within 42 milliseconds. If the runtime needs longer then that it just extends the length of the frame accordingly (kinda like stretching the frame time like an elastic) causing subsequent frames to be dropped in order to catch up.

For the user this means lagging which SUCKS in a game. So what can you do about it? Don’t do all the work EVERY frame. For instance, in Nano! I have only half the collision detection tests being done on one frame and then the other half on the next. This spreads all this heavy processing across two frames ultimately making it less likely my frame time will be stretched.

Check out these great articles on the topic:

13) Optimize, Optimize, Optimize

There are a number of things you can do to your code to make it run more efficiently. Most of these changes will provide small improvements, but they can really add up:

  • Use int datatype instead of Number where possible – int takes less memory
  • Use for each loops instead of for loops whenever possible – they run faster
  • Use Vectors opposed to Arrays – the elements of a vector are data typed and thus will be retrieved faster
  • Minimize method calls – I love coding in a modular fashion so I break this rule all the time; but definitely you should avoid calls to static (class) methods as much as you can (like Math.floor()). They are really slow.
  • When you construct objects or arrays do it literally not through the new keyword – for instance var tempy:Object = {}; will get constructed a lot faster than var tempy:Object = new Object();
  • Don’t use the length property of arrays/vectors within for loops – store the length in a variable and then use that variable instead like this: var myLength:int = stuff.length; for (var n=0; n<myLength; n++) Grabbing the length property from an array or vector on every iteration is taxing on the processor
  • Avoid the push() method for arrays – add new elements to the end of the array using the index instead

14) Release Me!

Publishing your AIR app in release mode will make it run significantly faster than in debug mode. For true testing on your target device, make sure you publish in release mode.


That’s it! I hope these help. As well, the following resources have provided me with a wealth of knowledge on many of the tricks listed above as well as some I haven’t mentioned – hopefully they will help you out as much as they helped me:

Happy coding…🙂

Posted May 31, 2012 by morrowsp in Actionscript / AIR

Laying it all out on the Tablet…   Leave a comment

There is no doubt that web application development has branched onto mobile devices (ipad, iphone, android, blackberry, etc) with a new way of interfacing (touch screens – rollovers are irrelevant!). As a result, many of us are switching our developing minds into this new arena. As an instructor I am constantly making sure that I am teaching relevant material to my students (hence my whole struggle with the flash/javascript), so it was inevitable that I would be picking up a tablet for the first time and seeing what I could do with it. I thought I would share my thoughts.

  • I used a Motorola Xoom Tablet running Android 3.0 Honeycomb for my first attempt at tablet development. This is currently one of the fastest/powerful tablets on the market, so I don’t feel like a lot of my issues were due to the hardware.
  • I have to admit that I am disappointed with Android. I want to really like this mobile OS, but it feels like it was put together in a hap hazard and sloppy manner. Perhaps Google was in such a rush to get it to the masses that they were forced to cut loads of corners?  I don’t have a lot of experience using iOS on the tablet, but I do own an iTouch and from my understanding it is very similar. I can say that I feel like iOS is much superior. This isn’t too surprising as Apple has had a number of more years to polish it, but also, Apple doesn’t generally let stuff out that isn’t perfect (“it just works”). Perhaps it would have been better for Google to adopt this ideology.
  • Many of the applications that shipped with Android are riddled with bugs and poorly limited options (email client can only show the last month of emails? That is stupid!). The browser, for instance, doesn’t handle pop ups very well (I can only open the first one), and both Javascript and Flash don’t execute. I did a whole lot of “Is it is doing anything?” after clicking (touching) a link. On top of that, many flash apps out there aren’t designed to handle touch based interactivity and do weird things when you interact with them.
  • I had to “force quit” more applications on Android 3 the first day of messing with it than I care to mention :S
  • The process of programing an App for the Android OS is fairly straightforward. An API is provided and developers can use their beloved Java.
  • Where the issue lies is in the packaging and deploying. It is a painful process involving lots of front end setup and batch file executions. It is not straightforward…it could be easier? I know there are a few tools that will streamline this, but it needs lots of work.
  • The Android emulator is so slow it is borderline useless. My test machine is relatively good…and I could not effectively test my apps on it.

Keeping in mind that Android 3.0 is relatively young (it was only released a few months ago), I know that future updates may address some of these bugs and issues. But the consumer base is fickle and this could definitely hurt Google’s presence in the tablet market. 

Posted May 20, 2011 by morrowsp in general topics

Deploying Adobe AIR Apps on Android 3.0 Emulator with FlashDevelop   3 comments

Android Emulator Screen

This is what my SWF looked like running in the emulator

This is a quick one to help others avoid hours of useless digging to get this to work. I’ve come across all sorts of documents on this subject, but of course many of them are lacking in detail and direction…so I wrote my own document to help me whenever I need to set this up.

To start you need loads of stuff:

Once you have everything above, follow the long setup instructions below. Hopefully this will get other developers up and running a lot quicker than I did🙂


> follow these steps:
(1) copy the template for android Apps into flashDevelop v3.3 (or greater)
> this template will be used by flashDevelop to setup a project accordingly
> when you go into flashDevelop and create a new project "AIR AS3 Projector for Android" appears as a option

(2) unzip Adobe AIR 2.5 SDK into a common folder
> I usually put it in the tools folder of flashDevelop but it can be put in the Flash Builder SDK folder

(3) install Flex 4.5 SDK into a common folder
> note this will already be installed if system has Flash Builder installed

(4) install Android SDK

(5) there are several tools (exe) throughout these SDKs that may be needed via command line so it is best to add them to the path (via environment variables)
> add path to bin folders of the AIR 2.4 SDK (one to "bin" and another to "lib\android\bin")
C:\Program Files (x86)\FlashDevelop\Tools\airsdk\bin;
C:\Program Files (x86)\FlashDevelop\Tools\airsdk\lib\android\bin;

(6) create a new android project in flashDevelop (under projects in menu)
> all android tablet apps should be at a resolution of 1280X800

(7) start the android emulator
> should be android 3.0 - API Level 11 (this is honeycomb, the tablet version of the os)
> add the cache parition size:66MB to the hardware
> add the device RAM size:1000MB to the hardware
> enable the snapshot; this saves the state of the android OS image when you shut down; slow shut down but faster startup

(8) create a self signed certificate
> in order to install an AIR application onto android (or any OS) it must have a self-signed certificate (digital) created
> edit the CreateCertificate.bat file (this batch file creates it)
> change the path to point to the AIR 2.5 SDK bin folder
set PATH=%PATH%;C:\Program Files (x86)\FlashDevelop\Tools\airsdk\bin;
> this is so the path is set to have access to adt.exe; this creates the Adobe AIR certificate as well as verifies it
later when you go to install the app
> adt.exe documentation: Adobe AIR Documentation on adt.exe
> change the name, password, and filename of the certificate
set NAME=testy
set CERTIFICATE=SelfSigned.p12
> run certificate and it should create a p12
> this only has to be done once for each project
> do not rebuild the certificate once you start developing or you will need to clear out the app from the android emulator snapshot

(9) create an APK
> this is the package that all android apps are distributed as
> it is this that will be installed on the android emulator
> edit the APK_PackagerApplication.bat file (this batch file creates it and uploads it to the emulator)
> set the path to AIR SDK binaries (one to "bin" and another to "lib\android\bin")
set PATH=%PATH%;C:\Program Files (x86)\FlashDevelop\Tools\airsdk\bin;C:\Program Files (x86)\FlashDevelop\Tools\airsdk\lib\android\bin;
> this is so the batch file has access to the adt.exe and adb.exe tools
> adt.exe is used to verify the AIR app in order to install
> adb.exe installs the AIR app on the android OS
> set path to the Adobe AIR plugin that needs to be installed onto the android device before your app
can run; of course this is an APK and can be found in the AIR SDK folder
set AIR_INSTALLER=C:\Program Files (x86)\FlashDevelop\Tools\airsdk\runtimes\air\android\emulator\Runtime.apk
> note that I am pointing to the emulator version of the AIR Installer APK
> set the certificate to be the same name as the one you built previous
set CERTIFICATE=SelfSigned.p12
> set the APK to be the name you want it to be:
set APK_FILE=apk/testy.apk
> as long as your emulator is loading from the snapshot, then you only have to install the Adobe AIR plugin once
> therefore you can comment out the following lines by adding "::" in front:
:: Install on android device. Comment lines if you don't need.
:: echo the program will install Air runtime on android emulator
:: echo.
:: :: pause
:: echo.
:: adb -e install -r "%AIR_INSTALLER%"
:: echo.
:: if errorlevel 1 goto androidFailed

> after you run this batch file you should see your application in the MyApps section...run as per normal

> there are multiple ways that this process can mess up; but I find restarting the emulator helps along with making sure
it is running properly
> you can check to see if the emulator is running right by opening a command window and entering "adb devices"
> if you don't see your emulator in the list of android devices you need to restart the android server
> enter "adb kill-server" to stop the server and "adb start-server" to start again
> restart the emulator after doing this and try to deploy the APK of your app again
> most trouble will occur when using the APK_PackagerApplication.bat
> you will only deploy your app in the emulator at various times during testing; too slow to use for every test of your app

Posted May 9, 2011 by morrowsp in Actionscript / AIR

Battle of the Client Side Techs : Flash vs. Javascript   1 comment

It was about fifteen years ago. The internet was still in its awkward early teenage years. HTML was just starting to take form, the silly media still referred to the web as the “Information Super Highway” (duh!), and email really only meant you could contact complete strangers from far away places and ask them stupid questions (I actually had a welsh pen pal for awhile). So why the nostalgia? Because this was when I picked up my first book on Javascript.

It was a visual quickstart book that I had borrowed from one of my professors, however, it is still sitting in my bookcase at home today so I guess I actually stole it. Nonetheless, Javascript introduced me to a world where visual design, information, and interactivity could all be meshed together. I remember thinking that this was so much better than the apps I was building for my computer science courses. There is nothing more dull than building an application that simulates the file system of DOS with ASCII characters on the screen. I was desperate for something more creative. After a quick read I was hooked on Javascript and all the doors it opened in website development. I ended up doing a lot of cool things with it (things JQuery can now do with one line of code) and even made a few bucks on some contracts for the university in the process.

But as it goes in the IT industry, things changed. Flash technology came along and pushed Javascript to the side; and rightfully so. Flash was not only brilliant at web based animation (it was originally conceived as a web animation tool), but as it evolved its embedded scripting language become more and more powerful. This grew the Flash platform into a serious web application development tool. What can you build with it? There isn’t much it can’t do. Advanced game development, slick interfaces for web applications, etc. These were all standard affair when it came to Flash. And if that wasn’t enough, other tools that leveraged this power were added to the mix as well. The Flex framework was introduced to enable developers quick construction of Rich Internet Applications. AIR was added to enable desktop development with Flash. And so it grew in popularity. And with my love for “creative development”, I naturally embraced flash with open arms. I worked and toned my flash development skills over the span of ten years on various projects in the industry. I built e-Learning software, real time games, precise science simulations, and online tools for my students. After all these years I can say I know flash technology very, very well. And as all developers can relate, you tend to love the technology you know.

The IT industry is just like love – it is fickle and it forces you to make changes. The open source movement, coupled with a decrease of support for flash technology among many industry clients (thanks Apple) has forced me to start researching other avenues.  Many of my students have been telling me about the power of Javascript over the last few school years, but I couldn’t imagine taking what I perceived as a giant step backwards in client side web app development. Nevertheless, I kept an open mind and dabbled in JQuery (an open source javascript framework) and made a few quick little apps to see what it could do. I was impressed, but it was really over the last few weeks that I have dedicated myself entirely to seeing what Javascript / JQuery / AJAX / and the HTML DOM have to offer. More importantly, I was interested in seeing how it ranked against Flash.

Step I : Converting a Simple Flash App Over To Javascript
I decided to start with converting a Rich Internet Application that I had developed using Flash into one implementing Javascript instead. This “portfolio” app was a class sample I use when I introduce students to the concept of dynamically generated XML (via server sided script) to populate a client side interface. Simple is always the best place to start…
Simple Portfolio RIA done with Flash
Simple Portfolio RIA done with JS

What did I learn?

  • I used Javascript, AJAX, and the HTML DOM to implement this application and it was surprisingly easy to get up and running – Javascript has come a long, long way!
  • Converting it over was much easier than I had originally thought – in fact, many of the lines of code in the Javascript version are exact duplicates of the Flash version. This isn’t too surprising since both languages are based on the same ECMA standard.
  • There was no difference in speed between these two apps.
  • The workflow for developing Javascript RIAs would definitely be much nicer for many developers since you are back using nice and cozy HTML / CSS for interface design (unlike the steep learning curve of flash’s timeline, symbols, etc).
  • AJAX works really well and is just as good as the URLRequest / URLLoader classes of the AS framework.

Step II : Ramp it up! Converting an Advanced Flex App Over To Javascript
Ok, we might be on to something here…but this is a simple application. Let’s ramp it up. How about adding different views of the portfolio data and a progress/loading screen, etc? And while we are at it, let’s see how close it can match the functionality of a flash based application that was built using the powerful flex framework:
Advanced Portfolio done with Flex
Advanced Portfolio done with Javascript

What did I learn?

  • For this sample I had to start using JQuery heavily. Although JQuery is a powerful framework, I find that I was most comfortable mixing some HTML DOM / Javascript concepts with it; however, it is not necessary. You can write entire applications without ever using traditional Javascript.
  • JQuery is clearly designed to be a rapid development language, and as a result its syntax is highly recursive in nature in order to do a whole lot in less lines of code. I could envision it being somewhat difficult for some new learners to grasp at first.
  • Having said that, JQuery is a godsend when it comes to targeting elements in your HTML; no need to mess with the getElementById() method all the time🙂
  • Many of the effects added to this application would not have been possible without the JQuery framework – not without losing my sanity that is…
  • Every piece of functionality that I implemented with Flex could be redone using JQuery / Javascript – I am very impressed!
  • This application included dynamically added elements to the “view all” view; although not done in an object oriented manner, it was still straight forward to implement
  • Once again, no difference in speed between the two apps

Step III : Alright smart guy, what about an administration end?
The next logical step was to give AJAX a real run for its money by building a simple administration end. In order to do this I needed access to some new controls – but I am only limited to the controls of HTML, right? Wrong. JQuery UI comes to the rescue by providing a handful of new controls beyond the limitations of the <input> tag. Note: For security reasons this application does not actually update the content in the database – you’ll have to trust me that it works😉
Portfolio Admin done with Flex
Portfolio Admin done with Javascript

What did I learn?

  • JQuery UI provides a very powerful set of controls that not only are very versatile but can also be skinned using an online tool that outputs a stylized JS and CSS file – and the Accordian I decided to use for the Javascript version is quite elegant in its design and functionality. This control certainly rivals many of the rich controls offered in the Flex framework.
  • AJAX handles sending XML just as nicely as receiving it
  • In order to handle the live validation (something my flex version does not have) I had to actually go into the plugin I used and modify it. This isn’t uncommon in the flex framework as well, although I found working with JQuery plugins a lot easier since they aren’t dependent on multiple class files in a big long inheritance chain. I should note that messing with JQuery plugins is definitely not for the faint of heart😉
  • Much like all the samples done so far, the code in the Javascript app was pretty close to the Flex app in both structure as well as syntax in most cases

Step IV : Apply it and dive into the deep end!
So far in my research Javascript technology has proven to be quite versatile and powerful and in all cases it measured up with Flash technology. But could it truly replace it? I needed to test this idea out. Over the years I have built many flash web applications, so it was really a matter of choosing one that would put Javascript (and my brain) through the gauntlet. I choose the event slider application I had developed for a local organization using flash technology. This application consisted of a sliding collection of company events that the user could explore. It was the perfect test as it incorporated XML fed data, loads of animation and effects, and a good level of interactivity.
Event Slider done with Flash
Event Slider down with Javascript

What did I learn?

  • There were some serious challenges in developing this application. I used four separate plugins, and not one of them could be used as is – I have always found this with pre-built components. They don’t quite work exactly the way you need them to work and you are forced to go into them, figure them out, and tweak them. This process was somewhat daunting at times and I have to admit that during most of the development of this application I was wondering if it could actually be done…but I did succeed🙂
  • Cross browser tweaking was a pain and was something you don’t have to think about when using Flash. The flash player is the same no matter what platform you are on and you can therefore be sure that your SWF will always work. Javascript on the other hand is at the whims of the browser’s interpretation and we all know just how much browsers disagree with each other. W3C standards has tightened the gap up nicely, but I still uncovered a number of issues that had to be dealt with on a one by one basis for different browsers.
  • The engines that run Javascript in some browsers are painfully slow and do not even come close to the speed of the Flash Player. For a while I had the event slider running perfectly on google chrome, but it would take up to 1 minute (along with the browser begging me to let it timeout) before it would load the XML and construct all the “blocks” of events on other browsers. I ended up fixing this by analyzing which functions were eating up the most cycles (one function took 37000 ms to complete!) and adjusted my code (just a note that the innerHTML property is a processor pig!). On top of that, it still doesn’t run as smoothly as I would like on Firefox and as of the time of this writing I am yet to test it on a MAC (I’m afraid to :S )
  • Javascript, although supports objects, does not support classes which is a big step backwards in terms of re-usability of your code and could hinderance some developer’s code structure practises
  • On the other hand, this event slider will now work on apple mobile devices!
  • All the hype of HTML 5 is kinda lost on me now. Besides the new <video> tag I don’t see any advantage since you can implement a lot of the cooler features of HTML 5 using XHTML 1.1 and JQuery / Javascript.
  • Firebug and Google Chrome Debugger tools are your best friend. Otherwise when you have a problem with your Javascript code the browser does nothing but stare back at you blankly.

My conclusion is pretty simple. Javascript technology has aggressively evolved throughout the years and is now a very powerful client side technology; largely due to the open source community. Eventually browsers will recognize that Javascript has become a pinnacle component of any webpage experience and the engines will speed up. Meanwhile, the W3C will continue to push compliancy making the cross browser development issues a thing of the past. But what is to become of my beloved Flash? Is this a flash killer? I don’t think so. As impressive as all this is, I believe that Flash will still reign in the web based game development arena for some time. As an instructor it makes sense to shift my delivery of flash technology into this discipline. But change is never an easy thing to do…especially with a technology that you love. But sometimes you have to set it free…😉

Posted May 5, 2011 by morrowsp in web development

Faceless : The Shift to Teaching Online   Leave a comment

After spending a number of years teaching IT courses in a traditional classroom you tend to get dependent on many communication devices. Raised hands, confused looks, scribbling diagrams on the white board, pointing at computer screens, and even asking a student politely “Can I drive” while taking his/her mouse and demonstrating a concept to them right on their computer screen. Now imagine a teaching environment where none of these things no longer easily apply. A place where there are no more faces, confused or otherwise. This is the world of teaching a course online.

Over the past four months I have embarked on teaching my first online course with the Nova Scotia Community College. This introductory course is entitled Flash Fundamentals covering the basics of Adobe Flash design and development. Flash Fundamentals is a course I know well as I have delivered it on campus for a number of years, so I wasn’t terribly worried about the content. What I was worried about was if and how my teaching style would translate over this new medium, and ultimately, would I be any good at it?

These are just a few things I noticed:

Uhmmm…Dead Air…Uhmmm…
One thing I wanted to make sure I added into my first online course is a weekly live online session with all students attending (virtually that is!). A weekly session really helps build confidence and fight the feeling of isolation that many students in online courses battle. Surprisingly, I also found that it was also a great social device for the course as many students took this time to get to know each other.

Sound all great, right? The down side is that running a live online session is kind of cross between being a radio DJ and a live television producer. At NSCC we use a tool called Elluminate to hold live sessions which has all sorts of features like a live chat window, microphone support, and a virtual white board. As a moderator of the session, you find yourself juggling several things all at once. Firstly, you have to make sure that there is no dead air so that the flow of the session is smooth. Lesson flow is an important issue to me as a instructor as I believe that if a lesson’s concepts flow together logically and smoothly the connections and learning happens a lot more naturally. Secondly, while you are doing that, you have to continually monitor the classroom chat window, the whiteboard, as well as answer any questions coming in through the audio. It is sort of like digital juggling, except when you mess up balls don’t go everywhere; instead there is just a disjointed lesson that confuses more than helps.

You Need To Be Always On…
Teaching in a traditional classroom setting involves all sorts of lines of communication, but naturally, the most predominant is your class time with your students. This is that dedicated slice of time during the week when you have every student’s undivided attention (we hope anyways). In an online course you either no longer have this time or it is hindered greatly by the online technology. As a result, all other lines of communication that are usually secondary suddenly are predominant to the success and understanding of your students. Email, web boards, etc. become a major life line for all students. Unfortunately, these aren’t always the quickest means for a student to communicate with his/her instructor. Not to mention that for students that are really struggling with the course’s concepts the wait times between a question and an answer can be excruciating. As a result, I find that you really need to be monitoring these communication lines a lot – every single day. Going even a mere two days (like a Saturday and a Sunday) without checking in is equivalent to a student asking you a question face to face and you sitting their mute for two days looking uninterested before responding.

A Large Toolbox is Confusing for Anyone…
Technology has been the main reason online courses are possible today. And although it has made leaps and bounds over the last decade, I would still say that it is only about 60% of the way there. Problems with microphones, lagging internet connections, etc. have all occurred during my first online course. But the biggest issue I see is that although there are lots of applications that help in their own small way, there is no application that does it all. As a result, students have to learn and use a large collection of applications and tools, many having their own logins, quirks, and setups. For students who are weary about technology in the first place this can bury them before the course even really gets going. My advice is keep the list of applications as small as possible! Pick the ones that cover all the minimum requirements you need and work within those restraints. The not so techno-savy students will thank you for it.

Be a Dictator of Your Online Course…
Speaking of multiple communication tools, I have found that as an instructor you need to control the online course experience as much as possible or confusion can result. A good example is using a webboard. During my first online course delivery all the students had permission rights to create their own topics as well as add replies to any existing topics. The problem with this is that at any given time there were multiple topics on a specific lesson or concept each containing their own replies…the web board quickly began to get cluttered and confusing for students to even use effectively to find answers. I found it is best to limit topic creation permissions so that only I could create them. This way the webboard is kept much more tidy and kept as efficient as possible.

Snuggle Up With A Good Book/Resource…
As a result of missing out on that face to face instruction, quite often it is much easier for a student to become confused over a topic or concept. This is why it is really important to have a well written secondary resource to act as a backup for students when they need elaboration or help on a topic. I like to choose actual books as my resources mostly because it allows each student to review or go over concepts away from a computer. Since online courses require a high level of computer usage, I think of book resources as a nice break from the glare of the monitor. Something that everyone needs (even me) from time to time😉

Posted June 24, 2010 by morrowsp in general topics

Adobe, Stop Spilling the Milk!   1 comment

I remember being a kid and in a mad rush to grab a hand full of cookies, pour a glass of milk, and run back to the TV before the commercial break was over…my father would always exclaim “Slow Down!”, and sure enough…there was always spilled milk.

It seems to me that information technology is moving in the same careless pattern. Technology companies are churning out new versions of their software at such a dizzying rate that there is a real disconnect from quality.

One company that seems to be the greatest offender of this is Adobe…I have been a college instructor for seven years and since then Adobe (Macromedia to a small extent) has released six versions of Flash…that’s right…six. Flash MX, MX2004, 8, CS3, CS4, CS5, blah, blah, blah! I understand that the IT industry is pretty ruthless and cutthroat (Steve Jobs), but there is real value in providing time for the development community to become efficient with a technology before new stuff is added to it again; or it is completely overhauled. Flash CS5/Flash Player 10 is riddled with inconsistencies with ActionScript behaviour, timeline glitches, and general weirdness. In fact, it is so bad that the animation department on my campus is seriously looking into other alternatives for 2D animation.

So, dear Adobe…get some patches out, fix these issues…and in the words of my father, “Slow Down”! Developers don’t appreciate spilled milk.

Posted June 8, 2010 by morrowsp in general topics


Get every new post delivered to your Inbox.