Starting with AIR 3.7, application developers will be able to host their secondary SWFs on an external server and load them on demand as per their application logic.
Till AIR 3.5, loading of only assets such as images, videos and SWFs without actionscript code, commonly referred as Actionscript Byte Code(ABC Code), from external server was supported. The workflow for the application developer for loading such assets from server resembles the diagram below :
With AIR 3.6, the feature for loading of locally packaged secondary SWFs containing ABC code was introduced. The detailed description about this feature and its usage can be found at this blog – “Packaging and loading of multiple SWFs for AIR apps on iOS“. The workflow for the application developer using this feature is described in the diagram below:
In AIR SDK 3.6 for iOS, there is a new feature that allows application developers to be able to package and load secondary SWFs that contain ActionScript byte code (or ABC) in their apps. Presently, due to certain restrictions on iOS, AIR on iOS requires that all the ActionScript code of an application be present in the main SWF or the root SWF. With this feature, an application developer can have ActionScript code in local secondary SWFs and package them along with the main SWF.
This post will talk about a small optimization that developers can do within their code to reduce the amount of time taken for AOT compilation of their application I would recommend developers to read this post to understand what is meant by AOT compilation.
One of the intermediate steps in AOT compilation requires LLVM to process the LLVM bytecode and to optimized LLVM bytecode. In case one of your function has a lot of actionscript code (~30000 lines) then the corresponding LLVM code is around 1.3 million lines. LLVM is known to perform badly (compilation time) on large functions. As a recommendation, actionscript developers should break down on large function into smaller functions to reduce the AOT compilation time. They need not change any code, just break a large function into many smaller functions to reduce AOT compilation time significantly.
Traditionally, computer programs can be executed in three possible ways – interpreted, static (ahead-of-time) compilation and Just In time (JIT). In interpreted mode, the code is translated from high-level language to low level language during execution whereas in ahead-of-time compilation the high-level language code is converted to low-level machine code before hand. JIT (Just in time) compilation is a hybrid approach of the two. Here the code translation into native code occurs during the execution time and the translated code is cached so that this conversion need not be done every time. Obviously there is a small penalty when compared to ahead-of-time compilation as there is a cost associated with this translation.
After this brief introduction lets get into the Adobe AIR world and what is there in it for an iOS AIR developer. SWF content on all platforms other than iOS is JIT compiled, whenever possible. The swf is downloaded locally and JIT compiled where possible. Continue reading…
If you are using iOS Native Extensions with AIR 3.3, you may find that your application does not get packaged when using Flash Builder/Flash Pro. This is because, when using native extensions, linker warnings are not suppressed, and Flash Builder/Flash Pro are not able to handle such large number of warnings, specifically on Windows. This issue will be fixed in the upcoming release of Flash Builder and Flash Pro.
In order to overcome this issue, you can include the platform descriptor file (platform.xml) in your ANE, which contains the following linker option:
A sample platform descriptor file will look like this:
Then, at the time of packaging the ANE, include the ADT switch -platformoptions, providing the path to the platform descriptor file. For example,