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,
With AIR 3.3, it is possible to use platformsdk switch for iOS on a Windows machine too. For using this feature, one needs to copy the desired iOS SDK (iPhoneOS.x.y.sdk) on their Windows machine and use the platformsdk switch of the ADT:
-provisioning-profile <path to .mobileprovision>
<output IPA file>
<application.xml> <SWF> <assets> -extdir <path to extensions folder>
-platformsdk <path to the iOS SDK folder>
Now, this seems fairly simple, the only difficulty which may arise is while copying the SDK from Mac to Windows machine(as symbolic links are present on Mac, which need to be copied as actual files on Windows, else packaging would fail).
With Adobe AIR 3.3, support for native iOS simulator would be available for application development.
Prior to this feature, the only way to test AIR applications on iOS was to have an actual device along with a developer certificate from Apple. With simulator support now available however, there is no need to obtain a developer certificate (which is a time consuming process) or to create a provisioning profile before starting to develop an AIR application. A p12 certificate, which can be created by the developer himself would be sufficient.
Native simulator for iOS is very helpful in testing and debugging AIR applications. Because support for this enhancement is currently not available in Flash tooling, one could use the following adt commands below to use this feature .
Simulator for iOS is based on x86 architecture and therefore two new targets have been added in ADT to support the same. Continue reading…
Adobe tools like Flash Builder allow you to compile actionscript sources of your application and then package all the swf content and assets as .air, .ipa, .apk and native package formats.
This post is meant to stress on the importance of using Release version of swf file for packaging when you intend to publish it on an application store.
Why should I care to create the release version of a swf?
There are two major advantages of using the release version for publishing applications:
- Application Size – The debug version of a swf contains lot of extra information which is required for debugging during development. As a result, the size of debug version of a swf is always more than the corresponding release version. Continue reading…