You want to build Blackberry application with action script?

With the Adobe Flex 4.5 SDK and Flash Builder 4.5 releases, Adobe is bringing the Flex SDK and Flash Builder to touchscreen smartphones and tablets as well. Leveraging the Adobe AIR 2.6 runtime, you can now develop mobile ActionScript and Flex applications with the same ease and quality as on desktop platforms.

Using Flash Builder 4.5, you can build mobile Flex applications for the Google Android platform. You can also build mobile ActionScript applications for both Android and Apple iOS. In June 2011, shortly after the release of Flex and Flash Builder 4.5, we'll be releasing an update that enables development of Flex applications for iOS, as well as both ActionScript and Flex applications for BlackBerry PlayBook.

Overview of mobile development with Flex

The initial release of mobile development with Flex involves three components:

• Runtime: Adobe AIR 2.6 on mobile devices
• Framework: Adobe Flex 4.5 SDK
• Development environment: Adobe Flash Builder 4.5

The runtime: Adobe AIR 2.6 on mobile devices

The initial versions of the mobile development features in the Flex SDK and Flash Builder are targeted at creating standalone installed applications using the Adobe AIR runtime for mobile devices. By focusing on AIR, Flex can take full advantage of the integration AIR provides with each mobile platform, such as the ability to handle hardware back and menu buttons and to access local storage.

AIR for mobile devices allows developers to create applications that can be deployed (and, if desired, sold) the same way as native applications on each platform. For example, an application built with AIR for Android can be posted to the Android Market. For more information on AIR for Mobile, see the Adobe AIR Developer Center.

The framework: Adobe Flex 4.5 SDK

Building on top of the core runtime APIs provided by Flash Player and AIR, the Flex SDK provides a robust and productive framework for building application UI and connecting to server-side data. Flex includes a rich set of built-in UI components, data access components and data binding, declarative UI creation through MXML, dynamic layout, and an extensible component architecture.

The mobile features in Adobe Flex 4.5 SDK build on these core Flex features in two ways. First, the existing components and their skins have been optimized and extended to be usable out-of-the-box on touchscreen devices. Second, new components have been added that encapsulate common application design patterns specific to smartphones. These additions to the framework are described in the section Developing mobile applications with Flex SDK 4.5 below.

The development environment: Adobe Flash Builder 4.5

Finally, the 4.5 release of the Flash Builder IDE brings a productive design/build/debug workflow to mobile development. From project creation to visual layout to one-click debugging and deployment on devices, the aim of the mobile features in Flash Builder 4.5 is to make it just as easy to develop an ActionScript- or Flex-based mobile application as it is to develop a desktop or web application. For more detail, see Streamlining the mobile workflow with Flash Builder 4.5 below.

Considerations for mobile design and development

Applications for mobile touchscreen devices differ from desktop and web applications in several important ways:

• In order to be easily manipulated by touch input, components must generally have larger hit areas than in desktop-oriented applications. This is especially true because the pixel density of mobile device screens is much higher than that of desktop monitors.
• The interaction patterns for actions like scrolling are different on touchscreen devices.
• Because of the limited screen real estate, applications on smaller devices like smartphones need to be designed differently from desktop applications, with only a small amount of UI on the screen at a given time. Additionally, UI designs need to take into account differences in screen resolution and pixel density across devices.
• While mobile devices are becoming more and more capable, their CPU and GPU performance is still much more limited than their desktop counterparts.
• Due to the limited memory available on mobile devices, applications need to be careful to conserve memory, and need to be aware that they can be quit and restarted at any time by the operating system.

As a result, building an application for a mobile device is not simply a matter of taking a desktop application and "scaling it down" to a different screen size. Our goal is to make it so that developers can easily craft separate user interfaces appropriate for each form factor, while sharing underlying model and data access code between mobile- and desktop-oriented projects to minimize redundant development effort.

Developing mobile applications with Flex 4.5 SDK

In order to address the design and development challenges listed above, the new mobile development features in Flex 4.5 augment the core features of the Flex SDK with skins and components that are optimized for mobile design and implementation patterns.

Mobile-ready core components

In Flex 4.5, we've taken a few steps to ensure that core Flex components work well on touchscreen devices.

For simple components like Button, CheckBox, and TextInput, we've provided a mobile theme that contains skins that are appropriately sized for touch input. Because of the flexibility of the Spark component architecture introduced in Flex 4, we were able to do this without modifying the core component code. Additionally, as described in the performance section below, the mobile skins we provide are built in ActionScript for optimal performance. Figure 1 shows some of the mobile skins provided in Flex 4.5.

Figure 1. Some of the mobile component skins in Flex 4.5.

Of course, you can leverage the same Spark architecture, styling and skinning the components in mobile applications in order to customize the look of the components to fit your branding and design.

For more complex components, notably Scroller and List, we've added functionality to the core component to enable touch-and-throw scrolling, with bounce and pull effects at the ends of the scroll. Touch scrolling is enabled by setting the new interactionMode style on Scroller and List to touch. If you're using the mobile theme, this style is automatically set on all appropriate components for you, so you don't need to do anything to enable touch interaction.

The initial version of the mobile theme will not have touch-enabled skins for all existing Spark components. Table 1 lists the set of components that are mobile-ready in Flex 4.5; we'll continue to make more components mobile-ready in subsequent releases.

Table 1. Mobile-ready components in Flex 4.5

Controls	BusyIndicator (new component) Button ButtonBar CheckBox HSlider Image (BitmapImage is also supported) Label List (supports touch scrolling, includes scroll indicator) RadioButton / RadioButtonGroup TextArea TextInput
Layout	DataGroup Group HGroup Scroller (supports touch scrolling, includes scroll indicator) Spacer TileGroup VGroup
Charts	All

Standard mobile application structure

In addition to skinning and extending the core components to work well on mobile devices, Flex 4.5 contains a set of new application components specifically designed to make it easy to build applications that follow standard design patterns for touchscreen smartphones.

Because of the limited screen real estate, applications on these devices are typically structured as a series of views, each of which is focused on displaying a single list of data or details about a single data item. The user navigates between views by tapping on data items or other controls, and goes back by either using on-screen UI or a hardware "Back" button. Additional actions can be provided through on-screen UI or a menu overlay. Figure 2 illustrates this application design pattern.

Figure 2. Standard application structure for touchscreen smartphones

We've added the following components to Flex in order to support this pattern.

View

The View component represents a single screen of UI. Typically, you'll create custom MXML or ActionScript components based on View, and add whatever components you want to appear within the content. For example, a shopping cart application might have a home view that displays a list of featured items and categories. Tapping on a category navigates to a product list view displaying items in a given category, and tapping on a product navigates to a product detail view showing information about the product.

Each View has a data property that specifies the data that should appear in that view. Views can pass data to each other as the user navigates around the application. Additionally, the data property enables the ViewNavigator and ViewNavigatorApplication components, described below, to provide features for persisting data both in memory and between runs of the application.

When the user rotates the screen between portrait and landscape orientations, the View is automatically resized by default to the appropriate aspect ratio. As a result, if you use the standard Flex layout managers, your application can handle orientation changes with little extra work on your part. For finer-grained control, you can use the Flex states mechanism to define portrait and landscape states that specify exactly how the View should look in each state.

ActionBar

ActionBar is a standard header component that appears above the Views in the application. It typically contains a title and one or more buttons that perform actions like refreshing the current view or creating a new item. You can fill the ActionBar with controls that are persistent across the entire application, or customize it for each individual view. For example, on the home screen of an application, you might put a search box in the ActionBar.

ViewMenu

ViewMenu provides a standard control that pops up from the bottom of the screen when the user presses the menu button on a device. In any view, you can add a viewMenuItems property containing a set of menu items, each of which specifies an icon, a label, and a click handler. ViewMenu takes care of showing and hiding itself and laying out the menu items appropriately.

ViewNavigator

ViewNavigator manages the ActionBar and the set of Views in your application using a stack-based history mechanism. When your application starts, the ViewNavigator shows the view specified by its firstViewproperty. After that, you can call pushView() to navigate to a new view in response to user input, such as tapping on a list item, and call popView() to return to the previous view. Flex provides a set of optimized view transitions out of the box to help the user maintain context while navigating around the application.

To conserve memory, ViewNavigator ensures that only one view is in memory at a given time by default. However, it maintains the data for previous views in the stack that have been disposed, so that when the user navigates back to a previous view, it can be reinstantiated with the appropriate data.

In addition to the standard ViewNavigator, we also provide a TabbedViewNavigator that allows you to switch between different stacks of views by tapping on tabs at the bottom.

ViewNavigatorApplication

ViewNavigatorApplication wraps all this functionality together into a convenient application class. By basing your application on ViewNavigatorApplication, you automatically get a ViewNavigator for managing your views. For tabbed applications, you can use the analogous application class, TabbedViewNavigatorApplication. ViewNavigatorApplication also provides default behavior for the hardware back button, mapping it to ViewNavigator's popView() method, and handles device orientation change events by passing them to the ViewNavigator and its current view.

Additionally, ViewNavigatorApplication provides a way to persist your application's view state and data when the application quits, so that the next time it starts, it can restore itself with the same current view and view history. This makes interruptions in your application's lifecycle completely transparent to the user—especially important on mobile devices, where the operating system can interrupt or kill an application at any time.

Of course, you're free to create an application completely from scratch using the standard Spark Application class as well, and use the core mobile components and skins without using the View navigation pattern. For example, if you're writing a tablet application, you likely won't be structuring your entire application around small views; tablets have more screen real estate to take advantage of, and tablet applications are less navigation-heavy. In that case, you'll want to start from standard Spark Application rather than ViewNavigatorApplication, but still use the mobile theme in order to get the benefit of the mobile-optimized components and skins.

Performance optimizations

Because the Flex SDK supports both mobile and desktop use cases in the same framework, all the functionality of Flex is available to you when building mobile applications. However, due to performance constraints on mobile devices, there are certain features you will need to be careful of when building mobile Flex applications, and other features we recommend you avoid entirely. Here are a few best practices to keep in mind.

• Use ActionScript rather than MXML to build item renderers. Because list scrolling is highly performance-sensitive, it's important to create item renderers that are as efficient as possible. To aid in creating item renderers for mobile projects, Flex provides the LabelItemRenderer and IconItemRenderer classes. These item renderers are built in ActionScript, and IconItemRenderer can be configured to show one or two text items, an optional icon or image on the left, and an optional decorator on the right. If this doesn't meet your needs, you can subclass one of these classes instead, adding controls and laying them out in ActionScript yourself.
• Where possible, use ActionScript and compiled FXG graphics or bitmaps for component skins rather than MXML and runtime MXML graphics. Similar to item renderers, it's best to ensure that your component skins are lightweight. The skins we provide in the mobile theme in Flex are all built directly in ActionScript, and you can subclass them in order to substitute your own FXG graphics or change the layout. That said, the performance issues with MXML skins are not as noticeable as with item renderers, so using a few MXML skins here and there throughout your application should not significantly impact performance.
• Charts are supported in mobile projects, but other MX components are not. We don't recommend using MX components in mobile projects; use the Spark components instead. The one exception is the charting components, which are usable in mobile projects if care is taken to avoid displaying or animating too much data at once.
• In general, use Spark Label, TextInput and TextArea for text rather than RichText and RichTextEditable. For most UI text, we recommend using TextField-based text for maximum performance, and the mobile skins and item renderers provided in the Flex SDK follow this guideline. It's possible to use the TLF-based RichText for cases where you need to display rich content, but we don't recommend using it for the bulk of your UI elements in mobile projects.

Adapting mobile applications to multiple pixel densities

Mobile devices come in a wide range of form factors, from phones with small screens to large-screen tablets. Simple variations in screen size and aspect ratio can be handled easily using the standard dynamic layout components, such as Group, VGroup, and HGroup, that are provided in Flex. However, devices also vary in pixel density—that is, the number of pixels in a given inch of the screen. For example, most tablets and some phones have a pixel density of 160 dots per inch (DPI), while other phones have pixel densities of 240 or 320 DPI. Variations in pixel density affect the visual size of individual elements in your user interface: all other things being equal, controls with a given pixel size will appear physically smaller on devices with higher pixel density. This is especially problematic for touchscreen interfaces, where controls need to be physically large enough to be targeted with a finger.

Flex 4.5 provides several new features to help developers make their applications work well across multiple densities.

Automatic scaling. Developers can choose to specify a target DPI for their application by setting the applicationDPI property on the application. When this is explicitly set, developers should set up their skins and layout as if they were running on a device of the given DPI. At runtime, if the device has a different DPI from the specified target DPI, Flex will automatically scale the entire application to preserve the approximate physical size of the application and its controls. For example, if an application is targeted at 160 DPI, it will automatically scale by 1.5x on a 240 DPI device. If you choose not to use this feature, you'll need to make sure your custom skins and view layouts adapt properly to different pixel densities at runtime.

Note that if you use automatic scaling, we recommend that you set applicationDPI to the lowest DPI you wish to support, and allow the application to scale up on devices with higher DPIs. This is because vector artwork tends to look better and be positioned more consistently when scaled upwards rather than downwards. For bitmaps, you'll need to take advantage of the multi-DPI bitmap support described below.

DPI-aware mobile skins. The built-in skins in the mobile theme that ships with Flex 4.5 automatically adapt to different DPIs. If you're using automatic scaling, the built-in skins will automatically configure themselves for your specified applicationDPI, and will then be scaled up by the automatic scaling feature. If you're not using automatic scaling, then the skins will adapt themselves to the actual runtime DPI of the device. By examining how the built-in skins work, you can follow the same pattern when you create your own custom skins.

Multi-DPI bitmaps. If you have any bitmap artwork in your application, you'll need to provide multiple resolutions of each bitmap for different DPIs in order to avoid scaling artifacts. To do so, you can take advantage of the MultiDPIBitmapSource class, which allows you to specify different bitmap files to be used at different DPIs for a given image. This class can be passed as the source property for components that display images, such as the BitmapImage or Image components, or as the icon property for Button. As with the mobile skins, these bitmaps are properly handled by the framework regardless of whether you're using automatic scaling, so that you're always seeing the appropriate-resolution bitmap for a given device DPI.

Per-DPI CSS rules. Flex 4.5 adds support for the CSS @media syntax to allow you to specify CSS rules that should only apply at a given DPI; the built-in skins take advantage of this to adapt font sizes and paddings for different DPIs. You can also specify per-platform CSS rules using this syntax.

Running on AIR

Finally, it's important to realize that in addition to all the mobile Flex components listed above, you can also directly take advantage of all the APIs that are available in AIR on mobile devices—geolocation, accelerometer, camera integration, and so forth. While some of these features are not exposed as Flex components, they are easy to access directly using ActionScript. For more information on developing using the APIs provided by AIR on mobile devices, see AIR mobile docs.

Streamlining the mobile workflow with Flash Builder 4.5

Building on the mobile development features in Adobe Flex SDK 4.5, Flash Builder 4.5, extends the existing ActionScript and Flex development workflows to mobile development, from project creation through packaging the final application.

Managing mobile projects

Flash Builder 4.5 provides two new project types: ActionScript Mobile Project and Flex Mobile Project. Creating an ActionScript Mobile Project gives you a completely clean slate on which to write your application in pure ActionScript code. Conversely, creating a Flex Mobile Project gives you access to the Flex framework, including the mobile features described above, as well as the Flex-related features of Flash Builder, such as Design mode and the data connectivity features introduced in Flash Builder 4.

As mentioned above, the Flash Builder 4.5 release supports building mobile Flex projects for Android, as well as building mobile ActionScript projects for both Android and iOS. Updates to enable Flex development for iOS as well as both ActionScript and Flex development for BlackBerry PlayBook will be available shortly after the 4.5 release.

If you're creating applications for multiple screens, such as a desktop/web application and a mobile application, your typical project structure will consist of an ordinary Flex or ActionScript project containing your desktop/web UI, a mobile Flex or ActionScript project containing your mobile UI, and a library project containing model and data access code that is shared between the two applications.

Designing views

For mobile Flex projects, we've extended Design mode in two ways. First, we've added controls to the Design toolbar (see Figure 3) that allow you to preview how the content of a view will look at different device screen sizes and in different orientations. You can add more device configurations yourself in Preferences > Flash Builder > Device Configurations.

Figure 3. Design mode controls for mobile device configurations

Second, we've made it so that Design mode works well with the standard view navigation structure described above. When you edit a View in a project based on ViewNavigatorApplication, you see the View's content in the context of the overall application structure—so, for example, you see the ActionBar above the View, and the ActionBar is filled with the content appropriate to that View. You can drag and drop controls into the ActionBar just like any other container in order to customize it for a particular View. Figure 4 shows dropping a button into the actionContent area on the right end of the ActionBar.

Figure 4. Dropping a button into the ActionBar using Design mode

Design mode also correctly previews the effects of pixel density on your application. For example, if your application has applicationDPI set to 160, and you choose a preview device configured for 240 DPI, Design mode will show the application scaled by 1.5x.

Running and debugging on the desktop and on device

When it comes time to test or debug your application, you have two options. For quick testing and debugging, you can launch and debug the application on the desktop using the AIR Debug Launcher (ADL). For greater fidelity, you can also launch and debug the application directly on a physical device. In either case, you can use the full array of Flash Builder's debugging capabilities, including setting breakpoints and examining the application's state using the Variables and Expressions panels.

When running or debugging on a device, there are a few key points you need to be aware of:

• If your application accesses data, you must deploy your data services to a server that can be accessed from the device via WiFi or the cell network; if you've been testing your application against localhost on the desktop, it won't work on the device, since "localhost" for the device is the device itself.
• The final release of Flash Builder 4.5 supports debugging directly through the USB tether on Android devices, unlike the preview release, which only supported debugging via WiFi.
• In order to run, debug or deploy an ActionScript mobile project on a physical iOS device, you will need to obtain a provisioning profile and certificate from Apple. Also, you'll need to manually deploy the application on your device using iTunes, and launch it on the device itself.
• Profiling is currently not supported on devices, only on the desktop.

Packaging applications for deployment

Finally, when your application is finished and ready to go out to the world, you can use the Export Release Build process just as you would to prepare desktop and web applications for deployment. The main difference is that when you export a release build of a mobile project, Flash Builder packages the build as a native installer, not as an .air file. For example, on Android, Flash Builder produces an .apk file that looks the same as a native Android application package. This enables AIR-based applications to be distributed and sold the same way as native applications on each platform, as mentioned above. On Android, users who do not already have the AIR runtime installed will be prompted to download and install it from the Android Market the first time they run any AIR application. This step is not necessary on iOS, where the runtime is bundled into the packaged application, or on BlackBerry Tablet OS, where the runtime is built into the operating system.

While the mobile development features in Flex are initially targeted at Adobe AIR, we will be looking to bring Flex-based development to Flash Player in the browser on mobile devices in subsequent releases.