Travels into the land of mobile app development

Recently at work (I work as a junior developer at Team Cooper), I was asked to look into mobile development using Flash and AIR. I was really excited about being given the opportunity to look into mobile app development, especially for a job. It’s something I’ve always been interested in, but never got around to doing. So being paid to do it makes it double the fun!

I say “fun”, but it’s been an excruciating process so far. While there is a lot of related information and content on the internet, it’s mostly for older versions of the Flex and AIR SDK, so a lot of the time I run into problems when trying to get things working. Throw into the mix that I’m working on a three year old Mac mini, and it’s a nightmare situation. While I’m on the subject of Macs, I must say: I really don’t understand why people who use them rave about them so much. At first I thought it was because I wasn’t used to it, but having used it for the past month, I can honestly say I don’t understand them at all. It does things in such strange ways and makes things incredibly difficult to achieve. I can set up a web server program in a matter of minutes on a Windows machine, but with OS X on a Mac, it’s needlessly difficult – even though it comes with Apache installed!

I digress. Well, not really. The Mac is integral to my journey as it’s what I have to use at work. We use Eclipse with the FDT plugin for writing Flash games and applications. However, we use a slightly older version of FDT, so to avoid any conflicts, I downloaded and installed the latest stand-alone version of FDT.

And I hit my first problem. Running FDT gave me the error that JVM 1.5 wasn’t suitable for the program and that it needed 1.6. No problem, I thought. Updating Java on OS X seems to be much more difficult than it needs to be. The updates weren’t coming up in the software update, but I managed to find some on the Apple site which I downloaded and installed. It didn’t work. I set the default version of Java to be 1.6, but it just didn’t want to recognise it. I managed to get FDT to load up by going into it’s application contents and editing the Eclipse ini file, setting the required Java version to 1.5. Huzzah!

Hang on a second… There was no FDT perspective. I guess it’s the FDT perspective that needed the Java 1.6 environment. This led me to more Googling, and I found an older build of FDT for Carbon. I downloaded and installed it and it worked straight off the bat. The FDT perspective even decided to show up! Now I could get rolling!

Having never used AIR before and being fairly new to AS3 and Flash development outside of Adobe’s own Flash CS series, I didn’t really have a clue where to start. I began by importing the project for the game I would try and port to mobile devices. It seemed like a good first step. Having Googled and read up on both AIR development and development for mobiles using the AIR SDK and run time, it became evident that I would need a newer version of the Flex and AIR SDKs provided with FDT. I downloaded the latest version of the Flex SDK, 4.5.1, which comes packaged with AIR 2.6. This is good, as a lot of the things I read talked about merging the Flex and AIR SDKs. However, this caused my project to come up with error signs all over it. After a bit of unsuccessful Googling, I consulted my colleague who informed me that there had been some changes from previous versions of the Flex SDK and the the Flex SWC was now called Core. I went into the build options and set this all up and the error signs were banished.

So I had my project all set up, with the SDK I needed to use also correctly set up and engaged. The next part gave me quite a lot of trouble just because I was new to AIR applications and how to package them. And also due to the fact that I was learning AIR through articles that were specifically for creating and deploying Android applications. After lots more Googling (I did a hell of a lot of it), I found numerous articles with ANT scripts that would supposedly do the leg work for me. I downloaded one and tested a couple of the scripts which created and deleted a folder structure. They worked fine so I assumed the rest would, too. I jumped straight into setting up an AIR app descriptor file with everything I needed and edited the ANT script so that it would work for me. I ran the script to package it as an AIR app, and encountered another problem with the dastardly Java.

Once it hit the stage of calling the mxml compiler, I got an error about having an unsupported major.minor version (49.0) and after more Googling deduced that there was nothing I could do about it. So I fiddled around a bit and finally figured out how to package up the AIR app straight from FDT. Once this was done it was a matter of packaging up the APK file for testing on an Android mobile device.

At this stage (after 2 solid days of Googling), my head was pounding and I could barely see straight. I did a lot more Googling and found, again, that there were ANT scripts and that, actually, it was the normal and recommended way of doing it. I tried some of these, but hit the same problem of unsupported major.minor version. Eventually, I found a page on the Adobe docs that described the syntax for compiling an APK file through the command line using ADB. Command lines scare me, but at this point, I was willing to try anything. I wrote out the command and, peeping through my fingers, I tapped enter.

Error, it said. Error. I’ve seen that word so many times in the last few days. However, I plodded on. It was an issue with the icon assets not being included in the package. After more Googling returned nothing, I turned back to the ANT scripts and noticed some extra arguments. I attached those on to the end of my command line command and…

Warning: Permissions for your app have not been set.

But it worked! It output an APK file! In my head I congratulated myself and called myself a genius. But only in my head.

Once I had the APK, I whacked open the Android emulator and installed the AIR run time and the game onto it. Yes, it ran slower than a snail with broken legs. Yes, the orientation of it wasn’t set up right. Yes, it was even running so slowly that the emulator thought it wasn’t responding. But it was running! And I’ll be damned if that’s not an achievement.

As an afterthought, I managed to install the emulator run time of AIR on my HTC Wildfire. Wildfires aren’t able to run the device run time, due to its ARM6 processor, but the emulator version is able to be installed. I then sent over the game to be installed on my phone and lo and behold… it ran! Again, it ran slower than a sleep walking turtle, but it was running on my phone! Then it crashed and I left for the day.

So my journey has begun, and I’m sure it will long continue. It’s been a stressful couple of days, but a couple of days that will ultimately be very rewarding, both for myself and for my work.