One of the biggest challenges of developing crossplatform applications using Flash and MDM Zinc is properly loading external assets. Typical assets include images, data (css, xml, txt etc...) and video (flv typically). The main outline of our task is as follows:

1. Determine what type of path
   we need to properly load each type of asset on each operating system. This
   is the most time consuming part.
2. Develop a method of
   determining which operating system we are on (without having to change any
   code).
3. Put together a package of
   classes that detects operating system and returns the proper path. At this
   point it is also helpful to plan on future platforms, such as the AIR
   runtime environment or running on a web server.

So without further ado, let's get on with it...

1. Determine proper path formating for each platform

This was pretty time consuming but after putting together a basic app I was able to easily extract the following rules for loadpaths and Zinc:

• Data and Images can be loaded
  in relatively or via an absolute path on OS X and Windows
• FLVs must be loaded in with
  absolute paths on both platforms
• On OS X paths must be
  separated by a colon ":" not a slash "/".
• These rules applied whether
  the application was being loaded from a CD-ROM or from a hard drive

2. Develop a method of determining which operating system we are on
(without having to change any code).

This one was pretty straight forward. Although MDM Zinc
offers a few handy variables such as "Application.winVerString" and
"Application.macVerString" I found those to be unreliable. For example, on Windows Vista winVerString shows up as "" or undefined.
On Mac 10.2: Mac OS 10.2.8 On Mac 10.3: Mac OS 10.3.9 On Mac 10.3: Mac OS
10.4.9 On Win XP: Windows XP On Win 2000: Windows 2000 On Win Vista: Windows Vista

3. Put together a package of classes that detects operating system and returns the proper path.

Finally the "fun" part begins. At the end of this
post you can download a package of classes that should do the job for you but let's look at an overview and a few choice details of these classes. Since we can load everything in via an absolute path, it was simpler to load data and images in that way even though it wasn't necessary.

Overview of twutils

UtilityManager
This is a class that creates an instance of an "environment" upon construction. By default this is a
ZincEnvironment, a class we discuss next, but in theory we could have multiple environments such as a TestingServerEnvironment or an AirEnvironment, etc... I think it is very important to maintain a gateway like this so you can easily switch environments when midway through a project there is a change in delivery method.

Environment
This is just a base class for other environments to extend off, I chose to extend off a base class rather than use an interface becaue you can not require a static function through interfaces. A static function is required because I also think an environment should be a singleton class, because after all you're only in one environment at a time.

ZincEnvironment
This is where most of our research work is
finally put into code. The class is responsible for receiving a relative path (with the standard forward slash separating folder and filename) and return an absolute path with the proper separator.

How to use twutils
Here is some sample code showing how a person could use the twutils class


import twutil.UtilityManager
mdm.init(); // some sort of call to mdm from the main timeline is necessary to initialize any mdm methods/properties

var utilMan:UtilityManager = new UtilityManager();
var imageFile:String = utilMan.getFilePath("Assets_and-stuff!/myLong_name_for-image1.swf")
var flvFile:String = utilMan.getFilePath("Assets_and-stuff!/myLong_name_for-movie1.flv")
image_ldr.contentPath = imageFile
playback_flvp.load(flvFile)
playback_flvp.play();


I hope that people out there will benefit from the many hours I spent beating my head against the wall over Zinc filepaths. You may notice that we left this class package wide open for using other environments, such as a standard webserver and/or Adobe Air. The goal is to be able to switch from web to executable delivery very easily and without having to change any significant code in our project.