Base Mobile Tasks .ane and a Few Tips

Admittedly (and rather pathetically), it’s been so long since I’ve posted anything on this blog, I’ve nearly forgotten how. I am still around, however, and still, after the innumerable deaths of Flash over the past decade and a half, primarily an Actionscript developer. Being an Actionscript dev these days, though, really means being an AIR developer. And being an AIR developer, really means being a mobile developer. And being an AIR developer who works on mobile apps means at the very least occasionally getting one’s hands ‘dirty’ writing native code packaged as an Adobe Native Extension or .ane.

If you’re reading this (for the most part) Flash blog and don’t know what an .ane file is, I’ll just assume you’ve been living under a rock and just move on.

Having worked on several (Android only) ane files at work now, I thought I’d share a few tips and tricks I’ve learned along the way. Some of these are Android specific and some generic.

• Don’t package support files in your ane. If you are writing an ane (just for example) for Google Analytics, by all means include the GA sdk code. But if your ane requires, say, the Android support v4 .jar leave it out. And never freaking ever package Adobe’s FlashRuntimeExtensions source. When using multiple ane files in the same project, conflicts will occur when doing this and it is a horrible headache to try to sort it all out. Instead, if your ane has dependencies, package them in a separate ane file (or files) and inform users to use them all if they don’t know otherwise. If they do know otherwise, they’ll be so happy to leave out what they don’t need, they could give you a big hug.
• Android Intents and Intent Filters are awesome. If you’re an Android dev, you’re probably just staring blankly or shrugging your shoulders, but having recently discovered them, I’m in awe. They are a breeze to use and can do things like open other apps, pass data around between apps, be used for deep linking inside an app or a combination of all of the above or more. Enjoy them.
• Watch your target and source attributes when compiling your java classes with ant. I’m not sure why (words a programmer hates to say – code isn’t magic, after all), but when compiling java source with a javac ant target and the source and target attributes aren’t set to ‘1.6’, your ane will fail every time. And the only indication you’ll get is that the extension will fail to be created. Other than that it’s a silent error that killed one afternoon for me. If anyone knows the reason for this, please share it – it nearly drove me nuts and I’d like to know why.
• Put versions in your file names. It’s a simple thing, and really more of a pet peeve than a tip, but I hate downloading updates (to anything really) then confusing them with previous versions.
• Include a method to test support that doesn’t touch native code. I’ve been guilty of this several times but there’s no reason others should be too. There should always be a way in your ane to test if the file is supported on the current device/platform that doesn’t instantiate the ExtensionContext or try to call any native code. Just a simple static Class.isSupported() will suffice and save a tremendous amount of grief having to deal with compiler config settings, etc. to not run code that shouldn’t be run.

If anyone else has any tips, tricks, horror stories, or what have you about ane files share ’em in the comments.

Anyway, having said all that, I wrote a simple (again, Android only) ane file for a little personal project I’m currently working on and thought I’d share. It allows you to display Toast text, get the OS Version, go full screen using Android’s immersive mode, and share an image file with any apps that allow it. Anyway, the source, more info and usage instructions are all over on github. I’m sure some folks may find it useful.