When writing a book there are many tough decisions to be made. Perhaps the most agonising for me was deciding what to keep and what to drop. With an agreed page count to stick to I found that I simply couldn’t cram everything I wanted to into my Flash iOS Apps Cookbook.
So during the revision process I went about cutting out certain code recipes that I felt I could probably do without. Some of them simply didn’t fit the structure of the book and were clear candidates. Others had limited real-world use cases, or weren’t aimed at the book’s target audience. In the end we probably removed around 100 pages worth of content.
I thought it would be worth resurrecting some of that material and making it available from my blog. There’s no particular order and some of it went through more revisions than others. I’ll start with a couple of recipes that were originally intended for Chapter 11, Rendering Web Pages. Both detail bi-directional ActionScript/JavaScript communication and are worth a read if you’re planning to make use of AIR’s StageWebView
class. Anyway, enjoy and I’ll see what else I can dig out for you over the coming months.
Great book! It’s shaved a LOT of time of my Flash-to-iOS learning curve!
Thanks for offering up the “leftovers”! 🙂
No problem JP and I’ll hopefully have a few more added to my blog soon.
This looks like a promising book! Chapter 3: “Linking classes to movie-clip symbols” … what might that be about exactly?
There’s currently a huge shortcoming when developing apps for iOS with AS3: The problem is that you can’t use class definitions from an SWF that is loaded into your main app. iOS sees those class defs as non-native code and an exception is thrown. This is a major disadvantage since there’s no really well working way of putting assets (sounds, display objects, etc.) into a resource SWF that is loaded later when needed by your app.
Hi, hexagonstar. Yes this is unfortunately an annoying limitation of working with external SWFs with AIR for iOS. Instead, the book explains how to create a SWC file and statically link it your app, but of course doing so doesn’t allow you to load the content at runtime.
SWCs become part of the main app (SWF) so for small apps/games that’s alright but with large games that use lots of assets it’s preferable to load assets in when needed. It would be helpful if DisplayObject had a clone() method that provides a perfect clone. Then we could just lay out needed (display) assets on the stage in the Flash IDE and load that in, parse through the objects on the timeline and clone them, but, alas, that’s not possible and trying to clone a MovieClip (with all nested children etc.) is a huge undertaking.
For sound assets … they can of course be loaded via the Sound class but I prefer to load them as byte data (actually it’s required for the game engine I’m developing, Tetragon) and that again posed problems on iOS. I’ve used AS3SWF lib to create an in-memory SWF to workaround this before but again, in-memory SWFs are not allowed on iOS. Fortunately Adobe provided a new Sound API (loadCompressedDataFromByteArray() among others) and if it wasn’t so limited (or buggy) it would be great. Until they fix it my loaded MP3 files must have ID3 tags to be loaded correctly (since the ID3 event is the only supported for the new API and is used to signal that an MP3 has completed loading).
So many shortcomings, but we’re getting there … slowly! 😉
Yeah AIR is definitely getting there but you’re right, many shortcomings that still need fixed. Thanks for sharing your thoughts and info!