Handle Duplicate Content and Caching

Duplicate Content:

When we're testing apps, we often see ones that download duplicate HTTP objects. By "duplicate content" we mean:

• Content that has no caching information in the headers (examples of caching information are "Max-Age" and "Expires" lines in the header).
• Content that has valid caching information that is not expired (yet the files were downloaded anyway).
• Content that has been cached, the caching information has expired, the file was unchanged on the server — but the file was still downloaded anyway. This is typically caused by the client, which does not perform cache validation by including "If-Modified-Since" or "If-None-Match" directive in an HTTP request header.
• Content that has been cached, the caching information has expired, but the file was unchanged on the server, and the server generated a 304 response. In this case, since the file was not downloaded again, this is a desirable result.

Couple of ways to come at this one...

On the server:

• Be sure to properly set the caching information. If your setting is too short, it may cause content that is still current to be reloaded multiple times.
• If the object is not changed, use HTTP 304 instead of transferring the whole object.

On the client:

• Use a cache. Simple, eh?
• Make sure you're properly handling HTTP caching. If the object is cached and the caching information is not expired, there's no need to issue an HTTP request.
• When a cache entry expires, the UE should perform cache validation by using an "If-Modified-Since" or "If-None-Match" directive in an HTTP request header. Otherwise the server won't be able to use HTTP 304.

Caching:

We've also found that many applications repeatedly download files and data, even when there are no changes to the files. Since many developers are using content that has been optimized for the mobile web, the content is already populated with the caching headers required. In this case, a local cache for the application must be invoked.

Caching is an important tool for the mobile developer.

• Cached files are instantly available, with no download lag. That means your application feels faster to the user. Caching makes batteries last longer.
• Every time your app needs to make a data connection, it drains the battery. Hog too much battery and users will dump your app.
• Downloading files over and over increases data usage and cost users money. Guess what they think about apps that cost them extra money.
• Wireless networks have limited capacity. If you clog the tubes with needless downloads, it slows everyone down.

Believe it or not, even a 4kb image can make a huge difference. Let's say your app has 5,000 users (congrats, by the way). If they have to download a single 4kb image twice each session, it means 19MB of needless data sent to your users. And that means using the radio power to drain more than a third of a Samsung Captivate™ battery.

To cache effectively, your content needs headers. This change has to be made at the server level. If you're ready to implement a caching regime, it's important to think about your content's lifespan.

For example...

• Sports team logos — long shelf life
• Blog post — a shelf life of just hours
• News images — perhaps a day
• News stories — changes several times an hour
• Weather data — could easily change every 5-10 minutes

Once you determine the appropriate timings, you can add the right headers.

Want to learn more about managing Caching? Read our Best Practices document: Top Radio Resource Issues in Mobile Application Development and have some fun playing the game below:

What would happen if your user reacted the same way as an app that doesn't cache its data? As the forecast stays the same, he'll load up multiple shirts and get awfully warm on a sunny day.

Play Now!