David A. Molanphy

I have recently been engaged in a fun experiment for a touchscreen using Actionscript and the Twitter API. It has been a fantastic learning experience in many ways, including AS3, object oriented programming, and above all, usability. There are some things worth mentioning: 1. Making a virtual keyboard for a touchscreen is much more tedious than I ever dreamed. I have gained the utmost respect for whoever designed/developed the iPhone's keyboard. Much has been said about its functionality and its surprisingly usable interface. I have tried to re-create a similar experience using it as my main point of reference and continue to be amazed at how well designed and though out this aspect of the iPhone is. It has been the seemingly little details that have made me stumble the most (i.e. showing the user where the carat is as a visual cue of where the next letter will land, or even something as simple as a shift key). 2. Twitter's API is a blast to play with - particularly for those interested in data visualization. But none of what I have done so far would've been possible without Sandro Ducceschi's (@_sandro) excellent Tweetr library for AS3. Even though it is still in heavy development, I have been able to implement any API call I can think of, including the new lists feature. Major kudos to Sandro for his dedication to this library and for keeping it open source! Yes, there is also the Twitterscript library, but I have found Sandro's work to be infinitely more usable. 3. Touchscreen technology introduces a whole new set of rules to be mindful of. With the lack of hover states for interactive elements, the feedback loop becomes a trickier thing to implement and consider. The lack of the mouse as in input method is both liberating and frustrating at the same time - as something as simple as scrolling becomes a challenge to design and code for. 4. The power of object oriented programming is becoming more and more clear to me as this experiment progresses. Encapsulation and inheritance are both concept I'm still trying to wrap my head around, but I see the clear benefits they bring to any coding project. One of my earlier complaints about oop and AS3 was that I felt that writing a simple action for a button took me twice as long as it did in AS2. Such a small detail compared to how much power oop can bring to your code. 5. And finally, I am now more confident than ever that understanding how to build and program an interactive experience opens up a whole new realm of design possibilities. So much, in fact, that I have been unable to settle on a final interface design for my experiment because I keep realizing I can push it further. Thank goodness for deadlines!

It's been some time since my last post. My apologies - I have been sucked into the Twitter vortex which I find fascinating to be honest. I mean, whodda thunk that 140 characters could reveal so many brand insights! But that's a different post altogether. Today I'm sharing some tips that I learned from Todd Dominey's Twitter feed (@tdominey). For those of you who don't know Todd Dominey, you'll certainly know his work: SlideShowPro - the completely ubiquitous (and awesome) Flash slideshow gallery. Both tips are AS3 specific, and oh so helpful. Tip 1: A simpler trace function I can't tell you how many times I have had to type long, convoluted trace statements to see if whatever I'm working on is doing what I think it should be doing. Usually those trace statements look something like this: trace ("array item " + i + ": " + my_arr[i]); which would turn out something like this: array item 0: blue array item 1: red array item 2: green You'll notice a lot of plus signs and quotes and stuff. Well, instead, try replacing the + signs with commas: trace ("array item ", i, ": ", my_arr[i]); Though it's nothing truly magnificent, I find typing commas vs. + signs is much faster and easier to understand. Tip 2: A simple for loop for arrays This one is also quite simple in its function, but saves a lot of typing. Instead of looping through an array with a for statement, like so: for (var i:int = 0; i you can use this: my_arr.forEach(myFunction); so long as myFunction accepts the right params: function myFunction(element:*, index:int, arr:Array) { trace (element, ": " , index); } Pretty nifty eh? Yeah, I thought so too. Thanks @tdominey!

Quick AS3 tip that may be self-explanatory to most of you out there, yet stumped me for a while. In AS2, if you set a variable on your main timeline and wanted to access it from inside a movieclip, all you would need to do is call it by name. AS2 would then proceed up the scope chain looking for the variable by name. First, inside the movieclip, then on the parent of the movieclip (in this case...stage). AS3 is a little different. Say you declare a variable on your main timeline like so: var my_arr:Array = ["one", "two", "three", "four"]; Then you place a movieclip on your stage, and INSIDE your movieclip, you want to reference my_arr (which is on the main timeline, or the movieclip's parent). Back in AS2, you would simply type out my_arr, and Flash would automagically find the variable as it searched the scope chain. In AS3, however, if you type this (again...inside the movieclip): trace (my_arr); or even trace(this.parent.my_arr); You would get this error: 1119: Access of possibly undefined property my_arr through a reference with static type flash.display:DisplayObjectContainer. Well, to avoid this little annoyance, you can try a strict coercion like so: trace (MovieClip(this.parent).my_arr); I wish I knew the exact reason as to why this behavior exists, but I do have my suspicions and theories in case you're interested. What I believe is happening is that in AS3, the movieclip doesn't want to assume it knows what its parent is. In fact, as far as it's concerned, it only worries about whatever is in it, or "below" it (the concept is called encapsulation). Anything outside of it (or "above" it) is basically anybody's guess and unless you specifically tell it "your parent is a movieclip," it doesn't make any assumptions. Again, that's my own theory - so if anyone out there knows the real reasons for this behavior (or even a better way of handling this) - let us know!

I recently got upgraded to CS4 at work and for the most part, the many changes that have taken place in Flash have been pretty cool. I'm having trouble adjusting to the new interface (in particular, having the timeline be at the bottom of the screen vs. the top). Many of the changes have been requested for years - like more AfterEffects integration, 3D, etc. And to be honest, Adobe has delivered some pretty cool new features. Now for the bad news. As is always the case (or so it seems), every major release comes with its own baggage and behavior that isn't so welcome. For me (and many others), it's the new CS4 help system – or lack thereof. It turns out that the folks at Adobe decided that if you're looking for help, you should be going to their servers — you know...those slow snail-paced things that adobe.com is hosted on — and get your answers there. The help that we've all grown accustomed to is now gone, and to quote Bentley Wolfe, an Adobe engineer "The old help format is gone, and not coming back. Sorry." Nice. So there you have it. If you're like me and use the help files constantly as a reference while developing in the Flash IDE, stick to CS3. Otherwise, if you don't mind waiting for the slow server to load, then finding the right section, then searching for a class or function, then sorting through irrelevant search results until you find something the resembles what you're looking for, then realizing it's not it and starting another search, and finally finding something that is already confusing to begin with...well then, be my guest. :) More on CS4 later. [ update ] Well, thanks to David Stiller in this thread, I now at least have access to the local help files when pressing F1 - though it still opens in a browser. Here's how you do it: 1. Go to Window/Extensions/Connections 2. Click on the context menu (upper right-hand corner) 3. Select "Keep me offline" 4. You're good to go. Now when you press F1, the browser will open and look for the local files.

As mentioned in my previous post, some things about AS3 are finally beginning to click. Others are still dark and murky, but we are all fortunate to have lots of smart people figuring things out and posting them online for the rest of us. In an effort to further their efforts (and to document some of these things for myself so I'm not hunting for them frantically next time I forget them), here are some simple tips I have found:

Stage=null

I ran into this one today. I was trying to preload a swf into another swf and everything seemed to work fine, except when I tried to simulate download speed so I could preview my work. As soon as I tried simulating the download, AS3 would spit out this cryptic error: TypeError: Error #1009: Cannot access a property or method of a null object reference. Which translated into plain speak means: Stage = null. The error happens because on the swf I'm loading, I have several references to the stage (such as stage.stageWidth, etc). Well, since nothing has been added to the displayObject yet (I'm assuming), AS3 is kindly pointing out the error of my ways. Problem is, I need to figure out the width of my stage as soon as my movie starts! Google to the rescue: Mark Ledford explains in more detail what the problem is - but more importantly, here's the fix (which was actually posted by Steven Sacks – in a somewhat arrogant tone I might add): if (stage == null) { addEventListener(Event.ADDED_TO_STAGE, onAddedToStage); } else { onAddedToStage(); } private function onAddedToStage(event:Event = null):void { // init code that requires stage }

Clear out an object

I can't remember where I found this one, but the problem/solution is simple. Say you need to make sure an object has only one child (and for some reason it has something in it already). Simply clear out the object with this: function clearObjectChildren(which:Object):void { while (which.numChildren > 0) { which.removeChildAt(which.numChildren-1); if (which == null ) break; } }

onReleaseOutside in AS3

One of my gripes about AS3 is that many simple concepts were replaced by ridiculous complexity. Such is the case with the onRelease function that used to exist in AS2. If you're looking for it in AS3, good luck. It's gone. So what do we do when we're dragging something (like a slider) and want to make sure it stops dragging correctly? We add an eventListener to the stage. (random, but it works). slider_mc.buttonMode = true; slider_mc.addEventListener(MouseEvent.MOUSE_DOWN, mouseDownHandler); function mouseDownHandler(e:MouseEvent):void { var bounds:Rectangle = new Rectangle(0, 0, 100, 0); slider_mc.startDrag(false, bounds); stage.addEventListener(MouseEvent.MOUSE_UP, mouseUpHandler); } function mouseUpHandler(e:MouseEvent):void { stage.removeEventListener(MouseEvent.MOUSE_UP, mouseUpHandler); slider_mc.stopDrag(); }

Using names

Another big difference between AS2 and AS3 that took me some time to figure out was instance names. In AS2, you named everything on the stage (and off) using instance names or variables. In AS3, if your item is physically on the stage (i.e. a movieclip you created on the stage), you can still reference it by instance name, however...if you are creating an object dynamically, you will need to implicitly add a name to it like so: my_mc.name = "my_mc"; So if you need to access an mc by name (because you're not sure what number it is in the display line), you can look for it like this: some_mc.getChildByName("my_mc"); Makes sense really. So those are some of the things I've learned so far. There are plenty more, but I'm gonna stop while I'm ahead and put some more up later. Hope this helps someone out there. :)