Apple has made a significant change in the application orientation APIs in the newly released iOS 6 SDK. Some of the auto-orientation callbacks have been completely deprecated in iOS 6 SDK. This means apps packaged with iOS 6 SDK and running on iOS 6 devices will not receive the deprecated callbacks. However the same apps running on iOS 5.1 or earlier will continue to receive the deprecated native callbacks. This change affects the screen orientation API’s in AIR too and support for the new callbacks have been added in AIR 3.5 beta release available here.
Prior to iOS 6 SDK, native orientation callbacks informed the application about the new orientation it was being rotated to. Hence, an application could decide whether it wanted to rotate to the new orientation or not at runtime. However, the new callbacks do not give us such information.The OS only queries the application about the set of orientations it currently supports. If the new orientation that the application is being rotated to is one of these values, the application rotates automatically. Otherwise it does not. Continue reading…
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.
Flash provides great support for rendering text with a great set of API. Flash also allows developers to render text in various languages so that developers can build localized applications. Flash allows developers to render text in languages like Japanese or Chinese whose character set contains unicode characters. There is a small subtlety that developers need to be aware of when targeting localized versions of their applications on iOS.
Traditionally flash developers have been more focused on the browser to deliver their content. While delivering the content through the browser, developers generally embedded their assets within the root swf. Honestly, there is no other way except loading these images off their servers but this could have resulted in a lag whilst the content was running
With AIR however, developers need to make certain changes to their applications to make them more apt for deployment on mobile devices. With AIR, developers get access to the file system and the assets for their content can be accessed off the file system instead of being embedded within the root swf. Assets for the application should be packaged along with the application and then should be accessed on demand by simply loading them using a Loader.
Up to AIR 3.3, it was not possible to handle exceptions inside the Cocoatouch Static Library in an ANE. AIR 3.4 onwards, it is possible to use the Objective C @try-@catch-@finally syntax inside one’s native library. The native developer can now also use C++ try-catch blocks successfully. The only thing to keep in mind while using exceptions in native code on iOS is that the exceptions should be handled inside the ANE itself. The AIR runtime will not catch the exceptions thrown by extensions.
You can download the latest AIR SDK with support for handling exceptions in a Native Extension from http://labs.adobe.com/technologies/flashplatformruntimes/