10.6. Caching

If the accessed data is not changing during the course of its reuse it always makes sense to cache it. Caching is a time-tested way of increasing performance by avoiding data fetches across the network and using pre-fetched local data instead.

Caching emerged in the world of databases and operating system file access and became a popular technique in web applications. Most browsers today cache content that promises to be idempotent and rarely changing. Therefore, a web site's static content and images are often fetched from cache after the first time, when they are loaded. Browsers also define a cache expiration policy to make sure content does not reside for periods beyond which its usefulness is questionable, becoming stale.

A Flex application runs in a browser and delegates all its web user agent responsibilities to the browser. Therefore, all HTTP requests that involve the GET method are, by default, cached on the user's disk. Only in situations where the browser cache is turned off or the HTML wrapper page explicitly defines <META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE"> head tag is the caching not available.

Sometimes, the caching facility also has a notorious side effect, when calls to remote destinations for data involve GET method calls. Subsequent calls to the data fetch remote URI using the GET method are served from the cache and a trip to the remote destination is skipped. This is sometimes a problem as the application data may be stale. A small workaround like appending a random variable to the URL string can make the browser believe that the request is new and different from the earlier one. Alternatively, using the POST method avoids the problem altogether as POST methods are not idempotent and are not cached by the browsers.

Apart from the browser cache, you also have the Flash Player cache that could be leveraged to enhance the performance of Flex applications. Flex applications download an application .swf before they play it. If the Flex application .swf is large, there could be a substantial wait time during download. The upfront high download time is a deterrent to superior user interactivity and responsiveness.

To alleviate the pains of big upfront download, Adobe introduced the concept of Runtime Shared Libraries (RSL) for Flex applications. RSLs use the concept of dynamically linking referenced libraries at runtime.

To explain this further, let's take a hypothetical example. Say that you have two applications, A.swf and B.swf, both of which are served from the same domain. You realize that both these .swf files share a fair bit of code. So, you abstract out the common elements into a self-contained library, say common.swf. This prompts you to refactor A.swf and B.swf into much smaller compiled binaries which you now perhaps call A1.swf and B1.swf.

When you access A1.swf, both A1.swf and common.swf are downloaded, as both these pieces are required to run the application, which was earlier bundled as A.swf. However, if you subsequently access B1.swf only B1.swf is downloaded. The shared library file, common.swf, is not downloaded, as it's already available in the browser's memory cache.

By using a shared library that is downloaded at runtime, you can save on download size and time when multiple subsequent applications from the same domain use the same shared library. This enhances performance and interactivity.

Next, consider another application, which I now call C1.swf. Say that C1.swf is served from a domain different from the one from where A1.swf and B1.swf are served. Also assume that C1.swf can leverage the same shared library common.swf. The question then to ask is: If A1.swf and common.swf are already downloaded and then C1.swf is downloaded, would it be able to reuse the already locally available common.swf? The answer to this important question is "no". A1.swf and C1.swf will not be able to share common.swf, as they are served from different domains. They can share an RSL only if it's served from the same domain.

However, starting with Flash Player 9,0,0,115 (Flash Player 9 Update 3), there is a way A1.swf and C1.swf, even though served from different domains, could leverage a runtime shared library.

The Flex Framework RSLs now can come in a special flavor called signed RSLs. RSLs signed by Adobe are cached in the Flash Player, which can be shared by Flex applications served from different domains and accessed by different browsers that share the same Flash Player cache. Such RSLs signed by Adobe end with a .swz extension.

10.6.1. Signed Framework RSL

At this stage, I will create a sample application and link it to the signed Flex "framework.swz" file to illustrate how one could include and leverage Adobe signed RSLs.

To use RSLs, signed or unsigned, you need three pieces of information:

• Path to the library .swc file that will be delivered later as RSL. Flex needs the .swc at compile time. The RSL "digests" are contained in the .swc file, which are used for validation when the RSL is available at runtime.

• URL of the RSL.

• URL of the security policy file (crossdomain.xml) for the domain from where the RSL will be served.

In addition, you may need a pair of failover URLs for the RSL and a URL to access the cross-domain policy file for the domain that will serve the failover RSL. Failover RSLs are useful when there are problems connecting to the primary server and when Flash Players do not support the version of RSLs available at the primary URL.

Next let's open up Flash Builder and create a new Flex project that will leverage RSLs, in particular signed RSLs. You are familiar with the process of a Flex project creation in Flash Builder so I will skip all those details here.

The Flex application, called SignedRSLSampleApplication, is elementary and all the code is as follows:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
    <mx:Label text="Signed RSL Sample Application"/>
</mx:Application>

Now, go to the project Flex Builder Path view accessible through the project Properties menu option. Once the screen comes up, choose the Library Path tab. When you are at the Library Path screen, you will see a screen like the one shown in Figure 10-2.

To use the framework RSL all you have to do is switch the Framework Linkage combo box selection from Merged Into Code to Runtime Shared Library (RSL). See Figure 10-3 to view this selection.

Now once you recompile, you will see a drop of over a 100k in file size for this low footprint .swf. This is because the framework .swc, which contains the Flex framework essential components, is linked to the application as an RSL. This was possible because flex-config.xml, which resides in the sdks3.2.0frameworks directory contains the following entries by default:

<runtime-shared-library-path>
      <path-element>libs/framework.swc</path-element>
      <rsl-url>framework_3.2.0.3958.swz</rsl-url>
      <policy-file-url></policy-file-url>
      <rsl-url>framework_3.2.0.3958.swf</rsl-url>
      <policy-file-url></policy-file-url>
   </runtime-shared-library-path>

Figure 10.2. Figure 10-2

Figure 10.3. Figure 10-3

To conclude, RSLs reduce the application's size and thereby work more efficiently with signed RSLs, which once downloaded from any domain remain in the local Flash Player cache and can be reused. At this time signed RSLs are only available for the Flex framework—related RSLs. User RSLs are unsigned.

I used the Flash Builder to create the signed RSL but you could also use the command line mxmlc compiler and pass in these options when using it. Alternatively, you could also leverage the Flex ANT tasks for creating applications that leverage signed RSLs.

Next, resource pooling is illustrated. Resource pooling provides further performance gains on top of caching.