Developing ’Native Extensions for iOS’ requires knowledge of both native iOS code (C/C++/Objective C, XCode, static libraries etc) and AS3 code. So, it’s not unusual for developers to face issues. I have tried to list some of the most common roadblocks for native extension developers on this page.
An extension is recognized by its extensionID. Thus, one should try to keep it as unique as possible, as an application developer might want to use more than 1 native extension in his application. Having the same name will create conflicts and the application won’t get packaged or work as expected.
a. Same extensionID should be used in the extension.xml, application.xml and the AS3 Class where ExtensionContext.createExtensionContext() function is called.
b. Using “nativeExtension” as the extensionID isn’t really a good idea. Prefixing the extensionID with com.developerName is probably the way to go.
In this post, I will explain a little about how Cache As Bitmap can impact Anti Aliasing of your content.
Let’s start with a definition. To put it very simply, I will say that anti aliasing is what gives smooth look to your content. Anti Aliasing is a way to make content look smoother by drawing certain pixels to avoid jaggedness.
For iOS applications, there are two render modes – cpu and gpu. Let us look at what all can happen with this seemingly harmless change. For all further purpose please assume that we have set the render mode as gpu within application descriptor.
Before I start, look at the two ellipses in the diagram. If you stare hard enough you will agree with me that the left image loses out when compared to the one on right in terms of quality. The right one looks like a smoother version of the left one. If you had difficulty defining anti aliasing then this image should help clear the definition. The right one is anti aliased better or is smoother.
The latest release of AIR SDK (version 3.3) now supports iOS 5.1 SDK. AIR 3.3 SDK includes stubs of all the frameworks and the public libraries available in iOS 5.1 SDK. Frameworks that have been added as stubs in the AIR 3.3 SDK are Accounts, Twitter, NewsstandKit, CoreBluetooth, CoreImage, GSKit and GLKit. Some of the public libraries whose stubs have been added into the AIR SDK are libxml2.dylib, libsqlite3.dylib, libAWDProtocolbuf.dylib and many more. This change relieves the AIR developer of the following requirements:-
[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…
One must have come across many mobile applications(mostly games) that remain in landscape orientation across their lifetime. They start in landscape orientations and remain in landscape orientations irrespective of the orientation in which the device is held or moved. A landscape only application should ideally support both landscape orientations namely Landscape_Left and Landscape_Right and should not auto rotate to any portrait orientation if the device is held in one of the portrait orientations.
Prior to AIR 3.3, StageAspectRatio supported two public constants PORTRAIT and LANDSCAPE. Using one of these values in the aspectRatio tag in the application descriptor would only lead to the application opening up in PORTRAIT or LANDSCAPE orientation respectively. However, the Stage would re-orient in all orientations as per the new device orientation. For example:- with StageAspectRatio set to PORTRAIT, an app would open in PORTRAIT orientation but would reorient to LANDSCAPE_LEFT orientation when device orientation was changed to LANDSCAPE_LEFT.