Lots of Screens with a Little Code

Posted by on January 19, 2011
 

A few months ago I had the opportunity to attend AdobeMAX. While I was there at Adobe’s invitation, I took it upon myself to chat with smart people from all over the community. One of the more interesting people I tracked down was Christian Cantrell. As a Developer Advocate and Product Manager for Adobe part of his job is to build applications, experiment, and use that experience to help guide product development. But the interesting part is that he come up with demos like “One App, Five Screens”:

Me: What motivated you to create the video?

CC: When we first started talking about getting AIR on mobile devices, I was a little skeptical about the idea of writing one application that would run everywhere. Not only is it a technical challenge (primarily in adapting to different screen sizes and resolutions), but I was also afraid that a single application might not give users the kind of experience they are accustomed to having on their specific devices.

The more I thought about it and experimented, the more I realized that there probably wasn’t going to be one single way that developers would build applications for all the different devices we support; rather, the approach to cross-screen development would be dictated by the project itself. Games were one area where I thought applications could really work well almost entirely unchanged across devices, so I decided to create iReverse as a proof of concept. To be honest, I was even surprised by how well the project has worked out.

Me: What changes did you make to support each of the devices?

CC: Almost none. For Adobe AIR for TV, I added support for the remote control (which is really just keyboard events), and I had to write a little additional layout logic in the TV project “wrapper” to compensate for overscan in order to make sure the game board was rendered entirely on-screen. The rest of the code just follows multi-screen best practices like doing dynamic layout in stage resize events, checking for capabilities like the accelerometer before using it, and trying to stick with APIs that are available to as many profiles as possible. The rest of the platform differences are pretty well contained in the individual projects’ application descriptor files.

Me: What was the easiest part in development?

CC: Adding new platforms was surprisingly easy. I used the desktop version primarily during development, and I can honestly say that I experienced almost no problems at all when running iReverse for the first time on other devices. Thanks to the best practices and the architecture I used, it just worked. The only issue I ran into was when the Adobe AIR for TV team ran it on a set-top box for the first time. Since the game only supported touch and mouse events, everything ran fine, but there was no way to interact with it. I spent a couple of hours adding keyboard support (while testing on the desktop), and when I sent it back to them, it worked perfectly.

Me: Where did you have the most problems in development?

CC: It took me some time to work out some best practices and to figure out a good architecture to use. I built some simple prototypes before I started on iReverse to make sure the concepts were solid, but once I had it all figured out, it was just a matter of writing the code. iReverse was the first game I ever wrote, so there was a little learning curve in terms of figuring out things like game logic and the computer player’s AI, but that had nothing to do with multi-screen development.

Me: What resources or tips would you suggest to someone attempting to develop their first cross platform app?

CC: I would probably start with the Adobe Developer Connection. There are a lot of good articles posted about multi-screen development (including more information about iReverse) and links to all the best blogs to follow. The technology is so new that the first round of books isn’t out yet, so getting information online is probably your best bet.

If you want to learn more about cross platform development with AIR or about Christian’s work in that area, don’t hesitate to visit his blog, Adobe Developer Connection or sign up for our upcoming class Essential Flex for PHP Programmers.


About the author—Keith Casey has been a developer for over a decade and helps organize various tech communities. Previously, he was a professional agitator within the Washington, DC until he decided to explore Austin, TX in 2010. To pay the bills, he works as a Developer Evangelist for Twilio to get good tools to good developers so they can build great things. Previously, he built large-scale PHP-based systems for organizations ranging from major news companies to small non-profits. In his spare time, he is a core contributor to web2project, works to build and support the Austin PHP community, co-founded the HubAustin coworking space in South Austin communities, blogs regularly at CaseySoftware.com and is completely fascinated by monkeys.