Mobile Development with Flash Lite

Mobile applications still seem to be just about to happen. Every year there are some great advances in the underlying network, data transfer is faster, devices are smarter, more consumers buy them, and even the providers seem to come up with reasonable data rates. Customer interest seems to be the last (and biggest) battle ground, and this year it’s the iPhone that makes me hope again that people realize the power of the little devices they’re already carrying with them.

Flash Lite - Why?

There are four key options to develop for mobile phones at the moment:

• Using platform-specific “native” development tools, like the C++ devkit on Symbian devices, or the Compact .NET framework on Windows Mobile devices
• Using the Java language and the J2ME platform to build more or less device-independent applications
• Building Flash Lite movies and ActionScript code using the Flash Lite runtime
• It’s also possible to build fully web-based applications, providing XHTML mobile-specific pages on the site

Platform-specific tools tend to provide the best possible user experience, and they look and feel closest to the mobile device, using the same UI components as the built-in applications. Unfortunately I just don’t have the patience anymore to write C++ code, and at this point I don’t have (and don’t want) a Windows Mobile OS based phone, so these options are not available for me.

Web based solutions work well in some situations, but locally installed applications have the advantage of a richer UI, tend to be faster to launch than the browser, and have no associated data transfer costs.

I’ve already learned the J2ME platform, and built a couple of small applications with it, and I like the platform, but I wanted to see if using Flash Lite I could develop faster. I was also curious about how I can deploy these Flash applications on my phone, and what are the challenges in terms of invoking remote web services.

Getting Tooled Up

To get started, we need a number of things:

• The Flash authoring environment, a trial version can be downloaded from Adobe
• The Flash Lite-specific SDK, with some documentation, examples, and reusable components, also from Adobe
• We also ideally need a phone to test the application. This is not so straight forward, as there are a number of devices which have the Flash Lite player built in, but you might need to buy the player for other devices. This list should help you to see if your phone supports Flash Lite

The device profiles for the IDE are updated regularly, you can reach the download page from the Device Profiles dialog, or by visiting Adobe’s Flash downloads site.

I’ve also acquired a nice book on Flash Lite development, called “Flash Applications For Mobile Devices”. I think it’s essential for most of us, but I suppose long-time Flash experts might be able to get by just through the Adobe/Macromedia tutorials.

The Flash 8 Professional authoring tool is quite expensive for hobby development at around 700$. So make sure you get the most out of it during the 30 days trial. Perhaps if you enjoy Flash development, try to get a small professional project on the platform, that should cover the costs, and will make you feel like you’ve earned the right to buy this new toy. There are some free Flash development tools, but they’re not focused on mobile development, and they’re far from the Macromedia/Adobe IDE capabilities.

So How Does It Work?

The web based Flash toolset and runtime grew into a nice platform for application development, with a mature object-oriented scripting language, and some broad choices on the development approach. Flash Lite on the other hand is still firmly rooted in animated movie-land, with some scripting extensions. The most widely deployed runtime, Flash Lite 1.1 is based on Flash 4, and it’s really focused on adding scripted behavior to animation frames.

The book I recommended has a number of approaches and tricks to coerce this environment into an application platform, but developers will need to get their minds around Flash movies, layers, and timelines to do anything useful.

The central backbone of a Flash Lite application is a timeline. It’s basically a sequence of frames (keyframes and transitional frames between them). Each timeline will have a number of layers, hosting different objects for the application. By objects I mean images, text, buttons - the language itself has no object-oriented features. The Flash developer has the freedom to place these objects on keyframes, and define transitions, movement, and scripts triggered by events. These events can be things like the frame being rendered, or button press handlers.

When running the application, the Flash Player will play through the sequence of frames, executing any animation, transformation, or ActionScript routine defined in the Flash program. It’s worth mentioning that unless we explicitly stop it, the animation will loop by default. The loop can be stopped by putting a stop(); ActionScript command on the last keyframe of the timeline.

Laying Out Components

The user interface is laid out on a canvas, for which you can set a default size based on the phone platform targeted. This does not mean that the form will have that specific fixed size - the canvas and the components will be resized based on the mobile device’s screen size. This is one of the reasons why Flash leads you towards using vector-based graphics as much as possible, instead of bitmaps. When you insert a bitmap image in your workspace, the IDE will allow you to transform it into a set of vector objects. You will need to group the resulted set of objects into a single object, if you want to then move it around.

Each animation can have multiple layers, just like the separate editing layers in Photoshop. If you animate several objects, you can place each object on its own layer, and define the transformations on a per layer basis. It’s useful to separate out the initialization logic and the non-object-related ActionScripts into a separate layer.

Whenever you want to perform an animation, you can place the object onto a keyframe, add another keyframe and place the object into its final position, then select the animation effect (transformation, movement, tilting, resizing, etc.). The runtime itself will render the actual frames between the keyframes automatically.

User interaction can be captured in a number of ways:

• By capturing keypresses: there’s a mechanism to place a “keycatcher” object on the screen, in an out-of-frame location, which will receive the keypresses on the mobile handset’s keypad. You can define the event handling code in the Action window for the catcher object, using the on(keyPress "1") {} notation.
• By capturing “soft key” events on the mobile device: typically there’s a customizable soft key (left and right) on each mobile phone. The PageUp and PageDown events are mapped to the soft keys. The labels for the soft keys need to be defined using the fscommand2("SetSoftKeys") command. This command should be also placed on the initial frame.
• Screen objects themselves can act on user events, when the user navigates to a button, and presses the center button on the handset “joystick”. To enable a component on the screen to act as a pushable button, select the image on the form, and convert it to a Symbol, specifically a Button type symbol. Then the on(press) {} event handler code can contain the scripted events you want to execute when the button is pressed.

Adding Logic

Once the components are placed on the screen, and the buttons and their events handlers are specified, typically the execution logic is about reacting to the change. This change can be executing an external service with the parameters that the user specified on the screen, or processing some of the input provided by the user, or in case we’re building a game, it can be about moving components into the direction the user specified. All these things tend to be implemented by navigating to different keyframes on the timeline, and performing the scripts with the user’s parameters on these new keyframes.

When there’s significant processing logic, it’d be convenient to define custom functions, or object libraries to separate out the “business logic” code from the UI. This is not supported in Flash Lite 1.1, but using various hacks, it’s quite possible to simulate the mechanism. The Flash Lite book I mentioned above describes a nice trick. This relies on a capability that we can place sub-movies on the frame, and this sub-movie can have its own scripts and keyframes. While Flash Lite can’t invoke a custom function, it can set parameters that can be visible to the sub-movie, and it can “call” a keyframe, using the `call(“movie_name:keyframe_name”) notation. To make this work, we need to place a component on the screen (again, to an out-of-frame location), transform it into a Symbol (movie), we can then click on the object, and start to define its own frames. Each frame can represent a “function” on our simulated component.

One thing to note is that while the target device might have the catcher and business logic objects out of the screen, while executed on a different screen sized device, those components might show up in-frame.

A serious limitation in Flash Lite 1.1 is the inability to locally store data on the handset. There’s no API to save or retrieve the user’s settings for example. There’s a workaround on some platforms (at least on Symbian), where the Flash Lite runtime can call out to an external executable, passing parameters. This can facilitate local storage, but this limits the platform to certain Symbian devices. As a work-around, if the Flash Lite application will call services on the web anyway, we can store preferences on the server side, and retrieve it when the application is launched and the user provides a username/password combination. This limitation is thankfully gone in Flash Lite 2, so when the runtime coverage will expand, we can start to rely on local data storage on Flash Lite 2 devices.

Invoking Services

One of the best use cases for Flash Lite on mobiles is using it for a more dynamic, rich interaction with a web based service. Just relying on an XHTML browser based interaction can still feel complicated and sluggish, especially when interacting with a service frequently on the mobile. We need to open the browser, navigate to the bookmark, wait until the page loads, log in, wait for another page to load, and so on. Using a device-specific, dynamic client, which loads from the mobile locally can really enhance the user experience.

The reason I refer to a “web based service” is that in Flash Lite 1.1, there’s no SOAP based Web Service client. We can however invoke web servers using the HTTP protocol, pass query parameters, and retrieve the results as a set of ActionScript variables. The loadVariables() method takes an URL as a parameter, and retrieves a set of variablename=value results, separated with an & sign. There’s nothing stopping you however to implement your server side logic as a web service, and provide a specific proxy implementation for your Flash Lite clients, which invoke the service on behalf of the Lite client, serializing the results in the format accepted by loadVariables.

Testing, Deployment

Although there are Unit Testing frameworks available for Flash, I don’t think they have specific support for Flash Lite. The most straightforward way I’ve found was basically the following:

• Build as much as possible into separate “functions” on separate sub-movies
• Put test code in the main starting keyframe of the sub-movie for each function
• You can execute this manually from the IDE, but the client will only call the separate functions or keyframes, so the test code will not run unnecessarily when deployed

The Flash IDE will be able to run the application in a mobile simulator, with multiple supported device profiles, so it can be tested without having to copy it on the phone, however some functions are not supported on the emulator, typically specific FSCommand functions.

There are two main ways I’ve found to get the Flash Lite application on my SonyEricsson w900i phone.

• The first option is to publish the SWF compiled file onto a website. Then we can browse to the site on the mobile handset’s internet browser, and execute the Flash movie within the browser. This is not ideal, because each time I need to run the app, I need to go out to the internet, and pay for the traffic to my mobile data service provider. I’ve found that I cannot save the SWF file successfully from the browser for offline access.
• The second option requires access to my mobile’s file system. Using the USB data cable, I was able to save the flash file into the Saved Web pages folder on the mobile. Then from the File Manager on the phone, I was able to execute the SWF file successfully. This is great, because I don’t have to go online to launch the application. The only downside is that I cannot create a shortcut or menu item to this Flash movie on the handset, so anytime I want to launch the app, I need to drill down on the folder hierarchy on the file manager to navigate to the app.

Final Thoughts

As I am a developer more accustomed to object-oriented programming platforms and languages, I must admit that I’ve found the animation and movie-based logic in the IDE and in the language quite different from anything else I’ve done. I guess this is why Adobe/Macromedia provides the Flex platform for more code-oriented developers.

I’m sure that web-based Flash designers will be more productive using Flash Lite than me. What I did found interesting is how the IDE and the philosophy behind it made me develop something that’s more visual and dynamic than what I implemented on the J2ME platform. Because animation comes free with the platform, it’s trivial to use it, and the form designer is all about graphical components, I believe the application I developed became more enjoyable and visually more appealing.

Looking at the Flash Lite 2 platform, it has major enhancements to the core language, it has functions, local storage, XML support, basically all the key things I missed from Flash Lite 1.1. It will take a while until enough handset supports it. The good thing is that I recently got a Windows Mobile 5-based handset at work, which has Flash Lite 2.1 support, so I will have a chance to implement something on it. Whenever I get around to do some development, I plan to share my experiences on this blog.