Category Archives: Mobile

AIR 3.0 Captive Runtime

If you hadn’t heard yet, Beta 2 of AIR 3.0 and Flash Player 11 are now availabe on Adobe Labs. The AIR 3.0 beta release is sporting some great new features, including hardware accelerated video playback for mobile, iOS background audio, android licensing support, front-facing camera support, encrypted local storage for mobile, H.264 software encoding for desktop applications, and last, but not least, captive runtime support for desktop and Android applications.

If you are wondering what “captive runtime support” is, then I’ll try to explain… Currently all AIR applications that are deployed on the desktop and in Android require the 3rd-party Adobe AIR runtime. If you are familiar with the process for developing mobile AIR applications for Apple’s iOS devices, then you may already know that these applications don’t require the 3rd-party runtime; they are completely self-contained applications. These AIR applications for iOS already take advantage of the captive runtime. All necessary components of the AIR framework are bundled into a self-contained, compiled distributable application that has no dependence upon other frameworks.

With AIR 3.0, you will have the option to bundle the AIR framework into your applications to eliminate the 3rd-party dependency. However, one thing to keep in mind is that you can only export mac application packages on Macs and Windows EXEs on Windows. You can’t target native installers or bundled runtimes for cross-platform development. You can only have a single app that targets both platforms if you export a .AIR file (which requires the 3rd-party AIR runtime).

Instructions for using the captive runtime:
First, make sure that you extract the AIR runtime SDK from the archive. Instructions for extracting the AIR SDK are located at: http://kb2.adobe.com/cps/495/cpsid_49532.html

Next, add a compiler argument for swf-version=13.

Then use the ADT command line utility to build and package your application. If you run the ADT tool on the command line without passing any arguments, it will show you all of the packaging options.

For the Android captive runtime, you just need to select the target “apk-captive-runtime“, as identified by:
[bash]adt -package -target ( apk | apk-debug | apk-emulator | apk-captive-runtime ) ( CONNECT_OPTIONS? | -listen <port>? ) ( -airDownloadURL <url> )? SIGNING_OPTIONS <output-package> ( <app-desc> PLATFORM-SDK-OPTION? FILE-OPTIONS | <input-package> PLATFORM-SDK-OPTION? )[/bash]

For the desktop captive runtime, you need to select the target “bundle“, as identified by:
[bash]adt -package SIGNING_OPTIONS? -target bundle SIGNING_OPTIONS? <output-package> ( <app-desc> FILE-OPTIONS | <input-package> )[/bash]

Molehill (Stage3D) on Mobile

I recently had the opportunity to start playing around with Molehill for mobile (hardware accelerated 3D graphics), and I think it is something that many of you will be very excited about (see video below). Everyone thinks that 3D is just for games, but it’s not… 3D graphics can be used for complex data visualizations, scientific modeling, or a whole host of other subject areas.

I started down the path of creating 3D charts that are capable of rendering on mobile, using the Away3D engine. This is really just exploratory work, and I have it rendering multiple axes with 250 spheres (individual data points), which is about 70K-90K polygons drawn onscreen at any given time. Check out the preview below:

Molehill (Stage3D) on Mobile

This preview is running on a Motorola Atrix, and Samsung Galaxy Tab 10.1 with a prerelease AIR runtime… more devices will coming soon. Source code will be available once molehill for mobile has been released.

Molehill (Stage3D) on Mobile recorded via iPhone

You can see another preview of molehill for mobile here: http://www.bytearray.org/?p=3053

Enjoy!

Exporting AIR Mobile Apps as Desktop Apps

A great question came out of the comments on my last post “Why Can’t I Run My App in the iOS Simulator” asking if it is possible to export the mobile simulator from Flash Builder to allow you to distribute builds for functional testing/validation.   The quick answer is yes (but you don’t really export the simulator).

Let me explain… When running or debugging a mobile application directly within Flash Builder’s environment, you really are running a local desktop application within the ADL executable (AIR Debug Launcher) that is part of the AIR SDK.  The size/layout of ADL in this case is locked to imitate the experience of a particular device/configuration.  The mobile application isn’t running in a device-specific simulator.

All Flex/AIR mobile applications can actually be exported as .AIR files that can run within the desktop runtime environment.  This enables you to easily repurpose an application from mobile to desktop.

Keep in mind, this does not mean there will be a 100% parity between desktop and mobile features, interaction, and performance.  Interaction paradigms, such mouse vs. touch, keyboard vs. hard-keys vs. soft-keys, form factor, as well as hardware (CPU/memory) may all have critical impacts in the overall experience.  Again, if you are targeting mobile devices, then it is imperative that you test your applications on real, physical devices to identify any kind of performance issues, bugs, or UX issues.

To export a mobile application for desktop usage as a .AIR file, just select the “Signed AIR package for installation on desktop” export option within the “Export Release Build” dialog.

Flash Builder Export AIR Options

The exported AIR file will use the standard AIR runtime, inclusive of cross-platform features and the AIR installer.  Note: I used a local dev certificate in this example, with just the default options.

AIR Installer

At runtime, it will look like any other AIR application.  You can configure the AIR app-xml descriptor files to customize it.

Runtime Mobile AIR Application on the Desktop

 

Why Can’t I Run My App in the iOS Simulator?

One very common and valid question when developing AIR mobile applications is “Why can’t I run my app in the iOS simulator?”

This is especially the case once you realize that you can compile and target the Android emulator; The ADT packager supports exporting to the Android emulator, but you can also install any APK (Android Package) binary file into the emulator using the normal tools contained within the Android SDK.

The reason that you can run a Flex Mobile app in the Android emulator, but not in the iOS Simulator comes down to the fundamental difference between an emulator and a simulator. An emulator emulates a physical device; The emulator program mimics the hardware, and the device-specific code that will run on the actual device runs within the mimicked environment. A simulator simulates an environment – it has a likeness or model of an environment, however it is not identical to the target environment.

In this case, the Android emulator mimics the hardware environment and is capable of running a compiled APK for a Flex/AIR mobile application. However, the iOS simulator is not capable of executing the contents of an IPA file. This isn’t specific to an IPA file for an AIR mobile app, but any IPA file – even those downloaded from Apple’s own app store.

The executable content within an IPA file is compiled targeting the device’s A4-ARM processor. Your desktop computer uses an intel-based processor architecture, which isn’t compatible and will not work. Even if you rename an IPA file to a ZIP file and extract the contents, it will not work within the iOS Simulator because of the CPU architecture differences.

Best Practice:

The first, and most important point that I emphasize regarding mobile application development is that nothing is more important than testing your mobile applications on a physical device. Emulators and simulators can help you see how an application may operate within a given environment, but they do not provide you with the actual environment. Physical devices may have memory, CPU, or other physical limitations that an emulator or simulator may not be able to reveal.

Secondly, keep in mind that emulators and simulators are created to make your development process easier and faster (especially if hardware is not readily available for the entire dev team). The debugging environment within Flash Builder is designed exactly for that purpose. You can quickly and easily test your application’s interface and functionality with a single button click. You can even setup debugging profiles for multiple devices, or use one of the predefined device configurations:

While these capabilities make developing for multiple form factors and multiple device types significantly easier and faster, this does not trump my first point. If you are targeting specific hardware, then it is imperative that you test thoroughly on your target platform(s).