Flash may be a better choice for your next mobile application development project. Learn why, along with some hard core programming tips.

June 16, 2004
URL:http://drdobbs.com/mobile-flash-development-for-pocketpc/22100181

Bruce Hopkins is the Chief Architect at Hopkins Technology and Research in Oak Park, MI (www.hopkinsTR.com). He has worked in Java for more than seven years, and has researched wireless networking for four years. He's the co-author of Bluetooth for Java (Berkeley, CA: Apress, 2003).

If you're a typical mobile application developer, then you've most likely used traditional programming languages (such as J2ME, C++, or BREW) to create your applications. However, over the past few years, Macromedia has been positioning Flash on mobile devices for applications and games. In the desktop browser market, Flash is succeeding Java and is allowing developers to create interactive Web sites.

What Exactly Is Flash?

If you have never created a Flash application, then you may be confused by all of the terminology flying around Flash developers. First of all, Flash is not a programming language. It's a specification. To create Flash applications (or "movies") in the Flash 7 format, you need a Flash Authoring Environment, which is currently either Flash MX 2004 or Flash Professional MX 2004. When using a Flash Authoring Environment, the native Flash applications are saved as .fla files. Compiling the .fla files produces a .swf file, much like when compiling a .java file that produces a .class file.

Also like Java, Flash needs a run-time on each platform where it must execute because the compiled .swf files are not native machine code to any platform. Of course, that's why your browser needs the Flash plug-in. It's the "Flash Virtual Machine" in Java-speak. On desktop operating systems, .fla files can be compiled into standalone executable files called "projector" files. For most mobile devices (such as the Nokia 9200 series of devices and the Sony CLIÈs), the Flash run-time is built into the operating system of the device. The PocketPC platform is the only Flash-capable mobile platform where you must download the Flash run-time separately.

Note: You can also use a tool called the "Flash Standalone Player for the PocketPC" to create .exe files for the PocketPC 2002 and 2003 operating systems.

Flash has a scripting environment called ActionScript (which is very much like JavaScript) where you can script actions and events based upon a button click or other events. If you want your Flash movie to connect to Java Database Connectivity (JDBC) databases, to SOAP Web services, or to make remote procedure calls, then you must implement Flash Remoting MX on the server-side. The Flash Communication Server is a useful tool if you want two or more users to communicate and collaborate with each other (such as in a chat room or in video conferencing). Macromedia Flex allows you to dynamically generate Flash movies on the server-side from a text file, much like Java Server Pages (JSPs) allow the dynamic generation of Java class files on the server-side from a text file. Finally, Macromedia Central allows you to download and run Flash content outside of the Web browser (just like with Java Web Start).

Table 1 summarizes the nomenclature for those who are new to Flash, and also compares the terms for those who are familiar with Java programming.

Table 1: Flash Versus Java Features and Terminology

Benefits of Flash

What are the benefits of using Flash for mobile applications? In the late 1990s, Flash gained its popularity by being a compact format to deliver browser-independent and interactive applications over a low-bandwidth connection. Browser independence was very important several years ago, because Java applets and ActiveX controls were extremely browser-dependent. Some applications worked in Internet Explorer, but not in Netscape (and vice versa). Java developers even faced issues where some applets worked well in Netscape 4.7, but not in Netscape 4.0 because of Java Virtual Machine (JVM) changes. Several years ago, being able to operate over a low-bandwidth connection was very important because broadband-based Internet access was not as widely available as it is today. Images in Flash are vector-based and not rasterized (or bitmapped) as with Java applets and ActiveX controls. So, what does that mean? Take a look at Figures 1 and 2 for an explanation.

Figure 1: Rasterized image at 100 percent and 800 percent (Full Size)

Figure 2: Vector image at 100 percent and 800 percent (Full Size)

So, that's how the "West was won" in the war of interactive browser-based applications. Java applets and ActiveX controls used rasterized images (which are bitmapped) and, therefore, they don't scale very well. If you want to use larger images, then the file size of the application increases, which also increases the amount of time to download it. In Flash, vector-based images are stored as formulas and are rendered on the client. Therefore, as you see in Figure 2, the quality of the image doesn't degrade, no matter how much you scale the image. This allows Flash movies to display extremely crisp images and smooth animations over low-bandwidth connections.

Of course, these same benefits are evident when you use Flash for mobile application development. Now, whether you use Flash for desktop or mobile applications, it is platform-independent, assuming the Flash run-time has been ported to the platform. Table 2 shows a matrix of mobile device that are Flash-capable.

Table 2: Flash-Capable Mobile Devices

Today, when you use Flash on the PocketPC platform, you get the best of both worlds between thin-client and thick-client applications. By placing your Flash movie on a Web page, your customers can download the latest version of the application instantaneously, and you don't have to worry about how to deploy or update the application (behaving much like a thin client). However, Flash also allows you to persist data on the client-side and operate when a network connection is not present (behaving like a thick-client).

With all this valuable information under our belts, let's create an application!

Getting Started

Of course, to get started, you're going to need a PocketPC device and a Flash Authoring Environment. Remember, you can use either Flash MX 2004 or Flash MX Professional 2004. The only difference between the two is that the Professional version is better suited for Visual Basic and Swing programmers, who are more accustomed to forms and panels rather than timelines and keyframes. For the purposes of this article, I used Flash MX and an iPAQ 4155 to develop and test the examples.

On the other hand, if you don't want to purchase a device with Windows Mobile 2003 (that is, PocketPC 2003), you can use the Flash Standalone Player to make .exe files in PocketPC format and download the free Windows Mobile 2003 emulator from Microsoft. If you choose to go this route, here's a list of files that you'll need to install to run the Windows Mobile 2003 emulator:

• eMbedded Visual C++ 4.0 (use the key TRT7H-KD36T-FRH8D-6QH8P-VFJHQ)
• eMbedded Visual C++ 4.0 SP3
• PocketPC 2003 SDK

Of course, it seems a little silly that you have to install the entire eMbedded Visual C++ SDK to use the emulator, but, hey, I don't work for Microsoft so don't shoot the messenger!

The Temperature Converter Application

To demonstrate some of the capabilities of Flash on the PocketPC, let's look at a simple Temperature Converter application that converts temperature from Fahrenheit to Celsius. The left side of Figure 3 shows ex1.fla within Flash MX, which is a simple 240 x 260 pixel movie with a few text boxes and a button. The right side of Figure 3 shows the compiled version of the movie, ex1.swf.

Figure 3: The Temperature Converter without a title or a version number. (Full Size)

Note: To preview your movie, just press Ctrl+Enter.

Currently, the movie doesn't have a title or a version number, because ideally, those items should be kept in a property file.

Working with Property Files in Flash

In Flash, to read data from a property file, you must write a little ActionScript code. Don't worry, Macromedia makes this task extremely simple. In my applications, the dynamic text boxes for title and version number of the application are appropriately named, "title" and "version." Of course, they could be named almost anything, but I chose those names to keep things simple. Below are the contents of the ex1.txt property file used for the Temperature Converter application.

title=Temperature Converter&version=1.0

As you might have expected, the file contains two name-value pairs separated by an ampersand. So, why would Macromedia make entries in a Flash property files separated by ampersands? Keep in mind, Flash was created as an interactive application for the Web, so it should be no surprise that the contents of Flash property file look like a URL string. Following is the ActionScript code that's needed to read and parse ex1.txt.

loadVariablesNum("ex1.txt", 0);

And that's it. You can't get any simpler than that. You also have the option to load data from a URL of a plain text file, as shown here:

loadVariablesNum("http://www.cmp.com/ex1.txt", 0);

Figure 4 shows the movie with the title and version number loaded from the properties file.

Figure 4: The Temperature Converter with the properties file loaded (Full Size)

Oops! It looks like the font size for the title of our application is a little too big for the 240-pixel width of the PocketPC. Fortunately, you have a couple of ways to easily rectify this problem. The first (and obvious) option is to reduce the font size. However, if you're trying to display a horizontally large image, or if you want some more screen real estate to add more form fields, you need the application to work in landscape mode. Displaying your application in landscape mode on the PocketPC platform is no easy task, but thankfully, Macromedia has greatly simplified the effort for developers by creating a template (in the Pocket PC Content Developer Kit) that already does the work for us. Macromedia has also published Content Developer Kits for the other mobile Flash platforms listed in Table 2.

Figure 5 shows the landscape template of what things look like when your Flash movie is tilted 90 degrees. As you'll see in the remainder of this article, I'll reduce the size of the title's font.

Figure 5: The Flash PocketPC landscape template (Full Size)

Performing the Calculation Locally

Since Flash is capable of performing mathematic computations, let's look at the ActionScript code that's needed to perform the calculation within the movie itself:

function tempConverter(){
     cvalue = (5/9)*(Number(fvalue) - 32);
}

As you can see, Number() takes a text value and converts it to a numerical value. The text boxes (cvalue and fvalue) by default store the entered data as a String (just like a JtextField in Java), and must be converted to a number before any computation takes place. Figure 6 shows version 1.1 of the Temperature Converter in action.

Figure 6: Version 1.1 of the Temperature Converter application (Full Size)

Now, how does the button on the movie know that it's supposed to call the tempConverter() function when it's pressed? Just define tempConverter() as the Click Handler for the button, as shown in Figure 7.

Figure 7: Assigning the tempConverter() function to the button click handler (Full Size)

Sending Form Data to a JSP

Now since the formula for converting Fahrenheit to Celsius is a matter of simple arithmetic, we were able to perform the conversion within the application. However, let's look at the code that we would use to let a server perform the calculation for us.

In version 1.2 of the Temperature Converter, we're going to instruct the Flash movie to send the Fahrenheit value to a remote JSP server, perform the calculation on the server-side, and return the value back to the Flash movie (for this example, I used the Jakarta Tomcat 5.0.19 as the JSP engine). Following is the ActionScript code that sends the Fahrenheit value to the Tomcat server, and gets the Celsius value back:

function tempConverter(){
     loadVariablesNum("http://localhost:8080/convert.jsp?ftemp=" + fvalue, 0);
}

Listing 1 shows the JSP code that accepts the Fahrenheit value to perform the conversion.

<%
String ftemp = request.getParameter("ftemp");
int f_int = Integer.parseInt(ftemp);
double cvalue = (f_int - 32) * 5 / 9;
out.println("cvalue="+ cvalue);
%>

Listing 1: convert.jsp

So, if you enter "212" as the Fahrenheit value, then the URL String that would be sent to convert.jsp would look like this:

http://10.0.1.15:8080/convert.jsp?ftemp=212

After this is executed, the JSP will return a plain text file like this:

cvalue=100.0 

Since our Flash movie has defined cvalue as a variable, all the JSP had to do was to return a name-value pair for cvalue without any HTML formatting. Of course, if we wanted the JSP to return more than one value back to the movie, then the values must be separated by ampersands. Figure 8 shows the final version of the Temperature Converter application.

Figure 8: Temperature converter running on an iPAQ 4155

Conclusion

So, what can we take away from all this? As you can recall from Table 2, Flash carries over several good features from Java, including platform independence. On the PocketPC platform, Flash applications have a distinct advantage over Java 2 Micro Edition (J2ME) Connected Device Configuration (CDC) applications because Flash can be executed locally or provisioned over a network connection. We've also learned that Flash movies have the capability to load external data, either from a property file or via a URL. One of the most powerful features that we've seen is the capability of Flash to send and receive data from a JSP.

Now that you know that Flash has several mobile and enterprise features built-in, who knows, maybe it will be the platform of choice for your next project!

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.