On Porting from iPhone to Netbook with Flex – Understanding the Syntax of ActionScript and MXML

by Ryan Green

I’ve spent most of my career on the web. Well, my first real job was as busboy at a local mexican hole-in-the-wall restaurant (love the salsa.) Then as proud crew member of a certain fast-food burger joint with golden arches (click here to skip to the meat of this post), then, as up and coming young web designer. It is amazing the job you could land in the dot-com bubble with some decent photoshop know-how and a copy of Microsoft Frontpage…

Flex BurgerAnyhow, what I quickly learned in my stint as web master, besides the art of pixel perfect nested HTML table layouts so that my webpages could load inside the 1990’s on a 28.8 baud modem, was that if you wanted to give your customers any value besides a relatively accurate re-creation of their 4 page full-color brochure, you needed to know databases and some form of server side scripting.

I chose Cold Fusion. At the time this was due to the fact that it was the only book in our little office that didn’t have the letters ‘CGI’ and ‘Perl’ in the title. Cold Fusion provided some nice tag based syntax for connecting with a database and displaying tractor parts in a webpage. Then came Javascript and DHTML and VBScript and PHP and then, at last, Actionscript 1 & 2.

Now, lest you fear I die a quick death stuffed to the gills with obscure scripting language knowledge, Actionscript 3 arrived with Flex just in time to spare me the wrath of Java nerds hailing the death of ColdFusion and other “non-languages.” The language of the User Interface has steadily matured into Object-Oriented like syntax and smarter uses of XML to define the UI, and the “real-programmers” have moved native with Objective-C/C++/C#/C-flat and C#-minor. Oh, and don’t forget Java on that little mobile platform called Android… and how dare I forget ruby and python.

All this to say that, in this day-and-age, we face a fragmented amalgamation of languages and platforms all vying for title of “most-awesome-real-language.”

Well, my nomination for new entrant into the “real-language” lexicon is Actionscript/MXML, a syntax that gives Javascript its Object-Orientation and the HTML tag actual namespaces and custom tag names.

Sound Design in AppUp Games and Apps

by Matt Fox

When we set out to make G: Into The Rain, we came to understand that sound design was an area we did not want to neglect. This is not to say that we were immediately aware of the importance of having good sound. In fact, to be honest, we knew that G was going to be first deployed on the iPhone. The on-board audio playback hardware on the iPhone is not exactly high quality – unlike the netbooks which we eventually ported G to late in 2009. During the development, we started to realize that we weren’t necessarily tied to one platform, and that devices like the netbook could impart a much richer game play experience in terms of sound.

In the early conceptual phases of our development, we decided to have a look around at the games that we all liked. Sound design wasn’t something that jumped out as a priority. Frankly, the first non-visual game element that most people notice is music; and while we were blessed with a very talented composer for the musical score of G, that is a topic for another post. Sound, as a game element, is often overlooked. If you ask many people what they enjoyed about a particular game or application, more often than not you will hear about how they liked the gameplay, or that the art was stunning, or that the storyline moved along really well, or that they really liked (or hated) a particular character. Sound design, or rather good sound design is not something that is in your face. It’s subtle, and most often it’s only really noticed after the visual. For instance, when you walk into a room, unless there’s a buzzsaw running, most likely the first thing you’ll notice is what it looks like. We are visual creatures, and hearing most often is employed after sight.

Now I don’t want to convey the idea that because we’re primarily visually oriented, that good sound design can be left for the back burner. Quite the contrary. When we looked around at the games that we all liked to play, we started to catalog and attempt to define what it is that we enjoyed about those games. Eventually, we began to pay close attention to the sound design. In doing so, we had to look beyond the iPhone, and plan accordingly. We came to the conclusion, that one of the reasons we liked the games we did was because of the sound. In most cases, it wasn’t an obvious, in-your-face sort of revelation. Sound was used here as a way to augment the look and feel of the games. Looking ahead, we made the choice to take sound design seriously – which is especially vexing considering the less-than stellar (external) speakers on the iPhone. But if we had taken the approach that “nothing will sound good on the iPhone” and had half-hearted sound design, then G certainly wouldn’t have sounded as good as it does now on a netbook.

On Porting from iPhone to Netbook with Flex – Interacting with the UI: Cocoa Delegates and Flex Observers.

by Ryan Green

Today we explore the emerging zeitgeist of two companies that I love. I submit to you that embedded in the very code of their developer SDKs lie the underpinnings to a complete corporate world view. I know, profound stuff. I thought so myself while typing this in the airline terminal of Denver International Airport while waiting for a friend to arrive. Perhaps I’ve waited too long and those funnel cake sticks from that other burger chain have started to affect my brain chemistry. We shall see.

Interacting with the UI: Cocoa Delegates and Flex ObserversMy new working theory is derived by examining the use of patterns in the User Interface components of Cocoa and Flex.

Exhibit A: Apple believes the world and developers must be controlled and well managed. This is why the primary pattern for talking to User Interface (UI) Components is the delegate pattern. The delegate pattern means that when a user does something to a component, like clicking on a Picker, that Picker UI Component delegates responsibility to a delegat-ee. In other words, the Picker tells the delegate what to do and when to do it. There are a few benefits to the use of this pattern. Delegates clean up well (memory-wise), delegates have a clear and predictable function, and there is one and only one responder for any action by a UI component.