Mobile development using Adobe Flex SDK "Hero" and Flash Builder "Burrito"

Ever since we first introduced Flex and Flash Builder, our core goal has been to provide a highly productive way to create rich applications across multiple platforms. Starting with Flash Player in the browser, and then with Adobe AIR on the desktop, Flex and Flash Builder have enabled developers to build applications that run across Windows, Mac OS, and Linux.
With the upcoming Adobe Flex SDK "Hero" and Flash Builder "Burrito" releases, Adobe is bringing the Flex SDK and Flash Builder to touchscreen smartphones and tablets as well. Leveraging the Adobe AIR runtime, you can now develop mobile Flex applications with the same ease and quality as on desktop platforms.
The preview versions of "Hero" and "Burrito" target Adobe AIR 2.5, which supports the Android platform. Over time, we plan to enable AIR, Flex, and Flash Builder for other mobile platforms, including BlackBerry Tablet OS and Apple iOS.
Of course, since this article describes preview versions of Flex and Flash Builder, not all features are fully implemented yet, and some details may change before the final releases of these products.

Overview of mobile development with Flex

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

• Runtime: Adobe AIR 2.5 on mobile devices
• Framework: Adobe Flex SDK "Hero"
• Development environment: Flash Builder "Burrito"

The runtime: Adobe AIR 2.5 on mobile devices

The initial versions of the mobile development features in "Hero" and "Burrito" 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. If the AIR runtime is already installed on an end user’s device, the user can simply install any AIR application as if it were a native application. If the runtime is not yet installed, the user will be prompted to download and install the AIR runtime on first launch of an AIR application. For more information on AIR for Mobile, see the Adobe AIR Developer Center.
While the mobile development features in Adobe Flex SDK "Hero" 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.

The framework: Adobe Flex SDK "Hero"

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 SDK "Hero" 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 'Hero'" below.

The development environment: Flash Builder "Burrito"

Finally, the "Burrito" 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 "Burrito" 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 'Burrito'" below.
In subsequent releases, we plan to bring the power of Flash Builder's integrated design/development workflow with Flash Catalyst to mobile development as well.

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 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 with "Hero" 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 Adobe Flex SDK "Hero"

In order to address the design and development challenges listed above, the mobile features in "Hero" 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 "Hero", we've taken a few steps to ensure that a number of core Flex components work well on touchscreen devices.
For simple components like Button, CheckBox, and TextInput, we've provided a mobile theme in "Hero" 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 in the preview release of "Hero".

Figure 1. Some of the mobile component skins in the Flex "Hero" preview release.

Note that in this preview release, the mobile skins have been optimized for 240 dpi devices. On devices with lower pixel densities, such as tablets, these skins will appear a bit large by default—we'll be addressing this before our final release.
For more complex components, notably Scroller and List, we've added functionality to the core component to enable touch-and-throw scrolling. 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 provided with "Hero" will not have touch-enabled skins for all existing Spark components. Table 1 lists the set of components that are mobile-ready in the current preview release; we'll be adding more before the final release of "Hero", and will continue to make more components mobile-ready over time.

Table 1. Mobile-ready Flex components in the "Hero" preview release

Controls	Button CheckBox 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) TileGroup VGroup
Charts	All (add mx.swc and datavisualization.swc to library path)

Standard mobile application structure

In addition to skinning and extending the core components to work well on mobile devices, "Hero" 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

In "Hero", we've added the following components 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 MobileApplication to provide features for persisting data both in memory and between runs of the application, as described below.
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.

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 firstView property. 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. "Hero" 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.

MobileApplication

MobileApplication wraps all this functionality together into a convenient application class. By basing your application on MobileApplication, you automatically get a ViewNavigator for managing your views. MobileApplication 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, MobileApplication 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 MobileApplication, but still use the mobile theme in order to get the benefit of the mobile-optimized components and skins.

Performance optimizations

Because "Hero" 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, "Hero" provides the MobileIconItemRenderer class. This item renderer is built in ActionScript, and 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 the base MobileItemRenderer class 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 "Hero" 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. Note that by default, Flash Builder does not include the MX components on the library path of mobile projects; to use the charting components, you will need to manually re-add mx.swc and datavisualization.swc to your library path.
• 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 in "Hero" 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.

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 "Burrito"

Building on the mobile development features in Adobe Flex SDK "Hero", the next version of Flash Builder, codenamed "Burrito", extends the existing ActionScript and Flex development workflows to mobile development, from project creation through packaging the final application.

Managing mobile projects

"Burrito" 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.
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 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 MobileApplication, 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

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.
• When debugging on a device, in addition to connecting the device to your computer via USB, your device must be connected via WiFi to the same network your computer is on, because the debugger communicates with Flash Builder over the network (not over the USB tether). Additionally, you may have to temporarily disable your computer’s firewall, or open ports 7 and 7935. This only applies when debugging—just running the application doesn't require this.
• 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.

Where to go from here

We're excited to be able to bring the Flex SDK and Flash Builder to mobile development. Of course, since this is a preview release, not everything is implemented yet, and there's much more to come before our final release.
In the meantime, though, we hope you'll jump into building great mobile applications with "Burrito" and "Hero". Here are some resources to get you started quickly:

• Preview release labs page—contains downloads, tutorials, sample applications, and documentation for "Burrito" and "Hero"
• Adobe AIR Developer Center—for more information on AIR on mobile devices
• Flex Mobile, Part 1: Beginning a mobile application (ATV video)
• Flex Mobile, Part 2: Navigation and lists (ATV video)
  
• Flex Mobile, Part 3: Debug and package apps for devices (ATV video)
  

And, of course, we'd love to hear your questions and feedback on what we've done so far:

• Flash Builder forum
• Flex forum

Thanks : http://www.adobe.com/devnet/flex/articles/mobile_development_hero_burrito.html