If you're an old-timer like some of the authors of this book, you may recall when 64k of RAM was more than you'd ever need and a floppy disk was truly, floppy. Well, now we've gone back in time a bit, not that far to TRS-80s but to a few years ago where Pentium 100s and 64MB of RAM was the norm.

All the devices that support the Pocket PC 2002 operating system have at least 32MB of RAM and sometimes up to 64MB. That's a pretty fair amount of storage. Most users have 5 6MB free at any given time for applications. Also, you may hear the term "flashable ROM," it has nothing to do with Flash, but it's still very cool. Basically, flashable ROM allows all the new Pocket PCs to be upgraded to the next version of the operating system. The Compaq iPAQ was the first to support this and it could be the reason they sold over one million in just under a year!

To see how much memory your Pocket PC has, go to the Start menu on the Pocket PC, Settings, the System tab, and then click the Memory icon (see Figure 2.26). As you create applications, it's important to check this setting often to see how much memory and storage you have on your device. Also check the running programs and quit specific programs when needed.

Figure 2.26. Storage on the Pocket PC.


Back to physical storage. Flash files are tiny, so tiny that only a few megabytes could contain an entire learning course or dozens of games. For wireless networks, the smaller the size the better; the average connection speed for a wireless device in the year 2001 was less than 9.6kbps. In 2002 there will most likely be faster networks, but not in all areas.

Similar to traditional device application development, one of the many advantages of using Flash for application creation for Pocket PC is that larger applications, which are designed to be stored locally, can have larger file sizes and contain richer content than web-based Flash content. This is because the file is loaded from the file system and not transmitted every time the user interacts with the application.

Also, Pocket PCs usually have many forms of storage built in or additional storage available as an add-on accessory. Formats include: Compact Flash (CF), Multimedia Cards (MMC), and Secure Digital (SD).

Managing Memory

As you create applications for the Pocket PC, you can never test them too often. This is especially important because memory can be scarce and is most likely going to be the main deal breaker in many of your applications. Creating content for any device is a careful balance of sacrifices. Flash allows you to sometimes have your cake, and eat it too. You can use the built in features of Flash and its scripting language to load and purge memory as the user interacts with your applications.

When planning your applications always try to break the components of the application into smaller movies. It's very common to deploy a Flash application for Pocket PC that consists of one HTML page and 7 8 movie files (SWF). For example, if you're creating a learning course, each main section can be a Flash movie (SWF) and all the text can be an external data source like a text file. This enables you to not only update your content on a more frequent basis and use other languages, but by loading content in and out of a main Flash movie you can restore the system memory as you use the application and also after you leave the application.

If you are familiar with multiple timelines and the loadMovie command, you shouldn't have too much difficulty doing the same for your Pocket PC applications. If you're not familiar with the concept, here's a quick overview. Also, don't forget to lean on the thousands of books and resources online for the complete load movie experience.

The first Flash movie you put into the HTML page on the Pocket PC is referred to as a "base movie." This movie is level 0. The base movie controls the frame rate for all the loaded in movies.

When loading a Flash movie into a level, the SWF files that are being loaded in should be the same dimensions as the base movie; otherwise you may experience unpredictable results.

You can load movie files (SWF) into levels, usually 1 and above, as well as targets (other movie clips inside existing levels inside your Flash application).

When loading a movie into the same level where another movie exists, the newer movie purges the existing movie before the new one can be displayed. If you need to view the movie that was purged, you will need to load that movie in again. After playing a large movie, it's often a good technique to load in a blank or empty movie to free up the memory on the device.

Loaded movies can communicate to each other by referencing the timelines using relative ( ) or absolute ( ) paths, as well as sending variables to and from movies or globally. Root level is also relative, it only references the root of the level; if you need to reference an absolute path, use level 0, level 1, and so on.

When loading a movie into a target, you're loading a movie into a predetermined location on the stage.

In the sample applications included on the site we use the loadMovie command to load in content to and from our Flash application for Pocket PC.


Let's look at the various ways to load data into Flash applications for Pocket PC. Flash has two main ways to load data:

  • loadVariables

  • XML

Using loadVariables

loadVariables is the most common way to load in data. It follows a simple name/value pair system. For example, if you had a dynamic text field in your Flash application on the Pocket PC named "message" and loaded in a data source text file called "data.txt" with the following text

 &message=your  ad  here 

the text would display "your ad here" inside Flash. Let's take a look at the ActionScript. In some cases, you may need to url encode your data, for example, %20 are url encoded spaces. See the note in this section for specific information about url encoding.

 loadVariablesNum ("data.txt", 0); 

This loads in the data file located in the same directory as the Flash movie into level 0. You could load the data in from another location (see the "Security" section later in this chapter for specific information) from an ASP, JSP, CFM, PHP, or CGI script, as well as loading the data into another level if needed. In Chapter 10, "Server-Side Dynamic Content for Flash-Enabled Devices," we really dig in to how to use dynamic data sources for you Pocket PC applications; be sure to check it out.

Be sure to separate your name value pairs with &'s and make the values by using the = sign before the value. For example, var1=value1&var2=val2 .


If you're going to send characters and symbols (like &s and =s), in some cases you'll need to url encode the data as well as using escape characters.

You can also use the built-in escape and unescape functions inside Flash. The escape () function converts ASCII text and encodes it in a URL-encoded format, where all alphanumeric characters are escaped with % hexadecimal sequences. Conversely, the unescape converts a URL-encoded string to ASCII characters.

If you're looking for a great URL encoding chart, visit:

Also, for a Flash-based encoder and decoder visit:

In many of the sample applications on the site we use loaded data for our applications. Of course, if you are loading data from an external server, then the Pocket PC device must be connected to a network for the Flash movie to work.


See Chapter 10 for some techniques on how to dynamically embed your dynamic data into a Flash movie before it is downloaded or synced to your device.

Using XML to Load Data

Another way to get data into Flash applications in the Pocket PC is Extensible Markup Language (XML). It is called extensible because it is not a predefined language like HTML. Instead, XML is actually a "meta-language," a language for describing other languages, which lets you design your own customized markup languages. With XML you can create your own language definitions or use other XML standards based schemas. The Flash Player for Pocket PC can read XML data the same as the desktop player.

This is exciting for mobile application developers because many of the data sources that are used for applications are XML based, but with Flash for the Pocket PC you have far more design control when presenting the data. The Flash Player for the Pocket PC does not use Document Type Definition (DTDs) files, which are used by other XML-reading applications. Flash allows you to read XML-structure data into a Flash XML object, which has predefined methods and properties associated with it.

Loading XML data into the Flash Player for Pocket PC is a fairly straightforward process.

  1. Start a new Flash movie: 240x240, white background, 12 frames per second. Create a text box on the stage; choose the _sans font (that will force the Pocket PC to use built-in fonts). Under Text Options (Window, Properties) make the text Dynamic text, and check off HTML, Word Wrap, and Selectable. Also select Multiline and name the variable _root.HTML. Try to make the text about the same size as the example by resizing it.

  2. Create a new layer called actions and in frame actions of that frame add the following ActionScript:

     function Process (success) {  if (success) {       _root.Parser.Parse(this);  }  else {       _root.HTML = "XML Load Error<br> XML File Doesn't Exist!";       }  }  WebXML = new XML();  WebXML.onLoad = Process;  WebXML.load("data.xml"); 

    This ActionScript defines the function executed when the data has loaded, and reports an error if there is not an XML document to load. It also tells Flash which function will be used when the data has loaded and lastly it loads the data.

  3. Now we need to create a new XML Object. Insert a New Movie Clip (Insert, New Symbol) and call it parser.

  4. From the Library (Window, Library) drag that Movie Clip to the stage, select that clip by clicking on it, open the Actions Panel (Window, Actions), and place the following ActionScript in the Object Actions (see Figure 2.27):

    Figure 2.27. Putting it all together.


     onClipEvent (load) {     function Parse (xml) {     DocumentName = new XML();        DocumentName = xml.firstChild;     if (DocumentName.nodeName.toLowerCase() == "data") {     ChildName = new XML();     ChildName = DocumentName.firstChild;     _root.HTML = ChildName.nextSibling.firstChild.nodeValue;     }  }  } 

    This creates the new XML Object that contains the data and sets test box equal to loaded XML data.

  5. What's missing? The XML data. Using Notepad or your favorite text editor create the following XML document:

     <?xml version="1.0"?><data>   <info><![CDATA[<p>this is dynamic text, with <b>bold</b>, <u>underline</u>, <i>italic</ graphics/ccc.gifi>, a <font face="Arial">different font</font>, <font size="20">size</ font> and <font  graphics/ccc.gifcolor="#0000FF">color</font> with a link to <a href="http://www.flashenabled  graphics/"><u><font color="#0000FF"></font></u> </a>.</p>]]>   </info>  </data> 
  6. Now test you, movie (Control, Test Movie). You should have the same results as the previous example with all the HTML formatting preserved, but loaded in via an XML data source.


    Parsing XML within Flash can be CPU intensive. This is especially true if you are parsing large or complex XML documents. If you must parse large documents, you may need to parse them in chunks across frames to avoid errors and delays. Also, when parsing large documents, remember to give your user some feedback on what is happening. See the section " Data Loading and Processing Considerations " that follows for more information and optimization techniques.

If you're looking for some great (and free) XML newsfeeds, be sure to visit Moreover at

There are hundreds of data sources in Flash variable format as well as XML formatted.

Data Loading and Processing Considerations

Using loadVariables and parsing data with the ActionScript XML object can be just as processor intensive as using MP3 files, large images, and complex scripting. Processing large amounts of data can cause slow and sluggish performance on the Pocket PC. Just as you break movies into smaller Flash movies (SWFs) to load in, you should try to process small bits of data when possible as opposed to loading in all the data all at once. However, if loading the data from the network, proper testing will help find the balance against the added time required to load the data from an external source versus loading in the data in one query.

Also, the Flash community has written a number of optimized ActionScript objects that improve the performance of the built-in ActionScript objects:

  • An ActionScript library that rewrites some of the built-in string functions, resulting in performance increases. In particular, the String.split() method has a significant performance increase. You can download the library from:

  • XML Nitro. An ActionScript library that rewrites the parsing of the ActionScript XML object, and in the process provides significant performance increases. You can download XML Nitro from:

  • FLEM. An effort to add "event engines" to Flash that allows developers to have more application-like features in their projects:

    Although not specific to data processing optimizations, this can greatly ease your ActionScript development workflow.

Data Loading Bandwidth Conservation

Because most Internet connections on the Pocket PC will be wireless and usually less than 9.6k per second, it's important to keep the amount of data you're transferring as small as possible. Only send data that is necessary for your movie. If you have to send large amounts of data, consider loading it in smaller pieces. Not only will this be faster, but also the Flash application on the Pocket PC will appear to be more responsive. Also consider using short variable names and XML tags. For example:

 <TitlePageHeader>Your Ad Here</TitlePageHeader> 

Should be changed to:

 <tp>Your Ad Here</tp> 

This can significantly reduce the amount of data that has to be transferred and in some cases make the difference between a good and poor user experience.

Connected and Unconnected Applications

In most cases, the content will be transferred to a device by either "syncing" with a desktop machine or transferring the files over some type of connection. With a connected application (one where the device has a docking cradle for periodic updates) the developer can take advantage of the device having a speedier connection.

With Pocket PC 2002, users can access the web through "Desktop-Pass through." This allows users to surf the web while the device is connected to the cradle or connected to the PC/Mac via IR. While most end users won't use this feature that often, it's an excellent tool for developers to test content online. There is a great opportunity to create "cradle games" where the user is instructed to play the game or content while the device is connected in the cradle. Or a sketch or note pad that can save mobile notes to a server, such as the draw pad example found in the samples on (see Figure 2.28).

Figure 2.28. Pocket Sketch for the Pocket PC uses a server and client side component (Flash on the Pocket PC).


A developer could also make a time-based clock or stock watch that could sit in the cradle and provide information to the user on a regular basis, thus making the Pocket PC into an information display device.


For more information on Desktop Pass-Through visit:

For the unconnected application (wireless transferring or live querying), the content needs to be as small as possible with only the smallest amounts of information transferred to function. Loading in text files that drive Flash content via Load Variables is a good example of when Flash files cannot be transferred at all. Rather, only the small text files needed for data can be transferred as described in the previous section.

Online Detection

When deploying an application that requires a wireless or LAN connection for the Pocket PC, a developer can "ping" the web server by loading in a text file via an http request. This request contains a value that will trigger the application to allow interaction for online use. Include a timer script that will give the user a message or display content when the application is not connected.

On the web site, we created a file that any developer creating Flash content for the Pocket PC can use to test their online connection. You should only use this file for testing, though. If you move your movie to production, you should place a copy of the file on your own server. Here are the steps:

  1. To "ping" the server, create a new Flash movie, 240x240, 12 frames per second, white background (see Figure 2.29).

    Figure 2.29. Let's ping the server to see if we're online.


  2. Create two layers, one called actions, the other vars. In the vars layer, add a variable text field and call the text field status (Window, Properties).

  3. In the first frame of the actions layer, add the following frame action (Window, Actions):

     loadVariablesNum ("", 0); 
  4. When you test the movie (Control, Test Movie) the Flash file will load the text file and the status variable will be changed to "loaded;" based on that you can write other scripts. If the variable never loads, then you can make decisions and load in other content or instructions so the user knows he needs to be online to use the application. This example assumes the Flash file and HTML are on the local device and the device is connected online (see Figure 2.30).

    Figure 2.30. Successful ping from


Be sure to read the following section about the security model that you must follow to load in your data.


As a special treat we've also included an advanced example on the site, which allows developers to detect the Internet connection speed of the device when it is connected to your server!


The Flash Player for Pocket PC follows the existing security model of the Flash Player. For security reasons, a Flash movie playing in a web browser and loaded from a URL cannot access data residing outside the web domain from which the SWF originated. This applies to any ActionScript command or object that can send or receive data, including loadVariables, the XMLSocket Object's methods, and the XML Object's send and sendAndLoad commands.

For example, if you're accessing a Flash application from Pocket Internet Explorer at, the application can access any data (TXT, HTML, XML) and files at the domain such as sub-directories (, as well as sub-domains (

The application on cannot load data from an outside domain like The query will not return any results nor will it provide an error message.

These security features do not affect Flash applications loaded locally from the device, only those playing during browsing via http requests.

A common technique is to store the Flash application on the Pocket PC and use the wireless connection to load data into the application. This has two benefits:

  • The "heavy parts" of the application, such as graphics, sounds, and main files, reside on the device.

  • Only small amounts of data are transferred over the Internet, in fact the data is smaller than HTML files because the data is specifically formatted for the Flash application on the Pocket PC.

There are two other options if keeping the application on Pocket PC is not permissible for the project:

  • Create a "Proxy script." A Proxy script allows the Flash application on the Pocket PC to request the data from a script on the server such a CGI, ASP, CFM, JSP, and PHP middleware on the server, and that script will request and return the data. This can be a fairly slow process and tax the server if not deployed and tested thoroughly.

  • The next method is called Domain Name System (DNS) aliasing. With domain name aliasing, the Pocket PC Flash application requests its data from a sub-domain like and the server sends that request to an outside server. This usually is a messy process and generally not supported by most system administrators.


For more information on Flash security, consult the documentation or visit:

Version Detection

It's important to know which version of the Pocket PC Flash Player is on the user's device for deploying specific content. Also Macromedia occasionally creates updates to the Flash Player and it may be part of your application to use the new or updated features. Flash for the Pocket PC has built-in detection so a developer can detect the current version and push content or instructions based on the return.

  1. To detect the version of the Flash Player for Pocket PC, create a new movie, 240x240, white background, 12 frames per second.

  2. Create a text box on the stage and choose the _sans font (that will force the Pocket PC to use built-in fonts). Under Text Options (Window, Properties) make the text Dynamic text, and check off Word Wrap and Selectable (see Figure 2.31). Select Multiline and name the variable detect. Also, add an additional text block with the same parameters, but name this one playerVersion in the variable field. Try to make the text fields about the same size as the example by resizing it.

    Figure 2.31. Text field with playerVersion variable.


  3. Add the following ActionScript to the first frame in the movie (you should be in expert mode for this ActionScript):

     playerVersion = getVersion(); 
  4. Test the movie (Control, Test Movie). On the desktop, it will return the desktop version of the player you're currently using; and on the Pocket PC, it will also display the current version on the device (see Figure 2.32).

    Figure 2.32. Flash version detection on the Pocket PC.


When using this ActionScript to detect version information, it is returned as a string in the following format:

(Windows Player) WIN 5,0,42,0

(Macintosh Player) MAC 5,0,41,0

(Linux Player) UNIX 5,0,45,0

(Pocket PC Player) WINCE 5,0,86,1

The string consists of an abbreviation for the platform, followed by numbers indicating Flash Player version number (major version, zero, minor version, zero).

Note that the Pocket PC version begins with "WINCE". Using the code that follows, you can detect whether your Flash movie is being played on a Pocket PC device.

 /*  * This is a simple function added to the built in String object that checks  * whether a String begins with the string passed into the function.  */  String.prototype.beginsWith = function(s)  {  return(s == this.substring(0, s.length));  }  var playerVersion = getVersion();  if(playerVersion.beginsWith("WINCE"))  {  //Pocket PC 2002 <u><b>Detected;  detect = "Pocket PC 2002 Flash player detected";  }  else  {  //Pocket PC 2002 NOT detected;  detect = "Pocket PC 2002 Flash player not detected or version info has changed";  } 

For more information, consult or visit:

It is possible to determine whether the user has the Flash Player 5 for Pocket PC without using JavaScript (as you would normally use JavaScript for detection on the desktop, JavaScript detection is not supported with the Flash Player 5 for Pocket PC).


It's often a good idea to place this type of action in the first 4 to 5 frames in case there are any playback issues on the download to the device.

In your Flash application (which resides on the server), place a getURL action in the first frame that goes to your Flash application on the server.

In the index page of the application on the server, place a meta tag with a 2 to 3 second refresh tag that points to a non-Flash page with instructions on downloading the Flash Player for Pocket PC, for example:

 <META HTTP-EQUIV="Refresh" content="2;URL="> 

For more information, consult the Flash documentation or visit:

Macromedia Flash Enabled. Flash Design and Development for Devices
Macromedia Flash Enabled. Flash Design and Development for Devices
ISBN: 735711771
Year: 2002
Pages: 178 © 2008-2017.
If you may any questions please contact us: