by Adobe
Adobe logo

Created

19 June 2011

Run on a device

 
 

Code

DetailView.mxml
 
<?xml version="1.0" encoding="utf-8"?> <s:View gestureSwipe="view1_gestureSwipeHandler(event)" ...> <fx:Script> <![CDATA[ (...) protected function view1_gestureSwipeHandler(event:TransformGestureEvent):void { if(event.offsetX == 1)navigator.popView(); } ]]> </fx:Script> (...) </s:View>

Tutorial

In this tutorial, you make your server-side files available to the mobile device and then run the application on it.
 

 
Step 1: Make the server files available to the mobile device.

If the mobile device is on the same network as the computer, for testing purposes, you may be able to modify the project and code to simply reference the development server by its IP address. Otherwise, you need to place the server-side files on a publicly available web server. To deploy the server-side file to a publicly available server, follow the instructions in one of the sections below.
 
PHP setup
 
Follow the setup instructions in testdrive_setup.zip that you already used to deploy the server-side files to your local server to now deploy them to your public server.
 
Make sure the server has PHP 5.2.4 or later and that the PHP MySQLi Extension is enabled. If you are using a shared server, you may not be able to enable the MySQLi extension. In this case, you can either rewrite EmployeeService.php to use the older MySQL driver or you can instead move to another server or hosting company that does have it enabled.
 
Next, you need to set up the server so your application can call methods of server-side PHP classes. You need to:
 
  • Install the Zend Framework on the server.
  • Modify and upload the generated amf_config.ini and gateway.php files to your server.
The data service created with Flash Builder to make calls to your EmployeeService.php file uses Flash Remoting, a combination of client and server-side functionality that allows you to easily invoke methods of server-side classes. It uses Action Message Format (AMF) to exchange data between Flash Player or the AIR runtime and the remote service. AMF is a binary format used to serialize ActionScript objects and results in smaller data packets being sent over HTTP (than XML or web services) and hence, faster data exchange. Remoting capabilities are built in to Flash Player and the AIR runtime and work in conjunction with server-side classes that must be installed on the server. For PHP, these server-side classes are included as part of the Zend Framework.
 
Note: You can use the Zend Framework with any PHP server.
 
The Zend Framework is an open source, object-oriented web application framework that provides individual components for many common requirements in web application development, including Flash Remoting capabililties (Zend AMF). To install the Zend Framework on your server, either copy the Zend Framework folder added to your local server when you created the Flex data service (see Figure 1) and upload it to your server's webroot or download the latest version of the Zend Framework and install it instead.
 
Install the Zend Framework.
Figure 1. Install the Zend Framework.
Next, you need to modify and upload the additional server files needed to make Flash Remoting calls from your application. To see what files you need, return to Flash Builder and open the generated data service file, services.employeeservice._Super_EmployeeService.as. Locate the source , endpoint , and destination assignment statements (see Figure 2).
 
View the code specifying the location of the Flash Remoting endpoint.
Figure 2. View the code specifying the location of the Flash Remoting endpoint.
When you create a data service in Flash Builder, you specify the location of the PHP class to call. The name of this class is hard-coded in this generated service file but its location is not. If the PHP class ever changes, you can refresh the data service from the Data/Services view and the generated files will be updated. If you rename the PHP class, though, you will need to recreate the data service.
 
Note the endpoint , the URL to call, is set equal to gateway.php. When you created the data service, Flash Builder created this file. If you are using Flash Builder 4.5 for PHP Premium, it was created in the public folder of the PHP TestDrive project (see Figure 3). If you are using Flash Builder 4.5 Premium, it was created in the output folder specifed for the project. the bin-debug folder for the project. Locate the gateway.php and amf_config.ini files and open them. To open them in Flash Builder, right-click and select Open With > Text Editor.
 
Locate and open the gateway.php and amf_config.ini files.
Figure 3. Locate and open the gateway.php and amf_config.ini files.
gateway.php is the endpoint for all Flash Remoting requests from your application. It (along with the Zend Framework) handles the service request, invoking the correct class method and handling all data translation and packaging. It references a configuration file, amf_config.ini, which sets the location of the webroot, the location of Zend Framework, a production flag (to suppress debug messages), and the directories to look in for classes specified in service calls:
 
[zend] ;set the absolute location path of webroot directory, example: ;Windows: C:\apache\www ;MAC/UNIX: /user/apache/www webroot =/usr/local/zend/apache2/htdocs/ ;set the absolute location path of zend installation directory, example: ;Windows: C:\apache\PHPFrameworks\ZendFramework\library ;MAC/UNIX: /user/apache/PHPFrameworks/ZendFramework/library ;zend_path = [zendamf] amf.production = false amf.directories[]=TestDrive/services
Copy and paste these two files into a different folder called public on your computer so you can modify them and upload them to your production server. Open amf_config.ini and change the webroot and the zend_path variables to the appropriate paths on your server. Example settings on Windows and Linux servers may resemble the following:
 
webroot = D:\inetpub\domainname zend_path = D:\inetpub\domainname\ZendFramework\library webroot = /home/user/www zend_path = /home/user/www/ZendFramework/library
Make sure you do not have ending slashes or the remoting calls will fail. Locate the amf.directories[] setting.
 
amf.directories[]=TestDrive/services
It contains a list of the directories that contain classes used in Flash Remoting service calls. If you place the server-side classes somehere else on the server, you need to modify this value. Lastly, when no longer debugging the application, set amf.production to true.
 
If you are using Flash Builder 4.5 for PHP, upload the public folder with the modified files to the TestDrive folder on your PHP server. If you are using Flash Builder 4.5, place the gateway.php and amf_config.ini files in a folder called public and upload this folder to the TestDrive folder on your server (see Figure 4). Note, you can also upload these files directly to your webroot (or any other location); in that case, you would need to modify the endpoint used in the Flex data service class to match this location.
 
Upload the gateway.php and amf_config.ini files to your server.
Figure 4. Upload the gateway.php and amf_config.ini files to your server.
Test the gateway by browsing to http://yourserver/TestDrive/public/gateway.php. You should see the text Zend Amf Endpoint displayed. Your public server is now set up and you are ready to change your Flash Builder project to use the files on this server.
 
ColdFusion setup
 
Follow the setup instructions in testdrive_setup.zip that you already used to deploy the server-side files to your local server to deploy now them to your public server. If you are using a shared server, you usually cannot deploy CAR files so follow the instructions for setting up ColdFusion Standard using testdrive.zip. You should end up with a data source called testdrive_db and folder called TestDrive in your webroot (see Figure 5).
 
Install the server-side ColdFusion files.
Figure 5. Install the server-side ColdFusion files.
If you are using a shared server, you may need to make appropriate modifications. Solutions for several examples are listed below.
 
  • No Apache Derby Embedded data sources allowed. In this case, create a MySQL database using one of the scripts contained in the testdrive_setup_PHP.zip in the testdrive_setup.zip and then create a data source called testdrive_db for that MySQL database.
  • You cannot create a datasource called testdrive_db. On some shared servers, data source names cannot contain underscores or they must include your domain name (like domainname_testdrive). In this case, create a data source with an allowed name (like testdrive or domainname_testdrive) and then open EmployeeService.cfc, /ColdFusion/wwwroot/TestDrive/services/EmployeeService.cfc, and change all the testdrive_db references to your new data source name.
  • No access to the services-config.xml file. In this case, you cannot change the values of the force-cfc-lowercase , force-query-lowercase , and force-struct-lowercase values to true so you will probably need to make some changes to your code. These code changes and how to determine if you need to make them or not are covered in step 5.
That's it, your server is set-up and is ready to be used in your application. Before proceeding though, let's take a look at how this all works.
 
The data service created with Flash Builder to make calls to your EmployeeService.cfc file uses Flash Remoting, a combination of client and server-side functionality that allows you to easily invoke methods of server-side classes. It uses Action Message Format (AMF) to exchange data between Flash Player or the AIR runtime and the remote service. AMF is a binary format used to serialize ActionScript objects and results in smaller data packets being sent over HTTP (than XML or web services) and hence, faster data exchange. Remoting capabilities are built in to Flash Player and the AIR runtime and work in conjunction with server-side classes that must be installed on the server. For ColdFusion, these server-side classes are already included as part of the ColdFusion server.
 
Next, return to Flash Builder and open the generated data service file: services.employeeservice._Super_EmployeeService.as. Locate the source , endpoint , and destination assignment statements (see Figure 6).
 
View the code specifying the location of the Flash Remoting endpoint and the CFC.
Figure 6. View the code specifying the location of the Flash Remoting endpoint and the CFC.
Because the path to the CFC is specified in this file, it needs to be located in the same relative location on the public server as it was on the local server. If it isn't, you can also change the value of source in this _Super_EmployeeService.as file to reflect the path of the CFC on the server before compiling the application.
 
Note: If the CFC ever changes, you can refresh the data service from the Data/Services view and the generated files will be updated. If you move or rename the CFC, though, you will need to recreate the data service.
 
The endpoint is the URL used for all Flash Remoting requests from your application. It (along with other server-side classes) handles the service request, invoking the correct CFC method and handling all data translation and packaging. If you browse to this endpoint (make sure you include the final slash), you should get a blank page.
 
To understand the destination property, we need to take a look at several server-side configuration files. In Flash Builder, select Project > Properties and select Flex Compiler. You will see the following compiler argument (with the appropriate path for you server):
 
-services "/Applications/ColdFusion9/wwwroot/WEB-INF/flex/services-config.xml"
This compiler argument was added when you created the project (as a ColdFusion project using Flash Remoting). It specifies the location of the services-config.xml file that contains the details for how the communication between the application and the server should occur and what server-side classes handle the requests and translation and packaging of data.
 
If you locate and open this services-config.xml file, you will see settings for whether ColdFusion uses mappings to find CFCs, whether public as well as remote methods will be accessible, and how to handle the case of property values when converting between ColdFusion and ActionScript (since ColdFusion is case-insensitive and ActionScript is case-sensitive).
 
<coldfusion> <access> <use-mappings>true</use-mappings> <method-access-level>remote</method-access-level> </access> <use-accessors>true</use-accessors> <use-structs>false</use-structs> <property-case> <force-cfc-lowercase>true</force-cfc-lowercase> <force-query-lowercase>true</force-query-lowercase> <force-struct-lowercase>true</force-struct-lowercase> </property-case> </coldfusion>
Note: If you are not using ColdFusion 9, your configuration files will look slightly different. Refer to your ColdFusion documentation for details.
 
Near the top of the file, you will also see an include statement for a remoting-config.xml file.
 
<service-include file-path="remoting-config.xml" />
Locate and open the remoting-config.xml file, /ColdFusion9/wwwroot/WEB-INF/flex/remoting-config.xml. It contains a destination called ColdFusion that is used for calls to any ColdFusion component from a Flex application; the wildcard (*) character for the source means a CFC in any location can be called.
 
<destination id="ColdFusion"> <channels> <channel ref="my-cfamf"/> </channels> <properties> <source>*</source> </properties> </destination>
Note: You can also specify named destinations that are associated with a particular CFC endpoint.
 
The generated service file in your project—services.employeeservice._Super_EmployeeService.as—has its destination property set to this destination, ColdFusion and the source property is set to the location of the CFC from the webroot (see Figure 6).
 
Your public server is now set up and you are ready to change your Flash Builder project to use the files on this server.
 
Java setup
 
Follow the setup instructions in testdrive_setup.zip that you already used to deploy the services to your local server to deploy to your public server (see Figure 7). Open the /publicserver/testdrive/WEB-INF/web.xml file and remove the servlet and servlet-mapping tags for the RDSDispatchServlet.
 
Install the server-side Java files.
Figure 7. Install the server-side Java files.
If you are using a shared server, you usually cannot deploy WAR files so you will need to manually set up the application. The steps below are for a shared server that allows a single web application.
 
  1. Copy the /localserver/testdrive/photos/ folder and place it on your public server so you have http://publicserver/testdrive/photos/.
  2. Copy the /localserver/testdrive/test/ folder and place it on your public server so you have http://publicserver/testdrive/test/.
  3. Copy the /localserver/testdrive/WEB-INF/database/ folder and place it in your public server's WEB-INF folder so you have http://publicserver/WEB-INF/database/.
  4. Copy the /localserver/testdrive/WEB-INF/flex/ folder and place it in your public server's WEB-INF folder so you have http://publicserver/WEB-INF/flex/. If your public server already has a flex folder, just open both the local and remote remoting-config.xml files and copy the employeeService destination in the local file and paste it in the remote file.
  5. Copy the services folder, /localserver/testdrive/WEB-INF/classes/services/, and place it in your public server's /WEB-INF/classes/ folder.
  6. Copy the files in the /localserver/testdrive/WEB-INF/lib/ folder except the flex-rds-server.jar and place them in your public server's /WEB-INF/lib/ folder.
  7. Make a copy of /localserver/testdrive/WEB-INF/web.xml and open it and remove the servlet and servlet-mapping tags for the RDSDispatchServlet.
  8. If a web.xml file is used for your shared server application, upload this file to your public server's WEB-INF folder. If it is not, which is more likely the case, you need to contact the hosting company and send them this XML file and have them create the MessageBroker servlet mapping for you.
  9. Browse to http://yourserver/messagebroker/amf. If you get a blank page, the servlet mapping was successfully created.
That's it, your server is set-up and is ready to be used in your application. Before proceeding though, let's take a look at how this all works.
 
The data service created with Flash Builder to make calls to your EmployeeService.class file uses Flash Remoting, a combination of client and server-side functionality that allows you to easily invoke methods of server-side classes. It uses Action Message Format (AMF) to exchange data between Flash Player or the AIR runtime and the remote service. AMF is a binary format used to serialize ActionScript objects and results in smaller data packets being sent over HTTP (than XML or web services) and hence, faster data exchange. Remoting capabilities are built in to Flash Player and the AIR runtime and work in conjunction with server-side classes that must be installed on the server. For Java, these server-side classes are included as part of BlazeDS (and Adobe LiveCycle Data Services).
 
BlazeDS is an open source, server-based remoting and web messaging technology for J2EE servers. It includes Flash Remoting capabililties for calling methods of server-side Java classes, a proxy service, and a messaging service for pushing data to clients for real-time data applications. LiveCycle Data Services includes these and additional features. See this chart for a comparison between BlazeDS and LiveCycle Data Services.
 
Next, return to Flash Builder and open the generated data service file, services.employeeservice._Super_EmployeeService.as. Locate the endpoint and destination assignment statements (see Figure 8).
 
View the code specifying data for Flash Remoting calls.
Figure 8. View the code specifying data for Flash Remoting calls.
Note: If the service class ever changes, you can refresh the data service from the Data/Services view and the generated files will be updated. If you move or rename the service class, though, you will need to modify the destination mapping (which we'll take a look at next) and recreate the data service.
 
The endpoint is the URL used for all Flash Remoting requests from your application. It (along with other server-side classes) handles the service request, invoking the correct class method and handling all data translation and packaging. This URL is mapped to a MessageBroker servlet in the web.xml file. If you browse to this endpoint, you should get a blank page.
 
To understand the destination property, we need to take a look at several server-side configuration files. In Flash Builder, select Project > Properties and select Flex Compiler. You will see the following compiler argument (with the appropriate path for you server):
 
-services "/Applications/tomcat/webapps/testdrive/WEB-INF/flex/services-config.xml"
This compiler argument was added when you created the project (as a J2EE project using Flash Remoting). It specifies the location of the services-config.xml file that contains the details for how the communication between the application and the server should occur and what server-side classes handle the requests and translation and packaging of data.
 
Navigate to the flex folder in the /WEB-INF/flex folder. It contains all the BlazeDS configuration files. Open the services-config.xml file. It contains an include statement for a remoting-config.xml file.
 
<service-include file-path="remoting-config.xml" />
Locate and open the remoting-config.xml file, /WEB-INF/flex/remoting-config.xml. It contains a destination called employeeService that is a mapping to the services.EmployeeService class. If you place your service file in a different location on the server, you need to modify this destination.
 
<destination id="employeeService"> <properties> <source>services.EmployeeService</source> <scope>application</scope> </properties> </destination>
When you created the data service in Flash Builder, you selected a destination from a list of the destinations; this list was created from the destinations defined in the remoting-config.xml file. The destination you selected, employeeService, was set to be the destination in the generated service file in your project: services.employeeservice._Super_EmployeeService.as (see Figure 8).
 
Return to the server files (on the local or remote server) and look in the /WEB-INF/lib folder (see Figure 7). Most of these JAR files include classes for handling communication between Flash Player or the AIR runtime and the server except flex-rds-server.jar and derby.jar. The flex-rds-server.jar is new to BlazeDS 4 and is used by Flash Builder at development time to create a data service by introspecting the server-side classes. You do not need this file on your production server and can remove it. The derby.jar is, of course, for the Apache Derby embedded database that this application uses.
 
Lastly, open the /WEB-INF/web.xml file. (If using a shared server, you may not have or need this file on your public server. Open the version for the local server). You need to copy this file to the production WEB-INF folder as well. If the production web application already has a web.xml configured, you can just copy the servlet mapping for MessageBrokerServlet and listener for HttpFlexSession . Here is the code:
 
<!-- Http Flex Session attribute and binding listener support --> <listener> <listener-class>flex.messaging.HttpFlexSession</listener-class> </listener> <!-- MessageBroker Servlet --> <servlet> <servlet-name>MessageBrokerServlet</servlet-name> <display-name>MessageBrokerServlet</display-name> <servlet-class>flex.messaging.MessageBrokerServlet</servlet-class> <init-param> <param-name>services.configuration.file</param-name> <param-value>/WEB-INF/flex/services-config.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>MessageBrokerServlet</servlet-name> <url-pattern>/messagebroker/*</url-pattern> </servlet-mapping>
The other servlet mapping you see in the web.xml file is for the RDSDispatchServlet which is used by Flash Builder to create a data service by introspecting server-side classes at development time. If you did not already, remove it from the web.xml file on the public server (if it has a web.xml file).
 
Your public server is now set up and you are ready to change your Flash Builder project to use the files on this server.
 

 
Step 2: Change the application server for the project.

If you are using Flash Builder, select Project > Properties > Flex Server and change the root URL to the webroot for your application (see Figure 9). For Java, also set the context root. Click the Validate Configuration button. If you are using Flash Builder 4.5 for PHP, do not complete this step (there is currently a bug and you cannot successfully change the root URL to a different server).
 
You may get a warning message at the top of the window that the web server cannot be accessed, but that's OK. Do not modify the web root or the root folder.
 
If you are using Java on a shared server, your context root may be blank.
 
Change the root URL for the project.
Figure 9. Change the root URL for the project.

 
Step 3: Locate and if necessary set the new remoting gateway.

Open services.employeeservice._Super_EmployeeService.as and look at the new value for the endpoint (see Figure 10). If necessary, modify it. If you are using Flash Builder 4.5 for PHP,  be sure to modify this endpoint to point to the gateway.php file on your public server.
 
Locate the new endpoint.
Figure 10. Locate the new endpoint.
For PHP, if you placed your gateway.php and amf-config.ini files somewhere else on the server, modify this path appropriately (see Figure 11).
 
For ColdFusion, the endpoint URL should look like this:
 
_serviceControl.endpoint = "http://yourserver/flex2gateway/";
...and for Java, like this:
 
_serviceControl.endpoint="http://yourserver/testdrive/messagebroker/amf";
If you have no context root, the URL will not contain /testdrive/.
 

 
Step 4: Change the URLs for the photos.

In FlexMobileTestDriveHomeView.mxml, change the return string for the getPhotoURL() function in the IconItemRenderer to use the appropriate URL for the photos directory on the public server. In DetailView, change the value of the source property for the Image control.
 
Change the URL for the photos in FlexMobileTestDriveHomeView.mxml:
 
private function getPhotoURL(item:Object):String{ return "http://yourserver.com/TestDrive/photos/"+ item.photofile; }
Change the URL for the photos in DetailView.mxml:
 
<s:Image x="10" y="10" width="100" height="100" source="http://yourserver.com/TestDrive/photos/{getEmployeesByIDResult.lastResult.photofile}"/>

 
Step 5: Enable the Network Monitor and run the application.

In the Network Monitor view, click the Enable Monitor button (see Figure 12) and then run the application using the device emulator.
 
Enable the Network Monitor.
Figure 12. Enable the Network Monitor.
You should see the data and images displayed in the application exactly as before, except now the service file and photos are being accessed on your public server instead of locally. Select an employee and make sure you see the employee details. If you are using ColdFusion and do not see employee details, you probably did not or could not set the force-struct-lowercase property to true in the services-config.xml file on the public server.
 
Return to Flash Builder and look at the Network Monitor view. You may want to double-click the tab to make it full screen so you can see all the data better. You should see that the remoting calls are now being made to the gateway on your public server (see Figure 13). Note, Flash Player pings the endpoint first to see if it is available before making the actual call and sending any data.
 
View the network calls made by the application.
Figure 13. View the network calls made by the application.
Select the getEmployeeSummary operation and in the Tree view, click the Response tab and then expand the response body (see Figure 14).
 
View data returned for the getEmployeeSummary operation.
Figure 14. View data returned for the getEmployeeSummary operation.
Select the getEmployeesByID operation and expand the response body. If you are using a shared ColdFusion server and could not change the services-config.xml file to force structures to be returned in lowercase, the properties will be in uppercase (see Figure 15).
View data returned for the getEmployeeByID operation on a shared ColdFusion server.
Figure 15. View data returned for the getEmployeeByID operation on a shared ColdFusion server.
ActionScript is case-sensitive so when Flash Player creates an Employee instance with the return data, all the lowercase properties ( state , officephone , and so on) have no matching values and so remain null. That's why you didn't see any detail data. The objects created from ColdFusion query obects automatically get lowercase properties; those for structures do not unless force-struct-lowercase is set to true in the services-config.xml file.
 
If you are using a shared server and cannot modify services-config.xml, you need to modify your code in DetailView.mxml.
 
First, In the Data/Services panel, change the return type of getEmployeeByID() back to an Object. Next, in the Script block, define a bindable, private variable called employee of type Employee and instantiate it. Be sure to select Employee from Content Assist so the import statement is written for you.
 
import valueObjects.Employee; [Bindable]private var employee:Employee=new Employee();
Locate the getEmployeeByIDResult CallResponder in the Declarations block and generate a result handler for it.
 
<s:CallResponder id="getEmployeesByIDResult" result="getEmployeesByIDResult_resultHandler(event)"/>
Inside the generated handler, set the properties of the employee object to those returned from the operation call. You can reference the data as getEmployeesByIDResult.lastResult or as event.result .
 
protected function getEmployeesByIDResult_resultHandler(event:ResultEvent):void { employee.firstname=getEmployeesByIDResult.lastResult.FIRSTNAME; employee.lastname=event.result.LASTNAME; //set other properties }
Now you need to bind your component properties to the employee variable instead of getEmployeesByIDResult . lastResult . Be sure to also change the view's title property and the image's source property. For example:
 
<s:Label text="{employee.title}"/>
After changing all the bindings, run the application and select an employee. You will initially see null null for the title and a broken image link which get replaced after the data is retrieved from the server and the employee variable is populated. To keep this from occuring, remove the title property from the View tag and the source property from the Image tag and set these values in the result handler instead.
 
protected function getEmployeesByIDResult_resultHandler(event:ResultEvent):void { // more code title=employee.firstname +" "+employee.lastname; image.source="http://yourserver/TestDrive/photos/"+employee.photofile; }

 
Step 6: Run the application on a device.

Follow the steps in one or more of the sections below.
 
 
Run on a Google Android device
It's easiest to run and test your application on a Google Android device because you can deploy the application without having to sign the application package—which is required for Apple iOS and Blackberry Tablet OS devices. All you need to do is enable USB debugging on the device, connect it via USB to the computer, create a Flash Builder run configuration for it, and then run the application.
 
  1. On your Google Android device, navigate to Settings > Applications > Development and make sure USB debugging is enabled (see Figure 16). This setting must be selected so Flash Builder can install applications on your device without notification.
Enable USB debugging on your device.
Figure 16. Enable USB debugging on your device.
  1. Connect your Google Android device to your computer's USB port and if using Windows, follow the prompts to install a device driver.
  2. In Flash Builder, select Run Configurations from the Run menu or from the dropdown list for the Run button and click the duplicate button.
  3. Change the name of the new configuration to FlexMobileTestDrive (android), set the target platform to Google Android, set the launch method to On device, and click Run (see Figure 17).
Create a run configuration for running on a Google Android device.
Figure 17. Create a run configuration for running on a Google Android device.
The application should be installed and launched on the device (see Figure 18). If the AIR runtime is not installed on the device, it will be installed first.
 
Run the application on a Google Android device.
Figure 18. Run the application on a Google Android device.
  1. Rotate the device and see the application resize. Select an employee and see the employee details (see Figure 19). Click the back button to return to the employee list.
View employee details on a rotated Google Android device.
Figure 19. View employee details on a rotated Google Android device.
  1. Look at the list of applications on the device. You will see your application listed using a default name and icon (see Figure 20). You will learn to customize the name and icon in a later tutorial.
Locate the installed application on the Google Android device.
Figure 20. Locate the installed application on the Google Android device.
  1. Return to Flash Builder and locate the APK file in the bin-debug folder (see Figure 21). This is the Android package file. This is a debug version of the application that was installed on the Android device. You learn to create a release version of the APK for distribution in a later tutorial.
Locate the debug Android package created.
Figure 21. Locate the debug Android package created.
 
Run on an Apple iOS device
To run and test your application on an Apple iOS device, you must first create an Apple developer certificate and a provisioning profile for this application and the iOS device(s) you want to run it on. To create these files, follow the steps in the Using Flash Builder 4.5 to package applications for Apple iOS devices tutorial. After you've created these files, you use Flash Builder to convert your application into a native iOS application; you specify these files in the project's packaging info and then create a run configuration for iOS devices. Flash Builder creates an IPA application package that you add to iTunes and then sync to your device.
 
Because iOS devices do not have back buttons, you need to add a way to return to the main view of the application from the detail view. You could add a back button to the navigator area of the action bar or create a listener for a gesture event, which is what you will do here.
 
  1. In Flash Builder, return to DetailView.mxml and register to listen for the view's gestureSwipe event and create a handler.
  2. Your View tag should appear as shown here:
     
<s:View viewActivate="view1_viewActivateHandler(event)" gestureSwipe="view1_gestureSwipeHandler(event)" ...>
    The gestureSwipe event broadcasts a TransformGestureEvent object:
     
protected function view1_gestureSwipeHandler(event:TransformGestureEvent):void { }
  1. Inside the handler, return to the previous view if the user swipes left. To check the direction of a swipe, check the event object's offsetX and offsetY properties that specify the translation since the previous gesture event. For a left swipe, check to see the offsetX is 1.
protected function view1_gestureSwipeHandler(event:TransformGestureEvent):void { if(event.offsetX == 1)navigator.popView(); }
  1. In Flash Builder, select Run Configurations from the Run menu or from the dropdown list for the Run button and click the duplicate button.
  2. Change the name of the new configuration to FlexMobileTestDrive (iOS), set the target platform to Apple iOS, set the launch method to On device, and select either standard or fast packaging (see Figure 22).
Figure 22. Create a run configuration for running on an Apple iOS device.
Figure 22. Create a run configuration for running on an Apple iOS device.
  1. In the Run Configuration dialog box, click the Configure link next to Packaging settings have not yet been configured (see Figure 22).
  2. Specify your P12 certifcate and provisioning file (see Figure 23). To create these files, follow the steps in the Using Flash Builder 4.5 to package applications for Apple iOS devices tutorial.
Figure 23. Specify Apple iOS packaging info.
Figure 23. Specify Apple iOS packaging info.
  1. In the Run configuration dialog box, click the Run button and then enter your certificate password in the Certificate Password dialog box. Flash Builder will convert your application to a native iOS application. You will get a Packaging Completed dialog box when the process is finished.
  2. Locate the application IPA file in your Flash Builder bin-debug folder (see Figure 24). This is a debug version of the application. You learn to create a release version of the IPA for distribution in a later tutorial.
Figure 24. Locate the debug Apple iOS package created.
Figure 24. Locate the debug Apple iOS package created.
  1. Connect your iOS device to your computer's USB port and open iTunes.
  2. Add the provisioning profile and IPA file to iTunes. You can add the files on a Mac by dragging the files and dropping them on the iTunes icon in the dock. Optionally on any platform, in iTunes, select File > Add to Library and add each file.
  3. Locate your new application in apps (see Figure 25). Currently, a default name and icon are used for the application. You will learn to customize these in a later tutorial.
Figure 25. Locate the application in iTunes.
Figure 25. Locate the application in iTunes.
  1. Add the application to the iOS device. In iTunes, select the attached device and make sure your application is selected to be synced on the device and then sync the device (see Figure 26).
Figure 26. Add the application to the Apple iOS device.
Figure 26. Add the application to the Apple iOS device.
  1. Locate the application on the device (see Figure 27) and run it (see Figure 28).
Figure 27. Locate the installed application on the Apple iOS device.
Figure 27. Locate the installed application on the Apple iOS device.
Figure 28. Run the application on the Apple iOS device.
Figure 28. Run the application on the Apple iOS device.
  1. Rotate the device and see the application resize. Select an employee and see the employee details (see Figure 29). Swipe left to return to the main view.
Figure 29. View employee details on a rotated Apple iOS device.
Figure 29. View employee details on a rotated Apple iOS device.
 
Run on a BlackBerry Tablet OS device
For details on how to run on a BlackBerry Tablet OS device, see the Using Flash Builder 4.5 to package applications for BlackBerry Tablet OS devices tutorial.
 
In this module, you created a Flex mobile application that retrieves and displays database records. You tested the application in the Flash Builder ADL device emulator and on an actual physical device. In the next module, you enhance the application, adding the ability to make phone calls, send emails and text messages, and to add, update, and delete database records.
 

 
Learn more

Refer to the following resources to learn more about this topic:
 
 
Documentation: Using Flex 4.5
 
Documentation: Using Adobe ColdFusion 9
 
Flex Developer Center
 
Adobe AIR Developer Center