Working with Application Cache

When working with offline JavaScript applications it is important that they can handle being reloaded as well as they can continue to work if the browser or device is completely restarted. The best way to deal with these types of situations is to use the application cache.

We are working on providing samples that show how to use this. They can be found in the repo's /sample directory. We have also provided an appCacheManager.js library to help with monitoring application cache events. This will accelerate your ability to troubleshoot issues.

We have also provided a Grunt task that uses grunt-manifest to assist with creating the manifest file.

Best Practices

1. Best way to cache the ArcGIS API for JavaScript? Host the ArcGIS API for JavaScript libraries on your own server or, when the ArcGIS Web Optimizer becomes available use that to create a CDN copy. The reason for this is when the application cache tries to load the init.js file from the CDN version it will fail. init.js introduces an http redirect and the application cache API simply has no built-in way to resolve http redirects.
2. Keep total database size below 100MBs. This is a rough rule of thumb. It includes the tile cache database as well as the files stored in the application cache. Mobile browsers are subject to memory constraints depending on the resources available on the device. Keeping the size as small as possible will help with performance and reduce the chance of the browser crashing.

Misc. Notes

1. The manifest will fail to load if any of the URLs contain an HTTP redirect.
2. The manifest will fail to load if there are any errors.
3. On Chrome and Firefox, you can simply empty the browser cache to delete a manifest file. Safari can be very sticky and you may have to make a small change to the manifest file, itself, to force the browser to load the manifest.

References:

Using the application cache (Mozilla)

Managing application storage (Chrome)