All but the simplest UJML application will require external files of some kind. See Types of UJML Files. These might be external UJML code to run or link to. See Running Files, Linking Files, Component Resources. Or, they might be media files of some kind. See Media Files. Generically, any file which UJML can use in some way is a 'resource' and UJML provides a rich set of language elements, events, and functions to manage resources.

URL stands for 'Uniform Resource Locator'. It is basically a way of specifying a resource (file) that your application needs. The resource may be local to the device (on the device file system) or it may be accessed from a server over the network. How the URL is formatted determines the way UJML goes about obtaining the resource when it is requested. When a resource URL is required, it is specified with a string literal or variable value in scripting code or with the url element. See Scripting, url. 

Different devices support different file types for bitmaps and sounds. The _image_url() and _sound_url() functions provide a way to adapt a generic URL reference to a device's preferred file type at run time. See Image Support, Audio Support, _image_url() function, _sound_url() function.

UJML supports the file protocol if the device has a file system and the http protocol if the device has a network connection. Some devices may provide support for other protocols. If no protocol is provided, UJML uses the protocol that the application was loaded from. File protocol and custom protocol URLs may vary in how they are formatted from device to device. However, http protocol URLs should be the same on all devices supporting the http protocol.

For a typical resource, UJML will execute the following steps:

1. Wait until some UJML element or scripting code requires the resource.
2. Look for the resource in memory.
3. If the resource is not in memory, attempt to load it from the file system and (if appropriate) decode it.
4. If the resource is not on the file system and has a network protocol, attempt to load it over the network to the file system and return to step 3.
5. Hold the resource in device memory for as long as any UJML code requires it.
6. When the last UJML code using the resource releases it, release the memory used by the resource.

How resources are managed is application-dependent. Some applications may include all their resources on the device file system, either standalone or in a package. See Package Files. Other applications may load some or all of their resources over the network without explicitly managing them. However, to provide a good user experience in an application which relies heavily on network resources, it is important to manage resource availability in UJML code. To this end, UJML provides a rich set of events, functions, and elements to manage resources. UJML also uses default behaviors which allow the application to continue operating even if there are issues with resource loading. 

Until a resource is loaded into memory it is not available. During this period, UJML will ignore any code requiring the element. This means that images will not display and sounds will not play until the resource is loaded into memory and decoded. However the UJML application will continue to execute normally in all other respects instead of waiting for the resource. The same thing happens if the resource is a UJML application or partition which is run or linked to; the UJML program continues to execute even if the application or partition fails to load. See Running Files, Linking Files. 

UJML provides events which fire for network activity. See Handling Events, Resource Management Events. This means you can create event handlers which do things when a network resource fails to load or when the resource has loaded correctly. These event handlers can show error messages, exit the application or modify the application's behavior as needed. 

Once loaded, a network resource remains cached on the device file system when the application exits and is available without network activity the next time the application runs, unless it is specifically discarded using the _discard() function. See _discard() function. 

UJML also provides the resources element, the _prefetch() function and the _nocache URL modifier to fine-tune resource availability.

The resources element allows you to explicitly control a resource's lifetime without having code actively using the resource for something. When the state transition containing a UJML resources element becomes active, UJML will attempt to load all the files declared in any resource child elements into the device's memory and hold them there. If the files are not local to the device, they are loaded across the network as described above. See resources, resource. 

Once loaded, the files are locked into the device's memory until the state transitions out or the UJML application exits. When the state transitions out, the files are released from the device's memory unless some other code in the UJML application is using them. Any network requests in progress when the state transitions out are canceled. 

A resource element may contain special event handlers which indicate when that specific resource is available or if the resource has failed to load. See Handling Events, Resource Management Events.

The _discard() function removes a network resource which is cached on the device file system. See _discard() function. If the resource is not on the device, this function has no effect.

The _prefetch() function fetches a resource across the network to the device file system, but does not decode the file or load it into memory like the resource element. See _prefetch() function. If the resource is already on the device, either because the URL refers to the device file system or because the resource has already been fetched, this function has no effect.

If you want to make certain that a network resource is always loaded from the server, all you need to do is include '_nocache' somewhere in the URL for the resource. For example 'http://www.example.com/images/_nocache_myimage.gif' and 'http//www.example.com/_nocache/images/myimage.gif' are both valid uses of '_nocache'. In the first case, it is part of the file name, while in the second case it is a directory name. It could even be part of the domain name, it doesn't matter.

The following example shows how to use the resource element to load a sound file into device memory. If the sound file fails to load, it attempts to load a different, but compatible, file. It is part of the events.ujml sample.

<resources>
    <resource>
        <url><eval>mSoundURL</eval></url>
        <event name="onResourceAvailable">
            <script>
                showMessage(_strcat("onResourceAvailable: ", mSoundURL));
                mSoundLoaded = true;
            </script>
        </event>
        <event name="onResourceError">
            <variables>
                <var name="preferredFormat" type="string"/>
            </variables>
            <script>
                showMessage(_strcat("onResourceError: ", mSoundURL));

                preferredFormat =
                    _getStringProperty(&_PROPERTY_STRING_PREFERRED_SOUND_EXTENSION;);

                // Try for a fallback URL?
                if (!mSoundFallback)
                {
                    // See if there is a fallback we can do.
                    if (!_streq(preferredFormat, "mid"))
                    {
                        // Try .mid
                        if (_isSupported(&_SOUND_TYPE_MID;))
                        {
                            mSoundURL = "snd/sound.mid";
                            mSoundFallback = true;
                            _clear_state(sLoadSounds);
                            sLoadSounds = true;
                        }
                    }
                    else if (!_streq(preferredFormat, "wav"))
                    {
                        // Try .wav
                        if (_isSupported(&_SOUND_TYPE_WAV;))
                        {
                            mSoundURL = "snd/sound.wav";
                            mSoundFallback = true;
                            _clear_state(sLoadSounds);
                            sLoadSounds = true;
                        }
                    }
                    // Are we still not doing a fallback?
                    if (!mSoundFallback)
                    {
                        sLoadSounds = false;
                    }
                }
                else
                {
                    sLoadSounds = false;
                }
            </script>
        </event>
    </resource>
</resources>

Types of UJML Files, Media Files, Package Files, Running Files, Linking Files, Handling Events, Image Support, Audio Support, _image_url(), _sound_url(), _discard(), _prefetch(), <resources>, <resource>