Understanding Flex Mobile View and ViewNavigator

The Flex framework “Hero” makes the task of creating mobile applications for BlackBerry Tablet OS, Android, and soon iOS extremely simple. I think that one of the best looking apps for Android is MAX Companion 2010 and please bear in mind that this app was created using an early build of Flex “Hero”.

This is a reasonably complex application with lots of screens and social integration (Twitter) and yet on my Nexus One and Samsung Galaxy Tab it still works great. This is exactly where the Flex framework can shine on mobile devices: fast and easy development of applications that can connect to virtually anything (web services, REST services, RPC).

In this article I will talk about Flex Mobile Views and ViewNavigator. If you want to use Flex “Hero” to create mobile apps you need to understand how these components work.

Oh and one more thing, if you want to try this yourself you’ll need the Flash Builder “Burrito”. You can download it from here.

Screen Metaphor

Before talking about Flex mobile components let’s talk a little bit about a concept called screen metaphor. This is basically a neat solution for a very big problem any developer encounters when developing for mobile devices: screen real estate.

On a desktop computer we have enough resolution to fit all the information we want on the screen. By using hierarchical menus and pop-up windows we can push a lot to the screen. Compared to this, a smartphone screen feels (almost) like a stamp. Besides resolution, pixel density plays an important role  – my Nexus one has a resolution of 480X800 pixels and 254 pixels per inch. This means that you have to enlarge the text roughly two to four times compared to the same resolution on a desktop/laptop screen when building apps for mobile devices. Thus you end up with less space to display information.

Using the screen metaphor you can split the information/UI of your application on multiple screens. For example when a user wants to see details for a particular session (see the above pictures of MAX Companion 2010 app) another screen is presented. When he wants to go back to the session list, the previous screen is presented.

Elegant though it might be, the screen metaphor is not rocket science. However there are some things to be considered such as:

  • memory management – pushing dozens of screens can eat up all the memory available on the device
  • transitions from one screen to another – those nice effects that help you create an application like a professional UX Designer
  • passing data from one screen to another
  • preserving application state when the OS choose to close it
  • integration with hardware buttons – for example using the Back button of the phone to navigate to the previous screen

Fortunately, the Flex framework has built-in support for the screen metaphor so you don’t have to reinvent the wheel.

Flex Mobile Project

When you install Flash Builder “Burrito” you will notice that there are two new types of projects related to mobile: Flex Mobile Project and ActionScript Mobile Project.

If you want to use Flex support for mobile development you should choose Flex Mobile Project and on the second page of the wizard make sure you select Mobile Application (this option makes a project that has uses Flex built-in support for the screen metaphor). As you can see in the screen capture below, you can choose to target both BlackBerry Tablet OS and Google Android platforms or just one of these platforms (as I said before we are working to extend the reach of the Flex framework to iOS – sometime in 2011).

Once you click Finish you will have a project structured like this:

Compared to a desktop AIR project you have one extra file: views/MobileProjectHome.mxml. The other two files are the “usual suspects”: the main application file (MobileProject.mxml) and the application descriptor file (MobileProject-app.xml). So what you have here is a skeleton for a Flex mobile application that has a single screen/View for now: MobileProjectHome.mxml. And if you open the main application file (MobileProject.mxml) you’ll see that on the MobileApplication tag there is an attribute named firstView and its value is set to views.MobileProjectHome – this is how you set the default screen for your mobile app.

Now, I’d like to step back and tell you about the two options you have when building Flex mobile apps. The first one is to use MobileApplication like in the project above. However if you work on an application that has lots of screens, it might be a good idea to use TabbedMobileApplication. As the name suggests you’ll have an application with support for tabs and for each tab you can have a stack of screens/Views (for each tab you can define the default/first screen). Here is an example:

And here is the source code for the main application file:

Views and ViewNavigator

Now let’s dive deeper and see how you can use Views and ViewNavigator to build a mobile application. First of all, screen metaphor support is built-in in the MobileApplication/TabbedMobileApplication and ViewNavigator. You use View components to create the UI of your application.

If you want to add a second screen to your Flex mobile application you will create a new MXML component inside the views package (this is the folder created by new project wizard; of course you can choose to place the views in a different package) and this new component must be based on spark.components.View.

The spark.components.View class extends the Group component and is familiar if you have worked previously with Flex 4. For example here is the source code for a second screen (SecondScreen.mxml) that uses  VerticalLayout to lay down two components: a Button and a TextArea component:

And here is what the screen looks like on a device:

When you want to set a title for a screen you use the title attribute of the View component. What about changing the current View (screen) and moving to another one? Well, here comes in the ViewNavigator component.  The View component has a property called navigator (it represents the instance of ViewNavigator that manages the Views). Using this property you can push a new View (screen), move back to the previous View, jump to the first View and more:

  • navigator.push(SecondScreen, data) – move to a new screen
  • navigator.popView() – move back to the previous screen
  • navigator.popToFirstView() – jump to the first screen
  • navigator.activeView – returns the active view

Going back to our project, if you want to move to the second screen we’ve created earlier (SecondScreen.mxml) you can do something like this in the first screen (MobileProjectHome.mxml):

<?xml version="1.0" encoding="utf-8"?>
<s:View xmlns:fx="http://ns.adobe.com/mxml/2009"  xmlns:s="library://ns.adobe.com/flex/spark"
        title="Home">
    <fx:Script>
        <![CDATA[

        private function goToSecondScreen():void {
            navigator.pushView(SecondScreen);
        }

        ]]>
    </fx:Script>
</s:View>

What about moving back from the second screen to the first screen? Your application is automatically wired to listen to Back hardware button. Thus, if the user presses the Back button he will go to the previous screen. Or you can add to your application a software button that executes this code when pressed: navigator.popView().

If you want to pass some data from one view to another (for example an ArrayCollection or some other Data Model), then you can use the second argument of the navigator.pushView() method:

   navigator.pushView(SecondScreen, myData);

You can access the data pushed by the previous View in the current one by accessing the data property of the View class.

ActionBar

There are situations when you want to have at the top of your screen some sort of a bar that can be used for:

  • a title customized for the current information displayed
  • a navigation button to go back to the first screen
  • buttons for actions related to the current screen

Maybe you need something like this:

Again Flex comes to your rescue. For each view you can specify ActionBar content. This bar has three different areas: navigation content, title content, and action content. You can make use of any or all of them. Here is the code to add two buttons and a title to a View using the ActionBar component:

<?xml version="1.0" encoding="utf-8"?>
<s:View xmlns:fx="http://ns.adobe.com/mxml/2009"
        xmlns:s="library://ns.adobe.com/flex/spark">

        <s:navigationContent>
            <s:Button label="Back"/>
        </s:navigationContent>
        <s:titleContent>
            <s:Label text="This Title Vies"/>
        </s:titleContent>
        <s:actionContent>
            <s:Button label="Opt"/>
        </s:actionContent>

</s:View>

And here is the screenshot:

Some notes on ActionBar usage:

  • You can control the ActionBar visibility using the actionBarVisible View property. You can change this property at runtime
  • You can overlay the ActionBar on top of the View content using the overlayControls View property
  • You can set the ActionBar content in each View or, if you have some controls that are used across different Views you can set them up in the main application file. Then you can overwrite  just the bits you need to be different in each View. If you add a Back button in the main application file, then all views will have this button. However, if you decide the first View doesn’t need a Back button, you can override this by setting navigationContent to null in the first View:
<?xml version="1.0" encoding="utf-8"?>
<s:View xmlns:fx="http://ns.adobe.com/mxml/2009"
        xmlns:s="library://ns.adobe.com/flex/spark">

    <s:navigationContent/>

</View>
  • Although, you can control the ActionBar content from any View or from the main application file, in fact the content is managed by the ViewNavigator component

Views life cycle

Now let’s talk about the Views life cycle. There are three important events for any View that you should be aware of:

  • viewActivate (FlexEvent.VIEW_ACTIVATE) – Dispatched when the current view has been activated.
  • viewDeactivate (FlexEvent.VIEW_DEACTIVATE) – Dispatched when the current view has been deactivated.
  • removing (FlexEvent.REMOVING) – Dispatched when the screen is about to be removed in response to a screen change. If you called preventDefault() you can cancel the screen change. This event is triggered before the FlexEvent.VIEW_DEACTIVATE event.

A question that might bother you is what is happening with a View when the FlexEvent.VIEW_DEACTIVATE event is triggered? Well, the default behavior is that the view is destroyed. This is great because it keeps the memory foot print small as you push and pop Views.

This raises two more questions. What happens to the data you might have in a View when the View is destroyed? And, can you prevent a particular View from being destroyed? If you want to preserve the data you use in a View all you have to do is to assign those data to the View.data property. Suppose you read some data by calling a web service. Because this information doesn’t change too often and it takes a while to get it  from the Cloud you want to have the data saved. All you have to do is to assign the data you get from the web service to the View.data property.

If you want to prevent the entire View from being destroyed (maybe it is a complicated View and it takes too much to create it) you can use View object’s destructionPolicy attribute: destructionPolicy=”none”.

What about making sure that the entire application state is preserved in the case the application is closed by the OS? All you have to do is to set the sessionCachingEnabled attribute in your main application file to true. This is a neat feature that allows you to support (with no sweat) scenarios like this: the user navigates to the n screen of the application, he has some data on that screen and the application gets closed (maybe the user went to a new application or decided to close the app); when he opens the application again he will see the same screen as in the previous session.

The last point I want to make is related to the splash screen feature. If your application is not trivial then it will take some time to load. Instead of letting the user stare at an empty screen you can provide a static image. Once the application is loaded this image will be replaced by the actual UI. You can set up this image by using the splashScreenImage attribute in the main application file:

<?xml version="1.0" encoding="utf-8"?>
<s:MobileApplication xmlns:fx="http://ns.adobe.com/mxml/2009"
 xmlns:s="library://ns.adobe.com/flex/spark"
 firstView="views.ASimpleMobileAppHome"
 sessionCachingEnabled="true"
 splashScreenImage="@Embed(source='loading.png')">
...
</s:MobileApplication>

Where to go next

The Flex “Hero” release will make the mobile development much easier – even with the current preview release one can enjoy productivity boosts. Understanding the screen metaphor and how it is implemented in the Flex framework is an important first step, especially for people coming from the world of web/desktop development.

If you want to try for yourself the best thing to do is to go to Adobe Labs, grab the Flash Builder “Burrito” bits and read Ryan’s post on how to set up your environment to support PlayBook development.

55 thoughts on “Understanding Flex Mobile View and ViewNavigator

  1. Pingback: Video display issue in Adobe flex android mobile development? : Android Community - For Application Development

  2. Pingback: Video display issue in Adobe flex android mobile development? : Android Community - For Application Development

  3. Pingback: Understanding Flex Mobile View and ViewNavigator | TechnoVeille

  4. I wants to enable print from my flex mobile application which I am developing for iOS, Can you help me for that?

  5. Pingback: Feature – Flex 4.5 BlackBerry PlayBook & Geolocation

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>