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:
RequestedDisplayResolution tag in application descriptor allows the developer to choose between standard or high resolution on iOS devices with high resolution screen. High resolution screens were earlier only available in iPhone and iPod 4th Generation and above. Recently released models on iPad namely iPad 3rd & 4th Generation also boast of a high resolution screen with 2048×1536 resolution. Specifying a ‘high’ value in requestedDisplayResolution tag enables the retina mode in the all iOS devices having the high resolution screen. Prior to AIR 3.6, there was no way to enable or disable retina mode on some specific devices. There existed some workarounds but they came with some trade offs of not able to use the iOS 6 specific features.
A new attribute ‘excludeDevices’ has been added in AIR 3.6 in the requestedDisplayResolution tag in the application descriptor. Developers will now be able to explicitly disable the specified display resolution on one or more iOS devices using this attribute.
Apple expects all its iOS applications to have launch images for all supported devices and resolutions to enhance the user experience at application launch. In general, an iPhone application should have a Portrait launch image and an iPad application should have a launch image as per the launch orientation of the application. As mentioned here, every application must include launch image for different sizes and resolution. Looking at the sizes closely, we notice that Apple expects fullscreen launch images for iPhone whereas it expects non fullscreen launch images for iPad. This size recommendation by Apple is irrespective of the fact whether the application is meant to be fullscreen or not. Continue reading…
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…
[UPDATE: InvokeEventReason.NOTIFICATION added for accessing the notification payload when application was not running in the background. Latest AIR build containing these changes available here]
Push/Remote Notifications support for iOS platform has been made available in latest release of AIR 3.4. This blogpost will cover everything you need to do to get remote/push notifications working in your AIR application: subscribing for remote notifications, configuring your application in the iOS Provisioning Portal, sending notifications to Apple’s Push Notification Service (APNS), and handling them in your application. Another detailed article discussing Push Notifications Support in AIR can be found at http://www.adobe.com/devnet/air/articles/ios-push-notifications.html
Remote notifications, or server push or push notifications, describe a style of Internet-based communication where the request for a given notification is initiated by the publisher or central server. It contrasts with pull technology, where the request for the transmission of information is initiated by the receiver or client (device in our case). Push technology has the advantage over pull notifications that device battery and network bandwidth are saved when no new data is available. Continue reading…