Welcome!

Think Labs is an ongoing effort by Seven2 to provide research and educational opportunities in the web development and mobile field. To see what we’ve been cookin’ up, check out our blog postings.

Created by
Seven2 Login

Categories
Tags
Team Think Labs | Adobe Native Extensions: The Untold Story
4049
single,single-post,postid-4049,single-format-standard,ajax_fade,page_not_loaded,,,wpb-js-composer js-comp-ver-4.2.3,vc_responsive
Adobe Native Extensions!

Adobe Native Extensions: The Untold Story

Adobe Native Extensions (ANE) are a much needed feature added to Adobe AIR that allows developers to access “Native” logic in their Adobe AIR app without being forced to completely emulate and re-develop that logic in AS3.  Looking at the starter tutorials on Adobe’s website is a great spot to start, and the tutorials are very straightforward.  So straightforward that doing anything and everything as an ANE seems like it’ll be a total breeze!

ANE's are free real estate! Right??

Adobe Native Extensions seem so great, that they’re like free money!  Officially You just need to do three things to make a Native Extension come to life.

1) Write some XCode (or Android/etc) code as a Static Library using the “FlashRuntimeExtensions” header and using their function naming conventions.  Cake! Here’s a tutorial example:

BatteryLifeDemo

Awesome, in like 5 lines of code, you’ve asked your iPhone what battery percent you’re at and handed it back to your AIR app.  Nice! In my opinion, the XCode part is the best part, even though you’re having to figure out all the weird Flash Datatypes.  This is because Flash Builder makes XCode look like Visual Studio.  ps: Flash Builder is awful.

2) A FLEX project that is the intermediary between ActionScript (your class namespace) and XCode.  Any functions you want to offer need to be defined in this Mobile Flex Project.  Then, you take the SWC that’s made in that project, unzip it so that you can get the library.swf from inside of it, put that alongside a number of XML files and run some command-line functions that aren’t super documented and you’ve got a fresh new Adobe Native Extension ready to use!

 

3) Import your finished ANE into your Adobe AIR project, import the namespace and you’re golden!

 

What? Did item #2 seem kind of ambiguous?

That’s because it’s the part that’s absolutely going to fight you the most.  Here are the set of files and folders that are used in the Photo Finish FolderStructure

/ANE: The folder that contains all the dependent libraries that your iOS library needs.  In addition to or in place of the /ANE/ios folder you could build different targets like desktop, android, etc.  The important part is that any external libraries your XCode project uses need to be organized here as well.

/AS3: That FLEX Project.  The important part is the SWC file which gets both copied and unzipped into the ANE folder to setup the AS3 interface.

/XCode: The iOS side, again the only important part for ANE building is the static library (.a) file, which gets thrown into /ANE/ios to be consumed by the ADT command.

Extension and Platform XMLs are files that you will use to manually map dependencies required in your ANE so that the terminal commands can wire up everything properly.  The documentation on these is so straightforward that you’ll spend dozens of hours trying to get a really custom ANE to work right.

Platform.xmlExtension.xml

 

If you organize everything properly and run the ADT command from Terminal, you should end up with an ANE file that’s good to go!  Here’s that easy to enter command!

adt -package -target ane build/debug/DisneyFinishANE.ane  ANE/extension.xml -swc ANE/DisneyFinishANE.swc -platform iPhone-ARM -platformoptions ANE/platform.xml -C ANE/ios .

So copying, unzipping, building, moving files, running terminal commands.  That sucks.

That’s why you figure out a build script. A lot of people like ANT, but I wasn’t familiar with that so I just made a shell script to deal with all of that nonsense.

makeScript

Let’s use this sucker!

Alright, so you’ve got your Native Extension built and you’ve imported it into your Adobe AIR project! You can see the Native Functions you (or some other developer) made and you’re ready to build and test your AIR App on your machine!

ld64-error

LD64, from Hell’s heart I stab at thee! 

The ANE developer successfully built his file and handed it off to you, this should be a done deal right?!

Wrong!  If the developer building the App doesn’t have every single library used by the ANE installed in the exact same spot on their machine, compiling the actual App will fail in a fantastically generic fashion.  It’ll also fail if something isn’t also set in your Platform.xml file. You’ll need to verify that your IOS Version is set properly, because AIR defaults compilations to iOS 4.0 and you’re almost certainly using 5+ in your XCode project.

Also, AIR nicely imports a bunch of standard libraries for you, but maybe you didn’t (or did and shouldn’t have) set a -framework or -weak_framework in your platform.xml.  You’ll be checking this page all the livelong day making sure a library is included properly!

theWire

If you’ve done your homework and watched The Wire, like you should have, you heard that GIF in Lance Reddick’s voice.  If you didn’t, stop everything and go watch all the seasons of The Wire. I’ll wait.

What did you think of Season 2?  Okok, later.

 

Where do you go for help? 

Stackoverflow? Sure, but ANE development seems really niche right now and, at least during my adventures, I didn’t get much action from it.  That’s why you need to go to:

http://forums.adobe.com/community/air/development

Far better response times, and mostly helpful.

 

What else was ridiculous?

deeper

* Application Icons: More related to AIR development, than ANE, but when you build an IOS app, you need about 400 different icon sizes.  We had a problem with one specific icon size being stretched, and it was because AIR was being helpful!

* Flash Builder is obnoxious: Any time you wanted to add a new function in your ANE and have it visible in your AIR App, you needed to totally restart Flash Builder.

* Many iOS libraries don’t want to be used in a Native Extension context.  You may need to create your own XCode App Delegate class that is basically like App Inception. It’s a totally different/longer tale.

* Not ridiculous, just a little challenging: Except by using Callback/event dispatching from Xcode to AS3, your ANE can never directly manipulate the displayed view.  The best you can do is lay your iOS visual content on top of the AIR application. For instance, a banner ad isn’t in your SWF design, it’s sitting on top of the displayed view, at a position you give it.

Did somebody already build that?

There is a community of ANE developers out there, it’s just not super big.  If you’re doing stuff like Push Notifications, Game Center, In App Purchase or other big-name items, check these out first.  It could save you a lot of hassle!

* http://www.adobe.com/devnet/air/native-extensions-for-air.html – Adobe’s page listing out a bunch of submitted extensions

* http://www.milkmangames.com/blog/tools/  – Lots of great stuff here, very solid code!

* https://airextensions.net/ – Again, good stuff, the developer(s) are very helpful if you have any questions.

 

Verdict:

Even with all the learning curve, Native Extensions can be pretty great.  The part that can really destroy your time and budget are when you need to implement Native Extension versions of things from clients that were never intended to be used any place except from XCode.  I spent many, many hours debugging just the build process (not anything related to the code…the code itself worked fine) just to get things to compile.

Can ANE’s be like free real estate?  Yes, but only if you know ahead of time what you need to implement.  Once you start throwing in the kitchen sink it can get very complicated very fast, which could change your development path from AIR to just doing everything Native.  Alternatively, going AIR and not using all of the many tools that XCode gives you now to design your apps can just be swapping out one set of challenges for a different set of challenges and can be very risky if your project requirements wander (because other apps do that, its easy!)