I started experimenting with flash and the iPad this week since Adobe has finally confirmed that they will resume development of their iOS Packaging Tool.
First things first, here are some of the pieces of documentation that I found helpful getting started:
- Adobe Flash Platform – Mobile/iPhone Documentation
- –ActionScript 3.0 APIs unsupported on mobile devices!
- –ActionScript APIs specific to mobile AIR applications
- –ActionScript 3.0 APIs of special interest to mobile application developers
- Packager For iPhone – Developer FAQ
- Packager For iPhone – Release Notes
- ActionScript 3.0 APIs unsupported on mobile devices!
Initially I ran through the simple example outlined in the packager documentation to build an app with the Flash application, which I was very quickly able to build and install on the iPad to test.
Since I do the majority of my development building Air applications in .as within Flash builder (on a mac) my next step was to build a similar test app from Flash Builder using the console based tools that Adobe has provided. The tools are great, but would be difficult to use at this stage for non console savvy users. Most of the developers I know could handle them, many could not.
After I got a base example together, I quickly jumped into trying to migrate Germz from a desktop-based AIR application to a native iOS app. I ran into a lot of roadblocks–mostly due to unsupported API’s (see link above for documentation on this).
Here are some of the things I discovered that might help other developers:
There are a Lot of language elements that you might typically use for development that are not implemented for mobile development.
-Loader.Load() – Many of us use this to dynamically load .swf content and then run and control embedded classes or access assets. Even if your files are local to your project, you can not use the Load() command.
-NativeWindow Anything – In developing Air applications for the iPad (all I have tested), you must use the default window and can not access the NativeWindow API or stage.NativeWindow. Accessing this during your initial application load will brick your application and result in a solid white screen on the iPad.
Debugging Any Unsupported API Calls Bites.
It would be great if the Flash Builder IDE could target the mobile platform and tell us that there are elements that are not supported and let us know. Thus would have saved me a lot of time in debugging, as even when creating a running air project in Flash Builder–once it compiles to an iOS application it will fall back to a blank white screen when loading if you attempt to access any unsupported libraries.
It would have been great if the compile to debug process were able to help with this, but so far my best debugging tip for other developers–if you have a white screen on your target device, look for any Unsupported API’s that you might have used.
At the end of the day, I am pretty excited about the prospects of developing multi-platform applications within Flash that will build for both desktop and mobile environments. While I would love to have the luxury of mastering two development environments, I am very happy focusing on ActionScript 3 and the Flash Platform. I appreciate the effort that Adobe has made to allow our projects to cross over into Apple’s walled garden.
As I refine my process for building iPad applications, I will likely write a series of simple shell scripts to automate my build and compilation processes. Keep an eye open for a future update with some downloads that might help you as you begin experimenting yourself with building Flash for the iOS platform.