In the last article about Flash on the Pocket PC platform I covered the basics of creating flash interfaces that will work and look good on the “small screen”, covering the aspects of the platform that need to be considered when developing an interface or application. With this article I’ll be talking about the tools used to create more advanced applications. These things aren’t necessarily Pocket PC-specific, but they do work a little differently in some cases.

Shared objects
Shared objects are used in many Flash applications. Flash isn’t allowed much interaction with the client’s computer; there’s no built-in method for creating text files, though existing ones can be read. The primary option for storing user data is to store it remotely but if the client isn’t connected to the Internet that option isn’t always available. If that’s the case, then store the data in the only local vehicle available for client storage data: shared objects.

Shared objects are small files that Flash stores on the client computer. The shared object is specific to the application that created it. They’re also not easy to find, usually residing within a hidden subfolder on the client computer.

In terms of a Pocket PC device, the shared object exists only until the next soft reset. Therefore, you can’t rely on it always being there. In fact, the application you’ll be looking at only uses a shared object to store data temporarily while a network connection is not available.

Creating the shared object is pretty straightforward:
1 var MyBlog = SharedObject.getLocal(“blogobject”);
2 = new Array();

Line 1 only executes if the shared object doesn’t exist. Line 2 assigns the shared object a value. You can put anything you want in your shared object; I use an array since I want to put several pieces of data in the same container. I’ll address actually putting data into the shared object array later.

Flash remoting
Flash remoting is one of the main methods used for connecting Flash applications to Web backends. It allows Flash applications to send and receive data to Web services regardless of the server side technology (.NET, ColdFusion, J2EE, etc.). Flash remoting replaces the use of sending XML files back and forth and having to parse them manually. Once Flash remoting support is installed on your application server, you are all set.

For this application, I will connect to a ColdFusion Web service designed to accept a blog (Weblog) entry from a flash application on a pocket PC device. Since this application is merely a learning project, there isn’t a great deal of security or robustness within the Web service or the app.

The next example shows the basic code needed to connect to an outside resource with Flash remoting. First, you establish your gateway, and then connect to it. Once connected to your gateway, that connection is available to the entire swf file for as long as that file is open. Once you’ve established the connection, you access your Web service (in my case http://website/blog/uploader.cfc is the ColdFusion component that makes up my Web service). You’ll notice I don’t use the ( / ) when providing the path to the blog/uploader Web service. Web service calls use dot notation where each ( / ) is replaced with a ( . ).

Lastly, you pass your data to the Web service just like any local function in your application.
gatewayConnection = NetServices.createGatewayConnection();
Myservice = gatewayConnection.getService(“blog.uploader” , this);
Myservice.UpdateBlog({subject:blogTitle, CatSelect:blogCategory, newentry:blogBody, entrydate:blogDate, passcode:”XXXX”});

ColdFusion components are a different article but the gist of this Web service is a database query that inserts the passed variables to the database and returns a status message.

Flash form elements
Flash form elements are specially built components for Flash to use in Pocket PC applications to help keep file sizes to a minimum. Using these elements, you have access to all of the standard form elements: drop-down lists, text boxes, radio and check boxes, etc. The Flash Device UI components are part of the Flash for Pocket PC Developer Kit available for free from Macromedia.

There’s a variety of UI components available in the kit, though you’re in no way limited to just these components. You can use any of the Flash form element components that come with Flash MX, but they can adversely affect the file size of your Flash application and its usability on the Pocket PC platform.

The real work starts now
The bulk of the work in this application takes place in the SubmitBlog() function (Listing A). SubmitBlog() takes the form data from the front end and either submits it via Web service to the blog site or, if the device isn’t connected, stores it for later upload. Because the shared object contains an array, you can store multiple entries, holding each one until a network connection is established.

The function starts by creating two arrays; they’ll be the working data stores. I create a date/time variable that will help the offline posts show the date they were recorded. (This is not implemented yet; work in progress, ‘ya know). Next, I check to see if the Pocket PC device is connected to a network. This is done elsewhere, setting the ConnectStatus variable earlier in the application.

That Flash remoting connection I established earlier is used here. I could establish the connection within the SubmitBlog() function; as far as I know, there’s no performance impact either way. The actual submitting to the server is pretty unremarkable, a single call to UpdateBlog. The last step of the update is to display a status message to the user so that he knows the update was successful. One thing to note, this message is displayed no matter what the status of the update. Flash remoting provides functionality to return results from the Web service, but this application doesn’t utilize that functionality yet.

Now, let’s assume that the Pocket PC device is not connected to any network, you’re in the car or on a plane, or in the supermarket—the SubmitBlog() function moves over to storage mode. You start by taking the data stored in the shared object and putting it into one of the local temp arrays. This preserves any entries that might be in the shared object already. Then you populate the other temp array with the form data for the new entry. Finally, you push the new entry array to the array containing the existing shared object data, then put it all back in to the Shared object.

One last bit of code
The last bit of code for the application is the auto upload feature. When the application loads, it checks to see if it is connected to a network and that there are blog entries to upload. If so, it resubmits them to the SubmitBlog() function.
var ArLen =
if (ConnectStatus == “Online” && ArLen >= 1)
       for (var i = 0; i < ArLen; i++)
              Data2Submit =;
              //trace(i + ”  ” + Data2Submit + “— Length: ” + Data2Submit.length);
              SubmitBlog(Data2Submit[0], Data2Submit[1], Data2Submit[2], Data2Submit[3]);
              //trace(“blogTitle: ” + Data2Submit[0]);
              //trace(“blogCategory: ” + Data2Submit[1]);
              //trace(“blogBody: ” + Data2Submit[2]);
              //trace(“blogDate: ” + Data2Submit[3]);
              ResultStatus = “Stored Entries have been uploaded.”;

Whenever the blog entry application is loaded, the code above pops each entry out of the shared object and submits it for upload. It loops as many times as there are entries to be uploaded.

This application is pretty simple—not very robust or secure, but that’s okay. It’s just a beginner application, to get you started on the road to Pocket PC Flash applications. A more advanced example of the application would include using the result() function provided by Flash remoting to handle errors and confirm completions of the process. And security would be more than a four-character passcode sent along with the data. But it’s a starting point for building your own Pocket PC Flash applications.