Category: Uncategorized

Speaking at NAB: Game and TV Collaborations

I was asked, agreed, and received confirmation that I will be speaking at the NAB conference in Vegas this month. The presentation/panel is titled “Game & TV Collaborations” and is focused on solutions that integrate games with video based entertainment. I will be showing off the Playstation Megasode that we built a few years back and participating in the subject discussion.

The presentation is slated for Thursday April 23 at 10:15.
You can find all the details here.

It should be quite interesting presenting at NAB, since the crowd is so different than a lot of the places I speak. It also marks my first attendance to the event, so I’d love to hear feedback from others that have attended in years past.

BUG: Flash Google Analytics trackEvent

Today I was integrating with Google Analytic’s Flash codebase and ran into a bug that had me running up against a wall for about 45 minutes. It was a simple bug, but no details bubbled up from the code base to let me know what was occurring. I’m noting it here for everyone else’s sanity. If you want to skip all the details and just know the cause jump down to the end of the post.

I had set up my analytics package all via code and made a simple track call.

For the sake of this example, it looked equivalent this


// setup tracker
 var tracker:GATracker = new GATracker(this, "UA-111-222", "AS3", true);
// make simple track event with a numeric value
 tracker.trackEvent("MyCategory", "MyEvent", "Title1", 10.5);

Very simple right? I had followed examples online and on the surface it all appeared to work correctly. I could see the calls in the visual debugger working exactly how I wanted. However, when looked to see if the calls were going to the server with a packet sniffer, no dice! Nothing was going through. I checked my code about 500 times, looked to see if trackEvents were just beta, and tried to find out if I wasn’t setting something for production.

I couldn’t find anything. It wasn’t until I switched the call to trackPageview that it started to go through. That worked. I decided to take the numeric value out of the call for the trackEvent call, since that was a variant between trackEvent and trackPageview. Ching, ching, little winner. Everytime I added it back in it failed silently and didn’t call the server. I then noticed that the number was a fraction and not a Integer (even though the call’s signature has it as Number). Therefore I decided to round the fraction everytime, and triple ching, we had the final winner.

The bug turned out to be that trackEvent can only take Integers as the numeric value in it’s call. If you make calls using trackEvent you must round all numbers going in or the calls will not be sent out to the server.

Hope this helps with some folks headaches. Also if you ever have a bug with no details, follow the example above and work backwards. Looking at variants and testing multiple inputs you can find the root.

Event type naming: qualifying vs simple

I have put a lot of thought into event naming recently. In my research, I’ve seen a few developers fully qualifying their event type names. This is something I actually debated myself when writing our Media Framework, but opted not to do. The subject is debatable, so let me describe what I mean by fully qualified names and why I decided not to use them. Based on the points I outline you can make your own decision of whether to use them yourself.

What is a fully qualified event type name?
ActionScript 3 has a formal event framework where objects dispatch events and others subscribe to them and react accordingly. Each event dispatched is represented by an event object. All of the native AS3 event objects follow a formal convention of defining the types of events they can be dispatched as. This convention places a static constant representing the type name directly on their class to allow for strict typing. For example, Event.RESIZE denotes an event type of “resize” for the object. The property value itself equates to a simple string. In all native AS3 objects these strings are simple and only represent the action (ex: “resize”).

Some programmers are actually fully qualifying these strings. Instead of Event.RESIZE representing the string “resize”, it is equal to “”. Now why do this? Well say you had another event ComponentEvent which had a resize event. If you fully qualified it as well, you would have ComponentEvent.RESIZE equating to “”. Notice that now both events could be thrown from the same object and subscribed to distinctly. If they both represented the string “resize” then you would run into cases where you thought you subscribed to one event but would potentially receive both.

Why I chose not to use full qualifed names
Even though fully qualifying the string that represents the event type resolves subscription conflicts, for the most part you can resolve them just by prepending your event’s name to the type. ComponentEvent.RESIZE could be “componentResize”. In a sense this allows you to qualifying it without having a very long unique string. This is what I opted to do. One of the reasons I did this was for less advanced users and for code spiking. Simply, if you want to do things fast, it is easier just to type in a short magic string when listening to an event vs actually importing in the class and typing it out statically.

foo.addEventListener("componentResize", this.onEvent);


foo.addEventListener(ComponentEvent.RESIZE, this.onEvent);

Yes, this is kind of the lazy approach and one might also say its bad practice since without strict typing it could result in a “magic error”. However, I do it when I’m trying to spike an idea real fast, and I know others do it as well. I’d even venture to say designer/developer hybrids are especially prone to use it since it serves as a comfort concept they brought over from ActionScript 2. It is a practice that exists and I can’t say whether it is right or wrong.

In summary, fully qualified event types have a purpose and serve their purpose well. In our case, we wanted to take into account developers who were used to exploiting existing conventions. I feel even bad habits have advantages if it creates productivity, so the coin toss resulted in a choice not to take them away.

What are your thoughts?