To build a Flex application for Mobile is very easy, provided you use Flash Builder. When it comes to automating that build, things are not as easy. Because recently I’ve managed to overcome the obstacles that were preventing me to build a running Flex 4.5 app for mobile, I want to share the build.

I’ve taken the initial build from this thread. Marvin Froeder ( a.k.a VELO ) has been doing some hard work recently, creating the Enterprise version of Flex Mojos. This version seems pretty promising. I’m looking forward for its release. When you’re testing the build, make sure you register during the build, following the instructions. The process is fairly easy, but … rewarding. The maven build creates the final apk/air/exe/dmg…, which you can use to install the app on your device. It’s worth trying it.

To build the app, you need to execute

mvn3 clean install package

Prior to the build, you need to make sure you have Maven 3 installed, with the following environment variable:

MAVEN_OPTS="-Xmx1024m -Xms128m -XX:+DisableAttachMechanism"

Also, you need to have the mobile theme installed in a repository. As of today, the flex mojos repository doesn’t contain this theme, so you need to install it manually.

When the build ends, connect your device to the computer and execute:

adb install -r ./target/mobile-1.0-SNAPSHOT.apk

Then, go to your device and open “main” application.

If you see the following screen, it means that the application got compiled successfully.

Screenshot showing the app built with Maven

This plugin is useful when you want to debug Unit Test or Automated Tests which are failing in the CI machine.

For me information you can check http://wiki.hudson-ci.org/display/HUDSON/FlashLog+Plugin

The build was failing due to a SVN error occurring when maven was committing into SVN, into the tags folder, the current version of the project:

[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Commit failed (details follow):
svn: File '/svn/path/to/my/file/myclass.java' already exists

Solution
The solution is rather a workaround, than a solution: force a svn update before committing the code into SVN repository.
Searching to see if other people have had a similar problem I discovered this bug, and in one of the comments of the bug I saw the workaround:

# mvn release:prepare
== fails ==
# svn up -r head
# mvn release:prepare -Dresume

As you can see, you are being suggested to do a svn update after the build fails and resume the release process from that point.

I tested this workaround, and luckily for me, it worked. Going further, I thought that’s great, but how can I deal with these extra steps on my continuous integration machine ? I didn’t want to create a special job just to do the release of my library, so I started to see if I can integrate this workaround into a single maven command line.

Looking into the Maven Release Plugin, I discovered the preparationGoals property. As the documentation specifies, it defines which “goals to run as part of the preparation step, after transformation but before committing.“.

Into these preparation goals I executed a shell command, using Maven Exec Plugin.

mvn -e release:clean release:prepare release:perform \
  -DpreparationGoals="clean install exec:exec" \
  -Darguments="-Dexec.executable=svn -Dexec.args=up"

This single command did in the end the same thing. Forced a svn update before committing the code into SVN.

Apparently this bug occurs only for SVN versions up to 1.6.4. In SVN version 1.6.5 this shouldn’t be a problem anymore. Too bad that Google Code uses older versions of SVN.

Adobe is always looking for the best solution to meet any business challenge. Recently, we set out to empower call center agents with faster, smarter access to information—giving them instant access to the information they need to answer customer questions. By leveraging the Adobe Flash Platform, we created a dynamic and sophisticated RIA that gives call center agents an intuitive, rich interface for accessing data in complex enterprise systems. Almost instantly, service agents can identify customers’ primary concerns, quickly locate the appropriate information, and address customer requests faster than ever. The RIA is helping us exceed our customers’ service expectations—and improve agent training and reduce costs as byproducts. To read more about the world-class customer service RIA, check out the story on the Adobe Customer Showcase.

To view a demo, you can also watch the 14 mins MAX keynote – “Pimp my App”.

Technology stack used to develop this product:

• Adobe LiveCycle Data Services ES2
• Adobe Flex SDK.
• Adobe Flash Builder
• Adobe Flash Catalyst
• Adobe Illustrator CS5
• Adobe Photoshop CS5

Running unit tests with maven, that require runtime resources such as runtime CSS, runtime resource bundles, or other resources throws error because the resources have not been marked as trusted.

To be more detailed, maven has a file within the #Security folder of Flash Player, in which it stores a list with trusted swfs. For example, when maven runs the unit tests, it automatically adds the FlexUnit.swf to be trusted by Flash Player. This file, named maven.cfg is stored into ~/Library/Preferences/Macromedia/Flash\ Player/#Security/FlashPlayerTrust/ folder on a Mac. Other operating systems have a different path, as described in this link .

In my case, the problem was that I was writing some unit-tests that would load modules placed under /src/test/resources folder within my maven project.

Solution

flexmojos:trust

In other words, I had to add this little script to the maven build in order to fix my problem:

<build>
    <plugins>
        <plugin>
            <groupId>org.sonatype.flexmojos</groupId>
            <artifactId>flexmojos-maven-plugin</artifactId>
            <executions>
                <execution>
                    <goals>
                        <goal>trust</goal>
                    </goals>
                    <configuration>
                        <filesToTrust>
                            <file>target/test-classes/test/LoginModule.swf</file>
                            <file>target/test-classes/test/LoginModuleSkin.swf</file>
                        </filesToTrust>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

After updating the pom.xml and running "mvn test" command, I could notice that my files were added to the maven.cfg file.

[INFO] Updating Flash Player Trust directory .../target/test-classes/test/LoginModule.swf
[INFO] Updating Flash Player Trust directory .../target/test-classes/test/LoginModuleSkin.swf

I’m going to summarize here the points, ordering them by how often you would face during development, and I invite you to go through the entire article for a more in-depth picture.

• Freezing and unfreezing objects. The secret here is to to be very cautious with the objects that are not visible, or not needed anymore.  There is also a method in the Loader class, unloadAndStop(). This method can enforce the Garbage Collector to run on the child SWF objects, if you call it with unloadAndStop( true ).
• Timers versus ENTER_FRAME events What is important here is to avoid using ENTER_FRAME events, and minimize as much as possible the usages of Timer objects.
• Activate and Deactivate Events. These are used to detect  background inactivity, and detect when Flash Player has lost the focus. When Flash content looses focus it’s worthy to decrease the frame-rate, and maybe cancel some background operations.
• Mouse interactions. This can be CPU-intensive, especially when the object tree is rich. Flash Player enables you to disable some UI components to respond to mouse event, using myUIComponent.mouseEnabled=false;
• Animations. Use them, but be aware that currently they are executed by the CPU, not the GPU. In the near future, this processing would move to GPU, easing the CPU, but until then, be careful with the rendering.
• Built-in Flash Player 10.1 enhancements. These are interesting and it’s good to be aware of.

Problem

After 30 playbacks or recordings the automation agent within Flex SDK stopped with the error “License not present. With the trial verison only limited replays are allowed.”

My Flex application was compiled with Flex SDK 4.1.0.16076 and with Maven. When compiled with a registered Flex Builder, the licensing information is automatically added into the flex app so you don’t have this problem anymore.

The problem is most likely to appear when building from a Continuous Integration machine and you need to use ant or maven, instead of Flash Builder.

Solution

In order to get rid of the error I had to compile the Flex application with a valid serial number of Flash Builder. To find out how to provide a license number, I looked at the mxmlc options:

osx:bin dragos$ ./mxmlc -help details licenses
Adobe Flex Compiler (mxmlc)
Version 4.1.0 build 16076
Copyright (c) 2004-2009 Adobe Systems, Inc. All rights reserved.

-licenses.license
    alias -license
    specifies a product and a serial number.  (repeatable)

Knowing my serial number, I asked myself what should I put as product name.
Looking on the internet I found people using “flexbuilder3″ in the following way:
-licenses.license flexbuilder3 xxxx-xxxx-xxxx-xxxx-xxxx-xxxx

What I didn’t find on the internet is that for Flash Builder 4, the product name has changed:
-licenses.license flashbuilder4 xxxx-xxxx-xxxx-xxxx-xxxx-xxxx

Since I was building with Maven on the continuous integration machine, I had to find a way to add the license information to flexmojos:

<plugin>
    <groupId>org.sonatype.flexmojos</groupId>
    <artifactId>flexmojos-maven-plugin</artifactId>
    <version>${flex-mojos.version}</version>
    <extensions>true</extensions>
 
    <dependencies>
        <dependency>
            <groupId>com.adobe.flex</groupId>
            <artifactId>compiler</artifactId>
            <version>${flex.sdk.version}</version>
            <type>pom</type>
        </dependency>
    </dependencies>
 
<configuration>
    <configurationReport>true</configurationReport>
    <licenses>
        <flashbuilder4>${fb.license}</flashbuilder4>
    </licenses>
    </configuration>
</plugin>

Until know, only developers with Flex knowledge, speaking ActionScript language could shape a Flex Application, applying the look & feel provided by a visual designer. Unlike developers, designers don’t speak ActionScript. Instead, they speak Illustrator, Photoshop, Corel Draw, Flash, Fireworks, or the language of another tool out there. A designer would feel much more comfortable drawing a shape ressembling to a button rather than typing a code like

<s:Button id="submitButton" label="Submit" bottom="10" right="10" />

In this presentation my intention was not to advertise Catalyst, but rather to focus on the productivity aspects and what is the best way to use this tool to create RIAs.

Problem
Catalyst is a great tool to create prototypes of Flex Applications quite easy. Even though Catalyst is a powerful tool, sharing a project between Catalyst and Flash Builder, between a designer and a developer, is quite challenging. Once the prototype is signed off by the client and it needs to be implemented by developers, issues arise :

• From a designer perspective, Catalyst feels great. Firstly, because Catalyst integrates well with Illustrator and Photoshop. If an effect is harder to create with Catalyst, a designer can always right click and choose to “Edit in Adobe Illustrator”. Besides that, the designer can easily add actions to objects and grasp a bit of the look&feel of the application.
  
  
  Problem is that, in a short while, designers will notice that there are few connections between their Catalyst project and the actual application, even though that application is built with the design they created in Catalyst. Before, all they had was Flash or Illustrator approach, creating only designs for how stuff looks. Now, even thought they have control over where the stuff is positioned, how it behaves, transitions, they’ll realize that they’re still away from the actual application. They create prototypes, but they’re still waiting for developers to implement their modifications.
  
  
  This feels better than before, but it’s not perfect.
• From a developer perspective, things are not as great either. It’s hard to work with a machine generated code, thus it’s hard to work with the raw code generated by Catalyst. Sometimes, it’s hard even for humans to write code that humans can understand. Martin Fowler has a say: Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
  
  
  So don’t expect Catalyst to grab an Adobe Illustrator file and turn it into a perfect MXML. A programmer will not be able to easily use the raw code generated by Catalyst; copy-paste might be the only way to grab the Visual Design and place it into Code, by scanning through the read-only Code-view exposed by Catalyst and getting the pieces that make sense for a developer, and place those pieces into skin files.
  
  
  Besides that, the FXP container, it’s a single file. As a programmer you want to keep you source files into a versioning file system, instead of a single file container.
  
  
  So now it’s indeed easier to get the complex shapes and shades that the designer creates, because they’re now available in FXG format, which Flex 4 can read. But still, things are not perfect since developers sill need to filter all that raw code generated by Flash Catayst, and only get the modifications they’re interested in.

Solution
Long story short: fix the issues mentioned. In other words:

• For a designer:
  • Easily test the UI changes into the real application
  • And preview the real application straight from Catalyst
• For a developer:
  • Use straight what Catalyst provides.No extra copy-paste from Catalyst into Flash Builder.
  • No more headakes to match the pixel perfect visual design
  • More focus on functionality, less focus on design

You can achieve all these with this first release of Catalyst, event though it’s not that straight forward.
I’m going to describe here a few things that helped me solve these issues for a current project. If you’re comfortable with Flash Catalyst, you can download the Catalyst project now to experience it, and then continue.

• First, I added these 2 buttons in the Flash Catalyst project, to enable the designer to easily switch from Visual Design to the real application
  
• Then I placed these under a Catalyst layer, which I called it “Top Toolbar”.
  
• This next step represented the main challenge: how to manage both Flash Catalyst file and Flash Builder files.
  
  
  Flash Catalyst had all the code bundled into a FXP file, while the real project had modules, each module had a separate project, so the configuration differed quite a lot. As you can see, in the next image, in the right side I have 4 Flex projects, while in the left side, I have only the Flash Catalyst project
  
  The question is how to merge the two, in a way that is productive for both the developer and the designer.
  • The first solution that came to my mind would have been to duplicate the code base out of the 4 projects, and place that code into the Catalyst project. This solution wasn’t so nice because it could have generated a lot of duplicated code to be maintained.
  • The next solution I liked it better. I thought to myself why not take advantage of the modular structure, and instead of maintaining a lot of source code files, maintain only 1 file for each module, which is the compiled SWF file. This way, with only a few files added to the Catalyst project, the designer can have the entire application at hand.
    
    To achieve this I had to go through several steps ( only developers are required to do this. The designer shouldn’t even care as long as the visual design remains the same):
    1. With Flash Builder: Split the application in functional areas and compile each area into a flex module. These are the modules to be loaded when running the Catalyst Project. This step is important because developers need to think well what is functionality, and what is skin and skin-behavior. The functionality would eventually stay in the modules, while the skin and its behavior would be exposed through a Main.css file to the Flash Catalyst.
    2. With Flash Builder: Make the main application only a shell-like application which only loads modules and also loads a main skin file compiled as SWF, at runtime.
    3. With Flash Catalyst and Flash Builder: Isolate the skins and skins behavior into skin classes. Expose these skin classes through the CSS file.The Main.css file should be good enough to store all about how application looks and feels.
       
       
       

       @namespace s "library://ns.adobe.com/flex/spark";
       @namespace mx "library://ns.adobe.com/flex/mx"; 
        
       s|Application
       {
       	font-family: "Myriad Pro";
       	font-lookup:embeddedCFF;
       }
        
       @font-face
       {
       	fontFamily: "Myriad Pro";
       	src: url("/Users/dragos/Library/Fonts/MyriadPro-Regular.otf");
       	embedAsCFF: true;
       }
       .videoControlBar
       {
       	skinClass: ClassReference("skins.controlBar.VideoControlBarSkin");
       	horizontal-center: 0;
       	bottom: 15;
        
       	font-family: "Myriad Pro";
       	font-size: 9;
       	color: #CCCCCC;
       }
       .videoPlayer
       {
       	left:0;
       	right:0;
       	top:0;
       	bottom: 40;
       }

       As you can see, I even declared the position of the video player in the screen, so that the bottom part leaves a space for the control bar. If later, the designer comes back to this and wants to make the control-bar overlay with the video, I could set “bottom:0″ for .videoPlayer and I can achieve this.

    4. With Flash Catalyst and Flash Builder: Create a configuration describing which modules to load into Catalyst. This will enable the designer to see the actual application, or maybe just a part of it. This is how I declared the modules:

       ...
       <fx:Declarations>
       <config:MediaCenterConfigurationDto id="defaultConfiguration">
       	<config:modules>
       		<s:ArrayCollection>
       			<config:MediaCenterModuleDto 
       			 label="Flex player" version="1.0" 
       			 fileName="assets/MediaCenterPlayer.swf" />
       			<config:MediaCenterModuleDto 
       			label="Flex control bar" version="1.0" 
       			 fileName="assets/MediaCenterControlBar.swf" />
       		</s:ArrayCollection>
       	</config:modules>
       </config:MediaCenterConfigurationDto>
       </fx:Declarations>

    5. With Flash Catalyst and Flash Builder: Update project’s Main.mxml file, adding the functionality to load modules.This can be achieved in several ways, you can see in the Catalyst project my approach.
    6. With Flash Catalyst and Flash Builder: Add the toolbar layer described above
    7. With Flash Catalyst and Flash Builder: Add the logic to show the actual application or hide it, to the buttons within the toolbar: “Show real application” or “Show design”

This is the setup I needed. So , to summarize, these are the points I have achieved at this moment:

• As designer, I can preview the changes into the action application by running only the Flash Catalyst project
• As developer, in order to update the visual design, I only need to compile the Main.css file into a SWF file and load it at runtime. No extra work needed.

If you’re wondering how did I manage to edit the Flash Catalyst files, since they are in read-only mode in Catalyst, I’m going to create a new post really soon and detail there how I managed to open an already opened Flash Catalyst project, into Flash Builder, and edit at the same time Flash Catalyst and Flash Builder.

For now, you can download the Catalyst project I used in this demo and play with it. At the same time, you can view also the PowerPoint presentation.

Problem
When deploying new versions of the application, some users having cache in their browser don’t see the updated version of the swf, thus loosing the updates.

Solution
Automatically append the version number at the end of the url pointing to the swf file, ending with something like : Main.swf?173-1.0-SNAPSHOT. The advantage is that you benefit of the cache in-between new releases; this means that clients can view you flash application faster, and only for new releases they have to wait a little bit more to load.

Having the flex application packaged inside of a WAR file I’ve been looking for places to store this information inside of it, and read the build-number at runtime. I discovered that the MANIFEST.MF file, which is found inside the META-INF folder, is the best candidate.
In order to write the buildNumber into that file, I used maven-war-plugin:

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-war-plugin</artifactId>
	<version>2.1-beta-1</version>
	   <executions>
		   <execution>
		        <phase>package</phase>
		        <goals>
		          	<goal>war</goal>
		        </goals>
		        <configuration>
		           <archive>
	          		<manifest>
	          		   <addDefaultSpecificationEntries>
	   	   	   	      true
	   	   	   	   </addDefaultSpecificationEntries>
	          		   <addDefaultSpecificationEntries>
	   	   	   	      true
	   	   	   	   </addDefaultSpecificationEntries>
	          		</manifest>
		          	<manifestEntries>
		            	   <Implementation-Build>
	   	   	   	      ${BUILD_NUMBER}
	   	   	   	   </Implementation-Build>
		          	</manifestEntries>
		           </archive>  
		        </configuration>
		</execution>
	</executions>
 </plugin>

${BUILD_NUMBER} is only available when executing the maven build from Hudson, as explained in my previous post. Maven also has a plugin that generates a build number automatically, but I didn’t need it because, in my case, no code goes into production without passing the Continuous Integration build and the tests, so I will have a build number for every promoted build.

Next, I had to read the information at runtime. For that I altered a bit the index.jsp file I am using to show the flex application:

<%@ page language="java" pageEncoding="UTF-8" contentType="text/html;charset=utf-8" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>
 
<% 
java.util.jar.Manifest manifest = new java.util.jar.Manifest();
manifest.read(pageContext.getServletContext().
                                   getResourceAsStream("/META-INF/MANIFEST.MF"));
java.util.jar.Attributes attributes = manifest.getMainAttributes();
String fullVersion = attributes.getValue("Implementation-Build") + 
                 "-" + attributes.getValue("Specification-Version");
%>
 
<c:set var="swf" value="bin/MediaCenter"/>
<c:set var="version" value="<%=fullVersion%>" />
 
<%@ include file="/flex.jsp" %>

The flex.jsp file is taken from the FNA project hosted on Google Code. I’ve only altered a bit just to add the version number at the end of the request:

swfobject.embedSWF(
            "${ctx}/${swf}.swf?${version}", 
            "${application}_div", 
            "${width}", "${height}", 
            "${version_major}", xiSwfUrlStr, 
            flashvars, params, attributes);

That’s pretty much it. The result is:

Main.swf?173-1.0-SNAPSHOT

and it’s set automatically, for each build. This ensures that users, testers, everyone else see the right version of the application.

Note that I’m also using the Specification-Version, which is the same with maven version. The reason I’m doing this is because locally, on the dev machine, the ${BUILD_NUMBER} is null, and I simply didn’t want to see Main.swf?null in the url . Specification-Version came for free with the Maven-war-plugin, so I decided to make use of it. The MANIFEST.MF file contains more information; you can have a look into that file, after deploying it.

Problem

Some of my changes were not built correctly and I had a hard time debugging and checking whether the version of the swf I had deployed is the same with the latest version of my swf file.

Solution

I wanted to have an embedded code into the swf and display it into a label, at runtime. Browsing the internet initially, I’ve found some solutions using Python and Ruby.  Having my build in maven, I decided to see what is provided by Flex, FlexMojos and Maven in order to facilitate that.

Analyzing the mxmlc compiler arguments I have found that I can define custom parameters into the compiler and read them from actionscript code. So I have defined a BUILD::buildNumber compiler variable:

-define+=BUILD::buildNumber,"'1.0.0'"

In the Main.mxml application I’ve added:

<fx:Script>
	<![CDATA[
		[Bindable]
		/**
		* specified through the flex compiler arguments like: 
		* -define+=BUILD::buildNumber,"'1.0.0'"
		*/
		private static var buildNumber:String = BUILD::buildNumber;
	]]>
</fx:Script>		
<s:Label 
	right="0" top="0"
	color="red"
	text="{buildNumber}" />

Next, I had to change the compiler parameter for each build, automatically. Using Hudson as my Continuous Integration server, things got very simple. When a Hudson job executes, it sets some environment variables that can be used in build scripts. Among those variables there is BUILD_NUMBER.

<plugin>
       <groupId>org.sonatype.flexmojos</groupId>
       <artifactId>flexmojos-maven-plugin</artifactId>
       <version>${flex-mojos.version}</version>
       <extensions>true</extensions>
       <configuration>
                <definesDeclaration>
		 	<property>
		 	       <name>BUILD::buildNumber</name>
		 	       <value>"${BUILD_NUMBER}-${project.version}"</value>
		 	</property>
          	</definesDeclaration>
       </configuration>
</plugin>

The output of this, for a buildNumber 173 and a project version 1.0-SNAPSHOT is:

173-1.0-SNAPSHOT

The next thing I need to achieve, is to trick the browser’s cache, using this buildNumber, appending it at the end of the request for Main.swf, to end up automatically with a request like:
Main.swf?173-1.0-SNAPSHOT.

My next post covers this.