With the release of AIR 3.3, it is now possible for developers to debug their iOS AIR applications over a USB cable on the device. Prior to this release developers had to use wifi for debugging an AIR application on the iOS Device. There were, however, a few limitations associated with wifi debugging.
1) A developer needs to have internet connection available all the time.
2) Both the device and the desktop machine must be on the same subnet.
This new capability will solve the above mentioned problems and will provide a seamless debugging experience to the user by just connecting the iOS device to a Mac or a Windows machine. Since this feature is not available in Flash Builder or Flash Professional at the moment, a developer has to perform certain steps to get the debugging over USB working.
The steps required to set up the debugging over USB are as follows:
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,
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:-