Evaluating Device Capabilities and Handling Multiple Devices

0
159

The premise of mobile AIR is to enable you to create one concept, one code base, and a set of assets to deploy an application on multiple devices effortlessly. AIR for mobile accomplishes this for the most part, but not without challenges. There is a disparity in performance and capabilities among devices, and deploying for a range of screen resolutions requires effort and time even if your art is minimal.

In the near future, mobile devices will approach, and perhaps surpass, the performance of desktop machines. Until then, you must adapt your development style to this limited environment. Every line of code and every asset should be scrutinized for optimization. The AIR runtime has been optimized for devices with limited resources, but this is no guarantee that your code will run smoothly. This part is your responsibility.

Hardware

The multitude of Android devices available today makes it difficult to evaluate them all. The subsections that follow discuss the major factors to examine. If you want to know about a specific phone, or if you would like a complete list of Android devices, visit these websites:

http://pdadb.net/
http://en.wikipedia.org/wiki/Category:Android_devices
http://phandroid.com/phones/

The Processor

The CPU, or central processing unit, executes software program instructions. Its speed on mobile devices varies from 500 MHz to 1 GHz. For comparison, the average speed of a desktop computer is around 2.5 GHz.

The instruction set must be ARMv7 or higher to run AIR for Android.

The GPU, or graphics processing unit, is a high-performance processor dedicated to performing geometric calculations on graphics. Its speed is evaluated in millions of triangles processed per second (mt/s), and it ranges on mobile devices from 7 mt/s to 28 mt/s. AIR uses OpenGL ES 2.0-based processors.

The graphics card, display type, and color depth affect display quality.

Memory and Storage

RAM on mobile devices varies from 128 MB to 768 MB, averaging at 512 MB. ROM is an important complementary memory type. On Android, if memory runs out, applications are terminated.

Different types of memory affect the GPU’s speed and capacity.

Storage includes the internal memory, expanded by the SD card.

The Camera

Camera quality is often evaluated by the megapixels it can store. The quality of the LED flash and the auto-focus option on the device is also a factor. Some devices include a front camera of lesser quality to use for video telephony.

Sensors

A built-in accelerometer is becoming standard on Android devices, but it is not yet universal. The GPS antenna and driver is used for satellite navigation. Touch technology is a combination of the screen touch overlay, the controller, and the software driver. The number of simultaneous touch points varies, although Android officially only supports two.

The Battery

Battery capability on an Android device is measured in milliamp hours (mAh), and is commercially evaluated by the number of hours of movie play capable on the device. Removable batteries can be replaced by stronger ones if needed.

The Display

Screen size on Android devices is measured as a diagonal, usually in inches.

Resolution is the number of pixels on the screen. The resolution varies between 800×480 and 854×480 on phones, and between 1,024×600 and 1,024×800 on tablets.

The PPI (pixels per inch) or DPI (dots per inch), also called pixel density, is the number of pixels on the screen in relation to the screen’s physical size. A device has a defined number of pixels it can display in a limited space. A higher pixel density is preferable on devices viewed at close range.

Table 5-1 lists the screen size, resolution, and PPI on some popular Android and Apple devices.

Feature comparison of popular Android devices

Software

At the time of this writing, Android’s latest operating system is 3.0 and is called Honeycomb.

The process for upgrading the Android operating system is very different from the Apple model, which requires the device to be synced with iTunes. Android uses an “over the air approach” to push upgrades. Manufacturers slowly push upgrades to phones, sometimes over several months. Not all devices receive upgrades, so developing for established versions instead of recently released versions may guarantee you a broader audience.

If you are not sure what version is installed on your device, select Settings→About phone→Android version (on some devices, this information is available under “Software information”). Your phone system must have at least Android 2.2, called Froyo, to run AIR for Android. The Adobe AIR runtime is not accessible on the Android Market for earlier versions.

Performance

The device’s performance is measured by its speed of execution and how much it can hold in memory. Methods and tools can be used to perform a benchmark. For a quick analysis, try the AIRBench application developed by Christian Cantrell, from Adobe, and read his blog at http://blogs.adobe.com/cantrell/archives/2010/10/using-airbench-to-test-air-across-android-phones.html.

AIRBench tests devices’ capabilities, but also runs performance analyses. I used it on three different devices. Table 5-2 shows the performance results I achieved in milliseconds (lowest numbers show best performance).

AIRBench performance results for the Samsung Galaxy Tab, Droid 2, and Nexus One devices

Capabilities

You can request information on the device at runtime to automate some of the presentation of your application. The Android Market, unlike the Apple Store, does not separate applications between phones and tablets. Be prepared for all devices.

Rather than trying to make your application look identical on all devices, adapt the layout for the resolution used.

The flash.system.Capabilities class provides information on the environment. To determine that your application is running on a mobile device, use cpuArchitecture:

import flash.system.Capabilities;
if (Capabilities.cpuArchitecture == “ARM”) {
trace(“this is probably a mobile phone”);
}

Alternatively, you can compare screenDPI and screenResolutionX. Here is the code to calculate the diagonal dimension of the screen:

var dpi:int = Capabilities.screenDPI;
var screenX:int = Capabilities.screenResolutionX;
var screenY:int = Capabilities.screenResolutionY;
var diagonal:Number = Math.sqrt((screenX*screenX)+(screenY*screenY))/dpi;
if (diagonal < 5) {
trace(“this must be a mobile phone”);
}

Orientation

To control the look of your application, you can define the application’s scaling and alignment. The scaleMode as set in the following code prevents automatic scaling and the align setting always keeps your application at the upper-left corner. When you choose auto-orient, it is added automatically in Flash Builder Mobile:

import flash.display.StageScaleMode;
import flash.display.StageAlign;
stage.scaleMode = StageScaleMode.NO_SCALE;
stage.align = StageAlign.TOP_LEFT;

Android devices equipped with an accelerometer can determine device orientation. As the user moves the hardware, your content rotates. Define a custom background color to prevent distracting white borders from appearing while in transition:

[SWF(backgroundColor=”#999999″)]

If you always want your application in its original aspect ratio, in Flash Professional select File→AIR Android settings, and under the General tab, deselect “Auto orientation”. In Flash Builder, under Mobile Settings, deselect “Automatically reorient”.

To get the initial orientation, use the following:

var isPortrait:Boolean = getOrientation();
function getOrientation():Boolean {
return stage.stageHeight > stage.stageWidth;
}

To listen for a device’s orientation and set a stage resize on the desktop, set autoOr ients to true:

<initialWindow>

<autoOrients>true</autoOrients>
</initialWindow>

and register for the Event.RESIZE event:

import flash.events.Event;
stage.addEventListener(Event.RESIZE, onResize);
stage.dispatchEvent(new Event(Event.RESIZE);
function onResize(event:Event):void {
trace(stage.stageWidth, stage.stageHeight);
}

The event is fired when your application first initializes, and then again when the device changes orientation. If you create an application to be deployed on the desktop, the event fires when the browser window is resized.

Another API is available for orientation changes. It uses StageOrientationEvent and detects changes in many directions. It is not as universal as RESIZE, but it does provide information on the orientation before and after the event.

The default orientation is up and right:

import flash.events.StageOrientationEvent;
if (stage.supportsOrientationChange) {
stage.addEventListener(StageOrientationEvent.ORIENTATION_CHANGE,
onChange);
}
function onChange(event:StageOrientationEvent):void {
trace(event.beforeOrientation);
trace(event.afterOrientation);
// default
// rotatedLeft
// rotatedRight
}

The goal is to use this information to position and perhaps resize your assets as needed. We will discuss this next.